社内で使うAIプラグインは、動いた瞬間より、更新した翌日に困ります。昨日まで通っていた手順が通らない。回答の形が少し変わった。担当者の感覚では「たぶん大丈夫」でも、その判断を別の人が再現できません。
Anthropicが2026年9月11日（UTC）に公開したClaude Code 2.1.269には、claude plugin evalが加わりました。プラグインの評価スイートをClaude Code上で実行し、採点結果をJSONとHTMLで残す機能です。私はこれを、プラグイン開発者だけのテスト機能ではなく、会社がAIへ仕事を委譲するときの受け入れ検査として見ています。
AIの出力には幅があります。だからこそ「一度うまくいった」ではなく、同じ課題を同じ条件で試し、更新前後の差を記録する。2.1.269は、その作業を製品側のコマンドへ持ち込みました。
2.1.269で加わった評価の入口
公式リリースの説明は明快です。claude plugin evalでプラグインの評価スイートを実行し、採点可能で再現性のある結果をJSONとHTMLレポートとして出せます。具体的な引数はclaude plugin eval --helpで確認するよう案内されています。
同じリリースでは、プラグインに限らず、運用の観測と再現性に関わる変更も入りました。Bashがファイルを編集した場合、その差分をツール結果へ添える設定bashEditDiffEnabled、Workflowツールの同時エージェント数を1〜256の範囲で調整するCLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS、バックグラウンドエージェントが動いている間に「入力待ち」と誤表示する問題の修正などです。
ただし、同時実行数を増やせば品質が上がるわけではありません。処理量は増えても、同じ誤りを並列で量産することがあります。評価スイートが先、並列化は後。この順番を崩さない方が安全です。
プラグインを「便利だった」で採用しない
Claude Codeの公式プラグイン文書では、プラグインをskills、agents、hooks、MCP serversなどをまとめた再利用可能な単位として説明しています。個人の.claude/設定と違い、チームで共有し、版を付けて配布する用途が前提です。共有物になると、作者のPCで動くかどうかだけでは足りません。
たとえば、顧客メールの返信案を作るプラグインを考えます。文章が自然でも、金額を勝手に確定する、宛先の会社名を取り違える、元メールにない納期を補うなら本番では使えません。ここで測るのは「文章が上手いか」より、守るべき境界を守れたかです。
私なら評価対象を、実際の失敗から作ります。過去に修正が入った返信、担当者が差し戻した提案書、確認漏れが起きた作業指示を匿名化し、入力と合格条件を固定します。架空のきれいな例だけでは、現場の癖を拾えません。
最初の評価セットは10件でいい
大がかりなベンチマークから始める必要はありません。まず10件を選びます。通常ケースを6件、例外を3件、絶対に通してはいけない危険ケースを1件。件数を増やす前に、何を正解とするかを人が決めます。
採点項目は業務ごとに変わります。顧客対応なら、固有名詞の一致、未確認事項の明示、禁止表現の不使用、人の承認が必要な箇所の停止を見ます。社内文書検索なら、正本の保存先を参照したか、引用元を示したか、見つからない情報を作らなかったかを確認します。
点数だけにまとめると事故を隠します。平均90点でも、契約金額を捏造した1件が混じれば不採用です。私は「平均点」と「一発失格」を分ける設計を勧めます。危険ケースの違反は0件。通常ケースは合格率90%以上。失敗した項目は、プロンプト、参照データ、ツール権限のどこで崩れたかを残します。
採点者も固定しすぎない
評価をAIだけに任せると、読みやすい文章や形式の一致へ点が寄りやすくなります。初回は業務担当者が全10件を読み、AIの採点と食い違った理由を記録します。2回目以降も、危険ケースは毎回人が確認。通常ケースは抜き取り確認に切り替えます。
採点者が変わっても判断が揃うかも見ます。「丁寧」「自然」のような言葉だけでは揃いません。「元データにない日付を追加していない」「承認前の金額を確定形で書いていない」のように、画面を見て判定できる条件へ直します。2人の判定が割れた項目は、AIの問題より合格条件の書き方に問題があるかもしれません。
この見直しを1回挟むだけで、評価セットはテスト集から社内ルールの棚卸しへ変わります。プラグインを直す前に、人の判断が言葉になっていない箇所が見つかることもあります。
更新前後で比べる4段階
- 現在使っている版で評価スイートを実行し、JSONとHTMLを保存する
- Claude Code、プラグイン、参照資料の版を変更記録へ残す
- 更新後に同じ評価セットを同じ条件で実行する
- 点数の上下だけでなく、新しく増えた失敗と直った失敗を人が読む
結果の保存先も決めます。HTMLは担当者が読む確認票、JSONは時系列比較や自動判定に使えます。どちらか一方ではなく、同じ実行から両方を残せる点が扱いやすいところです。レポートには実行日時、製品版、プラグイン版、評価セット版をひも付けます。後から数字だけを見ても、条件が違えば比較になりません。
導入の判定は、全体の平均点だけで決めません。危険ケースが1件でも失敗したら止める。通常ケースの合格率が基準を下回ったら前の版を維持する。改善した項目と悪化した項目が混ざる場合は、影響の大きい業務だけ旧版へ戻す。GO、HOLD、差し戻しの条件を実行前に書いておくと、結果を見た後の都合のよい判断を減らせます。
評価機能にも限界がある
claude plugin evalがあるだけで、評価内容が正しくなるわけではありません。評価セットにない失敗は検知できず、採点基準が曖昧なら、再現できるのは曖昧な判定です。モデルや外部MCPの状態が変われば、同じ入力でも出力が揺れる可能性もあります。
もう一つ気をつけたいのが、実データの持ち込みです。顧客メールや契約書をそのままテスト素材へ入れると、評価レポートや実行ログに機密情報が残ります。氏名、会社名、金額、認証情報を置換し、どうしても実データが必要な試験は保存範囲と削除時期を先に決めます。接続先、操作権限、秘密情報の境界を先に点検する手順は、Claude Code 2.1.268の受け入れテストで整理しています。
評価を本番監視の代わりにもできません。公開前の受け入れ検査に通っても、権限変更、参照資料の更新、外部サービス障害で挙動は変わります。本番では、差し戻し率、危険操作の停止率、根拠なし回答の件数を別に追います。評価スイートは出荷前の関門。本番ログは出荷後の現実です。
最初にやること
いま社内で使っているClaude Codeプラグインを1つ選び、過去に人が直した仕事を10件集めます。正解文を作り込むより、「この条件を破ったら失格」を先に書く。そのうえで2.1.269のclaude plugin evalを試し、最初のJSONとHTMLを基準値として保存します。
AIへ任せる仕事が増えるほど、担当者の勘だけでは更新を判断できなくなります。毎回同じ試験に戻れる状態を作っておけば、便利そうな新機能に引っ張られず、「この会社の仕事を壊さないか」で採否を決められます。