障害対応を支援するコパイロット開発秘話

どんな事例か

本記事では、社内向けのGoogle Chat Bot「障害対応コパイロット」を開発した経験について、その設計判断と運用の試行錯誤を中心に振り返るものです。障害対応という、手順が定まっており、かつ確認や判断に時間と手間がかかる作業を、LLM（大規模言語モデル）を活用して支援することを目指しました。MVP（Minimum Viable Product）から認証強化版までを約2ヶ月で開発した過程が語られています。

使われた技術・ツール

このコパイロットは、複数の外部サービスを連携させて構築されています。

• Google Chat: ユーザーとの対話インターフェース、Botへの質問、アラート通知の投稿先として利用されています。
• SumoLogic: 監視・ログ基盤として、アラートの発火元となっています。
• CloudWatch: AWSリソースの監視、オートスケーリング台数アラートの発火元（SNS経由で連携）として機能します。
• Google Calendar: 会社休日（全社行事予定）の情報源として、日次で同期されます。
• Backlog: 過去のチケット検索元、およびチケットの起票先として利用されます。
• Vertex AI（Gemini）: 解析や対話を担うLLMとして採用されています。
• Bedrock（Titan Embeddings）: 過去インシデント検索用のベクトル化に用いられています。

これらのサービスを連携させる本体は、AWS上のLambdaとDynamoDB上に構築されています。常時稼働のサーバーを持たず、イベント駆動で動作する構成は、運用負荷を最小限に抑えるための判断でした。状態管理（会話履歴、インシデント記録、当番情報など）はDynamoDBに集約されています。

また、Botへの入口には「チャット経路」と「アラート経路」の2種類があり、それぞれ認証の前提や流量が異なります。この入口の保護は、開発フェーズを通じて大きく変化した部分です。

開発は大きく3段階を経ています。

• Phase 1（MVP）: Lambda Function URL（無認証）を入口とし、LLMにはBedrock（Claude）を使用。主な機能はアラート解析と対話でした。
• Phase 2: 入口はLambda Function URLのまま、LLMもBedrock（Claude）を継続。機能としてQ&Aが追加されました。
• Phase 3（現在）: 入口をAPI Gateway + Lambda Authorizerに変更し、LLMをVertex AI（Gemini）に移行。主な機能追加として、類似インシデント検索、当番・休日同期が行われました。

得られた成果

このコパイロットの主な機能は以下の通りです。

• アラートの自動解析: アラート内容をLLMで解析し、原因の切り分けと対応要否の判定を添えてGoogle Chatに投稿します。
• 過去類似インシデントの提示: ベクトル類似検索により、過去の類似インシデント記録を提示します。
• 当番自動メンション: その日の当番者を自動で割り出しメンションします。土日・会社休業日はメンションを抑止しつつ、解析投稿は行います。
• 対話Q&A: アラートとは無関係に、運用や調査に関する質問に雑談的に答えます。
• スラッシュコマンド: /status, /oncall, /history, /summary, /postmortemなどの定型操作を呼び出せます。
• App Home: Google ChatのApp Home画面から主要機能にGUIでアクセスできます。

特に「アラートの自動解析」では、監視基盤からアラートが発火すると、BotがLLMに解析を依頼し、関連ログやAWSの状態を確認した上で、「何が起きていそうか」「対応が必要か」をまとめます。この一次切り分けの基礎を人間が動く前に用意することで、対応担当者は判断と実作業に集中できるようになります。

LLMの選定においては、当初AWSのBedrock経由でClaudeを使用していましたが、コストと推論の調整自由度を考慮し、Vertex AI（Gemini）へ移行しました。モデル移行に伴い、プロンプトのチューニングも行われました。具体的には、Geminiが「調査の手がかりが尽きると早めに『これ以上は分かりません』と切り上げる」傾向があったため、プロンプトに「代替経路」を明示することで、行き詰まっても手を止めないように促しています。

過去インシデント検索機能では、インシデント内容テキストをベクトル化し、新しいアラートのベクトルとの類似度で検索する仕組みを採用しています。Embeddingの生成はユーザーが「過去事例を知りたい」と判定操作したタイミングで行い、ベクトルデータはDynamoDBにJSON文字列として保存し、全件読み出して類似度を計算しています。これは、対象インシデント数がそれほど多くなく、専用のベクトル検索サービス導入による運用・コスト・学習負荷を避けるための判断です。

同じ規模の組織が真似できるポイント

この開発事例から、他の社内向けLLMツール開発に活かせるポイントがいくつか挙げられます。

• 「自動化」より「コパイロット（伴走）」を目指す: 最終判断や実作業までAIに委ねるのではなく、人間の判断を速く確実にするための支援に留めることで、品質とリスクのバランスを取る。
• 運用負荷の最小化: 常時稼働サーバーを持たず、イベント駆動で動く構成（Lambda + DynamoDB）を採用する。状態管理もDynamoDBに集約し、インフラの保守負担を減らす。
• 段階的な開発と移行: 最初から完璧を目指さず、MVPから始め、段階的に機能追加や技術選定の見直しを行う。特にLLMのモデル移行は、プロンプトチューニングとセットで行う必要がある。
• コストと機能のバランス: ベクトル検索のように、件数が少ないうちは専用サービスを使わず、汎用的なデータベース（DynamoDB）で全件スキャンする方が総合的に安価で運用負荷も低い場合がある。
• 入口の設計の重要性: チャット経路とアラート経路など、異なる性質を持つ入口に対して、それぞれ適切な認証や流量制御を行う。

まとめ

「障害対応コパイロット」の開発は、繰り返される定型作業をLLMで支援するという具体的な課題から始まりました。自動化ではなく「コパイロット」という位置づけ、運用負荷の最小化、段階的な技術選定と移行といった設計判断が、少人数でツールを育てていく上で重要な要素となっています。LLMの選定やベクトル検索の実装方法など、具体的な技術選択の背景には、コストや運用負荷を考慮した現実的な判断がありました。これらの経験は、今後社内向けLLMツールを開発する際の設計判断の参考になるでしょう。

出典: https://zenn.dev/interpark/articles/incident-copilot-design-decisions