モデルの外側に境界を引く──AIエージェントとインフラの制約設計

Copilotの課金変更で見えた「ツール」と「API」の境界線

GitHubがCopilotと生のAPIアクセスの違いを説明する記事を出した。「同じモデルをAPIで呼べばいいでは」という疑問に答える形だ。

結論から言うと、Copilotの課金モデルが変わったことがこの議論の引き金になっている。有料プランには毎月のAI Credits割り当てが含まれるようになった。コード補完とNext Edit Suggestionsはプラン内に留まる。一方、リソースを多く消費するチャットやエージェント機能にはAI Creditsが課金される。ここで「APIと同じトークン単価なら何を払っているのか」という問いが生まれるのは自然だ。

GitHubの主張はシンプルだ。モデルの呼び出しは、開発ワークフローの1ステップにすぎない。IssueからPRを作ってレビューを受けるまでを考えると、リポジトリのコンテキスト、許可されるコマンド、組織のポリシー。それらをエディタ、ターミナル、PR画面で繋ぐのがCopilotの役割だ。AI Creditsに課金されるのは、その周辺の仕事も含めてだと読める。

組織管理者にとっての変化もある。AI Creditsは組織全体でプールされ、予算設定や利用状況がダッシュボードで追える。個人APIキーに散らばっていた利用状況を一箇所で管理できるのは、規模の大きいチームほど意味があるだろう。

一方で、生のAPIが適している場面も明確に書かれている。自社のエージェント基盤、評価パイプライン、自動化ワークフローを構築する場合だ。プロンプト、ルーティング、リトライ、ログ、セキュリティモデル。全部を自前で制御したいならAPIを選ぶ。モデルエンドポイントはそこまで面倒を見てくれない。

この二つの間に位置するのがAgent SDKだ。オーケストレーションやツール利用、セッション管理を提供しつつ、プロバイダーに縛られるトレードオフがある。GitHubはCopilot SDKとしてこの層を提供している。Copilot CLIを支えているのと同じランタイムを、自分の環境に組み込める。

BYOKもパブリックプレビューに入った。Anthropic、AWS Bedrock、Google AI Studio、Microsoft Foundry、OpenAI、OpenAI互換プロバイダー、xAIに対応する。Copilotのワークフローと統合はGitHub側が提供し、トークン課金だけを自分のプロバイダーに切り替えられる。既存のクラウドコミットメントがあるチームにとっては現実的な選択肢だ。

20以上のモデルが選べるようになり、どれを有効にするかは組織管理者が決める。モデルアクセスそのものがポリシーの決定事項になったわけだ。

この記事は「どちらが優れているか」ではなく「どの仕事を自分で抱えるか」で選べと書いている。APIで自前のシステムを組むか、Copilotに開発ワークフローを任せるか。その境界線が課金の分離で少し見えやすくなったと思う。

エージェントの信頼性をどう担保するか

OpenAIがPresenceという製品を発表した。自社のカスタマーサポートラインで動いているAIエージェントを、エンタープライズの電話・チャットチャネルに展開するもの。OpenAIの英語の電話窓口では、75%の問い合わせを人間の介入なしで解決しているという。

ここで語られているのは、モデル自体はもう十分だということ。会話を深く掘り下げ、コードを生成し、サポートリクエストを解決する。その能力にボトルネックはない。むしろ問題は、モデルの周りにあるもの全部。エージェントが自律的に何をできるかを決めるポリシー、できないときのエスカレーションパス、何かが起きたときの記録。この「周りのもの」の設計と運用が、エンタープライズ導入の壁になっている。

バックエンドを書いている身としては腑に落ちる。CI/CDパイプラインを組むとき、アプリケーションコードそのものより、デプロイの前提条件やロールバックの仕組み、アラートの閾値の設定に時間がかかる。エージェントでも同じことが起きている。モデルが賢いことと、それを本番で安心して動かせることは別問題だ。

Presenceの面白さは、この「周りのもの」をパッケージングしている点。ポリシーの設定、テストツール、モニタリングダッシュボードが含まれている。特にポリシー変更をシミュレーションできる機能は実用的だ。返金やキャンセルといった過去のケースに対して、新しいポリシーがどう振る舞うかを事前にテストできる。デプロイ前のカナリアテストやシャドウモードと同じ発想だろう。

ただし、現状はセルフサーブではない。OpenAIのエンジニアが各顧客と一緒にジョブを定義し、システムを繋ぎ、権限を決め、テストを回して本番に出す。BBVA、SoftBank、IAGといった早期デザインパートナーとの取り組みも、OpenAI主導で進められている。エージェントの運用ノウハウがまだ属人的だということの裏返しと思う。Terraformでインフラをコード化する前に、手作業でクラスタを組んでいた時期に近いかもしれない。

エージェントが特定のジョブに特化し、そのジョブに必要なシステムと情報だけにアクセスするという設計は、最小権限の原則そのもの。企業側がルールを決める。自律的にできること、人間の承認が必要なこと、人間に引き継ぐポイント。この境界線をどこに引くかが、導入チームの最初の仕事になる。

モデルが賢くなればなるほど、周りの仕組みが勝負になる。Presenceはその現実に向き合った製品と言える。ただ、エンジニアが伴走しないと動かない段階というのは、スケールの観点でどう解消していくのか。そこが次の論点になりそうだ。

使用中のデータを守る――Confidential ContainersがCNCF Incubatingに昇格

Confidential ContainersがCNCFのIncubatingプロジェクトに承認された。2022年3月にSandboxへ入ってから、約4年での昇格となる。正式な移行日は2026年7月8日。

このプロジェクトが扱うのは「使用中のデータ」の保護だ。保管時の暗号化や転送時のTLSは当たり前になっている。しかしメモリ上で処理されているデータは、多くの場合平文のまま置かれている。Confidential ContainersはハードウェアのTEE（Trusted Execution Environment）を使って、この隙を埋める。

（TEEとは、メインプロセッサから隔離された安全な実行領域をハードウェア的に提供する技術で、メモリの内容を暗号化し、特権ユーザーであっても中身を覗けないようにします）インフラ提供者すらデータにアクセスできない。サードパーティのクラウドで機密ワークロードを動かすとき、この保証は大きい。

実務で何が変わるか。一番のポイントは、TEEの複雑さをKubernetesの標準パターンに抽象化しているところだ。Intel、AMD、NVIDIAなど、ハードウェアごとにTEEの実装は異なる。これをKata Containersランタイム経由でKubernetesに統合し、

（Kata Containersは、軽量な仮想マシンを使用してコンテナを分離するランタイムであり、TEEのようなハードウェア隔離をK8sで実現するための基盤となります）開発者はいつものkubectl applyで機密ワークロードをデプロイできる。ハードウェアの差異を意識しなくていい。Kyvernoとの統合でポリシーレベルの制御も可能になっている。

個人的に面白いと感じるのはKServeとの統合だ。AI推論のユースケースで、モデルの重みや入力データを保護しつつ推論を回す需要は実務で増えている。パブリッククラウド上でGPUを使いつつ、推論データをクラウド事業者から守る。Confidential Containersがこの要件をKubernetesネイティブに満たす選択肢になりうる。

エコシステムの数字も見ておく。コアリポジトリのGitHubスターは1,000超。マージ済みPRは1,200以上で、26のリポジトリグループにまたがる。アクティブなコントリビューターは150人を超え、Microsoft Azure、Alibaba、Red Hatといった主要プレイヤーが参加している。15以上のリリースを重ねているのも、プロダクション利用を見据えた成熟度の表れだろう。

SandboxからIncubatingへの移行は、技術面よりガバナンスの成熟を示すものだ。複数企業が関わるハードウェア系プロジェクトでは、中立な場所でのオープンガバナンスが前提になる。CNCFの傘下でそれが保証された。ただし、実際のプロダクション導入でどこまで普及するかは、各クラウドのサポート状況とパフォーマンスのオーバーヘッド次第だろう。そのあたりの実データはまだ見えてこない。

GitHub Issuesのナビゲーション、4%から22%までインスタント化した裏側

GitHubがIssuesのナビゲーションアーキテクチャを刷新し、インスタントに画面が切り替わる体験の割合を4%から22%に引き上げた。キャッシュヒット率は約33%。手元のデータを即座に描き、最新情報は後から同期する。この「制御されたstaleness」がトレードオフの核心だ。

採用したのはstale-while-revalidateに近いモデル。

（stale-while-revalidateは、キャッシュが期限切れ（stale）であっても一旦それを返しつつ、バックグラウンドで最新データを再検証（revalidate）して更新するHTTPキャッシュ戦略です）IndexedDBで永続化し、セッション中の頻出データはインメモリに置く。さらにService Workerがリクエストを傍受し、ローカルにあれば即座に返す。古ければバックグラウンドで再取得。ユーザーは待たずに画面を見る。データの新鮮さと速度のバランスを、許容される古さとして線引きした。

レイテンシの改善は分布全体に出ている。P10が600msから70ms、P25が800msから120ms、中央値も1200msから700msへ。P75とP90もそれぞれ1800msから1400ms、2400msから2100msに縮んだ。テールだけではなく、分布の裾野を底上げしている。Oguz Guvenが指摘した通り、p99の追い込みから分布の品質へ視点を移すことこそが成熟だと思う。

一方で、この手法がどこでも通用するわけではない。BareStackのコメントが要を突いている。プリフェッチが効くのは、データグラフが小さくread-heavyな領域だ。Issuesはまさにその条件を満たす。しかしread/writeの衝突が多いドメインでは、着地後に再フェッチが走り、かえって無駄を生む。再利用できるパターンは「shell-first render + cache-hit hydration」であって、プリフェッチそのものではない。

自分がマイクロサービスのAPIを設計している立場で気になるのは、この「古さの許容」をどこで決めるかだ。フロントエンド側で勝手に許容すると、バックエンドの整合性と食い違う。キャッシュのTTLや無効化のタイミングを、APIの責務として明示する必要がある。Service Workerがリクエストを握る以上、バックエンドの変更がいつクライアントに伝わるか、境界を設計しないと、デバッグが困難な不整合を生むかもしれない。

権限プロンプトは9割承認される──AnthropicがClaudeのコンテインメントで学んだ教訓

Anthropicがclaude.ai、Claude Code、Claude Coworkの3製品におけるコンテインメント設計を公開した。エージェントの安全性は分類器やシステムプロンプトでは保証できない。ファイルシステムやネットワーク、実行環境への決定論的な制限が唯一の確実な境界になる、というのがAnthropicの主張だ。実際のインシデントと設計変更がその理由をよく示している。

Claude Codeの初期設計は、書き込み・シェルコマンド・ネットワークアクセスごとにユーザー承認を求める方式だった。結果としてユーザーは約93%のプロンプトを承認した。人間がほぼ自動的に「許可」を押すなら、その確認に実質的な意味はない。Anthropicはその後、macOSでSeatbelt、Linuxでbubblewrapを使ったOSレベルのサンドボックスを追加した。

（これらはプロセスがアクセスできるファイルやネットワークリソースを厳格に制限する低レイヤーの隔離ツールです）ワークスペース内の書き込みは許可し、ネットワークアクセスはデフォルトで拒否する。権限プロンプトは84%減ったという。

レッドチームテストの結果も示唆的だ。フィッシング攻撃で従業員がClaude CodeにAWS認証情報の外部送信を指示したケースで、Claudeは25回中24回で機密情報を流出させた。リクエストが正当に見えるなら、出所がユーザーだろうがモデルの誤動だろうが関係ない。分類器で意図を推測するアプローチの限界がここに出ている。

Claude Coworkで起きたインシデントはさらに興味深い。悪意のあるファイルが、Anthropic自身のFiles APIを使ってワークスペースのファイルを攻撃者のアカウントにアップロードした。api.anthropic.comがドメイン許可リストに含まれていたからだ。許可されたドメインは、そのドメイン経由で到達可能な全機能へのアクセスを与える。この区別を見落としやすい。修正後はVM内にプロキシを置き、VMに割り当てられたセッショントークン以外のリクエストをブロックし、server-side-fetchヘッダーも拒否する設計になった。

自分がマイクロサービスのネットワークポリシーを書くとき、許可リストの運用で似た罠に遭遇した記憶がある。特定のドメインを許可すれば、その背後にある全APIエンドポイントが開く。エージェントが自律的にツールを呼び出す文脈では、この問題がさらに鋭くなる。人間がブラウザでURLを開く場合と違い、エージェントはAPIの全機能を機械的に叩けるからだ。

プロジェクトローカルな設定ファイルの取り扱いも地味だが重要なポイントだった。.claude/settings.jsonに定義されたフックが、フォルダの信頼プロンプトに承認される前に実行される脆弱性が報告されている。信頼の決定が終わる前にコードが走る。修正は解析と実行を信頼決定の後に遅延させることだった。CIパイプラインで信頼境界の前段で実行されるスクリプトの話に似ている。

Anthropicの結論はシンプルだ。コンテインメントは、ユーザーがどれだけ意味のある監視を提供できるかを反映すべきである。そしてエージェントのセキュリティは、有害な意図を認識することだけには依存できない。周囲の環境が、危険なアクションが引き起こす損害を制限しなければならない。KubernetesでNetworkPolicyを書く感覚に近い。Podがどこに通信できるかを境界として定義し、アプリケーション側の判断に頼らないアプローチだ。エージェントがより自律的になるなら、この環境側の制約の設計がますます重要になるだろう。

まとめ

モデルが賢くなればなるほど、周辺の仕組みの設計が勝負になる。Copilotの課金分離は、モデル呼び出しとワークフロー管理の境界を明示した。Presenceはエージェントのポリシーやエスカレーションをパッケージングしている。Anthropicのコンテインメントは、ユーザーの承認に頼らず環境側で決定論的な制限を課す方針だ。どれもモデルの外側に線を引いている。

境界線をどこに引くかは、人間の監視がどこまで有効かという問いに直結する。Anthropicの権限プロンプトが9割承認された事実は、人間の確認が実質的な安全網になり得ないことを示している。GitHub Issuesのstaleness許容も、バックエンドの整合性をフロントエンド側の判断に委ねる境界の線引きだった。システムが自律的に動くほど、人間の判断に頼れない領域が広がる。

インフラの観点から見ると、決定論的な制約をエージェントに適用する流れは自然だ。KubernetesのNetworkPolicyで通信を制限するのと同じ発想で、エージェントのサンドボックスやTEEによるデータ保護が語られている。ただ、運用ノウハウがまだ属人的な段階や、パフォーマンスのオーバーヘッドが見えない段階もある。実務でどこまで通用するかは、これからの検証次第だろう。

参照記事

記録日: 2026-07-23