【正解】A、D
【0からの解説】
①前提知識
Google の SRE 本（『Site Reliability Engineering』第 32 章「進化する SRE エンゲージメント モデル」）では、SRE が新しいサービスに関わる段階を、おおむね「アーキテクチャと設計」→「活発な開発（Active Development）」→「限定的な提供（Limited Availability）」→「一般提供（GA）」→「廃止」のライフサイクルとして説明しています。
・「アーキテクチャと設計」の段階では、SRE は早期エンゲージメントとして設計の相談に乗り、信頼性の高い設計パターンを提案します。
・「活発な開発」の段階に入ると、SRE はサービスを本番に出せる状態にする「本番環境化（productionizing）」を始めます。具体的には、キャパシティ計画、冗長性のための追加リソースの準備、負荷急増や過負荷への対策、ロードバランシングの実装、そしてモニタリング・アラート・パフォーマンス チューニングといった持続可能な運用プラクティスの整備です。
・選択肢を段階に当てはめると次のとおりです。
- 「アーキテクチャと設計」段階（開発が始まる前）：C（プロダクト チームと協力した設計）、E（設計上の選択を議論する早期エンゲージメントのコンサルティング）
- 「活発な開発」段階の本番環境化：A（モニタリングとアラート）、D（冗長化）
- 特定の段階の中核作業ではない補助的な活動：B（インフラのガイドラインの文書化）
この対応関係を押さえると、「今どの段階にいるか」を問題文から読み取るだけで正解を絞り込めます。
②要件と制約語の整理
・サービスは「活発に開発中（actively developing）」で、すでに設計段階は過ぎている。
・今やるのは「本番環境化（productionalization）のプロセス」で、「次に（next）」取るべき行動を問われている。
③正解の根拠
活発な開発段階の本番環境化で SRE が行うべき代表的な作業は、A のモニタリングとアラートの確立（サービスの健全性を SLI で把握し、問題を検知して対応できるようにする）と、D の冗長化の実装（単一障害点をなくし、ゾーンやリージョンの障害に耐えられるようにする）です。どちらも本番運用に入る前に必須の準備であり、Google Cloud の Well-Architected Framework の信頼性の柱でも「リソースの冗長性による高可用性」と「オブザーバビリティによる障害の検出」が原則として挙げられています。
【誤りの選択肢】
B：インフラストラクチャのガイドラインの文書化は有益な作業ではありますが、SRE エンゲージメント モデルで本番環境化の中核として挙げられる活動ではありません。モニタリングや冗長化のような、本番の信頼性を直接高める作業より優先度が低く、「次に取るべき行動」として最適ではありません。文書化はどの段階でも並行して続ける作業であり、それ自体ではサービスの障害検知や耐障害性は向上しないため、本番環境化のチェックリストで優先される A・D には及びません。
C：プロダクト チームと協力したサービス設計は「アーキテクチャと設計」段階で行う活動です。本問のサービスはすでに活発に開発中であり、設計段階は過ぎているため、今のフェーズに合いません。
E：アーキテクチャと設計の選択を詳しく議論する早期エンゲージメントのコンサルティングも、設計段階で行う活動です。「早期（early）」という言葉のとおり、設計が固まる前に SRE が関与して手戻りを防ぐための活動であり、開発がすでに進んでいる本番環境化の段階で「次に」行うべき作業ではありません。問題文の「活発に開発中」「本番環境に向けて準備」という表現が、設計段階を過ぎていることを示す手がかりです。
【参考】
リソースの冗長性により高可用性システムを構築するオブザーバビリティを使用して潜在的な障害を検出するWell-Architected Framework: 信頼性の柱