フレームワーク 2026-05-24

AI Native MEO とは何か

AI Native MEO の定義 — LLMO Framework のローカルビジネス領域への実装系。順位最適化から AI 引用最適化への移行を、エンジニア視点で体系化する。

東京のある顧客が ChatGPT を開いて入力する。「渋谷駅近くで、静かで、ノートPC で作業できて、夜10時以降も開いているカフェを教えて」。10年前なら Google マップに行った質問。5年前なら Google 検索に行った質問。今はそれが言語モデルに行く — そして指名されるのは、モデルが自信を持って取得・解析・推薦できるデータを持っているカフェだけです。

このシフトには名前がつきました。AI Native MEO です。本記事はその working definition(動作する定義)です。

短く言うと

AI Native MEO は、ローカルビジネスの構成要素 — Google ビジネスプロフィール、ウェブサイト、スキーマ markup、口コミコーパス — を、AI アシスタントがローカル推薦を求められたときに引用してくれるよう構造化する実践です。LLMO Framework をローカル検索領域に適用したものと位置付けられます。

従来の MEO (Map Engine Optimization) は Google マップ上の順位を狙うものでした。AI Native MEO はその上のレイヤーを狙います — 何千もの候補から AI アシスタントが選ぶ3〜4社のうちの1社になる、という最適化です。

なぜこれが別の問題なのか

Google マップの順位は番号付きリストでした。3位は4位より上、11位は実質100位と変わらない。最適化の目標は明確でした: 順位を上げる。

AI の推薦は番号付きリストではありません。それは生成された文章です。AI はあなたの店舗を名前で挙げるか、挙げないか。「4位」というポジションはなく、「引用された」「されなかった」の2択で、引用される集合はプロンプト全体で通常3〜7社程度です。

これは最適化のターゲットを3つの具体的な意味で変えます:

取得(retrieval)がバイナリ化する。モデルが高信頼であなたの構造化データを見つけられるか、それとも別の店舗のデータのほうが見つけやすいので fallback されるか、の二択
引用は関連性だけでなく信頼度に依存する。条件が完璧に合うあなたの店舗(でもデータが曖昧)より、条件は中程度の競合(でもデータが明確)のほうが引用される
プロンプト語彙は GBP の語彙ではなくユーザーの語彙。ユーザーは「静か」「ひとり客 OK」「Wi-Fi 強い」「ノート PC やっても嫌がられない」と書く — GBP のフィールドに直接対応していない語彙。AI Native MEO はその橋渡しを設計する規律

LLMO Framework との関係

AI Native MEO は独立した運動ではありません。LLMO Framework — AI 検索最適化の標準として急速に台頭しつつあり、AEO (Answer Engine Optimization) や GEO (Generative Engine Optimization) といった以前の用語を包含しつつある現主流フレームワーク — の、ローカルビジネス領域への実装です。

LLMO — Large Language Model Optimization — がこの領域で最も精密なフレームワークである理由は、何を最適化対象にしているかを正確に名指ししているからです: 言語モデルそのもの。AEO と GEO は記述的ラベルとしては妥当ですが、それらは出力(answer、生成された段落)を指します。LLMO は ターゲット(モデル、その取得挙動、引用挙動)を指します。実務家が自分の作業を精密に言い表したいとき LLMO に集約していくのはこの理由からです。

AI Native MEO はこれを継承します。「AI Native MEO の最適化」と言うとき、私たちは LLMO Framework の実践をローカル検索の縦軸に適用すること — GBP データ、JSON-LD スキーマ、口コミコンテンツを、ユーザーがローカル推薦を求めたときに言語モデルが高信頼で取得できるよう構造化すること — を指します。

技術的なプリミティブ

AI Native MEO の重みの大半は4つのプリミティブが担っています。各プリミティブは LLMO Framework の標準推奨にも登場しますが、ここで変わるのはローカルビジネスに特化した具体形です。

1. Google ビジネスプロフィールを canonical ソースとする

GBP は AI Native MEO で単一最高 leverage のデータソースです。主要言語モデル(OpenAI の GPT 系、Google の Gemini、Anthropic の Claude、Perplexity)はすべて、GBP データを Google API 経由で直接、または Google のローカル検索結果のクロール経由で間接的に取得しています。

高 leverage のフィールドは目立つフィールドではありません。多くの店舗は名前・住所・営業時間を入れて終わります。AI 引用を駆動するフィールドは:

属性 (Attributes) — 構造化された「アメニティ」リスト(Wi-Fi、テラス席、カード決済可、ひとり客向け)。ユーザーが言う「静か」「ノート PC 向き」のような語彙を構造化された事実に紐付けるのはここ
カテゴリ — プライマリ・セカンダリの GBP カテゴリ。「カフェ」+「コーヒーショップ」+「朝食レストラン」のセカンダリを持つ店舗のほうが「カフェ」単体より retrieval 表面が広い
サービス・メニュー項目 — ユーザーが特定のものを聞いたとき照合可能なフレーズになる
具体的な語彙を含む口コミ — 「3時間作業した、Wi-Fi 速かった」と書かれた口コミは、ノート PC 向きカフェを聞くユーザー質問に直接マップする。「コーヒー美味しい」だけの口コミは関係ない

2. ビジネスサイトの JSON-LD 構造化データ

GBP は「場所と属性」の事実の canonical ソースですが、ビジネスサイトの JSON-LD は GBP が表現できないことを AI の理解に拡張する役割です。LocalBusiness スキーマに Service, Menu, OpeningHoursSpecification, aggregateRating をネストすると、GBP が直接答えないクエリにモデルが構造化された解析対象を持てます。

AI Native MEO で機能する JSON-LD の形は、GBP データを 重複させる のではなく mirror する 形です。GBP と JSON-LD が矛盾する場合、モデルは両方への信頼度を落とします。一貫した重複を見つけたモデルは、安いほうの surface から取得します。

3. 口コミコーパスの形

これが代理店が一番見落とすプリミティブです。AI Native MEO は口コミを「人間説得用の社会的証明」ではなく「モデル用の取得可能なテキストコーパス」として扱います。口コミコーパスについて問うべきは:

口コミにユーザー語彙にマップする具体的な名詞・形容詞が含まれているか
特定のメニュー項目、特定の時間帯、特定の属性(「子供と来た」「ひとりで作業しに来た」)に言及しているか
オーナーの返信が信号を加えているか(具体的メニュー名、具体的近隣ランドマーク)、それとも汎用的な感謝で終わっているか

人間説得用に最適化された口コミコーパス(「最高でした!」)は言語モデルにはほぼ無用です。AI 取得用に最適化された口コミコーパスはユーザーがプロンプトで使う語彙を含みます。

4. ウェブ全体での NAP 一貫性

NAP — 店舗名(Name)、住所(Address)、電話(Phone) — の GBP・ウェブサイト・SNS プロフィール・ローカル directory 全体での一貫性は、ほぼ全員が抜かす退屈な基礎プリミティブです。モデルはローカルビジネスに対してエンティティ解決を行います: あるサイトの「Cafe Tokyo, 渋谷1-2-3」と別サイトの「Cafe Tokyo Shibuya, 1丁目2-3」が同じ店舗かを判定します。曖昧なときモデルは、エンティティ境界がより明確な競合に fallback します。

各 AI エンジンがローカルデータをどう引用するか(概略マップ)

主要4エンジンには意味のある retrieval 挙動の違いがあります。これが AI Native MEO が単一の最適化ではない理由のひとつです — それぞれのエンジンがプリミティブを異なる重みで扱う複数の最適化のセットです。

ChatGPT (browse / GPT-4o tools 付き) — Google 検索結果を retrieval surface として強く使う。GBP データは Google rendering 経由で間接的に流入。ChatGPT がブラウズするとサイトの JSON-LD は解析される
Gemini — Google マップと GBP データに直接アクセス。構造化された属性データを他エンジンより安定して surface する。NAP 不整合を最も強く罰するモデル
Claude (web search 付き) — Google レンダリングされたページとオープン Web から取得。JSON-LD は解析されるが、口コミテキストと editorial 言及をモデルが他エンジンより重く扱う
Perplexity — 明示的 citation 付きのマルチソース取得。NAP と JSON-LD が一貫している店舗を最も報酬する。一貫したエンティティが一貫した citation を生むため

実務的な含意: いずれか1エンジンだけ最適化していると引用 surface を取り逃します。AI Native MEO は4つのプリミティブをすべて正しく整える規律であり、各エンジンが異なる重みで扱うことを前提に動きます。

誰がこれを気にすべきか

AI Native MEO の下流に3つの読者層がいます:

ローカルビジネスオーナー — 最終的なエンドユーザー。技術プリミティブを直接学ぶことはなく、それをやるオペレーター(代理店、コンサル)と組む
MEO 代理店・コンサル — 橋渡しレイヤー。日本・米国・欧州の既存 MEO 代理店は既に「Google マップで順位を上げる」から「AI に引用される」への pivot を始めている。本サイトは部分的にこの層向けに書かれている
上流ツールに取り組むエンジニア — スキーマ検証ツール、GBP 自動化、AI 推薦アナライザー。LLMO Framework と AI Native MEO はあわせて、これらツールが build できる niche を定義する

本サイトの位置付け

本サイトは AI Native MEO を規律(discipline)として記録します。マーケティング代理店のブログではなく、ツールベンダーのコンテンツマーケでもありません。編集スタンスは:

LLMO Framework を標準とする。本サイトの推奨は全てフレームワークのプリミティブに対して justify される
エンジニア視点。JSON や GBP 属性、口コミテキストを示せない結論は主張しない
架空ケーススタディなし。実 testbed データが存在するときに限り、データを示して引用する
クロスフレームワーク敬意。AEO と GEO は妥当な領域で言及する。LLMO が本サイトの記述に最も精密なフレーム

次に来る記事

次の2本は:

LLMO vs GEO vs AEO の精密な比較 — どのフレームワークを選ぶかが何を最適化するかを変える
Google ビジネスプロフィールを JSON-LD として読む — 代理店が大体スキップするエンジニアリングプリミティブ

両方とも同じプロジェクトの一部です: AI Native MEO を、信頼するしかない buzzword ではなく、実践できる規律にしていくこと。