InfraAcademy Blog

SRE（サイト信頼性エンジニアリング）とは？2026年、AIで『速いけど壊れやすい』時代に効く信頼性の考え方

公開日: 2026-08-14 更新日: 2026-08-14 | #クラウド #インフラ #トレンド

Linuxをブラウザで試してみる

Linux・ネットワーク・AWSを、環境構築なしで実践学習できます

こんにちは、インフラエンジニアのryuです。

「前より速くリリースできるようになった。でも、なんだか前より壊れやすくなっていないか？」

最近、現場でこういう声をよく聞くようになりました。生成AIのおかげでコードを書くスピードは上がった。デプロイの回数も増えた。それ自体は良いことのはずなのに、障害の火消しや手戻りに追われる時間は、むしろ増えている気がする——。

これは気のせいではありません。2026年のいま、開発の世界を代表する調査がまさに同じことを指摘しています。速くはなった。けれど、安定はしていない。

その「速さ」と「壊れにくさ」を、感覚や根性ではなく数字で両立させるための考え方が、今日のテーマである SRE（Site Reliability Engineering／サイト信頼性エンジニアリング）です。

名前は少しいかついですが、中身はとても実践的で、これからインフラを学ぶ人にこそ知ってほしい分野です。専門用語をかみ砕きながら、順番に見ていきましょう。

SRE（サイト信頼性エンジニアリング）って、そもそも何？¶

まず言葉のイメージから入りましょう。

昔から、システムには「作る人（開発）」と「守る人（運用）」がいました。開発は新しい機能をどんどん出したい。運用はとにかく落とさず安定させたい。この二つは、しばしばぶつかります。

新機能を出せば出すほど、システムは変化し、壊れるリスクも上がる。だから運用側は「もう変更しないでくれ」と言いたくなる。でも変更を止めれば、サービスは前に進めません。

このずっと続いてきた綱引きに、Googleが約20年前に出した一つの答えがSREでした。

SREとは、これまで人手の作業だと思われてきた「運用」を、ソフトウェアエンジニアリングの問題として解き直すアプローチです。監視も、復旧も、環境の準備も、できる限りコードと仕組みで解く。人間は、人間にしかできない判断に集中する。そういう発想の転換ですね。

Googleは自社の巨大なサービスをこのやり方で支え、その知見を『Site Reliability Engineering』という一冊の本として公開しました。いまSREと呼ばれる実践の多くは、ここが出発点になっています。

「絶対に落とさない」を目指さないのがSRE¶

意外に思われるかもしれませんが、SREは「100%落とさないこと」を目標にしません。

これは大事なところなので、たとえ話をさせてください。

宅配便を思い浮かべてみましょう。「1個も遅れず、1個も壊さず、絶対に100%完璧に届ける」を目指したら、どうなるでしょうか。トラックを何重にも用意し、荷物を過剰に梱包し、検査を何度も重ねる。コストは天井知らずに膨らみます。

しかも、受け取る側からすると、99.9%ちゃんと届くのと99.99%届くのとで、体感の差はほとんどありません。差を詰めるための労力だけが、指数関数的に増えていきます。

システムも同じです。可用性を99.9%から99.99%へ、さらに99.999%へと上げていくと、必要なコストと手間は跳ね上がるのに、ユーザーが感じる価値はさほど変わらない。

だからSREは、まず問います。「このサービスは、そもそもどれくらいの信頼性があれば十分なのか？」と。100点満点ではなく、ちょうどいい合格ラインを決める。ここがSREのいちばんの肝です。

信頼性は「機能」のひとつだと考える¶

もう一つ、SREの根っこにある考え方があります。それは、信頼性をサービスの「一番大事な機能」として扱うことです。

どんなに便利なアプリでも、開こうとするたびに落ちていたら、誰も使い続けません。逆に、地味でも「いつ開いても、ちゃんと動く」ことは、それだけで大きな価値です。

信頼性を、あとから運用チームが頑張って守るオマケではなく、最初から設計に組み込む対象として扱う。SREはそういう目線でシステムを見ます。

SREの中核：SLI・SLO・エラーバジェット¶

では、「ちょうどいい信頼性」を、どうやって感覚ではなく数字で決めるのか。ここで登場するのが、SREを語るうえで欠かせない三つの言葉です。少し似ていて紛らわしいので、表で整理してみましょう。

用語	読み方	ざっくり言うと
SLI	指標	実際に測った「今の良さ」の数値
SLO	目標	「これくらいは満たそう」という合格ライン
エラーバジェット	失敗の許容量	合格ラインまでに許される失敗の残り枠

一つずつ、たとえを添えて見ていきます。

まず SLI（Service Level Indicator）は、サービスの良し悪しを測った実測値です。たとえば「直近30日で、リクエストのうち何%が成功したか」「応答が何ミリ秒以内に返ったか」。テストの点数そのもの、と思ってください。

次に SLO（Service Level Objective）は、その指標に対して自分たちで決める目標ラインです。「成功率は99.9%以上を保とう」というような約束事ですね。テストで言えば「合格は80点以上」と決めるようなものです。

そして、SREらしさが一番出るのが三つ目、エラーバジェットです。

エラーバジェットは「失敗してもいい枠」¶

エラーバジェットとは、SLOで決めた合格ラインまでに許される『失敗の残り枠』のことです。式にすると、とてもシンプルです。

エラーバジェット = 100% - SLO

例）SLO が 99.9% のサービスなら
　　許される失敗は 0.1%
　　1か月に100万リクエストを受けるとき
　　→ 1,000回までの失敗は「予算内」

ここが発想の転換ポイントです。SREでは、失敗をゼロにしようとしません。「ここまでは失敗してもいい」という枠を、あらかじめ予算として持っておくのです。

家計にたとえるとわかりやすいでしょう。今月の外食費は2万円まで、と決めておく。その範囲なら気にせず使っていい。使い切りそうなら、少し引き締める。エラーバジェットは、まさに信頼性の「今月の予算」です。

この予算があると、開発と運用のいつもの綱引きが、驚くほどすっきりします。

予算がまだ残っているなら、新機能をどんどんリリースしていい。多少の冒険もOK。逆に予算を使い切ってしまったら、しばらく新機能を止めて、まず安定を取り戻すことに集中する。

「攻めるか守るか」を、声の大きさや立場ではなく、残り予算という共通の数字で決められる。Googleの原典でも、エラーバジェットは開発チームとSREの間の交渉から「政治」を取り除くための仕組みだと説明されています。

静的なしきい値から「バジェットの燃え方」を見る監視へ¶

このエラーバジェットの考え方は、2026年のいま、監視のやり方そのものも変えつつあります。

昔ながらの監視は「CPU使用率が80%を超えたら警告」のような、固定のしきい値が中心でした。でも、しきい値を超えても実際にはユーザーに影響がないことも多く、真夜中に鳴る意味のないアラートに疲れてしまう——という悩みは尽きませんでした。

そこで最近増えているのが、エラーバジェットの「燃え方（burn rate）」を見る監視です。予算が普段より急に速く減り始めたら、それは本当に危ない兆候だと判断してアラートを上げる。まだ手が打てるうちに、意味のある通知だけを届けよう、という考え方ですね。

こうした「何を測り、どう気づくか」の土台になるのが、以前このオブザーバビリティ（可観測性）の記事で紹介した仕組みです。SREとオブザーバビリティは、いわば車の両輪の関係にあります。

トイル（toil）を減らす——手作業の繰り返しと戦う¶

SREにはもう一つ、現場でとても愛されているキーワードがあります。トイル（toil）です。

トイルとは、手作業で繰り返し発生し、自動化できるのに人間がやり続けている『価値を生まない労働』を指します。

たとえば、毎朝ログを目で確認して同じ対応をする。ディスクがいっぱいになるたびに手で掃除する。同じ手順書を見ながら、同じ復旧作業を毎回なぞる。どれも、悪くはないけれど、あなたが本来やるべき創造的な仕事ではありません。

SREはこのトイルを「敵」とみなします。人が繰り返す作業は、コードや自動化に置き換えていく。Googleの原典では、SREがトイルに費やす時間の上限を全体の50%までにすべきだと勧めています。半分を超えたら、それは自動化への投資を怠っているサインだ、というわけです。

トイルを減らすことは、単に楽をするためではありません。人間の時間を、監視の仕組みづくりや、障害の根本原因の解決といった「一度やれば効き続ける仕事」に振り向けるためです。ここに、運用をエンジニアリングとして解くというSREの思想がよく表れています。

2026年のSRE——AIが連れてきた「速いけど壊れやすい」問題¶

さて、冒頭の話に戻りましょう。なぜ2026年のいま、SREがあらためて注目されているのか。

背景にあるのが、開発の実態を毎年調べているDORA（DevOps Research and Assessment）の2025年レポートです。ここで示されたのは、少し皮肉な現実でした。

生成AIの活用はすでに当たり前になり、レポートでは回答者の約9割が日々の開発でAIを使っていると答えています。そしてAIの活用は、確かに開発のスピードを押し上げていました。

ところが同時に、AIの活用は「不安定さ」とも結びついていたのです。変更に伴う失敗や手戻りが増え、問題の解決までに時間がかかる傾向が見られました。理由はシンプルで、AIがコードを生み出す速さに、レビューやテスト、デプロイの仕組みが追いつかないから。生成の蛇口だけが太くなり、下流が詰まる、というイメージですね。

つまり、AIは既にあるチームの性質を「増幅」します。土台のしっかりしたチームでは速さがそのまま価値になり、土台の弱いチームでは、もろさや混乱までいっしょに拡大してしまう。

ここでものを言うのが、まさにSREの土台です。どこまでの失敗を許すかを決めるエラーバジェット。何を測り、どう気づくかを支えるオブザーバビリティ。手作業を仕組みに置き換えるトイル削減。AIで開発が速くなった時代だからこそ、この「速さを安全に受け止める受け皿」の重要性が増しているのです。

AIそのものが運用をどう変えていくかについては、生成AIとAIOpsの記事でも触れています。SREは、そのAI時代の運用を支える基礎体力にあたります。

SREは、プラットフォームエンジニアリングとどう違う？¶

最近よく一緒に語られる言葉に、プラットフォームエンジニアリングがあります。混同されがちなので、ここも整理しておきましょう。

ごく大まかに言えば、SREは「サービスをどれくらい信頼できる状態に保つか」という信頼性の視点です。一方でプラットフォームエンジニアリングは、開発者が迷わず速く働けるように「共通の土台（基盤）」を整える取り組みです。

料理店にたとえるなら、プラットフォームエンジニアリングは、誰が入っても同じ手順で調理できる整った厨房を用意する役割。SREは、その店が「いつ来ても、ちゃんと美味しく出てくる」という信頼を守る役割、といったところでしょうか。

対立する概念ではなく、良いチームは両方を組み合わせています。この関係にもう少し踏み込みたい方は、プラットフォームエンジニアリングの記事もあわせて読んでみてください。

これからSREを学びたい人へ——どこから始める？¶

「面白そうだけど、SREって上級者向けでは？」と感じたかもしれません。でも、入口は決して特別なものではないんです。

SREは、特定のツールの名前ではなく、考え方と基礎技術の積み重ねです。だから、遠回りに見えても、土台を順番に固めるのが結局いちばんの近道になります。

順番としては、まずLinuxとネットワークです。サーバーの上で何が起きているかを読み解けること、パケットがどう流れるかをイメージできることは、信頼性を語るうえでの共通言語になります。ここが曖昧なままだと、SLOもエラーバジェットも「言葉」で終わってしまいます。

学習サイトのInfraAcademyでは、この土台を初心者向けに順を追って学べます。まずはLinuxのロードマップから手を動かし、そのあとネットワークのロードマップへ進むと、SREの話がぐっと自分ごととして読めるようになります。全体像をつかみたいときは、インフラ学習のロードマップ記事も入口として役立つはずです。

大切なのは、いきなり難しい自動化に挑むことではありません。身近な作業のうち「これ、毎回手でやってるな」というトイルを一つ見つけて、小さく仕組みに置き換えてみる。SREの実践は、そんな一歩から始められます。