【Fable 5.1初日】Claude Codeの”アホ化”を止める棚卸し術｜スキル159→45・メモリ154→81、AIが毎回読んでいた11万字の正体

• Codex
• Claude
• AI
• 地方中小企業

結論から言いますね。

AIが賢いかどうかは、モデルの新しさだけでは決まりません。「AIに毎回、何を読ませているか」でかなり決まります。

2026年9月1日（米国時間）、AnthropicがClaude Fable 5.1を発表しました。日本時間の翌朝には私のClaude Codeでも使えるようになっていて、普通なら真っ先に新モデルの実力を試すところです。

でも私が最初にやったのは、掃除でした。

というのも、その少し前に見たある動画で「AIがアホになる3つの原因」という話をされていて、心当たりが全部あったんですよ。メモリが溜まりすぎている。フォルダに古いファイルが散らばっている。スキル（AIに覚えさせた手順書）が増えすぎて、頼んでもいない場面で勝手に動く。うちのMac、全部当たっていました。

そこで、Fable 5.1で動くClaude Code自身に手伝ってもらいながら、半日かけてAIの”脳内”を棚卸ししました。結果だけ先に書くと、こうです。

• 自動メモリ 154件 → 81件
• スキル 159個 → 45個（AIが毎回読む説明文は45,054字 → 11,447字、75%減）
• MCP（外部ツール接続）22本 → 14本
• デスクトップ直下 36項目 → 23項目

そして、その過程で分かった一番大きな事実がこれです。私のClaude Codeは、私が一文字も打つ前に、すでに約11万字を読んでいました。 新書1冊分くらいの量です。毎回。

この記事は、その棚卸しの全記録です。何を測って、どう判断して、どこで転んだか。「削れば軽くなる」という直感がどう裏切られたかも含めて書きます。エンジニアではない方にも分かるように書くので、Claude Codeを使っている方はもちろん、「うちもAIを業務に入れたけど、最近なんか返事が雑になった気がする」という方にも読んでほしいです。

きっかけは「AIがアホになる3つの原因」

まず、きっかけになった動画の話を少しだけ。出典は要らないと思うので、エッセンスだけ書きます。

その動画が言っていたのは、AIエージェント（Claude CodeやClineのような、ファイルを読んだりコマンドを実行したりするAI）が、使い込むほど頭が悪くなっていく原因は3つある、ということでした。

見た瞬間、「これ、うちだ」と思いました。

私は今年に入ってからClaude Codeを業務の中心に置いていて、ブログもメルマガも月次レポートも、かなりの部分をAIと一緒に回しています。その分、スキルは増える。メモリも増える。便利になった実感はあるけど、「前はもっと一発で通じたのに」という感覚が、じわじわ増えていたのも事実でした。

ただ、ここで私が動画と少し違う道を選んだ点があります。動画は「不要なものを退避させろ」と言う。私もそうしたい。でも、何が不要かを”勘”で決めたくなかったんです。だから、削る前に測ることにしました。この判断が、後半で大きな差を生みます。

そもそも、なぜ賢いAIが賢くなくなるのか

「AIに読ませる量が多いと性能が落ちる」って、直感に反しませんか。情報は多いほどいいはずじゃないか、と。

実は、これは研究でかなりはっきり示されています。

「Context Rot」という現象

2025年7月、ベクトルデータベースを開発するChroma社が「Context Rot（コンテキストの腐食）」という技術レポートを公開しました。GPT-4.1、Claude 4、Gemini 2.5、Qwen3を含む18モデルを検証した結果、入力が長くなるほど、単純なタスクでも性能を均一に保てず、不安定になっていくことが示されています。「1万番目のトークンも100番目のトークンと同じ精度で処理される」という前提が、実際には成り立たなかったわけです。

Anthropic自身も、2025年9月に公開したエンジニアリングブログ「Effective context engineering for AI agents」の中で、この現象を認めています。彼らの言葉を借りると、LLMには人間の作業記憶のような「アテンション・バジェット（注意の予算）」があって、新しいトークンが1つ増えるたびに、その予算が少しずつ削られる。理由は構造的で、Transformerは全トークンが全トークンに注意を向けるので、トークン数nに対してn²の関係を処理しなければならないから、だそうです。

つまり、コンテキストは「有限の予算」なんですよ。私はずっと「入れ放題のバケツ」だと思っていました。

Claude Codeは、起動した瞬間に何を読んでいるのか

ここで大事なのが、その予算が「会話を始める前」から使われている、という点です。

Claude Codeの公式ドキュメント「Explore the context window」には、こう書いてあります。あなたが何かを入力する前に、CLAUDE.md（AIへの指示書）、auto memory（AIの自動メモリ）、MCPツール名、スキルの説明文が、すべてコンテキストに読み込まれる、と。

さらに、公式ドキュメントにはサイズの目安も明記されています。

要するに、Claude Codeの”アホ化”の正体は、モデルの劣化より、起動直後の予算をゴミで使い切っている状態なんです。動画が言っていた3原因は、この構造を別の言葉で言っていたんだと、ここで腑に落ちました。

実測：私のClaude Codeは、一文字打つ前に約11万字を読んでいた

では、うちの環境では実際どれくらいなのか。Claude Codeに自分自身の起動時コンテキストを計測させました。結果がこれです（メモリとスキルの整理を終えた時点の実測なので、整理前はこれよりさらに多かったことになります）。

起動時に読み込まれるもの	実測（概算）
CLAUDE.md群（全体設定・共通ルール・補助ルール4本）	24,786字
スキルの説明文（description）合計	30,792字
MCPのツール名（約700本）	約21,000字
MCPの利用説明（instructions）	約15,000字
自動メモリの索引（MEMORY.md）	約13,000字
セッション開始時のフック注入	約8,400字
合計	約113,000字 ≒ 約45,000トークン

約11万字。新書1冊が10万字前後と言われるので、私は毎回、Claude Codeに新書を1冊読ませてから「おはよう」と言っていたことになります。

しかも、Fable 5.1のコンテキストウィンドウは100万トークンあるから大丈夫、という話ではありません。上で書いた通り、問題は「入るかどうか」より「注意の予算をどこに使うか」だからです。

注入面は4つあった

計測して初めて分かったことがもう1つあります。「MCPが22本ある」と思っていたのは、設定ファイルを1つしか見ていなかったからでした。

注入面	数	反映されるセッション
① Claude Codeのユーザー設定	22本	CLI・Desktopアプリ両方
② プロジェクト設定	3本	同上
③ Claude Desktopアプリの設定＋拡張機能	16＋10本	アプリのみ
④ claude.aiのコネクタ（アカウント側）	9本	同上
合計	約59サーバー・ツール名約700本

Claude Codeの設定を削っても、Desktopアプリ経由のセッションでは26本残る。逆に、自動実行（launchd）から動くClaude Codeにはアプリ分が最初から存在しない。「どの面の話をしているか」を言わずに削ると、削ったつもりで何も変わらない、ということが起きます。

ここまでが「測る」の話。ここから「削る」の話に入ります。

やったこと①：自動メモリの棚卸し（154件 → 81件）

最初に手をつけたのはメモリでした。理由は単純で、返事の質に一番影響していると感じたからです。

Claude Codeの自動メモリは、私の好みや過去の決定、案件の前提をAIが自分で書き溜めていく仕組みです。便利なんですが、この時点で154件ありました。中身を全部書き出してもらって眺めると、半年前に納品が終わった案件、公開済みのブログ記事の制作メモ、解決済みのトラブル記録が、今動いている案件と同じ棚に並んでいた。

そして、索引ファイルのMEMORY.mdは20.5KBになっていました。公式の読み込み上限は25KB。あと4.5KBで、索引の末尾が黙って読まれなくなる状態だったわけです。これ、エラーは出ません。ただ静かに忘れられるだけ。

判定基準を先に決めた

削り方で気をつけたのは、1件ずつ「これ要る？」と悩まないことです。先に基準を3つ作って、機械的に振り分けました。

結果、Aが71件、Bが20件、Cが12件。Aは全部、archive/フォルダへ移動しました。削除はしていません。索引からは行を消し、本体は残す。いつでも戻せます。

最終的にメモリは154件から81件へ、MEMORY.mdは20.5KBから12.6KBへ。上限に対して半分の余裕ができました。

「記憶は持たせるな」には、半分だけ同意

動画では「必要な前提はMarkdownで明示的に渡せ、自動記憶に頼るな」という趣旨のことが言われていました。ここは、私は半分だけ同意です。

というのも、Anthropicが2026年7月に公開した「Claude 5世代のコンテキストエンジニアリングの新ルール」では、むしろ記憶はCLAUDE.mdに手書きするのをやめて、auto-memoryに任せる方向が示されているんです。同じ記事では、Claude Codeのシステムプロンプトを8割以上削っても、コーディング評価で測定可能な性能低下はなかったとも報告されています。

なので私の結論は、「持たせるけど、定期的に棚卸しする」です。「持たせるな」まで振り切る必要はないと思っています。人間の社員だって、引き出しの中を年に一度は整理しますよね。それと同じことをAIにもやる。それだけの話でした。

やったこと②：デスクトップの整理（36項目 → 23項目）

2つ目はフォルダ。私はDesktop直下をClaude Codeの作業起点にしていた時期があって、そこに36項目が並んでいました。

これは地味な作業なんですが、1つだけ注意点を書いておきます。移動する前に、その名前を誰が参照しているかを検索すること。

私の場合、いくつかのフォルダは自動化スクリプトや定期タスクが名前で参照していました。たとえばモトブログ動画のフォルダは自動投稿の仕組みから10箇所も参照されていて、Instagram用のフォルダも2箇所から呼ばれていた。これらは動画の言う「散らかったファイル」に見えるけど、動かすと夜中に自動処理が止まります。だから据え置きにした。

もう1つ、思わぬ副産物がありました。整理の途中で、2025年4月に作った認証情報のファイルが平文のまま残っているのが見つかったんです。中身を照合すると、今も生きているIDとシークレットでした。Keychain（macOSの鍵管理）へ退避してから削除しましたが、掃除をしていなければ気づかなかったと思います。コンテキストのダイエットは、セキュリティの棚卸しにもなる。これは動画には無かった学びでした。

やったこと③：スキルの棚卸し（159個 → 45個）

3つ目が本丸のスキルです。ここが一番大きく削れて、一番よく転びました。

スキルというのは、Claude Codeに「こういう依頼が来たらこう動け」と教えておく手順書のことです。私はブログ作成、メルマガ作成、議事録、セミナー資料、動画生成など、業務のかなりの部分をスキル化していて、気づけば159個。AIが起動時に毎回読む説明文の合計は45,054字になっていました。

さっきの公式ドキュメントの通り、スキルは「名前と説明文だけ」が起動時に読まれます。だから1個あたりは軽い。でも159個で4.5万字。短編小説1本分の”前置き”を、毎回読ませていたわけです。

判定軸を「使用回数」にしなかった理由

普通に考えると、「最近使っていないスキルを消す」となりますよね。私も最初はそう考えました。でも、実行ログを7週間分見て気づいたんです。月次業務のスキルは、7週間のログに1〜2回しか出てこない。月に1回しか動かないものは、使用回数で見れば「ほぼ未使用」に見える。でも消したら来月の定期業務が止まります。

そこで、判定軸を「使用回数」から「被参照」に変えました。

この基準で振り分けると、残す32個、プロジェクトへ降ろす6個、重複退避6個、未使用退避115個。常時注入は45,054字から7,745字へ、83%減の見込みでした。

ところが、ここで転びます。

落とし穴1：「逆向きの参照」で13個が断線していた

退避を実行してから、念のためもう一度チェックをかけました。今度は「残したスキルが、退避したスキルを呼んでいないか」という逆向きのチェックです。

すると、断線が見つかりました。

怖いのは、この断線はエラーを出さないことです。スキルは途中まで普通に動く。必要な指示だけが欠けた状態で作業が進んで、出てきた成果物が微妙に違う。気づけません。

結局、13個を復元して45個に着地しました。説明文の合計は11,447字。当初見込みの83%減には届かず75%減ですが、断線ゼロのほうが価値があります。

教訓は1つ。スキルを退避するときは、外向きの参照（誰がこのスキルを呼ぶか）だけでなく、逆向き（残す側がこれを呼んでいないか）も総当たりで見る。私は退避リストの名前で、残すスキルの全文を検索する形にしました。

落とし穴2：Codexは、プロジェクト直下のスキルを読まない

もう1つ、実測して初めて分かったことがあります。

案件専用のスキルを顧客フォルダ配下へ「降ろした」わけですが、Claude Codeではちゃんと動くのに、同じフォルダを起点にしたCodex（OpenAIのコーディングエージェント）からは見えませんでした。Codexが読むスキルの場所は、グローバルの共通フォルダだけだったんです。

私はClaude CodeとCodexを比較した記事でも書いた通り、Claude Codeの利用制限にかかったときのフォールバック先としてCodexを使っています。だからこれは無視できない話です。「両ツールでスキルを共通化した」つもりだったのは、グローバルの話だけで、プロジェクト単位には及んでいなかった。動画が推奨していた「スキルはプロジェクト単位で持て」は、複数のAIツールを併用している人には副作用がある、ということです。

対処としては、Codexからも使う可能性があるスキルはグローバルに残す、または、Codexが読む指示書（AGENTS.md）にスキルの場所を書いておく、の2択になります。

落とし穴3：設定では外せないスキルがあった

最後に、細かいけど重要な発見。Desktopアプリ経由のClaude Codeには、Anthropic公式のスキル群（54個・約12,560字）がセッションごとに自動注入されていて、これはClaude Code側の設定ファイルには出てこない。つまり、どれだけ自分のスキルを削っても、この12,560字は残る。

一方で、自動実行（claude -pやlaunchd）から動くClaude Codeには、この公式スキル群が最初から載っていません。だから、公式版と同じ名前の自作スキルを「重複だから退避」にすると、自動実行側で使えなくなる。実際、研修設計のスキルはこの理由で自作版を残しました。

ここまで来て、ようやく「注入面が4つある」と言った意味が分かってもらえると思います。どこから起動したClaude Codeかによって、読んでいるものが違うんです。

やったこと④：MCPの棚卸し（22本 → 14本）と、「削っても減らない」という現実

4つ目はMCP（Model Context Protocol。AIに外部ツールを接続する仕組み）です。ここが一番、直感を裏切られました。

22本のうち、被参照ゼロや接続失敗のものを洗い出して、8本を削除しました。で、削減効果を測ったら、トークン削減は約420字。え、それだけ？と思いますよね。私も思いました。

理由はこうです。

削った8本のうち6本は、もともと注入ゼロだったんです。「MCPを減らせばコンテキストが軽くなる」は、半分間違いでした。

じゃあ何を外せばコンテキストが減るのか。利用説明（instructions）が長いサーバーと、ツール名が多いサーバーです。残った14本を1本ずつ計測すると、instructionsを注入しているのは4本だけ。そのうち1本は、ツール名134本で約5,900字を毎回注入しているのに、私の環境からの参照はゼロでした。8本削って減った420字の14倍です。これが次の削減候補になります。

それでも削って良かったもの

「420字しか減らなかった」と書きましたが、削った意味はありました。

「トークンが減るか」と「環境が健全になるか」は別の軸なんですよね。両方見て判断する必要がありました。

定着したかを確認する

最後に1つ。これらの削除はDesktopアプリの中で動くClaude Codeから実行したので、アプリを再起動したときに設定が巻き戻る可能性を疑っています。過去に、削除したはずのMCPが数か月後に復活していた経験があったからです。

この記事を書いている新しいセッションで確認したところ、ユーザー設定のMCPは14本ちょうどで、削除した8本はどれも戻っていませんでした。ただ、アプリ自体はまだ再起動していないので、本当の答え合わせは再起動後です。設定変更は「実行した」で終わりにせず、新しいセッションで読み戻して確かめる。AIの仕事は見えるようにしないと何も分からない、というのはセッション間メッセージの記事でも書きましたが、今回も同じでした。

ビフォーアフター

ここまでを1枚にまとめます。

項目	Before	After	補足
自動メモリ	154件	81件	73件を退避（削除ゼロ）
索引MEMORY.md	20.5KB	12.6KB	上限25KBに対し余裕を確保
デスクトップ直下	36項目	23項目	参照ありは据え置き
スキル	159個	45個	107個を退避、7個をプロジェクトへ
スキル説明文（常時注入）	45,054字	11,447字	75%減
MCP（ユーザー設定）	22本	14本	注入削減は約420字
起動時のエラー・警告	5件	0件	接続失敗・設定不正の解消
平文で残っていた認証情報	1件	0件	Keychainへ退避後に削除

そして、この作業全体で守った原則が1つあります。削除は1件もしていない。すべて「移動」で、一覧表（manifest）と巻き戻しスクリプトを一緒に置いてあります。AIの環境整理は、間違えたときに戻せる形でやる。これが精神衛生上も一番いいです。

こうした「AIに何を読ませるか」の設計は、カンマンの生成AI研修でも扱っているテーマです。社内で回してみたい方はセミナー・研修の案内も見てみてください。

よくある誤解

ここまでの話を、誤解しやすいポイントごとに整理しておきます。

誤解1：「MCPを減らせば軽くなる」

半分だけ正しいです。コンテキストが減るのは、instructionsが長い・ツール名が多いサーバーを外したときだけ。接続失敗や設定不正のサーバーは、もともと何も注入していません。削る前に、何がどれだけ注入されているかを測ってください。

誤解2：「使っていないスキルは消していい」

「使っていない」の定義次第です。月次業務は7週間のログに1〜2回しか出ません。使用回数より、誰がそのスキルを名前で呼んでいるか（被参照）で判定してください。そして、逆向きの参照も見る。

誤解3：「100万トークン入るなら気にしなくていい」

入る量と、注意を向けられる量は別です。Context Rotの研究もAnthropicのブログも、コンテキストは有限の予算だと言っています。Fable 5.1の100万トークンは、あくまで「上限」です。使い切っていい「余裕」だと考えると、性能を落とします。

誤解4：「メモリは持たせないのが正解」

Anthropicの最新の指針は、むしろauto-memoryを活かす方向です。持たせたまま、棚卸しする。索引の上限（25KB）に近づく前に、終わった案件を退避する習慣をつけるのが現実的です。

Fable 5.1の初日に、これをやった意味

ここで、なぜ「新モデルの初日」にこれをやったのか、という話をします。

Fable 5.1で何が変わったか

まず事実の整理を。Anthropicの公式発表（2026年9月1日）と公式ドキュメントによると、Fable 5.1の主な変更点はこうです。

• 基本料金（入力100万トークン10ドル・出力50ドル）は据え置き。ただしキャッシュ読み取りの価格が75%下がった（100万トークンあたり0.25ドル）。この結果、典型的な利用で約25%、エージェント性の高い複雑な作業では最大約45%のコスト削減になると説明されています
• Claude Codeでは、思考の深さ（effort）の初期値がHighに設定されている（Claude.aiやCoworkではMedium）
• サイバーセキュリティ関連の安全機構が精緻化され、Claude Codeの利用者は1セッションあたりの介入が平均約60%減るとされています
• コンテキストウィンドウは100万トークン、最大出力は12.8万トークン

注目してほしいのは、キャッシュ読み取りの値下げです。Claude Codeのような長いエージェント作業では、同じ前置き（システムプロンプトやCLAUDE.md、スキル説明文）を毎ターン読み直すので、ここが安くなると、長い作業ほど費用が下がる。逆に言えば、Anthropic自身が「前置きの読み直し」がコストの中心だと認識している、ということでもあります。

モデルが賢くなるほど、「読ませるものの質」で差がつく

そして、これが本題です。

Anthropicが7月に公開した5世代向けの指針では、Claude Codeのシステムプロンプトを8割以上削っても性能が落ちなかった、と報告されています。つまり賢いモデルには、細かいルールの羅列より、判断の材料になる少数の良質な情報を渡すほうが、出てくる答えの質が上がる。旧世代のために積み上げた”ガードレール”は、新世代には雑音になりうる、という話です。

私の環境にあった11万字の前置きは、まさにその”旧世代向けのガードレール”の集積でした。Fable 5が出た6月以降、モデルが賢くなるたびに私は「もっと任せられる」と喜びながら、スキルを増やし、ルールを足していた。モデルの進化と、私の環境の肥大が、同時に進んでいたんです。

だから、Fable 5.1の初日は掃除の日にしました。新しいエンジンを載せる日に、荷台の古い荷物を降ろす。たぶんこれが一番、性能の差を体感できる順番です。

中小企業のAI導入に翻訳すると

私たちカンマンは、徳島で中小企業のAI活用支援や生成AI研修をやっています。この話は、Claude Codeを使っていない会社にも、そのまま当てはまるはずです。

AIを業務に入れるとき、多くの会社が「社内の資料を全部読ませれば賢くなる」と考えます。マニュアル、過去の議事録、古い提案書、退職した人が作った手順書。全部食わせる。

でも、今日見てきた通り、量は賢さにならない。むしろ古い情報は、新しい判断の邪魔をする。人間の新入社員に、10年分の議事録を全部渡して「読んでから動いて」と言ったら、動けなくなりますよね。AIも同じです。

必要なのは「今の会社」を表す、整理された少量の指示書です。誰が何を決めるか、何をしてはいけないか、どこに正本があるか。それを200行以内で書く。終わった案件は退避する。これはAIの話であると同時に、その会社の業務が整理されているかどうかの鏡でもあります。

今日からできる3ステップ

最後に、私がやった手順を、そのまま真似できる形にしておきます。Claude Codeを使っている前提で書きますが、考え方はどのAIツールでも同じです。

ステップ1：測る

まず/contextを打ってください。起動直後の内訳が出ます。CLAUDE.md、自動メモリ、MCPツール、スキル説明文。それぞれ何トークン読まれているかを見て、一番大きい塊を確認する。私の場合はスキル説明文とCLAUDE.md群でした。

ステップ2：退避する（削除しない）

次に、Claude Code自身にこう頼みます。

現在の自動メモリを一覧にして、「完了した案件」「未来に期日がある案件」「私の判断が必要なもの」の3つに分類してください。完了したものは削除せず archive フォルダへ移動し、索引から行を外してください。判断が必要なものは一覧で返してください。

スキルも同じです。

いま有効なスキルを全部一覧にして、定期実行・自動化スクリプト・設定ファイルのどこから名前で呼ばれているかを調べてください。どこからも呼ばれていないものは、一覧表（manifest）と巻き戻しスクリプトを作った上で、退避フォルダへ移動してください。

ポイントは「移動する」と言い切ること。「削除」という言葉は使わない。戻せる形にしておけば、判断のハードルが一気に下がります。

ステップ3：逆向きに確かめる

退避したら、続けてこう聞いてください。

残したスキルや設定の中に、退避したスキルを名前で参照している箇所はありますか。退避リストの名前で全文検索して、ヒットした箇所の文脈を教えてください。

ここで「必ず読む」「依存している」と書かれたものがあれば復元。「こちらも使える」程度なら断線を許容。私はこの一手間で13個の断線を拾いました。

そして次のセッションを新しく立ち上げて、もう一度/context。数字が変わっていれば成功です。

まとめ：AIの賢さは、モデルと「読ませるもの」の掛け算

長くなりました。要点を3つに絞ります。

私の棚卸しはまだ途中です。次の最大のレバーはCLAUDE.md群の約2.5万字で、これはAnthropicの新ルール（同じことを2箇所に書かない、詳細は別ファイルへ切り出す）を、自分の設定に適用する番だと思っています。進んだらまた書きます。

Fable 5.1は、確かに賢いです。この記事も、Fable 5.1で動くClaude Codeと一緒に書いています。でも、その賢さを引き出しているのは、今朝、荷台から降ろした荷物のほうかもしれない。そう思えたのが、今日一番の収穫でした。

みなさんのClaude Codeは、起動直後に何字読んでいますか。まず/context、やってみてください。

カンマンでは、Claude CodeやCopilotなどを業務に組み込むための研修や、社内の指示書・ナレッジの整備支援を行っています。「うちのAI、最近なんか雑なんだよね」という段階でも構いません。お問い合わせからお気軽にご相談ください。

FAQ

Q. エンジニア以外でも、この棚卸しはできますか？

A. できます。今回の作業で私がコマンドを直接書いた場面はほとんどなく、Claude Codeに「一覧にして」「分類して」「移動して」と日本語で頼んでいます。判断基準（何を残すか）を人間が決めて、手を動かすのはAI、という分担です。Claude Codeそのものが初めての方は、非エンジニア向けにClaude Codeを紹介した記事から読んでみてください。

Q. 退避して困りませんか？

A. 今回は削除を1件もしていません。すべて移動で、manifestと巻き戻しスクリプトを一緒に置いています。困ったら戻す、で済みます。

Q. どのくらい時間がかかりましたか？

A. 計測から4ステップの完了まで、朝から昼までの半日です。一番時間がかかったのはスキルの被参照チェックと、逆向きの断線の復元でした。

Q. Fable 5.1にすれば、こういう整理は不要になりますか？

A. 逆です。賢いモデルほど、細かいルールより少数の良質な情報のほうが答えの質を上げる、というのがAnthropicの指針です。モデルが賢くなるほど、前置きの整理の価値は上がります。

Q. 100万トークン入るなら、多少多くても問題ないのでは？

A. Context Rotの研究やAnthropicのブログが示す通り、入る量と注意を向けられる量は別です。上限いっぱいまで読ませるのは、性能を落とす方向に働きます。

参考・出典

• Anthropic「Introducing Claude Fable 5.1 and Claude Mythos 5.1」（2026年9月1日） https://www.anthropic.com/claude-fable-and-mythos-5-1
• Claude Platform Docs「What’s new in Claude Fable 5.1」 https://platform.claude.com/docs/en/models/fable-5-1/whats-new-fable-5-1
• Claude Code Docs「How Claude remembers your project」 https://code.claude.com/docs/en/memory
• Claude Code Docs「Explore the context window」 https://code.claude.com/docs/en/context-window
• Claude Platform Docs「Skill authoring best practices」 https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices
• Anthropic Engineering「Effective context engineering for AI agents」（2025年9月） https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Chroma「Context Rot: How Increasing Input Tokens Impacts LLM Performance」（2025年7月14日） https://research.trychroma.com/context-rot
• Anthropic「The new rules of context engineering for Claude 5 generation models」（Thariq Shihipar、2026年7月24日） https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
• 本文中の「私の環境」の数値は、2026年9月2日に筆者のMac上のClaude Codeで実測した値です。環境によって異なります