UnifAPI が OOMOL と提携：公開データの読み取りと OAuth の書き込みが出会う

要点：UnifAPI は OOMOL のオープンソース OpenConnector にネイティブプロバイダーとして加わり、私たちの公開データカタログの全体、すなわち全 16 プラットフォームを、型付きで呼び出し可能な Actions としてミラーリングします。管理者が 1 人、Workspace の API キーで UnifAPI を一度接続すれば、会社全体がその共有接続を通じてライブな公開データを読み取れます。しかも、OOMOL がすでに仲介している OAuth の書き込みツールのすぐ隣で。オフボーディングは OOMOL 上のワンクリックで完了し、UnifAPI 側でローテーションするものは何もありません。

エージェント連携は、昔から 2 つの半分に分かれてきました。片方はプライベートなもの。ユーザー自身の Gmail、Notion、Linear、Slack といった、その本人だけが認可できるデータで、たいてい OAuth を使い、たいてい書き込みアクセスを伴います。もう片方は公開されたもの。投稿、プロフィール、動画、スレッド、ランキング、SERP といった、ブラウザを持つ誰もが読める証拠であり、これこそが UnifAPI のプロダクトそのものです。

これまで、チームはこの 2 つの半分を別々に配線してきました。OAuth ツールにはコネクタープラットフォーム、公開データには直接のキーか MCP 接続、そして「誰がアクセスを持っていて、どうやって取り消すのか」という問いにも 2 通りの答え。今日、私たちはそのギャップを埋めます。UnifAPI は OOMOL の OpenConnector に組み込みプロバイダーとして加わり、公開データの半分と OAuth の半分が、1 つのゲートウェイ、1 つのカタログ、1 つのチーム管理画面の背後に収まります。

OOMOL とは何者か

OOMOL は、エージェントとそれを運用するチームのための連携インフラを作っています。Composio と比較したことがあるなら、それは正しい隣人です。エージェントとサードパーティサービスの間で認証を仲介するコネクターゲートウェイという意味では同じですが、OOMOL は一風変わった経路からそこにたどり着いており、その回り道はプロダクトに表れています。

同社が最初に姿を現したのは 2025 年半ばの Hacker News で、local-first, code-first（ローカルファーストかつコードファースト）なワークフロー自動化エンジンとして OOMOL Studio を打ち出しました。Zapier や n8n が、ビルド済みノードのキャンバスと、それ以外のすべてを押し込む窮屈な式入力ボックスを渡してくるのに対し、Studio は VS Code をベースに構築されています。ワークフローを構成する Blocks は、どれも本物の Python または Node.js であり、コンテナ内で動くため、サードパーティライブラリはどのマシンでも同一に振る舞います。キャンバスの下では、Rust で実装されたワークフローエンジン OOCANA が、プレーンな YAML ファイルで宣言されたフローとブロックをスケジュールします。Blocks とワークフローテンプレートは共有可能なので、チームにはノードグラフのスクリーンショットではなく、動く部品のライブラリが蓄積されていきます。

このコアの周りで、エコシステムはエージェントインフラの常として育っていきました。oo CLI は、エージェントが公開済みのツールを検索・調査・実行できるコマンドラインリレー。OOMOL Cloud は、継続的デリバリーとマネージドな設定を必要とするワークフロー向けのホステッドランタイム。そして Wanta は、アカウントを一度接続すれば自然言語でそれらを横断して作業できるデスクトップアプリです。

そのすべてをつなぐ結合組織が OpenConnector であり、これこそ UnifAPI が今回組み込まれるピースです。

OpenConnector の中身

OpenConnector は、Apache-2.0 のオープンソースコネクターゲートウェイです。そのタグラインは「Connect Once. Use Everywhere.（一度つなげば、どこでも使える）」で、これは文字どおりの意味です。アカウントを一度接続すれば、1,000 以上のプロバイダーと 9,400 以上のビルド済み Actions からなる共有カタログが、チームが使うあらゆる面から呼び出せるようになります。アプリコードからは TypeScript SDK、ローカルのエージェントリレーとしては oo CLI、エージェントホストからは MCP、カスタムクライアントからはプレーンな HTTP/OpenAPI、そして管理とデバッグには Web Console です。

この先の話にとって重要な設計判断が 2 つあります。

第一に、すべての Action は検証可能なコントラクトです。リクエスト/レスポンスのスキーマ、必要なスコープ、さらにはエグゼキューターのソースそのものまで、すべて読めます。エージェントが呼び出すより前に、その Action が何をするのかを監査できるのです。これは、私たちが OpenAPI で取っているのと同じ「マーケティングではなく、コントラクトを読む」姿勢です。

第二に、クレデンシャルは、それを使うエージェントからアーキテクチャレベルで分離されています。API キーと OAuth トークンは保存時に封印され（AES-256-GCM）、エージェントはサーバーサイドのフローを通じて呼び出すため生のシークレットを目にすることはなく、許可/ブロックポリシーが各コンシューマーの呼び出せる Actions を絞り込み、すべての呼び出しが監査レコード（アクター、スコープ、タイムスタンプ、結果）を書き込み、実行ログでは出力がマスキングされます。暴走したエージェントはポリシーレイヤーで遮断できます。そもそもキーを握っていなかったのですから。

これが仕組みです。では、なぜ UnifAPI がその中にあるべきなのか。

目と手が出会う

UnifAPI のポジショニングは初日から一貫しています。eyes, not hands（手ではなく、目）。私たちは公開データ（TikTok、LinkedIn、Instagram、YouTube、Twitter/X、Threads、Reddit、Hacker News、ニュース、SEO・GEO シグナル、地図とローカルリスティング）を読み取り、1 つのエンベロープに正規化し、あなたの投稿用クレデンシャルを決して預かりません。リサーチ、モニタリング、監査、価格算出。すべて読み取りです。

OOMOL のカタログが最も強いのは、その反対側の半分です。1,000 を超えるプロバイダーの大半はプライベートな SaaS への OAuth、つまり手です。その接続によって、エージェントはユーザーが実際に所有するアカウントの中で行動できます。Slack メッセージを送り、Notion ページを更新し、Linear チケットを起票し、メールを下書きする。

つまり、互いに欠けている部分こそが、相手側のプロダクトだったのです。書き込みツールで満たされたコネクターゲートウェイにも、行動の根拠となる証拠は依然として必要ですが、ライブで正規化され、法的にも慎重な公開データレイヤーを構築するのは、それ自体がフルタイムのプロダクトであって、単なる機能ではありません。公開データレイヤーの側にも、見つけた成果の着地先が必要ですが、数百の SaaS アプリへの OAuth を仲介することも、同じく誰かの本業に値する仕事です。両者を同じゲートウェイの背後に置けば、どちらも自らのモデルを妥協することなく、ループが閉じます。

「今週、私たちのローンチについて TikTok クリエイターが何を語ったか調べて」→ UnifAPI、公開データの読み取り。

「そのダイジェストを #marketing に投稿して、フォローアップを Linear に起票して」→ OOMOL の OAuth 接続、プライベートな書き込み。

あなたのアシスタントは、1 つのカタログを通じて両方を呼び出します。UnifAPI は相変わらずあなたのプライベートアカウントに一切触れません。この境界は偶然の産物ではなく、構造を支える柱です。そして OOMOL は公開データレイヤーを自前で維持する必要がありません。読み取りは、それをライブに保ち、正規化し、レコード単位で価格付けすることだけを仕事とするプロバイダーから届くのです。

1 つのキーで、会社全体へ

この提携で私たちが最も期待しているのは、OOMOL のチームレイヤーが UnifAPI のオンボーディングにもたらす変化です。

UnifAPI の API キーは Workspace に属し、そのワークスペースの credits を消費します。この提携の前、キーを会社全体で共有するということは、キー共有が常に意味してきたことと同じでした。ボールトや env ファイルに貼り付け、ラップトップやノートブックやリポジトリに漏れないことを祈り、誰かが退職するたびにローテーションする。そのうえで、古いキーがキャッシュされていた場所をすべて追いかけ回すのです。

OOMOL を通せば、チームのクレデンシャルがあるべき姿で機能します。

管理者が 1 人、UnifAPI コンソールでキーを作成し、OOMOL に UnifAPI 接続として保存する。これを一度だけ行います。チームの全員が、Studio のワークフローからも、oo CLI や MCP の背後にいるエージェントからも、SDK を使うバックエンドコードからも、その共有接続を通じて UnifAPI を呼び出します。生のキーが出回ることはなく、チームメイトは接続を名前で参照し、シークレットはゲートウェイの中に封印されたまま留まります。許可/ブロックポリシーが、各コンシューマーが呼び出せる Actions を決めます。アナリストのリサーチエージェントは TikTok と Reddit を読めるが、インターンの実験は SEO エンドポイントに触れられない、というように。そして監査証跡が、どのシステムがどの接続を何のために使ったかを示します。

そして誰かが退職したら、OOMOL 上でそのアクセスを削除するだけ。それで終わりです。キーのローテーションも、再デプロイも、UnifAPI 側の変更も一切ありません。ワークスペースのキーは、そもそも最初からその人の手に渡っていないのですから。利用は同じ UnifAPI ワークスペースに流れ続けるため、請求は 1 つの残高、1 つの台帳、レコード単位のままです。

UnifAPI の全プラットフォームを、型付きの Actions として

これはロゴの差し替えでも、3 つのエンドポイントを覆う薄いラッパーでもありません。OpenConnector の UnifAPI プロバイダーは、私たちのカタログをプラットフォームごとにミラーリングします。TikTok、Twitter/X、Instagram、YouTube、LinkedIn、Threads、Reddit、Hacker News、ニュース、SEO、GEO、地図、ローカル、ホテル、イベント、そしてレンダリング済みブラウザによるフェッチ。unifapi.com/apis の背後にあるのと同じ 16 プラットフォーム・220 オペレーションが、それぞれ、エージェントが呼び出す前に検証できる入出力スキーマ付きの型付き Action として生成されています。

Actions は手書きではなく型付きのオペレーション定義から生成されるため、プロバイダーは私たちの OpenAPI サーフェスに追随します。カタログが増えれば、コネクターも一緒に増えるのです。そして請求は、経路の途中で形を変えません。OOMOL 経由の呼び出しは、直接の HTTP や MCP での利用と同じレコード単位の価格で UnifAPI ワークスペースの credits を消費し、すべてのレスポンスに同じ billing メタデータが含まれます。

オープンソースで、セルフホスト可能

OpenConnector は Apache 2.0 であり、UnifAPI プロバイダーは公開カタログに含まれています。プロバイダーのソースを自分で読むことができます。API キー認証を標準の Bearer ヘッダーとして送信し、アクションはプラットフォームごとに生成されています。

これが重要なのは、上で述べたチームのストーリーが、ホステッドなブラックボックスへの信頼を前提としないからです。ゲートウェイ全体を自分の管理下のインフラで動かせます。Docker や Node.js によるローカル実行、永続 SQLite を使った Fly.io、D1 と R2 を使った Cloudflare Workers。いずれでも、同一のプロバイダーカタログと Actions のコントラクトが得られます。OOMOL のホステッドランタイムは同じインターフェースを持つゼロオプスの道であり、ホステッドで始めて後からセルフホストに移る（あるいはその逆）としても、連携コードは変わりません。

セキュリティレビューが「クレデンシャルをサードパーティの SaaS 経由で流す」ことに難色を示すチームにとって、これは「面白い」と「承認済み」の違いです。クレデンシャルストアも、ポリシーエンジンも、監査ログも、すべて自社の境界の内側に置けるのですから。

OOMOL 経由で UnifAPI を接続する

セットアップは意図的に地味にしてあります。

1. UnifAPI コンソールにサインインし、ワークスペースの API キーを作成します（表示は一度きりで、unif_ のプレフィックスが付きます）。
2. OOMOL で UnifAPI 接続を追加し、キーを貼り付けます。そこから先の Authorization: Bearer ヘッダーは OpenConnector が処理します。
3. チームが働くあらゆる場所から UnifAPI のオペレーションを呼び出します。Studio のワークフロー、oo CLI、MCP 接続されたアシスタント、あるいはバックエンドコードからの SDK。

Claude や Codex で Skills を動かす個人オペレーターにとっては、unifapi.com/mcp の直接接続の道が、これまでどおり 3 分のセットアップです。OOMOL は、UnifAPI をチームのユーティリティにする道です。共有接続、スコープ付きポリシー、監査証跡、ワンクリックのオフボーディング。

これで閉じる 3 つのループ

かつては 2 つの連携プロジェクトを要したのに、いまや 1 つのゲートウェイで済むワークフローをいくつか。

ソーシャルリスニングを、端から端まで。ワークフローが UnifAPI を通じて Reddit、TikTok、Twitter/X 全体のブランド言及を読み取り、Python の Block でスコアリングし、OAuth 接続を通じてチームの Slack に朝のダイジェストを投稿する。読み取りは公開、書き込みはプライベート、カタログは 1 つ、監査証跡も 1 つ。

証跡の残るインフルエンサーマーケティング。ワークフローが公開エンゲージメントデータからクリエイターをショートリスト化して KOL の価格を算出し、そのショートリストを、公開の証拠を引用したうえで、レビュー用にチームの Notion ワークスペースへ書き込む。財務から「この数字の出どころは？」と聞かれたら、実行ログが答えてくれます。

自分でチケットを起票する競合インテリジェンス。スケジュール実行されるワークフローが、競合の公開ローンチ、スレッド、ランキングを監視し、アクションにつながるものをチームのトラッカーにチケットとして起票する。各チケットには公開ソースへのリンクが付きます。

いずれのケースでも境界はきれいなままです。UnifAPI は引用可能な公開の証拠を供給し、OOMOL を通じて認可されたユーザー自身のアカウントがアクションを担うのです。

より大きな絵

エージェントがひとりで使う道具でなくなったのは、去年のどこかの時点です。ワークフローが共有された瞬間、つまりチームの Slack ダイジェスト、全社のリサーチパイプライン、スケジュール実行される監査になった瞬間に、問いは「どのモデルを使うか」から「誰が何を、誰のクレデンシャルで呼び出せるのか。そしてその人が去ったらどうなるのか」に変わります。これらはゲートウェイの問いであり、コネクターゲートウェイがエージェントスタックの独立したレイヤーになった理由でもあります。

私たちの答えは 2 つの部分からなります。公開データの半分については、UnifAPI はこれまでどおりであり続けます。1 つのキー、1 つのエンベロープ、レコード単位の価格、そして設計からして読み取り専用。チームの半分については、その影のコピーを自前で作るより、オープンで検証可能なゲートウェイと統合するほうを選びます。OOMOL の OpenConnector はまさにそれです。オープンソースで、セルフホスト可能で、私たち自身の顧客に指し示せるセキュリティモデルを備えています。

一度つなぐ。会社全体が公開ウェブを読む。

次に読むべきもの

UnifAPI vs Composio - この提携の土台になっている「2 つの半分」という枠組みを示します。

UnifAPI を MCP 経由で Claude に接続する - 個人オペレーター向けの直接的な MCP の道です。

実用最小限のエージェントスタック - コネクターゲートウェイと公開データレイヤーが 1 つのアーキテクチャの中でどこに位置するかを示します。