REA（Reverse Engineer Anything）まとめ：エージェントと解析ツールのつなぎ方、学ぶこと、注目点

REA（Reverse Engineer Anything、morluto/rea）は、AI コーディングエージェントがリバースエンジニアリングのツールを使えるようにするオープンソースプロジェクトです。プロジェクトのドキュメントは REA を、MCP サーバーと CLI として提供される橋渡し役であり、エージェントと一緒にバイナリやアプリを調べるための作業の進め方だと説明しています。エージェントが質問を受け取り、REA を通じてローカルの解析ツールを呼び出し、その結果を根拠に答えを組み立てる、という構造です。

この記事は、このブログの定期的な CS 記事とは別に、最近注目されているツールをひとつ紹介するものです。プロジェクトについての説明はすべて公式リポジトリと rea.tools のドキュメントにもとづいており、この記事独自のベンチマークや REA を実行した結果は含まれていません。

まず、REA でないもの

「何でもリバースエンジニアリング」という名前から、期待が大きくなりがちです。ドキュメントを読むと、次の三点ははっきりさせておく価値があります。

• 自分で真実を突き止める機械ではありません。 REA が返すのはツールの出力です。その出力を解釈して説明を書くのはエージェント、つまり言語モデルであり、デコンパイラの結果もモデルの説明も、不完全だったり誤っていたりすることがあります。
• サンドボックスではありません。 プロジェクトのセキュリティポリシーは、REA が隔離の境界ではないこと、同じユーザー権限で動く悪意のあるプロセスは脅威モデルの対象外であることを明記しています。怪しいファイルを扱うなら、隔離は REA ではなく自分で用意する必要があります。
• 「ローカルで解析する」は「誰にも見られない」という意味ではありません。 ドキュメントによると、解析は手元のマシンで実行され、REA が対象ファイルをどこかへアップロードすることはありません。しかしツールの結果はエージェントに渡り、エージェントはそれをモデル提供者に送ります。そのデータの扱いは、使っているエージェントとモデル提供者のデータポリシーに従います。

調査はどう進むか

図は実際より単純にしています。実際の調査では手順を何度も行き来し、ひとつの質問のためにツールを何度も呼ぶこともあります。それでも骨組みは次のとおりです。

1. 質問。 「このプログラムは起動時にどのファイルを読むか」のように、答えを確かめられる質問ほど向いています。
2. エージェント。 質問を手順に分け、どのツールを呼ぶかを選びます。
3. REA。 MCP サーバーとして接続されるか CLI で呼ばれ、ローカルの解析ツール（ドキュメントでは provider と呼びます）を実行し、結果を構造化して返します。どの MCP ツールがあり、それぞれ何を返すかは MCP コントラクトのドキュメントに、CLI と根拠の出力は CLI のドキュメントに、構成要素の関係はアーキテクチャ図のソースにあります。
4. 調べる、または観察する。 ここで性質が大きく分かれます。ファイルのバイトを読むだけの静的解析は、対象を実行しません。一方、対象を実行する、動いているプロセスにデバッガをアタッチする、ネットワーク通信をキャプチャする、接続した端末を操作する、デバッガや provider のコマンドを制限なく渡す、といった作業は、対象とその周りのシステムの状態を変えることがあります。二つを同じ重さで扱ってはいけません。
5. 根拠とわからないこと。 よい結果には結論だけでなく、確かめ直せる位置（ファイルオフセット、アドレス、文字列、呼び出し関係）と、まだ確認できていない部分が含まれます。
6. 説明または再実装。 エージェントが根拠をもとに動作を説明したり、似たコードを書き直したりします。これは仮説です。
7. 人による確認。 再現し、元の動作と比べ、受け入れるかどうかを判断します。ここで生まれた疑問が次の質問になります。

この流れで REA が担うのは 3 と 4 です。残りはエージェントと人の役割で、特に 5 と 7 を飛ばすと、もっともらしい話だけが残ります。

何を解析できるか

REA が扱えるとしている対象は、README の What you can analyze の節に大きな表でまとめられています。表は頻繁に変わるのでここには写さず、読むときに見るべき点だけを挙げます。

• 対象の種類ごとに必要なものが違います。 リバースエンジニアリングでよく出会う対象は、ネイティブの実行ファイル（Windows の PE、Linux の ELF、macOS の Mach-O）、.NET や JVM のようにバイトコードで配布されるマネージドコード、バンドルされた JavaScript と Electron アプリ、Android パッケージのようなモバイルアプリ、に大きく分けられます。まず自分の対象が表のどの行に当たるかを探してください。
• REA 自身が行う検査と、外部ツールに頼る作業を分けて考えます。 一部の機能は、別途インストールした外部ツール（provider）がないと動きません。利用者が指定する objdump、GDB、Rizin、Cutter などとの連携は、リバースエンジニアリングツールのドキュメントで別に説明されています。それらのツールは REA の一部ではなく、それぞれのライセンスと利用条件を持つ別のソフトウェアです。
• 静的な作業かランタイムの作業かを確認します。 同じ対象でも、ファイルを読むだけの機能と、実行したりアタッチしたりする機能では、リスクが違います。

インストールはインストールのドキュメントと公式ガイドに従うのがいちばん安全です。この記事にインストールコマンドを載せないのは、バージョンによって変わりうること、そして似た名前の複製リポジトリやパッケージがありうることが理由です。公式リポジトリ、公式サイト、そこからリンクされたパッケージだけを使い、設定ファイルを書き換える手順があれば何が変わるかを先に確かめ、ドキュメントにドライランや準備状況のチェックがあれば、まずそれを実行してください。

なぜ今注目されているのか

2026年10月14日に GitHub API で確認したリポジトリの情報は次のとおりです。

項目	値
リポジトリ作成日	2026年4月14日
スター	217,251
フォーク	53,662
確認した最新リリース	rea-agents-6.4.0、2026年10月11日公開

半年でこれだけの数字が積み上がったのは、多くの人が関心を寄せたということです。それ以上の意味はありません。スターやフォークは、コードが正しい、安全である、成熟しているという証拠ではなく、あなたの対象でうまく動くという保証でもありません。数字は確認日時点のスナップショットで、今は変わっているはずです。

関心が集まった背景は想像がつきます。コーディングエージェントが MCP で外部ツールを使うのが当たり前になり、逆アセンブラやデバッガのように習得の難しいツールをエージェントに任せたいという需要が生まれました。ただしこれはこの記事の解釈で、プロジェクトが述べている動機ではありません。

始める前に知っておくとよいこと

すべてを身につけてから始める必要はありません。エージェントが何をしているかを追える程度の知識があれば最初の調査はできますし、足りないところは調べながら埋めていけば十分です。以下は、おおよそこの順に広げていくとよいという提案です。

1. ファイルはバイトの並びです。 16進ダンプを読み、マジックナンバーとヘッダーで形式を見分けるところから始めます。実行ファイル形式は、Microsoft の PE フォーマットのドキュメントと Linux の elf(5) マニュアルが一次資料です。セクション、シンボル、インポートが何かを知っているだけで、ツールの出力がずっと読みやすくなります。
2. アセンブリと呼び出し規約。 関数の引数がどのレジスタやスタックで渡されるかを知らないと、逆アセンブル結果を追えません。同じ x86-64 でも、Windows（x64 呼び出し規約）と Linux・macOS（System V ABI）では異なります。最初は、自分で書いた小さな C の関数をコンパイルして結果を見るのがいちばんの近道です。
3. 静的解析と動的解析。 実行せずに読むことと、実行しながら観察することの違い、そしてそれぞれが何を見落とすかを知ります。Ghidra のようなデコンパイラを自分で開いてみると、同じ種類の出力をエージェントがどう解釈するかを比べられます。
4. プロセス、メモリ、デバッグ。 プロセスのアドレス空間、ブレークポイント、ステップ実行を理解します。GDB のドキュメントや、使っているプラットフォームのデバッガのドキュメントが出発点です。
5. 対象に合わせたプラットフォームの知識。 Web や Electron アプリなら JavaScript のバンドルと ASAR アーカイブ、Android なら DEX 形式、.NET なら ECMA-335 のメタデータと IL を見ます。三つすべては必要なく、いま調べる対象のものをひとつ選べば十分です。
6. MCP とツールの境界。 MCP の公式ドキュメントで、サーバー、ツール、クライアントとは何か、ツールの結果がどこへ行くかを読んでおきます。どのツール呼び出しが何を変えるかを知って初めて、エージェントにどこまで許すかを決められます。
7. 根拠、不確かさ、再現性。 結論ごとに根拠となる位置を残し、確認できなかったことは確認できなかったと書き、同じ入力から他の人も同じ結果を得られるように記録する習慣です。どのツールよりも長く役に立つ技術です。

REA 側の資料は、公式ガイドとリポジトリの docs/ フォルダが基準です。

最初の練習：自分で書いたプログラムで

最初の対象には、自分で書いたプログラムがいちばん向いています。答え、つまりソースコードを自分が持っているからです。教育用に公開されたサンプルや、ルール上解析が認められている CTF の問題もかまいません。「公開されていてダウンロードできる」ことは、解析してよいという許可ではありません。

考え方としての手順は次のとおりです。

1. 設定ファイルをひとつ読み、その値によって違うメッセージを出す小さなプログラムを書きます。
2. デバッグ情報を含めたビルドと、最適化してシンボルを取り除いたビルドを作ります。
3. ソースは見せずに、エージェントに「このプログラムはどのファイルを読み、どんな条件でどのメッセージを出すか」と尋ねます。最初は静的解析だけを許可します。
4. 答えに付いた根拠（アドレス、文字列、呼び出し関係）と、「確認できなかった」とされた部分を、ソースとひとつずつ照らし合わせます。
5. 二つのビルドの答えを比べます。シンボルがないと何がぼやけるか、エージェントがその空白を根拠なしに埋めていないかを見ます。

この練習の目的は正解を当てることではなく、エージェントの説明がいつ根拠に従い、いつ推測に移るのかの感覚をつかむことです。

限界と境界

• データの流れ。 REA が対象をアップロードしなくても、エージェントが受け取ったツールの結果（文字列、デコンパイルされたコード、キャプチャした内容）はモデル提供者に送られます。個人情報や秘密が含まれうる対象なら、まずこの点を考えてください。
• 状態の変化。 実行、デバッガのアタッチ、通信のキャプチャ、端末の操作は、ファイルを作ったり消したり、ネットワークにリクエストを送ったり、端末の設定を変えたりすることがあります。ランタイムの作業は、捨ててもよい環境で行ってください。
• 隔離はない。 前に述べたとおり REA はサンドボックスではなく、同じユーザーで動く悪意のあるプロセスはセキュリティポリシーの対象外です。
• 結論は誤りうる。 デコンパイラは元のコードを復元するのではなく、もっともらしい形に書き直します。モデルはその上でさらに推測します。重要な結論は自分で確かめてください。
• 権利と責任。 REA の作者が書いたコードは MIT ライセンスです。一緒に使う外部ツールはサードパーティ通知とそれぞれのツールの条件に従い、解析対象に対する権利はまた別の問題です。プロジェクトの責任ある利用に関する免責事項も、解析の権限、ライセンス、プライバシー、対象の権利を守る責任は利用者にあるとしています。対象の利用規約がリバースエンジニアリングをどう扱っているか、あなたのいる地域の法律が何を認めているかはケースごとに異なり、この記事が判断できることではありません。確信が持てないなら解析しないか、専門家に相談してください。

最近の動きとこれから見るべきこと

2026年10月14日時点の最新リリースは、10月11日に公開された rea-agents-6.4.0 です。リリースノートに挙げられている主な変更は次のとおりです。この記事で実際に試したものではありません。

• Android 端末の検査とリソースのデコード
• 利用者が自分で起動したローカルの JEB MCP サーバーを通じた閲覧とデコンパイル
• 大きな解析での根拠（Evidence）の要約と選択したビューの保持
• Ghidra へのインポート時の言語、コンパイラ、シードの設定
• JavaScript ソース解析のリソース上限。上限に達すると、それまでに確認できた事実と、わからない部分を明示して返します。

変更内容はバージョンごとに違うので、更新する前にリリース一覧で何が変わったか、特にツールのコントラクトや設定が変わっていないかを読んでおくのがよいでしょう。

今後の方向はプロジェクトのロードマップにあります。ロードマップが挙げる優先事項は、ネイティブコードのアーキテクチャ、型、間接呼び出しの検証を広げること、静的解析の結果とランタイムの観察を複数の層にわたって結びつけること、難読化されたマネージドコードの比較とネイティブコードとのつながりを改善すること、プロセス、プロトコル、ファイルシステム、再接続、ビルド比較の対応範囲を広げることです。ロードマップは計画であって約束ではないので、実際に入ったかどうかはリリースノートで確かめてください。

続くシリーズ

狭い問いをひとつずつ掘り下げた記事が4本続きます。この記事と同じく、ドキュメントと公開された記事をもとにしたもので、Motitory が REA を実行して書いたものではありません。

1. 最近の記事は実際に何を試したのか：独立した実行、作者が主張するデモ、報道と意見を分けて読む
2. できることと限界：できる・条件付き・対応外の境界と、Evidence の読み方
3. 長所と引き換えになるもの、これからのシナリオ：対になる長所と代償、5つの条件付きシナリオ
4. 安全に始めるために：公式フィクスチャでの最初の練習、チーム向けチェックリスト、30/60/90日の計画

参考にした資料

• morluto/rea リポジトリと README（対象の表：What you can analyze）、公式サイトとガイド
• リポジトリのドキュメント：インストール、CLI、MCP コントラクト、アーキテクチャ、リバースエンジニアリングツール、ロードマップ
• セキュリティポリシー、責任ある利用に関する免責事項、ライセンス、サードパーティ通知
• リリース一覧、GitHub リポジトリ API
• 背景資料：PE フォーマット、elf(5)、x64 呼び出し規約、Ghidra、GDB ドキュメント、Electron ASAR、DEX 形式、ECMA-335、MCP

リンクと内容は2026年10月14日に確認しました。