Googleは2026年10月9日、Google Business Profile APIの飲食メニューに、食事制限を表す GLUTEN_FREE（グルテンフリー）と DAIRY_FREE（乳製品不使用）を追加したと発表しました。
ただし、この発表で確認できるのはAPIで扱える項目が増えたことです。日本のすべての店舗に新しい編集画面が一斉表示されることや、検索・Googleマップ上の表示場所、反映時期までは案内されていません。また、飲食メニューを扱える拠点だけがAPIの対象です。
結論として、まず行うべきことは一括登録ではありません。1店舗・1メニューから、レシピ、仕入れ、調理工程、選択肢を確認し、店舗が説明できる情報だけを登録することです。商品名、写真、過去の説明文だけで自動判定してはいけません。
この記事は、Googleの公式変更履歴と開発者資料を2026年10月10日（日本時間）に確認し、飲食店の担当者と多店舗本部が取るべき準備を整理したものです。認証済みの実アカウントやAPIでの変更操作、検索・Googleマップでの公開表示は検証していません。APIの実装手順書や、アレルギー対応の医学的・法的な判定基準ではありません。
今日やること
次の4点を、まず1商品だけ確認してください。
- 最新のレシピと仕入れ商品を確認できる担当者は誰か。
- サイズ、ソース、トッピングなどの選択肢で条件が変わらないか。
- 同じ商品を扱う店舗間で、材料や調理工程に差がないか。
- Googleの飲食メニューを更新しているシステムや外部事業者はどれか。
この4点が確認できない商品は、急いで食事制限の項目を付けず、情報の確認から始めます。
2026年10月9日に何が変わったのか
Google Business Profile APIの変更履歴には、2026年10月9日付で、飲食メニューの食事制限項目に GLUTEN_FREE と DAIRY_FREE が追加されたと記載されています。発表日と、各店舗の画面や公開表示へ反映される日は同じとは限りません。
FoodMenusの公式データ定義では、飲食メニューを「メニュー」「セクション」「商品」「選択肢」という階層で管理します。商品には価格のほか、アレルゲン、食事制限、栄養、原材料、調理方法、写真などの項目があります。
今回追加された2項目は、食事制限を示す項目の選択肢です。Googleのデータ上では、次の情報は別に管理されます。
GLUTEN_FREE：グルテンフリーの料理であることを表す食事制限項目DAIRY_FREE：乳製品不使用の料理であることを表す食事制限項目WHEAT：小麦に関するアレルゲン項目DAIRY：乳製品に関するアレルゲン項目
したがって、「小麦のアレルゲン項目」と「グルテンフリー」、「乳製品のアレルゲン項目」と「乳製品不使用」を、言葉が近いという理由だけで同じものとして扱わないことが大切です。どの項目を使うかは、店舗が確認した商品情報に基づいて判断します。
まず理解したい3つの範囲
API対応と管理画面の提供は別
APIとは、店舗情報を外部システムから読み書きするための仕組みです。Googleの今回の発表は、このAPIで2つの値を取得・更新できるようになったという内容です。
一方、Google検索やGoogleマップから店舗担当者が直接操作する画面について、今回の変更履歴には新しい画面名、対象地域、全アカウントへの提供日が書かれていません。画面に項目が見当たらない場合に、別の入力欄へ同じ意味の文言を詰め込んだり、カテゴリを変更したりする必要はありません。
飲食メニューを扱える拠点だけが対象
飲食メニューの取得方法と更新方法は、拠点の can_have_food_menu が有効な場合だけ利用するよう案内しています。すべての業種、カテゴリ、拠点が対象とは限りません。
外部システムを利用している場合は、「この店舗で飲食メニューAPIを利用できるか」をシステム側で確認してもらいます。対象外の店舗に合わせて業種やカテゴリを実態と異なる内容へ変えるのは避けてください。
API更新と公開表示も別
APIから値を保存できても、利用者に同じ内容が必ず同じ場所・同じ時刻に表示されるとは限りません。Googleのビジネスプロフィール追加利用規約では、正確で最新かつ完全な情報を保つ責任は店舗側にあり、Googleが内容を表示しない場合や、別の情報源を使う場合があると説明されています。
更新担当者は、次の3段階を分けて記録します。
- 店舗が内容を確認した
- APIまたは管理画面で保存した
- Google検索・Googleマップで利用者向け表示を確認した
「保存成功」だけで全店の作業を完了にしないことが、更新漏れや誤表示を見つける助けになります。
誤表示を避ける7つの手順
1. 情報の正本を決める
最初に、食事制限情報を判断する元資料を決めます。店舗ごとに口頭確認するだけでは、担当者が変わったときに根拠が残りません。
確認対象の例は次のとおりです。
- 現在使用しているレシピ
- 仕入れ商品の最新仕様
- ソース、調味料、付け合わせの内容
- 調理器具や調理場所の共用状況
- 店舗独自の材料変更
- 季節商品や仕入れ変更の開始日
これはGoogle指定の書式ではなく、店舗が情報を説明・更新できるようにするための運用案です。確認できない点が残る場合は、断定的な項目を付けない判断も記録します。
2. 商品名ではなく、提供状態を確認する
「豆乳」「米粉」「野菜」といった商品名だけでは、対象の食事制限に合うとは判断できません。ソース、衣、付け合わせ、仕入れ商品、調理工程まで含め、実際に提供する状態を確認します。
写真から原材料を推測したり、生成AIに商品名だけを入力して判定させたりしないでください。AIを使う場合も、確認済みの情報を整理する補助にとどめ、最終判断は店舗が行います。
3. サイズやトッピングを分けて確認する
Googleのデータ定義では、商品に複数の選択肢を持たせられます。選択肢で指定していない属性は、商品の基本属性を引き継ぐ仕組みです。
たとえば、基本の商品には乳製品を使わなくても、一部のソースやトッピングに乳製品を使う場合があります。基本属性に DAIRY_FREE を付けて全選択肢へ引き継がせる前に、各選択肢で条件が変わらないか確認してください。
4. 店舗ごとの差を確認する
同じブランド、同じ商品名でも、店舗により仕入れ先、調理設備、提供方法が異なる場合があります。本部の共通情報を全店へコピーする前に、次のどれに当たるかを分けます。
- 全店で材料と工程が同じ
- 一部店舗だけ材料が違う
- 期間限定で代替材料を使う
- 店舗で選べるトッピングが違う
- 現地確認が終わっていない
確認が終わっていない店舗を「本部と同じ」とみなさず、対象外として残せる運用にします。
5. 既存データを読んでから更新する
APIを使う事業者・開発担当者は、更新前に現在の飲食メニューを取得し、変更対象と差分を確認します。ここでAPIから取得するメニューは更新作業の比較対象であり、店舗が自ら保有するレシピ、仕入れ仕様、工程記録とは別に扱います。
GoogleのBusiness Profile APIポリシーでは、APIから提供されたコンテンツを保存できるのは、APIプロジェクトの性能向上に必要な限定量だけです。保存する場合も30日以内の一時保管、安全な保管、加工・集約をしないことが条件です。更新前のメニューを無期限に蓄積したり、別用途の分析データとして使ったりせず、保存先・保持期間・利用目的をこの条件に合わせます。
また、公式の更新方法では、更新範囲を指定しない場合、送信していない空の項目まで解除される可能性があると説明されています。メニューや商品などの繰り返し項目は、1件だけを個別指定して更新できません。
そのため、次の確認を外部事業者にも依頼してください。
- 更新前のメニューを取得し、更新作業に必要な範囲で比較したか
- APIから取得した内容を保存する場合、目的がAPIプロジェクトの性能向上に限られ、安全な保存先と30日以内の保持期間になっているか
- 既存の価格、説明、写真、他の食事制限を残せるか
- 1商品だけのつもりで、メニュー全体を上書きしないか
- 失敗時に元の内容と比較できるか
- 店舗担当者が変更内容を承認してから送信するか
GoogleのBusiness Profile APIポリシーでは、管理権限のあるプロフィールだけを扱うこと、第三者のツールが変更する場合は透明性を保つこと、利用者の事前の明示的な同意なく自動更新しないことが求められています。
6. 1店舗・少数商品で公開表示まで確認する
いきなり全店を更新せず、材料と工程を確認できる1店舗から始めます。
- 更新前のメニューと公開表示を控える。
- 対象商品だけ変更し、APIの応答を確認する。
- 再取得して、Google側に保存された値を確認する。
- Google検索とGoogleマップをスマートフォンで確認する。
- 価格、説明、写真、他の商品が欠けていないか確認する。
- 店舗ホームページや注文ページの表現と矛盾していないか確認する。
公開表示の場所や反映時間は今回の公式資料で保証されていません。確認時刻を残し、表示されないことだけを理由に同じ更新を何度も送らないでください。
7. 変更日と再確認日を決める
食事制限情報は、登録時点で正しくても、仕入れやレシピの変更で古くなります。メニュー台帳には、少なくとも次を残します。
- 店舗コードとプロフィールID
- 商品名と選択肢
- 確認した項目
- 根拠を確認した日
- 確認した役割
- Googleへ更新した日
- 公開表示を確認した日
- 次回確認日
個人名が不要な運用では、「商品開発」「店舗責任者」「本部運用」のように役割で記録できます。顧客の健康情報や問い合わせ内容をこの台帳へ転記する必要はありません。
具体例：全店共通メニューでも一括登録を止める場面
ここでは、実在店舗の実績ではなく、判断手順を示す仮の例を使います。
ある飲食チェーンが「野菜カレー」を全店共通メニューとして扱っているとします。本部レシピでは小麦と乳製品を使っていなくても、確認すると次の差がありました。
- A店：対象表示の根拠となる原材料仕様と工程を、本部と店舗が確認済み
- B店：地域仕入れのソースへ一時変更中
- C店：追加トッピングに乳製品を使用
- D店：調理工程の確認が未完了
この場合、商品名が同じという理由で全店へ同じ項目を付けません。A店も、単に小麦や乳製品を使っていないという説明だけで分類せず、対象表示の根拠、原材料仕様、調理工程、選択肢まで確認したうえで登録候補にします。B店は仕入れ仕様、C店はトッピング選択時の扱い、D店は現地工程を確認してから判断します。
この例から分かるのは、APIで一括更新できることと、全店舗へ同じ情報を入れてよいことは別だという点です。
APIを使っていない店舗が行うこと
外部システムやAPIを使っていなくても、メニュー情報の正確さを整える作業は役立ちます。
- 店舗ホームページや注文ページのメニューを確認する。
- 商品名、価格、提供店舗、提供期間を最新にする。
- 食事制限に関する説明は、確認できる範囲と問い合わせ先を明確にする。
- Google検索・Googleマップで現在表示されるメニューとリンク先を確認する。
- 管理画面に該当項目がある場合だけ、最新の公式案内と実際の画面に従って更新する。
Googleビジネスプロフィールから正しい店舗ページへ案内する方法は、ウェブサイト・予約リンクの設定ガイドも参照してください。ホームページ、注文ページ、店内メニュー、Googleの表示は別々の更新先として扱い、1か所の修正ですべてが自動更新されるとは考えない方が安全です。
うまくいかないときの確認
飲食メニューを取得・更新できない
対象拠点の飲食メニュー利用可否、管理権限、Googleアカウントから外部システムへ与えた接続権限（OAuth）、プロフィールIDを、システム担当者と確認します。機能を使うためだけに新しい重複プロフィールを作ったり、実態と異なるカテゴリへ変更したりしないでください。
更新できたのに公開表示が見つからない
APIで再取得した値、Google検索・Googleマップの両方、確認した端末と時刻を記録します。今回の変更履歴だけでは、日本での表示場所や一律の反映期限は確認できません。表示を保証する説明を顧客や店舗へ行わず、最新の公式資料とサポート案内を確認してください。
更新後に価格や写真が消えた
更新範囲を指定せずに送信した、または繰り返し項目を含むメニュー全体を上書きした可能性を確認します。同じ更新作業で取得した更新前の内容と比較してください。API取得内容を後から再利用できる形で保存する場合は、上記ポリシーの目的・期間・安全性・加工禁止の条件に従います。原因が分からないまま全店へ同じ処理を続けないでください。
店舗ホームページとGoogleの内容が違う
どちらを最新情報の正本にするか、誰が各媒体を更新するかを決めます。Googleのメニューに元ページのURLを設定できる場合も、リンク先の商品内容と価格が古ければ利用者の判断を助けられません。
やってはいけないこと
- 商品名や写真だけで食事制限を自動判定する
- 確認前の商品へ、生成AIが提案した項目をそのまま登録する
- 1店舗の確認結果を、材料や工程が異なる全店舗へコピーする
- グルテンフリーや乳製品不使用の項目だけで、すべてのアレルギー対応を説明できると考える
- APIの保存成功だけで、検索・Googleマップへの表示を保証する
- 食事制限項目の追加で、検索順位や来店が上がると約束する
- API利用のために、実態と異なるカテゴリや重複プロフィールを作る
最後のチェックリスト
- 公式変更履歴の発表日と、店舗での提供状況を分けた
- API項目と管理画面・公開表示を同じものとして説明していない
- レシピ、仕入れ、調理工程、選択肢を店舗が確認した
- アレルゲン項目と食事制限項目を分けて確認した
- 店舗ごとの差と未確認店舗を記録した
- 更新前の飲食メニューを取得し、更新作業に必要な範囲で比較した
- API取得内容を保存する場合、性能向上目的・安全な保存先・30日以内・加工や集約なしの条件を満たす
- 店舗担当者が変更内容を承認した
- 1店舗で既存の価格・説明・写真への影響を確認した
- Google検索・Googleマップと店舗ホームページを確認した
- 仕入れ・レシピ変更時の更新担当と再確認日を決めた
今回の新しい項目は、食事制限情報を構造化して扱う選択肢を増やすものです。登録できることを先に考えるのではなく、店舗が根拠を説明できる情報を、商品と店舗の単位で保つことから始めてください。
公式資料
以下を2026年10月10日（日本時間）に確認しました。