OpenConnectorを自社運用する？OOMOLのホスティングを使う？まず業務を動かそう

Google、Zoom、monday.comをアプリやエージェントに接続するとき、「OpenConnectorはオープンソースだから、自分たちのゲートウェイを立てようか」と考えるかもしれません。

自社のゲートウェイには明確な価値があります。認証情報の保存先、許可する操作、呼び出しの記録方法を自分たちで決められます。ただし、サービスを起動した後にも、見落としやすい作業が残ります。各アプリの認証設定です。

早く機能を公開したい多くのチームには、まずOOMOLのホスティングを使い、SDKで業務に組み込む方法をおすすめします。 接続サービスや認証情報を自社インフラに置く必要がある場合や、ゲートウェイやコネクターの実装を変更したい場合は、OpenConnectorを自社運用してください。

段階的に進めることもできます。ホスティングで業務連携を動かしながら独自のOAuthアプリを準備し、準備が整ってから移行する方法です。

いま必要なものから選ぶ

現在の要件	おすすめの出発点
アプリを早く接続したい。外部ホスティングを利用できる	OOMOLのホスティング
接続を共有し、メンバーのアクセスと操作権限をまとめて管理したい	OOMOLのホスティングのチーム機能
独自のOAuthアプリを使う予定だが、設定や審査が終わっていない	ホスティングで始め、準備後に移行を検討
認証情報、ゲートウェイ、実行記録を自社インフラに保存する必要がある	OpenConnectorの自社運用
コネクターの変更、ゲートウェイのカスタマイズ、外向き通信の制御が必要	OpenConnectorの自社運用

企業規模も判断材料になりますが、まず考えたいのは、チームに必要な管理権限と、引き受けられる保守作業です。

自社運用ではOAuthの設定が必要になる

DockerでOpenConnectorを起動すると、接続ゲートウェイを利用できます。OAuth認可が必要なサービスにアクセスするには、それぞれの開発者コンソールで独自のOAuthアプリも作成します。

ここでは二つの認証情報を区別します。OAuthアプリのClient IDとClient Secretは、アプリを識別するためのものです。ユーザーがアカウントへのアクセスを許可した後に発行されるアクセストークンは、そのユーザーが認めたリソースにアクセスするために使います。

前者を先に準備し、後者はアカウントの認可を通じて取得します。

Googleでは、プロジェクトの作成、必要なAPIの有効化、OAuthクライアントの作成、コールバックURLの登録、要求する権限の選択などを行います。権限や用途によっては、アプリの確認手続きも必要です。GoogleのOAuth公式ドキュメント

ほかのOAuthサービスにも、それぞれ設定と配布のルールがあります。一つの接続なら対応しやすくても、複数のアプリを扱うと、クライアント設定、コールバックURL、認可スコープ、審査状況を個別に維持する必要があります。

社内テストと、多くの顧客への提供では要件が異なる場合もあります。自分のアカウントやテストユーザーから始められるサービスもあれば、用途に応じて管理者の承認や追加審査が必要なサービスもあります。提供元のコンソールとドキュメントを確認してください。

OpenConnectorはOAuth設定の保存、アカウント接続、操作の実行を提供します。独自のOAuthアプリを使う場合、アプリの作成と提供元の要件への対応はチームが担当します。手順はOAuthアプリ設定ガイドにあります。

ホスティングで業務連携に時間を使う

カレンダーの照会、メールの整理、プロジェクト記録の更新など、まず公開したい機能があるなら、それに必要な接続を動かすところから始められます。

管理済みOAuthアプリに対応する連携では、OOMOLが、各サービスでアプリを作成・維持する作業を減らします。自分のアカウントを接続し、必要な権限を許可する作業は引き続き必要です。API keyなど別の認証方式を使うサービスにも、対応する設定が必要です。

アカウント接続後は、OOMOLのホスティングが認証情報の保存、トークン更新、実際のアプリ呼び出しを担当します。バックエンドはSDKで接続を選び、パラメーターを送り、結果を受け取ります。提供元の生のトークンを業務コードやエージェントのプロンプトに入れる必要はありません。ホスティング版Connectorのガイド

図：二つの配置方法の呼び出し関係。ゲートウェイの場所と管理責任は異なりますが、外部アプリへのアクセスには提供元の認可とネットワーク接続が必要です。

複数人で使う場合は、チーム管理も利用できます。管理者はメンバーを管理し、接続ごとに許可する操作を設定して、その接続を使えるメンバーを決めます。

たとえば、同じメールアカウントに二つの接続を作れます。一方はメールの読み取りだけを許可し、情報を参照するメンバーに割り当てます。もう一方は送信を許可し、対外連絡の担当者だけに割り当てます。メンバーは許可された操作を使い、メールボックスの生のアクセストークンは受け取りません。チームと接続の権限

アプリが増えた後も、誰が何を使えるかを管理できます。特定のデータへのアクセスは、元のアカウントの権限と認可スコープにも制約されます。

製品のエンドユーザーそれぞれが自分のアカウントを接続する場合、ホスティング側ではConnector for SaaSとProjectConnectorを使い、ユーザーごとに接続を分離してください。

実行環境を管理する必要があるならOpenConnector

最初から明確な要件を持つチームもあります。認証情報は独自の鍵とストレージで保護する、ゲートウェイは社内ネットワークで動かす、実行記録は社内ルールに従って保存する、といった要件です。

このような条件があるなら、それに合う配置を選びます。OpenConnectorを自社運用すれば、ゲートウェイ、認証情報、操作ポリシー、実行記録に加え、データベース、バックアップ、更新、ネットワークアクセスを管理できます。

オープンソースの価値はコードにもあります。接続ランタイム、コネクター定義、操作の実行コード、Webコンソールのソースは公開されています。関連するConnector SDKとoo CLIもオープンソースです。呼び出しを調査したり、連携を追加したり、実装を変更したりする際は、既存のプロジェクトを出発点にできます。外部サービスのAPI認可要件と利用規約は、別途守る必要があります。

管理権限には保守責任も伴います。鍵管理、アクセス保護、更新、バックアップ、障害対応を担当する人が必要です。安全性はこれらをどう実施するかに左右されます。

環境に応じて配置方法を選べます。

• Docker Compose：自社サーバーや社内ネットワークで動かし、ストレージとアクセス範囲を管理します。
• Cloudflare Workers：D1やR2などのCloudflare基盤で、OpenConnectorの配置を自分たちで管理します。クラウド環境を使えるチーム向けです。
• ソースから実行：コネクター開発、デバッグ、OpenConnectorの変更に適しています。

Cloudflareはクラウドへの配置です。厳密に社内ネットワークで動かす必要があるなら、その条件に合うサーバー環境を選んでください。

社内ゲートウェイでも、必要な外向き通信は計画する必要があります。GoogleやZoomなどの外部SaaSを呼ぶには、APIと認可エンドポイントへのアクセスが必要です。外部通信が一切できない環境では、対象サービスに到達可能な内部インターフェースがあるかを先に確認してください。

手順はOpenConnectorのセルフホスティングガイドにあります。

ホスティングで始め、準備ができたら移行する

独自のOAuthアプリを使う予定でも、設定や審査が終わるまで業務検証を待つ必要はありません。ホスティングで業務連携を検証しながら、自社運用の認証情報と環境を準備できます。

どちらも@oomol-lab/connectorというSDKパッケージを使います。ホスティング向けのConnector、製品のエンドユーザー向けのProjectConnector、自社運用ランタイム向けのOpenConnectorが含まれます。操作の型と呼び出し規約は共通ですが、認証方式、アカウントの境界、利用できるメソッドは異なります。TypeScript SDKリファレンス

対応する操作の識別子、入力パラメーター、呼び出し方は再利用できます。たとえばメール検索なら、操作名と検索パラメーターを保ったまま、自社のランタイムに接続するクライアントで実行できます。

移行時は次を準備します。

1. 新しい環境にOpenConnectorを配置して保護し、独自のOAuthアプリを設定する。
2. アカウントを接続し、必要な認可スコープを確認する。
3. SDKクライアント、サービスURL、ランタイムトークン、接続の選択を変更する。
4. 必要な操作の実行対応と、チーム、プロジェクトユーザー、権限機能の対応範囲を確認する。
5. よく使う操作を一つ検証してから、ほかの呼び出しを段階的に切り替える。

アカウント接続とホスティングの管理機能は、それぞれ対応が必要です。共通SDKの利点は、既存の操作呼び出しとパラメーター構造を保ち、各APIとの連携を作り直す手間を減らせることです。

移行は必須ではありません。ホスティングが業務と管理の要件を満たすなら、そのまま使えます。実行環境の管理が具体的な要件になった時点で、ゲートウェイの運用を引き受けてください。

実際の操作を一つ動かす

いま自社運用が必要でなければ、公開したい機能を一つ選んでください。今日のカレンダーを読む、顧客のメールを検索する、プロジェクトの進捗を調べる、といった操作です。

OOMOL Consoleでアプリを接続して認可を済ませ、SDK導入ガイドに従ってバックエンドから操作を呼び出します。まず動作を確認してから、メンバーと接続権限を設定してください。

自社運用が明確な要件なら、OpenConnector配置ガイドで環境を準備し、OAuthアプリを設定してください。

現在の要件に合う出発点を選びましょう。ホスティングで業務連携を早く動かし、必要になったときには、オープンソースのOpenConnectorでコード、認証情報、実行環境を管理できます。