MCPツール承認の仕組み：保留中の呼び出しから人間による最終判断まで

「ヒューマン・イン・ザ・ループ（人間による介在）」のゲートは、提案内容、承認内容、承認の有効期間、そして実際に実行された内容がシステムによって保持されている場合にのみ有効です。

承認とはモーダルダイアログではなく、状態遷移である

人間による承認は、エージェントとツールの間にある「ひし形」の図として描かれることがよくあります。しかし、その図では重要な部分が省略されています。具体的にどの操作が待機中なのか？ どの担当者が決定権を持っているのか？ 承認は1回の呼び出しを対象とするのか、それとも将来の一定期間を対象とするのか？ 引数やビジネスの状態が変化した場合はどうなるのか？ 呼び出し元は「保留中」と「ツール実行成功」をどのように区別するのか？

本番環境における承認メカニズムは、提案を保持し、副作用が発生する前に実行を一時停止し、決定記録を作成し、結果として得られる許可のスコープと有効期間を定義し、エージェントやアプリケーションが安全に継続できるよう十分な状態を公開しなければなりません。また、承認は認可とは切り離されている必要があります。人間がリスク判断を承認したとしても、そのアクションを実行してよいかどうかは、下流のシステムが認証済みの主体に基づいて判断すべきだからです。

ツールは実行ゲートの先に配置されているため、保留中のリクエストやレビュー担当者への通知が副作用と誤認されることはありません。期限切れや拒否が発生した場合、システムは将来のアクセスを暗黙的に許可するのではなく、非実行状態に戻ります。

TrueFoundryのMCP承認ポリシーの仕組み

TrueFoundryは、MCPゲートウェイを経由するMCPツール呼び出しの承認ポリシーを文書化しています。ポリシーはサーバーとツールのスコープに一致します。ゲートで保護されたツール呼び出しが到着すると、ゲートウェイは同じツールとリクエスターに対する保留中のリクエストを作成（または再利用）し、ツールを実行せずに指定された承認者に通知します。呼び出し元には、承認が保留中であることを示すメタデータを含むJSON-RPC結果が返されます。

承認者はリクエストを許可または拒否でき、必要に応じて理由を添えることができます。許可されると、そのリクエスターからそのサーバーおよびツールへの呼び出しは、設定された有効期間内であれば実行可能になります。ツールの実行結果には承認メタデータが含まれます。許可の有効期限が切れると、次の呼び出しで新しいリクエストが作成されます。拒否はリクエストに対して記録されますが、永続的なアクセス禁止を意味するものではありません。後の呼び出しで再度承認リクエストを発生させることは可能です。

この最後の挙動は誤解されやすい点です。承認ポリシーは、通常アクセス可能なツールに対して、その時点で人間の同意が必要かどうかを判断するものです。永続的な拒否はアクセス制御の役割であり、リクエスターのアクセス権を削除するか、ツールを無効化すべきです。繰り返し拒否を行うことを非公式な認可ポリシーとして利用すると、レビュー担当者に負担をかけ、ノイズの多い証跡を生むことになります。

スコープと有効期間は異なる次元である

ポリシーは、特定のツール、MCPサーバーによって破壊的とマークされたツール、またはサーバー上のすべてのツールを対象にできます。スコープが重複する場合、文書化された優先順位に従い、より具体的な一致（名前指定 > 破壊的 > すべて）が優先されます。有効期間は、1回の実行に基づく回数指定か、設定された分数に基づく時間指定が可能です。複数のポリシーが適用される場合、最も制限の厳しい有効期間が適用されます。

結果として得られる許可は、リクエスター、特定のMCPサーバー、およびツールに限定されます。ユーザー間で共有されることはありません。保留中のリクエストビューにはツールの引数が含まれており、レビュー担当者に有用なコンテキストを提供します。ただし、公開されているドキュメントには、この許可が重要な引数やビジネス状態のバージョンのダイジェストを暗号学的にバインドしているとは記載されていません。影響の大きいアプリケーションでは、独自にそのバインディングを追加する必要があります。

例えば、返金ツールの承認は、必ずしも有効期間中に渡されるすべての返金額、注文、宛先、または理由に対する承認を意味するわけではありません。これらのフィールドがリスク判断に影響を与える場合、アプリケーション側でレビュー担当者の決定をそれらの値にバインドし、重要な変更があった場合には改めて承認を求めるべきです。

このリンクされたチェーンは、文書化されたゲートウェイの許可（リクエスター、サーバー、ツール、有効期間）と、推奨されるアプリケーション側のバインディングを分離しています。金額、受取人、リソースのバージョン、操作の識別子などは、リスク判断に重大な変更をもたらす場合に、個別の強制適用が必要となります。

承認エンベロープの設計

「保留」は失敗ではなく、成功でもない

承認が保留中の間、MCP Gatewayは、呼び出し元に対して待機を指示するテキストコンテンツを含み、isErrorがfalseに設定され、承認メタデータが保留に設定された、成功を示すJSON-RPCエンベロープを返します。このトランスポートレベルでの成功は、ゲートウェイがリクエストを処理したことを意味するものであり、ツールが実行されたことを意味するものではありません。

クライアントは承認メタデータを精査し、保留を独立した状態として扱う必要があります。トランスポートエラーのみを確認していると、モデルに対してツールが成功したと誤認させたり、待機メッセージを通常のツール出力としてフィードバックしたりする可能性があります。同じリクエスト元から同じツールへの繰り返し呼び出しは、保留中のリクエストを再利用するため通知のスパムを減らすことができますが、呼び出し元はリクエストを繰り返すのではなく、決定を待機するバックオフ戦略をとるべきです。

承認後、結果は承認済みメタデータと共に渡されます。アプリケーションは、その結果を元の提案および後続の操作と関連付ける必要があります。承認の証拠は「この人間の決定は、このゲートウェイポリシーの下で記録されたか？」という問いに答え、記録システムは「どのような影響が確定したか？」という問いに答えます。

ゲートウェイの承認とTrueForgeのチェックポイントは関連していますが、同一ではありません

TrueForgeは、承認が必要なツールに対してエージェントのターン一時停止もサポートしています。一時停止されたターンは「承認が必要」というイベントを発行し、必要なアクションを完了させます。クライアントは元のツール呼び出しを特定し、レビュアーの決定を収集し、許可または拒否のレスポンスを含む新しいターンを作成します。

これはTrueForgeセッション内のオーケストレーションチェックポイントです。MCP Gatewayの承認は、どの互換クライアントが呼び出したかに関係なく、ルーティングされたMCP呼び出しに適用されるゲートウェイポリシーです。組織はどちらか一方、または両方を使用できます。両方で同じ操作を制限する場合は、レビュアーが価値のない重複した承認を行わないよう、意図した順序とユーザーエクスペリエンスを定義してください。

一般的なパターンとして、タスク固有の対話（エージェントが提案されたアクションに対して確認を必要とする場合）にはTrueForgeチェックポイントを使用し、機密性の高いツールに関する共有ポリシーにはMCP Gatewayの承認を使用します。アプリケーションは、変更の直前にビジネス上の承認と状態の検証を依然として実行します。

このシーケンスは4つの主張を維持します。ハーネスがタスクのチェックポイントを記録し、ゲートウェイが承認の付与を記録し、アプリケーションが現在のビジネス状態を承認し、権威あるシステムが何が確定したかを記録します。

実例：本番データベースの変更

エージェントが「破壊的」とマークされたツールを使用して移行を提案します。ゲートウェイポリシーが破壊的スコープと一致し、保留中のリクエストを作成します。レビュアーはツール、リクエスト元、引数、ポリシー、および要求された有効性を確認し、1回の実行を許可します。

データベースサービスが移行を実行する前に、認証された主体とエージェントがターゲット環境に対して許可されていることを検証し、移行のダイジェストがレビューされた提案と一致することを確認し、スキーマバージョンが変更されていないことを確認し、操作IDを記録します。重要な入力が少しでも異なれば、アクションはレビューに戻されます。実行がタイムアウトした場合は、サービスは再試行の前に移行記録を照会します。

ゲートウェイの回数ベースの有効性は、付与された権限が恒久的な許可になることを防ぎます。引数のダイジェストと状態チェックは、有効な許可が別の操作を承認することを防ぎます。データベースは、移行が確定したかどうかについて権威ある存在であり続けます。各レイヤーは限定的な主張を行い、次のレイヤーのために証拠を残します。

レビューの人間工学は安全の一部である

技術的に正しいゲートであっても、レビュアーがコンテキストを欠いていたり、価値の低いリクエストを大量に受け取ったりすると失敗する可能性があります。レビュー画面では、リスクを左右する項目（アクター、ターゲット、アクション、差分、金額、宛先、データ分類、現在の状態、可逆性、期待される結果）を強調すべきです。生成された文章で要約することは可能ですが、重要な項目は型定義された記録から取得する必要があります。

リクエストは、リソースを理解している承認者にルーティングし、汎用的なキューに流さないようにします。タイムアウトとエスカレーションパスを設定してください。承認のレイテンシ、拒否率、放棄率、繰り返しリクエスト、承認後の失敗、および取り消しを測定します。拒否率の低下は、提案の改善を示している場合もあれば、単なる形式的な承認（ラバースタンプ）を示している場合もあるため、ワークフローの指標とサンプリングによる決定の質を組み合わせて評価してください。

承認システムの障害テスト

• 承認後に重要な引数を変更し、アプリケーションが再承認または新規承認を要求することを確認する。
• 他のリクエスターの許可（グラント）を消費しようと試みる。
• 名前付きポリシー、破壊的ポリシー、全ツールポリシーを同時に適用し、特異性と制限の妥当性を検証する。
• リクエストを拒否した後に再度呼び出しを行い、新しい保留中のリクエストが永続的な拒否としてではなく、正しく認識されることを確認する。
• リクエストの保留中にツールへのアクセス権を削除し、承認によって取り消された権限が復元されないことを確認する。
• 保留中のJSON-RPC結果を複数のクライアントに返し、いずれのクライアントもトランスポートの成功をツールの実行と誤認しないことを確認する。
• ダウンストリームのコミット後にタイムアウトを発生させ、操作の調整によって重複が防止されることを確認する。

許可の消費とエスカレーションの定義

回数ベースの「1回限り」の許可は単純に聞こえますが、本番システムでは何を消費とみなすかを定義する必要があります。最も安全な解釈は、承認された操作が1回実行されたことを指すことであり、同じツールに到達した次の構文的に有効な呼び出しを指すことではありません。そうしなければ、同時呼び出し、自動リトライ、並列エージェントスレッドが競合して許可を消費してしまう可能性があります。

時間ベースの許可には、時計以外のガード条件が必要です。リクエスターがアクセス権を失った場合、ツールが無効化された場合、ポリシーが変更された場合、ターゲットがリスクしきい値を超えた場合、あるいはリソースの状態が大きく変化した場合には、ゲートウェイの有効期間内であっても、アプリケーションは以前の決定を無効とみなすべきです。ゲートウェイへのアクセスとビジネス上の承認は、実行時に再評価されるべきです。

エスカレーションも明示的であるべきです。期限までに決定が下されないリクエストは、期限切れにするか、別の有資格のレビュアーにルーティングするか、タスクを一時停止状態にする必要があります。エージェントが待機しているからといって、デフォルトで承認されるべきではありません。緊急時のパスでは、決定記録を完全にバイパスするのではなく、より限定的な機能、より短い有効期間、より強力な証拠、および事後レビューを使用すべきです。

最後に、ポリシーの調整とレビュアーのパフォーマンスを切り離してください。承認数が多いということは、ツールが広範すぎる、しきい値が低すぎる、あるいはワークフローが不適切な決定を委任している可能性があることを示しています。恒久的な解決策は、単にレビュアーを増やすことではなく、より安全なツール契約や適切な承認プロセスを構築することです。

どのルールがリクエストを作成し、どのルールが実行を許可したかを記録してください。両方のバージョンがなければ、調査担当者は結果の原因が人間の判断にあるのか、ポリシー設定にあるのか、あるいはその後のアプリケーションの状態にあるのかを特定できません。

運用ルール

「Human-in-the-loop（人間が介在するプロセス）」とは、単に「人が承認ボタンを押した」以上の意味を持つべきです。防御可能なメカニズムとは、保留中の操作、レビュアー、決定内容、ポリシー、スコープ、有効性、実行の試行、およびコミットされた結果を特定するものです。また、プラットフォームが強制する部分と、アプリケーション側が管理する部分を明確にする必要があります。

TrueFoundry MCP Gatewayは、ルーティングされたツールに対して共通の承認インターフェースを提供し、TrueForgeは特定の提案に基づいてエージェントのワークフローを一時停止および再開できます。これらを組み合わせることで、決定の透明性を確保できます。これらは承認をビジネス上の権限付与や「Exactly-once（厳密に1回）」の実行に変換するものではありません。その点を明確にすることが、アーキテクチャをより強固なものにします。

参考文献

1. TrueFoundry — MCPツール承認。
2. TrueFoundry — MCP Gatewayの概要.
3. TrueForge — エージェントの利用.
4. TrueForge — SDKのコンセプト.

編集上の開示 本記事は、2026年9月17日時点における公開資料に基づき、TrueFoundryのエンジニアリングチームが解釈した内容をまとめたものです。製品の機能については、リンク先のドキュメントに記載されている範囲に準拠します。例示やデフォルト設定はあくまで説明を目的としたものであり、法的助言、監査意見、独立したベンチマーク、あるいはセキュリティ、安全性、コンプライアンスを保証するものではありません。

‍