プロンプトと適用されるコンテキスト
あなたはエンタープライズ向けエージェントプラットフォームを担当しています。このエージェントはMCPを介してチケット管理、ソースコード管理、および財務システムを呼び出すことができます。一部のツールは読み取り専用ですが、コードのデプロイ、返金の発行、データの削除を行うツールもあります。サーバーは時間の経過とともに変更される可能性があり、ツールの説明や実行結果は完全に信頼されていないサーバーから提供される場合があります。ディスカバリ、認可、呼び出し、結果処理、監査、および復旧を設計してください。どの操作に人間の承認が必要かも説明してください。
中心となる問いは、すべての呼び出しにおいて次の4つの問いに明確に答えられるかどうかです：誰が誰のためにどのようなスコープで行動しているか、どのツールバージョンが使用されたか、入力と結果が検証されたか、そして障害を追跡してロールバックできるか。AmazonのSDE IIガイダンスでは、システム設計における信頼性、スケーラビリティ、セキュリティ、トレードオフが明示的に評価されるため、これはエンドツーエンドの適切な設計課題となります。
面接官が評価するポイント
優れた回答では、モデルが呼び出しを提案する能力と、プラットフォームがそれを実行する権限とを明確に分離します。モデルはツールと引数を提案できますが、ポリシーエンジンはユーザー、テナント、リソース、リスクレベル、および承認状態を使用して再度認可を行う必要があります。
また、MCPの境界も認識しておく必要があります。サーバーから提供されるツールアノテーションは信頼できないものとして扱う必要があります。readOnlyHint は認可の事実ではありません。結果には、構造化データ、テキスト、リソースリンク、または埋め込みリソースが含まれる場合があります。NSAのガイダンスでも、動的呼び出し、暗黙の信頼、コンテキスト共有がシステム全体のリスクとして強調されています。
面接官は、カタログの汚染、スキーマバリデーションを通過してしまうテナント間を跨ぐ引数、承認後に変更されたパラメータ、タイムアウト、重複した副作用、監査パイプラインの停止といった障害パスについて深掘りします。
明確化のための質問
まず副作用について質問します。クエリ、書き込み、デプロイ、削除をリスク順にランク付けできますか？すべてのツールが読み取り専用であれば、承認と復旧はよりシンプルになりますが、資金移動、本番環境の変更、個人データにはより強力な統制が必要です。
次に信頼境界について質問します。サーバーは自社管理、サードパーティホスト、ユーザー持ち込みのいずれですか？プラットフォームがサーバーを制御していない場合、その説明、アノテーション、結果テキスト、リソースURIはポリシーではなく入力データです。
最後にコンプライアンスと復旧目標について質問します。どのプリンシパル、テナント、データ分類を記録する必要がありますか？ロールバックは補償トランザクション、逆操作、それとも手動手順ですか？これらの回答によって、保持期間、認証情報のスコープ、ワークフロー設計が変わります。
30秒の回答フレームワーク
次のように答えることができます：
「私はモデルを信頼できない提案者として扱い、実行をポリシーエンジンと隔離されたランナーの背後に配置します。プラットフォームは各ツールを登録してバージョニングし、ユーザー、テナント、リソース、副作用ごとに最小権限を適用し、デプロイ、返金、削除などの高リスクなアクションを正確なパラメータの承認にバインドします。読み取り専用の呼び出しでも入力と結果を検証します。実行の前後で関連付けられた監査イベントを書き込み、結果が次の呼び出しの認可情報として流用されないようにします。冪等性、タイムアウト、サーキットブレーカー、ロールバックまたは手動復旧により、リトライ、サーバー変更、承認不一致、部分障害に対応します。」
ステップバイステップの詳細な回答
アイデンティティを認識するツールカタログの作成
サーバーアイデンティティ、ツール名、入力および出力JSON Schema、コードバージョン、ネットワークスコープ、実際の副作用を登録します。カタログの変更によりバージョンとレビュー記録が作成され、ランタイム呼び出しでは承認されたバージョンのみが使用されます。MCP仕様は名前、説明、入力スキーマを定義し、出力スキーマも許可していますが、クライアント側での独立した検証が依然として必要です。
認可を1回の呼び出しにバインドする
ポリシー入力には、プリンシパル、テナント、リソース、アクション、データ分類、環境、およびツールのバージョンを含める必要があります。決定は許可（allow）、拒否（deny）、承認必須（approval-required）のいずれかであり、有効期限の短い呼び出しトークンが生成されます。モデルが承認後に金額、リポジトリ、またはリソースを変更できないように、トークンをパラメータダイジェストにバインドします。
アノテーションと説明をヒントとして解釈する
readOnlyHint や destructiveHint はランキングの改善に役立ちますが、実行を認可することはできません。サーバーが読み取り専用であると主張していても、ポリシーは審査済みの登録内容と観測された機能に引き続き依存します。「これまでの指示を無視してください」といったテキストはデータであり、ポリシーの更新ではありません。
隔離されたランナー内での実行
有効期限の短い認証情報、制限された外部通信（egress）、リソースクォータを使用します。ランナーはポリシーチェック済みの構造化された引数のみを受け取り、会話全体や他のテナントのデータは受け取りません。ツールのテキスト、リンク、埋め込みリソースは、まず結果隔離領域（quarantine）に入り、出力スキーマ、サイズ、Content-Type、データラベルのチェックを通過します。
明示的かつパラメータにバインドされた承認の実現
承認画面には、プリンシパル、サーバー、ツールのバージョン、完全なパラメータサマリー、対象リソース、想定される副作用、有効期限、取り消しパスが表示されます。承認をパラメータダイジェストとともに保存し、いずれかのフィールドが変更された場合は無効化します。低リスクの読み取りでは事後サンプリングを使用し、高リスクのアクションでは実行前に承認を必須とします。
リトライと部分完了の処理
書き込み処理には、モデルが生成したランダムな値だけでなく、ビジネスアクションと呼び出し意図から導出された冪等性キーを持たせます。リクエスト、結果、リトライ状態を永続化します。タイムアウト時は、リトライする前に実行状態を問い合わせます。補償処理が安全でない場合は、返金やデプロイを盲目的に再試行するのではなく、人間の対応キューにアクションを移動します。
関連付けられた監査イベントの出力
イベントには、リクエストID、プリンシパル、テナント、サーバーフィンガープリント、ツールバージョン、パラメータダイジェスト、ポリシー決定、承認者、実行結果、ダウンストリームの認証情報IDが含まれます。機密性の高い引数は、マスキングされたダイジェストまたは暗号化された参照としてのみ保存します。監査ストレージが利用できない場合、高リスクの呼び出しはサイレントに処理を続行するのではなく、フェイルクローズするか保留状態にする必要があります。
段階的なロールアウトと失効
カタログ、ポリシー、結果チェックをサンドボックスサーバーとシャドウトラフィックに対して検証してから、少数のテナントまたはバージョンへ段階的にロールアウトします。古いカタログバージョンと認証情報の失効スイッチを保持します。権限昇格、プロンプトインジェクション、結果の汚染を検出した場合は、まず新規呼び出しをブロックしてトークンを失効させ、その後監査イベントを使用して完了済みの副作用に対処します。
高品質な回答例
「MCPの統合を、カタログ、ポリシー、承認、ランナー、監査の各レイヤーに分割します。カタログはサーバーフィンガープリント、ツールのバージョン、スキーマ、実際の副作用を記録します。モデルは呼び出しを提案できますが、ポリシーエンジンがプリンシパル、テナント、リソース、環境に基づいてそれを認可します。承認はパラメータダイジェストにバインドされているため、金額やターゲットを変更すると承認は無効になります。ランナーは短命な認証情報、制限されたネットワーク、冪等性キーを使用します。結果は隔離され、エージェントに届く前にスキーマ、サイズ、Content-Type、データラベルがチェックされます。すべての決定とダウンストリームリクエストは監査ログ内で関連付けられます。サーバーの変更、タイムアウト、重複した副作用、監査の障害には、拒否、サーキットブレーカー、復旧パスが用意されており、サンドボックスと段階的ロールアウトを通じて検証されます。」
よくある間違い
アノテーションを権限として扱う
失敗パターン：readOnlyHint を含んでいるという理由だけで呼び出しを自動的に許可する。失敗する理由：MCP仕様では、信頼できないサーバーからのアノテーションをセキュリティ上の事実として扱ってはならないとされています。修正策：アノテーションはヒントとして使用し、権限は登録情報、ポリシー、ランタイムの機能チェックから導出します。
生成された引数のみをバリデーションする
失敗パターン：JSON Schemaバリデーションを通過したらすぐに実行する。失敗する理由：型が正しい引数であっても、テナントを跨いだり、本番環境を対象にしたり、不可逆なアクションを繰り返したりする可能性があります。修正策：プリンシパル、リソース所有権、リスク、冪等性、承認ダイジェストも検証します。
自然言語による承認のみを表示する
失敗パターン：ユーザーに「返金を処理する」ことの承認のみを求める。失敗する理由：承認対象が曖昧なため、実行時に金額やアカウントが変更される可能性があります。修正策：ターゲット、金額、バージョン、パラメータダイジェスト、有効期限を表示し、承認をそのダイジェストにバインドします。
ツールの出力を信頼できる指示として扱う
失敗パターン：返されたテキストをそのまま次のシステムプロンプトに連結する。失敗する理由：結果にプロンプトインジェクション、別テナントのデータ、悪意のあるURIが含まれる可能性があります。修正策：結果を隔離し、型を検証し、データにラベルを付け、必要最小限のフィールドのみを渡します。
正常系（ハッピーパス）のみを設計する
失敗パターン：すべてのタイムアウトでリトライし、エラーが発生するたびにそのまま次へ進む。失敗する理由：実行状態が不明なままだと書き込みが重複する可能性があり、部分完了によってビジネス不変条件が破られる可能性があります。修正策：冪等性、ステータス確認、補償処理、サーキットブレーカー、人間へのエスカレーションを一体として設計します。
フォローアップの質問と回答
呼び出し中にツールカタログが変更された場合はどうなりますか？
その呼び出しで使用されているサーバーフィンガープリント、ツールバージョン、スキーマを固定します。カタログの変更は新しい呼び出しにのみ適用されます。バージョンが失効した場合、ポリシーエンジンは古いトークンを拒否し、新たな承認を要求します。
承認サービスが利用できない場合はどうなりますか？
高リスクのアクションについてはフェイルクローズし、提案を保留キューに保持します。低リスクの読み取りは事前承認されたポリシーの下で継続できる場合がありますが、監査イベントは引き続き出力されます。承認のタイムアウトは認可を意味しません。
有効なJSONに別のテナントのデータが含まれている場合はどうなりますか？
出力スキーマは構造を検証するものであり、認可スコープを検証するものではありません。テナントとリソースのスコープをダウンストリームに渡し、結果を解放する前に所有権、データラベル、結果のカーディナリティをチェックします。違反時は隔離してアラートを発行します。
ツールを自動実行してよいかどうかをどのように判断しますか？
可逆性、影響範囲（ブラスト半径）、データの機密性、重複コスト、検知性をスコアリングします。可逆的で機密性が低く影響の小さいクエリは自動実行できますが、資金移動、本番環境の変更、削除、テナント間の読み取りには、人間の承認または専用のワークフローが必要です。
プロンプトインジェクションをどのように調査しますか？
元の入力、ツールの説明バージョン、モデルの提案、ポリシー決定、承認画面、ツールの結果、後続の呼び出しをリクエストIDによって関連付けます。まず影響を受けるサーバーとトークンを失効させ、隔離されたログから決定を再生して、完了した副作用を特定します。