「配送先を変更したいです」
問い合わせAIのデモでは、この依頼は簡単に見える。顧客を特定し、注文を検索し、新しい住所を書き込めばよい。しかし本番では、出荷前か、本人確認が済んでいるか、その住所が今回の注文だけに適用されるのか、変更後に何を通知するのかまで決めなければならない。
ここでMCPを導入すると、Knowledge、CRM、Order、Ticketといった複数のシステムを共通の方法でAgentへ公開しやすくなる。だが、接続方式がそろっても、業務上の判断が自動的にそろうわけではない。むしろ、どのToolを見せ、どこまで操作させるかが設計の中心になる。
MCPを接続点として、参照と更新の権限を分けて業務Toolを公開する
MCPが標準化するのは接続であって、業務判断ではない
MCPのToolは、外部システムへの問い合わせやAPI呼び出しなどをモデルから利用可能にする。現在の仕様も、Toolをモデルが発見して呼び出す前提を置きつつ、利用者が公開中のToolを把握できる表示や、操作前の確認を推奨している。つまり、MCP Serverを立てれば完成ではなく、Toolを企業の権限体系とどう対応させるかまでが実装範囲になる。
Toolはシステム名ではなく、業務上の責任で切る
Agentにorder_systemという大きなToolを一つ渡すと、検索、住所変更、キャンセル、返金が同じ入口に集まる。呼び出しは楽でも、必要な権限と確認条件が見えにくい。問い合わせ対応では、get_order、check_changeable、update_shipping_address、send_confirmationのように、結果と副作用を説明できる単位へ分けた方が扱いやすい。
ただし細かければよいわけでもない。住所変更のために十数個のToolを往復すると、途中状態が増え、失敗点も増える。判断基準はコード量ではなく、権限、監査、再実行の境界が同じかどうかだ。常に一緒に実行され、同じ権限と失敗処理を共有する操作なら、業務単位でまとめる余地がある。
更新Toolの最小例
{
"name": "update_shipping_address",
"description": "本人確認済み・未出荷の注文だけを更新する",
"inputSchema": {
"type": "object",
"required": ["order_id", "new_address_id", "confirmation_token"]
}
}
ここでconfirmation_tokenを必須にするのは、自然言語の「変更して」をそのまま書き込み権限へ変換しないためだ。本人確認、変更可能判定、ユーザーの最終確認を通過したことを、アプリケーション側が短命なトークンとして表現する。これはMCP固有の標準項目ではなく、Toolの外側に置く業務ポリシーの一例である。
読み取りと更新では、同じ情報を返さない
get_orderが顧客マスター全体を返せば、Agentは便利になる一方、今回の依頼に不要な住所履歴や決済情報までコンテキストへ入る。Toolの返却値は「モデルが知り得る最大量」ではなく、「次の判断に必要な最小量」で設計したい。注文番号、出荷状態、変更可否、現在の配送先IDで足りるなら、それ以上を返す理由はない。
また、参照Toolと更新Toolを別の認可スコープにすれば、「配送状況は自動照会できるが、住所変更は承認が必要」といった運用を実装しやすい。MCPの認可機構は入口を守るが、個々の業務操作の可否はServer側で検証する必要がある。
失敗時に別Toolへ逃げない
check_changeableがタイムアウトしたとき、Agentが確認を省略してupdate_shipping_addressを試す設計は危険だ。業務状態を確認できない失敗と、単なる一時的な通信失敗は分ける。前者は停止し、後者だけ回数を限定して再試行する。より権限の広いToolを代替経路にすると、障害時ほど制御が緩む。
私の結論は、Agentの実務能力はモデルの賢さだけでは決まらない、ということだ。企業がどのToolを見せ、どのデータを返し、どの操作に確認を要求するかによって、同じモデルでも任せられる仕事は変わる。
Udeskが向き合う企業のカスタマーサポートでも、知識、顧客情報、チケット、業務処理は別々のシステムに分かれている。だからこそ、「APIを呼べるか」より「どの能力を、どの境界でAIへ渡すか」が現実的な論点になる。業務システムをMCPでAgentにつなぐなら、Toolは細かく分けるべきでしょうか。それとも業務単位でまとめる方が運用しやすいでしょうか。