結論：小さなアプリと自作EXEでは期待どおり。大きな実アプリでは範囲を自分で絞る必要がある
REA（Reverse Engineer Anything）は、Claude Code などのAIエージェントに、逆解析（リバースエンジニアリング）用のツールをまとめて渡すローカルのMCPサーバーです。MCP は、エージェントに外部のツールをつなぐ共通の仕組みです。Windows 11 の実機で、導入から解析まで試しました。
- 導入は3.7秒で終わりました。 設定の変更は Claude Code の設定ファイルへの登録とスキルの追加だけで、元の設定のバックアップも自動で作られました。
- 自作の小さなアプリと EXE では、エージェントの説明が正解と一致しました。 無料の Ghidra と組み合わせると、シンボル（関数名）のない Rust の EXE でも、3つの関数の動作をアドレスつきで説明できました。プログラムの出力の予測も、実際の実行結果と完全に一致しました。
- 大きな実アプリ（公開OSSの Mark Text）では、そのままでは解析が終わりませんでした。 既定の全体解析は449.5秒で上限に達して止まり、解析対象を main と preload に絞ると75.3秒で通りました。最終的に説明は公開ソースと一致しましたが、決め手になったのは、抽出したコードをエージェントが直接読んだことでした。
費用の面では、1回の質問で約16万〜20万トークンを使いました。従量課金のAPIで使う場合は、費用に注意が必要です。
GitHub のスター数が大きいことは話題性の目安にはなりますが、中身の評価とは別です。スターの増え方については、末尾の検証メモにまとめました。
REAでできること
公式 README によると、REA は次のようなものを解析できます。今回実際に試したのは、太字にした項目です。
| 対象 | 何がわかるか | 必要なもの |
|---|---|---|
| JavaScript / Electron アプリ | モジュール、IPC（画面側と本体側の通信）、preload の公開API | 追加なし |
| ネイティブの EXE / DLL | 疑似コード、アセンブリ、文字列、関数 | Ghidra（無料）か、IDA Pro・Hopper（商用） |
| Go のバイナリ | Go のバージョン、モジュール、依存、ビルド設定 | 追加なし |
| Rust のバイナリ | cargo-auditable の依存一覧（埋め込まれている場合） | 追加なし |
| Windows の PE | インポートするDLL、署名テーブル | 追加なし |
| .NET アセンブリ | メタデータ、CIL | 追加なし |
| Android APK | マニフェスト、クラス、メソッド | JADX と JDK |
| Webサイト | ページ構造、スクリプト、通信 | Chrome系ブラウザ |
| GGUF / safetensors | ヘッダーとテンソル情報 | 追加なし |
使い方は2つあります。1つはエージェントに日本語で頼む方法で、たとえば「このアプリの保存機能がどう動いているか、根拠つきで説明して」のように聞きます。もう1つは、ターミナルで rea コマンドを直接使う方法です。
解析はローカルで行われます。ただしエージェントには解析結果が渡るので、その内容はエージェント（モデル提供者）のデータの扱いに従います（README の FAQ より）。
検証環境
| 項目 | 内容 |
|---|---|
| OS | Windows 11 Home（10.0.26300） |
| CPU / RAM | Ryzen 9 9950X3D / 128GB（RTX 5090 も載っていますが、今回は使っていません） |
| Node.js | v24.22.2（検証用に別フォルダへ用意） |
| エージェント | Claude Code 2.1.309（公式） |
| REA | rea-agents 6.8.0（npm、2026-10-25 リリース） |
| Ghidra / JDK | Ghidra 12.1.4 / Eclipse Temurin JDK 21.0.13 |
| 検証日 | 2026-11-03 |
今回の検証では GPU を使っていません。RTX 5090 以外の人でも、GPU の性能を気にする必要はありません。ただし、解析時間は16コアの CPU での値です。
rea-agents の導入手順
手順1：Node.js のバージョンを確認する
REA には Node.js の 22.23.4 以上（22系）、24.22.1 以上（24系）、または 26.12.1 以上 が必要です。
node -v検証PCの Node は 24.14.1 で、条件を満たしていませんでした。そこで、普段使いの Node はそのままにして、nodejs.org の zip 版（v24.22.2、約38MB）を別のフォルダに展開し、作業するターミナルでだけ PATH を通しました。
$env:Path = "L:\kobo_tools\node-v24.22.2;" + $env:Path
node -v # v24.22.2手順2：入手元を確認する
README の冒頭には、公式の入手元は次の3つだと書かれています。
- GitHub：github.com/morluto/rea
- 公式サイト：rea.tools
- npm：rea-agents
README は、名前の似たリポジトリや、コピーされた README は公式の証明にならないと警告しています。上の3つ以外からは入れないでください。
手順3：変更内容を先に確認する（dry-run）
いきなり書き込まずに、まず「何が変わるか」だけを表示させます。プロジェクトのフォルダとは別の、作業用のフォルダで実行してください。
npx rea-agents@6.8.0 setup --client claude_code --dry-run --json初回はパッケージを取得するので時間がかかります（検証では、最初のコマンド全体で16.4秒、npm のキャッシュが約295MB増えました）。途中で prebuild-install@7.1.3 が非推奨だという警告が出ますが、公式のインストール文書によれば、REA には影響しません。
--client を付けずに dry-run すると、PCにあるエージェントの点検だけが行われ、変更のプランは0件でした。検証PCでは、Claude Code、Claude Desktop、Codex、OpenCode、GitHub Copilot CLI、VS Code、Grok Build、Hermes、DeepSeek Harness、Grok Bot の10種が見つかりました。--client で指定すれば、計画に入るのはそのエージェントだけです。指定しない場合は対話画面で選びます（公式文書より。この画面は今回試していません）。
手順4：設定をバックアップしてから setup する
REA も自動でバックアップを作りますが、念のため自分でもコピーしておきます。
Copy-Item $HOME\.claude.json $HOME\claude.json.before-rea
npx rea-agents@6.8.0 setup --client claude_code今回は端末のない環境だったので --yes --json を足して実行し、3.7秒で終わりました。変わったのは次の2つだけです。
~/.claude.jsonのmcpServersにreaを追加（中身はcmd.exe /d /c npx -y rea-agents@6.8.0 mcp）~/.claude/skills/reverse-engineer-anythingにスキルを追加（8ファイル、約138KB）
REA が作ったバックアップ ~/.claude.json.rea.backup は、元のファイルとハッシュが一致しました。
設定が終わったら Claude Code を再起動します。claude mcp list で rea が Connected になっていれば準備完了です。
手順5：ネイティブ解析を使うなら Ghidra を入れる（無料）
EXE や DLL の中身（疑似コード）を見るには、解析エンジンが必要です。今回は無料の Ghidra を使いました。
| ダウンロード | サイズ | 入手元 |
|---|---|---|
| Ghidra 12.1.4 | 約570MB | NationalSecurityAgency/ghidra |
| Temurin JDK 21 | 約205MB | Adoptium（temurin21-binaries） |
最新の Ghidra は 12.2 ですが、REA が動作確認している 12.1.4 を使いました。展開したら、環境変数を3つ設定します。パスは検証PCの例なので、実際のフォルダに合わせて直してください。
$env:GHIDRA_INSTALL_DIR = "L:\kobo_tools\ghidra-12.1.4\ghidra_12.1.4_PUBLIC"
$env:JAVA_HOME = "L:\kobo_tools\jdk-21.0.13\jdk-21.0.13+9"
$env:REA_ANALYSIS_PROVIDER = "ghidra"
npx rea-agents@6.8.0 doctor --provider ghidra --jsonhealthy: true と出れば準備完了です（1.9秒）。Windows での Ghidra 連携は、公式ドキュメントでは「experimental（試験的）」の扱いですが、今回の範囲では問題なく動きました。
doctor --provider ghidra の結果（検証ログの JSON から必要な項目を抜き出して整形）試したこと1：自作の Electron 風アプリ（正解つき）
答え合わせができるように、IPC（画面側と本体側の通信）で動く機能を5つ持つ小さなアプリを作りました。どの機能がどのファイルのどの関数にあるかを、先に正解表として書いておきました。
npx rea-agents@6.8.0 analyze-javascript-application "L:\...\targets\js-app" --json| 結果 | 内容 |
|---|---|
| 時間 | 2.5秒 |
| 見つかったもの | IPC チャンネル 5/5、main 側の受け口 5/5、preload の公開API 5/5、ウィンドウの設定（contextIsolation: true）、1500ms のタイマー、上限値 20 |
| 出なかったもの | 文字列の値（保存先のフォルダ名、拡張子、URL の制限など）、HTML をエスケープしていない不備の指摘 |
| 出力サイズ | 約1MB（ソースは約4KB） |
構造（どこからどこへ通信しているか）は正確でした。一方で「何という文字列を使っているか」はほとんど出力に残らないので、細部はエージェントがソースを読んで補う形になります。
チャンネル名をループで組み立てる版（kobo:${k} のような書き方）も試しました。こちらは「動的なチャンネル 3件、対応付け 0件」と出て、推測で埋めることはしませんでした。REA の出力の注記どおりの動作です。
試したこと2：自作の Go / Rust の EXE を Ghidra で読む
関数を3つずつ持つ小さな EXE を Go と Rust で作り、REA と Ghidra に読ませました。Rust はシンボル（関数名）を残していない状態です。
| 操作 | 時間 | 結果 |
|---|---|---|
Go のビルド情報（inspect-go-binary） | 1.5秒 | Go 1.26.4、モジュール名、依存なし。正解と一致 |
Rust のビルド情報（inspect-rust-binary） | 1.6秒 | 依存一覧が埋め込まれていないことを正しく報告。rustc のコミットも検出 |
| Go の関数一覧（Ghidra） | 34.1秒 | 1,765関数 |
| Go のチェックサム関数を逆コンパイル | 38.7秒 | 値 * 0x1f + バイト（31倍して足す）。正解どおり |
Rust で kobo を名前検索 | 27.7秒 | 0件（シンボルがないので当然） |
ターミナルから使う場合は、呼び出すたびに Ghidra を読み込み直すので、上の表の操作は1回あたり30〜40秒かかりました。公式ドキュメントには「最初の関数の問い合わせに約434秒」という例が載っていますが、これは性能を絞った環境での値です。今回の環境では1分未満でした。
試したこと3：エージェントに説明させる
本番の使い方である「エージェントに聞く」形も試しました。正解表とソースは読ませない条件で、REA のツールだけを使って「この機能はどう動いているか、根拠つきで説明して」と頼みました。
| 対象 | 時間 | トークン | 正解との一致 |
|---|---|---|---|
| 自作 JS アプリ | 249秒 | 約16.8万 | 流れ、行番号、5チャンネルとも一致。わからない文字列は「不明」と回答 |
| Go の EXE（シンボルあり） | 194秒 | 約16.5万 | 3関数の動作が一致。出力の予測が実行結果と完全一致 |
| Rust の EXE（シンボルなし） | 209秒 | 約17.5万 | 3関数をアドレスで特定。出力の予測が実行結果と完全一致 |
| 自作 JS（動的チャンネル版） | 547秒 | 約17.9万 | 5チャンネルを推定できたが、大半は推論 |
シンボルのない Rust の EXE でも、結果は同じでした。エージェントは REA の逆コンパイル結果から、ハッシュ計算、0x5A との XOR、コラッツ数列の3つを特定しています。プログラムの出力（3297457 [49, 53, 56, 53] 18）も、実行する前に言い当てました。
どの回答にも根拠（Evidence ID と、ファイル・行またはアドレス）が付いていて、確認した範囲では根拠のない断定はありませんでした。
すんなり進んだわけではなく、ツールの呼び出し計156回のうち、17回はエラー応答でした。
試したこと4：実在のOSS「Mark Text」で保存機能を調べる
最後に、MITライセンスの Markdown エディタ Mark Text 0.23.0（Windows 版、app.asar 178MB、20,141ファイル）で「ファイル保存の流れ」を調べました。ソースが公開されているので、REA の説明が正しいかを答え合わせできます。
| 操作 | 時間 | 結果 |
|---|---|---|
| アプリの種類の判定 | 1.7秒 | Electron と判定 |
| JS 全体の解析（既定の設定） | 449.5秒で失敗 | 依存ライブラリ内の1ファイルで、1ファイルあたり300秒の上限に到達。出力は476MB |
| main と preload に絞って解析 | 75.3秒 | 成功。結果のファイルは311MB |
| エージェントへの質問「保存の流れ」 | 894秒 | 約19.8万トークン。照合した範囲で公開ソースと一致 |
全体解析は、18,452ファイル中の797番目で止まりました。依存ライブラリの中の1ファイルが上限に達したためで、エラーには原因と対処（--analysis-timeout-ms と --source-path）が書かれていました。実アプリでは、最初から --source-path で調べたい部分に絞るのが現実的です。
npx rea-agents@6.8.0 analyze-javascript-application "C:\path\to\app.asar" --source-path out/main/index.js --source-path out/preload/index.js --detail summary --evidence_output evidence.json --json一致したのは、保存ダイアログの分岐、キャンセルしたときの中断、.md の補完、改行の変換と文字コードの変換、書き込みに失敗したときの再試行（エラーの種類と待ち時間まで）です。
一方で、REA の解析結果だけでは届かない部分もありました。
- 絞った解析では、main 側の IPC の受け口が 0件 と出ました。実際のコードには少なくとも118か所あります。原因は特定できませんでした（同じ書き方の小さなコードでは検出できました）。
- 呼び出し元をたどる機能は0件、機能名での追跡は一致なしでした。REA 自身は「見つからないことは存在しないことの証拠ではない」と注記しています。
- 正しい説明にたどり着けたのは、REA が抽出したコードを、エージェントがテキストとして直接読んだからです。
抽出そのものにも285秒かかりました。約10.5MB の応答は MCP の上限（10MiB）を超えてエラーになりましたが、抽出自体は完了しています。
主張と実測の比較
| README の主張 | 実測 |
|---|---|
| setup はバックアップを作り、関係ない設定は変えない | 確認できた（変更は mcpServers とスキルだけ。バックアップは元と一致） |
| 静的な JS 解析に解析エンジンは不要 | そのとおり。小さなアプリでは2.5秒 |
| Ghidra でネイティブ解析ができる（Windows は experimental） | Go / Rust の自作 EXE で動いた |
| 根拠と限界を添えて結果を返す | そのとおり。わからない部分は「未解決」「不明」と出た |
| 機能の仕組みを理解して、自分のプロジェクトに作れる | 小さな対象では理解まではできた（実装の生成は今回は試していない）。大きなアプリでは、範囲の絞り込みと、エージェントがコードを直接読むことが必要だった |
向いている人・向いていない人
向いている人
- 自作アプリや OSS の配布物の中身を、根拠つきで調べたい人
- Ghidra を自分で操作せずに、エージェント経由で EXE の関数を読みたい人
- Go / Rust / PE の情報（依存、インポート、署名）をまとめて確認したい人
向いていない人
- 大きなアプリを丸ごと1回で解析したい人（範囲を絞る作業が必要です）
- 従量課金の API でエージェントを使っていて、費用を抑えたい人（1回の質問で16万〜20万トークン程度）
- 権利のないアプリを解析したい人（REA の注意書きも、権限を得るのは利用者の責任だとしています）
元に戻す方法
Claude Code だけから外す場合は、次の2つを行います。
claude mcp remove --scope user rea
Remove-Item -Recurse $HOME\.claude\skills\reverse-engineer-anything検証後に元へ戻したところ、~/.claude.json に残った差は、空の mcpServers: {} と Claude Code 自身が更新する項目だけでした。公式文書によると、rea uninstall はほかのエージェントにも適用されます（今回は試していません）。
設定とは別に、解析で残るファイルも見てください。Mark Text の抽出フォルダ（約181MB）は、一時フォルダに残ったままでした。
よくある質問（FAQ）
Q. REA は無料ですか？
REA 本体は MIT ライセンスで、無料です。ネイティブ解析エンジンは、Ghidra なら無料で、IDA Pro や Hopper は商用ライセンスの製品です。
Q. REA に GPU は必要ですか？
今回の検証では GPU を使わずに、導入から解析まで終えました。
Q. 解析したアプリはどこかに送られますか？
README によれば、REA 自体はローカルで解析します。ただし結果はエージェントに渡るので、エージェント（モデル提供者）のデータの扱いが適用されます。
Q. 市販アプリを解析してもいいですか？
REA の注意書き（DISCLAIMER.md）は、自分が所有している、または許可を得たソフトの解析を前提にしています。DRM やライセンスチェックの回避、チートなどは、プロジェクトとして支援しないと明記しています。ソフトの利用規約や、お住まいの国の法律も確認してください。
Q. Windows でも Ghidra 連携は使えますか？
公式には experimental（試験的）の扱いです。今回は Ghidra 12.1.4 と JDK 21 の組み合わせで、自作の Go / Rust の EXE を解析できました。
検証メモ（留保と注意）
権利とライセンス
| 対象 | ライセンス・条件 | 今回 |
|---|---|---|
| REA 本体 | MIT（Copyright (c) 2026 morluto）。同梱の第三者物は各自のライセンス（例：Windows のネイティブアドオンは MinGW-w64 のランタイム告知、任意依存の Frida は LGPL-2.0 系） | 使用 |
| Ghidra 12.1.4 | Apache-2.0（NOTICE の条件あり）。REA は Ghidra を同梱しないので、各自で入手 | 使用 |
| Temurin JDK 21 | GPLv2（同梱の legal で確認。Classpath Exception の条文は未確認） | 使用 |
| IDA Pro / Hex-Rays、Hopper、JEB | 各社の商用ライセンス。REA はキーやライセンスを一切付与しない。公式の注記によると、JEB の EULA は逆コンパイル結果の公開を制限している | 未使用 |
| 解析対象 | 自作のテストプログラムと、Mark Text（MIT） | ― |
REA の DISCLAIMER.md は「ソフトが公開されていることや、ファイルを持っていることだけでは、すべての操作の許可にはならない」「解析結果を得ても、元のプログラムの権利は得られない」という趣旨を明記しています。
安全面の注意
npxは npm から取得したコードを自分の権限で実行します。README も、対象のプロジェクトの外で取得するよう勧めています。- 公式ドキュメントによると、Windows の Ghidra 連携はあなたの権限で動き、サンドボックスではありません。悪意のある対象や機密の対象も対応外としています。
スター数は評価に使っていない（話題性と中身は分ける）
- 取得時点のスター数は 423,460、フォーク数は 105,575 でした（GitHub API、2026-11-03）。README の末尾にも「400,000 GitHub stars」とあります。
- 二次情報の時系列では、10月9日に約3.4万、10月15日に25.2万超と、短期間で急増しています。自然な伸びかどうかは確認できていません。不正と断定する材料も持っていません。この記事では、スター数を人気や品質の証拠としては扱っていません。
- 上の評価は、スター数とは関係なく、今回の実測だけにもとづいています。
検証方法の限界
エージェントの試験は claude -p ではありません。 検証PCのコマンド版 Claude Code がログインしていなかったため、REA の実際の MCP サーバーを起動し、中継のスクリプトを通してエージェントから呼びました。そのため、Claude Code の MCP 統合そのものと、スキルの自動読み込みは試せていません。回答の形式（「直接わかったこと／推論／わからないこと」の区別）も、こちらから指定しています。
テスト担当のモデルは Claude Opus 5.5（Claude Code のサブエージェント）です。ソースと正解表を読まない条件は指示で伝えたもので、OS の権限で禁じたわけではありません。Mark Text では、REA で抽出した配布物を読むことを許可しました。
どの計測も1回ずつです。 Go の関数の一部（134.2秒、82.7秒）は、別の解析と同時に実行したので遅かった可能性があり、上の表には載せていません。
エラーの例： recover_javascript_sources は Wakaru が未設定で Linux x64 専用のため、Windows では使えませんでした。trace_* は、圧縮された入力スキーマから seed の形がわからず、推測で失敗した呼び出しが複数あります。
未計測： 対話式の setup 画面、rea uninstall、条件未満の Node での解析の完走、Mark Text の上限を上げた全体解析、.NET と APK、実行時の観測系の機能、同じ質問を繰り返したときの精度。
Mark Text でエージェントが述べた「名前を付けて保存で拡張子を省くと、通知されるパスと実際のファイル名がずれる可能性」は未検証です。不具合とは判断していません。README の事例（DX-Ball、Notion、TH04）は開発側の記録で、今回は再現していません。
検証PC固有のこと
- PATH 上の
claudeが別のラッパーだったため、REA の登録（~/.claude.json）が見えませんでした。公式の Claude Code からは問題なく接続できました。REA の不具合ではありません。 - 条件未満の Node 24.14.1 でも、MCP の接続とツール一覧の取得はできました。解析を完走させてはいないので、動く保証にはなりません。
- 最初の setup と解析コマンドは、Claude Code の権限チェック（auto mode）に「外部から取得したコードの実行」として止められました。運営者の指示を確認してから実行すると通りました。
参考にした公式資料
- REA 公式リポジトリ（README）
- REA のインストール文書（6.8.0）
- Windows Ghidra P0（公式ドキュメント）
- THIRD_PARTY_NOTICES.md（6.8.0）
- Mark Text v0.23.0 のソース
- Ghidra 公式リポジトリ
