「勘で直す」をやめる──Claude Codeに、評価づくりと自己改良を自動化する build-eval / hillclimb が加わった
Anthropicが9月28日、Claude Codeのclaude-apiスキルにbuild-evalとhillclimbを追加。評価づくりと自己改良を半自動化し、過学習を自分で疑う仕組みで「勘のチューニング」を数値に置き換える。
AIを使った機能の品質を上げるとき、多くの現場は「プロンプトをいじって、なんとなく良くなった気がする」で止まりがちです。Anthropic は2026年9月28日、この"勘で直す"を"点数で直す"へ変える仕組みを、Claude Code 向けの claude-api スキルに追加しました。追加されたのは /claude-api build-eval と /claude-api hillclimb の2つのコマンドで、評価(eval)づくりと、その評価に対する自己改良を、Claude Code 自身が半自動で回します。
まず「採点基準」を自分の手元に作る
build-eval は、あなたのコードベースの中にテストセットと採点方法を組み立てるコマンドです。いきなり作り始めるのではなく、利用者に聞き取りをしながら、決まった順番で材料を集めます。
- 本番の会話ログ(データ保持や機微情報の扱いを確認したうえで)
- バグ報告・サポートチケット
- 手書きのケース(5〜10件)
- 実例に紐づけた合成ケース
集めた材料は一覧(レビューページ)として提示され、Claude は利用者の承認を待ってから次に進みます。採点方法は、出力が決まった形なら完全一致やスキーマ検証などのプログラム判定、自由記述なら「確認可能な事実」で測る LLM-as-judge を使い分けます。さらに採点のブレや環境ノイズを点検し、初期スコアが約95%を超えるようなら「その評価は簡単すぎる」と警告します。
一手ずつ変えて、良くなった時だけ残す
hillclimb は、作った評価に対してアプリを改良していくコマンドです。やり方は丘登り(hill climbing)の名のとおり、1ラウンドにつき1か所だけ変えて、結果が良くなれば採用、悪くなれば元に戻す、を繰り返します。変更できる対象は利用者が指定でき、主に次のものを対象にできます。
- システムプロンプト、スキルや指示ファイル
- ツールの説明文
- 使うモデル、努力度(effort)、その他の API パラメータ
- ハーネス(アプリ側の制御)コード
「自分で自分を欺かない」ための仕掛け
このワークフローの肝は、過学習(テストケースだけに過剰に最適化すること)を自分で疑う点にあります。hillclimb は評価をランダムに「調整用(train)」と「確認用(test)」に分け、調整用のスコアが上がっても確認用が横ばいなら、「見せかけの改善では」と判断して変更を差し戻します。むろん単純にスコアが下がった変更も戻します。スコアが2〜3ラウンド伸び悩んだら、小刻みな修正を続けるのではなく、残った失敗を原因ごとに分析して手を変えます。「良くなったつもり」で前に進まないための歯止めが、手順に組み込まれているわけです。
デモが示した「安くて賢い」への付け替え
Anthropic が示したカスタマーサポートの例では、最適化の前後でモデル構成そのものが入れ替わりました。高価な上位モデルを高い努力度で回していた構成が、より軽いモデルを低い努力度で使う構成へと置き換わり、正答率はむしろ上がっています。
| 項目 | チューニング前 | チューニング後 |
|---|---|---|
| モデル／努力度 | Opus 4.8・高 | Sonnet 5・低 |
| 新規チケットの正答率 | 74.4% | 90.5% |
| 1件あたりコスト | 約4.6セント | 約1セント(約5分の1) |
Anthropic は claude-api スキル自体にもこの手法を適用し、評価の合格率を66%から約88%へ、24ラウンドで引き上げたと説明しています。「上位モデルを使えば賢い」という思い込みを、計測が覆した格好です。
開発の現場では何が変わるか
これまで、プロンプトやモデル選定のチューニングは属人的な「職人技」になりがちでした。build-eval と hillclimb は、その職人技を「評価を作る → 一手ずつ試す → 残す/戻すを記録する」という再現可能な手順に落とし込みます。結果として、精度を保ったままモデルを安い構成へ付け替える、といった判断を感覚ではなく数値で下せるようになります。利用には Claude Code v2.1.259 以降が必要とされており、まずは自分のリポジトリで少数の実ケースから評価を作り、hillclimb を短いラウンドで回してみるのが入口になります。
便利さの裏で、気をつけたいこと
一方で、自動化ゆえの注意点も指摘できます。第一に、build-eval は本番ログを材料に使うため、データ保持や機微情報の扱いを利用者自身が正しく判断する必要があります(手順に確認は組み込まれていますが、判断そのものは人の責任です)。第二に、最適化は「測っているもの」に向かって進むため、評価そのものが甘ければ見当違いの方向へ最適化が進みかねません。だからこそ Anthropic も、初期スコアが高すぎる評価に警告を出すなど、採点基準づくりを重視しています。数値で直せる手軽さと引き換えに、「何を正解とするか」を決める責任は、むしろ人間側に重くのしかかる、という見方もできそうです。
参照: Automating eval design and hillclimbing with Claude(claude.dev Blog) ／ Anthropic adds eval and hillclimb commands to Claude Code(metatalks.ai) ／ Anthropic Built a Better Way to Improve AI Agents(The Neuron) ／ Claude Code Helps Build App Evaluations: Version 2.1.259 or Later Required(vibecoding.tech)
