스크립트
00:00:00皆さん、こんにちは。「エージェンティック・ウェブ」と、
00:00:19Webをエージェント対応させる方法についてお話しします。昨日作った資料なので
00:00:26進化が非常に早い分野ゆえ、すでに古い情報もあるかもしれません。
00:00:32文脈の理解のために自己紹介をさせてください。私はMCP Appsという
00:00:38仕様の共同制作者兼メンテナーです。ChatGPT Appsや
00:00:45Claude Apps、Copilot、GitHubなどの基盤となる仕様です。目にするチャットアプリの
00:00:53多くがこの仕様に基づいています。また、AIと人間のインタラクションを研究する
00:00:58Auraの共同創業者の1人であり、Shopifyでエージェント型ストアフロントを構築・主導しました。
00:01:06そのためエージェンティック・ウェブというテーマは非常に身近なものです。馴染みのない方向けに解説すると、
00:01:12MCP Appsはエージェンティック・ウェブへの道を切り開いた仕様です。
00:01:18数ヶ月前に標準仕様として公開され、最初のクライアントであるClaudeをはじめ
00:01:25あらゆるクライアントが追随しました。チャットアプリで
00:01:32MCPサーバーから可視化や対話UIレイヤーを呼び出したことがあるなら、すでに利用しています。
00:01:39MCP Appsの優れた点は、関係者全員にメリットがあることです。プロバイダーが
00:01:48チャット内にUIを送信できれば、アプリはブランドアイデンティティを保てます。単なる
00:01:58データベースやテキスト情報に還元されずUIを維持できます。ユーザーは信頼感と
00:02:04親しみやすさを感じられます。ChatGPTにホテル予約を頼んだ際、Booking.comの表示が出れば
00:02:09誰とやり取りしているか明確で安心です。そしてホスト側（チャット側）は
00:02:16多様な機能へアクセスできるようになります。数ヶ月前、「なぜ
00:02:22OpenAIがイチから自作しないのか」と言われましたが、OpenAIが個別ホテルと提携交渉したり
00:02:29座席変更のサポート対応までするわけではありません。既存サービスが必要であり、
00:02:35MCP Appsはそのラストワンマイルを解決します。
00:02:41これらが享受できるメリットであり、MCP Appsは対話のラストワンマイルを解決しました。
00:02:51ラストワンマイルとはどういう意味でしょうか。エージェントやモデルが進化して
00:02:57自律性が高まっても、チェーンの最後には人間が存在します。
00:03:05ホテルの選択や3Dモデルの確認、会場での座席選択など、
00:03:12インタラクションの最終段階は人が行う必要があります。これは…失礼。
00:03:20ClaudeのMCP AppsのPR例です。チャット内にアプリを組み込むと、
00:03:28同じ文脈の中で統一されたUI体験が得られます。ご覧のように、
00:03:36同じスレッド内でBookingやAllTrailsなど、操作したいあらゆるサービスの
00:03:41データを取得できます。これはすでに現実となっており、Geminiを除く
00:03:49あらゆるチャットエージェントでサポートされています（Geminiも対応予定です）。
00:03:57興味深いのは、これが「エージェンティック・ウェブ」へ繋がっている点です。
00:04:05エージェンティック・ウェブとは何でしょうか。単に「エージェントのWeb」や現在のWebの延長ではなく、
00:04:11Webサイトやブラウザの概念における構造的なシフトです。
00:04:21私たちは20年もの間、従来のUXを洗練させてきました。
00:04:29何かを計画したりタスクをこなす際、ブラウザで複数のタブを開き、
00:04:36サービスごとに個別の入力を行わなければなりませんでした。
00:04:43記念日の計画だけでも、Google、Amazon、Bookingなど
00:04:51それぞれのUIの使い方を学び、同じ要望を入力する必要がありました。
00:04:58企業はこのフローを磨いてきましたが、もうその必要はありません。
00:05:04これらのインターフェースを最小単位（アトム）に分解できるからです。
00:05:12BookingやAirbnb、Jiraのダッシュボードの99%は不要ですが、
00:05:19意図だけは伝えたいわけです。ならばパーソナルアシスタントに任せればいいのでは？
00:05:27アシスタントが構成要素を組み立て、「記念日が近いですね」と
00:05:31Googleの情報を提示し、買い出しやホテルの手配を提案します。
00:05:36Claudeは私の好みを把握しているため、自然の中にあるホテルを好むと知っており、
00:05:43Bookingから適切なマップを表示します。自分で探す必要はありません。
00:05:49BookingやAmazon、Google側のメリットは、自社で連携層を開発せずに済む点です。
00:05:56Claudeが文脈を把握しているため、Bookingがカレンダー連携を作ったり
00:06:01AmazonがBooking連携を作ったりする必要がありません。
00:06:06三者にとって好都合です。私たちが目指すのはこの体験です。
00:06:13これは、各サービスにわざわざアクセスして
00:06:21テキストボックスと睨めっこするような現在のアプローチとは大きく異なります。
00:06:271年後、AmazonやEtsy、Expediaの各エージェントを回る人はいません。
00:06:34各社のエージェントではなく、自分のパーソナルアシスタントを使いたいからです。
00:06:41つまり「唯一の一次情報源としてのWebサイト」という存在は
00:06:49姿を消していくことになります。タブを開いてサイト側の提示する情報を
00:06:55わざわざ閲覧する必要性が薄れるからです。
00:06:59これに対し「ブラウザエージェントやComputer Use機能がある」という反論もあります。
00:07:04賢いアシスタントが代わりにWebを回ってくれるという考えですが、あまり合理的ではありません。
00:07:10それは「より速い馬」を求めるような発想です。人間の認知限界に合わせて
00:07:17設計されたフィルターやページネーション、並べ替えといったUIを、
00:07:24認知の制約がないエージェントにわざわざ操作させる意味はないからです。
00:07:33Googleは真逆の「共同ブラウジング」に賭けており、
00:07:37「WebMCP」というプロトコルを掲げています。スクショで状況を判断するのではなく、
00:07:44Webサイト側にJavaScriptツールを公開させ、エージェントに操作させる仕組みです。
00:07:49Chrome上のGeminiが閲覧中に買い物やお得な情報の検索を
00:07:55代行する例ですが、非常にシンプルなユースケースにとどまります。
00:08:02Salesforceの画面をChromeのGeminiで操作したいでしょうか？
00:08:09使いたくもないダッシュボードのボタンを代わりに押してもらうためだけに
00:08:15アクセスしたいとは思いません。私たちが求めているのはそれではありません。
00:08:24アシスタントこそがWebへの入り口になりつつあります。主要AIラボは
00:08:31自社アプリを万能アプリにしようとしており、すでに変化は始まっています。
00:08:39JiraのMCPを開発環境に接続している知人は、もうJiraのサイトを開きません。
00:08:44私の母もすべてChatGPTで済ませており、病院予約ができるなら
00:08:49クリニックのサイトなど見ないでしょう。個人アシスタント経由のほうが遥かに楽なため、
00:08:54見られなくなるWebサイトが大量に出てきます。Webサイトやブラウザは
00:08:59時代遅れになり、アシスタントが唯一のゲートウェイになります。
00:09:04大げさに聞こえるかもしれませんが、完全に消滅するわけではなくとも
00:09:11若い世代ではすでに顕著です。9歳の息子は検索の際にGoogleではなく
00:09:17ChatGPTを使います。東欧のジョージアを旅した際、
00:09:2470代の女性に写真を頼まれスマホを受け取ると、画面にあったアプリは
00:09:28WhatsApp、カメラ、ChatGPTの3つだけでした。シフトは起きています。
00:09:36SentryのDavid Cramerのような非常に聡明な人物でさえ、1年前は
00:09:44「25年以内にWebサイトが廃れるという主張には賭けない」と言っていました。
00:09:49しかし数日前、彼が公開した「Designing for Agents」では、
00:09:54「Sentry製品の利用はWebアプリ経由にとどまらなくなる。APIファーストで
00:10:00設計すべきだ」と述べています。あらゆるサービスがヘッドレス化しており、
00:10:06競合との差別化要因がUXにあったSalesforceのヘッドレス化は象徴的です。
00:10:12CloudflareやSentryも同様の道を歩んでいます。
00:10:17CloudflareのCEOは「Webにおけるエージェントのトラフィックが人間を超えた」と投稿しました。
00:10:25エージェントが自律的であれば最後のUIレイヤーは不要です。
00:10:30「メールを整理して」と指示し、完了報告を受け取るだけで済みます。
00:10:35しかし新婚旅行のホテル予約などの場合は、最後のインタラクションが必要になります。
00:10:40これを私たちは「ニアリー・ヘッドレス・ウェブ」と呼んでいます。
00:10:47エージェントが裏で処理しつつ、必要なUIリソースだけを人間に持ち返してくれます。
00:10:55従来のユーザー体験（UX）は、エージェント側の体験と、
00:11:02そのエージェントを介したユーザー体験の2つに分裂しています。
00:11:09そして9割はエージェント体験に依存するため、Webサイトはエージェント対応が必須となります。
00:11:16自社エージェントはもちろん、顧客のChatGPTや
00:11:21OpenClaw、そしてエージェントを使わずに直接アクセスしてくる
00:11:28エージェントを使わずに Booking.com を閲覧したい人間の顧客にも対応する必要があります
00:11:33つまり エージェント対応が必須なのです そして「エージェント対応」には様々な意味があることが分かってきました
00:11:39AEO、SEO、GEO など 見つけてもらう方法についてはよく耳にします しかし 発見されるのは最初のステップに過ぎません
00:11:47エージェントが自社を認識しても あなたが何者で どうやり取りし どう認証し
00:11:51どうやってヘッドレスで決済するかを知る必要があるからです 実際 これは余談ですが
00:11:56自社製品のアナリティクスを構築する際 Claude Code に最適な分析サービスを尋ねました
00:12:02すると PostHog というサービスを勧められました そこで「Mixpanel の方がいい」と答えました
00:12:0710年間使っていて扱い慣れているからです しかし Claude Code は PostHog を強く主張しました
00:12:11PostHog の方が MCP や API が優れていて 連携しやすいからだと言うのです そこで
00:12:17ブランドへのこだわりを捨て Claude Code が勧める PostHog を採用しました しかし
00:12:21Mixpanel のことを考えると深く考えさせられます Mixpanel は10年かけて UX や開発者体験を洗練させてきたのに
00:12:26Claude Code が PostHog を好むという理由だけで離れてしまったのです こうしたことは常に起こります 例えば Hermes も
00:12:31製品を使用するためにブラウザを立ち上げる必要があると それを記憶し
00:12:35次回からはその製品を使わなくなるでしょう そこで エージェント型 Web 研究ラボである Aura で
00:12:43調査を開始しました 資金を調達し
00:12:49Web がエージェント対応するとはどういうことかの研究を始めました 非常に興味深い対応度ベンチマークを用意しています
00:12:57Aura.ai にアクセスすれば 無料で任意の Web サイトを実行できます 多くのプロトコルとベストプラクティスに基づく
00:13:02スコアとベンチマークが得られ エージェントからのフィードバックも確認できます
00:13:09Web サイトに関するフィードバックが実際に返ってくるのです また このベンチマークによる企業や製品の
00:13:16ランキングを示すリーダーボードも作成しました そうして Web のマッピングを開始し 順調に進んでいました
00:13:24しかし 1つの洞察 予期せぬ結果に行き当たりました ここで LMS.txt について聞いたことがある人はいますか？
00:13:36LMS.txtは、エージェント対応のデファクト標準のようなものです。「WebサイトがLMS.txtを公開していれば、
00:13:42エージェントが相互作用する方法を理解できる」ということです。auth.mdやpricing.md、X402など多くの標準が存在します。そして、テストしたWebサイトの約50%が
00:13:52LMS.txtを公開していることが分かりました。しかし、それらのサイトで実行したエージェントの誰一人として、実際にLMS.txtを使用していませんでした。
00:14:02実際、ほぼすべてのエージェントがドキュメントページやホームページへ直行しました。LMS.txtを使用した40%のエージェントも、ドキュメントで
00:14:12使用すべきLMS.txtというファイルの存在が指摘されていたから使っただけでした。そこでハッと気づいたのです。
00:14:19人間である私たちが、エージェントに必要なものを定義するのはあまり意味がないということです。もう誰もそんなことはしていません。
00:14:26OpenAIでさえ、ツールのベストプラクティスを公開しなくなりました。なぜなら、彼らがベストプラクティスを公開するたびに
00:14:31モデルが進化し、それらの手法が時代遅れになるからです。半年ほど前、
00:14:36MCPサーバーのベストプラクティスは、エージェントが扱い方を理解できるように3パラグラフの簡単な説明を記述することでした。
00:14:41しかし今では3行で十分です。つまりベストプラクティスはすぐに陳腐化するのです。エージェント自身に
00:14:47必要なものを定義してもらう必要があります。Webサイトに対するエージェントのフィードバックが必要です。そこで作られたのがAura's Journeyです。
00:14:54Aura's Journeyはとても素晴らしいツールで、これも無料です。journey.aura.aiにアクセスすれば、
00:15:00任意のWebサイトにおいて、任意のインテントを持ったエージェントがサイトと対話しようとする際の行動ルートを確認できます。
00:15:08例えばatia.comでCloud Codeを選択してWebサイト上で実行します。するとリアルタイムで
00:15:17エージェントがどのように移動し、Webサイト内で何を探そうとしているのかが確認できます。私たちはこれを数万回も
00:15:25実行し、エージェントがWebサイトと連携しようとする際に何を求めているかを徹底的に調査しました。
00:15:30面白いのは、1つのハーネスを実行するだけでなく、複数のハーネスを同時に実行できる点です。
00:15:39ここにはCloud Codeと、VercelのハーネスであるEve、そしてChatGPTが同じWebサイトで同じインテントを実行しています。
00:15:45こちらがCloud Code、これがHaiku、そしてこちらがEveです。エージェントのジャーニー（行動経路）がどれほど異なっているか分かります。
00:15:52そしてこれがChatGPTです。ChatGPTはより的確に結果を見つけることができました。Webサイト上のジャーニーをそのまま確認できるのです。
00:16:01そして私たちは、なぜそうなるのかを理解する必要があります。なぜWebサイトがauth.mdファイルを公開しているのに、エージェントはそれを見ようとしないのか、
00:16:08Webサイトがauth.mdファイルを公開しても、エージェントはそれを探さず、何を探しているのか。
00:16:13Auraでは、ビジネスに関するあらゆる質問に対応しており、どのドメインでもビジネス上の目標や問いが存在します。
00:16:21そして、エージェントが辿る経路を確認できます。興味深いのは、
00:16:28エージェントがWebサイトとどうやり取りするかが分かった今、エージェンティックWebにおける次の大きな節目は何でしょうか？
00:16:33前のセッションを聞いた方ならお分かりかと思いますが、
00:16:40それは「ディスカバリー（発見）」です。しかし従来のSEOやGEO、AEOとは異なります。
00:16:45すべての技術革新には、常に独自のディスカバリー層が伴ってきたことを思い出す必要があります。
00:16:52Web革命には検索があり、モバイルにはアプリストア、ソーシャルにはフィードがありました。
00:16:59では、エージェント向けリソースのディスカバリー層とは？ MCPや
00:17:03OpenAPI.jsonのディスカバリー層とは何か？ 私たちは一体何を探しているのでしょうか。例えばAirbnbの方がBooking.comより優れたMCPを持っているかもしれません。
00:17:09しかし、Booking.comの方が優れたAPIを持っている場合、どう選択すべきでしょうか？
00:17:16従来のWeb検索だけでは不十分です。人間向けの
00:17:22SEOやページランクに基づいているため、柔軟性が足りません。エージェントやチャットごとのカスタムレジストリも
00:17:29不十分です。閉鎖的であり、すべてのアプリがそれらのレジストリに登録申請する必要があるからです。
00:17:36また、MCPレジストリのような中央集権型レジストリも不十分です。キュレーションは誰が行うのか、
00:17:42ガバナンスモデルはどうするのか、どのリソースを登録するかをどう決定するのかという問題が生じます。
00:17:48現在、これに関する新たな標準が登場しつつあります。Anthropic、OpenAI、
00:17:53Google、MCP、A2Aによる規格「AI Catalog.json」は、Webサイトがエージェントに自らを露出する方法を標準化しています。
00:18:00また、これらすべての企業などが推進する「エージェンティック・リソース・ディスカバリー標準」は、
00:18:05ディスカバリー層やディレクトリがエージェントへ情報を開示する方法を標準化するものです。そこで私たちは独自のディレクトリを構築しました。
00:18:14私たちはエージェンティックWebの研究ラボですから、これを作成したのです。この
00:18:18ディレクトリには、スキャンしたすべてのドメインを集約し、
00:18:24エージェントが実際にクエリを実行できるように配置しています。AI Catalog.jsonファイルも公開しているため、
00:18:31例えば monday.com の場合、エージェントに対して
00:18:38「これが monday のMCPサーバーであり、APIサーバーです」と伝えるJSONファイルを生成します。
00:18:42エージェントはそれをクエリするだけで済みます。つまり、どのドメインでも
00:18:47AI Catalog.json にアクセス可能です。さらにディレクトリ自体のレジストリも公開しており、
00:18:55ディレクトリ上の各エントリ（例えば Vercel）について、「これがエージェンティックリソースであり、
00:19:02アクセス方法はこうです」とエージェントに提示できます。当然ながらこのディレクトリは fully ARD（エージェンティック・リソース・ディスカバリー）に
00:19:08準拠しているため、あらゆるエージェントが任意のクエリで検索できます。
00:19:13ご興味があれば Aura.directory をご覧ください。これらはすべて Aura マルチバース（Journey、Directory、Ranker）の一部です。
00:19:21また、非常に興味深い知見も得られました。例えば、
00:19:26エージェント対応であることと、人間のアクセシビリティに対応していることは非常に似ています。LLMがWebサイトに
00:19:33アクセスする際、視覚障害を持つユーザーと似た状態になります。画面を直接見るわけではなく、
00:19:39サイト構造を理解するための他のシグナルを必要とするからです。Webサイトを人間向けにアクセシブルにすることは、
00:19:44エージェントのアクセシビリティ向上にもつながり、その逆も然りです。まとめると、これらはMCPアプリであり、私がここ数ヶ月
00:19:51取り組んできた成果です。これはエージェンティックWebにおける最後のパズルでした。これにより
00:19:57エージェンティックWebが実現し、エージェントがWeb上を巡回し始めています。彼らには異なる道路やインフラなど
00:20:03異なるものが必要ですが、エージェントのためにWebを一から再構築したいわけではありません。私たちが目指すのは
00:20:09Webをエージェント対応にすることです。エージェントの到来に備えてWeb環境を整えていきましょう。
00:20:18ご清聴ありがとうございました。
00:20:39ありがとうございました。
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기