コンテナで動かせば済む——そう思われがちなクラウドエージェントだが、実際に本番スケールで運用しようとすると、セキュリティ・永続化・オーケストレーションという3つの大きな壁にぶつかる。
Cognitionが2年以上かけてDevinのインフラを構築した経験をまとめたブログ記事が、2026年4月23日に公開された。Stripe社の事例など「自社でクラウドエージェントを作る」という選択肢が企業の間で広まる中、構築に何が必要かを具体的に示す内容になっている。
この記事でわかること：
- コンテナ化エージェントが抱えるセキュリティ上の根本的な問題
- 非同期作業をまたいでセッションを維持する方法
- 大規模運用に必要なオーケストレーション・ガバナンス・インテグレーション
- 技術インフラだけでは解決できない組織変革の課題
コンテナ化では本番環境に耐えられない
クラウドエージェントの構築で多くの企業がとる最初のアプローチは、CLIエージェントをコンテナ化してリポジトリやツールチェーンにアクセスさせることだ。実行環境をクラウドに移すという目的は達成できるが、すぐに3つの根本的な問題に直面する。
セキュリティ: 共有カーネルは攻撃面になる
コンテナはカーネルを共有する。つまり、1つのセッションが侵害されると、同じホスト上の全コンテナのファイルシステム・クレデンシャル・ネットワーク接続に到達できてしまう。エージェントは自前のコードを実行し、任意のコマンドを走らせ、環境を予測不可能な形で探索する。カーネルレベルのエスケープが現実的な脅威になる。
業界標準の回答はVMレベルの隔離だ。ワークロードごとに独立したカーネルを持つVMを割り当て、ストレージ・ネットワーク・コンピュートをすべて分離する。CognitionがmicroVM実装に取り組んだ期間は1年以上に及んだ。この構成の副次的なメリットとして、各エージェントセッションがフルブラウザやデスクトップアプリを含む任意のツールスタックを使えるようになる。
永続化: コンテナは非同期の「間」を生き残れない
コンテナ化エージェントには、もう一つ致命的な問題がある。PRを作成してCIの完了を待ち、レビューコメントに対応して再テストし、追加コミットをプッシュする——こうした実際のエンジニアリング作業は、ステップとステップの間に数分から数時間、場合によっては数日の「待機」が入る。コンテナにはこの非同期の間隔をまたいで状態を完全にスナップショットする手段がない。
動き続けるためにコンピュートを消費し続けるか、コンテナが再スケジュールされたり落ちたりした時点でセッションを失うか、どちらかしかない。依存関係のアップグレードのような一回で終わる作業なら問題ないが、SDLCの非同期プロセスをまたぐ作業には対応できない。
CognitionはハイパーバイザーレベルでVMの状態をスナップショットすることでこれを解決した。メモリ・プロセスツリー・ファイルシステムを丸ごと保存し、アイドル中はコンピュートをシャットダウン。CIの結果やレビューコメントが届いた時点でセッションを完全に復元する。異なるリポジトリ・依存関係・ランタイム環境を持つ数千の並行セッションで確実に動かすまでに、これが最も時間のかかった実装だったとCognitionは述べている。
スケールするとインフラが3倍に増える
1つのエージェントを動かすことと、エンジニアリング組織全体で数百のエージェントを同時に運用することは別問題だ。大規模なクラウドデータプラットフォーム企業がこれに挑戦し、プロジェクトスコープの膨大さに圧倒されて断念した事例もCognitionは紹介している。
スケールに必要な3つの層は次のとおりだ。
オーケストレーション: セッションごとに異なるタスクとエンジニアの権限に合わせて適切な環境をプロビジョニングし、需要を予測してウォームなVMプールを用意し、コードベースが日々変化する中で環境を最新の状態に保ち続ける必要がある。Cognitionのオーケストレーション層の構築には専任チームが3四半期以上かけており、現在は数千の並行VMを管理できる状態になっている。
ガバナンス: 各セッションはディスパッチしたエンジニアの権限を引き継ぎ、すべての操作を改ざん不能な監査ログに記録する必要がある。ID連鎖・アクセス制限・監査ログをエンタープライズスケールで構築・維持するのはそれ単体でも大型プロジェクトになる。
インテグレーション: エージェントはCI・モニタリング・パッケージレジストリ・ドキュメント・ソース管理など、触れるすべてのシステムに接続できなければ価値を発揮できない。Stripeは社内のMCPサーバーに400以上のツールを登録してエージェントを接続しているとのことで、このレイヤーへの投資規模が伺える（参考）。
Cognitionが繰り返し強調しているのは、「どれか一つが大変なのではなく、三つすべてを同時に構築・統合・維持し続けることが問題になる」という点だ。現在もCognitionは各レイヤーごとに専任チームを置いている。
技術が揃っても組織が変わらないと動かない
インフラ構築はフェーズ1に過ぎない。フェーズ2は、エンジニアリング組織がエージェントと一緒に働く方法を再構築することだ。
すべてのエンジニアリングプロセスは人間が作業する前提で設計されている。スコープの決め方・チームの組み方・コードレビューの進め方、そのすべてが見直しの対象になる。具体的に変わるのは次の3点だ。
エンジニアの習熟: どの作業をエージェントに委譲し、どれを自分でやるかの判断と、エージェントが修正なしに実行できる精度でタスクを定義するスキルが必要になる。並行するエージェントセッションを管理することは、コードを書くこととは根本的に異なるスキルで、実際のプロジェクトで数ヶ月かけて身につくものだ。
計画とリソース配分: チームサイジング・スプリントキャパシティ・プロジェクトスタッフィングの前提がすべて変わる。エージェントの能力が上がり、エンジニアが習熟するにつれて、定期的に見直しが必要になる。
レビューと品質基準: コードの量が劇的に増える一方で、人間が書いたコードを前提にしたレビュープロセスはそのまま使えない。高いボリュームでエージェントが生成したコードを厳密にレビューする方法を確立する必要がある。
これらは事前に設計できるものではなく、実際のプロジェクトで使いながら数ヶ月かけて開発されていく。Cognitionはラテンアメリカ最大の民間銀行であるItaúの事例を紹介しており、約1万7,000人のエンジニアを対象に11ヶ月運用した結果、マイグレーションが5〜6倍速くなり、静的解析で検出されたセキュリティ脆弱性の70%が自動修正され、テストカバレッジが2倍に向上したと報告している（参考）。
早く始めた組織ほど差が広がる
Cognitionの記事は、クラウドエージェント基盤の自社構築が現実的かどうかを判断するための材料として書かれている。VM隔離・セッション永続化・オーケストレーションの3層それぞれがマルチクォーターの専任エンジニアリングプロジェクトであり、その上に組織変革が重なる。
技術的なハードルの高さを認識した上で、自社構築かプラットフォーム利用かを選ぶことが出発点だ。どちらを選んでも、組織がエージェントと一緒に働く習熟度は実際に使い始めた時間に比例して積み上がる。開始が早いほど差は大きくなる。