Claude Opus 5への移行前に確認すべきプロンプト・ハーネスの点検方法

提供資料では、Claude Opus 5を日常的なエンタープライズ業務・エージェント作業向けのモデルとして紹介し、新世代のClaudeでは既存のプロンプトとハーネスを再設計する必要があると主張している。しかし、資料で言及されている**Claude Opus 5、Fable 5、Sonnet 5のリリース日・価格・性能およびパートナーの発言は、この記事に記載された情報だけでは独立して検証されていない。**特に、FableがAnthropicの正式なモデル名であるかどうかも、まず公式モデル一覧で確認する必要がある。

したがって、この文書では該当するリリース情報を確定した事実として繰り返すのではなく、公式文書で確認すべき項目と、実際のモデル移行に適用できる検証手順を分けて整理する。

最初に確認すべきリリース情報

新しいモデルをAPI、Claudeアプリ、またはClaude Codeに適用する前に、次の項目をAnthropicの公式文書と利用中のサービスのモデル選択画面で照合する必要がある。

モデル名や価格が公式文書にない場合、API設定や予算計算に使用してはならない。クラウド事業者や再販サービスを利用する場合は、Anthropicの直接APIとはモデルID、価格、提供開始時期が異なることもある。

モデル移行で変更すべき判断基準

1. 最高性能よりタスク当たりの効率を測定する

すべてのリクエストを最も高価なモデルで処理する方式では、エージェントが複数のツールやsubagentを繰り返し呼び出す際、コストが急速に増える可能性がある。モデルは名前やグレードではなく、次の指標を併せて確認して選択する必要がある。

• 成功率: 人が修正しなくても要件を満たした割合
• 総コスト: 最初のリクエストだけでなく、再試行、ツール呼び出し、subagent呼び出しを含むコスト
• 完了時間: 待機時間と人によるレビュー・修正時間まで含めた時間
• 失敗コスト: セキュリティ上の欠陥、誤ったデプロイ、分析漏れなど、失敗によって生じる影響
• 一貫性: 同じ種類の作業を繰り返した際に結果が変動する度合い

タスク当たりのコストは、単純なトークン単価だけで判断してはならない。概念的には次のように計算できる。

タスク当たりの総コスト = メインモデルのコスト + subagentのコスト + ツールのコスト + 再試行のコスト + 人によるレビューのコスト

2. 公開ベンチマークと独自評価を分ける

公開ベンチマークはモデルの一般的な特性を比較する出発点ではあるが、特定のコードベース・文書形式・業務ルールにおける成功を保証するものではない。組織は実際のタスクを匿名化した独自の評価セットを作成する必要がある。

優れた評価セットには、次の事例を併せて含める。

• 正常に完了すべき代表的なタスク
• モデルが間違えやすい境界事例
• 要求が曖昧で、追加の質問が必要なタスク
• ツールの呼び出しや外部資料の確認が必要なタスク
• 実行を中止するか、人の承認を受ける必要がある高リスクなタスク
• 長時間の実行中に状態を保存し、復旧する必要があるタスク

モデルごとに同一の入力、ツール、時間制限、成功基準を適用して初めて比較できる。1つや2つの印象的な結果よりも、複数回繰り返した成功率とコスト分布を記録するほうが安全である。

3. モデルとハーネスを1つのシステムとして評価する

**ハーネス（harness）**とは、モデルを取り巻く実行環境を意味する。システムプロンプト、プロジェクト指示、検索、メモリ、ツール、Skill、subagent、権限管理、検証および再試行ロジックがすべて含まれる。

同じモデルでも、ハーネスによって結果が変わる可能性がある。たとえば、モデル自体がテストを作成して実行する一方で、ハーネスも同一の検証を強制すると、同じ作業が重複することがある。逆に、デプロイ承認やセキュリティ検査のように決定論的な制御が必要な段階までモデルの自律的判断に委ねると危険である。

重要な原則は、モデルが得意とする推論と、システムが必ず保証すべき制御を区別することである。

プロンプトとハーネスで点検すべき6項目

1. 重複した検証・再確認指示を実験的に削除する

完了後に必ず再確認せよのような文を無条件に削除することが正解とは限らない。まず、新しいモデルが自発的に行う検証とハーネスの検証段階が重複しているかを追跡する。

• モデルの自己レビューが繰り返されるだけで品質が向上しない場合は、プロンプトを短くする。
• テスト、スキーマ検証、静的解析など、自動化できる検査はハーネスに残す。
• 決済、デプロイ、データ削除などの高リスクなタスクの承認を、モデルの自己検証で代替しない。

2. subagentの呼び出し条件と上限を定める

subagentは並列調査や専門領域の分離に有用だが、小さなタスクまで委任するとコストと遅延時間が増大する。次のようなポリシーを明示できる。

• 独立して分割できるタスクにのみsubagentを使用する。
• 1つのリクエストで同時に実行できる数を制限する。
• 各subagentに明確な成果物と終了条件を与える。
• 同じ資料を複数のエージェントが重複して探索しないようにする。
• 予想コストや所要時間がしきい値を超える場合は、人の承認を得る。

3. 詳細な禁止規則を判断基準に変える

長い禁止事項の一覧は、互いに矛盾したり、新しい状況に対応できなかったりする可能性がある。スタイルのようにリスクが低い領域は、周辺のコンテキストを読み取って判断するよう委ねることができる。

• 規定型: 複数段落のdocstringを絶対に作成するな。
• 判断委任型: 既存コードのコメント密度、docstringの形式、命名と慣用表現に従え。

ただし、個人情報の処理、セキュリティ、法的義務のように違反コストが大きい規則は、明示的な制約とプログラムによる検査として維持する必要がある。

4. 応答の長さと出力形式を直接指定する

推論に使うリソースと、ユーザーに表示される回答の長さは同じ概念ではない。クライアントがeffortまたは類似の推論強度オプションを提供していても、短い回答が必要なら別途出力条件を記述する。

例は次のとおりである。

• 結論を先に書き、根拠は3項目以内にまとめよ。
• 最終回答は500文字以内で作成せよ。
• 説明なしで有効なJSONオブジェクトのみを返せ。
• 変更ファイル、主な理由、残っているリスクのみを報告せよ。

5. 推論強度は実際のタスクで再調整する

以前のモデルで使用していた推論強度やeffortのデフォルト値を、そのまま新しいモデルに適用しない。低い設定から始め、品質が不足する場合にのみ引き上げる方法でコスト曲線を測定する。

オプションの正確な名称と対応範囲はAPIのバージョンおよび製品によって異なる可能性があるため、公式文書を確認する必要がある。

6. コンテキストを役割別に分け、段階的に開示する

すべての指示をシステムプロンプトや1つのCLAUDE.mdに入れると、関係のない情報までリクエストごとに含まれる可能性がある。次のような階層構造が実用的である。

1. システム・製品指示: 役割、安全上の境界、出力契約など、常に必要な規則
2. 軽量なプロジェクト指示: ビルドコマンド、ディレクトリ構造、共通の作業方法
3. 必要なときに読み込むSkill: デプロイ、データベース変更、特定のフレームワークなど、条件付きの手順
4. 技術リファレンス: APIスキーマ、コード例、設計文書、テスト可能な仕様

これを段階的開示と呼ぶことができる。モデルに現在の段階で必要な資料を検索または読み込ませる一方、どの資料を使用したかを記録することで、再現性と監査可能性を確保する必要がある。

推奨される移行手順

ステップ1: 現在の状態を固定する

既存モデルのプロンプト、ツールのバージョン、成功率、トークン使用量、遅延時間、失敗事例を保存する。ベースラインがなければ、新しいモデルによって実際に改善されたかを判断するのは難しい。

ステップ2: モデル情報と権限を検証する

公式モデルID、価格、コンテキスト上限、ツール対応、データ保持ポリシーを確認する。テスト環境では、書き込み・削除・デプロイ権限を制限する。

ステップ3: 既存のハーネスをそのままテストする

最初からすべてを一度に変更しない。モデルだけを置き換えてベースラインと比較すれば、モデル変更による影響を切り分けられる。

ステップ4: 重複する指示を1つずつ削除する

検証指示、冗長なスタイル規則、不要な例、常に注入されるリファレンスを、種類ごとに1つずつ削除する。変更のたびに品質とコストを再測定する。

ステップ5: ルーティングポリシーを作成する

業務の難易度、リスク、予想コンテキスト、時間制限に応じてモデルを選択する。提供資料が提案したモデル別の役割は、正式名称と性能を確認した後に仮説としてテストすべきであり、そのまま運用ポリシーとして採用してはならない。

ステップ6: 限定的なトラフィックからデプロイする

一部のユーザーやリスクのないタスクに先に適用する。失敗率、再試行、subagent数、ツールエラー、人による修正時間を観察してから、適用範囲を拡大する。

運用チェックリスト

• 正式なモデル名とAPIモデルIDを確認した。
• 入力・出力・キャッシュ・バッチなど、実際に適用される料金を確認した。
• 実際の業務で構成された独自の評価セットがある。
• モデルとハーネスの検証段階が重複していない。
• subagentの呼び出し基準、同時実行数、予算上限がある。
• 応答の長さと出力スキーマを明示した。
• 推論強度ごとの品質・コスト・遅延時間を比較した。
• 高リスクなタスクには、決定論的な検査と人の承認が残されている。
• コンテキストが常時適用される指示、Skill、リファレンスに分離されている。
• ロールバック先となる既存モデルと設定が用意されている。

結論

新しいモデルへの移行で重要なのは、プロンプトを無条件に短くしたり、自律性を無条件に拡大したりすることではない。公式の製品情報を先に確認し、実際の業務評価を通じてモデルとハーネスの役割を再配分することが重要である。

提供資料にあるClaude Opus 5関連の数値と名称は、公式な根拠が確認されるまで暫定情報として扱う必要がある。ただし、重複検証の削除、subagentの制限、明確な出力契約、段階的なコンテキスト開示、独自評価に基づくルーティングは、モデルの世代に関係なく適用できる移行原則である。