AIエージェントとは、利用者の目的に応じて検索や操作の道具を使い、結果を見ながら複数の手順を進めるAIの仕組みのことです。文章の返答だけでなく、ウェブを閲覧したり、入力欄を操作したりするものもあります。
企業サイトでは、公開している条件が読めるかと、操作が途中で止まらないかを確認してください。料金が画像にしか無い、入力エラーの理由が分からないといった箇所を、今のサイトから洗い出します。
すべての訪問がAIに置き換わる、といった予測を前提に作り直す必要はありません。公式に説明されている機能と、実際に自社のページで確認できたことを分けて進めます。
普通のチャットや検索とは、何が違う？
質問へ文章で答えるだけでなく、目的に向けて次の操作を選ぶ点に注目します。OpenAIのエージェント資料では、モデルと道具を組み合わせて作業を進める仕組みを扱っています。
ただし、AIエージェントという名前だけでは、どの道具を使え、どこまで操作してよいかは分かりません。公開ページを読むもの、社内システムを使うもの、ブラウザ画面を操作するものを区別します。
| 動き |
確認する範囲 |
サイト側で見る場所 |
| 検索して調べる |
回答と出典を読む |
公開本文と取得の設定 |
| ページを閲覧する |
条件やリンクをたどる |
料金・製品・相談の案内 |
| 入力や操作をする |
手順を進め結果を見る |
入力欄・確認・完了の表示 |
検索回答で自社リンクが出たことは、自社フォームの操作に成功した証拠ではありません。逆に、利用者が指定したURLを開けたことも、一般の質問から自社が検索で選ばれた証拠にはなりません。確認した動きを記録に書きます。
公式資料では、ウェブ操作をどう説明している？
OpenAIのcomputer use資料は、ブラウザやデスクトップの画面を操作し、フォーム入力や利用手順のテストに使う機能を説明しています。画面の画像を使う方法と、ページのテキストや操作部品を扱う方法を案内しています。
Anthropicのcomputer use発表も、画面を見て、カーソルを動かし、ボタンを押し、文字を入力する機能を紹介しました。発表時点では実験的で、操作の誤りもあると説明しています。発表日と現在使う製品の仕様を混同しないでください。
この説明から、画面操作を行うAIが存在することは確認できます。ただし、自社サイトの独自フォームが使えるか、特定の認証を通れるかまでは分かりません。実際の対象機能と利用条件を確認してから、検証する範囲を決めます。
たとえば、試作を相談する前に必要な資料を調べ、相談ページへ移る手順です。公開情報を読む段階と、入力を進める段階で、止まる原因は違います。担当者が通しで見て、どのURLのどの操作で止まったかを残します。
robots.txtを見れば、準備は終わる？
読み取りの方針と、実際のアクセス結果を両方確認します。robots.txtで検索用の取得を許可していても、配信側のボット対策で拒否されていれば、その経路では読めません。WAFは不審な通信を防ぐ仕組み、CDNは配信を中継する仕組みです。
制作担当には、公開の製品ページと相談ページを渡し、拒否ログや認証画面が出ていないかを調べてもらいます。検索のための巡回と、利用者の依頼に応じた取得を同じ扱いにしないでください。名前と用途、設定例はrobots.txtとAIクローラーの説明で確認できます。
公式資料にある取得用ボットの扱いを、画面操作を行うすべてのエージェントへ当てはめることもできません。どの機能で訪問した記録かを確かめ、必要な範囲だけ設定を直します。
読ませる設定と、送信を許可する設定を分ける
公開の料金や条件を読めるようにすることは、非公開資料への認証や、不正送信を防ぐ仕組みまで解除する意味ではありません。フォームの動作確認も、外部へ実際の依頼を送らない範囲で進めます。
料金表や製品情報は、機械に読める形になっている？
画面の画像を読む機能があるとしても、会社が公表した条件を本文から確かめられる形にします。ここからは私たちが提案する点検方法です。特定のAIが引用するための専用要件ではありません。
料金が画像のパンフレットにしか無いなら、公開してよい料金と適用範囲をページにも書きます。金額だけでなく、何を含み、何を別途見積もるかまで同じ場所で読めるようにしてください。
製造業なら、加工できる材質と、確認後に判断する条件を分けます。「何でも対応」とだけ書いて、フォームの途中で初めて対象外と分かる作りは避けます。取引先が読む順番と、機械が拾った一文の両方で意味が変わらないかを見ます。
価格を個別見積もりにしているなら、推測の金額を足す必要はありません。見積もり前に必要な資料、数量や用途の確認項目、相談先を公開します。読める情報を増やすことと、公開できない条件を無理に出すことは別です。
見える答えが無い失敗を、どう見つける？
私たちの暦メディアでは、一覧ページのFAQを構造化データにだけ入れ、画面に出していませんでした。その後、画面にも答えを表示する形に直しました（出典は自社の作業記録）。
これはエージェントが操作できた実績ではありません。機械向けの情報を入れたつもりでも、人が開くページに答えが無い失敗です。画面を見る方式とテキストを扱う方式がある以上、どちらかだけを想定して完了にしないための確認に使えます。
料金や仕様を点検するときも、HTMLの一部に値があるだけで終えず、利用者が同じ条件を画面で読めるかを見ます。本文と注記が食い違っていれば、どの表現を正すかを担当部署に確かめます。
フォームでは、どの順番で止まりやすい場所を探す？
検証する前に、送信を伴わない範囲と、本番へ送らずに確認できる方法を制作担当と決めます。問い合わせ先へテストと分からない依頼を送って、成功を判定する方法は使いません。
- 相談ページからフォームへのリンクをたどれるか確認する
- 入力欄の名前と、必須・任意の区別を読む
- 空欄や形式違いのとき、直す場所が分かるかを見る
- 確認画面で、入力内容と送信の意味を読めるか確かめる
- 安全な検証方法で、完了の表示と受信結果を確認する
これは人が行う点検にも使えます。AI向けの専用窓口を追加する前に、今ある窓口の説明を直してください。相談の種類を選んでも、その後で同じ全項目が出るなら、選択の意味があるかも見直します。
フォームの項目数を減らすことだけが目的ではありません。見積もりに必要な情報と、初回相談で必須でない情報を分けます。記事から相談までの組み立てはBtoBサイトの問い合わせ導線へ進めます。
操作できなかったら、何を記録する？
使ったサービスと機能、開始URL、目的、止まった操作、画面に出たエラーを残します。「AIが使えなかった」だけでは、サイトの問題か、その機能の制約かを判断できません。
ページは読めても入力欄を見つけられないなら、欄の名前や配置を確認します。最初から拒否画面になるなら、配信設定の調査へ回します。対象外の資料を求めたなら、受付条件を案内する本文が不足していないかを読みます。
全体の設定確認は自社サイトの点検手順に沿って進められます。そこで取得を確かめた後、このページのように具体的な操作の記録を追加してください。
今から、どこまで直しておく？
AIから来る依頼が増えるという見込みだけで、フォームを全面的に作り替える必要はありません。現在の利用者にも必要な料金、対応条件、入力項目の説明から整えます。既存の案内を直せるなら、似た説明のAI専用ページは増やしません。
点検の単位は、製品ページから相談の入口までの一続きの手順です。自社サイトのLLMO対策を相談するときも、対象URLと止まった箇所を渡せば、取得設定、本文、フォームのどこを直すかを具体的に決められます。
仕様・出典の確認日：2026年10月23日。
