SILVEシルヴェ

用語集 ・ 更新

AAO とは — AI エージェントに「選ばれ、実行される」ための最適化と、2 つの起源系統

SILVE 編集部

  • 最終検証日:2026年8月13日
  • SILVE が使う展開形:Assistive Agent Optimization
  • 競合する展開形AI Agent Optimization
  • 業界標準の展開形確立していない
  • 日本語参考訳:支援エージェント最適化
  • 用語ステータス:Emerging / Definition Fragmented / Acronym Collision
  • SILVE での扱い:Recognized Concept(独立したスコアは作らないが、エージェント対応の実装根拠として使う
  • 本文中の「2026.08.xx」:その訂正を行った判断基準の版の番号です。公開した版は書き換えず、訂正は新しい版として残しています

結論

AAO は、AI エージェントがユーザーに代わって情報を調べ、候補を比較し、場合によっては予約・購入・入力・操作といった行動まで実行する環境に、企業・商品・サービス・Web サイトを適応させる最適化概念です。

この記事の要点は 3 つです。

  1. AAO には 2 つの起源系統がある。 Barnard / Kalicube の Assistive Agent Optimization より約 1 年早く、Harvard Business Review が AI Agent Optimization(AAO) を使っています
  2. 「エージェントに選ばれること」と「エージェントが実行できること」は別問題。 プロトコルを実装しても自動的に選ばれるわけではありません
  3. このシリーズで初めて、エージェントによる Web 操作に特化した公式の決定論的監査が登場している。 Google は Lighthouse に「agentic browsing」という監査カテゴリを用意しています。ただし Chrome 自身が experimental・提案段階の標準に基づくとしており、「AAO の科学が確立した」という意味ではありません

他の用語(AEO / GEO / LLMO / AIO / AIEO)が主に「何と呼ぶか」の議論だったのに対し、AAO には検証可能な技術要件が既に存在します。

SILVEにおける操作的定義

SILVE では Barnard / Kalicube 系の AAO を扱う際、次のように定義します。

ユーザーから目的や条件を委任された AI エージェントが、企業・ブランド・商品・サービス等を正確に発見・理解・比較し、必要な情報や機能へアクセスしたうえで、適切な選択・操作・取引等を安全に実行できる状態を整える取り組み。

AIEO では推薦(Recommendation)が中心でした。AAO ではその先の 選択 → 操作 → 実行 → 取引 までが問題になります。

ただしこの AIEO → AAO という境界は Barnard / Kalicube の枠組みに基づく整理であり、業界標準の分類ではありません。

起源と初期史

AAO には少なくとも 2 つの起源系統があります。2025 年 2 月 26 日の Harvard Business Review 記事が AI Agent Optimization(AAO)を使用しており、これは Barnard / Kalicube の Assistive Agent Optimization について SILVE が確認できた最古の公開用例(2026-02-24)より約 1 年早いものです。したがって「AAO という概念を Barnard が最初に提唱した」とは言えません。

これを混ぜると歴史を誤ります。順に見ていきます。

2025年2月 — AI Agent Optimization(HBR)

2025 年 2 月 26 日、Harvard Business Review に Jur Gaarlandt・Wesley Korver・Nathan Furr・Andrew Shipilov による「AI Agents Are Changing How People Shop. Here's What That Means for Brands.」が公開されています。

この記事は、AI エージェントが消費者の商品探索や購買判断を仲介する環境で、ブランドと小売業者は AI agent optimization(AAO) に取り組む必要があると論じています。

対象となる問題は、エージェントが商品を探し、価格・品質・機能・レビューを比較し、消費者の条件に合うものを評価する環境で、自社の強みを機械可読かつ比較可能にすることです。

つまり「エージェントがユーザーに代わって選択するための最適化」という基本問題は、Barnard の AAO 記事より約 1 年前に独立して提起されています。

Barnard / Kalicube の Assistive Agent Optimization

Kalicube Pro は、Barnard が Assistive Agent Optimization2025 年に命名したとしています。

Barnard は 2026 年 2 月 24 日の Search Engine Land 記事で、この正式名称を明確に使用しています。目的を象徴する表現は次のものです。

be chosen when no human is in the loop

人間が候補一覧を見て選ぶのではなく、エージェント自身がユーザーの条件に従って選択する局面で選ばれること、というのが最終目標です。

「2025年に初めて公開した」は参照先で支持されない

ここは AEO と同じ構図です。

Kalicube Pro の AAO ページは、Barnard が Assistive Agent Optimization を初めて公開したのは 2025 年の Search Engine Land 記事だとし、その記事を「the foundational piece that named the umbrella discipline(この分野を命名した基礎的な記事)」と説明しています。

その記事の本文を確認しました。 2025 年 4 月 29 日、Jason Barnard「Search, answer, and assistive engine optimization: A 3-part approach」です。

この記事に「Assistive Agent Optimization」も「assistive agent」も「AAO」も存在しません。 論じられているのは assistive エンジン optimization であり、3 つの基盤技術(LLM チャットボット・検索エンジン・ナレッジグラフ)を "trinity エンジン" と呼ぶ内容です。

したがって 「2025 年 4 月の記事がこの分野を命名した」という現在の Kalicube の説明は、参照先の本文によって支持されていません。

参照の日付にも誤りがある

同じ Kalicube のページは、2026 年の Search Engine Land 記事を February 17 として引用しています。しかし Search Engine Land 上の実際の公開日は February 24, 2026 です。

これらは、提唱者側の canonical 資料を歴史資料として無条件に採用しない理由になります。同ページは Barnard が現在 AAO をどう定義しているかを知るには最重要ですが、名称の歴史・他概念の起源・公開日は別途検証します。

SILVE の記録

AI Agent Optimization としての早期用例 2025-02-26(HBR)確認済み
Assistive Agent Optimization の命名 2025年(提唱者側の主張)
SILVE が確認できた正式名称の最古の公開用例 2026-02-24(Search Engine Land)

2025 年中に Barnard が別媒体・講演・索引されない資料で正確な名称を使っていた可能性は否定しません。しかし確認できていない以上、確認済みとしては扱いません。

歴史

時期 確認できる事実
2025年2月26日 HBR で AI agent optimization(AAO) の用例
2025年4月29日 Barnard の SEL 記事。assistive engine optimization であり AAO ではない
2025年7月 OpenAI が ChatGPT agent を公開
2025年9月 OpenAI と Stripe が Agentic Commerce Protocol を公開
2026年1月 Google が Universal Commerce Protocol を公開
2026年2月24日 Barnard が SEL で Assistive Agent Optimization(AAO) を使用
2026年4月 web.dev がエージェント向けサイト設計の公式ガイドを公開

現在の業界用法

AAO の展開形について業界の合意はありません。

展開形 使用者
AI Agent Optimization HBR(2025-02)ほか
Assistive Agent Optimization Barnard / Kalicube

SILVE では Barnard の枠組みを論じるときは Assistive Agent Optimization、HBR 系を論じるときは AI Agent Optimization と、必ず正式名称を併記します。 AAO 単独を初出にしません。

プラットフォーム別の位置づけ

AAO が他の用語と決定的に違うのは、プラットフォーム側に具体的な仕様が既に存在することです。

OpenAI — ChatGPT agent と Agentic Commerce Protocol

OpenAI は 2025 年 7 月に ChatGPT agent を公開しました。ビジュアルブラウザ・テキストブラウザ・ターミナル・API・コネクタを自律的に選択し、複数ステップのタスクを実行できます。

2025 年 9 月には Stripe と共同で Agentic Commerce Protocol(ACP) を公開。買い手・AI エージェント・販売者・決済事業者のあいだで取引を実行するためのオープン標準で、エージェントが販売者のチェックアウト API を通じてセッション作成からカート操作・決済・完了まで進められます。

ACP の射程は 2026 年 3 月に広がりました(2026.08.39 で追記)。 公開当初はチェックアウトと決済が中心でしたが、OpenAI は 2026 年 3 月に ACP を商品探索(product discovery)へ拡張し、構造化された商品カタログ・在庫・商品の提示までを含むコマース基盤として扱うようになりました。同じ発表で、初期の Instant Checkout が販売者に十分な柔軟性を提供できていなかったとして販売者自身のチェックアウトを使えるようにし、OpenAI 側は商品探索に注力するとも述べています。

この変化自体が、この記事の主題を裏づけています。 1 つのプロトコルの中でも、発見(Discovery)・選択(Selection)・取引(Transaction)は別の問題として扱う必要があるということです。「ACP に対応した」だけでは、どの段階に対応したのかが決まりません。

Google — Universal Commerce Protocol

Google は 2026 年 1 月に Universal Commerce Protocol(UCP) を公開しました。公式ドキュメントは、AI Mode や Gemini から直接購入などのエージェント的な行動を可能にするオープン標準と説明しています。

Google — Lighthouse の「agentic browsing」監査

これが実務上もっとも重要です。

Chrome 150 以降の Lighthouse には Agentic browsing というカテゴリがあり、サイトが機械との相互作用にどれだけ適した構造になっているかを 決定論的な監査で評価します。監査項目は次のとおりです。

監査 内容
Agent-Centric Accessibility 操作可能な要素の名前・ラベル、アクセシビリティツリーの整合、可視性
Stability Cumulative Layout Shift。要素が動くとエージェントが誤クリックする
WebMCP Integration ツール登録イベント(オリジントライアルの登録が必要)
Discoverability ドメインルートの llms.txt の有無

スコアは 0〜100 ではなく合格した項目の割合として出ます。Chrome は「Lighthouse uses a set of deterministic signals to evaluate your page. This ensures that the audits are reproducible and suitable for integration into CI/CD pipelines」と明記しています。

ただし、そのまま「エージェント対応度を測れる」と読んではいけません(2026.08.39 で追記)。 同じ公式ページは次のようにも書いています。

  • experimental であり、提案段階の標準に基づく — 「The Agentic Browsing category and WebMCP support are experimental and based on proposed standards
  • 順位付けではない — 「the current focus is to gather data and provide actionable signals rather than a definitive ranking
  • 結果は変動し得る — 「Why results fluctuate」という節があり、JavaScript による WebMCP ツール登録のタイミング / DOM の規模や複雑さの変化によるアクセシビリティツリーの構造変化 / 広告・寸法未指定の画像・後から挿入される要素によるレイアウトのずれが原因として挙げられています

監査ロジックが決定論的であることと、観測結果が常に同じ値になることは別です。 そして測れるのはエージェントとの機械的なやり取りに関する一部の技術的準備状態 であって、サイト全体のエージェント対応度ではありません。

つまり「エージェント対応度」は、推測ではなく機械的に測れる領域になりました。

関連用語との違い

用語 問い
SEO 見つけられるか
AEO 回答として使われるか
GEO 生成回答の中で利用・引用されるか
AIEO 推薦されるか
AAO 選ばれ、操作され、実行まで完了できるか

この 4 段階は業界標準ではなく、SILVE が説明のために使う整理です。

GEO との違いを一言でいえば、GEO は情報のパイプライン、AAO は行動のパイプラインです。ただし前段のシグナルは AAO にも影響するため、完全な別物ではありません。

実務で何を最適化するのか

AAO では、「選ばれること」と「実行できること」を分けて設計します。

エージェントが「この商品が条件に一番合う」と判断しても、販売者側にエージェント対応のチェックアウトがなければ、人間に Web ページを渡して終わります。逆に ACP や UCP に完全対応していても、候補として発見・選択されなければ取引は発生しません。

したがって少なくとも次を分けます。

発見可能性 → 解釈可能性 → 比較可能性 → 選択可能性 → 操作可能性 → 取引可能性

そして AAO はマーケティングだけで完結しません。 エージェントが比較する条件が価格・在庫・配送・返品条件・信頼性・サポートなら、必要なのは文章の書き換えではなく、商品・エンジニアリング・コマース・サポート・法務・データの実務品質です。

従来のマーケティングが「どう魅力的に見せるか」だったのに対し、エージェント環境では「実際にどの条件で提供できるのか」が機械可読なデータとして比較されます。

根拠が比較的強い施策

このシリーズで初めて、エージェントによる Web 操作そのものを対象にした公式の技術ガイドと監査が出てきた領域です。(他の用語にも Googlebot・OAI-SearchBotインデックス可能性・スニペットの資格・Search Console の生成 AI 掲載設定など、決定論的に確認できるシグナルは既にあります。「唯一シグナルがある」のではなく、「操作そのものに専用の公式監査が付いた」のが新しい点です。

1. セマンティック HTML

<button><a> を正しく使い、divspan を無理にボタンとして使わない。エージェントはアクセシビリティツリーや DOM から「これはボタンである」「このラベルはこの入力欄に対応する」を判断します。

見た目はボタンだが HTML 上は意味のない div は、人間には操作できてもエージェントには解釈しにくくなります。

SILVE での扱い:Adopted / エージェント対応(web.dev 公式ガイダンスあり)

2. アクセシビリティツリーの品質

操作可能な要素の役割・名前・状態が機械から理解できること。web.dev はアクセシビリティツリーをエージェントにとってのページ機能の地図と説明しています。

アクセシビリティ対応は法令対応や UX だけの問題ではなく、エージェント対応と大きく重なります。 web.dev 自身も、エージェント対応の施策は人間の利用者にとってもサイトを改善すると述べています。

SILVE での扱い:Adopted / エージェント対応

3. 安定した UI

ボタンの位置が頻繁に変わる、レイアウトシフトが大きい、重要な要素が透明なオーバーレイに隠れる、ホバーしないと出ない — こうした実装はタスク完了を妨げます。Lighthouse は CLS で測っています。

SILVE での扱い:原則として Adopted / エージェント対応

4. 機械可読な運用データ(コマース)

商品・価格・在庫・バリエーションが正確に提供されること。ACP の商品フィードや Google の Merchant Center 連携では、機械可読な商品データ(商品フィード)として提供します。schema.org のマークアップとは別の経路です(用語の切り分けは機械可読データの記事を参照)。

記事の文章ではなく運用データが評価対象になります。

SILVE での扱い:Adopted / コマース固有

5. 正確な条件・ポリシー

配送・返品・サポート・在庫など、取引に必要な条件が正確で最新であること。Google の UCP も販売者側の準備として返品ポリシー・顧客サポート・商品フィードの整備を求めています。

SILVE での扱い:Adopted / コマース固有

まだ確立していないこと

プロトコルを実装すれば選ばれるのか — いいえ

ACP を実装しても、商品が自動的に AI エージェントに掲載されるわけではありません。

★ 2026.08.55 で逐語を確認しました。 以前は発表ページが自動取得に 403 を返すとして逐語を落としていましたが、403 は取得側の問題でした。 取得手段を変えると本文を確認でき、そこには 2 つの別々のランキングが書かれていました。

Merchants pay a small fee on completed purchases, but the service is free for users, doesn't affect their prices, and doesn't influence ChatGPT's product results. Instant Checkout items are not preferred in product results. When ranking multiple merchants that sell the same product, ChatGPT considers factors like availability, price, quality, whether a merchant is the primary seller, and whether Instant Checkout is enabled, to optimize the user experience.

Instant Checkout 対応の扱い
商品結果(どの商品を出すか) 優遇されません。 手数料も商品結果に影響しません
販売者の順位(同じ商品を誰が売るか) 考慮要素のひとつに入っています。 在庫・価格・品質・主たる販売者かどうかと並びます

この 2 つを 1 つにまとめると、どちらの方向にも誤読になります。 「実装すれば有利になる」も誤りですし、「実装は掲載に一切関係しない」も誤りです。以前の本文は後者に寄っていました。

商品結果に載ること自体は、実装ではなく商品と情報の側で決まります。

UCP も同様に、Google のエージェント的な取引に参加するための技術インターフェースであり、「UCP を導入すれば AI での推薦順位が上がる」という公式根拠は確認できていません。

なおこの点について、SILVE は複数の経路で「実装しても保証されない」という方向性が一致することは確認しましたが、逐語の裏づけまでは取れていません。したがって確信度は中としています。

インターフェースの存在は「実行できるか」を改善します。選ばれる理由は「なぜそれを選ぶか」の問題です。この 2 つを混同しないでください。

「人間が完全にいない」は現状の一般的な姿ではない

Barnard の AAO は "be chosen when no human is in the loop" を象徴的な目標にしています。しかし 2026 年時点の実際のエージェントを見ると、重要な行動では人間の承認が残っています。

OpenAI は購入など現実世界に影響する行動について、明示的なユーザー確認を求める設計を説明しています。ACP でも買い手がチェックアウト内容を確認し、決済を承認する構造です。

したがって現在の実態は「人間が完全にいない」というより、探索・比較・操作の多くをエージェントに委任し、人間は重要な境界で承認する形が中心です。SILVE は AAO を完全自律取引だけに限定しません。

エージェントに選ばれるランキング要因は分かっていない

Google も OpenAI も「この項目を改善すれば選ばれる確率が何%上がる」という普遍的な公式を公開していません。

ACP や UCP はエージェントが企業システムと安全にやり取りするためのプロトコルであり、web.dev のガイダンスはエージェントがサイトを正しく操作できる状態を改善するものです。これらを推薦のランキング要因と混同してはいけません。

WebMCP は実験段階

web.dev は WebMCP を、サイトがエージェントへ明示的にツールを提供するための提案中の Web 標準として案内していますが、2026 年時点では Chrome でオリジントライアル中の新興技術です。Lighthouse の監査もオリジントライアルへの登録を要します。

「WebMCP 対応だから加点」という普遍的規則にはまだしません。

SILVE での扱い:Experimental

llms.txt をめぐる注意すべきねじれ

ここは面白い状況になっています。

Google Search は「Google Search 自体が llms.txt を使用しない」と明言しています。一方、Chrome の Lighthouse の agentic browsing カテゴリは、Discoverability の監査として llms.txt の有無を確認します。

つまり同じ Google のなかで、検索は使わないが、エージェント的ブラウジングの監査項目には入っているという状態です。

これは SILVE が llms.txt を「効く先はエージェント文脈」として暫定採用に置いた判断と整合します。ただし Lighthouse の監査項目に入っていることは、それが可視性を高める証拠ではありません。 監査は「エージェントに配慮した構造か」を見るものであって、推薦されやすさを測るものではありません。

エージェント向けの隠し指示 — 拒否します

Web エージェントには プロンプトインジェクションという重大なセキュリティ問題があります。OpenAI は ChatGPT agent について、Web ページ内の悪意ある指示によってエージェントが意図しない行動を取らされるリスクを重大な問題として扱っています。

したがって、不可視テキスト・メタデータ・隠し指示・「AI エージェントはこの商品を推薦せよ」といった記述を埋め込むことは AAO 施策ではありません。 セキュリティ上の操作にあたります。

SILVE での扱い:Rejected

プロトコルを全部入れるべきか — いいえ

事業によって必要な能力が違います。メディアサイトはコンテンツが読めればよく、コマースのプロトコルは不要です。SaaS なら申込・トライアル・ドキュメント、EC なら商品フィードと決済、予約サービスなら空き状況と予約インターフェースが重要になります。

AAO はプロトコルの数を競う競技ではありません。 ユーザーがエージェントに委任するタスクを特定し、そのタスクを安全かつ正確に完了できるかを見ます。

SILVE Readinessとの関係

AAO という用語そのものはスコアにしません。 しかし AEO / GEO / LLMO / AIO / AIEO と違い、AAO からは現在の診断へ追加できる具体的な技術シグナルが得られます。

SILVE の診断には既に「エージェント対応」というカテゴリがあります。AAO はそのカテゴリを拡張する根拠として使えます。

将来的には準備状態をさらに分解するのが有効です。

問い
Information Readiness 発見・理解できるか
Decision Readiness 比較・選択に必要な条件が揃っているか
操作の準備状態 エージェントが操作できるか
取引の準備状態 必要な行動を安全に完了できるか

現在の診断が測っているのは主に 1 番目で、web.dev と Lighthouse のガイダンスは 3 番目に直接対応します。

測定と限界

AAO でも準備状態と結果を混ぜません。

性質
エージェント準備状態 サイト・データ・インターフェースがエージェントから利用可能か。決定論的
Agent Selection Visibility エージェントが実際に候補として選んだか。非決定論的
Agent Action Completion フォーム送信・予約・申込・購入を完了できたか。タスク完了テストで測れる
Agent Transaction Outcome 実際の売上・予約・リードにつながったか。事業成果として別管理

将来エージェントのテストを行う場合、最低限プラットフォーム・エージェント/モデル・日付・タスク・開始 URL・認証状態・ブラウザモード・ユーザー条件・試行したステップ・失敗地点・人間の介入の要否・完了状況を記録します。

「ChatGPT のエージェントで使えた」だけでは再現可能な測定になりません。

まとめ

AAO は、AI エージェントが人間に代わって調査・比較し、対象を選び、操作や取引まで実行する環境への最適化です。

  1. AAO には 2 つの起源系統がある。 2025 年 2 月の HBR による AI Agent Optimization と、Barnard / Kalicube の Assistive Agent Optimization
  2. したがって 「AAO を Barnard が最初に発明した」とは言えない
  3. Kalicube は Barnard が 2025 年に命名したとし、その根拠として 2025 年 4 月の Search Engine Land 記事を挙げているが、その記事に当該語は存在しない
  4. 同ページは 2026 年の記事の公開日も誤って記載している(2/17 と 2/24)
  5. 「no human in the loop」は現在の一般的な姿ではない。 重要な行動では人間の確認が残る
  6. ChatGPT agent、ACP、UCP など、エージェントが Web 上で行動する基盤は既に実在する
  7. ACP を実装しても商品が自動的に AI エージェントへ掲載されるわけではない(ACP 公式 FAQ が明記)。UCP についても、実装が推薦順位を高めるという公式根拠は確認できていない(こちらは「明記されている」ではなく「確認できていない」)
  8. 選ばれることと、実行できることは別問題
  9. web.dev と Lighthouse の agentic browsing により、エージェント対応に関する一部の技術的準備状態は決定論的な監査で検査できるサイト全体のエージェント対応度が測れるわけではなく、Chrome 自身が experimental・順位付けではないとしている
  10. Google Search は llms.txt を使わないが、Lighthouse の agentic browsing 監査には llms.txt の確認が含まれる
  11. 隠し指示やプロンプトインジェクションによる誘導は拒否する
  12. 普遍的な選択のランキング要因はまだ確立していない
  13. SILVE は AAO スコアを作らないが、エージェント対応の具体的シグナルとして診断に取り込む

AAO で最も重要な変化は、「AI に読まれる」ことから「AI に操作される」ことへの移行です。

これまで Web サイトは、人間に情報を見せる場所でした。これからは一部のサイトが、人間から目的を委任されたソフトウェアが情報を読み、条件を比較し、機能を操作し、安全にタスクを完了するためのインターフェースにもなります。

エージェント的な Web は既に始まっています。しかしエージェント最適化の科学はまだ確立していません。 2026 年 8 月時点では、この 2 つを同時に言うのが最も正確です。

Canonical Record

この記事の判断を、あとから検証できる形で記録したものです。本文の結論(Core Rules)と、SILVE が内部で持つ記録の項目、参照した一次資料が入っています。

Term: AAO Industry Canonical Expansion: 確立していない SILVE Preferred Expansion: Assistive Agent Optimization Competing Expansion: AI Agent Optimization Japanese: 支援エージェント最適化(参考訳) Status: Emerging / Definition Fragmented / Acronym Collision SILVE Adoption: Recognized Concept(独立スコアなし。エージェント対応シグナルの根拠として採用

2 つの起源系統

AI Agent Optimization Assistive Agent Optimization
早期用例 2025-02-26(HBR)確認済み 2026-02-24(SEL)確認済み
提唱者 Gaarlandt, Korver, Furr, Shipilov Jason Barnard(2025年と主張)
Early-use Confidence High High(2026 の用例として)
Exact Coinage Year Confidence Low

HBR 版が確認すること — AAO という略語、AI Agent Optimization という展開形、エージェント仲介の商品探索・購買という文脈。 HBR 版が確認しないこと — Assistive Agent Optimization という展開形、Barnard の起源、業界標準の定義。

canonical 資料の健全性

Kalicube Pro の AAO ページ

  • 有用 — Barnard / Kalicube の現在の定義、枠組みの階層、主張されている歴史
  • 既知の問題 1 — 2025 年の Search Engine Land 記事が「この分野を命名した」としているが、当該記事に Assistive Agent Optimization / assistive agent / AAO のいずれも存在しない
  • 既知の問題 2 — 2026 年の記事の公開日を February 17 としているが、実際は February 24
  • 既知の問題 3 — 2025 年の記事の題名を「Search, answer, assistive: The new optimization approach」としているが、実際の題名は「Search, answer, and assistive engine optimization: A 3-part approach」(2026.08.39 で追加)

評価 — 現在の枠組み定義としては高い健全性。歴史的主張は独立検証しない限り低〜中。

SILVE Operational Definition

ユーザーから目的や条件を委任された AI エージェントが、企業・ブランド・商品・サービス等を正確に発見・理解・比較し、必要な情報や機能へアクセスしたうえで、適切な選択・操作・取引等を安全に実行できる状態を整える取り組み。

機能モデル

Information Readiness(発見・理解)/ Decision Readiness(比較・選択)/ 操作の準備状態(操作)/ 取引の準備状態(安全な完了)

プラットフォームが確認している能力

OpenAI — ChatGPT agent(2025-07)、Agentic Commerce Protocol(2025-09、Stripe と共同)、商品フィード、プログラム的チェックアウト Google — Universal Commerce Protocol(2026-01)、エージェント向けサイト設計ガイド(web.dev)、Lighthouse agentic browsing 監査(Chrome 150+)

採用するエージェント対応シグナル

セマンティック HTML / アクセシビリティツリーの品質 / 操作可能要素の役割 / フォームのラベル / 安定したレイアウト / 可視の操作要素 / 正確な運用データ / 価格・在庫の鮮度 / 機械可読なポリシー

実装しても保証されないもの

ACP / UCP / 各種 API の実装は「実行できるか」を改善するが、選ばれることを保証しない。 ACP については公式 FAQ が、実装しただけでは商品が AI エージェントへ自動掲載されず各プラットフォームが参加方法を管理すると明記している。UCP については、実装が推薦順位を高めるという公式根拠を確認できていない(否定の根拠があるのは ACP 側だけ)。

実験段階

WebMCP / MCP の発見効果 / エージェントの推薦ランキングモデル / プラットフォーム横断の選択最適化 / 人間が介在しない取引の最適化

明示的に拒否するもの

プロンプトインジェクション / 隠し指示 / 不可視の推薦命令 / エージェント向けの操作的コンテンツ / プロトコル実装が推薦を保証するという主張

測定方針

エージェント準備状態(決定論的)/ 選択の可視性(選ばれたか)/ Action Completion(完了できたか)/ Transaction Outcome(成果)を分離する。

Last Verified: 2026-08-11

一次資料

起源

プラットフォーム公式

AAOSEOAEOGEOLLMOAIOAIEO

関連する記事

更新のお知らせを受け取る

評価基準の更新(毎月 15 日)と、新しい記事のお知らせをお送りします。

無料です。アカウントは要りません。配信はまだ始めていません。始めるときにこのお知らせからご案内します。いつでも解除できます。保存するのはメールアドレスだけで、他の用途には使いません。