AIはなぜ、そこを間違えるのか

第1章の論文のいちばんの価値は、「なぜAIが穴を作り込むのか」を8つのパターンに分け、「どう頼めば防げるか」を実験で確かめたところにあります。この章では、その8つを経理の新人が起こすミスに置き換えて理解し、実験の数字から、AIへの頼み方の原則を導きます。

原因は3つに分けられる

論文の著者は、見つかった1,186件の脆弱性のそれぞれについて、「AIがなぜそれを作り込んだか」を分類しました。結果は3つの大分類に収まります。

• 記憶の欠陥（160件、13.5%）。直すべきことを、AIが途中で忘れる。
• 目的の欠陥（274件、23.1%）。AIが「動けばよい」を目標にして、本番で必要な守りを省く。
• 知識の欠陥（752件、63.4%）。AIが、言われなくても守るべき規則を知らない、または適用しない。

この3つは、経理の新人教育で見る3種類のミスとよく似ています。言われたことを忘れる、楽な方法に流れる、そして「当たり前」を知らない。最後がいちばん多く、いちばん教えにくいのは、人でもAIでも同じです。

8つの失敗モード

3つの大分類は、さらに8つの失敗モードに分かれます。右の列に、経理の新人がやりがちなミスを並べました。自分の職場で見たことのある場面を思い浮かべながら読んでください。

記憶の欠陥：忘れる

①の「変更の伝播不足」は、ある箇所に守りを入れたのに、同じ処理をしている別の箇所には入れ忘れることです。取引の読み取りには所有者の確認を付けたが、削除には付けなかった、という形で現れます。規程を改定したのに、旅費精算の様式だけ古いままになっているのと同じです。②の「先送りの忘却」は、AIがコードの中に「あとで認証を追加する」とメモ（TODO）を残したまま、追加されずに公開されることです。仮伝票のまま月次を締めてしまう状態です。

目的の欠陥：楽な方法に流れる

③の「デモ志向の設計」は、最も目に見えやすい失敗です。暗号化しているように見えて実は何もしていないダミーの処理、誰でも知っている固定の鍵、確認なしで通る「とりあえず動く」ログイン。AIは「動く見本」を作ることに最適化されがちで、本番で必要な守りを省きます。④の「機能修正の副作用」は、エラーを直してほしいと頼まれたAIが、エラーの原因である確認処理そのものを外してしまうことです。「権限エラーが出る」と言われて、権限チェックを消せばエラーは消えます。チェックが煩わしいからと、承認フローを飛ばすのと同じです。第13章で「修正のあとに、もう一度確かめる」理由がここにあります。

知識の欠陥：当たり前を知らない

⑦の「暗黙のセキュリティ規則の欠落」が658件、55.5%で、単独で全体の半分を超えます。「他人のデータは見せない」「入力はそのまま命令にしない」「鍵はコードに書かない」。こうした規則は、誰も指示文に書きません。書かなくても当然守られるべきものだからです。しかしAIには、その「当然」がありません。言われなかったことはやらない。印紙を貼る必要があることを誰も言わなかったから貼らなかった、というのと同じ構造です。⑧の「利用者任せ」は、AIが守りの設定や確認を利用者に委ね、それが行われないまま公開されたものです。委ねられた利用者が非エンジニアなら、何を委ねられたのか分からないまま終わります。⑤と⑥は少数で、指示そのものが危険だった場合と、存在しない機能や設定をAIが作り出した場合です。

頼み方で、再発率はどう変わったか

論文の著者は、見つかった脆弱性のうち70件を選び、同じ機能をAIにもう一度作らせました。指示文の添え方、使うモデル、追加知識（スキル）など条件を8通りに変え、70件×8条件×3回で合計1,680回（各条件210回）。同じ脆弱性が再び作り込まれた割合が、次の表です。

なぜ、詳細な指示は逆効果なのか

直感に反する結果です。丁寧に指示するほど、穴が増えました。論文の著者の解釈はこうです。手段を細かく指定されると、AIは指示に忠実になりすぎ、指示に書かれていない暗黙の規則を落とす。「この処理をこの順番でこう書いて」と言われれば、言われた通りに書くことに集中し、「所有者を確認する」という書かれていない規則を省きます。逆に「本番で使う」という目的だけを伝えると、AIは本番に必要なものを自分で補います。⑦の暗黙の規則の欠落が最大の原因であることと、つじつまが合います。

新人に「この伝票を、この科目で、この金額で切って」と手順だけ指示すれば、証憑の確認を飛ばすかもしれません。「監査に耐える処理をして」と目的を伝えれば、証憑の確認まで自分でやります。同じ構図です。

なぜ、強いモデルでも変わらないのか

より強いモデルに替えても、再発率は26.2%で基準と変わりませんでした。モデルの賢さは「書かれたことをどれだけうまくやるか」を高めますが、「書かれていないことをやるべきか」の判断は別の話だからです。これは論文だけの観察ではありません。第1章で触れたVeracodeの「2025 GenAI Code Security Report」も、100以上のモデルを比べて、新しいモデルでも安全性はほぼ横ばいだったと報告しています。モデルの更新を待っても、この問題は解決しそうにありません。

ここから導かれる3つの原則

実験の数字と失敗モードの構造を合わせると、AIへの頼み方は3つの原則にまとまります。

1. 細かく指示するより、本番水準を求める。「本番運用に耐えるものを」の一言が、最も安く、最も効きました。手段を指定するのは、自分が中身を理解しているときだけにします。セキュリティについては、遠慮せず明示的に求めます。
2. セキュリティ観点のスキルを渡す。「当たり前」を知らないなら、当たり前を文書で渡します。スキル（AIに追加で読ませる知識）の形で渡すと、再発率は11.9%でした。第6章と第13章で、渡す文書の中身を用意します。
3. 作る側と確認する側を分ける。「変更を見直して」と同じ会話で頼んでも、ほぼ効きませんでした（23.8%）。自分で起票した伝票を自分で承認しても統制にならないのと同じです。レビューは別の会話で、できれば別のモデルで行います（別の会話・別のモデルでのレビューは、論文が効果を測った条件ではなく、内部統制の考え方から導いた実務上の工夫です）。

この3つは、どれも技術の知識を必要としません。経理の内部統制で日常的にやっていることを、AIとのやりとりに持ち込むだけです。次の章では、AIが作り込みがちな穴の種類を、自分のアプリで起きたらどうなるかという形で具体的に見ていきます。