プラグインを配布したあと、「本当にこれは Claude の挙動を良くしているのか」を数字で説明できますか。手元では良さそうに見えても、プラグイン無しの素の Claude Code と比べて何がどれだけ改善したのかは、感覚では証明できません。2026 年 9 月に追加された claude plugin eval は、この「効いている証明」をコマンド一本で回すための仕組みです。本稿は 2026-10-08 時点の仕様を起点に、採点基準（grader）の設計とベースライン比較の読み方という、docs の一行説明の先にある実務の勘所を扱います。
claude plugin eval は何をするコマンドか（仕様）
まず機能の輪郭を公式記述で確認します。
run your plugin against a suite of test cases, score the results, and compare against a no-plugin baseline.
claude plugin eval は、テストケースのスイートに対してプラグインを実行し、結果を採点し、プラグイン無しのベースラインと比較します。重要なのは三要素が一体である点です。「実行」だけでも「採点」だけでもなく、ベースラインとの比較まで含むことが、このコマンドの価値の中心です。このリリースは Week 37（v2.1.263–v2.1.269、2026 年 9 月 7〜11 日）です。
採点基準そのものを手書きする必要はありません。
claude plugin eval init drafts the cases and graders for you.
claude plugin eval init が、評価用のテストケースと採点基準の草案を生成します。eval と init は同じ Week 37 で同時に提供されました。つまり「草案を生成 → 人が調整 → 評価を回す」という一連の流れが最初から想定されています。
評価ハーネスをきれいな環境で回す
評価の信頼性は、環境のきれいさに依存します。手元の設定やカスタムツールが混入すると、スコアがプラグインの効果なのか環境のせいなのか切り分けられません。ここで使えるのが --restricted です。
starts a session without the command-running tools or your user and project settings, for evaluation harnesses on shared machines
--restricted は、コマンド実行ツールとユーザー・プロジェクト設定を除いた状態でセッションを開始します。共有マシン上の評価ハーネス向けと明記されています（Week 35、v2.1.240–v2.1.250、2026 年 8 月 24〜28 日）。トラブルシュート用途には、すべてのカスタマイズを無効化する --safe-mode もあります（Week 24、v2.1.166–v2.1.176、2026 年 6 月 8〜12 日）。評価が壊れたとき、まず --safe-mode で切り分けるのが定石です。
プラグインが載っているかを先に確かめる
評価で低スコアが出たとき、原因が「プラグインが効いていない」のか「そもそも読み込まれていない」のかは別問題です。/plugin list はインストール済みプラグインをインラインで出力します（Week 23、v2.1.158–v2.1.165、2026 年 6 月 1〜5 日）。評価の前にロード状態を確認する一歩として使います。評価対象になりうる実例として、Claude が変更を加えている最中に脆弱性レビューを走らせる security-guidance プラグイン（Week 22、v2.1.150–v2.1.157、2026 年 5 月 25〜29 日）のような「挙動を変える」プラグインは、まさに eval で効果測定したい対象です。
採点とベースライン比較の設計（実務の核心）
ここからが docs の一行には書かれていない部分です。grader は「Claude の言い回し」ではなく観測可能な成果物を採点するよう設計します。ベースラインとの差分（delta）を主指標に置き、絶対スコアだけを見ないこと。プラグイン有りと無しが両方成功するケースは判別力がゼロなので、スイートの質はそこで決まります。詳細な実装手順と採点設計の落とし穴は、本記事の有料版（note）に完全な通し例として収録しています。