AIの失敗ログを捨てない：次の自動化を強くする振り返りノート術

AIに記事やコードを作らせたとき、失敗を直して終わりにしていませんか。

失敗ログの目的は、会話やエラーを大量に保存することではありません。次回の依頼、検品、テストに使える証拠だけを残すことです。成功した成果物が「完成した料理」なら、失敗ログは「どの火加減で焦げたかを残す調理メモ」です。

生成AIは、同じ入力でも出力が変わる場合があります。OpenAI公式も、生成AIでは早い段階からタスクごとの評価を作り、開発中のログを保存し、継続して評価することを勧めています（Evaluation best practices）。だからこそ、実際に起きた失敗は次回のテストケースとして役立ちます。

この記事では、初心者でも使える一つのMarkdownファイルから始めます。失敗の事実と原因の仮説を分けます。再現に必要な証拠を安全に残します。最後に、曖昧な注意書きを測定できる合格条件へ変えます。

まず「起きた事実」と「原因の仮説」を分ける

失敗を見つけた直後は、症状と原因を混ぜないことが大切です。

症状は、目で確認できた問題です。「記事が1000字しかなかった」「指定外のファイルが変わった」「テストが終了コード1で止まった」などが当てはまります。

原因は、その問題が起きた理由です。ただし、最初に思いついた理由が正しいとは限りません。AIへ「なぜ失敗したの」と聞くと、筋の通った説明が返ることがあります。しかし、その説明だけでは確認済みの原因になりません。

次の5段階に分けると、推測を事実として固定しにくくなります。

区分	文字数不足の例	扱い方
期待した状態	本文が1500字以上になる	依頼文や仕様から引用する
観測した症状	本文が1120字だった	計測結果を残す
証拠	計測コマンドの出力が1120だった	コマンド、対象、日時を残す
原因の仮説	完了前の計測が手順になかった	まだ断定しない
確認済みの原因	作業手順と報告の両方に計測がなかった	差分や設定で裏づける

たとえば、文字数不足の直接原因は「AIが短く書いたこと」に見えます。しかし、上流には別の原因があるかもしれません。

• 最低文字数を依頼に書いていなかった
• frontmatterを数えるかどうかが曖昧だった
• 書いたが、完成前に計測しなかった
• 計測したが、基準未達でも処理を止めなかった
• 修正後に古いファイルを納品した

原因を深く見る目的は、AIや担当者を責めることではありません。Google SREのポストモーテム（障害後の振り返り）も、個人への非難ではなく、寄与した条件と仕組みに目を向ける考え方を示しています（Postmortem Culture: Learning from Failure）。

原因が分からないときは、無理に埋めなくて構いません。「原因は未解決」「仮説Aは未検証」と書きます。症状、終了コード、差分、環境、再現手順が残っていれば、後から証拠が増えたときに更新できます。

反対に、「AIの能力不足だった」「指示を理解しなかった」だけでは、次回の改善場所が分かりません。「完了条件に文字数の数え方がなく、基準未達を止める処理もなかった」と書けば、依頼文と検品手順の両方を直せます。

失敗直後に7項目だけ記録する

最初から正式な障害報告書を作る必要はありません。個人のAI作業では、Google SREの考え方を小さくして使えば十分です。

失敗直後は、次の順で7項目を埋めます。

1. 日時と対象を書く
2. 何をしようとしたかを書く
3. 期待した状態を書く
4. 実際に起きた症状を書く
5. 観測できた証拠を貼る
6. 対応と、その結果を書く
7. 次回の予防策を書く

Markdownの最小テンプレートは次の形です。

---
date: 2026-07-27
status: monitoring
category: validation
---

## 失敗ログ：記事の文字数不足

### 対象と目的
article.mdに、本文1500字以上の記事を作る。

### 期待した状態
frontmatterと空白を除いた本文が1500字以上になる。

### 症状
完成ファイルが基準より短かった。

### 確認できた証拠
文字数の計測結果は1120だった。
対象ファイルと計測コマンドは下に記録した。

### 原因
確認済み：完了手順に文字数計測がなかった。
仮説：見出しごとの内容量も指定不足だった。
未解決：別の指示が長さを抑えたかは未確認。

### 対応と結果
不足した説明を追加した。
同じ方法で再計測し、基準を満たした。

### 次回の予防策
依頼テンプレートへ数え方と合格値を追加する。
基準未達なら処理を止める。

statusは、まだ原因も対応も決まっていなければopenにします。修正したが次の実行で確かめていなければmonitoringにします。修正後の確認まで終えたらresolvedにします。

大切なのは、修正しただけでresolvedにしないことです。たとえばプロンプトへ注意を1行足しても、次の実行で同じ失敗が起きるかもしれません。修正と効果確認を分けると、対策を実施した事実と、対策が役立った可能性を混同しにくくなります。

期待した状態も具体的にします。「十分に長い記事」では合否を決められません。「frontmatterと空白を除く本文が1500字以上」のように、対象、測り方、合格値を書きます。

Claude Platformの公式文書は、成功基準を具体的で、測定でき、達成可能で、目的に関係する形にするよう案内しています。また、実際のタスクと例外ケースを評価へ含めることも勧めています（Define success criteria and build evaluations）。振り返りノートでも、この考え方をそのまま使えます。

コマンドと出力をセットで残し、秘密は先に伏せる

「確認した」とだけ書いても、後から同じ確認はできません。実行したコマンドと出力をセットで残します。

最低限あるとよい証拠は、次のとおりです。

• 対象ファイルや対象処理の名前
• 実行したコマンド
• 終了コード
• 最初に失敗した箇所
• エラーメッセージ
• 関係する差分
• OSやツールの版など、再現に必要な環境
• 修正後に同じ確認をした結果

PowerShellでMarkdownファイルのおおよその文字数を見る例です。

$text = Get-Content -Raw -Encoding utf8 .\article.md
$text.Length

禁止語が含まれていないかを見る例です。

Select-String -Path .\article.md -Pattern "禁止したい言葉"

変更箇所を見る例です。

git diff -- .\article.md

直前のコマンドが成功したかを見る例です。

$LASTEXITCODE

終了コードは、処理が成功したか失敗したかを示す数字です。一般には0が成功として使われますが、意味はツールごとに確認します。コードだけで判断せず、出力内容も一緒に見ます。

GitHub Actionsを使っている場合は、ジョブ（処理のまとまり）ごとの実行ログから失敗したステップを探せます。公式文書では、ログの表示、検索、ダウンロード、各ステップの所要時間確認、特定行へのリンク共有が案内されています（Using workflow run logs）。

ただし、一部のジョブだけを再実行した場合、その再実行のアーカイブには再実行したジョブしか入らないことがあります。失敗の全体像が必要なら、再実行前の試行も確認します。

ログを保存する前に、秘密を取り除きます。

• パスワード
• APIキー
• 認証コード
• アクセストークン
• 個人の住所や電話番号
• 決済情報
• 公開できない顧客データ

値を振り返りノートへコピーしてはいけません。「認証情報を伏せた」とだけ書きます。すでに秘密が出力された場合は、記事や共有ノートへ転記しません。失効や再発行が必要かどうかは、利用中のサービスの公式手順で別に判断します。

GitHub Actionsには、Secret以外の機密情報をadd-maskで伏せる仕組みがあります。しかし、これはGitHub Actions固有の機能です。ほかのAIチャットやローカルログまで自動で守られるわけではありません。GitHub公式も、自動で伏せられない情報があり得ることや、可能なら秘密をコマンドラインで渡さないことを案内しています（Using secrets in GitHub Actions）。

保存先の閲覧権限と保持期間も決めます。全チャットや全エラーを永久保存する必要はありません。再現に必要な最小限へ絞ります。組織で運用する場合は、誰が読めるか、いつ消すか、どこへ保管するかもルールにします。

記録する失敗を選び、注意書きから自動検品へ変える

すべての小さな失敗を記録すると、ログ整理そのものが新しい仕事になります。先に「どの失敗を残すか」を決めます。

優先して残したいのは、次の失敗です。

1. 同じ作業で再発しそうな失敗
2. 人の手戻りが大きかった失敗
3. 公開、費用、個人情報、データへ影響した失敗
4. 人が途中で止めなければ進んでいた失敗
5. テストや監視で検出できなかった失敗
6. 原因は不明でも、再現に使える証拠がある失敗

重大な失敗は、1件でもすぐ見直します。データ消失、誤公開、予期しない費用、秘密の出力などは、件数が増えるのを待ちません。

軽い失敗は、自分で決めた件数や手戻り時間を目安にします。この記事では、初心者が定例会を増やさず始めるために「同じ分類が3件たまったら見直す」を開始目安にします。これはOpenAI、Claude Platform、Google、GitHub、NISTが定めた共通の基準ではありません。自分の作業量に合わせて変えてください。

Google SREも、振り返りを始める条件を事前に決める考え方を示しています。例には、利用者への影響、データ損失、担当者の手動介入、長い復旧時間、監視の失敗があります。ただし、これは大規模なサービス運用の知見です。個人のAI作業では、正式な報告書を全失敗へ求めず、項目と考え方だけを軽くして使います。

ログを3件並べたら、次の順で見直します。

1. 同じ症状や分類が繰り返されているか確かめる
2. 次回も起きる条件が残っているか確かめる
3. 人の時間、費用、公開範囲、データへの影響を比べる
4. 小さな変更で検出できる失敗を選ぶ
5. 変更後の効果を測る方法を決める
6. 改善案を最大3件に絞る

再発防止には、強さの段階があります。

段階	対策	弱点と使いどころ
1	人が気をつける	忘れやすい。最初の応急処置
2	AIへの依頼文に注意を書く	曖昧だと合否を決められない
3	チェックリストで確認する	抜けを減らせるが、人の操作が残る
4	コマンドやテストで検出する	測れる条件に向く
5	不合格なら次へ進ませない	影響が大きい失敗に向く

すべてを一度に自動化する必要はありません。損失が大きいもの、繰り返すもの、機械で判定しやすいものから強くします。

たとえば「分かりやすい記事にする」は、そのままでは機械判定できません。次のように分けます。

• 必須見出しがあるか
• 本文が決めた文字数以上か
• frontmatterに許可した項目だけがあるか
• 禁止語が含まれないか
• 外部リンクが必要数あるか
• リンク先の内容が主張を支えているか
• 初心者が手順を再現できるか

前半の項目はコマンドで確認しやすいものです。後半は、人や別の検品役による確認が必要です。機械確認と人の判断は、どちらか一方に寄せず、得意な部分を分けます。

Markdown記事の必須項目をPowerShellで確認する例です。

$path = ".\article.md"
$body = Get-Content -Raw -Encoding utf8 $path
$checks = [ordered]@{
  "frontmatter" = $body.StartsWith("---")
  "下書き" = $body -match "draft:\s*true"
  "章立て" = $body -match "(?m)^## "
  "文字数" = $body.Length -ge 1500
}

$checks.GetEnumerator() | ForEach-Object {
  "{0}: {1}" -f $_.Key, $(if ($_.Value) { "PASS" } else { "FAIL" })
}

この例は入口です。実際には、frontmatterを文字数から除くなど、記事の合格条件と数え方をそろえます。テストの数字だけを達成しても、読者に分かりにくければ完成ではありません。

次に、実際の失敗を回帰テストへ加えます。回帰テストとは、直した問題が戻っていないかを確かめるテストです。

1. 失敗した入力や条件から、秘密を取り除く
2. 期待した結果を、測定できる形で書く
3. 失敗した例をテスト用データへ加える
4. 修正前にそのテストが失敗を検出するか確かめる
5. 修正後に同じテストが通るか確かめる
6. ほかの正常な例を壊していないか確かめる
7. 依頼文や仕組みを変えるたびに再実行する

OpenAI公式は、評価の流れを「目的の定義、データの収集、指標の定義、実行と比較、継続評価」として説明しています。新しく見つかった事例を評価セットへ増やし、変更ごとに評価する考え方も示しています。Claude Platform公式も、現実のタスクと例外ケースを反映し、文字列一致やコードによる採点など、可能な部分を自動化するよう案内しています。

対策の効果を確かめるときは、再発しなかったという1回の結果だけで断定しません。対策前後で、同じ定義のタスク数と再発件数を比べます。

たとえば、対策前の同種タスク10件で3件失敗し、対策後の10件で1件失敗したなら、改善の兆しはあります。ただし、入力の難しさや作業環境が違えば単純比較はできません。観測期間が短い場合は「暫定結果」と書きます。

NIST SP 800-92は、ログを集めるだけでなく、ログ管理の仕組みを開発し、実施し、維持する考え方を示しています（Guide to Computer Security Log Management）。これは2006年公開の組織向け文書です。個人のAIノートへ全要件を当てはめるものではありません。ただし、保存、確認、見直しまでを一つの運用として考える補助になります。

AIに複数の失敗ログを分析させる場合は、事実と推測を分けるよう先に頼みます。改善案を増やしすぎないことも大切です。

以下は、秘密と個人情報を除いた過去の失敗ログです。
事実として記録された内容と、原因の仮説を分けてください。

1. 再発回数が多い失敗
2. 人の手戻りが大きい失敗
3. 機械確認へ置き換えやすい失敗
4. 依頼テンプレートで防ぎやすい失敗

を表にしてください。
改善案は最大3件に絞ってください。
各案に、変更する場所、合格条件、確認方法を付けてください。

AIの提案は、そのまま原因や対策として確定しません。元のログと差分を見ます。小さく試します。測った結果を振り返りノートへ戻します。

よくある質問

AIとの会話はすべて保存したほうがよいですか？

すべてを保存する必要はありません。目的、期待した状態、症状、コマンド出力、差分、対応結果など、再現に必要な情報へ絞ります。

再発しそうな失敗や、手戻りの大きい失敗を優先します。秘密や個人情報は除きます。保存先の閲覧権限と保持期間も決めます。全会話を残すより、次回の判断に使える短い記録のほうが見直しやすくなります。

原因が分からないまま失敗ログを残してもよいですか？

残して構いません。観測できた症状と証拠は事実として書きます。原因候補は仮説と書きます。確認できない部分は未解決にします。

AIの説明だけで根本原因を決めないでください。実行ログ、終了コード、差分、環境、再現手順で裏づけます。後から証拠が増えたら更新します。

何件たまったら振り返ればよいですか？

全員に共通する公式の件数はありません。データ損失、誤公開、費用、秘密などへ関わる失敗は、1件でも見直します。

軽い失敗は、自分で決めた件数や手戻り時間を目安にします。この記事の「3件」は、初心者が始めやすくするための独自の目安です。作業量が少なければ2件でもよく、多ければ期間や手戻り時間で区切っても構いません。

再発防止はプロンプトへ注意を書くだけで十分ですか？

注意の追記は入口です。判定できる失敗は、具体的な合格条件、チェックリスト、コマンド、変更ごとのテストへ移します。

「丁寧に書く」ではなく、「必須見出しが5個ある」「指定外ファイルの差分が0件」のようにします。文章の分かりやすさや事実の妥当性など、機械だけで決めにくい項目は人の確認も併用します。

ログにAPIキーや個人情報が入っていたらどうしますか？

値を振り返りノートへ転記しません。共有や保存の前に削除またはマスクし、「機密情報を伏せた」と記録します。自動マスクを過信せず、公開範囲と閲覧権限も確認します。

すでに外部へ出た秘密の扱いは、利用中のサービスごとに異なります。失効や再発行が必要かどうかを、そのサービスの公式手順で確認してください。

公式一次情報

確認日: 2026-07-27

• Evaluation best practices｜OpenAI API: 生成AIの評価を早く始め、ログ保存、タスク固有の評価、自動採点、継続評価へつなぐ考え方が書かれています。
• Define success criteria and build evaluations｜Claude Platform Docs: 成功基準を具体的かつ測定可能にし、実際のタスクと例外ケースを評価へ含める方法が書かれています。
• Postmortem Culture: Learning from Failure｜Google SRE: 影響、対応、原因、再発防止を記録し、個人を責めずに仕組みを改善する考え方が書かれています。
• Using workflow run logs｜GitHub Docs: GitHub Actionsの失敗ステップを見つけ、ログを表示、検索、共有、ダウンロードする方法が書かれています。
• Using secrets in GitHub Actions｜GitHub Docs: ログ内の機密情報をマスクし、秘密を安全に扱うための注意が書かれています。
• Guide to Computer Security Log Management｜NIST: 組織のログ管理を開発、実施、維持するための高水準の指針が書かれています。

OpenAIとClaude Platformの評価方法や廃止案内は更新される場合があります。公開または更新の直前に、2026-07-27時点の案内から変わっていないか各公式ページで確認してください。

失敗例を自動検査へ戻す具体策はAIコーディングの回帰テスト手順、次の担当者へ事実と未解決点を渡す方法はAIコーディングの引き継ぎメモで確認できます。

まとめ

AIの失敗ログは、失敗を集めて落ち込むための保管庫ではありません。次の依頼、検品、自動テストへ使える証拠を残すためのノートです。

事実と原因の仮説を分けます。再現に必要なコマンドと出力を残します。秘密は先に除きます。影響の大きい失敗は1件でも見直し、軽い同種失敗は自分で決めた目安でまとめます。

注意書きを増やすだけで終わらせないことも大切です。測定できる合格条件を作り、実際の失敗例をテストへ加えます。変更後は同じ定義で結果を比べ、短い観測なら暫定結果として扱います。

まずは、次の3つだけ進めてください。

• 直近の失敗を1件選び、7項目テンプレートへ移す
• 原因を「確認済み」「仮説」「未解決」の3つに分ける
• 次回の完了条件を1つ選び、コマンドで判定できる形へ変える