-- Views
August 07, 26
スライド概要
https://workers-tech.connpass.com/event/399304/
Developer
Cloudflare Workers Teck Talk Osaka #3 それでもやっぱり MCP Cloudflare Workers で作る Remote MCP サーバー 岡本秀高 @hidetaka_dev
自己紹介 Hidetaka Okamoto (岡本秀高 ) ● CircleCI Senior Field Engineer ● 個人開発で AI / Cloudflare あと AWS ぶん回す人 ● 年間ブログ件数 100 - 150 本ペースを 10年以上 ● https://hidetaka.dev 2
AGENDA 本日の お話 01 MCPが要る場⾯∕要らない場⾯ 02 認証をサーバー側に置く 03 状態の置き場:KV / DO / D1 / WAE 04 2026-07-28 の仕様変更
API / CLIがあれば、 MCPいらなくね? 01
AGENDA CLIが使えるなら、 MCP の設定は基本不要
AGENDA CLIが使えるなら、 MCP の設定は基本不要 npx / uv / docker とかで動かすやつは、個人的に not for me
AGENDA CLIが使えるなら、 MCP の設定は基本不要 → CLI が使えない環境では?
Remote MCPは、skill と web_fetch で済まないときの手段 CLIが使えるか 使える → skill + CLI web_fetchなどのビルトインツールで取得できる 届く → web_fetch どちらでもアクセスできない場所 → Remote MCP
配布側のメリット : Claudeなどで1クリックインストールさせれる手軽さ
ただしこれは各サービスによる審査が必要 https://claude.com/docs/connectors/building/directory-vs-custom
運用中の MCP サーバーにあるツール(一部) 1. WordPressの記事管理系統 記事の取得‧更新(タグやカテゴリなども)に加えて Revision / Diff 取得など 2. Google Analytics 4 / Search Console データ取得系 定型分析‧クエリ実⾏‧ PDCA サイクル的ワークフローなど 3. MCP利⽤状況分析系 エラー発⽣や利⽤状況の分析など
APIラッパーよりもワークフロー
Cloudflare で Remote MCP サーバーを作る 02
npm create cloudflare@latest -- remote-mcp-server \ --template=cloudflare/ai/demos/remote-mcp-google-oauth
npm create cloudflare@latest -- remote-mcp-server \ --template=cloudflare/ai/demos/remote-mcp-google-oauth たぶん近々 Deprecated になる
MCP の仕様が 大幅に変更 https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
MCP がステート・セッションを持たなくなる
MCP がステート・セッションを持たなくなる https://developers.cloudflare.com/agents/model-context-protocol/guides/migrate-to-mcp-sdk-v2/
MCP がステート・セッションを持たなくなる https://developers.cloudflare.com/agents/model-context-protocol/guides/migrate-to-mcp-sdk-v2/
MCP がステート・セッションを持たなくなる https://developers.cloudflare.com/agents/model-context-protocol/guides/migrate-to-mcp-sdk-v2/
MCP-Protocol-Version: 2026-07-28は、 まだ「Release Candidate」 → 直ちに従来の MCP が死ぬことはない 02
but 02
今からRemote MCPサーバーを作るなら ・Agents SDK v0.20.0以上 ・MCP-Protocol-Version: 2026-07-28 を要件に入れよう 02
AGENDA 時間があれば Remote MCPサーバーにおける データ保管場所の使い分け
MCPで使っているリソース
wrangler.jsonc L25-54(各バインディングを1行に詰めて表示・IDは <REDACTED>)
"durable_objects": {
"bindings": [{ "class_name": "MyMCP", "name": "MCP_OBJECT" }]
},
"kv_namespaces": [{ "binding": "OAUTH_KV", "id": "<REDACTED>" }],
"d1_databases": [
{ "binding": "ANALYTICS_DB", "database_name": "mcp-analytics", "database_id": "<REDACTED>" }
],
"analytics_engine_datasets": [
{ "binding": "MCP_ANALYTICS", "dataset": "mcp_tool_usage" }
KV と DO はテンプレート由来、D1 と Analytics Engine は⾃分の追加
利用状況や Tool追加効果の検証は WAE
長期記憶は D1 / KV (クエリでの使い分け )
長期記憶は D1 / KV (クエリでの使い分け )
レポートとかは MCP Appsでよりリッチに
外部APIのレスポンスキャッシュを DOで 理論上は、sessionIDではなくuserIdをキーにするなどで新仕様でも可能(らしい)
AGENDA まとめ MCP vs CLI / API ではなく、 CLI & API & MCP
まとめ 1. 今後 MCP はステートレスになる これまでの情報が古くなる点に注意 2. キャッシュや永続化などで、 D1 / DO / KVなどを組み合わせよう 保存するキーや取得時のクエリで使い分けの意思決定 3. ワークフローを MCP 化するのは楽しい Google / GitHub OAuth でみんなもオレオレ MCP サーバーを作ろう