カテゴリー: AI技術

リアルタイム音声AIの負荷分散を、Web APIと同じQPS（1秒あたりのリクエスト数）だけで設計すると危険です。短い100件より、20分続く5会話のほうが重いことがあるからです。Google Developers Blogは2026年8月、CPU使用率に「アクティブなセッション数」を重ねる設計を紹介しました。重要なのは、いま使っている資源だけでなく、すでに引き受けた仕事も測ることです。

QPSとCPUだけでは見えない負荷

通常のAPIは、要求を受けて応答すれば処理が終わります。一方、音声・動画などのリアルタイムAIは、WebSocketやgRPCの双方向ストリームを長時間維持します。その間、音声バッファ、途中の文字起こし、モデルの文脈、ツール呼び出しなどがランタイム内に残ります。

ここで2つの錯覚が生まれます。

• QPSの錯覚：新規接続が少なくても、長時間セッションが積み上がっている可能性があります。
• CPUの錯覚：利用者が黙っている間は低負荷でも、同時に話し始めれば一気に処理が集中します。

Googleの記事は、CPUを「現在の圧力」、アクティブセッション数を「将来分も含む約束済み負荷」と捉えています。片方を捨てるのではなく、両方を見るのがポイントです。

設計は3つの信号を分ける

リアルタイムAIでは、少なくとも次の3信号を別々に観測します。

• 到着量：新規セッションの開始率
• 現在負荷：CPU、メモリ、推論待ち時間
• 約束済み負荷：各バックエンドが保持するアクティブセッション数

単純な空き枠は「最大セッション数 − 現在のセッション数」で表せます。ただし、全セッションの重さが同じとは限りません。実運用ではCPUやメモリと組み合わせ、安全係数を置いて新規割り当てを徐々に増やします。見かけ上アイドルな1台へ接続を一気に流し込まないためです。

実装で外せない4点

1. 開始と終了をアプリ内で数える
   ロードバランサーからは、会話中・待機中・ヘルスチェックの区別がつきません。セッションの意味を知るランタイム側で計測します。
2. 必ず終了処理を通す
   正常終了だけでなく、タイムアウト、キャンセル、切断でもカウンターを戻します。残った「幽霊セッション」は、メモリリークだけでなく誤ったルーティング判断を生みます。
3. 二重減算を防ぐ
   切断とタイムアウトが同時に発火しても、終了処理は一度だけにします。実際より空いているように見せる誤カウントのほうが危険です。
4. 観測窓と安全係数を決める
   瞬間値で振り回されないようCPUを平滑化し、メトリクス取得間隔の遅れも見込んで保守的に割り当てます。

負荷試験も「短い大量リクエスト」から変える

短い要求を連打する試験だけでは、リアルタイムAIの故障モードを再現できません。Googleの記事は、同時セッション数、継続時間、到着パターン、無音と発話の比率、キャンセル・切断率、バックエンド数などを変えるよう勧めています。

確認したい指標も平均応答時間だけではありません。

• バックエンド間のアクティブセッション分布
• 過負荷なインスタンスへ割り当てた比率
• 起動レイテンシのp95・p99（遅い側から数えて上位5％・1％に当たる値）と最初のストリームまでの時間
• 切断後にカウンターが正しく戻るか
• セッション切断数

さらに、共有カウンター自体もクリティカルパスです。高並列時には単一のアトミックカウンターが競合点になり得るため、単スレッドの速さではなく競合時の挙動を測ります。

プロジェクトリーダー視点では「処理量」より「引受残」を管理する

これはプロジェクト管理にも似ています。今日届いた依頼件数だけでは、チームの余力は分かりません。すでに着手し、完了責任を負っている案件の残量も必要です。

リアルタイムAIでも、QPSは入口、CPUは現在、セッション数は引受残です。この3つを分離して見れば、オートスケールの判断、ルーティング、SLO（サービス品質目標）の原因分析を同じ枠組みで議論できます。ネットワーク設定だけで解こうとせず、アプリケーションの状態をインフラへ安全に渡す設計が必要です。

まとめ

• 長時間ストリームでは、QPSだけではバックエンドの忙しさを測れません。
• CPUは現在負荷、アクティブセッション数は約束済み負荷として併用します。
• 終了漏れと二重減算を防ぎ、現実的な会話パターンで負荷試験します。
• リアルタイムAIの負荷分散は、接続数ではなく「生きた会話」を配る設計です。

公式ソース

• Google Developers Blog: Scaling real-time AI agents with session-aware load balancing
• gRPC公式ドキュメント: Flow Control

AIコーディングを並列化するなら、エージェントの人数より先に「ぶつからない作業面」を用意する。

OpenAIが公開したAsanaの事例によると、同社はフロントエンド更新の障害になっていたテスト基盤Enzymeの撤去を、約2週間で完了しました。従来計画は少なくとも5年、約600万ドル相当。今回のモデル・インフラ費は約1万2,000ドルだったと報告されています。

ただし、これはAIが5年分の開発を自動で終えたという一般論ではありません。成功の核心は、機械的に分けやすい移行を選び、最大4体を別々のコードベースで動かし、人間が全変更をレビューした運用設計にあります。

何を2週間で終えたのか

対象は新機能開発ではなく、React向けテストツールEnzymeの撤去です。OpenAIの公式事例によると、EnzymeはAsanaのフロントエンド更新を妨げる技術的負債になっていました。

Enzymeの公式リポジトリを見ると、公式アダプターの対応表はReact 16までです。つまりAsanaの仕事は、仕様が固まっていない探索ではなく、既存テストを読み、置き換え、動作確認する反復型の移行でした。AIエージェントが得意な「似た変更を多数のファイルへ一貫して適用する」仕事と相性がよい領域です。

実績の数字は、次のように読む必要があります。

• 完了期間：1.5週間分のエンジニア作業量を、暦の2週間で実施
• 並列数：最大4体のコーディングエージェント
• 費用：モデルとインフラで約1万2,000ドル
• 比較対象：従来計画は少なくとも5年、約600万ドル相当というAsanaの見積もり

600万ドルから1万2,000ドルへの単純比較は魅力的ですが、同じ条件の実測対照試験ではありません。従来計画の見積もりと、今回の直接費を比べた事例値です。人間の設計・監督・レビュー費までゼロになった、という意味ではありません。

設計1：エージェントごとに作業面を分ける

Asanaは最大4体を、それぞれ別のコードベースのコピーで動かしました。ここが重要です。同じ作業ツリーを共有すると、同じファイルの編集、依存関係の更新、テスト生成が衝突し、速さより調整コストが増えます。

実務では、次の単位で隔離すると扱いやすくなります。

• エージェントごとにブランチまたはworktreeを分ける
• 担当範囲をディレクトリ、パッケージ、変更パターンで切る
• 共通設定ファイルの変更は一つの担当へ集約する
• 成果物は直接マージせず、PRとCIを通す

並列数は性能ではなく、衝突しない仕事の数で決めるべきです。4体を動かせることより、4つの独立した変更単位を作れることの方が先です。

設計2：長い指示書より、判定可能なゴールを置く

Asanaの事例では、出発点は5文のプロンプトで、複雑な設定より簡潔な指示の方がうまく機能したとされています。

ここで「短いほどよい」と一般化するのは危険です。短くできた理由は、ゴールが明快だったからです。Enzymeをなくす、既存の振る舞いを保つ、テストを通す。終了条件を機械的に判定できます。

OpenAIのCodex活用ガイドも、大規模変更では先に実装計画を作り、GitHub Issueのようにファイルパス、対象コンポーネント、参考実装を示す方法を推奨しています。指示を短くする代わりに、リポジトリ側へ規約、AGENTS.md、参考パターンを置き、完了判定はテストに委ねる。プロンプトへ全部詰め込まず、環境を説明書にする設計です。

設計3：人間は生成量ではなく、統合点を管理する

この事例で人間は外れていません。エンジニアが1日2回進捗を確認し、提案された変更をすべてレビューしました。

AI導入前は「誰がコードを書くか」がボトルネックでした。並列エージェント導入後は、次の工程へボトルネックが移ります。

1. タスクを衝突しない単位へ分ける
2. 失敗した変更を早く検知する
3. PRの依存順序を決める
4. 最終的な動作と保守性を人間が承認する

したがって、エージェント数だけを増やすとレビュー待ちが膨らみます。人間が確認できるPR数、CI時間、競合解消能力を含めて、仕掛かり上限を設定する必要があります。

車載開発にたとえると

これはECUソフトの一括置換にも近い構図です。複数チームが同じ統合ブランチを直接触れば、個々の実装が速くても結合で詰まります。

一方、対象コンポーネント、入出力、回帰試験、統合順序を先に固定すれば、作業を並列化できます。AIエージェントは高速な実装担当として働けますが、変更影響の境界と合否判定を作るのは依然としてPL（プロジェクトリーダー）の仕事です。

「4人を4倍速く働かせる」より、「4つの独立した検証可能な作業へ分ける」。Asanaの事例から持ち帰るべきなのは、この分解の設計です。

導入前チェックリスト

• 対象は大量の反復変更で、完了条件をテストで判定できるか
• 担当範囲を分け、同じファイルへの同時編集を減らせるか
• 各エージェントに独立したブランチまたはworktreeがあるか
• 共通設定、依存更新、マイグレーション順序の責任者を決めたか
• CI失敗、競合、レビュー待ちを可視化できるか
• 人間が全変更を確認できる仕掛かり上限になっているか

まとめ

• AsanaはEnzyme撤去を、最大4体のCodexと人間の全件レビューで約2週間で完了した
• 各エージェントを別のコードベースで動かし、編集衝突を隔離した
• 簡潔な指示が効いた背景には、判定可能な移行ゴールがあった
• 600万ドル対1万2,000ドルは、従来見積もりと直接費の比較であり、一般的な削減率ではない
• 並列化の上限はモデル数ではなく、独立タスク数と人間のレビュー能力で決まる

AIコーディングの速度を決めるのは、最も賢いモデルだけではありません。変更をぶつからない単位へ分け、機械で検証し、人間が統合できるハーネスです。

参考ソース

• OpenAI：Asana cleared 5 years of engineering work in 2 weeks with Codex
• OpenAI：How OpenAI uses Codex
• Enzyme公式GitHubリポジトリ

AIに考えさせる。でも、計算と更新まで任せきらない。

Googleの「Agent Bake-Off」総括は、5つの実践則の一つを見出しでこう表現しました。LLMは推論し、決定論的なコードが実行する。金融取引の計算をAIに担わせたチームでは、大きな検証エラーを招いたと報告しています。

今回は、自然言語を理解するAIと、毎回同じ結果を返す従来コードをどう分業させるか。構造化出力を「安全装置」と誤解しないための設計を整理します。

LLMが得意な仕事、コードが得意な仕事

LLMは入力の揺れを吸収するのが得意です。「来月から毎月3万円を積み立てたい」のような文章から、金額・開始月・意図を読み取れます。一方、複利計算、在庫更新、送金、権限判定のように、同じ入力には同じ結果が必要な処理は従来コードの担当です。

• LLM：意図抽出、分類、候補作成、例外の説明
• スキーマ：受け渡す項目・型・許容値の固定
• コード：計算、検証、認可、データ更新

Googleの公式記事では、金融取引の変数を厳格なJSONスキーマで受け取り、検証後にPython関数やSQLへ渡す構成を推奨しています。AIを電卓にするのではなく、電卓へ正しい引数を渡す通訳にする設計です。

構造化出力は「正しい意味」を保証しない

Gemini APIの公式ドキュメントでは、JSON Schemaに従う構造化出力を、データ抽出・分類・ツール入力に使えると説明しています。PythonではPydantic、JavaScriptではZodからスキーマを定義できます。ただしJSON Schemaの全機能に対応するわけではなく、大きすぎる、または深くネストしたスキーマは拒否される場合があります。

ただし、ここが重要です。Google自身が「出力は構文的に正しいJSONでも、値はアプリケーション側で必ず検証する」と明記しています。形が正しくても、中身が正しいとは限りません。

たとえば仮に、次のJSONは型としては正常です。

{
  "amount_yen": 30000,
  "months": 12,
  "annual_rate": 15.0
}

しかし、年利15%がユーザーの入力なのか、AIが補った値なのかは別問題です。スキーマが検査できるのは、定義した項目・型・列挙値・上限などの範囲です。根拠のない数値まで消してはくれません。

本番では4つの境界を置く

1. 抽出境界：LLMは入力から変数だけを抽出する。推測値には出典や信頼度を付ける
2. 型境界：JSON Schemaで必須項目、型、列挙値、上限・下限を絞る
3. 業務境界：コードで「残高以内か」「承認権限があるか」「締切前か」を再検証する
4. 副作用境界：確認前は計算・見積もりまで。DB更新や送信は承認後の別処理にする

特に3番目が肝です。型検証を通過したからといって、業務上正しいとは限りません。金額が整数でも、利用上限を超えていれば拒否する必要があります。

車載開発にたとえると

この考え方は、AIシステムに限らず制御系の設計にも通じます。

LLMはドライバーの曖昧な要望を読み取るHMIに近く、決定論的コードはECUの制御ロジックに近い存在です。「少し暖かくして」を温度目標へ変換するのはAI向きですが、アクチュエータの上限監視やフェイルセーフまで確率的モデルへ預けるべきではありません。

自然言語の柔軟性は入口で使い、実行経路は型・ルール・承認で狭める。この分離が、便利さを落とさずに事故の範囲を小さくします。

実践チェックリスト

• LLMの出力を、そのまま計算結果や更新値として使っていないか
• 構造化出力をPydanticやZodなどで再検証しているか
• 型検証とは別に、金額上限・権限・状態遷移を確認しているか
• 欠損値をAIが勝手に補わず、確認へ戻せるか
• 読み取り・計算と、送信・更新の副作用を分離しているか

まとめ

• LLMは意図を読み、決定論的コードが計算・検証・実行する
• JSON Schemaは形を保証するが、値の意味までは保証しない
• 型検証、業務ルール、承認を別々の境界として設計する
• AIは「答えを出す装置」より「正しい処理へつなぐ通訳」として使う

賢いモデルほど多くを任せたくなります。しかし本番品質を決めるのは、AIに何をさせるかだけではなく、どこから先を普通のコードへ戻すかです。

参考ソース

• Google Developers Blog：Build Better AI Agents: 5 Developer Tips from the Agent Bake-Off（2026年4月14日）
• Google AI for Developers：Structured outputs（2026年8月26日更新）
• Google Agent Development Kit：Simple agents with LlmAgent

スキルは積むものじゃない。引き出しにしまって、必要な瞬間だけ開けるもの。

前回はKVキャッシュの観点から「一度渡したコンテキストは書き換えない」設計を紹介しました。前々回は、ツール定義を遅延読み込みするTool Searchでした。道具側の最適化は揃いつつあります。

今回は知識側です。社内ノウハウをエージェントに覚えさせるとき、どう保存し、どう配布するか。Anthropic発のオープン仕様「Agent Skills」が、この問題に一つの答えを出しました。

システムプロンプト全積み方式の限界

エージェントに専門手順を教える定番は、システムプロンプトに全部書き込む方法です。ただしこの方法には2つの問題があります。

• 起動コスト：使う使わないに関係なく、全ノウハウが毎回の入力トークンになる
• 資産化の失敗：書き方が人それぞれで、バージョン管理もレビューもされない

Agent Skillsは、ノウハウを「フォルダ1個」にパッケージ化する軽量な形式です。SKILL.md（必須：メタデータ＋手順）を中心に、scripts/（実行コード）、references/（参考資料）、assets/（テンプレート）を任意で束ねます。

形式はオープン標準として公開されており（コードはApache 2.0、文書はCC-BY-4.0）、公式READMEは「一度作れば、skills互換のどんなエージェントでも再利用できる」と明記しています。

3段階の開示：常駐は約100トークン

中核は段階的開示（progressive disclosure）です。Anthropic公式ドキュメントのトークンコスト表が、設計思想を端的に示しています。

• レベル1 メタデータ：常時（起動時）／約100トークン／スキルの名前と説明
• レベル2 手順本文：発動時のみ／5kトークン未満／SKILL.mdの本文
• レベル3+ リソース：必要時のみ／アクセスするまでゼロ／参照ファイルやスクリプト

起動時にコンテキストを占有するのは、名前と説明だけ。約100トークン×スキル数なので、100個積んでも約1万トークンです。手順書全文を毎回積む方式とは桁が違います。タスクの内容が説明に一致した瞬間だけ本文が読まれ、さらに深い情報は参照ファイルとして、必要になってから開かれます。

スクリプトの位置づけも特徴的です。バンドルされたコードはbashで「実行」され、コンテキストに入るのはその出力だけ。手順書（柔軟性）・コード（信頼性）・資料（事実参照）を、別々の読み込み方で扱う分担設計になっています。

descriptionが発火を決める

発動のトリガーはレベル1の説明文です。仕様は「何をするか」に加えて「いつ使うか」を書くことを求めています。公式の例で比較すると差は歴然です。

• 悪い例：「Helps with PDFs.」
• 良い例：「Extracts text and tables from PDF files, fills PDF forms… Use when working with PDF documents.」

つまり説明文は名札ではなく、発火のための着火材です。ここが弱いと、せっかくの知識が一度も開かれないまま終わります。

MCPが配布経路の標準化に動き出した

保存形式だけでなく、配布も標準化が進んでいます。MCPの2026-07-28版仕様は「Skills over MCP」を注目拡張として挙げ、専任のワークグループが設置されています。草案SEP-2076（スキルを第一級プリミティブに）を経て、現行の方針はSEP-2640「Skills Extension」（Resourcesベース、Extensions Track）です。Google、Databricks、GitHub、AWSらが参加しています。

「スキルをどこに置き、どう見つけ、どう渡すか」が、ベンダー横断のインフラ問題として扱われ始めた、ということです。

車載開発にたとえると

新人に社内規則の全文を暗記させるのがシステムプロンプト全積みなら、現場の方式は、掲示板には「何を、いつ使うか」の札だけを貼り、手順書はファイルサーバーに置き、規格原本や検証治具にあたる参照資料・スクリプトは、さらに奥の引き出しにしまう方式です。Agent Skillsはこれを「フォルダ＋マニフェスト」に落とし込み、検索と実行の仕組みまで込みで標準化したものと言えます。

実践チェックリスト

• descriptionには「何をするか＋いつ使うか」を書く（発火精度の決め手）
• SKILL.md本文は5kトークン未満に収め、長い手順は参照ファイルへ分割する
• 判定や変換など決定的な処理はスクリプト化し、コード本文はコンテキストに入れない
• スキルフォルダはGitで管理し、知識の変更もレビューする
• 起動時コストは「スキル数×約100トークン」で見積もる

まとめ

• 知識も道具と同じ。「全部積む」のではなく、必要な瞬間に必要な分だけ開く
• 3段階の開示で、起動時の常駐コストは1スキル約100トークンに圧縮
• 説明文は発火のための着火材。「何＋いつ」を書く
• MCP側の標準化（Skills Extension）で、配布経路もベンダー横断へ

コンテキスト設計は「削る」「遅延読み込み」「動かさない」と続いてきました。今回の「どこに置くか」が加わって、個人のプロンプト職人の技から、組織のナレッジインフラ設計へと移り始めています。

参考ソース

• agentskills.io：Agent Skills Specification（フォルダ形式・frontmatter制約）
• GitHub agentskills/agentskills：README（3段階の開示・ライセンス・再利用）
• Anthropic公式ドキュメント：Agent Skills overview（トークンコスト表）
• Anthropic Engineering：Equipping agents for the real world with Agent Skills（2025年10月）
• Model Context Protocol：Specification 2026-07-28／Skills over MCP Working Group Charter（SEP-2076・SEP-2640）

前回は、ツール定義を最初から渡さない遅延読み込みを紹介しました。あの記事の最後に「見つかったツールはコンテキストの末尾へ追加されるので、キャッシュが効きやすい」と書きました。

今回はその一般化です。「減らす」のではなく「一度渡したものは、1バイトも動かさない」。コストと速度の両方に効く、KVキャッシュの話をします。

エージェントは「入力」にお金を払っている

エージェントはツールを使うたびに、過去のやり取りすべてを含んだコンテキストを送り直します。対して出力は、短い関数呼び出し1個。

Manusの公式ブログ（2025年7月）によれば、同社のエージェントでは平均の入出力トークン比が約100:1。つまり支払いのほぼすべてが入力処理です。

そして入力には、公式に「値引き」が用意されています。

• Anthropic: キャッシュ済み入力はベース価格の0.1倍。Claude Sonnet 5なら $2/MTok → $0.20/MTok（10分の1）
• OpenAI: キャッシュ済み入力トークンは「最大90%割引」

仕組み：完全一致しか許されないキャッシュ

LLMは入力を処理するとき、トークン間の関係をまとめた中間計算結果（KV状態）を作ります。プロンプトキャッシュはこのKVテンソルを保存しておき、同じプレフィックスを持つ次のリクエストで再利用する——これがOpenAI公式ドキュメントの説明です。

重要なのは「同じ」が完全一致だという点。1トークンでも違えば、そこから先は全部再計算になります。

Anthropicのキャッシュ対象は tools → system → messages の順で連結した全体。この順序を覚えておくと、「何がキャッシュを壊すか」が見えてきます。

車載開発にたとえると、配線を1本引き直すと、下流のECUは全部再認証になるのと同じです。キャッシュは「先頭からの一致」でしか成立しません。

キャッシュを殺す3つの罠

罠1: プロンプト先頭のタイムスタンプ

「現在時刻を伝えるために、システムプロンプトの先頭に日時を入れる」のは典型悪手です。秒単位の時刻は毎回変わるので、キャッシュが毎回全滅する。Manusの公式ブログも真っ先にこれを挙げています。時刻が欲しいなら、コンテキストの末尾（ユーザーメッセージ側）に置きましょう。

罠2: 過去メッセージの書き換え

「前のターンの観測結果を要約して置き換える」処理を毎ターン実行すると、置換位置から先がキャッシュ不能になります。基本は追加専用（append-only）。要約・圧縮するなら、まとめて実行して置換の頻度を下げるのがポイントです。

罠3: ツール配列の入れ替え

OpenAI公式ドキュメントは、tools の「名前・説明・スキーマ・順序」の変更がキャッシュに影響すると明記しています。自前でツールを抜き差しするのはキャッシュ面でも動作面でもリスク大。やるなら前回紹介したTool Searchのような公式の遅延読み込み機構を使うのが安全です。

実践チェックリスト

• 可変情報（現在時刻、検索結果など）はコンテキストの末尾に置く
• JSONのシリアライズはキー順を固定する（言語・ライブラリによってはキー順が非決定的で、黙ってキャッシュを壊す）
• Anthropicのキャッシュ寿命はデフォルト5分。ただしキャッシュを使うたびに無料で更新されるので、頻繁に呼ぶエージェントなら実質無期限。1時間TTLは書き込みが2倍コスト
• APIレスポンスのusageを確認し、キャッシュ読み（cache read）トークンがちゃんと出ているか定期チェックする

考察：「削る」と「固定する」は矛盾しない

ここ数回の「減らす」話と、今回の「動かさない」話は一見逆方向に見えます。でも原点は同じ、「コンテキストは有限リソース」という認識です。Anthropicはこれを「モデルにはattention budgetがある」と表現しています。

• 削る → 1回の推論の質を守る（context rot対策）
• 固定する → 推論間の再利用を最大化する（コスト・レイテンシ対策）

設計の本体は結局、「安定なものを前、可変なものを後ろ」という順序設計に集約されます。静的なシステムプロンプトとツール定義を前に固め、履歴は追加専用で積み、そのターンだけ必要な一時情報を末尾に置く。この1行に全部入っています。

まとめ

• エージェントのコストは入力が支配する（100:1）。入力には10分の1の値札が最初から付いている
• 値引きは「完全一致」しか効かない。1トークンの差が10倍の差になる
• 今日からできる3つ: 時刻は末尾・履歴は追加専用・ツールは固定

「減らす」設計と「動かさない」設計、両方揃って初めてコンテキストエンジニアリングです。

PL視点では「トークン数」より「キャッシュヒット率」を見る

コスト見積もりで入力トークンの総数だけ数えても、実費は変わりません。見るべきはキャッシュ済み入力の割合です。APIのusageレスポンスでキャッシュ読みトークンが記録されているので、運用ダッシュボードに入れておくと、「ある改修を入れた瞬間に命中率が落ちた」という発見ができます。速度の劣化も、まずこの指標で説明がつくことが多いです。

参考ソース

• Anthropic公式ドキュメント: Prompt caching（料金倍率・TTL・キャッシュ順序）
• OpenAI公式ドキュメント: Prompt caching（90%割引・KVテンソル・toolsの影響）
• Manus公式ブログ: Context Engineering for AI Agents（2025年7月）（100:1・タイムスタンプ罠・append-only）
• Anthropic Engineering: Effective context engineering for AI agents（2025年9月）

AIエージェントへ100個のツール定義を最初から渡すと、使わない引数スキーマまでコンテキストを占有します。OpenAIのTool Searchは、必要なツールだけを実行時に読み込む仕組みです。ただし、これは認可機能ではありません。効率化と実行権限を分けて設計することが重要です。

Tool Searchは「巨大な工具箱の目次」です

通常のツール呼び出しでは、モデルは利用可能な関数の名前、説明、引数スキーマをコンテキスト内で受け取ります。ツールが増えるほど、その定義だけでトークンを消費し、モデルが似た道具を取り違える余地も増えます。

Tool Searchでは、候補となる関数、名前空間、MCPサーバーを検索対象として登録し、詳細の読み込みを実行時まで遅らせます。モデルが必要だと判断したサブセットだけがコンテキストへ追加され、その後に通常のツール呼び出しへ進みます。

OpenAIの公式ガイドでは、ツール検索を有効にする条件を次の2点としています。

1. tools配列へtool_searchを追加する
2. 遅延対象の関数またはMCPサーバーへdefer_loading: trueを付ける

2026年8月29日時点の公式ガイドでは、Tool Searchをサポートするのはgpt-5.4以降です。Agents SDKのホスト型検索はOpenAI Responsesモデル向けで、Pythonではopenai>=2.25.0に依存します。導入時はモデルとSDKの両方を確認する必要があります。

遅延される範囲を誤解しない

Tool Searchは、ツールを完全に不可視にする機能ではありません。名前空間やMCPサーバーを使う場合、最初に見えるのは名前と概要だけで、内部の個別関数は検索後に読み込まれます。一方、個別関数だけを遅延すると、その関数名と説明は最初から見え、主に引数スキーマが後回しになります。

そのため、個別関数を大量に平置きするより、crm、billing、shippingのような業務単位で名前空間へまとめる方が効果的です。OpenAIは、可能なら名前空間またはMCPサーバーを使い、各名前空間を10関数未満に保つことをベストプラクティスとして示しています。

車載開発でいえば、全ECUの全サービス仕様を毎回配るのではなく、まず「診断」「書き換え」「ログ取得」という目次だけを見せ、選ばれた領域のサービス定義を開くイメージです。

キャッシュを壊しにくい追加位置

Tool Searchはトークン削減だけでなく、プロンプトキャッシュを保ちやすいよう設計されています。公式ガイドによると、新しく見つかったツールはコンテキスト末尾へ追加されます。先頭の共通部分が変わりにくいため、リクエスト間でキャッシュが効きやすくなります。

ただし、「何％削減できる」と一律には言えません。効果はツール数、スキーマの大きさ、実際に読み込む割合、モデル料金で変わります。導入前後で少なくとも次を計測すべきです。

• 初回リクエストの入力トークン数
• 検索で読み込んだ名前空間・ツール数
• 最終回答までのレイテンシー
• ツール選択の正解率と再試行回数
• キャッシュ済み入力トークンの割合

安全に導入する4つの設計

1. 名前空間を業務境界に合わせる

ライブラリの都合ではなく、利用者の目的に合わせて分けます。たとえば注文照会ならcrm、請求確認ならbillingです。説明文には「何ができるか」だけでなく「何は含まないか」も書くと、不要な検索を減らせます。

2. 常用ツールと遅延ツールを混在させる

名前空間内では、即時利用できるツールとdefer_loading付きのツールを混在できます。毎ターン使う検索や状態確認は常用にし、長いスキーマを持つ例外処理や管理機能だけを遅延させる方が、検索の追加ステップを抑えられます。

3. 在庫が固定ならホスト型、動的ならクライアント実行型

候補ツールがリクエスト作成時に分かるなら、OpenAI側が検索するホスト型から始めるのが簡単です。テナント、契約、プロジェクト状態によって候補自体が変わるなら、アプリが検索結果を返すクライアント実行型が向きます。

ただしAgents SDKの標準Runnerは、クライアント実行型のtool_search_callを自動処理せず、呼び出されると例外になります。Responses APIを手動でオーケストレーションする必要があります。方式選択は「自前検索が必要か」で決めるべきです。

4. 検索と認可を分離する

defer_loadingは、ツール定義を後から読み込む指定であって、実行権限を奪う指定ではありません。利用者に見せてよい名前空間の絞り込み、ツール実行時の認可、引数検証、承認ゲートは別に実装します。

また、実行ログには最終的な関数呼び出しだけでなく、tool_search_callとtool_search_outputも残します。「なぜその道具が候補になったか」を追えないと、誤選択の原因をモデル、検索面、権限設定のどこへ戻すべきか判断できません。

PL視点では「ツール数」より探索経路をレビューする

レビューでは、登録ツールの総数だけを数えても不十分です。次の5点を確認します。

• 最初からモデルへ見える情報は何か
• どの名前空間が、どんな説明で検索されるか
• 1回の要求で何個のツール定義が読み込まれるか
• 検索結果が権限変更やテナント境界を越えないか
• 検索、実行、承認をトレースで結べるか

Tool Searchは、巨大なツール群を扱うためのルーターです。ルーターが賢くても、実行ゲートがなければ安全にはなりません。逆に、すべてを最初から渡して認可だけ強くしても、コンテキスト効率は改善しません。

まとめ

• 全ツール定義を先に渡さず、必要なサブセットだけ読み込む
• 個別関数の平置きより、10関数未満を目安に名前空間化する
• 固定在庫はホスト型、動的在庫はクライアント型を検討する
• 遅延読み込みを認可と混同せず、実行時に別途検証する

AIエージェントの工具箱が大きくなったら、モデルを替える前に「目次と実行鍵を分ける」設計を見直す。Tool Searchが示しているのは、ツール追加ではなくツールの公開範囲を管理する重要性です。

公式ソース

• OpenAI API — Tool search
• OpenAI Agents SDK — ホスト型ツール検索
• OpenAI Agents SDK — Tool Search公式実装例
• OpenAI Agents SDK公式リポジトリ

MCPサーバーが利用者ごとに使えるツールを絞るとき、落とし穴になるのがキャッシュです。権限の強い人向けのツール一覧を共有キャッシュへ入れると、別の利用者に「見えてはいけない道具」が見える可能性があります。2026年7月28日版のMCP仕様は、ツール一覧を接続ではなくリクエストの認可情報で決め、キャッシュ範囲も分離する設計を明記しました。

接続は利用者の境界ではありません

最新版MCPの基本仕様は、プロトコルをステートレスと定義しています。サーバーは同じ接続で届いた過去のリクエストから、クライアントの識別情報や権限を推測してはいけません。必要な情報は各リクエストに含めます。

tools/listについても、返すツール集合を接続ごとに変えたり、同じ接続上の別リクエストの副作用で変えたりしてはいけません。一方で、そのリクエストに提示された認可情報に応じて変えることは認められています。

たとえば、同じMCPサーバーでも次のように返せます。

• 閲覧権限だけのトークン：search_docs、read_ticket
• 更新権限を持つトークン：上記に加えてupdate_ticket
• 管理者トークン：さらにdelete_project

重要なのは「このTCP接続は管理者用だったはず」ではなく、今回のリクエストが何を許可されているかで毎回判定することです。接続プールやプロキシを使う構成では、接続と利用者が一対一とは限りません。

ツール一覧には2種類のキャッシュがあります

2026年7月28日版では、完了したtools/listの結果にttlMsとcacheScopeを付けることが必須です。

• ttlMs：何ミリ秒まで新鮮とみなせるかを示すヒント
• cacheScope: public：利用者をまたいで共有可能
• cacheScope: private：同じ認可コンテキスト内だけで再利用可能

全利用者に同じツールを返すならpublicを選べます。しかし、スコープや役割で一覧を絞るならprivateが基本です。仕様は、別のアクセストークンなど異なる認可コンテキスト間でprivateキャッシュを共有してはならないとしています。

ここで怖いのは、認証済みエンドポイントだから安全だと思い、利用者別の一覧へpublicを付けることです。仕様上、publicな結果は最初の認可コンテキストの外へ共有され得ます。認証の有無と、キャッシュを共有してよい範囲は別問題です。

キャッシュは認可の代わりになりません

ツール一覧から危険な操作を隠すことは、モデルの誤選択を減らすうえで有効です。ただし、一覧に表示しないだけでは認可になりません。攻撃者はtools/callを直接送れます。

MCP仕様も、サーバーは各プリミティブに適切なアクセス制御を実装し、cacheScopeだけで不正アクセスを防いではならないとしています。したがって、サーバー側では最低でも次の二段階が必要です。

1. tools/listで、現在の権限に合うツールだけを返す
2. tools/callでも、対象ツールと引数に対する権限を再検証する

車でいえば、メーター画面から整備モードを隠すのが一覧制御、実際のECUコマンドを拒否するのが認可です。画面を隠しただけで、実行経路まで閉じたことにはなりません。

速さを落とさず安全にする4つの設計

1. キャッシュキーに認可コンテキストを含める

メソッド名とパラメータだけでなく、テナント、利用者、付与スコープ、ポリシーバージョンなど、結果を変える要素を分離します。トークンそのものをログやキー名へ露出させず、安定した内部識別子や安全なハッシュを使うのが実務的です。

2. 権限で変わる結果はprivateにする

迷ったらprivateから始めます。全利用者で同一だと検証できた一覧だけpublicへ昇格させる方が、情報漏えいのリスクを抑えられます。

3. ツール順序を安定させる

仕様は、基礎となる一覧が変わらない限り決定的な順序で返すことを推奨しています。毎回順番が揺れると、LLMへ渡すプロンプトの差分が増え、プロンプトキャッシュのヒット率が下がります。ツール名などで安定ソートすれば、認可分離と効率を両立できます。

4. TTLと変更通知を併用する

TTLは「この時間は絶対に変わらない」という保証ではなく、新鮮さのヒントです。notifications/tools/list_changedを受け取ったら、TTL内でもキャッシュを無効化します。権限変更時にも通知またはポリシーバージョン更新で、古い一覧を残さない設計が必要です。

PL視点では「誰の一覧か」を設計レビューする

レビューで確認すべきなのは、キャッシュを使っているかどうかだけではありません。

• ツール一覧は、どの認可情報で変わるか
• privateキャッシュの「同じ利用者」を何で判定するか
• 権限変更を何秒で反映するか
• 一覧にないツールを直接呼ばれたとき拒否できるか
• ツール順序が毎回変わっていないか

この5点を先に決めると、安全性と応答速度を後付けで争わずに済みます。キャッシュは高速化部品ですが、境界を誤ると権限情報の配布装置になります。

まとめ

MCPのツール一覧は、単なるメニューではありません。利用者が何を実行できるかをモデルへ伝える、認可に近い情報です。ただし、それ自体を認可の代わりにはできません。

• 接続ではなく、各リクエストの認可情報で一覧を決める
• 利用者別の一覧はprivateキャッシュへ分離する
• 実行時にも必ず権限を再検証する
• 安定した順序とTTL・変更通知で効率を保つ

AIエージェントを速くするなら、キャッシュ量より先に「誰と共有してよいか」を設計する。これが、2026年版MCP仕様から読み取れる実装原則です。

公式ソース

• Model Context Protocol — Tools（2026-07-28）
• Model Context Protocol — Caching（2026-07-28）
• Model Context Protocol — Basic protocol / Statelessness（2026-07-28）
• Model Context Protocol — Authorization（2026-07-28）

長時間動くAIエージェントでは、会話やツール実行の履歴が増えるほど、毎回モデルへ渡す文脈も膨らみます。履歴を丸ごと送り続ければ、応答は遅くなり、コストも上がり、やがてコンテキスト上限にぶつかります。

一方、古い履歴を機械的に捨てれば、「誰が何を承認したか」「直前にどのツールを呼んだか」が抜け落ちます。GoogleのAgent Development Kit（ADK）が提供するコンテキスト圧縮から、長時間エージェントの履歴を小さく保ちながら、仕事の連続性を守る設計を考えます。

履歴は「保存」と「モデル投入」を分けて考える

ADKのSessionは、ユーザーの入力、エージェントの応答、ツール操作などを時系列のイベントとして保持します。しかし、保存されている全イベントを、毎回そのままモデルへ投入する必要はありません。

Google公式ドキュメントによると、ADKのContext Compactionは古いセッション履歴を要約し、モデルへ渡す文脈を圧縮します。狙いは、長いセッションでも直近の重要なやり取りを残しつつ、レイテンシーとコストを抑えることです。

ここで大切なのは、圧縮を「ログ削除」と混同しないことです。本稿の設計方針としては、次の3つを別物として扱うと整理しやすくなります。

• 原本：監査や障害解析に使う完全なイベント履歴
• 作業文脈：直近の生イベントと、古い履歴の要約
• 業務状態：承認結果、注文番号、処理段階などの構造化データ

モデルに見せる作業文脈を軽くしても、原本と業務状態まで失う必要はありません。

Google ADKに学ぶ2つの圧縮トリガー

ADK公式ドキュメントは、圧縮の開始条件を2種類に分けています。

1. トークン量で発火する

トークンベース方式は、文脈が設定したトークン数を超えたときに圧縮します。巨大なコードや長いツール出力が突然入るような、負荷を予測しにくい仕事に向いています。

公式ドキュメントでは、トークン方式を主要な安全網として位置づけています。設定例のtoken_threshold=4000は製品の固定値ではなく、説明用のサンプルです。本番値は、利用モデルの上限、通常時の入力サイズ、出力用に確保したい余白から決める必要があります。

2. 会話ターン数で発火する

スライディングウィンドウ方式は、一定回数のやり取りごとに古いイベントを要約します。問い合わせ対応のように、1ターン当たりの情報量が比較的そろう仕事では扱いやすい方式です。

両方を設定した場合、ADKはトークン上限を超えたターンでトークンベースの圧縮を優先します。つまり、ターン数による圧縮を通常時の運用条件とし、トークン量による圧縮を大容量入力への保護条件として設計できます。

圧縮しても連続性を壊さない4つの設計原則

原則1：直近イベントは生のまま残す

要約は便利ですが、固有名詞、数値、否定表現、ツール引数を落とす可能性があります。ADKのevent_retention_sizeは、圧縮後も直近のイベントを未圧縮で残すための設定です。

「さっきの案で進めて」のような指示を理解するには、最後の数往復がそのまま残っている方が安全です。要約だけに置き換えず、古い履歴は要約、直近は原文という二層構造にします。

原則2：圧縮区間を少し重ねる

スライディングウィンドウでは、前回圧縮した末尾を次の圧縮にも含めるoverlap_sizeを設定できます。公式例では、3回ごとに圧縮し、直前の1回を重ねています。境界をまたぐ指示と応答が分断されにくくなる仕組みです。

これにより、圧縮境界の直前に出た指示と、その直後の応答が別々の要約に分断されにくくなります。重複はわずかなコストになりますが、文脈の継ぎ目を保てます。

原則3：重要事項は要約ではなく状態に昇格する

人の承認、支払額、対象ファイル、完了条件などを自然文の要約だけに預けるのは危険です。本稿の提案として、これらはADKのSession State、または必要に応じて業務データベースへ、型を持つ値として保存します。

• approved=true
• approved_by=user_123
• target_file=/reports/q2.pdf
• workflow_step=reviewed

要約は「会話を思い出す」ため、構造化状態は「処理を正しく再開する」ため、と役割を分けます。

原則4：圧縮品質も評価対象にする

圧縮後に答えが自然でも、重要な制約が消えていれば失敗です。テストでは、長い会話を流した後に次を確認します。

• ユーザーが禁止した操作を覚えているか
• 承認済みと未承認を取り違えないか
• ツール呼び出しと結果の対応が崩れていないか
• 数値、単位、対象物が保持されているか
• 圧縮前後でトークン量と応答時間がどう変わったか

圧縮率だけをKPIにすると、短くても役に立たない要約が勝ちます。本稿のQA提案として、保持すべき事実の再現率と、禁止事項の維持率も一緒に測るべきです。

車載開発にたとえると「リングバッファ＋故障記録」

車載システムでも、すべてのCAN通信を制御ロジックへ毎周期入力し続けるわけではありません。直近データはリングバッファで保持し、故障コードや重要イベントは別の不揮発領域へ残し、詳細ログは解析用に保管します。

AIエージェントも同じです。直近の会話は生データ、古い流れは要約、承認や処理結果は構造化状態、完全履歴は監査ログへ分ける。この分離によって、モデルの「作業机」を散らかさず、必要な証拠も失いません。

まとめ

長時間エージェントでは、履歴を増やし続けることも、古い順に捨てることも正解ではありません。Google ADKのコンテキスト圧縮から学べる要点は4つです。

• トークン量を安全網、ターン数を定期清掃として使う
• 古い履歴は要約し、直近イベントは原文で残す
• 承認や業務上の事実は構造化状態へ昇格する
• 圧縮率だけでなく、重要事実と禁止事項の保持を評価する

AIの記憶設計は、「どれだけ覚えるか」ではなく、何を原文で持ち、何を要約し、何を状態として固定するかの設計です。

公式ソース

• Google ADK公式ドキュメント「Context compression」
• Google ADK公式ドキュメント「Session: Tracking individual conversations」
• Google Developers Blog「Announcing ADK for Java 1.0.0」

AIエージェントが扱う対象は、ファイルやAPIだけではなくなりました。Anthropicは2026年8月27日、顕微鏡、液体処理装置、ロボットアームなどをAIから操作する共通仕様「Model Hardware Standard（MHS）」の研究プレビューを発表しました。

注目すべきは、自然言語で機械を動かせることよりも、AIの判断と物理機器の実行の間に何を置くかです。ソフトウェアの失敗は戻せても、物理世界の失敗は簡単には巻き戻せません。

MHSは「機械版MCP」を目指す研究プレビュー

MHSは、機器ごとに異なるプログラム可能なインターフェースを、標準化されたドライバーで扱うための共有仕様です。AnthropicとHHMI Janelia Research Campusの共同プロジェクトとして始まり、現在は科学、ロボティクス、電子機器、製造分野の限られた参加者向けに提供されています。

Anthropicによると、複数機器の統合には通常、数週間から数カ月かかります。MHSはこれを数時間から数分へ短縮します。ただし、2026年8月時点では限定的な研究プレビューで、まだオープンソース公開前です。

MCPがAIとデータ・業務ツールの接続を標準化したのに対し、MHSはAIと物理機器の接続を標準化する構想です。MHS自体もMCP、CLI、コード/APIの3経路から利用できます。

安全をモデルの注意力だけに頼らない4層

公式発表から、実務で重要な境界を4層に整理できます。

1. 共通ドライバー：機器固有の実装を、「read」「write」などの基本操作へ変換します。AIが各機器の細部へ直接入り込む範囲を狭めます。
2. 機器の参照情報：重量、測定可能な項目、調整可能な項目、強制される安全限界などを、自然言語タグから参照ファイルとして提供します。コードだけでは分からない物理的制約を明示します。
3. 実行経路の分離：対話的な操作はMCPやCLI、長時間・高速な処理はコードファイルとして実行します。毎ステップをモデルのオンライン推論に依存させません。
4. ハーネスと専門知：失敗から得た知識を再利用可能なスキルへ落とし込みます。モデルの判断力ではなく、周辺の仕組みで再発防止します。

これは車載制御にたとえると分かりやすいです。AIをECUの出力段へ直結するのではなく、信号定義、上下限、状態遷移、診断、フェイルセーフを間に置く発想です。自然言語は操作の入口にはなっても、安全要求そのものにはなりません。

Genentechの実験が示した「再試行」の危険

Genentechの実証では、Claudeが液体処理装置、ロボットアーム、プレートリーダーを連携させ、タンパク質濃度を測るBCAアッセイを実行しました。水では約140µL/s、粘性のあるBSA溶液では10µL/sという流量を導き、専門家も妥当と確認しています。

一方で、物理世界ならではの弱点も見えました。泡が原因の実行エラーに対し、Claudeは同じウェルでパラメータを変えて再試行し、かえって泡を増やしました。人が「きれいなウェルへ移り、混合回数を減らす」と教えると、その後は文脈を維持でき、学びは再利用可能な液体処理スキルへ組み込まれました。

ここから分かるのは、再試行は安全策ではないということです。ソフトウェアAPIでは有効なリトライも、熱、圧力、衝突、液体、摩耗を伴う装置では損失を拡大しかねません。

製造現場へ入れる前に決める5項目

• ハード上限：速度、温度、圧力、可動域など、AIが変更できない限界を機器側で強制します。
• 操作の危険度：read、可逆なwrite、不可逆なwriteを分け、承認条件を変えます。
• 停止条件：同じ失敗を何回まで許すか、どの異常で即停止するかを先に固定します。
• 状態の観測：命令の送信成功ではなく、センサーで実世界の結果を確認します。
• 技能の変更管理：学習した手順をそのまま共有せず、専門家レビュー、版管理、対象機器の範囲を持たせます。

特に重要なのは、制限をプロンプトだけに書かないことです。プロンプトは判断材料ですが、物理的な上限を保証する安全機構ではありません。

考察：標準化するのは接続だけでは足りない

MHSは、機器接続の個別開発を減らす大きな一歩です。しかし、同じ命令でも機器の状態、材料、周辺環境によって結果は変わります。標準化すべき対象は通信形式だけでなく、能力、制約、状態、失敗履歴、停止方法まで広がります。

AIを物理世界へ出すほど、モデルの賢さより境界の堅さが効きます。正常系のデモより先に、異常時に止まれるか、再開前に誰が確認するかを設計するべきです。

まとめ

• MHSはAIと物理機器をつなぐ共有仕様で、現在は限定的な研究プレビューです。
• 共通ドライバー、機器情報、実行経路、専門知の4層で、モデルと装置の間に境界を置きます。
• 物理世界では、無条件の再試行が被害を広げる場合があります。
• 安全限界、停止条件、観測、変更管理はモデルの外側で強制する必要があります。

「AIが機械を動かせるか」ではなく、「AIが間違えても機械が危険な動きをしないか」。MHSの本当の価値は、この問いを共通仕様として扱い始めた点にあります。

公式ソース

• Anthropic — Previewing the Model Hardware Standard
• Model Hardware Standard — 公式サイト
• Anthropic — Introducing the Model Context Protocol

データ分析AIの精度は、モデルの賢さだけでは決まりません。OpenAIが社内向けデータエージェントを構築した事例では、表のスキーマだけでなく、コード、組織知、記憶、実データまで含む6層の文脈が中核に置かれています。

これは「AIにSQLを書かせる」話ではありません。大量の似たデータから意味を取り違えず、検証可能な答えを出すための設計論です。

600PB・7万データセットで起きる問題

OpenAIの公式記事によると、同社のデータ基盤は3,500人超の社内利用者、600PB超のデータ、7万のデータセットを支えています。この規模では、SQLを書く前に「どの表を使うべきか」を見つけるだけでも大仕事です。

しかも、列名が似ていても意味は同じとは限りません。ログアウト利用者を含むか、更新頻度はどれくらいか、どのフィルターが必須か。こうした差を見落とすと、SQLが正常に動いても結論は間違います。多対多結合、NULLの扱い、フィルター位置など、静かに結果を壊す要因もあります。

つまり本当の課題は、構文生成よりデータの意味を正しく復元することです。

精度を支える6層の文脈

OpenAIの構成は、文脈を大きく次の6層に整理できます。

1. 表の利用情報：スキーマ、データ型、リネージュ、過去のクエリから、表同士の関係や典型的な結合を把握します。
2. 人の注釈：担当者が、列の意図、業務上の意味、既知の注意点を補います。
3. コードによる補強：表を生成するコードを調べ、対象範囲、粒度、更新条件、除外ルールを読み取ります。
4. 組織知：Slack、Google Docs、Notionなどから、指標の正式定義、障害、社内用語を取得します。
5. 記憶：過去の訂正や、推測しにくいフィルター条件を保存し、同じ失敗の再発を防ぎます。
6. 実行時の確認：情報がない、または古い場合は、データウェアハウスへ問い合わせて現状を確かめます。

重要なのは、これらを全部プロンプトへ詰め込まないことです。OpenAIは日次のオフライン処理で情報を正規化し、埋め込みに変換しておきます。実行時はRAG（検索拡張生成）で関連部分だけを取得し、必要ならライブクエリで確認します。

「意味はスキーマではなくコードに宿る」

この事例で特に実務的なのが、公式記事にある「意味はコードに宿る」という教訓です。

スキーマは表の形を示し、過去のSQLは使われ方を示します。しかし、データがどう作られたかは生成コードにあります。たとえば、集計対象の除外条件、更新のタイミング、重複排除の方法は、列名だけでは分かりません。

車載開発にたとえるなら、信号名一覧だけを見てもECUの振る舞いは説明できないのと同じです。仕様、生成ロジック、変更履歴までそろって、初めて意味が固定されます。

権限と評価を文脈の外に置かない

文脈を豊かにすると、同時に漏えいリスクも増えます。OpenAIのエージェントは既存のアクセス制御を引き継ぎ、利用者が元から閲覧できる表だけを問い合わせる「パススルー」方式です。文書の検索でも、メタデータと権限を扱う仕組みが実行時の取得を制御します。

品質評価では、重要な質問と人が作成した正解SQLを組にし、生成SQLの文字列だけでなく、実行結果も比較します。書き方が違っても結果が正しいSQLを落とさないためです。これはデータエージェント版の回帰テストです。

なお、公式ドキュメントでは従来のEvalsプラットフォームは2026年10月31日に読み取り専用化、11月30日に終了予定とされています。新規設計では特定サービス名に固定せず、代表質問・正解結果・継続実行という評価資産を移植可能に保つのが安全です。

導入時に先に作るべき4つ

• 意味の台帳：主要指標、利用禁止の表、必須フィルターを管理します。
• 権限付き検索：検索結果にも元データと同じ認可を適用します。
• 訂正可能な記憶：誰が保存し、誰が編集でき、どの範囲で共有するかを決めます。
• 結果ベースの回帰テスト：SQLの見た目ではなく、期待結果と業務上の意味を検証します。

モデル選定はその後でも遅くありません。先に文脈と評価の配線を作れば、モデルを更新しても知識と品質基準を引き継げます。

まとめ

データエージェントの信頼性は、プロンプトの巧さより意味を何層で支えるかで決まります。

• スキーマだけでなく、コードと人の知識を使う
• 記憶は保存するだけでなく、範囲と編集権限を設計する
• 古い文脈は実データで確かめる
• 生成物ではなく実行結果を継続評価する

AIにデータを渡す前に、データの意味を説明できる仕組みを作る。遠回りに見えますが、これが分析AIをPoCで終わらせない最短ルートです。

公式ソース

• OpenAI — Inside OpenAI’s in-house data agent
• OpenAI API Docs — Working with evals
• OpenAI API Docs — Vector embeddings