Airbyte Agent MCP、複数SaaSの business context を一つの接続へ

Airbyte は 2026年5月4日、Airbyte Agent MCP を紹介しました。複数の業務システムを個別 MCP としてつなぐのではなく、Context Store を介して agent に横断的な business context を渡す設計です。

要点

• 個別 MCP は単一 system の操作には便利だが、複数SaaS横断の推論では context が断片化しやすい
• Airbyte Agent MCP は、複数 source の業務データを Context Store として統合して agent へ見せる
• agent は discovery、read、write を分けて扱えるようになり、実行時の raw API 探索を減らせる
• Claude、ChatGPT、Cursor など AI client 側から一つの接続として使う構想が示されている

今回のブログ記事で語られていること

この記事は、MCP が普及するなかで「MCP をたくさんつなぐだけでは production agent の問題は解けない」という Airbyte の見立てを説明しています。個別 MCP は、GitHub で issue を見る、Slack に投稿する、CRM の特定レコードを読む、といった単一 tool の作業には便利です。しかし、agent が「今月 close 予定の enterprise deal のうち、open support ticket を抱えている顧客を見つける」のような横断的な質問に答えるには、CRM、support、billing、product usage などをまたいだ context が必要になります。

Airbyte Agent MCP は、この横断 context を一つの入口にまとめる発想です。背後には Context Store があり、接続済みの business system から data を取り込み、agentic search に適した index として整えます。agent は個々の raw API endpoint を知らなくても、まず関連する entity や source を発見し、その後に必要な fresh state を connector 経由で読む、あるいは write action を実行できます。

ブログで重要なのは、Airbyte が MCP を「API を model に見せる wrapper」としてではなく、「agent に business context を渡す protocol boundary」として扱っている点です。多くの MCP は既存 API の薄い表現であり、caller が object ID や field を知っていることを前提にします。Airbyte はそこに discovery layer を置き、agent が曖昧な依頼から relevant data を探せるようにする、と説明しています。

また、setup の観点では、agent client に Airbyte Agent MCP を一度接続し、Airbyte UI で OAuth や API key によって各 source を接続する流れが示されています。これはユーザー体験としては一つの MCP ですが、運用上は source ごとの権限、data freshness、write permission、audit を分けて設計する必要があります。agent が便利になるほど、どの system をどの権限で横断できるかが governance の焦点になります。

実務で確認したいポイント

1. 個別 MCP と統合 context layer のどちらが必要な workflow かを分ける
2. Context Store に入る data の scope と更新頻度を決める
3. source ごとの OAuth / API key / write permission を分離して管理する
4. agent が横断 query から write action へ進む場合の承認境界を設計する

どう読むべきか

Airbyte Agent MCP は、MCP の数を増やす話ではなく、agent に見せる business context をどう統合するかの話です。agent を業務横断に使うチームほど、MCP catalog だけでなく context layer と権限設計を評価する必要があります。