SRE とインフラエンジニアは違うのか?

肩書きより任される範囲で見るのが確実です。信頼性の目標を数字で決め、運用作業をソフトウェアで自動化することが仕事の中心なら SRE 寄りです。サーバーやネットワークの構築・保守が中心ならインフラエンジニア寄りで、実際には重なる組織も多くあります。

SRE になるには何を学べばよいか?

監視設計、IaC（コードでのインフラ管理）、障害対応の振り返りの順に手を付けるのが入口です。それぞれ監視設計の記事、構成管理の記事、ポストモーテムの記事で扱っています。

SRE 向けの AWS 認定はあるか?

SRE 専用の認定があるかは、この記事の執筆時点では確認できていないため断定しません。運用寄りの認定の一覧は /shikaku/ で確認できます。

FOR PRACTITIONERS実務向け

Qキャリア段3基盤層とは

SRE とは何か｜運用との違いと、SLO・エラーバジェットで「速さと安定」を数字で決める仕事

2026年11月04日約9分で読めます執筆: Cloudory 執筆者（AWS 認定全冠（AWS Certification をすべて保持））下書き: 生成 AI ／確認: 執筆者（編集ポリシー）

求人や社内の呼び名で「SRE」を見かけ、自分がやってきた運用や構築と何が違うのか、説明しようとして詰まることがあります。運用の人の呼び替えなのか、DevOps やクラウドエンジニアとは別物なのか。この記事は、職種名ではなく「何を任される役割か」を軸に、その違いを言葉にします。

この記事の結論

SRE は、ソフトウェアで運用作業を自動化し、変更が頻繁でも信頼性を保つ取り組み、またはその役割です。
DevOps は開発と運用の壁を取り払う考え方で、SRE はそれを目標の数字と自動化で実現する実践、という位置づけです（AWS の説明に沿います）。
SLI は実測、SLO は目標、SLA は未達のときの約束で、3 つは別物です。
エラーバジェット（SLO が許す不達の範囲）が、リリースを進めるか安定化に回るかの判断材料になります。
職種名より任される範囲で見ます。運用の当番やポストモーテムは SRE の仕事の一部です。

SRE とは何か｜「運用を自動化して信頼性を保つ」役割

SRE（Site Reliability Engineering）は、AWS の説明では、ソフトウェアを使って IT インフラの運用作業を自動化し、頻繁に変更が入っても信頼性を保つための取り組みです。担当する人や役割も SRE と呼びます。

ここで大事なのは、運用作業を人の手で頑張って回すのではなく、ソフトウェアで置き換える対象として扱う点です。デプロイ、スケーリング、障害の検知と初動のような繰り返しの作業は、手順書を増やすより、コードにして自動で回します。

もう 1 つの特徴は、信頼性を「できるだけ高く」ではなく「目標の数字」で決めることです。目標があるから、変更をどこまで速く出してよいかも決められます。

SPEED VS STABILITY速さと安定

変更の速さと安定は、エラーバジェットで釣り合いを決める

変更の速さ

新機能のリリース
設定や構成の変更

安定

SLO で決めた信頼性
障害の少なさ

エラーバジェットの残り

出典: AWS「SRE とは」

従来の運用・DevOps・クラウドエンジニアと何が違うのか

4 つの言葉は、見ているものの中心が違います。きれいに分かれる職種表ではなく、「何を主に任されるか」の違いとして読んでください。

呼び名	主に見るもの	動き方の特徴
従来の運用	動いていること、障害への対応	手順書に沿って人が回すことが多い
DevOps	開発と運用の分断	壁を取り払う考え方・文化
SRE	信頼性の目標と、変更の速さの釣り合い	数字で決め、自動化で回す
クラウドエンジニア	クラウド上の設計・構築・改善全般	幅広く、役割は組織で異なる

WHO WATCHES WHAT主に見るもの

4つの呼び名は、主に見るものが違う

運用
動いていること・障害への対応
手順書に沿って回すことが多い
DevOps
開発と運用の分断
壁を取り払う考え方
SRE
信頼性の目標と変更の速さ
数字で決め、自動化で回す
クラウド
設計・構築・改善全般
役割は組織によって異なる

出典: AWS「SRE とは」の整理をもとに作成

DevOps と SRE は競合ではない

AWS の整理では、DevOps は開発と運用の壁を取り払う考え方で、SRE はそれを実現するための具体的な実践の 1 つです。「どちらを選ぶか」ではなく、考え方と実践の関係として重なります。

クラウドエンジニアとの関係

クラウドエンジニアは、クラウドを使った構築や改善を広く担う言葉です。SRE の仕事はその一部と重なりますが、信頼性の目標と自動化を軸にする点が特徴です。広い役割の整理は次の記事で扱っています。

CHECK 3ここまでの確認

DevOps と SRE の関係として、AWS の整理に最も近いのはどれか?

答えと解説

答え: 2. DevOps は壁を取り払う考え方で、SRE は数字と自動化でそれを実践する取り組み

DevOps は開発と運用の壁をなくす考え方、SRE はそれを目標の数字と自動化で実現する実践、という位置づけです。「従来の運用・DevOps・クラウドエンジニアと何が違うのか」の章を読み直してください。

SLI・SLO・SLA は何が違うのか

SRE が信頼性を数字で語るときの 3 点セットです。混ぜて使われやすいので、先に区別します。

略称	何か	例
SLI	実際に測った値	この 30 日のリクエスト成功率
SLO	内部で置く目標	成功率 99.95% 以上を目指す
SLA	守れなかったときの扱いまで含めた、利用者との約束	下回った場合の対応を契約に書く

SLI SLO SLA3つの区別

実測のSLIの上に目標のSLO、その上に約束のSLAが乗る

測る側

SLI：実際に測った値
SLO：内部で置く目標
SLA：未達のときの約束

決める側

SLI：実際に測った値
SLO：内部で置く目標
SLA：未達のときの約束

約束する側

SLI：実際に測った値
SLO：内部で置く目標
SLA：未達のときの約束

自分たちで持つ利用者との約束

出典: AWS「SRE とは」

実測（SLI）がなければ目標（SLO）は達成できているかが分かりません。目標があって初めて、約束（SLA）をどこに置くかを決められます。SLA は契約や対外的な約束に近く、SLO はその手前で自分たちが守る線、と考えると整理しやすくなります。

何を SLI に選ぶか、どう監視に落とすかの詳細は、この記事では扱いません。監視の設計は次の記事にあります。

CHECK 1ここまでの確認

「実際にこの 30 日で 99.97% 成功した」という数字は、SLI・SLO・SLA のどれにあたるか?

答えと解説

答え: 1. SLI（実測した値）

測った結果が SLI、そこに置く目標が SLO、守れなかったときの扱いまで含めた約束が SLA です。「SLI・SLO・SLA は何が違うのか」の章を読み直してください。

エラーバジェットで「出す」か「止める」かを決める仕組み

エラーバジェットは、SLO が許す不達の範囲です。100% から目標を引くと出ます。

たとえば稼働率の目標が 99.95% なら、許容される不達は 0.05% です。30 日（43,200 分）に直すと、およそ 21.6 分になります。この範囲に収まっているうちは、目標を守れていることになります。

余裕があるとき、使い切りそうなとき

バジェットに余裕がある間は、変更を出す速さを優先しやすい
バジェットを使い切りそうなときは、新しい変更を絞り、安定化の作業に回す判断材料になる

「開発は速く出したい」「運用は安定させたい」という対立を、好みの議論ではなく、共通の数字の残り具合で話せるようにするのが、この仕組みの狙いです。

運用ルールは組織ごとに決める

バジェットを使い切ったらリリースを止める、といった具体的なルールは、組織やサービスの性質で変わります。この記事の数字は考え方を示す例であり、どの組織にも当てはまる正解ではありません。

CHECK 2ここまでの確認

稼働率の目標を 99.95% にしたとき、エラーバジェットは何を指すか?

答えと解説

答え: 2. 目標から逆算した、許容される不達の範囲（0.05%）

エラーバジェットは SLO が許す「外してよい幅」です。お金の予算ではありません。「エラーバジェットで出すか止めるかを決める仕組み」の章で、100% から目標を引く考え方を確認してください。

反復作業を減らす：運用の時間をどこに使うか

SRE の特徴は、運用の時間の使い方にも出ます。手で繰り返している作業は、ソフトウェアで置き換える候補です。

同じ手順を何度も手でやっている作業を洗い出す
自動化できるものはコードにして、人が触らなくても回るようにする
空いた時間を、監視の改善、構成のコード化、障害の振り返りに使う

障害が起きたあとの振り返りも SRE の仕事の一部です。誰のせいかではなく、なぜ起きたかを残し、同じ穴を塞ぎます。

AWS の Well-Architected フレームワークには運用上の優位性の柱があり、運用を継続的に改善する観点を整理しています。SRE の考え方を置く場所の 1 つとして、あわせて読むと位置づけがつかみやすくなります。

自分が SRE 寄りの仕事をしているかの見分け方

肩書きが SRE でなくても、次の項目に当てはまる範囲は SRE 寄りの仕事です。逆に、肩書きが SRE でも当てはまらないことがあります。

信頼性に目標の数字（SLO）があり、実測（SLI）と見比べている
繰り返しの運用作業を、コードにして減らしている
変更を出す速さと安定を、数字の残りを見て相談している
障害のあとに、責任の追及ではなく原因と対策を残している

全部に当てはまらなくて構いません。1 つでも手を付けられるところから始め、どこまでを自分の役割にするかは、チームで決めるものです。

Cloudory 執筆者（AWS 認定全冠）

SRE を「特別な職種」として身構えるより、数字で決めて自動化する、という 2 つの動きとして見ると、今の仕事のどこから近づけるかが見えてきます。この記事は生成 AI が下書きし、執筆者が公式の記述と照らして確認しています。

まとめ

SRE は、運用作業をソフトウェアで自動化し、変更が頻繁でも信頼性を保つ取り組み・役割です。
DevOps は考え方、SRE は数字と自動化による実践、という関係です。
SLI（実測）・SLO（目標）・SLA（約束）は別物で、エラーバジェットは SLO から逆算した許容範囲です。
職種名ではなく、何を任されているかで自分の仕事との距離を測ります。

参照ソース

Amazon Web Services「SRE とは」 — SRE の定義、DevOps との関係、SLI・SLO・SLA、エラーバジェットの説明の根拠に使った（2026-11 時点の公開内容）
AWS Well-Architected フレームワーク運用上の優位性の柱 — 運用を継続的に改善する観点の位置づけの根拠に使った

SCOREこの記事の確認テスト

0/3問正解

各章の「ここまでの確認」に答えると、ここに集まります。結果はこの端末のブラウザにだけ残り、サーバには送りません。

HAND IT OVER人に渡すなら

一言で説明するなら
店の「ここまでなら待たせてよい」という目標時間を先に決め、その枠の中で新メニューをどんどん出し、枠を使い切ったら新メニューを止めて厨房の整備に回す、という店長の仕切り方と同じです。

前提を持たない人にそのまま渡せる記事です。「後輩に説明する」「顧客に理由を伝える」の材料として。

クラウドエンジニアと SRE の違いをまず知りたいメンバーにクラウドエンジニアとは何か｜設計・構築・運用・自動化の仕事と、インフラエンジニアとの違い段1 入口 — クラウドエンジニアが日々何をしているのかを、設計・構築・運用・自動化の4つの工程で整理し、従来のインフラエンジニア...

FAQよくある質問

SRE とインフラエンジニアは違うのか?: 肩書きより任される範囲で見るのが確実です。信頼性の目標を数字で決め、運用作業をソフトウェアで自動化することが仕事の中心なら SRE 寄りです。サーバーやネットワークの構築・保守が中心ならインフラエンジニア寄りで、実際には重なる組織も多くあります。
SRE になるには何を学べばよいか?: 監視設計、IaC（コードでのインフラ管理）、障害対応の振り返りの順に手を付けるのが入口です。それぞれ監視設計の記事、構成管理の記事、ポストモーテムの記事で扱っています。
SRE 向けの AWS 認定はあるか?: SRE 専用の認定があるかは、この記事の執筆時点では確認できていないため断定しません。運用寄りの認定の一覧は /shikaku/ で確認できます。

この記事を書いた人

Cloudory 執筆者Cloudory 編集部

AWS 認定全冠（AWS Certification をすべて保持）／ 2025・2026 Japan All AWS Certifications Engineers 選出

インフラ・クラウドの設計と運用に従事。AWS 認定を全冠し、AWS Japan の Japan All AWS Certifications Engineers に2年連続で選出

サービスの仕様・試験の版・料金は AWS の公式ドキュメントと試験ガイドを、ネットワークの仕組みは RFC を一次情報にしています。AWS が公表していない合格率や受験者数は書きません。「体感の難易度」は執筆者本人の経験と明記して書き、本人の経験の外側は公開されたポストモーテムと Well-Architected を根拠にします。

執筆者について編集ポリシー訂正と更新の記録記事の誤りを知らせる