Anthropic Simon検索者が出会うsmevals、AI評価へのより小さな賭け

Simon Willisonは長年にわたるeval実験を経てsmevalsを公開し、AIエージェントのテストに関するAnthropicのより正式なガイダンスとの新たな対照を生み出した。anthropic simonというつながりが重要なのは、両者がいま同じ問題を強調しているためだ。チームがプロンプト、ツール、システム指示、そしてモデルを取り巻くハーネスも検証しなければ、モデルスコアだけではほとんど意味をなさない。

Willisonは、Jesse Vincentの応用AI研究ラボPrime Radiantとともにsmevalsを開発した。このプロジェクトは、小規模な評価スイートを複数の構成で実行し、出力を採点して、より詳しい検証のためのレポートを生成する。

この公開は、AI評価に関する一般的な前提に異議を唱える。チームが有用な問いを立てるために、必ずしも大規模なベンチマークプラットフォームは必要ではない。必要なのは、焦点を絞ったタスク、再現可能な構成、明示的なチェック、そして失敗を理解できるだけの可視性だ。

このため、主な競争軸はAnthropic対ほかのモデルプロバイダーという構図よりも小さく、実践的なものになる。焦点となるのは、軽量なローカル評価と、重量級で汎用的な評価インフラの対比だ。前者は速度と検査可能性を重視し、後者はより広範な実験と複雑な環境を支える。

smevalsが小規模AI評価にもたらした変化

smevalsは、特定のプロダクト上の問いを、タスク、構成、採点ルールから成る持ち運び可能なディレクトリへと変換する。

Willisonは2026年7月31日にsmevalsを発表した。彼のsmevals overviewでは、異なるモデル構成で小規模なevalスイートを実行し、得られた出力を採点するツールとして説明している。

基本的なワークフローはuvx smevals docsから始まる。このコマンドはコーディングエージェントにプロジェクトのドキュメントを渡し、評価スイートを構築する前に形式を学習できるようにする。

このアプローチでは、ドキュメントを運用上のコンテキストとして扱う。すべての構成フィールドをユーザーに覚えさせるのではなく、コーディングエージェントが指示を読み、ファイル作成を支援することを前提としている。

評価はYAMLファイルを含むディレクトリ内に置かれる。YAMLは、構成によく使われる人間が読みやすいデータ形式だ。これらのファイルは、問い、タスク、モデル構成、採点の挙動を記述する。

ユーザーは同じスイートを複数のモデルに対して実行できる。Willisonの例では、繰り返し指定する-m引数を通じて、名前付きのGPT構成とClaude構成を比較している。

このコマンド構造は重要だ。モデル選択をプロダクト全体ではなく、より大きな実験における一つの変数として位置付けるためである。

smevalsは実行と採点も分離する。runコマンドは、構成がタスクを試行した際に何が起きたかを記録する。gradeコマンドは後から、記録された結果に定義済みのチェックを適用する。

この分離は、有用な監査境界を生む。チームは生の挙動を保存し、採点ロジックを見直し、異なるルーブリックが解釈をどう変えるかを調べられる。

このツールには2つのレポート経路がある。serveコマンドはローカルWebインターフェースを起動し、buildは別の場所でホストできる静的HTMLを生成する。

Willisonは俳句評価でこのワークフローを実演した。レポートでは、モデルが空でない行をちょうど3行生成したかを確認し、その採点結果で構成を順位付けした。

俳句ベンチマークは意図的に控えめだ。それでも、重要な評価原則を示している。狭く定義された要件は、広範な選好スコアでは説明できない違いを明らかにすることが多い。

この公開は一貫した語彙も導入している。evalはタスクを含み、構成は検証対象となるモデルやその他の変数を定義する。

runは、1つの構成が1つのタスクを試行した記録を残す。graderは、決定論的なチェックやカスタムチェッカースクリプトを含む検査を適用してgradeを生成する。

これらのカスタムチェックは文字列を検査し、XMLなどの形式を検証し、あるいは別のモデルを判定に使える。この幅により、1つのスイートで客観的な制約と、より主観的な品質評価を組み合わせられる。

このワークフローのどこにも、smevalsがAnthropicのプロダクトであることを示すものはない。anthropic simonとの関連は、エージェント評価とClaude構成への関心が重なっていることによるもので、企業所有を意味するものではない。

したがって、直近の変化はアクセスしやすさにある。開発者は、広範な評価サービスを先に採用したり、独自ダッシュボードを構築したりせずに、小規模な評価上の問いをパッケージ化できるようになった。

Anthropic Simonへの関心がいまハーネスに集まる理由

モデルを囲むエージェントハーネスが結果を変え得るため、モデルはもはや比較における唯一の有意味な単位ではない。

Anthropicは、エージェントハーネスを、入力を処理し、ツール呼び出しを調整し、結果を返すシステムと定義している。同社のagent eval guidanceでは、その層を、実験を実行して採点する評価ハーネスと区別している。

この区別は、smevalsがモデル名以外の構成もサポートする理由を説明するのに役立つ。構成には、異なるシステムプロンプト、モデルパラメータ、エージェントハーネスも含められる。

2つのコーディングプロダクトが同じ基盤モデルを使っていると仮定しよう。一方はモデルにより良いリポジトリコンテキストを与え、もう一方はより強力なツールと明確な完了チェックを提供する。

モデルだけを対象にしたベンチマークなら、これらのシステムを同等に扱うだろう。構成レベルの評価なら、実際の挙動が異なることを示せる。

この圧力は、いまも公開リーダーボードだけでモデルを選定しているAIプロダクトチームにかかる。こうしたランキングは候補を絞り込む助けにはなるが、プロダクト固有のプロンプト、ツール、権限、データを再現することはほとんどない。

エージェントの挙動は複数のステップにわたって展開する。システムはツールを呼び出し、状態を変更し、結果を解釈し、継続すべきかを決めることがある。

初期段階の1つの誤りが、その後のすべての行動に影響する可能性がある。このため、エージェント評価は、チャットボットが1つの質問に正しく答えたかを確認する作業とは異なる。

Anthropicのガイダンスでは、チームはエージェントを評価する際、モデルとエージェントハーネスを一体として評価するとしている。この見方は、smevalsが用いる構成モデルと密接に一致する。

この重なりこそが、anthropic simonにまつわる本当の話だ。両アプローチは、孤立したモデル知能から、ユーザーが体験する完全なシステムへと注目を移している。

このタイミングは、拡大する運用上の問題も反映している。モデル、プロンプト、ハーネスは独立して変化するが、プロダクトチームは依然として、何がリグレッションを引き起こしたのかを特定する必要がある。

新しいモデルは推論を改善する一方で、出力スタイルを変えるかもしれない。改訂されたシステムプロンプトは冗長さを減らす一方、指示追従を弱める可能性がある。ハーネスの更新はより優れたツールを公開する一方で、状態エラーを持ち込むことがある。

制御された構成がなければ、これらの変更は絡み合う。チームはプロダクトの感触が変わったことは分かっても、その差を確信をもって原因に帰属できない。

Anthropicはこの状態を、十分な可視性なしに運用している状態として説明している。チームはユーザーからの苦情を待ち、失敗を手作業で再現し、1つの問題を修正し、別のリグレッションを生むリスクを負う。

smevalsは同じ問題に対する、より小さな対応を提供する。すべての本番条件を再現しようとするものではない。実験を拡大する前に、チームが問いを切り分けるための構造化された方法を与える。

これは知識集約型の業務で重要になる。たとえばエンジニアリングチームは、アシスタントがコードを生成する前に、正しい社内仕様を見つけられるかを検証するかもしれない。

テストでは、2つの検索プロンプト、2つのモデルバージョン、または2つのツールポリシーを比較できる。searchable knowledge baseを維持するチームも、ドキュメントへのアクセスが変わるたびに同様の問いに直面する。

その比較結果は、どのモデルが最良かを問うより有用だ。明示された条件下で、どの完全な構成が定義済みのタスクを実行するかを問うからである。

仕組みはより賢いスコアではなく分離にある

smevalsは、タスク、実行、採点、レポートを、それぞれ独立して検査できる程度に分離することで明確さを得ている。

多くの評価プロダクトは、比較を容易にする単一スコアを約束する。この便利さは、スコアを生んだ判断を隠してしまうことがある。

smevalsは、より分解された経路を取る。evalはより大きな問いを示し、各タスクは具体的な課題を提示する。

次に構成が、それらのタスクを試みるシステムを記述する。runが試行を捉え、graderが保存された結果を1つ以上のチェックで評価する。

このアーキテクチャは、通常のテストの多くのロジックに従うため、一般的なテストに聞こえる。入力、条件、出力、アサーション、レポートはいずれも馴染みのある概念として残る。

言語モデルの挙動は、各構成要素を複雑にする。同じプロンプトでも異なる回答を生むことがあり、複数の異なる回答がいずれもユーザーの要件を満たす場合もある。

したがって有用なチェックは、要件に合致する必要がある。完全一致の文字列照合は固定トークンに適するが、複数の言い回しが有効な場合にはうまく機能しない。

構造的なチェックも選択肢となる。チームはJSON、XML、行数、必須セクション、またはエージェント環境内で作成されたファイルを検証できる。

モデルベースのgraderは、より決定論的でない品質を扱う。別のモデルが、回答がルーブリックに従うか、必要な推論を含むか、スタイル要件を満たすかを評価できる。

ただしAI判定者は、主観的な問いを客観的な真実へ変えるわけではない。評価に別のモデル、プロンプト、仮定のセットを持ち込むことになる。

採点と実行を分離することで、この制約を調査しやすくなる。チームは同じrunを保存し、各タスクに再び費用をかけずに複数の採点方法を比較できる。

不一致も検査できる。形式チェッカーは合格としながらAI判定者が不合格とするなら、レポートはそれらをすぐに平均化するのではなく、異なる2つの次元として明らかにする。

レポート層も同じ理由で重要だ。集計スコアは読者が結果をすばやく確認する助けになるが、個別のrunは、ある構成が成功または失敗した理由を明らかにする。

Willisonの俳句の例はこのバランスを示している。リーダーボードが要約を提供する一方、最近のrun、タスクの詳細、タグ、grader情報が根拠となる証拠を示す。

静的HTMLには、別の実用的な利点もある。チームはライブの評価サービスを維持せずに結果を公開できる。

uvxのエントリーポイントもセットアップ時の摩擦を下げる。公式のuv tool guideによると、uvxは一時的な隔離環境でパッケージ化されたツールを実行する。

この設計は短期間の調査に適している。開発者は、永続的なグローバルインストールを最初の要件にせず、コマンドを試せる。

コーディングエージェントのワークフローは、別のセットアップコストも削減する。エージェントはプロジェクトのドキュメントを読み、YAMLファイルを提案し、テストの改善を支援できる。

人間によるレビューは依然として必要だ。エージェント生成のスイートは、曖昧な期待を埋め込んだり、難しいケースを見落としたり、自身の仮定だけを報いるチェックを作ったりする可能性がある。

したがってこのツールは、評価設計を不要にするものではない。問いから、その問いの最初の実行可能なバージョンまでの距離を短縮するものだ。

この違いは重要である。チームは、データベース、ダッシュボード、トレーシングシステム、大規模なゴールデンデータセットまで含むものを最初のステップとして想定し、評価を先送りしがちだ。

smevalsは、より狭い最初のステップを提案する。1つの現実的な不確実性をエンコードし、少数の制御された構成で実行することだ。

小規模evalスイートは重量級フレームワークに挑む

smevalsの最も強い価値は機能の広さではなく、範囲を限定した問いから始め、根拠を保持できる能力にある。

評価市場にはすでに、より広範なオープンフレームワークが存在する。英国AI Security InstituteのInspectプラットフォームは、データセット、ソルバー、スコアラー、エージェント、サンドボックス、モデルプロバイダー、詳細なトランスクリプトをサポートしている。

同社のInspect documentationでは、タスクをデータセット、ソルバー、スコアラーの組み合わせとして提示している。ソルバーは1回のモデル呼び出しを行うことも、ツールを備えたマルチターンのエージェントとして動作することもできる。

Inspectは、複雑なセキュリティ評価や隔離された実行環境にも対応している。こうした機能は、正式なベンチマークを運用する組織や、外部状態を変更するエージェントをテストする組織に適している。

Promptfooは、プロンプトとアプリケーションのテストという観点からこの問題に取り組む。その設定形式は、プロバイダー、プロンプト、テストケース、アサーション、変数をカバーしている。

公式のevaluation workspaceでは、YAMLでプロバイダー、プロンプト、期待される挙動を定義できることが示されている。このため、プロンプトをテスト可能なコードのように扱っているチームにとって、Promptfooは有力な比較対象となる。

smevalsは、より限定的な公称スコープでこの分野に参入する。その強みは、ユーザーがより多くの機能を求める中でも、その小さなスコープを一貫して維持できるかどうかにかかっている。

焦点を絞ったスイートはレビューしやすい。すべてのタスクを製品上の意思決定に直接結び付けられ、すべての設定をチームが実際に出荷し得る変更として表現できる。

この焦点は失敗分析も改善する。具体的なユーザーニーズを軸に名付けられたテストは、抽象的な能力カテゴリよりも多くの情報を開発者に与える。

週次の製品アップデートを作成するアシスタントを考えてみよう。小規模なスイートでは、正しい会議メモを引用するか、決定事項と提案を区別するか、裏付けのない主張を避けるかをテストできる。

設定では、検索用プロンプト、モデル、文書選択ツールを変えられる。グレーダーは、引用の有無、情報源の同一性、事実の一貫性を確認できる。

公開ベンチマークでは、その製品上の問いには答えられない。チーム固有の文書、想定ワークフロー、有用なアップデートの定義が欠けているためだ。

環境そのものにシミュレーションが必要な場合、重量級のフレームワークは依然として価値がある。ブラウザエージェント、コーディングエージェント、カスタマーサービスシステムでは、再現可能なデータベースやサンドボックスを伴う状態保持型のタスクが必要になることが多い。

小規模なYAMLスイートだけで、こうした条件を自動的に再現できるわけではない。互換性のあるランナー、スクリプト、フィクスチャ、あるいはその他のハーネス構成要素が必要になる。

だからこそ、主な競合は特定の企業ではなく、ひとつの進め方だ。狭い問いからローカルに始めるのか、汎用的な評価インフラから始めるのかという選択である。

どちらの進め方も、あらゆるケースで勝つわけではない。小規模な進め方が勝つのは、セットアップコストによってチームが何もテストできなくなる場合だ。

より広範な進め方が勝つのは、テストで複雑な状態を制御し、完全な軌跡を取得し、隔離を強制し、デプロイメントパイプライン内で継続的に運用しなければならない場合である。

最も有用な進展は、両者をつなぐ形かもしれない。チームはsmevalsで価値あるケースを見つけ、その後、成熟したテストをより大規模な回帰システムへ移行できる。

この進展が機能するのは、成果物の可読性が保たれる場合に限られる。別のエンジニアが再現できるよう、タスク、設定、出力、採点ルールは十分に明確でなければならない。

smevalsはこの可搬性を意識して設計されているように見えるが、その慣行が定着するかどうかは採用状況によって決まる。カスタムグレーダーやランナーが蓄積されるほど、ツールは置き換えにくくなる。

したがって、プロジェクトの小ささは売りであると同時に試練でもある。あらゆる複雑な評価プラットフォームを再現することなく、実用的なエージェントに十分な機能を追加しなければならない。

スコアだけではなお判断できないこと

再現可能なスイートは挙動を明らかにできるが、そのタスク、グレーダー、サンプルが本番環境の現実を代表している保証はない。

最初の不確実性はカバレッジに関するものだ。コンパクトなスイートは狭い問いには的確に答えられる一方で、平均スコア以上に重要な、まれな失敗を見落とす可能性がある。

チームは既知の成功ケースを中心にタスクを書いてしまうこともある。評価生成を依頼されたコーディングエージェントは、もっともらしいバリエーションを作れるが、実ユーザーが見つける意外なエッジケースを発見できるとは限らない。

そのため、本番環境のインシデントはスイートへフィードバックされるべきだ。苦情、失敗したトレース、サポートチケット、手作業のレビューは、合成タスク生成が見逃したシナリオを明らかにできる。

2つ目の不確実性は非決定性である。設定が変わっていないように見えても、モデルは繰り返しの試行で異なる結果を出すことがある。

タスクごとに1回だけ実行しても、信頼できる設定と、たまたま成功した設定を区別できない。出力のばらつきが意思決定に影響するなら、反復試行が不可欠になる。

Anthropicの評価ガイダンスは、複数回の試行にわたる成功率を調べることを推奨している。また、評価者が予測していなかった有効な解決策をモデルが見つける可能性にも警告している。

これは難しい失敗モードを生む。厳格なグレーダーは、その結果がユーザーにより適している場合でも、創造的な結果を不当に減点する可能性がある。

反対の問題はモデルグレーダーで起きる。寛容なAI判定者は、重要な隠れた要件に違反しているにもかかわらず、流暢な出力を受け入れるかもしれない。

人間によるキャリブレーションは、こうした誤りの特定に役立つ。レビュー担当者は合格と失敗を検査し、グレーダーの判断を比較し、判定者が誤った挙動を評価する場合にはルーブリックを改訂すべきである。

3つ目の不確実性は、システムと評価者の間の汚染に関するものだ。コーディングエージェントがタスク、プロンプト、チェックの作成を手伝うと、その選好がベンチマークを形作る可能性がある。

関連するモデルをグレーダーとして使うと、その効果はさらに強まる。テストは実際の有用性を測らず、慣れ親しんだ表現や推論パターンを優遇するかもしれない。

これはモデルによる採点を無効にするものではない。評価はルーブリック、判定者の設定、レビュー手順に追跡可能であり続けるべきだという意味である。

4つ目の問題は統計的信頼性である。3タスクのスイートは明白なフォーマット回帰を特定できるが、モデル品質について広範な主張を裏付けることはできない。

smevalsは自らを小規模な評価スイートと位置付けており、読者もその境界を守るべきだ。そのレポートが比較するのは、実行されたタスクであって、対象モデルのあらゆる能力ではない。

チームは、ローカルな結果を普遍的なランキングへ変換すべきではない。「設定Aは8件の製品ケースに合格した」は裏付けられる。「モデルAの方が優れている」は通常、裏付けられない。

コストとレイテンシーにも同様の注意が必要だ。より高いスコアを出す設定は、より長いプロンプト、より多くのツール呼び出し、あるいはより遅い推論モードを使っている可能性がある。

これらの要素が製品にとって重要なら、スイートはそれらを記録し比較する必要がある。品質スコアだけでは、最適な出荷判断を決められない。

セキュリティも評価設計を変える。シェル、ブラウザ、データベースにアクセスできるエージェントには、隔離された環境と最終状態のチェックが必要だ。

トランスクリプトは、エージェントが成功を主張したことを示すかもしれない。実際の結果は、正しいファイルを作成したか、意図したレコードを変更したか、禁止された行為を避けたかに左右される。

こうした限界は、小規模な評価に反対する論拠ではない。小規模なスイートが信頼できる領域を定義するものだ。

anthropic simonの収束が有用なのは、どちらのアプローチも集計値を終着点として扱っていないからである。実行、トレース、結果、グレーダーの挙動はいずれも検査に値する。

Anthropic Simonの重なりが続くかを示す3つのシグナル

チームが実際のハーネス上の意思決定を比較し、グレーダーをキャリブレーションし、再現可能な証拠を残すために使うなら、smevalsはローンチ後も重要であり続ける。

最初のシグナルは、公開される評価スイートの幅である。Haikuのフォーマットはワークフローを実証するが、エージェント開発者にはツール、状態、複数ステップの完了を含む例が必要だ。

プロンプトだけを比較するスイートでは、smevalsは既存のプロンプトテストツールに近いままとなる。コーディングやリサーチのハーネスを比較するスイートは、より広範な位置付けを裏付けるだろう。

ユーザーが、実行とチェックが可視化された再現可能なエージェント事例を公開すれば、この判断は強まる。例が短いテキスト整形タスクに限られたままなら、弱まる。

2つ目のシグナルはグレーダーのキャリブレーションだ。プロジェクトは、決定論的なチェックと、モデルベースの評価を含むより複雑なチェッカースクリプトをサポートしている。

現在、ユーザーにはそうした評価を人間の判断と比較する手法が必要だ。有用なレポートは、不一致を1つのスコアの中に隠すのではなく、明らかにすべきである。

チームが採点を再実行し、ルーブリックを検査し、グレーダーを変更した理由を文書化できれば、smevalsの意義は強まる。リーダーボードが基礎となる証拠から切り離されれば、弱まる。

3つ目のシグナルは、日常的な開発への統合である。ローカルな実験は一度だけ洞察を生むが、回帰スイートは将来の変更から守る。

モデルの更新、プロンプトの編集、ツールの変更、ハーネスのリリース後に、チームがsmevalsを実行するかを見守るべきだ。繰り返し使われるなら、小規模なスイートが長期的なエンジニアリング資産になり得ることを示す。

統合のために、すべてのチームが精巧なプラットフォームを構築する必要はない。共有リポジトリ、レビュー済みYAML、保存された実行結果、一貫したリリースチェックで十分かもしれない。

初回比較の後にスイートが陳腐化すれば、このシグナルは弱まる。古いベンチマークは、現在の製品を反映せずに安心感を生み出しかねない。

開発者とエンタープライズバイヤーにとって、実践すべきことはシンプルだ。現在直感で決めている判断を1つ特定し、それに異議を唱えられる最小のテストを定義する。

その判断はClaudeとGPTの比較かもしれないが、2種類のシステムプロンプトや2種類の検索戦略の比較でもよい。設定はユーザーが実際に経験するものを反映すべきだ。

最初の結果は判決ではなく、証拠として扱うべきである。失敗を検査し、グレーダーを疑い、実際の作業からケースを追加し、挙動にばらつきがある場合は試行を繰り返す。

持続するanthropic simonの教訓は、1つの小規模ツールがAI評価を解決するということではない。モデル選択、プロンプト設計、ハーネスの挙動は、まとめてテストしなければならないということだ。

あなたのチームは、いまもどの製品上の意思決定をデモ、リーダーボード、あるいは勘に基づいて行っているだろうか。その不確実性を焦点を絞ったスイートに変え、実行結果を残し、証拠が答えを変えるかを確かめてほしい。