飲食店のメニュー写真ファイル命名規則：チームが実際に使えるルール

どんな飲食店の写真ライブラリも、最終的にはIMG_4839.webpやburger_final_FINAL_v2.webpのようなファイルで溢れ、「ちょっと待って、これどれがDoorDashに載ってるの？」という恐ろしい質問が飛び交います。解決策は地味ですが強力です。チームが実際に使える、飲食店のメニュー写真ファイル命名規則です。これを正しく運用すれば、「この画像は何か」「最新か」が一目で分かり、メニューの一貫性と迅速な更新を保てます。

これはデザインの問題ではなく、オペレーションの問題です。散らかったライブラリは時間を無駄にするだけでなく、間違ったバージョンのアップロード、チャネル間でのメニューの不一致、そして写真の不整合からくる信頼の緩やかな低下を引き起こします。

この記事が解決する問題

システムがなければ、典型的な飲食店の写真フォルダはこんな状態です：

• IMG_4839.webp
• burger_final.webp
• burger_final_FINAL.webp
• burger_final_FINAL_v2.webp
• screenshot.png

どれが最新か、どれがどのプラットフォーム用か、Uber Eatsのものと自社サイトのものが一致しているか、誰にも分かりません。その結果、メニューが不整合になり、更新に本来の3倍の時間がかかります。命名規則は最も安価な解決策です。コストはゼロで、毎月数時間を節約できます。

機能する命名規則

すべてのファイルに、単一で予測可能な形式を使います：

brand-location_dish-platform_orientation_version_yyyymmdd.webp

例：

• acme-downtown_smash-burger_master_square_v01_20260203.webp
• acme-downtown_smash-burger_ubereats_square_v01_20260203.webp
• acme-downtown_iced-latte_social_vertical_v02_20260210.webp

機能させるためのルール：

• 最高品質の元画像にはmasterを使います。新しいクロップが必要なときに再書き出しする元ファイルです。
• プラットフォーム名は書き出したクロップにのみ使います（doordash、ubereats、web、social）。プラットフォーム名が、そのファイルの置き場所を正確に示します。
• バージョンを上げる（v02、v03）のは、料理の見た目が実際に変わったときだけです。新しい盛り付け、新しい付け合わせ、再撮影など。
• 日付を入れることで、アルファベット順に並べても最新ファイルが明確になります。

料理名を平易な言葉で書くこと（sb1ではなくsmash-burger）は、これらのファイルが自社サイトに掲載されたときに、ささやかながら誠実なSEOとアクセシビリティの利点にもなります。優れた画像SEOの実践と自然に組み合わせられます。

フォルダ構成は退屈に保つ

賢さより予測可能性です。チーム全員が考えずに従える構成：

• /Menu Photos/Masters/
• /Menu Photos/Exports/DoorDash/
• /Menu Photos/Exports/UberEats/
• /Menu Photos/Exports/Web/
• /Menu Photos/Exports/Social/

料理ごとに1つのマスターがMasters/にあります。各プラットフォーム用クロップは、対応するExports/サブフォルダにあります。原則は信頼できる唯一のソースを、明確にラベル付けした出力先に書き出すことです。チーム全員がアクセスできる1つの共有場所にすべてを保存します。別々のスマホやノートPCに重複したライブラリがあると、競合するバージョンが再び忍び寄ります。

マスターとエクスポート：メンタルモデル

ここで最も有用な考え方は、マスターとエクスポートを分けることです：

• マスターは、料理の最高品質で最もよく編集された画像です。料理ごとに1つ保持します（料理が変わってバージョンを上げるまで）。
• エクスポートは、マスターから派生したプラットフォーム固有のクロップです。DoorDash用のサムネイルでも切れにくいもの、Uber Eats用の正しいアスペクト比、SNS用の縦長など。

新しいプラットフォーム用のクロップが必要なとき、「良いバージョン」を探し回るのではなく、マスターに行って書き出します。これは週次写真スプリントを速くするのと同じ規律です。公開する人は常に、どのファイルを引っ張ってくるべきか正確に分かります。

清潔さを保つ週次の習慣

命名規則は維持されて初めて機能するので、小さな定期的なルーティンを組みます：

1. マスターを更新する：新商品と売れ筋について。
2. プラットフォーム用クロップを書き出す：それらのマスターから正しいフォルダへ。
3. サムネイルとしてアップロードして品質確認する：各プラットフォームで正しいバージョンが公開されているか確認します。

3ステップ、数分、毎週。このペースが、final_FINAL_v2の混沌へゆっくり戻るのを防ぎます。

避けるべきよくある間違い

• エクスポートをマスターとして命名する。ファイルにmasterとあるなら、それはクリーンで高品質なソースであるべきで、DoorDash用クロップではありません。これを混ぜると、間違った画像が再クロップされます。
• バージョンアップを飛ばす。料理の盛り付けが変わったらバージョンを上げます。そうしないと古い画像と新しい画像が区別できずに共存します。
• ファイルをデバイス間に散らばらせる。常に1つの共有ライブラリです。スタッフのスマホに散らばった写真は、バージョンの競合を招きます。
• 不可解な略語。料理名は平易な言葉で書き、新入社員が読めるようにします。命名規則は人間が使うために存在し、解読するものではありません。

実例：1つの料理を最初から最後まで

あなたがダウンタウンでAcme Burgersを経営し、スマッシュバーガーを撮り直したとします。命名規則はこう展開します：

1. 最高のフレームを加工し、ソースをacme-downtown_smash-burger_master_square_v01_20260203.webpとして/Masters/に保存します。
2. そのマスターから、被写体を中央に置いたDoorDash用16:9ファイルacme-downtown_smash-burger_doordash_16x9_v01_20260203.webpを/Exports/DoorDash/に書き出します。
3. Uber Eats用クロップとウェブサイト用バージョンも同様に書き出し、それぞれのフォルダに入れます。
4. 3か月後、バンズを変えてソースを追加します。撮り直し、新しいマスターは..._smash-burger_master_square_v02_20260510.webpになります。v02と新しい日付で、これが古いものを置き換えることがすぐに分かります。

チームの誰でも（新入社員、マーケティングのフリーランサー、深夜11時の自分）が、どのファイル名を見ても料理、出力先、向き、バージョン、日付を知ることができます。これが要点です。システムが「これは何で、最新か」を誰にも聞かせずに答えます。

なぜ複数店舗にスケールするのか

この命名規則が最も価値を発揮するのは、複数店舗を展開するグループです。ブランドと店舗がファイル名に含まれるため（acme-downtown対acme-airport）、共有ライブラリが一方のキッチンの写真を他方と混同することはありません。1人のレビュアーが各店舗の週次マスターを承認し、すべての店舗が同じ命名ルールで書き出します。これが、絶え間ない撮影費用をかけずにチェーンが視覚的一貫性を保つ方法であり、すべての店舗ページで一貫した画像SEOを実現するのと同じ規律です。

ワークフローの他の部分とのつながり

ファイル命名は、撮影と公開をつなぐ要となる仕組みです。クリーンな入力、一貫した強化、整理されたファイル、正しいエクスポート。各ステップは前のステップに依存します。命名とフォルダがしっかりしていれば、下流のすべてが速くなります。正しいマスターを即座に見つけ、正しいクロップを書き出し、すべてのチャネルで一貫したメニューを公開できます。

そもそも一貫したメニュー対応のマスターを作ることがボトルネックなら、FoodPhoto.aiがまさにそれを担います。本物の料理の本物のスマホ写真が、料理を変えずに、命名・保存・書き出しできるクリーンで一貫したマスターになります。Tasteパック（10枚で$12）でご自身の料理の1つをお試しください。ライブラリ全体を標準化する準備ができたら、料金をご確認ください。

命名規則は刺激的ではありませんが、飲食店ができる最も効果の大きいオペレーション改善の1つです。形式を採用し、フォルダを退屈に保ち、週次の習慣を実行すれば、どのバーガー写真が公開中かと10分間悩むことは二度とありません。