SRE面接対策2026：サイトリライアビリティエンジニアのためのAI練習ガイド

要約： SRE面接の準備は、一般的なソフトウェアエンジニア面接とは根本的に異なるマインドセットが必要です。失敗の最大の原因は技術知識の欠如ではなく、面接官がリライアビリティエンジニアの思考を期待しているのに、開発者として回答してしまうことにあります。本ガイドでは、SRE面接の6つのコアカテゴリ、エラーバジェットとSLO質問の実際の解き方、シニアエンジニアが落ちる理由、そして静的なQ&Aリストでは養えないオペレーショナル判断力をAIで鍛える方法を解説します。

あるシニアエンジニアが2026年のDEV.toに投稿した面接ガイドにこんな記述があります。「グーグルのSRE面接に落ちる候補者のほとんどは、SREの本を読んでいます。toil（運用上の苦労）が何かも知っています。SLOも定義できます。それでも落ちるのは、サービスが燃えているとき（障害時）に、インシデントの緩和ではなくコードの最適化に手を伸ばしてしまうからです」。これこそがギャップの正体です。

SRE面接が測るのは、プレッシャー下でオペレーターとして考えられるかどうかです――正しい用語を暗記しているかどうかではありません。だからこそ、汎用的な質問リストだけでは準備として不十分なのです。

日本のエンジニアにとってのSRE転職市場という観点では、グーグル・メタ・アマゾン・マイクロソフトといった外資系IT企業への応募だけでなく、SRE文化を取り入れたメルカリ・LINE・Zホールディングスなどの国内メガベンチャーへの転職機会も増えています。SREという概念はグーグルが提唱し、SREブックとして体系化したものであり、その思想を面接の場でどれだけ体現できるかが問われます。

SRE面接が他と異なる理由

ソフトウェアエンジニアの面接は、何を「作れるか」を問います。SRE面接は、何かが「壊れたとき」に何をするかを問います。

SRE面接のコア評価基準：

• 緩和優先の思考（Mitigation-first thinking）：障害が発生したとき、修正に手を伸ばしますか、それともロールバックに手を伸ばしますか？
• toil意識：自動化すべき作業を特定し、自動化のコストが見合う理由を説明できますか？
• ブラストラジウス思考：ミスのコストがカスタマー向けダウンタイムに直結する状況で、どう意思決定しますか？
• ポストモーテム文化：ブレームレスなポストモーテムを実施できますか、それとも誰かのせいにしようとしてしまいますか？

グーグル、メタ、ネットフリックスがSWE（ソフトウェアエンジニア）とは別にSREの面接トラックを設けているのは、スキルの重複はあっても重みづけが異なるからです。

グーグルSREブックはSREを「以前はオペレーション（運用）と呼ばれていた仕事を任されたソフトウェアエンジニアが行うもの」と定義しています。面接では、あなたがその定義を本当に体現しているか、それとも単に定義を読んだだけかを確認します。

SRE面接の6つのコアカテゴリ

SRE面接の大半はこの6つの領域をカバーしており、シニアリティに応じて重みづけが異なります。

1. SLO・SLI・エラーバジェット

これはSREの根幹となるメンタルモデルです。「SLOとは何か？」という質問はウォームアップです。本題の質問はこちらです：計画より速いペースでエラーバジェットを消費してしまっているとき、あなたはどうしますか？

強い回答には次の要素が含まれます：エスカレーションパス、フィーチャーベロシティを落とすかどうか、プロダクトチームへのコミュニケーション方法、エラーバジェットがオンコールローテーションの意思決定にどう影響するか。

典型的な質問：「あなたのサービスは99.9%可用性のSLOを持ち、2週目までに月次エラーバジェットの80%を消費しました。どう対応しますか？」

弱い回答：エラーバジェットとは何かを説明する。 強い回答：重要度の低いデプロイを凍結し、バジェットを消費したインシデントのポストモーテムを実施し、これらをより早く検知するためのアラートを調整し、信頼性とベロシティのトレードオフについてプロダクトチームと対話する。

2. インシデント管理とオンコール

定番の質問：「重要サービスで高レイテンシが発生しています。トラブルシューティングのプロセスを説明してください。」

期待される構造：ダッシュボード確認 → 影響範囲の特定 → 緩和（ロールバック、トラフィックシフト、フィーチャーフラグ）→ 安定化 → その後、根本原因の調査。

失敗パターンは、カスタマーへの影響を緩和する前に根本原因の分析へ直行してしまうことです。

3. Toil削減と自動化

「toil（トイル）とは何か、どのように体系的に削減しますか？」良い回答では、排除した特定カテゴリのtoilを具体的に挙げ、自動化のコストと削減効果を説明します。

4. 信頼性のためのシステム設計

SREのシステム設計質問は、スケールではなく回復性に焦点を当てます。グレースフルデグレーデーション、オブザーバビリティ、ブラストラジウスの制限を考慮した設計を問う質問が多く出ます。回答にはサーキットブレーカー、カナリアデプロイ、フィーチャーフラグ、ヘルスチェックを盛り込む必要があります。

5. オブザーバビリティとモニタリング

「フレイキーなアラートやアラート疲弊をどう対処しますか？」優れた候補者は、メトリクス・ログ・トレースを区別し、閾値ベースのアラートと比較してSLOベースのバーンレートアラートがノイズを削減できる理由を説明します。

6. LinuxとインフラストラクチャーFundamentals

「LinuxサーバーのCPU使用率が高い場合、どうトラブルシューティングしますか？」期待されるカバー範囲：top、htop、perf、コンテナ内のCPUスロットリング、ユーザー空間とカーネル空間のCPU使用率の違い。

実際に出るSRE面接質問

概念・マインドセット系：

• SREとDevOpsの違いは何ですか？
• あることが自分のチームの問題か他チームの問題かを、どうやって判断しますか？

オペレーショナル系：

• あなたが対応した大きなインシデントについて教えてください。あなたの役割は何でしたか？次はどう違うアプローチを取りますか？
• インシデント中にロールバックするかロールフォワードするかを、どのように決断しますか？

テクニカル系：

• マイクロサービスアーキテクチャに分散トレーシングをどう実装しますか？
• カナリアデプロイとブルー/グリーンデプロイの違いは何ですか？
• 単一障害点にならないレートリミッターをどう設計しますか？

行動面接系：

• あなたが主導したポストモーテムを教えてください。どんなアクションアイテムが出ましたか？
• 適切な信頼性トレードオフについてチームと意見が合わなかった経験を教えてください。

エラーバジェットとSLO質問を深掘りする

エラーバジェット質問は、候補者が最も躓きやすいポイントです。面接官がテストすること：

1. エラーバジェットを交渉ツールとして理解しているか？ 意図的にバジェットを使う（重要フィーチャーをアンブロックするためのリスクの高いデプロイ）と、偶発的に燃やしてしまう（誰も修正しなかった繰り返すタイムアウト）の違いを理解しているか。

2. エンジニアとプロダクト両方にSLOを説明できるか？ 厳しいSLOはデプロイベロシティを下げ、緩いSLOはイノベーションの余地を生む。この本質的なトレードオフを理解している候補者は強い。

3. 何を測るべきか分かっているか？ 適切なSLIの選択は非自明です。レイテンシ、可用性、エラーレートは基本。耐久性と正確性はシニアレベルで期待されます。

シニアエンジニアがSRE面接に落ちる理由

• デバッグマインドセット vs. 緩和マインドセット：経験豊富なエンジニアはインシデントシナリオで根本原因分析へ向かいます。SRE面接官が求めるのは「まず止血、次に原因究明」です。
• 原則ではなくツールへの過剰フォーカス：「PrometheusとGrafanaを使います」はツールリストです。「SLOベースのバーンレートアラートを導入します」が原則です。
• 信頼性を他者の仕事として扱う：サイロ化された組織出身の候補者は、信頼性をハンドオフとして説明します。SRE面接では信頼性をファーストクラスの要件として扱うことを求めます。

AI活用でSRE面接を練習する

静的なQ&Aリストでは埋められないギャップを、AI支援練習が埋めます：

• インシデントシナリオシミュレーション：インシデントシナリオを声に出して説明し、緩和を優先しているか根本原因分析を優先しているかについてリアルタイムフィードバックを受ける練習。
• エラーバジェット計算の練習：AIが生成するフォローアップ質問とともに、具体的な数値を扱う練習。
• 行動面接のコーチング：AIが、あなたのSTAR回答が適切なメンタルモデル（ブレームレスポストモーテム文化、toil意識、エラーバジェット思考）を示しているか評価します。
• 練習後の分析：あなたが開発者フレーミングとオペレーターフレーミングのどちらにデフォルトしていたかをAIが特定します。

転職活動でSRE面接を英語で受ける方にとっては特に、「SLI」「blast radius」「blameless postmortem」「toil」といった概念を英語でスムーズに説明できるかどうかは大きな課題です。AceRound AIはライブ面接中にリアルタイムで回答の示唆を提供します。面接官がインシデント対応プロセスについて聞いてきて頭が真っ白になっても、あなた自身の経験に基づいた話すべき要点をAIが提示します。

関連：DevOpsエンジニア面接ガイド | クラウドアーキテクト面接ガイド

SRE面接準備チェックリスト

• グーグルSREブックのtoil・SLO・エラーバジェットの章を読み直す
• 緩和優先のフレーミングで2〜3つのインシデントウォークスルーを練習する
• エラーバジェットの計算を習得する（99.9%・99.95%・99.99%でのダウンタイム分数）
• 自分が主導したポストモーテムを準備する
• 志望企業のエンジニアリングブログで公開ポストモーテムを確認する
• NALSDの質問を1つ練習する

よくある質問

SRE面接とDevOps面接の違いは何ですか？ DevOps面接はCI/CD、コンテナ化、ツーリングに焦点を当てます。SRE面接は信頼性エンジニアリング、エラーバジェット、インシデント管理、ベロシティと安定性のトレードオフに焦点を当てます。

フレイキーなアラートやアラート疲弊をどう対処しますか？ 体系的なアプローチとして捉えてください：閾値ベースのアラートではなく、SLOベースのバーンレートアラートへ移行する。SLOを脅かすペースでエラーバジェットを消費しているときにアラートを出す。

高レイテンシのトラブルシューティングプロセスを教えてください。 ダッシュボード確認 → 影響範囲の特定 → 緩和（デプロイと相関している場合はロールバック、地域障害の場合はトラフィックシフト）→ 未解決であれば対応者にページ → 緩和後に根本原因分析。

toilとは何か、どのように体系的に削減しますか？ Toilとは、手動で繰り返す運用作業で、永続的な価値を生まないものです。体系的削減の手順：toilの発生源を文書化し、頻度×時間コストで優先順位づけし、最もコストの高いものを自動化し、削減量を測定する。SREは作業時間の50%をエンジニアリング作業に充てるべきで、オペレーション作業が50%を超えている場合は何かが間違っています。

シニアエンジニアがグーグルのSRE面接に落ちる理由は何ですか？ 多くの場合、緩和優先の問題と、信頼性制約とブラストラジウスの強調なしにSWEシステム設計ラウンドのように面接に臨んでしまうことです。

SRE面接でAIを活用するべきですか？ 面接前のAI支援練習は、特にインシデントシナリオや行動面接の質問について、準備を大幅に加速させます。

---

著者 · Alex Chen。キャリアコンサルタント、元テックリクルーター。採用側で5年間働いた後、候補者のサポートに転向。教科書的なアドバイスではなく、リアルな面接の実態を書いています。