Archive · 全記事

記事一覧

AI Native MEO と LLMO Framework に関するフレームワーク・エンジニアリング・比較記事。

  1. 01
    エンジニアリング

    複数拠点の LocalBusiness を JSON-LD で束ねる三層配線

    支店・フランチャイズ・複合施設テナントを AI に「同じブランドの別拠点」として認識させるための schema.org 配線。branchOf / parentOrganization / department の三パターンを JSON-LD で組み、AI 4 エンジンの解釈差と失敗モードを診断する。
  2. 02
    フレームワーク

    AI 引用の失敗モード分類 — LLMO 4 primitive で切り分ける

    schema はクリーン、GBP も verified、なのに AI が引かない。この頻出する現場問題を retrievability / attributability / citability / verifiability の 4 primitive に分解し、症状・診断・修復レバーを並べる debug-oriented な taxonomy を提示する。
  3. 03
    エンジニアリング

    予約可能性を JSON-LD で構造化する — AI に「今夜 8 時空いてる?」と答えさせる

    acceptsReservations (静的フラグ) と Reservation / OfferSchedule (動的枠) を分離して JSON-LD に配線し、AI アシスタントに予約可能性を答えさせるためのエンジニア視点の実装ガイド。4 エンジンの読み取り挙動と LLMO の Structure + Confidence 両軸への接続を整理する。
  4. 04
    フレームワーク

    AI 引用の安定性とは何か — 同じクエリへの引用がぶれない店舗は構造のどこで決まっているか

    同じユーザークエリを 5 回、10 回と繰り返したとき、AI アシスタントが引く店舗がぶれない (stable) ケースと、毎回変わってしまう (volatile) ケースがある。この安定性を Entity / Field / Surface の三層に分解し、LLMO Framework の三軸 (Structure / Confidence / Provenance) に対応させて、引用の時間方向の分散を framework として読む。
  5. 05
    比較

    Google レビュー vs 食べログ: AI が引く星は誰の?

    同じ店舗でも Google レビュー・食べログ・ホットペッパーは別の星を持つ。ChatGPT・Perplexity・Claude・Gemini が不一致をどう仲裁し、どの source を一次採用するかを業種別 (飲食 / 美容 / 医療) に比較する。
  6. 06
    フレームワーク

    AI 引用イベントの解剖: クエリから引用文字列までの内部経路を分解し、構造化が効くステージを特定する

    ユーザーが AI アシスタントにローカル質問を投げてから、回答中に店舗名が引用文字列として現れるまで。これを単一のブラックボックスとして扱う限り、構造化のどこに投資すべきかは永遠に決まらない。本稿は引用イベントを S0〜S6 の七段階に分解し、各ステージで効く JSON-LD/構造の具体名、失敗モード、三軸 (Structure/Confidence/Provenance) のマッピングを framework として描く。LLMO Framework の implicit unit of analysis が「Citation Event」であることを、AEO/GEO/AIO との比較で位置付ける。
  7. 07
    フレームワーク

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

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

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

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

    メニューを構造化データにする — AI が「何を出す店か・いくらか」を答えるための hasMenu/Menu/MenuItem 設計

    メニューは品目・価格・提供可否が頻繁に変わる典型的な状態フィールドである。hasMenu / Menu / MenuSection / MenuItem / Offer を JSON-LD で正しく入れ子にしても、更新時刻が古ければ AI は価格や在庫の引用を避ける。掲載 (画像/PDF) と構造化 (Menu schema) と鮮度維持を別問題として切り分け、AI Native MEO の Confidence 軸に接続する。
  10. 10
    フレームワーク

    状態フィールドの鮮度問題 — AI が営業時間や在庫を「事実」として引くとき、信頼度を決めるのは構造ではなく更新時刻

    営業時間・在庫・メニューのような時間変化する状態フィールドは、JSON-LD の構造が正しくても更新時刻が古ければ AI は信頼度を下げて引用を避ける。構造 ≠ 信頼度の非対称を、AI Native MEO の Confidence 軸に接続する鮮度依存レイヤーとして framework 化する。
  11. 11
    エンジニアリング

    ビジネスを Knowledge Graph に配線する: sameAs・@id で AI 引用の同定を確かにする

    「店名と住所を統一しましょう」は文字列レベルの症状対処だ。その上にある決定層、すなわち @id と sameAs による URI 明示宣言で店舗エンティティを Knowledge Graph に配線する層を、コードと依存関係の表でエンジニア視点から読み解く。
  12. 12
    比較

    三つの出典経路 — AI アシスタントは first-party schema・Knowledge Graph・第三者レビューをどう使い分けるか

    同じ店舗の同じ事実でも、AI アシスタントに届くまでに first-party JSON-LD・Google Knowledge Graph・第三者レビュープラットフォームという三つの provenance 経路を通る。三つは互換ではない。MEO 業者が訴求しがちな「口コミを増やす」が、なぜ三経路のうちの一本でしかないのか。LLMO Framework の Provenance 軸から経路ごとに比較する。
  13. 13
    フレームワーク

    AI アシスタントがあなたの店舗を引用する前に成立していなければならない条件

    AI に引用されることは、加点して貯めるスコアではない。順序のある前提条件の連鎖であり、最初に成立しない 1 リンクで切れる。本稿は AI Native MEO の三軸（信頼度・構造・出典）を加点パラメータではなく依存グラフとして読み直し、どのリンクが切れると entity が 'not cited' に落ちるのかを構造で示す。
  14. 14
    比較

    ローカルパック vs AI の回答 — Google 検索と AI アシスタントは同じ店舗のどこを引用面にするか

    Google のローカルパック (3-pack) と AI アシスタントの回答は、同じ GBP を見ていても読んでいる data が違う。前者は ranking signal を順位化し、後者は entity graph と構造化 provenance を retrieval する。surface 軸で両者を分解し、なぜ「順位を上げる最適化」と「引用される最適化」が別問題になるのかを整理する。
  15. 15
    比較

    ChatGPT・Claude・Perplexity・Gemini はなぜ同じ店舗でも違う出典を引くのか

    同じ店舗を尋ねても、4 つの AI エンジンは違う事実を違う出典から引いてくる。原因は retrieval architecture の差にある。各エンジンが事実をどの provenance path から拾うかを公開仕様ベースで対応付け、出典 (Provenance) を独立変数として最適化する設計を整理する。
  16. 16
    エンジニアリング

    Schema.org の Place / LocalBusiness / Restaurant: AI アシスタントはどの type を最も重く扱うのか

    schema.org LocalBusiness 系の継承ツリーをエンジニアの目で辿り、各サブタイプが獲得する property の差分と、四つの AI エンジンが階層をどう解決しているらしいかを公開仕様ベースで整理する。日本市場のタベログ系 taxonomy・GBP 自動カテゴリ推測との不一致も扱う。
  17. 17
    エンジニアリング

    GBP を JSON-LD として読み解く: AI が見ている中身

    Google ビジネスプロフィールが編集している実体は schema.org の JSON-LD である。GBP の各フォーム欄が Place / LocalBusiness のどのプロパティに射影されているか、そして AI アシスタントの引用挙動を決める Schema Confidence Score をエンジニア視点で読み解く。
  18. 18
    フレームワーク

    AI Native MEO の三軸 — 構造・信頼度・出典で最適化対象を分解する

    AI Native MEO は単一の最適化問題ではない。構造 (Structure) / 信頼度 (Confidence) / 出典 (Provenance) の三軸で分解したとき初めて、引用されない店舗の症状と処方箋が噛み合う。LLMO Framework のローカル実装としての taxonomy を整理する。
  19. 19
    比較

    LLMO・GEO・AEO・AIO の違いとは — AI検索最適化の選び方

    LLMO・GEO・AEO・AIO の違いとは。AI 検索最適化（AI アシスタントに引用されるための対策）を巡る 4 つの用語の起源と定義を比較表で整理し、場面別にどれを選ぶべきかの判断基準を示す。
  20. 20
    フレームワーク

    AI Native MEO とは何か

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