Human Gate: Gateway境界におけるMCP Tool Approvalの設計

MCPは、クライアントとサーバーがツールを検出して呼び出すための標準的な方法を提供します。MCPは、単一の承認UIや単一のhuman-in-the-loop（人間の関与）ワークフローを意図的に標準化してはいません。2026-07-28 Tools仕様では、実装がそのインタラクションモデルを自由に選択できると記載されており、同時にアプリケーションは人間がツールの呼び出しを拒否できるようにしておくことを推奨しています。TrueFoundryのMCP Tool Approvalsはその実装空間に位置しています。Gatewayは一致するtools/callを留保し、承認リクエストを作成し、承認者に通知し、TrueFoundry固有の承認メタデータを含む成功結果を返します。これにより、互換性のある呼び出し元は承認待ちとツール実行失敗を区別できるようになります。エンジニアリング上の価値は、MCPが承認を標準化したこと（標準化されていません）ではなく、一時的な人間の決定を恒久的な認可ポリシーに変えることなく、共通のツール境界で承認を強制し、アイデンティティとツールにスコープを設定し、実行パスと相関付けられる点にあります。

1. プロトコル境界から始める

最も重要な区別は、MCPが標準化するものとGatewayが実装するものの間にあります。MCPは、ツールの検出、呼び出し、スキーマ、結果、および2026-07-28改訂版におけるツールワークフローが追加入力を要求するためのより豊かな方法を標準化しています。仕様のユーザーインタラクションガイドラインは意図的に緩やかになっています。アプリケーションはツールの公開と呼び出しを可視化し、人間が操作を拒否できるようにすべきですが、プロトコルは特定の確認インターフェースや承認ライフサイクルを義務付けていません。これにより、ポリシーオブジェクトがMCP自体の一部であるかのように装うことなく、 Gatewayが組織全体のポリシーを課す余地が残されています。

TrueFoundryのドキュメント化されたフローは、6つのステップとして解釈できます。tools/callがMCP Gatewayに到達し、承認ポリシーに一致します。Gatewayはダウンストリームツールを呼び出す代わりに呼び出しを留保します。Gatewayは保留中の承認リクエストを作成または再利用し、設定された承認者パスに通知します。呼び出し元は_meta.approval_statusで実行が保留中であることを伝える成功結果を受け取ります。人間が承認または拒否します。承認されると、Gatewayは設定された有効性に従って実行を解放します。同じ保留中のリクエスター/ツールコンテキストに対する繰り返しの呼び出しは、毎回新しい承認通知を生成するのではなく、保留中のリクエストを再利用できます。

一時停止は実装レベルの状態であり、プロトコルエラーではありません。 メタデータを理解するオーケストレーターは、ツールが利用不可として扱うのではなく「承認待ち」で分岐できるため、これは優れたクライアント契約です。ただし、負担は明示的です。TrueFoundryメタデータを理解しないクライアントが正しく待機することは保証されません。2026-07-28 MCP仕様では、マルチラウンドトリップリクエストのためのinput_required結果も定義され、長時間実行されるTasksは拡張機能に移行しました。これらは異なるワイヤーセマンティクスを持つ標準化されたMCPメカニズムです。したがって、承認ゲートは、Gatewayによって挿入されたMCP Taskとしてではなく、ますます中断可能になるMCPの世界と互換性があるものとして記述されるべきです。

監査のリンケージは相関であり、魔法ではありません。 ドキュメント化された結果メタデータは、呼び出しを承認ワークフローと相関付けるために使用できる承認ステータスとリクエスト識別子を実行パスに与えます。これらのフィールドが承認記録またはトレースに個別に存在しない限り、すべてのツール結果ペイロード自体に承認者のアイデンティティ、決定のタイムスタンプ、理由、または有効期間が含まれていると推論しないでください。「承認決定と相関可能」が主張可能な特性であり、「自律完結型コンプライアンス記録」ではありません。

2. セキュリティセマンティクスはスコープ内に存在する

承認機能は、万能な安全性レイヤーとしてではなく、狭い認可チェックポイントとして扱うと最も論理的に理解しやすくなります。4つのプロパティが重要です。

第一に、有効性が「承認済み」の意味を変えます。 1回限りの実行有効性では、承認は保留中の実行とhuman in the loopの決定に緊密に結びつけられます。時間ベースの付与では、人間の決定により、期間が満了するまで同じリクエスター + MCP server + ツールツプルの以降の呼び出しに対する一時的な権限が作成されます。これは、繰り返しの確認が判断を追加しない場合に便利ですが、以降の引数セットが新しい人間のレビューなしで実行される可能性があることも意味します。アクションが引数に依存するか、取り返しがつかないものであるほど、1回限りの実行承認または追加の引数レベルのポリシーを採用する理由が強くなります。

第二に、リクエスターのスコープ設定により承認の転送が防止されます。 あるアイデンティティに付与された承認は、両方のエージェントが同じサーバーとツールにアクセスするという理由だけで、別のアイデンティティを暗黙的に認可すべきではありません。これにより、解決されたリクエスターアイデンティティが、単なる監査ラベルではなく、セキュリティ境界の一部となります。

第三に、拒否は意図的に短期的となっています。 拒否は、保留中のリクエストに対して「今は不可」と回答します。あるアイデンティティがツールを呼び出すべきでない場合、恒久的な回答はサーバーアクセス、ツールの公開設定、または別の常設ポリシーレイヤーに属します。これらの概念を分離しておくことで、単発の承認決定のキューが偶発的な認可データベースになるのを防ぎます。

第四に、ポリシーの優先順位には正確な言語が必要です。 マッチングスコープと付与の有効期間は異なる問題です。より具体的な承認構成によってどのツールポリシーが適用されるかが決定され、有効性は該当する場合、より制限的な有効期間に向けて解決されるべきです。どの次元が解決されているかを言うことなく、両方の考え方を「最も制限の厳しいポリシーが優先される」というスローガンに圧縮しないでください。

3. 承認疲労は運用上の障害モードである

人間による承認は、人間の決定に静的ポリシーが含まない情報が含まれている場合にのみ、安全性を追加します。回答が実質的にあらかじめ決まっている場合、ゲートは判断ではなく、レイテンシと監査イベントになります。したがって、設計目標は「より多く承認すること」ではなく、残余のコンテキストに依存する決定を人に送り、それ以外はすべてポリシーとしてエンコードすることです。

まず、破壊的な変更、本番環境の変更、外部通信、高コストな操作、またはコンテキストによって回答が変わり得るその他の呼び出しなど、影響の大きい少数のアクションクラスにゲートを設定することから始めます。リクエストは広範な関係者ではなく、指名された所有者にルーティングします。有効期限ウィンドウは、単一の決定が作成すべき権限の大きさに比例するように保ちます。また、責任ある承認者がいないサーバーは安全性コントロールをボトルネックに変えてしまう可能性があるため、管理者へのフォールバック動作は監視すべき運用上の例外として扱います。

ゲートを測定しますが、運用のために必要なメトリクスと、プロダクトが現在組み込みとしてドキュメント化しているメトリクスを区別してください。有用な承認メトリクスには、作成から決定までのレイテンシ、承認/拒否率、期限切れ後の再リクエスト頻度、1回限りの実行と時間ベースの付与を使用するゲート制限呼び出しの割合、管理者フォールバックを経由してルーティングされた割合などがあります。TrueFoundryのドキュメント化されたMetrics Dashboardは、MCPリクエスト/ツールのスループット、レイテンシ、および失敗を表示します。現在、ファーストクラスの承認レイテンシ、承認率、または更新パターンダッシュボードはドキュメント化されていません。これらの承認固有の測定値が必要な場合は、汎用のMCP Metricsビューに起因させるのではなく、デプロイメントで利用可能な承認記録またはエクスポートされたイベントから導出してください。

ゲートの監査。 ゲート制限されたすべてのツールについて、7つの質問に答えてください。なぜ静的ポリシーではなく人間が必要なのか？ 有効性は1回限りの実行か、時間ベースか？ 時間ベースの場合、再承認なしでどのような以降の引数変更が発生する可能性があるか？ 解決されたどのアイデンティティが付与を所有しているか？ 指名された承認者は誰で、フォールバックは何か？ 呼び出し元のクライアントは保留中結果の規約を明示的に認識して再試行できるか？ また、ゲート設定がdestructiveHintなどのMCPアノテーションに依存している場合、サーバーは信頼されているか、あるいは組織が独自にツールを分類しているか？ 次に、承認リクエストIDが対応するツール実行および決定記録と相関付けられることを確認します。目的は、大量の「承認済み」イベントではなく、実際の決定の証跡を得ることです。

4. ゲートの配置場所と、それが代替しないもの

本番ツールのパスには、異なる役割を持つ複数のコントロールが必要です。レジストリまたはアドミッションプロセスにより、どのサーバーとツールが環境内で許可されるかが決定されます。認証により呼び出し元が解決されます。アクセス制御により、その呼び出し元が到達できるツールが決定されます。ツール実行前のガードレールは呼び出しを検査または変換します。Tool Approvalは、人間の決定のために許可された呼び出しを留保できます。Gatewayはその留保を強制します。ダウンストリームのMCP serverはサイドエフェクトを実行します。ツール実行後のガードレールは結果を検査します。トレースと承認記録は証拠チェーンを提供します。

これにより、Agent Harness human-in-the-loopとの関係も明確になります。Harnessは、機密性の高いツール呼び出しの前に管理対象エージェントを一時停止し、tool.approval_requiredを発行し、現在のターンを終了し、UserToolApprovalEventが到着したときに同じセッションを再開できます。Gateway Tool Approvalsは、共通のMCP境界でポリシーを強制します。両方ともツール実行をゲート制限できます。ライフサイクルと配置場所が異なるのであり、一方が汎用的な「推論チェックポイント」で、他方が唯一のツールゲートであるというわけではありません。

明確に述べる価値のある限界もあります。承認は認可に取って代わるものではありません。汚染されたツール説明や改ざんされた引数によって人間が騙される可能性は依然として存在するため、アドミッション審査と引数レベルのコントロールは引き続き必要です。ツールアノテーションは、単にMCP経由で届いたという理由だけで信頼できるわけではありません。時間ベースの付与は、繰り返しのレビューと引き換えに限られた利便性を意図的に選択しています。人間の可用性はレイテンシを追加し、信頼性の依存関係になる可能性があります。そして、GatewayポリシーはGatewayをバイパスするMCPトラフィックを統制することはできません。

したがって、耐久性のあるアーキテクチャ上の主張は、「一時停止がファーストクラスのプロトコルの構成要素になった」というよりも限定的であり、正確であるからこそ強力です。MCPはツール呼び出し基盤を標準化し、より豊かな中断可能ワークフローをサポートするようになりました。エンタープライズの承認セマンティクスは依然として実装とポリシーの選択肢です。共有Gatewayを使用することで、その選択を中央で強制可能、アイデンティティスコープ限定、時間制限付き、かつ監査可能にすることができます。

参考文献

• 一次MCP情報源 — MCP 2026-07-28 Tools仕様（ユーザーインタラクションモデル、input_required結果、ツールアノテーション）、MCP 2026-07-28仕様リリース（Tasks拡張機能および改訂の概要）。
• TrueFoundryドキュメント — MCP Tool Approvals、MCP Gateway、Agent Harness human-in-the-loop、役割とコラボレーター、MCPツール実行前後ガードレール、Metrics Dashboard。
• 関連するTrueFoundryエンジニアリングコンテキスト — MCPレジストリ、ツールポイズニング防御、タスクベースアクセス制御、認可の伝播、ガバナンスと監査。

この記事におけるプロダクトの仕組みは、現在のTrueFoundryドキュメントに基づいて記述されています。プロトコルに関する主張は、MCP 2026-07-28仕様および公式リリース資料に基づいています。TrueFoundryの保留中結果および承認付与セマンティクスはプロダクトレベルの規約であり、MCP標準の承認状態ではありません。上記で提案された承認固有の運用メトリクスは推奨される測定項目であり、現在のMetrics Dashboardが専用の承認チャートを提供していることを主張するものではありません。プロダクトの動作とドキュメントは変更される可能性があるため、フィールド名やポリシーセマンティクスを互換性契約として扱う前に、現在のドキュメントを確認してください。

‍