Claude Code 2.1.269、プラグインのA/B評価を導入。ただし自動スコアには依然として品質基準が不足

AnthropicはClaude Code 2.1.269に `claude plugin eval` を追加し、プラグインの品質検査を公式CLIに組み込んだ。開発者はテストケースを用意し、プラグインを読み込んだ場合と読み込まない場合のそれぞれで実行することで、ケースごとのスコア、集計JSON、HTMLレポートを取得できる。このablation設計は、成功した出力を一度だけ提示するよりも有用だ。基盤モデル自体がすでにタスクを遂行できる場合、本当に測定すべきなのは、最終回答が妥当に見えるかどうかではなく、プラグインがもたらす増分効果だからだ。

同バージョンでは、Remote Control、クラウド、その他のheadless sessionでも `/output-style` を切り替えられるようになった。また、Bashツールが編集を担う場合、ファイルの差分をツールの結果に添付できる。企業内のSkill、hook、MCP連携を保守するチームにとって、機械可読な評価出力は、CIへの組み込み、バージョンアップ前の回帰比較、エビデンスの保存を可能にする基盤となる。ただし、公式release noteが保証しているのは「scored、reproducible results」のみで、graderのキャリブレーション、反復サンプリング、モデルバージョンの固定方法、統計的不確実性については公開されていない。

評価研究者Hamel Husainによる公開検証も、このツールの限界を明らかにしている。彼らが文章スタイル用プラグインを試したところ、システムは3つのgrader、JSONLデータ、レポートを生成したが、一部の評価基準はプラグイン自身のルールから直接採用されていた。この場合、処置群がプラグインを読み込んでいないベースラインよりも、それらのルールに準拠するのは当然だ。そこで証明されるのは、プラグインの指示が守られたことであり、文章がより明確になったことや、ユーザー満足度が向上したことではない。検証者はさらに、スコアと評価基準に出典や文脈が欠けていること、また、ツールが依然として作成者自身に実際の失敗事例を用意するよう求めていることも指摘した。これは、評価プロセスで最も手間のかかるerror analysisにほかならない。

したがって、エンジニアリングチームは当面、このツールを汎用的な品質判定システムではなく、回帰テストrunnerとして捉えるのがよい。より信頼性の高い方法は、CLI、評価対象モデル、judge modelを固定し、生のtraceを保存したうえで、実際の失敗サンプルから人手でアノテーションしたデータセットを構築し、コスト上限を設定することだ。副作用を伴うツールについては、合成fixture、外部サービスのmock、最小権限も利用する必要がある。今後は、Anthropicがsuite schema、スコアの根拠、反復試験の制御方法を公開するか、さらに単独のSkillも同じプロセスで安定してテストできるようにするかが注目される。