DevOps・SRE・Platform Engineeringの違いとは？クラウドエンジニアが知るべき3つの運用モデル完全比較

2026年6月2日2026年6月9日

「DevOpsって言葉はよく聞くが、SREと何が違うのか？」「Platform Engineeringはまた新しい流行り言葉？」——クラウド移行プロジェクトに関わったインフラエンジニアなら、一度はこの疑問を持ったことがあると思います。

オンプレ時代は「インフラチーム」と「開発チーム」の役割が明確でした。インフラ側はサーバー調達・ネットワーク設計・障害対応を担い、開発側はコードを書いてリリース依頼を出す——というウォーターフォール的な分業です。クラウドに移行すると、この境界線が急速に曖昧になります。インフラがコードで管理され、開発者が自分でデプロイし、自動スケーリングが当たり前になる環境では、「自分たちは何をするチームなのか」を問い直す必要が出てきます。

この記事では、DevOps・SRE（Site Reliability Engineering）・Platform Engineering という3つの概念について、それぞれの背景・役割・向いている組織規模を整理します。「どれを選べばよいか」という実践的な判断基準まで解説するので、クラウド移行後の組織設計に悩んでいる方の参考になれば幸いです。

なぜ3つのモデルが生まれたのか——背景と登場の流れ

3つのモデルにはそれぞれ「生まれた時代」と「解決しようとした問題」があります。まずその歴史的な流れから整理します。

DevOps（2009年～）：開発と運用の「壁」を壊す文化ムーブメント

DevOps が提唱されたのは2009年、Patrick Debois らがベルギーで開催した「DevOpsDays」が起源とされています。当時の問題意識はシンプルです。「開発チームは早くリリースしたい、運用チームは安定を守りたい——この対立がソフトウェアデリバリーの速度を慢性的に落としている」というものです。

DevOps は特定のツールや職種を指す言葉ではありません。「開発と運用が協力してシステムのライフサイクル全体に責任を持つ」という思想・文化の変革を指します。CI/CD（継続的インテグレーション・継続的デリバリー）の普及や、Terraform・Ansible といった IaC（Infrastructure as Code）ツールの台頭は、DevOps 的な働き方を技術的に支える道具として発展しました。

SRE（2003年～、外部公開2016年）：Googleが設計した信頼性エンジニアリング

SRE（Site Reliability Engineering）は Google が2003年に社内で始めた実践です。Ben Treynor Sloss が「運用をソフトウェアエンジニアリングの問題として解く」という発想で立ち上げました。外部には2016年の書籍「Site Reliability Engineering」で広まりました。

Google が解決しようとした問題は「世界規模のサービスの信頼性をどう定量的に管理するか」です。感覚や経験則ではなく、SLI・SLO・エラーバジェットという指標体系で信頼性を数値化する手法を確立しました。

Platform Engineering（2020年代～）：「自由すぎるDevOps」の複雑性爆発への対応

Platform Engineering は2020年代になってから特に注目されるようになりました。背景には「DevOps が普及した結果、各チームが自由にインフラを触るようになったが、設定が統一されず運用の複雑性が爆発した」という課題があります。

Platform Engineering チームは、開発チームが安全に自律的に動けるための「内部開発者プラットフォーム（IDP: Internal Developer Platform）」を構築します。インフラ操作の標準化・セルフサービス化が目的です。

3つのモデルをオンプレ経験者向けに比較する

オンプレ時代のインフラエンジニアが理解しやすいよう、具体的な観点で比較します。

観点	DevOps	SRE	Platform Engineering
解決する問題	開発・運用チームの対立	信頼性の定量管理	DevOps普及後の複雑性爆発
主な担い手	開発・運用の全員（文化として）	SREエンジニア（専任）	Platform Engineeringチーム（専任）
提供するもの	文化・プロセス・CI/CD実践	信頼性管理手法・On-Call体制	内部開発者プラットフォーム（IDP）
向いている規模	スタートアップ～中規模	大規模サービス（高可用性が必要な組織）	中～大規模（複数チームが並走する組織）
成功の測り方	DORA指標（デプロイ頻度・障害回復時間等）	SLO達成率・エラーバジェット消費率	開発者のオンボーディング時間・セルフサービス率

DevOpsの成熟度を測るDORA指標とは

DevOps の効果を客観的に測る指標として「DORA指標」があります。Google の DevOps Research and Assessment チームが長年の研究から定義した4つのメトリクスです。

・デプロイ頻度（Deployment Frequency）: 本番環境へのデプロイ回数。高パフォーマンス組織は1日複数回、低パフォーマンス組織は月1回以下
・変更のリードタイム（Lead Time for Changes）: コードコミットから本番デプロイまでの時間。高パフォーマンスは1時間以内
・変更障害率（Change Failure Rate）: デプロイのうち障害やロールバックが発生した割合。高パフォーマンスは15%以下
・サービス復旧時間（Time to Restore Service）: 障害発生から復旧までの平均時間。高パフォーマンスは1時間以内

AWS では AWS CodePipeline・CodeDeploy のメトリクスから、デプロイ頻度や変更のリードタイムを算出できます。Amazon CloudWatch と組み合わせることで、変更障害率や復旧時間の可視化も可能です。オンプレ時代に「感覚で安定している」と言っていた状態を、数値で客観評価できるのが DORA 指標の価値です。

SREの実践：SLO・エラーバジェット・Toil削減

SLI・SLO・SLAの3層構造

SRE の中心概念を整理します。

・SLI（Service Level Indicator）: 実際に計測する指標。例「正常レスポンス率」「95パーセンタイルレイテンシ」
・SLO（Service Level Objective）: SLI の目標値。例「正常レスポンス率 99.9%以上」「p95レイテンシ 200ms以内」
・SLA（Service Level Agreement）: ユーザー・顧客と合意した保証値。SLO より緩めに設定するのが一般的

AWS でこれを実装するなら、Amazon CloudWatch でメトリクスを収集してダッシュボード化し、SLO 違反を検知するアラームを設定します。


# AWS CLI：ALBの5xxエラー率を監視してSLO違反を検知するアラーム設定例
aws cloudwatch put-metric-alarm \
  --alarm-name "SLO-5xxErrorRate-Exceeded" \
  --metric-name "HTTPCode_Target_5XX_Count" \
  --namespace "AWS/ApplicationELB" \
  --statistic "Sum" \
  --period 60 \
  --threshold 10 \
  --comparison-operator "GreaterThanThreshold" \
  --evaluation-periods 5 \
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:sre-oncall-alert"

エラーバジェットの考え方

SLO が「月間可用性 99.9%」なら、1か月（約43,200分）のうちダウンタイム許容は約43分です。この「許容できる不可用時間」をエラーバジェットと呼びます。

バジェットが残っているうちは新機能のリリースを加速できます。バジェットを使い切りそうになったら、リリースを一時止めて信頼性改善を優先する——というトレードオフを定量的に判断する仕組みです。オンプレ時代の「障害を絶対に起こすな」という属人的なプレッシャーと違い、「どこまで許容するか」を事前に決めておく点が SRE の革新的な発想です。

Toil（トイル）削減の原則

SRE では「Toil（トイル）」——手動・反復的・自動化できるオペレーション作業——の削減を重視します。SRE エンジニアの作業時間のうち Toil が50%を超えてはいけない、というガイドラインがあります。残りの50%をエンジニアリング（自動化・アーキテクチャ改善）に充てることで、チームの生産性を長期的に高めます。

オンプレ時代に「毎月手動でバックアップ状況を確認している」「定期的にログを手動でローテーションしている」といった作業はまさに Toil です。これらをスクリプト化・自動化することが SRE 実践の第一歩です。AWS Lambda や EventBridge を活用した定期タスクの自動化が、Toil 削減の典型的なアプローチです。

Platform Engineeringの実践：IDPとゴールデンパス

内部開発者プラットフォーム（IDP）の構成要素

Platform Engineering チームが構築する IDP は、以下の要素で構成されます。

・セルフサービスポータル: 開発者が自分でインフラをプロビジョニングできる UI または CLI ツール
・ゴールデンパス（Golden Path）: 「これを使えば安全にデプロイできる」という標準化されたテンプレート
・ソフトウェアカタログ: 社内のサービス・API・依存関係を可視化するツール（OSS例: Backstage）
・CI/CDパイプライン標準: セキュリティスキャン・テスト・デプロイを含む共通パイプライン

AWS環境でのゴールデンパス実装イメージ

AWS 環境の Platform Engineering では、Terraform モジュールや AWS Service Catalog を活用したゴールデンパスが一般的です。

# Terraformモジュール構成例（Platform Engineeringチームが管理するゴールデンパス） platform-modules/ ├── web-app/ # ECS + ALB + RDS + WAF の標準セット │ ├── main.tf │ ├── variables.tf │ └── outputs.tf ├── batch-job/ # AWS Batch + S3 + EventBridge の標準セット │ └── ... └── data-pipeline/ # Glue + S3 + Athena の標準セット └── ...

開発チームはモジュールを呼び出して変数を渡すだけで、セキュリティグループ・暗号化・ログ設定が標準化されたインフラが構築されます。Platform Engineering チームがモジュールをバージョン管理・更新することで、組織全体のベストプラクティスが一元的に適用される仕組みです。

AWS では AWS Service Catalog を使い、承認済みの CloudFormation スタックをセルフサービスで払い出す方法も有効です。開発者は「カタログから選んでデプロイ」するだけで、インフラの細かい設定を知らなくても適切なリソースが起動します。

よくある誤解と失敗パターン

誤解1：「SREはDevOpsの上位互換」

DevOps と SRE は上下関係ではありません。Google のエンジニアが「SRE is what you get when you treat operations as if it’s a software problem」と表現したように、SRE は DevOps 的な思想を Google 流に実装したものです。DevOps が「文化・思想」で、SRE はその実装パターンの一つです。

中小規模の組織が Google の SRE プラクティスをそのまま導入しようとすると、オーバーエンジニアリングになりがちです。「SLO の数が多すぎて管理しきれない」「エラーバジェット運用に人手がかかりすぎる」——といった状況は現場でよくある失敗です。

誤解2：「Platform Engineeringチームを作ればすべて解決」

Platform Engineering チームは「内部向けプロダクトチーム」です。開発者が実際に使いたいと思える IDP を作れなければ意味がありません。「作ったが誰も使わない」という失敗事例は多く、開発者体験（DX: Developer Experience）への投資と、継続的なユーザーフィードバックループが欠かせません。

誤解3：「クラウドに移行したら自然とDevOpsになる」

ツールを変えても、組織文化が変わらなければ DevOps にはなりません。「インフラチームがクラウドを操作しているが、開発チームへの変更依頼はチケットベースのまま」という状態でクラウド移行が完了したと思っているケースが実は多いです。クラウド化と組織変革は別々の問題として、両方に意識的に取り組む必要があります。

どのモデルを選ぶべきか：組織規模別の判断基準

組織の状況	推奨アプローチ	最初の一歩
エンジニア10名以下・クラウド移行直後	DevOps文化の醸成から始める	GitHub Actions でCI/CDパイプラインを1本整備する
エンジニア20～100名・サービス安定期	SREのプラクティスを部分的に取り入れる	主要サービスのSLO定義とCloudWatchアラーム整備
エンジニア100名以上・複数チームが並走	Platform Engineeringチームを設置する	Backstage等のソフトウェアカタログ導入から始める
大規模サービス・高可用性が事業の生命線	SRE専任チームを置く	On-Call体制とインシデント管理プロセスの整備

オンプレ主体のインフラチームがクラウド移行後に最初に取り組むべきは、DevOps アプローチです。「開発チームと一緒に CI/CD パイプラインを作る」「インフラを Terraform でコード管理する」——この2点を実現するだけで、リリース速度と品質は大きく改善します。組織が成熟するにつれて、SRE や Platform Engineering の要素を段階的に取り込んでいくのが現実的なロードマップです。

本記事のまとめ

DevOps・SRE・Platform Engineering の違いをまとめます。

・DevOps: 開発と運用の「壁」を壊す文化的ムーブメント。CI/CD・IaC・DORA指標での測定が核心
・SRE: Google が設計した信頼性エンジニアリングの実践。SLO・エラーバジェット・Toil削減が3本柱
・Platform Engineering: 開発チームにセルフサービスのインフラ基盤を提供する内部プロダクトチーム。IDP とゴールデンパスが具体的な成果物

3つは競合関係ではなく、組織の成長段階に応じて組み合わせて使うものです。クラウド移行を機に「自分たちのチームには今何が必要か」を問い直す良いタイミングです。まずは小さく始め、成果を測りながら拡張していくアプローチをお勧めします。

Linuxサーバーの基礎やシェルスクリプトを活用したオペレーション自動化については、姉妹サイトLinuxMaster.JPで詳しく解説しています。DevOps の文脈でサーバー運用を自動化したい方はあわせてご覧ください。