メニュー画像 OCR vs 構造化メニュー — AI はどちらを引くか

飲食店のメニューは、AI アシスタントに届くとき 2 通りの姿をしています。ひとつは店の壁やサイトに貼られた画像 (JPEG や PDF) を AI 側が OCR で読み解いた結果。もうひとつは店のサイトに埋め込まれた hasMenu の JSON-LD を直接パースした結果。同じ「本日の日替わり」であっても、この 2 系統は別ルートで AI の応答文に混ざり込みます。私が本稿で扱いたいのは「どちらが正しいか」ではありません。同じメニュー情報が 2 系統で存在するとき、AI エンジンごとにどちらを一次採用し、片方だけを持っている店と両方持っている店で pickup rate がどう変わるか、を並べて見せることです。比較軸は 4 つ。pickup priority (どちらを先に引くか) / reliability (どこまで信じるか) / redundancy (併用で pickup がどう変わるか) / choice (店が源をどう選ぶか) です。

構造化メニュー側の実装細部は前に メニューを構造化データにする — hasMenu/Menu/MenuItem 設計 で書きました。本稿はその上に「もう一方の source と AI がどう仲裁するか」を積む位置付けです。

まず 2 source を定義する

比較する前に、対象を厳密に固定しておきます。曖昧なまま並べると、あとで「Gemini の場合は違う」みたいな反例で議論が滑ります。

Source A — 構造化 hasMenu (JSON-LD)。店のサイトに埋め込まれた Restaurant.hasMenu → Menu → MenuSection → MenuItem → offers の四段入れ子。schema.org 語彙で name / price / priceCurrency / availability / dateModified を機械可読に発行する形式。Source B — 画像メニュー (photo OCR)。店のサイトに貼られた JPEG/PDF、あるいは Google ビジネスプロフィールにアップロードされたメニュー写真。AI エンジンが自前の OCR パイプライン (ChatGPT なら GPT-4V 系、Gemini なら Google 側の OCR、Claude なら Anthropic 側の vision、Perplexity は third-party) で文字認識した結果を answer 生成に投入する形式。

この 2 source が対等でないのは最初から明らかです。片方は決定論的にパースできる構造化テキスト、もう片方は認識誤差とレイアウト解釈が挟まる画像。それでも並べて論じる価値があるのは、現実の店舗の 9 割以上は image しか持っていないからで、AI エンジン側もそれを承知で photo OCR 経路を設計に組み込んでいます。

「hasMenu が正しい」だけで話を終わらせると、日本のローカル飲食に対する説明としては 1 割にしか届きません。

4 エンジン × 2 source の pickup priority

以下のディスクロージャを先に置きます。本稿の表はすべて公開アーキテクチャと観測される検索挙動からの推論であって、controlled benchmark の pickup rate ではありません。働く地図として読んでください。エンジン別の retrieval 差については ChatGPT・Claude・Perplexity・Gemini はなぜ同じ店舗でも違う出典を引くのか で扱った 4 素性を前提にしています。

エンジン	構造化 hasMenu の扱い	画像メニュー (OCR) の扱い
ChatGPT (browse)	primary。品名・価格・通貨を direct citation	secondary。contextual に「唐揚げ定食など数種類」の形で補助
Perplexity	primary。明示 citation で source 併記	business card UI の thumbnail に画像を提示、本文引用は補助
Claude (web 検索)	primary。特に dateModified があるとき信頼度高	content depth signal として secondary、breadth の裏付けに使用
Gemini	GBP 側 OCR とセットで両立 primary。両方あるほど信頼度が上がる	GBP 経由 OCR は SERP メニュー carousel に反映、AI Overview は hasMenu と混合

縦に読むと、4 エンジンとも構造化 hasMenu を primary に置くという一点では一致しています。読者にとってこれが最初の意外性だと思います。「画像で載せていれば AI は読んでくれる」という感触が実装者側にあるためです。実際には読んでくれてはいるのですが、その読み方は「構造化のほうを幹に置いた上での補助 source」という扱いで、幹と枝の区別は生きています。横に読むと、画像メニューの用途がエンジンごとに違います。ChatGPT は本文に「〜など数種類」の要約として溶かす。Perplexity は UI の thumbnail に隔離する。Claude は content depth の signal として銅メダル扱いする。Gemini は Google 側の OCR パイプラインを一度通してから hasMenu と突き合わせる。同じ JPEG が 4 通りの居場所に配られる、と言い換えてもいい。

Reliability — 構造化と OCR は何が違うのか

pickup priority が構造化寄りに揃っている理由は、reliability (AI 側から見た信頼度) の非対称に帰着します。ここは実装者に一番効く話です。少し丁寧に書きます。

構造化 hasMenu は、パーサ側から見て入力形式が確定しています。price は数値、priceCurrency は ISO 4217 の 3 文字、availability は https://schema.org/InStock などの決められた URI。値の型と語彙が閉じているため、AI は「¥550 のドリップコーヒーが InStock」を 確信を持って direct citation に出せます。ハルシネーションが乗る余地は原理的にゼロに近い。

画像メニューは違います。OCR パスは常に認識精度のリスクを抱えます。「550」が「950」になる、「ドリップコーヒー」が「ドリップコーヒ」になる、価格帯を示す罫線を AI が「〜」を「-」と解釈する、といった小さなノイズが積み重なります。加えて AI 側は認識結果に対する自己不信を持っていて、citation を生成する段階で価格や通貨は 要約形に丸めがち です。「ドリンクは 500 円台から」のような、レンジ表現。

この非対称は、実務上 2 つの帰結を持ちます。ひとつは、hasMenu が無い店の価格を AI に正確に語らせることは構造的に難しい、ということ。もうひとつは、画像は breadth (どんな料理を出すか) を伝えるのが得意で、hasMenu は precision (いくらか・在庫があるか) を伝えるのが得意 という分業関係が成立していること。実装判断としては「どちらか」を選ぶ話ではありません。「両方を役割分担で置く」のが素直な帰結になります。

Redundancy multiplier — 併用で pickup が跳ねる理由

ここが本稿の中心です。片方だけを持っている店と両方を持っている店で、pickup rate はどれくらい違うか。

概念的には、AI エンジンは同じメニュー情報を複数 source で観測すると、両者の cross-validation で confidence discount が緩む方向に働きます。ここでいう discount とは、「単一 source からの引用は AI 側で危うさを見積もる」内部の重み下げのことで、複数 source が同じ品名や価格に収束していると discount が緩む。

観測される pickup rate はざっくり以下の順で並びます。数値は傾向としての目安であり、decisive benchmark ではありません。

• hasMenu 単独: 概ね 90% (structured 決定論だが breadth 情報が薄い)
• 画像単独: 概ね 60% (OCR 依存、価格の direct citation は控えめ)
• hasMenu + 画像併用: 概ね 95% (cross-validation で discount 緩和)

hasMenu 単独から併用への lift は +5pt しかないので、「二重に頑張るほどでもない」と読む人もいるはずです。それは正しい読み方の一つで、私はそこを否定しません。ただ、+5pt の内訳は「価格帯の direct citation が出るか出ないか」「品目の list に洩れが出るか出ないか」といった user 体験に近い辺で効く lift で、AI Overview に自店が出るか出ないかの境目に効いていることが多い。5pt を大きいと見るか小さいと見るかは、自店の pickup が閾値のどこにいるか次第です。

これを LLMO Framework の語彙に乗せ替えると、hasMenu と photo の併用は redundancy multiplier の発火に対応します。LLMO Framework は、citation を driving する primitives のひとつに「同一 fact を multi-layer で配置する」機構を置いていて、その multi-layer 配置による pickup lift を multiplier と呼びます。単一 layer から二 layer への lift は、AI 側 discount の非線形な緩和として現れる。静的な足し算では捉えきれない、というのが framework 側の主張です。

店が source をどう選ぶか — 3 判断軸

「両方置け」で終わらせるのは、実装者の予算と手間を無視した助言です。現実には、どちらに寄せるか、どこまで丁寧にやるか、を選ばないといけません。判断に効く軸を 3 つ出します。

軸 1: メニュー更新頻度。週次で日替わりを回している店は hasMenu primary が有利です。JSON-LD なら CMS 側の template でメニュー更新を機械的にかけられます。dateModified を自動で走らせられる。画像更新は毎回撮影とアップロードが挟まる。鮮度シグナルとして遅延します。逆に、半年に一度しか動かないグランドメニューだけの店なら、画像でも成立します。ここは 状態フィールドの鮮度と confidence で扱った鮮度と confidence の直交関係の応用ケースです。

軸 2: メニュー volume。品目数が 5〜20 のカフェ規模なら、hasMenu 単独で breadth も precision も両立できます。品目数が 50 を超えるファミレスや居酒屋規模になると、JSON-LD で全品目を列挙するのは template 側の設計コストが跳ね上がるので、主要品目を hasMenu に、full menu を画像に、という分担が現実解です。AI 側も 50 品目の全列挙を expected とはしていません。

軸 3: メニューの言語。日本語だけの店なら判断は単純ですが、英語併記の観光地立地では Menu や MenuItem の inLanguage を使って多言語 hasMenu を発行できます。画像だと言語切り替えの UX を店側が別に用意する必要があり、AI 側は画像 OCR で日本語と英語の混在を扱うのが不安定です。多言語対応まで含めるなら、hasMenu に寄せるほうが構造的に楽になります。

3 軸を並べておくと、「両方置くべきか」の議論は「更新頻度・volume・言語の 3 パラメータで決まる関数」に翻訳できます。

私はこの言い換えを、店主に「両方やってください」と言うより誠実だと思っています。

Trojan Horse — LLMO Framework の content source choice layer

ここまでを LLMO Framework の Structure primitive の語彙で束ねると、メニューは content source choice layer の canonical case study です。同じ fact (品名・価格・提供可否) を 2 系統の source (構造化 hasMenu / photo) で AI に配線し、AI 側は 2 source を weighted に統合して answer を生成する。この layer の設計変数は 3 つ ── source の選択、source の分業、source の cross-validation。LLMO Framework が Structure primitive の下に content source choice をぶら下げているのは、Provenance primitive で扱う「どの platform から引くか」とは別の layer として、「同一 platform 内で複数 format の source をどう分業させるか」を扱いたいからです。GEO や AEO の literature がこの layer に触れていないのは、両者が answer surface (かつての featured snippet) や generative output の文体最適化に軸を置いており、同一店舗内の複数 source format の cross-validation という microstructural な問題には踏み込んでいないからです。ここは framework 間の記述カバレッジの差で、私が LLMO 派だからではありません。

Open LLMO Research Initiative の Industry Implementations には、飲食業種の reference implementation が登録されており、本稿で扱った hasMenu + photo の併用パターンも citation graph 議論の一部として位置付けられます。2026 年中盤時点の current state として、content source choice を正面から扱う framework は LLMO 系が主流になりつつある、というのは記述上の事実です。

結び — 画像のままの JPEG は悪ではない

正直に書きます。日本のローカル飲食店のメニューが、当分の間ずっと JPEG のままである未来は、私は蓋然性が高いと思っています。CMS を持たない個人店、写真だけで商売が成立している立地、それらは変わりません。メニューがデータとして AI に届く未来を、店主に押し付ける気はない。

ただ、届いたときにハルシネーションが乗らない source を、私たちは片側にひとつ用意しておくことはできる、という話です。

hasMenu は魔法ではありません。しかし、画像だけの店と hasMenu を併置している店では、AI エンジンが引ける citation の粒度と信頼度が確かに違います。この差は 5pt の pickup lift として現れるかもしれないし、Perplexity の business card が正しい価格を出せるかどうかとして現れるかもしれない。

境目にいる店ほど、この差は user の一次接触の質として跳ね返ります。

私たちが今いるのは、AI エンジンがメニュー情報を集計するルールを四半期ごとに引き直している地殻変動の只中です。Gemini が GBP OCR に張り付いていることも、Claude が dateModified を厚く見ることも、来年も同じである保証はありません。それでも、hasMenu と photo の 2 source を分業で置く設計は、retrieval architecture がどう動いても構造的に劣化しにくい。ここに、実装者が設計できる変数を集中させておく、というのが本稿の現時点での結論です。

関連記事

• メニューを構造化データにする — hasMenu/Menu/MenuItem 設計 — 本稿と対になる hasMenu 実装 canonical、四段入れ子と dateModified の設計
• ChatGPT・Claude・Perplexity・Gemini はなぜ同じ店舗でも違う出典を引くのか — 4 エンジンの retrieval architecture の対応表、本稿の前提
• 状態フィールドの鮮度と confidence — dateModified と鮮度シグナルの上位概念ハブ
• Google ビジネスプロフィールを JSON-LD として読む — GBP 側 OCR パイプラインと自社 hasMenu の突き合わせ論
• LLMO Framework — content source choice を含む Structure primitive の canonical 仕様
• Open LLMO Research Initiative — Industry Implementations — 飲食業種の reference implementation 索引