MCPサーバーを構築すること自体は難しくありません。しかし、生のAPI出力に埋もれさせることなく、AIエージェントに適切な情報を届けるMCPサーバーを構築するのは、はるかに困難です。出力が大きくなれば出力トークンが増え、それはコストの増加につながります。
最初のGmailサーバーは問題なく動作していました。課題はそこではありませんでした。課題は、タスクに必要な量をはるかに超えるデータを返してしまうことが多かった点にあります。Workatoを使うことで、無駄の量を測定し、その原因となっているワークフローまで追跡し、実装を素早く修正し、変更が実際の利用でも有効であることを実証できました。ここで、AIRO MCP by Workatoが決め手となりました。
成果:出力を減らし、より有用な作業を実現
再構築したGmail by Workato MCPは、モデルのコンテキストに占める容量が小さくなり、エージェントへの負荷も軽減され、置き換え前のバージョンよりも多くのことを実行できます。すべてのトークンが課金対象となる世界では、出力が少ないことはコストが低いことを意味します。
- 6つの完結したワークフロー全体で、ネイティブのGmailコネクタと比較してツール出力を79.8%削減しました。
- モデルとやり取りしたデータの合計量は79.3%削減されました。
- 60回のワークフロー実行のうち60回がすべて成功しました。
- 32件の機能テストおよび敵対的テストを実施し、すべて合格しました。29個のツールすべてが正しくルーティングされました。
この成果は、有用な情報を隠すことで得たものではありません。エージェントが本当に必要とするものを返し、生のメール構造、重複した履歴、決して使われないペイロードを省くことで実現しました。
ツール単体ではなく、ワークフローを測定する
レスポンスが小さくても、10回のフォローアップ呼び出しが必要になるのであれば、効率的とは言えません。そこで、個々のツール呼び出しだけでなく、タスク全体を比較しました。
ベンチマークでは、同じGmail体験について3つのバージョンを対象としました。
- 従来のGmail by Workato MCPと、その通常のマルチツール経路。
- タスクに合わせて設計され、レスポンスに上限を設けた再構築版のV2サーバー。
- 同じAIクライアントで利用可能なネイティブのGmailコネクタ。
両方のシステムが対応しているタスクについては、同じ認証済みメールボックスと同じテストメッセージを使用しました。単一呼び出しのテストでは、ウォームアップ後に10回の測定を行いました。6つのマルチステップのシナリオでは、それぞれ1回のウォームアップ後に5回の測定を行いました。依存する呼び出しはすべてカウントしています。ワークフローのコストとは、最初のレスポンスのコストではなく、仕事を完了させるまでのコストだからです。
Workatoが開発ループを高速化
Workatoは単なるランタイムではありませんでした。動作の検証、レスポンスの整形、変更のテスト、リリースの管理、そして本番環境でのサーバーの利用状況の監視を行う場でもありました。
この開発ループでは、3つのツールを使用しました。
- Codex:テストの設計、比較の実行、レスポンスの分析、各イテレーションの調整を担いました。
- AIRO MCP:分析結果を、Workatoのジョブの証跡、レシピ、MCPスキル、スキーマ、サーバー設定に直接接続しました。これにより、同じ開発セッションの中で証跡を確認し、基盤となるWorkatoのアセットを更新できました。
- ブラウザ自動化:最終的なカタログとデプロイメントの検証を含む、UI上でしか行えない限られたステップをカバーしました。
重要なのはツールの数ではありません。Workatoが、サイクル全体を一貫してつなぎ続けたことが重要です。証跡からレシピの変更、テスト、リリース、オブザーバビリティまで、流れを途切れさせることなく進めることができました。
変更したポイント
エージェントの判断を助ける検索
再構築した検索ツールは、最小限のリスト、コンパクトな結果、または次に何を読むべきかを判断するのに十分なコンテキストを備えたトリアージビューを返せます。この必要最小限の有用なコンテキストにより、エージェントはすべての検索結果を開く必要がなくなります。
余計な負荷のない、読みやすいスレッド
新しい読み取りパスは、読みやすいテキスト、返信のコンテキスト、ラベル、添付ファイルの詳細を返します。生のメールエンコーディングや、繰り返される引用履歴は含まれません。エージェントは最新のメッセージ、またはスレッドの一部の範囲を指定して取得できるため、長いスレッドでもコストが次第に膨らむことなく、有用性を保てます。
仕事を最後までやり遂げる返信と添付ファイル
Workatoは、元のメッセージから返信先のスレッドを特定し、要求に応じて呼び出し元のGmail署名を追加し、Gmailを呼び出す前にアドレスとヘッダーを検証します。また、添付ファイルの詳細を返し、ユーザーがそれらのファイルをダウンロードできるようにします。正しくスレッド化された返信、ネイティブの署名、添付ファイルのダウンロードは、今回の比較対象となったネイティブコネクタにはなかった機能を、当社のサーバーにもたらしています。
実際のワークフローでも、削減効果を維持
実際の6つのタスク全体で、Gmail by Workato MCPが生成した出力トークンは、推定17,320でした。ネイティブのGmailコネクタは85,546でした。測定したすべてのワークフローが正常に完了しました。
削減効果は、受信トレイのトリアージ、件名を指定した正確なレビュー、複数スレッドの読み取り、メタデータの検索、添付ファイルの取得、下書きのレビューなど、まったく異なる種類の作業でも維持されました。個々の削減率は4.1%から96.3%の範囲でした。6つのワークフロー全体では、Workatoの出力は79.8%少なくなりました。
最も大きな効果が見られたのは、複数のメッセージや添付ファイルを伴うタスクでした。3つの会話をレビューするケースでは、ネイティブコネクタが推定24,185の出力トークンを返したのに対し、Workatoは3,041でした。PDF添付ファイルのワークフローでは、38,081に対して2,408という結果でした。
これは実際の利用において重要な意味を持ちます。エージェントが受け取る情報は大幅に少なくなり、不要なリカバリー呼び出しも避けられます。次の開発サイクルでは、これまでの成果を損なうことなく、残るレイテンシの短縮に注力します。
ユーザーに影響を与えずに、開発から本番運用へ
既存のMCPエンドポイントはそのまま維持しました。新しいツールを優先ルートとし、従来のツールは既存の自動化のために引き続き利用できるようにしています。
Workatoは、どのツールが呼び出されたか、誰が呼び出したか、どの環境か、各ジョブにどれだけ時間がかかったかを記録します。データの収集はレスポンスの経路の外で行われるため、モニタリングによってユーザーが体感するレイテンシが増えることはありません。
リクエストは認証済みのGmailユーザーとして実行され、Gmailの権限がセキュリティ境界となります。ID、実行、デプロイメント、テレメトリは、ガバナンスの効いた単一のWorkatoプラットフォーム上に集約されています。
Workatoが決め手となった理由
MCPの効率化に関する議論の多くは、プロンプトから始まります。私たちは違いました。ツールのレスポンスを生成するシステムそのものから着手しました。
各MCPツールはWorkatoのレシピに支えられているため、レスポンスがモデルに届く前に整形できました。リクエストを検証し、Gmailを呼び出し、結果を解析し、上限を適用し、重複を取り除き、予測可能なレスポンスを返しました。AIROによって、これらのアセットを直接確認・編集でき、課題をすぐに修正へとつなげられました。
また、Workatoは改善を実際に運用できる形にしてくれました。負荷をかけた状態でテストし、後方互換性を維持し、変更されたアセットだけを昇格させ、リリース後の利用状況を観察しました。構築、ロールアウト、実証のすべてを、同じプラットフォームで支えることができました。
今後の展開
V2はすでに本番環境で稼働しています。並行してV3の開発を進めており、バッチ処理と並列エンリッチメントをGmail APIにより近い層へ移す、カスタムGmailコネクタを採用します。
ユーザーが利用するツールは安定したまま、実装をより高速にしていくことができます。これこそが、MCPサーバーを単なるAPIラッパーではなく、プロダクトとして扱うということです。APIラッパーは、GmailをモデルにExposeするだけです。Workatoは、Gmailを「使えるもの」にします。それが、私たちが構築したものです。
