Claude Code eval入門｜build-evalとhillclimbで問い合わせ振り分けを58%→85%に

Claude Codeのbuild-evalとhillclimbとは？

build-evalは、AIを組み込んだ仕組みの採点テスト（eval）をClaudeとの対話で作るコマンドです。hillclimbは、そのテストの点が上がるようにプロンプトや設定を1回に1か所ずつ直し、効果を確かめていくコマンドです。どちらもClaude Codeに同梱のclaude-apiスキルの一部で、追加のインストールは要りません。

AnthropicのLance Martin氏が2026年9月28日に公開した解説記事「Automating eval design and hillclimbing with Claude」で紹介されました。翌日の公式アカウントの告知は、10月6日時点で表示200万回、ブックマーク1.7万件を集めています。ブックマークがいいね（9,300件）の約1.8倍あり、「後で読むために保存された」公式ノウハウとしてはその週で最も多い数でした。

公式記事は、始める前に claude update で最新版にするよう案内しています。当研究所の検証は、手順書をv2.1.291同梱版で読み、採点対象のアプリはv2.1.296で動かしました。hillclimbはv2.1.284（9月28日）の時点で、雑音より小さい言い換えにラウンドを使わないよう改良されています（Claude Code changelog）。

なぜ士業やバックオフィスのAI活用にevalが必要なのか？

evalは、AIに入力を与え、その出力を決めたルールで採点するテストです。evalがないと、プロンプトを直すたびに「良くなった気がする」で判断することになり、1件を直した変更が別の案件を壊しても気づけません。士業の一次対応のように「見落とすと期限を過ぎる」業務ほど、点数で確かめる仕組みが要ります。

Anthropicの技術ブログ「Demystifying evals for AI agents」は、evalを「AIに入力を与え、その出力に採点の論理を当てて成否を測るテスト」と定義しています。Code w/ Claude 2026でevalの作り方を実演したFelix Becker氏は、evalの役割を次のように説明しました。

「evalは、『うまく動いているように見える』と『うまく動くと分かっている』の間をつなぐ橋でもあります」

"evals is also the bridge between things like it seems to work or like we know it works"

Felix Becker（Anthropic・Member of Technical Staff）— Code w/ Claude 2026 SF「Evals for taste」2:25

同氏は、evalなしで改善を続ける危うさにも触れています。1つの問題を直すためのプロンプトの手直しが、考えてもいなかった別のタスクの性能を急に落とすことがある、という指摘です（5:30）。

公式記事は、良いevalの条件を4つ挙げています。

例の選び方には注意書きがあります。今のモデルが間違える例ばかりを集めると、そのモデルの弱点（能力の「谷」）だけを測ることになります。公式記事は、人が見て難しいと判断した例を選び、入れる前に「なぜ難しいのか」を説明できることを目安にしています。当研究所の見解では、ここは士業の専門性が最も効く部分です。期限の数え方や他士業との線引きを知っている人でなければ、難しい例も正解も作れません。

build-evalで何を決めるのか？例・採点・承認の3つ

build-evalが決めるのは、どの業務の何を測るか、どの例で測るか、どう採点するかの3点です。手順書は、例の一覧と採点方法の2つについて、人がはっきり承認するまで先に進まないよう指示しています。初めてお金のかかる実行をする前にも、件数・回数・所要時間を示して同意を取ります。

当研究所の検証の設計

題材は、架空の社労士事務所に顧問先から届く問い合わせメールの一次振り分けです。メールを読み、8つのカテゴリ（入退社・社会保険手続き、給与計算・勤怠、労災・事故など）と、緊急度（至急・通常）をJSONで返させます。受信日はすべて2026年10月13日（火）としました。

40件のうち至急は15件、通常は25件です。16件には「なぜ難しいか」を書き添えました。たとえば、件名に【至急】とあるのに来年4月の扶養の相談、本文に「急ぎではありません」とあるのに入社日から5日以内に出す資格取得届の期限が翌日に迫っている依頼、などです。

この基準は、モデルを1回も動かす前に文章にしました。当研究所の見解では、この判定基準そのものがevalづくりの最大の成果物です。新人に業務を引き継ぐときの資料にもそのまま使えます。

採点はコードで行い、カテゴリと緊急度の両方が正解なら1点としました。本番前の確認として、正解をそのまま流すと100%、空の出力は0%、全件に同じ答え（その他事務連絡・通常）を返すと7.5%になることを確かめています。手順書が求める「必ず通る答えと必ず落ちる答えを流して、採点の配線を確かめる」手順です。

アプリ本体は、APIキーを使わずにClaude Codeのヘッドレス実行（claude -p）で作りました。システムプロンプトだけを差し替え、ツールは使わせず、1通につき1回だけ答えさせます。

claude -p "（メール本文）"   --system-prompt "（振り分けの指示）"   --tools "" --model claude-sonnet-5-5 --effort low   --output-format json

同梱の採点スクリプトの雛形（runner-scaffold.mjs）をそのまま使い、アプリを呼ぶ部分と採点の部分だけを書き足しました。1回の全件採点（40件×3回＝120回の呼び出し）は、同時に6本ずつ動かして約1.5〜3分です。

社労士事務所の問い合わせ40件で回した結果は？

2ラウンドで、テスト用16件の完全一致率は58.3%から85.4%になり、全40件での至急の検出率は13%から91%になりました。改善の大半は1ラウンド目の1つの変更で、2ラウンド目は正答率を保ったまま費用を約12分の1にしました。

1ラウンド目：モデルは分かっていたのに、規則に従っていた

改善案を考えるサブエージェント（analyzer）は、練習用24件の会話記録だけを読み、至急の見落とし25回と空振り6回が、すべて同じ原因で起きていると報告しました。初版プロンプトの「『至急』『急ぎ』と書かれていたら至急」「迷ったら通常」という2行です。

記録を読むと、モデルは内容から至急だと分かっていました。フォークリフトの事故で救急搬送されたという連絡に、初版は次のように答えています。

{"category": "労災・事故", "urgency": "通常"}

補足: ルール上、「至急」等の文言がないため形式的には「通常」としていますが、
重大事故で初動（療養補償給付の手続き、労働基準監督署への労働者死傷病報告の
準備など）が必要なため、担当者による早めの対応をおすすめします。

analyzerの提案は、言葉ではなく内容で至急を判定する4つの基準（受信日から7日以内の期日、けがや死亡の新たな発生、行政機関からの調査や指導、正式な請求や申立て）に置き換え、要約の3行目に「期日まで何日か」を書かせる、というものでした。適用すると、同じメールへの答えはこう変わりました。

3. 業務中の事故が新たに発生したため、至急の基準2に該当。

{"category": "労災・事故", "urgency": "至急"}

Claude Codeに同梱の費用改善の手順書（cost-hillclimb.md）は、新しいモデルほど古い時代の指示に文字どおり従うため、古いプロンプトのままモデルを比べると順位を誤ることがある、と注意しています。今回の初版の2行は、まさにその種類の指示でした。公式記事の事例でも、最初のラウンドで行ったのは、儀式的な手順や矛盾する規則を取り除くプロンプトの見直し（とモデルの切り替え）でした。

モデルを上げるより、プロンプトを直すほうが効いた

evalの健全性を確かめるため、初版プロンプトのままモデルと思考の深さ（effort）だけを変えた採点もしています。良いevalの条件どおり、強いモデルほど点は上がり、最も強い設定でも100%には届きませんでした。

最上位のOpus 5.5を思考を深くして使っても73.3%で、直したプロンプトのSonnet 5.5（91.7%）に届きません。費用は直したプロンプトのほうが4分の1以下です。公式記事の顧客サポートの事例も、Opus 4.8（effort high）で練習用30件の正答率74.4%・1件4.6セントだったところを、プロンプトの見直しとモデルの変更で、保留した14件の正答率を78.6%から90.5%に上げ、費用を約5分の1にしています。

2ラウンド目：Haiku 5.5に替えても正答率は保たれた

1ラウンド目で練習用は94.4%になり、プロンプトで直せる余地が誤差の幅より小さくなりました。そこで目標を「正答率を保ったまま費用を下げる」に切り替え、同梱の手順書の順序（キャッシュの確認、プロンプトの見直し、モデルと思考の深さの比較）に沿って、プロンプトはそのままモデルだけをHaiku 5.5に替えました。

テスト用の完全一致は87.5%から85.4%で、同じ例どうしで比べた差は-2.1ポイント（95%の幅で-6.2〜0.0ポイント）と誤差の範囲に収まりました。1件あたりの費用は0.61円から0.05円です。Haiku 5.5そのものの特徴や10万トークンを超えたときの料金は、Claude Haiku 5.5の解説記事にまとめています。

かかった費用は、初版から2ラウンド目までの採点360回で約0.72ドル（約108円）、少数での試行とモデル比較を含めた全760回で約4.25ドル（約638円）でした。改善案を考えたanalyzerの実行は1回で、約3分20秒・約11万トークンでした。

hillclimbは過学習をどう防ぐのか？

hillclimbは、例を練習用とテスト用に分け、改善案を考える側には練習用の結果だけを見せることで過学習を防ぎます。1回に1つの変更だけを試し、練習用とテスト用の両方で点が上がったときだけ残します。練習用だけ上がってテスト用が横ばいなら、その変更は元に戻します。

過学習とは、評価に使う例にだけ合わせ込んでしまい、本番では良くならない状態です。公式記事は対策を3つ挙げています。

同梱の手順書はさらに具体的で、改善案は毎回新しいサブエージェントに考えさせ、渡すのは練習用の会話記録だけにするよう指示しています。手順を回すClaude自身も会話記録を読まず、点数だけを見て判断します。当研究所の検証でも、analyzerには練習用24件×3回分の記録だけを別のフォルダにコピーして渡しました。

運用してみて、手順書の2つの決まりが効くことも分かりました。1つ目は分け方の確認です。最初にカテゴリだけで分けたところ、初版の採点で練習用44.4%、テスト用70.8%と大きくずれました。手順書は「初回の採点で練習用とテスト用の平均が誤差の範囲で一致しなければ、分け直す」よう求めています。至急・通常の比率もそろえて分け直すと、52.8%と58.3%になりました。

2つ目は止めどきです。2ラウンド目のあと練習用に残った誤りは、年末調整を税理士に回す1件の3回分（約4ポイント）だけでした。誤差の幅（練習用で約±12ポイント）より小さい改善は、採点では本物かどうか見分けられません。手順書に従い、ここで内容の修正は打ち切りました。

最後まで直らなかった誤りから分かること

ループを終えてからテスト用の誤りを読むと、4種類に分かれました。どれも、プロンプトの言い回しを直すより先に、事務所の側で決めることがある誤りです。

36協定の例は、練習用に「期限がすでに過ぎた」例が1件もなかったため、analyzerの作った基準にも入りませんでした。テスト用に分けておいたからこそ見えた抜けです。反対に、モデルが自分の知識で補った場面もありました。「急ぎではありません」と書かれた入社手続きの依頼に、Haiku 5.5は「資格取得届には入社後5日以内の提出期限があるとみられる」と書いて至急と判定しています。ただし当研究所の見解では、毎回そうなる保証はないため、業務に効く期限は事務所の基準として書いておくのが安全です。

始める前に知っておきたい費用と注意点は？

分類のように出力が短い業務なら、evalの費用は小さく収まります。注意すべきなのは費用より、例と採点方法と予算を人が承認すること、実データの扱い、そして件数が少ないことによる誤差です。

AIの出力を確かめる仕組みを、評価用の例ではなく日々の作業の中に組み込む方法は、Claude Codeの検証ループの記事で紹介しています。Claude Codeそのものの始め方はClaude Code入門ガイドをご覧ください。

まとめ