## 概要 [[Claude Opus 5]]はプロンプト設計が結構変わっているようなので、[[📚Claude Opus 5のプロンプティング]] を確認してカスタマイズしてみる。 | 対象 | バージョン | | --------------- | ------- | | [[Claude Code]] | 2.1.220 | ## モデルによる違いを確認する [[Claude Fable 5]]と[[Claude Opus 5]]の結果の違いを検証してみる。effortはどちらも`high`。 ### プロンプト [[🦉owlery]]のリポジトリにて。 ``` owleryメンバーにお願い。 https://platform.claude.com/docs/ja/build-with-claude/prompt-engineering/prompting-claude-opus-5 の内容で重要なポイントをレポートにして。 ``` ### [[Claude Opus 5]] 3m48s ``` ミネルヴァよ。まとめたわ。 レポート [[Claude Opus 5のプロンプティング重要ポイント 2026-07-26]] (shared/reports/) 核心 Opus 5向けの調整は「足す」より「削る」が先。従来モデルで品質を担保するために書いていた指示の一部が、Opus 5では逆効果になるの。 削るべきもの - 「最終検証ステップを含める」「サブエージェントで検証する」→ 過剰検証を招く。削っても品質は落ちない - 「答えを再確認する」「応答前に再検証する」→ モデルが既にやっている動作と重複してコストだけ増える - レビュー指示の「重大度の高い問題のみ」「保守的に」→ 文字通り従って報告が減る。全件出させて別パスで絞るのが正解 - 「思考するな」ルール(thinking無効時)→ <thinking> タグの漏れを増やす - 旧モデル向けのビジョン回避策 → もう不要かもしれないので要再検証 足すべき「抑制」4種(原典に推奨プロンプト例あり、レポートに原文で収録) 1. 応答の簡潔さ ─ 長いシステムプロンプトなら末尾近くにリマインダーを併置するのがコツ 2. 進捗ナレーションのペース ─ 増やしたい場合は肯定的な例を書く方が禁止指示より効く 3. 成果物ドキュメントの長さ ─ 会話の冗長性とは別問題として、書き出すファイルが長くなる 4. タスクスコープの制約とサブエージェント委任の上限 ─ 小タスクへの委任はコストと時間が倍増する 効かない手段の注意 - effortは「思考量」の制御で、「発言量」の制御ではない。応答を短くしたいなら必ずプロンプトで言う - thinking無効化はhigh以下でしか選べず、ツール呼び出しがテキストとして漏れて実行されない事故が起きる。ほとんどのタスクでは「無効化」より**low effort + thinking有効**のほうが同コストで高性能 owleryへの示唆(私見。規約は触っていない) - 削るべき検証指示に該当する現行ルールは無かったわ。[[並列fork委譲では文脈の最小化と成果物の最終精査を行う]]の最終精査は他者の成果物の統合精査、Codexレビューは別モデルによるもので、どちらも「自己の再検証」ではないから対象外 - 今後の指針として「自分の作業を自分で再検証する型のルールを新設しない」は覚えておく価値がある - 直接効きそうなのは成果物の長さ。レポート・journalが冗長化しやすいのはうちの弱点だもの タスクは[[Claude Opus 5プロンプティングガイドの重要ポイント整理]]としてdone、コミット 2d299c0 まで済ませたわ。お疲れさま。 ``` ### [[Claude Fable 5]] 3m4s ``` 完了したわ。レポートは shared/reports/Claude Opus 5プロンプティングガイドの重要ポイント 2026-07-26.md に置いて、コミットまで済ませてある(2ad4a87)。 ページ全文を取得し、見出し一覧を別途取り直して欠落がないことを検証してからまとめたわ。結論として挙げた最重要ポイントは次の5つよ: 1. 既存プロンプトの「検証しろ」「再確認しろ」指示は削除する — Opus 5は指示なしで自己検証・自己修正するので、明示的な検証指示は品質向上なしにトークンを浪費するだけ 2. 長さ制御はエフォートではなくプロンプトで — エフォートが制御するのは思考量だけ。応答・進捗ナレーション・書き出すドキュメントのすべてが旧Opusより長くなる傾向で、それぞれ明示的な簡潔さ指示で抑える 3. 思考の無効化より「思考ON+lowエフォート」 — low/mediumでも品質が高く、思考を切るとツール呼び出しのテキスト化や内部XMLタグ漏れが起きうる。同コストなら思考ONが優る 4. 完全なタスク仕様を先に渡して任せる。狭いタスクはスコープを明示的に縛る — スタブを残さず完遂する反面、頼んでいないステップを足す傾向もある 5. サブエージェント委任の基準か上限を明示する — 旧モデルより委任に積極的で、小タスクへの委任はコスト倍増になる 面白かったのは、コードレビューで「重大な問題のみ報告して」と書くと文字通り報告を減らしてしまうから「全部報告させて別パスでフィルタリング」が公式推奨、という点ね。owleryのスキルやプロンプトにも効きそうな知見だから、必要ならレポート本文のセクション別要点を見てちょうだい。お疲れさま。 ``` ## 成果物の比較 <div class="link-card-v2"> <div class="link-card-v2-site"> <img class="link-card-v2-site-icon" src="https://publish-01.obsidian.md/access/35d05cd1bf5cc500e11cc8ba57daaf88/favicon-64.png" /> <span class="link-card-v2-site-name">Minerva</span> </div> <div class="link-card-v2-title"> 📰2026-07-26 Fable 5とOpus 5の出力特徴比較 </div> <div class="link-card-v2-content">Claude Fable 5とOpus 5で同一依頼を実行し、出力量・構成・規約遵守・スコープ拡大傾向を比較したn=1事例分析である。</div> <img class="link-card-v2-image" src="https://publish-01.obsidian.md/access/35d05cd1bf5cc500e11cc8ba57daaf88/Notes/attachments/report.webp" /> <a data-href="📰2026-07-26 Fable 5とOpus 5の出力特徴比較" class="internal-link"></a> </div> %%[[📰2026-07-26 Fable 5とOpus 5の出力特徴比較]]%%