「営業中?」と「◯時営業?」で AI が引く signal はどう違うか

「営業中ですか」は real-time state を問う query で、AI は現在時刻・openingHoursSpecification・specialOpeningHoursSpecification (今日該当?)・dateModified (更新新しい?) の 4 要素を突き合わせる。dateModified が古ければ「営業時間データはあるが最新確認は古い」と判定され、hedge phrase (「営業時間の可能性がありますが、事前確認をお勧めします」) に流れやすい。「日曜は何時から営業?」は scheduled state を問う query で現在時刻依存が薄く、構造 (dayOfWeek / opens / closes) の完備性が primary。同じ営業時間データでも query 型が違えば freshness gate の閾値が違う、という非対称。

hours signal の update 頻度が信頼度に与える影響は

state field は consistency gate に加え freshness gate が並列で走る。複数 surface で営業時間が一致していても、揃って古い値なら freshness gate は通らず Confidence は減衰する。自社サイトでは dateModified で鮮度を構造で表明でき、GBP では実際にフィールドを編集し直す運用そのものが Google 側の更新時刻を動かす。祝日や臨時休業のたびに specialOpeningHoursSpecification を更新し続ける店舗と、一度埋めて放置した店舗は、ダッシュボード上は同じ「営業時間が埋まっている店舗」に見えるが Knowledge Graph 側のタイムスタンプが違う。

state field と static field の信頼度 gate はどう分かれるか

static field (name / address / phone) の信頼度は複数 surface での一致 = consistency gate で決まり、dateModified への感度は低い。住所が長年変わらなくても複数 surface で完全一致していれば full confidence が立つ。state field (openingHours / availability / price) は consistency gate に加え freshness gate が並列で走り、揃って古い値なら Confidence は減衰する。static field checklist の「複数 surface で NAP を揃える」と並置で、state field checklist には「dateModified を定期更新する」を書く必要がある。

4 AI engine で state field 鮮度の重み付けはどう違うか

以下は公開アーキテクチャからの推論で、controlled benchmark 結果ではない。Gemini は GBP 一次 API 経由で Knowledge Graph の更新時刻に最も直接的にアクセスし、GBP 側の実運用更新が反映されやすい。ChatGPT (browsing) はレンダリング検索結果と自社サイト JSON-LD の一貫性を見て、dateModified が新しく複数 surface で state が一致すると引用しやすい。Perplexity は明示的 citation 付きマルチソース取得で、鮮度が古い single source より複数 source の相互裏付けを優先する。Claude (web search) は Google レンダリングとオープン Web クロールを組み合わせ、dateModified を鮮度の一つとして参照するが決定論的な重みは公開情報からは不明。

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

AI 営業時間の信頼度と state field 鮮度 framework — 更新時刻が構造より効く

AI が営業時間や在庫を「事実」として引くとき、信頼度を決めるのは JSON-LD の構造ではなく更新時刻。state field 鮮度が Confidence 軸をどう駆動するか、engineer 視点で 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 が状態フィールドの存在を規定する。openingHoursSpecification という型で「営業時間という事実がここにある」と宣言する仕事。
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 軸の閾値を越えやすくする入力の一つであって、引用結果のバイナリを一人で反転させる強さは持ちません。決定論で読まないでください。

「営業中?」と「◯時営業?」で signal 経路が分岐する

同じ営業時間データを問うクエリでも、AI が引く signal の経路と freshness gate の閾値が違います。実運用で最も効くのは以下の分岐です。

「営業中ですか」は real-time state を問うクエリです。AI は「現在時刻 + openingHoursSpecification + specialOpeningHoursSpecification (今日該当?) + dateModified (更新は新しい?)」の 4 要素を突き合わせ、dateModified が古ければ「営業時間データはあるが最新確認は古い」と判定して、hedge phrase (「営業時間の可能性がありますが、事前確認をお勧めします」) に流れやすい。ここでは 鮮度が primary で決定的。

「日曜は何時から営業ですか」は scheduled state を問うクエリです。現在時刻依存が薄く、dayOfWeek / opens / closes の構造完備性が primary。ここでも古い dateModified はマイナスですが、real-time query より許容範囲が広い。構造完備が primary、鮮度が secondary の順序が入れ替わる。

同じ営業時間ブロックでも、real-time query と scheduled query で freshness gate の閾値が違う — この非対称は、状態フィールドの実装 checklist で「どの query 型を想定した鮮度目標を持つか」を先に決めなければならないことを意味します。24 時間営業寄りの業態と季節営業寄りの業態では、当然ながら鮮度目標も違います。

4 エンジンの state field 鮮度重み付け (公開アーキテクチャからの推論)

以下は各エンジンの公開アーキテクチャ・公開挙動からの推論であり、controlled benchmark の測定結果ではありません (documented architecture-based inference, not measured citation)。決定論で読まないでください。

Gemini: Google 一次 API 経由で Knowledge Graph に直接アクセスするアーキテクチャ特性から、state field は GBP 側の実運用更新が最も直接的に反映されやすい。dateModified のような自社サイト側の鮮度シグナルよりも、Google 内部のフィールド編集履歴を優先している可能性が高い。
ChatGPT (browsing): レンダリング検索結果と自社サイト JSON-LD の一貫性を見るモード特性から、dateModified が新しく、複数 surface で state が一致すると引用しやすい。逆に、自社サイト側の dateModified が古いと引用忌避に流れやすい。
Perplexity: 明示的 citation 付きマルチソース取得のモード特性から、鮮度が古い single source より、複数 source の相互裏付けを優先しやすい。鮮度単体より「複数 source で最近確認できたか」の合成 signal を見ている挙動。
Claude (web search): Google レンダリングとオープン Web クロールを組み合わせる特性から、dateModified を鮮度の一つとして参照するが、決定論的な重みは公開情報からは不明。

エンジンごとの重み付けの具体値は公開されていません。上記は Google Business Profile を JSON-LD として読み解くで扱った 4 エンジンの GBP 取り込み経路の差から派生した推論の範囲を出ません。

state field と static field の信頼度 gate は二重に走る

もう一段 framework 化しておきます。状態フィールドの信頼度 gate は、静的フィールドとは別の追加 gate が並列で走ります。

static field (name / address / telephone) の信頼度は、複数 surface での一致 = consistency gate で決まる。住所が 5 年前から変わらなくても、5 surface で完全一致していれば full confidence が立つ。dateModified への感度は低い。
state field (openingHoursSpecification / availability / price) は consistency gate に加え、freshness gate が並列で走る。5 surface で営業時間が一致していても、5 surface とも 6 ヶ月前の値なら「揃って古い」だけで freshness gate は通らず、Confidence は減衰する。

この二重 gate の存在が、AI Native MEO の三軸の Confidence 軸を state field で使うときの実装上の分岐点です。static field の実装 checklist に「複数 surface で NAP を揃える」を書くのと同じ手触りで、state field の checklist に「dateModified を定期更新する」を並置する必要がある。この並置を明示していないと、AI 引用の前提条件を状態フィールドについて満たしていないまま「JSON-LD は書いた」で終わってしまう。

個別の attribute layer 実装 (amenityFeature / acceptedPaymentMethod / hasMenu / reservationStatus 等) は、それぞれ static 寄り / state 寄りが分かれるため、field ごとの deep treatment を accessibility features の JSON-LD 実装や acceptedPaymentMethod の実装、reservation availability の実装、hasMenu / MenuItem の構造化で参照してください。エンティティ側の紐付けは Knowledge Graph エンティティリンキングに。

今日できる一つのこと

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

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

よくある質問

「営業中?」と「◯時営業?」で AI が引く signal はどう違うか: 「営業中ですか」は real-time state を問う query で、AI は現在時刻・openingHoursSpecification・specialOpeningHoursSpecification (今日該当?)・dateModified (更新新しい?) の 4 要素を突き合わせる。dateModified が古ければ「営業時間データはあるが最新確認は古い」と判定され、hedge phrase (「営業時間の可能性がありますが、事前確認をお勧めします」) に流れやすい。「日曜は何時から営業?」は scheduled state を問う query で現在時刻依存が薄く、構造 (dayOfWeek / opens / closes) の完備性が primary。同じ営業時間データでも query 型が違えば freshness gate の閾値が違う、という非対称。
hours signal の update 頻度が信頼度に与える影響は: state field は consistency gate に加え freshness gate が並列で走る。複数 surface で営業時間が一致していても、揃って古い値なら freshness gate は通らず Confidence は減衰する。自社サイトでは dateModified で鮮度を構造で表明でき、GBP では実際にフィールドを編集し直す運用そのものが Google 側の更新時刻を動かす。祝日や臨時休業のたびに specialOpeningHoursSpecification を更新し続ける店舗と、一度埋めて放置した店舗は、ダッシュボード上は同じ「営業時間が埋まっている店舗」に見えるが Knowledge Graph 側のタイムスタンプが違う。
state field と static field の信頼度 gate はどう分かれるか: static field (name / address / phone) の信頼度は複数 surface での一致 = consistency gate で決まり、dateModified への感度は低い。住所が長年変わらなくても複数 surface で完全一致していれば full confidence が立つ。state field (openingHours / availability / price) は consistency gate に加え freshness gate が並列で走り、揃って古い値なら Confidence は減衰する。static field checklist の「複数 surface で NAP を揃える」と並置で、state field checklist には「dateModified を定期更新する」を書く必要がある。
4 AI engine で state field 鮮度の重み付けはどう違うか: 以下は公開アーキテクチャからの推論で、controlled benchmark 結果ではない。Gemini は GBP 一次 API 経由で Knowledge Graph の更新時刻に最も直接的にアクセスし、GBP 側の実運用更新が反映されやすい。ChatGPT (browsing) はレンダリング検索結果と自社サイト JSON-LD の一貫性を見て、dateModified が新しく複数 surface で state が一致すると引用しやすい。Perplexity は明示的 citation 付きマルチソース取得で、鮮度が古い single source より複数 source の相互裏付けを優先する。Claude (web search) は Google レンダリングとオープン Web クロールを組み合わせ、dateModified を鮮度の一つとして参照するが決定論的な重みは公開情報からは不明。