AIエージェントのミスを繰り返さないために: Incident Log、Root Cause、Checklist、Evalループ

1. 概要: 繰り返すミスはシステム問題

AIエージェントはファイル、ツール、ウェブサイト、メール、CRM、社内知識に接続され始めています。便利になる一方で、ミスの意味も変わります。チャット内の誤答は不便で済むかもしれません。しかし業務フロー内の誤答は、顧客、公開、費用、データ、コンプライアンスの問題になります。

実務の問いは、AIを絶対にミスさせないことではありません。ミスのあとで組織が賢くなるかです。「次から気をつけよう」で終わると、同じ失敗は形を変えて戻ってきます。

ブログ公開の例は分かりやすいです。ローカルにファイルがあり、プレビューでき、コミットまであっても、読者が見られなければ公開は終わっていません。完了基準は、リモートへpushされ、実際の各言語URLが開き、画像とsitemapまで確認されることです。この最後の基準がChecklistにないと、エージェントは多くの作業をしても公開面を変えないまま終わることがあります。

2. やさしい用語: Incident Log、Root Cause、Checklist、Eval、Trace、SOP

Incident Logは業務上の事故記録です。サーバー障害だけではありません。AIが古いポリシーを使った、間違った下書きを作った、ライブ確認を飛ばした、同じ前提を繰り返したなら、記録対象です。

Root Cause、またはRCAは根本原因分析です。人を責める文書ではありません。「誰かが忘れた」よりも「完了基準にライブ確認がなかった」のほうが良い原因です。修正できるからです。

Checklistは記憶力の代わりに漏れを防ぐ実行表です。SOPはStandard Operating Procedureの略で、繰り返す仕事を処理する標準手順です。EvalはAIが重要な例を正しく処理するかを見るテストセットです。TraceやLogは、エージェントが何を読み、どのツールを使い、どんな判断をしたかを残す実行記録です。

• Incident Log: 何が、いつ、どこで間違ったかを残す業務記録。
• Root Cause: 同じミスを可能にしたシステム条件。
• Checklist: 完了前に必ず確認する最小ゲート。
• Eval: 望む行動が繰り返されるかを確認するテストセット。
• TraceまたはLog: エージェント実行の根拠と経路の記録。
• SOPまたはRunbook: 次に同じ状況で従う手順。

3. 繰り返しミスを止めるループ

ループは六つで十分です。業務を実行する。インシデントを記録する。Root Causeを探す。ChecklistまたはSOPを直す。Evalケースを追加する。次の実行で重要な表面を確認する。ブログならライブURLとsitemapです。サポートならチケット状態と顧客向け下書きです。財務なら承認済み台帳や請求書かもしれません。

OpenAIとAnthropicがEvalを重視する理由もここにあります。信頼できるAI業務には、テスト可能な行動が必要です。Google SREとAtlassianのポストモーテム文化は、そこに運用の教訓を加えます。失敗を個人の注意力ではなく、再発防止作業へ変える必要があります。

そのためAIの記憶だけでは足りません。記憶はエージェントに思い出させます。Checklistは完了を止めます。Evalは再発を捕まえます。Traceはなぜずれたかを見せます。それぞれ役割が違うため、実運用には複数の層が必要です。

• Run: 入力と出力が見える状態で業務を実行します。
• Record: ミスを構造化されたIncident Logに残します。
• Analyze: 人を責めずRoot Causeを書きます。
• Change: Checklist、SOP、プロンプト、権限、情報源ルールを直します。
• Test: 同じ失敗を捕まえるEvalまたは回帰テストを追加します。
• Verify: 実際の外部結果を確認して閉じます。

4. Incident Logに何を書くか

記録は派手である必要はありません。むしろ退屈で正確なほうがよいです。Notion、Google Sheets、GitHub、Obsidianの表一つでも十分です。大事なのは毎回同じフィールドを使うことです。

未来のレビュー担当者が長い会話を読み直さなくても理解できる必要があります。期待した結果、実際の結果、関係したツールやURLや情報源、抜けていた完了シグナル、追加された予防策を書きます。

• 日付と業務: いつ、どの業務で起きたか。
• 期待結果と実際結果: 最短の前後説明。
• 検知シグナル: 何を見て問題に気づいたか。
• 影響: 顧客露出、内部問題、費用、データ、ブランド、法的リスク。
• 証拠: URL、ログ、スクリーンショット、ツール出力、コミット、チケット。
• Root Cause: ミスを可能にした運用条件。
• 予防策: Checklist、SOP、Eval、Guardrail、担当者、権限変更。
• クローズ証拠: ライブURL、テスト結果、デプロイ、承認など実際の完了証拠。

5. Root Causeは非難ではなく設計

Blameless、つまり非難しない分析は、責任を曖昧にすることではありません。繰り返せる条件を探すことです。「エージェントがpushを忘れた」は弱い原因です。「完了定義がローカル確認で止まり、リモートpushとライブ確認を要求していなかった」は良い原因です。すぐChecklistに変えられるからです。

良いRoot Causeは、いくつかの分類に集まります。Source of Truthが不明確だった。担当者がいなかった。知識が古かった。権限境界が弱かった。外部検証がなかった。承認ルールが曖昧だった。Evalケースがなかった。Traceが残っていなかった。

ここで人もAIと一緒に成長する必要があります。人は単なる承認者ではなく、ワークフロー設計者になります。どのシグナルならもっと早く捕まえられたか、どのゲートが抜けていたか、次回エージェントが何を完了と呼べないようにするかを問う力が重要になります。

6. Checklistは意図ではなく完了基準を定義する

Checklistに「ブログ公開」とだけ書くのは弱すぎます。各言語の投稿データ追加、画像追加、型チェック、lint、build、各言語の詳細ページ確認、一覧ページ確認、sitemap確認、commit、push、ライブURL確認まで分ける必要があります。最後の10パーセントを見えるようにすることが核心です。

他の業務でも同じです。営業要約はCRMレコードに添付されて初めて完了です。サポート下書きは人間が承認するまで完了ではありません。データ整理は下流レポートが期待通り変わって初めて完了です。

強いChecklistには外部証拠があります。「ファイルを編集した」より「ライブページが200を返し、新しいslugを含む」のほうが強いです。「下書きを生成した」より「レビュー担当者が承認し、顧客自動送信はまだブロックされている」のほうが強いです。

7. Evalはインシデントを反復テストに変える

Evalは技術用語に見えますが、意味は単純です。エージェントが必ず正しく扱うべき例のセットを作ることです。古い知識を信じて失敗したなら、古い情報源と最新情報源が同時にある例を入れます。ライブ確認を飛ばしたなら、ローカル成功だけでは通過できない例を入れます。

最初から巨大なベンチマークは不要です。会社が実際に痛みを感じた失敗10件で十分です。期待回答、禁止行動、必要な引用、必要な承認、完了証拠を一緒に書きます。そしてプロンプト、モデル、ツール、情報源、Checklistが変わるたびに実行します。

コミュニティでも同じシグナルが繰り返されています。一般的なLLM判定者は、会社が本当に重視するドメイン固有の失敗を見逃すことがあります。だから良いEvalケースは、実際のインシデント、顧客修正、レビュー担当者の修正、near missから生まれます。

8. Guildex式Incident Learning Table

小さなチームに最も役立つ成果物は、インシデントと予防策をつなぐ一枚の表です。目的は官僚制ではありません。組織が学んだことをシステムに記憶させることです。

例えばこういう行です。Incidentは「投稿はローカルにあるがライブにはない」。Signalは「ライブブログの最新記事が前の日付で止まっている」。Root Causeは「完了基準にpushとlive sitemap確認がない」。Preventionは「Checklistにcommit、push、live URL、image、sitemap確認を追加」。Closeout Proofは「ライブURLの200確認」です。

• Incident: 何が間違ったかを一文で書きます。
• Signal: どう検知したかを書きます。
• Root Cause: 抜けていたシステム条件を書きます。
• Prevention: どのChecklist、SOP、Eval、権限、情報源ルールが変わったかを書きます。
• Owner: その予防策を誰が維持するかを書きます。
• Verification URLまたはOutput: 実際に閉じたことを示す外部証拠を書きます。

9. 結論: AI導入はミスを知識に変えると複利で良くなる

AIをうまく使う会社は、ミスがまったくない会社ではありません。ミスをより良い運用知識に変える会社です。すべてのインシデントは、システムをよりだまされにくくし、レビューしやすくし、「完了」の意味を明確にするべきです。

AIが進化するほど、人も一緒に進化する必要があります。人の役割は「この出力を早く確認する」から、「次の出力をより安全にするループを設計する」へ変わります。より良いIncident Log、より良いRoot Cause思考、より良いChecklist、より良いEval、より良いライブ検証を作る力が必要です。AIの速度は、人間の運用システムも同時に学ぶときに初めて価値になります。