『Claude 5世代』の新しい常識 ── Anthropic公式「6つの新ルール」を日本語で読み解く

こんにちは、株式会社Renewerの堀内です。

前回、Anthropic公式『Claude Fable 5 プロンプトエンジニアリングガイド』を日本語で読み解くという記事を書きました。

注目度の高かったモデル「Fable 5」のプロンプトエンジニアリングを公式ガイドに沿って整理したものです。
おかげさまで多くの方に読んでいただきました。

前回の記事は、Fable 5というモデルを、どう使いこなすかという話でした。

そんな中、7/24にモデルClaude Opus 5が公開されて、ClaudeのAIモデルは一気に「5世代」に突入しました。
同時期にAnthropic社が出した2本の公式ドキュメントは、前回よりももう一段上のレイヤーを扱っています。

2本の記事面白いのは、語られる原則の多くが「これまでの常識の逆」だという点です。
これらの記事を読み解き、Claude 5世代モデル通してAIの認識をアップデートすることは、GPT、Geminiでも通ずる次世代モデルを使いこなすための原則になると考えています。

そのようなアップデートをわかりやすくまとめて広く届ける、という趣旨で『Claude 5世代 マスターガイド』を公開しました。

Anthropic公式の記事を中心に、「コンテキストエンジニアリングの新手法」や、「Claude5 モデル選定ガイド」などClaude 5世代の使いこなし方について扱った、50ページを超える内容です。

前回に引き続きわかりやすい言葉に置き換えながら、日本語訳・解説としてまとめています。
ガイドに登場する例も、日本語で使える形に翻訳したり、非エンジニア向けに編集し直したりしています。

以下から無料でダウンロードできます。

本記事では、このうち1本目の「コンテキストエンジニアリング」を読み解きます。2本目の「モデル選定」は、次回の記事で扱います。
元になっている公式ドキュメントはこちらです。

The new rules of context engineering for Claude 5 generation models（Claude 5世代モデルのためのコンテキストエンジニアリングの新ルール）

Claude Code内のプロンプトを「80%削除」した結果

公式ブログは、冒頭でこう述べています。

Claude 5世代モデル向けにClaude Code内のプロンプトの8割を削除したそうです。結果、性能は落ちなかったとのことです。

削除された典型例として挙げられているのが、指示の矛盾です。
Anthropic社内での Claude Code利用ログを読み返したところ、1つのリクエストの中で矛盾する指示が混在しているケースが多数見つかりました。

Claudeはユーザーの意図を汲んで正解にたどり着けるものの、矛盾した指示のせいで余計な熟考を強いられていたわけです。

旧世代のモデルには、放っておくと手順を飛ばす、冗長に書く、指示を1回では守らないといった弱点がありました。それを1行ずつルールで潰していった結果が、巨大なシステムプロンプトなる、というのは、私たちが生成AIを使ったサービスを作っていてもよくあることです。

新世代モデルでは判断力が上がったため、この前提が変わりました。強い制約の多くを削除して、周囲のコンテキストとモデル自身の判断に任せられるようになりました。
Anthropicはこれを「足かせを外す（unhobbling）」と表現しています。

もう1つ、手段の進化もあります。
Claude Codeには現在、メモリ・Artifacts・skillsなど多くの道具が揃いました。かつてCLAUDE.mdというファイルが一手に担っていた「記憶・情報・ガイダンス」の役割が、それぞれ専用の置き場所に分散できるようになった。これも8割削除を可能にした背景です。

「コンテキスト」とは何か

新ルールに入る前に、「コンテキスト」についてを簡単に解説します。

コンテキストとは、AIが答えを考えるときに参照できる情報の全部のことです。手渡した資料、それまでの会話のやりとり、AIが覚えているあなたの好み、最初に渡してある指示書。
「AIの机の上に置いてあるもの全部」と考えてください。

大事なのはプロンプトの言い回しだけではなく、机の上に何を置くかの全体設計だ、とAnthropicの開発者自身が言っています。
AIの最適な活用方法はプロンプトの「書き方」の話から、コンテキストの「渡し方」の話へ移っています。
これが巷で注目を浴びている「コンテキストエンジニアリング」です。

このような背景を頭に置いて、6つの新ルールを見ていきましょう。

Claude 5世代の6つの新ルール

ここから、公式が挙げた6つの新ルールを1つずつ見ていきます。また、原文の6つのルールは主にエンジニア向けの例でしたが、ガイドブックでは非エンジニアが取り入れられる例に置き換えて紹介しています。

1. 禁止事項を並べず、判断基準をひとこと渡す

1つめの転換は「Give Claude Rules → Give Claude Judgement（ルールから判断へ）」です。

旧世代のプロンプトは、望ましくない動きを1つずつ禁止で潰していくのが定石でした。例えばClaude Codeの旧システムプロンプトには、こんな一節があったそうです。

新しいシステムプロンプトでは、この禁止リストが1文に置き換わりました。禁止で縛るのではなく、何を基準に判断すればよいかを渡す形です。

違いは「何をするな」ではなく「何に合わせるか」を渡している点です。

禁止リストは、想定した場面でしか働きません。想定外のケースが来ると穴が空きますし、リストが長くなると禁止どうしがぶつかり始めます。
一方、判断基準がひとことあれば、AIは初めての場面でもそこから答えを導けます。Claude 5世代は、その応用を利かせられるだけの判断力を持った、ということです。

このルールは、非エンジニアの使い方でもそのまま使える考え方です。
例えば議事録の作成依頼が、まさにこの構図です。「箇条書きは5項目まで。敬語は使うな。感想は書くな…」と並べる代わりに、「社内で回覧する議事録なので、誰が読んでも30秒でわかる形にまとめてください」。
誰のための、何のための文書かを渡せば、細かい体裁はAIが自分で決められます。

2. 例文で教えず、ひな形で伝える

2つめは「Give Claude Examples → Design Interfaces（例文から、型へ）」です。

旧世代のセオリーは、few-shot（少数の例示）としてプロンプトに埋め込むことでした。例えばClaude Codeのシステムプロンプトでは、サービス内のtoolの使い方を以下のように書いていたそうです。

# システムプロンプト
todo ツールの使い方の例:
例1: 作業を始めるときは {"task": "調査", "status": "作業中"} を送る
例2: 終わったら {"task": "調査", "status": "終わり"} を送る
例3: まだ始めていないものは {"task": "実装", "status": "これから"} と書く

Claude 5世代で代わりに推奨されるのがひな型（インターフェース）の設計です。
たとえば上記のToDoツールでは、 ステータスがpending / in_progress / completedの3種類であると定義します。
するとClaude 5世代のモデルは、例文を並べなくても、選択肢の設計そのものが使い方の説明として解釈します取りうる答えの全体、表記のゆれの排除、1つだけ選ぶこと。この3つが同時に伝わるからです。

プロンプトエンジニアリングの代表的な手法として「few-shotプロンプティング」がありますが、これも陳腐化していくような動きとも取れます。

仕事での使い方では、例えば週報をAIに頼むとき、過去の週報を3本貼り付けるより、「今週の成果／来週の予定／相談事項、ステータスは順調・注意・遅延の三択」という空欄付きのひな形を渡すほうが、短いのに正確に伝わります。

3. 最初に全部渡さず、必要になったら開かせる

3つめは「Put it all upfront → Use Progressive Disclosure（先に全部渡さず、段階的に開示する）」です。

旧世代では、使うかもしれない資料は、最初に全部渡しておくのが安全策でした。Claude Codeも同じで、コードレビューや検証の詳細手順が、システムプロンプトに最初から丸ごと入っていましたようです。

現在は「必要なときに、必要なコンテキストだけを読み込む」段階的開示（Progressive Disclosure）が主流になりました。詳細な手順は独立した skills に切り出され、Claudeが必要なときだけ呼び出します。

具体的には、 CLAUDE.md や SKILL.md に以下のように適用できます。「Claudeが見つけられないと困るから、知っている実践はすべて1つのファイルに集約すべき」というのはよくある誤解で、適切なタイミングで読み込めるファイルのツリーを作る方が良い、とされています。
Anthropic自身、Claude Codeの検証とコードレビューのガイダンスを、システムプロンプトから独立したSkillへ移しました。
AIには、使う可能性がある資料の目次1行分を渡し、呼び出せる場所に資料を置く。これが実装の型です。

この「目次だけ渡す」方式は、非エンジニアにおける、AIへの資料の渡し方にもそのまま応用できます。提案書づくりなら、社内規定集・過去の提案書10本・会社案内を全部添付するのがBefore。「参考資料の目次」だけ渡して、必要なものをAIに選ばせるのがAfterです。

4. 同じことを二度書かない

4つめは「Repeat Yourself → Simple Tool Descriptions（繰り返さず、書く場所を1つに）」です。

旧世代には「大事なことは2回言う」という事実上の作法がありました。1回書いただけの指示を、LLMが見落とすことがあったからです。
実際、Claude Codeでも同じ指示がシステムプロンプトとツールの説明文の両方に書かれていました。冗長さで信頼性を買っていたわけです。

Claude 5世代では、この二重書きが逆に害になります。指示を文字通り忠実に守るようになったぶん、2か所の指示がわずかに食い違っていると、「どちらを優先すべきか」で余計な思考を使ってしまうのです。

そこで公式は、繰り返しの削除を明確に推奨しています。同じ指示を見つけたら、片方を消して1か所に集める。
プロンプトと参考ファイル、それぞれどこに何を書くかを設計し、一元化をキープする、という設計が求められます。

5. メモリを手で書かない

5つめは「Memory in Claude.MDs → Auto-memory（手で書くメモから、自動の記憶へ）」です。

「この失敗を繰り返さないよう、メモファイルに書いておいて」。旧世代の標準的な運用でした。Claude Codeでは、CLAUDE.mdというファイルに大事なことを人間が書き足していきます。私も長くこの運用をしていました。

やってみると、3つのことが起きます。書き忘れる。更新されない。古い情報が残る。しかもこのメモは毎回AIの机に載るので、書けば書くほど毎回のコストが上がっていきます。
公式ドキュメントは、この肥大化をかなり強い調子で警告しています。

Claude 5世代では、作業に関係する内容や好みを、AIが自動で覚えるようになりました。
人間が手で書き残す価値があるのは、「このAPIは仕様書と実際の挙動が違う」のような、資料を読んでもわからない落とし穴だけ。それ以外は、覚える仕事ごとAIに任せます。

メモリの強化は、Claude 5世代を使っているとすぐに体感できる改善です。「覚えておいて」と都度指示するのをやめて、自動メモリに任せてみる。6つの中でも、まず試す価値のあるルールだと感じています。

6. 説明せず、参照させる

最後は「Simple Specs → Rich References（言葉の仕様書から、豊かな参照資料へ）」です。

旧世代のAIは、複雑な資料を渡しても正しく読み取れないことがありました。そこで人間が「翻訳者」を務めてきました。

Claude 5世代では、翻訳せずに現物をそのまま渡すほうが正確です。テストコード、画面のモックアップ、既存のコード、品質チェックの採点表。こうした資料を、仕様として直接読めるようになりました。

上の例で言えば、テストコードを渡すほうが速く、しかも漏れがありません。自然言語に翻訳する過程で、人間は必ず何かを落とします。

これは非エンジニアの業務でも同じだと感じています。「こういうトーンで書いて」と説明するより、過去の良い成果物を3本渡すほうが早いでしょう。
私自身、記事の文体を伝えるときは、説明ではなく実物を渡すようにしています。

新ルールをコンテキストに当てはめる ── 4つの置き場所

では、6つのルールを踏まえて、結局どこに何を書けばよいのか。公式ブログは締めくくりで、4つの置き場所の使い分けを示しています。

ここが、この公式ドキュメントの実務的な結論部分です。1つずつ見ていきます。

① System Prompt ── 土台の説明書。ほとんど触らない

System Promptは、AIツールに最初から組み込まれている土台の説明書です。「いまどの製品の中で、何をしているのか」をAIに伝える層で、Claude Codeのようなツールを使うだけなら、ここを触ることはまずありません。

「ただし自前でAIエージェントを作るなら、最も時間を使うべき場所」と付け加えています。私たちが日々のプロンプトににアプリの説明を書き足すのは、この層の仕事を二重にやっているだけ、ということでもあります。

② CLAUDE.md ── 注意書きメモ。「見ればわかること」は書かない

CLAUDE.mdは、仕事場に貼っておく「注意書きメモ」にあたる置き場所です。
ポイントは、資料を開けばわかることは書かないこと。例えば「このフォルダには請求書が入っています」は、フォルダを見ればわかるので不要です。

書く価値があるのは、「4月だけ締め日が違う」「この取引先は旧社名で登録されている」のような、見てもわからない落とし穴だけ。
さらに公式は、検証のやり方のような長い手順はここに書かず、skillsに切り出して参照させよ、と続けます。メモには要点だけを残し、詳細は手順書へ。会社の掲示板と業務マニュアルの関係と同じです。

③ skills ── 手順書。縛りすぎず、必要なときに開かせる

skillsは、ルール3で登場した「必要なときだけ開く手順書」です。公式はここに2つの注意を添えています。

1つは、縛りすぎないこと。手順書の役割は細かい動作を全部決めることではなく、AIが必要な情報を見つけるための「軽い道しるべ」です。ただし、セキュリティや取り返しのつかない操作のような重要な領域だけは、例外として細かく縛ってよいと明言されています。
もう1つは、固有性に価値があること。誰でも知っている一般論をAIは既に知っています。手順書が最も活きるのは、あなたやチームだけの判断基準・流儀を書き込んだときです。

④ References ── 見本。言葉の説明より現物を渡す

Referencesは、ルール6の「参照させる」の置き場所です。仕様書、モックアップ、過去の成果物といった現物を、そのまま参照させます。

例えば画面デザインなら、言葉の説明や画面写真より、HTMLで作った実物のモックのほうが良い結果を生む、と公式は述べています。画像は見た目こそ伝わりますが、構造までは伝わりません。

4つに共通する、たった1つの原理

こうして並べると、4つの置き場所はどれも「たくさん書く」ことを求めていないことがわかります。求められているのは、置き場所を間違えないこと。それぞれの層に、その層にしか書けないことだけを書く。何をどこに書くか迷ったら、この分担に立ち返るのがおすすめです。

ここまでお読み頂き、ありがとうございました！

6つのルールを貫いているのは、AIと人の役割分担の変化だと感じています。細かい指示でAIの行動を1つずつ管理するのは、もう人の仕事ではありません。判断はAIに任せて、人は「何を渡し、どこに置くか」を設計する側に回る。
まずは手元のプロンプトやメモファイルを1つ開いて、「これはAIの判断に任せられないか」「この説明は、見本に置き換えられないか」という役割分担の見直しを始めてみてください。

モデル別の比較をまとめたガイドブックは、以下から無料でダウンロードできます。

仕事・企業で使えるClaudeの情報は以下マガジンにまとめています。
合わせてお読みください。よろしければフォローお願いします。