Claude Codeでアプリをリバースエンジニアリングする方法

リバースエンジニアリングとは、完成したソフトウェアがどのように動くかを理解するために調べることで、通常は元のソースコードや、そこに使われた設計資料を持たずに行う。それが何をするか、どのように組み立てられているか、何とやり取りしているかを見て、そこから逆算してその振る舞いのモデルを作り上げる。

人がこれを行う理由は、たいてい地味で、たいてい正当なものだ。セキュリティ研究者は、より悪意を持った誰かより先に脆弱性を見つけるためにプログラムをリバースエンジニアリングする。開発者は、誰も文書化してくれない古いプログラムと新しいプログラムを連携させるために、ファイル形式やネットワークプロトコルをリバースエンジニアリングする。アーキビストやホビイストは、元のハードウェアとそれを作った会社が両方なくなった後もソフトウェアを動かし続けるために、古いソフトウェアをリバースエンジニアリングする。そして時には、依存しているプログラムが文書化されていない何かをしていて、それを信頼する、あるいは回避する前に何をしているのか知る必要がある、という理由もある。

これ自体は何も新しいことではない。セキュリティ研究者やソフトウェアアーキビストは、AIエージェントが存在するはるか以前から、何十年もディスアセンブラやデバッガを使ってこれを行ってきた。変わったのは速度だ。エージェントは逆アセンブルのリストやデコンパイルされたメソッドを読み、数秒で要約できる。熟練者が何時間もかけていた作業だ。これは本物の能力の向上であり、だからこそこのガイドの後半で触れる法的・倫理的な境界線が、今になってより重要になっている。以前なら好奇心からコピーへ進む人を押し留めていた障壁が、ほぼ消えてしまったからだ。

このガイドの残りの部分は具体的だ。Claude Codeのようなエージェントをこの種の分析に結びつける、REAという1つのツールと、何かに向ける前に身につけておく価値のある習慣について順に説明する。

ここで最も重要になる区別は、何かがどう動くかを調べることと、その保護された表現をコピーすることの違いだ。インターフェースやファイル形式、ある挙動を知るためのリバースエンジニアリングは、法的には、他人のコードや資産を自分の製品に持ち込むこととは別の行為である。

この区別を軸に築かれた実践手法がクリーンルーム設計と呼ばれるものだ。1人の人物または1つのセッションが元のものを調べ、そのインターフェース、データ形式、挙動について、元のコードを一切文書に貼り付けずに、自分自身の言葉で平易な仕様書を書く。元のものを一度も見ていない別の人物またはセッションが、その仕様書だけから新しい実装を構築する。要点は、最終的な結果が元の作品そのものではなく、書き起こされた説明から生まれたものであると示せる点にある。

この点でよく引用される、やや古い米国の判例が2つある。知っておく価値はあるが、どちらも何でもリバースエンジニアリングしてよいという一般的な許可ではない。1992年に第9巡回区控訴裁判所が判断したSega Enterprises Ltd.対Accolade, Inc.事件は、ある企業がゲームコンソールのロックアウトシステムをリバースエンジニアリングし、自社のゲームをそのコンソールで動かせるようにした事例だった。裁判所は、ゲームをそもそもそのハードウェア上で動かすために必要な、保護対象外の機能要素に到達するために行われた、そのリバースエンジニアリングに伴う中間的なコピーは、その事件固有の事実関係のもとではフェアユースに当たると判断した。同じ裁判所が2000年に判断したSony Computer Entertainment, Inc.対Connectix Corp.事件では、ある企業が別種のコンピュータ向けエミュレータを構築するためにコンソールの起動ソフトウェアをリバースエンジニアリングした件で同様の結論に至り、ここでも途中のコピーを、独自に書かれた相互運用可能な製品に役立つフェアユースとして扱った。

この2つはどちらも、自分の状況へのアドバイスとしてではなく、歴史的な背景として捉えてほしい。これらは特定の事実に関する2つの個別の控訴審判決であり、フェアユースは事件ごとに判断されるものであり、他の国ではこの境界線の引き方が異なり、またコピー防止の回避を対象とした後の法律によって、DRMと結びついたソフトウェアについてはこの余地がかなり狭められている。この種の作業を土台に何かを作ろうとしている人、特に出荷や販売を意図したものであれば、それに頼る前に実際の弁護士に相談すべきだ。

REAは、個々の事件について裁判所が最終的にどう判断するかとは関係なく、独自に境界線を引いている。プロジェクトのDISCLAIMER.mdによれば、REAはDRMやライセンスチェック、アンチチートシステムその他の技術的保護手段を回避することや、独自仕様のソフトウェアやその保護されたコード・資産をコピーすることには対応しておらず、協力もしない。また、分析の出力が元のプログラムに対する権利を何も付与しないと明言している。そこから導かれる実践的なルールは、自分が所有している、自分で書いた、あるいはその他の形で調査する権限があるソフトウェアだけを分析するということだ。

ここではNode.jsのバージョンが重要になる。REA自身のREADMEは要件を正確に、Node.js 22.x（22.23.4以上）、24.x（24.22.1以上)、または26.12.1以上、プラスnpm、と記している。この種の要件はリリースごとに変わるため、インストール前に実際のREADMEと照らし合わせて確認すること。

セットアップコマンドはnpx rea-agents setupだ。READMEによれば、REAを登録するエージェントをどれにするか選ぶ手順を案内し、承認する前に提案する変更内容を示し、既存の設定のバックアップを保持する。その後、新しいMCPサーバーを認識させるためにエージェントを再起動すること。これはREA自身の説明にも明記されている。

一度きりのnpx実行ではなく常駐するコマンドラインとしてインストールしたい場合、READMEではnpm install --global rea-agentsを実行し、続けてrea --helpで利用できる内容を確認する方法が説明されている。グローバルインストールからは、自動ではなく自分のタイミングでrea updateにより新しいバージョンに移行でき、その後npx rea-agents@latest setupを実行するとエージェントの登録内容がそれに合わせて更新される。

完全には自分が所有していないものにREAを向ける前に、まず自分で書いた小さなアプリケーションで試してみること。REAをセットアップした状態で、Claude Codeにその小さなアプリを開かせ、関数ごとに何が見えるかを説明させ、自分が実際に書いた内容と比較する。この1つの練習で、セットアップが実際に機能しているかどうかを確認でき、何か重要なことに頼る前に、REAの証拠、ファイルや関数、呼び出しが実際にはどう読めるのか、その感触もつかめる。

先に触れたクリーンルームという考え方を、2つの独立したClaude Codeセッションを使って具体的な形にする。1つめは仕様セッションだ。調査する権限があるソフトウェアにREAを向け、エージェントにそのインターフェース、データ形式、主要な関数の挙動を、すべて自分自身の言葉で、元のコードや疑似コードをそのまま文書に貼り付けずに平易な言葉の仕様書として書かせる。

2つめはビルドセッションで、最初のセッションの記憶を一切持たない、まったく新しい状態で開始する。渡すのは仕様書のファイルだけにし、それ以外は何も渡さない。元のバイナリも、最初のセッションの記録も、REAの生の出力も渡さない。仕様書を満たす新しい独立した実装を構築するよう頼み、仕様書の中に曖昧な点があれば、元のプログラムが何をしていたのかを黙って推測するのではなく、そのことを伝えるよう頼む。

重要なのは、これらを1つの長い会話の2つの段階ではなく、本当に独立したセッションとして保つことだ。元のものを調べ、その後に代替物を書くことを同じ1つのセッションで行ってしまうと、まさにクリーンルーム設計が明確に保とうとしている境界線がぼやけてしまう。後になって、後半部分が前半部分に頼っていなかったことを示す方法がなくなるからだ。

これによって何が得られるのかは、はっきりと見ておくべきだ。規律を持った2セッション方式のワークフローは、後になって何かがどう作られたのかを誰かに問われた際に、クリーンルームであるという主張を裏付ける実践だ。それ自体が法的な保証になるわけではなく、出荷や販売を予定しているものを実際の弁護士に見てもらうことの代わりにもならない。