LLMO対策の支援で売上34％増と報告。海外代理店JDMは何を商品にした？

LLMO対策を支援サービスにしたら、代理店の仕事と売上はどう変わるのか。

Profoundが紹介したJordan Digital Marketing（JDM）の事例では、AEO支援が新しい顧客の獲得につながり、代理店の売上が34％増えたと報告されています。ここで増えたのは、顧客企業のAI経由売上ではなく、支援する代理店自身の売上です。[1]

気になるのは、どのツールを導入したかだけではありません。調査結果を、顧客に渡せる仕事へどう変えたかです。

この記事では公開された事例を紹介したうえで、日本の制作会社やSEO支援会社が一社から試すための作業計画、修正依頼の書き方、費用の考え方をまとめます。後半の提案書や金額の例は、本記事で作った説明用のもので、JDMの契約内容ではありません。

LLMO対策の支援で売上34％増。JDMの事例

この事例は、AI検索向けの支援をサービスに加えた代理店の事業成長を扱っています。顧客の検索成果と、代理店の売上・利益を分けて読むことがポイントです。

JDMはどんなSEO支援会社か

JDMは、SEOや広告などのマーケティング支援を行う会社です。Profoundの事例では、検索行動の変化を受け、顧客企業がAIの回答でどのように扱われるかを調べる必要が生まれたと説明されています。[1]

支援会社にとっては、検索順位の報告に加えて、新しい質問へ答える場面が増えたと考えると分かりやすいでしょう。「AIがおすすめを聞かれたとき、自社の商品は紹介されるのか」という質問です。

ただし、この質問への回答を作るには、調べる条件を決める必要があります。どのAIへ、どんな質問を、いつ行ったかを残さず、表示されたかどうかだけを報告しても、翌月と比べにくくなります。

売上34％増と利益約2倍の意味

Profoundは、AEO支援による新規顧客の獲得などに伴い、JDMの売上が34％増え、利益がおよそ2倍になったと報告しています。売上額や比較期間の詳細は、同資料に示されていません。[1]

この数字を日本の支援会社の売上予測へ、そのまま当てはめることはできません。契約単価、既存顧客、担当者の経験、ツール費用が異なるためです。

自社で見るべきなのは、受注額と、仕事を納めるために必要な費用の両方です。売上が増えても、調査や修正の往復が増えれば、利益が同じように増えるとは限りません。

試す際には、見積もった時間と実際の時間を残します。調査、原稿修正、確認、報告に分けると、次の見積もりを修正する材料になります。

顧客のAI可視性0％→80％は別の成果

同じ事例には、ある顧客の関連する質問で、AI可視性が0％から80％になったという報告もあります。これは代理店全体の売上増とは別の指標で、全顧客や全質問の平均ではありません。[1]

支援レポートでも、顧客の成果は顧客の欄に置きます。代理店の受注数が増えたことを、顧客の問い合わせが増えた根拠として使わないようにします。

例えば、回答への登場状況が改善しても、サイトへの訪問が確認できない場合は、そこで区切って報告します。「紹介を確認」「流入は未確認」「問い合わせは計測なし」と分ければ、次に整える計測が分かります。

一つの数字へまとめないことが、説明を弱くするわけではありません。どこまで確認できたかが分かると、顧客が次の予算を判断しやすくなります。

AEOとLLMO対策の呼び方を整理する

この記事では、AIの回答に商品やサービスの情報が適切に参照されるよう、内容や計測を整える支援をLLMO対策として扱います。JDMの出典が使う呼び方はAEOです。

呼び方を契約名に使う場合は、それだけで作業内容が伝わるとは考えない方がよいでしょう。同じ名称でも、回答の観測だけを行う支援と、記事の修正や公開まで行う支援では範囲が違います。

提案書には、名称のすぐ下へ具体的な仕事を書きます。「質問を決める」「回答と引用URLを記録する」「対象ページの修正案を作る」「公開後に再確認する」といった内容です。

顧客が知りたいのは、何と呼ぶかより、何を頼めて、何が手元に残るかです。初回の打ち合わせでは、対象サービスと納品物まで一緒に説明してください。

JDMがLLMO対策を支援サービスにした流れ

公開資料では、一社で試し、AIが参照するページや質問を調べ、支援対象を広げた流れが紹介されています。[1] 以下では、その事実と、自社で試す際の考え方を分けて説明します。

既存顧客1社から試した理由と範囲

JDMは、一社でProfoundを試してから対象を広げています。実際の試験期間、担当人数、社内の採算基準までは公開されていません。[1]

自社で試験導入するなら、対象を一社に絞ることで、調査結果が既存の仕事の流れに入るかを確認しやすくなります。これは本記事の提案です。

最初の顧客は、担当者へ質問でき、商品資料を受け取れ、ページを修正する窓口がある会社を候補にします。調査できても公開する担当がいないと、改善の工程を試せないためです。

対象範囲は、一つの商品群やサービスへ絞ります。会社全体の情報を一度に整理するより、よくある質問と答えるページを具体的に対応させられます。

AIが引用するページを調べた

JDMの事例では、ブログ、商品ページ、購入ガイドなど、AIが引用する内容を調査したと説明されています。[1]

自社で調べる際も、ドメイン名の一覧だけで終えず、引用先のページを開きます。同じ会社のサイトでも、料金ページを参照する場合と、第三者による比較記事を参照する場合では、回答に使われる情報が異なるためです。

記録には、ページのURL、タイトル、扱う質問、確認した説明を残します。引用元の文章を大量に複製するのではなく、自社のページに何が足りないかを短く書きます。

また、リンク先が現在も公開されているかを確認してください。AIの回答にURLがあることと、そのページが開けて内容を確かめられることは別です。

顧客の質問から記事の対象を決めた

事例では、AIで尋ねられる質問の調査を、作るコンテンツの対象選びへつなげています。[1] 自社で同じ考え方を使うなら、まず顧客の営業やサポートが受けている質問を集める方法があります。

例えば業務用の予約システムなら、「導入できる業種」「既存の予約を移せるか」「担当者ごとの予定を分けられるか」などです。これらは説明用の想定で、実際の質問数を調べた結果ではありません。

質問ごとに、既存ページで答えられるか、新しい説明が必要かを判定します。既に十分な回答があれば、同じ内容の記事をもう一本作るより、見つけやすく整理する方が適している場合もあります。

最初の成果物は、質問と回答先URLの対応表です。記事のタイトルだけを先に増やすことを避けられます。

SEO支援にAEOを組み込んだ

公開資料では、AEOがJDMのSEO支援と組み合わされるようになったと説明されています。[1]

既存のSEO支援がある会社なら、調査や原稿確認をまったく別の運用にせず、どの工程を共用できるかを見ると始めやすくなります。商品資料の確認や、公開時のリンク確認などは、従来の作業と重なる部分があります。

一方、AIの回答を観測する条件や、回答に出ることと流入の違いを説明する資料は、新たに必要になるかもしれません。その作業を無料の付帯業務として曖昧にせず、契約範囲と担当を決めます。

サービスを組み合わせる場合も、通常検索の順位と、AIでの言及・引用の結果は分けて記録します。異なる数字を一つの改善率として顧客に見せないようにします。

LLMO対策を1社で試す作業計画

ここからは、支援を始める会社向けに本記事で作成した実践案です。JDMの非公開の作業手順ではありません。まず、対象、質問、記録、完了条件を決めます。

顧客の商材と問い合わせ先を一つ選ぶ

最初の打ち合わせでは、売りたい商材と、顧客が最終的に進んでほしいページを確認します。問い合わせフォームなのか、予約画面なのか、商品購入なのかを一つ決めてください。

そのうえで、価格、仕様、契約条件を確認できる資料と、内容に答えられる担当者を集めます。担当者の記憶だけでなく、現在公開してよい情報を確認することが重要です。

決める項目	記入例
対象サービス	法人向け予約管理サービスA
読者	導入を検討する店舗責任者
次の行動	サービス説明を読み、相談フォームへ進む
事実を確認する担当	商品責任者
ページを直す担当	Web担当者

表の例は架空のものです。自社の初回資料では実名とURLへ置き換え、対象が広すぎる場合は、業種や用途を一つに絞ります。

LLMO対策で調べる質問を決める

質問は、購入までの判断を想像しながら用途、比較、導入条件へ分けます。数を増やすより、質問ごとに調べる理由が説明できることを優先します。

予約管理サービスなら、「複数店舗で予約を管理したい」「スタッフごとに予定を分けたい」「今使っている表から移せるか」といった候補を作れます。営業担当に、実際の商談で出る疑問と近いかを確認してもらいます。

質問の一覧には、主な対象読者、関連するページ、確認したい点を付けます。検索ボリュームを使う場合も、Googleの検索数とAIへの質問数を同じものとして扱わないようにします。

最初の観測後に質問を変更するなら、変更日と理由を残してください。都合のよい回答が出るまで質問を書き換えた結果を、継続的な改善として報告しないためです。

AIの回答と引用URLを保存する

回答の記録には、サービス名、表示されるモデル名、質問全文、日時、利用条件、回答、引用URLを残します。モデル名が画面で分からない場合は「非表示」とし、推測で埋めません。

ファイルを作るなら、案件用フォルダの下に日付ごとのフォルダを置き、質問番号で揃える方法があります。例として、client-a/2026-10-01/q01.txtのような保存名です。

表計算側には次の列を用意します。

質問ID / サービス / モデル表示 / 確認日時 / 質問全文
自社への言及 / 引用URL / 回答の保存先 / 確認者 / 備考

一回の回答が市場全体を代表するとは限りません。再確認する日と条件を決め、履歴を残します。また、調査のために顧客の非公開情報をAIへ入力する必要はありません。公開済みの商材説明と一般的な質問から始められます。

試験導入の完了条件を決める

試験導入の完了は、AIに一度名前が出たことだけでは決めません。調査、修正案、公開確認、報告という仕事を一通り納められたかを確認します。

例えば、「合意した質問を記録」「改善対象のページを選定」「一ページ分の修正案を提出」「承認後の公開を確認」「結果と次の課題を報告」という条件です。

日程と一緒に、顧客からの資料提供や確認が必要な日も書きます。回答待ちの期間と、支援側の作業時間を分けると、遅れの原因を説明しやすくなります。

完了時には、担当者がその資料を使って次の修正を判断できるかを聞いてください。結果を眺めるだけのレポートになっていたら、対象URLや修正案が足りない可能性があります。

LLMO対策の分析を、ページ修正へつなげる

調査を納品物にするには、どのページの何を直すかまで具体化します。ここでは、顧客の資料を根拠に、一ページ分の修正依頼を作ります。

顧客のページに答えがあるかを読む

調べた質問ごとに、顧客のページを開いて答えを探します。見つかった場合も、答えがどこにあるかと、条件が明記されているかを確認してください。

例えば「複数店舗で使えるか」という質問に、トップページで「事業の成長を支援」と書かれているだけでは、具体的な対応範囲を判断できません。機能資料で確認できるなら、対応店舗数や管理権限の説明へつなげます。

調査表の判定は、答えがある、説明が足りない、情報が古い、確認できない、のように分けると便利です。「悪いページ」と一括りにするより、修正の内容が見えます。

また、説明が画像の中だけにある場合は、読者が拡大せず読めるかも確認します。AIへの対応という理由だけでなく、人がその場で理解できる情報にすることを優先します。

引用された他社ページと比べる

他社ページと比べる目的は、文章を似せることではありません。どの疑問に、どんな根拠で答えているかを確認し、自社の説明に欠けている材料を見つけることです。

比較表には、用途、対象者、料金条件、仕様、更新日、根拠資料など、その商材に必要な項目を並べます。自社に当てはまらない機能を、他社に書いてあるという理由で追加しないようにします。

例えば他社が導入事例を掲載していても、自社に公開許可のある事例がなければ、架空の実績を作ることはできません。代わりに、確認済みの機能説明や、説明用と明記した利用例を充実させる方法があります。

AIが引用したという事実だけで、そのページの説明がすべて正しいとも限りません。比較に使う条件や数値は、公式資料へ戻って確かめます。

1ページ分の修正依頼を作る

修正依頼には、対象URL、答える質問、現在の不足、変更案、根拠、確認する担当を入れます。Web担当者が別の打ち合わせなしでも着手できる具体性を目指します。

以下は架空の予約サービスについての記入例です。

項目	修正依頼の例
対象	店舗向け機能説明ページ
質問	店舗ごとにスタッフの予定を分けられるか
現在の不足	予定を管理できるとだけ書かれている
変更案	管理できる単位と、権限の条件を追記
根拠	最新の機能仕様書の該当箇所
確認	商品担当が条件確認、Web担当が反映

本文案も付けるなら、確認できた事実だけで書きます。未確認の点は原稿内の曖昧な表現で隠さず、確認欄へ分けてください。

依頼の最後には、公開後に見る場所も指定します。本文、目次、表、リンク先を確認すると、原稿では正しくても表示で伝わらない問題を拾えます。

公開後に答えとリンクを再確認する

公開後は、まずサイト側の変更を確認します。下書き画面だけを見て、公開されたと報告しないようにします。

購入者と同じURLを開き、修正した答えが読めるか、目次から移動できるか、関連リンクが正しい場所へ進むかを確認します。スマートフォンでは表や画像の文字が読めるかも見てください。

その後、決めておいた条件でAIへの質問を再確認します。回答に変化がなくても、すぐに原稿が失敗したとは判断できません。公開された内容が読めることと、各AIの回答に反映されることは別の確認です。

報告には、サイトの反映日とAIを確認した日時を分けて記録します。回答が変わった場合も、変更内容だけが原因と断定せず、観測した変化として示します。

LLMO対策の費用と納品物を決める

支援費用は、調査対象の数だけでなく、原稿修正、確認の往復、公開作業を含む範囲から考えます。以下は見積もりの作り方で、市場相場やJDMの価格表ではありません。

初回調査と毎月の運用を分ける

初回には、対象サービスの理解、資料集め、質問の設計、計測状況の確認などが必要です。毎月同じ量が発生するとは限らないため、継続運用と分けて見積もります。

月次の運用では、同じ条件での観測、新しい疑問の確認、対象ページの修正、結果の報告などを範囲にします。初回に作った表を再利用できれば、その分だけ作業を減らせる場合があります。

区分	作業例	納品物の例
初回	商材理解・質問設計・現状確認	調査表・対象URL一覧・作業計画
月次	再確認・修正案・結果整理	変更履歴・修正案・月次報告
別途	大規模なページ制作や実装	合意した設計・原稿・実装

別途になる仕事を先に説明すると、調査契約の中でサイト全体の改修を求められるような食い違いを防ぎやすくなります。

ツール代と人の作業時間を見積もる

費用の計算では、直接のツール代と、人の調査・編集・確認時間を分けます。ツールが回答を集めても、根拠の照合や顧客との調整が自動で終わるとは限りません。

計算例として、月の作業を調査4時間、編集6時間、確認と報告4時間の合計14時間と置きます。社内で見積もりに使う時間単価を5,000円と仮定すると、人の作業分は7万円です。ここへ対象案件に配賦するツール費用などを加えます。

この金額は料金相場ではなく、計算の仕方を示す仮定です。実際には、確認担当の人数や修正回数によって変わります。

試験導入では実績時間を記録し、見積もりとの差を見ます。調査より確認の往復に時間がかかっていたなら、資料の受け取り方や承認者の決め方を見直す余地があります。

原稿作成と公開の担当を決める

原稿を書く人、事実を確認する人、管理画面へ反映する人を決めます。一人が兼ねる場合も、作業の区切りは残しておきます。

支援会社が原稿だけを納める契約なら、公開する担当と公開予定日を顧客に確認します。逆に公開まで担当するなら、必要な権限、確認する画面、変更を戻す方法まで作業範囲に含めます。

「確認をお願いします」だけでは、文章の表現を見るのか、商品の仕様を確認するのかが曖昧です。商品担当には事実、編集担当には読みやすさ、運用担当には表示とリンク、というように役割を分けると進めやすくなります。

承認された版は、ファイル名や更新日時で特定できるようにします。メール添付と共有フォルダに異なる原稿がある場合は、公開に使う正本を一つ決めてください。

保証できる納品物と成果の違い

契約で約束する納品物と、公開後に観測する成果を分けます。調査表や合意した修正案を納めることと、特定のAIに必ず紹介されることは同じではありません。

Googleは、自社のAI検索機能への掲載について、技術的な条件を満たしても表示を保証するものではないと説明しています。[2] これを他社AIの仕様へ広げることはできませんが、少なくともGoogle向けの提案で掲載確約として扱うべきではありません。

提案書では、「合意した質問の回答記録」「対象ページの修正案」「公開確認」「月次報告」といった仕事を具体的に書きます。順位、引用、訪問、問い合わせは、別欄で測定方法を合意します。

顧客の目的が問い合わせ増加なら、フォーム計測まで確認しないと成果判断ができません。調査の納品だけで、その目的を達成したことにはしないようにします。

LLMO支援の月次報告と継続判断

月次報告では、顧客の事業に起きた変化と、支援サービスを提供する側の採算を別々に確認します。両方を見て、広げる範囲を決めます。

顧客の成果を訪問・問い合わせで追う

顧客向けには、AIの回答で確認したこと、サイトへの流入、問い合わせの順に記録します。計測できない箇所は、そのまま未計測として残します。

例えば、ある質問で自社ページの引用を確認した後、そのAIサービスから訪問があっても、同じ質問をした人の訪問かまでは分からない場合があります。回答の観測と、アクセス解析の結果を無理につなげないことが大切です。

問い合わせも、全件をAI施策の成果として扱わず、計測できる範囲と確認条件を示します。計測の詳細を整えたい場合は、AI流入と売上を測るRough Countryの事例で確認方法を紹介しています。

報告の末尾には、次に改善するページを一つ挙げます。数値の一覧だけでなく、次の仕事を判断できる内容にします。

代理店の売上と利益を別に見る

支援側は、契約金額に加え、案件にかかった作業時間と直接費用を確認します。受注が増えても、毎回同じ調査をやり直していれば、担当者の負担が先に増える可能性があります。

案件ごとに、初回の準備、回答の確認、原稿作成、顧客対応、公開作業を分けて時間を記録します。どの工程が増えているかが分かれば、テンプレートや役割分担を見直せます。

ただし、調査結果を顧客間でそのまま使い回しても、商材や質問が違えば役立ちません。共通化するのは記録の形式や確認手順であり、顧客の答えそのものではありません。

継続判断では、顧客に渡せた価値と、無理なく提供できる体制を一緒に見ます。売上の増加率だけで運用が成功したとは決めないことが必要です。

質問や記事を増やす条件を決める

対象を広げる前に、現在の質問とページの確認が回っているかを見ます。確認待ちの原稿が溜まっている場合、記事数を増やしても公開まで進まないためです。

追加する理由には、新商品の発売、営業で増えた質問、既存ページでは答えられない用途などがあります。同じ内容の言い換えだけで記事を増やさず、何を新しく答えるかを示します。

追加候補	先に確認すること
新しい質問	顧客の商材と関係があり、答える根拠があるか
新しい記事	既存ページと内容が重なっていないか
調査するAI	対象読者との関係と、記録できる条件
作業量の増加	確認担当と公開担当が対応できるか

合意した範囲を超える場合は、担当と費用も更新します。質問が増えたことを、無制限の作業を引き受ける理由にしないようにします。

最初の提案書に入れる項目

最初の提案書は、立派な専門用語より、対象と成果物が分かることを優先します。以下の項目を一枚にまとめれば、打ち合わせの出発点になります。

目的：どの商材について、誰の購入判断を助けるか
対象：調査するAI、質問、既存ページ
初回：現状確認、質問とURLの対応表、修正案
月次：同条件での再確認、変更記録、結果報告
担当：事実確認、原稿、公開、最終承認
費用：初回、月次、別途作業、ツールの扱い
測定：引用、訪問、問い合わせをそれぞれどう確認するか
完了：何が納品され、何を確認したら終わりか

作成後は、顧客が「来月、自分たちは何をすればよいか」を説明できるかを確認します。資料提供や原稿承認が必要なら、それも提案の中へ入れてください。

JDMの事例から支援会社が考えたいのは、調査ツールの追加だけではなく、調査から修正、公開、報告までの仕事を組み立てることです。一社でその流れを試し、実際の作業量を把握してから、対象を広げられます。