コードを書いてもらうAIは増えたが、実行中のアプリやバイナリの中身まで追えるわけではない。そこに踏み込もうとしているのが、RE Aという新しいツールだ。見せ方はかなり野心的で、単に「逆解析できます」では終わらない。コーディングエージェントに調査の手足を与え、調べた結果を自然文で説明させ、そのまま再実装までつなげようとしている。元記事は、その考え方をCalculatorやChromeのDinosaur gameで具体的に見せている。
REAは「Reverse Engineering for Your Coding Agent」をうたうサイトで、アプリ、binary、browser behaviorをコーディングエージェント経由で逆解析するための道具だ。トップでは、まず npx rea-agents@latest setup を実行してRE Aをエージェントに接続し、セットアッププランを承認してから再起動する流れが案内されている。Node.jsやcoding agentがない場合は、段階的なセットアップガイドに進む。
サイトは、reverse engineeringを「プログラムそのものを観察してソフトウェアの動きを理解すること」と定義している。目的は、機能を説明できるところまで理解し、変更したり、作り直したりすること。元記事ではその入口として、Windows Calculatorで 200 + 10% が 220 になる理由を例に出す。RE Aなしだと、命令列を読んで分岐をたどり、呼び出し先を追い、ルールを復元する作業になる。記事中では、0x5b と 0x5c という命令IDを見て、それぞれ Divide と Multiply に対応づけ、さらに関数の呼び出しを調べて「100」で割る処理だと見抜く流れが示される。最終的には、+ のときは「最初の数の10%を足す」、× のときは「10%を0.1として扱う」という動作にたどり着く。
もうひとつの例はChrome系のDinosaur gameだ。記事は、なぜ恐竜が速くなるのかを確かめるために、実際に動いているページのスクリプトをRE Aで読み、currentSpeed が MAX_SPEED に達するまで ACCELERATION を足し続けるコードを取り出す。設定値は ACCELERATION: 0.001、MAX_SPEED: 13、SPEED: 6 とされ、4,000回更新すると速度は10.0、10,000回で13.0になると説明されている。RE Aはこれをもとに、速度スライダー付きの小さな再現ゲームまで作る。元記事では、これを「調査結果を読ませるだけでなく、再現物まで作る」例として置いている。
サイト全体を見ると、RE Aは単なる解析補助ツールというより、エージェントに「実際のコード」「ハンドラの命令」「呼び出し関係」「実行中の設定」を渡して、そこから自然言語で説明し、さらに再構成させるための中間層として設計されている。対象は native binaries だけではなく、JavaScript & Electron、browser & runtime activity にも広がっている。つまり、調査対象の種類ごとに違う入口を用意しつつ、最後は「理解したものを動く形で返す」ことを狙っているわけだ。
私は、このサービスの肝は「逆解析そのもの」より、逆解析をAIの作業手順に落とし込んだところにあると思う。昔ながらのreverse engineeringは、慣れた人が命令列やシンボル、呼び出し関係を丹念に読む世界だった。RE Aはそこに、エージェントが読める入力と、説明や再実装という出口をつないでいる。重要なのは、解析の正しさを“それっぽい要約”で済ませず、実際の命令やスクリプト、設定値を返す点だ。ここが曖昧だと、AIはすぐに雰囲気で語ってしまうからだ。
ただ、ここには少し怖さもある。AIに解析を肩代わりさせると、便利になる一方で、何が観測に基づく事実で、何が推論なのかが見えにくくなる。RE Aの例はそこをかなり意識していて、Calculatorでは命令列と公開ソースを突き合わせ、Dinosaur gameでは更新回数まで検証している。つまり、AIに「考えさせる」前に、観測可能な材料をきちんと渡している。私はこの設計がかなり大事だと思う。逆解析は、答えだけ合っていても危ない作業だからだ。
200 + 10% = 220 は、使う側から見れば半分お約束の挙動だが、実装は意外に込み入っている。RE Aの説明を見ると、% ボタンがいつも同じ意味ではなく、直前の演算子によって解釈が変わる。+ や - のときは前の数を基準に割合を計算し、× や ÷ のときは単純に現在の数を100で割る。こういうUIは、仕様としては小さくても、実装の中では分岐が増える典型例だ。
ここで面白いのは、RE Aが「難しいことを見つける」より「複雑に見えないものの裏にあるルールを見つける」方向で効いていることだと思う。表面上は地味だが、こういう機能の解析は、実際のプロダクトを理解するうえでかなり重要だ。特に業務ソフトや計算系アプリは、見た目のシンプルさと内部ロジックの癖がずれやすい。AIがここをうまく扱えるなら、既存アプリの移植や互換実装でかなり役立つはずだ。
Dinosaur gameの例は、CalculatorよりもRE Aの思想がはっきり出ている。ここでは「なぜ速くなるのか」を調べるだけでなく、そのルールを使って速度調整可能なミニゲームを再構成する。つまり、解析と実装が分離されていない。調べた結果をそのまま別のコードへ移すところまで含めて1つの流れになっている。
私はこの点を、教育用のサンプルとしてもかなりうまいと思う。逆解析はどうしても敷居が高く、成果物もブラックボックス化しやすい。だが、RE Aは「更新関数を読む」「設定値を抜く」「そのルールを別の小さな実装に落とす」という段階を見せるので、何を観測し、何を再利用したのかが追いやすい。しかも、スクリプトのソースとdigestまで返すという説明がある。これは、単に“AIが言った”ではなく、後で確認できる足場を残そうとしているように見える。
RE Aの使い道は、普通のアプリ開発より少し外側にある気がする。たとえば、既存アプリの挙動を再現したいとき、ブラウザやElectronアプリの内部を追いたいとき、あるいはバイナリから一部のロジックを復元したいときだ。要するに、「ソースがない、または十分に信用できない」場面で効いてくる。そういう状況では、ただコードを生成するAIより、観測から根拠を積み上げるAIのほうが価値を持つ。
一方で、万能ではないとも思う。RE Aが強いのは、ルールが観測できる対象に限られるはずだ。難読化が強いコード、動的生成が激しいアプリ、外部サービス依存が大きい機能は、きっと途端に難しくなる。だからこれは「何でも解ける魔法」ではなく、「調査の初速を上げる道具」と見たほうが正確だろう。逆に言えば、その初速が上がるだけでも、現場ではかなり大きい。手で1時間かかる下調べが5分で終わるなら、人間はその先の判断に集中できるからだ。
