12分で読めます
  • AI
  • ツール
  • How-to
  • MCP
  • リバースエンジニアリング
  • GitHub

REA（Reverse Engineer Anything）の使い方——AIエージェントに根拠つきの逆解析を渡す

GitHub Trendingで話題のREAを、Node.jsの準備からMCP接続、JavaScript/Electronアプリの静的分析、根拠の読み方まで、安全な入口に絞って紹介します。

カテゴリー: AI · ツール · How-to · MCP · リバースエンジニアリング · GitHub | 公開: 2026年10月23日 | 読了目安: 約12分

📑 目次

ふむふむ。今週のGitHub Trendingを眺めていて、先頭にいた morluto/rea に目が止まりました。

キャッチコピーは、See a feature you like. Understand how it works, down to the binary level.。気に入ったアプリの機能を見つけたら、その仕組みをバイナリのレベルまで調べる——そんな道具です。

ちょっと待って。「AIにアプリを丸ごとコピーさせる機械？」と思うかもしれません。REA（Reverse Engineer Anything）が実際に渡してくれるのは、魔法の答えというより、調査のためのコード、参照、根拠、そして分からない部分です。今日は、自分が所有しているか、調査の許可を得ている対象だけを使う前提で、まず試しやすいJavaScript/Electronアプリの静的分析から歩いてみます。

REAとは——エージェントに調査道具をつなぐMCP

REAは、AIエージェントから使えるMCPサーバーであり、ターミナルからも同じ分析ワークフローを呼び出せるCLIです。MCPは、エージェントと外部ツールの間に共通の差し口をつくる仕組み。REAの場合、その差し口の先に、アプリケーションの構造を読む機能や、ネイティブ解析のためのプロバイダーがつながります。

「プロバイダー」は、実際に対象を調べる分析エンジンのことです。JavaScript/Electronの静的分析はREAに組み込まれた機能で、ネイティブバイナリの深い分析ではHopper、Ghidra、IDAなど、手元で用意したツールを使います。REAを入れただけで、必要な解析環境が自動で揃うわけではありません。

REAが面白いのは、結果を単なる説明文で終わらせないところです。各結論の根拠や対象のダイジェスト、制限事項を含む Evidence（証拠の束）として返します。研究ノートに、観察した事実と「ここから先は推測」という付箋を一緒に貼るようなものですね。

プロジェクト本体のライセンスはMITです。ただし、HopperやIDAなどの商用解析ツールのライセンスまで含まれるわけではありません。必要なツールは、それぞれの条件に従って自分で用意します。

まずは静的なJavaScript分析から始める

REAが扱える対象は広いですが、最初の一歩にはJavaScript/Electronが向いています。

  • 展開済みのJavaScript/Electronアプリのディレクトリを読む
  • .asarファイルを対象にする
  • モジュール、インポート、ソースマップ、Electronの境界などを構造化する
  • 解析結果を保存し、要約やモジュール単位の表示に絞って読む

公式ドキュメントによれば、この静的分析は指定したファイルを読み取りますが、アプリケーション自体は実行しません。一方、ブラウザー観測やプロセスキャプチャなどの別のワークフローは、対象を起動したり、実行中の状態を観測したりします。最初は「読む」操作と「動かす」操作を分けて考えるのが安全です。

インストール前の確認

REA 6.7.0の実行環境には、Node.jsとnpmが必要です。公式の現行ドキュメントが案内しているNode.jsの範囲は次のとおりです。

  • Node.js 22系（22.19以上）
  • Node.js 24系（24.11以上）
  • Node.js 26系以降

Node.js 23系と25系、プレリリース版はサポート対象外とされています。まず自分の環境を確認します。

node --version
npm --version

執筆時点（2026年10月23日）で、npmの rea-agents の最新公開版は6.7.0でした。開発の動きが速いので、記事のコマンドをそのまま長く固定するより、導入時に公式の最新要件も見直してください。

エージェントに接続する

一番簡単なのは、公式のセットアップを実行する方法です。

npx -y [email protected] setup

セットアップは、対応しているエージェントを選び、MCPサーバーの登録先と変更内容を表示してから、承認を求めます。既存の設定を確認し、バックアップを作ってから書き換える設計です。完了後は、表示された対象のエージェントを再起動します。

いきなり書き換えたくない場合は、先に計画だけを出します。

npx -y [email protected] setup --dry-run

この段階では変更を適用しません。どの設定ファイルが対象になるか、どのワークフローが入るかを読んでから、通常の setup を実行するのがおすすめです。特定のクライアントだけを対象にする場合は、公式ドキュメントにある --client の指定と、必要なら --skill=false を組み合わせます。

導入後の診断は、次のコマンドです。

npx -y [email protected] doctor --json

doctor はホストの前提条件や登録状態を読み取る診断コマンドです。HopperやGhidraが未設定でも、JavaScriptの静的分析だけをしたいなら、ネイティブ分析エンジンの不足と、自分の作業に必要な準備が整っているかを分けて確認してください。

ターミナルからアプリを分析する

ここからは、展開済みのアプリが /absolute/path/to/app にあるとします。結果は大きくなる可能性があるため、対象ディレクトリの中ではなく、別の場所に保存します。

mkdir -p analysis
npx -y [email protected] analyze-javascript-application \
  "/absolute/path/to/app" \
  --json > analysis/app-evidence.json

このコマンドは、アプリを起動せずに、JavaScriptの構造と関係を調べてJSON形式のEvidenceを保存します。公式ガイドは、実際のアプリでは完全なEvidenceが数百MBになる場合もあると説明しています。ターミナルに流れたものをその場で読むのではなく、保存して必要な部分だけ投影する、という順番が大切です。

保存したEvidenceを要約する

REA 6.7.0で inspect-analysis-view を使う場合は、保存したEvidenceを inline としてリクエストに包みます。巨大なJSONを会話にそのまま貼らず、要約表示だけを返すための手順です。

jq -c '{source: {kind: "inline", evidence: .}, view: {kind: "summary"}}' \
  analysis/app-evidence.json > analysis/app-view.json

npx -y [email protected] inspect-analysis-view analysis/app-view.json --json

この方法では jq がEvidence全体を一度読み込むので、数百MB級の対象ではメモリ使用量に注意してください。対象を小さく分けるか、導入した版のCLIガイドに保存ファイルを直接参照する形式が案内されていないかを確認するのが穏当です。要約、ページ、特定のモジュールなど、質問に必要な大きさへ絞ってから読む。これはAIのコンテキストを節約するだけでなく、人間が根拠を追いやすくするための整理でもあります。

エージェントには何を頼むか

セットアップ後、MCP対応エージェントには、対象と質問を具体的に渡します。たとえば、次のような頼み方です。

自分が所有するアプリの検索機能を調べてください。
静的分析で確認できたモジュール、呼び出し関係、根拠を示してください。
確認できた事実と推測を分け、分からない部分や追加で調べるべき点も書いてください。

「似た機能を実装して」だけで終わらせないのがコツです。どのファイルや関係を根拠にしたのか、何が未確認なのかを先に尋ねると、エージェントの説明を後から検証しやすくなります。

REAの面白さ——答えではなく、調査の足場を返す

リバースエンジニアリングは、長いあいだ専門家の経験と手作業に強く依存してきました。名前のない関数を見つけ、呼び出し元をたどり、観察したことを仮説にまとめる。REAは、その調査の流れをAIエージェントが扱える形に並べ替えます。

でも、本当に新しいのは「AIがソースコードを読めるようになった」ことだけでしょうか。

チカちゃん的には、もっと地味で大事なのは、結論の横に根拠と制限を置く設計だと思います。エージェントの返事だけを読むと、もっともらしい説明が事実のように見えてしまう。Evidenceがあれば、どの観察からその説明が出てきたのか、どこに空白が残っているのかを戻って確認できます。

反対側の見方もあります。REAは一つの万能な解析器ではなく、対象ごとの分析機能と既存のツールを、MCPとCLIでつなぐハーネスです。ネイティブバイナリの解析ならプロバイダーの準備が必要ですし、AIの解釈が正しいとも限りません。道具の入口が簡単になったからといって、対象の複雑さや検証の責任まで消えるわけではないんですね。

ここは一回、立ち止まる

許可のある対象だけを調べる

REAの公式免責事項は、所有しているか、調査の許可を得ているソフトウェアの合法的な分析を用途として挙げています。DRMやライセンスチェック、アンチチートを回避すること、認証やアクセス制御を回避すること、資格情報を窃取すること、許可のないサービスへ干渉すること、保護されたコードや資産をコピーすることを目的に使うものではありません。

公開されているファイルを持っていることと、あらゆる調査や実行が許可されていることは同じではありません。ソフトウェアのライセンス、利用規約、地域の法令、調査の範囲を先に確認してください。

ローカル分析と、モデルへの送信は別の話

REAの分析処理はローカルで動きます。ただし、MCPの結果を受け取るAIエージェントが、その内容をどのモデル提供元へ送るかは別問題です。秘密のソースコードや個人情報を扱うなら、エージェント側のデータポリシー、ログ、保存期間、利用するモデルを確認しましょう。

「ローカルで解析される」と「外部に一切出ない」は同じ意味ではありません。ここ、かなり大事です。

動かす分析には副作用がある

JavaScriptの静的分析は対象を実行しませんが、ブラウザー観測、プロセスキャプチャ、ネットワーク観測、デバイス操作などは別です。対象を起動したり、接続したり、状態を変えたりするワークフローがあります。未知のバイナリや不審なファイルを扱うときは、隔離した検証環境と、必要な権限だけのアカウントを使ってください。

出てきたコードは「原文」ではない

逆コンパイルや再構成、AIによる説明には、欠落や誤りがありえます。Evidenceがあるからといって、結論の正しさが自動的に保証されるわけではありません。重要な判断に使う前に、別の観測、実行テスト、対象の仕様、許諾範囲と照合します。

まとめ——逆解析の入口に、問いを置く

REAを試す流れは、まずこの4段で十分です。

  1. Node.jsとnpmの要件を確認する
  2. setup --dry-run で設定変更を読み、承認してMCP接続する
  3. 自分が許可を得たJavaScript/Electronアプリを静的に分析する
  4. 保存したEvidenceを要約し、根拠と未確認点を分けて読む

REAは、AIに「全部わかって」と頼む道具ではありません。対象を調べるための道具をエージェントの手元へ置き、その説明を根拠へ戻れる形にする道具です。

ソースコードが見えないものを理解したいとき、私たちはつい「答え」を急ぎます。でも、分からない部分を分からないまま残し、どこまで確かめたかを記録することも、理解の一部なのかもしれません。

あなたなら、最初にどんな機能を、どの根拠から確かめてみたいですか。

本記事は公開情報をもとにした個人的な技術メモです。REA、対応するAIエージェント、Node.js要件、MCP登録方法、分析対象や出力形式は更新される可能性があります。導入前に公式リポジトリ、公式ドキュメント、npmパッケージ、ライセンス、利用規約、対象ソフトウェアの許諾範囲を確認してください。REAの分析結果やAIエージェントの説明は、正確性・完全性・適法性を保証するものではありません。秘密情報や未知の実行ファイルを扱う場合は、データ送信先を確認し、隔離環境で検証してください。npmの最新公開版は2026年10月23日に確認した値です。

参考URL

  • インターネット上のツールは第三者が提供するものです。開発工程や配布経路を悪用した攻撃（サプライチェーン攻撃）が仕掛けられる可能性もゼロではありません。ご利用の際は公式リポジトリの情報をご確認いただき、自己責任でお使いください。
  • AIに関する技術や情報は急速に変化します。本記事の内容が公開後に古くなる可能性があります。各サービスの公式ドキュメントや最新情報をご確認ください。

近くの問い