Geminiで実現するSRE机上障害訓練

本稿はJCB Advent Calendar 2025の12月18日の記事です。

SREチームの鳩貝です。先月ぎっくり腰になってから整骨院に通い詰めてます。

JDEP SREではシステムの信頼性を担保するため、日々さまざまな運用改善に取り組んでいます。今回はチーム内で行っているオンコーラ（障害対応担当者）の育成施策と、そこに生成AI（Gemini）を導入した際の検証結果を紹介します。

1. 机上障害訓練「Wheel of Misfortune」における課題

JDEP SREでは主に基盤障害に対し24/365で対応する運用体制を構築しています。体制のなかでもオンコーラは監視システムからのアラートを一次切り分けし、必要に応じインシデント発生を宣言する役割を担っています。
基盤障害と一言で言っても、複数の要素技術で構成されているJDEPではその分適切な対応に多くの知見が必要です。一方で負荷軽減のためオンコーラは輪番体制をとっていることから、着任して比較的日の浅い開発者も担当可能なようスキルの底上げが必要でした。

よってGoogleが提唱する "Wheel of Misfortune" (WoM) というプラクティスを導入し、オンコーラの育成に活用しています。

WoMは過去発生した実障害や、Gamedayのシナリオを題材に行うロールプレイング形式の訓練です。進行役と対応者の2ロールに分かれ、可能な限り実際に近いシチュエーションを想定したうえで、机上のやりとりのみで障害訓練を行います。テーブルトークRPGをイメージ頂くとわかりやすいかもしれません。

Dungeon Master (DM)：進行役。障害発生の状況説明や、監視データの提示を行います。主にチーム内のシニアメンバが担当します。
Player：対応者。DMから提供された情報を元に調査を行い、原因特定と復旧を目指します。主にチーム内の経験の浅いメンバが担当します。

本手法は、実環境に影響を与えず安全に障害対応プロセスを習得できるというメリットがあります。
※JDEPにおけるWoMの取り組みをより詳しく知りたい方は、弊社笹野のWoM紹介記事を参照ください。

このようにWoMは有用な施策である一方で、継続的な実施には課題もありました。最大の障壁は「DM（進行役）の負荷」です。

Playerの調査状況に応じて適切な情報を提示し、時にはPlayerの誤判断を正しい方向に誘導する必要があるため、DMにはシステム全体への深い理解と高いスキルが求められます。結果DMを担当できるのは一部シニアメンバに限られてしまい、業務の合間を縫って開催することもあって実施頻度が伸び悩む、という状況でした。

2. 生成AIによるWoM自動化の試行

前項の課題を解決するため、私たちはGeminiをDM役として活用する検証を行いました。過去のGamedayでも使用したDatadogの各種監視設定やプレイブック（運用手順書）などの資料をGeminiに読み込ませることで、WoMのセルフサービス化を目指しました。

インプットファイルの概要は下表を参照ください。
なお、今回WoM実施にあたり利用した実機データはすべて開発・検証環境の情報となります。また、Geminiとしても入力データが学習に利用されない企業向け環境を使用しています。

ファイル種別	説明
環境情報および障害ケース	障害が発生したシステムの構成情報・メトリクス情報と、正解となるシナリオ情報。
インシデントポリシー	SREチームが障害対応時に利用する、インシデントポリシー。トラブルシューティング能力だけでなく、組織として正しい行動（連絡・起票等）が取れるかも検証するため。
Datadog定義(JSON)	ダッシュボードおよびMonitorの定義ファイル。アラート発報状況やメトリクス推移をGeminiに理解させるため。
プレイブック	Datadog Monitorに紐づくプレイブック。

上記情報をGeminiに読み込ませ、SREメンバーで試験運用を行いました。当初はスムーズに応答していましたがシナリオが進むにつれて徐々に雲行きが怪しくなり、最終的には明らかなハルシネーションが発生し始めました。

本来の障害シナリオとは異なるアラートが提示されたり、根拠のないコンポーネントが原因として示唆されてしまう。
参照すべきプレイブックの内容をGeminiが正しく認識できず、全く無関係な情報（戦国武将のプロフィール情報等）を提示し始める。

ハルシネーションの原因をGeminiに確認したところ、シナリオ難読化のために行っていた「資料のBase64エンコード」が原因だと判明しました。

というのも、検証を行った当初は、まだGemの共有機能（2025年9月リリース）がなく、Player各自でファイルをアップロードする必要がありました。そのため、ネタバレ防止の苦肉の策としてBase64化して配布していました。

もちろん本格的な暗号化ではありませんが、パッと見で内容が分からないようにするための処置でした。しかし残念ながら本処理がGeminiの負荷となり、正しく文脈を理解できない要因となっていたようです。加えて、開始前に毎回大量のファイルをアップロードする手間も発生しており、この時点では「実運用は厳しい」という判断を下さざるを得ませんでした。

3. 共有Gemの活用と今後

前述のハルシネーションにより（チーム内である種の盛り上がりは見せたものの）、Geminiを用いたWoMは一時頓挫しました。しかしながら、前述のGem共有機能のリリースにより、以下の通り状況が改善されました。

あらかじめ管理者が必要インプットをGemに投入できるため、ネタバレ防止理由によるBase64エンコードが不要になった。結果としてハルシネーションが激減し、回答品質が向上した。
そもそもインプット量が多いため、初期セットアップに時間がかかっていた問題も解消。Playerは共有Gemを開くだけでいつでもWoMを実施できるようになった。

実際に共有Gemを用いたWoMの例が以下です。 Base64化していた頃とは異なり、インシデントポリシーを正しく解釈しPlayerの行動不足（Ack漏れやインシデント宣言漏れ）を的確に指摘できている様子が見て取れます。