メインコンテンツへスキップ
AMPL
レッスン 7.6 / 13|17分で読めます

Context Engineeringの新ルール（制約を、外す）

Claude 5世代のモデルは賢くなりすぎて、これまでのコンテキスト設計の常識がいくつも迷信になった。開発チームがシステムプロンプトの8割を削った話と、Then→Nowの6原則。

一行でいうと

前回は、何を読ませ、何を捨てるかという話でした。今回はその続きです。

Claude 5世代のモデルは、これまで必要だった細かい指示の多くを、もう必要としなくなりました。Claude Code開発チームは、システムプロンプトの8割以上を削っても、コーディングの評価スコアが落ちなかったと公表しています。新しいルールは一言でいうと、制約を減らして、モデルの判断に任せるです。

前回覚えた「信号の濃さを保つ」という考え方の、実践編にあたります。

きっかけ：システムプロンプトの8割を削った

この話は、Claude Code開発チームのThariq（@trq212）が2026年7月24日に公開したスレッドと、同日の公式ブログ記事がもとになっています。

Claudeに1つメッセージを送るとき、あなたが打った文（プロンプト）は、渡される文脈のごく一部です。実際にはシステムプロンプト、Skills、CLAUDE.md、メモリといった複数の出どころから文脈が組み上がって渡されます。前回学んだコンテキストエンジニアリングは、この全体を設計する営みでした。

その全体を、開発チームは自分たちで読み返して気づきます。自分たちはClaudeを縛りすぎていた、と。

過剰な制約が、かえって足を引っぱる

チームが自分たちのClaude Code利用ログを読み返すと、1つの依頼の中に矛盾したメッセージが同居していました。システムプロンプトには「コメントは書くな」、別のSkillには「必要ならドキュメントは残してよい」、そこにユーザーの指示が重なる。

古いモデルでは、こうしたガードレールがないと最悪の事故（ファイルの削除や、コメントの氾濫）を起こしました。だから多少正しくない場面があっても、強い禁止を置くしかなかった。この割り切りを、当時は受け入れるしかありませんでした。

でも新しい世代は、周りの文脈と自分の判断で、こうした重なりをうまくさばけます。制約を外して判断に委ねたほうが、結果が良くなるという逆転が起きました。開発チームはこれをunhobbling、足かせを外す、と呼んでいます。

視点

矛盾した指示は、賢さを削る

「適宜ドキュメントを残せ」と「コメントは絶対に書くな」が同じ文脈に同居すると、Claudeは何をすべきか決める前に、まずこの衝突を解きほぐすことに頭を使います。禁止を1つ置くたびに、その一手ぶんの余力が削られていく、と考えると分かりやすいです。

Then → Now：6つの常識が、迷信になった

かつてのベストプラクティスの多くが、新しい世代では逆になりました。開発チームが挙げた6つを、以前といまの対比で並べます。左が縛りの発想、右が判断に委ねる発想です。

ルールを与える → 判断に任せる

以前

常に正しいとは限らない強い禁止を置く。たとえば「コメントは書くな。複数行のコメントブロックは禁止、書くなら1行まで」。

いま

「周りのコードに読み方を合わせよ。コメントの密度も命名も、隣のコードに揃えよ」。禁止のリストではなく、判断の基準を1つ渡す。

強い禁止は、複雑なコードで複数行の説明がどうしても要る場面では、かえって間違いになります。新しい世代は、周りの文脈から自分で判断できます。

例を与える → インターフェースを設計する

以前

とにかく使用例を並べて見せる。それがツールの使い方を教える一番の方法だとされていた。

いま

例はかえって探索の幅を狭める。引数や状態の選択肢など、インターフェースの設計そのもので意図を伝える。

たとえばTodoツールの状態を「未着手・進行中・完了」にし、「進行中は常に1つだけ」と足すだけで、使い方は自然に決まります。例文をいくら足すより、インターフェースの形が語ります。

全部を前もって渡す → 進歩的開示

以前

コードレビューや検証のやり方を、最初から全部システムプロンプトに載せておく。

いま

必要になった瞬間だけ読み込む。検証やレビューは独立したSkillに切り出し、要るときに呼ぶ。ツールも一部は遅延読み込みで、使う前にToolSearchで探す。

前回名前だけ出した進歩的開示です。これはあなたのCLAUDE.mdやSkillにもそのまま効きます。1つのファイルに全知識を詰め込まず、木のように枝分かれさせて、要るときに要る枝だけ開けばよいのです。

繰り返す → ツール説明はシンプルに

以前

古いモデルは指示を繰り返さないと守らなかった。だから同じ注意を、システムプロンプトとツール説明の両方に二重で書いていた。

いま

重複は消せる。ツールの使い方は、システムプロンプトではなくツールの説明欄に、一度だけ書く。

置き場所を1つに決めるほうが、混乱が減ります。

CLAUDE.mdに記憶させる → オートメモリ

以前

覚えておいてほしいことを、# ホットキーで自分のCLAUDE.mdに書き足していく運用を勧めていた。

いま

Claudeが、仕事とあなたに関係する内容を自動でメモリに保存する。手で書き足す前に、必要な記憶がたまっていく。

CLAUDE.mdを記憶の置き場として使い倒す時代は、一区切りつきました。

単純な仕様 → 豊かなリファレンス

以前

計画も仕様も、マークダウンのシンプルなテキストで残すのが定番だった。

いま

ArtifactのHTMLモック、詳しいテストスイート、別コードベースの関数そのものを、仕様として渡せる。

「良いAPI設計とは何か」といったあなたの美意識も、ルーブリック（採点基準）にして検証役のエージェントに確かめさせられます。言葉で説明するより、コードやHTMLのほうが高い解像度で伝わります。

視点

前回の「1行を削るテスト」が、さらに効く

前回、CLAUDE.mdで「この一行を削除したら、Claudeは間違えるか」を試すテストを紹介しました。新しい世代では、削っても間違えない一行がぐっと増えています。棚卸しの効果が、以前より大きくなったということです。

自分の運用に落とす

このスレッドの締めくくりを、あなたの手元の設定に置き換えます。文脈の出どころごとに、何を意識すればよいかが整理されています。

システムプロンプト

製品そのものの文脈。Claude Codeでは基本いじらない。自前のエージェントを作るなら、ここに一番時間をかける

CLAUDE.md

軽く保つ。リポの目的は短く、トークンの大半はコードの落とし穴（gotcha）に使う。ファイルを見れば分かる自明なことは書かない

Skills

必要なときに情報を見つけさせる軽い案内書。縛りすぎない。長くなるなら複数ファイルに割って進歩的開示にする

リファレンス

@で参照させる。設計は言葉より、コードやHTMLモックのほうが高い解像度で伝わる

文脈の出どころ別・いまの指針

CLAUDE.mdについての一言は、そのまま覚えておく価値があります。自明なことを書かず、落とし穴にトークンを使う。ファイルを見れば分かることをClaudeに説明しても、文脈を食うだけです。

棚卸しは、/doctorに任せる

削る作業を、開発チームは新しいコマンドで半自動化しました。Claude Code上で /doctor を実行すると、肥大化したSkillsやCLAUDE.mdを適正なサイズに直す手助けをしてくれます。

Claude Codeで棚卸しを走らせる
$/doctor
Skills・CLAUDE.mdを点検し、過剰な制約や重複した指示、削れる行を洗い出して、適正なサイズへの直し方を提案する。

自分たちが8割を削ったのと同じことを、あなたの設定でもやってみてほしい、というのが開発チームの結びです。

今日のまとめ

3行で振り返ります。

  • 新しい世代のモデルは判断力が上がったので、これまで必要だった細かい制約の多くが、いまはかえって邪魔になる（開発チームはシステムプロンプトの8割超を削った）
  • Then→Nowの6原則。ルールより判断、例よりインターフェース、前もってより進歩的開示、繰り返しよりシンプルな説明、CLAUDE.mdの記憶よりオートメモリ、単純な仕様より豊かなリファレンス
  • CLAUDE.mdは自明を書かず落とし穴にトークンを使う。棚卸しは /doctor に任せられる

セルフチェック

1. Claude Code開発チームが、新しい世代のモデル向けにシステムプロンプトへ加えた変化として、本文が挙げているものは？

2. 「例を与える → インターフェースを設計する」という変化の理由として、本文が説明しているのはどれか？

3. 本文がCLAUDE.mdの書き方として勧めているのは、次のどれか？

明日のアクション

いま使っているプロジェクトのCLAUDE.mdを開いてください。

そこで、(1) ファイルの中身を見れば分かる自明な説明はないか (2) 「絶対に〜するな」という強い禁止が、いまも本当に必要か、の2点を確認します。

心当たりがあれば、思い切って削るか、Claude Code上で /doctor を走らせて棚卸しを提案させてみてください。次は、失敗したときに戻れる仕組み、Checkpointsです。

参考・出典