月: 2026年8月

複数のAIエージェントが協働すると、「前の仕事を少し直して」という依頼が増えます。このとき、完了済みのタスクを再び動かす設計は、一見すると効率的です。しかし、入力・出力・責任の対応関係が曖昧になり、監査や障害解析を難しくします。

A2A Protocol v1.0の公式ドキュメントは、終端状態に達したタスクを再開せず、修正や追加依頼を同じ文脈に属する新しいタスクとして扱う考え方を示しています。これはプロトコルの細部に見えて、AI業務を追跡可能にする重要な設計原則です。

A2AのTaskは「会話」ではなく作業単位です

A2A（Agent2Agent Protocol）は、異なる基盤や組織のAIエージェントが通信・協調するためのオープンなプロトコルです。公式資料では、すぐ終わる応答にはステートレスなMessage、継続的な管理が必要な処理には状態を持つTaskを使うと説明されています。

Taskには識別子と状態があり、処理中だけでなく、追加入力待ちや認証待ちも表現できます。一方、completed、canceled、rejected、failedは終端状態です。公式の「Life of a Task」は、Taskがこれらの状態に達した後は再開できないと明記しています。

なぜ完了済みTaskを再利用しないのか

例えば、エージェントAが「月次レポートを作る」TaskをエージェントBへ依頼し、成果物が完成したとします。その後に「欧州部門を追加して」と頼まれた場合、元のTaskを書き換えると、最初の依頼と最終成果物の対応が崩れます。

A2Aの考え方では、元のTaskは完成時点の記録として固定し、追加依頼には新しいTaskを作ります。関連性は、会話や業務のまとまりを示すcontextIdと、参照元を示すreferenceTaskIdsで表現できます。

• taskId：一つの作業単位を識別する
• contextId：複数のMessageやTaskを同じ文脈にまとめる
• referenceTaskIds：新しい依頼がどの過去Taskを参照するか示す

つまり「履歴を消して上書き」ではなく、「元の結果を残したまま差分の仕事を追加」します。製品開発で、承認済み仕様を直接書き換えず、変更要求を別票で管理するのに近い考え方です。

成果物の最新版はクライアント側で管理します

注意したいのは、Taskを分けるだけでは成果物の版管理が完成しないことです。A2A公式ドキュメントは、派生したArtifact（成果物）のつながりをプロトコル自体では管理せず、どの版を採用するか判断できるクライアント側が履歴を持つべきだと説明しています。

サービス側のエージェントには、更新版でも一貫したArtifact名を使うことが推奨されています。クライアント側では、少なくとも次を保存すると追跡しやすくなります。

• 依頼Taskと生成Artifactの対応
• 参照した元Task・元Artifact
• ユーザーが採用した最新版
• 各Taskの開始時刻、終端状態、承認者

ただし、A2Aを採用すれば自動的に監査要件を満たすわけではありません。保存期間、アクセス制御、個人情報の扱い、承認ルールは、利用組織が別途設計する必要があります。

並列化にも効く「不変なTask」

元のTaskを固定すると、完了した成果物を起点に複数の後続Taskを並行して開始できます。A2A公式ドキュメントも、同じcontextIdの中で別々のTaskを作る並列フォローアップを説明しています。

例えば、出張のフライト予約結果を基に、ホテル手配と現地移動の手配を別Taskとして進められます。片方が失敗しても、もう片方や元の予約記録を巻き戻す必要はありません。依存関係をTask間の参照として扱えるため、再実行の範囲も限定しやすくなります。

実装時の4つの確認点

1. 終端状態のTaskを更新しない：修正依頼は新しいtaskIdで受けます。
2. 会話と作業を分ける：contextIdをTaskの代用にせず、一つの文脈に複数Taskを許します。
3. 参照関係を保存する：referenceTaskIdsとArtifactの採用履歴をクライアント側で記録します。
4. 重複実行を別途防ぐ：Taskの不変性だけに頼らず、依頼受付時の冪等性や業務側の一意キーも設計します。

まとめ

AIエージェント間の仕事を安全に増やすには、会話が続いていることと、同じ作業を続けていることを分けて考える必要があります。A2A v1.0が示すように、完了したTaskは固定し、修正や派生作業は同じ文脈の新しいTaskとして記録します。この小さな境界が、追跡可能性、並列実行、障害からの切り分けを支えます。

AIの回答を「最新版だけ残す」のではなく、「どの依頼から、どの成果物が生まれ、何を採用したか」を残すことが大切です。これは、マルチエージェント時代の運用設計で、モデルの賢さより先に決めておきたい台帳のルールです。

公式ソース

• A2A Protocol — Life of a Task
• A2A Protocol Specification v1.0
• A2A Protocol Ships v1.0
• a2aproject/A2A（公式GitHub）

長時間動くAIエージェントでは、実行コンテナが落ちた瞬間に仕事まで消える設計は危険です。OpenAIが更新したAgents SDKは、サンドボックスを単なる「隔離箱」ではなく、交換可能な計算資源として扱います。重要なのは、エージェントの状態をコンテナの外へ出し、別環境でも再開できる構造です。

サンドボックスと実行状態は別物です

OpenAIの公式発表では、更新版Agents SDKにファイル操作やシェル実行などを扱うハーネスと、ネイティブなサンドボックス実行が追加されました。

ここでいうハーネスは、モデルに作業を進めさせる制御層です。一方のサンドボックスは、コマンドやモデル生成コードを実行する計算環境です。この2つを分けると、認証情報をコード実行環境へ置かずに済み、コンテナを使い捨てやすくなります。

「落ちない」より「落ちても戻れる」

長時間タスクでは、コンテナの期限切れ、障害、再配置を完全には避けられません。OpenAIは、状態を外部化し、スナップショットと再水和（rehydration）によって新しいコンテナへ復元する設計を説明しています。元の環境が失われても、最後のチェックポイントから処理を続けられるという考え方です。

これは車載システムのフェイルオーバーにも似ています。特定のECUが絶対に故障しないことへ賭けるのではなく、必要な状態を保持し、代替系へ引き継げるようにします。AIエージェントでも、コンテナの寿命と仕事の寿命を同じにしないことが要点です。

Manifestは作業場所の契約書です

Agents SDKは、作業環境を記述するManifest抽象化も導入しました。入力ファイルのマウント、出力先、ストレージから持ち込むデータなどを定義し、ローカル試作から本番サンドボックスまで同じ形で扱います。

Manifestを「作業場所の契約書」と考えると分かりやすいです。モデルにホスト固有のパスを覚えさせるのではなく、入力はどこにあり、成果物をどこへ書くかを明示します。OpenAIの発表では、持ち込みのサンドボックスに加え、複数のサンドボックス事業者との組み込み連携も案内されています。

本番レビューで分けたい4項目

• 制御：次に何を実行するか、途中状態をどこへ記録するか
• 計算：コードをどの隔離環境で動かし、いつ破棄するか
• データ：入力、成果物、チェックポイントをどこへ永続化するか
• 秘密情報：モデル生成コードから認証情報へ到達できないか

ただし、SDKを使うだけで安全性や復旧性が自動的に保証されるわけではありません。ネットワーク制御、権限、保存先、復元試験は利用側の設計事項です。特に「スナップショットを取っている」と「実際に復元できる」は別なので、障害注入で確認する必要があります。

まとめ

長時間エージェントの信頼性は、高性能なモデルだけでは決まりません。

• ハーネスと計算環境を分離する
• 状態を使い捨てコンテナの外へ出す
• Manifestで入出力の場所を固定する
• 別コンテナからの再開を実際に試す

コンテナは作業員ではなく、交換できる作業台です。仕事の記憶まで作業台に置きっぱなしにしない設計が、長時間エージェントを実験から運用へ進めます。

公式ソース

• OpenAI: The next evolution of the Agents SDK
• OpenAI Developers: Agents guide

※本記事の設計上の考察は、OpenAI公式発表を基にした筆者の整理です。

AIエージェントがPDFや画像を扱うと、ファイルの保存先までAI基盤に任せたくなります。しかし、ファイルを参照する file_id は、利用者を識別する権限証明ではありません。AnthropicのFiles APIドキュメントは、アップロードしたファイルの共有範囲を「会話」や「利用者」ではなくワークスペースだと明記しています。便利なIDと認可の境界を混同しない設計が必要です。

Files APIで何ができるのか

Files APIは、ファイルを一度アップロードし、返された file_id をMessages APIから繰り返し参照できる仕組みです。毎回同じPDFや画像を再送する必要がなく、コード実行で作った成果物のダウンロードにも使えます。

一方、公式ドキュメントには重要な注意があります。アップロードしたファイルはエンドユーザー、会話、セッション単位ではなく、ワークスペース全体からアクセス可能です。同じワークスペースのAPIキーは、そのワークスペース内のファイルへアクセスできます。

file_idは「ロッカー番号」であって鍵ではない

file_id はファイルを指す識別子です。たとえるならロッカー番号であり、本人確認に使う鍵ではありません。アプリが利用者から受け取った file_id をそのままClaude APIへ渡すと、別の利用者がアップロードしたファイルを参照させる余地が生まれます。

Anthropicも、エンドユーザーなど信頼できない入力元から file_id を受け取らず、利用者とファイルの対応関係をアプリ側のサーバーで管理するよう案内しています。

実装で守る4つの境界

• 所有者を自社DBで管理する：file_id、利用者ID、テナントID、用途、作成日時を対応付けます。
• 参照時に認可する：ログイン中の利用者が、そのファイルを読む権限を持つか毎回確認します。IDが存在するだけでは許可しません。
• file_idをサーバー側参照にする：クライアントから任意のIDを受け付けず、自社DBで認可済みのIDだけをAPIへ渡します。
• 強い分離が必要ならワークスペースを分ける：Anthropicはマルチテナント用途で、テナントごとに別ワークスペースを作る方法を案内しています。APIキーも1つのワークスペースにスコープされます。

ワークスペースは組織あたり標準で最大100個です。テナント数が多い場合は、全顧客を機械的に1対1対応させる前に、データ機密度や契約要件に応じた分離単位を設計し、必要ならアカウント担当へ上限拡張を相談するのが現実的です。

保存期間も別の設計項目

アクセス制御が正しくても、保存方針が自動的に満たされるわけではありません。Files APIはZero Data Retention（ZDR、応答後に入力・出力を保存しない契約）の対象外です。公式ドキュメントでは、状態を保持するファイル系機能はZDRに適さないことが説明されています。

そのため導入時には、誰が読めるかに加えて、何をアップロードしてよいか、いつ削除するか、監査ログをどう残すかを決める必要があります。認可とデータ保持は、似て見えて別のチェック項目です。

なぜ重要か

プロジェクト初期は利用者が少なく、1つのAPIキーと1つのワークスペースでも問題が見えにくいものです。ところが業務展開すると、部署、顧客、機密区分の違いが一気に効いてきます。後から分離しようとすると、ファイル所有者の追跡やAPIキーの移行が大仕事になります。

車両開発でネットワーク境界を後付けしないのと同じで、AIのファイル境界もPoCの段階から決めるべきです。最初に「IDは住所、認可は通行許可」と分けておけば、モデルやAPIが変わっても設計原則は残ります。

まとめ

• file_id はファイル識別子であり、利用者の認可情報ではありません。
• Files APIのファイル共有境界はワークスペースです。
• 所有者管理と参照時認可はアプリ側で実装します。
• 強いテナント分離には別ワークスペースを使い、保存期間は認可と分けて設計します。

AIエージェントにファイルを渡す設計では、アップロード成功より先に「誰のファイルを、誰が、いつまで扱えるか」を決める。それが、PoCを業務システムへ育てるための地味ですが強い土台です。

公式ソース

• Anthropic公式ドキュメント：Files API
• Anthropic公式ドキュメント：Workspaces
• Anthropic公式ドキュメント：API and data retention

AIエージェントを個人が便利に使えても、それだけでは組織の仕事は変わりません。担当者ごとに指示、参照資料、判断基準が違えば、成果も属人化したままです。

OpenAIの「Workspace agents」が興味深いのは、AIを高性能なチャットではなく、チームで共有し、権限を管理し、改善を続ける業務プロセスとして扱っている点です。ここから、組織導入に必要な4つの条件を考えます。

Workspace agentsは「共有できる実行手順」

OpenAIの公式説明では、Workspace agentsは繰り返し業務向けのエージェントを作成し、テストしてから公開し、チームやワークスペースへ共有できます。ChatGPTだけでなくSlackやスケジュールから起動でき、アプリ、カスタムMCP、スキル、ファイルも接続できます。

大事なのは、共有されるのが単なるプロンプトではないことです。指示、利用する道具、参照情報、起動方法、承認条件まで含む「実行可能な標準手順」です。製造現場で言えば、作業標準書に設備の操作権限と検査工程まで組み込んだものに近いでしょう。

条件1：目的と完了条件を固定する

最初に決めるべきは「何でも手伝うAI」ではなく、対象業務と完了条件です。たとえば週次レポートなら、入力データ、集計ルール、出力形式、配布先、例外時の停止条件を明記します。

• 良い定義：毎週金曜に指定データを集計し、差分理由を添えた下書きを作る
• 危うい定義：経営に役立つレポートを作る

曖昧な目的は、利用者ごとの差をエージェント内部へ移すだけです。業務標準化には、開始条件と終了条件の両方が必要です。

条件2：接続権限を仕事の範囲まで絞る

公式ヘルプでは、接続先の認証に利用者本人のアカウントか、エージェント所有の共有アカウントを選べます。共有アカウントには可能ならサービスアカウントを使い、必要最小限の権限に絞ることが推奨されています。

また、Connector Action Constraintsでは、送信先ドメインを限定する、特定のGoogleドキュメントだけを読む、といった制約を追加できます。ただし、この制約はコネクタへ要求できる操作を狭めるもので、返却データそのものをフィルタリングする機能ではありません。

つまり「検索語を制限したから機密情報は返らない」とは限りません。操作権限、参照範囲、出力先を別々に設計する必要があります。

条件3：承認をリスクに応じて配置する

Workspace agentsでは、アプリやコネクタの書き込み操作は既定で実行時に確認を求める設定です。送信、編集、投稿、削除のような操作は、すべて同じ扱いにせず影響度で分けるべきです。

• 自動化しやすい：下書き作成、集計、分類
• 条件付きで自動化：限定フォルダへの保存、社内チケット作成
• 人の承認を残す：外部送信、公開、削除、金額や契約に関わる更新

確認を増やしすぎれば使われず、減らしすぎれば事故が増えます。承認は「AIを信用するか」ではなく、失敗時の影響と復旧可能性で決めるのが実務的です。

条件4：公開後も版と利用状況を管理する

共有エージェントは、公開した瞬間が完成ではありません。公式ヘルプでは、公開前のテストとドラフト調整、過去版の確認と再公開、利用者数や実行回数を確認する分析機能が案内されています。EnterpriseとEdu向けのCompliance Platformでは、監査用のログやメタデータをSIEM、DLP、eDiscoveryへ接続できます。

ここで見るべき指標は実行回数だけではありません。

• 完了率と人への差し戻し率
• 承認後に修正された割合
• 例外処理にかかった時間
• どの版から品質が変わったか

利用増加は成果の証明ではありません。工程能力を見るように、ばらつきと失敗モードを継続的に観測する必要があります。

考察：AI導入の単位は「人」から「工程」へ

個人向けAIは、一人の生産性を上げます。一方、共有エージェントは、複数人が同じ基準で仕事を進める仕組みです。導入対象が「社員にAIを配る」から「一つの工程を定義し直す」へ変わります。

この違いは大きいです。工程として扱えば、責任者、入力、権限、承認、出力、監査、改訂履歴を設計できます。逆に、便利なプロンプト集として配るだけでは、属人化を高速化する可能性があります。

まとめ

Workspace agentsから学べる組織導入の要点は4つです。

1. 目的と完了条件を固定する
2. 接続権限を必要最小限に絞る
3. リスクに応じて承認を配置する
4. 公開後も版、品質、利用状況を管理する

AIエージェントを個人技で終わらせない鍵は、モデル選びより業務設計です。まず一つの繰り返し工程を選び、「誰が使っても同じ境界で動く」状態を作るのが堅実な一歩です。

公式ソース

• OpenAI: Introducing workspace agents in ChatGPT
• OpenAI Help Center: ChatGPT Workspace Agents for Enterprise and Business
• OpenAI Help Center: OpenAI Compliance Platform for Enterprise and Edu Customers

Anthropicは2026年8月、将来のClaudeモデルが生成する文章にテキスト透かしを導入すると発表しました。読者には見えず、追加文字も追加トークンもない一方、専用の鍵を使えば「Claudeが関与した可能性」を確率的に調べられます。

ここで重要なのは、透かしが著者を断定する証明書ではないことです。AI利用を管理する組織ほど、検出結果を単独の判決にせず、複数の証拠を組み合わせる設計が必要です。

文章そのものではなく「単語選択の揺らぎ」に印を残す

言語モデルは、文脈に合う次の単語候補から一つを選びながら文章を作ります。意味や正確さがほぼ同じ候補が複数ある場面では、どれを選ぶかに一定の余地があります。

Anthropicが採用するのは、Google DeepMindが公表したSynthID-Text系の方式です。通常の乱数の代わりに、鍵と直前の単語から決まる規則を使って候補を選びます。文章を読む人には違いが分かりませんが、鍵を持つ検出側は、単語列がその規則とどの程度一致するかを評価できます。

• 隠し文字や識別子を本文へ埋め込みません
• 追加トークンがなく、料金は増えません
• 利用者、組織、会話を特定する情報は含みません
• 意味や正確さを犠牲にしてまで透かしを付けません

いわば、完成した文章にスタンプを押すのではなく、同じ目的地へ向かう複数の自然な道から、鍵に沿って一つを選ぶ仕組みです。

検出できないことを先に理解する

Anthropicの説明では、検出で分かるのは「Claudeが一部を書いた可能性」です。人間が書いたことの証明や、別のAIが書いたかどうかの判定はできません。また、短文は単語選択の回数が少ないため、十分な検出材料が得られません。

制約は用途によっても変わります。

• 校正：元の文章を少し直すだけなら、Claudeが選ぶ単語が少なく、透かしは弱くなります
• 事実文：正解がほぼ一つの箇所では、候補を動かせないため透かしを付けにくくなります
• コード：正確な記述が必要なので、一般文章より透かしが少なくなります
• 編集：軽い修正では残る可能性がありますが、全面的に書き換えれば検出しにくくなります

したがって、「未検出だから人間作」「検出されたから全文AI作」という二択は成立しません。透かしは出自を判断する一つの信号であり、単独の鑑定書ではありません。

組織で使うなら、判定より証拠の束を設計する

EUでは、AI生成コンテンツのマーキング義務が2026年8月2日に適用され、欧州委員会によれば約190組織が透明性に関する行動規範へ署名しました。Anthropicは開始時点で地域を安定して限定する方法がないため、透かしを世界的に適用する方針です。

企業の運用では、検出APIが提供されたとしても、その結果だけで採用、評価、懲戒、著作権判断を自動化すべきではありません。次の4層で扱うのが現実的です。

1. 自己申告：AIを使った工程と範囲を記録します
2. 技術的信号：テキスト透かしの検出確率を保存します
3. 来歴情報：生成履歴、版管理、承認ログを照合します
4. 人の判断：用途、影響、反証可能性を確認して結論を出します

画像などの対応ファイルについて、AnthropicはC2PA準拠のContent Credentialsをメタデータへ付ける方針も示しています。C2PAはデジタルコンテンツの作成元や編集履歴を示す公開技術標準です。文章の確率的な透かしと、ファイルの署名付き来歴は役割が違うため、同じ「AI検出」として混ぜないことも大切です。

PL視点では、誤判定時の制御までが仕様

透かし検出を業務へ組み込むなら、精度だけでなく誤判定の影響を先に決める必要があります。確認画面への注意表示なら許容できても、人事評価や不正認定へ直結させるなら要求水準は一気に上がります。

設計レビューでは、少なくとも「未検出時の扱い」「検出時の再確認」「異議申し立て」「ログの保存期間」を仕様に含めるべきです。センサーを追加しただけでは安全システムにならないのと同じで、信号の意味と故障時の振る舞いまで決めて初めて運用できます。

まとめ

• Claudeのテキスト透かしは、自然な単語選択のパターンから関与の可能性を調べる仕組みです
• 利用者情報は含まず、追加文字・追加トークン・実用上の品質低下もないと説明されています
• 短文、軽い校正、事実文、コードでは検出材料が少なくなります
• 検出結果は証拠の一つとして扱い、ログと人の確認を組み合わせるべきです

AI生成物の透明性は「見破る技術」だけでは完成しません。確率的な信号を、誤判定に耐えられる意思決定プロセスへつなぐことが本当の設計課題です。

出典

• Anthropic公式「How Claude’s text watermark works」
• 欧州委員会公式「Strong backing for the Code of Practice on Transparency of AI-generated Content」
• C2PA公式サイト

AIエージェントが外部サービスを使うとき、APIキーや決済情報をチャット欄に入力させる設計は危険です。MCP（Model Context Protocol）の2025-11-25仕様は、この問題に対して「秘密情報をクライアントへ通さない」という明確な境界を示しました。新しいURL mode elicitationから、便利さと安全性を両立する設計を考えます。

Elicitationは「途中で人に聞く」仕組み

MCPのelicitationは、MCPサーバーが処理の途中でクライアントを介し、ユーザーへ追加情報や操作を求める仕組みです。2025-11-25仕様では、用途を2つのモードに分けています。

• Form mode：名前、メールアドレス、選択肢などを、MCPクライアント内のフォームで受け取る
• URL mode：認証、APIキー登録、決済などを、外部の安全なWebページで行う

重要なのは、単なるUIの違いではないことです。Form modeの入力内容はクライアントを通ります。一方、URL modeでは、URL以外の入力データをクライアントへ渡しません。つまり、情報の機密度に応じて経路そのものを分けています。

秘密情報をチャット経路から外す

MCP仕様は、Form modeでパスワード、APIキー、アクセストークン、決済認証情報を要求してはならず、こうした操作にはURL modeを使うよう定めています。

たとえば、AIエージェントがクラウドストレージへ接続するとします。安全な流れは次のようになります。

1. MCPサーバーが「接続には認証が必要」とクライアントへ通知する
2. クライアントが接続先ドメインと理由をユーザーに表示する
3. ユーザーが同意して、ブラウザで公式の認証ページを開く
4. 認証情報はブラウザからサービス側へ直接送る
5. 完了後、MCPサーバーがクライアントへ完了通知を返す

この構成なら、秘密情報はLLMのコンテキスト、MCPクライアント、中間サーバーを通過しません。「AIに秘密を守らせる」のではなく、「AIが秘密を見られない経路にする」発想です。

「同意」と「完了」を分ける

URL modeでクライアントが返す action: "accept" は、ユーザーがURLを開くことに同意した、という意味です。認証や決済が完了したことまでは保証しません。

外部ページでの操作完了は、任意の notifications/elicitation/complete で通知できます。ただし仕様は、通知が届かない場合に備えて手動の再試行・キャンセル手段も用意することを推奨しています。

ここには実運用で重要な示唆があります。

• 同意済み：外部ページを開くことを許可した
• 処理中：ブラウザ側で操作している
• 完了：サーバーが結果を確認した
• 不明：通知が途切れ、状態を確定できない

この4状態を分けず、「同意＝成功」と扱うと、未完了の処理を成功扱いする不具合につながります。車載開発でいえば、スイッチ入力とアクチュエーター作動完了を同じ信号にしないのと同じです。

実装で押さえる4つの境界

1. データ境界

通常情報はForm mode、秘密情報はURL modeへ分けます。判断基準は「漏れたらアクセス権や取引権限を与えるか」です。該当するならチャット経路へ載せません。

2. 表示境界

クライアントは、どのサーバーが要求しているか、どのドメインを開くか、なぜ必要かを明示します。URLを自動で開くのではなく、ユーザーの同意を挟むことがフィッシング対策になります。

3. 状態境界

各要求には一意の elicitationId を持たせます。完了通知は、要求を開始したクライアントだけへ返し、未知または完了済みのIDは無視します。サーバー側の状態はセッションIDだけに結び付けず、認証済みユーザーの識別情報と安全に関連付ける必要があります。

4. 復旧境界

ブラウザを閉じた、ネットワークが切れた、通知が届かなかった、といった失敗を前提にします。自動再試行だけに頼らず、「もう一度開く」「状態を確認する」「キャンセルする」を用意すると、途中状態から安全に復旧できます。

考察：AIの安全性はモデルの外で作る

秘密情報をプロンプトへ入れた後で、ログに残さない、学習に使わない、画面に再表示しない、と制御を積み重ねる方法もあります。しかし、経路に入った情報は、監視、デバッグ、トレース、プラグイン連携など多くの場所へ波及します。

URL mode elicitationの価値は、モデルを賢くして漏えいを防ぐことではありません。最初から秘密情報をAI経路へ入れず、認証や決済を専用の信頼境界に戻すことです。

PL視点では、これは責任分担の明確化でもあります。AIは「必要な操作を案内する」、クライアントは「接続先と同意を管理する」、サービス側は「秘密情報を受け取り保管する」。役割を分けるほど、異常時にどこを止め、どこを監査すべきかが見えやすくなります。

まとめ

• MCPのelicitationはForm modeとURL modeを用途別に分けます
• パスワード、APIキー、トークン、決済情報はForm modeで要求しません
• URL modeは秘密情報をLLMやMCPクライアントへ通さない設計です
• URLを開く同意と、外部操作の完了は別状態として扱います
• 安全性は「AIに見せて守らせる」より「AIに見せない経路」で高められます

公式ソース

• Model Context Protocol仕様：Elicitation（2025-11-25）
• Model Context Protocol仕様：2025-11-25 Key Changes
• Model Context Protocol仕様：Overview（2025-11-25）

AIエージェントが複数のツールを使うたびに、すべての中間結果をモデルへ戻して「次は何をするか」を考え直させる必要はありません。OpenAIはResponses APIに、モデルがJavaScriptを書いてツール群を制御する「Programmatic Tool Calling」を用意しました。重要なのは新機能そのものより、判断が必要な工程と、コードに任せる工程を分ける設計です。

Programmatic Tool Callingとは

OpenAIの公式ドキュメントによると、Programmatic Tool Callingでは、モデルが生成したJavaScriptがツール呼び出しを調整します。並列実行、ループ、条件分岐が使え、中間結果をホストされた実行環境に保持したまま処理できます。

たとえば100件の商品情報を取得し、条件に合うものだけを重複除去して集計する場合を考えます。従来のように全結果をモデルへ戻すのではなく、コード側で絞り込み、最終判断に必要な小さな構造化データだけを返せます。OpenAIも、これによりツール中心の処理でトークン、モデルとの往復、追加指示を減らせると説明しています。

「コードに任せる範囲」を先に決める

公式ドキュメントが示す使い分けは明快です。

• コード向き：複数結果の絞り込み、結合、順位付け、重複除去、集計、形式検証
• モデル向き：検索結果ごとに意味判断が必要な処理、適応的な探索
• 直接呼び出し向き：書き込み、承認が必要な操作、引用や元の成果物を保持すべき最終確認

在庫確認と需要取得は並列化できますが、発注の実行は別です。「不足数を計算する」まではコードに任せ、「本当に注文するか」は明示的な承認境界に戻すべきです。高速化のために、責任の境界まで自動化してはいけません。

実行環境の制約は安全設計の材料になる

生成プログラムは毎回、新しい隔離済みV8環境で動きます。Node.js、パッケージ追加、直接のネットワークアクセス、汎用ファイルシステム、サブプロセス、永続的なJavaScript状態は提供されません。外部システムへ到達できるのは、リクエストで許可したツール経由だけです。

さらに各ツールのallowed_callersで、モデルからの直接呼び出し、プログラムからの呼び出し、その両方を指定できます。これは単なるAPI設定ではなく、工程ごとに権限を狭める仕組みです。集計用プログラムには読み取りツールだけを渡し、変更系ツールは直接呼び出しと承認に限定する、といった分離ができます。

運用では「停止条件」と「証拠」を仕様にする

プログラムに「効率よく処理して」とだけ伝えるのは危険です。OpenAIは、対象工程、利用可能なツール、返却形式、停止条件、再試行回数、副作用の禁止、失敗時の構造化結果まで具体化する例を示しています。

設計レビューでは、次の4点を先に決めると実装が安定します。

• どの工程までを決定論的なコードにするか
• 最終判断へ残す根拠データは何か
• 何回失敗したら停止するか
• 書き込みや承認をどこで分離するか

GPT-5.6の公式発表では、この機能を使い、ツールの調整、中間結果の処理、進行状況の監視、次の行動選択を軽量なプログラムで行えると説明しています。ただし、コード化できることと、コード化すべきことは同じではありません。

まとめ

エージェント設計の要点は、すべてをAIに考えさせることではありません。予測可能な制御フローはコードへ、意味判断はモデルへ、外部への変更は承認境界へ分けます。賢いモデルを使うだけでなく、「考えなくてよい仕事」を明確にすることが、速さ・コスト・監査性を同時に改善する近道です。

---

公式ソース

• OpenAI API Docs — Programmatic Tool Calling
• OpenAI — GPT-5.6: Frontier intelligence that scales with your ambition

AIエージェントのツールが「検索結果はこれです」と文章を返すだけでは、次の処理で値を取り違えても気づきにくくなります。MCPの2025-11-25仕様には、戻り値の形を宣言するoutputSchemaと、構造化データを返すstructuredContentがあります。これは単なるJSON化ではなく、エージェントの判断を検証可能な契約に変える仕組みです。

文章だけの戻り値は、次工程で曖昧になる

たとえば天気ツールが「気温は22.5度、湿度は65%です」と返した場合、人には読めても、後続処理は数値・単位・項目名を文章から再解釈しなければなりません。表現が少し変わるだけで、抽出ロジックやAIの理解が揺れます。

MCP仕様では、ツール結果は従来のcontentに加えて、JSONオブジェクトをstructuredContentとして返せます。さらにoutputSchemaを定義すると、返却すべき項目・型・必須条件を事前に示せます。サーバーはそのスキーマに適合する結果を返す必要があり、クライアント側にも検証が推奨されています。

outputSchemaがつくる3段階の防波堤

1. ツール側で壊れた出力を止める

気温が数値であるべきところに文字列が入った、必須の湿度が欠けた、といった異常をスキーマ検証で検出できます。AIへ渡してから推測で補わせるのではなく、境界で止める設計です。

2. エージェントの再解釈を減らす

temperature、conditions、humidityのように項目が明示されれば、エージェントは自然文を分解し直す必要がありません。MCP仕様は、出力スキーマが型情報の提供、厳密な検証、クライアントやLLMによる解析の支援につながると説明しています。

3. 後続システムへ安全に渡す

構造が固定されていれば、集計、条件判定、別ツールへの入力を通常のプログラムで扱えます。AIの柔軟さと、決定論的なソフトウェアの厳密さを分担できます。

エラーにも「直せる情報」を返す

MCPはエラーを、リクエスト構造そのものが不正な「プロトコルエラー」と、日付や値の範囲など実行条件に問題がある「ツール実行エラー」に分けています。後者はisError: trueと、修正に使える説明を結果として返せます。クライアントがその情報をモデルへ渡せば、エージェントは引数を直して再試行できます。

「失敗しました」だけでは復旧できません。「出発日は未来の日付で指定してください」のように、次の一手が分かるエラーを返すことが重要です。

大量データは一度に返さない

構造化しても、全件を一度に返せばコンテキストを圧迫します。MCPのページネーション仕様は、一覧を小さなまとまりに分け、nextCursorで続きを取得する方式を定めています。ページサイズはサーバー側が決め、クライアントは固定値を前提にしてはいけません。

実装では、次の順番が堅実です。

• 通常は必要最小限の項目だけ返す
• 一覧はページネーションする
• 詳細は別の取得操作に分ける
• スキーマ検証に失敗した結果はAIへ渡さない

考察：AI時代のAPI契約は「意味」まで含む

従来のAPI設計では、HTTP 200でJSONが返れば成功と見なしがちでした。しかしAIエージェントでは、そのJSONを次の判断材料として使います。項目名が曖昧、型が揺れる、エラーに修正方法がない――こうした小さな不備が、数ステップ後の誤操作へつながります。

車載システムで信号の型・範囲・異常時動作をインターフェースとして決めるのと同じです。モデルの賢さで吸収するのではなく、ツール境界で正常系と異常系を定義する。これが、エージェントを長い工程で安定させる近道だと考えます。

まとめ

• structuredContentで結果を機械処理しやすくする
• outputSchemaで項目・型・必須条件を契約にする
• 修正可能なエラー情報を返し、再試行につなげる
• 大量結果はページネーションし、コンテキストを守る

AIエージェントの信頼性は、モデルだけで決まりません。ツールの戻り値を「読める文章」から「検証できる契約」へ変えることが、地味ですが効く設計改善です。

出典

• Model Context Protocol — Tools（2025-11-25仕様）
• Model Context Protocol — Pagination（2025-11-25仕様）

AIエージェントの確認画面は、安全装置である一方、増えすぎると「全部承認する」作業になります。Anthropicによると、Claude Code利用者は権限確認の93%を承認していました。そこで同社は、人間の確認を単に消すのではなく、別モデルが実行直前の操作を審査する「auto mode」を設計しました。

重要なのは、AIに自由を与えたことではありません。通常作業は流し、被害が起こり得る操作だけを狭い情報で再判定する構造にした点です。

「毎回聞く」と「全部許す」の間を作る

従来の選択肢は極端でした。手動確認は安全性を高めますが、クリックが続けば確認疲れが起きます。一方、権限確認を全面的に迂回する方式は手軽でも、多くの環境で危険です。

auto modeは、操作を3段階で扱います。

• Tier 1：読み取りや検索など、状態を変えない安全なツールは許可
• Tier 2：プロジェクト内のファイル編集は許可。変更はGitで追跡可能
• Tier 3：シェル、外部通信、プロジェクト外の操作などは分類器が審査

すべてを重い審査へ送らず、損失可能性のある操作に審査コストを集中させています。

審査役には「言い訳」を見せない

出力側の分類器が見るのは、主にユーザーのメッセージと実行予定のツール呼び出しです。エージェント自身の説明文とツール出力は除外されます。

これは意図的な設計です。エージェントが「これは安全です」と自分の行動を正当化したり、Webページやファイルに混入したプロンプトインジェクションが審査役まで届いたりする経路を減らします。審査対象を「AIが何と言ったか」ではなく、「ユーザーが何を頼み、AIが何を実行しようとしているか」に絞っています。

入力側では別に、ツール出力を走査するプロンプトインジェクション検知が働きます。つまり、入ってくる情報の検査と出ていく操作の検査を分けた二層構造です。

承認は「目的」ではなく「被害範囲」で読む

分類器は、操作が目的に関連しているだけでは許可しません。たとえば「古いブランチを整理して」は、リモートブランチの一括削除まで明示的に認めたとは限りません。「ジョブを止めて」も、AIが名前の近い対象を推測して削除する根拠にはなりません。

ここでの原則は明快です。

• 対象が特定されているか
• 操作が可逆か
• 共有資源や他人へ影響しないか
• 安全確認の迂回や外部送信を伴わないか

これは車載開発の変更管理にも似ています。「不具合を直す」という目的への合意と、本番ECUへ特定の変更を書き込む承認は別物です。AI運用でも、目的と実行権限を分ける必要があります。

二段階判定は速さと見逃しを交換する

auto modeの分類器は、まず単一トークン出力の高速判定を行い、危険の可能性がある場合だけ推論を伴う第二段階へ進みます。Anthropicの評価では、実トラフィック1万件に対する誤検知率は第一段階の8.5%から、全パイプラインで0.4%まで下がりました。

ただし安全性は完全ではありません。実際の「先回りしすぎた危険操作」52件では、全パイプラインの見逃し率は17%でした。合成した情報流出1,000件でも見逃し率は5.7%です。Anthropic自身も、高リスクなインフラ作業で慎重な人間レビューを置き換えるものではないと説明しています。

この数字は重要です。分類器は「無確認」より安全にする層であり、サンドボックス、明示的な拒否ルール、最小権限、Gitによる復元性を不要にはしません。

実務へ持ち込む4つの設計原則

1. 可逆な操作を先に自動化する：読み取り、検索、作業ブランチ内の編集から始めます。
2. 審査役へ必要最小限だけ渡す：ユーザー指示と実行内容を中心にし、AI自身の説明を判定根拠にしません。
3. 信頼境界を環境ごとに定義する：社内Git、クラウド、外部URLを同じ扱いにしません。
4. 高リスク操作は人間へ戻す：本番デプロイ、強制push、大量削除、機密情報の外部送信は別枠にします。

まとめ

確認回数を減らすだけなら、権限を広げれば済みます。しかし、それでは速さと安全を交換しただけです。

auto modeが示したのは、通常操作を流す許可層、危険操作を狙う分類層、到達範囲を物理的に狭める隔離層を組み合わせる考え方です。AIエージェントの自律性は「確認をなくす」ことでなく、どの操作を、誰が、どの情報で止めるかを設計して初めて実用になります。

---

公式ソース

• Anthropic Engineering: How we built Claude Code auto mode: a safer way to skip permissions（2026年3月25日）
• Claude Code Docs: Choose a permission mode