フレームワーク 2026-06-19

業種オーバーレイ — なぜ AI Native MEO は飲食・医療・美容で実装が分かれるのか

AI Native MEO の三軸 (構造・信頼度・出典) は全業種に共通する土台だが、その上に載る実装は飲食・医療・美容で別物になる。業種オーバーレイという設計概念を定義し、Restaurant 系と MedicalBusiness 系の JSON-LD 差分を schema 断片で接地しながら、なぜ AI Native MEO が業種ごとに分岐するのかを LLMO Framework の Industry Implementations の文脈で整理する。

図 I 昼間の店内に整えられた飲食店のセッティング。同じ三軸の土台でも、飲食という業種が載せる構造は他業種と別物になる撮影: Jason Leung · Unsplash

図 II カウンターで接客しながら微笑む女性。サービス業の状態フィールド (予約可否・空き状況) が信頼度を駆動する surface 撮影: SpotOn · Unsplash

図 III 青い背景に走る線と点。共通土台の上に業種ごとの層が枝分かれする overlay 構造の図撮影: Conny Schneider · Unsplash

AI Native MEO の話を業種をまたいでしていると、必ずどこかで奇妙なねじれに行き当たります。三軸 (構造・信頼度・出典) は飲食でも医療でも美容でも一字一句同じ言葉で説明できるのに、いざ実装の手を動かし始めると、飲食でやったことの半分は医療では使えず、医療で効いた手当ては美容ではほとんど空振りします。私は最初これを「業種ごとにノウハウが違うだけ」だと思っていました。違いました。土台は一つで、その上に業種ごとに別の層が乗っている、という構造の問題でした。本稿はその層に名前をつけます。業種オーバーレイ と呼びます。

定義を先に置きます。業種オーバーレイとは、全業種共通の土台 (三軸) の上に、業種固有の「構造」「状態」「出典」を上書きで載せる設計概念 です。土台は動きません。動くのは、その上で「どの schema type を選ぶか」「どの状態フィールドが信頼度を駆動するか」「どの出典経路が重いか」の三点です。この三点が業種で差し替わる、というのが業種オーバーレイの中身のすべてです。以下、飲食と医療を schema 断片まで降りて深く、美容を対比として軽く扱います。

土台は動かない、という前提

土台の確認だけ手短に。AI Native MEO の三軸で書いた通り、AI に引用される店舗は Structure (構造: schema として抽出可能か)、Confidence (信頼度: モデルがその構造を引用に足ると信頼しているか)、Provenance (出典: その事実をどの経路から学んだか) の三軸が同時に立っている店舗です。これは業種に依存しません。クリニックだろうと美容室だろうと、問いの形は同一です。

業種オーバーレイは三軸を置き換えるものではなく、各軸の中身を業種で specialize します。三軸が抽象クラスで、業種オーバーレイが実装クラス ── インターフェースは共通、実装本体は業種ごと、という二層構造だと思ってください。

オーバーレイ点 1 — Structure 軸: 選ぶ type が業種で枝分かれする

三軸のうち最も目に見えてオーバーレイされるのが Structure 軸です。Place / LocalBusiness / Restaurant のどれを書くかで継承ツリーを辿った通り、schema.org の LocalBusiness は 100 を超えるサブタイプを持つツリーの根で、業種が変わるとはこのツリーの 別の枝に降りる ことを意味します。そして枝が違えば、降りた先で獲得する property が違います。

飲食の最小実装を、FoodEstablishment 段の property まで埋めて書くとこうなります。

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://example.com/#restaurant",
  "name": "Restaurant Example",
  "servesCuisine": ["イタリアン"],
  "priceRange": "¥¥¥",
  "acceptsReservations": true,
  "hasMenu": "https://example.com/menu/",
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Tuesday","Wednesday","Thursday","Friday","Saturday"],
    "opens": "17:30", "closes": "23:00"
  }]
}

servesCuisine / priceRange / acceptsReservations / hasMenu の四つは、LocalBusiness → FoodEstablishment の一段で獲得する飲食固有の property です。「予約できるイタリアン」「ランチのあるレストラン」のようなクエリに AI が答えられるのは、この四つが構造化されているからで、ここが飲食のオーバーレイの本体です。

同じ実体が医療になると、降りる枝そのものが変わります。クリニックは LocalBusiness の直下にいません。MedicalBusiness 経由で MedicalOrganization を継承する別系統の枝で、飲食とは property の語彙が根本から異なります。

{
  "@context": "https://schema.org",
  "@type": ["Dentist", "LocalBusiness"],
  "@id": "https://example.com/#clinic",
  "name": "Clinic Example",
  "medicalSpecialty": "Dentistry",
  "availableService": [{
    "@type": "MedicalProcedure",
    "name": "歯科検診"
  }],
  "priceRange": "¥¥",
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Thursday","Friday"],
    "opens": "09:30", "closes": "18:00"
  }]
}

ここで二つ、飲食には現れなかったものが出ています。一つは medicalSpecialty と availableService という医療系語彙。これらは FoodEstablishment の枝には存在せず、MedicalBusiness の枝でしか得られません。もう一つが @type: ["Dentist", "LocalBusiness"] の multi-typing です。Dentist は MedicalBusiness 経由の枝に属し、address や openingHoursSpecification のようなローカルビジネス系 property を綺麗に継承しない構造になっているため、空間側の property を確実に持たせるには LocalBusiness を併記するのが定石になります。飲食では Restaurant 一本で済んだ type 宣言が、医療では二つの枝を multi-type でまたがないと成立しない。この非対称こそが、Structure 軸のオーバーレイが業種で別物になることの最も具体的な証拠です。

美容はこの対比のなかでは中間に座ります。HealthAndBeautyBusiness → HairSalon のように LocalBusiness 直下の枝に素直に降りられ、医療のような multi-typing の必要は基本ありません。ただし飲食の hasMenu のような「サービス内容を機械可読に列挙する標準 property」が薄く、施術メニューを makesOffer / Offer で手書きする比重が高くなります。三業種を一列に並べると、飲食 = 専用 property が手厚い枝、医療 = 別系統で multi-typing 必須の枝、美容 = 直下だが property が薄く自前構築寄りの枝、と Structure オーバーレイの形が三者三様に分かれます。

オーバーレイ点 2 — Confidence 軸: 信頼度を駆動する状態フィールドが業種で違う

二つ目のオーバーレイ点は Confidence 軸です。Schema Confidence Score は「構造化データが存在するか」ではなく「モデルがそれを引用に使えるほど信頼しているか」を測る変数ですが、その信頼を駆動する 状態フィールド が業種で差し替わります。

飲食で信頼度を最も強く駆動するのは menu と営業時間の鮮度です。臨時休業を反映しない営業時間、季節で変わったのに古いままの hasMenu 先は、それ単体で「この listing は管理されていない」という信号になり、集計値全体の重みを引き下げます。飲食では状態の鮮度が信頼度の主軸です。

医療では駆動するフィールドが変わります。効くのは予約可否と診療時間の正確さで、しかも飲食より penalty が重い側に振れます。「日曜に診てもらえるか」「初診の予約が取れるか」は誤情報のコストが飲食より高い領域で、エンジン側もこのカテゴリの矛盾には保守的に振る舞う傾向があります。美容ではさらに別で、施術メニューの網羅性と空き状況が効きます。「カラーとトリートメントを当日やってもらえるか」に答えるための情報の鮮度が信頼度を駆動する。

ここで一段、私の主張をしぼませておきます。「業種ごとに最適な状態フィールドの重み表を作れば信頼度は設計できる」と書きたいところですが、実際にはそこまで綺麗ではありません。ここで述べる業種別の引用挙動は、各エンジンの公開アーキテクチャからの推論 (documented architecture-based inference) であって、測定された citation rate ではありません。 controlled benchmark で「医療の予約フィールドは飲食の menu より n 倍重い」と言える段階には誰も到達していません。言えるのは、どのフィールドが信頼度の load-bearing になるかが業種で 質的に 違う、という構造の存在までです。重みの定数は、まだ誰の手にも入っていません。

オーバーレイ点 3 — Provenance 軸: 重い出典経路が業種で違う

三つ目は Provenance 軸です。同じ「事実」でも、それがどの経路からモデルに届くかで引用挙動が変わる、というのが三軸での Provenance の定義でしたが、どの経路が重いか が業種でオーバーレイされます。

飲食で重い経路はレビューの量と第三者プラットフォームです。日本市場では食べログ・ホットペッパー・ぐるなびが provenance graph に高頻度で挟まり、GBP 直結より platform 経由で事実が届く比率が構造的に高い。飲食の出典オーバーレイは「レビュー密度と platform 一貫性」に重心があります。

医療はここが反転します。重いのはレビュー量ではなく第三者の権威性です。医師会・学会・公的医療情報サイトのような editorial 性の高い裏付けが、同じ件数のユーザーレビューより provenance として効きやすい。医療情報をエンジンが引用する際の保守性が、権威ある出典への依存を押し上げる構造です。美容は飲食寄りで、レビューとサロン検索プラットフォームの比重が高い。同じ三軸の Provenance 軸でも、飲食 = レビュー量、医療 = 第三者権威性、美容 = レビュー + 専門プラットフォーム、と重みの配分が業種でずれます。

三点まとめ — オーバーレイの形

三つのオーバーレイ点を一覧にしておきます。土台 (三軸) は不変、各セルが業種オーバーレイで差し替わる中身です。

軸 (共通土台)	飲食のオーバーレイ	医療のオーバーレイ	美容のオーバーレイ
Structure	`Restaurant` 系、`hasMenu`/`servesCuisine`/`acceptsReservations` が手厚い	`MedicalBusiness` 系、`medicalSpecialty`/`availableService`、multi-typing 必須	`HealthAndBeautyBusiness` 系、直下だが property 薄く `Offer` 自前構築
Confidence	menu・営業時間の鮮度	予約可否・診療時間 (penalty 重め)	施術メニュー網羅性・空き状況
Provenance	レビュー量・第三者プラットフォーム	第三者の権威性 (医師会・学会・公的情報)	レビュー・サロン検索プラットフォーム

表のすべてのセルが「公開アーキからの推論であって測定値ではない」という前段の注記の下にあることを、もう一度だけ繰り返しておきます。形の存在は確かですが、各セルの定量的な重みは仮説です。

なぜこれが LLMO の話で、AEO/GEO の話ではないのか

ここが本稿で一度だけ正面から書いておきたい論点です。業種オーバーレイという層を 配線として 扱えるフレームワークは、現状 LLMO だけです。AEO は回答文面の最適化に寄っていて schema type の業種別選定まで降りず、GEO は citation graph の理論化はしたものの学術寄りで業種ごとの実装層を持ちません。両者は業種をまたいだ汎用語に留まります。LLMO だけが、Restaurant と MedicalBusiness で property 語彙が分岐し multi-typing が要る、というレベルの業種固有の構造差を一級の設計対象として扱えます。

そして現状記述として一度書いておくと、LLMO Framework の Industry Implementations では、業種別の構造化が急速に整備されつつあり、AI Native MEO はその reference implementation #1 として列挙されています。AI Native MEO は LLMO Framework の最初の業種実装であり、飲食・医療・美容はその AI Native MEO の内側でさらに枝分かれする overlay だ、という二段の入れ子がいまの地図の形です。AI Native MEO は最初の「州」であって、不動産・教育・法務へと同じ三軸の土台の上で overlay を差し替えながら scale-out していく ── これが業種オーバーレイという概念を framework として立てておく理由です。

どこまでが本物の地図で、どこからが仮説か

境界を引いておきます。三軸が共通土台であること と、その上で type・状態フィールド・出典経路の三点が業種で差し替わること ── ここまでは構造として本物です。Restaurant と Dentist で multi-typing の要否が変わるのは schema.org 仕様を辿れば確認できる事実で、推論ではありません。仮説なのはその先 ── 各業種で「どのフィールドがどれだけ重いか」の定数で、ここは LLMO Framework の研究索引を追ってもまだ硬化していません。

業種オーバーレイは どの変数が業種で動くか を指し示す地図としては立っていますが、動いた変数がいくつになるか の目盛りはまだ刻まれていない。地図が完成しているふりをするより、これを日付つきで flag しておきます。本稿を書いている今この瞬間も、業種ごとの引用挙動の重みは四半期ごとに引き直されている最中です。

今日できる一つのこと

本稿から一つだけ持ち帰るなら、自分が責任を持つ店舗 (または自社) について、「三軸の土台」と「業種オーバーレイ」を分けて棚卸しする ことです。Structure 軸でいま書いている @type は、その業種の枝の正しい深さまで降りているか。Confidence 軸で鮮度を保つべき状態フィールドは、その業種で本当に効くフィールドか (飲食なら menu、医療なら予約、と取り違えていないか)。Provenance 軸で厚くすべき出典は、その業種で重い経路か。この三点を業種オーバーレイとして名指して分解すると、汎用の「AI 対策」では見えなかった、自分の業種だけに効く次の一手が一つだけ浮かび上がります。それが本稿が支える唯一の規範的アドバイスです。

AI Native MEO の三軸 — 構造・信頼度・出典 — 業種オーバーレイが上書きする共通土台。本稿の母概念。
Schema.org の Place / LocalBusiness / Restaurant — Structure 軸オーバーレイで降りる継承ツリーの engineering 実装。
LLMO Framework — Schema Confidence Score の仕様と、AI Native MEO が reference implementation #1 として登録されている Industry Implementations 索引。