六回かけて、地図を描いてきた。四つの層 ―― 意味、会話、操作、取引。それを貫く二本の柱 ―― 何を信じるか、どこまで許すか。そして、すべての層の入口に立つ発見（ARD）。部品は揃った。
最終回は、この地図を時間軸に展開する。何を今すぐやり、何を待ち、何が起きたら動くのか。投資判断としての優先順位を、一枚にする。
先に、この回の結論を置く。区切るのは日付ではなく、シグナルだ。 三段のロードマップを示すが、段と段の境界に書くのは年月ではない。「何が起きたら次に進むか」という観察可能な条件だ。理由は連載を読んできた方には明らかだと思う ―― この領域の地図は5か月で描き換わる。第5回で見た商流の再編がそうだった。日付で書いたロードマップは、公開した瞬間から古び始める。シグナルで書いたロードマップは、地図が描き換わっても機能する。
前提 ― 一度にやらない。ただし、待ちもしない
全層を一度に実装するのは誤りだ。層ごとにリスクの重さが違い、足場の固さが違う。だが逆側の誤りもある ―― 「標準が固まるまで待つ」だ。第4回で書いたとおり、安定版とマルチブラウザを待ってから設計を考え始めるのでは遅い。本番で試せる窓が開いているのに素振りをしない、というのは、慎重ではなく単なる出遅れになる。
判断の軸は二つで足りる。足場の固さ ―― その層の仕様と実装が、どれだけ固まっているか。そして事故が起きたときの重さ ―― その層で取り違えが起きたとき、何が失われるか。読み取りの層の事故は間違った答えで止まり、操作の層の事故は間違った結果を残し、取引の層の事故は金を失わせる。梯子の下段ほど軽く、上段ほど重い ―― 第1回で引いたこの構図が、そのまま実装順の根拠になる。
この表から、三段のロードマップが素直に落ちる。
第一段 今すぐ ― 足場が固いもの、事故が軽いもの、そして柱
今日から着手してよいものは四つある。いずれも、待つ理由がない。
一、柱を立てる。 第6回で書いた横断の運用 ―― 参照させる一次情報の指定（何を参照させ、何を参照させないか）、委任状の書式（範囲・条件・確認・記録）、非常停止の手順と公開物の台帳。これらはすべて文書仕事で、プロトコルの成熟を待つ必要が一切ない。コストは最も低く、あとから差し込む苦労は最も大きい。層の実装より先に、最初の一段を置く日に立てる。
二、意味の層を整える。 構造化データの棚卸しと、llms.txtの設置だ。Schema.orgは確立した仕様で、読み取り専用だから事故も軽い。そしてこの層の投資は三重に効く ―― エージェントが読む材料になり（第2回）、窓口を立てるときの原資になり（第3回）、AIがあなたの会社を語るときの根拠になる（第6回）。llms.txtの現在地を踏まえ、効能を誇張せずに置く。
三、素振りを二種類。 /.well-known/agent-card.json の設置（B2Bで問い合わせ・見積のやり取りが多い業種ほど先行の意味が立つ）と、WebMCPのオリジントライアル（Chrome 149で2026年5月に開始）での実験だ。後者は読み取り専用ツール ―― readOnlyHint: true の検索や参照 ―― に限る。副作用のあるツールを公開する段階ではまだない。窓が開いているうちに勘所を掴んでおく、それだけの投資でいい。
四、現状を測る。 自社のサイトはいまどの層まで応えているか。エージェント経由の流入や問い合わせは観測できているか。第1回で置いた自己診断の枠組みを、一度実際に回す。測る道具も外に現れ始めた ―― Lighthouse 13.3（2026年5月）は「Agentic Browsing」カテゴリを既定構成に載せ、アクセシビリティツリー・レイアウトの安定性・llms.txt・WebMCPツール登録を検査する（実験段階の分類だ）。自己診断と併せて定点に使える。次の段に進む判断は、この現在地の記録から始まる。
第二段 シグナルが灯ったら ― 目安として2026年後半から
第二段の作業は、公開の範囲を広げることだ。読み取り専用ツールの本公開、確認境界つきでの副作用ツールの段階公開、NLWebの導入（構造化データが厚く、問い合わせの型が定まっているサイトほど効く ―― 第3回の導入判断）、EC事業者なら商品フィードの整備とチェックアウトのAPI化（商流がACPとUCPのどちらに転んでも要求される共通の足回り）、そして第6回のai-catalog.jsonの素振り。
この段への移行を告げるシグナルは、外と内に一つずつある。
外のシグナルは、消費側の実働だ。第4回の時点で、WebMCPのツールを呼ぶ側はChromeのGeminiが「予告」されているだけだった。オリジントライアルが開いた今もサイト側の整備が先行しており、呼ぶ側のGemini in Chromeの対応は予告されたままだ（2026年7月時点）。予告が実働に変わったか ―― 一般ユーザーのエージェントが実際にツールを呼び始めたか。NLWebなら、対応アシスタントの広がり。呼ぶ側のいない公開は、露出だけが先行する。
内のシグナルは、前段のCheckの通過だ。第一段で実験したツールについて、露出範囲・契約の忠実性・情報露出の観点（第4回）を確かめ、意図とのズレを潰し終えているか。動いたことは通過条件ではない ―― この連載で繰り返し見たとおり、この領域の失敗はエラーを出さない。確かめていないなら、外のシグナルが灯っても進まない。
第三段 生態系が立ったら ― 目安として2027年から
第三段は、重いものを載せる段だ。書き込み・取引を伴うツールの公開。AP2の委任を受ける側としての実装 ―― 第5回で言語化した受け入れ条件（上限・期限・対象・Human Presentの線）を、実際の決済フローに載せる。A2Aでのエージェント間接続の本格運用（通信の足場は2026年4月のv1.0到達で据わっており、あとは相手と用途の問題だ）。そして全層の運用 ―― 一次情報の鮮度、権限の台帳、記録の突き合わせ ―― を一本のガバナンスに束ねる。
移行のシグナルは四つ観察する。ブラウザの足場 ―― WebMCPが安定版に入るか、ChromeとEdge以外の実装コミットが現れるか。Microsoftは仕様の共同編集者で、Edgeも独自のオリジントライアルを開いているが、安定版への実装はまだどのブラウザにもない。発見の生態系 ―― 主要なエージェントクライアントがARDのレジストリを既定で叩くようになるか（第6回で置いた観察項目そのものだ）。商流の帰結 ―― ACPとUCPの再編がどう着地するか。委任の証跡はどちらに転んでもAP2に載るという構図（第5回）が保たれる限り、ここは慌てなくていい。決済標準の成熟 ―― FIDOに移ったAP2の標準化が、v0.2（2026年4月末、FIDO寄贈と同時に公開。自律実行のHuman Not Presentフローを追加）から本番規模の実証へ進むか。
シグナルの観察は、意志の力に頼らず仕組みにする。第6回のDoで置いた四半期レビューに、この観察項目をそのまま載せればいい。日付は過ぎるが、シグナルは灯るまで待ってくれる。
優先度の決め方 ― どの梯子から登るかは、業種が決める
三段の骨格は共通だが、力点は事業で変わる。
B2B ―― 問い合わせ・見積・発注のやり取りが多いなら、会話の窓口とAgent Cardが先に立つ。あなたの取引先が購買エージェントを持つ日、最初に探されるのは窓口だからだ。EC ―― 商品フィードと構造化データの精度が、そのまま商流対応の原資になる。第5回で見たとおり、誠実に整備してきたサイトはここで先行できる。コーポレート・メディア ―― 主戦場は意味の層と一次情報の整備だ。取引の層は遠いが、AIに自社を正しく語らせるという意味で、根拠の設計は最も直接に効く。
ただし、どの業種でも変わらない原則が二つある。柱と意味の層は全員の最初 ―― ここに業種差はない。そして登る順序は、エージェント接点の多い順ではなく、事故が軽い順 ―― 接点が多い層ほど早く開きたくなるが、開く順序を決めるのはリターンの大きさではなく、取り返しのつくうちに学べるかどうかだ。
Check ― 確かめること（観点）
最終回のCheckは、個別の層ではなくロードマップそのものに向ける。観点は二つ。例によって、判定手順は書かない。
順序の観点。 公開の順序は、リスクの低い層から高い層へ、になっているか。読み取りより先に書き込みを開いていないか。確認境界を設計する前に、取引を受け始めていないか。なぜ要るか：逆順で登ると、学びが取り返しのつかない事故の形でやってくるからだ。下段の失敗は授業料で済む。上段の失敗は済まない。
ゲートの観点。 各段に進む前に、前段のCheck観点を実際に確かめたか。「動いたから次へ」になっていないか。なぜ要るか：この連載で見てきた失敗 ―― 契約と挙動の乖離、根拠のずれ、意図より広い委任 ―― はどれもエラーを出さないからだ。動作確認は、意図適合の確認の代わりにならない。確かめずに登った段の下には、静かな失敗が積み残る。
形式面の検査が機械に降りていき、人間には意図との突き合わせが残る ―― この線引きは各層で繰り返し引いてきた。ロードマップの上では、こう言い換えられる。進む速さは道具が決めてくれる。進んでよいかは、あなたが決める。
連載の締め ― 層は積むもの、柱は立てるもの、地図は観察するもの
七回を一枚にまとめる。
Webサイトに三番目の読者が現れた（第1回）。サイトは自分を名乗り（第2回）、問いに答え（第3回）、操作を委ね（第4回）、取引を任せる（第5回）ようになっていく。そのすべてを、何を信じるかと、どこまで許すかの二本の柱が貫き、発見の標準が入口に立ち上がりつつある（第6回）。そして対応は一度にやるものではなく、足場と事故の重さで順序を決め、シグナルで進む（第7回）。
使われるWebサイトは、一度に作るものではない。層を積むものだ。層は下から順に。柱は最初から。そして地図は、描いて終わりではなく観察し続けるものだ ―― この連載自体、公開の時点で最新というだけで、5か月後には現況の節から古び始める。それでいい。層の実装は古びても、梯子の構造と二本の柱は残る。古びた部分を差し替えながら使ってほしい。
各層をさらに深掘りする既刊の連載を、最後にハブとして置いておく。
- 全体戦略：エージェンティックWebの完全スタック
- 意味の層：llms.txtの現在地／AIは会社をどう知っているか
- 操作の層：WebMCP連載
- 取引の層：A2A連載／AIエージェントに財布を渡せますか／EC実践ロードマップ
- 柱（権限と根拠）：合鍵を渡すな、委任状を書け／HITL設計の現在地／ガバナンスは設計判断である
三番目の読者は、もう来ている。迎える準備は、今日の一段から始められる。
参考情報 ― シグナルの定点観測先
移行シグナルを観察するための一次情報を、定点として並べておく。
WebMCP：仕様（W3C Web Machine Learning Community Group ドラフト） / Chromeのドキュメント（オリジントライアル・対応状況）
A2A：仕様・ドキュメント
ARD：仕様サイト（レジストリ・参照実装の動向） / 発表（Google Developers Blog、2026年6月）
Lighthouse Agentic Browsing：スコアリング仕様（Chrome for Developers）
この記事をシェアする
