質問から解析ツールの呼び出しへ

REA（Reverse Engineer Anything）は、AIエージェントから既存の解析ツールを呼び出し、結果を次の調査へ引き継ぐ仕組みです。エージェントはMCP経由で解析を要求し、REAは選択した解析エンジンの結果を根拠情報とともに返します。CLIからも同じ解析ワークフローを利用できます。[1]

操作・結果の説明は、2026年10月17日に確認したmainブランチの文書に基づきます。npm公開版で確認できた範囲は、提供バージョンの節で区別しています。

ネイティブバイナリの調査ではたとえばopen_binaryに対象ファイルのpathとprovider_idを渡し、analyze_functionで関数名やアドレスを指定します。対象とプロバイダーを選び、関数の命令や疑似コード、参照関係を読む流れです。[2, 1]

ネイティブ静的解析の概念図です。エージェントは返った結果を読んで説明や次の要求を組み立てます。[1, 2, 5] 外部モデルを使う場合は、エージェントの構成とデータ方針に照らして、結果の共有範囲を確認します。

解析エンジンの選択にも条件があります。autoは、対象を扱える利用可能なプロバイダーが一つなら選び、複数なら明示的な選択を求めます。選んだエンジンの実行が失敗しても、別のエンジンへ自動で切り替えない仕様です。Ghidraでは、open_binaryの成功時点ではインポートや自動解析が終わっておらず、最初の解析ツール呼び出しで処理が始まる場合があります。[3]

Evidenceから読み取れること

MCP契約の文書が示す主な返却項目は次のとおりです。[5]

項目内容読むときの注意
normalized_result操作の結果取得した情報と、その範囲を確認する
raw_result正規化結果とは別のプロバイダー表現別の表現がない場合はnull
evidence_idEvidence記録の識別子記録の内容との対応を確認するID。解析結論の妥当性は別途検証する

保持されたEvidenceをIDで参照する場合、その参照はMCP接続内で有効です。別のCLI呼び出しでは完全な記録を渡す必要があり、ID文字列だけで他の接続の記録を取得することはできません。

実装はEvidenceの意味内容から識別子を計算し、内容とIDが一致しない記録を拒否します。[6] この整合確認を通っても、解析エンジンが取得できなかった情報や、モデルが説明を組み立てる際の誤りは別に検討する必要があります。疑似コードも解析エンジンが復元した表現として読みます。[4]

たとえば、呼び出し一覧が空だったとします。facet_availabilityが取得済みと示していれば、その観測範囲で項目がなかったと読めます。未取得の項目は、facet_availabilityのavailable: falseなどで判別します。取得範囲の宣言がない古い記録の空項目は未観測として扱います。呼び出し関係のカバレッジが部分的または不明なら、「この関数には呼び出しが存在しない」という判断は保留します。[5]

関係一覧のcompleteも、プロバイダーが観測した直接関係の集合についての完了を示します。実行時のすべての経路を確認した意味ではありません。limitationsと併せて、何を観測できたかを読みます。[7, 12] CLIの終了コードが0でも、出力には部分的な根拠、警告、未解決事項が含まれ得ます。

静的解析と実行観測を選ぶ

対象の形式と、知りたいことによって使う方法が変わります。

方法主に得られる情報実行条件・確認できる範囲
JavaScript／Electronの静的解析モジュール、ソース位置、preloadやIPCの関係ディレクトリやASAR内のファイルを読む。対象アプリを起動しない
.NETの静的解析対応するPE/CLIアセンブリのメタデータ、署名、CIL、参照標準の解析器に.NETランタイムやSDKは不要。実行時のCLR挙動は得られない
ネイティブ解析命令、疑似コード、関数やデータの参照Hopper・Ghidra・IDAなどを用いる。対応OS・形式・導入条件はエンジンごとに異なる
実行観測の一例であるプロセス捕捉端末入出力、終了状態、指定パスの前後の状態など対応するLinux／macOS環境で対象コマンドを実際に起動する

静的解析の各方式は公式の対象別ガイドに記載されています。[8, 9, 1, 10] 静的に見つけた参照関係から、実行時にその経路を通ったと断定することはできません。[4]

プロセス捕捉では、対象は利用者と同じ権限で動きます。この機能自体はサンドボックスではありません。[11] 観測するパスを指定しても、対象プロセスが読み書きできる範囲を制限する設定にはなりません。実行観測を使う際は、対象を動かせる環境と権限を別に整える必要があります。

Notionの事例では何をたどったか

公式のNotion事例はクリップボード処理の経路を調べています。この事例では、エージェントがREAの静的解析結果から読むべきソース位置を見つけ、ページ向けAPIからpreloadのIPC、mainプロセス側の受信と送信元確認、Electronのクリップボード書き込みへと処理をたどります。[13]

REAの結果が入口を示し、エージェントがその位置のラッパー実装を読んで、対応する受信側へ調査を進めます。関数名などの識別子とソース位置を残しておけば、説明がどのコードを根拠にしているかを確認できます。

この事例の対象は保存されたNotion Desktop 7.6.1のパッケージで、紹介されている解析結果はREA 4.1.0で記録されています。特定のパッケージについて処理を追った事例であり、任意のアプリを完全に復元できることを示す一般的な精度評価ではありません。本記事でも、対象ソフトを使った独立の解析・動作検証は行っていません。

再構築したコードの合格基準については、関数単位のバイト照合を扱った記事で取り上げています。再構築コードを採用する場合は、対象とする関数や動作について合格基準を決め、照合結果を確認します。

ローカル解析と結果の共有先

REAの公式FAQは対象をローカルで解析する一方、結果を受け取るエージェントのモデル提供者には別のデータ方針があると説明しています。[14] 返る情報には、対象から得た命令、疑似コード、参照などが含まれ得ます。[15]

外部モデルを使う構成では、その結果がモデル側で処理される可能性があります。解析がローカルで行われるという説明だけでは、結果の共有範囲までは判断できません。実際のツール応答に何が含まれるかと、利用するエージェントの送信先・モデル側のデータ方針を確認します。

REAが前提とするのは、所有するか、解析の許可があるソフトウェアです。対象の許可範囲や、解析結果を外部へ共有できる条件を定めたうえで使います。解析ツール自体の導入・ライセンス条件も、対象ソフトの解析許可とは分けて確認します。

npm公開版とmainの説明を合わせる

2026年10月17日にnpmレジストリで確認したlatestは6.5.0で、公開日時は10月14日12

UTCでした。6.5.0の公式配布物はレジストリの整合性情報と一致し、normalized_result、raw_result、evidence_idなど主要なEvidence項目をdist/domain/evidence.jsで確認できました。これは、mainのすべてのツールや機能が公開版に含まれるという確認ではありません。

公式の導入文書はmainの説明とnpm公開版を区別しています。永続的なMCP登録はsetup時のバージョンに固定され、新しい手順やskillを入れただけでは、稼働中のサーバや登録は更新されません。

既存環境へ適用するときは、実際に動いているサーバのバージョン、提供するツールの入力スキーマと戻り値を確認してから、main文書の例を使います。