プロトコルに熟達するのはやめよう。Agent Experienceに熟達しよう

2025年、もしあなたがMCP（Model Context Protocol）を使って構築していなければ、AIエージェントに真剣に取り組んでいないと思われたでしょう。MCPはその年の大半、エージェントに関する議論を支配しました。カンファレンス、ロードマップ、採用計画、すべてがMCPを中心に回っていました。

しかし、2025年末から2026年にかけてAI Skillsが登場すると、すぐに反発が起こりました。エンジニアたちはMCPは死んだと宣言し、Skillsを支持し、次いでCLIを支持しました。PerplexityのCTOは、同社がMCPの優先順位を下げていると公言しました。このサイクルは速く、騒々しく、予測可能でした。新しいツール、新しい熱狂、新しい書き直し。

私は2025年初頭から、MCPがまだ中心的な存在だった時期に、Agent Experience（AX）を提唱し始めました。反応はほとんど懐疑的でした。AXは考えすぎだ、MCPこそが唯一重要なレイヤーだと。その見解は時代遅れになりました。AXを否定した人々は、MCPが有用であるという点では間違っていませんでした。彼らが間違っていたのは、プロトコルを戦略とみなしたことです。

彼らが見落としていたこと、そして業界のほとんどがまだ見落としていると思うのは、プロトコルそのものに熟達することが重要なのではなく、その分野そのものに熟達することが重要だということです。

私たちは繰り返しツールの罠に陥る

私たちの業界には、ツールと戦略を混同するよく知られた習慣があります。マイクロサービス、Kubernetes、GraphQLでそうだったように、今はエージェントプロトコルで同じことをしています。

MCP、AI Skills、A2A、ACPはすべて実装です。それらは重要で、実際の問題を解決します。しかし、どれも戦略の基盤として構築すべきものではありません。それらは本質的に変化するものです。

特定のプロトコルを中心にエージェント戦略を整理すると、他人が管理し、市場がいつでも離れていく可能性のある基盤の上に構築することになります。さらに悪いことに、そのプロトコルがあなたのユースケースに適切かどうかを判断するステップを飛ばしていることになります。

これがツールの罠です。何を最適化すべきかを最初に理解することなく、特定の統合メカニズムの使用法を最適化してしまうのです。

では、Agent Experienceとは何か？

Agent Experience（AX）とは、AIエージェントがどのようにシステムを発見し、理解し、相互作用するかを研究し、それらの相互作用を体系的に改善する分野です。

これは、ユーザーエクスペリエンス（UX）のエージェント版と考えてください。UXが登場したのは、特定のUIフレームワークが勝利したからではなく、人間とソフトウェアの相互作用の質が、特定の技術を超えたデザイン問題であるとチームが認識したからです。ReactでもVanilla JavaScriptでも、ひどい体験を構築することは可能です。フレームワークは変数ではなく、デザイン思考が変数だったのです。

AXも同じです。エージェントはあなたのサービスが何をできるかをどのように発見するのか？APIの境界をどのように理解するのか？失敗したとき、回復するのに十分なコンテキストを得られるか？相互作用は効率的か、それともエージェントは不必要なラウンドトリップでトークンを浪費しているか？

これらの質問はプロトコルに依存しません。MCP、Skills、A2A、まだ発明されていないもののいずれで機能を公開する場合でも、これらは当てはまります。これらの質問に答えられるチームは、現在のツールチェーンだけでなく問題領域を理解しているため、次に何が来ても適応できます。

AXはあなたがすでに気にかけていることの延長

AXは、ユーザーエクスペリエンス、デベロッパーエクスペリエンス、カスタマーエクスペリエンスと競合するものではありません。これらすべての延長線上にあります。

あなたの第一の焦点は、依然として顧客に素晴らしい体験を提供することです。変わったのは、顧客があなたとやり取りする方法です。ますます多くの顧客がタスクをエージェントに委任しています。顧客がエージェントにあなたのAPIとの統合、プラットフォームへのデプロイ、サービスからのデータ取得を依頼するとき、そのエージェントは顧客に代わって行動しています。エージェントの体験が、顧客の目標を達成できる可能性を決定します。

顧客のエージェントが認証に苦労したり、エラーメッセージの解析にトークンを浪費したり、APIにコンテキストが不足しているために静かに失敗したりすると、苦情以上に悪いことが起こります。エージェントは、より良い体験を提供する代替サービスを静かに使い始めるでしょう。顧客は切り替えに気づかないかもしれません。あなたはサポートチケット1つなくして顧客を失うのです。

UXは人間がインターフェースをクリックする体験を最適化し、DXはあなたのプラットフォーム上で構築するデベロッパーの体験を最適化し、CXはカスタマージャーニー全体を考慮しました。AXはその思考を、顧客が代わりに送り込むエージェントに拡張します。

プロトコルのトレッドミルは機能しない

実際にMCPで何が起こったかを考えてみてください。チームはMCPサーバーの実装作成に多大な投資をしました。それらの実装の多くは平凡なものでした。MCPに欠陥があったからではなく、チームが自社システムからエージェントが実際に何を必要としているかを注意深く考えていなかったからです。2026年のクイーンズ大学の研究では、103のMCPサーバーにある856のツールを調査したところ、97.1%のツール記述に少なくとも1つの品質問題があり、56%は目的を明確に示していませんでした。プロトコルは問題なく機能していましたが、体験設計が問題だったのです。

Skillsが登場したとき、同じチームは新しい装いをまとったおなじみの問題に直面しました。彼らは依然として基本的な質問に答えていませんでした：エージェントは私たちのサービスで何を達成する必要があるのか？最小限の実行可能なインタラクションサーフェスは何か？エージェントが適切な判断を下すにはどのようなコンテキストが必要か？

これらの質問に取り組んでいたチームは迅速に適応しました。エージェント向けのインターフェースがどうあるべきかがわかっていれば、あるプロトコルから別のプロトコルへの移行は機械的な作業です。プロトコルはシリアライゼーションフォーマットであり、体験設計が難しい部分です。

このパターンは繰り返されます。ユニバーサル・コマース・プロトコル、A2A、あるいは次に登場するものなど、常に何か新しいものが注目を集めます。あなたの戦略が次々と現れるプロトコルの専門家になることなら、加速する一方のトレッドミルに乗るようなものです。

AXプラクティスの実際

では、Agent Experienceを真剣に受け止めるとは実際にはどういうことでしょうか？これまでにUXリサーチの実践やDXプログラムを構築したことがあれば、これは馴染み深いはずです。手順は新しいものではなく、ペルソナが異なるのです。

講演では、これを5つのステップに分解しています。

1. 顧客が使用するエージェントを監査する。 あなたの玄関口を何が通っているかを把握します。トラフィックデータとログを調べ、あなたのフットプリントのうち、エージェントと人間の割合、具体的にどのエージェントかを特定します。顧客はClaude Code、Cursor、あなたのAPI上に構築されたカスタムエージェントを使っていますか？観察したことのないもののためにデザインすることはできません。UXチームがユーザーリサーチを実施するのと同じ動機です。方法は異なりますが。

1. 顧客が委任したいユースケースを特定する。 すべてのインタラクションをエージェント向けに最適化する必要はありません。同じログデータを利用して、エージェントがプラットフォームに行うリクエストを調べ、それらが達成しようとしていたことを推測します。また、AEOデータを使用して、顧客がエージェント向け検索でどの領域について質問しているかを理解することもできます。まずは最も価値の高いサーフェスに焦点を当てます。デベロッパーが実際にAPIをどのように使っているかを見てDXロードマップの優先順位をつけたことがあれば、この感覚はすでに身についています。

1. それらのインタラクションの体験を検証し監査する。 エージェントがそれらのタスクをシステム上で完了しようとするときに何が起こるかを観察します。どこで行き詰まるか？どこでサービスの提供内容を誤解するか？これはユーザビリティテストです。ユーザーはLLMであり、困難はボタンの配置ではなくコンテキストですが、同じ質問に答えています：彼らは仕事を遂行できるか？

1. 改善し繰り返す。 エージェントの能力は進化し、モデルは賢くなり、新しいインタラクションパターンが出現します。Netlifyでは、製品が一方向に機能するが、エージェントは普遍的に別の方向に機能すると想定し、決して質問しないケースがありました。その想定と戦う代わりに、エージェントが期待する方法で製品が機能するように改善しました。その結果、エージェントフローの採用が増え、エラーが減少しました。これを生きた実践として扱うチームは、プロトコル移行を次々とこなすチームを凌駕するでしょう。

1. 検証を自動化し、後退を防ぐ。 「良い」状態のベースラインができたら、それを固定します。AXISのようなオープンソースのスコアリングフレームワークを使えば、実際のエージェントを実際のシナリオに対して実行し、比較可能なスコアを得ることができます。CIに組み込んで、壊れたテストをキャッチするのと同じようにAXの後退をキャッチします。これが、逸話的な改善から測定可能で再現可能なAX品質へと移行する方法です。

この実践が整えば、プロトコルの選択は明白になります。新しいツールをそのメリットに基づいて評価できます。それはあなたが観察した実際の摩擦点を解決するか？以前は達成できなかった能力を解放するか？それとも、すでにうまくやっていることの別のパッケージにすぎないか？

難しい部分はおなじみ

AXは新しいプロトコルを習得するよりも難しいのが現実です。MCPやSkillsを学ぶことは、境界のあるエンジニアリング問題です。ドキュメントを読み、コードを書き、統合を出荷する。明確な終点があり、進捗を示すのが簡単です。それは特に、あなたやチームが速く動いている場合、真に魅力的です。

AXの分野を構築することは、しばらくの間あいまいさと向き合うことを意味します。きれいな答えが出る前にエージェントの行動を研究する。適切な統合戦略は従えるチュートリアルではなく、発見すべきコンテキストに依存することを認める。しかし、UXやDXの実践をゼロから構築したことがあれば、ここは以前に通った道です。理由は同じ：ユーザーを理解し、摩擦を減らし、彼らが成功しやすくすること。方法が異なるのは、ユーザーが異なるからです。この分野自体は新しいものではなく、私たちの業界が何十年も行ってきた仕事の延長です。

良いニュースは、この考え方が勢いを増していることです。John Maedaの2026年 Design in Tech Reportは、UXからAXへの移行について明確に言及しています。研究者たちはエージェントのインタラクション品質を第一級のエンジニアリング問題として研究しています。BCGとMIT Sloanは、組織の35%がすでにエージェンティックAIを使用しており、さらに44%が計画中であることを明らかにしました。問題はもはやAXが重要かどうかではなく、あなたのチームが競合他社に先んじて実践を構築しているかどうかです。

2028年のエージェントは、2025年のエージェントと同じようにあなたのシステムと相互作用するわけではありません。プロトコルは異なり、能力は異なり、期待も異なります。変わらないのは、あなたのシステムがそれらを使用する人々、そして今やそれらの人々が代わりに送り込むエージェントに優れた体験を提供するという基本的な必要性です。

それに熟達しましょう。残りは実装の詳細です。