AI可視性のレポートの作り方｜代理店向け顧客報告
代理店がクライアントにAI検索での成果を報告するときのレポートの構成を解説します。最初に書く判断、範囲と日付、件数と分母、回答の例、実施した改善、注意点の書き方を、そのまま使える構成案つきで紹介します。
AI可視性のレポートでは、何を確認し、何が変わり、次に何をするのかをクライアントに示します。 プロンプトの文章、日付、集め方、保存した回答、各指標の分子と分母を載せ、分かったことを実施したページの改善と次の作業につなげます。注意点は1か所にまとめて、はっきり書きましょう。
クライアントが下すべき判断から始める
レポートの目的は、クライアントが役に立つ作業を承認できるようにすることです。最初に、いちばん影響の大きい発見、その根拠、おすすめの対応を書きます。「保存した回答で、前払いのルールが間違って説明されています。製品ガイドの修正を承認してください」と書けば、クライアントは具体的に判断できます。
最初の要約は、元の回答を確認したあとに書きます。主な発見は1つ、補足の観察は2つまでにしましょう。クライアントに必要なのが、変更の承認なのか、足りない製品の情報の提供なのか、終わった作業の確認だけなのかを書き、詳しい根拠はすぐ下に置きます。
報告する問いは、契約の最初にクライアントと決めておきます。分野の中で見つけてもらえるか、競合との比較でどう紹介されるか、機能が正しく説明されているか、などです。レポートの見出しには、クライアントの事業、市場、言語を書き、載せる数字はすべて、その問いに答えるものにします。
範囲と日付を結果の横に書く
報告の期間、比べる期間、最後に回答を集めた日を書きます。使ったAIの画面、表示される場合はモデル、検索のモード、地域の設定も記録します。プロンプトの一式にはバージョンを付け、クライアントの名前を含むプロンプトと、名前を出さずにおすすめを聞くプロンプトを分けましょう。
予定した確認の数、得られた回答の数、失敗の数を一緒に示します。失敗は、タイムアウト、回答の拒否、途中で終わった回答などに分け、もう一度試したことと、その扱いのルールも書きます。こうすることで、確認する人が、集めた記録とレポートの数字を照らし合わせられます。
サーチコンソールのデータを載せる場合は、その集計の期間を別に書きます。Googleは、クリック数、表示回数、掲載順位をそれぞれ定義しています。元のレポートとフィルタも残し、AIの回答の記録とは分けて示しましょう。
割合の前に件数を示す
言及率は「クライアントの名前が出た回答の数÷得られた回答の数」と定義します。1つの回答で名前が何回出ても、1回と数えます。順位を報告する場合は、おすすめの順番なのか、最初に名前が出た順番なのかを書き、計算の対象になった回答の数も示しましょう。
シェア・オブ・ボイスを報告する場合は、比べるブランドの一覧と数え方を書きます。引用元を報告する場合は、ページの数、ドメインの数、リンクを含む回答の数のどれを数えたのかを書きます。要約、表、根拠で同じ定義を使いましょう。計算の例はLLMOの効果測定で紹介しています。
次の表は、example.co.jpの架空の例です。どちらの期間も、同じ10個のプロンプトを、同じ方法で4回ずつ集め、すべての確認で回答が得られたとします。数字は書き方の例で、実際の顧客の結果ではありません。
| 項目 | 2026年8月1日〜28日 | 2026年9月1日〜28日 | レポートでの書き方 |
|---|---|---|---|
| 得られた回答 | 予定40件中40件 | 予定40件中40件 | 同じ範囲を確認 |
| example.co.jpの名前が出た回答 | 40件中12件 | 40件中18件 | 名前が出た回答が6件増加 |
| 言及率 | 30% | 45% | 15ポイントの上昇 |
| プロンプトのバージョン | 第1版 | 第1版 | 同じ10個のプロンプトと集め方 |
元の行は、要約の横に残しておきます。15ポイントは45%から30%を引いた差です。「15%の上昇」と書くと、別の計算の意味になってしまいます。グラフ、コメント、説明の場で、同じ言い方を使いましょう。
発見を説明する回答の例を載せる
自社の名前が出た回答、関係する競合が出た回答、対応が必要な問題を示す回答を選びます。回答の全文は付録に残し、抜粋の横には、プロンプトの文章、確認した日、集め方を書きます。
それぞれの例を選んだ理由も書きます。たとえば、「製品のページに書いてある返金の条件が、回答では抜けている」のようにです。そのページにリンクし、理解に必要な部分だけを引用します。
例を選ぶルールは毎月同じにします。良くなった回答があれば、変わらなかった回答や良くない回答も載せましょう。根拠には番号を付け、クライアントが要約から元の回答にすぐたどり着けるようにします。
発見を改善と担当につなげる
変更の記録には、ページのURL、問題、承認された変更、公開日、担当する役割を書きます。提案中の修正と公開した修正は分けます。製品の担当者の確認を待っている下書きも進捗ですが、ページが実際に変わるまでは「対応待ち」の欄に入れましょう。
それぞれの修正に、対象のプロンプトと、正しい情報の出どころを結び付けます。たとえば、返金のルールを分かりやすくする修正なら、承認されたルールと、見直しのきっかけになった回答を示します。次の確認は、同じプロンプトの文章と、記録した方法で予定しましょう。
そのまま使えるレポートの構成
次の構成を、自社のレポートの形式にコピーして使えます。要約は、打ち合わせの前に読み終えられる長さにし、詳しい方法と根拠はその後ろに置きます。
- 判断の要約：主な発見、おすすめの対応、必要な承認
- 範囲：ブランド、市場、言語、日付、集め方、プロンプトのバージョン
- 確認の状況：予定した確認、得られた回答、失敗の種類、もう一度試した確認
- 結果：件数、分母、定義、比べられる期間の変化
- 回答の例：選んだ理由、プロンプトの文章、抜粋、根拠の番号
- 実施した作業：ページの変更、公開日、裏付けとなる製品の情報
- 解釈の注意点：確認した範囲、足りない根拠、比べるときの注意
- 次の作業：優先順位、担当、必要な前提、確認の日程
- 付録：回答の全文、返された引用元URL、計算の表、変更の記録
続けられる頻度にする
社内では週に1回、確認の失敗、判定の誤り、急いで直すべき事実の問題を確認します。クライアントとは月に1回、決まったプロンプトの一式、終わった作業、次の判断について話し合います。これは出発点の目安なので、クライアントの更新のペースに合わせて調整しましょう。
Anthropicは、まったく同じ入力でも、出力が変わることがあると説明しています。予定した繰り返しの確認を続け、その記録も残しましょう。打ち合わせの前には、レポートの合計を照らし合わせ、おすすめの根拠に使ったすべての回答を開いて確認します。
注意点は1か所にまとめる
レポートが表しているのは、確認したプロンプトと条件での結果で、すべての顧客が見ているものではありません。APIとブラウザでは結果が違うことがあります。少ない数や偏った回答、集め方の変更は、比較を弱めます。返された引用元のリンクだけでは、訪問や売上が起きたとは言えません。また、変更の前後の違いだけでは、ページの修正が原因とは言えません。足りない根拠と、それが判断にどう影響するかも、ここに書きましょう。
SearchSeal は、AIによる概要、ChatGPT、Gemini、Perplexityで、登録した質問の回答を毎日保存し、ブランドの言及、順位、競合、返された引用元URLを記録します。代理店はREST APIで、質問と確認日が付いたままの記録をJSONで書き出し、自社のレポートに使えます。週次レポートのメールで、毎週の変化も確認できます。
よくある質問
レポートの最初のページには何を書けばよいですか？
主な発見、それを支える件数や回答の例、おすすめの対応、クライアントに必要な判断を書きます。報告の期間と、元の根拠への行き方も示しましょう。
回答の例はどう選べばよいですか？
発見に結び付いた、書面のルールで選びます。良い例、良くない例、変わらなかった例を含め、それぞれにプロンプトの文章、日付、集め方、保存した回答を付けましょう。
打ち合わせの前に何を確認すべきですか？
件数と分母を照らし合わせ、比べる期間で同じプロンプトと集め方を使っているかを確認します。公開日も確認し、おすすめの根拠に使ったすべての回答を開いておきましょう。