Devinが「全ファイル検査」を構造的に保証する方法を編み出した — Agentic MapReduceの仕組み

AIコーディングエージェントには共通の弱点がある。コードベースが大きくなるほど、見落としが増える。

10万行のコードに対して「セキュリティ上の問題を見つけて」と頼んでも、エージェントはコンテキストウィンドウに収まる範囲しか見ない。運が悪ければ、致命的な脆弱性があるファイルがたまたまスキップされる。カバレッジは確率的であり、「全部見た」という保証がない。

7月1日、Devinの開発元Cognitionがこの問題に対する一つの解を発表した。Agentic MapReduce——分散コンピューティングの古典的手法を、AIエージェントに適用するアーキテクチャだ。

MapReduceをエージェントに持ち込む

元のMapReduceは、Googleが2004年に論文化した分散処理の仕組みだ。巨大なデータセットを小さなチャンクに分割し（Map）、それぞれを並列で処理し、結果を統合する（Reduce）。Hadoopの基盤になったあれだ。

Devinが行ったのは、この概念を「データ処理」から「コード推論」に移植すること。

仕組みは3段階に分かれる。

1. Plan（計画） — プランナーエージェントがリポジトリ全体を俯瞰し、各ファイルに対する「関連性テスト」を設計する。このテストは決定論的——つまり、毎回同じ入力に対して同じ判定を返す。LLMの気分次第でファイルが見逃される、ということが起きない。

2. Map（並列調査） — 関連性テストに引っかかったファイル群を、調査対象のバッチに分割し、複数のエージェントが並列で深掘りする。各エージェントは自分の担当範囲だけに集中するので、コンテキストウィンドウの制約を受けない。

3. Reduce（統合） — 各エージェントの発見を1つのレポートに統合する。ここでは推論ステップが入り、個別のエージェントが見えなかった「ファイル間の関係」を接続する。

カバレッジが保証されるのは、Planフェーズで「有限のワークキュー」が生成され、すべてのキューが消化されるまでMapが完了しない、という設計になっているからだ。

この手法の最初の実用例が「Devin Security Swarm」だ。

全ソースファイルを対象にセキュリティ脆弱性をスキャンし、発見された問題をサンドボックスで実際に再現して確認。修正パッチを書き、PRを開く——ところまでを自動でやる。

Cognitionによると、GitHub Advisory Databaseに登録された実際のCVEに対して72%の検出率を達成。従来のスキャナーに比べて「ビジネスロジックの欠陥」や「サービス間にまたがる認証バイパス」といった、静的解析では見つけにくい類の脆弱性に強いという。

72%という数字は、人間のセキュリティレビューと比べれば物足りないかもしれない。しかし「全ファイルを漏れなくスキャンした上での72%」と「ランダムサンプリングからの推測」では、意味がまるで違う。

技術的なアプローチとしては素直に面白い。「LLMの確率的な振る舞い」を「決定論的なスキャン」で補完するという発想は、AIコーディングエージェント全体に適用できるはずだ。

ただし、気になる点もある。

コストが読めない。 10万行のリポジトリに対してSecurity Swarmを走らせたとき、何エージェントが何トークン消費するのか。Cognitionは具体的な数字を出していない。全ファイルカバレッジの代償として、トークンコストが跳ね上がる可能性は十分ある。

「セキュリティ」以外の応用が未知数。 Agentic MapReduceのフレームワーク自体は汎用的に見えるが、現時点で公開されているのはSecurity Swarmだけだ。コードリファクタリングやドキュメント生成への応用は「できそう」で止まっている。

Harrison Chase（LangGraphの開発者）がXで即座に反応し、「agentic map reduceは良い名前だ」と評価した上で、LangGraphの"deepagents"でも同様のパターンが実装可能だとコメントしている。

裏を返せば、この手法はDevinの専売特許ではなく、エージェントフレームワーク全般で採用される可能性がある。Claude Codeの「Dynamic Workflows」やCursorの「Automations」にも、同じ発想が組み込まれる日は遠くないかもしれない。

コードベース全体を「確実に見る」AIエージェント。そのための設計原理が、今日オープンに語られた。