Web開発
すべてのアプリを他のすべてのアプリに接続する
Connecting every app to every other app (blog.val.town)
要約
Val Townは、Zapierのような広範なコネクタライブラリの必要性を認識し、アプリ間の接続問題を解決するための新しいアプローチを提案しています。OAuthの動的クライアント登録（DCR）とクライアントIDメタデータドキュメント（CIMD）を活用することで、手動でのクライアント登録プロセスを自動化し、アプリ間のシームレスな連携を目指しています。
全文翻訳
Val Townのコードと文章
すべてのアプリを他のすべてのアプリに接続する
Steve Krouse
2026年9月2日
私はずっとZapierの広範なコネクタライブラリを羨ましく思っていました。私たちのアプリ、Val Town（バイブコーディングプラットフォーム）が、ワンクリックで全てのアプリに接続できたらと願っています。zapier.com/apps
これは、すべてのアプリを他のすべてのアプリに接続するという、古典的なn²問題です。私の長年の夢は、どのアプリでも他のどのアプリとも動的に認証・認可できるようなプロトコルが存在することでした。OAuthはそのプロトコルなのでしょうか？ほぼそうです！
OAuthクライアントの登録
コアとなるn²問題は残ります。各アプリは、他のすべてのアプリに対してOAuthクライアントとして登録する必要があります。最良の場合でも、OAuthクライアントの登録は、開発者ポータルで5分ほどクリックする作業です。しかし、それは予測できません。フォームへの記入、デモビデオの作成、書類への署名、あるいは最悪の場合、ビデオ通話への参加が必要になることもあります。これはアドホックで手動の頭痛の種です。そして、私たちは皆、ユーザーが接続したいと思うすべてのアプリに対して、これを行う必要があります。
しかし、希望の光があります！AnthropicとOpenAIは、この問題が来るのを見ていました。彼らはすべての顧客のアプリに接続する方法を必要としていましたが、それらのOAuthクライアントをすべて取得したくはありませんでした。そこで彼らは、MCPの仕様に、あまり知られていないOAuth拡張機能である動的クライアント登録（DCR）を導入しました。
動的クライアント登録（DCR）
DCRはクライアント登録の問題を自動化します。人間が手動でOAuthクライアントを取得する必要がある代わりに、あなたのアプリは動的にそれをプロビジョニングし、そしてすぐに、それが初めて聞いたことのないこのアプリとのOAuthフローを開始します。これが夢です！
私のスタートアップであるVal Townでは、MCPサーバー/プラグインを構築する際にDCRについて学びました。これが、ClaudeやChatGPTからVal TownへのOAuth接続を可能にするものです。しかし、その利点はClaudeやChatGPTだけにとどまりません。どのアプリでもVal Townと動的にOAuthクライアントを登録し、ユーザーのVal Townアカウントに接続できます。
DCRによるログイン
例えば、このプリミティブの上に、std/oauthというミドルウェアライブラリを作成しました。これは、Val Townアプリに「Val Townでログイン」OAuthを2行のコードで追加します。これは文字通り完全なアプリです。
/** @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」をクリックすると、そのアプリのコピーが手に入り、「Val Townでログイン」認証がすぐに機能します。あなたのアプリのVal TownへのOAuthクライアントは、最初のユーザーがログインしたときにバックグラウンドで作成されます。
誤解のないように言っておきますが、ここには魔法はありません。なぜなら、Val Townは認証サーバーとアプリのインフラストラクチャの両方を実行しているからです。このライブラリは、DCRをサポートする任意のインフラストラクチャや認証プロバイダーで動作するように適応させることができます。
さらに良くなります。
クライアントIDメタデータドキュメント（CIMD）
DCRは、OAuthクライアント登録のほとんどの問題を解決しますが、実装するのが多少面倒な場合があります。（MCPチームのPaul Carletonがここでさらに詳しく説明しています。）
ここでクライアントIDメタデータドキュメント（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のコネクタを持つこのライブデモアプリを作成しました：oauth-demos.val.run
驚くべき部分は、あなたがこのアプリのコピーを自分でデプロイした場合（つまり、Val Townで「remix」をクリックした場合）、すべてのコネクタが即座に機能することです。単一のOAuthクライアントを取得する必要はありません。
夢は近づいています
お気づきかもしれませんが、私たちはまだ夢の中に生きていません。Val Townでさえ、これらのすべてのアプリへのコネクタをリリースしていません。解決すべき問題はまだ残っています。主に、これらの新しいプロトコルが、この「すべてのアプリを接続する」問題を解決するために設計されたわけではないという事実から生じています。
問題1：動的登録が実際にサポートされているか
これらの動的クライアント登録エンドポイントの多くは、真に動的ではありません。例えば、私の上のアプリでGoogle広告に接続しようとすると、次のエラーメッセージが表示されます：「redirect host not in platform catalog: oauth-demos.val.run」。つまり、真に動的な登録はサポートされておらず、私たちはまだそれらのカタログに事前に登録されている必要があります。
問題2：MCP vs REST API
DCR/CIMDはMCPにのみ有効かもしれません。通常のREST API呼び出しを許可しない可能性があります。これは、バイブコーディングプラットフォームとしてのVal Townにとって、潜在的にトリッキーな問題です。例えば、Val TownでStripeダッシュボードを構築したいとします。DCRを使用してStripeにMCP経由で簡単に接続できます。しかし、それは彼らのREST APIには機能しません。
ここでの問題は、技術的な問題というよりも、社会的な慣習です。技術的には、StripeのMCPサーバーをAPIサーバーの代わりに呼び出すコードを記述できますが、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からリストをスクレイピングしました。また、優れたオープンソースツールも必要です。