Claude Opus 5の最適なプロンプト設計。自律的な振る舞いを前提に、任せる「範囲と境界」を定義するのがコツ

本記事は、生成AI・テクノロジー分野のニュースを取り上げ、中小企業の業務自動化の視点から考察する解説記事である。

Claude Opus 5の1Mトークン文脈で、最初に見直すべきものは何か

Claude Opus 5 has a 1M token context window as both the default and the maximum, and its instruction following, tool calling, and reasoning stay consistent throughout the window.

Claude Opus 5は、デフォルトと最大値のいずれにおいても100万トークンのコンテキストウィンドウを持ち、その全体を通じて指示追従、ツール呼び出し、推論の一貫性を保つ。

1Mトークンのコンテキストウィンドウ（モデルが一度に読み込める文章量の上限）は、単に「大量に入力できる」という話ではない。業務マニュアル、過去の顧客対応、仕様書、議事録、ソースコードを、分割して要約し直す工程を減らせる可能性を示す数字である。一般には、入力枠が広がるほどプロンプトを細かく書かなくてよくなると考えがちだが、本質は逆だ。入れられる情報が増えるほど、何を参照し、何を無視し、どの成果物に反映するかという境界設計の重みが増す。倉庫が広くなっても、棚の分類と取り出し方が曖昧なら、必要な商品を探す時間は減らない。

「高い推論設定」だけが正解ではない――low・mediumをどう見るか

low and medium effort produce strong quality at a fraction of the tokens and latency of higher settings, and they perform above the same settings on prior Opus models.

lowとmediumのeffortは、高い設定の何分の一かのトークン量と遅延で強い品質を生み、過去のOpusモデルの同じ設定を上回る。

ここでいうeffortとは、モデルがどれだけ推論に計算資源を使うかを決める設定である。重要なのは、effortを下げても表示される回答が自動的に短くなるわけではない点だ。推論量と、ユーザーに見せる文章量は別の制御対象である。

元記事は、Claude Opus 5では高いeffort設定を常に使う必要はないとしつつ、コーディングやエージェント型の仕事ではxhighが推奨される出発点だとも書いている。用途によって最適解が違うという、当然だが見落とされやすい整理である。分類、下書き、定型的な要約にlowやmediumを割り当て、設計判断や複数ファイルが絡む複雑な処理だけを高い設定に回すほうが、費用対効果は高くなる。

同日の発表によれば、Claude Opus 5の価格は入力100万トークンあたり5ドル、出力25ドルで前世代のOpus 4.8から据え置かれ、応答速度を約2.5倍に上げる高速モードは2倍の単価になる。

回答が長くなったとき、モデルの性能向上を歓迎できるか

Claude Opus 5’s default user-facing responses run longer than prior Opus models’.

Claude Opus 5のデフォルトのユーザー向け回答は、従来のOpusモデルより長くなる。

長い回答は、知識量の多さや丁寧さの証拠に見える。しかし問い合わせ対応、社内チャット、営業支援の現場などで即応性が求められるシーンでは、長さがそのまま価値になるとは限らない。元記事は、effortパラメータは「どれだけ考えるか」を制御するものであり「どれだけ話すか」を確実には短くしないため、回答の長さはプロンプトで明示的に指定する必要があると説明している。ここは実装担当者が誤解しやすい箇所である。

私は、AIの出力を「その場で読んで終わる即答」と「後から監査される保存文書」に分けて設計すべきだと考えている。前者に求められるのは即応性で、結論以外の経緯説明は判断を遅らせるだけだ。後者に求められるのは監査可能性で、根拠や前提が十分に残っているほうがよい。同じモデルでも、チャットの一言と保存する報告書では必要な長さが違う。

これはプロンプトに「簡潔に」と一言書けば終わる問題でもない。顧客向けには結論を先に置き、社内向けには判断理由を残し、ファイル出力ではページ数や章ごとの分量を指定する必要がある。モデルが賢くなったから指示が不要になるのではなく、出力の使われ方に合わせた指示が必要になる。それが元記事の含意である。

Claude Opus 5は指示なしで自己検証する――検証を足すほどコストになる理由

Claude Opus 5 verifies its own work without being told to.

Claude Opus 5は、指示されなくても自分の作業を検証する。

この発表で最も実務的な変化はここにある。従来のプロンプトには「最後に必ず確認する」「別のエージェントに検証させる」「回答を再チェックする」といった安全策が積み上げられてきた。Claude Opus 5では、それらが品質向上ではなく過剰検証につながる場合がある。同日のモデル発表でも、自己検証と反復的な問題解決の強化が特性として挙げられている。

品質保証を厚くすること自体は正しい。だが、すでにモデルが自動的に検証しているなら、同じ確認を重ねるほどトークン、API料金、処理時間だけが増える。人間の業務でも、担当者、主任、部長が同じ帳票を同じ観点で三回見れば、安心感は増えても処理能力は落ちる。

「AIの自己検証を信用するのは危険ではないか」という反論はもっともだ。ただし解決策は検証指示を増やすことではないし、検証を切り分けるために手順が増えて現場が煩雑になっては本末転倒である。手間を増やさずに済ませる方法は二つある。

一つは、検証回数を人が判断せず、仕組みで打ち切ることである。当社ではAPI経由の自動化において、検証ループの回数をユースケースごとに2〜3回で固定している。上限に達すれば機械的に止まるため判断の余地がなく、過剰検証は起きようがない。工程が増えるのではなく、既存の工程に上限値が一つ加わるだけだ。

もう一つは、検証を重ねるのではなく系統を変えることである。LOFIRの開発環境では、モデルが出した成果物とその自己検証の結果を、別ベンダーのコーディングエージェント（Codex）に監査させる工程を標準フローに組み込んでいる。同じモデルの自己検証では出てこなかった問題が、この経路では高い頻度で見つかる。Claude Opus 5を起点にしたフローはまだ試行回数が少ないものの、4.8以前のモデルと同じ傾向は続いている。同種の確認を積み増すより、視点の違う一回を挟むほうが効率がよい。

そのうえで、検証の目的を分ける。文章の誤字確認と請求金額の正しさは同じ検証ではない。前者はモデル自身の確認で足りるが、後者は会計システムの実データとの照合や人間の承認が要る。どの誤りをどの仕組みで検出するかを割り当てる。これが費用と品質を同時に管理する方法である。

サブエージェントは何人まで呼ぶべきか――自律性と費用の境界線

Claude Opus 5 delegates to subagents more readily than prior models.

Claude Opus 5は、従来のモデルより積極的にサブエージェントへ委譲する。

サブエージェントとは、親となるAIが別のAI処理を起動し、調査、執筆、検証などを分担させる仕組みである。複数の独立した作業を並行して進められる反面、処理回数とコストは増える。元記事は、独立性が高く規模の大きい作業では委譲が有効だが、小さなタスクでは時間と費用が増幅すると説明し、利用する場合は委譲条件を明示するか、起動できるエージェント数に決定論的な上限を設けるよう勧めている。

私は、サブエージェントを「作業者を増やす」ことに近いと見ている。増えるのは手数であって、判断の主体ではない。独立した市場調査を三方向から同時に進めるなら手数が効くが、100文字のメールを作るために三人を動かせば、指示と取りまとめの手間が成果を上回る。

そして、その取りまとめを行うのは親エージェントである。だからサブエージェント固有の論点は「誰が統合するか」ではなく、統合する材料の質にある。サブエージェントは親の文脈を全部は持たないまま作業を始め、途中経過は要約されて親に届く。思い違いや空振りは親の目に触れないまま結論だけが残るため、成果物を見ても経緯を再現しにくい。起動数に上限がなければ、その見えない作業が費用と時間を膨らませる。

したがって、委譲の判断は「できるか」ではなく、独立した作業か、要約されて届いても判断できる粒度か、上限を超えたら止まるかで考えるべきである。管理の実装も、そこから具体的に決まる。委譲する条件を親のプロンプトに明示し、起動数の上限をコード側で固定し、統合結果の正しさは親エージェントの出力として一元的に扱い、外部に出る成果物だけは人間が承認する。自律性を最大化する設計と、費用と責任を予測可能にする設計は、同時に実装しなければならない。

thinkingを無効にしたとき、画面に漏れるものをどう扱うか

With thinking disabled, the model occasionally writes a tool call into its user-facing text instead of emitting a structured tool_use block.

thinkingを無効にすると、モデルが構造化されたtool_useブロックを出力する代わりに、ツール呼び出しをユーザー向けテキストへ書き出すことがある。

ここでいうthinkingは、モデルの推論過程を扱う実行設定である。元記事によれば、これを無効にすると、ツール呼び出しが構造化された命令として実行されず、画面上の文章として漏れる場合がある。検索のようなツール依存の処理で起きやすく、その呼び出しは実際には実行されない。内部のXMLタグが表示される場合もあり、無効化したうえで「考えるな」「推論するな」と強く指示すると、かえってタグ漏れが増える点も重要である。

これは見た目の問題ではない。ツール呼び出しが実行されなければ、検索結果なしで回答が続き、漏れたテキストは履歴として後続のやり取りにも残る。顧客対応であれば、最新情報を取得したつもりの誤回答につながる。

コスト削減のためにthinkingを無効化する判断自体は理解できる。しかし、安価になった一回の推論が、誤送信、再処理、有人確認の増加を招けば、業務全体では高くつく。だから設定変更は感覚で決めるべきではない。同じ入力をthinking有効時と無効時にそれぞれ流し、構造化出力の成立率、ツールの実行率、再試行率、有人確認が発生した割合を並べて比較する。この四つを揃えて初めて、料金の差が本当に得なのかを言える。

「Claude Opus 5なら全部任せられる」は本当か――性能ではなく境界の問題である

Claude Opus 5 performs well out of the box on existing Claude Opus 4.8 prompts.

Claude Opus 5は、既存のClaude Opus 4.8向けプロンプトでも、そのまま高い性能を発揮する。

既存プロンプトとの互換性は、移行コストを抑えるうえで大きな利点である。元記事はClaude Opus 5の能力改善として、複雑なコーディング、コードレビュー、バグ発見、画像理解、表計算、スライド作成、マルチエージェント連携までを挙げている。性能が上がっていること自体は数字でも裏づけられている。同日の発表によれば、Claude Opus 5はコーディング評価のFrontier-Bench v0.1で前世代Opus 4.8のスコアを約2倍に伸ばしながらコストは下がり、推論課題のARC-AGI 3では次点のモデルの約3倍を記録し、コンピュータ操作の評価OSWorld 2.0では上位モデルを3分の1のコストで上回っている。専門領域でも、有機化学でOpus 4.8比10.2ポイント、財務モデリングの正答率で9ポイントの改善が示されている。

しかし、Claude Opus 5が「そのまま動く」ことと「そのまま運用してよい」ことは別である。Claude Opus 5は従来より自ら範囲を広げ、確認し、説明し、委譲する傾向がある。旧モデルで不足していた行動を補うために書いた指示が、新モデルでは過剰な行動を生む。

特にコードレビューでは、元記事は「重大度の高い問題だけ報告」「保守的に」と書くとClaude Opus 5が文字どおり従って報告を減らす可能性があるため、まずすべて報告させ、別の工程で絞り込むよう勧めている。AIに判断を一度で完結させず、発見と選別を分離する設計である。指示を弱めたつもりが、モデルの側では出力を絞る根拠として厳密に働く。

私はこの考え方をAI導入全般に適用すべきだと見ている。発見漏れを避ける工程と、経営判断に耐える形へ絞り込む工程は違う。最初から「重要なものだけ」と頼めば、何を捨てたかが見えなくなる。空欄や未確認事項を無理に埋めず、確度の低い情報を確定事項として扱わない運用が、結果的に意思決定を速くする。

Claude Opus 5に仕事を丸ごと渡すのではない。仕事の中で、探索、検証、選別、承認の境界を引き直すのである。性能が上がったぶんだけ、その線を引く精度が成果を決める。

まとめ：Claude Opus 5に任せる範囲をどう設計するか

Claude Opus 5の発表資料が示す核心は、モデルが賢くなったという一点ではない。自動検証、長い文脈処理、サブエージェント委譲、自己修正といった能力が、これまでプロンプトに書いてきた指示と重なり始めたことである。その結果、品質向上のために足していた指示が、過剰な確認、冗長な説明、不要な委譲を生む場合がある。反対に、回答の長さ、タスクの範囲、ツール利用、費用上限のような業務上の境界は、これまで以上に明示する必要がある。

最初に見直すべきは、最新モデルへの乗り換えそのものではない。既存のプロンプトに残っている「念のための確認」「常に再検証」「必要なら複数エージェント」といった指示が、現在のモデルにとって本当に必要かを実測で確かめることである。小さく始めるなら、同じ業務を旧設定と新設定で一定件数処理し、品質、処理時間、トークン量、有人修正の回数を記録するところからでよい。

では、任せた結果をどの境界で人間が確認すれば、成果とコストが釣り合うのか。当社の答えははっきりしている。契約や金額の確認など、信用に直結する部分は必ず人間が見る。発信するコンテンツの文章も、人間がチェックして赤入れする。一方で、誤字脱字の修正と出典リンクの照合はAIに任せている。

ファクトチェックも基本方針はAIに任せる。ただしAIが事実と異なる内容を出すことは稀にあり、人間が監査する対象は決して少なくない。過去には、国の統計データを根拠にした記事で、数値そのものではなく集計項目が食い違っていたことがあった。数値が合っていても、何を数えた数字なのかが違えば結論は変わる。この種の誤りは、AIの自己検証では拾いにくい。

境界線は「AIが得意かどうか」ではなく、「間違えたときに何を失うか」で引く。信用を失う領域は人間が持ち、やり直しが効く領域はAIに渡す。プロンプト設計とは、その線を文章に落とす作業である。