AI可視性監査: ツール購入前に行う手動ワークフロー

AI可視性の監査は、ダッシュボードや自社名の検索から始める必要はありません。読者が実際にする学習や購入の問いを、小さく繰り返せる形で集めるところから始めます。目的は総合スコアを作ることではありません。回答がブランドを正確に位置づけているか、どのページが根拠になっているか、競合がどの基準で扱われているか、そして自社サイトのどの変更が意味を持つかを見つけることです。

小さなチームでは、手動の手順が最初に向いています。正確な質問、言語、出典、ページの担当者を決める必要があるからです。この作業を飛ばすと、後で多くのchartを持つツールを買っても、何を追い、どの結果で行動するかが決まりません。

GoogleのAI機能は通常のSearchの基盤の上にあり、回答製品ごとに出典の見せ方も同じではありません。そのため監査は、見えた証拠を残します。見えないランキングの仕組みを推測することが目的ではありません。本稿の手順は2026年7月12日に確認しました。

三つのシグナルを混ぜない

多くのreportはすべてを「AI visibility」と呼びます。しかし、改善の判断には少なくとも三つに分ける必要があります。

シグナル	中心の問い	証拠	よくある作業
回答への登場	ブランドや概念が言及されるか	保存した回答と位置	カテゴリ説明、positioningを改善する
情報源としての登場	特定URLがlinkまたはcitationされるか	URL、publisher、ページ種別、文脈	出典、表、鮮度、構造を改善する
事業への寄与	その露出は本当に役立つか	Web流入、ブランド需要、lead、sales/supportのfeedback	conversion pathを改善するか優先度を下げる

この三つは同時には動きません。名前だけ出ても読者はページを開かないことがあります。URLが引用されても質の高い訪問につながらないことがあります。日本語の質問で英語docsが使われることもあります。一つの数にすると、この違いが消えます。

Prompt inventoryを作る

keywordのリストではなく、読者の仕事で質問を分けます。

問いの型	例	助けるべきページ	確認すること
定義	「AI可視性とは何か」	概念ページ	直接性、用語、確認できる説明
比較	「AI visibilityとSEOは何が違うか」	比較ページ	境界、コスト、向かない場合
ツール購入	「SaaSはAI monitoring toolの前に何を見るか」	購入ガイド	製品名の列挙ではなく基準
Workflow	「小さなチームはAI回答をどう手動監査するか」	checklist	繰り返せる手順と出力
製品の事実	「製品Xはこのintegrationを支援するか」	製品・docsページ	最新の事実と出典
日本市場	「日本のB2BチームはAI引用をどう確認するか」	日本語のガイド	稟議、security、support、導入

テーマごとに五から十問を選び、一つの監査周期では同じ表現を保ちます。新しい発見の質問は別に保存します。promptと市場が毎週変わるなら、回答の違いを読むことはできません。

他の編集者も再現できるEvidence Record

項目	記録する内容	解釈に必要な理由
観察時刻	日付、時刻、タイムゾーン	回答、index、製品情報は変化する
Engineと入口	製品名、必要ならlogin状態、分かる範囲の地域	featureと結果が異なる場合がある
正確なprompt	編集せずに保存	小さな言い換えでも回答が変わる
言語と市場	ja-JP、en-USなど	英語の結果は日本の結果を代替しない
回答全文	text、screenshot、または両方	scoreでは言い方と省略が分からない
ブランドの扱い	実際の表現と位置	一覧にあることと推奨は違う
引用URL	URL、publisher、ページの型	どの根拠が使われたか分かる
競合	名前と結びついた強み	読者に見えるカテゴリの枠が分かる
足りないもの	出典、表、例、FAQ、制約、手順	観察をページ作業に変える
次の行動	一つの変更、owner、再確認	受け身のreportにしない

六週間後に別の編集者が同じ問いを見た時、最初の観察が何を意味したかを追える必要があります。「見えた」は再現できる記録ではありません。

四週間の監査手順

週	作業	得るもの	判断
1週目	テーマ、市場、競合、固定質問を決める	prompt inventoryとaudit sheet	曖昧な質問を除く
2週目	対象engineと対象言語で回答を保存する	回答、出典、競合の基準	価値の高い三つの不足を選ぶ
3週目	不足ごとに一つのページを直す、または不足したページ型を作る	出典とownerを持つchange log	多くの変数を同時に変えない
4週目	同じ質問を繰り返し、Web、conversion、feedbackを見る	前後の一覧	仮説を継続、調整、終了する

四週間でcitationが必ず変わるという意味ではありません。crawl、製品変更、answer engineの更新は別の時間軸を持ちます。それでも、一度に多くのページを変えて、何を学んだか分からなくなることを防ぎます。

日本語の販売ページと英語docsを分けて確認する

日本のB2B SaaSでは、日本語の製品ページがsalesと稟議を支え、英語のAPI docsが実装を支えることがあります。この二つの役割を監査で混ぜません。

問い	期待する情報源	確認点
「製品は何を解決するか」	日本語の製品・概念ページ	対象者、用途、security、supportの範囲
「APIをどう設定するか」	保守されている英語または日本語docs	command、version、owner
「稟議に合うか」	日本語の購入判断ページ	契約、地域、SSO、承認、窓口
「代替案は何か」	公平な比較ページ	基準、制約、根拠のある説明

日本語の問いで英語の情報源が出ること自体は問題ではありません。その英語ページが日本の購買やsupportの問いに答えられない、または日本語ページが必要な事実を持っていない時に、改善の対象になります。

監査の終わりはcontent backlog

優先度	ページ	観察	具体的な変更
高	比較ページ	競合が自社にない基準で引用される	一次情報、fit matrix、non-fit caseを加える
中	日本語の製品ページ	回答が古い機能を説明する	事実、確認日、現在のdocsへのlinkを直す
中	ローカルガイド	日本語workflowの問いで英語だけが出る	日本の手順、FAQ、内部リンクを補う
低	用語ページ	ブランドは出るが定義が曖昧	冒頭を直し、関連ページへつなぐ

「AI可視性を上げる」は作業になりません。「日本語のintegration pageにSCIM、SSO、データの扱いの表を加え、同じ稟議の問いで再確認する」は作業になります。

よくある失敗

ブランド名だけを調べると、良い結果に見えやすくなります。質問が少なければ比較や購入の段階が抜けます。prompt、ページ、engineを同時に変えれば、次の回答から学べません。linkだけを数えれば、認知、情報源、質の高い需要の違いを見落とします。

そして、screenshotのために書かないことです。長く役立つ回答の存在は、明確な文章、更新された事実、読めるtext、適切な出典、判断に役立つ比較、正直な次の行動から生まれます。監査は不足を見つけますが、それ自体が内容の代わりにはなりません。