Claude Opus 5向けプロンプト設計の方法

TL;DR

Claude Opus 5では、重複する再確認やレビューの強制指示を減らし、タスク範囲、出力長、進捗報告形式、サブエージェント上限を明示する。thinkingは原則オンのまま、軽い対話はlowやmedium、長時間のループはxhighなど、effortを作業別に調整するとコストと品質を管理しやすい。

Transcript

お様さです。本日はですね、クロードの オパス5、このモデルについてプロンプト ガイドがね、ありますんで、え、お話しし ていきたいと思います。え、実はね、この クロードオパス5結構従来のモデルと違う 傾向みたいなのがありまして、ま、 ナレッチカットオフとかもね、2026年 の5月だったりとかして、ま、ソネッ5で あったりだとか、Fイブル5っていうのは 2026年の1月だったみたいな話を前回 の動画で、え、やらせていただいたんです けれども、ま、ま、結構最新な部分もあっ て、ま、例えばビジョン系が強くなってる とかね、ま、いろんな部分で、ま、能力が 向上していたりします。ま、Oパス4.8 と比較すればもうそれはね、別のだという ぐらい同じオパスという名前で0.2しか 変わらないのにも全然違うみた... Read More

Key Insights

• Claude Opus 5は、検証や自己修正を明示的に命じなくても自発的に実行する傾向があり、従来の重複した確認指示は削減候補である。
• 応答の長さはeffortを下げるだけでは調整できず、会話回答、作業中の報告、最終成果物を分けて希望する長さを直接指定する必要がある。
• thinkingは既定でオンになっており、話者は原則として維持したまま、タスクの重さに応じてeffortを切り替える運用を勧めている。
• 進捗報告は、頻度、情報の粒度、表示形式を明記すると制御しやすく、長すぎる作業実況による利用者の認知負荷も抑えられる。
• サブエージェントの利用は積極的になる傾向があるため、使用量を抑えたい場合は同時実行数や利用条件をプロンプトで制限する必要がある。
• 検証ツールは必ず使わせるのではなく、選択肢や参考情報として提示すると、モデル独自の検証方法を残しながら有効な手段へ誘導できる。
• 自己レビューの固定手順は、モデルの能力に対する天井や余分なコストになり得るため、実際の失敗を観察して必要な制約だけを戻す方針が適する。
• 性能向上の評価は、長時間のコーディング、コードレビュー、画像理解、低effort時の応答を試した話者の体感を含み、定量的な比較ではない。
• 🎬 このチャンネルの他の動画:
  • Agent Browserでブラウザを操作する方法
  • GLM Imageは低コスト画像生成に使えるか？
  • Tencent Hy4 previewの実力と弱点は？
• 📺 このチャンネル: まさおAIじっくり解説ch

Questions & Answers

Q: Claude Opus 5向けプロンプトから何を削るべきですか？

重複する検証、ダブルチェック、固定的な再レビューの強制指示を削ることが候補です。Claude Opus 5は自発的に検証して修正する傾向があるため、従来の細かな確認手順が品質を高めず、処理量やコストだけを増やす場合があります。まず任せて動作を観察し、重要な漏れが確認された箇所だけ指示を戻します。

Q: Claude Opus 5向けプロンプトには何を追加すべきですか？

タスクの範囲、希望する出力長、進捗報告の頻度・粒度・形式、必要に応じたサブエージェント数の上限を追加します。自律性が高いモデルは依頼外の検証まで広げることがあるため、検証方法を細かく縛るよりも、何を完了条件とし、どこまでが作業対象なのかを明示する方が適しています。

Q: Claude Opus 5の応答を短くする方法は？

応答の長さをプロンプトで直接指定します。effortは思考量やツール利用の程度に関係しますが、表示される文章の長さを自動的に短くする設定ではないと説明されています。会話への返答、作業中の進捗報告、最終成果物を別々に扱い、それぞれの長さや形式を明記すると制御しやすくなります。

Q: Claude Opus 5のthinkingはオフにすべきですか？

原則としてthinkingをオンのまま使い、effortで負荷を調整する運用が勧められています。動画ではthinkingが既定でオンになり、オフにできるのは一定のeffort以下だと説明されています。また、オフにした場合はツール命令や内部タグの漏れを防ぐための追加プロンプトが必要になる可能性にも触れられています。

Q: Claude Opus 5のeffortはどう使い分けますか？

軽い壁打ちや素早い回答にはlowまたはmedium、長時間のループや念入りな作業にはxhighを使い分けます。話者は、検証や多数のツール呼び出しを必要としない作業なら低effortでも速く、十分に賢いと評価しています。ただし、これは動画内の使用感に基づく説明であり、定量的な比較結果は示されていません。

Q: サブエージェントの利用コストを抑える方法は？

同時実行数と利用条件を明示し、簡単な作業では呼び出さないようにします。Claude Opus 5はサブエージェントを積極的に利用する傾向があるため、制約がなければ必要性の低い作業でも使用量が増える可能性があります。大規模で独立した移行作業などに限定し、単純な処理は主エージェントに任せる設計が示されています。

Q: 既存の検証ツールをClaude Opus 5に使わせる方法は？

必須手順として固定するのではなく、利用可能なツールやスキルとして存在を知らせ、必要なら参考にできる形にします。モデル自身がより適切な検証手段を作れる場合、質の低い既存ツールを強制するとボトルネックになり得ます。重要な問題にだけ候補を提示し、使用するかどうかの判断を残す方法が提案されています。

Q: Claude Opus 5の進捗報告を読みやすくする方法は？

進捗を出す頻度、含める情報の細かさ、表示フォーマットを事前に指定します。Claude Opus 5は実行予定や作業状況を積極的に述べ、レポートも長くなる傾向があると説明されています。短い節目だけ報告する、定型の報告形式を参照させるなど、利用者の認知負荷を抑える条件を具体化することが有効です。

Summary & Key Takeaways

• Claude Opus 5は、明示されなくても検証や自己修正を行い、必要に応じてサブエージェントも利用する自律性の高いモデルとして紹介されている。そのため、従来のCLAUDE.mdなどに書いていたダブルチェック、固定的な検証手順、別エージェントによる再レビューの強制は、品質向上につながらずコストだけを増やす可能性がある。まずモデルに任せ、実際の不足を観察してから制約を追加する設計が推奨される。

• 一方で、自律性が高いほど依頼範囲を超えた検証、長い応答、頻繁な作業実況、多数のサブエージェント呼び出しが起こりやすい。タスクの境界、会話回答と成果物の長さ、進捗報告の頻度・粒度・形式、同時実行数はプロンプトで直接指定する必要がある。話者は、既存ツールを必須にするのではなく、利用可能な選択肢として示し、モデル自身の方法を妨げない抽象度で誘導する案も提示している。

• コスト管理では、thinkingを切るよりも、オンの状態を前提にeffortを作業別に変える方法が中心となる。壁打ちや短い回答にはlowやmedium、放置して回す長時間ループにはxhighを使うという例が示された。サブエージェントは大規模で独立した作業に使い、簡単な作業では呼び出しを抑える。なお、コーディング、レビュー、画像理解、低effort時の性能向上は話者の使用感を含む評価であり、動画内では定量的な検証結果までは示されていない。