AIエージェントが既存インフラを食い破る季節が来た

Kubernetesの制御平面をバイパスする——Agent Substrateが描くエージェントランタイムの形

GoogleがGKE Agent Sandboxを一般提供化し、同時にAgent Substrateというオープンソースプロジェクトを発表した。

（※Agent Substrateは、エージェントのライフサイクル管理に特化した軽量なオーケストレーション層であり、従来のK8s APIサーバーを介さない高速なスケジューリングを可能にする仕組みです）Sandboxは信頼できないコードを安全に実行する環境。Substrateはその手前のスケジューリング層で、Kubernetesの制御平面を迂回する。2026年5月のこの二つの発表は、一つの前提を暗に認めたことになる。コンテナの十年を制したKubernetesは、AIエージェントの制御平面としては適切ではない、と。

ミスマッチの理由は、ワークロードの性質そのものにある。Kubernetesは元々、固定された長時間実行・レプリケートされたサービスを前提に設計された。一方エージェントは、OSのプロセスに近い。長時間生存するセッションだけど、大半はスリープしている。プロンプトが届くと十秒ほどコードを走らせ、また二十分眠る。このバースト的な振る舞いをPodで抱え続けると、アイドル時間のメモリとCPUが無駄になる。加えて、実行されるコードはモデルがランタイムで生成する。ランタイムはデフォルトでコードを信頼できないものとして扱い、コンテナ境界ではなくカーネル境界で分離しなければならない。コンテキストの保存も課題だ。休眠時に揮発性メモリとファイルシステム状態をスナップショットし、再開時に復元する。文脈を失ったエージェントは使い物にならない。

Kubernetesの制御平面がしんどいのは、スケジューリングとAPIサーバーの二点。エージェントは細粒度のスケジューリングイベントを絶えず生成する。配置決定が「稀で永続的」という前提の上に作られたKubernetesのスケジューラとは前提が違う。ラウンドロビンやランダム配置は短いリクエストなら悪手がすぐ平均化されるが、長く届く頻度の低いエージェントリクエストでは、一つの悪いルーティングがテールレイテンシを押し上げる。APIサーバー側も同じく、全エージェントをKubernetesオブジェクトで管理すれば数百万リソースが積もる。Agent Substrateの設計資料は「標準の制御平面でこれだけのオブジェクトを抱える巧妙な方法はない」と率直に書いている。だから大部分のエージェントをAPIサーバーの外に置き、専用のネットワーク層でリクエストを直接セッションへ届ける。スリープ中なら起こす。

仮想マシン、コンテナ、サーバーレスに次ぐ第四のコンピュート提供形態として、セッションアウェアなエージェントランタイムが位置づけられている。Kubernetesが不要になるわけではない。下層のマシンをプロビジョニングするデータセンターのスケジューラとしては引き続き有用だ。ただ、その上で走るワークロードのスケジューリングは、別の層に委ねられることになる。マイクロサービスをKubernetesで回しているチームが、エージェントワークロードを同じクラスタにDeploymentとして載せるか、それともSubstrateのようなランタイム層を手前に置くか。アーキテクチャの分岐点がここにある。APIサーバーのスケールに悩んだ経験があるなら、エージェントを素のKubernetesリソースとして扱うことの限界は想像がつくはずだ。

エージェント同士が金を払い合うインフラが標準化に動いた

Linux FoundationがX402 Foundationの正式な運用開始を発表した。40社以上の企業が初期メンバーとして名を連ねている。Google、AWS、Stripe、Visa、Mastercard、Shopify、American Express、Cloudflare、Coinbase。錚々たる顔ぶれだ。

X402が解決するのは、エージェント間の支払い問題だ。具体的にどういうことか。今までAIエージェントが有料APIを叩くには、人間と同じ手順を踏む必要があった。プロバイダーにアカウント登録し、身元確認をして支払い方法を紐付け、前払いでクレジット残高をチャージし、API鍵を管理する。エージェントが自律的に動く世界で、これでは迂回できないボトルネックになる。

X402のプロトコルはシンプルだ。

（※X402は、HTTPヘッダーやメタデータに決済情報を組み込み、リクエストと支払いをアトミックに処理するプロトコル規格を指します）エージェントが通常のHTTPリクエストを送り、"payment required"のレスポンスを受け取り、接続済みのステーブルコインウォレットで決済を完了させ、要求したデータを即座に受け取る。アカウントも鍵も事前の関係構築も不要になる。

もともとこのプロトコルはCoinbaseが2025年5月に発表したものだ。同年9月にCloudflareと提携して専用財団の設立を発表し、2026年4月にCoinbaseがLinux Foundationへ寄贈。そして今回の正式発足という流れだ。Cloudflareがエッジネットワークでグローバルトラフィックのかなりのシェアを処理していることを考えると、初期統合の意味は小さくない。

実は6週間の間に、Linux Foundationは3つのガバナンス組織を立ち上げている。6月にはトークンコストの測定と比較を標準化するTokenomics Foundation、同じく6月にはAIの安全性とコンプライアンスの主張を検証可能にするAppia Foundation。そして今回のX402 Foundation。コスト・信頼・決済の3層で、エージェント経済の基盤を整えようとしている。

背景にはトークンコストの異常な変動がある。2026年4月までの1年間で、平均月間トークン支出は13倍に増加。ヘビーユーザーでは単四半期で50%以上のコスト急増があったという。予算策定が困難な状況で、コストの標準化は喫緊の課題だ。

一方で気になる点もある。初期メンバーにAnthropicとOpenAIが不在だ。フロンティアモデルの2大ラボが抜けているのは、エコシステムの穴になりうる。招待されたのか、参加を見送っているのか。Linux FoundationのMike Dolanは既存の関係を指摘しつつも明確な回答を避けている。今後参加するのか、独自の道を行くのか。エージェント経済の実用性を考えると、主要なモデルプロバイダーの不在は無視できない。

それでも、API鍵の管理に悩まされてきたバックエンドエンジニアの視点から見ると、エージェントが自律的にリソースにアクセスし支払いを完了する仕組みが標準化の方向に動いていることは意味がある。マイクロサービス間の認証・認可の設計が、エージェント間の経済的やり取りに拡張されようとしている。この層が誰の支配下にも置かれないことは、オープンなウェブを維持する上で前提条件になるだろう。

Xが全コードベースのオープンソース化を発表、本番と公開の一致をどう証明するか

Elon MuskがXの全コードベースを例外なくオープンソースにすると発表した。内部のセキュリティ脆弱性レビューが完了次第、公開される。さらに第三者の独立レビューアーを招き、本番システムが公開コードと同じものを実行しているか確認する予定だという。

2022年の買収以来、Muskは段階的に透明性を高めてきた。2023年3月に推薦アルゴリズムの一部を公開。2026年1月に「For You」フィードのアルゴリズムコードを公開したとされるが、時系列的に精査が必要だ。いずれにせよ、部分公開から全面公開への移行は明確な方向転換だ。

企業のオープンソースプロジェクトに対する最大の批判は「公開コードが本番で動いているか分からない」という点にある。過去の公開でも重みやデータが省略され、単体で実行できない状態だった。今回は「例外なく」全コードを公開し、第三者が同一性を検証できる仕組みを提示する。この2点がセットになっていることに意味がある。片方だけでは信頼性の証明にならないからだ。

もし実現すれば、主要ソーシャルプラットフォームで前例のない透明性になる。MetaはLlamaなどのAIモデルを公開しているが、コアインフラやランキングシステムは独自規格のままだ。TikTokは推薦エンジンを非公開。YouTubeは研究者向けアクセスプログラムに留めている。Xが実行すれば、「なぜ自社のシステムは閉じたままなのか」という問いが競合に向けられることになる。

開発者の視点で注目すべきは3点。実際のリポジトリ公開日、独立レビューの具体的な範囲、コミュニティ貢献の扱いだ。数百万人のデイリーアクティブユーザーを支える本番グレードのスタックを研究できる機会は滅多にない。PRを受け入れる仕組みが整えば、LinuxやPostgresのような進化モデルに近づく可能性がある。

ただし、懸念はある。全コードの公開は攻撃面の可視化でもある。セキュリティレビューの完了条件や、レビュー後の公開までのタイムラグがどうなるか。独立レビューアーの選定基準も不明だ。運用モデルが根本的に書き換わる試みだけに、プロセスの設計次第で透明性の実効性が大きく変わる。

Jiraが開発者に向き直る：エージェントにチケットを投げる時代

AtlassianがJiraにAIエージェント機能を追加した。DevAIのエンジニアリング責任者Ming Wuは「開発者はJiraとのやり取りを好まないことは知られている」と認めている。Hacker Newsの反応を見れば、それどころではないかもしれない。それでもAtlassianは、開発者がJiraでもっと時間を過ごす方向に持っていきたい。

具体的に何が変わったか。JiraのワークアイテムをClaude Code、Cursor、GitHub Copilotに直接アサインできるようになった。OpenAIのCodexも後日対応予定。有料プランに含まれるJira Coding Agentは、ローカル環境のセットアップなしでワークアイテムをプルリクエストに変換する。Jira PlannerはJiraとConfluenceの履歴から技術仕様を生成する。Slackのスレッドで@Jiraに声をかけるとチケットが立つ。

気になるのはJira Coding Agentの挙動だ。旧称Rovo Dev。クラウドで動き、実行中のセッションを開くとVS Codeのようなエディタが表示される。コードの差分とターミナルを確認できる。人間とエージェントが並んでアサイン先に並び、どちらが適切か選ぶ設計になっている。

ここで考えたいのは、コード生成が高速化してもレビューがボトルネックになるだけではないかという問題だ。Wuは「ボトルネックは人間だ」と認めた上で、痛みの原因はコンテキストスイッチにあると言う。今は切り替えのコストが高く、追いつくのが苦しい。ただ、レビュー自体も変わりつつある。AIが重要な箇所にレビュアーを誘導し、小さな指摘を自動で処理する方向だ。コードが長ければ長いほどレビューは難しい。それは事実であり、どれだけ支援があっても変わらない。

Wuは「多くのことは最終的に完全に自動化される」と言う。まだそこではないが、起きていると。インターフェースからエディタが消え、チャットだけになる流れはすでに見える。Wu自身は不便に感じるそうだが、エージェントが書くコードが増えれば、開発者が書くコードは減る。いずれエディタは要らなくなるかもしれない。ただし時期は分からない。

PMやエンジニアリングマネージャーが不要になるわけではない。境界が曖昧になるだけだ。PMはエンジニアリングリソースを頼まずにプロトタイプを作れる。開発者はこれまで触らなかった製品要件やコンテキストを引き寄せる。Wuは「全員が底上げされる」と言う。同時に、最初は苦痛で混乱するとも認めている。

実務で何が変わるか。チケットを書いてエージェントに投げ、PRを受け取る。この流れがJiraの中で完結する。計画もJiraでAIと行い、成果物をConfluenceに公開し、技術タスクに分割してJiraに戻し、エージェントにアサインする。ワークフローがJiraに閉じる設計だ。

個人的には、コンテキストスイッチの話に納得する部分と懸念がある。確かに、エージェントがクラウドで動けばローカル環境の準備は要らなくなる。しかし、Jiraに留まることで得られるコンテキストと、IDEから離れることで失うコンテキストは別物だ。「自然な環境はJiraだ」というWuの仮説がどこまで通用するか。開発者がJiraに長居する未来が来るのか、それともエージェントへの指示だけJiraで済ませてすぐにIDEに戻るのか。そこはまだ分からない。

HAMiがCNCF Incubatingに昇格、異種アクセラレータの仮想化をKubernetesでどう変えるか

（※アクセラレータとは、GPU以外にNPU（AI処理専用チップ）やDCU（Deep Computing Unit）など、特定の計算を高速化するハードウェアの総称です）

2026年7月2日、HAMiがCNCFのIncubatingプロジェクトに承認された。2024年8月21日のSandbox入りから約2年での昇格である。

AIワークロードを扱うプラットフォームチームなら、誰もがフラグメンテーションの問題に直面する。高価なGPUが丸ごとPodに割り当てられ、メモリの一部しか使っていないのにリソースが専有される。ベンダーごとに運用モデルが異なるのも頭痛の種だ。HAMiはこの問題に立ち向かうミドルウェアで、物理GPUやNPU、DCU、MLUといった異種アクセラレータをメモリ・コア・デバイス数単位でスライスする。複数ワークロード間のハードなランタイム分離も担保する。

ここで重要なのが「既存のマニフェストやアプリケーションコードを変更しなくていい」という点。Mutating WebhookがPodのリクエストをインターセプトし、スケジューラ向けのフィールドやリソース要求を書き換える仕組みだ。

（例：ユーザーが gpu: 1 と指定したリクエストを、HAMiが内部的に gpu-slice: 0.2 などの仮想リソース割り当てに変換して物理デバイスにマッピングする）プラットフォーム側が導入するだけで、AIエンジニアのワークフローはそのまま移行できるかもしれない。

単一ベンダーのデバイスプラグインと異なり、マルチベンダーの統一インターフェースを持つのも特徴だ。メンテナーにはNVIDIAのメンバーも名を連ねており、NPUやDCUなども含めた混在環境を一元的に捌く構えになっている。招商銀行が多様なアクセラレータの大規模管理に使い、DaoCloudに至っては中国本土と香港の10以上のデータセンターで10,000を超えるGPUに展開しているという実績は無視できない。現在の安定版はv2.9.0。貢献者は2,687人、貢献組織は550以上に上る。

今後の論点は、VolcanoやKoordinatorとの統合、そしてKueueとの連携がどう進むかだ。単にGPUを分割して割り当てるだけでなく、バッチスケジューラのキューイングやプリエンプションと組み合わせた時、AIジョブのオーケストレーションがどう整理されるか。ここが実務上のインパクトになるはずだ。マルチベンダーの異種混在環境でリソースを効率化したいチームにとっては、試さない理由が減ったと言える。

まとめ

AIエージェントというワークロードが、これまでのインフラの前提を崩し始めている。Kubernetesの制御平面はエージェントの細粒度なスケジューリングに耐えず、Agent Substrateのようなランタイム層がバイパスとして生えている。GPUのフラグメンテーションもHAMiがスライスで解決しようとしている。既存のマニフェストを変えずに裏でリソースを書き換えるアプローチは、プラットフォームエンジニアにとって喉から手が出るほど嬉しいはずだ。

エージェント同士の経済活動も、人間向けのAPI鍵とアカウント登録では立ち行かない。X402がステーブルコインでHTTPリクエスト完結型の決済を標準化しようとしているのは、マイクロサービス間の認証・認可がエージェント間の決済に拡張された形だ。ただ、主要なモデルプロバイダーが不在のままエコシステムが回るのかは疑問が残る。

開発フローも変わりつつある。Jiraがエージェントにチケットを投げてPRを受け取る閉じたサイクルを描いている。コード生成が高速化してもレビューがボトルネックになるという指摘に対し、コンテキストスイッチを減らす方向で答えを出した。ただ、Jiraに留まることで得るコンテキストとIDEから離れることで失うコンテキストのトレードオフがどうなるかは、手を動かしてみないと分からない。

Xの全コードベース公開は、エージェントの文脈からは外れるが、プラットフォームの透明性と検証可能性という点で独立して注目すべき動きだ。全体を貫くのは、人間や従来のワークロードを前提に作られた層の上に、AIエージェントのための新しい層が割り込んでいるということだ。我々がKubernetesでマイクロサービスを回しているチームなら、エージェントワークロードを素のDeploymentとして載せるか、専用のランタイム層を挟むか。アーキテクチャの分岐点にすでに立っている。

参照記事

記録日: 2026-07-16