ツール面積を最小化するMCP設計：誤操作を減らすスコープ/引数/確認ステップ

エンタープライズ領域におけるAIエージェントの導入において、最大の懸念は「予期せぬ挙動」によるデータの破壊や誤送信です。これを防ぐための核となる概念が、Anthropicが提唱するModel Context Protocol (MCP)に基づいた設計思想です。本稿では、システムがLLM（大規模言語モデル）に露出する「操作面積」を最小化し、実務における安全性を極限まで高めるための、スコープ、引数、確認ステップの設計手法を詳説します。

関連記事：高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」ツール選定と公式事例

1. スコープの最適化：ResourceとToolの厳密な分離

MCP設計における「スコープ」とは、AIモデルがアクセス可能な情報の範囲を指します。誤操作を減らす第一歩は、AIに「何でもできる魔法の杖」を持たせないことです。

1-1. 最小権限の原則（PoLP）に基づくアクセス制御

実務では、AIに与える権限を「参照（Resources）」と「実行（Tools）」に明確に分離します。例えば、Salesforceから顧客情報を読み取る権限は与えても、商談フェーズを更新する権限はデフォルトでは無効化すべきです。

• Resources: 読み取り専用のデータソース。APIのGETメソッドのみを許可。
• Tools: データの作成・更新・削除を行う関数。POST/PATCH/DELETEメソッドを伴う。

1-2. 実務における「参照のみ」と「書き込み」の物理的隔離

多くの失敗事例では、一つのAPIキーに全権限を付与してしまいます。これを防ぐため、機能ごとにエンドポイントを細分化します。例えば、経理業務においてfreee会計を利用する場合、決済データの「参照」用スコープと、仕訳の「登録」用スコープを分け、AIが判断に迷うツール面積を物理的に削ぎ落とします。

【公式URL】freee導入事例：株式会社メルカリ

2. 引数（Arguments）設計：入力ミスを構造的に防ぐJSONスキーマ

AIがツールを実行する際、渡される引数（Arguments）が曖昧だと、意図しないデータが生成されます。これを防ぐには、厳格なJSONスキーマ定義が不可欠です。

2-1. enum（列挙型）による選択肢の強制

自由記述の文字列（String）を引数にするのは極めて危険です。可能な限りenumを使用し、AIが選択できる値を制限します。

{
"type": "object",
"properties": {
"status": {
"type": "string",
"enum": ["pending", "active", "closed"],
"description": "商談のステータス。これ以外の値は受け付けません。"
}
},
"required": ["status"]
}

2-2. 動的バリデーションの実装

例えば、SalesforceのAPIを利用する場合、オブジェクト固有のID形式（15文字または18文字）に合致するかを正規表現（pattern）で定義します。これにより、AIが「もっともらしいが無効なID」を生成してAPIエラーを連発させる事態を防げます。

【公式URL】Salesforce導入事例：キヤノンマーケティングジャパン株式会社

関連記事：【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

3. 確認ステップ：人機併存型の「Human-in-the-loop」

ツール面積を最小化しても、AIの最終的な「実行ボタン」を自動化しすぎるのはリスクが残ります。特に重要な操作には、必ず人間による承認（Confirmation Step）を介在させます。

3-1. 破壊的変更に対するダブルチェック

データの削除や、大量の顧客メール送信などの「取り消し不可能なアクション」については、MCPのプロトコル内でneeds_confirmation: trueフラグを立てる設計にします。AIが実行を決定した段階で、チャット画面上に「以下の内容で実行して良いですか？」というプレビューを表示させます。

3-2. 実行前プレビュー機能の実装手順

1. AIが実行したい内容をJSON形式で一時保存。
2. 人間が視覚的に理解できるUI（カード形式等）に変換して表示。
3. 人間が「承認」ボタンを押下したタイミングで、初めて本番APIを叩くトークンを発行する。

関連記事：【完全版・第4回】freee会計の「月次業務」フェーズ。給与連携・月次締めを爆速化し、決算の精度を高める手順

4. 主要SaaSにおけるAPI/MCP設計比較表

実務で頻用されるツールの、AI連携時の特性と制限をまとめました。

5. トラブルシューティング：よくあるエラーと解決策

MCP設計を実務に投入した際、高確率で遭遇する技術的課題とその回避策です。

エラー1：Context Windowのオーバーフロー

原因： AIに渡すResources（ドキュメントやデータ）が多すぎて、モデルの最大トークン数を超過した。

解決策： RAG（検索拡張生成）を併用し、ツール側で「上位3件の関連データのみを返す」といったフィルタリングを実装する。

エラー2：JSONデコードエラー

原因： AIがJSONスキーマに従わない、不完全な形式で引数を出力した。

解決策： Pydanticなどのライブラリを用いて、API実行前に厳格な型チェックを行い、エラー時はAIに対して「スキーマ違反です。再生成してください」とフィードバックするループを組む。

エラー3：レートリミットによる実行中断

原因： AIが短時間に大量のAPIリクエストをツール経由で発行した。

解決策： ツール側のラッパー関数にExponential Backoff（指数関数的バックオフ）を用いたリトライ処理を組み込む。

6. まとめ：堅牢なAI連携基盤の構築に向けて

ツール面積を最小化するMCP設計は、単なる技術的な工夫ではなく、業務の安全性を担保する「ガードレール」です。AIの自律性を重んじつつも、Resource/Toolの分離、JSONスキーマによる引数の縛り、そしてHuman-in-the-loopによる最終確認を組み合わせることで、実務に耐えうるAIエージェントの構築が可能になります。

まずは、現在利用しているSaaSのAPI仕様を確認し、最もリスクの低い「参照系ツール」から小規模に実装を開始することをお勧めします。

📚 関連資料

このトピックについて、より詳しく学びたい方は以下の無料資料をご参照ください：