AIエージェントに「スキル（Skill）」を授ける流れは、AnthropicのSKILL.md、Microsoftのagentskills.io、Addy Osmaniのagent-skillsなど、2026年に入って急速に標準化が進んできた。だがスキルが増えるほど現場で問題になるのは「そのスキルは本当に効いているのか」を測る共通の物差しがないことだ。

microsoft/wazaはこの空白に正面から取り組むGo製CLIだ。「CLI / Framework for Agent Skills - create, test, measure and improve skill quality and effectiveness」というREADMEの一文が示すとおり、skillの作成・テスト・計測・改善を1本のツールチェーンに束ねる評価フレームワークである。

リポジトリは2026年4月時点で315★／24forks／23 open issues。最新バージョンは2026年4月28日リリースのv0.31.0で、現在もMicrosoft内のActive Maintenance下で週次に近いリリースが続いている。

本記事ではwazaが解決しようとしている問題、eval.yamlを中核とする評価モデル、--baselineによるA/B比較、MCPサーバー連携、CIへの組み込み方、Anthropic SkillsやAddy Osmani Skillsとの位置関係まで、日本語で実用目線で整理する。

AIエージェント全体の選び方は AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 で全体像を掴んでから読むと、本記事の位置付けが分かりやすい。

microsoft/wazaリポジトリ — Agent Skills評価フレームワーク

この記事のポイント
  • ・Microsoft WazaはAgent Skillsの品質をeval.yaml＋validatorで採点するGo製CLI／フレームワーク。
  • ・--baselineモードでskill適用前後をA/B比較し、ブートストラップ95%CIでskillの効果を数値化できる。
  • ・MCPサーバー（10ツール）とAzure Developer CLI拡張を備え、Claude CodeとAzure両方のエコシステムから利用可能。

1. Wazaが解決する問題——Agent Skillsに足りなかった「物差し」

WazaはAgent Skillsの品質を客観的に測る共通基盤を提供する。skillが増えるほど、効果検証なしに導入する状況が当たり前になっていた。

2026年に入り、AnthropicのSKILL.md仕様が業界標準として定着した。mattpocock/skillsは57K★、addyosmani/agent-skillsは18K★を集めるなど、コミュニティ製skillパックも急増している。

しかし「skillを入れると本当にエージェントの品質が上がるのか」を定量的に検証する手段は、各チームが自作していた。手書きの回帰テスト、目視レビュー、社内Slackでの体感共有——これではスキルの増減が品質に与えるインパクトを再現可能な形で語れない。

Microsoftはこの問題に対し、Agent Skillsの評価レイヤーを独立OSSとして切り出した。Wazaはskill本体を作るツールではなく、既存のskill（SKILL.md）に対してテスト・採点・改善のループを回す評価フレームワークとして位置付けられている。

重要なのは、Wazaが特定のskillエコシステムに依存しないことだ。Anthropic公式skill、Microsoft公式skill、Addy Osmani agent-skills、社内skill——フォーマットがSKILL.mdに準拠していれば、すべて同じeval.yamlで評価対象にできる。

類似ツールとの違い
従来は「pytestのようなコード単体テスト」「Promptfooのようなプロンプト評価」「LangSmithのような観測ツール」がバラバラに存在していた。WazaはAgent Skills特有の概念（SKILL.md・validators・skill discovery・トークン予算）に最適化されており、これらを一気通貫で扱える。

2. アーキテクチャ概要——eval.yaml＋tasks＋validatorsの3層構造

Wazaの評価モデルは3つのファイル種別で構成される。eval.yaml（仕様）／tasks/*.yaml（個別テスト）／fixtures/（入力データ）の3層だ。

公式GETTING-STARTED.mdが示すeval.yamlの最小構造を見てみよう。name／skill／config／graders／tasksの5フィールドだけでベンチマーク仕様が完結する。

name: code-explainer-eval
skill: code-explainer
version: "1.0"

config:
  trials_per_task: 1
  timeout_seconds: 300
  executor: mock
  model: gpt-4o

graders:
  - type: code
    name: has_output
  - type: text
    name: explains_concepts
  - type: behavior
    name: reasonable_cost

tasks:
  - "tasks/*.yaml"

3層の役割分担は以下のとおりだ。

3層モデルの責務
  • ・eval.yaml：評価仕様。skill名、実行モデル、タイムアウト、validator（grader）の集合を定義。
  • ・tasks/*.yaml：個別タスク。プロンプト、期待出力、validator設定、follow_up_promptsを格納。
  • ・fixtures/：タスクが参照する入力ファイル。コードスニペット、サンプルデータ、ドキュメントなど。

WazaはCLIからwaza run eval.yamlを実行するだけで、tasks/*.yamlの全タスクをパラレル実行し、validatorで採点し、JSON結果を吐く。CIでも対話開発でも同じインターフェースで動く点が秀逸だ。

--parallel --workers 8で並列実行、--trials 5でフレーキー検出、--cacheで再実行高速化、--reporter junit:results.xmlでJUnit互換出力——必要な実用機能が一通り揃っている。

3. インストール——install.sh1行 or azd拡張

WazaはバイナリインストールスクリプトとAzure Developer CLI（azd）拡張の2系統で配布される。Goランタイムなしで即利用可能な点が大きい。

公式が推奨するバイナリインストールは1行で済む。OS／アーキテクチャ自動判定、SHA-256検証、/usr/local/binへの配置までスクリプトが面倒を見てくれる。

curl -fsSL https://raw.githubusercontent.com/microsoft/waza/main/install.sh | bash

azd環境を使っているチームには拡張パッケージのほうが管理しやすい。azd ext source addで独自レジストリを追加し、azd ext install microsoft.azd.wazaで導入する。

azd ext source add -n waza -t url -l https://raw.githubusercontent.com/microsoft/waza/main/registry.json
azd ext install microsoft.azd.waza
azd waza --help

注意点として、ソースインストールにはGo 1.26＋とgit LFSが必要だ。READMEには「go installでは入らない」と明記されている。これはCopilotバイナリをLFSアーティファクトとしてリポジトリに埋め込んでいるためだ。

git lfs install
git lfs pull
git clone https://github.com/microsoft/waza.git
cd waza
go build -o waza ./cmd/waza

インストール後はバックグラウンドで自動アップデートチェックが動き、新版があればコマンド出力末尾に通知が出る。CI実行時のノイズになる場合は--no-update-checkフラグ、または環境変数WAZA_NO_UPDATE_CHECK=1で抑止できる。

4. クイックスタート——waza initから最初のevalまで5分

WazaはAddy Osmani風に言えば「5 Minutes to First Eval」を本気で目指している。プロジェクト初期化、skill作成、eval scaffold生成、実行までを4コマンドで完結させる設計だ。

公式が示す最短ルートを実コマンドで追ってみる。Project ModeとStandalone Modeの2つがあるが、Project Modeのほうが複数skillを管理する実務に向いている。

waza init my-project          # skills/ evals/ .github/workflows/eval.yml を生成
cd my-project
waza new skill code-explainer # skills/code-explainer/SKILL.md と evals/code-explainer/ を生成
waza run my-project           # 全skillの全evalを実行
waza check skills/code-explainer

waza new skillはSKILL.md・eval.yaml・positive/negative trigger task YAMLまでscaffoldを吐く。waza checkは提出前の品質ゲートで、frontmatterの欠損やtrigger記述の弱さを警告する。

特にユニークなのはwaza new task from-promptコマンドだ。実プロンプトをCopilotに流して観測されたツール呼び出し・skillトリガー・出力テキストから自動的にtask YAMLを生成する。初期データ作成の手間を一気に削減できる。

waza new task from-prompt "Explain this code and suggest fixes" \
  evals/code-explainer/tasks/recorded-task.yaml \
  --model claude-sonnet-4.5 \
  --tags recorded,regression

このコマンドは「実利用ログをregressionテスト化する」業務フローと相性が良い。プロダクションで観測した良い応答をそのまま回帰スイートに昇格させられる。

5. 主要コマンド一覧——init／new／run／check／compareの役割分担

Wazaの主要コマンドは大きく生成系・実行系・分析系の3グループに分かれる。下表でそれぞれの役割を一覧で押さえる。

カテゴリ コマンド 役割
生成 waza init プロジェクトワークスペースを初期化（skills/・evals/・CI workflow生成）。
生成 waza new skill SKILL.md＋eval scaffoldを生成。Project／Standalone両モード対応。
生成 waza new eval 既存SKILL.mdからtrigger情報を読み取りeval suiteをscaffold。
生成 waza new task from-prompt 実プロンプトを録画してtask YAMLを自動生成。
生成 waza suggest LLMがSKILL.mdを読みtest case／grader／fixtureを提案（dry-run／apply）。
実行 waza run eval.yamlを実行。--parallel／--baseline／--trials／--cacheを備える。
実行 waza grade 既存results.jsonを再採点。validator変更時に便利。
分析 waza compare 複数のresults.jsonを横並び比較。pass率差分やper-task deltaを表示。
分析 waza coverage skill→evalの被覆グリッドを生成。Markdown／HTML出力。
品質 waza check skill提出前のreadinessチェック。trigger・metadata・eval coverageを検証。
品質 waza tokens count skillのトークン消費を計測。
品質 waza tokens compare main --threshold 10 mainブランチとのトークン予算diff。
品質 waza tokens suggest 不要トークンの削減候補を提案。
拡張 waza quality LLM-as-Judgeでskill出力の品質を主観スコア化。
拡張 waza dashboard ローカルダッシュボードサーバーを起動。トレンド／差分を可視化。

ポイントはrun／grade／compareが独立していることだ。重い実行を1度行えば、validator調整やモデル比較は安価な再採点で回せる。

特にwaza tokens compare main --threshold 10は、Pull Requestでskillのトークン予算が10%以上増えたら警告する設定で、Claude Codeのコンテキスト爆発を防ぐ品質ゲートとして実用度が高い。

6. –baselineモード——skillの効果をA/B比較で数値化

--baselineはWazaの最大の差別化要素だ。同一タスクをskill適用前後で2回実行し、改善度をスコア化する。

skillの効果検証は本来「適用前後の比較」が必須だが、手作業でやると現実的でない。Wazaはwaza run eval.yaml --baselineの1フラグで自動的にA/B構成を組む。

具体的な動きは次のとおりだ。

waza run evals/code-explainer/eval.yaml --baseline -v --output results.json

実行時、各タスクは2回流れる。1回目はskillなし（baseline）、2回目はskillあり（normal）。validator結果の差分からskill適用による改善（または劣化）スコアが計算される。

flowchart LR A[task.yaml] --> B[run #1: skill OFF
baseline] A --> C[run #2: skill ON
normal] B --> D[validators採点] C --> D D --> E[delta = score-ON - score-OFF] E --> F[results.json
per-task delta + aggregate]

さらにv0.3x系で導入されたブートストラップ95%信頼区間機能（10K resamples）により、skill適用の改善が偶然か有意かを統計的に判定できる。「3タスクでスコアが上がっただけ」では報告できないという厳しさが組み込まれている。

baseline運用のコツ
  • ・トライアル数を`--trials 5`以上にしないと信頼区間が広すぎて使い物にならない。
  • ・skillが正しくON／OFFされているかは`--transcript-dir`でtranscriptを保存してgrep確認するのが確実。
  • ・mock executorではbaselineの差が出ないので、必ずcopilot-sdk executorで本番モデルを当てる。

7. validators／graders——code・text・behavior・LLM-as-Judgeの4タイプ

WazaがTask出力をスコアリングする手段は4種類のvalidatorだ。それぞれ独立に追加でき、タスクごとに重み付けできる。

公式examplesのeval.yamlから抜粋した代表的なvalidator定義を見てみよう。typeフィールドだけ変えれば挙動が切り替わる構造だ。

graders:
  - type: code
    name: has_output
    weight: 1.0
    config:
      mode: contains
      target: "function"
      caseSensitive: false
  - type: text
    name: explains_concepts
    weight: 2.0
    config:
      patterns:
        - "time complexity"
        - "edge case"
  - type: behavior
    name: reasonable_cost
    weight: 0.5
    config:
      max_tokens: 2000
      max_tools_called: 3
  - type: llm-judge
    name: explanation_quality
    weight: 3.0
    config:
      judge_model: claude-sonnet-4.5
      rubric: "Score 0-10 on clarity, accuracy, and completeness"

各validatorの責務分担を整理すると次のとおりだ。

4 validatorタイプ
  • ・code grader：構造的検査。出力にfunction定義が含まれるか、ASTが妥当か等を機械的にチェック。
  • ・text grader：文字列／正規表現マッチ。「time complexity」「edge case」など期待語彙の網羅率を見る。
  • ・behavior grader：振る舞い検査。トークン上限、ツール呼び出し数、タイムアウトなど効率性を採点。
  • ・llm-judge：LLM-as-Judge。rubricに基づき判定モデルが0-10で主観スコアを付ける。

weightフィールドはv0.3x系で導入された機能で、ComputeWeightedRunScoreメソッドが各validatorの重み付き総合スコアを計算する。「behavior gradersは参考値、llm-judgeを最重視」のような運用ポリシーが宣言的に書ける。

LLM-as-Judgeは便利な一方でコストが嵩むため、waza qualityコマンドとして独立CLIが用意されている。CI上ではcode／text／behaviorのみで回し、毎晩のバッチでquality scoringを実行する設計が現実的だ。

8. MCPサーバー連携——Claude Codeから直接wazaを叩く

Wazaにはv0.3x系で常時稼働のMCPサーバーが組み込まれた。stdio transport経由で10ツールを公開し、Claude Codeから直接呼び出せる。

公開ツールは以下の10個だ。eval定義の検査、実行、結果の取得まで一通りカバーされている。

MCPツール 役割
eval.list プロジェクト内の全eval一覧。
eval.get 特定evalの詳細（tasks／graders／config）取得。
eval.validate eval.yamlの構文／参照妥当性検証。
eval.run evalを実行（同期）。
task.list 特定evalのtasks一覧。
run.status 実行中ジョブのステータス。
run.cancel 実行中ジョブのキャンセル。
results.summary 直近run集計（pass率・平均score）。
results.runs 過去runの一覧。
skill.check skillのreadinessチェック。

Claude Code側の.mcp.jsonには次のように登録する。Goバイナリが直接stdio MCPサーバーとして振る舞うので、別プロセス起動は不要だ。

{
  "mcpServers": {
    "waza": {
      "command": "waza",
      "args": ["mcp", "serve"]
    }
  }
}

Claude CodeからのMCP活用は MCPサーバー構築ガイド と組み合わせて読むと、Waza以外のMCPツール群との統合パターンも掴める。

これによりClaude Codeが「skillを書いて、Wazaに採点させ、スコアで赤点ならrewriteする」というセルフ改善ループを自動化できる。Microsoft自身、社内で同種の運用を始めていることがREADMEから示唆されている。

9. CI/CD統合——mock executorとcopilot-sdk executorの使い分け

WazaのCI戦略は「PRはmockで速く・mainはcopilot-sdkで本物を叩く」の2段構えが基本だ。

waza initで生成される.github/workflows/eval.ymlは、PRイベントではexecutor: mock、push to mainではexecutor: copilot-sdkを切り替える設計になっている。下のYAMLは公式examples/ci/READMEを骨子にした例だ。

name: skill-evals
on:
  pull_request:
  push:
    branches: [main]

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install waza
        run: curl -fsSL https://raw.githubusercontent.com/microsoft/waza/main/install.sh | bash
      - name: Run evals (mock on PR)
        if: github.event_name == 'pull_request'
        run: waza run evals/ --reporter junit:results.xml --no-update-check
      - name: Run evals (production on main)
        if: github.event_name == 'push'
        env:
          COPILOT_API_KEY: $
        run: waza run evals/ --executor copilot-sdk --baseline --output results.json
      - name: Upload results
        uses: actions/upload-artifact@v4
        with:
          name: waza-results
          path: results.*

ポイントはmockがdeterministicなfake応答を返すことだ。APIキー無しでCIが回り、PR上でskillの構文／eval定義／validator設定の問題はすべて検出できる。コストとflakinessを伴う本物のモデル呼び出しはmainブランチに遅延させる、という分担になっている。

--reporter junit:results.xmlを使えばGitHub PRのChecksタブに失敗tasks名がそのまま表示される。Skill開発者は「どのvalidatorが落ちたか」までCI画面だけで追える。

10. tokens commands——Skillsのコンテキスト肥大を防ぐ品質ゲート

Wazaのtokensサブコマンドは、Claude Codeを実運用に乗せたチームが必ず直面する「skillが増えすぎてコンテキストを食う問題」への直接的な解答だ。

waza tokens count skills/は全skillのトークン消費を一覧する。waza tokens compare main --threshold 10はcurrentブランチがmainに比べて10%以上トークンを増やしたかをチェックし、超えた場合exit code非ゼロで失敗する。

$ waza tokens compare main --skills --threshold 10
Skill                       Main      HEAD      Delta
code-explainer              3,420     3,510     +2.6%   OK
diff-analysis               2,100     2,540     +21.0%  FAIL
test-writer                 1,800     1,790     -0.5%   OK

❌ 1 skill exceeded the +10% threshold.

CIに組み込めば、skillのコンテキスト爆発をPR時点で検出できる。Anthropicのsubagent経由でskillを引き込むパターンでは、1つのskill肥大化が全体性能に直結するため、この品質ゲートは効果が大きい。

Claude Codeのトークン管理全体は Claude Code完全ガイド2026：インストールから本番運用まで も参考にしたい。コンテキスト最適化の設計思想がWazaのtokens commandsの背後にある。

waza tokens suggest skills/はheuristicベースで具体的な削減候補を出す。冗長な見出し、繰り返される免責文、長すぎるexample blockをハイライトしてくれるため、リファクタリングの起点として使いやすい。

11. ダッシュボード／コンパレンス——複数モデル横並びの可視化

Wazaは結果の可視化にもしっかり投資されている。ローカルダッシュボードサーバーとwaza compareコマンドの2系統が用意されている。

waza dashboard --dir ./resultsで起動するローカルサーバーは、指定ディレクトリ配下のresults.jsonをスキャンしてトレンド／pass率／per-task scoreの推移をWeb UIで描画する。複数runの重みづけスコア、信頼区間、validator別breakdownが1画面に集約される。

CLIだけで済ませたい場合はwaza compareが便利だ。複数のresults.jsonを並べてper-task scoreの差分とaggregate統計を表示する。

waza compare results-claude.json results-gpt4.json results-copilot.json

実務では「同じeval.yamlを3モデルで流して、Wazaにcompareさせる」のがstandardプラクティスとして定着しつつある。モデル選定の根拠が再現可能な数値として手元に残るのが大きい。

waza coverage --format markdownはskill→evalの被覆グリッドをMarkdownテーブルで吐く。fully covered／partially covered／missingの3段階で色分けされ、testing gapが一目で分かる。Microsoftはfull coverageの定義を「tasksが存在し、validatorが2タイプ以上ある」としており、簡素ながら実用的な閾値だ。

12. 類似ツール比較——Promptfoo・LangSmith・DeepEval等との位置付け

Wazaを正しく評価するには、隣接ツールとの差分を理解する必要がある。Skill-firstの設計こそがWazaの最大の差別化要素だ。

ツール 主目的 Skill対応 –baseline相当 OSS／商用
microsoft/waza Agent Skill品質評価 ◎ ネイティブ ◎ ビルトイン OSS（MIT）
Promptfoo プロンプト評価 △ 個別設定 △ 手動 OSS
LangSmith LLM観測／評価 × × 商用（OSS版あり）
DeepEval RAG評価中心 × × OSS
Helicone LLMコスト監視 × × OSS／商用
OpenAI Evals 一般的LLM評価 × × OSS

PromptfooはYAMLでprompt評価を書ける点でWazaに似ているが、SKILL.mdの概念やwaza tokensのようなskill予算管理は持っていない。LangSmithはobservabilityが本業で、CI上での再現可能なベンチマークには向かない。

WazaはAnthropicのSKILL.md仕様に最適化されており、skill discovery（--discover）／token budget／behavior validatorという3つの機能がagent skill運用に直接効く。これらは他ツールでは外側のスクリプトでつなぐしかなかった。

skill自体の設計思想は mattpocock skillsを再評価｜57K★『Skills For Real Engineers』設計思想を読む と Addy OsmaniのAgent Skills｜AIコーディングエージェントに上級エンジニアの思考を注入する20のスキル を併読すると、Wazaが何を「測ろうとしているか」がより鮮明になる。

13. 誰が使うべきか——4つの典型シナリオ

Wazaは万能ではなく、Agent Skillsを継続的に運用する組織にこそ価値が出る。導入判断のための4つのシナリオを示す。

導入候補
  • ・Claude Code／Copilotを5人以上で運用するチーム：skillの個人最適と組織標準のギャップ検出に最適。
  • ・独自Skillパックを公開するOSS開発者：Anthropic／Microsoft流の品質ゲート（waza check）をPRに自動付加できる。
  • ・複数LLMを比較検討中の組織：waza compareで「同じskillをClaude／GPT-4／Copilotに流した」スコアが揃う。
  • ・規制業界でAIエージェントを導入する企業：再現可能な評価エビデンスを監査向けに残せる（results.json＋transcript-dir）。

逆に1人プロジェクトでskillが3-4個程度の場合は、wazaの構造が重く感じられる可能性がある。最初はwaza checkだけ単体で使い、tasks／validatorは規模に応じて段階的に追加するのが現実的だ。

自動化全体の選定軸は AI自動化ツール完全ガイド2026 も参考になる。Wazaは「skill品質保証」という1レイヤーをDevOpsパイプラインに足す位置付けだ。

14. 既知の制約と今後のロードマップ

最後にWazaの現時点での制約を正直に整理する。導入前に把握しておくと運用設計を誤らない。

第一に、Pythonクライアントは廃止済みだ。v0.3.2が最後で、v0.4.0-alpha.1以降はGoバイナリ単体配布になっている。Python資産を持っている組織は移行コストを見積もる必要がある。

第二に、Goランタイムインストールがgo installでは動かない。LFS埋め込みCopilotバイナリが理由だが、Dockerfileから直接installしようとすると詰まる。バイナリインストールスクリプトを使うのが安全だ。

第三に、llm-judge（waza quality）はモデルコストが嵩む。CIで毎PR回すとコストが効いてくるため、夜間バッチや週次schedule実行が現実解になる。

第四に、executor pluginがcopilot-sdk中心で、他LLMプロバイダ向けpluginはコミュニティ実装が少ない。Claude API直叩きやBedrock経由は2026年5月時点では公式サポート外で、mock executor＋自作wrapperで対応している組織が多い。

ロードマップ面では、READMEに--templateフラグ（template pack）が「coming soon」として記載されている。skill scaffoldのテンプレート切り替え（FastAPI向け／React向け／データ分析向け等）が実装されれば、初期構築コストはさらに下がる見込みだ。

15. まとめ——Skill時代の「pytest」になり得るか

Microsoft Wazaは、Agent Skillsという新しい開発単位に対する評価の物差しを、OSS基盤として最初に整備したフレームワークだ。

eval.yaml＋validatorsの宣言的モデル、--baselineによるA/B、MCPサーバー連携、tokens commands、CI整合のmock executor——どれも「skillが増えた現場で実際に欲しいもの」を狙い撃ちしている。

Anthropic SkillsとAddy Osmani agent-skillsで「何を作るか」は標準化されつつある。残るは「どう測るか」だ。Wazaはこのレイヤーで先行しており、コミュニティの主流ツールに育つ可能性は十分ある。

Claude Codeを組織で運用するチーム、独自skillパックを公開するOSS開発者、複数LLMを横並び評価したい企業——これらにとってWazaは2026年中盤に検証する価値がある最有力候補だ。

公式リポジトリで最新リリースを追いつつ、まずはwaza initで5分試して肌感を掴むのが導入の最短ルートになる。

参照ソース