MCPでCloudflare Workersのログを調査してエラーを特定した話

MCPを活用してCloudflare Workersのログを直接調査し、本番環境で発生した500エラーの原因を特定。AIアシスタントがAPIを呼び出してログを解析する効率的なトラブルシューティング手法を紹介。

この記事では、Cloudflare Observabilityサーバーを使用して Cloudflare Workersにデプロイしたアプリに発生したトラブルを調査する方法を紹介します。

Cloudflare Workersで運用しているOG画像生成サービスで、本番環境のみで500エラーが発生しました。今回は、Model Context Protocol（MCP）のCloudflare Observabilityサーバーを使用して、本番環境のログを直接調査させることにしました。

MCPとは

Model Context Protocol（MCP）は、AIアシスタント（Claude、ChatGPTなど）が外部のツールやサービスと安全に連携するためのプロトコルです。2024年11月にAnthropicが発表した新しい標準規格で、AIシステムとデータソースの間に統一されたインターフェースを提供します。

従来、Cloudflare Workersのログを調査するには、Cloudflare Dashboardにログインし、該当のWorkerを選択してLogsタブでエラーをフィルタリングする必要がありました。この手順は煩雑で、ログの検索や分析に時間がかかります。

MCPを使うと、これらの操作をAIアシスタントに依頼するだけで完結します。AIアシスタントが直接APIを呼び出してログを取得し、エラーの分析までサポートしてくれます。手動でDashboardを操作する必要がなくなり、調査にかかる時間を大幅に短縮できます。

Cloudflare Observability MCPサーバーの設定

Cursor IDEでMCPサーバーを使用するには、設定ファイルにMCPサーバーの情報を追加します。CloudflareのWorkers Observability MCPサーバーは、リモートMCPサーバーとして提供されており、OAuth認証を使って安全に接続できます。

Cursor IDEの設定を開き、以下の設定を追加してください。

{
  "mcpServers": {
    "cloudflare-observability": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://observability.mcp.cloudflare.com/mcp"
      ]
    }
  }
}

npx コマンドは、Node.jsのパッケージを実行するためのツールで、mcp-remote パッケージを使ってリモートMCPサーバーに接続します。https://observability.mcp.cloudflare.com/mcp は、Cloudflareが提供するObservability MCPサーバーのエンドポイントです。

設定後、Cursor IDEを再起動するとブラウザが開き、CloudflareのOAuth認証画面が表示されます。認証を完了すると、AIアシスタントがCloudflare Workers Observability APIを使用できるようになります。この認証により、AIアシスタントはあなたのCloudflareアカウントのWorkerログに安全にアクセスできます。

Cursorに調査をさせる

セットアップと認証が成功すれば、あとは「このWorkersでXXというエラーが発生している。MCPでログを調査しなさい。」のような指示を出しましょう。 Cursor / Claudeなどであれば、Planモードで調査を指示することをお勧めします。Agentモードですと、調査結果を報告するより前に修正作業を始めることがありますので要注意です。

ちなみにMCPは以下のような順番で使われた様子でした。

Workersのリストを取得

Observability APIで利用可能なキーを確認

エラーログを検索

発見したエラーの詳細を分析

MCPを利用した調査によって以下のエラーがログに残されていることが判明します。

Error: Failed to initialize Worker - missing required bindings:
  - ASSETS binding is required but not found in environment

Please ensure all required bindings are configured in wrangler.jsonc

MCPはどのスクリプトバージョンでエラーが発生したかなども調べてくれる様子です。スクリプトバージョンIDを特定することで、どのデプロイでエラーが発生したかを正確に把握できます。どのデプロイで発生したエラーかが特定できれば、あとはGitのログなどを調査することでより踏み込んだレポートが取得できます。実際に今回のケースでは、最新のブランチがデプロイされていない可能性が高いことをMCPとCursorのエージェントが特定してくれました。

デプロイされていない差分があることが判明したので、そのままローカルのコードベースをCursorは調査してくれました。ローカルのコードは既に修正すみだったため、調査レポートでは最新バージョンのデプロイをサジェストされました。

MCPを使って、エディタの中で調査をすすめる

このようにMCPを接続することで、デプロイ後に発生したエラーやデプロイそのもので起きたエラーの調査などもエージェントに指示できます。特に手動でログを調査する場合は、どのログストリームを見るべきかの判断や検索作業の手間、そして発見したエラーログの解釈などの時間が発生します。これらをコーディングエージェントに任せて問題の仮説を立てさせることができるのは、大きな効率化です。

もっとも信頼しすぎる危険性もあります。調査結果もしくは考察フェーズでは、ハルシネーションやモデルの知識カットオフによるタイムラグなどを原因とする誤った判断が発生することがあります。仮説や考察が間違っていると、解決策自体も誤った前提によって作られてしまうため、場合によっては問題をより大きくしかねません。このような問題の発見や予防には、エージェントを利用する開発者自身が好奇心を持って知識のアップデートやチャレンジを続ける必要がありそうです。

まとめ

MCPのCloudflare Observabilityサーバーを使用することで、Cloudflare Workersのログ調査が大幅に効率化されました。従来はDashboardでの手動操作が必要だった作業が、AIアシスタントへの依頼だけで実行できるようになり、問題の特定から解決までを短時間で完了できました。今後も、同様のトラブルシューティングでMCPを活用していきたいと思います。

参考リンク

Model Context Protocol (MCP)

Cloudflare Workers Observability

Cloudflare MCP Server