1. これは何の話？

社内でAIエージェントを開発し、多様なタスクをこなせるようシステムを拡張しているエンジニアに向けた、耳の痛い指摘と解決策です。 Hugging Face等のコミュニティで著名なPhil Schmid氏は、AIエージェントの能力を補強する「スキル（ツールやプロンプトからなる手順群）」の評価（Eval）に関する実践的なガイドラインを公開しました。

彼が引いた論文（SkillsBench）のデータによれば、現在GitHub等には47,000種類以上ものユニークなAIスキルが公開されていますが、そのほとんどは手動で「なんとなく動いた（バイブスチェック）」だけで本番環境にデプロイされています。 通常のソフトウェア開発ではあり得ないこの無防備な状況に対し、Schmid氏は「成功の定義決め」「決定論的なテストの書き方」「LLM-as-judgeの正しい使い所」など、自らの経験（Gemini APIスキルの成功率を66.7%から100%に引き上げた事例）を基にした具体的なテスト構築手法を提示しました。

概要

2. 何がわかったか

エージェントスキルの評価環境（Eval Harness）を構築する上で、10個のベストプラクティスが明文化されました。重要な要素は以下の通りです。

最も強調されたのは「ルート（過程）」ではなく「アウトプット（結果）」を評価せよという点です。エージェントは予期せぬクリエイティブな手順で正解に辿り着くことがあるため、手順をペナルティの対象にするとスキルの柔軟性を殺してしまいます。 テストの構築は10〜20個の小さなプロンプトセットから始め、「古いAPIを呼んでいないか（Deprecatedの回避）」「指定されたSDKのコードが含まれているか」といった項目を、まずは単純なRegex（正規表現）を用いた決定論的チェックで検証すべきと説いています。

さらに、多くの開発者が軽視しがちなのが「ネガティブテスト（Negative Controls）」です。 「表の作成」「データ分析」といった広すぎるスキル名はあらゆるプロンプトで誤爆トリガーを引いてしまうため、「この質問にはスキルが発動しないこと」を担保するテストが同等に重要であることが示されました。一歩進んで、速度や消費トークン量といった「効率性」も、無視されがちですが非常に重要な評価次元として挙げられています。

3. 他とどう違うのか

既存の「なんでもAIに評価させる（LLM-as-judgeに頼り切る）」という風潮に対し、アンチテーゼとして明確に「コストと確実性」の切り分けを主張している点が異なります。

Schmid氏は、APIの型指定や旧版モデルを使わないといった明白な事実確認にまでLLMの自動評価を使うことを避け、関数を使った正規表現チェックを優先するよう求めています。 「フォントにRoboto等の凡庸なものを使っていないか」「デザインが退屈でないか」といった、どうしてもルールで定義できない定性的な評価のみに絞ってLLM-as-judge（＋Pydanticなどによる構造化出力）を適用すべきだとしています。この「素早く安い決定論的チェック」と「遅く高いLLM評価」のハイブリッド構成こそが、実運用に耐えうるスキルテストの解です。

4. なぜこれが重要か

このガイドが重要たる所以は、私たちが「モデル自体の賢さ」の検証から、「モデルに付与する自社ツールの安定性」の検証へと、AI開発のフェーズを移行させなければならない段階に来ているからです。

今後、各企業は自社の社内システムを操作させる独自の「スキル」を大量に開発することになります。 スキルがテストされていなければ、「旧バージョンの社内APIを叩き続けてエラーを吐く」「不必要なタイミングでスキルが起動し、無駄なAPIコストを垂れ流す」といった目に見えない負債がシステム内に蓄積します。AIエージェントが本番環境のインフラとして機能するためには、モデル自体の性能向上を待つのではなく、手元のスキルセットに対する「確固たるテスト文化」を今のうちに根付かせることが必須要件となります。

5. 未来の展開・戦略性

「スキルのテスト」という概念が普及することで、今後は「テスト済みの安全性・効率性が保証されたスキル」が取引される、新たなスキルマーケットプレイスの基盤が整備されていくでしょう。

開発者は能力不足のモデルを補完するために「Capabilityスキル」を大量生産していますが、数ヶ月後にモデル本体が賢くなれば、それらのスキルの多くは不要になります（Skill retirement）。評価用テストが整備されていれば、「スキルなしでモデル単体にテストを走らせ、合格すればそのスキルを安全に廃止する」という、エージェントシステムの自動リファクタリングが可能になります。 コードと同様に、AIスキルもテスト駆動開発（TDD）によって構築・剪定されるのが当たり前の時代が始まろうとしています。

6. どう考え、どう動くか

私たちは「手元で数回動いたから完成」というプロンプトエンジニアリングの延長のような考え方を捨て、ソフトウェアエンジニアリングのリサーチ手法を取り入れる必要があります。

まずは自社で開発しているAIエージェントのプロンプトや独自ツールに対し、わずか10個で構わないので「成功とみなす条件（コンパイルが通る、指定文字列が含まれるなど）」を定義し、それを自動でチェックするスクリプトを書くべきです。 特に、無駄なAPI呼び出しを防ぐための「ネガティブテスト」は、コスト削減に直結する即効性の高いアクションです。

  • 開発中のAIスキルに対し、「これだけは守らせる」という決定論的なルール（特定のライブラリを使う、特定の処理をしない等）を正規表現で書き出す。

  • スキルのトリガーとなる「Name」と「Description」を見直し、曖昧な言葉（「役立つツール」「データ処理」など）を削って発動条件をシャープにする。

  • プロンプトのテストセットの中に、「このツール（スキル）は使わずに答えろ」といった制約を加えたネガティブテストを3〜4件追加する。

  • 今日やること：自チームのAIチャットボットやエージェントツールに対して、「絶対にエラーになるべき意地悪な質問（ネガティブコントロール）」を入力し、意図せずスキルが暴発しないかテストする。

  • 今週やること：頻繁に失敗するエージェントの動作結果を集め、それを「これをパスできれば成功」という明確な評価用の小テストとしてドキュメント化する。

7. 限界と未確定

明確なテスト手法ではあるものの、評価基盤の構築には独自の投資と課題がつきまといます。

  • 評価環境のオーバーヘッド。数十のスキルそれぞれに10〜20のプロンプトセットと決定論的チェックを実装・保守する作業は、スキル開発そのものよりも多大な工数を要する場合があります。
  • 非決定性の壁。エージェントの性質上、3〜5回の試行でパス率を分散として見る必要がありますが、試行回数を増やせばテスト実行時の評価コストやAPI待機時間が膨れ上がってしまいます。
  • 次にどう調べるか：LangChainなどのフレームワークが提供している最新の「エージェント評価用ライブラリ（LangSmith等）」をインポートし、どこまでテストコードの実装を簡略化できるかを調査します。

8. 用語ミニ解説

  • LLM-as-judge 大規模言語モデル（LLM）自身を裁判官のように使い、別のAIが出力したテキストの妥当性や品質を「100点満点中何点か」などの定性的な基準で採点・評価させる手法のことです。
  • 決定論的（Deterministic） 同じ入力に対して、常に全く同じ結果（真か偽かなど）が必ず返ってくる性質のことです。曖昧さを含むAIの挙動テストにおいて、基準として重宝されます。

9. 出典と日付

Phil Schmid（公開日／更新日／最終確認日：2026-03-06）：https://www.philschmid.de/testing-skills