MCP が「聞かれたら答える」から「起きたら知らせる」へ — Cloudflare API MCP server が Workers Issues を push で配信

要約

Cloudflare API MCP server が、Workers Issues を MCP Events として MCP クライアントへ送るようになりました。公式は、これが同サーバーが公開する最初の event だと記しています。

この変更の本質は、MCP の方向です。

MCP はこれまで、クライアント（エージェント）が聞いて、サーバーが答える仕組みでした。ツールを呼ぶ、リソースを読む——いずれもエージェント側が起点です。サーバー側から「いま何か起きた」と伝える経路はありませんでした。

そのため、本番エラーを起点にエージェントを動かしたい場合はポーリングしかありませんでした。 定期的に「新しい issue はあるか」と聞き続ける構成です。間隔を短くすれば検出は速くなりますが呼び出しが増え、長くすれば検出が遅れます。

今回、サーバーからクライアントへ push が入る経路が開きました。

Workers Issues は Cloudflare 組み込みの Workers 向けエラー監視です。本番の失敗を検出し、関連するものを issue へグループ化します。SDK の導入やアプリ側の変更は不要です。

購読の流れは3段階。

1. events/list を呼び、event cloudflare.alert.workers_observability_real_time_issue を見つける
2. events/subscribe で購読する。アカウント全体または単一 Worker のスコープを選べる
3. Issues が新規または再発の issue を検出したとき、サーバーが署名付き event をクライアントの webhook へ送る

**公式が挙げている効果は「エージェントが、検出された時点で本番エラーの調査を始められる。新しい issue のポーリングが不要になる」**です。

要件は3つ。

• 対象 Worker で Issues を有効にする
• クライアントを https://mcp.cloudflare.com/mcp へ接続し、Notifications Write と Workers Observability Write の権限を付ける
• MCP Events の webhook に対応したクライアントを使う

MCP Events そのものは、triggers と events の実験的な MCP 拡張としてリンクされています。changelog は仕組みの詳細を定義していません。 当サイトの執筆環境からは拡張仕様の一次確認ができていないため、メソッド名として確認できているのは events/list と events/subscribe、event 名として cloudflare.alert.workers_observability_real_time_issue の3つだけです。それ以外の仕様（他のメソッド、capability のキー名、署名の検証方法）はこの記事では扱いません。

何が変わったか

• Cloudflare API MCP server が Workers Issues を MCP Events として配信（同サーバー初の event）
• event 名: cloudflare.alert.workers_observability_real_time_issue
• 購読メソッド: events/list（発見）→ events/subscribe（購読）
• スコープ: アカウント全体または単一 Worker
• 配信: 新規または再発の issue 検出時に、署名付き event をクライアントの webhook へ
• ポーリングが不要になる
• 必要な権限: Notifications Write と Workers Observability Write
• 接続先: https://mcp.cloudflare.com/mcp（変わらず）
• 前提: 対象 Worker で Issues を有効化、MCP Events の webhook 対応クライアント
• MCP Events は実験的な MCP 拡張として位置づけられている

業務インパクト（一般企業向け）

1. 障害対応の起点が人からエージェントへ移る構成が組める

これまでの流れは「監視が検出 → 人へ通知 → 人が調査を始める」でした。エージェントを挟む場合も、人が「調べて」と指示する必要がありました。

今回の構成では、検出された時点でエージェントが調査を始められます。 人が通知を見る前に、ログの確認と原因の切り分けが進んでいる状態を作れます。夜間や休日の一次切り分けは、これで実用的になります。

2. 「誰も指示していないのにエージェントが動く」状態を設計に入れる

これは便利さの裏側です。push が入る経路が開いたということは、エージェントが自分の判断で動き出す状態が生まれるという意味です。

決めるべきことは具体的です。(1) エージェントが調査だけするのか、修正まで試みるのか。 (2) スコープをアカウント全体にするか、単一 Worker にするか——公式が両方を用意しているのは、ここが設計の選択肢だからです。アカウント全体にすると、関係のない Worker の issue でもエージェントが動きます。(3) 深夜に issue が連続したとき、エージェントが何回動くのか。

「ポーリングが不要になる」は、裏返せば「こちらの都合で頻度を決められなくなる」ということです。頻度は issue の発生側が決めます。

3. API トークンの権限が2つ増える

Notifications Write と Workers Observability Write が必要です。どちらも Write 権限です。MCP server への接続先 URL は変わらないので、既に Cloudflare API MCP server を使っている環境では「トークンの権限を足す」という形の変更になります。

トークンの権限を足すときは、そのトークンが他に何に使われているかを確認してください。 1つのトークンを複数の用途で使い回していると、この追加で他の経路にも Write 権限が渡ります。 用途ごとにトークンを分けていない組織は、ここで分ける判断をする機会です。

4. 対応クライアントが前提になる

MCP Events の webhook に対応したクライアントが必要です。接続すれば自動で使えるものではありません。手元のクライアントが対応しているかを確認するのが最初の一歩です。対応していなければ、この機能は使えません。

5. Issues の有効化が前提

対象 Worker で Issues を有効にする必要があります。 Issues 自体は SDK 不要で使える組み込み機能ですが、有効にしていなければ event は飛びません。 「MCP の設定をしたのに何も来ない」という状態の典型的な原因になります。

副業・個人活用視点

1. MCP の説明を更新する必要がある

MCP を人に説明している立場なら、「クライアントが聞いて、サーバーが答える」という説明は、もう完全ではありません。 今回は実験的な拡張の段階ですが、方向が一方通行でなくなるという変化は、仕組みの理解として大きいです。

研修や記事で MCP を扱っているなら、ここは差分として押さえておく価値があります。 「ツールを呼ぶための規格」として覚えた人には見えにくい変化です。

2. 「通知駆動のエージェント」は提案の形が新しい

エージェントの提案はたいてい「人が指示して動く」形です。「異常が起きたら勝手に動く」形の提案は、まだ数が少ない。障害の一次切り分けは、夜間対応の人件費と直接比較できるので、投資対効果の説明がしやすい領域です。

ただし提案には、暴走を止める設計を必ず含めてください。 止め方の説明がない自動化の提案は、情シスに通りません。

3. 試して確かめる余地が大きい

changelog は仕組みの詳細を定義していません。 署名の検証方法、他にどんなメソッドがあるか、capability のキー名——どれも公式の changelog からは読めません。

events/list を叩いて何が返るかを確かめた記録は、そのまま一次情報になります。公式ドキュメントに書かれていないことを実験で埋めた記事は、公式に書かれていないという理由で価値が出ます。 実験的な拡張の段階は、この余地がいちばん大きい時期です。

4. スコープ設計を語れると要件定義から入れる

アカウント全体か単一 Worker か。この選択は技術的な難易度はゼロですが、運用の結果が大きく変わります。 複数のサービスを1つのアカウントで動かしている組織では、アカウント全体の購読は関係のない issue でエージェントを起動させます。

こうした「設定項目1つで運用が変わる」箇所を事前に指摘できる人は、実装者ではなく設計者として扱われます。 単価の差はここで付きます。

5. 情報源の制約を明記する書き方

この記事では、確認できたメソッド名3つ以外は扱わないと明記しました。 MCP Events の拡張仕様へ到達できなかったためです。二次情報には仕様の説明が出回っていますが、一次確認なしでは書きません。

この判断をそのまま書くこと自体が、読者への情報です。「どこまでが公式確認済みか」が分かる記事は、実装でつまずいたときに戻ってこられます。全部書いてあるように見える記事より、境界が明示された記事のほうが使えます。