REAのAIリバースエンジニアリングの仕組みと性能の限界

REAは、AIがリバースエンジニアリングのツールを呼び出してアプリの動作を調査できるようにします。公開事例は、特定の機能を分析し、再実装できる可能性を示しています。これをソフトウェア産業の終わりや、サービス全体を複製できる証拠と見るのは困難です。

DX-Ballの検証数値は、公式事例の2026年10月7日時点の進行記録に基づきます。

REAとは何ですか

REAはReverse Engineer Anythingの略です。AIエージェントにソフトウェア分析ツールを接続するプロジェクトです。それ自体ですべての分析を担う単一のAIモデルではありません。

リバースエンジニアリングは、完成したソフトウェアから構造と動作をたどる作業です。韓国語では「역공학」といいます。目的は、機能の説明や互換性の確保に必要な内容を把握することです。

コンパイルは、人が書いたコードを実行可能な形式に変える過程です。このとき、コメントや一部の名前に関する情報が失われることがあります。最適化の過程で、関数や計算式の形も変わります。

ただし、すべてのアプリで名前のない機械語だけが残るわけではありません。JavaScriptコードやデバッグ情報を含む配布物もあります。そのため、分析方法はファイル形式と残っている情報によって変わります。

×

信頼できないアプリを分析する前に、セキュリティ上のリスクを抑える必要があります。

AIとGhidraはどのようにつながりますか

REAはMCPを通じて、エージェントの分析リクエストをツールに渡します。MCPは、AIと外部ツールがリクエストと結果をやり取りするための接続規格です。Ghidraは実行ファイルを調査するリバースエンジニアリングツールです。

公式READMEでは、GhidraのほかにHopperやIDAとの連携も案内しています。JavaScriptの静的解析にはネイティブの解析エンジンは必要ありません。そのため、REAの機能をGhidraの自動操作だけで説明すると、対象範囲が狭くなります。

分析は通常、次の順序で進めます。

1. 調査するアプリと機能を決めます。
2. 文字列や関数呼び出しから関連する箇所を探します。
3. 命令とデータの流れをたどって動作を解釈します。
4. 不足している根拠を追加のツール呼び出しで確認します。
5. 再実装した結果を元の動作と比較します。

Ghidraにも以前から自動解析機能があります。REAは、エージェントが分析リクエストを続けられるようにします。実際の精度は、対象、解析エンジン、モデル、検証方法によって変わります。

条件別の分析範囲

REAで確認できる範囲は、アクセス可能なファイルと実行環境によって決まります。ローカルアプリに、サーバーと通信するコードが含まれることはあります。それは、サーバー内部の実装まで含まれているという意味ではありません。

サービスの再実装には、観察した機能以外の要件も必要です。アカウントの権限やエラー処理などの動作が代表例です。画面が同じように動いても、サービス全体が同じとは判断できません。

8分41秒の計算機実験の検証範囲

8分41秒という数値は、元の記録を確認できていないデモでの主張です。あわせて提示されたツール呼び出し回数は17回です。4つの計算規則を見つけたという主張も、独立した確認はできていません。

元の動画と実行記録で試験条件を確認する必要があります。モデルとプログラムの規模によって、所要時間は変わります。1回の成功だけで一般的な分析速度や精度は判断できません。

計算機の分析では、数式を読むだけでは検証は終わりません。割引とクーポンを適用する順序によって結果が変わることがあります。整数除算での切り捨て処理も別途確認する必要があります。

• 割引とクーポンを適用する順序
• 税額を計算する基準額
• 途中の計算で四捨五入または切り捨てをする箇所
• 条件が変わる境界値での出力
• 元のコードと再実装したコードに同じ入力を与えた比較記録

分析の速さを立証するには、成功した回答以外の記録も必要です。失敗した実行や再試行の回数は比較に影響します。現在確認できている根拠だけでは、人より優れていると一般的に評価することは困難です。

公開事例で確認された成果

公式事例では、Notionのクリップボードに至る経路とDX-Ballの計算関数を示しています。どちらの事例も、調査した機能の範囲を明記しています。REAプロジェクトが公開した記録である点にも注意が必要です。

Notionの事例では、画面側の呼び出しが内部通信を経る過程を追跡しています。最後には、Electronのクリップボードへの書き込み機能につながります。これは特定の機能の処理経路を説明する事例です。

DX-Ballの事例では、関数の入力と計算に使う定数を実行ファイルから確認しました。該当する関数の比較試験は3,205件です。検討した再配置処理を反映したコンパイル結果は、63バイトが一致しました。

この記録は、特定の関数の再実装を裏付けます。公式文書では、ゲーム全体を実行可能な形に復元する作業が進行中だと説明しています。一部の関数の検証と製品全体の完成は区別する必要があります。

観察と推論の表示は何を保証しますか

根拠の表示は、結論がどこから得られたかを区別するための仕組みです。REAの文書では、観察、推論、未確認の情報を区別しています。ただし、すべてのツールが同じ4つのラベルを使うわけではありません。

公式文書には、分析の種類ごとに異なる状態や信頼度の表現が出てきます。読む際は、以下のように意味を分けると役立ちます。表の区分は理解を助けるための説明です。

公式のDISCLAIMER.mdは、分析結果の限界を明記しています。

Decompilation, reconstruction, heuristics, and AI-assisted analysis may be incomplete or incorrect.

出典：REA DISCLAIMER.md

これは、デコンパイルやAIによる分析が不完全だったり、誤っていたりする可能性があるという意味です。観察という表示が付いていても、ツールのエラーの可能性はなくなりません。根拠を表示する価値は、再検討すべき箇所を残せることにあります。

よくある間違い

最もよくある誤解は、説明できる結果を検証済みと受け取ることです。読みやすいコードでも、元のプログラムとは異なる動作をすることがあります。調査していない経路は別途明示する必要があります。

REAのCLI文書でも、正常終了と分析の完全性を区別しています。作業が終わっても、一部の根拠や疑問が未解決のまま残ることがあります。完了メッセージよりも、結果の制限事項を確認する必要があります。

分析結果を再検証できる記録

再現可能な分析には、結論を得た条件も記録する必要があります。同じ名前のアプリでも、アップデートによってコードが変わることがあります。関数のアドレスだけを記録しても、別のバージョンでは対象を見つけるのが難しくなります。

REAのEvidence記録は、対象を識別する情報と根拠の箇所を保存します。スナップショットは、条件が合う分析結果を再利用する機能です。保存された結果が、最新バージョンまで検証済みという意味ではありません。

検証記録を残すには、次の順序で進めてください。

1. 対象ファイルのバージョンとハッシュを記録してください。
2. REAと解析エンジンのバージョンを記録してください。
3. 各結論にファイル内の箇所や関数のアドレスを紐付けてください。
4. 元のコードと再実装したコードの入出力をあわせて保存してください。
5. 調査できなかった条件と失敗した試験を別に記録してください。

ハッシュは、ファイルが同じかどうかを比較するための識別値です。記録しておけば、説明がどの配布物を対象としているかをたどれます。AIが後で結果を引用する際も、適用範囲を区別できます。

ローカル分析とデータの外部送信

ローカルで分析するという説明は、作業全体で外部送信がないことを意味しません。公式READMEによると、REAによる対象の分析はローカルで進みます。ツールの結果は、接続したAIエージェントが受け取ります。

外部のモデルを使う場合、分析結果がモデルの提供者に送られることがあります。適用されるデータポリシーは、接続したサービスによって異なります。会社のアプリや非公開ファイルについては、まず送信経路を確認してください。

• モデルに渡されるコードと文字列の範囲
• ログに含まれるアカウント情報とアクセストークン
• 通信記録に含まれる個人情報
• 分析結果の保存場所と保管ポリシー

静的なファイル調査とプログラムの実行も区別する必要があります。実行時の観察は、ファイルやアカウントの状態に影響することがあります。信頼できないプログラムは、分離された試験環境で扱ってください。

開発者が確認すべきセキュリティと権利

アプリに入れた秘密情報は、リバースエンジニアリングによって露出する可能性があります。OWASPは、配布パッケージに機密情報を入れる問題について説明しています。このリスクはREAが登場する前からありました。

特に、サーバーの権限を持つ秘密のAPIキーをアプリに含めてはいけません。OWASPは、固定の秘密情報をサーバー側に置く方法を案内しています。難読化によって抽出を難しくできても、秘密を守れる保証はありません。

• 配布ファイルに含まれるパスワードと秘密鍵を点検してください。
• 認証トークンの権限と有効期間を制限してください。
• サーバーでリクエスト元の権限を検証してください。
• 露出した認証情報は交換してください。

リバースエンジニアリングが許される範囲は、国、契約、作業内容によって異なります。互換性が目的ならすべての行為が許されるとは断定できません。分析と、コードや画像の再配布は別々に検討する必要があります。

REAのMITライセンスは、分析対象に関する権利まで与えるものではありません。公式のDISCLAIMER.mdでプロジェクトの利用原則を確認できます。実際に許される範囲は、適用される法律と対象ソフトウェアの規約で確認してください。

ソフトウェア産業にはどのような変化がありますか

REAは、既存の機能を理解する作業のコストを下げる可能性を示しています。これは公開された分析事例から導ける見通しです。産業全体でのコスト削減規模について、確認された数値はありません。

一部の機能の実装方法が分かっても、サービスの運営能力は別です。データの品質や障害対応は、実行ファイルの分析だけでは複製できません。そのため、機能を模倣する容易さと事業の競争力は分けて評価する必要があります。

REAの公開事例は、ソフトウェアを理解する方法の変化を示しています。開発需要がなくなることを立証する資料ではありません。機能を再実装した後も、互換性と運用品質を検証する作業は残ります。