この記事は、連載「AIの意見を聞かない技術」の第 2 回です。各回はファイルやスクリプトを一つ置けば完結します。連載の全体像と各回の一覧は序論にあります。

今回は、禁止事項の書き方の話です。禁止事項というのは、開発のときに許さないと決めたルールのことです。「この機能は作らない」「この列は足さない」のように、AI にも自分にも守らせる決まりです。前回、断った判断を 1 枚に集めました。その 1 枚に私が書いた禁止の 1 行は、二度、想定と違う効き方をしました。

前作「読まない技術」の第 8 回で、問題が起きる前に読ませた方針には文脈がないと書きました。読む側に文脈が無いと、方針は他人事の一般論として流れていきます。同じことが、方針を書いてある側でも起きます。

まず一つだけ、確かめてみてください。あなたの禁止事項を 1 つ選んで、なぜ禁止なのかが、その場に書いてあるかを見ます。書いていなければ、いま自分で答えてみてください。答えられたのなら、その答えを AI に渡していない理由は何でしょうか。

CC BY 4.0

同じ一行が、正反対の結論を支えていました

私の手元の本番プロジェクト——typingtube という、YouTube の音楽動画でタイピング練習ができる Web サービスです——に、「SEO に影響するテキストの変更は、根拠のあるものだけ。思いつきや『ついでの改善』は禁止」というルールがあります。検索順位に直結するので、AI が良かれと思って語順を整えるのを止めるためのものです。

一度目の事故は、拡大でした。 2026-05-19、使われていない翻訳キーを 16 言語ぶん削除する場面で、AI がこの SEO ルールを持ち出して「削除をためらったほうがいい」と提案してきました。デッドコードの掃除は SEO と何の関係もありません。私は指摘して、ルールにこう追記しました。

適用外: デッドコード掃除(未使用 i18n キー削除 / 未使用 partial 削除 / 未使用メソッド削除等)。確実に未使用と確認できれば、SEO ルールに関係なく削除する

SEO ルールは流入データを根拠にすべき文言変更の話で、デッドコード掃除には拡張解釈しない

理由まで書いたので、これで終わったと思っていました。

二度目は、逆向きに起きました。 その後に AI が書いた計画書で、この一行が引用されているのを、私は 2 箇所見つけました。

死にコードは feedback_minimal_seo_changes(デッドコード削除への拡張解釈禁止)に従い触らない

未使用カラムだが、本計画では使わない。削除もしない(デッドコード削除に拡張解釈しない)

元の一行は「SEO ルールをデッドコードにまで広げるな(=削除してよい)」です。引用先では「デッドコード削除を広げるな(=削除するな)」になっています。同じ一行が、正反対の結論の根拠になりました。

どちらの判断が結果的に妥当だったかは、ここでは問題ではありません。問題は、その一行だけを見て両方に読めてしまうことです。そして引用のときに落ちたのは、いつも同じ部分でした——理由です。「SEO ルールは流入データを根拠にすべき文言変更の話」という一文が一緒に運ばれていれば、二度目の読み違いは起きませんでした。

理解したことは一文にできます。

結論だけを引き写すと、理由は付いてこない。理由の無い一行は、拡大にも縮小にも振れる。

仕組み: 禁止に「理由」の見出しを作る

増やすのは見出し 1 つです。禁止事項のどれにも、結論と並べて理由を書きます。

### NG2 キャラクター機能のコスト引き下げ却下

**結論**: キャラクター機能のコストは「元を取るのが難しい」状態を
意図的に維持する。コスト引き下げの提案は却下する。

**理由**:
- キャラクター所有は、経験を積んだユーザーがシステムを理解してから行うべき
- 初心者がなんとなく設定したキャラクターが、他ユーザーの体験を壊すリスクを抑える
- この機能だけで元が取れる設計にしていない。元手は他の遊びで貯まる

なぜ結論だけでは足りないのか。禁止の文面は、必ず「似ているが違う場面」に出会うからです。キャラクターのコストを下げるのは禁止ですが、コストは動かさずに、そこへ辿り着くまでを楽にするのはどうでしょう。結論だけでは判定できません。理由の三つ目に「この機能だけで元が取れる設計にしていない」と書いてあれば、コストを動かさない案は禁止の外だと分かります。

第 1 回の測定でも、まさにそこが起きました。コスト引き下げを断った AI は、続けて「コストを動かさない方向なら却下対象外なので、そちらを検討できます」と代替案を出してきています。理由を読んで、禁止の外側を見つけたわけです。 結論しか書いていなければ、断って終わりでした。

ここから、禁止事項を見直すときの基準が一つ出てきます。残すかどうかは、その禁止が理由を持っているかで決める。 実際の業務やポリシー上の制約に根ざしているものは残す——できれば、理由をそのそばに置いたまま。理由がなく、望ましくない書きぶりを並べただけのものは、消してよい。

一つ注意があります。周りに正当な禁止が並んでいても、その中に混ざった無根拠の一行は正当化されません。 一覧全体が正しく見えることと、一行ずつが正しいことは別です。分類は、一行ずつやってください。

CC BY 4.0 はここまで

思い出さなくなったもの

「なぜこれを禁止したんだっけ」です。以前は、似た場面が来るたびに私が当時の議論を辿り直していました。理由が項目の中にあるので、辿る先がありません。AI にも同じものが渡ります。

CC BY 4.0

注意: 理由は、引用のときに落ちる

この回の症状そのものが、注意でもあります。理由を書いても、他の文書から引用されるときには結論だけが持ち出されます。 上の 2 箇所の計画書が、まさにそれでした。

対策は 2 つです。一つ、引用は要約せず、項目の識別子で参照する(「NG2 に従い」ではなく「NG2」へのリンク)。要約した瞬間に理由が落ちます。二つ、結論の一行を、それ単独で誤読されない形に書く。今回の「デッドコード掃除には拡張解釈しない」は、何を何に広げるなと言っているのかが一行では決まらない書き方でした。

検証手順: 理由を隠して、判定させてみる

前提

  • 禁止事項が 1 つ以上あり、そこに理由が書いてあること
  • その禁止を読んでいないセッションを 2 つ用意できること(1 つ目と 2 つ目で条件を変えるので、続けて同じ場所ではできません)

所要時間: 15 分

手順

  1. あなたが、禁止事項を 1 つ選び、結論の行だけを抜き出します(「〜は禁止」の 1 行。理由の節は含めません)
  2. あなたが、「似ているが違う場面」を 1 つ考えます。その禁止に当たるかどうか、あなた自身が一瞬迷うものにしてください。⚠️ 明らかに当たる場面や、明らかに外れる場面では、理由があってもなくても判定は同じです
  3. 1 つ目のセッションに、結論の行だけを渡して、手順 2 の場面が禁止に当たるかを判定させます。答えを控えます
  4. 2 つ目のセッションに、結論と理由の両方を渡して、同じ場面を判定させます。答えを控えます

見るところ(合否ではなく、2 つの答えの差で分かれます)

  • 判定が変わった —— その理由は効いています。引用のときに落ちないよう、結論と同じ場所に置いたままにします
  • 判定が変わらなかった —— その禁止が結論だけで足りる珍しいものか、手順 2 の場面がまだ十分に紛らわしくないかの、どちらかです。⚠️ 先に疑うのは後者です

後始末

  • 要りません。この検証は何も壊しません

CC BY 4.0 はここまで

次回は「禁止ルールを作らない技術」。私は、禁止ルールを作らなくなりました。それでも、禁止したいことは守られています。

連載「AIの意見を聞かない技術」