こんにちは。株式会社IVRyでSREをやっている渡部です。ネパールカレーにハマりすぎて旅行先でもその土地の料理より先にネパール料理屋を探すようになってしまって久しくなります。
私たちIVRyのSREチームは、「全人類が電話をかけてきても耐えられるサービスを目指す ~ 落ちても落ちない編 ~」をテーマに、日々サービスの信頼性向上に取り組んでいます。音声AIというリアルタイム性が求められる領域では、わずかな遅延やエラーでもユーザー体験に直結します。だからこそ、ただ強いシステムを作るだけではなく、落ちても素早く立ち上がれる運用体制が必要です。この記事では、IVRyで実際に行ったPlaybookの作成プロセスと障害訓練、そしてそこから得られた学びと今後の展望について紹介します。
※Playbook：障害発生時の調査・対応プロセスをドキュメント化したもの
はじめに
サービス成長に伴い、信頼性は運用における重要な指標のひとつになっています。どれだけ堅牢なシステムを構築しても「障害ゼロ」は不可能です。だからこそ、「障害に強い運用体制」を整えることが、IVRyのような音声AIサービスを安定して提供する上で欠かせません。一方で、障害対応の現場では「限られた情報の中で、どのように最適な判断を下すか」が常に問われます。過去の対応履歴をもとにした知見や、誰がどのタイミングで何をすべきかといった行動指針が明確でないと、初動の遅れや認識のずれが発生しやすくなります。また、障害の影響範囲が広がるにつれ、「技術的な解決」だけでなく「組織としてどう動くか」が重要になります。
この課題を解決するために、IVRyではPlaybookの整備と障害訓練の実施に取り組みました。Playbookによって判断と行動の基準を共通化し、障害対応を個人の経験に依存しないものへと変えていく。そして訓練によって、それを「ドキュメントとして知っている」から「実際に動ける」状態へと昇華させていくことに取り組みました。
Playbookを整備する理由
IVRyのような音声AIサービスでは、音声認識や合成、通話制御など複数の外部サービスやコンポーネントが連携して動作しています。そのため、障害が発生した際にどの部分で問題が起きているのかを即座に判断することが求められます。しかし実際の現場では、「どのメトリクスを見ればよいか」「どのような対応をすれば良いのか」「どのチームに連絡すべきか」といった判断が属人的になりがちでした。このような課題を解消するために、Playbookの作成を進めました。
Playbookには次のような内容を整理しています。
- アラートが発報されたときに最初に確認すべき指標
- 影響範囲の特定方法（どのユーザー・どの機能が影響を受けているか）
- 一時対応のためのステップ
これにより、誰が対応しても同じ品質で初動ができるようになり、障害対応を「個人のスキル」から「チームの仕組み」へと進化させることを目指しました。
実際のPlaybook
以下は実際のPlaybookになります。具体的な異常状態に加えてユーザーごとにどういった状況になるのかや、内部的にどういう動作をするのかについて書かれています。
Playbook作成中の課題
Playbookを書いていく中で見えてきたのは、異常を検知する仕組みの乏しさでした。例えば、LLMの応答精度の悪化や、音声合成（TTS）の遅延にどのように気づけるか、といった事象を正確に把握するための可観測性がまだ十分とは言えず、改善の余地があることが分かりました。
↓実際に使用しているDatadogのダッシュボード
特に、IVRyのようにWebSocketでリアルタイムに音声をやり取りするアプリケーションでは、どの指標を観測し、何を異常とみなすかの定義自体が難しい領域です。メトリクスやトレースの取り方、異常の定義、ユーザー体験との結びつけ方など、まだまだ挑戦の余地があります。
このあたりのテーマに興味がある方は、ぜひカジュアル面談などでお話しできればと思います。
また、過去に私と弊社AI Engineerのmoriyaが共同登壇した資料も公開しています。
障害対応や信頼性向上の実践についてより詳しく知りたい方は、ぜひそちらもご参照ください。
障害訓練の実施
Playbookを作って終わりではなく、実際に手を動かして検証することが重要です。そこで、チーム全体で障害訓練を実施しました。今回のシナリオは「LLMのレイテンシーが閾値を超え、通話応答が遅延し始めた」というケース。実際にアプリケーションに遅延を仕込みDatadogからのアラートをトリガーに、インシデントチャンネルを作成し、各メンバーがインシデントコマンダー・調査担当・コミュニケーション担当といった役割を持って対応を進めました。
訓練では、実際のインシデント対応を模して、次のような流れで進行しました。
アラートの検知と初動対応
Datadogのアラート内容を確認し、どの機能・ユーザーに影響があるかを即座に把握。
Playbookの手順に沿って、最初に確認すべきメトリクスを確認しました。
情報共有と対応方針の決定
Slack上で状況を共有し、「どのコンポーネントが原因か」「どの対応を優先するか」をチーム全体で議論。コマンダーが判断し、タスクを分担しました。
一時対応とモニタリング
仮修正を行いながら、メトリクスの変化やエラーレートを監視。リカバリーが見込めるか、さらなる対応が必要かをリアルタイムで確認しました。
ログ整理とポストモーテム準備
各担当者が対応経過を残し、ポストモーテムで振り返るための情報を整理しました。
ポストモーテムの実施
障害の要因や判断プロセスを振り返り、Playbookへの改善点をディスカッションしました。
今回の訓練では、Playbookが「単なるドキュメント」から「実際に動けるためのガイド」へと進化している手応えがありました。特に、状況認識の共有スピードや判断の一貫性が向上し、「個人の勘」に頼らない対応が実現しつつあります。
↓は対応している様子
訓練を通じて得られた学び
実際に行動してみることで、いくつもの改善点や新しい気づきが得られました。
まず、Playbookを活用することで状況認識の統一がスムーズに行えた点が大きな成果でした。
「どのメトリクスを見て、どの順に確認すればよいか」が明確になっていたため、アラート対応から体験確認、インシデント判定、実装確認といった一連の流れを落ち着いて進めることができました。チームメンバーからも「Playbookがなかったら混乱していたと思う」「二次災害を防ぐため、修正をそのまま本番環境に出すのではなく、stagingで最初に確認できたのが良かった」といった声が挙がり、属人化の解消と初動品質の均一化に手応えを感じました。
一方で、実際に対応してみることで改善すべきポイントも明らかになりました。DatadogやSentryなどで見たい情報にすぐアクセスできなかったり、使用しているクラウドサービスのメトリクスの閲覧権限を持たないメンバーがいたりと、環境や権限の整備に課題が残りました。また、内製しているインシデントBotの操作に慣れていないことで一部対応が滞る場面もあり、操作リマインドや自動参加設定の仕組みを検討する必要があると感じました。
さらに、「遅延」というインシデントの判断基準の難しさも浮き彫りになりました。音声AIのように外部APIやモデル性能に依存するサービスでは、「遅いけれど動いている」状態をどう扱うかの判断が難しく、そのような判断基準の整備が必要であると気づきました。
今後の展望
今後も定期的な訓練を継続しながら、Playbookをより現実的で使いやすい形へアップデートしていきます。また、SLOやポストモーテムの仕組みとも連動させ、「検知 → 対応 → 振り返り → 改善」のサイクルが自然に回る運用体制を目指します。最終的には、Playbookに蓄積された知見をもとに、人が判断しなくても自動的にフォールバックできる仕組みへと進化させていきたいと考えています。たとえば、音声認識や生成処理で異常を検知した際に、システムが自律的に別モデルへ切り替えたり、エラーが発生する前に自動的に負荷を分散し、“落ちても落ちない”世界を人手なしで実現すること。それが今のIVRyのSREのミッションの一つです。障害対応を“例外的な出来事”ではなく、 学習と進化のプロセスと捉え、信頼性をチームや会社全体で育てていく。その文化を“当たり前”にすることを目指しています。
また、今回はエンジニア中心で対応を行いましたが、実際の障害現場ではビジネス影響を踏まえた判断が求められる場面が多くあります。「いつリリースを止めるか」「どのユーザーへの影響を優先するか」などは、PdMが関わることでより迅速かつ的確な判断が可能になります。そのため、次回はPdMにも参加してもらい、技術とビジネスの両面で意思決定できる運用体制を強化していきたいと考えています。
宣伝
今回紹介した内容の詳細や、より実践的なノウハウについては、Software Design 2025年11月号に寄稿した記事「怖くないオンコール対応 ― 障害対応の基本動作と精神的ストレスを軽減する方法」で詳しく紹介しています。また、SREの視点から見た障害対応の考え方や組織づくりについては、共著書『SREの知識地図』にもまとめています。
どちらも、日々の運用や信頼性向上のヒントになれば幸いです。書店などで見かけた際はぜひ手に取ってみてください。
Discussion