すべてのアプリを他のすべてのアプリに接続する

あらゆるアプリを他のあらゆるアプリに接続する

私は長年、Zapierの広範なコネクタライブラリを羨ましく思ってきました。私たちのアプリであるVal Town（バイブコーディングプラットフォーム）も、あらゆるアプリにワンクリックで接続できたらと願っています。

［画像: Google Sheets, Gmail, Slack, Google Calendar, Notionなど、9,000以上のアプリ連携が表示されたZapierのインテグレーションディレクトリ］zapier.com/apps

これは、あらゆるアプリを他のあらゆるアプリに接続するという、古典的なn²問題です。

私の長年の夢は、どのアプリも他のどのアプリとも動的に 認証・認可できるようなプロトコルが存在することでした。

OAuthはそのプロトコルなのでしょうか？

ほぼそうです！

OAuthクライアントの登録

中心的なn²問題は残ります。つまり、すべてのアプリが他のすべてのアプリに対してOAuthクライアントとして登録する必要があるということです。

最良の場合でも、OAuthクライアントの登録は開発者ポータルで5分ほどクリックすれば完了します。しかし、それは予測不能です。フォームへの記入、デモ動画の作成、書類への署名、あるいは最悪の場合、ビデオ通話への参加が必要になることもあります。これは場当たり的で手作業の頭痛の種です。そして、私たちはユーザーが接続したいと望むすべてのアプリに対して、これを行う必要があります。

しかし、希望の光もあります！AnthropicとOpenAIはこの問題が来ることを予見していました。彼らはすべての顧客のアプリに接続する方法を必要としていましたが、それらのOAuthクライアントをすべて取得したくはありませんでした。そこで彼らは、MCPの仕様にあまり知られていないOAuth拡張機能を導入しました。それがDynamic Client Registration (DCR)です。

Dynamic Client Registration (DCR)

DCRはクライアント登録の問題を自動化します。人間が手動でOAuthクライアントを取得する必要がある代わりに、あなたのアプリはそれを動的にプロビジョニングし、その後、初めて聞いたこのアプリへの OAuthフローをすぐに開始します。これが夢です！

私のスタートアップであるVal Townでは、ClaudeやChatGPTからVal TownへのOAuthを可能にするMCPサーバー/プラグインを構築中にDCRについて学びました。

しかし、その恩恵はClaudeやChatGPTだけにとどまりません。どのアプリでも Val Townと動的にOAuthクライアントを登録し、ユーザーのVal Townアカウントに接続できます。

DCRによるログイン

例えば、このプリミティブの上に、私たちはstd/oauthというミドルウェアライブラリを作成しました。これは、Val Townアプリに2行のコードで「Login with Val Town」OAuthを追加するものです。これは文字通り、完全なアプリです。

/** @jsxImportSource https://esm.sh/hono/jsx */
import { Hono } from "https://esm.sh/hono";
import {
  getOAuthUserData,
  oauthMiddleware,
} from "https://esm.town/v/std/oauth/middleware.ts";

const app = new Hono();

app.get("/", async (c) => {
  const session = await getOAuthUserData(c.req.raw);

  return c.html(
    <html>
      <body>
        {session?.user
          ? <p>Logged in as {session.user.username}</p>
          : <a href="/auth/login">Log in</a>}
      </body>
    </html>,
  );
});

export default oauthMiddleware(app.fetch);

以下で試してみてください。

追加の設定手順は一切ありません。Val Townで「remix」をクリックすると、そのアプリのコピーが手に入り、「Login with Val Town」認証がすぐに機能します。あなたのアプリのVal TownへのOAuthクライアントは、最初のユーザーがログインしたときにバックグラウンドで作成されます。

明確にしておくと、Val Townが認証サーバーとアプリのインフラストラクチャの両方を実行しているため、ここには魔法はありません。このライブラリは、DCRをサポートする任意の認証プロバイダーに対して、任意のインフラストラクチャ上で実行できるように適応させることができます。

さらに良くなります。

DCRは、OAuthクライアント登録問題の大部分を解決しますが、実装するのがやや面倒な場合があります。（MCPチームのPaul Carletonがここで詳しく説明しています）。

そこで登場するのがClient ID Metadata Documents (CIMD)です。

CIMDは、OAuthクライアントを事前に登録する必要がまったくないことを意味します。代わりに、OAuthクライアントデータをURLで自己ホストし、すぐにOAuthフローを開始できます。

例えば、NotionのCIMDリンクはhttps://mcp.notion.com/.well-known/oauth-authorization-serverで、以下のようなJSONが返されます。

{
  "issuer": "https://mcp.notion.com",
  "authorization_endpoint": "https://mcp.notion.com/authorize",
  "token_endpoint": "https://mcp.notion.com/token",
  "registration_endpoint": "https://mcp.notion.com/register",
  "scopes_supported": [
    "default"
  ],
  "response_types_supported": [
    "code"
  ],
  "response_modes_supported": [
    "query"
  ],
  "grant_types_supported": [
    "authorization_code",
    "refresh_token",
    "urn:ietf:params:oauth:grant-type:jwt-bearer"
  ],
  "authorization_grant_profiles_supported": [
    "urn:ietf:params:oauth:grant-profile:id-jag"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post",
    "none"
  ],
  "revocation_endpoint": "https://mcp.notion.com/token",
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ],
  "client_id_metadata_document_supported": true,
  "introspection_endpoint": "https://mcp.notion.com/introspect",
  "introspection_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post",
    "none"
  ]
}

CIMDをサポートするどのアプリも、ユーザーが要求したときに、そのアプリがNotionのことを以前に聞いたことがなかったとしても、すぐにNotionとのOAuthフローを開始できます。

すべてをまとめて

現在、数千のアプリがDCRをサポートし、数百のアプリがCIMDをサポートしています。新しいソフトウェアプロトコルがこれほど速く普及したのは、私の記憶にありません。ChatGPTやClaudeと連携するMCPサーバーをすべて作成する急ぎの中で、私たちは意図せず、アプリ同士も相互に接続できるようになりました。

そこで私はそれを論理的な極限まで推し進め、3,613のコネクタを持つこのライブデモアプリを構築しました。

［画像: 21のDCRまたはCIMD接続のデモアプリ］oauth-demos.val.run

驚くべきは、このアプリのコピーを自分でデプロイした場合、つまりVal Townで「remix」をクリックするだけで、すべてのコネクタが即座に機能することです。単一のOAuthクライアントを取得する必要はありません。

夢は近づいている

お気づきの通り、私たちはまだ夢の生活を送っているわけではありません。Val Townの私たちでさえ、これらのすべてのアプリへのコネクタをリリースしていません。解決すべき問題はまだ残っています。主に、これらの新しいプロトコルが、この「すべてのアプリを接続する」問題を解決するために設計されたわけではないという事実から生じています。

問題1：動的登録の実際のサポート

これらの動的クライアント登録エンドポイントの多くは、真に動的ではありません。例えば、上記の私のアプリでGoogle Adsに接続しようとすると、redirect host not in platform catalog: oauth-demos.val.runというエラーメッセージが表示されます。つまり、真に動的な登録はサポートされておらず、カタログにあらかじめ登録しておく必要があります。

問題2：MCP対REST API

DCR/CIMDはMCPにしか機能しない可能性があります。通常のREST API呼び出しを許可しないかもしれません。これは、バイブコーディングプラットフォームとしてのVal Townにとって、潜在的にトリッキーな問題です。

例えば、Val TownでStripeダッシュボードを構築したいとします。DCRを使用してStripeにMCP経由で簡単に接続できます。しかし、それは彼らのREST APIには機能しません。

ここでの問題は、技術的な問題というよりも、社会的な慣習です。技術的には、StripeのAPIサーバーではなく、StripeのMCPサーバーを呼び出すコードを書くことは可能ですが、MCPサーバーとの対話方法は通常そのようではありません。私は、これがREST APIとMCPの根本的な違いであると考えています。それは安定性の約束です。Stripeは特に、REST API呼び出しが常に機能することを保証するために多大な努力を払っています。コードは壊れやすいため、これは重要です。APIが変更されると、コードは壊れます。

しかし、MCPの慣習は、呼び出しの両側に推論があるということです。LLMは、MCPツールセットを呼び出す前にそれを読み取ることができ、エラーが発生したり動作が変更されたりした場合、LLMはエラーを修正し、成功するまでさらにMCP呼び出しを行うことができます。比喩的に言えば、MCPサーバーはユーザーインターフェース（UI）のAI同等物です。なぜなら、UIも安定性の約束がなく、同じ理由で、UIのどちらかの側にも推論（人間）があるからです。コードとは異なり、UIでボタンの位置が変わったり、ボタンが突然異なることをしたりしても、人間はそれに気づき、リアルタイムでエラーを修正できます。

ここでの1つの解決策は、アプリケーションがAPIに対してDCR/CIMDを許可するか、または（必要なリソース権限が付与されている場合）どちらかの手段で取得したトークンを両方のサーフェスで機能させることです。それが現在Val Townで機能している方法です。DCRから取得したトークンは、当社のMCPとREST APIの両方で機能します。

問題3：OSSとツール

これらすべてのコネクタの公開レジストリのようなものが存在するべきでしょう。私はmcpservers.orgからリストをスクレイピングしました。

また、それらすべてに簡単に接続するための優れたオープンソースツールも必要です。OSSライブラリは、Zapier SDK、Pipedream Connect、またはNangoのようなものになるかもしれません。

クリックもキーもなし

上記で見たように、DCR/CIMDは、アカウントを持っている他のアプリに認可することを可能にします。

しかし、別の種類の問題があります。アカウントを持っていない従量課金制のAPIにアクセスすることです。おそらくx402がこの問題のもう半分、つまり支払いの部分を解決し、クレジットカードが付帯したアカウントを持っていなくても、プレミアムAPIの支払いをすぐに開始できるようになるでしょう。

DCR/CIMDとx402を組み合わせることで、APIキーが環境変数として存在しない未来が示唆されます。バイブコーディングの時代、つまりアプリ全体を数分で生成できる時代において、人間がAPIキーを取得して設定する必要がないことは、退屈さの大きな軽減であり、柔軟なソフトウェアにとって大きな前進です。