2026 年 5 月 12 日、InfoQ が Grafana’s Pyroscope 2.0 Makes Continuous Profiling Practical at Scale を公開し、Pyroscope 2.0が 「本番でフルタイム動かしても重くない継続プロファイリング」を実現したと報じました。
これまで弊社の受託運用案件でも、「CPU 100% 張り付き」「メモリリークでスケールアウトが効かない」「同じインスタンス数なのに先月より遅い」といった 再現性の低い性能問題が頻発していました。継続プロファイリングは 「いつ / どの関数 / 何を消費したか」を コードレベル + 時系列で残せる仕組みで、クラウドコスト 20〜40% 圧縮の 直接的な根拠になります。これは Local-First AI 推論で API コスト 75% 削減 で扱った 「ホットスポットを実測で叩く」設計思想の 汎用版と整理できます。
なぜ「ログ + メトリクス + トレース」だけでは足りないのか
| 観測対象 | 既存スタック | 解けない問題 |
|---|---|---|
| エラー | ログ + Sentry | OK |
| 応答時間 | メトリクス + Grafana | OK |
| リクエスト経路 | 分散トレーシング | OK |
| CPU / メモリのホットスポット | サンプリングなし | 「どの関数が遅いか」不明 |
| 間欠的なリーク | スナップショット型 | 再現できない |
3 本柱（Logs / Metrics / Traces）は **「何が起きたか」「どこで遅いか」は分かりますが、「コードのどの行が CPU を食ったか」**は 継続プロファイリングでしか分かりません。これは OpenTelemetry × Airbnb 可観測性移行 で扱った 3 本柱に「Profiling」を加える 4 本目の柱として位置づけられます。
Pyroscope 2.0 の 3 つの革新
革新 1: eBPF サンプリングで「本番に常駐」可能
Pyroscope 2.0 は eBPFを活用し、アプリ無改造で CPU 0.5〜1.5% のオーバーヘッドで 常時プロファイリングできます。これは 「本番に重さで入れられない」従来の壁を解消しました。
革新 2: 「コミット差分」とフレームグラフを紐づけ
Git コミット ハッシュと フレームグラフを紐づけ、「あのリリース以降、関数 X の CPU 使用が 2.4× になった」という 回帰分析が 数クリックで可能になります。
革新 3: OpenTelemetry トレースとの相関
OTel のスパンに Profile IDが紐づき、「遅いトレース → そのスパンで動いていた関数のホットスポット」を 1 アクションで参照できます。これは 「メトリクス → トレース → プロファイル」の 垂直ドリルダウンを実現します。
受託で構築する 4 つの実装フェーズ
フェーズ 1: コスト診断（2 週間）
Cost Explorer + CloudWatch / Datadogで **「インスタンス費 vs 実 CPU 利用率」を実測し、「過剰プロビジョニングの実額」**を顧客に提示します。ROI 試算の根拠を握ります。
フェーズ 2: Pyroscope 導入（3 週間）
Pyroscope OSS / Grafana Cloud Profilesを選定し、本番 + ステージングに展開します。eBPF サンプリングで アプリ無改造を前提に進めます。
フェーズ 3: ホットスポット改善ループ（8 週間）
月 3〜5 件のホットスポットを コミット差分 + フレームグラフで特定し、コードレビュー → 修正 → 本番反映 → 効果測定の 2 週ループで回します。
フェーズ 4: 継続運用 + 月次レポート（運用）
月次でホットスポット top 10を顧客にレポートし、「インフラ費削減」と 「応答時間改善」を KPIで可視化します。これは DORA / SPACE / Core 4 ROI 受託 で扱った 継続改善の可観測性版です。
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| プロファイラ | Pyroscope 2.0 + eBPF | Parca / Polar Signals |
| 可視化 | Grafana Cloud Profiles | Pyroscope OSS UI |
| OTel 連携 | OpenTelemetry Collector | Tempo + Pyroscope |
| コスト分析 | AWS Cost Explorer + CUR | GCP Billing Export |
| アラート | Grafana Alerting | PagerDuty |
| 改善管理 | Jira / Linear | GitHub Projects |
| CI 統合 | GitHub Actions + プロファイル差分 | GitLab CI |
特に **「コミットごとの CPU 関数差分」を PR レビューで表示することで、「マージ前にホットスポット悪化を検知」**できます。これは GitHub Agentic Workflows と組み合わせて CI に組み込む価値があります。
どの案件で刺さるか
| 向く案件 | 効果 |
|---|---|
| 月インフラ費 100 万円超の SaaS | 20〜40% 削減で月 20〜40 万円 |
| Node.js / Go の高負荷 API | GC / イベントループ最適化 |
| Python / Ruby のバッチ処理 | ホットスポット可視化で高速化 |
| EC / 在庫の月末ピーク | ピーク時のホットスポット解析 |
| ゲーム / リアルタイム配信 | レイテンシ毎ミリ秒の改善 |
受託契約に書く 5 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 削減目標 SLA | 月インフラ費の削減率目標 | 未達時の対応 |
| オーバーヘッド許容範囲 | 本番 CPU の追加負荷 | 業務影響の許容 |
| 保管期間 | プロファイルデータの期間 | ストレージコスト |
| 改善範囲 | コード修正の責任分界 | 顧客側 / 受託側 |
| コミット連携 | Git アクセス権の範囲 | コンプライアンス |
価格モデル — Pyroscope 継続プロファイリング受託パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| コスト診断 | 60 万円〜 | 2 週間 | 過剰プロビジョニング分析 |
| Lite | 400 万円〜 | 6 週間 | 1 サービス導入 + 初期改善 5 件 |
| Standard | 1,200 万円〜 | 3 ヶ月 | 上記 + 3〜5 サービス + ループ運用 |
| Care（運用代行） | 月 60 万円〜 | 12 ヶ月〜 | 月次ホットスポット改善 + レポート |
ハマりやすい 4 つの落とし穴
落とし穴 1: 「全サービスにいきなり導入」
全サービス同時導入は オーバーヘッド計測の範囲が広すぎて、異常検知が機能しません。1 サービスずつ段階導入が原則です。
落とし穴 2: ホットスポットだけ追って効果測定をしない
「修正したつもり」で 本番のフレームグラフが変わらないケースが頻発します。Before / After のフレームグラフ比較を 修正レビューの必須項目にします。
落とし穴 3: プロファイルデータの保管コストを過小評価
1 サービス 1 ヶ月で 50〜100GBのプロファイルが溜まります。Hot / Warm / Cold の階層保管を最初から設計します。
落とし穴 4: 改善 KPI を「速さ」だけで握る
**「応答時間を 20% 改善」だけで握ると、「ストレージ費が増えた」などの副作用を見落とします。「速さ × インフラ費 × エラー率」**の 複合 KPIで握ります。
まとめ — 「3 本柱」から「4 本柱」へ
Pyroscope 2.0 は、継続プロファイリングを 「本番に常駐できる」実用域に押し上げ、Logs / Metrics / Traces / Profilesの 4 本柱可観測性を エンタープライズ標準にする転換点です。クラウドコスト 20〜40% 圧縮は、継続改善の自己投資 ROIとして 最も再現性が高い領域です。
弊社では コスト診断 / Lite / Standard / Care の 4 段階で Pyroscope 継続プロファイリング受託パッケージを提供しています。「クラウド費が読めない / 削減余地が見えない」「継続的にホットスポットを潰したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
