AI運用の再発防止を仕組み化。事故をチェック項目に変える手順

AI運用の「再発防止の仕組み化」とは、起きた事故を人の注意力ではなく機械のチェック項目に変換し、同じ原因の事故を実行前に自動で止める体制を作ることです。柱は3つ。事故の記録を消さないこと、原因を機械が合否判定できる1文に言い換えること、その検査を実行前の関門に組み込むことです。

僕はAIVESTという会社を経営しながら、ブログ記事の企画から公開までをAIに任せる仕組みを自作して運用しています。この記事では、その運用で実際に起きた事故をチェック項目へ昇格させてきた手順を、実例つきでそのまま公開します。

AI運用の再発防止を仕組み化するとは何か

再発防止策には、置き場所が2種類あります。「人の記憶」に置くか、「機械の検査」に置くかです。

注意喚起、朝礼での共有、手順書やAIへの指示文への追記。これらはすべて前者で、思い出してもらえた時だけ機能します。一方、仕組み化とは後者に置くこと、つまり同じ事故の条件が揃ったら、誰も思い出さなくても機械が実行前に止める状態を作ることです。

対策を「人の記憶」から「機械の検査」へ移す

ここで言う検査とは、難しいものではありません。「タイトルが32字を超えていたら不合格」「必須項目が空なら不合格」のように、合否が機械的に決まる1文のことです。

重要なのは検査を置く位置です。作業の途中ではなく、公開・送信・実行の直前に必ず通る関門に置きます。僕の運用ではこれをゲート（公開前に全記事が例外なく通る機械の関門）と呼んでいて、ここを通らない記事は公開の処理に進めない構造にしています。

僕が実際に運用している仕組み

僕のブログは、企画、執筆、画像生成、検証、下書き投稿までをAIと自動処理で回す体制で運用しています。その運用ルールの原文が、この記事の背骨です。

eval・gateの緩和/削除禁止。failed.log・rejectは消さない（没も学習データ）

言い換えると、「検査と自動テストは勝手に緩めたり消したりしてはいけない。失敗の記録と没にした成果物は削除せず、理由をつけて残す」という原則です。事故が起きるたびに検査項目が1つ増え、減ることはない。この一方通行が、再発防止を仕組みとして成立させています。

なぜ注意喚起と手順書の追記では再発が止まらないのか

事故のあとに「以後注意します」「手順書に追記しました」で締める。多くの現場で見る対応ですが、AI運用ではとくに効きません。理由は2つあります。

注意は時間で必ず減衰する

人の注意力は事故直後がピークで、あとは下がる一方です。担当者が変われば記憶ごと消えます。手順書への追記も、追記が増えるほど1項目あたりの順守率は下がっていきます。読まれない手順書は、書かれていないのと同じです。

AIは「前回の反省」を覚えていない

AIに業務を任せている場合、事情はさらに深刻です。AIは基本的に毎回まっさらな状態で仕事を始めるので、前回の事故を反省として引き継ぎません。指示文に「〇〇に注意して」と書き足しても、指示が長くなるほど個々の指示の順守率は下がりますし、モデルの入れ替えや指示文の整理で1行消えれば、対策ごと消えます。

だから、毎回確実に守らせたいことは、出力を「作る側」への注意ではなく、出力を「検査する側」に置くのが確実なんですよね。注意は時間で減衰しますが、検査は時間が経っても劣化しない再発防止の在庫になります。

事故をチェック項目へ昇格させる5ステップ

僕が実運用している昇格手順は、次の5ステップです。

つまずくのはほぼステップ2

やってみると分かりますが、失敗するのはだいたい言い換えのステップです。「丁寧に確認する」「品質に気をつける」は検査になりません。合否の境界が人の解釈に残っているからです。

コツは、事故の結果ではなく痕跡を探すことです。「読者に不親切な記事だった」は判定できませんが、「見出しが3本未満」「本文にリンクが1つもない」なら判定できます。事故のたびに「この事故は、成果物のどこを見れば機械でも見抜けたか」と問い直すわけです。

僕のブログの公開前ゲートに実際に入っている検査項目と作り方は、AIの成果物を公開前に検査する仕組みの記事で実物を公開しています。

昇格の実例。1つの事故がチェック項目になるまで

抽象論で終わらせないために、僕のブログで実際に起きた事故を1件、昇格の手順どおりに追ってみます。

事故。公開記事の冒頭に同じ画像が2枚並んだ

2026年7月、このブログの公開1本目の記事で、冒頭に同じ画像が2連続で表示される事故が起きました。原因は、記事の顔として自動表示されるカバー画像を、執筆担当のAIが本文の先頭にも書き込んでいたこと。システムがカバー欄と本文の両方に同じ画像を出してしまったわけです。

昇格。5ステップをそのまま適用する

この事故は次のように処理しました。

• 記録: 評価表に「既知の失敗」として事故の内容と日付を記録。記録は今も残っています

• 言い換え: 「カバー画像と同じURLの画像が本文にも埋め込まれていたら不合格」という1文に変換

• 関門へ追加: 公開前ゲートにこの検査を追加し、修正した記事が合格することを確認

• 回帰検査に固定: 以後、すべての記事が公開前にこの検査を毎回通過。将来AIを入れ替えても、指示文を書き直しても、同じミスは公開前に自動で止まる

• 人間の役割: 僕はこの種類のミスをもう目視で探していません

注意喚起との差がはっきり出るのはここからです。指示文に「カバー画像を本文に入れないで」と書き足すだけの対応なら、その1行が消えた瞬間に事故が再発します。検査は消えません。消すためには人間の決裁が要るというルールごと仕組みに含めているから、対策が風化しないんです。

なお、僕のAI運用で起きた事故の中身そのものは、失敗事例をまとめた別記事に譲ります。この記事の主役はあくまで「事故を検査に変える手順」です。

関連記事AI自動化の失敗例。AIVESTが捨てた自動化と設計原則AI自動化の失敗例を、AIVESTの実運用記録からそのまま公開します。カバー画像の二重表示、設定ずれの2日連続停止、並列実行の残高枯渇、自己採点ゲートの撤廃。共通する3つの原因と、失敗を検査項目に変える設計原則まで解説します。→

仕組みにしてはいけないもの。人間が持ち続ける判断はどれか

5ステップを回し始めると、今度は「何でも検査にしたくなる」段階が来ます。ここで線引きを間違えると、仕組みが逆に現場を壊します。

機械に渡すもの、人間が持つもの

僕の運用での分担はシンプルです。

• 機械に渡す: 形式（字数・必須項目・件数）、重複、リンクの実在、過去の事故の再発。合否が客観的に決まるものすべて

• 人間が持つ: 企画やテーマ選定の判断、公開してよいかの最終判断、検査の合格ラインの改定、そして検査の緩和・削除の決裁

とくに最後の1つが重要です。検査を作る力より、検査を勝手に緩めない規律のほうが、再発防止の寿命を決めます。忙しい日ほど「今回だけ検査を飛ばそう」という誘惑が来ますが、例外を1回許した検査は、もう検査ではありません。

品質の好みと責任の判断は昇格させない

「この記事は面白いか」「この表現はうちの会社らしいか」のような判断は、機械の合否に落ちません。無理に点数化すると、点数を最適化しただけの成果物が量産されます。僕の運用でも、品質の最終判断と公開の決裁は人間側に残しています。

また、この記事で扱ったのは事故が起きた後の話です。そもそも事故の被害を小さくする事前の設計、つまりAIにどこまでの権限を渡すかは別の論点で、AI自動化のリスク設計の記事にまとめています。事前の権限設計と事後の検査昇格は、再発防止の両輪です。

よくある質問

まとめ。事故は検査項目の在庫である

最後に、この記事の手順をまとめます。

• 再発防止の仕組み化とは、対策を「人の記憶」から「機械の検査」へ移すこと

• 注意喚起と手順書の追記は時間で減衰する。AIは前回の反省を覚えていない

• 昇格の5ステップは、記録して消さない、合否判定できる1文への言い換え、実行前の関門へ追加、回帰検査への固定、人間レビューの絞り直し

• 検査の緩和・削除には決裁を必須にする。この規律が対策の風化を防ぐ

• 品質の好みと公開の最終判断は、機械に渡さず人間が持ち続ける

事故は隠したり消したりした瞬間にただの損失になりますが、記録して昇格させれば検査項目の在庫になります。事故が起きるたびに仕組みが強くなる運用と、起きるたびに注意喚起が増えるだけの運用。1年後の差は、想像より大きいはずです。