生成と制御の非対称性が描き直す、システムの境界線

AIパッチは成果物ではなく探針だ

GitHub BlogでDalia Abuadasが「The cost of saying yes has changed」を公開した。主張は明確だ。コードを書くコストは下がった。しかし所有するコストは下がっていない。この非対称性が、エンジニアの判断プロセスを根底から変える。

記事が描く光景は痛いほど分かる。設定ページにlast_active_atのタイムスタンプを表示してほしいという要望が来る。バックエンドにはすでにそのフィールドがある。チームのスレッドで40分議論。リスクを指摘する人、2年前のマイグレーションを持ち出す人、期限の話をする人。結論は「たぶん1日か2日、もっとかも」。自信は低い。誰も実際に試していないからだ。

これまでこのプロセスは理にかなっていた。試すこと自体が高コストだったからだ。コンテキストを頭に読み込み、手で変更を書き、テストを書き、二次的・三次的な影響を発見する。しかし最初の試行が安価になった今、境界を守る議論のコストが境界を超えるコストを上回ることがある。

ここでDaliaが提案するのが「制約付きの試行」だ。エージェントに最小限のパッチを生成させる。既存のフィーチャーフラグの背後に置く。公開コントラクトは変えない。テストを追加・更新する。触れたファイルをすべて列挙し、リスクのある箇所を明示する。この制約こそが重要だ。

生成されたパッチを成果物として扱うのが罠だとDaliaは断じる。それは探針だ。抽象的なスコープ議論を、検証可能な具体物に変える道具にすぎない。last_active_atが4行のdiffと通過するテストで返ってくれば、出荷すればいい。議論の方が高コストだったのだ。逆に同じ要求が認証ミドルウェアに触れるdiffで返ってきたなら、その要求は最初から小さくなかった。しかも2日かけてではなく30分でそれが分かる。

この区別は実務に直結する。マイクロサービス間の契約変更、プライバシー・課金・コンプライアンスに触れる変更は、コードが自明でもハードノーだ。AIが生成コストを下げても、所有コストは1ミリも下がらない。1000行のdiffがテストを通っても、誰も所有したくないなら、それは先送りされたコストに過ぎない。

スコープの規律を実装前からレビュー時に移す。計画を飛ばす話ではない。どの計画が実際に見返りがあるか、精確になれという話だ。AI支援下で最も有能なエンジニアは、すべてにイエスと言う人でも、反射的にノーと言う人でもない。不確実性を素早く値付けできる人だ。要求が実装の衣を着たプロダクト決定か、レビューが書くより難しいか、小さくて最速の責任ある回答が「とりあえず試す」ことかを見分ける人だ。

私の実務感覚に照らしても、この探針としての使い方は筋が良い。PRレビューの前に「制約付きで試す」という選択肢が増えたことで、議論の質が変わりそうだ。

デリバリーアプリがエージェント向けCLIを出すという判断

DoorDashが「dd-cli」というコマンドラインツールを発表した。macOS向けで、米国とカナダの開発者を対象にウェイティングリストを公開している。これ単体なら「面白い試み」で終わる話だが、中身がかなり思い切っている。AIエージェントが人間の承認なしに注文を完結できるのだ。

これまでDoorDashにもClaude連携やChatGPT統合、アプリ内の「Ask DoorDash」があった。しかしどれも最後のステップで人間が注文内容を確認する前提だった。dd-cliはそこを外す。エージェントが単独で検索し、価格を比較し、カートに入れ、支払う。1コマンドで済む。

なぜこれが重要か。DoorDashのようなデリバリープラットフォームは、エンドツーエンドの顧客関係を握ることで成り立っている。アプリ内のレコメンドや広告でマネタイズするモデルだ。APIを開放して開発者に自由にされては、その関係が切れる。Pragmatic EngineerのGergely Oroszも「低マージンビジネスなのに驚きだ」と指摘している。脱仲介化のリスクは本物だ。

だが、やらないリスクも同じくらい現実的だ。OpenCodeのDax Raadが言う通り、エージェント経由の注文が当たり前になる世界では、公式の手段を提供しなくてもエージェントは勝手にアクセスしてくる。スクレイピングでもブラウザ自動化でも。そうなるとDoorDashは制御を失う。競合に取って代わられる可能性もある。「パラダイムシフトが起きているなら、これを出さないと終わる」とRaadは断言している。

タイミングとして気になるのが、Linux Foundationが立ち上げたX402 Foundationの存在だ。

（X402は、AIエージェントが自律的に決済を行うための標準プロトコルを策定する取り組み）GoogleやStripe、Visa、Mastercardなど約40社が参加し、エージェントとAPI、アプリ間の「インターネットネイティブな決済」の標準化を進める。x402は既存の関係がない相手間での即時決済を想定している。dd-cliは逆で、既存のアカウントと決済手段がある前提だ。課題は違えど、どちらもエージェントが人間の代わりに取引するためのインフラを整えようとしている。

バックエンドを書く身として気になるのは、API設計の前提が変わる点だ。これまでも人間向けとマシン向けでエンドポイントを分けることはあった。しかし「人間の承認を前提としないクライアント」を公式に受け入れる設計は、認可・レート制限・エラーハンドリングの考え方を根底から変える。エージェントは人間より速く、予測不能なパターンでリクエストを投げる。どこまで許容し、どこで弾くか。dd-cliの実装詳細はまだ不明だが、この領域の標準がどう固まるかは、マイクロサービス間の連携設計にも影響するだろう。

OTELのトレースから小規模モデルを蒸留する話

Ben O'MahonyがInfoQで興味深いアプローチを披露した。OpenTelemetryのテレメトリデータを使って、フロンティアモデルの振る舞いを小規模言語モデル（SLM）に蒸留するという話だ。

（SLM: Small Language Model。パラメータ数を抑え、特定のタスクに特化させることで軽量化・高速化したモデル）

彼はAI搭載のLanguage Server Protocolを自作していた。Neovimユーザーとして何百行ものLuaを書いてエディタを自分好みに整形するタイプの人間が、当然AI補完も自分好みにしたいと思う。その流れは分かる。作ったAI LSPは、ファイル保存のたびにエージェントにリクエストを送る。プロアクティブに動く。チャンパネルを開いて指示を待つタイプではない。ただ、この設計には問題があった。トークンが燃える。一日中コーディングしていれば、その都度APIを叩く。コストが積み上がる。

もう一つ、カスタマイズの限界も感じていた。モデルを差し替えることはできても、AIの「頭脳」そのものを改善することは難しい。メモリ以上の恒久的な改善ができない。

そこで彼が気づいたのが、自分が既に学習データを生成しているという事実だ。OpenTelemetryがすべてをキャプチャしていた。どの提案を.acceptし、どれをdismissし、どれをregenerateさせたか。この行動データこそが、小さく速いモデルを訓練するためのデータセットになる。

ここが面白い。プロダクション環境のテレメトリは、監視やデバッグのためのものだと思っている。しかしAIエージェントの文脈では、ユーザーの行動シグナルがそのまま教師データになる。_accepted_というラベルは「この出力は良かった」、dismissed_は「良くなかった」という人間のフィードバックそのものだ。わざわざ別途アノテーションしなくていい。

O'Mahonyはこれをスケールするプラットフォーム機能にしたいと言っている。一回限りのハックではなく、抽出・フィルタリング・訓練・評価ゲートを通したデプロイという繰り返し可能なパイプラインにする。データフライホイールだ。

実務で考えると、気になる点がある。OTELトレースから学習データを抽出するにしても、フィルタリングの基準はどこに置くのか。ノイズが混じる可能性は高い。ユーザーが一時的にdismissしただけの提案を否定データとして扱っていいのか。評価ゲートの設計次第で、蒸留されたモデルの品質が大きく変わるはずだ。ここはまだ手探りなのか、それとも確立された手法があるのか。プレゼンだけでは読み取れなかった。

それでも方向性としては筋が良い。LLMのトークンコストは実務の頭痛の種だ。プロダクションで既に流れているOTELのデータを再利用して、より安く速いモデルに置き換えられるなら、インフラコストの削減とレスポンス向上の両方が狙える。

EKSが見せた、コントローラーのスケールで本当に難しいこと

Amazon EKSチームが、Kubernetesコントローラーを大規模に運用して得た教訓を公開した。対象はNetwork Policy ControllerとVPC Resource Controllerの2つ。数百ポッドのクラスターから10万ノードのクラスターまでを相手に、宣言的モデルをどう現実のものにするか。その実践知がまとまっている。

Kubernetesの宣言的アプローチは魅力的だ。「app=apiからのトラフィックだけ許可する」と宣言すれば、ポッドが入れ替わってもルールは維持される。小規模なら確かにそう動く。しかしスケールすると問題が変わる。キャッシュの遅延、オブジェクトの頻繁な変更、そして「世界の完全な見取り図」に依存する強制実行。これらの中で正確性を保つことこそが、本当の難しさだという。

Network Policy Controllerの設計は読み応えがあった。NetworkPolicyはラベルで意図を表現するが、データプレーンのeBPFが照合するのはポッドのIPアドレスだ。

（eBPF: Linuxカーネル内でサンドボックス化されたプログラムを実行し、ネットワークパケットのフィルタリングなどを高速に行う技術）この「ラベルからIPへの解決」をどこで行うか。各ノードが独立して全オブジェクトをwatchして解決する実装もある。EKSは違う。コントローラーが中央で1回だけjoinし、結果をPolicyEndpointという独自リソースに書き出す。各ノードのエージェントは自分のポッドに関連するPolicyEndpointだけを処理する。APIサーバーの負荷を抑えるための分割設計だ。ポッドが大量にマッチしたり頻繁に出入りしたりする場合、単一オブジェクトが肥大化・頻繁更新されるのを避けるため、結果を複数のPolicyEndpointに分割するという工夫も入っている。

ここで面白いのは、制御プレーンとデータプレーンの明確な分離だ。ノード上のエージェントは書き戻さない。コントローラーが決定し、ノードが強制する。この分離は、私が普段書くマイクロサービスでも意識している境界だ。責務が混ざると、どこで不整合が起きたか追えなくなる。

VPC Resource Controllerの方も実務に直結する問題を扱っている。通常、ポッドはノードのセキュリティグループを継承する。つまりRDSデータベースが特定のポッドからのアクセスだけ許可したい場合、ノードのセキュリティグループを許可しなければならず、結果としてそのノード上の全ポッドが許可されてしまう。ポッドに独自のセキュリティグループを付与できれば、この問題は解決する。SecurityGroupPerPolicyUnitという機能がそれを実現しているらしい。詳細な設計は元記事の続きに譲るが、AWSリソースとKubernetesリソースの境界をどう埋めるかという課題は、EKSを使うチームなら誰もが直面するはずだ。

コントローラーは実際に読むフィールドだけをキャッシュすることで、大規模クラスターでのメモリ使用量を数百MBから100MB未満に減らしている。

この「何をキャッシュするか」の判断も、スケール時の制約対応として興味深い。

私が気になるのは、この設計選択のトレードオフだ。中央でのjoinはAPIサーバー負荷を減らすが、単一障害点になりうるのか。PolicyEndpointの分割数はどう決まるのか。不可逆な操作の扱いについても言及があるようだが、元記事の後半で詳しく触れられているのだろう。そこまでは分からない。

確かなのは、コントローラーを書くこと自体は難しくないということ。難しいのは、スケールした環境で意図が「静かに失効する」のを防ぐことだ。この「静かな失効」こそ、本番運用で最も恐れるべき現象ではないか。

エージェントAIのオーケストレーションをCPUに任せる設計が現実味を帯びてきた

Googleが2024年4月に発表した自社初のArmベースサーバーCPU「Axion」が、エージェントAIの実行基盤として注目を集めている。ArmとGoogleの共同提案はシンプルだ。エージェントAIのワークロードを、GPUで処理すべき重い推論と、CPUで処理すべきオーケストレーションに切り分ける。そして後者をAxionで動かす。

なぜこうなるのか。エージェントAIは、LLMの推論だけで完結しない。APIを叩き、状態を保持し、ツールを選択し、生成されたコードを安全に実行する。これらのタスクは並行性が高く、レイテンシの影響を受けやすい。GPUの得意分野ではない。ArmのBhumik Patelも「オーケストレーション、API通信、メモリ管理はCPUが得意な領域だ」と指摘している。エージェントの数が増えれば、オーケストレーション層の負荷は無視できなくなるはずだ。

具体的な差分として提示されているのは、GKE Agent SandboxをAxion N4Aインスタンス上で動かした場合の価格性能比。他のハイパースケーラーと比較して最大30%良いという。GKE Agent Sandboxは、信頼できないAI生成コードを安全に実行するためのKubernetesネイティブな仕組みだ。gVisorによるカーネルレベルの隔離をデフォルトとし、

（gVisor: アプリケーションとホストカーネルの間にユーザー空間カーネルを介在させ、セキュリティ境界を強化するGoogle製のランタイム）Kata Containersもプラグイン可能。サブ秒のレイテンシで隔離環境を提供するという。

ここで面白いのはGKE Pod snapshotsの存在だ。エージェントがアイドル状態になったとき、サンドボックスのプロセス状態を保存し、後から復元できる。コールドスタートを減らし、長時間実行されるエージェントの一時停止と再開も可能になる。KubernetesでPodの状態をスナップショットとして扱うという発想は、ステートレス前提だったこれまでのワークロード設計から明確に外れる。エージェントAIのライフサイクル管理に合わせてクラスタの機能も変わりつつあると読める。

実務への影響を考えると、インフラの設計判断が増える。推論以外をどこに置くか。GPUインスタンスに全部載せてコストを膨らませるのか、CPUインスタンスにオーケストレーションを分離してコストを抑えるのか。Axionという選択肢が増えたことで、後者の設計が現実的なコストメリットを持ってきた。ただし、Armベースのインスタンスを選ぶということは、コンテナイメージのマルチアーキテクチャ対応や、ライブラリの互換性確認が前提になる。ここは地道な移行作業が待っている。

サンドボックスの隔離戦略も見直しが必要だ。gVisorやKata Containersをすでに使っているチームなら導入の敷居は低いが、そうでない場合はカーネル隔離のオーバーヘッドとトレードオフを評価することになる。エージェントが生成するコードの信頼度と、隔離のコストをどう釣り合わせるか。まだ答えの出ない部分も多い。

まとめ

コードを書くコストは下がった。だが、所有するコストは変わっていない。この非対称性が、実務の判断を根底から揺さぶっている。AIパッチを成果物ではなく探針として扱うのも、エージェントのオーケストレーションをGPUからCPUへ切り分けるのも、結局は「どこで境界を引くか」の再計算だ。安価になった試行をどう制約し、どう所有するか。そこにこそ今の設計の筋が通る。

エージェントが人間の承認なしに動く前提も、同じ境界の問題を突きつける。デリバリーアプリがエージェント向けCLIを出すのは、制御を失うリスクと取って代わられるリスクの綱引きだ。Kubernetesのコントローラーを大規模に運用する際に「静かな失効」を防ぐために制御プレーンとデータプレーンを分離するのも、エージェントのオーケストレーションを分離するのも、本質は同じではないか。意図を正確に伝え、それを維持する難しさ。スケールの有無を問わず、そこに共通の課題がある。

既存のデータを再利用してコストを下げる動きもある。OTELのトレースから小規模モデルを蒸留する試みは筋が良い。だが、ノイズのフィルタリングや評価ゲートの設計はまだ手探りだ。

インフラの面でも、ArmベースのCPUにオーケストレーションを分離すればコストは抑えられるが、マルチアーキテクチャ対応や隔離戦略の見直しという地道な作業が待っている。

境界を引き直すことでコストが見えるようになった一方で、新たなトレードオフも顔を覗かせる。

参照記事

記録日: 2026-07-18