SREとは何か。運用担当の新しい呼び名ではなかった。Googleの原典では、運用の仕事は勤務時間の半分までだった

SREは、インフラを運用する仕事の新しい呼び名だと受け取られやすい言葉です。転職サイトの求人検索でも、SREはインフラエンジニアの下の職種として並んでいることがあります。

ところが、SREという言葉が生まれたGoogleで、技術者たちが2016年に書いた本は、SREの運用の仕事を勤務時間の50%までに抑え、残りの時間は開発に充てる、としています。

原典の説明に沿えば、SREは運用をこなす人というより、運用の手間をコードで減らしていく人です。

SREとは何か。国のスキル標準や職業分類ではどう扱われ、運用の仕事からはどうつながるのか。出てきそうな問いに、ひとつずつ資料で答えます。

SREは、何の略ですか

Googleの原典では「Site Reliability Engineering」の略です。IPAの新しい試験のシラバス案は「サイト信頼性エンジニアリング」と訳しています。

職種としては「SREエンジニア」と呼ばれることもあります。言葉を作ったのは、ベン・トレイナー・スロス氏です。

本の序文も同氏をそう紹介していて、肩書きは、Googleで24時間365日の運用を担当するバイスプレジデント（VP）となっています。

同氏は本の序章で、SREをこう説明しています。

SRE is what happens when you ask a software engineer to design an operations team.Google『Site Reliability Engineering』Chapter 1 Introduction

ソフトウェアエンジニアに運用チームの設計を任せたときに生まれるもの、という意味です（編集部訳）。2003年に7人の運用チームを任されたとき、それまでの経歴はすべてソフトウェア開発だった、とも書いています。

ただ、日本の公的な資料では、書き方が分かれていました。

表1　資料ごとの「SRE」の書き方

資料	書かれている英語の表記
Googleの本（2016年）	Site Reliability Engineering
政府の重点計画（2024年）	Site Reliability Engineer
国のスキル標準（2026年）	Service Reliability Engineering
IPAの試験シラバス案（2026年）	Site Reliability Engineering

Googleの本＝『Site Reliability Engineering』。政府の重点計画＝「デジタル社会の実現に向けた重点計画」（2024年6月21日）の脚注。国のスキル標準＝経済産業省・IPA「デジタルスキル標準 ver.2.0」（2026年4月）のロール名。IPAの試験シラバス案＝「プロフェッショナルデジタルスキル（システム）試験（仮称）シラバス（案）Ver.0.2」（2026年6月30日掲載、7月31日更新）
出典：各資料

「Service」と書いているのは、経済産業省とIPAのデジタルスキル標準（DSS）だけでした。同じIPAが作る新しい試験のシラバス案は「Site」です。DSSは、このロール名について次のように書いています。

「フロントエンドエンジニア」「バックエンドエンジニア」「クラウドエンジニア／SRE（Service Reliability Engineering）」は、昨今、一般的な求人市場等で用いられている表現を意識したものである。経済産業省・IPA「デジタルスキル標準 ver.2.0」（2026年4月）p.119

ただ、略さない形を「Site」ではなく「Service」とした理由までは、DSSには書かれていません。

一方、Googleの本の序文は、名前の「Site」はもともとgoogle.comのサイトを動かし続ける役割を指していた、と説明しています。

この記事では、言葉の出どころであるGoogleの「Site Reliability Engineering」で説明します。

書き方は違っても、Googleの本とDSSは、どちらもサービスの信頼性に責任を持つ役割として説明しています。

インフラの運用担当と、何が違うのですか

Googleの原典では、運用の仕事に使う時間に上限を設けている点です。チケット対応やオンコール（呼び出しへの待機）、手作業といったSREの運用の仕事を、勤務時間の50%までに抑えるとしています。

残りの時間は、コードを書く力を使った開発のプロジェクトに充てます。運用の負担が50%を超えたチームは、運用の一部を開発チームに戻すなどして、上限の中に戻すとしています。

減らす対象の運用の仕事は「トイル（toil）」と呼ばれます。本は、本番サービスの運用に結びついた仕事のうち、次のような傾向を持つものをトイルとしています。

手作業である、くり返し発生する、自動化できる、割り込みで発生して受け身で対応する、長く残る価値がない、サービスの成長に比例して増える。

すべてに当てはまる必要はなく、これらに当てはまる度合いが強いほどトイルの可能性が高い、としています。

たとえば、障害のたびに同じ手順でサーバーを再起動する作業や、利用者が増えるたびに手でサーバーを足す作業は、この特徴に当てはまります。SREは、こうした作業を仕組みに置き換えていきます。

国の資料も同じ方向を向いています。政府のシステムでクラウドを使うときの基本方針（デジタル社会推進会議幹事会決定、デジタル庁が公表）は、運用作業の自動化を徹底するよう求めています。

人手に頼っていた運用作業を自動化し、運用コストの削減とヒューマンエラーの防止を図る必要があるため、自動で実行可能な単純作業を事業者が人件費を用いて実施しないよう、特に留意が必要となる。「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（DS-310、2025年5月27日デジタル社会推進会議幹事会決定）

同じ方針は、クラウドではサーバーやネットワークの監視よりも、アプリケーションやサービスが正常に動いているかの監視が重要になる、とも書いています。

DSSは、クラウドエンジニア／SREの責務を、次のように定めています。

デジタル技術を活用したサービスを提供するためのソフトウェアの開発・運用環境の最適化と信頼性の向上に責任を持つ経済産業省・IPA「デジタルスキル標準 ver.2.0」クラウドエンジニア／SREの担うべき責務（p.123）

主な業務には、サービスの運用中に継続的なモニタリングを行い、その結果を踏まえて、信頼性の向上に必要なシステム・ソフトウェア面での対応を行うことが挙がっています。

運用を回すだけでなく、開発・運用の環境を良くし、サービスの信頼性を上げることにまで責任を持つ役割です。

「信頼性」は、どうやって決めるのですか

数字の目標で決めます。サービスの状態を測る指標（SLI）を決め、その目標値（SLO）を置きます。

SLIの例は、リクエストへの応答時間やエラーの割合です。SLOは「応答時間が○ミリ秒以内」のように、SLIの目標値や範囲として置きます。

守れなかったときの扱いまで利用者と約束したものはSLA（サービスレベル合意）と呼び、区別します。

Googleの本は、ほとんどのサービスで、信頼性の目標を100%にするのは正しくないとしています。例外として挙げているのは、心臓のペースメーカーや自動車のABS（アンチロック・ブレーキ）です。

そこで使うのが「エラーバジェット」です。1から可用性の目標を引いた残りのことで、目標が99.99%なら、残りの0.01%が「使えなくてもよい」予算になります。

30日の月に直すと、約4.3分です（30日×24時間×60分×0.01%で編集部が算出）。

本には、予算が残っているあいだは新しいリリースを出せ、使い切ったらリリースを一時的に止める、という使い方が書かれています。

序章では、予算を使い切ったらその四半期が終わるまでリリースを止める、という判断を、経営層の後押しがないと開発チームに受け入れられにくい例として挙げています。

開発チームは新しい機能を早く出したい。運用の側は安定を保ちたい。この対立を、数字の予算で調整する仕組みです。

日本の政府の資料にも、SLOの考え方は入っています。デジタル庁の技術検討会議（第21回、2024年10月1日）に出された「APIテクニカルガイドブック（案）」です。

エラーバジェットという言葉は出てきませんが、SLIを定めたうえでSLAとSLOを置くよう書いています。SLOは、SLAを達成するための内部目標として、より厳しい基準で置くとしています。

例に挙げているのは、可用性99.99%と、95パーセンタイルの応答時間200ミリ秒以内です。

運用の仕事から、SREになれますか

運用やインフラの経験は土台になります。ただ、Googleの原典では、SREの時間の少なくとも半分を開発に充てるとしているので、コードを書く仕事を増やしていく必要があります。

Googleの本によると、SREの50〜60%は、Googleのソフトウェアエンジニアと同じ手順で採用された人でした。

残りの40〜50%は、ソフトウェアエンジニアの基準にかなり近いうえで、SREに役立つのにソフトウェアエンジニアには珍しい技術を持つ人です。

そうした技術としてGoogleが特に多く求めているのが、UNIXの内部構造とネットワーク（レイヤー1〜3）の専門知識です。インフラの知識は、SREで生きる経験として扱われています。

そのうえで、どちらの人にも共通するのは、複雑な問題を解くためにソフトウェアを作る力と姿勢だと書かれています。

日本の運用の現場でも、ITスキルのレベルが高い人ほど、システム開発のタスクを求められている割合が高くなっていました。

厚生労働省の委託調査で、運用・保守の職種で働く正社員に、業務の中で求められているタスクを聞いた結果です。

表2　運用・保守の職種で求められるタスクと年収（ITスキルのレベル別）

レベル	システム開発	運用・保守	年収中央値
レベル1〜2	37.5%	50.0%	500万円
レベル3	43.0%	67.2%	550万円
レベル4	59.1%	55.4%	650万円
レベル5以上	78.5%	55.4%	850万円

運用・保守は、調査の職種区分の「運用スペシャリスト」と「情報セキュリティアーキテクト」（3分の1で重み付け）をまとめた区分。レベルはIPAのITスキル標準（ITSS）による区分で、レベル1は実務未経験者や新入社員など、レベル2は一定範囲の作業であれば独力で担当できる、レベル3は要求された作業をすべて独力で進める、レベル4は業務上の課題の発見と解決を独力でリードする水準（レベル1と2は合わせて集計）。システム開発は、要件定義・ソフトウェア開発・システムテスト・移行や導入・基盤システムの設計や実装などをまとめた区分。タスクは複数選択で、回答はレベル順に70・85・87・41人。年収は正社員の今年度の見込み年収で、回答は53・67・73・36人（300万円未満と5,000万円以上の回答は集計から除かれている）。調査は2023年9月で、調査全体の回答者の約4分の3が45〜64歳（編集部が算出）
出典：厚生労働省「IT・デジタル人材の労働市場に関する研究調査事業」調査報告書（令和6年3月）

システム開発のタスクを求められる人は、レベル1〜2の37.5%から、レベル5以上では78.5%に増えていました。運用・保守のタスクは、どのレベルでも5割から6割台です。

年収の中央値も、レベル1〜2の500万円から、レベル5以上の850万円まで上がります。ただし、この調査にSREという職種の区分はなく、SREの年収そのものではありません。

運用の経験を積みながら、自動化のスクリプトやツールを自分で書く仕事を増やしていく。運用からSREに近づくのは、この順番です。

DevOpsとは、何が違うのですか

Googleの本は、SREをDevOpsと近いものとしつつ、違いも書いています。序文では、SREは信頼性を一番の関心に置き、運用の必要そのものをなくす方向を強く目指す点で、DevOpsとは違うとしています。

序章では、DevOpsはSREの中心的な原則のいくつかをより広い組織に広げたもの、SREはDevOpsの一つの実装に独自の拡張を加えたもの、どちらの見方もできるとしています。

「DevOps」という言葉は2008年の終わりごろに業界で生まれたもので、本は、人手より自動化に頼ることなど、DevOpsの中心的な原則は、SREの原則や実践の多くと一致するとしています。

DSSも、スキル項目の「SREプロセス」を「開発と運用が協力し、リリースサイクルの向上とサービスの安定を目指すスキル」と定義し、学ぶ項目の例にCI/CDとDevOpsを挙げています。

国の職業分類では、どの職業に入りますか

「SRE」という名前の職業はありません。厚生労働省編職業分類の職業名索引と職業分類表を編集部が検索したところ、SRE、クラウドエンジニア、DevOpsを含む職業名は見つかりませんでした。

分類表の定義に照らすと、仕事の中身によって入る先が分かれます。

構築されたシステムの運用・監視・保守は「010-04 ITシステム運用管理者」、システム全体の基本構造の企画・設計は「010-02 ITシステム設計技術者」の定義に当たります。

サーバーの構築・設定は「010-06 通信ネットワーク技術者」です。自動化のツールなど、ソフトウェアを書く仕事が主なら、中分類「009 情報処理・通信技術者（ソフトウェア開発）」の側になります。

これは分類の定義を当てはめた編集部の整理で、分類表がSREの分類先を示しているわけではありません。

職業情報提供サイトのjob tagにも、SREの職業ページはありません。近いのは「システムエンジニア（基盤システム）」と「運用・管理（IT）」の2つで、仕事の中身はインフラエンジニアとはで確かめました。

SREを役割として定義し、求められるスキルまで示している国の文書は、確認できた範囲ではDSSだけです。ロール名は求人市場で使われる表現を意識して付けられていて、職業分類のほうには、この名前はありません。

政府の採用でも、SREという言葉は使われています。デジタル庁の中途採用では、ガバメントクラウドのクラウドエンジニアなどの求人で、SREの実践経験が歓迎するスキルに挙がっていました（2026年9月30日時点）。

身分は非常勤の一般職国家公務員で、任期は年度ごとの更新です。

職種名に「リライアビリティエンジニア」が入る、カスタマーリライアビリティエンジニア（CRE：Customer Reliability Engineer）の募集もありました。

何を学べばいいですか。資格はありますか

国のスキル標準が目安になります。DSSは、クラウドエンジニア／SREに、4つのスキルで「高い実践力と専門性」（重要度a）を求めています。同じソフトウェアエンジニアのバックエンドエンジニアと並べると、違いが見えます。

表3　バックエンドエンジニアとSREで、求められるスキルの違い

スキル項目	バックエンド	SRE
SREプロセス	b	a
セキュリティ運用・保守・監視	c	a
クラウドインフラ活用	a	a
コンピュータサイエンス	a	a
バックエンドシステム開発	a	b
ソフトウェア設計手法	a	b
データ基盤の設計・実装・運用	a	b

バックエンド＝バックエンドエンジニア、SRE＝クラウドエンジニア／SRE。a＝高い実践力と専門性が必要、b＝一定の実践力と専門性が必要、c＝説明可能なレベルで理解が必要。全67項目のうち重要度aは、バックエンドエンジニアが8項目、クラウドエンジニア／SREが4項目（編集部が数えた値）
出典：経済産業省・IPA「デジタルスキル標準 ver.2.0」（2026年4月）共通スキルリスト（スキルマッピング）

SREプロセスで学ぶ項目の例は、オブザーバビリティ（システムの状態を外から観測できるようにすること）、オープンテレメトリ、four keys、カオスエンジニアリング、CI/CDとDevOpsです。

クラウドインフラ活用は「クラウドサービスを利用しシステムインフラを構築・運用するスキル」で、学ぶ項目の例にはコンテナ技術やIaC（インフラの構成をコードで管理する方法）が入っています。

バックエンドエンジニアはサーバー側の機能の開発を担う役割で、DSSが中心に置くスキルは「バックエンドシステム開発」や「クラウドインフラ活用」です。

SREは、クラウドインフラ活用に加えて、SREプロセスとセキュリティの運用・監視に重心を置いた役割です。

クラウドの仕事の実像はクラウドエンジニアはやめとけでも確かめています。

SREという名前の国家資格はありません。ただ、IPAは今の試験制度を2026年度の試験で終え、2027年度から新しい制度に移る予定です。新しい試験の出題範囲の案には、SREが入っています。

「プロフェッショナルデジタルスキル（システム）試験（仮称）」のシラバス案には、SRE、エラーバジェット、オンコール、ポストモーテム（障害の振り返り）などの用語が並んでいます。まだ案の段階なので、変わる可能性はあります。

民間の資格では、Google Cloudの「Professional Cloud DevOps Engineer」が、試験内容の約23%を「サイト信頼性エンジニアリング手法のアプリケーションへの適用」に充てています。

試験は2時間で、登録料は200ドル（税別）、日本語でも受けられます。

AWSでは、運用の資格だった「SysOps Administrator - Associate」が「CloudOps Engineer - Associate」に名前を変えました。

受験料は日本円で20,000円です（税が別にかかる場合があります）。

SREは、運用をこなすだけの人ではなく、運用の手間を減らしていく人です。Googleの本は、SREの時間の少なくとも半分を、この先のトイルを減らすか、サービスに機能を足すエンジニアリングの仕事に充てるとしていました。

先週のあなたの仕事のうち、同じ手順をくり返しただけの作業は、いくつありましたか。

参考出典
Google『Site Reliability Engineering』（Preface、Chapter 1 Introduction、Chapter 3 Embracing Risk、Chapter 4 Service Level Objectives、Chapter 5 Eliminating Toil）
経済産業省・情報処理推進機構（IPA）「デジタルスキル標準 ver.2.0」／IPA「情報処理技術者試験及び情報処理安全確保支援士試験の見直しの検討状況について」・「プロフェッショナルデジタルスキル（システム）試験（仮称）シラバス（案）Ver.0.2」
デジタル庁「デジタル社会の実現に向けた重点計画」（2024年6月21日）・「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（DS-310）・技術検討会議（第21回）資料3-1「APIテクニカルガイドブック（案）」・中途採用の求人
労働政策研究・研修機構「第5回改定 厚生労働省編職業分類 職業分類表」・「職業名索引」
厚生労働省「IT・デジタル人材の労働市場に関する研究調査事業」調査報告書（令和6年3月）・job tag
Google Cloud「Professional Cloud DevOps Engineer」認定試験ガイド／AWS「AWS Certified CloudOps Engineer - Associate」

「SRE」は国の統計の区分になく、表2のタスクと年収は運用・保守の職種の値です。IPAの新しい試験は検討中の案で、変わる可能性があります。求人の件数は2026年9月30日時点のもので、日々変わります。サービス内容と試験の条件は2026年9月時点の各公式サイトの記載です。申し込みの前に、最新の内容を公式サイトで確認してください。