Anthropicは2026年9月28日、Claude Codeで利用できるclaude-apiスキルに、サブコマンド「build-eval」と「hillclimb」を追加したことを紹介した。build-evalは、AIアプリケーションの出力や、スキルに従って動くClaudeの処理結果を評価する仕組みを作成する。入力データと採点方法についてユーザーの承認を得ながら、初回の評価まで実行する。

hillclimbは、用意した評価を使って、プロンプトやモデル設定、スキルの指示内容などを調整する。ユーザーが目標と変更を許可する対象を指定すると、Claudeが変更を1つずつ試して評価を実行する。結果をもとに変更を残すか元に戻すかを判断し、次の変更を試していく。

• Automating eval design and hillclimbing with Claude - claude.dev Blog

なおclaude-apiは、Claude APIを使うアプリケーションの開発を支援するスキルで、Claude Codeに同梱されている。

build-eval⁠：評価の仕組みを作り⁠、初回の評価を実行する

Claude Codeの入力欄で/claude-api build-evalを実行すると、Claudeがユーザーに評価したい機能や用途を聞く。そのうえで、テスト用の入力データと、アプリケーションなどを実行して出力を採点するコードをプロジェクト内に作成する。スキル内では、既存の入力データや採点処理、実行スクリプトがあれば再利用し、足りないものだけを作成するよう指示している。

入力データと採点方法を確認する

入力データを用意する際は、評価対象のアプリケーションやエージェントが実際の運用で記録した会話履歴や実行ログを優先する。ログを取得する前に、保存期間や機密情報の扱いをユーザーに確認する。利用できるログがなければ、不具合報告や問い合わせ、ユーザーが作成した例、プロジェクトのコードをもとに生成する例の順に候補を検討する。データを生成する場合も、ユーザーが提供する少数の実例をもとに、内容を変えた例を作る。

用意した入力データはユーザーに提示し、実際の利用場面を反映しているか、重要なケースが抜けていないかを確認してもらう。

入力データの承認を得たあとに、評価対象の出力に合う採点方法を提案する。たとえば、分類を行うアプリケーションなら結果が正解と一致するか、JSONを出力するアプリケーションなら指定した構造に従っているかを、コードで検証する。

自由記述のように複数の正解があり得る出力では、AIモデルを採点役として使う方法を検討する。採点役には入力・出力・採点基準を渡して判定させる。採点用のモデルはユーザーが選ぶ。スキル内の指示では、出力を生成したモデルとは異なるモデルを使うよう勧めている。

Claudeは、提案した方法でいくつかの出力を採点し、ユーザーに結果を見せて、人の判断とのずれを確かめる。

初回の評価を実行し⁠、結果を保存する

採点方法についても承認を得たあとに、用意したすべての入力データで評価を実行する。この初回評価のスコアが、以後の変更の効果を確かめる基準になる。

入力データや採点処理、評価を実行するスクリプトは、プロジェクトの既存構成に合わせて配置する。初回評価の結果とテストケースごとの実行記録は、デフォルトではプロジェクト内の.claude/hillclimb/<flow>/baseline/に保存する（<flow>には、評価する機能や処理を識別する名前が入る⁠）⁠。

全体のスコアと個別の出力を確認できるHTMLレポートは、デフォルトでは.claude/hillclimb/<flow>/report.htmlに生成する[1]。

hillclimb⁠：プロンプトや設定などの変更を評価で確かめる

Claude Codeの入力欄で/claude-api hillclimbを実行すると、Claudeが評価結果をもとに、評価対象のアプリケーションで使うプロンプトやモデル設定、スキルの指示内容などを調整する。

build-evalで初回評価まで終えていれば、その評価と実行結果を使って調整を始められる。ほかの方法で用意した評価も利用でき、その場合は、評価を実行できることと、比較の基準となる結果を確認してから調整に進む。

目標と変更する対象⁠、進め方を決める

コマンドの実行後、Claudeは、性能向上や性能を保ちながらのコスト削減など、何を目標にするかをユーザーに確認する。ユーザーは、目標に加えて、Claudeに変更を許可する対象を指定する。対象には、システムプロンプト、スキルや指示ファイル、ツールの説明、使用するモデルやAPIパラメーター、モデルの呼び出しやツールの実行を制御するコードなどを選べる。

変更と評価を何回繰り返すかは固定されておらず、ユーザーが進め方を選ぶ。スキル内の指示では、改善が頭打ちになるまで続ける方法を推奨している。変更を1つ試すごと、または指定した回数の試行を終えるごとに経過を報告し、続行するか確認する方法も選べる。

評価結果のばらつきを確認し⁠、入力データを分ける

同じ条件で評価しても、実行のたびにスコアが変動することがある。Claudeは、最初の変更を試す前に、目標とする改善幅がこのばらつきに埋もれないかを確認する。変更による効果と偶然の変動を区別できない場合は、評価の繰り返し回数やテストケース数を増やすことを提案する。

調整を繰り返すと、評価に使ったデータに合わせ込みすぎて、実際の利用場面では性能が改善しない過剰適合が起こることがある。これを見つけるため、基本の進め方では入力データを、変更案の検討用（train）と、効果の検証用（test）に分ける。変更案を考えるClaudeには、testの入力データや個別の実行記録を見せない。

なお、スキルの詳細手順には、ケース数が少ない場合などにデータを分割せず、結果を改善傾向の確認に使う方法もある。また、約150件以上の大きな集合では、変更案の選択に使うvalidationを別に設け、testを最後の確認まで使わない方法も選べる。以下では、基本となる二分割の場合を説明する。

変更と評価を繰り返し⁠、結果を報告する

準備が整うと、次にユーザーへ確認するタイミングまで、Claudeが変更と評価を自動で繰り返す。1回の試行では、train側の実行記録を読んで変更を1つ提案する。その変更を適用してtrainとtestの両方で評価を実行し、変更前のスコアと比較する。

公式ブログによると、性能向上が目標の場合は、trainのスコアだけが上がってtestのスコアが変わらなければ過剰適合を疑って変更を戻す。性能が低下した場合も元に戻し、両方のスコアが上がれば変更を残す。コスト削減が目標の場合は、品質を維持できているかも判断の条件になる。

スコアが伸びなくなった場合は、失敗したテストケースの原因を分析し、テストケースの条件が曖昧でないか、採点処理に誤りがないかも調べる。

調整を終える際には、指定した目標に照らしてtestで最も良い結果が得られた状態を残す。その結果を調整開始前のtestの結果と比較し、改善幅を報告する。初回評価と同じ.claude/hillclimb/<flow>/report.htmlも更新し、各試行の結果を確認できるようにする。改善幅が評価結果のばらつきの範囲に収まる場合は、その旨を伝え、変更の取り込みを勧めないという。