AIからSlackやGmailを使うComposioでAPI連携をどこまで省けるか

Composioは、AIが外部サービスを使うときの接続処理を受け持つSaaSです。AIの判断役と分離して、サービスごとに異なるAPI接続・認証・呼び出し形式をまとめ、利用者の業務ルールに合わせやすい共通形式へ変換します。

APIとは、あるソフトウェアが別のソフトウェアへ処理依頼を出すときに使う形式です。たとえばSlackへ投稿する場合、送信先・本文・認証情報の形をSlack API向けに整える必要があります。Composioを挟むと、AIには「Slackへメッセージを送る」という短い指示だけを渡し、実際の呼び出し変換と認証付与はComposioが受け持ちます。

この構成で役割を切り分けると、モデルと業務の判断は利用企業が設計し、外部サービス接続の反復実装はComposioへ外出しできます。

外部サービスを一つだけ呼ぶコードは、小さく作れます。接続先と利用者が増えると、APIアダプター、認証管理、AI向けツール定義、実行管理の四つが繰り返し必要になります。Composioが主に肩代わりするのは、この反復部分です。

APIアダプターは、Gmail、Slack、GitHubなどのURL、入力項目、ページ分割、エラー形式の違いを吸収します。認証管理は、利用者をログイン画面へ案内し、OAuthトークンやAPIキーを接続アカウントとして保存し、期限切れ時に更新します。OAuthは、利用者がパスワードを相手へ渡さず、許可した範囲だけ別のサービスから操作させる仕組みです。

AI向けツール定義は、「何ができるか」「どの入力が必要か」「何が返るか」をモデルが読める形式にします。実行管理は、どの利用者のどのアカウントで操作するかを解決し、結果を構造化して返します。Composioはこの四つを、一つのSDKやAPI、MCP接続から使える形へまとめた製品です。

Claude CodeからGmailを読み、要約をSlackへ投稿する機能を自作する場合は、Claude CodeへMCPサーバーを登録し、その内側にGmailとSlackの認証処理、API呼び出し、エラー処理を実装します。MCPは、Claude Codeに操作一覧と入出力を見せる接続規格です。個人が自分の固定トークンで試す段階なら小さく作れますが、別の利用者やチームへ配る段階で接続基盤の仕事が増えます。

Gmail側ではGoogle CloudのプロジェクトとOAuthクライアントを作り、同意画面、リダイレクト先、必要最小限の権限を設定します。認可コードをアクセストークンと更新用トークンへ交換し、利用者ごとに安全に保存して、期限が切れれば更新する処理も必要です。メール本文を読む権限は制限付き権限に分類され、一般公開するアプリでは審査が必要になり得ます。Slack側でもアプリ登録、Botまたは利用者の権限、HTTPSのリダイレクト先、認可コード交換、トークンの保存と失効処理を別に用意します。

次の作業は、Gmailの検索結果からページをたどって本文を取り出し、Slackのチャンネルを解決して投稿する処理を、MCPのツールとして定義することです。応答形式の違い、部分失敗、重複投稿、SlackのHTTP 429と待ち時間、再認証も扱います。運用開始後は、両社のAPIや権限、利用制限、SDKの変更を監視し、操作定義と試験を更新します。2026年7月のSlack Node.js向けSDK情報でも、メジャー版更新と破壊的変更が報告されており、接続コードは運用を通じて継続的な見直しが前提になります。

ComposioのClaude Code向けプラグインを使う場合、利用者の初期作業はプラグイン導入、Composioへのログイン、初回時のGmail・Slack OAuth承認です。その後のツール検索、接続状態の保持、資格情報の付与、各APIへの変換はComposio側で進みます。API変更追従は残るものの、通常はサービスごとの接続コードを都度直す量より、Composio側のコネクター更新で収束しやすい構成です。

それでも利用者側には、どのメールを読ませるか、どのSlackチャンネルへ投稿できるか、送信前に確認を挟むか、結果が正しいかを決める責任が残ります。独自の操作がComposioにない場合の追加実装、Composio自体の障害や仕様変更への対応、資格情報を外部事業者へ預けられるかの判断も消えません。Composioが肩代わりするのは業務判断ではなく、接続先ごとに繰り返す実装と保守です。

「過去24時間の重要メールを要約してSlackへ投稿する」という仕事では、最初に利用企業のAIが目的を解釈します。AIはGmail検索とSlack投稿が必要だと判断し、Composioのセッションから利用可能なツールを探します。セッションとは、一回の実行で誰のアカウントとどの道具を使えるかを束ねる作業単位です。

Gmailが未接続なら、Composioが利用者へ返すのは認証リンクです。認証後はGoogleの許可情報がConnected Accountとして利用者IDへ紐付きます。AIがメール検索ツールを呼ぶと、Composioが認証情報を付けてGmail APIを実行して結果を返し、AIはその内容を要約して次にSlack投稿ツールを呼びます。

この流れでComposioが決めないのは、何を重要メールとみなすか、どのチャンネルへ投稿するか、投稿前に承認を求めるかです。接続と実行は借りられても、業務ルールと事故を止める設計は利用企業に残ります。

対応サービスが増えるほど、すべての操作定義を一度にAIへ渡す方法は使いにくくなります。候補が多すぎると、モデルが読む情報量が増え、似た操作を選び間違える可能性も上がるためです。Composioの現行セッションは、少数のメタツールから必要な操作を検索し、接続状態を確認して実行する方式を中心にしています。

代表的な流れは、検索用のメタツールで目的に合う操作を見つけ、未接続なら接続管理ツールで認証し、実行ツールへ引数を渡す順番です。利用者、利用可能なツール、認証済みアカウント、実行状態は同じセッションへ紐付きます。MCPを使う場合も、セッションごとの接続先を発行できます。

ただし、検索結果をそのまま無制限に実行させる設計は危険です。実際の製品では、利用できるサービスと操作を許可リストで絞り、読み取りと書き込みを分け、送信や削除の前に承認を置く必要があります。

Composioは2026年8月15日の公式カタログで1,052のツールキットを掲載しています。ツールキットとは、一つのサービスに関する操作、認証方法、イベント通知をまとめた単位です。サービス名の掲載は接続の入り口を示すものなので、全APIを同時にまとめているとは限りません。

Google関連でもGmail、Drive、Calendar、Docs、Sheets、Admin、Slides、Forms、Meet、Tasks、Contacts、BigQueryなどのツールキットがあります。各ツールキットは利用頻度の高い操作を優先的にまとめる構成なので、Google公開APIの全エンドポイントを同一形式で扱う設計ではありません。数値は確認時点のカタログであり、追加、廃止、版の更新によって変わります。

用意済みのツールにないエンドポイントや特殊な検索条件が必要な場合は、Proxy Executeを使えます。これはComposioが利用者の認証情報をサーバー側で付け、同じ接続先の任意APIへHTTP要求を中継する機能です。この場合もトークン管理は任せられますが、APIのURL、入力、応答処理は利用企業が実装します。

MCPは、AIクライアントと外部のデータや操作を共通形式でつなぐ通信規格です。どんなツールがあり、どの入力で呼び、何が返るかをやり取りできます。SlackやGmailのOAuth処理とAPIアダプターの実装はMCP単体で完結しないため、MCPサーバーを自前で作る場合は、その内側で各社APIと認証を一緒に設計します。

Composioは、その実装済みコネクターと認証管理を、SDK、REST API、MCPのいずれからも使えるようにしています。MCPとComposioは役割が異なります。MCPが差し込み口の規格なら、Composioは多数の接続先、認証、実行機構を備えた中継装置に当たります。

接続先が一つで必要な操作も少ないなら、自前MCPと公式SDKの方が単純な場合があります。多数のサービスを利用者ごとに接続するほど、共通化された認証とコネクターの価値が大きくなります。

Composioを採用すると、API仕様への追従、資格情報の保管、ツール定義、イベント配送の一部を外部事業者へ寄せられます。新着メール、GitHubのCommit、Slackメッセージなどをきっかけに処理を始めるTriggerでは、Composioが接続先からイベントを受け、署名付きのWebhookとして利用企業のURLへ配送し、再試行も担います。Webhookは、外部で出来事が起きたときに指定URLへ通知を送る仕組みです。

同時に、認証情報と操作経路をComposioへ依存します。Composioは暗号化、監査ログ、権限制御、SOC 2などを公式に掲げていますが、採用企業は自社要件に照らして契約、保存場所、保持期間、障害時の経路、解約時の移行方法を確認する必要があります。ベンダーのセキュリティ説明は、利用企業自身の権限設計を代替しません。

AIが誤った宛先へ送信したり、広すぎる範囲を削除したりする危険も残ります。OAuthの権限を狭くし、セッションで利用可能なツールを制限し、外部へ影響する操作は人の承認で止め、実行記録を残す設計が必要です。

Composioが向くのは、複数の外部サービスを、複数の利用者のアカウントで操作するAIエージェントを短期間で作りたい場合です。OAuth、トークン更新、ツール定義を接続先ごとに繰り返す必要が減り、まず一つの業務フローを試しやすくなります。

接続先が一つか二つで、使うAPIが固定され、細かな性能や応答形式を管理したい場合は、公式SDKを直接使う方が小さく作れます。規制上、資格情報を外部へ預けられない場合や、Composioにない特殊APIが中心の場合も、自前実装または自社環境での接続基盤が向きます。

導入前に確認するのは、サービス名の有無だけでなく、必要な読み取り、書き込み、イベントがツール化されているかです。足りない操作をProxy Executeで補う量、独自OAuthアプリの要否、承認と監査の設計まで見積もれば、自作より本当に小さくなるかを判断できます。Composioの価値はAPIをなくすことではなく、異なるAPIをAIから繰り返し使うための共通部分を外出しすることにあります。