Platform Engineering とは？ SREのための実践ガイド
要約
プラットフォームエンジニアリングとは、プロダクトチームとインフラの間にIDPを設ける規律だ。専任チームがCI/CDやオブザーバビリティを内部プロダクトとして届ける。DORA 2025ではIDP採用チームのデプロイ頻度が3.5倍、変更失敗率が25%低い。本記事は投資タイミング、チーム構成、ROI測定の実践的な枠組みを示す。
Platform Engineering とは？ SREのための実践ガイド
プラットフォームエンジニアリングとは、プロダクトチームと生のインフラとの間にセルフサービス層を設ける内部開発者プラットフォーム（IDP）を設計・運用する規律だ。2026年中頃の時点で、この言葉に関連する検索は月間約1万8,000件にのぼる。これが示すのは、多くのエンジニアリング組織がいまだにこの概念の本質を把握しきれていないという現実だ。DevOpsの名称変更なのか、SREの昇格版なのか、あるいは組織の構造的変化なのか。答えは三番目だ。
これはCI/CDの入門書ではない。プラットフォームチームを構築しているか、その投資をリーダーシップに正当化しようとしているプラットフォームエンジニア、SREリード、エンジニアリングマネージャーのための実践ガイドだ。
プラットフォームエンジニアリングはDevOpsの焼き直しではない
DevOpsはプラクティスと文化的規範のセットだ。プラットフォームエンジニアリングは、プロダクトを持つチームトポロジーだ。
この区別は運用上の意味を持つ。DevOps文化は開発者が自分のデプロイを所有することを推奨する。プラットフォームチームは、その所有をスケールで現実的にする仕組みを構築する。CI/CDパイプラインテンプレート、デプロイ抽象化、オブザーバビリティスタック、シークレット管理、コストガードレール。これらすべてをセルフサービスインターフェースを通じてアプリチームが消費する内部プロダクトとして届ける。
エンジニア20人の組織では、この区別は学術的なものだ。80人の組織では、2人のOpsパーソンにインフラ知識がボトルネックされた状態と、チケットなしで誰でも使える舗装された道との差になる。
SREとの関係は競合ではなく補完だ。SREは本番システムの振る舞いを改善する。プラットフォームエンジニアリングは、ソフトウェアをshipする行為を組織としてスケールさせる方法を改善する。多くのプラットフォームチームはSREチームから生まれ、SREが本番に適用するSLOベースの信頼性パターンがプラットフォームのデプロイゲートに直接エンコードされることが多い。
内部開発者プラットフォーム（IDP）に実際に含まれるもの
IDPは単一のツールではない。複数のシステムの組み合わせだ。典型的な構成は以下の通りだ。
デプロイメカニズム（Kubernetes、サーバーレスランタイム、またはその上の管理された抽象化）、事前承認済み設定を持つCI/CDパイプラインテンプレート、スコープされたアクセスとローテーションを持つシークレットマネージャー、サービスタイプごとに事前設定されたダッシュボードを含むオブザーバビリティスタック（メトリクス、ログ、トレース）、何が動いていてどこで誰が所有しているかを文書化したサービスカタログ、そして2026年のデファクトスタンダードであるBackstageのような開発者ポータルだ。
重要な設計決定は抽象化のレベルだ。生のKubernetesをそのまま出せば、開発者はHelmチャートのデバッグに時間を費やす。抽象化しすぎると、エッジケースや非標準ワークロードへの対応力を失う。
プラットフォームチームの仕事は、修正なしで80%のユースケースをカバーする抽象化レベルを見つけ、抽象化の下に潜る必要があるチームのための脱出口を文書化することだ。
どのタイミングでプラットフォームエンジニアリングに投資すべきか
普遍的な閾値はないが、ポストモーテムとDORAの研究は一貫したレンジを示している。
エンジニア30人未満では、専任プラットフォームチームのオーバーヘッドが価値を上回る。フィーチャーチームに組み込まれたSRE指向のエンジニア数名で十分だ。
エンジニア30〜80人では、個々のチームの認知負荷が複合し始める。デプロイ知識が一握りの人間に集中する。オンコールローテーションが薄くなる。典型的なインシデントパターンが現れる。開発者が共有インフラの懸念事項でブロックされ、Opsに近い人が空くのを待つ。その待ち時間がシグナルだ。
エンジニア80人超では、専任プラットフォームチームはもはやオプションではない。DORA State of DevOps 2025によると、内部開発者プラットフォームを使うチームはそうでないチームに比べて3.5倍の頻度でデプロイし、変更失敗率が25%低い。これらの成果は偶然ではない。プラットフォームが調整コストを吸収したから生まれる。
DORAデータが示すプラットフォームチームの実績
DORAメトリクスはアクティビティではなく成果を測定するため、効果を判断するのに適したレンズだ。
高パフォーマンスのプラットフォームチームは一貫して2つのDORAメトリクスを動かす。デプロイ頻度と変更失敗率だ。標準化されたデプロイパイプラインはコードが本番に到達する方法のばらつきを減らす。SLO違反でトリガーされる自動ロールバックゲートは、検出から応答までの時間を圧縮してMTTRを短縮する。
2025年のDORAレポートでは、より微妙なパターンも特定された。プラットフォームの採用率が高いチームは、計画外作業の割合が低かった。計画外作業はデプロイ頻度のサイレントな劣化要因だ。スプリント速度には現れない。チームが出荷する予定だったものと実際に出荷したものとのギャップに現れる。2人のエンジニアが共有パーミッション設定のデバッグに3日費やした週は、ユーザー向けインシデントが発生しなくても、プラットフォーム信頼性の失敗だ。
インナープラットフォームの罠：プラットフォームがボトルネックになるとき
インナープラットフォーム効果は、プラットフォームエンジニアリングのカンファレンス講演では誰も話さない失敗モードだ。
仕組みはこうだ。プラットフォームチームはすべての内部ユースケースに対応しようとして、ますます汎用的な抽象化を構築する。プロダクトチームからの新しい要件が次々と収容される。やがてプラットフォームは汎用インフラシステムになる。本質的にはKubernetesやTerraformの劣化版だ。しかも限られた帯域幅で小さなチームが維持している。
結果：そのプラットフォームが置き換えたオープンソースの代替品よりも遅く使いにくいプラットフォームが生まれる。プラットフォームチームはチケットキューになる。本番までの時間が増加する。
診断の問いはこうだ。プラットフォームチームはプロダクトを構築しているのか、それともサービスを提供しているのか。プロダクトは意見のあるインターフェースを持ち、一部のユースケースをスコープ外と明示的に受け入れ、採用率を測定する。プロダクトはスケールする。サービスはしない。
実用的なテスト：プラットフォームチームのバックログが、プラットフォーム全体の改善ではなく個々のアプリチームからの個別リクエストで占められているなら、チームはサービスモードに流れ込んでいる。
プラットフォームチームのデリバリーを測定する方法
プラットフォームチームが価値を示せなければ、最終的には解体されるかフィーチャーチームに吸収される。エンジニアリングリーダーシップに通用する指標を示す。
採用率：何パーセントのアプリチームが本番デプロイにプラットフォームのゴールデンパスを使用しているか。12ヶ月後に60%未満であれば、プラットフォームが実際の問題を解決していないシグナルだ。
デプロイ頻度デルタ：プラットフォーム上のチームとまだ独自パイプラインを管理しているチームのデプロイ頻度を比較する。6ヶ月以内のポジティブなデルタが最も明確なROIシグナルだ。
初回デプロイまでの時間（TF1D）：新しいサービスがプラットフォーム経由で初めて本番に到達するまでの時間はどのくらいか。適切に構築されたIDPは標準的なサービスを初期設定から2時間以内に本番に届けられるべきだ。
P99復旧時間：本番で何かが壊れたとき、解決またはロールバックまでの時間はどのくらいか。SLOゲーテッドデプロイ自動化がこの数値に直接影響する。午前3時に手動でそれを計算したくはないはずだ。
スケールするプラットフォームチームの構成
Series B〜Dの企業（エンジニア50〜500人）のプラットフォームエンジニアリングチームは、一般的に以下で構成される。
アーキテクチャ方向を所有しアプリチームリードとの関係を持つプラットフォームリードまたはスタッフエンジニア。分散システム、インフラ、SREのバックグラウンドを持つシニアエンジニア2〜4人。アプリエンジニアが特定の統合問題を持ち込める週次プラットフォームオフィスアワー枠。プラットフォームが支援するサービスだけでなくプラットフォーム自体の明示的なSLA。アプリチームリードとともに優先度を検討する四半期ロードマップ。
チームはアプリチームのアウトカムで成功を測定する。デプロイ頻度、MTTR、計画外インフラ作業に費やす時間だ。自分たちのインフラの稼働時間ではない。
投資を始める前に問うべき唯一の問い：アプリチームはプロダクトとは無関係のインフラの懸念事項に、スプリント容量の20%以上を費やしているか。答えがYesなら、プラットフォームのROI計算は明快だ。Noなら、解決する前に問題に対してオーバーヘッドを構築している。
プラットフォームエンジニアリングが適切に機能しているとき、それは目に見えない。ポストモーテムには「03:47に自動ロールバックが起動、03:47にインシデント解決」と書かれる。エンジニアリングマネージャーはページされない。誰も気づかない。それが目標だ。