REAの検証記事は実際に何を試したのか:実行・デモ・報道・意見を分けて読む

REAを扱った外部の記事や動画8件を「誰が何を実行したか」で分類しました。独立した実行2件、作者が主張するデモ2件、報道・意見3件、議論スレッド1件が、それぞれ何の裏付けになるかを整理します。

開発セキュリティリバースエンジニアリングAIエージェント

REA(morluto/rea)が一気に注目されてから数週間のうちに、実際に使ってみた記事、YouTube のデモ、ニュース記事、長い議論スレッドが次々に出てきました。ただし、その重みは同じではありません。この記事が扱う問いはひとつです。このうちどれが実際に REA を動かし、何を対象にし、その結果から何が言えるのか。

REA そのものについては、先に概要記事を読んでください。この記事は、続く4本のうちの1本目です。

  1. 最近の記事は実際に何を試したのか(この記事)
  2. できること、条件付きでできること、対応していないこと
  3. 長所と引き換えになるもの、これからのシナリオ
  4. 安全に始めるために

確認日は 2026年10月14日です。 以下の資料はすべて同日に原文を開いて読みました。このシリーズのために Motitory が REA を実行したことはなく、ここに出てくる数値に私たち自身の計測はありません。私たちの解釈には、解釈であることを明記しています。

資料は6種類に分けられる

資料の種類ごとに1枚ずつ描いた7枚のカードです。公式ドキュメントは意図された動作と明記された制限を示しますが、あなたの対象でどう動くかは示しません。プロジェクトが報告した事例は、プロジェクトがやったと述べている内容であり、独立したベンチマークではありません。独立した実行は外部資料8件のうち2件で、その対象とそのバージョンでの結果だけを示します。作者が主張するデモは8件中2件で、試してみる手がかりではあっても確かめられる結果ではありません。報道と意見は3件で、人々が何を言っているかを示しますが、新しい技術的根拠ではありません。匿名の議論は1件で、検討すべき反論にはなりますが事実ではありません。破線で描いた Motitory の分析は、これらの資料に対する私たちの読みであり、私たちは REA を実行していません。技術的な主張の拠り所にすべき資料として、公式ドキュメントと独立した実行に緑の枠を付けています。

この種のツールについての記事を読むとき役に立つのは、「好意的か批判的か」ではなく「誰が何を実行し、自分で確かめられるか」という問いです。この記事では資料を次のように分けました。

  • 公式ドキュメント。 コミット 29d3dcb に固定した REA のリポジトリと文書、そして 6.4.0 リリースです。プロジェクトの意図と、自ら述べている制限はわかりますが、あなたの対象でどこまでうまくいくかはわかりません。
  • プロジェクトが報告した事例。 README や公式サイトのショーケースです。プロジェクト自身の報告であって、独立したベンチマークではありません。
  • 独立した実行。 プロジェクトの外の人が REA を実行し、バージョンと環境を明かし、確認できるだけの出力を残したものです。
  • 作者が主張するデモ。 結果は見せているものの、生の出力、固定したバージョン、再現の手段がない動画や記事です。
  • 報道と意見。 ドキュメントの要約や、REA の意味を論じる記事です。
  • 匿名の議論。 掲示板のコメントです。反論を探すには役立ちますが、根拠には使いません。

読む価値があると判断した外部資料は8件でした。Medium の記事と、それを HackerNoon に転載したものは1件と数え、原文を開けなかった資料は使っていません。

8件の資料を一覧で

資料 日付 種類 何を実行したか 裏付けになること
Ishank Choudhary, HackerNoon 10月14日 独立した実行 実在の Electron アプリと小さな自作フィクスチャに REA 6.4.0 大きな JavaScript 対象1件でのカバレッジと出力サイズ
Curtis Pyke, Kingy AI 10月8日、その後更新 独立した実行 公式 Notes フィクスチャに REA 6.0.0 小さく読める対象での完全な追跡
02ui, YouTube 10月12日 作者が主張するデモ 作者によれば Apple のパスワードアプリの生成ルール 手がかりのみ
SI NEWS, YouTube 10月13日 作者が主張するデモ 作者によれば Windows 上の Bitburner 3.0.1 手がかりと、有用な失敗報告
Guru Baran, Cyber Security News 10月10日 報道 実行なし、ドキュメントの要約 公平な二次的要約
Abid Ali Awan, KDnuggets 10月12日 意見 実行なし 「AI によるソフトウェア複製」の流れについての見方
Jose Antonio Lanz, Decrypt 10月13日 意見・物語 実行なし 拡散した物語であり、REA の根拠ではない
Hacker News のスレッド 10月12日 匿名の議論 REA の再現を投稿した人はいない 反論

2本の YouTube 動画は、字幕全体ではなく公式ページの概要欄とメタデータを読みました。そのため、概要欄に書かれている内容だけを紹介します。

2つの独立した実行は並べて読む

この2件は両極端にあるので、並べてこそ役に立ちます。

小さな対象を最後まで追えた例。 Pyke は macOS 26.3(arm64)、Node 24.16 で REA を 6.0.0 に固定し、ソースが約 1.6KB の公式 Notes Electron フィクスチャを解析しました。記事によると、REA は「エクスポート」操作がレンダラーから preload のブリッジと IPC を経てメインプロセスの CSV フォーマッタに至る経路を復元し、別に書き直したフォーマッタはあらかじめ決めた14件のケースでバイト単位まで一致しました。作者は ZIP、ハッシュ、ロックファイル、生の Evidence を保存したとしています。成功と同じくらい大事な点が2つあります。この小さなフィクスチャで出力が約 907KB になったこと、そして絞り込んだ追跡では不明点が0件だった一方、プロジェクト全体のグラフにはまだ44件が残っていたことです。

実在のアプリを部分的にしか覆えなかった例。 Choudhary は Debian 13(8 vCPU)上の REA 6.4.0 で、実在する Electron デスクトップアプリの 100MB の ASAR と、自作の5ファイルのフィクスチャを解析しました。459ファイル(うち JavaScript が421)、約310万の AST ノードを52秒ほどで処理し、ウィンドウ・ブリッジ・IPC の数は素朴な grep の結果と一致しました。しかし作者の報告では、REA は preload の経路を2つ見落とし、リソースの上限のために365ファイル分の関係を結果から省き、間接的に行われる送信元の検証を捉えられませんでした。ツールの表面も大きく、tools/list の応答は約 1.95MB、コンパクトモードでも約9%小さくなるだけで、要約テキストは約 672KB ありました。トークン数は作者の大まかな見積もりで、実際の請求額ではありません。

どちらも試していないことも同じくらい重要です。長い調査でのエージェントの判断、ネイティブコード、Web ページ、APK、ファームウェア、Ghidra・Hopper・IDA、そしてアプリの「複製」に近いことは、いずれも試されていません。2件とも JavaScript です。また Pyke の対象は作者がソースとして読めるものだったので、不透明なソフトウェアや独占的なソフトウェアについての根拠にも、クリーンルームでの作業の根拠にもなりません。

私たちの読み(Motitory の分析)はこうです。小さく読みやすいフィクスチャでの成功と、大きな実アプリでの部分的なカバレッジは同時に成り立っており、一方を引用するならもう一方も一緒に引用すべきです。また、精度だけがボトルネックではありません。出力の大きさ、ツールのスキーマをモデルのコンテキストに載せるコスト、バージョンの固定、人が結果をレビューする時間のすべてが、このツールに見合う価値があるかを左右します。

2つのデモは結果ではなく手がかり

Apple のパスワード生成ルール。 02ui の動画の概要欄には、REA で Apple のパスワードアプリが強力なパスワードを生成する仕組みを調べて17のルールを得たこと、新たに生成した100個のパスワードがすべてそのルールを満たしたこと、約40分と約10ドルの API 費用がかかったことが書かれています。REA のバージョン、生の Evidence、再現用のリポジトリはありません。より根本的な問題は検証方法です。同じ調査で抽出したルールをパスワードが満たしたというのは、ルール同士に矛盾がないことを示すだけで、Apple の生成器と同じであることは示しません。それを示すには、Apple が公開しているルールや、失敗しうるテストのような、調査から独立した基準が必要です。

Bitburner。 SI NEWS の動画は、Windows で REA の CLI を使って Bitburner 3.0.1 を解析し、ns.exploit() 関数を見つけたと説明しています。Bitburner はオープンソースなので、その関数は公開されているソースにあり、ゲーム自体もプレイヤーがこうしたものを見つけるように作られています。作業の流れは見せていますが、クローズドなソフトウェアの解析ではありません。いちばん役に立つのは失敗の報告です。使った無料モデルが後続のツール呼び出しに誤った引数を繰り返し渡し、作者は CLI に切り替えざるをえなかったそうです。ツール呼び出しの信頼性そのものがコストになる、という HackerNoon 側の観察とも合っています。

報道と意見が付け加えるもの

  • Cyber Security News は公式ドキュメントを妥当にまとめています。プロジェクトが報告したデモはそうと明記し、ドキュメントの警告を2つ紹介しています。ローカル解析でもツールの結果はモデル提供者に送られるため、データが手元から出ないという意味ではないこと、そしてランタイム機能には副作用がありうることです。
  • KDnuggets は REA を ArtCraft と並べ、「AI によるソフトウェア複製」の流れの中に置いています。ArtCraft は別のプロジェクトで REA の事例ではなく、その比較に出てくる対応範囲や完成度の数字は開発者自身の自己評価です。
  • Decrypt は REA を GTA、Fable、MOD、ArtCraft の話と結びつけています。記事自身、そのうちいくつもが別のツールを使ったものか、REA と無関係だと認めています。REA についての根拠はひとつもなく、よく引用される一節は私たちが繰り返さない主張です。
  • Hacker News では、REA の再現を投稿した人はいませんでした。ただ、スレッドでいちばん説得力のある反論は、意見として覚えておく価値があります。クライアントを解析できることと、そこで見つけたものを使えることは別だ、という指摘です。クライアントには、サーバーのデータ、アカウント、サービスの運用、ネットワーク効果、商標、アセットは含まれていません。

話題の事例が REA の根拠にならないことが多い理由

目を引く話のほとんどは、次の確認項目のどれかで引っかかります。共有する前に一度見ておきたいリストです。

  1. そもそも REA を使ったのか。 話題になった話のいくつかは別のツールでした。
  2. どのバージョンを、どのシステムで。 REA は変化が速く、npm のリリースと main ブランチは同じものではありません(詳しくは第2回)。
  3. すでに公開されていた結果ではないか。 オープンソースのゲームで関数を見つけたのは、公開されたソースで見つけたということです。
  4. 確かめられる生の出力はあるか。 動画の中の要約は Evidence ではありません。
  5. 検証は独立していたか。 同じ調査が作ったテストに通っても、元と同じであることの証明にはなりません。
  6. 権利は揃っていたか。 他人の製品でのデモは、その解析が許可されていたことを示しません。REA の MIT ライセンスは REA 自身のコードについてのもので、解析対象や外部ツールへの権利は与えません(免責文書)。自分が所有している、または明示的に許可を得たソフトウェアだけを解析してください。この記事は法的助言ではありません。

ソースのように見える出力も同じです。元のコードのように読めるコード、一部のケースでのバイト単位の一致、ルール検査の合格は、書き直したコードが実行時に同じように動くことの証明ではなく、その成果物が誰のものかについては何も語りません。

まとめ

  • 独立した実行2件は小さな土台です。どちらも JavaScript と Electron、つまり REA が追加の provider なしで扱える経路でした。私たちが探した範囲では、それ以外の対象は公開の場で試されていません。
  • プロジェクト自身のショーケースは出発点であって、ベンチマークではありません。
  • 新しい記事が出たら、意味を判断する前に、まず上の6種類のどれに当たるかを分けてみてください。

第2回では、他人が試したことから、ドキュメントが示す「できる・条件付き・対応外」の境界に移ります。

参考資料

リンクと内容は 2026年10月14日に確認しました。

ブログへ