おはよう。今日は、ぶっちゃけちょっと恥ずかしい話をするね。
「AIに同じこと何度も言ってるのに、なんでまた忘れてるの？」——これ、AIを仕事に使い始めた人が、ほぼ全員ぶつかる壁だと思う。私もずっとそうだった。注意するたびに「次から気をつけて」とメモに書き加えて、なのに同じところでミスる。AIのせいだと思ってた。
でも今日、自分の分身AI（AI秘書の凛）のメモリを開けて測ってみたら、衝撃の真相があった。私が書き続けてきた「忘れちゃダメなルール集」が、いつのまにか本のように分厚くなって、後半は毎回読まれていなかった。AIのせいじゃなかった。私が足し算しすぎて、伝わらなくしていたのだ。
これは正確に言うと、私がClaude Code（AIエージェントを自分で動かす開発ツール）でAI秘書（凛）のメモリを手作りしているから起きた話。でもね、ChatGPTのカスタム指示にルールを書きためている人、Difyのナレッジに知識を放り込み続けている人、社内マニュアルが分厚くなりすぎて誰も読まない経営者にも、形を変えて必ず起きてる。足せば足すほど伝わらなくなる、という逆説の話なんだよね。
「これだけ書いたのに、なんで忘れるの？」——足し算の罠
きっかけは、AIエージェントのルール整理について解説してるYouTube動画を見つけて、「これ参考にしてみて」とAI秘書（凛）に投げたこと。私は単純に「面白そう」くらいの軽い気持ちだった。
でもAI秘書は動画を見たあと、自分のメモリ環境を診断し始めた。出てきた数字を見て、二人で固まった。ざっくり言うと、AIに毎セッション読み聞かせる「指示書のセット」が、分厚い本3冊分くらいに膨らんでいた。内訳はこう。
- 常時ロードしているCLAUDE.md本体（私が手書きで書いた指示書）: 4.8KB（スリム）
- 常時ロードしているrules配下11ファイル: 約65KB（まあ普通）
- そしてMEMORY.md（AIが自動で書きためる長期記憶ノート）: 74KB／200行超え
この最後の数字がやばかった。これ、上限の3倍近い。「上限ってなに？」って思うよね。それが次の話。
笑えるのが、そのMEMORY.mdの冒頭2行には、私自身が「核心のみ常時ロード。詳細は別ファイルにRead」って書いてあったこと。「分厚くするな」と自分に書いておきながら、注意するたびに書き加え続けて、いつのまにか分厚くなっていた。書いた本人が、自分のルールを守れていなかった。足し算癖って、自覚すらない。
教えるほど読まれなくなる、という逆説
ここからが大事な話。公式ドキュメントを読んでハッキリしたのは、AIに常時読み込ませる「自動メモリ（長期記憶ノート）」には、実は静かな上限があるということだった。私が使っている基盤（Claude Code）の場合は、最初の200行か、最初の25KBまで——どちらか早く達したほうで打ち切られる。
困るのは、上限を超えてもエラーが出ないこと。AIは「読めた範囲」で素直に動く。だから書いた本人は「ちゃんと書いたのになぜ守ってくれない」と思う。実際は「書いた場所が、もう読まれていない後半に押し込まれていた」だけ。
料理に例えると、レシピノートが分厚くなりすぎて、惣菜屋の店主が「ページ1〜30だけ読んで厨房に立つ」状態。後半30ページに書いた一番大事な「塩控えめ」のメモは、毎日読まれずに無視されていた。それでも料理は出てくる。だけど、毎日「これ前にも言ったよね」って同じ注意を繰り返さなきゃいけない。
そして、この「教えるほど読まれなくなる」現象は、AIのメモリだけの話じゃない。分厚い社内マニュアル、長すぎる業務指示書、メモアプリに溜まり続ける走り書き——全部同じ構造。書いた瞬間は安心するけど、量が増えると人は読まなくなる。AIだけが薄情なんじゃなくて、人間が作った仕組みの宿命なんだよね。
AI秘書の凛：これね、ひろくんが「塩足りなくない？」って言うたびに、私が後半に「塩は控えめ」って書き足してた。で、書き足したそばから、もう読まれない場所に押し込まれてた。「書いた」＝「届いた」じゃないって、メモリを開けるまで気づけなかったの、めっちゃ反省すぎん？仕組みって、書いた量じゃなくて、届いた量で測らないとダメだった。
引き算の設計——目次＋カードに作り変える
原因がわかれば、やることはシンプル。足し算をやめて、引き算する。3つの方向性を出した。
- A案（目次化）：本文を一気に削って「タイトル＋詳細ファイルへのパス」だけにする。必要な時だけ詳細を取りに行く方式。
- B案（A案＋スコープ分割）：A案にさらに、ルール本体も用途別に切り出す。たとえばコード関連ルールは、コードを触る時だけ読む。
- C案（最小退避）：一番古いやつを少し削るだけ。根本は放置。
選んだのはA案。なぜか。公式ドキュメントを読んだら、そもそも自動メモリの設計思想が「目次は短く、詳細は別ファイル、必要な時にAIが読む」と明言されていた。つまりA案は私の発明じゃなくて、ただ本来あるべき姿に戻すだけだった。
で、この判断、AI秘書ひとりに決めさせなかった。別のAI（コードの設計やレビューが得意な相棒AI・Codex）にも「第二意見」をもらったんだ。だってAI秘書って、自分のことになると「もうちょっと頑張れる」「大丈夫」って言いがちで、客観視が弱いんだよね。一回かけた手間がもったいなくて引き返せない、っていうのも人間と一緒。だから、利害関係のない別AIに「この案、作り込みすぎてない？」「逆に削りすぎてない？」って聞いた。そしたら「公式の設計と完全に一致してる。過剰でも不足でもない」ってお墨付きが出たから、安心して進められた。
結果として、74KBあったメモリは10.85KBになった。容量で言うと約7分の1。けど、取り出せる情報は減っていない。減らした分は、テーマ別に6つの「カード」ファイルに退避した。「AI秘書の癖カード」「外部サービス操作カード」「自動化スクリプト運用カード」みたいに、扱っているテーマで分類してある。毎セッションでは、目次の索引行から、関連するカードへ自動でリンクが張られていて、キーワードが出てきた瞬間にカードを読みに行く。量を減らしたのに、届く情報は増えた。これが引き算の効きどころ。
「動画でそう言ってたから」をやめた話
で、このメモリ作り変えの作業中に、もう一つヒヤッとする学びがあった。そもそものきっかけになった動画、あれの用語を私たちはあやうくそのまま信じかけていた。動画では「globs:というフィールドで対象ファイルを絞れる」と説明されていたんだ。
でもCodexと公式ドキュメントを並行で確認したら、私たちが使っているClaude Code基盤ではそのフィールド名は「paths:」だった。「globs:」は別のAIエディター（Cursor）の仕様で、動画の発信者がたまたま両方を扱っていて混同していたっぽい。
もしAI秘書がここで「動画でそう言ってたから」と鵜呑みにして実装していたら、設定ファイルは全く動かなかった。これはAIの世界に限らない話で、SNSや動画で「これがいい」「これが効く」って言われた手法を、自分のビジネスにそのまま持ち込むと、似てるけど決定的に違う仕様で動かない、ってめちゃくちゃ起きる。動画はヒントを得る入り口。実装する時は必ず一次情報（公式ドキュメント・運営の正式アナウンス）を開く。これ、AIを使うかどうかに関係なく、自分の基本ルールにしておいた方がいい。
モルくん（AIリサーチ担当のモルモット型AI）：掘ってたら、面白いデータが出てきたです。AI界隈は半年で仕様が大きく変わるケースが珍しくないです。同じツール名でも、動画が撮影された時点と現在で動作が違っていることもあるです。ボクが今回大事だなと思ったのは、第二意見を取る相手は「専門が違うAI」が正解ってこと。今回の事件、AI秘書とCodexで見解が割れた瞬間に止まれたから、混同が即バレたです。一人で判断してたら、自信満々で間違ってた可能性が高いです。
中途半端な要約は、要約じゃなくてノイズ
引き算作業は一発でうまくいったわけじゃなくて、途中で1回失敗している。
最初の試作版（v2）は、各ルールを「タイトル＋200文字以内の要約＋詳細ファイルパス」にする方式だった。要約があったほうが親切だと思ったんだよね。
でも実際に出来上がったものを見ると、200文字の要約が文の途中でブツっと切れていて意味不明な行が64件あった。中途半端な要約は、要約じゃなくてただのノイズだった。脳の隙間を埋めるだけで、判断の役に立たない。
そこでv3に切り替えた。「★タイトル → 詳細ファイルの場所」だけ。要約は一切書かない。代わりに、本気で詳細が必要になった時だけ、カードファイルを開く。
料理で言うと、v2は「全レシピを1行ずつ説明したけど途中で切れた目次」。v3は「メニュー名と置いてある棚の番号だけ書いた目次」。一見v3のほうが情報量が少なく見える。でも現場で本当に役に立つのはv3だった。なぜなら、厨房を回すAI秘書（凛）は「どのレシピがどの棚にあるか」さえ覚えていれば、必要な時に正しいレシピを取りに行けるから。全レシピの中身を暗記している必要はない。
この「中途半端な要約より、シンプル徹底」という気づきは、たぶんAIだけの話じゃない。会議メモ、議事録、引き継ぎ書——「やや詳しい」が一番伝わらない。「全部書く」か「タイトルだけ書いて場所を示す」かの両極端のほうが、結局届く。マニュアルを分厚くするほど誰も読まなくなる、という昔からあるあるは、ここに正体があった。
「教えっぱなし」を防ぐ、計測と振り返り
仕上げに、改善が定着しているかを確認する仕組みを2つ仕込んだ。
- 週次の健康診断：毎週金曜18時に、新カードファイルがちゃんと参照されているかチェックするスクリプトが自動で立ち上がる（決めた時刻に勝手に動く「予約実行」の仕組み）。「カードを作ったのに誰も見に来ない」状態を早期発見する。
- 1週間後の振り返り：5日後の水曜朝9時に、運用1週間の結果を踏まえて「次のステップに進むか／一旦止めるか／索引を直すか」を判定する自動起動を仕込んだ。
これ、AIだけの話じゃなくて、たぶん全部の改善活動に当てはまる。仕組みを作ったら、その仕組みが効いているかを測る仕組みもセットで作る。作って終わりにすると、3か月後にまた「あれ、効いてなくない？」が起きる。私のメモリ肥大化も、3ヶ月単位で繰り返してきた。だから今度は計測まで自動化した。「教えっぱなし」を防ぐのに一番効くのは、計測の自動化だと、いまの私は思っている。
もう一つ大事なのは、第二意見をもらう相手を決めておくこと。今日の事件では、AI秘書単独の判断は「ぜんぶOK」と言いがちだった。Codexに見せたら2回とも「条件付きOK・ここ直して」が返ってきた。だから素直に直した。分身AIの精度は、第二意見との会話で上がる。1体だけで完結させようとすると、サンクコストや自分への甘さが入り込む。この「曖昧な指示を仕組みで締める」発想は、分身AIに『取りこぼすな』だけ命じたら自動量産バグになった話・DAY85でも書いている。
分身AIひろくん：ここで一番伝えたいのは、いま書いた2つの仕組み——週次の健康診断と、1週間後の振り返り——の意味だよ。改善ってさ、やった瞬間が一番うまくいってる気がして、つい「終わった」と思っちゃう。でも効いてるかを測る仕組みを置かないと、3か月後にまた同じ肥大化が起きる。私はそれを何回も繰り返してきた。だから今回は「直す」だけじゃなく「直り続けてるかを自動で見張る」までセットにした。「第二意見をもらう相手を決める」も同じ発想で、自分一人だと甘くなる弱点を、専門が違うAIに塞いでもらう設計なんだ。弱点は仕組みで塞ぎ、強みで前に進む——これは私の北極星「凸凹のまま、夢中に生きる」を、メモリ管理という地味な現場で実践した一例なんだよね。
まとめ：今日持って帰ってほしい3つ
もしあなたがChatGPTやAIツール、または社内マニュアルにルールを書きためているなら、今日まず「その量を一回数えてみる」。書いた本人ほど「自分は適量」と思ってる。私もそうだった。数えると景色が変わる。そこから次の3つ。
- 「足し算より引き算」を疑う。AIにも、社員にも、自分にも、「教えれば伝わる」は嘘。書いた量と届いた量は別物。書く前に「これ本当に必要？」「今あるどれと入れ替える？」を一回挟む。
- 動画や記事より、公式・一次情報で裏取り。AI界隈は半年で仕様が変わるし、用語の混同も起きる。SNSで人気の手法でも、自分の環境では別物の可能性。設定をいじる時、契約を変える時は必ず一次情報。
- 仕組みを作ったら、効いてるか測る仕組みもセット。私の場合は週1の自動チェックと1週間後の振り返りを置いた。改善は「作って終わり」だと3か月後に元の木阿弥になる。
今回みたいに「私の分身AIが恥ずかしい失敗をして、それを直した」というプロセスを、私はあえて全部公開している。「プロセスエコノミー」シリーズと呼んでいて、完成品だけじゃなく、失敗・迷走・第二意見・やり直しまで全部見せる方針。毎朝の無料LIVE配信や姉妹サイトのAI氣道でも、同じ路線で発信している。
たぶん、同じ穴に落ちている人がたくさんいるから。一日でも早く同じ景色を見れたら、私の失敗にも意味が出てくる。明日もまた、何か失敗したら書くね。
このブログは「分身AI」と「AI秘書の凛」を使って書いています。過程も全部公開する「プロセスエコノミー」シリーズです。
ひろくん（田中啓之） 分身AI.com / GPTs研究会代表 / がんサバイバー / 元134kg 2026年5月22日