事例研究 · カスタマーサポート自動化
そのサポートエージェントは、チケットよりもツール定義に多くのコンテキストを費やしていた。
あるサポートチームの AI エージェントは十数の MCP サーバーに接続し、あらゆるプロンプトをツールスキーマで溺れさせていた。onemcp の Code Mode へ移行したことで、コンテキストは顧客の問題へと引き戻され、応答ごとのコストとレイテンシも低下した。
- 業種
- SaaS カスタマーサポート
- チーム
- 約 15 名のサポート組織
- 技術スタック
- Zendesk · Stripe · Postgres · 社内注文 API · Slack
# 概要
- リクエストごとのツール負荷を約 90% 削減
- 呼び出しごとのツールスキーマがおよそ 15,000 トークンから約 500 トークンへ
- あらゆる応答でコストとレイテンシが低下
本稿は一般的な onemcp 導入に基づく例示的なシナリオである。登場するチームは複合的な創作であり、実在の顧客ではない。数値は実測値ではなく代表的な目安である。
背景
ある SaaS サポートチームは、チケットのトリアージと回答を担う AI エージェントを構築した。実際に役立つには、広い到達手段が必要であった。チケットには Zendesk、課金には Stripe、アカウント状態には Postgres と社内の注文 API、エスカレーションには Slack。これらはいずれも MCP サーバーであり、エージェントに直接組み込まれていた。
このエージェントは初日から有用であった。同時に、うまく説明しきれない形で遅く、そして高くついた——各プロンプトに実際には何が入っているのかを確かめるまでは。
課題
エージェントが接続する各 MCP サーバーは、リクエストごとにツールスキーマ一式をコンテキストへ注入していた。十数のサーバーが接続された状態では、それは数百のツールおよびパラメータ定義が、当のチケットがそれを必要とするか否かにかかわらず、一枚一枚のチケットに随伴することを意味した。
そのコストは三つの形で現れた。
- コンテキストの浪費。 顧客の実際の問いに先立ち、およそ 15,000 トークンのツール定型文が各プロンプトの冒頭を占めた。長いスレッドでは、定義が会話そのものを押しのけた。
- より高い費用とレイテンシ。 これらの入力トークンは一手ごとに課金・処理され、週あたり数千件のチケットで乗算された。
- 誤りの余地の拡大。 より大きく雑然としたプロンプトは、モデルが誤ったツールを選んだり、複数ステップのチケットで筋道を見失ったりする余地を広げた。
アプローチ
チームはエージェントの全サーバーを単一の onemcp ポータルの背後に置き、エージェントを Code Mode 経由で通信させた。
ポータルはあらゆる定義を事前に読み込むのではなく、三つのメタツールのみを公開する。
search—— 目の前のチケットに関連するツールを見つける。describe—— それらのツールの正確なシグネチャを必要に応じて取得する。execute—— それらを呼び出す短いスクリプトを、一度の往復で実行する。
こうして返金チケットは、必要な Stripe と注文のツールだけを読み込み、それ以外は読み込まない。全カタログは依然として利用可能であり、単に毎回のプロンプトへ引きずり込まれなくなっただけである。
成果
- リクエストごとのツール負荷を約 90% 削減。 呼び出しごとのツールスキーマは、およそ 15,000 トークンから約 500 トークンへ低下した。この節約はあらゆるチケットのあらゆる一手で繰り返し生じる。
- より安く速い応答。 呼び出しごとの入力トークンが減ったことで、請求額は下がり初回応答は速まった。しかもエージェントの到達範囲は一切損なわれていない。
- より安定した複数ステップの処理。 コンテキストが道具箱ではなくチケットに向いたことで、エージェントは返金、アカウント照会、エスカレーションの全体を通じて筋道を保った。
切り替えた当日から、エージェントは速く安くなった。しかも私たちはツールを一つも取り除いていない。ただ、そのすべてを毎回のメッセージへ持ち運ぶのをやめただけだ。