AIO対策の具体例：AI経由の登録率は他の流入経路の7倍。Alchemyが過去記事に足したもの

AIO対策を始めるとき、新しい記事を増やす前に見直せるのが、すでに公開している記事です。 顧客からよく聞かれる質問に、その記事だけで答えられているでしょうか。

AI検索からの訪問者が登録につながった海外事例として、Alchemyがあります。支援会社Profoundは、AI経由の訪問者の登録率が、他の流入経路の7倍だったと報告しています。[1]

着目したいのは数字だけではありません。公開されている取り組みには、過去記事へのFAQ追加や、質問と短い答えを読み取りやすくする変更が含まれています。

AIO対策とは、AIの回答を通じて自社の情報を見つけてもらうために、内容や伝え方を整え、紹介のされ方を確かめていく取り組みです。ここでは、既存記事を編集できる集客担当者に向けて、事例の読み方と、自社で試す具体的な作業を説明します。

Alchemyの事例：AI経由の登録率「7倍」は何と何を比べた数字か

「7倍」は流入経路どうしの登録率の比較です。施策前から売上や登録数が7倍になった、という意味ではありません。

数値はProfoundの公開事例による報告値です。図は説明用で、実際の管理画面ではありません。

Alchemyは、ブロックチェーンを使うアプリ開発者向けの基盤を提供する会社です。Profoundの事例では、AI経由の登録率に加え、登録時の自己申告でAIを流入元に挙げた人の割合が、1年で3倍になったことも紹介されています。[1]

この二つは分けて読みます。前者は「訪問した人がどれくらい登録したか」、後者は「登録した人のうち、どれくらいがAIを挙げたか」です。分母になる集団が異なります。

登録の種類、集計期間、母数、実際の登録率は公表されていません。支援会社による報告であり、第三者による検証や、個々の変更が成果へ与えた影響までは確認できません。

自社で似た数字を使うときも、最初に何を数えるかを決めます。会員登録、無料トライアルの開始、問い合わせ、有料契約では、読者が想像する成果が変わるからです。

例えば、資料を受け取るためのメール登録を数えているなら「資料ダウンロードの登録」と書きます。購入完了を数えていないのに「売上につながった人数」と言い換えると、その数字から読み取れる範囲を超えてしまいます。

同じ理由で、割合だけを見て、どの経路へ予算を増やすかを決めるのも早計です。登録率が高くても訪問者が少なければ、登録件数はまだ小さい場合があります。件数と率を並べると、規模とつながりやすさの両方が分かります。

知りたいこと	確認する数字	数字だけでは分からないこと
訪問した人が登録したか	経路別の訪問数と登録数	登録後に有料契約したか
登録者は何を見て知ったか	登録時の流入元アンケート	実際にクリックした全経路
AIの回答で紹介されたか	質問ごとの回答と引用URL	その回答を何人が読んだか
記事の変更が役立ったか	変更前後の記録と他の変更	追記だけが原因だったか

まず自社の報告資料にある「成果」という言葉を、一つの具体的な行動へ置き換えてみてください。それだけでも、どの数字を記事の改善に使えるかがはっきりします。

AlchemyのAIO対策の具体例：過去記事にFAQ・質問の小見出し・短い答えを足す

報告されている変更は、過去記事へ質問と答えを追加し、必要な説明を読み取りやすく整えることです。 FAQは、よくある質問とその答えをまとめた部分を指します。

説明用の図です。画面や作業記録は実物ではありません。

Profoundは、FAQの追記、質問形式の小見出し、短く明確な説明を使った取り組みを紹介しています。記事の外で引用されている情報源も調べていますが、個々のページの修正順や、外部ページへ行った具体的な変更は分かりません。[1]

この事例を自社へ応用するなら、「FAQという部品を付ける」より、「読み終えても残る疑問は何か」を出発点にする方が作業を決めやすくなります。

例えば、予約管理サービスの紹介記事に「簡単に導入できます」とだけ書かれていたとします。導入担当者が知りたいのは、今ある予約を移せるか、従業員も操作できるか、何を準備すればよいか、といったことかもしれません。

記事が長くても、その答えがなければ担当者は判断できません。反対に、対象となるデータや担当者の作業が分かれば、どこまで自社で進められるかを考えられます。この記事で提案する追記は、その不足を埋める作業です。

本文に答えを足す前に、質問の種類を分けておくと、追記する場所を選べます。

読者が知りたいこと	答えを置く場所の候補	追記する中身
そもそも何ができるか	冒頭の説明や機能紹介	対象となる仕事と利用例
自社でも使えるか	利用条件の節	対応する環境、対象外の条件
どう始めるか	導入手順の節	用意する情報と最初の操作
いくらかかるか	費用の節や料金ページ	課金対象、追加費用の条件
途中で困ったらどうするか	手順の補足やFAQ	状況別の確認先と次の対応

これは当社が提案する整理例です。Alchemyの分類表や作業工程を再現したものではありません。

質問をすべて記事末尾に集める必要もありません。本文を読んでいる途中で必要になる答えなら、その説明の近くに置きます。記事全体を読んだ後にも残りやすい短い疑問は、末尾のFAQで扱えます。

ここで避けたいのは、同じ答えを本文、表、FAQにそのまま繰り返すことです。本文では理由と手順を説明し、表では条件を比べ、FAQでは残った疑問に短く答える。役割を分けると、必要な説明を増やしても読み進めやすくなります。

直す記事は、製品ごとに顧客の質問を分けて選んだ

Alchemyは、質問を製品ごとに整理し、記事の新規作成や更新の優先順位を考えていました。 原典で確認できるのは製品単位の分類で、詳細な分類軸は公表されていません。[1]

自社に置き換えると、まず一つのサービスに関係する質問だけを集める方法が考えられます。予約管理の記事を直す日に、採用支援や経費精算の質問まで混ぜると、誰の疑問に答える記事かが広がりすぎます。

同じサービスの質問でも、検討段階は異なります。「何ができるか」を調べる人と、「今の予約を移せるか」を確かめる人では、必要な説明が違います。

最初の人には全体像が必要です。後者には、移せる項目や移行前の確認が必要です。双方を同じ一文で済ませようとせず、記事の主な読者に合わせて説明の順を決めます。

手を入れる記事を選ぶ基準は、閲覧数だけにしなくても構いません。問い合わせで繰り返し案内している、営業担当が説明のたびに補足している、記事を読んだ後も同じ確認が届く、といった状態も候補になります。

ただし、問い合わせが多い理由を、記事の説明不足と即断するのは避けます。料金が複雑、社内の承認が必要、個別条件の確認が欠かせない、といった別の理由もあります。文章で解消できる疑問を選ぶことが先です。

「記事を直すと、この質問にはページだけで答えられる」という一つの到達点を決めておけば、必要以上に全面改稿せずに着手できます。

Alchemyの公開記事で見る、FAQと短い答えの実物

Alchemyの現行記事では、本文で扱った選択肢を、末尾のFAQで短い質問と答えとして確認できます。 これは現在のページの観察で、施策当時の修正前後を比較したものではありません。

説明用の図です。画面や作業記録は実物ではありません。

Alchemyの公開記事は、ステーブルコインの構築を扱う解説です。ページには2026年2月3日の更新表示があり、末尾のFAQに、外部の既製サービスを使うか、自社で構築するかを問う項目があります。[2]

ここでは金融や技術の説明を借りるのではなく、「本文で扱う判断を、読者が尋ねる形にする」という記事の構成を見ます。

実物を確認するなら、リンク先を開き、ページ内検索で「Frequently asked questions」を探します。次に、内製か外部サービスかを尋ねる項目と、その直後の答えを読みます。専門的な本文全体を理解しなくても、質問と答えが対応していることは確認できます。

自社の記事を点検するときにも、同じように質問だけを先に読んでみると、答えの不足に気づきやすくなります。その質問をした人に対して、最初の二文だけで方向性を伝えられるかを見るためです。

例えば、予約管理の記事で「導入は簡単ですか」と聞かれたとします。「簡単に導入できます」という答えでは、質問の言葉を繰り返すだけです。担当者が準備する情報や、初日に行う作業を添えれば、検討を一歩進められます。

次の二つは、説明用の書き換え例です。実在する製品の仕様ではありません。

質問：導入は簡単ですか。
答え：簡単に導入でき、誰でもすぐに使えます。

質問：予約管理を始める前に、何を用意しますか。
答え：受付時間と予約枠を決め、現在の予約一覧を手元に用意します。予約一覧を取り込めるかは、使うサービスが対応するファイル形式と項目を先に確認します。

後の例は、利用開始までの速さを保証せず、担当者が用意するものを答えています。「誰でも」という広い言葉も使っていません。

FAQを読みやすくする際には、次の三点を一組で確認すると直しやすくなります。

質問は、読者の判断を一つに絞る。 「料金や導入方法、サポートについて教えてください」では、答えが長くなります。費用を知りたいのか、移行の可否を知りたいのかを分けます。

最初の文は、その質問への答えにする。 「当社サービスは豊富な機能を備えており」から始めると、可否を知りたい人には遠回りになります。条件付きで利用できるなら、何の条件かも近くに置きます。

短い答えの後に、判断に必要な補足を置く。 一文に収めるために例外を削る必要はありません。可否、対象、条件、詳しい手順へのリンクという順にすると、最初に答えをつかんでから必要な情報へ進めます。

記事に書く内容を選ぶときは、質問への答えと営業上の訴求を分けて考えます。「移行に必要なファイルは何か」という問いへの答えは、ファイルの形式や項目です。サポートの丁寧さを説明したい場合も、その答えを示してから補足します。

また、答えの中に新しい用語が出てきたら、その意味を短く添えます。「CSVに対応」とだけ書かれていても、表計算ソフトから出せるデータだと分からない人は手が止まります。操作に必要な正式名を残しながら、「表の情報を保存するファイル形式」と説明すれば、準備するものを想像できます。

自社で点検する際の完了条件は、「FAQを五つ用意した」ではありません。その質問を初めて読む人が、次に準備するものや、確認すべき条件を説明できる状態です。答えを短くすることと、説明を省くことを分けて考えます。

自社の過去記事1本で試す：顧客の質問への短い答えを足す

まず、繰り返し聞かれる質問を一つ選び、既存記事に答えを追加します。 以下は当社が提案する作業例です。Alchemyが実際に行った手順ではありません。

説明用の図です。画面や作業記録は実物ではありません。

最後まで一つの場面を使います。架空の予約管理サービスを扱う会社が、「予約管理サービスの選び方」という過去記事を直す例です。担当者には記事の編集権限があり、料金や移行条件を確認できる社内の窓口があるとします。

用意するものは、公開中の記事、問い合わせや商談の記録、現在の製品資料、修正案を保存する文書です。顧客名や連絡先を記事へ移す必要はありません。質問の内容だけを取り出します。

最初から全記事を対象にすると、質問の整理も事実確認も大きな作業になります。まず一本で、質問を選ぶ、答えを確かめる、文章へ直す、公開後に確認する、という流れを最後まで通します。

問い合わせで繰り返し聞かれる質問から、見直す記事を選ぶ

記事の候補は、顧客が何度も尋ねる質問に答えるべきページから選びます。 閲覧数が多い記事でも、今回の質問と関係がなければ優先しません。

1. 普段使っている問い合わせ記録や商談メモを開きます。
2. 同じサービスについて繰り返し聞かれる質問を、三〜五個ほど書き出します。
3. 自社サイトで、その質問に最も近い記事を一本選びます。
4. 記事の公開画面を読み、各質問への答えがある場所を記録します。
5. 答えがないもの、条件が足りないものを修正候補にします。

三〜五個は、最初の作業を小さくするための目安です。実際に二つしかなければ、数を合わせて架空の問い合わせを加えません。まだ顧客の記録がなければ「編集担当が想定した質問」と明記し、実際に届いた質問と別に扱います。

予約管理の例では、次のような表を作れます。内容はすべて説明用です。

よく聞かれる質問	現在の記事で答えている場所	足りない説明	最初に確認する相手・資料
今ある予約情報を移せますか	導入の節に「移行対応」とだけ記載	対象項目、ファイル形式、対象外の情報	現行の移行手順と製品担当
受付担当も予約を変更できますか	記載なし	権限を分けられるか	権限設定の説明資料
開始前に何を準備しますか	記事末尾の申込リンクのみ	準備する情報と作業の順	導入担当が使う案内文
契約後に人数を増やせますか	古い料金表へのリンク	現在の人数条件と変更方法	現行の料金ページ

表の「足りない説明」が、そのまま執筆の材料になります。「もっと詳しくする」という依頼より、何を調べて何を書くかが具体的です。

質問と同じ言葉が本文にあっても、答えがあるとは限りません。「移行」「予約」「権限」という単語を見つけた後、その周りの文を読んで判断します。読者が可否や条件を知れるかが基準です。

一方、答えがすでに十分あるなら、同じ内容をもう一度書く必要はありません。見出しが曖昧で見つけにくいのか、別の記事へ行かないと分からないのかを確かめます。見出しやリンクの案内を直すだけで済む場合もあります。

答えが社内資料にしかない場合は、そのまま公開せず、現在も正しいかと公開してよい範囲を担当者へ確認します。個別契約だけの対応を、全顧客が使える標準機能として書かないためです。

確認を依頼するときには、質問だけを送るより、公開する予定の文を一緒に送ると認識を合わせやすくなります。

予約管理の選び方の記事に、既存データの移行条件を追記したいです。
「予約情報を移せます」という案内について、対象となる項目、受け付けるファイル形式、移せない情報、利用条件を確認したいです。
公開できる資料や、現在の説明文があれば教えてください。個別対応だけの内容は、標準機能と分けて記載します。

返答が「ケースによります」だったら、判断が分かれる条件を尋ねます。例えば、元のサービス、データの形式、件数、予約の状態で対応が変わるなら、そのうち公開できる条件を記事へ反映します。

具体的な条件を公開できない場合も、確認に必要な情報は示せます。「移行できるか問い合わせてください」だけで終わらせず、「利用中のサービス名と、書き出せる予約一覧の項目を用意してください」と書けば、読者は相談の準備ができます。

質問を選び終えた時点で、残すものは三つです。対象記事のURL、最初に答えを追加する質問、答えを裏付ける資料です。この三つがそろえば、文章を整える工程へ進めます。

答えがない質問に、質問形式の小見出しと短い答えを足す

質問を小見出しにし、すぐ下に答えを置きます。その後に対象や条件、具体例を補います。 質問の言葉だけを追加しても、説明の不足は埋まりません。

次は、架空の予約管理サービスについて、製品担当が内容を確認したと仮定した書き換え例です。実際に使う場合は、対応する項目や条件を自社の仕様へ置き換えてください。

修正前の例

導入しやすい予約管理サービスです。既存のデータ移行にも柔軟に対応し、日々の管理を効率化できます。

修正後の例

小見出し：現在の予約情報を、新しいサービスへ移せますか。
答え：予約日時と予約者名は、指定形式のCSVファイルから取り込めます。過去の変更履歴と添付ファイルは移行対象に含まれません。
補足：CSVは、表の情報を保存するファイル形式です。移行前に現在のサービスから予約一覧を書き出し、取り込み用の見本と列の項目を照合します。元の予約データは残し、少量のテストで内容を確かめてから移行します。

修正後は、移せる情報、移せない情報、最初に確認するものが分かります。「柔軟」「効率化」といった評価の言葉を増やすより、読者が判断に使える事実が増えています。

この形を、そのまま全質問へ当てはめる必要はありません。可否を尋ねる質問なら「できます。ただし対象は〜です」と答えられます。選び方を尋ねる質問なら、何を重視するかによって分かれる選択肢を示す方が自然です。

例えば「予約管理サービスはどれがよいですか」への答えを、機能の多さだけで決めるのは難しいでしょう。受付担当が毎日触るなら操作のしやすさ、既存予約が多いなら移行方法など、この記事で扱う選び方を先に示します。

答えを書く順番に迷ったら、次の四つを一行ずつ下書きします。

• 質問への直接の答え。
• その答えが当てはまる対象や条件。
• 読者が行う最初の操作や確認。
• 詳しい説明があるページや資料。

その後、重なる内容をまとめて自然な段落へ直します。四つの項目を毎回箇条書きで公開するという意味ではありません。答えの抜けを見つけるための下書きです。

条件をすべて括弧へ押し込むと、最初の答えだけを読んだ人が誤解することがあります。利用できるプランが限られるなら、可否と同じ段落で説明します。料金が別途必要なら、手順の最後まで伏せず、利用を判断するところへ置きます。

記事の編集画面では、まず元の本文を控えます。普段の編集機能に履歴や下書き保存があるなら、それを使います。公開中の記事を直接編集する場合は、変更前の文と変更日時を別の文書へ残しておきます。

続いて、質問に関係する節へ小見出しと答えを挿入します。記事の一番下へ機械的に足すのではなく、読者がその疑問を持つ場所を選びます。移行の可否なら導入の説明、追加費用なら料金の説明の近くが候補です。

使う編集サービスによってボタン名は異なります。ここでは特定の「更新」ボタンを押せば終わるとはせず、そのサービスの下書き・プレビュー機能で表示を確認してから公開します。

確認するのは、見出しが本文に紛れていないか、答えが直下にあるか、表の文字がスマートフォンで読めるか、リンクが正しい説明へ開くかです。入力欄での見た目と、公開ページでの表示は別に確かめます。

FAQの構造化データを先に作る必要はありません。 構造化データは、ページの内容を機械が読み取りやすい形式で伝える付加情報です。Googleは、AI機能への掲載に特別な構造化データを要求していません。使う場合も、表示される本文と内容を一致させます。[3]

このGoogle検索向けの説明を、すべてのAIサービスの仕様として広げないようにします。まず整えるのは、読者がページの文字として読める答えです。

図を付ける場合も、重要な条件は本文へ残します。例えば「添付ファイルは移せない」という条件を、画像内の小さな注記だけへ入れないようにします。図は、本文の条件を読み飛ばしてもよい理由にはなりません。

公開後は、編集画面を離れて実際のURLを開き直します。ログインしていない人にも答えが表示されるか、PCとスマートフォンの両方で確かめます。案内リンクが別のログイン画面や古い説明へつながっていないかも見ます。

次の表に沿って、見つかった状態から次の作業を選べます。

公開画面で見つかった状態	次にすること
追記した文が表示されない	保存先と公開状態を確認し、配信の反映を確かめる
答えはあるが条件が別の節へ離れている	誤解しやすい条件を答えの近くへ移す
料金ページと記事の説明が食い違う	現行条件を担当者へ確認し、両方をそろえる
画像の中だけに重要な説明がある	同じ内容を本文の文字にも書く
次の操作へ進むリンクが見つからない	操作名が分かる文言で、適切な案内先へリンクする
内容も表示も確認できた	変更日とURLを残し、継続確認へ進む

編集を他の人へ引き継ぐ場合には、完成文だけでなく、確認済みの条件も一緒に渡します。文章を読みやすくする段階で、製品担当が付けた条件が消えてしまうのを防ぐためです。

例えば、移行に関する文なら、「予約日時と予約者名に対応」「添付ファイルは対象外」「指定形式を使う」の三つが意味の中心です。言い回しを変えても、この三つが残っているかを照合します。

依頼文は、次のように作れます。角括弧の部分は自社の情報へ置き換えます。

対象記事は［公開URL］です。導入を検討する担当者が、既存の予約を移せるか判断できるようにします。
［移行の説明がある見出し］へ、確認済みの質問と回答を追記してください。対応する情報、対象外の情報、利用条件は削らず、短い段落へ分けてください。
料金や機能の新しい説明は推測で足さず、不明な点は確認事項として返してください。公開前に、現在の料金ページと移行手順へのリンクも確かめます。

この依頼は人にも文章作成AIにも使えます。AIへ渡す場合も、個人の予約情報や問い合わせ本文を丸ごと貼る必要はありません。公開できる質問と、確認済みの回答だけで修正案を作れます。

出来上がった案は、初めて読む人の順番で点検します。「予約情報を移せます」という最初の答えを読んだ直後に、対象外の情報まで分かるか。準備するファイルの説明を読んだ後に、どの資料へ進めばよいか。その順番で追うと、単語の誤りだけでは見つからない説明の飛びを確認できます。

記事を一本直した後に他の記事へ広げる場合も、完成したFAQをすべてへ貼り付けません。同じ移行条件を説明する必要があるページを確認し、短い案内で足りるところは詳しい手順へリンクします。各ページに別々の条件を書き写すほど、仕様が変わったときの更新箇所も増えます。

反対に、そのページを読まないと判断できない条件は、リンクだけへ任せないようにします。移行できない情報があることは選定記事にも短く書き、詳しいファイルの作り方を手順ページへ案内する、といった分担です。

ここまでで、記事を直す作業はいったん完了です。「AIに紹介されるまで公開作業を続ける」と考えると、どこで編集を終えるか決められません。文章の公開確認と、その後の紹介・訪問の観測を分けておきます。

追記後は、AI経由の登録率を他の流入経路と比べる

公開後は、AIでの紹介、サイトへの訪問、登録を別々に記録します。登録率は、同じ条件で集めた経路別の数から計算します。

説明用の図です。画面や作業記録は実物ではありません。

例えば、AIの回答に記事へのリンクが付いたとしても、その回答を読んだ人が実際にクリックしたかは、その回答だけでは分かりません。サイトへ来ても、その場で登録するとは限りません。

そこで、記事の改善を一つの数字で評価せず、順番に見ます。

段階	手元へ残すもの	次に考えること
記事を直した	URL、変更日、質問と追記文	読者に必要な答えがそろったか
AIで紹介された	質問、回答、引用先URL、確認日時	追記した説明がどう紹介されたか
訪問があった	期間、参照元、対象ページ、訪問数	紹介されても訪問が増えない状態か
登録があった	同じ期間・定義での登録数	訪問後の案内や申込条件を見直すか

AIがサイトを取りに来た記録も、訪問した人の数とは別です。自動的な情報取得を人の訪問へ混ぜると、登録率の分母が変わります。何を集計対象にしたかを、表の見出しや注記へ残します。

登録率の計算自体は、登録件数を、同じ範囲の訪問数で割る形です。ただし、訪問を「人数」で数えるか「訪問回数」で数えるか、登録をどの訪問へ割り当てるかによって値が変わります。すでに使っている解析の定義を途中で変えず、集計担当とそろえておきます。

次は計算を説明するための架空の数値です。Alchemyの実績や、自社の見込みではありません。

経路	同じ期間の訪問数	登録数	登録数÷訪問数
AIからの参照と識別できた経路	200	10	5%
比較する他の経路	1,000	20	2%

この例では、AI経由の率は他経路の2.5倍ですが、登録件数は10件と20件です。「どちらが多くの登録を生んだか」と「どちらが登録につながりやすかったか」で答えが変わることが分かります。

表計算ソフトなら、訪問数をB列、登録数をC列に置き、D列でCをBで割って割合表示にします。訪問数がゼロの行は、率をゼロと決めず「計算対象なし」と扱います。数を取得できていない場合も、ゼロの代わりに「未取得」と書きます。

AI経由かどうかを特定できない訪問は、無理にAIへ割り当てません。参照元が残る訪問と、アンケートでAIを知ったと答えた人の数は、それぞれ別の列へ置きます。二つを合算すると同じ人を重ねて数える可能性があります。

「同じ期間」の意味も決めておきます。訪問した日で区切るのか、登録が完了した日で区切るのかが違えば、月末をまたいだ登録の扱いが変わります。比較する経路で揃っていれば、どちらの方式を使ったかが後から分かります。

登録の完了地点には、フォームの送信完了やアカウント作成完了など、実際の行動を使います。ボタンを押した回数を登録数の代わりにすると、入力エラーで止まった人まで含む場合があります。すでに計測している項目の定義を、担当者へ確認するところから始めます。

この作業に必要なのは、新しい解析サービスをすぐ契約することではありません。手元の解析と登録記録で、どの範囲なら比較できるかを決めることです。数がそろわなければ、率の比較を急がず、まず記録できる状態を作ります。

少ない件数の変動も、率だけでは大きく見えます。例えば十回の訪問で登録が一件なら10%、二件なら20%です。計算は正しくても、一件の違いだけで安定した傾向と判断するのは難しいでしょう。これは計算の説明用で、成果の予測ではありません。

そのため、報告には率と一緒に元の件数を残します。「20%に改善」とだけ書くより、「訪問十回・登録二件。前回は訪問十回・登録一件」と書けば、読む人も変化の大きさを判断できます。

比較期間を延ばす場合は、途中の製品変更や計測変更を記録します。長く集計すれば何でも比較しやすくなるわけではありません。登録フォームを変えた日をまたぐなら、その変更があったことを表に添えます。

率の平均にも注意します。訪問十回の週と、千回の週の登録率を単純に足して二で割ると、訪問規模を無視した値になります。複数期間をまとめる場合は、同じ定義の訪問数と登録数をそれぞれ合計してから割ります。記録の段階で元の件数を残しておく理由の一つです。

数字が変わったときも、次に直す場所を一つずつ選びます。紹介は増えたが訪問が増えないなら、どの質問のどの回答で紹介されたかを見直します。訪問はあるのに登録が少ないなら、記事から申込先へ進めるか、対象条件が伝わっているかを確認します。

AIからの訪問だけを特別扱いするより、同じページへ来た他経路の読者も含めて、案内の分かりにくさを探す方が取り組みやすいでしょう。料金が分からない、申込先が見つからない、といった問題は、流入元を変えても残る可能性があります。

変更日と対象URLを残し、同じ質問で繰り返し確認する

一度のAI回答ではなく、質問と条件を残して繰り返し見ます。 記事を直した日だけの結果では、変化が続いているか判断できません。

最初の確認では、この記事を直すきっかけになった質問を使います。予約管理の例なら、「今の予約を移せる予約管理サービスを選ぶとき、何を確認しますか」といった質問です。これは編集上の確認例で、顧客が実際にAIへ入力した内容を取得したものではありません。

利用しているAIサービスを開き、機密情報を入れずに質問します。回答の内容とリンクを保存し、リンク先を実際に開いて、どのページが紹介されたかを記録します。自社が紹介されなかった結果も残します。

質問を毎回都合よく変えると、記事の変化と質問の違いを分けられません。まず同じ文で確認し、新しく試す質問は別の行にします。自社名を含めた質問と、会社名を含めない質問も混ぜずに記録します。

記録項目	予約管理の例で残す内容
対象ページ	実際に修正した記事のURL
変更内容	移行対象と対象外の情報を追記
変更日	公開画面への反映を確認した日
質問	入力した文をそのまま保存
AIと利用条件	サービス名、表示されるモデル名、検索の利用有無
確認日時	日付と時刻
回答の状態	自社への言及、引用リンク、説明の正誤
訪問・登録	同じ定義で集計した期間と件数

同じ質問でも回答は変わり得るため、確認日は複数設けます。例えば、公開時に基準となる記録を残し、その後は担当者が続けられる間隔で見直します。この間隔は運用上の決め方で、何日待てば成果が出るという期限ではありません。

変化を読み取るときは、同じ期間に行った別の作業も見ます。料金の変更、広告、営業施策、製品の発表が重なっていれば、登録数が増えた理由は記事の追記だけとは限りません。変更の一覧があれば、説明できる範囲と分からない範囲を分けられます。

自社の情報が紹介されたときは、良い結果として保存するだけでなく、内容も読みます。移せない添付ファイルまで移せると説明されていれば、本文で対象外の条件を見つけやすくできるかを検討します。AIの誤りを直ちに制御できるとは限りませんが、自社ページの説明不足は修正できます。

紹介されなかったときも、すぐに文章量を増やす必要はありません。今回の質問に記事が答えているか、読者が利用する言葉で説明しているか、根拠や条件がそろっているかを先に読み直します。引用先を詳しく調べたい場合は、競合がAIに引用されているページを調べる方法を参照してください。

AIO対策の全体像から確認したい場合は、AIOとは何かと、自社サイトを点検するAIO対策チェックリストも使えます。この事例でまず試すのは、過去記事一本の、まだ答えがない質問への追記です。

最初の成果物は、質問、確かめた答え、公開したURL、変更日がそろった記録です。その記録を出発点に、紹介、訪問、登録を別々に追えば、次にどの記事の何を直すかを考えられます。