---
author: OOMOL
author_url: https://oomol.com/ja/about/
title: OOMOL vs Composio
description: OOMOL と Composio を、ホスト型アプリ操作、自部署、Cloudflare デプロイ、接続ランタイムの管理権限で比較します。
lang: ja
canonical_url: https://oomol.com/ja/docs/oomol-vs-composio/
markdown_url: https://oomol.com/ja/docs/oomol-vs-composio.md
---

# OOMOL vs Composio

OOMOL hosting で速く始め、後から接続ランタイムを自分たちで管理できる道を残します。

## 要点

Composio と OOMOL はどちらも、AI Agent や製品バックエンドから GitHub、Gmail、Slack、Notion などを呼び出せるようにします。違いは、アプリ操作がプロトタイプから製品インフラに移るときに出ます。

Composio は、Composio のホスト型プラットフォーム内で Agent のツール呼び出し、管理された認証、セッション、MCP、従量課金のツール呼び出しを試すだけなら足ります。この道の境界も明確です。Composio の公開された製品導線はホスト型プラットフォームが中心で、VPC / On-Prem は Enterprise の個別見積もりとして示されています。

ホスト型で早く立ち上げつつ、将来のランタイム管理権限を残したいなら OOMOL を選びます。OOMOL には同じ provider/action モデルを使う 3 つの道があります。OOMOL hosting、Cloudflare へのデプロイ、自分の環境での OpenConnector 自部署です。同じアプリ操作層を SDK、MCP、HTTP/OpenAPI、CLI、Web Console から使えます。

大きな違いはランタイムの管理権限です。OOMOL は管理された接続経路と、公開されたオープンなランタイム経路の両方を持ちます。最初は OOMOL hosting で運用負担を下げ、より強い境界が必要になったら OpenConnector を Cloudflare や自分たちの環境に移せます。

## 早見表

| 観点 | Composio | OOMOL |
| --- | --- | --- |
| 向いている場面 | Composio のツールプラットフォーム内に収まるプロトタイプ、デモ、Agent 実験。 | ホスト型で早く出し、後から接続ランタイムを自分たちで管理したいチーム。 |
| 本番経路 | 公開経路は Composio のホスト型プラットフォームが中心。VPC / On-Prem は Enterprise の個別見積もり。 | OOMOL hosting、Cloudflare、自部署 OpenConnector が同じ provider/action モデルを使います。 |
| 自部署 | プライベートデプロイは Enterprise の商談経路として示されています。 | 公開された自部署経路：ローカル Docker/Node、Cloudflare Workers、または自社インフラ。 |
| Cloudflare | 公開ドキュメントには、Cloudflare へ自分でデプロイする手順はありません。 | Workers でランタイムを動かし、D1 に状態を置き、R2 で一時ファイルを中継し、Static Assets でコンソールを出す公開経路があります。 |
| アプリ操作層 | Composio のセッション、native tools、MCP、管理プラットフォームから toolkits を公開します。 | オープンソースのアプリ操作層：サービス定義、アクション schema、必要 scope、利用可能なローカル実行 handler。OOMOL hosting、Cloudflare、自部署 OpenConnector で同じ契約を使えます。 |
| Agent インターフェース | native tools、provider packages、MCP セッション、SDK / API。 | Connector SDK、oo CLI、MCP、HTTP/OpenAPI、Web Console が同じアクション契約を使います。 |
| 認証モデル | 既定は managed apps。カスタム認証設定で自前 OAuth app、API key、bearer token、ブランド、scope、quota を扱えます。 | 認証と credentials を OOMOL に任せるなら OOMOL hosting。自分たちの境界に置くなら OpenConnector ランタイム。 |
| コストと運用 | 公開プランはツール呼び出し量に基づきます。Enterprise は個別見積もりです。 | OOMOL hosting は運用負担を減らします。Cloudflare と自部署では、ランタイムのコストと管理を自社インフラ側に置けます。 |

## OOMOL の 3 つの道

OOMOL は、同じ接続モデルを複数の運用形態で使えるようにします。

| 道 | 使う場面 | 管理できるもの |
| --- | --- | --- |
| OOMOL hosting | アプリ操作を早く追加し、運用負担を減らしたい。 | 製品コード、ユーザー、接続済みアカウント、アクション呼び出し。認証、credentials、接続運用は OOMOL が扱います。 |
| Cloudflare デプロイ | チームが Cloudflare 上で運用する軽量ランタイムが欲しい。 | Workers デプロイ、D1 の状態、R2 の一時ファイル、Static Assets のコンソール、access token、ポリシー、provider 設定。 |
| 自部署 OpenConnector | 接続サービス、Web Console、credentials、データを自分たちの環境に置きたい。 | ランタイムコード、ストレージ、credentials、アクションポリシー、ログ、OAuth apps、運用境界。 |

これは製品チームにとって実務的な違いです。初期は OOMOL hosting で接続基盤を持たずに始められます。接続層が製品インフラになったら、同じ provider/action の語彙のまま Cloudflare や自部署 OpenConnector に移れます。

## ホスト型ツール基盤とランタイム選択

Composio は、ホスト型の Agent ツールプラットフォーム内で完結するチームに向きます。セッションを作成し、ユーザーを認証し、ツールを取得して Agent に渡すか MCP で接続します。Managed apps はプロトタイプや内部ツールの準備を軽くします。カスタム認証設定はブランド、scope、quota の要件を扱えます。

制限はランタイム境界です。アカウント、scope、アクション制限、credentials の位置、ログ、デバッグ方法は、Enterprise のプライベート経路に進まない限り Composio のホスト型プラットフォームを中心に残ります。

OOMOL は、ホスト型の道と自主管理の道を両方必要とするチームに向けています。ホスト型 gateway は接続インフラを運用せずに立ち上げるための経路です。OpenConnector は確認可能なランタイムを提供します。サービスカタログ、アクション契約、credentials 境界、MCP と HTTP/OpenAPI、runtime token、アクションの許可/禁止ポリシー、一時ファイル中継、脱敏された実行ログを含みます。Web Console もこのランタイムの一部です。

本番 Agent には、ツールにアクセスできるだけでは足りません。どのアカウントで実行するか、どの scope が必要か、どのアクションを許可するか、credentials をどこに置くか、呼び出しをどう記録し、どう制限するかを決める必要があります。OOMOL では、それを OOMOL hosting に任せるか、チームが運用するランタイムに置くかを選べます。

## Cloudflare が重要な理由

自部署は、追加の VM やコンテナホストの運用を意味しがちです。多くのチームは、もっと軽い管理経路を求めます。

OpenConnector の Cloudflare 経路はその負担を下げます。接続ランタイムを Cloudflare Workers で動かし、状態を D1 に置き、一時ファイルを R2 で中継し、コンソールを Static Assets で提供できます。これは公開され、文書化された経路です。

ランタイム管理権限が重要なとき、OOMOL を選ぶ実用的な理由になります。速度が必要な間は OOMOL hosting を使い、より強い管理が必要になったらオープンソースのランタイムを Cloudflare に置けます。アプリ操作モデルは同じままです。

## Agent 向けのアプリ操作

OpenConnector は、第三者サービスの機能を Agent と製品バックエンドが発見して呼び出せるアプリ操作としてまとめます。

これらのアプリ操作は OOMOL hosting と自部署経路の両方で使えます。OOMOL のアプリ操作層はオープンソースで、サービス定義、アクション schema、必要 scope、利用可能なローカル実行 handler を含みます。同じアクション契約を OOMOL hosting、Cloudflare、自部署 OpenConnector で使えます。

アプリ操作層には次が含まれます。

- サービス定義と認証モデル。
- `gmail.search_threads` や `github.get_current_user` などの action ID。
- 入力と出力の schema。
- 必要 scope と provider 側の権限。
- 利用可能なローカル実行 handler。
- MCP の発見ツールと実行ツール。
- カスタムクライアント向けの HTTP/OpenAPI。
- デバッグ用の実行メタデータとログ。

Agent には構造化された契約が必要です。アクションが何をするか、どんな入力を受け取るか、どのアカウントで実行されるか、どの scope が関係するかを見られるべきです。製品結果に影響するなら、開発者も実装を確認できる必要があります。

Composio も Agent のツール呼び出しを扱います。ドキュメントには native tools、MCP セッション、認証、ツール検索、workbench があります。制限はデプロイとランタイム境界です。OOMOL は同じ接続戦略を OOMOL hosting、Cloudflare、自部署 OpenConnector にまたがって使えます。

## Composio で足りる場合

接続ランタイムがまだ戦略的な境界ではないなら、Composio で足りる場合があります。

向いているのは次の場面です。

- プロトタイプ、デモ、内部実験を作っている。
- Composio のホスト型セッションと native tool モデルを使いたい。
- ツール呼び出し量に基づく課金を受け入れられる。
- 接続ランタイムを直接確認したり運用したりする必要がない。
- OOMOL hosting から自部署へ進む経路が不要。
- 将来のプライベートデプロイは Enterprise VPC / On-Prem の商談経路で扱える。

この道は初期には速いです。制限は管理境界です。今はホスト型で始め、後から公開された管理経路を持ちたいなら、OOMOL のほうが合います。

## OOMOL が合う場合

接続層が製品インフラの一部になるなら、OOMOL を使います。

OOMOL が合うのは次の場面です。

- OOMOL hosting から始め、Cloudflare や自部署への道を残したい。
- provider credentials を選んだランタイム境界の中に置きたい。
- サービス定義、schema、scope、アクション実行を確認したい。
- Enterprise 契約の前に自部署を検証したい。
- Cloudflare Workers + D1/R2 が有力なデプロイ先になる。
- Agent、製品バックエンド、スクリプト、MCP クライアントが同じアクション契約を呼び出すべき。
- オープンソース経路とホスト型経路で同じ provider/action モデルを使いたい。

## FAQ

### Composio は自部署できますか？

Composio の公開価格ページでは、VPC / On-Prem が Enterprise の個別見積もりとして示されています。Composio はその商談経路でプライベートデプロイを提供する可能性があります。

ここで比較しているのは、公開されたセルフサービスの経路です。OOMOL は OpenConnector の接続ランタイム、アプリ操作層、ローカルランタイム、Cloudflare デプロイ、MCP/HTTP/OpenAPI、Web Console をオープンソースの自部署経路として公開しています。

### OOMOL はオープンソースを求めるチームだけのものですか？

いいえ。OOMOL hosting は、認証、credentials、接続運用を OOMOL に任せて早く始めたいチームのための経路です。コード、データ、運用の管理が重要になったら、OpenConnector と Cloudflare デプロイを使えます。

### OpenConnector は認証 gateway だけですか？

いいえ。OpenConnector は credentials 境界を扱うだけでなく、サービス定義、アクション schema、必要 scope、利用可能なローカル実行 handler、MCP tools、HTTP/OpenAPI endpoint、runtime token、許可/禁止ポリシー、一時ファイル中継、実行ログも提供します。

### OpenConnector の App Actions はどこがオープンソースですか？

接続ランタイムとアプリ操作層がオープンソースです。サービス定義、アクション schema、必要 scope、利用可能なローカル実行 handler が含まれます。

第三者 API、provider の商標、ロゴ、ブランド素材、provider ドキュメント、provider がホストするサービスは OpenConnector のライセンス範囲外です。一部のアクションはカタログ上の宣言だけの場合や、provider 側 API に依存する場合もあります。

### いつ OOMOL hosting を使うべきですか？

アプリ操作を早く追加し、運用負担を減らし、アプリケーションコードに credentials を触らせたくないときに使います。接続ランタイムを自分たちで確認、デプロイ、制限、デバッグ、運用する必要が出たら、Cloudflare または自部署 OpenConnector に移ります。

## 判断ルール

Composio のホスト型ツール/セッションモデルでプロトタイプを作ることが優先なら、Composio で足りる場合があります。

今はホスト型で立ち上げ、後から接続ランタイムを自分たちで管理できる選択肢を残したいなら、OOMOL から始めます。

OOMOL は、速く始めるためのホスト型アプリ操作、ランタイム管理のための OpenConnector、軽量デプロイのための Cloudflare 経路を提供し、それらを同じ provider/action モデルでつなぎます。

## 次のステップ

今の段階に合う OOMOL の経路を選んでください。

1. 認証、credentials、接続運用を任せたいなら、OOMOL hosting と Connector SDK を使います。
2. チームが管理する軽量ランタイムが必要なら、OpenConnector を Cloudflare Workers にデプロイし、D1/R2 を使います。
3. 接続サービス、Web Console、credentials、ポリシー、ログを自分たちの環境に置きたいなら、OpenConnector を自部署します。

- [Connector SDK](/ja/docs/connector-sdk/)
- [OpenConnector セルフホスティングガイド](/ja/docs/openconnector-self-hosting/)
- [OpenConnector](https://github.com/oomol-lab/open-connector)