
非同期エージェントの時代 — CognitionのWalden Yan & OpenInspectのCole Murray
- AIエンジニア向けポッドキャスト「Latent Space」の本エピソードは、Cognitionの共同創業者兼CPOであるWalden Yanと、オープンソースのバックグ...
- 議論の中心となったのは、エージェントの「頭脳」を実行環境(サンドボックス)の内部に置くか外部に置くかという「ハーネス・イン・ザ・ボックス vs アウト・オブ・ザ・ボックス...
- [0:03] 非同期エージェントの夜明けとモデルの転換点 2025年12月は、AIエージェントの歴史における分水嶺となった。Walden Yanによれば、Opus 4.5...
自分では見つけにくい海外Podcastの話題に、日本語で気軽に触れたい人。
Latent Space: AIエンジニアポッドキャスト / Latent.Space
AIエンジニア向けポッドキャスト「Latent Space」の本エピソードは、Cognitionの共同創業者兼CPOであるWalden Yanと、オープンソースのバックグラウンドエージェントシステム「OpenInspect」の開発者Cole Murrayを迎え、急速に普及する「非同期エージェント(Async Agents)」の実像に迫った。2025年12月を境に、AIモデルの能力が「仕様からプルリクエスト(PR)へ」という自律的なワークフローを実現可能な水準に達したことで、開発者の手元を離れクラウド上で自律稼働するエージェントへの関心が爆発的に高まっている。Cognition社内では、Devinが生成するコードの割合がわずか数ヶ月で16%から80%へと急増し、エンジニアの頭数は10%しか増えていないという驚異的な生産性向上を示すデータが公開された。本エピソードでは、この「バックグラウンドエージェント」のアーキテクチャ、セキュリティ、テスト、メモリ、マルチエージェント、そして企業導入における現実的な課題まで、現場のエンジニアが直面する詳細な論点が議論された。
議論の中心となったのは、エージェントの「頭脳」を実行環境(サンドボックス)の内部に置くか外部に置くかという「ハーネス・イン・ザ・ボックス vs アウト・オブ・ザ・ボックス」のアーキテクチャ選択である。Cognitionはセキュリティと柔軟性を重視し、頭脳を外部に分離する方式を採用。これにより、機密情報をサンドボックスに露出させるリスクを低減し、既存の開発環境インフラを再利用可能にしている。一方、OpenInspectは現在はシンプルさを優先してハーネス・イン・ザ・ボックス方式を採用しているが、長期的にはアウト・オブ・ザ・ボックスへの移行を見据えている。また、エージェントが実際にアプリケーションを起動し、テストし、その結果をスクリーンショットや動画で人間に確認させる「テスト」機能の重要性が強調された。これは単なる「コンピューターユース(画面操作)」をはるかに超える、複雑な推論とオーケストレーションを要する課題であり、場合によっては複数のフロンティアモデルを連携させる必要があるという。
非同期エージェントの夜明けとモデルの転換点
2025年12月は、AIエージェントの歴史における分水嶺となった。Walden Yanによれば、Opus 4.5やGPT-5.2といったモデルが、人間の細かな指示なしに「仕様から完成したプルリクエストへ」というプロセスを実用的なレベルで実行できるようになった。この「December inflection(12月の転換点)」により、開発者が常にコードを監視し、修正を逐一手動で適用する「ローカルエージェント」の時代から、クラウド上で自律的にタスクを遂行する「バックグラウンドエージェント」の時代への移行が加速した。Cognition社内のデータはこの変化を如実に示している。Devinが生成しマージされたPRの数は数ヶ月で7倍に増加し、全リポジトリにおけるDevinのコミット比率は2025年1月の16%から3月には80%にまで跳ね上がった。この間、エンジニアの人員増加はわずか10%であり、AIエージェントがもたらす生産性の飛躍的な向上を裏付けている。
この流れは、Cognitionのような専業ベンダーだけでなく、RampやShopify、Stripeといった企業が自社専用のコーディングエージェントを内製する動きにもつながっている。Cole MurrayがOpenInspectを開発したきっかけも、クライアントがClaude CodeやOpenAI CodexをSlack経由で利用する際の摩擦にあった。特に、PMが起動したエージェントセッションをエンジニアが引き継げないという問題は、チームコラボレーションの大きな障壁となっていた。Rampが公開したバックグラウンドエージェント構築に関する詳細なブログ記事は、Coleにとって「自分も作れる」という確信を与え、短期間でのOpenInceptの開発と公開につながった。このように、モデルの能力向上と、それを活用するための実践的な知識の共有が、非同期エージェントムーブメントを牽引している。
アーキテクチャの核心:ハーネス・イン・ザ・ボックス vs アウト・オブ・ザ・ボックス
バックグラウンドエージェントシステムを構築する上で最も重要な設計判断の一つが、エージェントの「頭脳(brain)」を実行環境(サンドボックス)の内部に置くか、外部に置くかという点である。CognitionのDevinは当初から「頭脳とマシンの分離(separate the brain from the machine)」を採用している。これは、エージェントの意思決定を行う中枢をサンドボックス外の安全なワーカーコントロールプレーンに配置し、サンドボックスは単に「手(hands)」としてツール呼び出しを実行する役割に徹するというアーキテクチャだ。この方式の最大の利点はセキュリティにある。サンドボックス内には必要最小限の権限を持つシークレットだけを配置すればよく、たとえエージェントが予期せぬ動作をしても、中枢部分やより機密性の高い情報へのアクセスを防げる。また、既存の開発ボックスインフラをそのまま流用できるため、エージェント専用の環境を新たに構築する必要がない。
一方、OpenInspectが現在採用する「ハーネス・イン・ザ・ボックス」方式は、エージェントの全状態がサンドボックス内に閉じ込められるため、アーキテクチャがシンプルで管理が容易である。しかし、すべてのシークレットをサンドボックス内に配置する必要があるため、セキュリティ面では劣る。Cole Murrayは、OpenInspectの長期的なロードマップでは、より複雑ではあるが優れたアウト・オブ・ザ・ボックス方式への移行を検討していると述べた。この二つの方式の選択は、セキュリティとシンプルさのトレードオフであり、企業のセキュリティポリシーや運用体制に応じて適切な選択が求められる。OpenAIやAnthropicが提唱する「マネージドエージェント」の概念も、このアウト・オブ・ザ・ボックス方式のバリエーションであり、業界全体がこの方向に収束しつつある。
レポジトリセットアップの困難とVMの重要性
バックグラウンドエージェントを実運用する上で、しばしば過小評価されるのが「レポジトリセットアップ(repo setup)」の難しさである。Walden Yanは、これを「Cognition設立以来の永続的な問題」と表現する。多くの企業、特に大企業では、開発環境のセットアップが属人化しており、「Bobに聞け」という状態が珍しくない。エージェントが自律的に動作するためには、依存関係のインストール、シークレットの設定、データベースの準備など、すべてがコード化され、再現可能である必要がある。Docker Composeは一般的な解決策だが、エージェントがDockerを使用するアプリケーションをテストする場合、Docker in Dockerという複雑な状況が発生する。また、Dockerコンテナは真のセキュリティ境界としては不十分であるという指摘もなされた。
CognitionがフルVM(仮想マシン)を採用した理由は、実アプリケーションを実行し、実際に画面を操作してテストする価値が高まっているからだ。Devinは、アプリケーションを起動し、画面上のボタンをクリックし、その結果をスクリーンショットや動画で人間に確認させる。この「テスト」機能を実現するには、単なるコンテナではなく、完全なオペレーティングシステムを実行できるVMが必要となる。さらに、Android開発のサポートを追加する際には、FirecrackerマイクロVM上でAndroidエミュレータを実行するためのネステッド仮想化(入れ子仮想化)という技術的課題に直面した。このように、エージェントが扱うアプリケーションの多様性が増すにつれて、実行環境の複雑性も増大している。Cognitionは、VMのスナップショットを高速に保存・復元する独自のファイルシステム「Block Diff」を開発し、エージェントの起動時間を劇的に短縮するなど、インフラレベルでの深い最適化を行っている。
テストの本質:コンピュータユースを超えて
エージェントが生成したコードの品質を保証する上で、「テスト」は最も重要な機能の一つである。Walden Yanは、このテスト能力を「コンピュータユース(画面操作)」と混同すべきではないと強調する。コンピュータユースは「どのボタンをクリックすべきか」という比較的単純な問題であるのに対し、テストは「変更がフロントエンドとバックエンドの両方に及ぶ場合、どのようにアプリケーションを起動し、連携させ、特定の機能をトリガーするか」という、はるかに高度な推論とオーケストレーションを必要とする。例えば、特定の機能がフィーチャーフラグで制御されている場合、エージェントはそれを有効にする方法を理解しなければならない。場合によっては、一つのフロンティアモデルではこのタスクを完遂できず、複数のモデルを連携させる必要があるという。
Devinのテスト機能は、単にコードを実行するだけでなく、その結果を動画で記録し、画面上のカーソルの動きや操作内容をラベル付けして表示する。これにより、開発者はコードを読まなくても「動作することが確認できた」という確信を持ってPRをマージできる。この「I know it works(動作することが分かる)」という体験は、エピソード内で「AGIを感じる瞬間」と評された。また、GitHub上でのエージェントとのインタラクションも重要な要素だ。Devinは、自身が作成したPRに対して人間がコメントすると、それに応答し、修正を加えることができる。さらに、Devin ReviewというAIレビュアーがPRにコメントを投稿し、それに対してDevin自身が返答するという、一見すると無限ループに陥りかねない状況も、慎重なチューニングによって実用的なものにしている。この「AIレビュアー」と「コーディングエージェント」の連携は、バックグラウンドエージェントシステムの重要な構成要素である。
メモリと知識:未解決の難問
エージェントが組織固有の知識や過去の経験を学習し、それを将来のタスクに活用する「メモリ」は、現在もっとも解決が難しい問題の一つである。Walden Yanは「まだ解決されていない」と率直に認め、Cole MurrayもOpenInspectへのメモリ機能追加に慎重な姿勢を示した。その理由は、メモリが「検索(retrieval)」と「生成(generation)」という二つの難しい問題を内包しているからだ。生成の難しさは、一度きりの指示を永続的なルールとして誤って記憶してしまうことに現れる。例えば、「PRはドラフトで作成してほしい」という一度の依頼を、すべてのPRに適用すべきルールとして記憶してしまうと、かえって不便になる。検索の難しさは、数千ものメモリの中から、現在のタスクに本当に必要な情報だけを、コンテキストを爆発させることなく取り出すことにある。
Cognitionは、この問題に対して「Knowledge」というシステムを開発した。これは、ユーザーがDevinに何かを教えた際に「これを記憶しますか?」と提案し、ユーザーが承認・拒否することで、自動的にメモリを蓄積していく仕組みだ。驚くべきことに、Devinが持つメモリの約95%はこの自動生成によるものであり、ユーザーが自ら文書を作成することはほとんどないという。また、メモリの編集や、時間経過による古いメモリの忘却(pruning)といった機能も実装されている。しかし、Waldenは、現在のファイルベースのアプローチから、エージェントが自らナビゲートできる「ファイルシステム」のようなメモリへと進化させる可能性を示唆した。さらに、特定のプロダクト領域に専念する「常時稼働のPMエージェント」というアイデアも紹介された。これは、Slackチャンネルに常駐し、メモリファイルを維持しながら、優先順位の決定や関係者のタグ付けを自律的に行うエージェントであり、エンジニアリングプロセスそのものを上流から変革する可能性を秘めている。
マルチエージェントと「バイブコーディング」の限界
マルチエージェントシステムは、多くのAIエンジニアの関心を集めるトピックだが、Walden Yanは実用性に対して慎重な立場をとる。彼は以前「Don't Build Multi-Agent(マルチエージェントを構築するな)」という記事を公開しており、その理由は、エージェント同士が自律的に会話し、協調するという理想像は、現状では「マネージャーとサブエージェント」という単純な階層構造以上のものになっていないからだ。Devinは内部的にサブエージェントを起動し、タスクを並列処理することができるが、それはあくまで「ツール呼び出し」の延長線上にある。真のマルチエージェントとは、異なる情報を持つエージェント同士が議論し、互いに間違いを指摘し合い、より良い解を導き出すことだとWaldenは定義する。そして、最近のモデルは「あなたは絶対に正しい」と盲目的に同意するのではなく、「いや、それは違うと思う」と人間に反論するようになってきており、この「成熟したコミュニケーション能力」こそが、将来の真のマルチエージェント世界を可能にする鍵だと述べた。
一方、純粋にAIにコード生成を任せ、人間のレビューなしに自動マージする「バイブコーディング(vibe coding)」には、明確な限界がある。Cognition社内での実験では、この手法でプロダクトを開発し続けられる期間は約2週間であることが判明した。2週間もすると、同じ機能が10箇所で異なる実装になっていたり、ボタンの色を変えようとしても、どこを修正すればいいか分からなくなる。Cole Murrayは、この現象を「コードベースが最も能力の低いエンジニアの水準にまで低下する(regresses to your worst engineer)」と警鐘を鳴らす。AIが生成したコードは、往々にして既存のコードパターンを模倣するため、質の低いコード(slop)が指数関数的に増殖する。この問題への対策として、セマンティックなコード解析ツール(Semgrep)を用いて、AI特有のコードパターン(例えば、エラーを避けるための無理な後方互換性や、型を無視したタプルの使用など)をリントルールとして検出する方法が紹介された。また、コードの変更理由をgitメタデータに保存する「GitAI」のようなアプローチも、将来のコードメンテナンスに役立つ可能性がある。
ユースケースの拡大と企業導入の現実
バックグラウンドエージェントの活用範囲は、ソフトウェアエンジニアリングの枠を超えて広がっている。最も一般的なユースケースはSRE(サイトリライアビリティエンジニアリング)である。DatadogやSentryなどの監視ツールからのアラートをトリガーに、エージェントが自動的に調査を開始し、コンテキストを収集し、場合によっては修正PRを作成する。この「オートトリアージ(auto-triage)」により、インシデント対応の初動が劇的に高速化される。次に、PMやマーケティングチームなど、非エンジニアによるコード貢献が現実のものとなりつつある。PMがSlackで簡単なバグ修正を依頼すると、エージェントがPRを作成する。これにより、エンジニアリングチームのボトルネックが解消される。さらに、カスタマーサポートの領域でも、顧客からのバグ報告に対して、エージェントがコードベースを調査し、問題の原因とコンテキストをエンジニアに引き継ぐという使い方が広がっている。
これらのユースケースを実現するためには、エージェントを企業の既存のエコシステムに深く統合することが不可欠である。Cole Murrayは、MCP(Model Context Protocol)が統合の標準として注目を集めているが、Slackのような重要なツールとの連携には、単なるツール呼び出しを超えた、双方向のコミュニケーションを可能にする独自の仕組みが必要だと指摘する。Cognitionは、DevinをSlack上の「同僚」として扱い、Webhookによるイベント駆動型の応答や、スパムにならないように調整された自然な対話を実現している。また、Walden Yanは、エージェント導入の成功には、製品そのものだけでなく、オンボーディング、統合、そして組織全体でのAIリテラシー向上を支援する「導入コンサルティング」が重要な付加価値であると述べた。エージェントのコストについては、エンジニア一人あたり月額1,000ドルから5,000ドルが一般的な範囲であり、将来的にはより高額なフロンティアモデルと、コスト効率の良いサブフロンティアモデルを組み合わせた「ハイブリッドシステム」が主流になると予測されている。
結びに
本エピソードは、AIエージェントが「実験的なツール」から「企業のソフトウェア開発の中核インフラ」へと変貌を遂げつつある現場の生々しい実態を描き出した。単なるプロダクトデモや将来予測ではなく、CognitionとOpenInspectという、それぞれ異なる立場(商用プロダクトとオープンソース)の開発者が、アーキテクチャ、セキュリティ、テスト、メモリ、組織導入に至るまで、具体的な技術的課題とその解決策を詳細に議論した点に、このエピソードの最大の価値がある。特に、「ハーネス・イン・ザ・ボックス vs アウト・オブ・ザ・ボックス」のアーキテクチャ選択や、「バイブコーディング」が2週間で破綻するという実験結果は、AIエージェントを実運用する全てのエンジニアにとって、極めて実践的な知見である。また、メモリやマルチエージェントといった、まだ解決されていない課題について、楽観論と懐疑論の両方をバランスよく提示した点も、聴き手に深い考察を促す。このエピソードは、AIエージェントの「次の波」を理解し、自社での導入を真剣に検討するエンジニアや技術リーダーにとって、必聴の内容である。
要点
- 2025年12月のモデル転換点(Opus 4.5, GPT-5.2)以降、「仕様からPRへ」の自律的ワークフローが実用的になり、バックグラウンドエージェントの時代が本格的に到来した。
- Cognition社内では、Devinのコミット比率が数ヶ月で16%から80%に急増。エンジニア人員は10%増加にとどまり、AIエージェントによる生産性向上がデータで証明された。
- エージェントアーキテクチャの核心は「ハーネス・イン・ザ・ボックス vs アウト・オブ・ザ・ボックス」の選択。Cognitionはセキュリティと柔軟性を重視し、頭脳を実行環境から分離する方式を採用している。
- エージェントによるテストは、単なる画面操作(コンピュータユース)を超え、複数サービスを跨る複雑なオーケストレーションを要する。場合によっては複数のフロンティアモデルの連携が必要となる。
- エージェントの「メモリ」は依然として未解決の難問。生成と検索の両面で課題が残るが、Cognitionはユーザーの承認に基づく自動記憶システムで約95%のメモリを生成している。
- 純粋な「バイブコーディング」(自動マージ)は約2週間で破綻する。コードベースは質の低いエンジニアのパターンに収束し、AIがそれを増幅する「slopの指数関数的増殖」が発生する。
- バックグラウンドエージェントの主なユースケースは、SREの自動トリアージ、非エンジニア(PM、マーケティング)によるコード貢献、カスタマーサポートの三点。Slackを中心とした深い統合が鍵となる。
- エージェント導入の成功には、製品自体に加え、オンボーディング、統合、組織変革を支援するコンサルティングが不可欠。コストはエンジニア一人あたり月額1,000〜5,000ドルが一般的。