保守を引き継いだ業務システムに、仕様書もソースコードもない外部連携モジュールが残っている。そんな状況に心当たりがあるエンジニアに向けた内容です。Claude Opus 5.5（Anthropic が提供する大規模言語モデルの最新版）と REA という MCP サーバーを組み合わせ、実行ファイルの振る舞いを段階的に解明する手順を整理します。
MCP とは Model Context Protocol の略で、AI モデルが外部ツールを呼び出すための標準規格です。REA はこの MCP を使い、AI エージェントと逆アセンブラ（機械語を人間が読める形式に変換するツール）の間を橋渡しします。2026年10月12日に公開されたガイドが X で100万回閲覧され、2,800件ブックマークされたことで注目を集めました。REA 自体も同時期に GitHub スターが約115,000から393,000超へ急増しています。
なぜ業務システムの保守にこの話が関係するか
長期運用中の業務システムでは、外部ベンダー製のバイナリモジュールや、退職者が書いたコンパイル済み資産が混在します。ドキュメントが失われ、ソースも手元にない状態です。
こうしたブラックボックスを調査する従来手法は、Ghidra や IDA といった逆アセンブラを人力で読み込む地道な作業でした。REA はその読解プロセスに AI エージェントを介在させ、関数の命名や振る舞いの要約を自動化する試みです。
前提として、解析対象は自社が所有するか、調査権限を持つソフトウェアに限定されます。REA の README でも「所有または調査を許可されているソフトウェアの分析」に用途が限定されています。保守契約やライセンス条項の確認は、作業着手前に必ず行う必要があります。
仕組みと手順を段階的に見る
Opus 5.5 はテキストの読み書きはできても、Mach-O（macOS の実行ファイル形式）や ELF（Linux の実行ファイル形式）そのものは読み込めません。REA がこの間に立ち、Hopper・Ghidra・IDA といった解析エンジンの出力結果を、証拠（アドレス・擬似コード・文字列・呼び出し箇所）付きでモデルに返します。
セットアップは Node.js 22.23.4 以降（24.22.1+ や 26.12.1+ も可）と npm が必要です。コマンドは以下の通りです。
npx rea-agents setup
npm install --global rea-agents
rea --helpセットアップ時に設定変更のプレビューとバックアップが行われます。Claude Code、Codex、Cursor、Gemini CLI、Grok Build に対応しています。
次に重要なのが「ハウスルール」の明文化です。CLAUDE.md などの設定ファイルに、調査範囲の限定・証拠の提示義務・推測と事実の区別を明記します。業務システムの調査では、これが監査証跡の代わりにもなります。
解析はまずターゲットの種別判定から始めます。Electron アプリ（JavaScript ベースのデスクトップアプリ）なのか、ネイティブバイナリなのか、.NET アセンブリなのかで、使うツールが変わります。いきなり逆アセンブラを開くのは初心者がよくやる失敗で、JavaScript がそのまま見える Electron アプリに対して重い解析エンジンを使ってしまうケースです。
種別が判明したら、文字列抽出とクロスリファレンス（呼び出し元の数）によるランク付けに進みます。
rea inspect /absolute/path/to/program --provider ghidra --json
rea search /absolute/path/to/program entry --kind procedures --provider ghidra --json呼び出し元が147箇所ある関数は、設定ローダーのような基盤的な処理である可能性が高くなります。呼び出し元が2箇所しかない関数は後回しにして構いません。URL や認証情報らしき文字列が見つかれば、そのバイナリが外部 API と通信している手がかりになります。
最後にデコンパイル（機械語を擬似的なソースコードに変換する処理）と命名です。
rea function /absolute/path/to/program parseConfig --provider ghidra --json
rea decompile /absolute/path/to/program --procedure=parseConfig --provider ghidra --json出力結果は var_28 のような機械的な変数名だらけです。ここに「変数名を用途に応じてリネームする」「関数の目的を一文で述べる」「不明な点は推測せず明示する」といったチェックリストを添えてモデルに渡します。
既存の静的解析ツールとの違い
日本の開発現場では、バイナリ解析というと strings コマンドや objdump による手作業、あるいは IDA Pro・Ghidra を使った人力デコンパイルが馴染み深い手法です。これらは解析者の経験に依存し、1つの関数を読み解くのに時間がかかります。
REA の違いは、AI エージェントが仮説生成と検証のループを回す点です。努力レベル（effort level）という概念があり、 low・medium・high・xhigh・max の5段階でモデルの推論量を調整できます。
単純な一覧取得には medium、データフロー推論が必要な関数命名には high、30分を超える長時間セッションには xhigh、難読化された複雑なコードには max を割り当てるという使い分けが示されています。これは API コストとも直結するため、セッション単位ではなく関数単位で調整する運用が推奨されています。
この考え方は、CI/CD パイプラインでテストの実行粒度を調整する発想に近いものがあります。全部を最重量級の設定で回すのではなく、リスクの高い箇所だけコストをかけるという判断軸です。
今日確認できること
自分のプロジェクトでこの手法が該当するか、以下の観点で確認できます。
| 確認項目 | 確認方法 |
|---|---|
| 対象の所有権・調査権限 | 保守契約書・ライセンス条項・ベンダーとの合意書を確認 |
| Node.js バージョン | node -v で 22.23.4 以降か確認 |
| ターゲット種別 | ファイル形式（Mach-O/ELF/.NET/APK/WASM）を file コマンド等で確認 |
| 解析エンジンの有無 | ネイティブ解析には Ghidra/Hopper/IDA のインストール有無を確認 |
導入前には、組織のセキュリティポリシーで AI エージェントへの社内資産アップロードが許可されているかも見ておく必要があります。デコンパイル結果や文字列情報には、設定値や内部仕様が含まれる可能性があるためです。
再構築後は、元のバイナリとパリティテスト（挙動が同等であることを確認するテスト）を行います。ここまでやって初めて「再実装が完了した」と言える状態です。あわせて、ほとんどのガイドが省略しがちな、対象が通信する外部 API の動作確認も忘れずに行う必要があります。ネットワークキャプチャを REA に読み込ませる機能も用意されているため、API 呼び出しのパターンも同じ枠組みで調査できます。
まとめ
Opus 5.5 と REA の組み合わせは、ドキュメントの失われた業務バイナリを調査する際の選択肢の一つになり得ます。
導入前に確認すべきは次の3点です。
- 対象ソフトウェアの所有権・調査許諾が明確か
- 自組織のセキュリティポリシーで AI エージェントへのバイナリアップロードが許容されるか
- 努力レベルの使い分けによる API コストの見積もりができているか
まずは rea --help でコマンド体系を確認し、小さな1機能の調査から試してみると、全体の作業イメージがつかみやすくなります。