---
title: "事例研究：ある AI サポートエージェントのツール負荷を約 90% 削減 — onemcp"
description: "ある例示的なサポートチームの AI エージェントは、コンテキストの大半を MCP ツール定義に費やしていた。onemcp の Code Mode 経由でツールを扱うことで、リクエストごとの負荷を約 90% 削減し、応答は速く安価になった。"
ogTitle: "事例研究：トークン・ダイエット中の AI サポートエージェント"
ogDescription: "あるサポート自動化が onemcp の Code Mode でリクエストごとのツール負荷を約 90% 削減した方法——より速く、より安く、より確実に。"
url: "https://onemcp.dev/ja/case-studies/support-agent-token-diet"
eyebrow: "事例研究 · カスタマーサポート自動化"
headline: "そのサポートエージェントは、チケットよりもツール定義に多くのコンテキストを費やしていた。"
summary: "あるサポートチームの AI エージェントは十数の MCP サーバーに接続し、あらゆるプロンプトをツールスキーマで溺れさせていた。onemcp の Code Mode へ移行したことで、コンテキストは顧客の問題へと引き戻され、応答ごとのコストとレイテンシも低下した。"
industry: "SaaS カスタマーサポート"
teamSize: "約 15 名のサポート組織"
stack: "Zendesk · Stripe · Postgres · 社内注文 API · Slack"
illustrative: "本稿は一般的な onemcp 導入に基づく例示的なシナリオである。登場するチームは複合的な創作であり、実在の顧客ではない。数値は実測値ではなく代表的な目安である。"
results:
  - "リクエストごとのツール負荷を約 90% 削減"
  - "呼び出しごとのツールスキーマがおよそ 15,000 トークンから約 500 トークンへ"
  - "あらゆる応答でコストとレイテンシが低下"
quote: "切り替えた当日から、エージェントは速く安くなった。しかも私たちはツールを一つも取り除いていない。ただ、そのすべてを毎回のメッセージへ持ち運ぶのをやめただけだ。"
quoteAttribution: "サポート・オペレーション責任者（例示）"
---

## 背景

ある SaaS サポートチームは、チケットのトリアージと回答を担う AI エージェントを構築した。実際に役立つには、広い到達手段が必要であった。チケットには Zendesk、課金には Stripe、アカウント状態には Postgres と社内の注文 API、エスカレーションには Slack。これらはいずれも MCP サーバーであり、エージェントに直接組み込まれていた。

このエージェントは初日から有用であった。同時に、うまく説明しきれない形で遅く、そして高くついた——各プロンプトに実際には何が入っているのかを確かめるまでは。

## 課題

エージェントが接続する各 MCP サーバーは、リクエストごとに**ツールスキーマ一式**をコンテキストへ注入していた。十数のサーバーが接続された状態では、それは数百のツールおよびパラメータ定義が、当のチケットがそれを必要とするか否かにかかわらず、一枚一枚のチケットに随伴することを意味した。

そのコストは三つの形で現れた。

- **コンテキストの浪費。** 顧客の実際の問いに先立ち、およそ 15,000 トークンのツール定型文が各プロンプトの冒頭を占めた。長いスレッドでは、定義が会話そのものを押しのけた。
- **より高い費用とレイテンシ。** これらの入力トークンは一手ごとに課金・処理され、週あたり数千件のチケットで乗算された。
- **誤りの余地の拡大。** より大きく雑然としたプロンプトは、モデルが誤ったツールを選んだり、複数ステップのチケットで筋道を見失ったりする余地を広げた。

## アプローチ

チームはエージェントの全サーバーを単一の onemcp **ポータル**の背後に置き、エージェントを **Code Mode** 経由で通信させた。

ポータルはあらゆる定義を事前に読み込むのではなく、三つのメタツールのみを公開する。

- `search` —— 目の前のチケットに関連するツールを見つける。
- `describe` —— それらのツールの正確なシグネチャを必要に応じて取得する。
- `execute` —— それらを呼び出す短いスクリプトを、一度の往復で実行する。

こうして返金チケットは、必要な Stripe と注文のツールだけを読み込み、それ以外は読み込まない。全カタログは依然として利用可能であり、単に毎回のプロンプトへ引きずり込まれなくなっただけである。

## 成果

- **リクエストごとのツール負荷を約 90% 削減。** 呼び出しごとのツールスキーマは、およそ 15,000 トークンから約 500 トークンへ低下した。この節約はあらゆるチケットのあらゆる一手で繰り返し生じる。
- **より安く速い応答。** 呼び出しごとの入力トークンが減ったことで、請求額は下がり初回応答は速まった。しかもエージェントの到達範囲は一切損なわれていない。
- **より安定した複数ステップの処理。** コンテキストが道具箱ではなくチケットに向いたことで、エージェントは返金、アカウント照会、エスカレーションの全体を通じて筋道を保った。

> 切り替えた当日から、エージェントは速く安くなった。しかも私たちはツールを一つも取り除いていない。ただ、そのすべてを毎回のメッセージへ持ち運ぶのをやめただけだ。

## 関連する事例研究

- [あるプラットフォームチームが 20 の MCP サーバーを単一エンドポイントの背後に集約](/ja/case-studies/platform-team-mcp-gateway)
- [認証情報を漏らさずセルフサービスのデータエージェントを実現する](/ja/case-studies/data-team-secure-agents)