Redis で MCP 開発を加速:高速でコスト効率の高いソリューション

モデル コンテキスト プロトコル (MCP) は、AI モデルを外部ツールやデータ ソースに接続するための標準的な方法として急速に普及しつつあります。 MCP の採用が進むにつれて、開発者は、堅牢で本番環境に対応した MCP 実装を構築するには、単に仕様に従うだけではなく、適切なインフラストラクチャが必要であることに気づき始めています。この投稿では、Vercel の SSE 実装での分散サーバーレス機能の調整、長時間実行ストリームのイベント再開の有効化、Clerk による安全な OAuth フローの管理という 3 つの異なる MCP ユースケースを Redis がどのように強化するかを説明します。

MCP トランスポートについて

例に入る前に、MCP が通信をどのように処理するかについて簡単に説明しましょう。 MCP は 2 つのトランスポートをサポートしています:Stdio ローカル サーバーとストリーミング可能な HTTP 用 リモートサーバー用。以前は、リモート サーバー用の SSE (Server-Sent Events) トランスポートもありましたが、現在は非推奨となっています。

SSE から Streamable HTTP への移行は、MCP がリアルタイム通信を処理する方法の進化を表していますが、既存の実装の多くは依然として SSE パターンに依存しています。 Redis がそのモデルの重要な課題の 1 つを解決するのにどのように役立ったかを見てみましょう。

使用例 1:Redis Pub/Sub を使用した SSE

Vercel CTO Malte が MCP ハンドラーを構築したとき、古典的なサーバーレスの課題に直面しました。それは、各リクエストが異なるサーバーレス機能によって処理される可能性がある場合、複数のエンドポイント間でどのように調整するかということでした。

SSE トランスポート モデルには、2 つの重要なエンドポイントがあります:/sse 接続を維持するためと /message クライアントメッセージを受信するため。ここに問題があります。Vercel のようなサーバーレス環境では、これらのエンドポイントは完全に分離されています。彼らはメモリを共有せず、/message へのリクエストを送信します。 /sse を処理する関数インスタンスとはまったく異なる関数インスタンスによって処理される可能性があります。 .

解決策は？ Redis パブリッシュ/サブスクライブ。 Malte が X で説明したように:

この実装では、Redis チャネルを使用してエンドポイント間を調整します。クライアントが /message にメッセージを送信するとき 、そのエンドポイントは /sse という Redis チャネルに公開します。 エンドポイントがサブスクライブされています。 /sse エンドポイントはリクエストを処理し、/message という別のチャネルを通じてレスポンスをパブリッシュします。

を聞いています。

このパターンは、Redis を事実上、分離されたサーバーレス機能間のギャップを埋めるメッセージ バスに変え、それらの機能が同じプロセスの一部であるかのように連携できるようにします。 SSE は現在、Streamable HTTP (新しい MCP 実装では最新のトランスポートを使用する必要があることを意味します) に代わって非推奨になりましたが、これは分離されたサーバーレス機能間の調整に Redis を使用する優れた例として残ります。

使用例 2:再開可能なイベント ストア

MCP のストリーミング可能な HTTP トランスポートの最も強力な機能の 1 つは、再開可能性のサポートです。この機能により、クライアントは切断時に中断したところからストリームを継続できます。これは、ネットワークの中断が避けられない運用アプリケーションにとって非常に重要です。

MCP ストリームについて

再開可能性がなぜ重要なのかを理解するには、MCP ストリームが何で構成されているかを理解する必要があります。単純なツールの呼び出しなど、一部の操作は単一の応答を返します。ただし、ツールは、server.sendLoggingMessage などのメソッドを使用して、実行中に複数のイベントを返すこともできます。これらのマルチイベント ストリームでは、再開可能性が重要になります。クライアントが途中で切断した場合、最初からやり直すのではなく、中断したところから再開できる必要があります。

Redis を使用した EventStore の実装

MCP SDK は、次の 2 つのメソッドを必要とする EventStore インターフェイスを定義します:storeEvent イベントと replayEventsAfter の追加用 特定のイベント ID から始まるイベントを取得します。 SDK にはメモリ内実装が含まれていますが、運用環境で使用するには永続ストレージが必要です。

Redis ベースの EventStore 実装は次のとおりです。

import { Redis } from '@upstash/redis';
import { JSONRPCMessage } from '@modelcontextprotocol/sdk/types.js';
import { EventStore } from '@modelcontextprotocol/sdk/server/streamableHttp.js';
 
export class RedisEventStore implements EventStore {
 private redis: Redis;
 
 constructor(params: ConstructorParameters<typeof Redis>[0]) {
 this.redis = new Redis(params);
 }
 
 /**
 * Stores an event in a Redis Stream
 * Implements EventStore.storeEvent
 */
 async storeEvent(streamId: string, message: JSONRPCMessage): Promise<string> {
 const eventId = await this.redis.xadd(`stream:${streamId}`, '*', {
 message: JSON.stringify(message),
 });
 return eventId;
 }
 
 /**
 * Replays events that occurred after a specific event ID
 * Implements EventStore.replayEventsAfter
 */
 async replayEventsAfter(
 lastEventId: string,
 { send }: { send: (eventId: string, message: JSONRPCMessage) => Promise<void> }
 ): Promise<string> {
 if (!lastEventId) {
 return '';
 }
 
 // Extract the stream ID from the lastEventId
 const streamId = lastEventId.split('-')[0]; // Assuming the stream ID is part of the key
 if (!streamId) {
 return '';
 }
 
 let nextId = lastEventId;
 while (true) {
 // Fetch events from the stream starting AFTER the next ID (exclusive)
 const events = await this.redis.xrange(`stream:${streamId}`, `(${nextId}`, '+', 10);
 
 // Convert the returned object to an array of entries
 const eventEntries = Object.entries(events);
 
 if (eventEntries.length === 0) {
 break; // No more events to replay
 }
 
 for (const [eventId, fields] of eventEntries) {
 // Ensure fields.message exists and parse it
 if (fields && typeof fields === 'object' && 'message' in fields && typeof fields.message === 'string') {
 const message = JSON.parse(fields.message) as JSONRPCMessage;
 await send(eventId, message);
 nextId = eventId; // Update the next ID to the current event ID
 }
 }
 }
 
 return streamId;
 }
}

この実装では Redis ストリームを使用します。これはこのユースケースに最適です。

制限事項

注意すべき重要な注意点が 1 つあります。ツールが複数のイベントを送信する場合、streamId は _GET_stream に設定されます。 、そしてこの定数は、異なるストリームやユーザー間でも同じままです。これは、2 人のユーザーが複数のイベントを送信する同じツールを同時に使用している場合、彼らのイベントが同じストリーム内で混在する可能性があることを意味します。

これに関する問題を公式リポジトリにオープンしました。解決策によっては、実装を調整する必要がある場合があります。必要に応じてこの投稿を更新します。

使用例 3:事務員の MCP OAuth 実装

MCP 仕様には認証と認可のサポートが含まれており、MCP サーバーがクライアントを安全に認証し、リソースへのアクセスを制御できるようになります。この仕様は、OAuth 2.0 を含む複数の認証スキームをサポートしています。これは、既存の ID プロバイダーと統合し、ツールやデータへのユーザー スコープのアクセスを可能にする場合に特に役立ちます。

Clerk は、MCP SDK から OAuthClientProvider インターフェイスを実装することにより、MCP 用の包括的な OAuth クライアントを構築しました。これらの実装は、MCP アプリケーションにおける Redis の別の重要な使用例を示しています。 MCP ツールを使い始めたい場合は、優れた出発点となるデモ リポジトリをチェックしてください。

OAuth にとってストレージが重要な理由

店員が mcp-tools で説明しているように リポジトリ、永続ストレージは、次の 2 つの主な理由から MCP OAuth 実装に不可欠です。

<オル>

OAuth フローは複数のエンドポイントにまたがります - 初期化、OAuth コールバック、MCP リクエストはすべて、共有メモリなしでさまざまなサーバーレス関数で処理できる

MCP 接続は長時間実行されます - メモリ内ストレージに依存すると、アプリケーションの規模が拡大するにつれてメモリ要件が肥大化し、サーバーが再起動されるとすべてのセッションが無効になります

Redis に保存されるもの

Clerk の Redis ストアは 3 種類のデータを管理し、それぞれが OAuth フローで特定の目的を持っています。

PKCE 検証者 (pkce_verifier_<...> )これらは OAuth フローの開始時に保存され、ユーザーがアクセスを許可した後に再度読み取られます。これらは PKCE (Proof Key for Code Exchange) フローの一部であり、フローを開始したアプリケーションがフローを完了したアプリケーションと同じであることを保証することで、パブリック クライアントの OAuth に追加のセキュリティを提供します (RFC 7636 で定義されているとおり)。

{
 "value": "XoYQ...",
 "created_at": "2025-10-03T06:27:06.928Z",
 "updated_at": "2025-10-03T06:27:06.928Z"
}

セッション データ (session_<...> )これには、MCP セッションのすべての構成と状態が保存されます。最初は、MCP エンドポイント、OAuth 構成、およびクライアントの資格情報が含まれています。ユーザーがアクセスを許可すると、アクセス トークンと更新トークンで更新されます。最後に、authComplete フローが終了するとフラグが追加されます。

{
 "value": {
 "mcpEndpoint": "http://localhost:3001/mcp",
 "oauthRedirectUrl": "http://localhost:3000/oauth_callback",
 "oauthScopes": "openid profile email",
 "mcpClientName": "Clerk MCP Demo",
 "mcpClientVersion": "0.0.1",
 "oauthClientUri": "http://example.com",
 "oauthPublicClient": false,
 "clientId": "8Yb2...",
 "clientSecret": "64YG..."
 },
 "created_at": "2025-10-03T06:27:06.882Z",
 "updated_at": "2025-10-03T06:27:06.882Z"
}

状態パラメータ (state_<...> )これらは OAuth 状態パラメータをセッション ID にマッピングし、状態 ID を使用してセッション データを取得できるようにします。

{
 "value": "dX61...",
 "created_at": "2025-10-03T06:27:03.585Z",
 "updated_at": "2025-10-03T06:27:03.585Z"
}

このアーキテクチャにより、セキュリティとセッションの整合性を維持しながら、OAuth フローが分散サーバーレス機能間でシームレスに動作できるようになります。

Redis が MCP に最適な理由

3 つの例すべてにわたって、MCP インフラストラクチャとして Redis を理想的な選択肢とする共通のパターンがわかります。

低遅延 :MCP 操作は多くの場合、高速である必要があります。 Redis のインメモリ アーキテクチャは、リアルタイム AI インタラクションに必要な応答時間を提供します。

Pub/Sub 機能 :Vercel の実装で見たように、Redis Pub/Sub では、完全なメッセージ キューの複雑さを伴うことなく、分散コンポーネント間のエレガントな調整が可能になります。

豊富なデータ構造 :イベント ストリームのストリーム、セッション データのハッシュ、状態の単純なキーと値のペア。 Redis は、各ユースケースに適切なデータ構造を提供します。

組み込みの有効期限 :TTL による自動クリーンアップ。 OAuth トークン、イベント ストリーム、セッション データはすべて、手動でガベージ コレクションを行わなくても、自動的に期限切れになります。

サーバーレスフレンドリー :Upstash Redis のようなソリューションを使用すると、使用していないときはゼロにスケールする、フルマネージドのサーバーレス Redis が得られます。ワークロードが変動する可能性がある MCP 実装に最適です。

MCP 仕様の機能を超えて:より広範な AI エコシステムにおける Redis

私たちは MCP 仕様で明示的に定義されている機能に焦点を当ててきましたが、AI の強化に関しては、Redis のユーティリティは私たちが調査したパターンをはるかに超えています。最近のブログ投稿では、これらのパターンのいくつかを紹介しています。

• AI SDK の統合 - Redis を使用して Vercel AI SDK を強化する
• チャット履歴 - メッセージング履歴の永続化

私たち自身の例を超えて、コミュニティは AI アプリケーション用の Redis を利用した優れたツールを構築しました。 Midday の ai-sdk-tools スイートには、次の例に示すように、Redis を使用して AI SDK ツールの結果をキャッシュするツール結果キャッシュ パッケージが含まれており、パフォーマンスが大幅に向上し、コストが削減されます。

MCP サーバー、AI エージェント、完全な AI アプリケーションのいずれを構築している場合でも、Redis は、システムを本番環境に対応させ、スケーラブルでパフォーマンスの高いものにするインフラストラクチャ層を提供します。

結論

Model Context Protocol はまだ誕生したばかりですが、急速に AI アプリケーションにとって不可欠なインフラストラクチャになりつつあります。これら 3 つの例を通して見てきたように、Redis は、以下を通じて MCP 実装を堅牢にし、本番環境に対応できるようにする上で重要な役割を果たします。

• スピードと柔軟性 :速度、柔軟性、サーバーレスに適したアーキテクチャの組み合わせ
• コスト削減 :高価な API 呼び出しと計算を削減するキャッシュ機能

MCP を使用して構築している場合、サーバー側でもクライアント側でも、MCP を利用した AI アプリケーションの完璧なコンパニオンとして Redis がツールキットに含まれている必要があります。 Upstash Redis を使用すると、使用されていないときはゼロにスケールできる、世界中で利用可能なサーバーレス Redis を今すぐ数秒で使い始めることができます。