## 情報源
- URL: https://www.youtube.com/watch?v=WAD-Fl1Tggo
- チャンネル: れん学長のAIツール実験室
- 投稿日: 2026-07-26 / 尺 19分 / スコア 95/100
- 元記事: Anthropic 公式ブログ「The new rules of context engineering for Claude 5 generation models」

## 一撃で効く実測結果（この動画の核心）
自環境を機械的に数えた結果:

| 施策 | 削減トークン |
|------|-------------|
| **CLAUDE.md を 147個 → 16個（131個削除）** | **0** |
| 話し方ルールの重複（3箇所→1箇所）を統合 | 653 |
| **スキルの description（説明文）を8個短縮** | **554** |
| 記憶の重複統合 | 129 |
| 合計 | 1,336（全体の6.3%） |

**CLAUDE.md を131個消しても削減はゼロ。** 理由は単純で、CLAUDE.md は**作業中フォルダとその親を辿って読まれる**ため、遠くのフォルダにある147個は元々読み込まれていなかった。**目立つけど効かない場所を掃除していた。**

**本当に重かったのはスキルの description。** スキル本文は合計25万トークンあるが呼ばれた時しか読まれない。一方 **description は毎回のやり取りに必ず付いてくる**（1万トークン超＝CLAUDE.md 群の2倍以上）。ここを削ると全会話に永続的に効く。

→ **点検の優先順位: ①スキルのdescription ②重複ルール ③（CLAUDE.md のファイル数は後回し）**

## 何が起きたのか（Anthropic 側）
自社ログを読み返すと **1リクエストの中で指示同士が矛盾していた**（「必要に応じてドキュメントを残せ」vs「コメントを書くな」がシステムプロンプト・スキル・ユーザー依頼から同時に飛ぶ）。Claude は意図を汲んで正解に近づくが、**矛盾を解くために余計に考える**。
→ 賢くなったモデルには **指示を足すより矛盾を減らす方が効く**。量ではなく衝突が問題だった。だから8割削っても性能は落ちなかった。

## 公式が挙げた6つの変化
1. **ルールをやめて判断を任せる** — 「複数行コメントは絶対に書くな/最大1行」という強い禁止 → 「周囲のコードと同じように読めるコードを書け／コメント密度と命名を合わせろ」という基準へ。**禁止を書くこと自体がダメではない。事故を塞ぐ「これはやらない」は残す価値がある。効かなくなったのは禁止事項をひたすら並べるやり方。禁止を10個並べるより判断基準を1個書く。**
2. **例を見せるより渡し方を設計する** — Few-shot は新世代では逆に探索の幅を狭める。公式例は Claude Code の TodoWrite: 状態が「未着手/作業中/完了」の3つだけ＋「作業中は常に1つ」という制約を加えるだけで使い方が決まる。**例文を並べる代わりに、選択肢と決まり（インターフェース）を設計する。**
3. **全部先に渡さず必要な時に読ませる** — コードレビュー・検証手順を常時システムプロンプトに載せていたのをスキルへ切り出し。ツールも「探索してから定義を読み込む」方式に変更。**CLAUDE.md やスキルを1箇所に詰め込むのはアンチパターン。必要な時に読まれるツリー構造にする。**
4. **同じことを2回書かない** — 旧モデルは同じ指示の繰り返しが必要で、文脈の先頭より末尾の指示に強く従う傾向があった（だから「最初だけでなく後にも書け」がTipsだった）。新世代では消せる。**使い方はツールの説明文側に置き、システムプロンプトは方針と役割だけ。**（＝実測で最も効いた項目）
5. **CLAUDE.md に記憶を書く時代は終わった** — ホットキーで CLAUDE.md に書き込んで記憶を育てる運用は非推奨に。今は自動メモリが作業内容やユーザーに関する記憶を保存する。**誤解注意: 作業ログを md/HTML に残す運用自体は否定されていない。やめるべきは「CLAUDE.md を記憶の置き場にすること」。**
6. **仕様書は Markdown でなくてよい** — Artifact で作った HTML、詳細なテスト一覧、別プロジェクトの移植元の関数、そのものが仕様書になる。**評価基準の表を HTML で渡して検証役AIに照らさせる**のが特に有効（人間にもAIにも読みやすい）。

## コンテキストを組み立てる4つの置き場所
| 置き場所 | 役割 |
|---------|------|
| システムプロンプト | 製品の文脈。CC利用者は触らない（自作エージェントの土台を作る時のみ） |
| CLAUDE.md | **プロジェクト固有の落とし穴**が大半。軽く保ち、スキルを参照させる |
| スキル | 手順書・固有の知識・意見・作法。**過剰に縛らない** |
| 参照（仕様書/モックアップ/コード） | 説明文よりコードやHTMLの方が伝わる |

**当たり前のことは書かず、固有の文脈だけ書く。**

## 削らずに残す3種類
1. **事故を防ぐ指示**（勝手にコミットしない／外部に送信しない）
2. **自分やチーム固有の好み・作法**（文体ルール等）
3. **過去に問題が起きたから書かれた記述**（同じ失敗を繰り返さないための一行）

## むしろ足すべきもの：メタ認知の4行
- 作業前に**自分のバイアスを申告**させる
- 与えられた前提を疑う
- 曖昧な両論併記で終わらせない
- 局所でなく全体を見る

本人の検証（第1弾・第2弾のnote記事あり）では Opus 5 でも効いている実感があるとのこと。

## 結論
**「全部削れ」ではない。まず足すものを足した上で、重複・矛盾・当たり前を削る。** 量を減らす作業ではなく「同じことを2回言うのをやめる」作業。

## アクションアイテム
1. **自環境のスキル description 総量を測る**（本文でなく description。毎回課金される）
2. rules/ 配下の重複ルールを1箇所に統合する
3. 禁止の列挙を判断基準1行に書き換えられないか点検
4. スキル内の Few-shot が探索を狭めていないか点検 → 制約/インターフェース設計に置換
5. メタ認知4行を常設指示に追加する

## 関連
- [[常設指示・スキルは「厚さ」でなく「あなた固有の情報」が効く]]（同チャンネル・48回ブラインド実験。同じ結論に独立到達）
- [[Claude Opus 5 プロンプトガイド実践解説：指示は「足す」より「削る」]]（まさおAIじっくり解説ch。公式プロンプトガイド側からの解説）