Webサイトには、長いあいだ二種類の読者しかいなかった。
一つは人間。もう一つはクローラ。私がHTMLを手で書き始めてから四半世紀、私たちが作ってきたサイトは、突きつめればこの二者に向けたものだった。人間には見やすく、迷わず、気持ちよく。クローラには正しく、漏れなく、構造的に。SEOも、レスポンシブデザインも、表示速度の改善も、根は同じだ。二種類の読者に、それぞれ最適な形で情報を届ける。それがWeb制作の仕事だった。
いま、三番目の読者が現れた。AIエージェントである。
そしてこの三番目は、これまでの二者と、関わり方の質が根本から違う。
クローラは読むだけだった。エージェントは動く
違いを順に見ていく。
クローラは受動的だ。ページを読み、索引に入れ、それで終わる。Googlebotがあなたのサイトで商品を買うことはないし、問い合わせフォームを送ることもない。読んで、記録する。それだけの読者だった。
人間は能動的だ。読んで、考えて、操作する。フォームを埋め、ボタンを押し、決済まで進む。ただし遅い。一度に一人しか動けないし、疲れるし、迷う。
エージェントは、この両者の性質を併せ持つ。クローラのように高速で、休まず、大量に。そして人間のように、読むだけでなく操作する。あなたのサイトで検索し、絞り込み、申し込み、ときには支払いまで済ませる。しかも本人としてではなく、本人の代理として。
受動的な観測者だったものが、能動的な行為者に変わる。これが三番目の読者の正体だ。
観測者と行為者では、サイト側の身構え方がまるで違う。読まれるだけなら、正しく書いてあればいい。だが動かれるなら、「何を、どこまでさせるか」を設計しなければならない。ここから先は、情報設計の話であると同時に、権限設計の話になる。
関与には、深さの階段がある
もっとも、エージェントの関与は一枚岩ではない。浅いものから深いものまで、はっきりした段階がある。
第一段は、見る。ページの意味を機械的に読み取る段階だ。これは実のところクローラの延長線上にある。「この価格は税込か」「この日付は営業日か」を、推測ではなく構造として読めるようにする。Schema.orgや構造化データの世界だ。
第二段は、問い合わせる。エージェントが自然言語で「在庫はあるか」「最短の納期は」と尋ね、サイトがそれに答える。サイトが会話可能な窓口になる段階だ。
第三段は、操作する。検索する、絞り込む、フォームを送る、予約を入れる。人間がマウスとキーボードでやっていたことを、エージェントが直接呼び出す。
第四段は、取引する。操作の果てに、決済がある。エージェントが本人の財布を預かり、支払いまで完了させる。
この階段を一段上がるごとに、サイトがエージェントに渡すものが増えていく。最初は情報を見せるだけ。次に質問に答える。次に操作を許す。最後に財布を預ける。渡す権限が増えるほど、設計の責任は重くなる。
この梯子が、そのままこの連載の地図になる。
「より良く」ではなく、「対応しているか」
ここで、これまでのWebと決定的に違う点を一つ挙げておく。
SEOは競争だった。GEO（生成エンジン最適化）も競争だ。同じ土俵に大勢が並び、「より上位に」「より引用されやすく」を競う。順位という連続した量を、少しでも上げる戦いだった。
エージェント対応は、競争というより、二値に近い。フォームにエージェント向けのツール定義があるか、ないか。決済のプロトコルに乗っているか、いないか。「より良く見つけてもらう」の前に、「そもそも扱える形になっているか」が問われる。ある線を越えていなければ、どれだけ丁寧に作り込んでも、エージェントからは存在しないのと同じになる。
「最適化（Optimization）」という言葉が、この地形ではうまく届かない。より良くする、の対象がそもそも無いからだ。まず、在るか、無いか。私は以前、最適化という言葉の輪郭が痩せていく感覚について書いた。その続きを、今度は実装の側から確かめていく連載だと思ってもらっていい。
なぜ、今なのか
三番目の読者の話は、少し前まで思考実験だった。2026年、そうではなくなった。
象徴的なのがWebMCPだ。Webページが自分の機能を「エージェントが呼べる道具（tool）」として差し出すための、ブラウザ側の仕組みである。2026年2月にW3CのWeb Machine Learning Community Groupで最初の草案が公開され、GoogleとMicrosoftのエンジニアが共同で仕様を進めている。ただし現時点ではW3Cの正式な標準ではなく、コミュニティグループの草案という位置づけだ。当初はChrome 146でフラグを立てないと動かない実験実装だったが、そこからChrome 149のオリジントライアルへと段階的に開かれてきた（Chrome for DevelopersのWebMCPドキュメント）。自分のマシンのフラグの内側ではなく、実際のユーザーの前でツールを試せる段階に入った、ということだ。
仕様も生きて動いている。APIの名前も設計も、この一年で何度も書き換えられてきた（Edgeチームによる更新と補足）。初期の草案にあった provideContext() は2026年3月に削除され、ツールを登録・解除する作法もその後さらに置き換えられている。半年で作法が変わる。それくらいの速度で動いている領域だ。正確な現行APIは、実装を扱う第4回で最新状態に洗い直す。
まだ固まってはいない。ブラウザの対応状況は、一次情報で追えるかぎりChromeが先行し、Edgeは共同で仕様を練りながらも搭載の足並みは流動的だ。「安定版を待ってから」と言えるほど整ってはいない。だが同時に、「まだ何も動いていないから様子見でいい」も、もう正しくない。動き出したものを、動き出した状態のまま観察する。それが今の正しい立ち位置だと考えている。
そしてWebMCPは一つの点にすぎない。意味の層（Schema.org、llms.txt）、会話の層（NLWeb）、決済の層（A2A、AP2）。バラバラの点として現れていた技術が、この一年で互いにつながり、一つの地形になり始めた。私は以前、それらを一枚に束ねた全体像を書いた（エージェンティックWebの完全スタック）。本連載は、その地図を実装者の手元に引き寄せ、2026年7月時点の最新状態に洗い直す試みである。
この連載で歩く道
各層について、二つのことを対で書く。何を入れるか（Do）と、それが意図どおり入っているかを確かめる観点（Check）だ。作ることと確かめることは、同じ一覧の裏表だからだ。
- 第2回 意味と全体像 ― Schema.org、構造化データ、llms.txt
- 第3回 会話 ― NLWeb
- 第4回 操作 ― WebMCP（この連載の主役）
- 第5回 取引・決済 ― A2A、AP2、ACP、UCP
- 第6回 横断 ― RAG（根拠）とセキュリティ・権限
- 第7回 実装順とロードマップ ― 何から、いつ手をつけるか
各回は単独でも読める。だが順に積むと、冒頭の梯子が一枚の地図として立ち上がる。
まず、自社サイトの現在地を知る
具体的な確認の観点は各回で示す。その前に、大づかみの自己診断を置いておく。次の四つに答えてみてほしい。
- あなたのサイトの意味は、機械が推測せずに読めるか。価格、在庫、日付、対応地域が、構造として書かれているか。
- 「これは何ができるサイトか」を、エージェントが一覧できるか。人間向けのナビゲーションとは別に、機械向けの見取り図があるか。
- サイトの主要な操作 ― 検索、申し込み、予約 ― は、エージェントが呼べる形になっているか。それとも画面を目で見て手で押すことを前提にしているか。
- その操作のうち、取り返しのつかないもの（購入、送信、契約）に、人間の確認は挟まっているか。
多くのサイトは、一つ目からすでに怪しい。それでいい。まず現在地を知ることが、地図を持つということだ。
次回
土台から始める。第2回は「意味と全体像の層」を扱う。サイトが、自分が何者で、何ができるのかを、機械にどう名乗るか。Schema.orgと構造化データ、そしてllms.txt。エージェントがあなたのサイトで何かをする前に、まず正しく「読める」ようにする話だ。
参考情報
この記事をシェアする
