先に結論
Google Workspace を AI agent につなぐ方法は、どれが一番モダンか ではなく、どこに責任を置きたいか で選ぶのが正解です。
ざっくり分けるとこうです。
- Google Workspace CLI: 開発者が最短で試す入口としてかなり強い
- Composio: auth・監査・運用までまとめて早く出したいときに強い
- self-hosted MCP server: MCP でつなぎたいが、完全 managed に寄せたくないときの中間案
- 直接Google API: 最も自由度が高く、最終的な本番最適になりやすい
つまり、
- まず動かす なら Google Workspace CLI
- 社内や顧客向けに早く安定運用へ持っていく なら Composio
- MCP を標準化インターフェースとして使いたい なら self-hosted MCP server
- 権限・監査・独自ロジックを自分で握りたい なら 直接Google API
この順で考えると判断を誤りにくいです。
なぜ今この比較が重要か
2026年は、Google Workspace を「人がブラウザで使う場所」から AI agent が直接触る業務OS として見直す流れが強くなっています。
背景には大きく3つあります。
- Google Workspace CLI の登場で、Gmail / Drive / Calendar / Sheets / Docs を CLI から横断しやすくなった
- MCP が agent 連携の標準インターフェースとして定着し始めた
- 単なる自動化より、認証・監査・権限制御まで含めて設計しないと本番で詰まりやすくなった
特に Workspace は、メール、会議、ドキュメント、表計算、社内ファイルに直結します。便利な反面、「つながった」だけで終わると権限事故や運用崩壊が起きやすい 領域です。
だからこそ今は、ツール名だけで選ぶのではなく、
- どの認証方式を取るか
- 誰がトークンを持つか
- 監査ログをどこで見るか
- cron / CI / headless でどう回すか
- 個人向けか、チーム向けか、社内IT向けか
まで含めて決める必要があります。
比較表
| 手段 | 強い用途 | 向いている人・組織 | 詰まりやすい点 | 評価 |
|---|---|---|---|---|
| Google Workspace CLI | 個人開発、PoC、agent からの即時実行 | 開発者、個人事業主、小規模チーム | OAuth scope、破壊的変更、権限制御の粒度 | 4.7 |
| Composio | managed auth、observability、複数agent運用 | SaaSチーム、社内IT、クライアント案件 | 外部依存コスト、提供面の癖、完全自前ではない | 4.6 |
| self-hosted MCP server | MCP 標準での統一、社内ツール接続 | MCP 前提の agent 基盤を作るチーム | サーバー保守、OAuth 管理、スキーマ保守 | 4.3 |
| 直接Google API | 本番実装、独自制御、深いカスタム処理 | プラットフォームチーム、厳格な統制が必要な組織 | 初期実装コスト、認証設計、保守負荷 | 4.8 |
4つの違いをひとことで言うと
Google Workspace CLI
Google Workspace CLI は、Google Workspace API を人間と agent の両方が叩きやすい形にまとめた実行レイヤー です。
公式 README ベースでは、Drive・Gmail・Calendar・Sheets・Docs などを 1つの CLI から扱え、JSON 出力、schema 表示、dry-run、agent skill 同梱を前提にしています。Discovery Service を runtime で読む設計なので、Google 側の API 追加に追随しやすいのも特徴です。
ただし README にもある通り、まだ active development 中で breaking changes が起きうる 立ち位置です。つまり、PoC や個人運用の入口としてはとても強い一方、組織導入ではバージョン固定や auth まわりの整理が必要です。
Composio
Composio は、Google Workspace 連携そのものより、agent が安全に使える integration plane を提供する側 です。
公式サイトでは、managed OAuth、token refresh、execution logs、RBAC、監査性を前面に出しています。要するに「Google API をつなぐコード」より、agent 用の認証・実行・観測の面倒を減らす のが主価値です。
そのため、最短で本番っぽく動かしたいチームには相性が良いです。一方で、コスト構造や外部依存が増えるので、全部を自社統制に閉じたい組織には向かないことがあります。
self-hosted MCP server
self-hosted MCP server は、Workspace API を MCP という標準インターフェースで AI クライアントに公開する方式 です。
メリットは、Claude / Codex / Cursor / VS Code 系の MCP クライアントに同じ形でつなげやすいことです。CLI より「agent に渡すツール面」を綺麗に見せやすく、Composio より自分で制御しやすい中間案になります。
ただし実態としては、OAuth、scope、token 保管、tool schema、サーバー運用を自前で持つことになるので、『見た目は標準化されるが、裏側は普通に大変』 です。
直接Google API
直接Google API 実装は、最も泥臭いが、最終的には一番強い 選択肢です。
Google の公式ドキュメントどおり、OAuth client ID、service account、domain-wide delegation などを用途別に選び、必要な API だけを叩く設計にできます。
つまり、
- 本当に必要な scope だけに絞る
- 独自の approval flow を入れる
- 監査ログを自社基盤に寄せる
- Gmail / Drive / Calendar だけ別々に権限制御する
- 既存の backend / queue / cron / IAM に統合する
といった 本番向けの制御 が最もやりやすいです。
比較の観点
1. セットアップ速度
最速なのは Google Workspace CLI です。
CLI の install と OAuth 設定で、かなり早く「Gmail を読む」「Drive を列挙する」「Calendar を取る」まで進めます。PoC の速度は大きな武器です。
Composio も速いですが、管理画面や integration 設定、API key の持ち方まで含めた設計になるため、個人開発ではやや重く感じることがあります。
self-hosted MCP server と 直接Google API は、最初の一歩が明らかに重いです。特に本番で使うなら auth 設計が支配的になります。
2. auth と権限制御
ここは 直接Google API が最も強く、Composio が最もラクです。
Google の公式ドキュメントでも、Workspace API の認証は API key、OAuth client ID、service account で分岐し、用途ごとに選ぶ必要があります。実際に重要なのは、どの credential を使うかより、誰の権限をどこまで代理実行するか です。
- 個人の Gmail を読むのか
- 共有 Drive を触るのか
- 管理者権限でユーザー管理するのか
- CI から unattended で回すのか
この違いが大きいので、雑に「MCP でつながるからOK」と考えると危ないです。
Composio は managed auth と token lifecycle を提供するぶん、この面倒をかなり減らせます。逆に CLI や self-hosted MCP は、最終的に auth 責任を自分で持つ前提です。
3. agent からの使いやすさ
agent 実装との相性だけ見ると、Google Workspace CLI と Composio がかなり強い です。
Google Workspace CLI は JSON 出力や schema 表示が前提で、agent skill も同梱しています。Composio は LLM-friendly schema と execution logs を売りにしていて、ツール呼び出し体験が整えられています。
self-hosted MCP server も MCP クライアントからはきれいに見えますが、道具として快適にするまでの整備は自分次第です。直接Google API は自由ですが、当然いちばん tool surface を自作する必要があります。
4. 監査・可観測性
ここは Composio が分かりやすく優位 です。
「どの agent が、誰の権限で、いつ何を実行したか」を見たいとき、managed integration の価値が最も出ます。複数ユーザー・複数agent・複数環境になるほど効きます。
CLI や self-hosted MCP server でもログは取れますが、標準で「運用者向けに見やすい」状態とは限りません。直接Google API なら好きに設計できますが、そのぶん observability を自前実装する必要があります。
5. CI / cron / headless 実行
この軸では、直接Google API と Google Workspace CLI が強いです。
Google Workspace CLI は credentials file や service account を使った headless 実行の導線を持っています。cron や agent 実行基盤から扱いやすいです。
ただし、scope 制限や OAuth app の検証状況には注意が必要です。README にも、未検証 app の testing mode では scope 上限に引っかかる話が明記されています。
Composio は headless 運用自体はしやすいですが、管理対象が増えるほど platform 依存も増えます。self-hosted MCP server は headless に見えて、実は token 更新や server 可用性を自分で守る必要があります。
どんな人にどれがおすすめか
まず個人で触ってみたい開発者
Google Workspace CLI が最有力です。
理由は、Workspace API の複雑さをいきなり全部背負わずに済むからです。Drive / Gmail / Calendar を試しながら、どの scope が必要で、どの操作が本当に価値を生むかを見極めやすいです。
小規模チームで agent を社内導入したい
Composio か Google Workspace CLI + 限定的な自前ラッパー が現実的です。
「まず成果を出す」だけなら Composio が速いです。逆に、外部依存を増やしすぎたくないなら、CLI を土台に必要操作だけ薄くラップする構成も十分ありです。
MCP を社内標準にしたい
self-hosted MCP server が候補です。
MCP で統一すると、クライアント差し替えや複数 agent への配布が楽になります。ただし、MCP はあくまで表の規格なので、裏の認証・監査・保守まで勝手に解決してくれるわけではありません。
厳格な統制や大きい本番導入が前提
直接Google API が本命です。
面倒ですが、結局ここが一番ブレません。サービスアカウント、domain-wide delegation、権限分離、監査ログ、キュー処理まで全部合わせて設計したいなら、抽象化レイヤーを増やしすぎない方が長期では安定します。
失敗しやすいポイント
1. 「MCP なら安全」と誤解する
MCP は便利ですが、安全性を自動で保証する仕組みではありません。どの tool を expose し、どの credential を使い、どこで approval を挟むかは別問題です。
2. scope を広げすぎる
Workspace は対象データが濃いです。Gmail、Drive、Calendar をまとめて開けると便利ですが、そのぶん事故の影響も大きいです。PoC ほど scope を絞るべきです。
3. 監査ログを後回しにする
個人開発では軽視しがちですが、チーム導入では必須です。あとから「誰が消した」「誰が送った」を追えないと、便利さより怖さが勝ちます。
4. ノーコード自動化と混同する
Zapier / Make / n8n のような iPaaS は、定型ワークフローには強いです。ですが、agent が文脈を読みながら Gmail や Docs を操作する世界では、CLI / MCP / direct API の方が自由度が高いです。逆に単純な承認フローや通知連携なら、最初から iPaaS の方が安いこともあります。
その意味で、ノーコード中心で考えたい人は先に Zapier / Make / n8n 比較 を見た方が判断しやすいです。
迷ったときの選び方
まず価値検証したいなら
Google Workspace CLI です。
最短で「どの業務が agent 化に向いているか」を見られます。Inbox triage、会議前準備、Drive 検索、Sheets 追記のような定番業務を試しやすいです。
早く本番寄りに持っていきたいなら
Composio です。
認証・観測・権限まわりを自力で整え始めると、思った以上に時間を食います。そこを短縮したいなら managed platform の価値があります。
長期で自社基盤にしたいなら
直接Google API を選んだ方がいいです。
最初は遅くても、組織が大きくなるほど「何を外部に預けるか」の重みが増えます。長期投資としては直接実装の方が回収しやすいケースが多いです。
この比較と相性が良い関連記事
Google Workspace 連携は単独で完結しません。実務では、
- AI agent の土台をどう作るか
- ノーコード自動化とどう住み分けるか
- Google Workspace 内の情報をどこまで業務判断に使うか
までセットで決まります。
あわせて読むなら次の記事が相性良いです。
- Zapier vs Make vs n8n を比較する
- ChatGPT for Excel vs Gemini in Sheets vs Copilot in Excel
- AIエージェント向けSearch API比較
参考にした一次・公式情報
- Google Workspace CLI GitHub README（Discovery Service ベースの動的 CLI、JSON 出力、auth、scope 制限、agent skills）
- Google Workspace API の認証公式ドキュメント（OAuth client ID / service account / domain-wide delegation の整理）
- Composio 公式 toolkit / docs（managed auth、execution logs、RBAC、監査性）
まとめ
結論はシンプルです。
- 試作の最短距離 は Google Workspace CLI
- 運用の手間を減らして早く出す なら Composio
- MCP を規格として使いたい なら self-hosted MCP server
- 長期の本番最適 は 直接Google API
Workspace 連携で本当に大事なのは、接続方式そのものよりも、誰の権限で、何を、どこまで、自律実行させるか です。
ここを曖昧にしない限り、どの選択肢を取っても前に進めます。逆にここを曖昧にしたまま「流行っているから」で選ぶと、あとで auth と運用で詰まります。