REA（Reverse Engineer Anything）とは — AIエージェントでバイナリを解析するMCPツールの仕組みと法的な注意点

はじめに

「あのアプリのあの機能、どうやって動いているんだろう」。そう思ったときに、ソースコードがなくても AI エージェントに中身を調べさせ、根拠つきで説明させ、自分のプロジェクト向けに似た機能まで書かせる。そんなオープンソースツール「REA（Reverse Engineer Anything）」が話題になっています。はてなブックマークでは 300 を超えるブックマークを集めました。

この記事では、REA が何をするツールなのか、MCP を使った仕組み、実際のショーケース、そして使う前に押さえておきたい法的・運用上の注意点を整理します。

REA とは何か

REA は、AI エージェントにリバースエンジニアリング用の道具一式を渡すためのツールです。リポジトリ（morluto/rea）の作成は 2026 年 4 月で、10 月 13 日時点で GitHub のスター数は約 14.7 万。ライセンスは MIT で、実装は TypeScript です。

セットアップは次の 1 コマンドです。

npx rea-agents setup

対話形式で使うエージェントを選ぶと、REA の MCP サーバーと調査手順を書いた指示ファイルがエージェントに登録されます。既存の設定はバックアップされます。対応エージェントは Claude Code、Codex、Cursor、Gemini CLI、Grok Build などで、ローカル MCP サーバーを扱えるものなら手動登録でも使えます。

あとはエージェントに次のように頼むだけです（README の例）。

Understand how search works in the Notes app, show me the evidence, and build a similar feature for my project.

ターミナルから直接使うこともできます。たとえば展開済みの Electron アプリを解析するなら次のとおりです。

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

仕組み — 「解析エンジンを MCP の裏に並べる」設計

REA 自体は逆アセンブラではありません。既存の解析ツールを束ね、エージェントが MCP 経由で呼べる形にそろえる「つなぎ役」です。ターゲットごとに使う道具と返す情報は次のように決まっています。

ターゲット	返す情報	必要なもの
ネイティブバイナリ	疑似コード、アセンブリ、文字列、シンボル、呼び出し関係	Hopper / Ghidra / IDA のいずれか
JavaScript / Electron	モジュール、import、ソースマップ、IPC	Node.js と npm
.NET アセンブリ	メタデータ、CIL 命令	追加不要（静的解析）
Android APK	マニフェスト、クラス、逆コンパイル結果	JADX と JDK
Web サイト	ページ構造、スクリプト	Chrome 系ブラウザ
ファームウェア	領域、抽出結果	Binwalk / Unblob（Linux）

ほかにも Go バイナリ、WASM、EVM バイトコード、SQLite データベースなどに対応しています。

流れは「エージェントが調べたい対象を指定 → REA が解析ツールで検査・追跡 → コード片・参照・わからなかった点をまとめて返す → エージェントが説明・実装・テストを行う」です。返却値に「わからなかった点」を含める設計が重要です。LLM は分からない箇所をもっともらしく埋めがちなので、どこまでが証拠でどこからが推測なのかを結果として明示させています。

公式のショーケースでは、Notion デスクトップアプリのコピー処理を追跡した例が紹介されています。画面側が使うクリップボード API を見つけ、preload と IPC を経由してメインプロセスに届くまでをたどり、リッチなクリップボード形式まで調べています。古いゲーム DX-Ball では、音の左右位置を計算する関数を C で再構成し、元の x86 実装と照らし合わせた 3,205 件のケースに合格、コンパイル後の関数 63 バイトもすべて再現した例が載っています。

エンジニアへの影響と使いどころ

一番実用的なのは、自分のアプリが外からどう見えるかを確かめる用途です。Electron アプリに本番用のソースマップが残っていないか、preload が必要以上の API をページに公開していないか、APK に API キーが埋め込まれていないか。こうした点検は、攻撃者が同じ道具を使える以上、先に自分でやっておく価値があります。

一方で「他社アプリの機能を作る」用途には、次の 3 点で注意が必要です。

法律と規約は別物: 日本では 2018 年に改正され 2019 年に施行された著作権法 30 条の 4 が、著作物を「享受」しない利用を必要な限度で認めており、改正の説明ではソフトウェアの調査解析もその例に挙げられています。ただし「著作権者の利益を不当に害する場合」は対象外です。また、ソフトウェアの利用規約がリバースエンジニアリングを禁じている場合、契約違反の問題は著作権法とは別に残ります。個別のケースは専門家に確認してください。
クリーンルームにならない: 互換実装では「解析する人」と「実装する人」を分け、仕様だけを受け渡すことで元コードの表現を持ち込まないようにする「クリーンルーム設計」という手法があります。REA では同じエージェントが疑似コードを読み、そのまま実装まで書くので、この分離が働きません。参考にした結果が元コードの表現に近づいていないかは、人が確認する必要があります。
解析はローカルでも結果は外に出る: REA の FAQ にあるとおり、解析そのものは手元で行われますが、解析結果はエージェントが受け取り、その扱いはエージェントが使うモデル提供元のデータポリシー次第です。クラウドの LLM を使うエージェントなら、解析結果はモデルへの入力として外部に送られます。顧客から預かったバイナリや社外秘のアプリを解析する場合は、この点を契約や社内規程と照らし合わせるべきです。

README でも、用途は「合法的な研究、教育、相互運用、ソフトウェア保存、所有または許可を得たソフトウェアの解析」のためのものと明記され、違法・無許可の利用は認めないとしています。IDA や Hopper などの商用ツールは、それぞれ正規のライセンスが必要です。

まとめ

REA は Hopper / Ghidra / IDA や JADX などの解析ツールを MCP でエージェントにつなぐ OSS
ネイティブバイナリ、Electron、.NET、APK、Web、ファームウェアなど対象が広い
結果に「証拠」と「わからなかった点」を含める設計で、LLM の推測と事実を分けている
一番の使いどころは、自分のアプリの露出点検
他社アプリの模倣には、利用規約・クリーンルーム・データ送信の 3 点の確認が欠かせない

リバースエンジニアリングは専門家の手作業から、エージェントに頼める作業になりつつあります。守る側も同じ道具を前提に、自分のアプリを見直す時期に来ています。