コンテキストエンジニアリングとは何か
まず用語をほどく。プロンプトはいま打った一行だ。コンテキストはその一行がモデルに届くとき一緒に運ばれる全部である。システムプロンプト、CLAUDE.md ファイル、スキル、メモリ、その他の出所から集まった束であり、自分のプロンプトはその束の最後の一行にすぎない。
原文の言い方が正確だ。メッセージを送るとき、プロンプトはモデルが受け取るコンテキストのごく一部でしかない。その束を設計することがコンテキストエンジニアリングであり、結果の質を大きく左右する。
たとえるなら、プロンプトは今日新人に渡した業務指示で、コンテキストはその新人が抱えているマニュアル全体だ。指示がどれほど明確でも、マニュアルがぐちゃぐちゃなら成果物もぐちゃぐちゃになる。
そしてこのマニュアルには賞味期限がある。去年のモデルと今日のモデルは同じではないからだ。新人用マニュアルを十年目の人に握らせても助けにならず、むしろ邪魔になる。今回の発表の要点はまさにそこにある。
何が、どれだけ変わったか
Anthropic は Claude Opus 5 や Claude Fable 5 のような最新世代を対象に、Claude Code のシステムプロンプトから 80% 以上を削除し、コーディング評価で測定可能な性能低下はなかったと述べている。原文の冒頭段落そのままだ。
会社が自ら付けた名前は「Unhobbling Claude」である。足枷を外すという意味で、システムプロンプトと CLAUDE.md とスキルの三か所でモデルを過剰に制約していた、という自己診断だ。
変わったのは六組。原文は「かつては」と「いまは」を並べて示している。
| かつて | いま |
|---|---|
| 規則を与える | 判断に委ねる |
| 例を与える | インターフェースを設計する |
| 先に全部入れる | 段階的開示を使う |
| 同じことを繰り返す | ツール説明にだけ書く |
| CLAUDE.md にメモリを溜める | 自動メモリに任せる |
| 簡単な仕様を渡す | 豊かな参照を渡す |
規則一 — 規則を与えず判断に委ねる
古いシステムプロンプトにはこうあった。「コードでは既定でコメントを書くな。複数段落の docstring や複数行のコメントブロックは絶対に書くな。短い一行が最大だ。」
問題は、この種の規則が常に正しいとは限らないことだ。本当に複雑なコードには長いコメントが要ることがあるのに、絶対に書くなと釘を刺せば必要なときも書けない。古いモデルは判断力が足りず、この副作用を飲んででも規則で縛る必要があった。
いま残っているのは一行だ。「周囲のコードのように読めるコードを書け。コメント密度・命名・慣用を周囲に合わせよ。」十行の禁止条項が一行の基準になった。
自分の CLAUDE.md を開いてみてほしい。「絶対にするな」で終わる文が何行かあるはずだ。数か月前はそれが推奨だった。その相当部分はいま消したほうが性能に良い。
規則二 — 例ではなくインターフェースを設計する
ツールを作るときの旧来の定石は、使い方の例を多く添えることだった。この場面ではこう、あの場面ではこう、という具合に。
ところが最新モデルでは、例がかえって探索空間を囲い込む。原文の言い方では、例を与えることが実際には特定の探索空間へモデルを制約する。基準として渡したものが柵になるわけだ。
そこで新しいやり方は、説明を減らしてツール自身に語らせることだ。原文が挙げる例はやること管理ツールである。状態を pending・in_progress・completed の三つの列挙で定義しておけば、それだけでどう使うかが浮かび上がる。さらに「進行中は一つだけ保て」と一行足せば、望む振る舞いまで定義できる。
よくできたドアハンドルは、説明書がなくても押すか引くか分かる。説明書に費やす時間をハンドルを良くすることに使え、という話だ。
規則三 — 先に全部入れず、必要なときに取り出させる
段階的開示と呼ぶ。必要なコンテキストを必要なタイミングで読み込む方式だ。
Claude Code 自身がそう変わった。コードレビューや検証方法のように、常に必要ではないが必要なときには決定的な情報を、システムプロンプトから抜き出してそれぞれのスキルに移した。ツールも同じで、一部は遅延読み込みになっており、エージェントは ToolSearch で完全な定義を探してからでないと使えない。おかげでツールを増やしても普段はコンテキストを食わない。
CLAUDE.md も同じ方向だ。倉庫ではなく受付に置く。このリポジトリが何かを短く書き、検証はこのファイル、デプロイはあのファイルと指し示すだけにする。詳細は別ファイルやスキルに割って、その作業のときだけ開かせる。
では CLAUDE.md に残すものは何か。原文はトークンの大半を gotcha に使えと言う。落とし穴のことだ。たとえばこのリポジトリは型を一つの大きなファイルだけに集めている、といったもの。逆に、ファイル構成を見れば分かる自明なことは書くなと釘を刺す。それはモデルがすでに見られる。
規則四・五 — 繰り返しを消し、メモリは任せる
古いモデルは会話が長くなると前を忘れた。だから重要な指示は何度も書くのが定石で、Anthropic 自身も同じツールの使い方をシステムプロンプトとツール説明の二か所に書いていた。
最新モデルは一度言えば分かる。そこで重複を取り除き、ツールの使い方はツール説明にだけ残した。各自の CLAUDE.md でも同じ規則が二度三度出てくる箇所があるはずで、消せばトークンが減り性能が上がる。
メモリも手がかからなくなった。以前は覚えさせたい内容を人が直接保存していた。チャット欄に # で始まる行を書くと CLAUDE.md に直接書き込まれる近道がその用途だ。いまは作業と利用者に関わるものをモデルが自分で保存する。
ただし自動という言葉は、一つひとつ面倒を見る必要がないという意味であって、明示が無意味という意味ではない。本当に残すべきものは、はっきり覚えておけと言うほうが確実だ。
規則六 — Markdown より深い材料を渡す
これまで計画書も仕様も設計文書も Markdown で書くのが標準だった。軽くて簡単だからだ。
しかし最新モデルははるかに複雑な参照資料を扱う。ならば伝える情報をわざわざ曖昧にする理由はない。原文はコードの形のファイルを優先せよと言う。モデルがよく知っている言語なので指示が鮮明になるからだ。
具体的にはこうだ。画面の要求は「ボタンは青、角は丸く」と Markdown に書く代わりに HTML のモックアップを渡す。仕様は詳細なテスト群でもよい。このテストを通せ、より明確な要求はない。別のコードベースの関数をそのまま移植せよ、というのも仕様になる。
ルーブリックも参照の一形態だ。良い API 設計とは何かといった基準表を渡せば、モデルは検証エージェントを立ち上げてその基準で自分の成果を採点する。好みを言葉で説明する代わりに採点表を渡す方法である。
では自分のファイルはどう整えるか
原文は最後に四つの席に分けて整理している。それぞれ役割が違う。
システムプロンプトは製品の文脈に強く結びつく。モデルがいまどの製品の中で何をしているかを伝える席だ。Claude Code を使う側はほとんど触ることがなく、自分でエージェントのハーネスを作るならここに時間をかけよと勧めている。
CLAUDE.md は軽く置く。リポジトリが何をする場所かを短く書き、トークンの大半は落とし穴に使う。検証方法が複雑なら検証スキルを別に作り、CLAUDE.md ではそれを指すだけにする。
スキルは必要なときに情報へたどり着くための軽い案内書と見る。極めて重要な領域を除いて過剰に縛らない。長くなったら複数ファイルに割って段階的開示を効かせる。スキルが最も値打ちを出すのは、自分やチームや製品にしかない意見とノウハウを収めたときだ。
参照は @ でファイルを引き込む。仕様ファイル、モックアップ、さらにはコードベース全体まで来る。できればコードの形のファイルを優先する。
手で全部直さなくてよい
ここまで読むと、自分のファイルのどこから手を付けるべきか迷う。だが Anthropic はこのベストプラクティスを道具に入れておいた。
Claude Code を最新版に上げて /doctor と打てばよい。スキルと CLAUDE.md ファイルをこの基準に合わせて適正な大きさに整えてくれる。原文の語では rightsize、ちょうどよい大きさに合わせるという意味だ。
まとめると六行だ。規則を減らし判断に委ねる。例ではなくインターフェースを設計する。先に全部入れず必要なときに取り出させる。同じことを繰り返さない。メモリは自動に任せる。Markdown ではなくコードと HTML とテストで渡す。
貫くメッセージは一つ。モデルはベテランになったのに、こちらはまだ新人マニュアルを握らせていた、ということだ。今日すぐできるのは CLAUDE.md を開いて「絶対にするな」と重複した段落を消すことで、その次が /doctor である。