--- author: OOMOL author_url: https://oomol.com/ja/about/ datePublished: 2026-09-17 title: OpenConnector・Composio・Nango・Pipedream：どこまでオープンソースなのか description: 4つのAgent連携ツールを公開コード、セルフホスト、ライセンスで比較。providerの追加と、OOMOL SaaSから自社環境への移行も解説します。 lang: ja canonical_url: https://oomol.com/ja/blog/openconnector-comparison/ markdown_url: https://oomol.com/ja/blog/openconnector-comparison.md --- ![OpenConnector、Composio、Nango、Pipedreamの公開コードと運用方式を比較](/blog/openconnector-comparison/ja-cover.webp) AI AgentをGmail、Notion、Slackにつなぎ、初めて処理が成功すると、できることが一気に広がります。質問に答えるだけだった助手が、メールを探し、文書を更新し、実際の作業を進められるようになります。 使い続けると、別の疑問も出てきます。必要な操作がなければ追加できるのか。呼び出しが失敗したら、どこまで調べられるのか。顧客から認証情報を自社環境に置くよう求められたら、接続サービスも移せるのか。 ここで重要になるのが、公開コードの範囲と、自分たちで運用できる部分です。OpenConnector、Composio、Nango、Pipedreamはいずれもアプリ連携に使えますが、公開範囲やライセンス、デプロイ方法は同じではありません。 ## 公開されているのは、どの部分か SDK、コネクター、実行環境はそれぞれ役割が異なります。 - **SDK** は引数をまとめてリクエストを送り、結果を受け取ります。ソースから確認できるのは、クライアント側の呼び出し処理です。 - **コネクターの実行コード** は、操作を外部APIへのリクエストに変換します。引数の変換やレスポンス処理を確認し、拡張できます。 - **コネクター実行環境** は操作を実行し、認証情報、権限、実行ログなどを管理します。このコードとデプロイ手順が公開されていれば、チームで運用する道が開けます。 ![クライアントからコネクター実行環境を経由して外部APIにアクセスする概念図](/blog/openconnector-comparison/ja-layers.webp) *図1：コネクターの実行コードは実行環境の中にあります。具体的な実装は製品ごとに異なります。* SDKが公開されていても、ゲートウェイのソースまで公開されているとは限りません。コネクターを編集できることと、プラットフォーム全体を自分で動かせることも、別々に確認する必要があります。 ## 4製品の比較 | 製品 | 主な公開コード | セルフホスト | 確認したい範囲 | | --- | --- | --- | --- | | **OpenConnector** | Connector SDK、oo CLI、ゲートウェイ、provider定義、操作の実行コード、Web Console | Docker、Node.jsの公開手順があり、Cloudflareにも対応 | 本体はApache-2.0、SDKとCLIはMIT。操作ごとの実行コードと認証要件を確認 | | **Composio** | 公開メインリポジトリにはSDK、CLI、フレームワーク用アダプター | 企業向けセルフホストとプライベート環境の選択肢 | SDKのMITライセンスをゲートウェイ実装にそのまま適用できるわけではない | | **Nango** | 連携プラットフォームと連携関数のコード | 無料版とEnterprise版のセルフホスト | メインリポジトリはElastic License 2.0。無料版の機能は限定される | | **Pipedream** | コンポーネント、ドキュメント、関連パッケージ | 通常はPipedreamのホスト環境で実行 | メインリポジトリはSource Available。コンポーネント公開だけでは全体のセルフホストを意味しない | 出典：[OpenConnector](https://github.com/oomol-lab/open-connector)、[Composioリポジトリ](https://github.com/ComposioHQ/composio)、[Composioのデプロイ方式](https://composio.dev/mcp-gateway)、[Nangoセルフホスト](https://nango.dev/docs/guides/platform/self-hosting)、[Pipedreamコンポーネント](https://pipedream.com/docs/components)。 ## 必要なproviderがまだない場合 新しい顧客管理システムを導入し、Agentに顧客検索や対応履歴の更新を任せたいとします。ただし、既存のカタログにはそのサービスがありません。 このとき役立つのは、ゲートウェイ側に **provider** を追加できることです。新しいサービスの認証方式、操作の引数、実行処理を定義します。SDKやCLIは従来の呼び出し方を使うため、通常はそれらのソースを変更する必要はありません。 OpenConnectorには3つの進め方があります。 - **自分で実装する**：自社のゲートウェイにproviderを追加し、必要な時期に利用します。 - **PRを送る**：実装をプロジェクトに貢献し、ほかの利用者も使えるようにします。 - **issueを作る**：必要なサービスと操作を伝え、私たちのチームに対応を依頼します。 こうしたproviderや操作の追加では、通常 **24〜36時間以内に関連機能をマージ**しています。これは普段の対応ペースであり、APIの複雑さ、テスト用アカウント、外部サービスの認証条件によって変わることがあります。 カタログにないサービスにも、実装を進める方法があります。自分たちで追加する場合も、メンテナーと協力する場合も、既存の呼び出しツールを活用できます。[provider追加ガイド](https://github.com/oomol-lab/open-connector/blob/main/CONTRIBUTING.md#adding-providers) · [issueの作成](https://github.com/oomol-lab/open-connector/issues) 公開範囲には **Connector SDK、oo CLI、ゲートウェイ、操作定義と実行コード、Web Console** が含まれます。アプリからはSDK、コマンドラインからは`oo connector`、AgentからはMCP、ほかのクライアントからはHTTP/OpenAPIを利用できます。SDKとCLIはOOMOLのホスト環境にもセルフホスト環境にも接続できます。[開発者ツール](https://github.com/oomol-lab/open-connector#developer-tools) コードは [OpenConnector](https://github.com/oomol-lab/open-connector)、[Connector SDK](https://github.com/oomol-lab/connector-sdk)、[oo CLI](https://github.com/oomol-lab/oo-cli) に分かれて管理されています。クライアントから実行までを確認でき、接続アカウント、操作権限、機密情報をマスクしたログを自社環境で管理できます。 ![OpenConnectorのサービス一覧とOAuth設定画面。英語版の公式スクリーンショット](/blog/openconnector-comparison/catalog-en.webp) *図2：[公式リポジトリ](https://github.com/oomol-lab/open-connector/blob/main/assets/open-console-en.jpg)の英語版画面。名称や件数は撮影時点のもので、現在の対応数を保証するものではありません。* providerを追加した後も、アプリとAgentは同じ入口から呼び出します。採用前には、必要な操作の実行コード、引数、外部サービスの認証条件を確認してください。 Composioのメインリポジトリは、PythonとTypeScriptのSDK、CLI、アダプターを収めたSDK monorepoです。クライアントの挙動を調べるのに役立ちますが、ゲートウェイの内部実装まで公開されていることの根拠にはなりません。[Composioリポジトリ](https://github.com/ComposioHQ/composio) 一方、Composioには企業向けセルフホストとプライベートデプロイがあります。「クラウドでしか使えない」という説明は不正確です。公開ソースから始められる範囲、企業契約が必要な範囲、デプロイ後に変更できる部分を分けて比較します。[Composio MCP Gateway](https://composio.dev/mcp-gateway) Nangoはプラットフォームのコードを公開し、セルフホストにも対応しています。無料版は主に認証とAPIプロキシを提供し、関数、同期、Webhook、MCPなどの全体機能はCloudまたはEnterpriseの対象です。[Nangoの説明](https://nango.dev/blog/best-self-hosted-api-integration-platforms-for-ai-agents) Pipedreamでは、コンポーネントを読んだり、自作したり、PRで貢献したりできます。ただし通常の実行先はPipedreamのサーバーレス基盤です。操作の編集とプラットフォーム全体の運用は、別の能力として評価する必要があります。[Pipedreamの説明](https://pipedream.com/docs/components) ## ライセンスも範囲ごとに確認する GitHubでコードが見られても、利用条件が同じとは限りません。 | 対象コード | 公開ライセンス | | --- | --- | | OpenConnector本体 | [Apache-2.0](https://github.com/oomol-lab/open-connector/blob/main/LICENSE.txt) | | Connector SDK | [MIT](https://github.com/oomol-lab/connector-sdk/blob/main/LICENSE) | | oo CLI | [MIT](https://github.com/oomol-lab/oo-cli/blob/main/LICENSE) | | Composioの公開SDK | [MIT](https://github.com/ComposioHQ/composio/blob/next/LICENSE) | | Nangoメインリポジトリ | [Elastic License 2.0](https://github.com/NangoHQ/nango/blob/master/LICENSE) | | Pipedreamメインリポジトリ | [Pipedream Source Available License](https://github.com/PipedreamHQ/pipedream/blob/master/LICENSE) | フォークの維持、再配布、外部向けサービスへの利用を考えるなら、対応する条項を先に確認します。OpenConnectorのライセンスはプロジェクト自身のコードを対象とし、外部APIの規約や認証要件、ブランドの権利を置き換えるものではありません。 ## 自分で運用するなら、保守も必要 セルフホストでは、実行環境の状態、直近の失敗、実行ログを見て、設定やコードを調整できます。 ![OpenConnectorの実行環境の状態、呼び出し推移、最近の呼び出しを表示した英語版画面](/blog/openconnector-comparison/overview-en.webp) *図3：[公式リポジトリ](https://github.com/oomol-lab/open-connector/blob/main/assets/overview-page-en.jpg)の画面例。数値は現在の規模や信頼性を示す指標ではありません。* 同時に、更新、バックアップ、鍵の管理、インフラの運用、一部サービスのOAuthアプリ登録も必要です。管理できる範囲が広がる分、その保守を担当する人も必要になります。 ## SaaSで始め、成長に合わせてセルフホストへ OOMOL SaaSとオープンソースのOpenConnectorは、コネクターの呼び出し層で共通の構造を持ちます。provider ID、操作ID、引数の契約が共通なので、実行場所が変わっても同じ操作の呼び出し方を使えます。[利用方式](https://github.com/oomol-lab/open-connector#usage-paths) まずSaaSで連携を動かし、事業の拡大や顧客の要件に応じてOpenConnectorを自社環境に置くことができます。SDKとCLIの接続先を切り替えれば、対応する操作の呼び出しや引数を再利用できます。 | 入口 | セルフホストへの切り替え | 再利用できるもの | | --- | --- | --- | | **Connector SDK** | `OpenConnector`クライアントに自社の`baseUrl`と実行用トークンを設定 | 対応する操作ID、入力、`execute`などの呼び出し方 | | **oo CLI** | `OO_CONNECTOR_URL`と、必要に応じて`OO_CONNECTOR_TOKEN`を設定 | `search`、`schema`、`run`などのコネクターコマンドと操作の引数 | 手順は [SDKガイド](https://github.com/oomol-lab/connector-sdk#self-hosted-runtime)と [CLIガイド](https://github.com/oomol-lab/oo-cli/blob/main/docs/self-hosted-connector.md)にあります。 新しい環境では、外部サービスのアカウント接続、OAuthアプリ、認証情報の設定が必要です。SaaSのチーム管理、プロジェクトユーザー、そのほかのホスト機能は個別に対応範囲を確認します。共通化されているのはコネクターの呼び出し層であり、すべてのアカウントや機能が自動移行するわけではありません。 評価するなら、日常的な操作をSaaSで実行し、次に同じSDKやCLIをセルフホスト環境につないで、同じ操作と引数を試してみてください。足りないサービスがあれば、providerの追加やissueの流れも確認できます。 早く導入しつつ、将来自分たちで運用する選択肢を残したいチームは、[OOMOLでアプリを接続](https://console.oomol.com/connections)するか、[デプロイガイド](/ja/docs/openconnector-self-hosting/)から実行環境を用意し、普段使う操作で検証できます。 --- *ロゴと画面画像は各プロジェクトの公式サイトまたはリポジトリに由来し、識別と比較のために使用しています。権利は各権利者に帰属します。概念図は本記事用に作成しました。*