- 顧客は、Webサイトを開く前にAIに尋ねるようになっています。自社の情報がはっきりしていなければ、AIは代わりに競合を勧めます。
- AIが選ぶのは、そろっていて確かめられる情報です。きれいな宣伝文句はあまり効きません。
- まずは、価格、条件、実際に提供できる内容を、すべてのチャネルでそろえるところから始めてください。
1. 「検索 → 比較 → 決定」という顧客の流れが1つにまとまるかもしれない
以前の顧客は、価格を比べるために10ものWebサイトを開いていました。今はAIに1回尋ねるだけで、絞り込まれた3つの候補が手に入ります。その3つに入っていなければ、顧客が自社のWebサイトを目にすることは一度もありません。
AIは候補を集め、レビューを要約し、条件を比べ、状況に合わせて勧めることができます。顧客の一部は、頭の中に候補の短いリストを持った状態で、購入までの道のりの後半になってからWebサイトを訪れるようになるでしょう。検索順位や広告だけに頼っている企業は、質問にもっとはっきり答えている情報源に居場所を奪われるかもしれません。
これは予測で、Webサイトやブランドがなくなるという話ではありません。リスクが高い買い物、高価な買い物、好みが分かれる買い物では、これからも体験と信頼が判断を左右します。ただ、商品を見つける段階と比べる段階では、AIの手を借りる場面が増えていくでしょう。
2. AIは、はっきりしていて確かめられる情報をもとに選ぶ傾向がある
AIが選ぶのは、広告がいちばんうまいブランドより、情報がそろっていて矛盾のないブランドです。Webサイトの価格と見積書の価格が違えば、システムは説明しやすい競合のほうを選びます。
押さえるべき情報は、商品名と商品コード、仕様、価格、在庫、対応エリア、返品ポリシー、保証、レビュー、成果の裏づけです。Webサイト、マーケットプレイス、PDFのあいだで情報が食い違っていると、AIはその情報への確信を下げたり、説明しやすい競合を選んだりするかもしれません。

「最高の」のような大まかな言葉に頼ったマーケティングコンテンツは、基準や出典の裏づけがなければほとんど価値がありません。公平な比較表を作り、自社の商品が向いているケースと向いていないケース、最終更新日を書いておきましょう。透明性は、機械にとっても人にとっても判断の助けになります。
| 情報 | 準備ができている形式 | よくある問題 |
|---|---|---|
| 商品 | 標準の項目とID | チャネルごとに名称が違う |
| 価格 | 通貨、税、適用期間 | 古いページがまだ検索で見つかる |
| 裏づけ | 出典、サンプル、日付 | 根拠のない主張 |
| ポリシー | 条件と例外が明確 | あいまいな表現 |
3. ブランドの語り口を損なわずに、機械が読めるブランドをつくる
開発チーム向け · 技術的な詳細
商品情報管理(Product Information Management)、つまりすべてのチャネルが使う共通のデータを整えます。スキーマ、メタデータ、更新できるAPIやフィードを用意し、正となるデータ(Source of Truth)を決めて、Webページをそこから生成します。こうすると、内容の食い違うバージョンが減ります。

事実の層(Fact Layer)と物語の層(Story Layer)を分けます。事実は機械がはっきり読み取れるようにし、物語は人の感情に訴えて意味を伝える役割を担います。両者の内容は一致していなければなりません。FAQは実際に寄せられた質問から作り、顧客が使う言葉で書きます。重要な詳細を、画像や開きにくいファイルの中に隠さないようにします。
- 商品・サービスごとの専用ページと、変わらないURL
- 価格、条件、最終更新日
- 構造化データとフィード
- 比較表、FAQ、ユースケース
- タイ語版と対象言語版で内容がそろっている文章
4. コンテンツの量産から、裏づけづくりへ
AIがコンテンツを要約できるようになると、ありきたりな記事をどれだけ量産しても差はつきにくくなります。背景、導入前後の変化、測定方法、限界、顧客の声をそろえた導入事例に投資しましょう。汎用的なモデルが固有のデータを持たない、踏み込んだ質問に答える専門的なコンテンツも作ります。
レビュー、問題への対応、主要なプラットフォーム上の会社情報といった評判に関わるデータも手入れしておきます。偽のレビューを作ったり、データを水増ししたりしてはいけません。システムが複数の情報源を突き合わせる精度は上がっていますし、信頼が損なわれたときの痛手は大きいからです。
商品について打ち出す主張は、すべて承認の仕組みに通し、責任者、出典、有効期限を記録します。裏づけが変われば、修正が必要なコンテンツをシステムが知らせます。AIが最初のふるい分けを担うようになると、信頼性が大きな資産になります。
5. AIが勧めた後は、その場で成約まで進める体験にする
勧められてから行動に移るまでの手順を減らします。たとえば、顧客の条件に合った構成の画面に直接つながるURLを用意する、理由なく価格を変えない、複雑な商談には人に相談できる窓口を設ける、といったことです。顧客が共有に同意した状況は引き継ぎ、最初からすべて説明し直させないようにします。

顧客が提案を調整し、比較し、総額をはっきり確認できるようにします。複雑な商品には、汎用的なチャットボットで済ませず、自社のデータをもとに答える対話型のアドバイザーを用意すべきです。人への引き継ぎは、要約とSLAをつけて設計します。
6. 顧客のエージェントが自社のシステムにアクセスしてくる日に備える
開発チーム向け · 技術的な詳細
将来は、エージェントがAPIを通じて価格、在庫、予約、ステータスを確認するようになるかもしれません。企業は、マシン同士のアクセス(Machine-to-Machine)に備えて、認証、レート制限、スコープ、監査の仕組みを用意すべきです。情報を求めるだけのエージェントと、取引を行うエージェントは区別して扱います。

注文、住所変更、キャンセルのように結果を伴う操作には、リスクに応じて、代理権限の証明と確認の手順が必要です。人と機械の両方が読める受領記録を発行し、取り消しや異議申し立ての手段も用意します。「顧客の代わりに操作している」というメッセージを、確認できるIDなしに信用してはいけません。
7. 効果測定の軸は、クリックから影響と成果へ移る
開発チーム向け · 技術的な詳細
AIがWebサイトに来る前に答えてしまうので、売上が落ちていなくてもトラフィックは減るかもしれません。AIの回答の中でブランドが言及される回数(Brand Mention)は慎重に追いかけつつ、より重視するのは、購入意欲のある訪問(Qualified Visit)、アシストコンバージョン、フィードやAPIの利用状況、実際の顧客が自社を選んだ理由と選ばなかった理由です。
実験を設計します。商品情報と裏づけを手直しし、コンバージョンとサポートへの問い合わせ件数を測ります。1つのプラットフォームのダッシュボードだけを信じず、自社で計測(ファーストパーティ計測)を行い、顧客にどこでブランドを知ったかを尋ねます。
8. 12か月の準備計画
- 第1四半期:商品情報、価格、FAQを監査し、食い違いを洗い出します。
- 第2四半期:正となるデータ、構造化データ、主張ライブラリ(Claim Library)を整えます。
- 第3四半期:裏づけとなるコンテンツを制作し、勧められてから購入するまでの流れを改善します。
- 第4四半期:パートナーやエージェント向けに、範囲を限ったフィードやAPIを試験提供します。IDの確認と効果測定の仕組みもあわせて用意します。
まとめ:AIが顧客との間に入る場面が増えるなら、ブランドは、わかりやすく、確かめられて、取引しやすくなければなりません。コンテンツの量産だけに頼らず、共通のデータ、裏づけ、人への引き継ぎの体験を整えましょう。信頼できる情報源になっている企業は、顧客が商品を見つける経路が変わっても、勧められる機会があります。
自社の商品情報を、人にも機械にも読めて信頼できるものにする
商品、価格、保証条件、対応エリアについての正確な情報は、社内の製品チーム、営業部門、サービス部門が持っています。足りないことが多いのは、全員が「これが正しい版だ」と認める1つの置き場所です。そこでDNA Makerは、データごとに誰が責任者か、どの頻度で更新するか、食い違ったときにどれを優先するかを決めるお手伝いから始めます。そのうえで、仕様、価格、在庫、返品ポリシー、成果の裏づけなど、顧客の質問に答えられるだけのデータを構造化し、事実の層とブランドの物語の層を分けます。
1つのデータをすべてのチャネルに届けるシステム
私たちが作るのは、たいてい共通の商品情報管理システムです。Webサイト、マーケットプレイス、取引先向けのフィードやAPIとつなぎ、すべてのチャネルが同じ情報源からデータを取るようにします。Webページには外部のシステムが読み取れる構造化データを入れ、勧められてから購入するまでの道のりを、事業として許容できる範囲で最短にします。効果を測る仕組みも最初から組み込み、候補を決めた状態で訪れた顧客の成約が増えているかを確かめられるようにします。Webサイトの価格と見積書の価格がいまも食い違っているなら、その話からご相談ください。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
ここに挙げる用語は、事業のデータを人にもほかのシステムにも読める形にすることに関わるものです。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| Structured Data | 自由な文章の形をとらず、機械が理解できるよう標準の形式に整えたデータ | 商品ページで、価格と在庫状況を標準の形式で記述する | 自社の重要なページには、機械が読める形のデータがそろっていますか? |
| API | 外部のシステムが、自社のシステムにデータを求めたり処理を依頼したりするための標準的な窓口 | 取引先がファイルを送ってもらう代わりに、APIで最新の価格と在庫を取得する | 誰が利用できますか?利用の上限と本人確認はどうなっていますか? |
| Product Information Management | すべてのチャネルに向けて、正となる商品データを保管する共通のシステム | 価格を1か所で直せば、Webサイトとマーケットプレイスにも反映される | 2か所のデータが食い違ったら、システムはどちらを優先しますか? |
| Feed | 商品データを更新するために、送り先へ定期的に届けるファイルやデータの流れ | 外部のチャネルに、商品一覧を1時間ごとに送る | フィードが失敗したら、送り先は古いデータをどれくらいの間使い続けますか? |
| Conversion Rate | 訪問者のうち、顧客になった人や目標とする行動をとった人の割合 | おすすめからクリックした人のうち、実際に購入した人は何%か | どの時点からどの時点までを測っていますか?重複する利用者はどう除いていますか? |
