東浩紀「データベース消費」をヒントに、LLM時代のBtoBコンテンツ戦略を考える

BtoBマーケティングは過渡期に入っています。生成AIの登場によって情報収集のあり方が大きく変わってきています。

今、BtoBマーケティングでは如何に生成AIに選ばれるコンテンツを作成するのか？というトピックが盛り上がっています。

これらの課題を解決するヒントが、2001年に哲学者・東浩紀が提唱した「データベース消費」の中にあるのではないと考えています。さらに言えば、ChatGPTをはじめとするLLM（大規模言語モデル）が普及した今こそ、この考え方の重要性が増しているのでないか？。

「生成AIの物事の理解って、データベース消費と似てない？」という筆者の思いつきから始まったコラムですが、かなり本質的な問いなのではないかと考えています。

90年代のオタク文化から生まれた「データベース消費」という概念を、BtoBマーケティング、特にコンテンツ制作に応用する方法を解説します。

データベース消費とは何か

「大きな物語」から「データベース」へ

東浩紀が『動物化するポストモダン』（2001年）で提唱した「データベース消費」は、もともとオタク文化を分析するために生まれました。

かつて人々は「大きな物語」を求めていました。例えば、アニメや漫画なら壮大な世界観やストーリー、深いテーマ性といった全体的な構造を重視していたのです。『機動戦士ガンダム』のような作品が典型例でしょう。

しかし、1990年代以降、消費者の態度が変化します。人々は作品全体の物語よりも、個別の「萌え要素」に反応するようになったといいます。

萌え要素のデータベース

東浩紀は、この変化を「データベース消費」と名付けました。

例えば、こんな要素群を想像してください：

• アホ毛（頭のてっぺんから飛び出た髪の毛）
• 猫耳
• メイド服
• ツンデレ（最初はツンツンしているが、徐々にデレデレする性格）
• 眼鏡
• ツインテール

これらは、アニメキャラクターを構成する「パーツ」のようなものです。

消費者はこれらの要素を組み合わせることで、自分好みのキャラクターを見つけたり、創作したりします。

重要なのは、背後に壮大な物語がなくても、これらの要素の組み合わせだけで人気が出るという点です。

デ・ジ・キャラットと初音ミクの事例

具体例を見てみましょう。

デ・ジ・キャラットは、1998年にブロッコリーのイメージキャラクターとして誕生しました。このキャラクターは当初、背景となる物語を一切持っていませんでした。しかし「猫耳」「鈴」「語尾に『にょ』をつける」といった萌え要素の組み合わせだけで人気を獲得し、後からアニメ化され、物語が後付けされたのです。

初音ミクも同様です。2007年に発売された音声合成ソフトのイメージキャラクターに過ぎなかった初音ミクは、「ツインテール」「ネギ」「16歳」「身長158cm」といった設定（萌え要素）だけが与えられ、物語は存在しませんでした。

それにもかかわらず、ユーザーたちは自由に二次創作を行い、ニコニコ動画を中心に爆発的な人気を獲得しました。東浩紀自身も、初音ミクの消費のされ方を「データベース消費そのもの」と評しています。（出典：Wikipedia - データベース消費）

二層構造：表層と深層

東浩紀は、データベース消費を理解するために二層構造モデルを提示しました。

• 深層（データベース層）：萌え要素が蓄積されたデータベース
• 表層（シミュラークル層）：データベースから要素をピックアップして組み合わせた個別の作品

消費者は表層の作品を見ているようでいて、実は深層のデータベースにアクセスし、自分の好きな要素を見つけ出しています。そして、その要素の組み合わせ次第で、作品の人気が決まるのです。

この構造は、BtoBマーケティングにおいても極めて重要な意味を持ちます。

LLMの情報処理メカニズム：2つの核心

ここで視点を変えて、LLM（大規模言語モデル）の仕組みを見てみましょう。ChatGPTやClaude、Geminiといった生成AIの基盤技術であるLLMは、どのように情報を処理しているのでしょうか。

LLMの基本的な仕組み

LLMは、膨大なテキストデータを学習し、人間のような自然な文章を生成するAIモデルです。その処理は次のステップで行われます：

1. トークン化：入力されたテキストを小さな単位（トークン）に分割
2. ベクトル化：各トークンを数値データ（ベクトル）に変換
3. 自己注意機構：トークン間の関連性を計算
4. 重み付け：重要な情報により高い重みを割り当てる
5. 出力生成：ベクトルをテキストに変換して出力

この中で特に重要なのが、「属性による絞り込み」と「文脈での重み付け」という2つのメカニズムです。

メカニズム1：属性による絞り込み

LLMは、キーワード、タグ、カテゴリーといった属性情報を手がかりに、膨大なデータの中から関連する情報を絞り込みます。

例えば、ユーザーが「クラウド型で、API連携可能で、ISO27001認証を取得しているMAツールを教えて」と質問したとします。

LLMは次のように属性で絞り込みます：

• 属性1：クラウド型
• 属性2：API連携可能
• 属性3：ISO27001認証取得済み
• カテゴリ：MAツール

この絞り込みプロセスは、データベースから条件に合致するレコードを抽出するSQL検索に似ています。

メカニズム2：文脈での重み付け

しかし、属性だけでは不十分です。LLMはトランスフォーマーアーキテクチャの中核である自己注意機構（Self-Attention）を使って、文脈に基づいた重み付けを行います。

同じ「セキュリティ」という属性でも：

• 「金融機関向けの事例」という文脈では、より高い重みが与えられる
• 「中小企業の導入事例」という文脈では、重みが調整される

この重み付けにより、LLMは単なるキーワードマッチングを超えた、文脈を理解した回答を生成できるのです。

IBMの解説によれば、LLMは「数十億または数兆の重みを設定できる」パラメータを持ち、トークン間の関係に重みを割り当てることで、データの処理方法と予測方法を制御しています。（出典：IBM - 大規模言語モデル（LLM）とは）

データベース消費との類似性

ここで、データベース消費理論とLLMの仕組みを対比してみましょう：

この対応関係を理解することが、LLM時代のコンテンツ戦略を考える上で決定的に重要になります。

BtoBマーケティングへの応用：萌え要素=サービス属性

パラダイムシフト：物語からデータベースへ

従来のBtoBマーケティングでは、「ブランドストーリー」「企業理念」「ビジョン」といった大きな物語が重視されてきました。

しかし、顧客の情報収集行動は変化しています。特にLLMの普及により、顧客は次のように行動します：

1. AIに具体的な条件（属性）を提示して検索
2. 複数の選択肢を比較検討
3. 属性の組み合わせで意思決定

この行動パターンは、まさにデータベース消費そのものです。

萌え要素 = BtoB企業のサービス属性

ここで重要な読み替えを行います。

具体例を見てみましょう：

SaaS型MAツールの「サービス属性」例

• クラウド型 / オンプレミス型
• API連携対応
• 多言語対応（日本語、英語、中国語など）
• セキュリティ認証（ISO27001、SOC2、プライバシーマークなど）
• 料金体系（月額固定、従量課金、ユーザー数課金など）
• 無料トライアル期間
• サポート体制（24時間365日、日本語対応など）
• 導入実績（業界、企業規模など）
• 機能（スコアリング、シナリオ設計、ABテストなど）

製造業向けIoTソリューションの「サービス属性」例

• エッジコンピューティング対応
• 既存設備との互換性
• リアルタイム監視機能
• 予知保全AI搭載
• オフライン動作可能
• 工場内ネットワーク対応
• データ保持期間
• カスタマイズ対応範囲

顧客は、これらの属性（萌え要素）の組み合わせで、自社に最適なソリューションを探しているのです。

顧客は物語ではなく、属性の組み合わせで選ぶ

重要なポイントは、顧客は企業のビジョンや創業ストーリーよりも、自社の課題を解決できる属性の組み合わせを求めているという事実です。

もちろん、ブランドストーリーが無意味というわけではありません。しかし、意思決定の優先順位において、具体的な属性が上位に来るのが現実です。

特にLLMを使った情報収集では、この傾向が顕著です。AIは抽象的なビジョンよりも、明確な属性情報を優先して処理するからです。

サービスページと事例の戦略的重要性

データベース消費とLLMの仕組みを理解すると、なぜサービスページと事例コンテンツが決定的に重要なのかが明確になります。

サービスページ：「データベース」としての機能

サービスページは、単なる商品説明ではありません。属性データベースとして機能させる必要があります。

NGなサービスページの例

【従来型のサービスページ】
「弊社のMAツールは、お客様のマーケティング活動を革新します。長年の経験と最新技術を組み合わせ、真のデジタルトランスフォーメーションを実現します。」

このような抽象的な表現は、人間にもLLMにも伝わりません。

良いサービスページの例

【データベース型のサービスページ】

■ 基本仕様
・提供形態：クラウド型（SaaS）
・対応言語：日本語、英語、中国語（簡体字・繁体字）
・データセンター：国内（東京、大阪）
・稼働率：99.9%（SLA保証）

■ セキュリティ
・ISO27001認証取得
・SOC2 Type2準拠
・プライバシーマーク取得
・データ暗号化：AES-256

■ 連携機能
・API：RESTful API、Webhook対応
・連携実績：Salesforce、HubSpot、kintone、Slack、Zoom

■ 料金体系
・初期費用：0円
・月額費用：50,000円〜（連絡先件数による従量課金）
・無料トライアル：14日間

後者は、LLMが属性として認識し、絞り込みに使える情報が明確に記載されています。

構造化データの重要性

さらに効果的なのは、Schema.orgなどの構造化マークアップを使って、機械可読な形式で属性情報を提供することです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "○○ MAツール",
  "applicationCategory": "Marketing Automation",
  "offers": {
    "@type": "Offer",
    "price": "50000",
    "priceCurrency": "JPY"
  },
  "featureList": [
    "API連携",
    "多言語対応",
    "ISO27001認証"
  ]
}
</script>

このような構造化データは、検索エンジンだけでなく、LLMにとっても理解しやすい形式です。

事例コンテンツ：文脈を提供し、属性に重みをつける

一方、事例コンテンツは文脈を提供する役割を果たします。

属性だけでは、「どの属性がどのような状況で重要なのか」がわかりません。事例コンテンツは、この文脈情報を補完します。

効果的な事例コンテンツの構造

【事例コンテンツのテンプレート】

■ 企業プロフィール
・業種：製造業（自動車部品）
・従業員数：500名
・導入部門：マーケティング部（5名）

■ 導入前の課題
・展示会で獲得したリードのフォローが手作業で非効率
・営業とマーケティングのデータが分断
・リードの優先順位付けができない

■ 選定理由（重要な属性）
・Salesforceとの双方向連携が可能 ← 属性1
・日本語サポートが充実 ← 属性2
・スコアリング機能が柔軟 ← 属性3
・中小企業でも導入可能な価格帯 ← 属性4

■ 導入後の成果
・リードフォロー時間：80%削減
・商談化率：2.5倍に向上
・マーケティングROI：150%改善

■ 担当者の声
「特にSalesforce連携の精度が高く、営業が最新情報をリアルタイムで確認できるようになった点が大きい」

この事例は、「Salesforce連携」という属性に対して、製造業の中小企業というコンテキストで高い重みを与える情報を提供しています。

LLMがこの事例を学習すると、「製造業」「中小企業」「Salesforce利用」というクエリに対して、該当サービスを高い関連性とともに提案できるようになります。

データベース消費における二層構造の再現

ここで改めて、データベース消費の二層構造を思い出してください：

• 深層（データベース層）：サービスページに記載された属性情報
• 表層（シミュラークル層）：事例コンテンツで示される、属性の組み合わせと文脈

顧客（そしてLLM）は、この二層を行き来しながら、最適なソリューションを見つけ出します。

まとめ：データベース消費時代のBtoBマーケティング

物語からデータベースへのシフト

BtoBマーケティングは、「大きな物語」から「データベース」へとシフトしています。

顧客は、もはや企業のビジョンや創業ストーリーだけで意思決定をしません。彼らは具体的な属性（スペック）の組み合わせを求めています。

そして、LLMの普及により、この傾向はさらに加速します。

データベースを構築せよ

東浩紀の「データベース消費」が示唆するのは、コンテンツマーケティングの本質的な役割の転換です。

これは、決して「情緒を排除せよ」という意味ではありません。むしろ、属性という土台の上に、文脈という情緒を載せるというアプローチです。

LLMが理解できる形でのコンテンツ設計

最も重要なのは、LLMが理解できる形式でコンテンツを設計することです。

LLMは今後、顧客の情報収集プロセスにおいて中心的な役割を果たします。あなたのサービスページや事例コンテンツが、LLMに正しく理解され、適切な文脈で顧客に提案されなければ、競争に勝てません。

そのために必要なのは：

1. 属性の明示：サービスページでの具体的なスペック記載
2. 文脈の提供：事例コンテンツでの活用シーン提示
3. 構造化：機械可読な形式での情報整理

あなたのサービスは「データベース」として機能しているか？

最後に、自社のコンテンツを見直してみてください。

• サービスページに、明確な属性が記載されていますか？
• 事例コンテンツは、文脈を提供していますか？
• LLMがあなたのサービスを「発見」し、顧客に「提案」できる形になっていますか？

もし答えが「No」なら、今すぐ改善を始める時です。