AIが指示を守らないのはなぜか｜再発防止策を3つの層に仕分ける

AIに「必ずこうして」と指示しても、そのとおりに動かないことがあります。指示の書き方を直す前に見てほしいのは、その指示をどこに置いたかです。

これはAIに限った話ではありません。再発防止策を書いたのに似たような事故が起きるとき、原因はルールの中身ではなく置き場所にあります。ルールの置き場所は3つに分かれ、それぞれ効き目がまるで違います。あなたの会社の再発防止策を3つの層に仕分けると、「対応済み」のまま効いていないものが見えてきます。

再発防止策の「置き場所」は3つに分かれる

ルールの置き場所は、内部統制の分野で指示的統制・予防的統制・発見的統制と呼ばれる3つの層に分かれます。この記事では、それぞれ「依頼」「関所」「点検」と呼びます。AIに仕事を任せる場面でも、人の業務フローでも、この3つの守備範囲は変わりません。

置き場所	正式名称	いつ働くか	守れる範囲	働くために要ること
依頼（マニュアル・指示書）	指示的統制	作業の前に読ませる	その作業を丁寧にやったときだけ	読まれること＋前提まで書けていること
関所（実行の直前で止める仕組み）	予防的統制	実行しようとした瞬間	その1回の実行	通り道に置いてあること
点検（あとから必ず通す確認）	発見的統制	作業が終わったあと	別の日・別の人の作業も含む	必ず通す運用にしてあること

依頼は書くのがいちばん簡単で、条件がいちばん多い置き場所です。読まれなければ働きませんし、読まれても、書かれていない前提は伝わりません。関所は強い代わりに、守れるのは目の前の1回だけ。点検は通ったあとを見るので、別の日・別の人の作業まで届きます。

3つは強さの順番ではなく、守備範囲の違う3人だと考えてください。

仕組みで品質を決めるという考え方そのものは「AIレポートの精度はモデル選びでなく仕組みで決まる」に書きましたが、この記事はその一段手前——どの層に置くかの話です。なお、「AIに広告運用を任せるときに鵜呑みを防ぐ仕組み」はAIの出力を層に分けて受け取る話で、この記事はAIに渡すルールのほうを層に分けています。分ける対象が違います。

動画広告費の24%が、分析の視界から抜け落ちていた

ツールが出した分析結果を見て「この施策が効いている」と判断したことがあるなら、その分析が対象の広告費の何%を見ているか、検算したことはあるでしょうか。

1つ目は、AIを使った広告運用の分析で起きた話です。ある媒体の動画広告について、実績をクリエイティブ単位に切り分けて返す機能（ブレイクダウン）を使って、動画ごとの実績を出しました。どの動画にいくら使い、どの動画からコンバージョンが出たか。ところがそのブレイクダウンは、特定の入稿形式にしか対応していませんでした。

動画広告の費用に限ると、拾えていたのは76%だけでした。残る24%は費用が計上されないままで、その前提で「この動画が勝ち筋だ」と結論していたことになります。

気づいたきっかけは、APIが返した費用の合計と、動画広告に使った費用の合計との検算です。その検算を仕組みに組み込んだうえで、別の経路からも実績を紐づけたところ、取りこぼしなく費用を紐づけられた割合（被覆率）は100%になりました。

この話のポイントは「APIの仕様が悪い」ではありません。数字を出す仕組みに、合計との突き合わせが入っていなかった——発見的統制がゼロだったことです。点検がなければ、見えている範囲だけで判断し続けます。しかも、見えている範囲だけで答えは出るので、何も欠けているようには見えません。

ルールを決めた時点では、スクリプトは直っていなかった

2つ目は、依頼だけで守ろうとしている状態がどれだけ危ういかの話です。

検証の過程で、AIエージェントに「配信を止めた状態で入稿して」と依頼していたのに、有効な状態で作られることがありました。本番で課金が発生したわけではありませんが、審査が通れば課金が始まる状態でした。

そこで「新規入稿は必ず配信停止状態で作る」というルールを決め、是正記録は「対応済み」になりました。ただしこの時点で止めているのは、ルールの文だけです。スクリプトは依然として、有効な状態でも作れるままでした。

そのあとスクリプト自体を直し、配信を止めた状態でしか作れないようにしました。ここで初めて、依頼から関所へ移ったことになります。同じ「対応済み」でも、中身が違います。

ここで確認したいのは、あなたの会社の是正記録にある「対応済み」が何を指しているかです。文書に書いた時点で「済」なのか、止まる仕組みにした時点で「済」なのか。前者なら、依頼の層にしか置かれていません。

私たちが自社の是正記録を仕分けたときは、6件中5件が文書に書いただけの状態でした。先ほどの入稿の件も、スクリプトを直すまではその1つです。「済」の定義が、ルール文書の改定を指していたからです。

自動化は「動いている」前提で放置される

3つ目は、点検がないと何が起きるかの話です。

日次でデータを集める処理を、GitHub Actions（決めた時刻に処理を自動で走らせる仕組み）で自動化していました。ところが、ある時期からエラーで止まったままになっていました。

止まっていることに、AIは気づけませんでした。気づいたのは、人が数字を目視で確認したときです。

止まった原因は、コードの誤りではなく、動かすのに必要な設定が1つ入っていなかったことでした。気づけなかった原因は別にあります。ワークフローが「設定が無ければ黙って飛ばす」設計になっていたことです。

直したのは、データを集める処理そのものではありません。「設定が無ければ黙って飛ばす」を「無ければ赤く失敗する」に変えました。

発見的統制の本質は、沈黙を許さないことです。自動化は動いている前提で放置されます。壊れても音が出なければ、壊れた日から無防備になります。

これはAIに読ませるだけの場面でも同じです。「AIで決算書を分析する前に済ませる3つの準備」で約30倍の誤りを捕まえたのは、元の記録との突き合わせ——つまり点検の層でした。

読める場所に、正しく書いてあった。それでも破られた

4つ目は、いちばん言い訳のきかない話です。このサイトの運用で起きました。

アクセス解析には、海外からの自動アクセス（ボット）が実際の読者より多く混ざっています。絞り込まずに数えると、サイトの規模が実態の約4倍に見えます。そこで運用の台帳に「指標は日本の実ユーザーで見る」と書き、絞り込みの手順まで残しました。

そのうえで、解析をAIに任せました。台帳はAIが読める場所にありました。それでもAIは全体の数字をそのまま集計し、誤った結論を3つ出しました。伸びが止まったように見え、読まれ方が悪化したように見え、問い合わせの件数も取り違えました。どれも、数字を正しく切り出すと消えるものでした。

数字を読み違えると、動くのはお金です。伸びている施策を「効いていない」と止め、効いていない施策に予算を足す。AIが出した数字の検算をしていても防げません。計算が合っているかと、正しい範囲を見ているかは別だからです。

この記事の最初に、依頼が働く条件を「読まれること」と「前提まで書けていること」の2つだと書きました。前提は書けていて、読める場所にも置いてありました。それでも破られたのは、「読める」と「読まれる」が別だからです。書き手が保証できるのは前者までで、後者は相手任せ。依頼の層に守らせる力が無いのは、ここです。

直したのは、ルールの中身ではなく置き場所です。アクセス数を見る入口を1本に決め、「日本だけを見る」条件を外せない形で埋め込みました（関所）。出力の最後には、ボットの混入率を必ず併記します（点検）。

ただし、この関所は完全ではありません。入口を通らずに元のデータを直接取りにいくことは、技術的にはまだできます。塞ぎきれない部分は「塞げない」と明記したうえで、依頼の層に戻しました。全部を関所にできなくても、いちばんよく間違える1か所を関所にする——私たちはそこで線を引きました。

道具がなくても、関所と点検は作れる

ここまでの例にはコードが出てきましたが、関所と点検はコードなしでも作れます。

層	コードで作る例	コードなしで作る例
依頼（指示的統制）	指示書の絶対ルール	社内マニュアル・朝礼での周知
関所（予防的統制）	実行前に止めるスクリプト	承認がないと次に進めないワークフロー／操作権限そのものを渡さない
点検（発見的統制）	作業後に走る自動テスト	提出前チェックリスト／月次の棚卸し／別の担当者による確認

いちばん手軽で確実なのは、権限を渡さないという関所です。私たちはある作業で、下書きまでは作れるが公開はできない権限設定にしています。「公開しないこと」という指示ではなく、公開ボタンが押せない状態にしてある。コードは1行も書いていません。

もうひとつ効くのは、機械にできる判定とできない判定を同じ場所で書き分けることです。機械で判定できないものは、「機械では判定できないため人が確認する」と理由つきで明記しておく。全部を自動にしようとせず、どこまでを機械に、どこから人が見るかを先に決めて書いておくのが急所です。

仕分けは5分でできる

道具を買う前に、5分でできることがあります。

1. 繰り返し注意していることを3つ書き出す。AIへの指示でも、社内のルールでも、部下への口頭の念押しでもかまわない
2. それぞれが「依頼・関所・点検」のどこに置かれているか、印をつける
3. 3つとも「依頼」なら、いちばんお金が動く（＝間違えたときの損がいちばん大きい）1つだけを関所か点検に移す
4. 移せない理由が「機械では判定できないから」なら、そう明記して人の確認に振る。曖昧に残さない
5. 3か月後にもう一度仕分ける。増えた分が「依頼」ばかりなら、同じことがまた起きる

まとめ

ルールを書いたことと、事故が止まることは別です。再発防止策が「対応済み」になっていても、それが依頼の層にしか置かれていないなら、読まれたときにしか効きません。

AIが指示を守らないのも、多くはここです。AIの出来が悪いからではなく、その指示が依頼の層にしか置かれていないからです。

動画広告費の24%が視界の外にあったのも、配信を止めるという依頼が守られなかったのも、日次の自動処理が黙って止まっていたのも、正しく書いたルールがAIに破られたのも、点検か関所がひとつ足りなかったからです。3つの層のどこに置かれているかを知っているだけで、次にどこを塞ぐかが決まります。