この記事は、自社サイトの情報を、AIにも正しく読み取ってもらいたいと考えている事業責任者や担当者に向けて書いています。読み終えると、見出しや表の整え方、構造化データ（情報の意味を機械が読める形で添える書き方）の考え方、正確に保つべき項目、そして新しい試みとの付き合い方を、順序立てて判断できるようになります。
この記事はWebMCPシリーズの一部ですが、主題は「読む入口」の整備です。WebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）は、「操作の入口」にあたります。WebMCPは草案の段階で、内容が変わり続けています。この記事の確認は2026年10月20日時点です。
なお、検索エンジンやAIが実際にどう情報を扱うか、順位や表示にどの程度影響するかは、この記事では断定しません。確認できていない事柄は、確認できていないと書きます。シリーズ全体の入口は、WebMCPの入門記事にあります。
「読む入口」と「操作の入口」は別の層
AIがサイトと関わる場面は、大きく二つに分けて考えられます。一つは、サイトの情報を読み取る場面。もう一つは、サイトの機能を操作する場面です。
| 層 | 目的 | 主な手段 | この記事の扱い |
|---|---|---|---|
| 読む入口 | 情報を正しく読み取ってもらう | 見出し・表・リスト、セマンティックHTML、構造化データ | 主題 |
| 操作の入口 | 検索・予約・問い合わせなどの機能を使ってもらう | WebMCPのツール | 位置づけのみ |
WebMCPのツールは、名前・自然言語の説明・入力スキーマ・実行する処理でできています。エージェントは、画面のスクレイピング（画面の内容を機械的に抜き出すこと）やクリックの代わりに、ツールを呼べます。ただし、ツールを用意しても、サイトに載っている情報そのものが曖昧であれば、結果も曖昧になります。
逆に、情報が整っていても、それだけで操作ができるようになるわけではありません。二つは役割が違い、片方がもう片方の代わりにはなりません。まず読む入口を整えておくと、操作の入口を作るときにも、何を公開すべきかが見えやすくなります。この流れは導入のロードマップの記事でも触れています。
基本の整え方：見出し・表・リスト・セマンティックHTML
構造化データに進む前に、普通の文章とHTMLを整えるところから始めます。人にとって読みやすい構造は、機械にとっても読み取りやすい構造であることが多いからです。ただし、これは一般的な考え方で、特定のAIや検索エンジンの挙動を保証するものではありません。
見出しは目次として使えるようにする
- ページの主題を示す見出し（h1）は、1ページに1つにする。
- 見出しの階層を飛ばさない。h2の下にh3、というように順番に使う。
- 見出しだけを拾い読みしても、内容が分かるようにする。「詳細」「その他」のような曖昧な見出しは避ける。
表とリストは、比較と手順に使う
料金プランの違い、対応エリア、手順のように、項目が並ぶ情報は、文章に埋め込まず、表やリストにします。表には見出し行（th）を付け、何の列かが分かるようにします。数えられるものは箇条書き、順序があるものは番号付きリストにします。
セマンティックHTMLを使う
セマンティックHTMLとは、見た目ではなく意味に合わせてタグを選ぶ書き方です。たとえば、ナビゲーション、本文、補足、フッターといった領域を、それぞれ意味を持つタグで示します。見た目だけを整えたdivの羅列より、意味が伝わりやすくなります。ボタンにはボタン用のタグを、リンクにはリンク用のタグを使います。ラベルと入力欄を正しく結びつけることも、同じ考え方です。
Chromeの公式資料も、ツールの設計の勧めとして、セマンティックHTMLに触れています。WebMCPの宣言的API（HTMLのフォームに注釈を付けてツールにする方式）では、フォームの項目の説明に、labelの文言が使われます。普段から項目名を明確に書いておくことが、そのまま役に立つ場面があります。なお、この宣言的APIは、Chromeの資料では紹介されていますが、W3Cの草案の本文にはまだ含まれていません。
文章の書き方
- 主語と対象をはっきり書く。「こちら」「それ」だけで済ませない。
- 1つの段落には1つの話題を入れる。
- 用語は統一する。同じものを、ページごとに別の名前で呼ばない。
- 日付、金額、名称などの事実は、本文の中で明示する。画像の中の文字だけにしない。
- 略語は初出で説明する。
画像の中だけに書かれた情報は、機械が読み取れない場合があります。重要な事実は、テキストでも書いておくのが無難です。
構造化データで、事実を機械可読にする
構造化データとは、ページに書かれた内容の意味を、決まった形式で添える方法です。たとえば、「これは会社の名称」「これは営業時間」「これは料金」といった区別を、機械が読める形で示します。語彙としては、schema.orgのような共通の定義がよく使われます。形式の一つとして、JSON-LDという書き方があります。
ここで大切なのは、構造化データは「ページに書いてある事実を、別の形で添えるもの」だという点です。ページの本文と食い違う内容を入れてはいけません。本文では金額が変わっているのに、構造化データの金額が古いままだと、どちらが正しいのか分からなくなります。
考え方の流れ
- 事実を整理する：会社名、所在地、連絡先、サービス、料金など、正しいと言える情報を書き出す。
- 本文に書く：人が読めるページに、まず書く。
- 意味を添える：その事実に合う語彙を選び、構造化データとして添える。
- 一致を確認する：本文と構造化データが同じ内容か、公開前と更新のたびに確かめる。
- 検証する：形式が正しいか、利用できる検証ツールで確かめる。
どの語彙が、どの検索エンジンやAIで、どう使われるかは、この記事では断定しません。各社の公式の説明を、利用する時点で確認してください。また、構造化データを入れたことで、表示や順位がどう変わるかは確認できていません。効果を前提にせず、「事実を正確に伝えるための手当て」と考えるのが穏当です。
WebMCPとの関係
WebMCPのツールにも、入力スキーマ（JSON Schema）があります。これは、ツールが受け取る入力の形を定義するものです。名前が似ていますが、ページの事実を示す構造化データとは、目的が違います。構造化データは「読むための情報の整理」、入力スキーマは「操作の引数の定義」です。設計の考え方は、ツール設計の記事で扱っています。
正確で最新に保つべき項目
AIが読み取る情報は、古ければ、そのまま古い答えにつながります。更新が漏れやすい項目を、先に洗い出しておくと管理が楽になります。
| 項目 | 整えるときの要点 | 更新が必要になる場面 |
|---|---|---|
| FAQ | 1問1答で、質問を具体的に書く。答えは条件も含めて書く | 制度やサービスの内容が変わったとき |
| 料金 | 税の扱いや、含まれる範囲を明記する。表にまとめる | 価格改定、プラン変更のとき |
| 営業時間・休業日 | 曜日ごとに書く。臨時休業は、日付つきで案内する | 年末年始、臨時の変更のとき |
| 所在地・連絡先 | 表記を全ページで統一する | 移転、番号やアドレスの変更のとき |
| サービスの内容 | できることとできないことを書く | 提供範囲を変えたとき |
| お知らせ・更新日 | 日付を明記する。古い告知は整理する | 終了したキャンペーンがあるとき |
特に、同じ情報が複数のページに散らばっていると、更新漏れが起きます。可能なら、事実の置き場所を一箇所に決め、ほかのページはそれを参照する形にします。担当者と更新の周期も決めておきましょう。
料金や条件に関わる記載は、法令や業界のルールに関係することもあります。表示の方法に不安があるときは、専門家に確認してください。
llms.txtなど、新しい試みとの付き合い方
AI向けにサイトの情報を案内するための、新しい試みがいくつか提案されています。llms.txtは、その一例です。サイトの重要なページを、AIが辿りやすい形で一覧にするといった発想のファイルです。
ただし、これらの有効性は、現時点で確立しているとは言えません。どのAIや検索エンジンが、どのように扱うのか、効果があるのかについて、この記事では確認できていません。そのため、効く、効かないのいずれも断定しません。
試す場合の進め方を、小さく提案します。
- 小さく試す：手間のかからない範囲で始め、主要な導線だけを載せる。
- 本命にしない：見出しや表、構造化データなど、基本の整備を先に行う。
- 内容を最新に保つ：古い情報を載せたままにしない。更新できる体制がなければ、始めない選択もある。
- 載せてよい情報を確認する：公開したくない情報や、社内向けのページを載せない。
- 期待を置きすぎない：効果は測れていない前提で、続けるかどうかを定期的に見直す。
新しい試みは、今後の議論で扱いが変わる可能性があります。一度設定したら終わりではなく、最新の情報を見て判断してください。
チェックリストと、よくある失敗
点検のチェックリスト
- 各ページに、主題を示す見出しが1つある。
- 見出しの階層が飛んでいない。
- 比較や手順は、表やリストで書かれている。
- 重要な事実が、画像の中だけでなく、テキストでも書かれている。
- 会社名、所在地、連絡先の表記が、全ページで統一されている。
- 料金や営業時間などが、最新である。
- 構造化データを使う場合、本文と内容が一致している。
- FAQの答えに、条件や例外が書かれている。
- 更新の担当者と、点検の周期が決まっている。
- 公開してはいけない情報が、載っていない。
より広い観点でのチェックは、AIエージェント対応サイトのチェックリストにまとめています。
よくある失敗
- 本文と構造化データがずれる：価格改定で本文だけを直し、構造化データを古いままにする。
- 見た目だけで構造を作る：文字を大きくしただけで、見出しタグを使っていない。
- 情報が画像に閉じている：料金表や営業時間を、画像だけで載せている。
- 表記が揺れる：サービス名や会社名が、ページによって違う。
- 更新されないFAQ：終了した制度の説明が、そのまま残る。
- 新しい試みへの過信：llms.txtを置いたことで、十分だと考えてしまう。
- 読む入口と操作の入口を混同する：情報を整えたから、AIが予約まで行えると思い込む。
架空の例：予約制の教室サイトの場合
以下は説明のための架空の例で、実在のサイトや実績とは関係ありません。ある教室のサイトで、料金が画像でしか載っておらず、営業時間の表記も、ページごとに違っていたとします。この場合、まず料金を表にしてテキストにし、営業時間の表記を統一します。そのうえで、構造化データを足すかどうかを考えます。順序は、基本の整備が先、新しい試みは後です。
そのあとで、予約の機能をAIエージェントに使ってもらいたいなら、WebMCPのツールを検討します。予約のような重要な操作では、人が確認する設計が大切です。この点は、人が確認する設計の記事と、認証と権限の記事で扱っています。
注意点
- 効果は断定できません。検索エンジンやAIの具体的な挙動、順位や表示への影響は、この記事では確認できていません。
- WebMCPは草案です。W3Cの標準ではなく、W3C Web Machine Learning Community Groupの草案です。Chromeではオリジントライアルとして提供されています。Edgeなど他のブラウザの対応時期は、確認できていません。
- 読む入口の整備は、操作の代わりになりません。操作の入口には、別の設計が必要です。
- 情報は更新し続けるものです。一度整えて終わりにせず、担当者と周期を決めてください。
- 個人情報や契約に関わる記載は、専門家に確認してください。公開してよい範囲や、表示の方法は、法令や自社の規程で決まる場合があります。
- セキュリティにも注意が必要です。ツールの説明や出力に悪意ある指示が紛れるプロンプトインジェクションなど、草案もリスクを挙げています。判断に迷うときは、専門家の確認を受けてください。
Otsumuに相談できること
見出しや表の整理、事実の棚卸し、更新の担当と周期の決め方は、社内で始められます。まずは、料金や営業時間のように、間違うと困る項目から確かめてみてください。
一方で、サイト全体の情報設計の見直しや、WebMCPのような操作の入口の設計は、実装との兼ね合いで難しくなりがちです。Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しています。その一環として、サイトを「AIが読めて、使える形」にする設計も、ご一緒できます。
詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。構造化データやllms.txtなど、WebMCP以外の事柄は、一般的な考え方を述べたもので、個別の製品や検索エンジンの仕様を確認したものではありません。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20