AIエージェントに書いたルールが守られない。何度書いても無視される。置き場所を変え、量を減らし、参照の仕方を工夫し、それでも駄目なら仕組みで強制する。そうやって守らせる方法を積み上げてきた方は、多いのではないでしょうか。
よく見かける答えは、だいたい3つです。ルールを薄く保つ。参照先を一元化する。フックなどの仕組みで強制する。どれも実際に効きます。私も試して、効果を確認しました。
この記事が立てる問いは、その先にあります。守らせる仕組みが完成したとき、そのルールは正しいのでしょうか。
ルールが守られないのは、まだ気づける失敗である
守られない失敗には、大きな利点があります。破られた瞬間に見えることです。
コミットメッセージの形式が違う。触るなと書いたファイルが書き換わっている。禁止したライブラリが入っている。どれも目に入るので、その場で気づけますし、気づけるから対策が積み上がってきました。ルールを薄くする工夫も、仕組みで強制する実装も、破られたという観測があって初めて生まれたものです。
つまり、守られない問題は、すでに検知の仕組みを持っています。
残っているのは、検知できない側の失敗です。
気づけないのは、守られているのに間違っているとき
ルールが正しく守られていて、そのルール自体が間違っている。この状態には、検知の仕組みがありません。
出力は指示どおりで、エラーも出ません。レビューを通しても、ルールに沿っているかを見るだけなので通ります。誤りはルールの中にあるので、ルールと照らし合わせる限り、永久に見つかりません。
そして、ここに厄介な反転があります。守らせる精度が上がるほど、間違ったルールも正確に実行されるようになります。仕組みで強制する段階まで来ていれば、なおさらです。
誤ったルールは、こうやって書き込まれる
抽象的な話に聞こえるかもしれないので、私の運用で実際に起きたことを書きます。
私はAIエージェントに指示書を持たせ、それを育てる形で運用しています。失敗が起きるたびに原因を規定として書き足し、次のセッションはその指示書を読んでから作業に入る。そういう積み上げ方です。
ある日、エージェントが指示書に1行足しました。この指示書は2箇所に置く必要がある、片方だけだと判断基準がずれる、という内容です。根拠として公式ドキュメントの記述が引かれており、もっともらしく読めました。
翌日、同じエージェントがその規定に従って、私に作業を振ってきました。もう片方の場所へ手で上書きしてください、という依頼で、手順まで丁寧に書いてあります。
私は「なぜ必要なのか」と聞きました。その場で実際のフォルダを開いて確認したところ、保存の2分後にもう片方のファイルは自動で書き換わっており、内容も完全に一致していました。手で置く工程は、最初から存在していませんでした。
確かめるのに2分もかからないことを、まる1日のあいだ誰も確かめていなかったわけです。
公式ドキュメントを読むことは、確かめたことにならない
なぜ確かめなかったのか。読んでいたのが、現物ではなく記述だったからです。
AIの誤りへの対処として、よく挙げられるのは一次情報源にあたることです。公式発表を見る、仕様書を読む、査読された論文を確認する。今回、それは実行されていました。読まれていたのは公式ドキュメントです。手順としては正しく踏まれています。
問題は、ドキュメントが何を書いた文書なのか、という点にありました。
ドキュメントには、そうなっているはずのことが書いてあります。そうなっていることが書いてあるわけではありません。
仕様が書かれた時点と、いま目の前で動いているものは別です。実装が変わることもあれば、書かれた条件がそのケースに当てはまらないこともあります。にもかかわらず、ドキュメントを読むと調べたという手応えが得られます。この手応えが、確認を打ち切らせます。
先に問うべきだったのは、現物を見る方法があるかどうかでした。今回であれば、フォルダを1つ開けば済む話です。
書いた本人が、いちばん疑わない
もうひとつ、構造的な理由があります。自分が書いた文章は疑いにくい、ということです。
大規模言語モデルを評価者として使ったときのバイアスを調べた研究があります。Wataokaらによる2024年の報告で、NeurIPSのワークショップに採択されています。ここで示されたのは、モデルが自分の生成物を贔屓するという単純な話ではありませんでした。
モデルは、自分が書いたかどうかに関わらず、パープレキシティが低いテキスト、つまりそのモデルにとって見慣れた文章を、人間の評価者より有意に高く評価していました。
原因は自己愛ではなく、馴染みやすさだったということです。
ここからは私の解釈です。学説として確立された議論ではありませんので、そのつもりで読んでください。指示書に書き込まれた規定は、そのモデルが自分で書いた文章です。当然、そのモデルにとって世界でいちばん自然な日本語になります。翌日それを読み返したとき、引っかかりが生じにくいのは、この性質と同じ形をしています。
公平を期すために限界も書いておきます。この研究が測ったのは、2つの回答のどちらが良いかを判定する場面での評価値です。自分が書いた規定を疑うかどうかを測ったものではありません。同じ形に見えるという以上のことは、ここでは言えません。
誤りは、セッションをまたいで運ばれる
エージェントの失敗を大規模に分類した研究では、最大のボトルネックは誤りの伝播でした。
Zhuらが2025年に発表した報告では、500件を超える失敗の軌跡を分析しています。失敗は作業の中盤、6ステップ目から15ステップ目のあたりに集中していました。早い段階の小さな誤りが下流へ連鎖し、最終的な失敗まで増幅していく構造です。
ただし、この研究が測っているのは1つのタスクの内側です。セッションが終われば、そこで積み上がった誤りも一緒に消えていきます。
指示書は、それを外へ持ち出す装置になっています。会話の文脈は消えても、書き込まれた規定は残る。しかも次のセッションは、その規定を検証済みの前提として読むので、誰が何を根拠に書いたのかはもう問われません。
セッションをリセットしても、誤りだけは残ります。残す仕組みを、こちら側が作っているからです。
崩れたのは、人間が根拠を聞いたときだった
今回の誤りが表に出たきっかけは、たった一つでした。人間が「なぜ必要なのか」と聞いたことです。
エージェントは自分では気づきませんでした。私も、指示書に書かれた規定を読んだ時点では気づいていません。読んだときはもっともらしく見えたからで、違和感を持ったのは、その規定に従って自分に作業が振られたときでした。
ここに、見落とせない偏りがあります。
表に出た誤りは、人間に手間が発生した分だけです。
手間を生まない誤りは、同じように書き込まれ、同じように前提として読まれ、そのまま残り続けます。今回のケースで私が気づけたのは、誤りが人間の作業という形で外に出たからで、運が良かっただけです。誤りの検出を、こちらの不便さに頼っている状態でした。
よくある疑問
Q：AIが書いたルールを、毎回検証するのは現実的でしょうか。
A：全部を検証するのは無理だと思います。ただ、種類で分けることはできます。実際に見れば数分で決着するもの、たとえばファイルの場所、コマンドの有無、設定の実際の値は、その場で確かめてから書く。確かめるのに時間がかかるもの、あるいは確かめようがないものは、推測であることをルール本文に書き残しておく。この区別だけで、後から遡れるようになります。
Q：人間が書いたルールなら安全でしょうか。
A：同じ問題が起きます。人間もドキュメントを読んで、そういう仕様のはずだと考えてルールを書きます。違いは、人間のほうが「そういえば根拠が曖昧だった」と後から思い出す可能性が残る点くらいです。セッションごとに記憶が消えるエージェントには、その回路がありません。
Q：ルールを増やさないようにすれば済む話でしょうか。
A：量の問題とは別だと思います。10個しかないルールの1つが間違っていれば、それは常に読まれて常に効きます。むしろ薄い指示書のほうが、1行あたりの影響は大きくなります。
判断基準は、そのルールの根拠が現物かどうか
ルールを1行足すときに、確かめることは1つで足ります。その根拠は現物か、それとも記述か。
現物というのは、実際に開いて見た、実際に動かした、実際に数えた、という意味です。記述というのは、ドキュメントにそう書いてあった、そう説明されていた、そういう仕様のはずだ、という意味になります。どちらも調べた感触は同じくらい得られますが、確かさの度合いはまったく違います。
記述しか根拠がない場合でも、ルールを書いてはいけないわけではなく、書いてよいと思います。ただ、これは未確認である、と1行添えておく。それだけで、次に読む側が疑える状態になります。
エージェントの指示書は、育てるほど強くなる資産だと思われがちです。実際その通りなのですが、育てるという行為には、検証されていない推測を固定していく側面もあります。
強くなるのと、正しくなるのは、別の話です。
あなたの指示書に並んでいるルールのうち、現物を見て書かれたものは、どのくらいあるでしょうか。
