Archive · 全記事

記事一覧

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

  1. 01
    エンジニアリング

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

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

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

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

    Google レビュー vs 食べログ vs 第三者レビューサイト — AI アシスタントは同じ店舗の評判をどの面から引いてくるか

    同じ店舗について Google レビュー、食べログ、ホットペッパー、Caloo は別の星の数を持つ。ChatGPT・Claude・Perplexity・Gemini はその不一致をどう仲裁し、どの source を一次採用するか。Yelp 神話を一度しぼませ、業種別 (飲食 / 美容 / 医療) に provenance 経路の重み付けを比較し、`sameAs` による entity reconciliation がその重み付けにどう効くかを LLMO Framework の citation-graph 観点から整理する。
  4. 04
    フレームワーク

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    NAP 一貫性を「表記ゆれ」ではなくエンティティ解決の問題として読む

    MEO 業者が言う「NAP を揃えましょう」は症状の話だ。AI エンジンが複数のソースから同一店舗を同定するエンティティ解決のレイヤーで、NAP が実際に何をしているかをコードと表で読み解く。
  14. 14
    比較

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

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

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

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

    Google Business Profile を JSON-LD として読み解く: AI アシスタントが実際に見ているもの

    GBP のダッシュボードはフォームではなく schema.org の administrative interface である。Knowledge Graph を経由して AI が手にする JSON-LD の実体と、Schema Confidence Score がローカル引用を決める仕組みをエンジニア視点で読み解く。
  17. 17
    フレームワーク

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

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

    LLMO vs GEO vs AEO: AI 検索最適化はどのフレームワークが勝つか

    LLMO・GEO・AEO の違いとは。AI 検索最適化（AI アシスタントに引用されるための対策）を巡る 3 つの競合用語を精密に比較し、なぜ実務家が LLMO に集約しつつあるのかを示す。
  19. 19
    フレームワーク

    AI Native MEO とは何か

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