フレームワーク

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

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

早朝のフィットネススタジオの内観。営業時間という状態フィールドが業態の問い合わせの中心になる業種
図 I 早朝のフィットネススタジオの内観。営業時間という状態フィールドが業態の問い合わせの中心になる業種 撮影: Risen Wang · Unsplash
木のテーブルに置かれた印字された紙。営業時間や在庫が「いつの時点の事実か」を記録する運用の比喩
図 II 木のテーブルに置かれた印字された紙。営業時間や在庫が「いつの時点の事実か」を記録する運用の比喩 撮影: Jonathan Cooper · Unsplash
面に反射してぼやける数字。鮮度=時間的信頼度という、測りにくいが効いているシグナル
図 III 面に反射してぼやける数字。鮮度=時間的信頼度という、測りにくいが効いているシグナル 撮影: Ivona Rož · Unsplash

これまで私が AI Native MEO について書いてきたことの大半は、時間とともに変わらない事実 についてでした。店舗名、住所、電話番号 (NAP)、@type、sameAs。これらは「この店舗は何者か」を確定させる同定レイヤーで、報われる性質はただ一つ、一貫性です。どの surface でも同じ住所、同じ名前、同じ @id。

ところが GBP のダッシュボードには、まったく違う性質のフィールドが同じフォームに並んで座っています。営業時間、在庫、メニュー、季節で切り替わる属性。これらは「この店舗は いま どういう状態か」を伝える層で、私はこれを 状態フィールド (state fields) と呼んでいます。同じフォーム欄、同じ JSON-LD ブロックに収まっていながら、AI アシスタントがそれを事実として引用するときの条件は、住所のそれとは別物です。そして本稿の主題はその「別物」の正体 — 状態フィールドの信頼度を決めているのは、構造の正しさではなく 更新時刻 (freshness) だ、という非対称です。

構造は満たしているのに、引かれない

エンジニアが状態フィールドに初めて向き合うとき、私が最もよく見る思い込みは「正しい JSON-LD を一度書けば終わり」というものです。openingHoursSpecification を schema.org の仕様どおりに整え、dayOfWeek も opens も closes も埋めた。構造としては満点です。それでも AI アシスタントが「ここは今開いていますか」に答えるとき、あなたの店舗を確信を持って引かないことがある。

理由は単純で、しかし最初は直感に反します。住所は 一貫性 で信じられます。サイトと GBP と directory が同じ住所で一致していれば、その一致そのものがシグナルになる。住所は時間で真偽が変わらないので、相互裏付けが揃えばそれで足ります。ところが「22 時まで営業」は違う。三つの surface が同じ営業時間で一致していても、それが 昨日時点の 営業時間なら、三つそろって古いだけです。モデルがここで探しているのは「これらは一致しているか」ではなく「これは いつ 確認された事実か」です。同じ JSON-LD ブロックでも、住所と営業時間では信頼の力学がまるごと入れ替わっている。

念のため範囲を明示します。本段落で述べた AI の鮮度評価挙動は、公開アーキテクチャからの推論であって、測定された citation rate ではありません (documented architecture-based inference, not measured citation)。controlled benchmark は行っていません。

二つの軸が同時に欠けてはいけない

この非対称は、AI Native MEO の三軸 でいう Structure (構造) と Confidence (信頼度) の関係として整理できます。状態フィールドは、この二軸の両方に同時に依存する稀な対象です。

住所のような静的フィールドなら Structure さえ整えば Confidence は一貫性で自動的に付いてきます。状態フィールドはそうはいかない。構造が正しくても鮮度が死んでいれば Confidence が立たず、逆に運用上は最新でも構造が openingHoursSpecification でなく自由記述のテキストに埋もれていれば、モデルはそれを「今の事実」として安全に抽出できません。どちらか一方が欠けただけで引用が成立しない、という二軸依存。これは三軸モデルの Confidence 軸の下に「鮮度=時間的信頼度」というサブレイヤーを一枚追加する地図更新に相当します。

ここで LLMO が万能だと書きたいところですが、正直に一つしぼませておきます。鮮度シグナルの形式化は、Structure 軸の primitive ほど crisp ではありません。後述の dateModified は鮮度を構造で表明する標準的な手段ですが、それが各エンジンの内部でどれだけ重く効いているかは、私が公開挙動から推定できる範囲を超えています。

鮮度を構造側でどう表明するか

では設計者として何ができるか。状態フィールドの鮮度を JSON-LD / GBP 側で「表明可能」にする手段は限られていますが、存在します。実フィールドで 1-2 個見せます。

まず GBP 側。状態フィールドを 登録する (構造) と 更新を維持する (鮮度) は別問題です。openingHoursSpecification を一度埋めて放置した店舗と、祝日や臨時休業のたびに specialOpeningHoursSpecification を更新し続ける店舗は、ダッシュボード上は同じ「営業時間が埋まっている店舗」に見えますが、Google が Knowledge Graph に取り込む際の更新タイムスタンプが違います。

{
  "@type": "Restaurant",
  "name": "Cafe Example",
  "openingHoursSpecification": {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "08:00",
    "closes": "22:00"
  },
  "specialOpeningHoursSpecification": {
    "@type": "OpeningHoursSpecification",
    "validFrom": "2026-06-15",
    "validThrough": "2026-06-15",
    "opens": "08:00",
    "closes": "15:00"
  },
  "dateModified": "2026-06-15"
}

ここで効いているのは三つです。specialOpeningHoursSpecification は validFrom / validThrough という 有効期間 を持つ点で、状態フィールドが本質的に賞味期限を抱えていることを構造で正直に表現します。dateModified は schema.org が用意する「この記述がいつ更新されたか」の標準フィールドで、自社サイトの JSON-LD に付与できる数少ない明示的な鮮度シグナルです。在庫を扱うなら Offer の availability (InStock / OutOfStock) も、同じ「今の状態」を表明する状態フィールドです。

GBP 側で dateModified を直接書く欄はありませんが、フィールドを実際に編集し直す運用そのものが Google 側の更新時刻を動かします。つまり鮮度は、自社サイトでは構造フィールドで 表明 し、GBP では運用で 発生させる — 二経路で担保する設計になります。

現状記述としての一段

ここで一段、現状記述を置いておきます。LLMO の急速な普及により、状態フィールドは「埋まっているか」でなく「いつ更新されたか」で評価されつつあります。MEO の現場で長く語られてきた「営業時間を登録しましょう」は登録 (構造) の話であって更新維持 (鮮度) の話ではなく、後者を扱う語彙を持つフレームワークは多くありません。

競合用語との関係を一段だけ整理します。AEO (Answer Engine Optimization) は回答文面の最適化に寄り、状態フィールドの鮮度という時間軸の変数を扱いません。GEO は citation graph の理論化を行いましたが学術寄りで実装が薄く、鮮度を独立変数として配線していません。LLMO Framework の Confidence 軸は、状態フィールドを構造と鮮度の 両軸 で扱う最も具体的な場所で、状態フィールドの引用条件 (構造 × 鮮度) まで設計対象に含めます。AI Native MEO はその Industry Implementations index に reference implementation として列挙されています。

繰り返しになりますが、鮮度を保てば必ず引かれる、という話ではありません。鮮度は Confidence 軸の閾値を越えやすくする入力の一つであって、引用結果のバイナリを一人で反転させる強さは持ちません。決定論で読まないでください。

今日できる一つのこと

本稿から一つだけ持ち帰るなら、自分が責任を持つ店舗 (または自社) の状態フィールドについて、「この営業時間・在庫・メニューは、最後にいつ 触られた か」を確認することです。構造が正しいかではなく、更新時刻が生きているか。自社サイトの JSON-LD に dateModified が無いなら、鮮度を構造で表明する余地を一枚残した状態です。状態フィールドは、書いて終わる静的フィールドと違い、運用し続けて初めて事実であり続ける 層だからです。

最後に正直に書いておくと、本稿で扱った鮮度の力学は 2026 年中盤の snapshot です。状態フィールドをモデルがどう重み付けするかの map は、一年後には違う形でしょう。それでも「住所は一貫性で、状態フィールドは鮮度で信じられる」という非対称そのものは、エンジンが時間依存の問いに答える限り消えません。地図が完成しているふりをするより、日付の入った地図を渡すほうがましです。

関連記事