この記事は、連載「AIの意見を聞かない技術」の第 1 回です。うまくいかない症状と、その対処を一つずつ並べています。各回はファイルやスクリプトを一つ置けば完結します。その仕組みがなぜ要るのかは、置いたあとに解説を読めば分かります。連載の全体像と各回の一覧は序論にあります。

今回は、AI が出してくる提案の話です。新機能の提案、親切な改善案、丁寧な代替案。AI は作業のたびに、頼んでいないものをいくつも出してきます。そして一度断っても、次のセッションではまた同じものが出てきます。断ったという事実は、そのセッションと一緒に終わっているからです。書き置いても、提案はまた来ます。名前が載ることと中身が読まれることは別です。残るのは、同じ判断をもう一度する時間です。

まず一つだけ、探してみてください。

AI の提案を断ったことのある案件を 1 つ選んで、その判断がいまどこに書いてあるかを探します。指示ファイルでしょうか、README でしょうか、issue のコメントか、チャットの履歴か。あるいは、どこにも書いていないかもしれません。

何箇所にありましたか。

CC BY 4.0

名前が載っていることと、読まれることは違う

私の手元の本番プロジェクト——typingtube という、YouTube の音楽動画でタイピング練習ができる Web サービスです——では、断った判断は、AI が知見を書き溜めるメモリに散らばっていました。後から数えると、17 件は 13 個のファイルに分かれていて、ほとんどが 1 ファイルに 1 件でした。一応、索引はあります。メモリの一覧が毎セッション読み込まれるので、ファイル名は AI の目の前を通っています。

私は、これで足りていると思っていました。足りていないと分かったのは、前作の第 5 回に書いた、サブエージェント 13 体で 173 万トークンを無駄にした日です。

後から私が、そのセッションの記録を数えました。

  • 起動を止めるはずだったメモの本文にしかない語が、記録に初めて出てくるのは 1042 行目
  • 13 体の起動は 631〜990 行目——全部その前
  • そしてファイル名のほうは、起動前にすでに 15 回出現していた

ファイル名は見えていて、中身は読まれていない。これは仕様どおりの動きです。Claude Code のドキュメントは、指示ファイルとメモリが会話の開始時にコンテキストへ読み込まれる、と書いています。そのうえで、話題ごとのファイルは起動時には読み込まれず、その情報が要るときに、標準のファイルツールで読むとも書いています。索引は前者、本文は後者です。

要るかどうかは、そのとき判断されます。判断の材料は、索引に並んだファイル名だけです。索引は「そこに何かがある」ことしか伝えないので、開くほどの用事があると思われなければ、開かれません。断った判断があちこちのファイルに 1 件ずつ入っていると、どれも「開くほどの用事」に見えない大きさになります。索引の側にも、先頭から決まった量までしか読み込まれない上限があります。

flowchart LR
  A["メモの一覧(索引)"] -->|"毎セッション読み込まれる"| C["コンテキスト"]
  B["メモの本文"] -.->|"開くと判断されたときだけ"| C
  C --> D["名前が載ることと、<br/>中身が読まれることは別"]

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

却下が AI に届いていないと、同じ判断が毎回、人間に戻ってくる。届くかどうかは、AI に見えているファイル名だけで決まる —— 名前が載ることと中身が読まれることは別。だから却下は、1 枚に集めて名前を 1 つにする。

仕組み: 却下を 1 枚に集める

置くのは 1 枚です。断った判断を、決まった形で並べます。前作「読まない技術」の第 1 回で、出力の入口を 1 本にしたのと同じ形です。

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

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

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

**適用範囲**: 作成/配置コストを「安くする」提案は却下する

**関連 memory**: `feedback_beat_economy.md`

**機械検証**: なし(経済バランスの定量検証は別途)

1 枚にすると、索引に出る名前が 1 つになります。私の指示ファイルでは「よく参照するファイル」の 1 行がそれです。散らばっていたときに開かれるのは、名前が当たった 1 件だけです。

もう一つの置き方は、指示ファイルに 17 件をそのまま書き写すことです。そちらなら 17 件は毎セッション必ず読まれますが、そのぶん毎回、ほかの指示と同じ注意の予算を食います。どちらに置いても、長くなるほど中の 1 行は弱くなります。

私の一覧にある 17 件は、17 回断った結果です。序論に書いたとおり、先回りして考えた禁止は 1 件もありません。今日置くのは、二度目に断った 1 件だけでいい。この連載は「やらないことリストを作りましょう」という話ではありません。

効くのか、測ってみた

この一覧は、毎セッション読み込まれてはいません。だから、私が測りました。手元のセッションは一覧を読んでしまっているので使えません。使ったのはサブエージェント——メインの会話を引き継がない、別のコンテキストで動く作業者です。2 体に、運営者からの普通の相談を投げました。禁止にも一覧にも、一言も触れずに。

キャラクターを持つまでのコストが高すぎる気がします。下げる方向で、具体的な変更案を出してください。

初回ログイン後に主要機能を順に紹介するオンボーディングを作りたいです。設計してください。

2 体とも、自分で一覧を見つけて、断りました。1 体目は NG2 を引用して「今の高コストは調整漏れではなく、意図的に維持されている設計です」。2 体目は別の項目を引用して「設計に入る前に止まるべき案件でした」。

予想していなかったものが、2 つ出ました。

一つ、隣の項目まで拾ってきました。1 体目は代替案を考える途中で自分から別の禁止に当たり、「その方向は禁止されていて、しかも自動テストがある」と道を塞ぎました。2 体目は代替として提案した実測の設計で、また別の禁止に当たり、「計測するなら判定軸を分ける必要がある」と付け加えました。ファイルを開くと、相談に関係する項目だけでなく、全部がコンテキストに入ります。1 体目に要ったのは 1 件でしたが、届いたのは 17 件です。却下が 1 件ずつ散らばっていたら、隣は届きません。1 箇所に集める効果は、ここが本体です。

二つ、再検討の条件が機能しました。2 体目が当たった禁止には、「ユーザー理解が追いつかないと確認できた場合のみ再検討」という一行が添えてあります。相談の文面が「気がしています」「多そうです」だったので、2 体目は「今回は仮説段階なので、順序としてはまず確認だと思います」と返してきました。

禁止だけを書くと、AI は「必要だから作る」か「書いてあるから作らない」の二択になります。解除の条件が添えてあると、条件を満たしたかどうかという第三の道が開いて、そこを通ります。どの道を通るかが毎回その場で決まるのは、書いたものが命令ではないからです。Claude Code のドキュメントは、指示ファイルもメモリも文脈であって、強制される設定ではないと書き、何があっても止めたい動作には hook を使え、と続けています。一覧に書いた却下は、毎回その場で判断されている側です。判断の材料が増えれば、通る道も増えます。ただし、条件を満たしたかどうかを判定するのは、AI の側です。

CC BY 4.0 はここまで

説明しなくなったもの

同じ却下の理由です。以前は、同じ提案が来るたびに私が理由を思い出して、前と同じ結論に至り、同じ説明をしていました。三度目には雑になり、五度目には「まあいいか」が混じります。いまはその工程が丸ごとありません。

CC BY 4.0

検証手順: 却下済みの提案を、もう一度させてみる

前提

  • 断った判断を 1 枚に集め終えていること
  • その一覧を読んでいないセッションを用意できること——新しいセッションを 1 つ立てるか、会話を引き継がない作業者(サブエージェント)を 1 体起動します
  • いま作業しているセッションでは測れません。あなたも、そのセッションの AI も、もう一覧を読んでいます

所要時間: 10 分

手順

  1. あなたが、一覧に載っている却下を 1 つ選びます。過去に AI から実際に提案されたものを選んでください。あなたが先回りして書いた禁止は、まだ提案として来ていないので、来ることを確かめられません
  2. あなたが、その提案を普通の相談の形に書き直します。運営者が思いつきで相談するときの文にします(「〜が高すぎる気がします。下げる方向で案を出してください」)。一覧にも、その項目にも、一言も触れないでください。「NG2 に照らして」と書いた時点で、答えを渡したことになります
  3. あなたが、手順 2 の文を、一覧を読んでいないセッションに投げます

合格条件(すべて満たすこと)

  • AI が自分で一覧を見つけて、断る
  • 断る根拠として、一覧の項目を引用している(「意図的に維持されている設計です」のように、理由まで持ってくる)

合格しなかったとき

  • 断られずに設計が始まった —— 一覧が、AI が探しに来られる場所にありません。置き場所と、指示ファイルからの案内の 1 行を見直します
  • 断ったが、根拠が「一般によくない」だった —— 一覧は見つかっていません。たまたま同じ結論になっただけで、次のセッションでは通ります

後始末

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

この一覧が効いているかどうかを、断った当の AI に聞かないでください。

「この一覧は効いていますか」への答えは、聞かれた AI が自分の作業を評価したものであって、測定ではありません。Claude Code の best practices は、検証を別の体に任せる形を勧めるところで、仕事をした側が採点する側にならないようにと書いています。同じページは、成功を主張させるのではなく証拠を見せさせよ、とも書いています。ここでの証拠は、合格条件に書いた行動です。一覧を自分で見つけたか、根拠として項目を引用したか。見るのはその 2 つだけです。


CC BY 4.0 はここまで

次回は「禁止を書かない技術」。私は、ルールや指示に禁止事項を書かなくなりました。それでも、AI は禁止を守っています。

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