【正解】A
【0からの解説】
①前提知識：Google Security Operations（Google SecOps、旧 Chronicle と旧 Siemplify を統合した SIEM / SOAR プラットフォーム）の SOAR 機能では、アラートがケースとしてまとめられ、プレイブック（ハンドブック）がケースに対して自動でアクションを実行します。プレイブックは「メールの取り込み → 添付ファイルや URL・送信元などのエンティティ抽出 → Google Threat Intelligence（旧 VirusTotal Enterprise）などの脅威インテリジェンスによる拡充 → 影響範囲の判定（同じメールを受信・開封したユーザーの特定など）→ 適切なアナリストやステージへの割り当て」といった一連の手順を、人手を介さずに数秒〜数分で実行できます。
②要件の整理：問題の根本原因は「Tier 1 アナリストの手作業（証拠の追加・判断・エスカレーション）に依存していたため、30 分の SLA 内に重要な判断と次のアクションが行われなかった」ことです。求められているのは「今後の優先度の高いインシデントに向けてケース管理ワークフローを最適化する」ことで、人に依存する遅延を構造的に取り除く対策が必要です。
③正解の理由：A のプレイブックは、報告されたフィッシング メールの取り込み・エンティティ拡充・影響判定を自動で行い、その結果を付けてケースを適切な担当者に割り当てます。アナリストが手作業で行っていた初動調査が自動化されるため、判断材料がそろった状態で即座にレビューへ回り、SLA 内の封じ込めにつながります。Google SecOps SOAR の設計思想（反復的な初動対応はプレイブックで自動化し、アナリストは判断に集中する）に沿った最も適切な改善策です。
【誤りの選択肢】
B：すべてのフィッシング アラートを Tier 2 に送るのは担当者を変えるだけで、手作業による調査とエスカレーション判断の遅延という根本原因は解消されません。Tier 2 の負荷が増え、低優先度のアラートまで上位層に集中するため、かえって対応が遅れるおそれがあります。
C：5 分ごとに複数の関係者へメールを送り続ける通知ループは、アラート疲れ（ノイズ）を生むだけで、調査や封じ込めそのものは何も自動化されません。「手動で再割り当てされるまで」という条件も人の操作に依存しており、ワークフローの最適化とは言えません。
D：60 分間対応がなければ自動クローズするのは、未対応の高優先度インシデントを放置したまま闇に葬ることになり、セキュリティ上きわめて危険です。SLA 違反を隠すだけで、対応速度は改善しません。
【参考】
ハンドブックと自動化の概要 | Google Security Operations調査とケース管理の概要 | Google Security Operations拡充 | Google Security Operations