「見出しは7つにする」「イベント情報には開催日と場所を入れる」「公開前に最新情報を確認する」。一度伝えたはずなのに、AIが次の作業で同じミスを繰り返すことがあります。
そのたびに注意文を足しても、指示は長くなる一方です。別のモデルへ替えても、しばらくすると似た不具合が戻ってくることがあります。
問題は、AIが反省していないことではありません。ミスが生まれる工程と、ミスを止める工程が変わっていないことです。
この記事では、製造業の品質改善で使われる「なぜなぜ分析」をAI運用へ応用し、同じミスを再発させにくくする方法を解説します。専門的な開発環境がなくても、まずはチェックリストから始められます。
結論｜注意ではなく3つの仕組みで止める
AIの同じミスを減らす基本は、次の3段階です。
- 指示と手順を整理し、ミスを作りにくくする
- 出力後に「関所」を置き、不合格なら次へ進ませない
- 実際に起きたミスを回帰テストとして残す
よい出力が出たかを人が毎回じっくり読むだけでは、件数が増えるほど見落としやすくなります。反対に、プロンプトを長くするだけでも不十分です。
作る工程と止める工程を分け、失敗を次回の検査項目へ変える。これが再発防止の中心です。
なぜ「一度教えたミス」がまた起きるのか
AIは会話の中で注意されたからといって、その内容をすべての次回作業へ確実に引き継ぐとは限りません。再発しやすい代表的な理由は、次のとおりです。
- 重要なルールがチャットの途中や複数ファイルへ分散している
- 同じ内容を別の言い方で書き、どれが最新版か分からない
- 「よく確認する」など、合否を判定できない表現になっている
- 出力を止める仕組みがなく、注意書きだけで通過できる
- 発生したミスを次回のテストへ追加していない
- 出力の形式と、内容の正しさを同じ検査で済ませている
長い指示なら安心とも限りません。研究では、長い入力の途中にある関連情報を、言語モデルが安定して使えない場合があると報告されています。指示を増やすほど、重要ルールが目立たなくなることもあります。
原因分析の前に不具合を1文で定義する
「AIの品質が悪い」では、原因を追えません。まず、観測できる事実へ言い換えます。
- 悪い例：AIがルールを守らない
- よい例：本文中のH2見出しが、指定した7件ではなく8件になった
- よい例：イベント一覧3件のうち1件で開催場所が空欄だった
- よい例：公開前確認をせず、古い料金情報を本文へ残した
主語をAIの性格ではなく、どの出力の、どの項目が、どの基準から外れたかへ変えると、検査できる不具合になります。
なぜなぜ分析は「発生原因」と「流出原因」を分ける
なぜなぜ分析は、目の前の症状から「なぜ」を重ね、根本に近い原因を探る方法です。名前は「5 Whys」ですが、必ず5回で終える決まりではありません。ASQも、根本原因へ届くまでの回数は5回より少ない場合も多い場合もあると説明しています。
AI運用では、原因を2本立てで考えると対策が具体的になります。
例：イベント情報から開催場所が抜けた
発生原因は、次のように掘れます。
- なぜ場所が抜けたか：出力項目に場所がなかった
- なぜ項目になかったか：依頼文では「イベントを整理」としか書かなかった
- なぜ曖昧なままか：必須項目の正本がなく、毎回チャットで伝えていた
一方、流出原因は別です。
- なぜ不足したまま保存されたか：保存前チェックがなかった
- なぜチェックがなかったか：AIの自己確認だけで合格とした
- なぜ止まらなかったか：場所が空欄なら保存を中止する条件がなかった
この例なら、「今後は場所を忘れないで」と注意するだけでは弱いままです。発生対策として必須項目の正本を作り、流出対策として空欄を止める関所を追加します。
発生対策｜ルールの正本を1つにする
まず、同じルールを複数の場所へコピーするのをやめます。採用するルールを1か所へ集約し、そこだけを更新する「正本」を決めます。
正本には、少なくとも次の項目を置きます。
- 必須項目
- 禁止事項
- 出力形式
- 情報の基準日
- 参照してよい情報源
- 作業を止める条件
- 完了とみなす証拠
AIサービスのプロジェクト機能や共有知識へ資料を置く方法は、文脈を揃える助けになります。ただし、保存した指示があることと、毎回すべての条件が機械的に保証されることは同じではありません。
正本は、長さよりも優先順位が大切です。たとえば、記事作成なら次のように分けます。
【必須】
・指定タイトルを変更しない
・公開前に日付依存の情報を一次資料で確認する
・各画像に内容を表す代替テキストを付ける
【禁止】
・根拠のない数値を補わない
・未確認を0件と書かない
・公開許可がない状態で公開しない
【停止条件】
・一次資料で確認できない重要情報がある
・指定画像を確認できない
・保存後のプレビューでレイアウトが崩れる「丁寧に」「十分に」ではなく、第三者でも合否を判断できる言葉へ変えます。
流出対策｜不合格なら進めない「関所」を置く
関所とは、次の工程へ進む前に、決めた条件を満たしているか確認する場所です。不合格なら修正へ戻し、保存、送信、公開などを止めます。
製造業の「自働化」には、異常が起きたときに工程を止め、不良品を後工程へ流さない考え方があります。AI運用でも、生成後に異常を検知して止める仕組みが重要です。
よい関所の条件
- 合否条件が具体的である
- 失敗した項目を特定できる
- 不合格時に処理を停止する
- 修正後に同じ検査を再実行する
- 合格した証拠を残す
OpenAIのAgents SDKでも、入力・出力・ツール実行へガードレールを設定し、条件に触れたときに処理を止める仕組みが案内されています。ここで重要なのは、AIへ「自分で確認して」と頼むだけではなく、不合格なら本当に次へ進めないことです。
AIの自己確認だけに頼らない
同じAIが出力し、同じ文脈のまま「問題ないですか」と判定すると、生成時の見落としを再び見落とすことがあります。
現実的な構成は、次のいずれかです。
- 決められた項目や文字列は、ルールベースで検査する
- 事実確認は、一次資料やデータベースと照合する
- 主観的な品質は、別の評価手順や人間の確認を使う
- 重要な外部操作は、実行直前に人が承認する
Web操作で送信・購入・削除などを止める設計は、AIエージェントにWeb操作を任せる安全設計で詳しく解説しています。
形式の正しさと内容の正しさを分けて検査する
検査項目を「全体を確認する」の1つにまとめると、何を保証できたのか分からなくなります。形式と内容を分けてください。
たとえば、構造化出力を使えば「開催日」「場所」「URL」の項目がある形に揃えやすくなります。しかし、スキーマへ適合していても、入力された日付や場所の値まで正しいとは限りません。OpenAIの公式資料も、構造化出力はスキーマとの一致を高める一方、値の中の誤りまでは防がないと説明しています。
形式の関所を通過した後に、内容の関所を置く。両方に合格して初めて、完成として扱います。
一度の失敗を回帰テストへ変える
回帰テストとは、過去に直した不具合が再び起きていないか確認するテストです。AI運用では、失敗が起きたら次のセットを残します。
- 失敗を再現する入力
- 期待する正しい出力または判定条件
- 失敗した出力
- 追加した対策
- 修正後の結果
モデル、プロンプト、参照資料、ツールを変更したときは、過去の失敗例をまとめて再実行します。OpenAIの評価ガイドでも、変更のたびに評価を行い、新しい不安定なケースを見つけ、評価データを増やし続ける方法が案内されています。
非エンジニアでも始められる4段階
いきなりプログラムを作る必要はありません。作業の重要度に合わせて、次の順で強くします。
チェックリストを作る
最初は、完了前に必ず見る項目を5〜10件へ絞ります。該当欄へチェックを付け、不合格なら修正します。
別のチャットや別工程で検査する
生成時の長い文脈を引き継がず、「本文」「合格条件」「検査だけを行う指示」を渡します。生成と検査の役割を分けるだけでも、見落としに気づきやすくなります。
表計算や簡単なスクリプトで検査する
空欄、件数、禁止語、URL形式、日付形式など、機械で判定できる項目を自動化します。事実の正しさは別途確認します。
ワークフローを自動停止させる
定期処理や大量処理では、不合格時に保存や送信へ進めない仕組みを作ります。失敗内容をログへ残し、修正後に再実行します。
原因分析に使えるプロンプト
次のプロンプトは、AIを責めるためではなく、工程を改善するための整理用です。
以下の不具合について、個人の注意力や「気をつける」で終わらせず、
再発を防ぐ仕組みを設計してください。
【期待した結果】
（ここに記入）
【実際の結果】
（ここに記入）
【使用した入力・指示・参照資料】
（ここに記入）
次の順で分析してください。
1. 不具合を、観測できる事実として1文で定義する
2. 発生原因を「なぜ」で掘り下げる。回数は5回に固定しない
3. 流出原因を「なぜ」で掘り下げる
4. 推測と確認済み事実を分ける
5. 発生対策を提案する
6. 不合格なら次工程へ進めない関所を提案する
7. 今回の失敗を回帰テストへ変換する
8. 人が確認すべき項目と機械で検査できる項目を分ける
9. 対策後に再確認する方法を示す再発防止にならない対策
次の対策は、補助としては使えても、それだけでは再発防止になりません。
「今後は気をつけて」と書く
何を合格とするか判定できず、不合格でも処理が止まりません。件数、必須項目、情報源、停止条件へ置き換えます。
指示文をコピーして増やす
修正漏れや矛盾が増えます。正本を1つにし、他の場所から参照します。
長い会話やメモリへ任せる
文脈共有には役立ちますが、保証にはなりません。重要条件は関所でも確認します。
毎回、人が全文を読む
少量なら有効でも、件数が増えると負担と見落としが増えます。機械で判定できる形式を先に落とし、人は事実や判断へ集中します。
別の高性能モデルへ替える
改善する場合はありますが、工程の欠陥は残ります。モデルを替えるなら、過去の回帰テストを実行して効果を確かめます。
まとめ｜ミスを責めず、工程を変える
AIが同じミスを繰り返したとき、最初に増やすべきものは注意文ではありません。
不具合を観測できる形で定義し、なぜなぜ分析で発生原因と流出原因を分けます。発生側では正本と手順を直し、流出側では不合格を止める関所を置きます。そして、今回の失敗を回帰テストへ追加します。
この流れを作れば、モデルや担当者が変わっても、同じ不具合を見つけやすくなります。AIを一度で完璧にするのではなく、失敗する前提で、失敗を通さない運用へ変えることが重要です。
まずは最近起きたミスを1つ選び、「どの出力の、どの項目が、どの基準から外れたか」を1文で書いてみてください。そこが再発防止の出発点です。
主な参考資料
- ASQ「Five Whys and Five Hows」
- Toyota Motor Corporation「Basic concept of the Toyota Production System」
- Lost in the Middle: How Language Models Use Long Contexts
- OpenAI「Guardrails」
- OpenAI「Introducing Structured Outputs in the API」
- OpenAI「Evaluation best practices」
- Claude Help Center「What are projects?」
コメント