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

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

要点

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

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

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

Airbyte エージェント MCP は、この横断 context を一つの入口にまとめる発想です。背後には Context Store があり、接続済みの business システム から data を取り込み、agentic search に適した index として整えます。エージェント は個々の raw API エンドポイント を知らなくても、まず関連する entity や source を発見し、その後に必要な fresh state を コネクター 経由で読む、あるいは write action を実行できます。

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

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

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

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

どう読むべきか

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