AIエージェントにGmailやNotionやSlackを触らせたい。しかしエージェントのプロセスに各サービスのアクセストークンを直接渡すのは避けたい——この矛盾を、エージェントとSaaSの間に1枚ゲートウェイを挟むことで解こうとするのが OpenConnector（oomol-lab/open-connector）です。READMEはこれを「Pipedream/Composioのオープンソース代替」と位置づけています。本記事では公式リポジトリを実際にセルフホストして起動し、カタログの規模・起動条件・MCPの見え方・既定のセキュリティ設定を実測しました。
30秒でわかるOpenConnector
・何ができるか：SaaSアカウントを一度接続すれば、AIエージェントはトークンを持たずに1,421プロバイダー・14,911本のActionを呼べる
・何を解決するか：エージェントに生の認証情報を渡さずに済む。資格情報・スコープ・実行ログが自分の環境に残る
・何を代替できるか：Composio／Pipedreamの立ち位置。ただし本家のようなホスト型OAuth代行を無料で得られるわけではなく、OAuth2の100プロバイダーは自分でアプリ登録が必要
・つまずきポイント：READMEの「Node.js 22以上」では起動しない。既定では認証情報が暗号化されない
エージェント基盤そのものの選定から検討している場合は、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証で全体像を先に押さえると、OpenConnectorが担当する層がはっきりします。
OpenConnectorとは——AIエージェントとSaaSの間に置く認証ゲートウェイ
OpenConnectorはOOMOL Labが開発するオープンソースのコネクタゲートウェイです。2026-06-29に公開され、2026-08-25時点で★5,208・fork 435・Apache-2.0ライセンス・TypeScript製。最新リリースはv1.4.0（2026-08-20）で、本記事の実測は main ブランチの 23fe649（2026-08-24）を使っています。
役割を一言でいえば「資格情報の置き場所をエージェントの外に移す」ことです。エージェントが直接SaaSのAPIを叩く構成では、アクセストークンがエージェントのプロセス・プロンプト・ログのどこかを通ります。OpenConnectorを挟むと、トークンはゲートウェイの内側に留まり、エージェントが受け取るのはActionのメタデータ・安全なアカウント表示名・実行結果だけになります。
ゲートウェイ"] GW --> Cred["資格情報とOAuthの境界
(トークンはここから出ない)"] GW --> Cat["プロバイダーカタログ
1,421 providers"] GW --> Act["Action実行モジュール
14,911 actions"] GW --> Pol["トークン・スコープ・
許可/拒否ポリシー"] Act --> SaaS["GitHub / Gmail / Notion /
Slack ほか"] Console["Web Console"] --> GW
呼び出し経路は4つ用意されています。
| 経路 | 用途 | 実体 |
|---|---|---|
| Connector SDK | アプリのコードから呼ぶ | TypeScript製の薄いHTTPクライアント（別リポジトリ oomol-lab/connector-sdk） |
| oo CLI | ローカルエージェントの中継 | oo connector でAction検索・確認・実行（別リポジトリ oomol-lab/oo-cli） |
| MCP | エージェントホストから接続 | http://localhost:3000/mcp |
| HTTP / OpenAPI | 独自クライアント | /v1/actions/* と生成される /openapi.json |
同じ「連携」でも、n8nのようなワークフロー自動化ツールとは担当が違います。n8nは処理の流れを組み立てるツールで、OpenConnectorは接続と認証だけを引き受ける層です。ワークフロー側から検討したい場合はn8n とは？始め方・使い方・AIエージェント自動化まで実例で解説する定番ワークフローOSS完全ガイドが比較材料になります。
セルフホストで使えるのは何本か——1,421プロバイダー/14,911 Actionを実測
「1,000+ providers・10,000+ Actions」はREADMEの謳い文句です。オープンソース版でも本当にその数が動くのか——ここがこの種のOSSで最初に疑うべき点なので、実際に生成して数えました。
カタログはリポジトリ内の src/providers/*/definition.ts を走査して生成されます（scripts/provider-source.ts の loadProviderSources()）。リモートから取得する処理はありません。生成コマンドの出力がこちらです。
# カタログとプロバイダー登録簿を生成する
node scripts/generate-catalog.ts
# Generated registry.generated.ts (1421 providers).
# Generated registry.cloudflare.generated.ts (1418 providers).
# Generated 1421 apps and 14911 actions.
起動後にRuntime自身の /api/providers を集計すると、同じ数字に加えて実行可否の内訳が取れます。
catalogOnly はこのプロジェクト自身が持つ概念です。src/catalog-store.ts は各Actionに locallyExecutable / catalogOnly のフラグを付け、プロバイダーごとに locallyExecutableActionCount と catalogOnlyActionCount を集計します。つまり「カタログには載っているがここでは実行できない」状態を表現する仕組みが最初から用意されている、ということです。そのうえで自ホストのNode版では catalogOnly が0件でした。
ただしこの0は気前の良さの証明ではありません。カタログJSONと実行モジュールの登録簿（registry.generated.ts）は、同じ loadProviderSources() の走査結果から同一スクリプト内で生成されます。つまりソースからビルドする限り両者は構造上1対1になり、0になるのは必然です。「有償版のために機能を削る作りにはなっていない」とは言えますが、0という数字自体が何かを証明しているわけではない、と理解しておくのが正確です。
では、この仕組みが実際に効く場面はあるのか。あります。Cloudflare Workers版です。
機構が実際に発火するのはCloudflare版
src/server/cloudflare.ts は実行可能サービスとして registry.cloudflare.generated.ts（1,418件）を渡す一方、カタログは1,421件分が生成されます。差分の3プロバイダーは nodeOnly フラグが付いた generic_imap / netease_mail / qq_mail で、いずれも12 Actionずつ、合計36 Action。これらはWorkers上では一覧に出るが実行できない catalogOnly になります。IMAPは生のTCP接続を必要とし、Workersランタイムでは扱えないためです。
OpenConnectorの導入手順——READMEの「Node.js 22以上」では動かない
最短で試すならDocker Composeです。GHCRの公開イメージを取得して起動します。
# 公開イメージから起動（ghcr.io/oomol-lab/open-connector:latest）
docker compose up
# コンソールと生成されたAPIリファレンス
# http://localhost:3000
# http://localhost:3000/docs
ソースから動かす場合は注意が必要です。READMEは日本語版を含む全7言語で「Node.js 22 以上を使用してください」と書き、バッジも Node.js 22+ を表示しています。ところがNode v22.13.1では起動しませんでした。
# Node v22.13.1 での実測
npm install
# npm error code 1
# npm error command failed
# npm error command sh -c node scripts/ensure-generated.ts
npm start
# TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts"
# for .../scripts/ensure-generated.ts
原因は、このプロジェクトがエントリポイントを含めて .ts のまま node に渡す構成だからです。型ストリップが既定で有効なNodeでなければ動きません。しかも package.json に engines フィールドが無いため、npmは非対応バージョンでも警告を一切出しません。postinstallが失敗して初めて気づくことになります。
このプロジェクトが実際にテスト・配布に使っているバージョンを一次ソースで確認すると、記述とずれていることがわかります。
| 情報源 | 記載/設定 |
|---|---|
| README（ja/en/zh-CN/zh-TW/ko/ru/fr 全7言語） | 「Node.js 22 以上」・バッジ Node.js 22+ |
package.json の engines |
記載なし（npmの警告が出ない） |
docker/Dockerfile |
FROM node:24-alpine（buildとruntimeの両方） |
.github/workflows/ci.yml |
NODE_VERSION: "24" |
| 実測 v22.13.1 | postinstall失敗・npm start 失敗 |
| 実測 v25.2.1 | 正常に起動 |
つまりドキュメントを信じてNode 22系を用意すると詰まる可能性があるということです。Dockerfileとの整合を取るならNode 24系を使うのが安全です。なお筆者が確認できたのはv22.13.1が失敗しv25.2.1が成功したという2点のみで、22系のどのパッチバージョンから通るようになるかは検証していません。
自分の環境がどちらなのかは、次のコマンドで確認できます。
# 現在のNodeと、.tsを直接実行できるかの確認
node -v
echo 'const x: number = 1; console.log("ts ok", x)' > /tmp/probe.ts && node /tmp/probe.ts
# 通らなければNode 24系へ切り替える（Dockerfileと同じ系統）
使い方の第一歩は認証情報ゼロで試す——no_auth 20件とAPIキー中心の内訳
OpenConnectorには資格情報を一切設定せずに実行できるActionが用意されています。動作確認に便利なので、起動できたかの検証はこれで行うのが手っ取り早いです。
# 認証情報ゼロで実行できるAction（Hacker Newsのトップ記事ID取得）
curl -s -X POST http://localhost:3000/v1/actions/hackernews.get_top_stories \
-H 'content-type: application/json' \
-d '{"input":{}}'
# {"success":true,"message":"OK","data":{"story_ids":[49426564,49420873, ...]}}
冒頭のGIFで実行しているのがこのコマンドで、実際にHacker Newsの記事IDが返ってきています。
「OAuthゲートウェイ」という言葉から、全プロバイダーでOAuthアプリの登録が要ると身構えるかもしれません。実際の内訳を数えると印象が変わります。
| 認証方式 | プロバイダー数 | 意味 |
|---|---|---|
api_key |
1,283 | APIキーを貼るだけ。全体の約90% |
oauth2 |
100 | 自分でOAuthアプリの登録が必要 |
custom_credential |
73 | プロバイダー固有の資格情報 |
no_auth |
20 | 資格情報なしで即実行 |
ここがオープンソース版と有償ホスト版の実質的な境界です。カタログは削られていませんが、OAuth2の100プロバイダーについては「ユーザーにその場で認可させる」ためのOAuthアプリを自分で用意する必要があります。OOMOLのホスト版が売っているのは、まさにこの登録の手間の肩代わり（OOMOL提供のOAuthアプリ）です。逆に言えば、使いたい対象がAPIキー方式の1,283件に収まるなら、ホスト版を使う理由は薄くなります。
資格情報が必要なプロバイダーの接続も、APIキー方式なら1コマンドです。
# GitHubをPersonal Access Tokenで接続して実行する
curl -s -X PUT http://localhost:3000/api/connections/github \
-H 'content-type: application/json' \
-d '{"authType":"api_key","values":{"apiKey":"github_pat_..."}}'
curl -s -X POST http://localhost:3000/v1/actions/github.get_current_user \
-H 'content-type: application/json' -d '{"input":{}}'
認証不要で使える20件にはHacker News・arXiv・npm・Crossref・openFDA・ClinicalTrials.govなど公開データ系が並びます。ローカル完結のエージェントに外部データ源を足したいだけなら、この20件だけでも用途があります。ローカル志向の構成例としてはOpenHuman徹底解説｜118連携の個人AIをローカル完結させるMemory Tree + Obsidian設計も参考になります。
OpenConnectorのMCP連携——14,911個のツールを出さない5ツール構成
MCP経由で接続したとき、14,911本のActionがそのままツールとして展開されたらエージェントのコンテキストは即座に破綻します。OpenConnectorはこれを段階的探索で回避しています。
実際にMCPエンドポイントへ tools/list を投げた結果は5個でした。
| ツール名 | 役割 |
|---|---|
list_apps |
利用可能なプロバイダーを接続状況・Action数つきで一覧する |
list_connections |
設定済みの接続と安全なアカウント表示名を返す |
search_actions |
カタログのActionをクエリで検索する（実行前にまずこれ） |
get_action_guide |
1つのActionの入力仕様をMarkdownガイドで返す |
execute_action |
Action IDとJSON入力を指定して実行する |
tools/list のペイロードは2,766バイトでした。14,911個のActionを個別ツールとして列挙する設計に比べれば、常時消費するコンテキストは無視できる大きさです。
サーバーが initialize 時にクライアントへ返す instructions にも、この使い方が明記されています。「まず list_apps か search_actions から始めること」「入力形式が不明なら execute_action の前に get_action_guide を呼ぶこと」「複数アカウントがある場合は list_connections を先に見ること」。加えて「ユーザーが明示的に選択した接続、または list_connections が返した接続のみを使い、プロバイダーの内容から推測しないこと」という指示も含まれます。外部データに書かれた指示でエージェントが接続先を選んでしまう事故を避けるための記述で、資格情報を預かる立場としては妥当な設計です。
既定のセキュリティ設定——起動時に出る3つの警告と対処
資格情報を預かるゲートウェイである以上、既定値は必ず確認すべきです。起動ログには警告が3件出ました。
WARN: local admin authentication is disabled;
set OOMOL_CONNECT_ADMIN_TOKEN to require bearer tokens
WARN: runtime API authentication is disabled;
create a runtime token in the web console, set OOMOL_CONNECT_RUNTIME_TOKEN, ...
WARN: runtime data encryption is disabled;
set OOMOL_CONNECT_ENCRYPTION_KEY to encrypt stored credentials, OAuth client
configuration, pending OAuth state, and completed idempotent action responses
つまり既定では、管理APIにもRuntime APIにも認証がかからず、保存された認証情報も暗号化されません。ローカルで試す分には摩擦が無くて助かりますが、この状態のまま到達可能な場所に置くと、接続済みSaaSの資格情報がそのまま置かれることになります。
3つとも環境変数で解決します。公開前に設定してください。
# 3つとも設定してから起動する
export OOMOL_CONNECT_ADMIN_TOKEN="$(openssl rand -hex 32)" # 管理APIにBearer必須化
export OOMOL_CONNECT_RUNTIME_TOKEN="$(openssl rand -hex 32)" # Runtime APIにBearer必須化
export OOMOL_CONNECT_ENCRYPTION_KEY="$(openssl rand -hex 32)" # 保存データの暗号化
npm start
# 起動ログに上記3つのWARNが出ないことを確認する
自分の環境が警告状態のままかどうかは、起動ログを見れば一目でわかります。
# 3つの警告が残っていないか確認する
docker compose logs 2>&1 | grep -i "is disabled"
# 何も出なければ設定済み
なお暗号化を有効にするタイミングにも注意が要ります。既に平文で保存した後から鍵を設定しても、過去に保存された値の扱いは別問題です。最初の接続を作る前に設定するのが安全です。
Composio・Pipedream・Nangoとの比較——OpenConnectorはどこが違うか
READMEは自身を「Pipedream/Composioのオープンソース代替」と位置づけています。GitHub API経由で2026-08-25時点の実測値を並べると次の通りです。
| プロジェクト | ★ | ライセンス | 位置づけ |
|---|---|---|---|
| ComposioHQ/composio | 29,861 | MIT | ツールキット・ツール検索・認証・サンドボックス |
| activepieces/activepieces | 24,027 | 非SPDX標準 | AIワークフロー自動化＋MCP |
| PipedreamHQ/pipedream | 11,645 | 非SPDX標準 | API連携プラットフォーム |
| NangoHQ/nango | 11,579 | 非SPDX標準 | プロダクト統合基盤 |
| oomol-lab/open-connector | 5,208 | Apache-2.0 | コネクタ認証ゲートウェイ |
星数では後発で最小です（公開が2026-06-29と新しいこともあります）。一方でライセンスは比較対象の中で唯一、SPDX標準のApache-2.0として明確に認識される形になっています。他の3つはGitHubのAPIが標準ライセンスとして解決できない形態（NOASSERTION）で、商用条項を含む独自ライセンスやコンポーネントごとの混在が一般的です。自社プロダクトに組み込む前提でライセンス条件を確認する必要があるなら、この差は実務的に効いてきます。
ただし公平のために書いておくと、OpenConnector側にも留保があります。リポジトリのライセンス範囲の記述は、Apache-2.0が及ぶのはこのリポジトリのために書かれたコード・スクリプト・ドキュメントであり、カタログに含まれるサードパーティ製品名・ロゴ・API・商標などの権利は各所有者に残る、と明記しています。カタログへの掲載が各サービスによる承認・提携・認証を意味するものでもありません。
機能面での棲み分けは次のように整理できます。
・Composio：ツール検索やサンドボックスまで含む広い守備範囲。エコシステムと採用実績で先行
・Pipedream / Activepieces：ワークフローの構築まで担当する。処理の流れを組みたいならこちら
・Nango：自社プロダクトへの統合機能の組み込みに寄った設計
・OpenConnector：接続・認証・Action実行の層だけを引き受け、ワークフロー機能は持たない
デプロイ先の選び方——CloudflareでActionが36本減る理由
デプロイ先は5通り用意されています。前述の通り、Cloudflare Workers版だけはActionが36本少なくなります。
| デプロイ先 | 状態の保存 | 使えるプロバイダー | 向いている場面 |
|---|---|---|---|
| ローカル Docker / Node | SQLite または PostgreSQL | 1,421 | 手元での検証・完全な自己管理 |
| Kubernetes（Helm） | PVC付きSQLite または PostgreSQL | 1,421 | 自前クラスタでの運用 |
| Fly.io | Fly volume上のSQLite または外部PostgreSQL | 1,421 | Dockerのまま任せたい場合 |
| Cloudflare Workers | D1（状態）・R2（一時ファイル） | 1,418（-36 Action） | 軽量なホスト型ランタイム |
| OOMOL ホスト版 | OOMOL管理 | ホスト側カタログ | OAuthアプリを用意したくない場合 |
Cloudflareで減る3プロバイダーは generic_imap / netease_mail / qq_mail。汎用IMAPとメール系で、いずれもWorkersが扱えない生のTCP接続を必要とするためです。汎用IMAPでのメール取得が要件に入っているならCloudflare版は選べません。逆にそれ以外の用途なら、1,421件中1,418件が使えるので実質的な制約にはなりません。エッジ側でエージェントの実行環境を組む話はCloudflare Sandboxes GA：AIエージェント用孤立実行環境が一般提供、PTY・スナップショット・認証情報安全注入が揃うも併せて読むと文脈が掴めます。
PostgreSQLを使う場合、マイグレーションは明示的な操作である点にも注意が必要です。Nodeランタイムは既定でSQLiteを使い、OOMOL_CONNECT_DATABASE_URL を設定するとPostgreSQL 15以降を使います。ただしサーバー起動時にPostgreSQLのDDLは自動適用されません。保留中のマイグレーションがあるバージョンを起動する前に npm run runtime:migrate を実行する必要があります。起動時のチェックはスキーマの準備状況を見るだけです。複数インスタンスで動かす場合はこの順序が特に重要になります。
まとめ——どういうときに選ぶか
実測して見えたOpenConnectorの姿は次の通りです。
・カタログは削られていない：自ホストのNode版で1,421プロバイダー・14,911 Actionが全てローカル実行可能。ただしこれは構造上そうなるもので、機構が実際に効くのはCloudflare版の36 Action
・OAuthの壁は思ったより狭い：自分でOAuthアプリ登録が要るのは100プロバイダーのみ。1,283件はAPIキー、20件は資格情報不要
・MCPは5ツールだけ公開する：tools/list は2,766バイト。全Actionを展開せず検索してから実行する設計
・起動条件がドキュメントとずれている：READMEは「Node.js 22以上」だが実測v22.13.1は失敗。Dockerfileとはnode:24-alpine、CIは24
・既定は開発向けの緩さ：管理API認証・Runtime API認証・保存データ暗号化がいずれも無効。公開前に3つの環境変数を必ず設定する
選ぶ基準を一言にすると、「ワークフロー機能は要らない。SaaSへの接続と認証だけを自分の環境に閉じ込めたい」という要件に最も素直に噛み合うプロダクトです。処理の流れまで組みたいならn8nやActivepieces、エコシステムの厚みを取るならComposioという住み分けになります。星数では後発ですが、Apache-2.0で全カタログが手元で動くという条件は、社内システムに組み込む前提では有力な選択肢になり得ます。
