GitHubトレンドに突如現れた「open-connector」は、AIエージェントを1000超のSaaSに接続する認証ゲートウェイだ。OSSかつMCP対応という設計思想は、これまでAI活用の最大のボトルネックだった「認証とAPI接続」を一気に標準化する。エンジニア視点で見れば、これは単なる便利ツールではなく、SaaS業界の力学を根本から書き換える一撃である。

何が起きたか

oomol-labが公開した「open-connector」が、GitHubトレンドに登場し226スターを獲得している。これはAIエージェントがSlack、Notion、Salesforceを含む1000以上のSaaSにログインし、操作するための「認証の共通玄関」を提供するOSSだ。SDK、CLI、MCP、HTTP、OpenAPIという5つのインターフェースを備え、ClaudeやChatGPTから直接社内システムを叩ける。OAuth2やAPIキー管理といった、これまで個別実装が必要だった認証プロトコルを抽象化し、AIエージェントに対して統一的なアクセスレイヤーを提供する点が本質だ。ライセンスはOSSで無料。企業のAI導入における最後のラストワンマイル、「認証とトークン管理」を丸ごと肩代わりする位置づけである。

なぜこのニュースが重要か

これまで生成AIの業務適用が進まなかった真因は、モデルの賢さではなく「AIが社内SaaSに触れなかったこと」だ。LLMがどれだけ高度な推論をしても、Salesforceの商談データを引くにはOAuthトークンの取得、リフレッシュ、スコープ管理、Rate Limit対応を各SaaSごとに実装する必要がある。1000個のSaaSに対応するには1000通りの認証コードを書く必要があった。これがAIエージェント開発の90%の工数を食っていたと推定される。

open-connectorはこの構造を破壊する。MCP（Model Context Protocol）対応であることが決定的で、Anthropicが提唱したこの標準がついに「実装レイヤー」まで降りてきたことを意味する。つまりAIエージェント側は「MCPで話しかける」だけで、裏側の1000種類のOAuthフローを意識しなくていい。これはHTTP以前のTCP直叩き時代から、HTTPライブラリが登場した瞬間に匹敵する抽象化ジャンプである。

技術的な深掘り

コードと仕様書から本質を読むと、open-connectorの設計で注目すべきは「5つのインターフェースを並列提供」している点だ。SDKは開発者向け、CLIは運用者向け、MCPはAIエージェント向け、HTTPは汎用クライアント向け、OpenAPIは自動生成クライアント向け。この多層設計は、単なる「便利ツール」ではなく「認証プロトコルの新標準を狙う」意図を示している。

技術的にはNangoやPipedream Connectといった既存の認証Hub SaaSと競合するが、決定的な差はOSSであることとMCPネイティブであることだ。競合の商用サービスは月額数百ドル〜数千ドルのランニングコストがかかるが、open-connectorはセルフホスト可能でトークンも自社管理できる。これはセキュリティ監査が厳しい金融・医療分野で決定的な優位となる。

一方で懸念もある。1000個のSaaS APIのスキーマ変更に追随するには相当な開発リソースが必要で、コミュニティが維持できるかは未知数だ。226スターという初速は良いが、Nangoが数千スター規模で長期メンテしている現実を見ると、oomol-labの継続コミットが問われる。エンタープライズ採用の分水嶺は「1年後にどれだけのSaaSプロバイダーがまだ動いているか」だと想定する。

経営者として次に取るべき動き

第一に、自社が提供するSaaSがある場合、MCP対応を今四半期のロードマップに載せること。AIエージェントから呼び出せないSaaSは、今後「AIから選ばれない=顧客の業務フローから外される」構造に入る。API提供だけでは不十分で、MCPサーバー実装が事実上の必須要件になる。

第二に、情シス部門にシャドーAIのガバナンス設計を即時指示すること。open-connectorのようなツールが無料で使える以上、現場エンジニアが勝手にSalesforceトークンをClaudeに渡す事態は避けられない。監査ログ、スコープ制限、トークン失効ポリシーを2週間以内に策定すべきだ。

第三に、社内の「AI×SaaS PoC」予算を再配分すること。これまで認証実装に費やしていた工数が消えるため、同じ予算で3倍のPoCが回せる。真っ先に着手すべきは、経費精算・議事録・営業レポートといった、複数SaaS横断の定型業務である。