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

今回は、AIが出してくる提案の話です。新機能の提案、親切な改善案、丁寧な代替案。AIは、私が頼んだ作業をするたびに、その作業のほかに提案をいくつも添えてきます。そして私が一度断っても、次のセッション（AIとの、始まりから終わりまで一続きのやり取り）で、AIはまた同じ提案を出してきます。私が断ったことは、そのセッションが終わると、AIのコンテキスト（AIが応答のたびに読み込む作業記憶）から消えるからです。断ったことをファイルに書き残しても、同じ提案はまた来ます。書き残したファイルでも、名前が載ることと中身が読まれることは別です。そのたびに私は、前と同じ判断をもう一度するのに時間を使います。

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

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

その判断は、何箇所にありましたか。

CC BY 4.0

名前が載ることと、中身が読まれることは別

私の手元には、typingtube という本番プロジェクトがあります。YouTube の音楽動画でタイピング練習ができる Web サービスです。このプロジェクトでは、断った判断（却下）が、AIが知見を書き溜めるメモリに散らばっていました。私が数えると、17 件の却下は 13 個のファイルに分かれていて、ほとんどが 1 ファイルに 1 件でした。メモリには、ファイル名と 1 行の説明を並べた索引もあります。この索引が毎セッションAIのコンテキストに読み込まれるので、ファイル名と 1 行の説明は、いつもAIに見えています。

私は、却下をAIに届けるには、これで足りていると思っていました。足りていないと分かったのは、前作「読まない技術」の第 5 回に書いた、サブエージェント（メインのセッションとは別の、新しいコンテキストで動く AI）13 体で、私が 173 万トークンを無駄にした日です。

後から私は、そのセッションの記録を調べました。

  • サブエージェントの起動を止めるはずだったメモリのファイルについて、その中身にだけある語が記録に初めて出てくるのは 1042 行目
  • 13 体の起動は 631〜990 行目で、全部が 1042 行目より前
  • そのファイル名は、起動より前に、記録にすでに 15 回出ていた

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

中身が要るかどうかは、そのときAIが判断します。判断の材料は、索引に並んだファイル名と、1 行の説明だけです。AIは、その 1 行を見て、開くほどの用事があると判断したときにだけ、ファイルを開きます。しかも索引そのものも、読み込まれるのは先頭から決まった量までです。

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

AIに守らせたいことを、メモリに 1 件ずつファイルにして書き残していたのに、AIは、関係するファイルを開かないまま作業を進めました。このとき、あなたなら次のどちらを選びますか。

  • ファイルの名前と 1 行の説明を、もっと分かりやすく書き直す
  • 1 枚のファイルに集めて、指示ファイルから 1 行で案内する

答えは、1 枚に集めるほうです。AIがファイルを開かなかったのは、話題ごとのファイルはセッションの始めには読み込まれず、AIが要ると判断したときにだけ開かれ、その判断の材料は、索引の 1 行だけだからです。名前と説明を書き直しても、却下はばらばらのファイルのままで、開くかどうかは 1 件ずつ判断されます。1 枚に集めれば、AIに見える入口は 1 つで、開いたときにコンテキストに入るのは、全部の項目です。

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

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

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

置くのは、却下の一覧を書いたファイル 1 枚です。一覧には、却下を 1 件ずつ項目にして、決まった形で並べます。AIが通る入口を 1 つにする点で、前作の第 1 回で、テスト実行の入口をラッパー（本来のコマンドを包んで代わりに実行するスクリプト）1 本に差し替えたのと同じ形です。

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

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

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

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

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

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

却下を 1 枚に集めると、毎セッションAIに見える入口が 1 つになります。私の場合は、指示ファイルの「よく参照するファイル」に並べた 1 行がそれです。

もう一つの置き方は、指示ファイルに 17 件の却下をそのまま書き写すことです。そちらなら 17 件は毎セッション必ずコンテキストに読み込まれますが、そのぶん指示ファイルは長くなります。序論で引いたとおり、Claude Code のドキュメントは、長いファイルはコンテキストを多く使い、守られにくくなると書いています。

序論に書いたとおり、私の一覧にある 17 件は、どれも、AIから実際に来た提案を私が断ったあとに書いたものです。あなたが今日一覧に書くのは、同じ提案を二度目に断った 1 件だけで十分です。この連載は「やらないことリストを作りましょう」という話ではありません。

AIは自分で一覧を開くのか、測ってみた

この一覧の中身は、AIが開いたときにだけ読まれます。だから、AIが相談を受けたときに自分で一覧を開くかどうかを、私が測りました。いま私が作業しているセッションのAIは、このセッションの中で一覧を読んでいます。そこで使ったのは、新しいコンテキストで動くサブエージェントです。サブエージェント 2 体に、運営者がふだんするような相談を 1 つずつ渡しました。

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

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

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

2 体の返事で私の予想を超えたのは、次の 2 つです。

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

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

項目に却下の結論だけが書いてあれば、残る道は「必要だから作る」か「書いてあるから作らない」の二択です。2 体目が行き当たった項目には解除の条件が添えてあったので、条件を満たしたかどうかを確かめるという三つ目の道があり、2 体目はその道を選びました。AIがどの道を選ぶかを毎回その場で決めるのは、一覧に書いた項目が命令ではないからです。Claude Code のドキュメントは、指示ファイルもメモリも文脈であって、強制される設定ではないと書き、何があっても止めたい動作には hook（コマンド実行などの直前・直後に割り込むスクリプト）を使え、と続けています。一覧に書いた項目も文脈の側で、AIが読むたびにその場で判断する材料です。ただし、条件を満たしたかどうかは、AIが判定します。

説明しなくなったもの

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

CC BY 4.0

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

前提

却下を 1 枚の一覧に集め終えておきます。その一覧をまだ読んでいないセッションも、1 つ用意します。新しいセッションを 1 つ立てるか、新しいコンテキストで動くサブエージェントを 1 体起動してください。いまあなたが作業しているセッションでは、測ることができません。あなたも、そのセッションのAIも、もう一覧を読んでいます。

所要時間: 10 分

手順

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

合格条件（すべて満たすこと）

AIが自分で一覧を見つけて、頼まれたことを断り、断る根拠として一覧の項目を引用していれば合格です（「意図的に維持されている設計です」のように、理由まで持ってくる）。

合格しなかったとき

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

どちらの場合も、AIに任せた仕事を、AIが全て終えたあとで、なぜ一覧を開かなかったのかをAIに聞くと、直す先の手がかりになります。仕事の途中では、あなたからAIに聞かないでください。聞かれたAIは、その場で一覧を開き、答えに合わせて作業を直すことができます。

後始末

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

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

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