TL;DR
- 2026年の Platform Engineering 予算中央値はサブ$1M から倍増し、リーダー組織は $5-10M を投資して AI/セキュリティ/オブザーバビリティを統合する
- ただし業界の 29.6% は依然「成功を測っていない」状態で、予算の有無と成果の連動が崩れている（Platform Engineering Maturity Report Vol.4）
- 投資判断の本丸は「規模」より「測定軸」: CNCF 5次元成熟度（Investment / Adoption / Interfaces / Operations / Measurement）のどこに穴があるかを見える化してから配分する
- AI を Platform に組み込むコスト（LLM Gateway / policy-as-code / コスト配賦）が新規予算ラインとして必須化
- リアクティブ予算（45.5%）から戦略的投資への転換は1年単位で計画する
この記事の目的と成功基準
- 目的: Platform Engineering の予算規模感を2026年データで具体化し、自社の投資判断材料にする
- 想定読者: Platform チームの EM / VP Engineering、予算策定に関わるテックリード
- 成功基準: 「Platform Engineering 予算」「DevEx 投資」関連クエリでの流入、Platform Engineering AI 時代 への回遊
なぜ予算が倍増しているのか
State of Platform Engineering Report Vol.4 は、組織が CNCF の5次元成熟度モデル（Investment / Adoption / Interfaces / Operations / Measurement）に沿って漸進的に進化していると報告している。同時に2026年は予算規模の構造変化が起きた節目だ。
サブ$1M に集中していた予算分布が中央値倍増へ移行し、リーダー組織は $5-10M を投じる。理由は3つ。
- AI 統合の必須化: LLM Gateway・policy-as-code・cost attribution が IDP の標準コンポーネントに。詳細はPlatform Engineering AI 時代で扱った
- セキュリティとの統合: Zero Trust・SBOM・Supply Chain 監査が Platform 責務に組み込まれ予算が増える
- オブザーバビリティ統合: 自社観測スタック（trace + eval + cost）の整備、LLMオブザーバビリティ の延長
「Platform を作る」段階から「Platform を運用しながら拡張する」段階へ移行した組織が、年間 $5M 以上を投じるようになった。
構造的ギャップ：29.6% は依然「測っていない」
Vol.4 の最も衝撃的なデータは、業界の 29.6% が どんな成功指標も測っていない こと。45% から進歩したとはいえ、2026年に「測っていない組織が3割」という状態は構造的な遅滞を示す。
| 状態 | 割合 |
|---|---|
| 何も測っていない | 29.6% |
| リアクティブ予算（測っているが戦略性なし） | 45.5% |
| 戦略的・データ駆動 | 残り |
「予算は付いているが何が成功か分からない」状態は最悪のシナリオ。投資が成果につながっているか判定不能で、CFO レビューで予算を削られるリスクが高い。
予算配分の5次元フレーム
CNCF 成熟度モデルの5次元で予算を分けると、抜けが見える。
1. Investment（投資）
- 専任エンジニア数（FTE）と外部ツール費用
- リーダー組織：5-10 FTE + ツール契約 $1-3M
- 中堅組織：2-5 FTE + ツール契約 $200K-1M
2. Adoption（採用率）
- アプリチームの利用率を四半期で計測
- IDP 経由のリリース割合、self-service カタログ採用率
- 採用率が伸びない予算は無駄。投資前提として目標値を設定
3. Interfaces（インターフェース）
- CLI / Web Portal / API の整備
- バックステージなど OSS 採用 vs 内製の判断
- 内製は人件費年間 $500K-1M、OSS は運用 FTE 1-2 名
4. Operations（運用）
- インシデント対応・SLA 維持・コンプライアンス対応
- 24時間 on-call ローテーション要員、外部監査費用
- 想定外コストの最大ライン
5. Measurement（測定）
- DORA / SPACE / DevEx / 自社独自 KPI
- 測定ツール費用（DX Score、Jellyfish、LinearB 等）
- 最初に整えるべき軸（測定がないと他4軸の投資妥当性が立たない）
投資判断のチェックリスト
予算策定前のセルフチェック：
- 5次元のどこに弱点があるか、現状値を数値で言える
- AI 統合（LLM Gateway / policy / 監査）の予算ラインが独立計上されている
- 採用率（Adoption）の四半期目標が設定されている
- DORA / SPACE / DevEx のいずれかで成果を継続測定している
- Toil 率（手作業時間比）50% 以下を維持できる FTE 数を確保
- 来年度（2027）の AI コスト増加（モデル単価・トークン消費）を織り込んでいる
これらが揃っていないなら予算規模より先に「測定の仕組み」に投資する。
アンチパターン
- 規模だけで判断: $5M でも測っていなければ無駄になる
- AI ライン未計上: 隠れコストとして他から食われる、可視化が必須
- ツール選定を入札で決める: 採用率を高めるには「現場が使いたいツール」が必要、相見積もりだけで決めない
- on-call を予算に含めない: 隠れコストとして消える、専任FTE で確保
Growth Lab での経験則
このサイト（社内 Platform）では以下の配分を採用：
| 軸 | 配分 |
|---|---|
| Investment（FTE + ツール） | 50% |
| Adoption 促進・教育 | 15% |
| Interfaces 整備 | 15% |
| Operations | 10% |
| Measurement | 10% |
Measurement を10%確保することで、他4軸の投資判断が継続できる。これを5%以下に削ると1年後に「何のための予算か」が分からなくなる。
FAQ
Q. 中小規模組織（30 エンジニア以下）でも Platform Engineering 予算は必要？ A. 規模より「内製ツールに月100時間以上使っているか」が分岐点です。月100時間 = 年間1FTE 相当なので、Platform 化の ROI が見え始めます。
Q. 既存のインフラチームと Platform Engineering の予算境界は？ A. インフラ＝ベース層、Platform＝開発者向け抽象化層、と役割分離します。予算は別ライン推奨。共通化するとどちらの責務でもない領域が抜けます。
Q. AI 統合の予算をどう試算する？ A. テナント数 × 平均トークン消費 × 単価 + Gateway 運用FTE で初期試算します。詳細は LLM API料金最適化 を参照。
まとめ
2026年の Platform Engineering 予算は規模が倍増したが、29.6% が依然測っていない構造的ギャップが残る。投資判断の本丸は規模より「測定軸」。CNCF 5次元の現状値を可視化し、AI 統合の予算ラインを独立計上、Measurement を最低10%確保することが、リアクティブ予算からの脱却ルート。
