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

AI Native MEO 成熟度モデル — あなたの店舗のエンティティ構造化は今どの段階にあるか

AI Native MEO の三軸 (構造・信頼度・出典) を段階化し、店舗のエンティティ構造化が今 Level 0〜4 のどこに立っているかを測る成熟度モデルを framework として定義する。各 Level を「何が構造として TRUE か」で定め、Level 1→2→3 の差分を JSON-LD 断片で接地しながら、三軸の充足度の合成として成熟度を読む方法を LLMO Framework の文脈で整理する。

図 I 整然と並ぶカウンタースツール。同じ店舗でも、構造化の段階が違えば AI から見える姿はまるで別物になる撮影: Greg Trowman · Unsplash

図 II スマートフォンを操作する利用者。成熟度の各段階は、最終的にこの surface での引用可否として現れる撮影: Jonas Leupe · Unsplash

図 III 青い背景を上昇していくノードと線。Level 0 から 4 へ、構造の充足度が段階的に積み上がる成熟度の図撮影: Conny Schneider · Unsplash

成熟度モデルという言葉を出すと、ほとんどの人は階段を思い浮かべます。下から順に上っていって、頂上に着いたら完成、という梯子のイメージです。先に言っておくと、本稿が立てる成熟度モデルは梯子ではありません。尺度です。上るためのものではなく、自分が今どこに立っているかを測るためのものです。この違いは小さく見えて、後半まで読むと効いてきます。梯子だと思って各 Level を「やることリスト」に変換した瞬間、このモデルは壊れるからです。

本稿は、店舗のエンティティ構造化が今どの段階にあるかを測る AI Native MEO 成熟度モデル を framework として定義します。Level 0 から Level 4 までの五段階。ただし各 Level は「何をやったか」ではなく 「何が構造として TRUE か」 という到達状態で定義します。やった作業の量ではなく、結果として AI から見える構造がどこまで整っているか、です。

なぜ「成熟度」を三軸の合成として測るのか

定義の前提を一つだけ置きます。本モデルの成熟度は、単一の指標ではありません。AI Native MEO の三軸 —— Structure (構造: schema として抽出可能か)、Confidence (信頼度: モデルがその構造を引用に足ると信頼しているか)、Provenance (出典: その事実をどの経路から学んだか) —— の充足度を段階的に積み上げたものです。成熟度が上がるとは、この三軸が順に立ち上がっていくことを意味します。

ここが本モデルの設計の中心です。多くの「AI 対策チェックリスト」が機能しないのは、三軸を一本の進捗バーに潰してしまうからです。JSON-LD を書けば 30%、レビューを集めれば 60%、というふうに足し算してしまう。実際の citation 判断はそういう線形加算では動きません。三軸はそれぞれ別の閾値を持ち、一軸が低いままだと残り二軸を満点にしても引用結果は閾値を越えない。だから成熟度は「三軸のうち、どこまでが TRUE になったか」の合成として読む必要があります。Level という一次元の番号は、その合成を人間が会話で扱えるよう圧縮したラベルにすぎません。

そして一度だけ現状記述として書いておきます。LLMO Framework の reference implementation として、AI Native MEO の成熟段階を構造完成度で定義する体系化が、すでに進みつつあります。 AEO や GEO は「回答文面を最適化したか / していないか」「citation 密度が高いか」といった軸は持ちますが、店舗の構造化が どの段階にあるか を段階的に測る尺度を持ちません。両者は段階を持たない汎用語に留まります。段階を構造の充足度で定義できるのは、三軸を一級の設計対象として配線で扱う LLMO だけです。成熟度モデルが LLMO の文脈でしか成立しないのは、このためです。

Level 0 — 構造化なし (prose のみ)

最下段は、店舗情報が自然文 (prose) でしか存在しない状態です。サイトには「営業時間 11:00〜22:00、定休日は水曜」と人間向けの文章で書いてある。GBP も埋めていないか、埋めていても自社サイト側に構造化マークアップが一切ない。

ここで TRUE なのは「人間が読めば分かる」ことだけです。AI から見ると、この店舗の事実は曖昧性を抱えたテキストの塊で、@type による型付けもなく、どれが営業時間でどれが住所かをパースで確定できません。三軸でいえば Structure がゼロ、したがって Confidence も Provenance も乗る土台がない。Level 0 は三軸すべてが未充足の状態です。多くの店舗の出発点はここです。

Level 1 — 基本 LocalBusiness JSON-LD (Structure が立ち上がる)

Level 1 は、最小の LocalBusiness JSON-LD が存在し、AI が店舗を一つのエンティティとして抽出できる状態です。

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Cafe Example",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1-2-3 Example",
    "addressLocality": "渋谷区",
    "addressRegion": "東京都",
    "postalCode": "150-0001"
  },
  "telephone": "+81-3-1234-5678"
}

ここで初めて TRUE になるのは Structure の最下層 —— 名前・住所・電話番号が型付きで抽出可能 ということです。prose では塊だった事実が、PostalAddress という型と streetAddress などのプロパティに分解された。AI は「これは住所だ」と確定的にパースできます。

ただし Confidence と Provenance はまだ立っていません。営業時間のような状態フィールドがなく、surface 横断の一貫性も裏付けもないからです。Level 1 は Structure 軸の最下層だけが TRUE、と読みます。ここで止まる店舗が実は最も多く、そして「JSON-LD を書いたのに引用されない」という相談のほとんどがこの Level 1 で足踏みしています。

Level 2 — NAP 一貫 + 業種 type + 状態フィールド (Confidence が立ち上がる)

Level 2 で初めて Confidence 軸が立ち上がります。条件は三つ。surface 横断で NAP (Name / Address / Phone) が一貫していること、LocalBusiness から業種の正しいサブタイプへ降りていること、そして営業時間のような 状態フィールド が構造化されていること。Level 1 との差分を schema で見ると、こうです。

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Cafe Example",
  "servesCuisine": ["イタリアン"],
  "priceRange": "¥¥",
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"],
    "opens": "11:00",
    "closes": "22:00"
  }]
}

@type が LocalBusiness から Restaurant へ降り、openingHoursSpecification という状態フィールドが加わりました。なぜこれが Confidence を駆動するのか。Schema Confidence Score は「構造化データが存在するか」ではなく「モデルがそれを引用に使えるほど信頼しているか」を測る変数で、その入力は NAP の内部一貫性・選択した @type での必須プロパティ充足・状態の整合性です。営業時間が構造化され、複数 surface で住所が食い違わず、業種 type が正しく深い —— この三つが揃って初めて、モデルは「この listing は管理されている」と読み、集計値の重みを引き上げます。状態フィールドの設計をさらに深く扱った状態フィールドと鮮度・信頼度は、この Level 2 の核心部分の engineering 実装です。

Level 2 は Structure が業種の枝まで降り、Confidence の土台が立った 状態です。Provenance はまだ自社 surface に閉じていて、外部からの裏付け経路は確立していません。

Level 3 — sameAs / @id で Knowledge Graph 配線 (Provenance が立ち上がる)

Level 3 で三軸目の Provenance が立ち上がります。@id で自分のエンティティに安定した識別子を与え、sameAs で外部の権威ある surface (GBP・Wikipedia・業界プラットフォーム) と結線して、「この事実をどの経路から学んだか」をモデルが辿れる状態にする。

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://example.com/#restaurant",
  "name": "Cafe Example",
  "sameAs": [
    "https://www.google.com/maps/place/?q=place_id:ChIJ...",
    "https://tabelog.com/tokyo/A1303/..."
  ]
}

@id が付くことで、このエンティティは複数の言及を一点に集約できる固定の参照点を持ちます。sameAs は、同じ店舗が GBP やプラットフォーム上の別 surface と同一実体であることをモデルに宣言する配線です。これで provenance chain —— どの surface が emit し、どの surface が裏付けるか —— が graph として読める。AI のバイナリ citation 判断は事実そのものより graph の形 に敏感だ、というのが三軸での Provenance の主張でした。Level 3 は、その graph をエンティティ側から能動的に描く段階です。エンティティ結線の engineering は Knowledge Graph とエンティティリンキングで別に扱っています。

Level 3 は 三軸すべてが TRUE になった最初の段階です。Structure・Confidence・Provenance が同時に立っている。citation の閾値を越え始めるのは、多くの場合この Level からです。

Level 4 — 状態の鮮度運用 + 業種オーバーレイ完備 (三軸を運用で維持する)

Level 4 は到達状態であると同時に、維持し続ける状態 です。三軸が立っているだけでなく、状態フィールドが鮮度をもって運用され (臨時休業が当日反映される、季節メニューが古いまま放置されない)、かつ業種固有の構造が完備されている。ここで業種オーバーレイが効いてきます。飲食なら hasMenu と menu の鮮度、医療なら予約可否と診療時間の正確さ、美容なら施術メニューの網羅性と空き状況 —— 業種ごとに信頼度を駆動するフィールドが違い、その正しいフィールドを鮮度運用できているのが Level 4 です。

Level 4 が他と質的に違うのは、ここだけが静的な達成ではなく動的な維持だという点です。営業時間は変わり、メニューは入れ替わり、住所すら移転で動く。Level 1〜3 は「一度書けば TRUE であり続ける」構造ですが、Level 4 の鮮度は放置すれば Level 2 相当に劣化します。成熟度の頂点が「完成」ではなく「運用」なのは、店舗という実体が静止しないからです。

各 Level と三軸の充足マップ

成熟度 = 三軸の充足度の合成、という主張を一覧にします。各セルは「その Level でその軸がどこまで TRUE か」です。

Level (到達状態)	Structure	Confidence	Provenance
0 prose のみ	未充足	未充足	未充足
1 基本 LocalBusiness	最下層 (NAP 型付き)	未充足	未充足
2 NAP 一貫 + 業種 type + 状態	業種の枝まで	土台が立つ	未充足
3 sameAs / @id 配線	維持	維持	立ち上がる
4 鮮度運用 + 業種オーバーレイ	維持	鮮度で維持	完備・運用

この表が成熟度モデルの本体です。Level という番号は、三軸の充足パターンを一次元に圧縮したラベルにすぎず、本当に見るべきは「自分の店舗のどの軸が、どの Level で止まっているか」です。

ここで一度、モデルをしぼませておく

成熟度が上がると AI 引用の確度がどう変わるか —— 構造の確定性が上がり、状態の信頼度が上がり、出典の検証可能性が上がる —— を、私はこのモデルの効用として書いてきました。ここで正直にしぼませます。Level が上がるほど引用されやすくなる、という本稿の段階別の挙動記述は、各エンジンの公開アーキテクチャからの推論 (documented architecture-based inference) であって、測定された citation rate ではありません。 controlled benchmark で「Level 3 は Level 2 より n% 引用される」と言える段階には誰も到達していません。

言えるのは、各 Level で どの軸が構造として TRUE になるか までです。Restaurant に降りれば飲食固有 property が抽出可能になる、@id を付ければ参照点が固定される —— これらは schema.org 仕様を辿れば確認できる事実で、推論ではありません。仮説なのはその先、「TRUE になった軸が引用確度を具体的に何ポイント動かすか」の目盛りです。成熟度モデルは どの軸が立つか を測る尺度としては立っていますが、立った軸がスコアをいくつ動かすか の目盛りはまだ刻まれていません。地図が完成しているふりをするより、これを日付つきで flag しておきます。

なぜこれが LLMO の話なのか、もう一度

成熟度を構造の充足度で定義できるのは、三軸という分解軸を持つフレームワークだけです。AEO は回答文面の最適化に寄っていて店舗構造の段階まで降りず、GEO は citation graph の理論化はしたものの段階を測る実装尺度を持ちません。LLMO Framework の Structure 軸と Framework 概要は、Schema Confidence Score のような primitive を first-class で持ち、AI Native MEO をその reference implementation として位置づけています。成熟度モデルは、その primitive を「店舗が今どこに立つか」を測る尺度へ翻訳したものです。三軸という土台がなければ、Level 0〜4 はただの恣意的な番号付けに堕ちます。

まだ収まらないもの

最後に正直に書いておくと、この五段階は現時点で私が手にしている最も clean な尺度であって、最終形ではありません。本稿を書いている今この瞬間も、各 Level の境界 —— 特に Level 3 と 4 の間、つまり「配線が立った」と「運用で維持されている」の線引き —— は、エンジンの provenance 重み付けが成熟するにつれて引き直されている最中です。五段階という粒度すら、一年後には四段階か六段階に変わっているかもしれません。それでも尺度として今 solid なのは、三軸の充足という 測る対象 が安定しているからです。番号の刻み方は変わっても、「Structure・Confidence・Provenance のどこまでが TRUE か」という問いの形は変わりません。永遠に通用するふりをした梯子より、正直に日付の入った尺度を渡すほうがましです。

今日できる一つのこと

本稿から一つだけ持ち帰るなら、自分が責任を持つ店舗 (または自社) を、Level という一つの番号ではなく 三軸それぞれで別々に採点する ことです。Structure は Level 2 まで来ているのに Provenance が Level 0 のまま、という非対称はごく普通に起きます。そのとき次に構造化すべきは、最も進んだ軸をさらに磨くことではなく、最も遅れている軸を一段引き上げること です。三軸は加算ではなく、最も低い軸が citation の閾値を縛るからです。自分の店舗の三軸を別々に Level 付けして、最も低い一軸を次サイクルの対象に据える —— それが本稿が支える唯一の規範的アドバイスです。

AI Native MEO の三軸 — 構造・信頼度・出典 — 成熟度が合成する三つの独立軸。本モデルの母概念。
業種オーバーレイ — Level 4 で完備すべき業種固有の構造。飲食・医療・美容で差し替わる層。
状態フィールドと鮮度・信頼度 — Level 2 で立ち上がる Confidence 軸の engineering 実装。
Knowledge Graph とエンティティリンキング — Level 3 の @id / sameAs 配線の engineering 実装。
LLMO Framework — Schema Confidence Score の仕様と、AI Native MEO が reference implementation として登録されている Structure 軸 / Framework 概要。