こんにちは！株式会社雲海設計の技術部です。
「ハーネス評価をClaude APIで組みたいが、SonnetとOpusのどちらを評価モデルに使うべきか判断がつかない」「LLM-as-a-Judgeを実装したらコストが想定の3倍になった」「評価モデルの採点が甘くて、本番リリース後に品質崩壊が起きた」——2025年後半からエージェント案件が急増し、2026年に入ってからハーネス エンジニアリング claudeに関する相談が、技術部にほぼ毎週のように届いています。本記事では、ハーネス エンジニアリング claude API実装の具体手順を、Sonnet/Opus精度比較と業務ユースケース別の使い分けという観点で、実装コード付きで整理します。
TL;DR
ハーネス評価をClaude APIで組むなら「評価モデル」と「被評価モデル」を必ず分離する。同一モデルの自己採点は精度が17〜23%甘くなる
評価モデルは難所はOpus 4.5、日常運用はSonnet 4.5の2階建てが2026年5月時点のコスパ最適解
Sonnetは分類・スコアリング・形式チェックで Opus と精度差5%以内。コストは約1/5なので大量評価に向く
Opusは論理破綻検出・ハルシネーション検出・複雑な業務ロジック判定で Sonnet を10〜15%上回る。本番リリース判定など重要局面に投入
評価プロンプトはJSON Schema出力 + Chain-of-Thought + 採点基準の明文化の3点セットで再現性が一気に上がる
なぜハーネス評価にClaude APIが選ばれるのか？
結論から言うと、Claudeは構造化出力の安定性と長文評価タスクでの一貫性が他LLMより一段高いからです。Anthropicが2025年末に公開したベンチマークでは、Claude 3.5 Sonnet以降のモデルがLLM-as-a-Judgeタスクにおいて、人間評価者との一致率で競合比+8〜12ポイント高い結果を出しています。
Gartnerが2026年初頭に発表したAI品質管理レポートでは、本番運用中の生成AIシステムの62%が「評価の自動化が追いつかず、品質劣化を半年以上見逃した経験がある」と回答しています。ハーネス評価の自動化は、もはや「あれば便利」ではなく「ないと事故る」フェーズに入りました。
ハーネスエンジニアリングの全体像については、Claude Codeでの評価ループ構築ガイドで詳しく解説していますが、本記事ではAPI直接利用の観点に絞ります。
Claude APIで評価ハーネスを組む3つの利点
JSON Schema強制出力: tool useまたはstructured outputで、採点結果のスキーマを完全固定できる
200Kトークンの評価窓: 長文出力や複数ターンの会話履歴をまとめて評価できる
Prompt Caching: 評価基準プロンプトをキャッシュし、コストを最大90%削減できる
Sonnet 4.5とOpus 4.5、評価モデルとして何が違うのか？
結論から言うと、Sonnetは「広く速く正確」、Opusは「深く重く緻密」という棲み分けです。雲海設計が2026年4月に社内で実施した評価精度ベンチマーク（社内エージェント案件12件、評価サンプル合計2,400件）の結果を共有します。
| 評価タスク | Sonnet 4.5 一致率 | Opus 4.5 一致率 | コスト比 | 推奨用途 |
|---|---|---|---|---|
| 形式チェック (JSON妥当性等) | 97.2% | 98.1% | 1 : 5.2 | Sonnet一択 |
| 分類・タグ付け | 91.4% | 93.8% | 1 : 5.2 | Sonnet |
| 要約品質スコアリング | 87.6% | 91.2% | 1 : 5.2 | Sonnet（大量時） |
| 論理破綻検出 | 74.3% | 88.1% | 1 : 5.2 | Opus |
| ハルシネーション検出 | 76.8% | 89.4% | 1 : 5.2 | Opus |
| 業務ロジック妥当性判定 | 71.2% | 86.7% | 1 : 5.2 | Opus |
※ 一致率は「人間評価者3名の多数決」に対する一致率。社内ベンチマークのため、案件特性により変動します。
使い分けの実務ルール
定量的・形式的な評価（スキーマ妥当性、文字数、必須項目チェック）はSonnet。Opusを使う理由がない
意味解釈が絡む評価（要約の網羅性、トーンの適切性）はSonnetで一次スクリーニング → 不合格をOpusで再評価の2段構え
業務リスクが高い判定（医療・法務・金融の妥当性判定、リリース可否判定）は最初からOpus
Claude APIで評価ハーネスを実装する最小コード
結論から言うと、評価ハーネスは「テストケース → 被評価モデル実行 → 評価モデル採点 → スコア集計」の4段で十分動くものです。以下、Python での最小実装例を示します。
import anthropic
import json
client = anthropic.Anthropic()
EVAL_SYSTEM_PROMPT = """あなたは厳格な評価者です。被評価AIの出力を以下の基準で採点してください。
採点基準:
- 正確性 (0-5): 事実誤認やハルシネーションがないか
- 網羅性 (0-5): 質問の要素を漏れなくカバーしているか
- 簡潔性 (0-5): 冗長な記述がないか
必ず以下のJSON形式で出力してください。"""
EVAL_TOOL = {
"name": "submit_score",
"description": "評価結果を提出",
"input_schema": {
"type": "object",
"properties": {
"accuracy": {"type": "integer", "minimum": 0, "maximum": 5},
"coverage": {"type": "integer", "minimum": 0, "maximum": 5},
"conciseness": {"type": "integer", "minimum": 0, "maximum": 5},
"reasoning": {"type": "string"},
"failure_modes": {"type": "array", "items": {"type": "string"}}
},
"required": ["accuracy", "coverage", "conciseness", "reasoning"]
}
}
def evaluate(question: str, answer: str, judge_model: str = "claude-sonnet-4-5"):
msg = client.messages.create(
model=judge_model,
max_tokens=2048,
system=EVAL_SYSTEM_PROMPT,
tools=[EVAL_TOOL],
tool_choice={"type": "tool", "name": "submit_score"},
messages=[{
"role": "user",
"content": f"【質問】{question}\n\n【AI回答】{answer}\n\n上記を採点してください。"
}]
)
return msg.content[0].input
# 2段階評価: Sonnetで一次 → 低スコアのみOpusで再評価
def tiered_evaluate(question: str, answer: str, threshold: int = 3):
result = evaluate(question, answer, "claude-sonnet-4-5")
min_score = min(result["accuracy"], result["coverage"])
if min_score < threshold:
result = evaluate(question, answer, "claude-opus-4-5")
result["escalated"] = True
return result
このコードのポイント
tool_choice で submit_score を強制: 自由記述ではなくスキーマ準拠の出力を保証
failure_modes を必ず取得: 単なるスコアではなく「なぜ落ちたか」を蓄積し、プロンプト改修に回せる
2段階評価でコスト最適化: Sonnetで足切り、Opusで精査。大量評価でも費用が爆発しない
業務ユースケース別の評価モデル選定マトリクス
結論から言うと、ユースケースのリスクと評価ボリュームの2軸で選定するのが現場で詰まらない判断軸です。
| ユースケース | 評価ボリューム | 業務リスク | 推奨構成 |
|---|---|---|---|
| 議事録AIの要約品質 | 高（日次1000件超） | 中 | Sonnet単独 + 週次サンプリングでOpus |
| カスタマーサポートBot | 高 | 中〜高 | Sonnet一次 → 低スコアOpusエスカレーション |
| 契約書レビューAI | 中 | 非常に高 | Opus単独 + 人間最終確認 |
| 社内ナレッジ検索RAG | 高 | 中 | Sonnetで網羅性チェック、Opusで根拠性チェック |
| コード生成エージェント | 中 | 高 | Opus（静的解析と組み合わせ） |
| マーケコピー生成 | 高 | 低 | Sonnet単独で十分 |
カスタマーサポートや契約書レビューなど業務リスクの高い領域では、ガードレール設計と組み合わせることで、評価ハーネスが事後検知だけでなく事前防御としても機能します。
評価精度を底上げする3つの実装テクニック
1. Prompt Cachingで評価基準を固定
評価プロンプト（システムプロンプト + 採点基準 + Few-shot例）は毎回同じです。cache_control を付与すると、入力トークンコストが最大90%削減されます。大量評価では必須テクニックです。
system=[
{
"type": "text",
"text": EVAL_SYSTEM_PROMPT + FEW_SHOT_EXAMPLES,
"cache_control": {"type": "ephemeral"}
}
]
2. Chain-of-Thoughtで採点根拠を強制
スコアだけ出させると採点が雑になります。reasoning フィールドを必須にして「先に理由を書かせてからスコアを出させる」と、精度が10〜15ポイント向上することが社内検証で確認できています。
3. Few-shotで採点基準を具体化
「正確性5点とは何か」を文章で説明しても評価モデルの解釈はブレます。「この回答は3点、なぜなら〜」というFew-shot例を3〜5件入れると、人間評価との一致率が一気に上がります。
Anthropicが2025年に公開したエンジニアリングブログでも、「評価モデルの精度はモデル選択よりもプロンプト設計の影響が大きい」と明言されており、Few-shot設計を投資対象にすべきです。
コスト試算と運用上の落とし穴
結論から言うと、Opus単独で全件評価すると、想定の3〜5倍のコストになるのが典型的な失敗です。2026年5月時点の概算で、日次1万件の評価を回す場合のコストを比較します。
| 構成 | 月額概算（USD） | 精度 | 推奨度 |
|---|---|---|---|
| Opus単独 | $8,000〜12,000 | 最高 | △ 業務リスク極高のみ |
| Sonnet単独 | $1,500〜2,500 | 高 | ○ 多くのケースで十分 |
| Sonnet + Opus 2段（閾値3点） | $2,500〜4,000 | 最高 | ◎ 業務利用の標準構成 |
| Sonnet + Prompt Caching | $400〜800 | 高 | ◎ 形式チェック中心なら最強 |
※ Anthropic API公式価格に基づく試算。入出力トークン量により変動します。
コスト統制を本格的に組むなら、Bedrock経由の運用でCost Allocation TagとBudgetsを組み合わせるのが、エンタープライズの定石です。
雲海設計の支援サービス
雲海設計では、Claude APIを用いた評価ハーネスの設計・実装・運用支援を行っています。「LLM-as-a-Judgeを組みたいが社内に評価設計の知見がない」「Sonnet/Opusの使い分けで社内合意が取れない」「PoCから本番運用へスケールさせる段で詰まっている」といった段階での伴走支援が中心です。
DX ソリューション: 生成AI評価基盤の設計・構築
IT コンサルティング: 評価指標設計・モデル選定・コスト統制
お問い合わせ: 個別案件のご相談
よくある質問
Q. SonnetとOpusどちらを評価モデルに使うべきですか？
A. 業務リスクと評価ボリュームで判断します。日次1000件超で業務リスクが中程度ならSonnet単独、業務リスクが高い領域なら「Sonnet一次 → 閾値以下をOpusで再評価」の2段構えが標準です。Opus単独はコストが膨らみやすく、業務リスク極高の領域に限定するのが現実解です。
Q. 評価モデルと被評価モデルを同じClaudeにしても問題ないですか？
A. 推奨しません。社内ベンチマークでも、同一モデルの自己採点は人間評価との一致率が17〜23ポイント低下しました。最低でも「被評価=Sonnet、評価=Opus」のように異なるモデルを使うか、評価プロンプトで「あなたは批評者役である」と明示的に役割分離するのが鉄則です。
Q. Claude API直接利用とBedrock経由、どちらでハーネスを組むべきですか？
A. 規制業種・大企業はBedrock経由、スタートアップやPoC段階はAPI直接が現実的です。Bedrockはデータ主権とIAM統制で稟議が通りやすく、API直接は最新モデルが先行リリースされるため検証スピードで有利です。
Q. 評価結果をどう改善ループに繋げればよいですか？
A. failure_modesを必ず蓄積し、週次で頻出パターンを集計します。同じ失敗が3回以上出たら、プロンプト改修・Few-shot追加・ガードレール強化のいずれかで対処します。手動採点では追いつかないので、ダッシュボード化が必須です。
Q. PoCから本番運用への移行で気をつけるべき点は？
A. 評価データセットの代表性とコスト試算の精度の2点です。PoCでは50〜100件の手作りデータで動きますが、本番では業務分布を反映した1000件以上の評価セットが必要です。また、Prompt Cachingを組み込まないと本番コストが想定の数倍になる事故が起きやすいので、初期設計から織り込んでください。