AIエージェント対応サイトのチェックリスト30項目

この記事は、自社サイトの責任者や、新規事業・Web運営の担当者に向けたチェックリストです。「AIエージェントに、自社サイトを使ってもらえる状態」とは何か。それを30項目に分けて確認します。読み終えたとき、自社の現状を点検し、最初にやる5つを決められるようになります。

前提として、ブラウザ上のAIエージェント向けの仕組み「WebMCP」は、まだ草案の段階です。W3Cのコミュニティグループの仕様草案（2026年10月16日付）は、W3C標準ではありません。内容は変わり続けています。そこで、このリストは特定の書き方に寄りすぎないよう、「サイトの側で決めておくこと」を中心にまとめました。仕様の詳しい説明は、起点となる解説記事にあります。

このチェックリストの使い方

項目は6つの観点に分かれています。各項目には「理由」を一言添えました。すべてに「はい」と答える必要はありません。「いいえ」や「分からない」が見つかること自体が、このリストの成果です。

観点1：何を開くか決める

最初に決めるのは、技術ではなく範囲です。何でも開くと、守るべきものが増えます。

• AIに任せたい操作を、10個程度（目安）で書き出したか　理由：全部を対象にすると、検討が終わらないため。
• 操作ごとに「読むだけ」か「変更する」かを分けたか　理由：変更を伴う操作は、守り方が変わるため。
• 取り消せない操作（決済、送信、削除）に印を付けたか　理由：後戻りできない操作は、扱いを別にする必要があるため。
• 最初に試す操作を、1つに絞ったか　理由：1つで学べば、他の操作に応用できるため。
• 開かない操作と、その理由を決めたか　理由：「やらない」と決めておくと、後の議論が速いため。

観点2：情報を機械が読める形にする

ツールを用意する前に、情報そのものが読めるかを確かめます。ここは、WebMCPを使わない場合でも役に立つ土台です。

• 価格・営業時間・申し込み条件が、画像やPDFだけになっていないか　理由：画像の中の文字は、AIが正しく読めないことがあるため。
• 商品やサービスの名前と説明が、ページごとに統一されているか　理由：表記ゆれは、AIの取り違えを招くため。
• 在庫や空き状況は、最新の値を取り出せるか　理由：古い値で案内すると、利用者に迷惑がかかるため。
• よくある質問が、見出しと文章で整理されているか　理由：AIが答えの根拠を探しやすくなるため。

観点3：ツール設計

ツールとは、サイトが公開する「名前・説明・入力項目・処理」のまとまりです。1つの操作に1つが基本です。細かい書き方はツール設計の記事で扱います。ここでは、点検の問いだけを挙げます。

• 名前を「動詞＋対象」にしたか　理由：名前が曖昧だと、AIが選び間違えるため。
• 説明に「何をするか」と「何をしないか」を書いたか　理由：範囲が分かれば、誤った呼び出しが減るため。
• 入力項目に、形式・範囲・必須かどうかを定義したか　理由：AIが作り話の値を入れにくくなるため。
• 処理の側でも、入力を検証しているか　理由：AIが渡す値は、想定外になることがあるため。
• 失敗したとき、次の手が分かるエラーを返すか　理由：AIが自分でやり直せるようにするため。
• ツールの数を絞り、必要なときに登録する設計か　理由：数が多いと、AIの扱える情報量を圧迫するため。

観点4：安全・権限

ツールの説明や、返す内容に紛れた悪意ある指示で、AIが動かされる危険が草案に書かれています。ここは、実装前に決めておく観点です。詳細は権限と認可の記事を参照してください。

• ツールを見せる相手を、自分のサイトの中に限っているか　理由：草案では、既定は同じオリジン内。外へ出すには明示が必要です。
• 外部のiframeやドメインに公開するなら、その理由を説明できるか　理由：意図せず外へ出していないか確認するため。
• ツールが返す内容に、外部から入った文章を含めていないか　理由：悪意ある指示が紛れる経路になりうるため。
• 宣言と実際の動作が、ずれていないか　理由：名前は「確認」なのに実際は購入、という事故を防ぐため。
• 必要以上の情報を、入力や出力に含めていないか　理由：過剰な項目は、プライバシーの問題につながると草案が指摘しているため。

観点5：人の確認と責任

仕様は、人が関わる使い方を主に想定しています。草案の本文は、実行前の利用者確認を必須とは定めていません。つまり、確認の設計はサイト側の責任になりやすい、ということです。詳しくは人の確認の記事で扱います。

• 購入・送金・個人情報の変更などで、人の確認を挟むか　理由：取り消せない操作を、AI任せにしないため。
• 実行した操作が、画面上で見えるようになっているか　理由：利用者が何が起きたか分かる状態にするため。
• 取り消せない操作に、注釈（consequentialHint）で印を付けたか　理由：クライアント側が確認を出す手がかりになるため。
• AIが止まったとき、人が引き継げる画面が残っているか　理由：AI向けの入口は、画面の代わりではないため。
• 問題が起きたときの、社内の責任者と連絡先を決めたか　理由：誰が判断するかが曖昧だと、対応が遅れるため。

観点6：計測と運用

公開して終わりではありません。対応状況も草案も動くので、見直す仕組みが要ります。

• ツールが呼ばれた回数と、成功・失敗を記録するか　理由：直す場所は、数字からしか分からないため。
• 人の確認が必要になった回数を見られるか　理由：確認の多い操作は、設計を見直す合図になるため。
• 登録を変える手順（解除して再登録）を把握しているか　理由：草案には、内容の自動更新の仕組みがまだないため。
• 仕様と対応状況を、定期的に確認する担当を置いたか　理由：変更される可能性があると、Chromeの資料も述べているため。
• 止めるときの判断基準を、先に決めたか　理由：続けるか止めるかを、感覚で決めないため。

仕様や対応ブラウザの見通しは、WebMCPの現状と今後の記事にまとめています。Edgeなど他のブラウザの対応時期は、現時点で公式な確認が取れていません。

最初にやる5つ

30項目を一度に進める必要はありません。次の5つから始めるのが、現実的です。

ここまでは、ツールのコードを1行も書かずに進められます。実装は、その後の話です。他の方式との使い分けは、API・RPA・スクレイピングとの違いの記事が参考になります。

チェックを使った進め方：棚卸し会議の例

リストは、会議で使うと効果が出ます。次は、60分ほどの会議の進行例です。時間は目安で、規模に応じて変えてください。

以下は、架空の例です。ある会社の予約サイトで、担当者4人が集まったとします（営業、運営、エンジニア、法務）。

1. 最初の10分：目的をそろえる。「AIに使ってもらう」とは何を指すのか、言葉を合わせます。仕様が変動中であることも共有します。
2. 次の15分：観点1を全員で埋める。操作の候補を書き出し、読むだけか変更するかに分けます。
3. 次の20分：観点2〜5を、担当別に確認する。運営は観点2、エンジニアは観点3と4、法務と営業は観点5を見ます。「分からない」は、そのまま記録します。
4. 最後の15分：最初の5つを決める。担当者と期限を置き、次の見直し日を決めます。

この例では、会議の成果は「結論」ではなく「分からないことの一覧」です。分からない点を放置せず、誰が調べるかまで決めておきます。

注意点：このリストの限界

• 仕様が変わります。窓口の名前が変わるなど、短期間で変更が出ています。実装の直前に、最新の仕様を確認してください。
• 標準になるかは、まだ分かりません。ここに挙げた項目の多くは、どの方式に進んでも役立つ整理ですが、特定の方式の普及を保証するものではありません。
• リストは完成品ではありません。業種や規模で、必要な項目は変わります。自社に合わせて足し引きしてください。
• 法務・個人情報・セキュリティは、専門家に確認してください。このリストは、判断の代わりにはなりません。
• AIの出力は、人が確認してください。AIにリストの下書きを作らせる場合も、同じです。

Otsumuに相談できること

操作が1つに絞れていて、社内にエンジニアがいるなら、この記事の項目で自己点検し、検証環境で試すことは十分できます。まずは観点1と2だけでも、社内で進める価値があります。

一方で、複数のサービスをまたぐ設計、権限やログの基準づくり、人の確認の流れの設計は、判断が重くなります。どの操作をAIに開くかで社内の意見が割れているときも、外部の視点が役立ちます。

Otsumuは、AIファーストで事業を組み直す（事業の再構築）立場から、操作の棚卸しと設計・開発を支援しています。詳しくはAIエージェント開発をご覧ください。ご相談はお問い合わせからお寄せください。

この記事について

Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中のため、内容は今後変わる可能性があります。参照元は、W3C Web Machine Learning Community Groupの仕様草案、WebMCPの提案リポジトリ、Chromeの公式資料です。

執筆：Otsumu株式会社 ／ 編集日 2026.10.20