「Claude Opus5 プロンプトのコツ」を調べていて、YouTubeで見た解説動画がすごく面白かったので、公式ドキュメントの原文と一つずつ突き合わせてみました。結論から言うと、動画の内容はだいたい公式と合っていました。でも2つだけ、公式が今も逆のことを書いている部分がありました。
Claude Opus5 プロンプトのコツは「だいたい合っていて、2つだけ違いました」
先にまとめます。動画で言われていた「Claude Opus5 プロンプトのコツ」を公式ドキュメントで1つずつ確認して、①もうぼくがやっていること ②これから取り入れること ③取り入れないこと の3つに仕分けました。
| 分類 | 内容（かんたんに） |
|---|---|
| ①もうやっていること | 指示書を短く保つ／役割を名乗らせる／報告の長さを決めておく／仕事の全体像を最初にまとめて渡す／古い指示を溜めない／指示書に残すのは自分だけの決めごとだけにする／/doctorを今日動かしてみた（ただし中心機能はぼくの環境では使えなかった。詳しくは本文）／チェックリストを3段に分けた（動画をきっかけに気づいたこと。分ける途中で廃止済みのルールが出てきて、今回試した中でいちばん効いた） |
| ②これから取り入れること | 軽い仕事は任せず自分でやると一言添える／成果物そのものの長さを指定する |
| ③取り入れないこと | お手本を貼るのをやめる／役割設定をやめる／effortでトークンが7倍になるという数字をうのみにする／無料プランとProで同じ指示が使えると思い込む／作業を分割しないで丸投げする |
ここから、なぜこの3つに分けたのかを、公式ドキュメントの原文を見ながら説明していきます。
そもそも何の話なのか｜AIへの指示は「足す」から「消す」に変わった
元になっているのは、YouTubeチャンネル「【さき】のAIでええやん。」さんが出している、Claude Opus5への指示だしを扱った動画です。詳しくはこちらをご覧ください（英語ではなく日本語の動画です）。
【短くてイイ】AIへの指示は詳細すぎると失敗する？ClaudeOpus5を使いこなす指示だしのコツ。動画の大きな主張は「これまでのAIは指示を細かく足すほど良くなったけど、Opus5は逆で、余計な指示を消すほど良くなる」というものです。これが、Anthropicが2026年7月24日に出した公式ドキュメントに書いてあることと合っているのかを確かめてみました。
その前に、動画にはもう一つ気になる言い方がありました。Opus5が最上位モデルを超えた、という話です。
発表ページ「Introducing Claude Opus 5」では、Opus5について次のように書かれています。
It’s a thoughtful and proactive model that comes close to the frontier intelligence of Claude Fable 5 at half the price.
日本語にすると「最上位モデルのClaude Fable5の知性に、半額で迫るモデル」という意味です。ここ、ちょっと注意が必要で、書かれているのは「迫る（comes close to）」であって「超えた」ではありません。個別のテストでは最高評価（state-of-the-art）を取ったものもありますが、Fable5そのものを追い抜いたとは書かれていません。動画でも似た表現がありましたが、そこは公式の書き方に合わせて「迫った」くらいに受け取っておくのが正確だと思います。
そしてもう1つ、正直に書いておきたいことがあります。動画でいちばん目を引く主張は「システムプロンプト（AIへの指示書）を8割以上削っても性能が落ちなかった」という話でした。これについて、Anthropicのエンジニアが書いた公式ブログ「The new rules of context engineering for Claude 5 generation models」の原文を読むことができました。
We removed over 80% of Claude Code’s system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations.
訳すと「Claude Opus5やClaude Fable5などのモデル向けに、Claude Codeのシステムプロンプトを8割以上削ったが、我々のコーディング評価では測定可能な性能低下は無かった」とのことです。ここは3つ注意が必要です。削ったのは「利用者が打つプロンプト全般」ではなく、あくまでClaude Code自身が持つシステムプロンプトであること。対象として名前が挙がっているのはOpus5とFable5であること。そして「性能が落ちなかった」と言えるのは、Anthropicがコーディングの評価で測ったときの話だということです。
この公式ブログには、AIへの指示の出し方が「昔（Then）」から「今（Now）」でどう変わったかをまとめた対比表も載っています。見出しの英語は原文のまま、訳を添えて抜粋します。
| 昔（Then） | 今（Now） |
|---|---|
| Give Claude rules（規則で縛る） | Let Claude use judgement（判断させる） |
| Give Claude examples（例を見せる） | Design interfaces（道具の設計をよくする） |
| Put it all upfront（全部先に置く） | Use progressive disclosure（必要な時に読ませる） |
| Repeat yourself（念を押して繰り返す） | Simple tool descriptions（道具の説明に書く） |
| Memory in CLAUDE.md files（手でメモを書く） | Auto-memory（AIが自分で覚える） |
| Simple specs（素っ気ない仕様書） | Rich references（厚い参照資料） |
上の表は、Anthropicのエンジニアが書いた「The new rules of context engineering for Claude 5 generation models」の「Then and now」という節をまとめたものです。
ここからは、指示の長さの話に移ります。まず、Opus5の発表ページにこう書かれていました。
Introducing Claude Opus 5（※英語サイト・自動翻訳推奨）
公式が「消していい」と書いている指示
ここが動画でいちばん価値があると感じた部分です。Anthropicの「Prompting Claude Opus 5」というガイドには、次のように書かれています。
Claude Opus 5 verifies its own work without being told to. If your prompt contains explicit verification instructions (“include a final verification step for any non-trivial task,” “use a subagent to verify”), remove them: instructions like these cause over-verification on Claude Opus 5, and removing them reduces wasted tokens with no loss in quality. The same applies to legacy harness scaffolding that adds separate verification steps.
訳すと「Claude Opus5は言われなくても自分の作業を確認する。プロンプトに『念のため最終確認をして』『サブエージェントに検証させて』のような明示的な検証指示が入っていたら消していい。こうした指示はOpus5では過剰な確認を引き起こし、消すことで無駄なトークンが減り、品質は落ちない。工程を分けて検証の段を足す、旧来のしくみについても同じことが言える」とのことです。
同じガイドの「Self-correction」という節にも、こう書かれています。
Avoid instructing re-checks it already performs (“double-check your answer,” “re-verify before responding”); like verification instructions, these compound with the model’s own behavior and add cost without improving results.
「もう一度確かめて」「答える前に再検証して」のような、Opus5がすでに自分でやっている再確認を重ねて指示するのは避けたほうがいい、ということです。動画で言われていた「チェックして」「見直して」を消すというコツは、この2か所とちゃんと一致していました。
ただし、ここで1つ注意点があります。上の引用の最後の一文をよく見ると「工程を分けて検証の段を足す、旧来のしくみについても同じことが言える」とあり、作業する人と確認する人を分ける、いわゆる工程を分けた検査もこの「消していい」に含めて読める書き方になっているんです。一方で、公式には工程を分けた検証を今も有効な型として載せている文章もあります。この食い違いをどう受け止めたか、記事の後半で正直に書きます。
引用の原文を確かめたい方は、こちらの公式ページもご覧ください。
Prompting Claude Opus 5（※英語サイト・自動翻訳推奨）
逆に「足したほうがいい」指定
消す話ばかりではありません。同じガイドには、Opus5は逆に「言わないとやりすぎてしまう」ことも書かれています。3つ紹介します。
仕事の範囲に終わりの線を引く
Claude Opus 5 can also expand the scope of a task, adding steps that weren’t requested or applying its own judgment about what the task should be. For narrow tasks, constrain scope explicitly
Opus5は、頼んでいないステップを勝手に足したり、仕事の範囲を自分で広げたりすることがあるそうです。狭い範囲の仕事を頼むときは、範囲をはっきり区切る指示を入れるのがコツとのこと。公式にはお手本の文まで載っていて、「頼まれたことを、意図された範囲でやり切ること」「明らかに頼まれた範囲を超える行動の手前で止めること」という言い方をしています。
これは、AIに仕事を渡すときのゴールの決め方の話ともつながります。関連する話は前に書いたこちらの記事にもまとめています。
Claude Codeのgoalの使い方の記事はこちらサブエージェントを呼びすぎる
Claude Opus 5 delegates to subagents more readily than prior models. Delegation pays off on genuinely independent, sizeable tracks of work, but it multiplies cost and time when applied to small tasks.
Opus5は前のモデルより気軽にサブエージェント（作業を任せる別のAI）を呼び出すそうです。独立していて量のある仕事なら任せる価値がありますが、小さい仕事にまで使うと、コストと時間がかさむとのこと。公式のお手本文には「自分で数回の操作で終わる仕事は任せない」「自分の作業の検証にサブエージェントを使わない」とあります。動画で言われていた「軽い仕事はサブエージェントを使わないでと一言足す」は、この公式の書き方とそのまま合っています。
返答も成果物も長くなる
Claude Opus 5’s default user-facing responses run longer than prior Opus models’. The effort parameter controls how much the model thinks rather than how much it says … To control response length, prompt for it explicitly.
Opus5は、ふつうに使うと前のOpusモデルより返答が長くなるそうです。effort（思考の量を調整する設定）は「どれだけ考えるか」を決めるだけで「どれだけ話すか」は決めない、とはっきり書かれています。だから、返答や成果物の長さをコントロールしたいなら、はっきり長さを指示するしかない、ということです。動画で言われていた、成果物の長さを一言そえておくというコツは、この公式の説明どおりでした。
【実際にやってみた】ぼくの指示書とスキルを開いて数えてみました
ここまでは公式の話ですが、この記事でしか読めないところも書いておきます。ぼくはブログ運営にClaude Codeを使っていて、AIへの指示書（CLAUDE.md）と、部長役・実行役に分けた作業の設定ファイルを持っています。今回、公式の話に合わせて実際に開いて数えてみました！
指示書は138行でした（2026年8月時点で）
- 指示書（CLAUDE.md）の行数：138行（2026年8月時点で）
- 役割ごとの設定ファイルの本数：9本。全部が「あなたは〜部の部長です」「あなたは〜部の実行者です」という役割の宣言から始まっていました
- 記事作成用のチェックリストの項目数：21項目
Claude Codeのメモリー（指示書のしくみ）についての公式ドキュメントには、こう書かれています。
Size: target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence.
「CLAUDE.mdは1ファイルあたり200行未満を目標に。長いファイルは処理の余地を食い、指示への追従を下げる」とのことです。ぼくの指示書は138行（2026年8月時点で）なので、この基準の中に収まっていました。役割の宣言から始める9本の設定ファイルも、公式が今も勧めている「役割を持たせる」という書き方に合っていました（この話は次のセクションで詳しく取り上げます）。
/doctorを動かしてみたら、肝心なところが機能しませんでした
Claude Codeにはもう1つ、/doctorという機能があって、公式のコマンド一覧にはこう説明されています。
… trims checked-in CLAUDE.md files by cutting content Claude could derive from the codebase, and migrates the always-loaded guidance that remains into skills and nested CLAUDE.md files that load on demand.
指示書から不要な内容を削り、スキルという別ファイルに移す提案をくれる機能です。動かした結果、設定ファイル5つ・役割ごとの設定ファイル9つ・スキル20個の冒頭情報まで、壊れているところは1つもありませんでした。指示書は31,656文字・138行で、「重い」の目安（約40,000文字）の79%でした。ただ、いちばん試したかった、使っていないスキルを見つけて消す機能は使えませんでした。ブラウザ（クラウド）で作業場所が毎回作り直されるため利用履歴が1件しかなく、判定材料がゼロでした。クラウドで動かす以上どうにもならない話で、設定の間違いではありません。期待していた分、評価は下がりましたが、「指示書はあと8,000文字ほど足せる」と分かったのは収穫でした。
チェックリストを3段に分けたら、廃止したはずのルールが出てきました
チェックリスト21項目を3段に分けました。項目は増減していません。絶対条件（破ったら書き直し）7項目、目安（下回っても不合格にしない・根拠は経験則の数字）7項目、中身を読んで確かめる項目7項目です。
分ける途中で見つかったもののほうが大きな話でした。チェックリストの入ったファイルから少し離れた場所に、「記事は8,000〜12,000文字で書く」という先月廃止したはずのルールが生き残っていたんです。この数字には実害があり、守ろうとしてある記事から558文字を削り、商品の不具合や見え方の悪評まで消していました。販売元のコピーではない、その記事にしか無い情報でした。廃止のとき手引きと機械のチェックは直したのに、このファイルだけ、ブログの原稿とは別のアカウント全体の設定にあったせいで直し漏れていました。同じ決まりを2か所に書くと、片方だけ直して片方が取り残されるんですね。今回試した中で、いちばん効いたのはこれでした。
ちょうどここまで、Claude Codeの指示書や/doctorの話をしてきました。もう少し実践的に手を動かしたい方には、Claude Codeの使い方をまとめた解説書も出ています。西見公宏さん・吉田真吾さん・大嶋勇樹さんの3名が書いた『実践Claude Code入門』という本で、指示書の書き方や運用の話が近いテーマの1冊だと思います。楽天ブックスのレビューは4点です（2026年8月24日時点・レビューはまだ1件だけです）。ぼくはまだ読んでいないので中身の評価はできません。同じように指示書を自分で書いている方は、一度手に取ってみると発見があるかもしれません。
※以下は楽天アフィリエイト・Amazonアソシエイトの成果報酬型広告のリンクです。
ここで書いた作業のやり方は、こちらの記事にもう少し詳しくまとめています。
Claude Codeでブログ運営を自動化する方法はこちらもう少し詳しく知りたい方は、下の公式ドキュメントもどうぞ。
How Claude remembers your project／Claude Codeのコマンド一覧（いずれも※英語サイト・自動翻訳推奨）
鵜呑みにしなくていい①「お手本を貼るのは逆効果」
動画では「過去の案内メールを何通も貼って書かせたら、同じような焼き直しの文章になった。お手本は貼らないほうがいい」という実演がありました。これは、鵜呑みにしないほうがいい話だと思いました。
Anthropicの「Prompting best practices」という別のガイドには、今もこう書かれています。
Examples are one of the most reliable ways to steer Claude’s output format, tone, and structure. A few well-crafted examples (known as few-shot or multishot prompting) improve accuracy and consistency.
「お手本の例示は、Claudeの出力の形式・トーン・構造を導く、もっとも信頼できる方法の1つ。よく練られた数個の例示は、正確さと一貫性を上げる」とのことです。さらに「Include 3–5 examples for best results（最良の結果には3〜5個の例示を）」ともあります。
ただ、条件も書かれていて、お手本は「実際の使い方を写していること」「バラエティがあること（Claudeが意図しない型を勝手に拾わない程度にばらけていること）」「タグで構造化されていること」の3つが要るとされています。動画の実演は、過去の案内メールという似た内容ばかりを貼っていて、このバラエティの条件から外れた使い方だったように見えます。お手本そのものがダメというより、お手本の選び方の話だったように、ぼくには見えました。
実は、この違いをもっとはっきり言い切っている文章も見つかりました。Anthropicのエンジニアが書いた「The new rules of context engineering for Claude 5 generation models」には、こう書かれています。
The number one rule for tool usage was to give Claude examples on how to use them. With our newest models, we’ve found that giving examples actually constrains them to a certain exploration space. Instead of using examples, think more about the design of your tools, scripts and files- what parameters does Claude have and how can they be more expressive?
訳すと「道具（ツール）の使い方を教えるには、Claudeにお手本を見せるのがいちばんの鉄則だった。でも最新モデルでは、お手本を見せるとかえって探索の幅を狭めてしまうことが分かった。お手本を使う代わりに、道具やスクリプト・ファイルの設計そのものを見直したほうがいい」とのことです。ここでやめろと言われているのは道具の使い方を教える例示であって、文章のトーンや構成を導く例示ではありません。動画の実演は文章の焼き直しの話だったので、公式がここでやめろと言っている対象とは別物です。
The new rules of context engineering for Claude 5 generation models（Thariq Shihipar・※英語サイト・自動翻訳推奨）
ぼくのブログでは、口調の手本になる記事を3本決めていて、それを見て「ですます調・一人称ぼく」を確認する運用をしています。これは公式が今も勧めているやり方なので、そのまま続けます。
鵜呑みにしなくていい②「役割設定はもう卒業」と、そのほか気になった3つ
動画では「役割を名乗らせる（あなたは〇〇の専門家です、のような書き方）はもう卒業していい」という話もありました。動画自身も「あかんわけじゃないんやけど」と、言い切らない言い方をしたうえでの話でしたが、公式とは少し違っていました。
「Prompting best practices」の「Give Claude a role」という節には、今もこう書かれています。
Setting a role in the system prompt focuses Claude’s behavior and tone for your use case. Even a single sentence makes a difference
「システムプロンプトで役割を設定すると、Claudeの振る舞いとトーンが用途に合わせて絞られる。たった1文でも違いが出る」とのことです。ぼくの部長・実行者の設定ファイル9本は、全部この役割宣言から始まっていて、公式がまだ勧めている書き方に乗っていました。ここはやめる理由がありません。
そのほかにも、動画を見ていて「これは公式で確かめられなかった」「半分だけ合っている」と感じた点が3つありました。
effortを上げるとトークンが7倍という数字
動画にあった「effort（思考の量の設定）を上げるとトークンが7倍になる」という数字は、Effortについての公式ドキュメントにも、Opus5の発表ページにも見つけられませんでした。近い数字として発表ページには、ある企業の事例で「推論トークンが前のモデルの約7分の1になった」という、向きが逆の記述がありました。もしかすると、この「7分の1」と取り違えられたのかもしれません。ただしこれはぼくの推測で、確かめられてはいません。
「上げすぎると質が落ちうる」こと自体は公式にも書かれています。effortを上げすぎたときの過剰な探索と、対処としてeffortを下げる案がPrompting best practicesに載っています。
effortは「賢さ」ではなく「量」の設定という説明
Effortの公式ドキュメントには、こう書かれています。
By default, Claude uses high effort, spending as many tokens as needed for excellent results. You can raise the effort level to max … or lower it to be more conservative with token usage, optimizing for speed and cost while accepting some reduction in capability.
「既定ではhigh effortが使われ、優れた結果に必要なだけトークンを使う。effortをmaxまで上げることも、速度とコストを優先して控えめに下げることもできるが、下げると能力の低下を受け入れることになる」とのことです。つまり、量の設定であると同時に、下げれば能力が落ちるのを受け入れる設定でもあります。「基本のままでいい」という動画の話自体は、公式の「Start with high, the default（既定のhighから始める）」と一致していました。effortについてはこちらの記事にも書いています。
Claudeのエフォート（effort）の記事はこちら英語の原文が気になる方は、下のリンクも覗いてみてください。
Effort（※英語サイト・自動翻訳推奨）／Prompting best practices（※英語サイト・自動翻訳推奨）
無料プランでも同じ指示だしが使えるという話
動画では「無料プランでもProプランでも、同じような指示だしのコツが使える」という言い方もありました。Opus5の発表ページには「the strongest model on Claude Pro（Claude Proでの最強モデル）」とは書かれていますが、無料プランでの提供については書かれていません。それに、ここまで紹介してきた「検証指示を消す」というコツは、Opus5専用のガイドに書かれた話です。汎用のPrompting best practicesのほうは、今でも「下書きを作る→基準に照らして確認する→確認をもとに練り直す」という自己検証の連鎖を、有効なやり方として載せています。モデルが変われば、正しい指示だしも変わる、ということだと思います。
いちばん間違えやすいところ｜「チェックして」を消すことと、検査をやめることの境目
ここが今回いちばん時間をかけて確かめた部分です。ぼくは最初「公式が消せと言っているのは同じやり取りの中の再確認だけで、工程を分けた検査は対象外」と決めつけて書いていました。でも、公式ドキュメントを並べ直すと、そう言い切れないことが分かったんです。
消す方向に傾いている記述が2つあります。1つは前のセクションで紹介した「remove them」の一文（工程を分けた検証の仕組みにも同じことが言える、と続いていました）。もう1つは、サブエージェントの節にあった「自分の作業の検証にサブエージェントを使わない」というお手本文です。
一方で、残す方向の記述もちゃんとあります。1つは「Prompting best practices」の「Chain complex prompts」という節です。
The most common chaining pattern is self-correction: generate a draft → have Claude review it against criteria → have Claude refine based on the review. Each step is a separate API call so you can log, evaluate, or branch at any point.
「もっとも一般的な連鎖のパターンは自己修正で、下書きを作る→基準に照らしてClaudeにレビューさせる→レビューをもとにClaudeに練り直させる、という流れ。各ステップは別々の呼び出しなので、途中で記録・評価・分岐ができる」とのことです。
もう1つは、公式ブログ「The new rules of context engineering for Claude 5 generation models」の一文です。
if you have several unique instructions on how to verify your work, create a verification skill and reference it from your CLAUDE.md.
訳すと「作業の確かめ方について独自の指示がいくつもあるなら、検証用のスキルを作って、指示書（CLAUDE.md）からそれを参照するようにする」とのことです。捨てろではなく、常に読む場所から外して別ファイルに置け、という言い方です。
つまり公式の中でも、書き方が揃っていません。同じ応答の中の再確認と、工程を分けた検証をまとめて「消していい」と読める書き方と、工程を分けた検証は今も有効な型として使ってよい、と読める書き方の両方があります。
そのうえで、ぼくは検査を残す側を選びました。理由は理屈ではなく、この記事を作る途中で実際に起きたことです。作る役と検査する役を分けていたおかげで、書いた側の間違いが4つ見つかりました。項目数の数え違い、引用で根拠をすり替えていた箇所、本文と表の内容が食い違っていた箇所、そしてこの章の冒頭で書いた、この記事の一番強い主張の元になっていた公式原文の引用の見落としです。検査を外していたら、この4つは全部そのまま公開まで残っていたはずなんです。
ぼくが見た限りでは、動画にはこの区別ははっきり出てきませんでした。動画のコツをそのまま真似ると、工程を分けた検査まで一緒に外してしまうかもしれません。
まとめ｜消していい指示と、消してはいけない指示
Claude Opus5のプロンプトのコツを、Anthropicの公式ドキュメントで1つずつ確かめてみました。検証の指示を消す、仕事の範囲を区切る、サブエージェントを呼びすぎない、返答や成果物の長さを指定する、仕事の全体像を最初に渡す、動画のこうした話は、公式ガイドの原文とちゃんと合っていました。一方で、お手本を貼ることと役割を設定することは、公式が今も有効だとしている側にあって、動画の「もう卒業していい」という話とは違っていました。システムプロンプトを8割削っても性能が落ちなかったという話は、対象がClaude Codeのシステムプロンプトとコーディング評価に限られる形で公式の原文にありました。effortでトークンが7倍になるという数字は、公式の原文では見つけられませんでした。
いちばん大事だと感じたのは、「チェックして」を消すことと、検査そのものをやめることは別だという点です。AIに指示を出すときは、同じやり取りの中で重ねている確認は消してよくても、作る人と確かめる人を分ける仕組みは残したほうがよさそうです。ClaudeやClaude Codeでできることの全体像は、こちらの記事にもまとめています。
Claudeとは何ができるかの記事はこちら動画を見て気になっていた/doctorとチェックリストの3段分け。この2つは、今日実際にやってみました。今回試した中でいちばん効いたのはチェックリストを3段に分けたことで、途中で廃止したはずのルールが出てきたのは大きな収穫でした。一方の/doctorは、肝心の「使っていないスキルを見つけて消す」機能をぼくの環境では試せず、期待したほどではありませんでした。残った目安7項目は、根拠が経験則しかない数字ばかりなので、次はここを作り直そうと思います。
コメント