Agent Experience（AX）とは、AIエージェントの使いやすさをどう測るか

SDKやAPIを試すとき、最初の相手がAIエージェントになる開発者が増えています。エージェントが競合のサービスを選んだり、廃止済みのAPIを呼んだりすれば、ドキュメントが人間にとって読みやすくても、その技術は「壊れている」と見られます。

MicrosoftのPrincipal Developer AdvocateであるWaldek Mastykarz氏が、この問題を「Agent Experience（AX）」としてまとめた記事を公開しました。定義、計測の考え方、実測の結果を順に見て、Claude CodeやGitHub Copilotを使う側が何を持ち帰れるかを考えます。

AXの定義と由来#

用語の出どころは、NetlifyのMathias Biilmann氏が2025年1月に書いたIntroducing AXです。AXを「AIエージェントが製品やプラットフォームのユーザーとして得る、全体的な体験」と定義しています。ユーザー体験（UX）や開発者体験（DX）に続く概念として提唱されました。

Biilmann氏が挙げる問いは具体的です。

• エージェントがユーザーに代わってプラットフォームを操作する権限を簡単に得られるか
• エージェントが操作できる、整理されて説明のあるAPIがあるか
• LLMとエージェントが正しく使えるための、機械向けのドキュメントと文脈があるか

同じ記事はChatGPTのGPTストアに向けて作ったNetlifyの連携を実例にしています。ChatGPTからNetlify上に作られるサイトが、1日に1,000件を超えているという数字です。これは当時の同社の自己申告で、現在の数字ではありません。

Microsoftの記事は、この定義を受けて「AXを実践するとは、その体験を体系的に改善することで、計測は改善できたかを知る手段である」と整理しています。対象はエディタ内のコーディングエージェントに限らず、MCPサーバーを呼ぶChatGPTのようなものも含みます。

何を測るのか：選ばれるかと、正しく使えるか#

Microsoftの記事は、AXの測定を2つの問いにまとめています。

1. propensity（選ばれやすさ）: エージェントは、その技術を見つけて選ぶか。「アプリにメール送信を足して」のように、製品名を書かないタスクを与え、何を選ぶかを見る
2. efficacy（正しく使えるか）: 選んだあと、正しく使うか。製品名を書いたタスクを与え、現行のAPIを呼ぶか、廃止済みのAPIを呼ぶかを見る

どちらも、成果物の質と、かかったコストの両方を採点します。コストは見落とされやすい項目です。

別の記事で、同じ著者がClaude Sonnet 4.6とSonnet 5を、VS Code上のGitHub Copilot Chat（Windows）で比べています。Sonnet 5はトークン単価が全項目で33%低く、入力は100万トークンあたり3.00ドルから2.00ドル、出力は15.00ドルから10.00ドルです。それでも、SharePoint Framework（SPFx）のプロジェクトを更新する3シナリオ（各モデル15回）では、1回あたりのコストが0.55ドルから2.01ドルへと3.7倍になりました。トークンの消費量が10倍に増えたためです。

一方、設計を考えるタスク（12シナリオ、各モデル60回）では、Sonnet 5の平均コストは0.47ドルで、4.6の0.54ドルより12%安くなりました。方向はタスクによって変わります。この記事の結論は単価ではなく自分たちのタスクで測るべきだ、というものです。

品質も単純ではありません。設計タスクでは慣習に沿った出力かを見る指標（Idiomatic）で、Sonnet 4.6が90%、Sonnet 5が78%でした。SPFxの更新では逆に、指示どおりに進められたかを見る最初の関門を通過した実行の割合が、Sonnet 4.6は60%、Sonnet 5は100%でした。「新しくて安いから良い」とは言えない、というデータです。

手を入れられる場所と、入れられない場所#

AXのスタックを説明する記事では、開発者の指示がコードになるまでの層を、モデル、ハーネス（Copilot、Claude Codeなどエージェントのアプリ）、エージェント拡張、技術の表面（CLI、SDK、API）に分けています。

• モデル: 学習データは変えられない。古いドキュメントで学習していれば、廃止済みの書き方を出す。学習データの多い競合があれば、そちらに寄りやすい
• ハーネス: ベンダーの領域で、提供側からは見えにくい。同じMCPサーバーでも、ハーネスによって結果が変わりうる
• それより先: ドキュメント、スキル・MCPサーバー・指示ファイル・カスタムエージェントといった拡張、APIやSDK、CLI、エラーメッセージは、自分で変えられる

ドキュメントは拡張より先に直す対象です。学習済みのモデルは、ドキュメントを更新しても次のモデルが出るまで知りません。作業中にそれを読むエージェントは、次の実行から更新を反映します。インターフェースも同じで、記事は「バージョンを固定していないスキャフォールダーが2020年7月のバージョンでプロジェクトを作り、エージェントがそれを成功として受け取った」例を挙げています。エージェントは返ってきたものを信頼するため、結果が誤りを含んでいても、成功と報告します。

「エージェントに優しそう」な対策は、測るまで仮説#

Microsoftの記事が最も強調するのは、ベストプラクティスの一覧は出発点にすぎず、効くかどうかは測るまで分からないという点です。異なる実験で測った結果が、表にまとめられています。SPFxの更新で測ったものと、合成CLIで測ったものが混在しています。

対策	測った結果（実験の対象）
CLIの引数をJSON入力にする	通常の引数では、全モデルのプロファイルで5回とも正解。JSON入力にするとClaude Haiku 4.5は5回中2回だけが正解で、全モデルのコストが1タスクあたり4倍から11倍になった（合成CLIのpodctlによるマルチサービス配備）
ドキュメントに、正しいツールを案内する注記を足す	直接的な案内でも5回中1回しか使われなかったが、失敗するやり方を名指しした警告では5回中5回使われた（SPFxの更新）
別のドキュメント取得元（context7 MCPサーバー）を足す	目立った改善なし。5回中3回はツールが読み込まれず、残り2回は呼ばれなかった（SPFxの更新）
トークン単価の安いモデルに切り替える	前節のとおり、コストは3.7倍になった（SPFxのコード更新）

CLIの引数をJSON入力に変える提案は、「エージェントは構造化データを扱い慣れている」という筋の通った仮説に基づいています。計測した記事は合成CLIのpodctlを使い、30以上の値を持つ入れ子のマルチサービス配備を、通常の引数とJSONの両方で実行させました。結果は上の表のとおりで、書き換えたほうが悪くなっています。

SPFxの更新に効いた対策は、スキルの追加ではありませんでした。更新タスクで、エージェントは最初、80項目の設定チェックのうち30項目しか通せませんでした（Claude Sonnet 4.6、5回実行）。CLI for Microsoft 365を使うよう指示すると75項目に増えましたが、この方法はCLIを知っている人か、スキルを入れた人にしか効きません。エージェントの手順を見ると、作業中にSPFxのリリースノートを取得していたため、リリースノートに、手動での更新は失敗しやすいと警告する文を足し、移行ガイドも、変更点の説明とCLIへの案内に書き換えました。すると、プロンプトで指示しなくても毎回CLIが使われました。スキルを入れていない開発者にも効きます。

自分たちの環境で始める#

自社製品のドキュメントを持たない開発者にとっても、この考え方は使えます。リポジトリや社内のライブラリは、エージェントから見れば「技術の表面」だからです。ここからは記事の内容を、Claude CodeやGitHub Copilotを使う開発チームの立場に当てはめた私の解釈です。

Microsoftの記事が示す始め方は、次の5段階です。

1. 開発者が実際にエージェントへ頼む作業を、頼む言葉のまま数件書く。製品名を書かないもの（propensity）と書くもの（efficacy）を混ぜる
2. 拡張を入れない素の状態（bare baseline）で、同じ設定のまま数回ずつ走らせる。間違えた場所と、途中で読んだものを見る
3. 原因を直す。エージェントが既に使っているドキュメントとインターフェースから手を付け、新しい拡張は最後にする。拡張はインストールした開発者にしか効かないため
4. 同じ作業をもう一度走らせ、品質とタスクあたりのコストを比べ、改善（lift）か悪化・変化なし（drag）かを判断する
5. 結論は測ったエージェントの設定（OS、ハーネス、モデル、拡張）の範囲で扱う。設定が変わったら測り直す

既にスキルやMCPサーバーを配っているなら、2から始めて、あり・なしで比べればよいとされています。

指示ファイル（CLAUDE.mdやAGENTS.mdなど）を足す前に、エージェントが実際に何を読んでいるかを見る。この順番が、記事の実測が示す要点です。説明を足しても読まれなければ効かず、既に読まれているリリースノートと移行ガイドを直すと、追加の指示ファイルなしでCLIが選ばれた、という結果でした。

限界と読み方#

Microsoftの記事自身が、結果は測ったシナリオとエージェントの設定の範囲で成り立ち、ほかの環境では違うかもしれないと書いています。数字は主にSPFxという1つの技術と、WindowsのGitHub Copilot Chatでの実行で、1つの条件につき5回前後の小さな標本です。「JSON入力は悪い」という一般則として読むのは行き過ぎで、「測らずに入れると外れることがある」という例として読むのが妥当でしょう。

また、著者はMicrosoft製品のAXを評価する立場にあり、取り上げられているのは自社の技術です。社外の技術で同じ傾向が出るかは、この記事からは分かりません。

AXという言葉自体はまだ新しく、用語の集まり（bare baseline、lift・drag、propensity・efficacy）も、Microsoftのシリーズの中で使われているものです。業界で定着した定義ではない点は、頭に置いておくとよいでしょう。