【Google Cloud Next ’26】Devin開発元が語るコーディングエージェントが抱える本当の課題

DX開発事業部 フルスタックセクションの田村です。
Google Cloud Next 2026 よりセッションの要点解説をお届けいたします。
今回は「Why Cloud Agents are a Systems Problem in Disguise」ライトニングトークを聴いてきました。

概要

登壇したのはCognition社、自律型AIソフトウェアエンジニア「Devin」を開発している会社で、今回のトークはDevinを本番運用するなかで直面した課題と、その解決アプローチがベースになっています。
「AIエージェントの難しさはモデル選びではなく、その周りのプラットフォーム構築にある」というメッセージを、Devin開発の実体験をもとに語ったセッションでした。

コーディングエージェントの本質

従来のLLMの利用においてはリクエスト／レスポンス型が基本となっており、ステートレスで処理時間は短く、境界が明確です。

ただしコーディングエージェントはファイルシステムやプロセスの状態を蓄積し、任意のコードを実行して、認証情報やネットワーク接続を保持し、CIや人間のレビューを待って一時停止して、数分〜数時間にわたって動き続けることも少なくありません。

そのため「コーディングエージェントはリクエストではなくセッションだ」というのがコーディングエージェントの根底にあります。

ローカル実行・共有マシンの落とし穴

実際に起きたインシデントが2つ紹介されました。

Incident 1

大手テック企業で、複数のエージェントセッションが1台のマシン上で並列実行され、共有ビルドキャッシュを通じて互いに干渉してしまった。
パフォーマンスが悪化し、出力品質も低下しました。根本原因はOS状態の共有（キャッシュ・プロセス・一時ディレクトリ）です。

Incident 2

auto-acceptモードで動いていたエージェントが、会社のモノレポ全体を個人のGitHubアカウントにpushしてしまった。
ローカル開発者の認証情報をそのまま引き継いでいたため、エージェントは『何でもできる状態』で動いており、操作範囲も万が一の被害範囲も制限されていない。

この2つの事例に共通するのはそれぞれエージェントの干渉できる境界が設定されていないという点にあります。
たしかに私もコーディングエージェントを利用していると、他の環境や意図しない操作を実行しようと計画していてヒヤッとする機会が何度もありました。

コンテナでの解決策

コンテナにはエージェント向けに足りない部分があるという説明がありました。

コンテナが得意なのは高速起動・使い慣れたツール・再現性のあるパッケージングである一方、エージェントが必要とする以下のようなものは提供されていません。

• カーネルやプロセスツリーを含む本物のマシンセマンティクス
• ブラウザ・GUI・フルツールアクセス
• 任意コード実行に耐えられる十分な強度の隔離
• セッション状態の時系列的な永続化

上記の条件を全て満たすにはコンテナでは不十分で、最終的にはより堅牢な仕組みが必要とのことでした。

Micro VMでの解決策

コンテナの次に検証されたのが Micro VM、特に Firecracker です。

Micro VMはハードウェアレベルでの隔離・専用カーネルやマシンセマンティクスを提供します。
そのため「セッションの境界」と「フルのコンピュータ使用能力」の環境でコーディングエージェントを利用可能です。

ただし、「A microVM != a platform」とあるように、Micro VMはコンピューティング能力の問題を解くだけで、エージェントプラットフォームとして必要な残りの部分はVM「の上」に構築する必要があります。

VM上に構築する

VM上には具体的に以下のレイヤーにそれぞれ自前構築していきます。

サスペンド／レジュームの難しさ

エンジニアリングの観点で特に掘り下げられたのが、サスペンド／レジュームの実装です。

現実のエンジニアリング作業は連続しておらず、エージェントがPRを出すとCI（Continuous Integration）を待ちます。（長くても15〜20分）
その後、人間のレビューを待つ必要があり、完全な自動化を考えるとこの間、マシンをアイドルのまま動かし続けるのはコスト的に現実的ではありません。

正しいサスペンド／レジュームには4つの要件があります。

1. メモリ・ファイルシステム・実行中プロセスを含むフルマシン状態の保存
2. アイドルセッションのコストがゼロになるようコンピュートをシャットダウン
3. まったく同じ状態・コンテキストで復元
4. オフライン中に届いたイベント（他のメンバーからのメッセージ等）の調整

上記を正しく実現するにはカスタムのハイパーバイザーレベルでのエンジニアリングが必要というコメントがありました。
実際にCognition社はFirecrackerをベースに自前のハイパーバイザーを構築しており、当初使っていたCloud VMインスタンスでのスナップショット（数分かかっていた）から大幅に改善したとのことです。

エージェント自身のID

もう一つ深掘りされたのがパーミッションモデルです。

通常の開発者のPCには、GitHubやAWSなどへのアクセストークンが保存されていて、そのマシン上で動くプロセスであれば誰でも使える状態になっています。
エージェントがこれをそのまま引き継ぐと、「開発者本人として何でもできる」状態で動くことになります。インシデント2の事例（モノレポが個人GitHubにpushされた件）はまさにこの構造が原因でした。

クラウドのプロジェクトはPC端末に保存された設定情報を使用することも少なくないため、厳密なパーミッション管理は大きな課題の1つかなと思います。

エージェントが必要とするID権限

• タスクごとにスコープされた独自のID
• デフォルトで最小権限
• 監査されたプライベートネットワーク経路
• すべてのアクションの完全なトレース

例えばGitHub・Jira・Artifactory・Linear・Slack・GitLabといった外部サービスとの接続も、このパーミッションモデルの上で安全に行われる必要があります。多くのエンタープライズにとって、これは「ブロッキングなアーキテクチャ上の問題」と表現されていました。

エージェントがMCPやAPIで課題を取得したり更新したりを考えると、誤って別プロジェクトのものを操作してしまわないような厳密な権限管理、スコープ管理はなかなかできていないことが多いのではないでしょうか。

エージェントの周りのコントロールプレーン

• どのモデルを使うか
• どのコンピュートプラットフォームを使うか
• どのVMハイパーバイザーを使うか

上記のような問いに対して対応すること自体は難しくはありません。
本当に難しいのは、開発者が成熟したコーディングエージェントに当然期待するあらゆる機能と操作手段を、ひとつのプラットフォームとして揃えることです。

プラットフォームが整ったときに得られるものとして、以下が挙げられました。

• Built for parallelism：DevinがさらにDevinを生成し、大規模な移行・リファクタリングを並列処理できる
• Collaborative by default：共有セッションで複数のエンジニアが同じエージェントと協働できる
• Observable and manageable：マネージドソリューションとして、エージェントの動作に可視性を持てる
• More autonomous end-to-end：シークレット管理・オーケストレーションが整うことで、エージェントがより独立してテスト・実行できる
• Integrated into your workflow：Slack・Jira・Microsoft Teams・Linearと最初から連携できる

Q&Aでは「エージェントが暴走しないようにするには？」という質問に対し、「各エージェントに『できることの範囲』を明示的に絞ることが基盤です。それができて初めてスケールアップできる」という回答がありました。誤った出力への対策については「コードを実際に動かして結果を確認するループが鍵。実行環境が整っていれば、エージェントは自分でミスに気づいて直せる」とのことでした。

セッション全体を振り返って

個人的に一番考えさせられたのは権限設計の話です。「エージェントに開発者のアクセストークンをそのまま渡す」は手っ取り早い解に見えますが、実際には、エージェントが動いている間ずっと「開発者本人として何でもできる状態」が続きます。

DevinのようなPRまで完全自律型のワークフローに限らず、人間がPRを作るハイブリッド運用だとしてもエージェントがコードを書いている時間帯にリスクが発生することは、コーディングエージェントを使う上で理解しておく必要がありますね。
急激にコーディングエージェントが普及してきてプロジェクトにも導入されることが多いですが、「まず各エージェントのできることを絞る。それができてからスケールさせる」というところが、エージェント導入の正しい順序だと思いました。