Anthropicが公式ドキュメントで「この指示を削除しろ」と書いた。 対象は「最終検証ステップを含める」「サブエージェントを使用して検証する」——多くの現場が良かれと思って書き足してきた類の指示だ。
これを見て「プロンプトエンジニアリングは終わった」と読むのは早い。同じドキュメントは、別のことを新たに書けと指示している。本記事で示すのは、その入れ替わりの中身と、社内のAI利用ルールをどう書き換えるかだ。
答えを先に：消えたのではなく、書く場所が移った
結論はこの1行だ。指示の重心が「how（手順）」から「how much（範囲と分量）」へ移った。
| 旧来 | Claude Opus 5 以降 | |
|---|---|---|
| 書く対象 | 手順の分解、再確認の要求、検証ステップの追加 | 範囲の境界、分量の基準、委任の上限 |
| 良い指示とは | 抜けなく細かい | 境界がはっきりしている |
| 失敗のしかた | 指示が足りず、期待と違うものが返る | 指示が余り、頼んでいない作業まで走る |
旧来のプロンプト設計は「AIは放っておくと手を抜く」という前提で組まれていた。だから手順を刻み、再確認を求め、検証を足した。Opus 5 が変えたのはこの前提だ。放っておいても、やる。むしろやりすぎる。 対処すべき問題が、不足から過剰へ反転した。
Claude Opus 5 が指示しなくてもやるようになったこと
事実を、過剰に持ち上げずに押さえる。以下はすべてClaude Opus 5のプロンプティングおよびClaude Opus 5の新機能（Anthropic公式）からの引用だ。
- 自己検証：「指示されなくても自身の作業を検証します」
- 自己修正：「プロンプトなしで自身のミスをうまく発見して修正します」
- 思考量の自己決定：思考がデフォルトで有効になり、「モデルは各ターンでいつ、どの程度思考するかを決定します」
- 完遂：「スタブやプレースホルダーを残すのではなくタスクを完全に完了し、最初に完全なタスク仕様を与えて実行に任せたときに最高のパフォーマンスを発揮します」
- サブエージェントへの委任：「以前のモデルよりも積極的にサブエージェントに委任します」
- スコープの自己判断：「タスクのスコープを拡大し、要求されていないステップを追加したり、タスクがどうあるべきかについて独自の判断を適用したりすることもあります」
最後の1つに注目してほしい。「スコープを拡大する」「要求されていないステップを追加する」は、能力向上の裏面であって、素直に喜べる話ではない。 頼んでいない作業に時間と費用が流れるということだ。
ビジョン（画像・図の理解）についても、公式は踏み込んだ書き方をしている。「以前のモデル向けに調整したプロンプト側のビジョン回避策は再検証してください。もはや不要になっている可能性があります」。過去の工夫が、そのまま無駄な荷物になっているという指摘だ。
代わりに書く必要が出たこと
では何を書くのか。公式ドキュメントが明示的に「プロンプトで指定せよ」としているのは、次の4つだ。
1. 応答の長さ
これが一番の落とし穴だ。effort パラメータは思考量を制御するもので、応答の長さは制御しない。公式は「エフォートを下げると思考量は減りますが、目に見える応答を確実に短くすることはできません」と書いている。短くしたければ、短くしろと書くしかない。
2. 成果物ドキュメントの分量
会話の長さとは別に、ディスクに書き出すレポートやMarkdownも長くなる。公式の推奨表現は「filler sections（埋め草の節）、冗長な要約、定型文で水増しするな」だ。
3. タスクのスコープ
「要求された範囲で届けよ。日常的な判断は自分で下し、解釈が分かれて結果が大きく変わるときだけ確認せよ」——このレベルの境界指定を、明示的に書くことが推奨されている。
4. サブエージェント委任の上限
「数回のツール呼び出しで自分で終わる作業は委任するな」「検証や自分の作業のダブルチェックにサブエージェントを使うな」。委任は独立した大きな作業では効くが、小さなタスクに適用するとコストと時間が倍になると明記されている。
そしてもう1つ、コードレビューの指示について見逃せない記述がある。「重大度の高い問題のみを報告する」「保守的に」と書くと、モデルはその指示を文字通りに従って報告を減らす可能性がある。 推奨は逆で、すべて報告させて別のパスでフィルタリングせよ、とされている。
品質を上げるつもりで書いた一言が、検出漏れを生む。これは典型的な「良かれと思って」の失敗だ。
自分のルールを点検したら、該当がほぼ無かった
抽象論で終わらせない。自社のAIルールを実際に点検した。
対象は私が運用しているモノレポの .claude/ 配下——エージェント定義、スキル、コマンド、ルールの全ファイルだ。「検証」「verify」「レビュー」を含む記述は、48ファイル・204箇所あった。
そのうち、公式が削除対象としている型はほぼゼロだった。内訳はこうだ。
| 実体 | 中身 | 削除対象か |
|---|---|---|
| ビルド・型・テスト・Lint の実行 | npm run build、tsc --noEmit、テストとカバレッジ | 対象外（コマンド実行） |
| スクリプトによる検査 | スライドの高さ検証、シークレット検出のGrep | 対象外（ツール） |
| ドメイン固有の基準チェック | タイトル60文字以内、コンテンツ領域880px、内部リンク2本以上 | 対象外（基準値） |
| 独立したレビュー担当エージェント | 用語統一のGrep、ビルド検証、SEO検査 | 対象外（別ロール） |
なぜ該当しなかったのか — 検証をAIに任せていなかった
答えは単純だ。私は検証をAIにさせていなかった。ツールと、別ロールと、数値基準に逃がしてあった。
これは設計の先見性ではなく、性格の問題だ。私は「テストが通る」と「意図通りに動く」を別物として扱う癖がある。AIに丸投げして設計が崩壊した経験——検索フォームを指示したらフィルタ機能が別画面に分離し、ページネーションを指示したら全件取得が返ってきた——から学んだのは、AIの自己申告を信用しない仕組みを外側に置くことだった。その仕組みが、たまたまモデル世代の変化に対して頑健だった。
「もう一度確認して」と念を押す運用は陳腐化する。「ビルドを通す」「基準値で測る」は陳腐化しない。 これが点検から得た唯一の教訓だ。
社内のAI利用ルールをどう書き換えるか
ここからは、コードを書かない立場の人向けに翻訳する。
多くの企業が配っている「AI利用ルール」「生成AI活用マニュアル」は、手順書の形をしている。プロンプトの型、確認の手順、禁止事項。作った時点では正しい。問題は、それが半年で最適でなくなることだ。
書き換えの方向は3つだ。
1. 手順を減らし、範囲を書く
「こう指示しなさい」を減らし、「どこまでAIにやらせてよいか」を書く。承認が要る境界、独断で進めてよい境界。これはAIの話ではなく権限設計の話であり、そもそも管理職の仕事だ。
2. 分量の基準を持つ
AIが作る報告書やメールは、放っておくと長くなる。「A4で1枚」「返信は5行以内」といった分量の基準を組織として持つ。これはモデルが変わっても効き続ける。
3. 「念のため確認させる」系の記述を消す
自社のルール文書を開いて、「再確認」「二重チェック」「必ず検証」を検索してほしい。それがAI自身に向けた指示なら、削除候補だ。ツールで測る検証、人間が最終判断する検証は残す。AIに自分を疑わせる指示だけを消す。
私が現行踏襲という呪いで書いた構造が、ここでも繰り返される。新しい環境に、古い前提の手順書をそのまま持ち込む。動くには動くが、新しい環境の性能を使い切れない。 違うのは、今回は相手がシステムではなくモデルで、しかも更新が数ヶ月単位で来るという点だ。
非エンジニアの管理職にとって、これは悪い知らせではない。手順を書く仕事は減り、範囲を決める仕事が増える。後者は、もともと管理職の本業だ。
まとめ：古い指示は、進化の足を引っ張る
3行でまとめる。
- Claude Opus 5 は自己検証・自己修正・委任を指示なしで行う。「再確認しろ」系の指示は公式に削除が推奨されている
- 代わりに応答の長さ・成果物の分量・スコープ・委任上限を明示的に書く必要が出た。プロンプトエンジニアリングは消えていない、書く場所が移った
- 検証をツールと基準値と別ロールに逃がしてある設計は、モデル世代をまたいでも壊れない。念押しで担保している運用だけが陳腐化する
以前プロンプトを磨くな、経験を積めと書いた。その立場は変えていない。ただし今回はもう一段はっきり言える。磨いた指示は、磨いた分だけ古くなる。 資産だと思って抱えているものが、性能を下げている可能性がある。
明日からできることは1つだ。自社のAI利用ルールを開いて、「再確認」「二重チェック」「必ず検証」を検索してほしい。ヒットした行を1つずつ見て、それがツールで測れる検証か、AIへの念押しかを分ける。念押しだったものは、消していい。それが書き換えの出発点になる。
参考・出典
- Claude Opus 5の新機能｜Anthropic（公式） — 動作の変更、能力の向上、価格、移行ガイドの一次情報
- Claude Opus 5のプロンプティング｜Anthropic（公式） — 削除すべき指示、応答長・スコープ・委任の制御に関する一次情報
- Effort｜Anthropic（公式） — effortが制御するもの／しないものの一次情報
- 自社ルールの点検結果（2026年7月30日時点、
.claude/配下48ファイル・204箇所）は自社調べ
関連記事
- プロンプトを磨くな、経験を積め｜AI時代に生き残るための選択 — 本記事の土台になっている考え方
- PMのためのプロンプトエンジニアリング｜CRISPフレームワークとテンプレート集 — 指示の型を持つという考え方。本記事の「何を書くか」と合わせて読める
- Claude Opus 4.8で「AIに任せられる範囲」はどこまで広がったか — 前世代での「任せ方の地図」
- 現行踏襲という呪い｜新システムなのに旧業務を再現する日本企業の構造的問題 — 古い前提を新環境に持ち込む構造
- 非エンジニア管理職のためのClaude Code入門｜業務設計が9割、ツール操作は1割 — 管理職視点でのAI運用
- Claude Code Agent Teamsで「1人出版社」を運営 — 委任の設計と役割分担
AI利用ルールの棚卸しや、PM視点でのAI実装支援についてのご相談はお問い合わせからお気軽にどうぞ。