エージェントの障害対応を振り返ると、「この現象、先月も見ませんでしたか」という声がよく上がります。担当者は毎回まじめに切り分け、プロンプトを少し直したり、ツールをリトライさせたりして、きちんと収束させています。それでも、似た障害は数週間後にまた起きます。
AgentOpsシリーズでは、インシデント運用（9/5）で「目の前の障害をどう収束させ、どう振り返るか」を扱いました。ただ、1件ずつのポストモーテムをいくら丁寧に書いても、複数のインシデントに共通する根本原因は誰の担当にもならず、放置されがちです。とくに非決定的なLLMエージェントでは、「たまにしか起きない」「似ているけれど毎回少し違う」障害が多く、個別対応だけでは傾向が見えてきません。
ITILでは、インシデント管理・問題管理・変更管理を3点セットで運用します。インシデント管理はサービスを早く元に戻すこと、問題管理は原因を突き止めて再発を防ぐこと、変更管理はその対策を安全に本番へ入れることが役割です。筆者はCiscoやJuniper NetworksのNOC/TACで長く障害対応に携わってきましたが、現場で効いていたのは、目立つ大障害の対応力よりも、既知のエラーDB（KEDB）と再発分析を地道に回す仕組みでした。
本稿は、その問題管理をAIエージェント向けに組み直した「ProblemOps」の実践ガイドです。インシデントのクラスタリング、KEDBとワークアラウンドの登録、問題チケットのライフサイクルと優先度づけ、恒久対策を変更管理（ChangeOps）へ渡す連携、そして再発率とエイジングによる運用の計測までを、順に整理します。対象読者は、AIエージェントを本番運用しているSRE・運用チーム、情報システム部門、AI導入の責任者の方です。
本稿の位置づけ
AgentOpsシリーズの既存記事と、本稿の役割分担は次のとおりです。
| 記事 | 扱う範囲 | 時間軸 |
|---|---|---|
| インシデント運用（9/5） | 1件ごとの検知・収束・ポストモーテム | 障害の最中〜直後 |
| AI-SOAR（9/22） | 自動復旧・自動封じ込めの技術レイヤー | 障害の最中（機械が対応） |
| 変更管理（ChangeOps）編（10/12） | 変更の区分・カレンダー・MOP・変更後検証 | 対策を本番に入れるとき |
| 本稿：問題管理（ProblemOps）編 | 複数インシデントを横断した傾向分析と根本原因の追跡 | 障害の後〜恒久対策が効くまで |
インシデント運用が「火を消す」工程、ChangeOpsが「直し方を安全に入れる」工程だとすると、本稿のProblemOpsはその間で「なぜ火事が起き続けるのかを調べ、直すべきものを決める」工程です。ChangeOps編と合わせて読むと、障害の発生から再発防止までの流れが1本につながります。また、AI-SOARが機械による自動復旧だったのに対し、本稿は人とチームが「同じ問題を二度起こさない」ための運用プロセスを扱います。
なぜエージェントでは”同じ障害”が見えにくいのか
従来のシステムでも問題管理は難しい仕事でしたが、LLMエージェントには再発を見えにくくする特有の事情があります。
1. 症状が毎回少しずつ違う
同じ根本原因（たとえば、ナレッジ検索で古い規程が上位に来る）でも、出力は毎回異なる文章になります。「誤った回答をした」「ツールを呼ばずに推測で答えた」「途中で手順を省略した」と、インシデント票に書かれる症状がばらばらになるため、件名や症状の文字列で検索しても同じ問題だと気づけません。
2. “たまに起きる”が許容されてしまう
非決定的なシステムでは、再実行すれば正常に終わることが少なくありません。現場では「リトライで解消」「再現せず」としてクローズされ、発生率が1〜2%のまま何か月も続くことがあります。1件ごとの影響は小さくても、件数を積み上げると、利用者の信頼やオペレーターの工数を確実に削っています。
3. 原因が複数の資産にまたがる
エージェントの挙動は、プロンプト、モデル、ツール、ナレッジ、ガードレールの組み合わせで決まります。原因が1つの資産に収まらないことが多く、各担当チームが「うちの資産は正しく動いている」と考えると、問題は誰のものにもなりません。根本原因に”オーナー”をつけることが、ProblemOpsの出発点です。
まず定義——インシデント・問題・既知のエラーを分ける
ProblemOpsを回すには、まず言葉をそろえます。ITILの定義をエージェント運用に当てはめると、次のようになります。
| 用語 | 意味 | エージェントでの例 | ゴール |
|---|---|---|---|
| インシデント | サービスの計画外の中断や品質低下 | 経費精算エージェントが誤った上限額を案内した | 早くサービスを元に戻す |
| 問題（Problem） | 1件以上のインシデントの原因、または潜在的な原因 | 規程改定後もナレッジに旧版が残り、検索で上位に来る | 原因を特定し、取り除く |
| 既知のエラー（Known Error） | 分析は済んだが、まだ解決していない問題 | 原因は特定済みで、ナレッジ再構築は来週の変更枠で実施予定 | 回避策を周知し、恒久対策までの被害を抑える |
| ワークアラウンド | 根本原因を取り除かずに影響を減らす手段 | 旧版文書を検索対象から一時除外し、該当質問は有人窓口へ回す | 一次対応を速く、均一にする |
重要なのは、インシデントのクローズと問題のクローズを別物として扱うことです。インシデントはワークアラウンドで閉じてかまいませんが、問題は根本原因が取り除かれ、再発していないことを確認するまで閉じません。
規律1：インシデントをクラスタリングし、再発傾向を見つける
問題管理には、起きたインシデントから問題を見つける「リアクティブ」と、まだ大きな障害になっていない兆候から問題を見つける「プロアクティブ」の2つの入口があります。どちらも、インシデントを束ねて見る仕組みが前提になります。
問題を起票するトリガーを決める
「気づいた人が起票する」だけでは、問題チケットはほとんど作られません。次のような機械的なトリガーを決めておきます。
- 同じクラスタに属するインシデントが、30日以内に3件以上発生した
- 重大度の高いインシデント（Sev1/Sev2）が発生した（1件でも問題として起票）
- ポストモーテムで「根本原因は未確定」または「暫定対処のみ」とされた
- 「再現せず」「リトライで解消」でクローズされたインシデントが、同じエージェントで一定数を超えた
- 評価パイプラインや本番モニタリングで、特定の失敗パターンの比率が上昇傾向にある（プロアクティブ）
クラスタリングの軸
症状の文章だけで束ねると、前述のとおり取りこぼしが出ます。エージェントのインシデントは、複数の軸を組み合わせて束ねるのが実践的です。
| 軸 | 具体例 | 取得元 |
|---|---|---|
| 失敗の型 | 幻覚・ツール誤選択・ツール引数誤り・ループ・拒否過多・ガードレール誤検知 | インシデント票の分類、評価器のラベル |
| 関与した資産と版 | プロンプト版、モデル版、ツール版、ナレッジのインデックス版 | トレース、変更台帳（ChangeOps） |
| 経路 | どのツールを、どの順番で呼んだか | エージェントのトレース |
| 入力の特徴 | 質問のカテゴリ、言語、長さ、添付の有無 | リクエストログ（個人情報はマスク） |
| 時間的な相関 | 特定の変更直後、月末、外部APIの遅延時など | 変更カレンダー、外部ステータス |
実装の考え方
インシデント票の要約・症状・トレースの抜粋を埋め込みベクトルにして類似度でクラスタを作り、そこに上の構造化された軸（資産の版、失敗の型）を掛け合わせると、精度の高い束ね方ができます。LLMに「この10件に共通する原因仮説を3つ挙げて」と要約させるのも、分析の初動としては有効です。
ただし、クラスタリングはあくまで“問題の候補”を出すための道具です。最終的に「これは同じ問題だ」と判断し、問題チケットとして起票するのは、問題マネージャー（後述）の役割にしておきます。機械が自動で問題を量産すると、誰も見ないチケットが積み上がるだけになるためです。
規律2：既知のエラーDB（KEDB）とワークアラウンドを登録する
NOC/TACの現場で最も費用対効果が高かった仕組みが、既知のエラーDB（KEDB）です。原因は分かっているがまだ直っていない問題を一覧にし、一次対応者が「これは既知の問題で、回避策はこれ」とすぐに判断できるようにします。エージェント運用では、KEDBを人が読むだけでなく、監視やトリアージの仕組みからも参照できる形にしておくと効果が大きくなります。
KEDBエントリの構成
| 項目 | 内容 |
|---|---|
| ID・タイトル | KE-2026-0142「規程改定後、旧版の経費規程が検索上位に残る」など、症状でなく原因で書く |
| 症状のシグネチャ | どんな出力・トレース・メトリクスになったら該当するか（検知ルールに転用できる粒度で） |
| 影響範囲 | 対象のエージェント、ユースケース、利用者層 |
| 根本原因 | 分かっている範囲で。未確定なら「仮説」と明記 |
| ワークアラウンド | 具体的な手順、実施権限、所要時間、副作用 |
| 関連インシデント | 紐づくインシデントのIDと件数（自動で増える形が望ましい） |
| 恒久対策の状況 | 対応する変更要求（RFC）のID、予定日、担当 |
| 有効期限・見直し日 | ワークアラウンドを続けてよい期限 |
ワークアラウンドの品質を管理する
ワークアラウンドは便利な反面、恒久対策を先延ばしにする言い訳にもなります。次の3点を必ず確認します。
- 副作用が明記されているか：たとえば「該当カテゴリの質問を有人窓口へ回す」は、窓口の負荷を増やします。
- 誰でも同じ手順で実施できるか：特定の担当者の経験に頼る回避策は、夜間や休日に機能しません。
- 期限があるか：期限を過ぎたワークアラウンドは、問題チケットの優先度を自動で引き上げます。
一次対応とガードレールに組み込む
KEDBの症状シグネチャは、そのまま監視ルールやトリアージの自動判定に流用できます。新しいインシデントがシグネチャに一致したら、自動でKEDBエントリと紐づけ、オンコール担当に回避策を提示します。こうすると、一次対応の時間が短くなるだけでなく、関連インシデントの件数が自動で積み上がり、問題の深刻さが数字で見えるようになります。
一方で、AI-SOARのような自動復旧の仕組みに回避策を組み込む場合は、「自動回避が成功した件数」もインシデントとして記録し続けることが大切です。自動で直っているから見えなくなる、という状態は、問題管理にとって最も危険な状態の1つです。
規律3：問題チケットのライフサイクルと優先度づけ
ライフサイクル
問題チケットは、インシデントとは別のワークフローで管理します。ITILの「問題の識別→問題のコントロール→エラーのコントロール」をもとに、次のような状態遷移にしておくと運用しやすくなります。
| 状態 | やること | 次へ進む条件 |
|---|---|---|
| 起票（New） | トリガーやクラスタから問題を登録し、関連インシデントを紐づける | 問題マネージャーが受理し、オーナーを割り当てた |
| 調査中（Investigating） | 根本原因分析、再現テスト、影響範囲の見積もり | 原因が特定された、または仮説で回避策が決まった |
| 既知のエラー（Known Error） | KEDBに登録し、ワークアラウンドを周知 | 恒久対策の方針が決まった |
| 対策待ち（Fix Pending） | 変更要求（RFC）をChangeOpsへ提出 | 変更が本番に適用された |
| 解決確認（Verifying） | 一定期間、再発がないことを監視 | 観察期間中に再発がない |
| クローズ（Closed） | KEDBエントリを廃止し、学びを記録 | — |
「調査したが原因が特定できない」「対策の費用が見合わない」という結論もあり得ます。その場合は、リスクとして受容する判断を、誰が、いつ、どの根拠でしたかを記録したうえでクローズします。理由を残さずに放置されたチケットとは区別することが大切です。
優先度づけ
問題チケットは、インシデントの重大度とは別の基準で優先度をつけます。おすすめは、次の要素を掛け合わせた簡易スコアです。
- 発生頻度：直近30日の関連インシデント数（自動回避分も含む）
- 影響の大きさ：誤回答の業務影響、顧客接点か社内か、金銭・法令・安全に関わるか
- 対応コスト：ワークアラウンドにかかっている人手や、有人窓口への転送件数
- 傾向：増加傾向か、横ばいか、減少傾向か
- エイジング：起票からの経過日数、ワークアラウンドの期限切れ
数式を厳密に決めるより、「毎週の問題レビューで、上位5件だけは必ず議論する」という運用ルールにしたほうが機能します。スコアは議論の順番を決めるための道具だと割り切ります。
非決定的な障害の根本原因分析
エージェントの根本原因分析では、「なぜなぜ分析」だけで1つの原因にたどり着こうとすると、無理な結論になりがちです。次のような進め方が実践的です。
- 再現を確率で扱う：同じ入力を50〜100回実行し、失敗率として再現性を測ります。「再現しない」ではなく「失敗率2%」と表現します。
- 差分で切り分ける：プロンプト・モデル・ナレッジ・ツールの版を1つずつ入れ替え、失敗率がどう変わるかを見ます。ChangeOpsの変更台帳がここで効きます。
- 寄与要因を複数残す：「直接の原因」と「発生を許した要因（評価セットにケースがなかった、監視に検知ルールがなかったなど）」を分けて記録します。
- 失敗事例を評価セットに入れる：再現用の入力は、そのまま回帰テストの評価ケースになります。
規律4：恒久対策を変更管理（ChangeOps）へ渡す
問題管理のゴールは、原因を特定することではなく、原因を取り除く変更が本番に入り、再発が止まることです。ここでChangeOps編（10/12）とつながります。
ハンドオフで渡す情報
問題チケットから変更要求（RFC）を起こすときは、次の情報を必ず添えます。ChangeOps側がリスクを評価し、変更後検証の基準を決めるための材料になります。
| 渡す情報 | ChangeOps側での使い道 |
|---|---|
| 問題IDと関連インシデント数 | 変更の緊急度・優先度の判断 |
| 根本原因と変更対象の資産 | 変更区分（標準・通常・緊急）の判定、衝突検知 |
| 再現用の入力と現在の失敗率 | 変更後検証の合格基準（例：失敗率2%→0.2%以下） |
| ワークアラウンドの解除手順 | MOPの最終ステップに組み込む |
| 想定される副作用 | ロールバック条件の設定 |
“直したはず”で閉じない
変更が本番に入った時点で問題をクローズしてしまうのは、よくある失敗です。変更後は「解決確認」の状態に置き、観察期間（たとえば2〜4週間、または関連インシデントが従来なら3件起きていたはずの期間）を設けます。その間にKEDBのシグネチャに一致するインシデントが起きなければクローズし、起きたら問題を再オープンします。
逆方向の連携も重要です。ChangeOpsで「変更起因の障害」が発生した場合、それは変更プロセス側の問題として、問題チケットに起票します。変更管理と問題管理は、お互いの品質を監視し合う関係です。
規律5：再発率と問題のエイジングで運用を測る
インシデント運用のKPIが「どれだけ早く直したか（MTTRなど）」中心なのに対し、ProblemOpsでは「どれだけ同じことが起きなくなったか」を測ります。
| KPI | 定義 | 見方 |
|---|---|---|
| 再発率 | 既存の問題・KEDBに紐づくインシデント数 ÷ 全インシデント数 | 高止まりしているなら、恒久対策が進んでいない |
| 既知問題による一次解決率 | KEDBのワークアラウンドで解決したインシデントの割合 | KEDBが使われているかの指標。高すぎる場合は恒久対策の遅れも疑う |
| 未解決問題のエイジング | オープン中の問題の経過日数の分布（30日・90日・180日超） | 長期滞留の問題を毎月レビューに上げる |
| 問題の解決リードタイム | 起票からクローズまでの日数（中央値） | 調査・変更のどこで詰まっているかを工程別に分解する |
| 再オープン率 | 解決確認後に再発し、再オープンした問題の割合 | 根本原因分析や変更後検証の質の指標 |
| 期限切れワークアラウンド数 | 有効期限を過ぎて運用されている回避策の数 | “回避策が恒久化している”状態の早期警告 |
特に再発率と未解決問題のエイジングは、経営層やサービスオーナーへの報告に向いています。「火消しは速いのに、火事が減らない」状態は、MTTRだけを見ていると良い数字に見えてしまうため、この2つを並べて示すことが重要です。
運用サイクル——いつ、何を見るか
| 頻度 | 場 | やること |
|---|---|---|
| 毎日 | オンコール引き継ぎ | 新規インシデントのKEDB自動紐づけを確認し、未分類のものを分類する |
| 毎週 | 問題レビュー（30分） | クラスタから問題候補を起票、優先度上位5件の進捗確認、オーナーの割り当て |
| 毎週 | 変更諮問（CAB）との連携 | 問題由来のRFCを確認し、変更カレンダーに載せる |
| 毎月 | サービスレビュー | 再発率・エイジング・再オープン率の報告、リスク受容の判断 |
| 四半期 | プロアクティブ分析 | 評価結果や利用傾向から、まだ障害になっていない問題を洗い出す |
小さなチームであれば、毎週の問題レビューをインシデントの振り返り会の後半15分に組み込むだけでも十分に効果があります。大切なのは、問題を見る時間が”空いたら見る”ではなく、予定として確保されていることです。
よくある落とし穴
- ポストモーテムを書いて満足する：1件ごとの振り返りは丁寧でも、アクションアイテムが追跡されず、横断的な傾向も見ていない状態です。
- 「再現せず」でクローズする：非決定的なシステムでは、再現しないことは原因がないことを意味しません。失敗率で測り直します。
- ワークアラウンドが恒久対策になる：有人窓口への転送や、特定の質問の拒否が、いつの間にか「仕様」になっているケースです。期限を必ず設けます。
- 問題に”オーナー”がいない：プロンプト、モデル、ナレッジの担当が分かれていると、原因が境界にある問題は誰も引き取りません。問題マネージャーが明示的にオーナーを指名します。
- 自動復旧で問題が見えなくなる：AI-SOARなどで自動回避できたインシデントを記録しないと、再発率が実態より低く見えます。
- 問題チケットを機械で量産する：クラスタリングの結果をそのまま起票すると、誰も読まないチケットが積み上がり、本当に重要な問題が埋もれます。
ProblemOps チェックリスト
| 領域 | 確認項目 |
|---|---|
| 定義・体制 | インシデント／問題／既知のエラーの定義がチームで共有されている。問題マネージャーの役割が決まっている |
| 識別 | 問題を起票するトリガー（件数・重大度・「再現せず」の扱い）が明文化されている |
| 分析 | インシデントを失敗の型・資産の版・経路で束ねられる。再現を失敗率で測っている |
| KEDB | 症状シグネチャ・ワークアラウンド・副作用・期限を備えたエントリになっている。一次対応から参照できる |
| ライフサイクル | 問題チケットがインシデントとは別のワークフローで管理され、リスク受容の判断が記録されている |
| 優先度 | 頻度・影響・対応コスト・傾向・エイジングで、毎週の上位問題が決まる |
| ChangeOps連携 | RFCに再現入力・失敗率・ワークアラウンド解除手順が添付され、変更後に解決確認期間がある |
| 計測 | 再発率、未解決問題のエイジング、再オープン率、期限切れワークアラウンド数を定期報告している |
よくある質問（Q&A）
Q1. 小規模なチームでも、問題管理を別に運用する必要がありますか？
専任の問題マネージャーや専用ツールまでは不要です。ただし、「インシデントのクローズと問題のクローズを分ける」「既知の問題を1か所に一覧化する」「週に1回、再発しているものを確認する」の3点だけは、規模にかかわらず効果があります。スプレッドシート1枚のKEDBから始めても十分です。
Q2. ポストモーテムとの違いは何ですか？
ポストモーテムは1件のインシデントを深く振り返るもので、本稿の問題管理は複数のインシデントを横断して共通原因を追うものです。ポストモーテムで「根本原因は未確定」となったものや、「同様の事象が過去にもあった」と書かれたものを問題として起票する、という形でつなげると、両者が補い合います。
Q3. LLMの出力はもともと揺らぐものです。どこからを”問題”として扱えばよいですか？
揺らぎそのものではなく、業務上許容できない結果が一定の頻度で起きているかで判断します。事前にユースケースごとに許容できる失敗率（たとえば、社内FAQなら数%、金額や契約に関わる案内ならほぼゼロ）を決めておき、それを超えたら問題として扱います。SLOの考え方と同じです。
Q4. AI-SOARで自動復旧できているなら、問題管理は不要ではありませんか？
自動復旧は被害を抑える仕組みであり、原因を取り除く仕組みではありません。自動復旧が頻繁に動いているということは、それだけ根本原因が残っているということです。自動回避の発動回数をKEDBに紐づけて数え、問題の優先度の材料にすることをおすすめします。
Q5. 再発率は、どのくらいを目標にすればよいですか？
一律の目標値はなく、まずは現状を測ることから始めます。多くの場合、最初に測ると想定より高い数字が出ます。最初の数か月は「再発率が下がり続けているか」「90日を超えて滞留している問題が減っているか」という傾向を目標にし、安定してきたらサービスごとに目標値を決めるのが現実的です。
まとめ——”火消しの速さ”ではなく”火事の減り方”で運用を評価する
非決定的なエージェントの障害は、1件ずつ見ると小さく、毎回少しずつ違って見えます。だからこそ、個々のインシデントの先にある根本原因を、誰かが責任を持って追い続ける仕組みが必要です。
- インシデントと問題を分ける：インシデントは回避策で閉じてよく、問題は再発が止まるまで閉じない。
- 既知のエラーを資産にする：KEDBとワークアラウンドを整備し、一次対応と監視から参照できるようにする。
- 恒久対策を変更管理につなぐ：再現入力と失敗率を添えてChangeOpsへ渡し、解決確認期間を経てからクローズする。
インシデント運用で火を早く消し、ProblemOpsで火事の原因を突き止め、ChangeOpsで安全に直す。この3つがそろって初めて、「同じ障害を、毎回はじめて対応する」状態から抜け出せます。運用チームの成熟度は、MTTRの短さだけでなく、同じ問題を二度起こさない仕組みがあるかどうかで決まります。
関連記事
- 【AgentOps・変更管理（ChangeOps）編】”誰が、いつ、何を変えたか”がわからない本番をなくす
- 【AgentOps・エスカレーション運用（HumanOps）編】”人間に回せば安全”で終わらせない
- 【AgentOps・インシデント運用編】障害発生時の対応と振り返り（URL差し替え）
- AI-SOAR編（URL差し替え）
コメント