Claude Opus 5で「検証して」が逆効果に——AIエージェントへの指示を書き換えるべき理由

Claude Opus 5が「検証して」を要らなくした

Anthropic が公開した Claude Opus 5 向けのプロンプティングガイドには、はっきりとした指示が書かれています。「最終確認の手順を含めてください」「サブエージェントを使って検証してください」「ダブルチェックしてください」といった一文を、プロンプトから削除するようにという内容です。

理由は単純です。Opus 5 は指示されなくても自分の作業を確認します。これまでは検証させるために明示の一文が必要でしたが、いまはモデルの標準動作に組み込まれました。ファイルを編集したあとに自分で読み直す、計算をしたあとに前提を再確認する——こうした振る舞いが、プロンプトに書かなくても起きるようになっています。

私たちの現場経験では、この変化に気づかないまま旧モデル用のプロンプトを使い続けているクライアントが少なくありません。移行作業に入る前は「性能が上がったのだから、指示はそのままでいいはず」と考えていました。正直に言えば、これは想定外でした。指示をそのままにすると、性能が上がった分だけ余計な処理が増えるという逆の現象が起きます。旧モデルの時代は「指示を増やすほど安全になる」という前提で運用していたので、この逆転はなかなか実感として腑に落ちませんでした。

なぜ「検証して」が逆効果になるのか——二重検証の正体

このセクションで言いたいことは、指示の重複がコストとして跳ね返る仕組みです。

Opus 5 は自律的に検証したあと、プロンプトに書かれた「検証して」も別途実行しようとします。同じファイルを読み直し、同じチェックを繰り返し、確認済みの内容をもう一度確認する——これが二重検証です。人間の仕事に例えれば、部下が自主的に見直しを済ませた報告書を、上司が「見直しておいて」と言われたからもう一度最初から見直す、という状態に近いです。

トークン消費が増えるだけでなく、応答も長くなります。ある移行ガイドは「検証指示を消すと、品質を落とさずに無駄なトークンを減らせる」と報告しています。これは私たちが実際に計測した結果とも一致しています。同じ議事録生成タスクを旧プロンプトと新プロンプトの両方で走らせたところ、応答の長さに明確な差が出ました。ここで重要なのは、品質が下がったわけではないという点です。二重に確認していた工程がひとつ消えただけで、出てくる結果自体は変わりません。

厄介なのは、この無駄が1回のタスクでは小さく見えることです。数百字分のトークンが余計に消費される程度で、単発なら気づきません。ところが1日に数十回、数百回とエージェントを動かすようになった現場では、この積み重ねが無視できない規模になります。

実際に測った数字——トークンと応答時間

このセクションで言いたいことは、引き算の効果は感覚論ではなく数字で確認できるということです。

私たちがある議事録AIのプロンプトで、旧モデル向けの検証系の指示を残したまま Opus 5 に切り替えたケースと、指示を削って簡潔さの一文に差し替えたケースを比べました。同じ1時間の会議録を要約させるタスクで、後者は応答時間がおおよそ2〜3割ほど短くなりました。トークンの消費量も同程度の比率で減っています。

正直に言えば、最初はここまで差が出るとは思っていませんでした。二重検証というと、せいぜい数パーセントの上乗せだろうと予想していたからです。ところが検証の対象がファイル全体や長い会議録全体になると、「もう一度読み直す」というだけで相応のトークンを使います。読み直す範囲が大きいタスクほど、引き算の効果は大きく出る——これが私たちの実感です。

もちろん、全てのタスクでこの比率が当てはまるわけではありません。もともと出力が短く、検証対象も小さいタスクでは、差はほとんど出ませんでした。効果の大きさはタスクの性質に依存します。ここは一律に「何割削減できる」と言い切れる話ではなく、案件ごとに実測しながら判断する必要があります。

削るべき指示・残すべき指示

移行時にまず手を動かすべきは、プロンプトの棚卸しです。私たちがクライアントのプロンプト集を見直すときは、次の基準で仕分けています。

削るべき指示

• 「最終確認をしてから返してください」
• 「サブエージェントを使って結果を検証してください」
• 「ダブルチェックしてください」「再確認してください」
• 「間違いがないか慎重に確認してから提出してください」

残す、あるいは書き足すべき指示

• 出力の簡潔さを言葉で明示する指示(「結論を先に、3行以内で」)
• 作業範囲(タスクスコープ)を狭く区切る指示(「このファイルのみを対象にする」)
• 進捗報告の頻度と形式を指定する指示(「大きな区切りごとに1行で報告する」)
• 出力するファイルの長さを縛る指示(「500字以内でまとめる」)

ここで誤解のないように言っておきたいのは、検証そのものが不要になったわけではないということです。モデルが自律的にやっている作業を、こちらが二重に指示しなくてよくなった、というだけの話です。品質の話とコストの話を混同すると、判断を誤ります。

私たちがある化学メーカーのクライアントで需要予測システムのプロンプトを見直したときは、削除対象が全体の3割ほどありました。残りの7割は、業務固有の前提条件やデータの読み方を指定する指示で、これらはモデルが新しくなっても変わらず必要です。ここを一括で消してしまうと、今度は業務知識が欠けた出力になってしまいます。棚卸しは丁寧に、一文ずつ役割を確認しながら進める必要があります。

棚卸しの実務では、一文ごとに「これはモデルへの安全策か、業務のルールか」を自問しながら仕分けます。例えば「発注量は在庫の上限を超えないようにしてください」という一文は、業務のルールそのものなので残します。一方「計算結果を見直してから出力してください」という一文は、モデルへの安全策であり、Opus 5では重複になります。見分け方に迷ったら、その指示を削って一度動かしてみて、結果が変わるかどうかを確認するのが私たちのやり方です。

「簡潔に」は effort では代替できない

このセクションで伝えたいのは、パラメータ調整と言葉の指示は別物だという点です。

Claude Code には effort という応答の労力を調整するパラメータがあります。私たちも最初は「effort を下げれば応答は自然に短くなるはず」と考えていました。ところが実際は違いました。effort を下げても、応答の長さそのものはほとんど変わりません。

簡潔さを求めるなら、プロンプトの中に言葉として書く必要があります。「結論を先に、3行以内で」といった具体的な指定です。effort は思考の深さを調整するパラメータであり、出力の長さを制御するパラメータではありません。この2つを混同すると、「モデルの設定を変えたのに応答が長い」という的外れな不満につながります。

私たちの経験では、2つのやり方を比べてみました。effort を high のまま簡潔さの指示だけを足すやり方と、effort を下げて指示は変えないやり方です。前者のほうが応答は短く、内容の抜け漏れも少なくなりました。コストを抑えたいからといって闇雲に effort を下げるのは、実は的外れな対処になりかねません。

進捗ナレーションとサブエージェント委任も見直しが必要

Opus 5 は作業中の実況、つまり「いま何をしているか」の言語化が増える傾向があります。これは透明性としては良い面もありますが、頻度や粒度を指定しないと冗長になります。私たちの現場では「大きな区切りごとに1行で報告する」という指定を加えることで、実況の量を抑えています。

サブエージェントへの委任についても同様です。並列化できてコストが見合う場合にだけ使うよう指定しないと、単純なタスクにまでサブエージェントを乱発する場面が出てきます。私たちが週次でモニタリングしているあるクライアントのログでは、移行直後にサブエージェントの起動回数が跳ね上がった時期がありました。1件のFAQ回答に3つのサブエージェントを立てるような、明らかに過剰な使い方です。プロンプトに「サブエージェントは並列化できる場合のみ使う」と一文を足したところ、起動回数は元の水準まで落ち着きました。

これらは単体では小さな調整ですが、積み重なると1回のタスクあたりのトークン消費に大きく影響します。プロンプト資産が多いクライアントほど、見直しの効果が大きく出ます。

複数クライアントのプロンプト資産をOpus5に移行して分かったこと

私たちがFDEとして関わっている案件では、クライアントごとに専用のプロンプト集を運用しています。議事録AI、需要予測、検図AIなど、用途は案件ごとに違いますが、どの案件でも「検証して」に類する一文が8割ほどの案件で入っていました。旧モデルの時代に、AIを信用しきれずに書き足した一文だったからです。

移行では、まず1つのクライアント分のプロンプト集を1日で書き直し、動作を確認してから他のクライアントへ横展開する、という順番を取りました。全案件を一度に書き換えるのはリスクが高く、どこで問題が起きたかが分からなくなるためです。ここは意見が分かれるところですが、私たちは小さく検証してから広げるやり方を選んでいます。

書き直した結果、応答時間が短縮された案件がいくつもありました。ある製薬・健康食品メーカーの需要予測システムでは、発注判断のプロンプトから検証系の一文を削り、簡潔さの指示を足したところ、1回あたりの応答時間が目に見えて短くなりました。この案件の担当者は「発注データが来たらボタンを押すだけにしたい。考えたり悩んだりするのは管理者側」と、現場に判断させない設計を求めていました。応答が速くなったことは、この設計思想とも噛み合っています。

ただし全ての案件で効果が同じだったわけではありません。もともと指示が簡潔だった案件では、変化はほとんどありませんでした。プロンプトが長く複雑な案件ほど、引き算の効果が大きく出る——これが私たちの実感です。

「検証を削る」は「品質を捨てる」ではない

このセクションで言いたいことは、検証の役割を別の層に移すという発想です。

検証指示をプロンプトから削ると、「品質担保が弱くなるのでは」と心配する声を聞きます。私たちの立場は違います。プロンプト内の検証指示は、もともとモデル1つに全部を背負わせるやり方でした。これはAIエージェントの数が増えるほど無理が出ます。

私たちの現場では、検証を複数の層に分けています。ある案件では、1つのモデルが出した回答を、別のモデルに採点させる構成を取っています。正直に言うと、モデルによってはハルシネーション(事実に基づかない出力)の出やすさに差があり、単体では気づかない誤りを別の視点で拾えるからです。さらに本番反映は二段階で行い、まずステージング環境で回帰テストを通してから本番に出します。トレーニング環境は背景色を変えるなどして見た目で区別できるようにしており、間違えて本番を直接触ることを防いでいます。

非エンジニアの担当者がプロンプトやコードに触れる案件では、もう一段別のガードレールを設けています。データベースを直接編集させず、変更はすべてPR(変更提案)として上げてもらう形です。PRを上げると、AIがまず中身を確認してレビューし、問題があれば指摘します。人が最終判断をする前に、もう一段AIの目を通す構成です。

プロンプトの一文を削ったからといって、この4層構造がなくなるわけではありません。むしろ、モデル任せの検証を1つ減らした分、私たちが設計する検証層に責任が集まる、という感覚のほうが近いです。

もう一つ意識しているのは、検証の対象を分けることです。「一次情報」つまり蓄積してきたナレッジで先に答えを出し、それだけでは足りない場合に外部のWeb情報を追加で確認する、という順番にしています。根拠の出所を混ぜてしまうと、後から「この回答はどこから来たのか」を追えなくなるからです。プロンプトを簡潔にすればするほど、この根拠の分離は雑になりやすいので、意識して残すようにしています。

製造業の現場でAIエージェントに指示を出す人たちへ

AI-Pathの顧客は製造業が中心です。多くは、コードを書いた経験のない現場担当者がAIエージェントに指示を出しています。ある大手建材メーカーグループでは、検図AI(図面チェックの自動化)を全社導入ではなく2工場でのパイロットとして先行させました。図面記載ミスのチェックという狭い範囲に絞ったからこそ、現場の担当者でもプロンプトの調整に手を出せる規模に収まっています。

私たちが内製化を支援するときは、まずデータベースを直接いじらない範囲に限定し、変更はすべてPRを上げてもらう形にしています。この仕組みがあるので、非エンジニアの担当者でも安全にプロンプトを書き換えられます。

Opus 5への移行も、この枠組みの中で進めるのが現実的です。プロンプトを書き換えたら、まず1つの業務で動作を確かめる。問題がなければ、他の業務にも同じ書き方を広げる。私たちの経験では、この順番を守った現場ほど、移行後のトラブルが少なくなっています。逆に、複数の業務のプロンプトを一度に書き換えた現場では、どの変更がどの不具合につながったのかを追うのに時間がかかりました。

現場の担当者からは「検証の一文を削っていいと言われても、何かあったときに自分の責任になるのが怖い」という声も出ます。この不安は理解できます。私たちが答えているのは、削っていいのはプロンプトの中の一文であって、レビューの仕組みそのものではないということです。PRベースのレビューやステージングでの確認は残したまま、モデルへの指示だけを整理する——この線引きを最初に共有しておくと、現場の納得感が違います。指示を減らすことと、責任の所在を曖昧にすることは、まったく別の話です。

私たちの見解

複数クライアントのプロンプト資産を移行してみて分かったのは、モデルの世代交代がプロンプトの「引き算」を迫るタイミングでもあるということです。旧モデル向けに積み重ねてきた注意書きや保険の一文は、新しいモデルの標準動作と重なり、コストだけを増やす荷物になりがちです。

AIは壁打ち相手であり、判断は人間がするというのが私たちの基本姿勢です。これは検証の話にもそのまま当てはまります。モデルが自律的に検証する時代になっても、「何を検証すべきか」「どこまでを本番に出していいか」を決めるのは人間の役割のままです。プロンプトから一文を削る作業は簡単ですが、その裏にある検証の設計思想までは自動化されません。ここを私たちFDEが引き続き担っています。

もう一つ付け加えるなら、こうしたモデル移行のたびにプロンプト資産を見直す作業自体が、社内にAI活用のノウハウを蓄積する機会にもなっています。「なぜこの一文を書いたのか」を一つずつ振り返る作業は、地味ですが資産として残ります。

私たちの社内勉強会でも、Opus 5への移行はちょうど良い教材になりました。AIの特性を踏まえてどう指示を組み立てるかという考え方は、個別のツールの使い方より長持ちします。ツールの使い方は動画を見れば数分で覚えられますが、「なぜこの一文が要らなくなったのか」を理解しておくと、次のモデル移行でも同じ思考の型を使い回せます。プロンプトはハーネス(仕組み)の一部であり、書いて終わりのものではない、というのが私たちの結論です。

よくある質問

Q. 既存のプロンプトを全部書き換える必要がありますか。 A. 優先順位をつけることをお勧めします。私たちの経験では、実行頻度が高いプロンプトから見直すと、効果を早く実感できます。

Q. effort を上げれば検証の質は上がりますか。 A. effort は思考の深さに関わるパラメータで、検証の網羅性を直接保証するものではありません。検証の設計は別途、仕組みとして持つ必要があります。

Q. thinking(思考機能)は無効にしたほうがいいですか。 A. 私たちは無効化を勧めていません。コストを抑えたい場合は effort の調整で対応し、thinkingは有効のままにするほうが、安定した結果につながっています。

Q. 旧モデルと新モデルのプロンプトを併存させても大丈夫ですか。 A. 一時的には可能ですが、長期の併存は管理コストが上がります。案件ごとに移行スケジュールを決め、順に統一していくことをお勧めします。

Q. 社内に専門のエンジニアがいない場合、この見直しは自分たちでできますか。 A. 「検証して」に類する一文を洗い出すだけなら、専門知識は不要です。ただし、どの指示が業務固有の前提条件で、どの指示が単なる保険なのかを見分ける作業は、一度誰かと一緒に棚卸しをしておくと以降が楽になります。

Q. 他社のツール(ChatGPTやGeminiなど)にも同じ考え方は当てはまりますか。 A. モデルごとに検証や実況の癖は異なるため、削るべき指示の具体的な内容までは当てはまりません。ただし「モデルの世代が上がったら、旧世代向けの指示を疑ってみる」という姿勢そのものは、どのモデルでも共通して有効だと私たちは考えています。

まず試すなら

1. プロンプト集の中から「検証して」「ダブルチェック」に類する一文を洗い出す。 検索するだけなので数分で終わります。
2. 実行頻度が最も高いプロンプト1つを選び、1日で書き直して動作を確認する。 全件を一度に変える前に、小さく試すのが安全です。
3. 効果が確認できたら、他の業務へ順に横展開する。 横展開のたびに、その業務固有の事情がないかを確認してください。

自社のプロンプト資産がどれだけ「引き算」できるか、見えていない企業も多くいらっしゃいます。私たちは無償の業務プロセス診断(BPR)を実施しており、AIエージェントへの指示設計を含めた現状の棚卸しをお手伝いしています。まずは無償の業務診断で、どこにAIが効くかを明らかにしませんか。

VibeCoding そのものの考え方については、関連記事: VibeCodingとは何か もあわせてご覧ください。

参考リンク

• Claude Opus 5のプロンプティング（Anthropic公式ガイド）
• Claude Opus 5に効くプロンプト徹底解説｜「検証して」は削る（sinyblog）
• Claude Opus 5のプロンプトは、足すより引く（株式会社HF.M）