キャップストーンの成果

本番環境対応のMCP統合とは、単にツールを呼び出せるエージェントではありません。AIエージェントを承認済みのツールやデータに接続し、各リクエストをMCPクライアントを介して仲介し、何が起きたのかをユーザーに信頼性の高い形で説明できるアプリケーションです。このキャップストーンでは、曖昧、安全でない、または完了不可能なリクエストを含む現実的なリクエストを使って、その一連の経路全体を設計・評価します。

各役割を明確に分けてください。ホストは、エージェントの利用体験とMCPクライアントを管理するアプリケーションです。MCPクライアントは、MCPサーバーとの接続を維持します。サーバーは、ツールやリソースなどの機能を公開します。モデルはアクションの選択を支援できますが、ポリシー上の判断、ユーザーとの対話、結果の報告については、引き続きホストが責任を負います。モデルへの指示やツールの説明を、認可の境界として扱ってはいけません。

リクエストと境界を定義する

まず、サポートチケットのトリアージなど、具体的なワークフローを1つ選びます。ユーザーが何を依頼できるか、アプリケーションがアクセスできるデータは何か、外部状態を変更できるアクションはどれかを書き出します。初期の機能セットとしては、読み取り専用のチケット検索と、内部メモの追加など状態を変更するアクションが有用です。エージェントを接続する前に、各アクションについて、許可される入力、期待される結果、認可要件を定義してください。

情報収集と、結果を伴う意思決定を分離してください。アプリケーションは、チケットを取得して変更を加えずに提案メモを作成できます。ただし、ユーザーが対象とする正確なアクションと対象を確認するまでは、メモを追加したりチケットのステータスを変更したりしてはいけません。リクエストでチケットが特定されていない場合や、取得した情報に重大な不確実性が残る場合は、推測せずに確認の質問をしてください。開発と評価にはサンドボックスデータを使用し、デモを現実的に見せるために実際の顧客レコードを使用しないでください。

MCPの経路を構築する

選択したSDKとトランスポートでサポートされているMCPクライアントを使用して、サーバーに接続します。ローカルサーバーでは標準入出力が適切な場合があります。リモートサーバーでは、サポートされているHTTPトランスポートを使用し、そのセキュリティを意図的に設定してください。トランスポート、SDK、サーバーのバージョンを、明示的なプロジェクト依存関係として扱います。起動時に、想定されるサーバーのIDと機能を記録し、必要なツールが存在しない場合や、公開されている入力スキーマがアプリケーションと互換性がない場合は、明確に失敗させてください。

MCPのディスカバリーと呼び出しは、モデルのために考案した名称ではなく、プロトコル操作として扱います。クライアントはtools/listを通じて利用可能なツールを発見し、tools/callを通じて選択したツールを呼び出せます。サーバーはリソースを公開することもでき、クライアントは対応するリソース操作を通じて、それらを発見して読み取れます。このワークフローに必要な機能だけを要求してください。ツールを呼び出す前に、ホストは独自のポリシーを確認し、アプリケーションの想定に照らして引数を検証し、必要に応じて確認を取得する必要があります。呼び出し後は、結果をエージェントに渡したり事実として提示したりする前に、その内容を検証してください。

安全性と信頼性を徹底する

ツールのスキーマと説明は、エージェントが機能を理解するのに役立ちますが、呼び出しが安全であることを証明するものではありません。読み取り専用や破壊的操作に関するヒントなどのアノテーションは有用なメタデータですが、アプリケーションポリシーの代わりにはなりません。サーバーの権限設定とホスト独自の認可チェックを使ってアクセスを制御してください。サーバーには、必要な操作とレコードに限って認証情報を付与し、シークレットはpromptやソース管理の外部に保存し、選択したトランスポートに適したリモート認可メカニズムを使用してください。

モデルが生成した引数とサーバーから返されたコンテンツの両方を、信頼できない入力として扱ってください。識別子、許可されたステータス値、テキストの長さ、関連するユーザー権限を検証します。ツールの出力には、不正確なデータやエージェントを操作する目的の指示が含まれる可能性があります。ツールの出力によってホストポリシーを上書きすることはできません。タイムアウトを設定し、明確な失敗時の処理経路を用意してください。安全に再実行できることが分かっている操作だけをリトライしてください。不確実なタイムアウトの後に状態を変更するリクエストを再試行すると、重複した効果が発生する可能性があるためです。対応している場合は、キャンセルを処理し、クライアントとサーバーの接続を適切に終了してください。

エンドツーエンドで評価する

MCP接続が確立するかどうかだけでなく、ユーザーのワークフロー全体をテストしてください。単純な検索、追加の確認が必要なリクエスト、変更を行うリクエスト、確認を拒否するユーザー、タイムアウトするかエラーを返すサーバーを含めます。また、ツールの出力にアプリケーションポリシーと矛盾する指示が含まれるケースも追加してください。各ケースについて、ユーザーに表示される想定レスポンスと、ツール呼び出しが許可されるかどうかを明確に定義します。

観測可能な動作を測定してください。意図したツールが選択されたか、渡された引数が検証に通ったか、必要な承認が行われたか、最終レスポンスが実際のツール結果と一致しているかを記録します。アプリケーションが安全でない呼び出しを拒否し、失敗を正確に説明できる場合にのみ、テストは合格とします。失敗したリクエストを診断できるだけの詳細をログとトレースに記録しつつ、認証情報はマスキングし、機密性の高いユーザーデータは最小限に抑えてください。小規模なテストスイートで一般的な安全性が証明されたと主張するのではなく、テストカバレッジと既知の制約を報告してください。

リリースとレビュー

リリース前に依存関係を固定し、MCPサーバーとトランスポートの設定を文書化し、必要な設定や機能が利用できない場合にアプリケーションがフェイルクローズすることを確認してください。アクセス制御、認証情報の取り扱い、ネットワークへの公開範囲、タイムアウト、ログの保持期間をレビューします。開発、テスト、本番のサーバー設定は分離してください。ツールのスキーマまたはサーバー実装を変更した場合は、デプロイ前に互換性テストと安全性テストを実行します。

capstoneの成果物は、スクリーンショットの成功ではなく、再現可能なアプリケーションです。セットアップ手順、信頼境界、承認が必要な操作、テスト結果を含めてください。レビュアーがサンドボックスデータに対してアプリケーションを実行し、成功する検索と、拒否または失敗する操作の両方を再現でき、サーバーが確認していない変更を最終メッセージが決して実行済みと主張しないことを検証できるようにします。これらの基準により、統合が理解しやすく、テスト可能で、より安全に運用できるものになります。