Workers / Durable Objects を本番のままプロファイリングできるように — CPU とメモリのフレームグラフを CLI・ダッシュボード・API から取得

要約

Cloudflare が、本番稼働中の Worker と Durable Object をその場でプロファイリングできる機能を発表しました。CPU とメモリの2種類を取得でき、インタラクティブなフレームグラフで表示し、プロファイルファイルをダウンロードできます。

公式の立場は明快です。「アプリケーションを理解する最良の方法は、本番でプロファイルすることだ」。

フレームグラフの読み方は、箱の幅です。 各箱が関数呼び出しで、幅がその関数が使った CPU 時間またはメモリを表します。横に広い箱を探せば、時間を食っている場所が分かります。

経路は3つあります。

CLI は cf パッケージを使います。Wrangler ではありません。 公式の例は cf workers versions profile latest に Worker の ID または名前、--duration-ms の値、--profile-type cpu を渡し、結果を .pprof として保存する形です。

ダッシュボードは Observability タブです。 Build → Compute → Workers & Pages → 対象 Worker → Observability タブ → ドロップダウンで Flamegraph を選び、CPU / メモリとバージョン・期間を指定して Capture Profile を押します。

API は script version のプロファイルエンドポイントへ {"duration_ms":5000,"profile_type":"cpu"} のような JSON を投げます。

出力は3種類です。 インタラクティブなフレームグラフ、関数をサンプル数順に並べたテーブルビュー、そしてダウンロード可能なプロファイルファイル。公式の記事では、取得したヒーププロファイルを pprof で開いています。手元の既存ツールチェーンにそのまま乗ります。

オーバーヘッドの数値は公式に記載がありません。 代わりに仕組みが説明されています——プロファイルの開始と停止の瞬間だけ isolate ロックを取るため、サンプリング中も Worker はリクエストを処理し続ける。CPU サンプリングの間隔は 1ms です。

ここから制約です。実務ではこちらのほうが重要です。

プロファイル用に新しい isolate を立てないため、対象はデプロイ済みで稼働中のバージョンだけです。 さらに、有用な結果を得るには選んだバージョンに十分なトラフィックが必要です。サンプリング方式なので、呼ばれていない関数は現れません。

セッションは毎回手動で開始します。 公式はこれを制約として明記し、**「一時的に現れる問題は取り逃がしうる」**と書いています。継続プロファイリングは開発中とされています。

メモリプロファイラは、プロファイリング窓の中で行われたアロケーションだけを捕まえます。起動時のアロケーションは含まれません。 初期化で大きな構造を確保している場合、それはフレームグラフに出てきません。

TypeScript の Worker は source maps を有効にしないと関数名が読めません。 Durable Objects は名前で特定のオブジェクトを選び、リクエストはそれを所有するロケーションへルーティングされます。

提供プラン・価格・正式な提供開始日の記載はありません。

何が変わったか

• 稼働中の Worker / Durable Object を本番のままプロファイリングできる（2026-10-09 公表）
• 取得できるもの: CPU プロファイルとメモリプロファイル
• 出力: インタラクティブなフレームグラフ、サンプル数順のテーブルビュー、ダウンロード可能なプロファイルファイル（.pprof）
• 経路3つ
  • CLI: cf パッケージ（Wrangler ではない）。cf workers versions profile latest <id|name> --duration-ms <ms> --profile-type cpu
  • ダッシュボード: Build → Compute → Workers & Pages → 対象 Worker → Observability タブ → Flamegraph → Capture Profile
  • API: script version のプロファイルエンドポイントへ {"duration_ms":5000,"profile_type":"cpu"}
• 仕組み: 開始・停止の瞬間だけ isolate ロックを取るため、サンプリング中もリクエスト処理は継続。CPU サンプリング間隔は 1ms
• 制約
  • デプロイ済みで稼働中のバージョンのみ（プロファイル用に新しい isolate を立てない）
  • 十分なトラフィックが必要
  • セッションは毎回手動開始。 公式は「一時的な問題は取り逃がしうる」と明記
  • メモリプロファイラはプロファイリング窓内のアロケーションのみ。起動時は含まない
  • TypeScript は source maps 必須（無効だと関数名が読めない）
  • Durable Objects は名前で対象を選び、所有ロケーションへルーティングされる
• 記載が無いもの: 提供プラン、価格、正式な提供開始日、オーバーヘッドの具体数値
• 継続プロファイリング（continuous profiling）は開発中

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

最初にやることは、TypeScript の Worker で source maps を有効にすることです。

これを後回しにすると、機能を使える状態になっていません。 source maps が無いと、フレームグラフにミニファイされた関数名しか出ません。 「どの関数が遅いか」を見るための道具で関数名が読めないなら、使えないのと同じです。障害が起きてから有効にしようとすると、デプロイが必要になり、その時点の本番は観測できません。 先に入れておく種類の設定です。

次に、CLI が Wrangler ではなく cf パッケージであることを確認してください。 公式記事の例は cf を使っています。既存の CI やローカル環境に Wrangler しか入っていないなら、別途導入が必要です。 「Wrangler のサブコマンドだろう」と思って探すと見つかりません。

この機能が実際に変えるのは、性能問題の調査手順です。

これまで Workers の性能問題は、ログとメトリクスからの推測でした。 CPU time が上がっている、という事実は見える。どの関数が食っているかは見えない。 結果として「ローカルで再現を試みる」か「怪しい箇所にログを挟んで再デプロイする」ことになります。どちらも本番とは条件が違います。 エッジのランタイム、実際のトラフィックパターン、実データのサイズ——ローカルでは揃いません。

本番のフレームグラフが取れるなら、推測の工程が消えます。 「CPU time が上がっている」から「この正規表現が全体の60%を使っている」まで、1回のキャプチャで到達できます。

ただし「手動開始」という制約が、適用範囲を決めます。

常時高い負荷には効きます。 いつ取っても同じものが見えるからです。断続的なスパイクには効きません。 公式自身が「一時的に現れる問題は取り逃がしうる」と書いています。スパイクが起きた瞬間に手でキャプチャを押すのは、現実的ではありません。

断続的な問題には、従来の手段を残してください。 メトリクスのアラート、構造化ログ、トレース。プロファイリングはそれらの置き換えではなく、「原因の特定」の段を短くする道具です。切り分けはこれまでどおり必要です。継続プロファイリングが開発中とされているので、ここは将来埋まる可能性があります。

メモリの調査では、起動時アロケーションが見えない点に注意してください。 初期化で大きな辞書や設定を読み込んでいる構成では、それがフレームグラフに現れません。 「メモリを食っているはずなのに、プロファイルに出てこない」という状況が起きます。起動時の確保量は、プロファイリングではなくコードを読んで把握するしかありません。この境界を知らないと、調査が空振りします。

Durable Objects の調査では、どのオブジェクトを見るかを決める必要があります。 Durable Objects は名前で特定のオブジェクトを選ぶ仕様です。つまり**「全体のどこが遅いか」ではなく「このオブジェクトのどこが遅いか」**を見る道具です。遅いオブジェクトを特定する作業は、プロファイリングの前に別の手段で済ませておく必要があります。

社内の障害対応手順書に、この経路を追記する価値があります。 「Workers の CPU time が高いとき」の節に、ダッシュボードの Observability タブからフレームグラフを取る手順を入れてください。障害の最中に初めて機能を探すのは最悪のタイミングです。 平時に一度取ってみて、手順を書いておくのが有効です。

提供プランと価格が未記載なので、本番運用への組み込みは確認してからにしてください。 公式記事に記載がありません。無料で使えると仮定して手順書に書くのは早いです。

副業・個人活用視点

この機能は、受託の保守案件で「見える化」を提案する材料になります。

性能問題は、原因が分かるまでが仕事の大半です。 「遅い」という報告を受けて、ログを見て、推測して、仮説を検証する。この工程に時間がかかるから見積もりが膨らみ、顧客は「なぜ原因調査にそんなにかかるのか」と感じます。 本番のフレームグラフを1枚見せられるなら、説明が一瞬で終わります。

提案の形にしやすいです。 「現在の Worker をプロファイルして、CPU 時間の内訳をフレームグラフでお見せします。source maps を有効にする設定変更が先に必要です」——設定変更1件とキャプチャ1回で、成果が目に見える仕事です。保守契約の価値を示す材料として、粒度がちょうどよいです。

個人開発では、無料枠の中で何に CPU を使っているかが見えます。 Workers の課金は CPU time が効きます。「どこで CPU を使っているか」が分からないまま最適化すると、効かない場所を直すことになります。 フレームグラフで幅の広い箱を探せば、直すべき場所が1つに絞れます。個人開発で最も無駄になりやすいのは、効果のない最適化に時間を使うことです。

記事にするなら、「取り逃がす条件」を書くと価値があります。 公式記事は機能の紹介として読まれます。制約の節は、実際に使って初めて効いてくる部分です。 手動開始だから瞬間的な問題は取れない、メモリは起動時が見えない、トラフィックが無いと何も出ない——これらを知らずに使って空振りした記録は、同じことをしようとする人に確実に読まれます。

.pprof という出力形式は、記事の切り口として単独で成立します。 Go のエコシステムで育った pprof 形式を出すということは、既存の解析ツールがそのまま使えるということです。独自形式のビューワに閉じ込めず、標準形式を出す設計判断は、観測ツールを評価するときの重要な指標です。「ダッシュボードで見られる」だけの製品と、「ファイルを出してくれる」製品の差を説明する材料になります。

フレームグラフの読み方そのものが、まだ需要のある題材です。 箱の幅が時間、縦が呼び出しの深さ——この2点を知らない人は多い。 Workers という具体的な対象で説明すれば、抽象的な解説より読まれます。自分のプロジェクトのフレームグラフを貼って「ここが広いのはこういう理由」と書くのが、一番価値のある形です。

関連リンク

• Introducing on-demand CPU and memory profiling with flamegraphs for Workers and Durable Objects（Cloudflare Blog）
• Workers Observability（Cloudflare Docs）