今日から使えるOpus 5の実践コンテキスト設計――「ルールを増やす」から「判断できる環境を作る」へ　“わざとルールを増やした失敗例付き” #Opus5 実用記事

こんにちは、黒パグです🐾

月曜日なので、今日はそのまま仕事へ持っていけるClaude Codeの話をします。
先に執筆方法も明記しておきます。この記事は私が土台と実務上の解釈を書き、GPT-5.6 SolがAnthropic公式記事との照合、加筆、文章修正を担当しました。「AIに少し整えてもらった」程度ではなく、執筆比率は本当に半々です。この共同執筆稿自体も、現在進めているAI鑑識学v5設計の観測標本として保存します。

3行要約（電車の中で読む方へ）

1. AnthropicはClaude Codeのシステムプロンプトを80％以上削除しました。同社のコーディング評価では、測定可能な性能低下はありませんでした。
2. 効いたのは「短くしたこと」ではありません。禁止事項の列挙を減らし、判断基準、ツール設計、段階的開示へ置き換えたことです。
3. 今日やることは三つ。CLAUDE.mdから「リポジトリを見れば分かること」を外す。反復手順はSkillへ移す。公式記事が案内する /doctor で現在の構成を診断する。

↑こちらはClaude Codeを使わない方向けのポッドキャストになります。Opus5の日常使いにもヒントになるようなものを解説しています。お時間のある時にお聞きください。

────────

Claudeへの指示は、細かく書けば書くほど精度が上がる。

つい最近まで、これはかなり妥当な考え方でした。禁止事項を書き、ツールの使用例を並べ、重要な命令を何度も繰り返す。CLAUDE.mdには、プロジェクトで必要になりそうな情報を可能な限り詰め込む。

ところが、Claude 5世代ではその常識が変わり始めています。

Anthropicは2026年7月24日、Claude 5世代向けのコンテキスト設計を解説する公式記事を公開しました。Claude Codeでは、Opus 5やFable 5向けのシステムプロンプトを80％以上削減しても、同社のコーディング評価では測定可能な性能低下がなかったと報告しています。

公式記事に出てくる社内事例が、問題の性質をよく表しています。Anthropic自身の利用ログには、一つの依頼の中で「必要に応じてドキュメントを残す」と「コメントを追加しない」が同居する場面がありました。システムプロンプト、Skill、ユーザーの依頼が、それぞれ別の方向を向いていたわけです。

Claudeは最終的な意図を推測できます。それでも、作業へ入る前に重複した指示と矛盾を解かなければなりません。Anthropicは従来の状態を「過剰に制約していた」と振り返り、制約を外す作業を unhobbling、足かせを外すこと、と表現しています。

正直、これは他人事ではありません。私が作っているAI鑑識プロンプトも、現行版は933行あります。必要な規則を積み上げた結果ですが、「どこかで同じことを二度言っていないか」と聞かれると、ちょっと目をそらしたくなる長さです。

今回の公式記事は、単なる「短いプロンプトの勧め」ではありません。モデルへ大量の規則を常時背負わせる設計から、必要な情報へ必要なときに到達させる設計への転換です。

Claude Codeを使う人が主に見直すのはCLAUDE.mdとSkillです。独自のエージェントハーネスを作っている人は、システムプロンプトとツール定義まで対象になります。ここは分けて考えます。

1．細かい禁止事項より、判断基準を書く

以前のClaude Codeでは、コメントやドキュメントを増やしすぎないよう、かなり具体的な禁止事項が置かれていました。コメントは原則書かない。長いdocstringや複数行コメントは避ける。依頼されていない計画書や分析文書は作らない。古いモデルで失敗を抑えるには、こうした安全装置が必要でした。

しかし、コメントを入れるべきかどうかはコードによります。複雑な処理には数行の説明が必要ですし、コメントの少ない既存リポジトリへ長文解説を持ち込めば、それも不自然です。

Claude 5世代では、個別の禁止を並べる代わりに、周囲との一貫性を判断基準として渡します。公式記事が示す新しい指示を日本語でまとめると、こうなります。

> 周囲のコードと同じように読めるコードを書く。コメントの密度、命名、書き方を既存コードへ合わせる。

仕事で使うなら、次の四つを別々に書く必要は薄くなりました。

一つの判断基準へまとめられます。

> 既存リポジトリの構造、命名、コメント密度を確認し、周囲と一貫した変更を行う。新しい成果物は、依頼の完了に必要な場合だけ追加する。

規則を消して放任するのではありません。場面ごとに正解が変わる部分をモデルの判断へ戻し、その判断に使う物差しを残します。

2．使用例を増やす前に、ツールの入口を整える

従来、モデルへツールを正しく使わせる第一手は、具体的な使用例を見せることでした。ところがAnthropicは、Claude 5世代では例示が探索範囲を狭める場合があると説明しています。

例を強く参照すると、本来は別の手順が合う場面でも、見せられた操作を再現しようとします。これから先に見るべきなのは、例の数ではなくインターフェースです。

たとえばタスク管理ツールなら、状態を pending、in_progress、completed の列挙型にする。「同時に in_progress にできる項目は一つ」と定義する。これだけでも、期待する進行方法はかなり伝わります。

独自エージェントのツールで失敗が続くとき、プロンプトを足す前に確認したいのは次の点です。

同じ説明をシステムプロンプトとツール定義の両方に置く必要もありません。ツールの使い方はツール側へ寄せ、置き場所を一つにする。モデルの問題に見えて、入口の曖昧さが原因だった、ということは普通にあります。

3．すべてを最初に読ませない

今回の実務上の本丸は「段階的開示」です。

CLAUDE.mdへレビュー手順、テスト方法、デプロイ規則、文章作成ルール、障害対応まで詰め込むと、使わない情報も毎回コンテキストへ入ります。情報量だけでなく、冒頭で触れたような指示衝突も増えます。

Anthropicは、検証やコードレビューの詳しい手順を独立したSkillへ移し、必要な場面で選択的に読む構成へ変更しました。ツールにも遅延ロードが使われています。最初から全定義を渡さず、必要になったらToolSearchで探す仕組みです。

たとえば、常駐させる情報と必要時に読む手順を次のように分けます。

普段の小さな修正で、障害対応手順まで読む必要はありません。レビューを頼まれていない場面で、レビュー用チェックリストを常駐させる理由も薄いでしょう。

長いSkillも同じです。一枚の巨大な手順書にせず、入口には「いつ、何を読めばよいか」を置く。詳細は別ファイルへ分けます。

全部を覚えさせる発想から、必要な資料を見つけられる構造へ。ここがコンテキスト設計の変化です。

4．CLAUDE.mdを社内Wikiにしない

Anthropicは、CLAUDE.mdを軽量に保ち、リポジトリの説明は短く、トークンの大半をコードベース固有の落とし穴へ使うよう勧めています。

残す価値があるのは、コードを眺めただけでは分からない事情です。

ファイル構成を調べれば分かることや、一般的なプログラミング原則まで説明する必要は薄くなりました。Claudeが確認できる情報は確認させ、人間しか知らない事情へコンテキストを使います。

メモリの扱いも変わっています。以前は # ホットキーで覚えてほしいことをCLAUDE.mdへ書き足す運用が案内されていました。現在は、作業や利用者に関係する情報をClaudeが自動保存する方向へ移っています。

長く使っているCLAUDE.mdほど、昔の手動メモリが残っています。いきなり全部を削るより、まずそこを見直すのが安全です。

5．仕様は説明文だけでなく、コードやテストで渡す

Claude 5世代は、単純なMarkdown仕様書だけでなく、複雑で情報密度の高い参照物を扱えます。

実務では、長い説明より次の資料が強い場面があります。

Anthropicは、コードの形をした参照物を優先するよう勧めています。デザインも、説明文やスクリーンショットだけでなくHTMLモックを渡せば、構造やコンポーネントの関係まで伝えられます。

評価ルーブリックは、「良いAPI設計とは何か」のようなチーム固有の判断基準を渡す方法です。別の検証エージェントに同じ基準を持たせ、成果物の再確認にも使えます。

仕様を長く説明するより、期待する状態と検証方法を機械が読める形で置く。これも今日から使える変更です。

6．削るのは検証ではない

ここは誤読しやすいところです。

システムプロンプトを80％以上削ったという話だけを見ると、「細かい確認もClaudeへ任せればよい」と読めます。しかしAnthropicが同じ週に公開した検証ループの記事では、テスト、リンター、実行時エラー、独自チェックをSkillとして反復可能にする方法を詳しく説明しています。

つまり、減らすのは全作業へ常駐する一般ルールです。プロジェクト固有の検証は消さず、必要な作業へ結びつけます。

毎回手で確認している項目は、検証Skillの候補です。特定の作業だけで必要なら、その作業Skillへ埋め込む。複数工程をまたぐなら、実装、レビュー、簡略化、検証を連鎖させる。PRごとに安定して動かせる段階になれば、チーム共通のゲートへ上げる。

ルールを減らすことと、確認を減らすことは別です。むしろ常駐ルールを軽くした分、検証の実行条件と結果を明確にする必要があります。

今日やる15分の棚卸し

大改修は要りません。月曜の朝なら、次の順で十分です。

1. 公式記事が案内する /doctor を実行し、CLAUDE.mdとSkillの状態を見る
2. 同じ指示が二か所以上にないか探す
3. リポジトリから確認できる説明を一つ外す
4. 毎回手で確認している作業を一つ、検証Skillの候補としてメモする

削除結果はそのまま採用せず、差分を確認してください。安全条件、公開、削除、権限、秘密情報、必須テストに関する境界は残します。

独自エージェントを運用している場合は、CLAUDE.mdの代わりにシステムプロンプトとツール説明の重複を探します。最初に触るのは、同じ命令が二度書かれている場所です。

「何も指示しない」が正解ではない

今回の公式記事は、すべての制約を捨ててClaudeへ丸投げする提案ではありません。Skillも、重要な領域では強い制約を残す前提です。

業務では、少なくとも次の境界を明示します。ここからは公式記事の逐語的な一覧ではなく、私の実務上の整理です。

高性能なモデルほど、依頼の周辺まで判断して動きます。通常の実装判断は任せる。権限、境界、停止条件は人間が決める。この切り分けは残ります。

もう一つ、80％という数字の射程にも注意が必要です。Anthropicが述べているのは、Opus 5やFable 5向けにClaude Codeのシステムプロンプトを削減し、同社のコーディング評価では測定可能な性能低下がなかった、という結果です。

一般的な文章作成、法務、医療、社内独自評価、あらゆるエージェントへ同じ割合を適用できるとは書かれていません。「うちも80％削ろう」ではなく、重複と衝突を測りながら減らすための事例として読むのがよいでしょう。

まとめ

Claude 5世代のコンテキスト設計は、細かい命令を積み上げる方法から、判断と参照の環境を作る方法へ移っています。

月曜の朝にCLAUDE.mdを全部書き換える必要はありません。同じ指示が二か所にないか、一つ探す。そこからで十分です。

私もまず、933行を見直します。

人のプロンプトを心配している場合ではありませんでした。

────────

参考

• Thariq Shihipar（Anthropic）「The new rules of context engineering for Claude 5 generation models」2026年7月24日
• Delba de Oliveira（Anthropic）「Building verification loops in Claude Code with skills」2026年7月22日

※本記事は公開時点のAnthropic公式情報をもとに整理したものです。「今日やる15分の棚卸し」と業務上の境界条件は筆者による整理であり、Anthropic公式記事の逐語訳ではありません。製品仕様や推奨事項は今後変更される可能性があります。業務環境で設定を変更する場合は、既存の安全要件、社内規程、権限管理、検証手順を優先してください。

#生成AI #Claude #ClaudeCode #Opus5 #コンテキストエンジニアリング #プロンプトエンジニアリング #AIエージェント #AI活用 #業務効率化