【ITニュース解説】O que é REA (Reverse Engineer Anything)? O servidor MCP que alcançou 115 mil estrelas no GitHub em uma semana

REA (Reverse Engineer Anything) とは、ソースコードを持たずにソフトウェアの内部構造や動作を解析するためのオープンソースツールである。これはMCP（Multi-Client Protocol）サーバーとコマンドラインインターフェース（CLI）として提供され、Claude Code、Codex、Cursorといったプログラミングエージェントに、ソフトウェアを「分解」し理解するための機能を提供する。具体的には、ネイティブなバイナリファイル、Electronアプリケーション、.NETアセンブリ、AndroidアプリのAPKファイル、ウェブサイト、または保存されたネットワークキャプチャデータなどを解析の対象とする。エージェントが「この機能はどのように動作するのか」と質問すると、REAは擬似コード、モジュール間の関係を示すグラフ、ネットワークリクエストのログ、そしてその解析結果の根拠となる証拠データなどを返す。これにより、エージェントはそのソフトウェアの振る舞いを説明したり、あるいは同じような機能を再構築したりすることが可能になる。

この「morluto/rea」リポジトリは2026年4月にGitHubで公開されたが、最初の数ヶ月はあまり注目されなかった。しかし、同年10月の第一週に状況は一変し、わずか1週間でGitHubのスターは115,000を超え、フォーク数も25,000に達するという、GitHub史上でも稀に見る急速な成長を遂げた。この爆発的な人気の背景には、「好きな機能の仕組みを、バイナリレベルまで深く理解できる」というREASTの魅力的な提案があった。ソースコードがない状態から、プログラムが何をしているのか、どのように動いているのかを知りたいという開発者のニーズに深く刺さったのである。動画でプログラミングエージェントがデスクトップアプリケーションをバイナリから再構築する様子が広まるにつれ、「すべてのソフトウェアが解析可能になる」といった誇張された主張も生まれたが、実態としては、REAは既存のリバースエンジニアリングツールとAIエージェントを効率的に連携させるための、うまくパッケージ化された「コネクタ」として機能する。

REAはローカル環境でMCPサーバーとして動作し、プログラミングエージェントがこのサーバーを介して様々な解析ツールを呼び出す。REAは適切なエンジンを使ってターゲットを検査し、その結果を構造化された情報としてエージェントに返す。これらのワークフローはCLIコマンドとしても利用できるため、エージェントを使わずにスクリプトで自動化することも可能だ。 REAが解析できる主なターゲットとその出力、必要なツールは以下の通りである。ネイティブバイナリからは擬似コードやアセンブリ、文字列などを抽出し、Hopper、Ghidra、IDAといった専門ツールが必要になる。Goバイナリや.NETアセンブリの解析には追加ツールは不要だ。JavaScriptやElectronアプリケーションからはモジュールやインポート情報、ウェブサイトからはページ構造やネットワーク監視データ、スクリーンショットなどを得ることができ、これらにはNode.jsやChrome系のブラウザがあればよい。特に注目すべきは、HARファイルなどの保存されたネットワークキャプチャを解析し、リクエストやレスポンスのペイロード、発生源を特定できる点である。AndroidのAPKファイルやデバイスからはマニフェストや逆コンパイルされたメソッドなどを解析し、JADXとJDK、adbが必要となる。ファームウェアやWASM/EVMバイトコードの解析も可能だが、これらは主にLinux環境での利用が想定されている。 REAの設計における特徴の一つに「証拠モデル」がある。すべての解析結果には、その情報の出典（ファイルハッシュ、バイト範囲など）と、分析で特定できなかったことの明確なリストが添えられている。これにより、結果の信頼性を高めている。分析処理自体はユーザーのローカルマシンで実行されるが、エージェントが利用するモデルプロバイダには結果が送信される可能性があるため、そのデータポリシーを確認することが重要だ。

REAの導入は比較的容易である。Node.js 22.19以降とnpmが必要で、npx rea-agents setupというコマンドを実行することで、MCPサーバーが登録され、エージェントがREAの機能を利用するための設定が行われる。Claude Code、Codex、Cursor、GitHub Copilot CLIなど、多くの主要なエージェントに対応している。グローバルCLIとしてインストールすることも可能だ。JavaScriptアプリケーション、.NETアセンブリ、ウェブサイト、ネットワークキャプチャの解析には追加のエンジンは不要だが、ネイティブバイナリの詳細な解析を行うにはHopper、Ghidra、またはIDAといった専門のリバースエンジニアリングツールが必要となる。

REAは「このアプリ全体を再構築する」といった大まかなタスクよりも、「この特定の機能はどのように動作するのか」「データはこのIPCチャネルをどのように流れるのか」といった、スコープが明確で具体的な質問に対して真価を発揮する。プロジェクトが公開しているデモンストレーションからも、特定の関数やデータパスの挙動を深く掘り下げ、その結果を検証できるようなシナリオで高い効果を示していることがわかる。ターゲットが複雑であればあるほど、具体的な質問に対するREAの価値は高まる。

API開発者にとって特に実用的なのは、REAがネットワークキャプチャデータを扱う能力だ。REAのinspect_web_network_captureツールは、HAR（HTTP Archive）ファイルやmitmproxyのキャプチャデータをオフラインで読み込み、解析できる。このプロセスでは、記録されたURLへのリクエストが再実行されることはなく、認証ヘッダーやクッキー、URL内の認証情報といった機密データは証拠から除外される。 さらに、解析した証拠をinspect_analysis_viewのapi-surfaceビューで処理すると、REAは各リクエストをメソッド、発生源、そして推論されたパスのテンプレートごとにグループ化する。例えば、数値IDは{numeric}、UUIDは{uuid}といった抽象的なプレースホルダーに変換される。これはAPIのスキーマやハンドラを直接示すものではなく、あくまで「推論されたAPIの全体像（インベントリ）」である。 このインベントリは、APIリバースエンジニアリングの出発点として非常に有用だ。例えばApidogのようなAPI開発ツールと連携することで、その価値を最大限に引き出せる。Chrome DevToolsなどでHARファイルをキャプチャし、REAを使ってそのAPIサーフェスをエージェントに要約させる。次に、同じHARファイルをApidogにインポートすることで、キャプチャされたリクエストを編集可能なエンドポイント定義に変換し、モックやテストに利用できる。REAが推論したパスのプレースホルダーをApidogのエンドポイント定義の実際のパラメータに昇格させ、Apidogのスマートモック機能を使ってクライアントコードをテストしたり、キャプチャされたレスポンスの形に基づいてアサーション（検証）を作成し、継続的インテグレーション（CI）環境で実行したりすることが可能になる。REAは証拠の読み取りと説明に優れており、Apidogはエンドポイントを文書化し、モックし、テストする契約に変えるというように、それぞれが異なる役割を担い、補完しあう関係にある。

REAを採用する際にはいくつかの注意点がある。まず、リリースサイクルが非常に速いことだ。短い期間で複数のマイナーバージョンアップが行われることがあり、プロジェクトの「常にマイナーバージョンを上げる」というポリシーのため、マイナーバージョンアップが破壊的な変更を含む場合がある。REAのJSON出力に依存するスクリプトを開発する際には、バージョンを固定し、更新前に変更履歴を慎重に確認する必要がある。 また、REAは「コネクタ」であり「サンドボックス」ではない。信頼できないバイナリを解析する際、分析はユーザーの権限で実行されるため、信頼できないターゲットは隔離された環境で分析すべきだ。プラットフォームの制限も存在する。mitmproxyのネイティブデコードやファームウェア抽出、EVM/WASMの解析はLinux x64環境に限定されており、HopperはWindows版を提供していない。 法的責任はユーザー側にある。REAは合法的な調査、分析、再構築に限定されており、解析の許可を得る責任はユーザーにあることをREADMEが明示している。競合他社の機能をコピーする行為は、ツールがあっても法的問題は以前と変わらない。 最後に、REAはまだ開発の初期段階にある。100名以上のコントリビューターと多数のオープンな課題やプルリクエストがあり、ドキュメントは詳細だが、強調されていない部分には未熟な点があるかもしれない。

REAは、実際のリバースエンジニアリングエンジンをMCPサーバーの背後に統合し、解析結果の証拠を明確に文書化することで、大きな注目を集めた。特定の機能の動作、IPCチャネルでのメッセージの流れ、アプリケーションのネットワークトラフィックの解析など、明確に定義された質問に焦点を当てて活用することが重要だ。そして、API開発チームにとっては、ネットワークキャプチャ（HARファイル）をREAで解析し、その結果をApidogのようなツールに取り込んで、モック、テスト、文書化されたAPIエンドポイントへと発展させるワークフローが、非常に実用的なメリットを提供するだろう。