AIエージェントを実際の業務ツールと接続しようとするとき、最初に直面するのは認証の壁です。GitHubのOAuth、GmailのOAuth2、NotionのAPIキー、それぞれが異なる仕組みを持ち、エージェント側のコードにクレデンシャルを直接渡す設計にするか、毎回接続処理を書き直すか、という選択を迫られます。そこで使えるかもしれないのが、今回紹介する open-connector です。OSSのコネクターゲートウェイとして認証とアクションの実行を一手に引き受ける設計になっていて、紹介と設計論の両方から掘り下げていきます。
リポジトリ: https://github.com/oomol-lab/open-connector
どんなツールか
ooml-lab氏が開発する open-connector は、1,000以上のSaaSプロバイダーをAIエージェントに接続するためのOSSゲートウェイです。GitHub、Gmail、Notion、Slack、BigQuery、Airtableといったサービスへの認証・アクション実行を一元管理し、エージェント側には認証情報を渡さないアーキテクチャが特徴です。
アクセス手段は複数用意されていて、TypeScript製のConnector SDK、ローカルのエージェントリレーとして使うCLIツール（oo CLI）、MCPプロトコル経由のエージェントホスト連携、そして素のHTTP/OpenAPIといった選択肢があります。デプロイ先もDockerによるローカル実行、Cloudflare Workers、Fly.io、Kubernetes（Helm）、さらにOOMOLが提供するホスト済みランタイムまで対応しています。PipedreamやComposioの代替として位置づけられており、Apache-2.0ライセンスで公開されています。スター数は5,000を超え、プロダクション利用を視野に入れた開発が続いています。
設計でここが上手い
認証境界の分離
エージェントとプロバイダーのあいだにゲートウェイを挟み、クレデンシャルをエージェントプロセスから切り離している点がまず目を引きます。OAuthトークンやAPIキーはゲートウェイの内部に留まり、エージェントには実行結果とメタデータだけが渡ります。これは「エージェントに秘密鍵を持たせない」という原則を構造として実現したもので、万が一エージェントのプロセスが何らかの問題を起こしても、認証情報への経路が存在しないという状態を作り出しています。自分のチームでエージェントを開発していて、複数のSaaSにまたがるアクセスを扱う場面を想像すると、この分離の価値がよく分かります。
アクションの契約による安定性
プロバイダーごとにリクエスト・レスポンスのスキーマ、必要なスコープ、実行ソースが定義された「アクション契約」を持っています。エージェントはアクションIDとスキーマさえ知っていれば、プロバイダーの仕様を個別に調べる必要がありません。スキーマはOpenAPIドキュメントとして生成されるため、OpenAPIを読める既存のクライアントをそのまま使えます。アクションIDがOSSとSaaSホスト版で共通化されているので、開発環境ではセルフホスト、本番ではOOMOLホスト、という移行も設計上スムーズです。
MCPとHTTPの両立
MCP（Model Context Protocol）エンドポイントとHTTP/OpenAPIエンドポイントを同一ランタイムで公開しています。MCPに対応したエージェントホストからはMCP経由で呼び出し、カスタムクライアントからはREST経由で呼び出す、という使い分けが同じゲートウェイで完結します。どちらかに限定せず、接続先の多様性に対して同じコネクターカタログを使い回せる構造は、複数のエージェントフレームワークを並行して試している開発チームにとって選択の幅を広げてくれます。
デプロイオプションの設計
Dockerイメージ、Cloudflare Workers、Fly.io、Kubernetes Helmチャートと、インフラ選択肢を明確に分けてドキュメント化しています。Cloudflare版はWorkers・D1・R2・Static Assetsの組み合わせで構成され、SQLiteとPostgreSQL両対応のNode版とは別の実装パスをとっています。このような「プラットフォームごとの明示的な分離」は、ランタイムの特性（エッジ実行の制約など）を設計段階から意識した証拠で、「どこでも動く」という曖昧な主張とは異なる具体性があります。
こういう人に向くかも
複数のSaaSへのアクセスが必要なAIエージェントをチームで開発していて、認証処理をエージェントコードから分離したい場合に向きます。特に、MCPに対応したエージェントホストを使いつつ、既存のREST APIクライアントも並行して動かしたいという状況では、両方のエンドポイントを同一ゲートウェイで提供できる点が効いてきます。
セルフホストの選択肢が充実しているので、クレデンシャルを外部サービスに預けることに制約があるチームにも選択肢として入ってくる可能性があります。逆に、単一のSaaSとの接続だけを素早く試したい場合は、このゲートウェイを立ち上げるコストに対してメリットが薄くなるでしょう。PipedreamやComposioをすでに使っていて、特定のSaaSへの接続さえ動いている環境なら、移行コストをどう見るかがひとつの判断軸になります。
設計の良し悪しをどこで見るか
評価の軸として特に気になったのは、機能の単一性、ドキュメントの深度、そしてトークン経済性の3点です。
機能の単一性という観点では、open-connector は「接続の管理と実行の仲介」という役割に集中しています。ワークフローのオーケストレーション機能はなく、エージェントのロジック自体も持ちません。これはPipedreamのような多機能なiPaaSとの明確な違いで、意図的な絞り込みだと読めます。単一機能への集中はドキュメントの範囲も狭くなるため、必要なことを調べやすくなる副次的な効果があります。
ドキュメントの深度については、docs/runtime-api.md、docs/credentials.md、docs/configuration.md、docs/cloudflare.md、docs/quickstart.mdとデプロイ先ごとに分割されていて、READMEの情報密度が高い一方で参照先が明確です。多言語対応（英語・中国語繁体・中国語簡体・日本語・韓国語・ロシア語・フランス語）も済んでおり、国際的な利用を前提とした整備が見えます。ただし、アクション契約がどのように定義・追加されるかの開発者向けガイドが、READMEの範囲では確認しにくいところがあります。1,000以上のプロバイダーを誰がどのように管理しているのかは、プロジェクトの長期的な信頼性を判断するうえで追いかけておきたい点です。
トークン経済性については、アクション契約に「スキーマとスコープの遅延読み込み」が明記されています。エージェントが全プロバイダーの定義を一度に受け取るのではなく、必要なアクションだけを参照できるオンデマンド設計になっているとすれば、コンテキストウィンドウへの影響を最小化する意図があると見られます。MCPエンドポイントがどこまで選択的に情報を渡せるかは、実際に動かして確認したいところです。
メンテナンスの継続性という軸では、OOMOLというプロダクトとの連携が強く、OOMOLホスト版との互換性維持がリポジトリの持続性を支えている面があります。純粋なコミュニティドリブンではなくベンダー主導の開発であることは、長期的な方向性の安定につながる一方で、OOMOLのビジネス判断がOSS側の開発方針に影響しうるという点も頭に入れておいた方がいいでしょう。
自分が書くなら、どこを変えるか
アクション契約のメンテナンス経路が気になります。1,000以上のプロバイダー、10,000以上のアクションという数字は魅力的ですが、それらが誰によってどのように追加・更新されているのか、コントリビューターがプロバイダーを追加するためのフローが、このリポジトリの中では見えにくい状態です。connector-sdk リポジトリとの分担も含め、「自分でプロバイダーを追加したい」という開発者向けのガイドをREADMEから直接参照できる形にすると、OSSとしての広がり方が変わってくるのではないかと思います。
もうひとつは、エラーレスポンスの扱いです。ランタイムがアクション実行時に受け取ったプロバイダー側のエラーを、エージェントにどう伝えるかは、エージェント側の再試行ロジックに直接影響します。docs/runtime-api.md に詳細があるとは思いますが、READMEのクイックスタートの段階でエラーの形式を示しておくと、導入の判断が早くなりそうです。認証周りのデバッグは特に試行錯誤が増えやすい箇所なので、ここへの導線を太くする価値はあるかなと感じます。
導入を検討するときのチェック観点
以下の点を確認してから判断するとスムーズかもしれません。
- 接続したいSaaSプロバイダーがカタログにすでに含まれているか（公開カタログURLで確認できます）
- セルフホストが必要か、OOMOLホスト版で十分かを組織のポリシーから先に決める
- エージェントがMCP対応かREST対応かで使うエンドポイントが変わるため、エージェント側の接続方法を先に確認する
- PostgreSQLを使う場合、マイグレーションが手動実行であることを運用フローに組み込めるか
- OAuth2プロバイダーを使う場合、各プロバイダーのOAuthアプリ登録（クライアントID・シークレット）を自前で管理できるか
- Cloudflareデプロイを選ぶなら、D1・R2・Workers・Static Assetsを合わせて扱う知識がチームにあるか
- アクション契約の追加・カスタマイズが必要な場合に、
connector-sdkとの連携方法を事前に調べておく
向き不向きの分かれ目
open-connector が面白いのは、「認証の境界をゲートウェイに引く」というひとつの判断を設計の中心に据えている点です。エージェントにクレデンシャルを持たせないという方針を構造として実現し、複数のアクセス手段（SDK・CLI・MCP・HTTP）を同一のカタログに向けることで、エージェントフレームワーク側の変化に対して柔軟に対応できる下地を作っています。複数のSaaSを束ねるエージェントを本格的に作るなら、ゲートウェイ層の存在意義をここで試す価値はあるでしょう。一方で、接続先が少ない、あるいはすでに別の手段で認証が動いているなら、このゲートウェイを挟む必然性から先に検討することをお勧めします。
