DoorDash、Uber Eats、Deliveroo、Glovoで悪いメニュー写真を差し替えること自体はリスクではありません。リスクがあるのは、その周りの商品情報を編集することです。画像だけを変更する写真の差し替えなら、商品は公開されたまま、注文履歴も保持され、獲得した掲載順位も維持されます。写真の差し替えと同時に名前、説明文、価格、カテゴリーを編集すると、商品が審査に戻され、モデレーターが確認する間オフラインになる可能性があります。
写真だけを変え、商品には手を触れない。このシンプルなルールが、メニュー写真の刷新におけるほぼすべての自滅的な停止を防ぎます。
簡単な答え
デリバリーアプリの写真は、商品エディターで1品ずつ、写真だけを変更して刷新してください。同じ保存で説明文を編集したり、価格に触れたり、営業中にメニュー全体のエクスポートをアップロードしたりしないでください。まず代替画像を撮影・準備し、閑散時間帯に小さなバッチで公開し、保存後に各商品をスマートフォンで確認します。
写真を変更すると実際に何が起こるか
画像変更の扱いはプラットフォームごとに多少異なりますが、パターンは一貫しています。画像が検証され、場合によってはモデレーションされ、商品が再インデックスされます。運用担当者が実感するのはランキングの計算式ではなく、検証期間です。
| 行う変更 | 一般的な影響 | リスクレベル |
|---|---|---|
| 写真のみ、同じ商品、同じフィールド | 処理後に画像が更新され、商品は通常公開されたまま | 低 |
| 写真と説明文の小さな修正 | 一部のプラットフォームではコンテンツの再審査が発生し、商品が一時停止する可能性 | 中 |
| 写真と価格変更 | 価格変更は特に敏感で、審査ルートが発生する可能性 | 高 |
| 多数の商品を置き換える一括メニューファイル | メニュー全体の再処理が発生し、ファイル内にエラーが隠れる可能性 | 高 |
実用的な結論は2つです。第一に、最も安全な変更単位は1商品につき1画像です。第二に、写真の刷新はマーケティングの見せ場ではなく運用プロジェクトなので、金曜日の19:30ではなく閑散時間帯に行うべきです。
写真の差し替え中に運用担当者が勢いを失う3つのパターン
- 意図しない編集。商品エディターはページ上のすべてを保存するため、説明文への誤入力やオプション項目の再選択が新しい写真と一緒に反映されます。保存前には画像フィールドだけでなく、フォーム全体を確認してください。
- 中途半端に適用される一括アップロード。メニューのエクスポートファイルは列の順序、ヘッダー、文字エンコーディングに厳格です。1行が検証に失敗した場合、ファイル全体を拒否するプラットフォームもあれば、正常な行だけをインポートして残りを黙って破棄するプラットフォームもあります。
- 古いキャッシュ。保存に成功しても、顧客アプリに古い画像がしばらく表示されることがあります。オペレーターが再アップロードし、重複や二重審査を招くのはこのためです。アップロードが失敗したと判断する前に、処理期間を待ってください。
獲得したものを守る1品ずつのロールアウト
- プラットフォームに触れる前にすべての画像を準備する。最終的なクロップを書き出し、サムネイルサイズで確認し、料理とクロップが明確にわかるようにファイル名を付けます。命名規則があれば、間違った商品に間違ったファイルをアップロードするのを防げます。これについてはメニュー写真のファイル命名規則で解説しています。
- 写真の見栄えの悪さではなく、売上で優先順位を付ける。注文数上位10品を最初に刷新してください。高回転商品の悪い写真は、低回転商品の悪い写真よりも損失が大きくなります。
- 5〜10品のバッチで作業する。進捗を出せる大きさで、手作業で確認できる小ささです。
- 閑散時間帯に公開する。平日の午後半ばが、営業のピーク時間帯よりも通常安全です。
- 顧客アプリで、スマートフォンで確認する。店舗管理画面のプレビューはお客様側の表示ではありません。アプリで、サムネイルサイズで、プラットフォームが上に描画するオーバーレイテキストとともに商品を確認してください。
- 変更内容を記録する。商品、旧ファイル、新ファイル、日付、確認者を記載した簡単なシートがあれば、リスクの高い手作業を再現可能なプロセスに変えられます。
実施例（例示）
40品のメニューで12枚の写真を差し替える必要があるとします。オペレーターは新しいメニューファイルをエクスポートしません。代わりに：
| 週 | 作業 | 確認 |
|---|---|---|
| 1 | 12枚すべての画像を撮影・準備し、実際の料理と照らし合わせて承認 | 各画像がサムネイルサイズで判別でき、盛り付けが厨房の提供と一致 |
| 2 | 最も注文数の多い6品を公開、閑散時間帯に2品ずつ | 商品は公開されたまま、顧客アプリで新しい写真が表示される |
| 3 | 残り6品を公開 | 同じ確認、ライブラリに重複画像が残っていない |
| 4 | 対象商品の注文構成と返金を比較 | 新しい画像に起因する「写真と違う」という苦情がない |
この例は例示であり、顧客の実績ではありません。要点はその形にあります。すべてを準備し、小さなバッチで公開し、顧客側から確認する。
同じ編集で安全に変更できるもの
料理が変わったために写真が間違っている場合、説明文も変更が必要なことが多いです。それは写真の刷新ではなくコンテンツ更新であり、独自のスケジュール枠と検証が必要です。2つの作業は分けてください：
- 写真の刷新：画像のみ、5〜10品のバッチ、顧客アプリで確認。
- 商品コンテンツの更新：名前、説明文、価格、オプション項目を意図的に計画し、その後で印刷メニューとPOSを確認。
これらを混ぜると、写真の改善がアプリとレジの価格不一致に変わります。このルールの季節ごとの運用については、メニュー写真刷新カレンダーをご覧ください。
制限事項
- 各プラットフォームは画像の検証とモデレーションを異なる方法で行い、ルールは予告なく変更されます。ここに記載された内容は、お客様の市場における最新の店舗向けヘルプページより優先されるものではありません。
- 新しい写真がランキング、成約率、注文量を改善することを保証することはできません。できるのは、明らかな弱点を取り除き、商品を判断しやすくすることだけです。
- 一部のプラットフォームでは、写真を含むあらゆる変更に審査保留がかかります。商品が一時的に利用不可になることを想定し、それに応じて時間帯を選んでください。
- 処理とキャッシュの遅延は制御できません。1時間古く見える写真が、必ずしもアップロード失敗とは限りません。
- 材料、分量、容器を変える編集済み画像は絶対に公開しないでください。デリバリープラットフォームで重要な品質シグナルは、写真が料理と一致することから始まります。
よくある質問
デリバリーアプリのメニュー写真を変更すると、商品はオフラインになりますか？
写真だけを変更する場合は通常オフラインになりません。同じ保存で説明文、価格、カテゴリー、トッピングなどを編集すると、商品が一時停止される可能性が高まります。これらの項目は商業的な重要度が高く、審査が発生することがあるためです。
新しいメニュー写真を一度にすべてアップロードできますか？
可能ですが、一括メニューファイルは最もリスクの高い方法です。1行の不備でファイル全体が拒否されたり、一部だけインポートされたりします。商品エディターで小分けに作業する方が時間はかかりますが、確認と復旧がはるかに容易です。
新しい写真がお客様のアプリに表示されるまでどのくらいかかりますか？
即時切り替えではなく処理時間がかかると考えてください。また、表示によっては古い画像が長く残ることもあります。再アップロードする前に処理時間を置いて再確認してください。重複が生まれるのはこのためです。
商品エディターを開いたついでに説明文も変更すべきですか？
料理自体が変わった場合のみです。写真の刷新は写真だけにとどめてください。コンテンツの編集は、POS、印刷メニュー、アプリをまとめて確認する計画的な更新で行うべきです。
写真が公開された後、何を確認すべきですか？
3点です。商品がまだ注文可能であること、お客様が見る画像が新しいものであること、料理が説明文や厨房から提供する分量と一致していること。確認はデスクトップのダッシュボードではなく、スマートフォンで行ってください。
次のステップ
最も注文数の多い5品を選び、きれいな代替画像を準備し、次の閑散時間帯に写真だけを公開してください。ご自身の料理写真から一貫性のあるメニュー向け画像が必要な場合は、FoodPhoto studioで実際の料理1品から始め、現在の料金プランや利用条件はプランページでご確認ください。
