「REA」とは？AIがリバースエンジニアリングでアプリを完全再現！？
REAの公式サイトでは、AIが電卓の計算ルールやゲームの加速処理を解析し、その結果を使って新しい電卓やゲームを作る例が紹介されている。
REA（Reverse Engineer Anything）は、AIエージェントにソフトウェアの解析機能を提供するツール（OSS）だ。実行ファイルや動作から内部の仕組みを調べるリバースエンジニアリングを支援する。何を解析し、どの機能を再現できるのか、導入するときにどんな権限や送信先を確認するのかを、公式資料の例から見ていく。
REAとAIエージェントは何を分担するのか
REAは、AIエージェントと外部のツールを接続する方式であるMCPに対応している。AIエージェントがREAの解析機能を呼び出すと、命令やコード、関数の呼び出し関係などが返る。ターミナルから操作するCLIも用意されている。
利用者は、解析したいソフトウェアを指定し、「CSV出力ボタンを押すと、どのファイルに保存されるか」など、調べたいことをAIエージェントに伝える。AIエージェントはREAから受け取ったコードや関数の呼び出し関係を使って、保存先までの処理を追う。必要な情報が足りなければ、REAで別の関数やファイルを追加で解析する。
利用者は、AIが示した保存先や処理の流れを、コードや実際の操作結果と照合する。公式のCSV出力の解析例では、画面のボタンからファイルへの書き込みまでを追っている。
ソフトウェアの機能を再現できるのか
公式の電卓の例では、Windows電卓の「%」が加算と乗算でどの数値を使うかを解析し、その規則を小さな電卓で再現している。REAが返すコードや解析結果から、AIエージェントが計算ルールを読み取り、新しい電卓を作る。
恐竜ゲームの例では、動作中のスクリプトから加速の規則を調べ、速度を調節できる小さなゲームを作っている。再利用したのは加速の規則で、描画やジャンプ、衝突判定は学習用の簡易実装だ。
このように、解析で確かめた規則を使って、計算や加速の機能を再現できる。再現したい機能を決め、同じ入力や操作に対する結果を元のソフトウェアと照合することが必要だ。ソフトウェア全体や、接続先サーバーの処理を含めた再現の範囲は、個別に確かめる。
REAはどんなソフトウェアを解析できるのか
実行ファイル、JavaScriptのコード、ブラウザのページでは、REAへの入力や解析で得られる情報が変わる。次の表では、公式資料にある解析機能と、自社ソフトウェアを点検するときに追加で確かめる項目を整理している。
| 対象・入力 | 解析で得られる情報 | 点検で追加確認すること |
|---|---|---|
| 実行ファイル・ライブラリ |
|
|
| JavaScript・Electronのフォルダや配布ファイル |
|
|
| ブラウザのページとデバッグ接続先 |
|
|
疑似コードは、コンピュータが実行する命令を、人が処理の流れを読めるように書き直したものだ。例えば、命令の列を「入力値が0ならエラーを表示する」のような条件や処理として示す。元のソースコードそのものではなく、開発者が付けた変数名やコメントまで復元されるわけではない。ネイティブの実行ファイルを詳しく調べる場合は、Ghidra・Hopper・IDAなどの解析ツールも必要になる。対応する形式やOSは、選ぶ解析ツールで変わる。
CSV出力ボタンからファイル保存までの処理を調べる
REAの公式JavaScript・Electronガイドでは、メモをCSVファイルとして保存するソフトウェアを題材に、出力ボタンからファイル保存までの処理を解析している。Electronは、Webの技術でデスクトップ用ソフトウェアを作る仕組みだ。このソフトウェアでは、画面を扱う処理とファイルを書き込む処理が別のプロセスに分かれている。
出力ボタンを押すと、画面側の`renderer.js`が`preload.js`の公開するAPIを呼ぶ。プロセス間の通信であるIPCを通じて`main.js`へ要求が渡り、`csv.js`で整形したメモがダウンロードフォルダの`notes.csv`へ保存される。REAは、この呼び出しと受け手を対応付け、根拠となるソース位置を示す。
公式ガイドではREA 4.1.0での解析結果を紹介している。CSV出力で呼び出される関数が分かるため、ファイルへ出力する値や、書き込みが失敗したときの処理を詳しく調べられる。実際にCSV出力の処理が実行されたかは、ソフトウェアを操作したときの記録で確認する。
導入前に確認する環境・権限・送信先
2026年10月15日に確認した導入ガイドで、Node.jsの要件は22系の22.19以降、24系の24.11以降、または26以上だ。npmも必要になる。MCPで連携するAIエージェントには、ローカルMCPサーバーへの対応が要る。セットアップはMCP接続と調査用スキルを登録するため、変更する設定を確認してから適用する。LinuxでJavaScript・Electronの静的解析などを行う場合は、公式READMEに記載されたプロセス確認用の`ps`コマンド（procps互換）も必要だ。
解析方法に応じて、実行環境も分けたい。JavaScriptなどのファイルを読む静的解析と、ソフトウェアを起動して挙動を観測する調査では、必要な権限が違う。実行を伴う場合は、調査用アカウントと検証データを用意し、接続先や書き込み可能な場所を限定する。
公式の安全境界では、REAは実行環境を隔離するサンドボックスではなく、解析器が利用者の権限でファイルを処理すると説明されている。ファイルを読む調査でも、解析環境に本番の認証情報や機密データを置かないようにしたい。
公式FAQによると、REAの解析は利用者のコンピュータで行うが、結果はAIエージェントへ渡る。その結果にはモデル提供元のデータポリシーが適用される。解析したコードや通信内容を外部のモデルへ送ってよいかは、利用するエージェントとモデルの設定まで確認する必要がある。
解析するソフトウェアは、自社のものや調査の許可があるものに絞る。顧客のソフトウェアを扱う場合は、解析の許可に加えて、得られた情報をAIサービスへ渡せる範囲も確認しておく。
解析結果をセキュリティ点検へつなげる
例えば、自社ソフトウェアのCSV出力を点検するなら、先に「どの項目を出力してよいか」「誰が実行してよいか」「どこへ保存してよいか」を決める。その条件と、REAで追った処理や試験時の出力を照合する。これは公式の解析例を点検業務へ応用する考え方だ。
結果には、解析したソフトウェアのバージョン、調べた操作、根拠となるコードの位置、実行して確かめた内容を残す。AIの説明だけで結論を出すと、実行されない分岐や、別の権限でだけ通る処理を取り違えやすい。動的に決まる呼び出し先など、解析で確定できなかった箇所も追加確認の対象になる。
ブラウザの通信も観測した範囲で読む。公式のブラウザガイドが記録するのは、観測時間内の要求と応答だ。その時間に通信が見えなかったことから、起動時や別機能でも外部へ送信しないとは判断できない。