自然言語BIで障害一次切り分けを5分に縮める運用設計
「本番でエラーが出てます」という連絡が来たとき、まず何を確認するだろうか。ログを開いて、ダッシュボードを見て、過去のインシデントを検索して……。この一連の作業、慣れた人でも15分はかかる。
最近注目されている「自然言語BI」を使えば、この一次切り分けを大幅に短縮できる可能性がある。「直近1時間でエラーが多いサービスは？」と聞くだけで答えが返ってくる世界だ。ただし、これには前提条件がある。今回は、その前提条件を満たすための運用設計について整理する。
自然言語BIとは何か
自然言語BI（Natural Language Query）は、SQLやDAXを書かずに「日本語や英語で質問するだけ」でデータを可視化・集計できる仕組みだ。Amazon QuickSight QやPower BI（Fabric Copilot）などが代表的なツールとして挙げられる。
ポイントは、これらのツールが「事前に意味づけ（セマンティック）されたデータ」を前提としていること。つまり、「service_name」というカラムが「サービス名」を表していて、「error_count」が「エラー件数」を意味する、という定義がツール側に登録されていないと、質問の意図を正しく解釈できない。
QuickSight Qの場合、この意味づけを「Topic」という単位で管理する。売上データ用のTopic、インシデントデータ用のTopic、といった具合だ。質問したとき「この質問をこう解釈しました」という説明情報が表示されるため、「あ、違う意味で取られた」と気づきやすい。
Power BIのCopilotは、自然言語からDAX（Power BI独自の数式言語）を生成してくれる。ただし公式ドキュメントで明確に警告されているのが、「生成されたDAXは必ず検証すること」という点。特にフィルターコンテキスト（どの条件で絞り込むか）が変わると、意図しない結果になることがある。
「5分で一次切り分け」の前提条件
正直なところ、自然言語BIを導入しただけで一次切り分けが5分になるわけではない。以下の土台が整っていないと、質問しても「該当データがありません」「解釈できません」で終わる。
1. インシデントのラベル標準化
「service_name」「severity」「status」といったフィールドを統一ルールで記録する必要がある。チームAは「auth-service」、チームBは「認証サービス」と書いていたら、「認証サービスのエラー件数は？」という質問に正確に答えられない。
2. 重要度と応答時間の規定
Grafanaのインシデント運用ベストプラクティスでは、重要度の例として「Criticalは即時対応」「Majorは15分以内」などが挙げられている。ただしこれはあくまで例であり、自社のSLA（サービスレベル合意）や体制に合わせて調整する前提だ。重要なのは、この定義が曖昧だと「重大度別の件数は？」という質問への回答が意味をなさなくなること。
3. ステータス遷移の共通化
「Declared → Acknowledged → Mitigated → Resolved」のように、インシデントがどの段階にあるかを統一フォーマットで記録する。これがバラバラだと、「現在対応中のインシデントは？」という質問に正確に答えられない。
4. よく聞く質問のテンプレ化
一次切り分けで頻繁に確認する質問をあらかじめリスト化しておく。例えば：
- 「影響を受けているサービスは？」
- 「直近1時間で何が変わった？」
- 「過去に同じ原因のインシデントはあった？」
- 「MTTA（平均確認時間）は？」
これらをTopicやセマンティックモデルの設計時に織り込んでおくと、質問の精度が上がる。
運用に組み込むときの注意点
自然言語BIには「ハルシネーション（もっともらしい嘘）」や「誤集計」のリスクがある。特に一次切り分けは判断の起点になるため、誤った情報に基づいて動くと被害が拡大しかねない。
対策として有効なのが、「根拠リンクにワンクリックで戻れる導線」を手順に組み込むこと。QuickSight Qなら質問の解釈結果を確認し、Power BIなら生成されたDAXを目視チェックする。「この回答、どこから来たの？」を5秒で確認できる状態を作っておく。
また、自然言語BIは万能ではない。複雑な条件分岐や、データソースをまたいだ分析には向いていない。そういった場面では従来通りSQLを書くか、専用のダッシュボードを用意するほうが早い。
どんなチームに向いているか
自然言語BIによる一次切り分け効率化が効果を発揮するのは、以下のようなチームだ：
- インシデント対応が特定の人に属人化していて、他のメンバーがログやダッシュボードを見ても状況把握に時間がかかる
- すでにインシデント記録はあるが、検索性が低い（フリーテキストで書かれている、ラベルがバラバラ、など）
- オンコール対応の負担を減らしたい
逆に、インシデントがほとんど発生しない安定したシステムや、すでに高度に自動化された監視体制があるチームには、導入コストに見合わないかもしれない。
まとめ
自然言語BIで障害一次切り分けを短縮するには、「聞けば答えが出る状態」を先に作る必要がある。ラベルの標準化、重要度の定義、ステータス遷移の共通化、よく聞く質問のテンプレ化。これらが揃ってはじめて、「直近1時間でエラーが多いサービスは？」という質問が意味を持つ。
そして、出てきた答えを鵜呑みにしないこと。根拠となるデータへの導線を確保し、「なぜこの答えになったか」を確認できる手順を残しておく。
地味な準備作業が多いが、一度整備すれば「この障害、前にも見た気がする」を5分で確認できるようになる。オンコール対応のストレスを減らしたい人は、まずインシデント記録のラベル統一から始めてみてほしい。