AI Search Readiness（AI検索対応準備）
3つの施策。これらはnon-commodity-content（非汎用品コンテンツ）が扱うコンテンツ品質とは異なります。ここで問うのは、サイトが顧客に代わって行動する機械から見つけられ、見積もられ、取引されることができるかどうかです。
コンテンツルールをすべてクリアしていても、価格を公開しておらず、機械が読み取れる予約エンドポイントを公開していなければ、エージェントからは不可視です。
Move 1：価格帯を公開する
ルール。 あらゆる商用サイトは、自社のサービスがいくらかかるかを公開します。価格表（プライスブック）ではありません。範囲（レンジ）、つまり上下の端と、その間の数字を動かす要因を公開します。
人々はAIに「何がいくらするか」を絶えず尋ねています。何も見積もれないAIは、何かを公開している競合へとユーザーを誘導します。「価格はお問い合わせください」は機械にとって行き止まりであり、人間にとってもますますそうなりつつあります。
最低限公開すべきもの：
- 下限と上限、実数で
- 価格を動かすもの：ジョブの価格帯を決める2～3の変数
- 数値の横に範囲を測定した日付
- すべての固定料金、全額：配送料、セットアップ料、保証金、清掃料、最低料金、違約金
- 正確な見積もりのためのライブソースへのリンク
異論とその回答。 事業者は、価格が変動するため、古い数字に縛られることを恐れて抵抗します。その異論は*「単一の固定価格を正価として提示する」*ケースに関するものです。範囲（レンジ）に対する反論ではありません。日付入りの範囲とその変動要因が明示されていれば、沈黙より正確であり、事業者にしか言及できない内容です。
これを解決するルール。 裸のレートを公開してはいけません。以下のように公開します：
ナイトレートは車両全体で106ドルから175ドル（2026年9月18日測定）。どのキャンパーといつ利用するかで料金が決まります。正確な料金は日程をご確認ください。
以下のようにしてはいけません：
キャンパー $106/泊～。
同じ価格を二度入力しない。 ビルド時に、事業者がすでに維持しているソース（予約プラットフォームのフィード、POS、公開料金表）から読み取ります。ページに手入力された価格は、1ヶ月以内にチェックアウト時の価格と食い違います。事業者自身のページから数値をパースすれば、両者が乖離することはありません。
料金を本当に公開できない場合（ジョブごとに見積もられる、または第三者によって設定される場合）、ページは固定されているすべての隣接情報（料金表、最低料金、保証金、予約変更の違約金）を提示する義務があります。その上で、料金そのものは見積もり時に設定されること、そしてその入手先を明確に示します。「Xは公開していません。理由はこれで、入手先はこちら。変動しないものはすべてここにあります」と書かれたページは、何も書かれていないページより勝ります。
価格ページの公開前チェックリスト：
- 範囲の両端が「～から」ではなく実数である
- 価格を動かす変動要因が明記されている
- 測定日が数値の横にある
- すべての固定料金が全額公開されている
- 数値はビルド時にソースから読み取られており、手入力ではない
- 構造化データが散文と同じ数値を保持している（Move 2参照）
- 価格設定ができない項目については、その旨が記載され、見積もり取得先が示されている
Move 2：エージェント対応スケジューリング
ルール。 顧客のエージェントがカレンダーとの取引方法を認識できない場合、その事業者はエージェントにとって不可視です。エージェントによる予約はすでに現実のものです。アシスタントがテーブル、サービスコール、レンタルを予約します。エージェントはまず構造化データを探し、次にDOMを参照します。
3つのレイヤー。すべて必須。
1. 構造化データによるオファー。 予約可能なすべてのアイテムは、実際の価格またはpriceSpecification範囲、通貨、在庫状態、測定日と一致するpriceValidUntilを備えたOfferを保持します。ビジネスに対するpriceRangeだけでは不十分です。機械は、予約を依頼されているアイテムに対するオファーを必要とします。
"offers": {
"@type": "Offer",
"priceCurrency": "USD",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"priceCurrency": "USD",
"minPrice": 106,
"maxPrice": 175,
"unitCode": "DAY",
"referenceQuantity": { "@type": "QuantitativeValue", "value": 1, "unitCode": "DAY" }
},
"availability": "https://schema.org/InStock",
"priceValidUntil": "2026-12-31",
"url": "https://example.com/book"
}
2. アクション。 エンティティは、予約エンドポイント、HTTPターゲット、および必要な入力を指定するpotentialActionを保持します。これはほとんどのサイトが公開しておらず、エージェントが実際に必要とする部分です。
"potentialAction": {
"@type": "ReserveAction",
"name": "このキャンパーを予約",
"target": {
"@type": "EntryPoint",
"urlTemplate": "https://example.com/book?rental_id={rental_id}&from={checkin}&to={checkout}",
"actionPlatform": [
"https://schema.org/DesktopWebPlatform",
"https://schema.org/MobileWebPlatform"
],
"httpMethod": "GET"
},
"result": { "@type": "Reservation", "name": "キャンパーレンタル予約" },
"object": { "@type": "Product", "name": "2023 Jayco Jay Flight" }
}
動詞に合わせてアクションタイプを選択します：予約・リザベーションにはReserveAction、アポイントメントにはScheduleAction、購入にはOrderAction、イベントにはRsvpAction。
3. 制約条件をデータとして、散文ではなく明示する。 事業者が対応できない滞在をエージェントが予約すると、全員の時間を無駄にします。予約を失敗させるルールを公開します：
- 最小および最大期間
- リードタイムと締切（
availabilityStarts、advanceBookingRequirement） - 資格条件（最低年齢、免許、保証金）
- サービスエリア（
areaServed）と、その各エリアに到達するためのコスト - 営業時間や配達時間枠（到着時間が他者によって制約される場合）
これらを、プロパティが存在するスキーマに配置し、存在しない場合はページ上で平文でも記載します。両方、常に：エージェントは一方を読み、人間は他方を読み、それらは一致していなければなりません。
エージェントが読み取れるレンダリング。 重要なコンテンツはサーバーサイドレンダリング、セマンティックHTML、実際の見出し、altテキスト、テーブルは<table>で。エージェントはDOMとアクセシビリティツリーを読み取ります。クライアントサイドフェッチ後にのみ表示されるコンテンツは、エージェントが認識しなかったものです。
機能を偽装しない。 実際に予約を受け付けるエンドポイントに対してのみReserveActionを公開します。問い合わせフォームを指すアクションは、エージェントが実行する嘘であり、顧客は最悪のタイミングでそれに気づきます。予約が本当に電話のみの場合、スキーマに電話番号を公開し、予約アクションは公開しません。
プロトコルレイヤーと構築すべきもの
3つのレイヤーが存在します。これらは代替手段ではなく、積み重なります。順序が重要なのは、下位レイヤーは今日読み取られる一方、上位レイヤーはまだほとんど読み取られていないためです。
レイヤー1：構造化データ（これを最初に、常に構築する）。 上記のOfferとpotentialAction。これが今日のアシスタントが、ビジネスに関する質問に答え、リンクをたどって行動する際に実際に消費するものです。JSON-LDの1ページ分のコストで即座に機能します。
レイヤー2：機械可読フィード。 安定した1つのJSON URLでカタログを保持：レンタルまたは販売対象、各アイテムの価格、制約条件、予約URL、測定日。プロトコルのコミットメント不要、守るべきエンドポイント不要、あらゆるエージェント、クローラー、兄弟サイトが読み取り可能。安価であり、後でレイヤー3を半日の作業にするものです。
レイヤー3：A2A（Agent2Agent）。 エージェント間タスク委任のためのオープンプロトコル：既知のURLにあるエージェントカード（エージェントのID、スキル、認証を記述）、およびタスクを受け入れ結果を返すJSON-RPC over HTTPSを話すエンドポイント。これは、顧客のアシスタントがページを読む代わりに質問して回答を得るべき場合に適切な答えです。
その現在の位置づけを正直に伝えます。2026年後半時点で、コンシューマーアシスタントがエージェントカードを日常的にクロールするレジストリは存在しないため、カードの公開は、ディスカバリーが到来するという賭けであり、今四半期の予約源ではありません。ビジネスが、静的フィードでは答えられないエージェントからの質問（通常はリアルタイム在庫）に答える必要がある場合に構築します。
正直ルールはここで最も厳しく適用されます。 エージェントカードはスキルを宣言し、別のエージェントがそれを呼び出します。エンドポイントが実際にできることだけを宣言します。ほとんどの小規模事業者は、支払い、保険、レンタル契約がサードパーティプラットフォーム内にあるため、エージェント間で予約を完了できません。それは問題なく、カードはその旨を明記すべきです：
{
"name": "Example Rentals 予約アシスタント",
"description": "1つの車両群の空き状況と価格に関する質問に答えます。支払いは受け付けられません。",
"skills": [
{ "id": "check-availability", "description": "2つの日付の間で空いているユニットを確認" },
{ "id": "quote-stay", "description": "ユニットと日付の合計金額を提示（地域別配送料含む）" }
],
"capabilities": { "streaming": false, "pushNotifications": false }
}
リダイレクトで終了するbook-stayスキルを主張するカードは、問い合わせフォームを指すReserveActionと同じ失敗であり、相手が人ではなく機械である点が異なります。
支払い。 エージェントによる支払いレール（A2A拡張としてのAP2、および競合するエージェントコマース仕様）は急速に進化していますが、ほとんどの予約プラットフォームではサポートされていません。これらを中心にチェックアウトを設計しないでください。プラットフォーム自身のチェックアウトに引き継ぎ、カードにその旨を記載します。
予約可能なページの公開前チェックリスト：
- 価格または価格範囲、通貨、在庫状況、
priceValidUntilを備えたOffer - エージェントが呼び出せる実際の
EntryPointを持つpotentialAction - アクションのURLテンプレートのパラメータが、予約システムが実際に受け付けるものであること
- 最小期間、リードタイム、資格条件、サービスエリアがデータおよび散文として公開されている
- スキーマのすべての数値がコピーの数値と一致している
- ページの予約関連情報がサーバーサイドでレンダリングされている
- 存在しない機能に対してアクションが公開されていない
Move 3：実際の質問からコンテンツを作成する
ルール。 顧客が実際に尋ねる質問こそがコンテンツです。電話、メール、「予約前の質問」はすべて、公開されたページまたはセクションとなり、顧客自身の言葉で回答されます。
Google自身のガイダンスによれば、一般的なアドバイスコンテンツ（「夏の7つのヒント」）は勝てません。勝つのは、超具体的で実際の内容です。今朝顧客から寄せられた質問は、その性質上、公開情報から執筆する競合がそれを知らないため、まさにそれに該当します。
運用上の習慣：
- 質問を逐語的に記録する。 顧客の表現そのまま。業界用語ではありません。「屋根を修理している間、家に届けてもらえますか」がクエリです。「住宅配置ロジスティクス」ではありません。これは、検索者の名詞を書くのと同じルールです。
- 読者がその質問をした場所で回答する。 誰もたどり着かないブログ記事ではなく、質問が発生したページで。
- ソースを添えて回答する。 ソースのない回答は単なる意見です。引用に値するのは、固定料金、公開ルール、測定された数値です。
- 回答が自分で出せない場合、その旨を明記する。 回答が第三者、自治体、保険会社、公園に属する場合、その旨を伝え、誰に尋ねるべきかを明記します。その一文は資産です。
- 事業者だけが知っていることのリストを保持する。 すべてのプロジェクトは未解決質問ファイルを保持します。それらの回答は誰もコピーできないコンテンツであり、そのファイルはインタビューの議題です。
FAQブロックは読者のためのものであり、FAQPageマークアップを付けることでページが何に答えているかを明確にします。 これらが引用を獲得するためのテコではありません。一次情報の具体性こそがそれです。
3つの施策がどのように連携するか
読者は、価格帯を引用したAIの回答からたどり着きます。ページは数値を確認し、変動要因を明示し、読者が実際に抱いていた質問に答えます。その後、オファーとアクションがデータとして公開されていたため、読者のエージェントが予約します。
どれか1つでも欠けると、連鎖が断ち切れます。優れたコンテンツがありながら価格が公開されていないサイトは見積もられません。価格はあるがアクションがないサイトでは取引できません。両方あってもコンテンツが一般的なサイトは、そもそも引用する価値がありません。
出典
- Danny Sullivan基調講演、Google Search Central Live Toronto、2026年4月、非汎用品コンテンツについて。
- AI最適化ガイド、Google Search Central、エージェント可読性とクエリファンアウトについて。
- schema.org
Offer、UnitPriceSpecification、ReserveAction、EntryPoint。 - A2A (Agent2Agent) プロトコル、Linux Foundation、エージェントカードとJSON-RPCタスクインターフェースについて。