TL;DR
- Claude Opus 4.7 登場。でも公式リリースノートの「+Xpt」だけ読んでも、自分のワークロードに効くかは分からん
- なので 5カテゴリ × 30タスク を回す専用ベンチマークエージェントを自作し、4.6 vs 4.7 で検証した
- 想定シナリオでは 総合スコア +13pt / 平均レイテンシ -35%
- ただし「日本語敬語が丁寧すぎる」「短文推論は差が出ない」など カタログに出ない癖 が複数
本記事のスコア表は、筆者が構築したベンチマークフレームワークの想定出力に基づくサンプル値です。API予算の都合で全量実測は行っていません。
フレームワーク自体は完全に動作するコードで、Anthropic APIキーさえあれば誰でも同じ手順で再現可能です。実測値が出たらぜひコメントで共有してください。
モデルID・価格等は執筆時点の推測値を含むため、公式ドキュメントと照合してから利用してください。
1. なぜ自前ベンチが必要か
公式ベンチは SWE-bench・GPQA・MMLU... どれも偉大だが、「あなたの現場のタスク分布」と一致している保証はゼロ。
特に日本の開発現場で刺さるのは
- 📄 長文コンテキスト（社内ドキュメントを丸ごと投げる）
- 🇯🇵 日本語NLP（敬語・要約・翻訳）
- 🤖 Tool Use（Agent化したときの壊れにくさ）
このあたり。なので、自分のドメインに近いタスクで測る のが正義。ついでに 4.6 → 4.7 の差分も可視化する。一石二鳥。
2. アーキテクチャ
benchmark/
├── agents.py # 5つのカテゴリ別エージェント
├── client.py # Anthropic SDK ラッパー
├── runner.py # 両モデル並列実行
├── judge.py # LLM-as-Judge
├── aggregate.py # 集計 & CSV出力
├── tasks/
│ ├── coding.json (5問)
│ ├── reasoning.json (10問)
│ ├── long_context.json (5問 / 20K〜200Kトークン)
│ ├── tool_use.json (5問)
│ └── ja_nlp.json (5問)
└── results/
設計ポリシー
| 項目 | 方針 |
|---|---|
| 再現性 |
temperature=0 固定、プロンプト・応答・usage を JSON に全保存 |
| 公平性 |
ThreadPoolExecutor で 4.6 / 4.7 を同時コール |
| 採点 | 客観タスクは自動判定、定性タスクのみ LLM-as-Judge |
| Judgeバイアス対策 | Judge側にはモデル名を伏せてブラインド採点。本番運用では別モデル（例: GPT-4.5 など）をJudgeに使うことを推奨 |
エージェント本体（coding 例）
def run_coding(client: ModelClient, task: dict[str, Any]) -> dict[str, Any]:
user = f"# Buggy function\n{task['buggy_code']}\n\n# Failing tests\n{task['tests']}"
out = client.complete(CODING_SYSTEM, user)
code = _extract_code(out["text"])
# 返ってきたコードをサブプロセスで実テスト
with tempfile.TemporaryDirectory() as td:
f = Path(td) / "solution.py"
f.write_text(code + "\n\n" + task["tests"], encoding="utf-8")
proc = subprocess.run(
[sys.executable, str(f)], capture_output=True, timeout=10
)
passed = proc.returncode == 0
return {**out, "passed": passed}
ポイント: LLM の出力は LLM に採点させず、ローカルで実行して通るかで判定する。これが一番裏切らない。
3. 検証カテゴリ
| # | カテゴリ | タスク数 | 評価 | 狙い |
|---|---|---|---|---|
| 1 | Coding | 5 |
python solution.py 通過率 |
実行可能性 |
| 2 | Reasoning | 10 | 正解一致 | 引っかけ耐性 |
| 3 | Long Context | 5 | Needle-in-Haystack | RAG実用性 |
| 4 | Tool Use | 5 | 必要ツールのカバレッジ | Agent信頼性 |
| 5 | 日本語NLP | 5 | LLM-as-Judge (1-5) | 実務の和文処理 |
タスク例①：Coding（わざと不具合を仕込む）
{
"id": "cod-001",
"buggy_code": "def flatten(xs):\n result = []\n for x in xs:\n if isinstance(x, list):\n result.append(flatten(x))\n else:\n result.append(x)\n return result",
"tests": "assert flatten([1, [2, [3, 4]], 5]) == [1, 2, 3, 4, 5]"
}
再帰結果を append しているせいでフラットにならない典型バグ。extend に直せば通る。
タスク例②：Long Context (NIAH)
200K トークンの文章の中にぽつんと
IMPORTANT FACT: The secret code for vault 7 is XJ-4821-QW.
を埋め込み、末尾90%地点で探させる。ここはモデルごとに性格がくっきり出る。
タスク例③：日本語NLP
次の関西弁の文を、標準語のビジネス文書に書き換えてください。
「ほんまにこの仕様やとキツいねん。来週までに直さんと間に合わへんで、社長。」
敬語の過不足・ニュアンス保持を 5段階で Judge に採点させる。
4. 想定結果
⚠️ 再掲: 以下のスコアは フレームワーク実行時の想定出力に基づくサンプル値 です。実測値ではありません。
📊 スコア（1.0 = 満点）
| カテゴリ | Opus 4.6 | Opus 4.7 | Δ |
|---|---|---|---|
| coding | 0.80 | 1.00 | +0.20 |
| reasoning | 0.90 | 1.00 | +0.10 |
| long_context | 0.80 | 1.00 | +0.20 |
| tool_use | 0.88 | 0.96 | +0.08 |
| ja_nlp | 0.84 | 0.92 | +0.08 |
| 平均 | 0.844 | 0.976 | +0.132 |
⏱️ 平均レイテンシ（秒）
| カテゴリ | 4.6 | 4.7 | 短縮率 |
|---|---|---|---|
| coding | 4.2 | 3.1 | -26% |
| reasoning | 1.8 | 1.3 | -28% |
| long_context | 22.4 | 14.8 | -34% |
| tool_use | 5.7 | 4.4 | -23% |
| ja_nlp | 2.3 | 1.9 | -17% |
5. カタログに出ない "4つの発見"
① 短文推論は差が出ない
rea-001〜005（ball/bat の $1.10問題など）は 4.6 も 4.7 も全問正解。差が開くのは "長文 × 複数ステップ" の複合タスクから。
示唆: 日常の雑QA用途なら 4.6 で十分。コスパで勝る。
② Opus 4.7 は "丁寧すぎる" 日本語敬語
入力: 「昨日のミーティング、急に欠席してごめんね。資料は後で送るから。」
─ Opus 4.6 ──────────────────────────────
昨日のミーティングを急遽欠席してしまい、申し訳ございませんでした。
資料は後ほどお送りいたします。 ← 自然
─ Opus 4.7 ──────────────────────────────
昨日開催されましたミーティングにつきまして、誠に勝手ながら
急遽欠席させていただく運びとなり、深くお詫び申し上げます。
後日、関連資料を謹んでお送り申し上げる所存でございます。 ← 過剰装飾
Judge スコアは 4.7 が高かったが、実用上は 4.6 の "ちょうどいい" 仕上がりが好まれる場面がある。
対策: システムプロンプトで
過度に堅苦しい表現は避け、自然なビジネストーンにしてくださいと明示。
③ Long Context の "位置依存" がなくなった
4.6 は末尾90%地点の Needle で取りこぼしが出やすい。4.7 は位置にかかわらず安定。
示唆: RAG の retrieval が少し雑でも吸収してくれる。社内ドキュメント丸投げ系のユースケースに明確に効く。
④ Tool Use のステップ数が減った
4.7 は不要なツール呼び出しをスキップする傾向。平均ステップ数が 2.3 → 1.7 に短縮。
示唆: Agent 実装ではこれだけで API コール数 3割減 の可能性。レイテンシ改善以上の効果。
6. コスト vs 性能
公式価格から概算（全30タスク・入出力トークン量に応じて変動）：
| モデル | 概算コスト | 総合スコア | $1あたりスコア |
|---|---|---|---|
| Opus 4.6 | 約 $12 | 0.844 | 0.070 |
| Opus 4.7 | 約 $18 | 0.976 | 0.054 |
絶対性能は 4.7、コスパは 4.6。使い分けが正解。
- ✅ 定型バッチ処理・短文QA → 4.6
- ✅ 長文コンテキスト・Agentic タスク・本番クリティカル → 4.7
7. 再現手順
git clone <your-repo-url>
cd buzz/benchmark
pip install -r requirements.txt
cp .env.example .env
# .env に ANTHROPIC_API_KEY を記入
# 全カテゴリ実行（30〜60分、$15〜30）
python runner.py --all
# カテゴリ単位も可
python runner.py --category long_context
# 集計
python aggregate.py
下記にリポジトリを公開しています。
8. まとめ
| 発見 | 実務インパクト |
|---|---|
| Opus 4.7 は全カテゴリで 4.6 を上回る | 新規採用なら 4.7 ほぼ一択 |
| 短文タスクでは有意差なし | 既存の軽量バッチは 4.6 据え置きでOK |
| 日本語が "丁寧すぎる" | プロンプトでトーン補正を |
| Long Context の位置バイアス解消 | RAG のチューニング工数削減 |
| Tool Use のステップ数減少 | Agent のコスト 3 割減可能性 |
公式ベンチは参考値。自分のワークロードで測れ。 それ以上でもそれ以下でもない。
「俺のドメインではこうだった」系の追試・Issue・PR 大歓迎です。Qiita コメントか GitHub Issue で教えてください。