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 で教えてください。