Prefer

Prefer は買い手が実際に聞く質問を投げ、回答に自社ブランドが出たか、隣にどの競合が並んだか、何番目に挙がったかを記録する。ダッシュボードは結果をペルソナ別・地域別に分けるので、価格重視の買い手向けの回答と大企業向けの回答を別々に点検できる。プロンプトごとに履歴が残り、本当の伸びとモデルの一時的な不調を切り分けられる。

穴はすべてタスクになり、賭けている可視性、引用を取る見込み、必要な工数の 3 つで採点される。Prefer は点数の内訳を開示するので、納得できなければ順番を組み替えられる。タスクには担当区分が付く。エージェントが実行できるもの、支援するもの、自社チームが担うものだ。次のクロールでプロンプトの位置が動いたと確認できるまで、キューは閉じない。

エージェントは技術面から着手する。クロールの遮断や構造化データの欠落は修正が安く、欠落のまとまった原因になっていることが多いからだ。robots.txt を直し、構造化データを追加し、エンジンが探しているページを起草する。こちらは 1 件ずつ確認して承認する。開発の手を借りずにページ単位の作業を進められるようになったという顧客の証言が、サイト上に少なくとも 1 件ある。

コンテンツはキーワードではなくプロンプトから始まる。Prefer が記事や比較ページを書き、勝つべきプロンプトに照らして採点し、承認後に CMS へ公開する。草稿はモデルがすでに信頼している情報源を引用する。エンジンが読む内容と一致するページは引用されやすいという、実務的な近道である。

監査では、回答エンジンが引用する前に必要な条件を確認する。各ボットのアクセス、インデックス可能なページ、機能している構造化データ、文脈を正しく渡す内部リンクだ。損害は平易な言葉で示される。たとえば商用ページ 12 枚が 2 つのクローラーから見えていない、といった具合だ。修正に時間を割く前に期待値を確認できるので、開発者に「なぜ必要か」を説明しやすい。

Prefer は MCP サーバーを用意している。Claude や Cursor から、今週のタスクを取ったり、プロンプトが落ちた理由を尋ねたりできる。API は可視性データを自社のダッシュボードへ送り、Looker Studio と CSV 出力は多くのチームがすでに使うレポート環境をカバーする。計測側では Search Console、Google Analytics、Bing Webmaster Tools、DataForSEO、Cloudflare、Vercel が同じワークスペースにつながる。