商品画像の命名規則：古い写真を送らないために

先週送った見積は、2024年に撮った写真をもとに作ったものでした。バイヤーは旧型のベースで値段を出し、こちらは新型を出荷した。そのあと揉めたのは技術でも価格でもなく、「どのファイルが正しいのか」でした。あの写真のファイル名は、どちらにも答えを教えてくれませんでした。

製品画像の命名規則とは、すべてのSKUのすべての写真に同じ固定パターンを適用し、ファイルを開かなくても「どの製品の、どのアングルで、何版目、いつ承認されたか」が分かるようにする取り決めです。離れた拠点の二人が同じフォルダを見ても、どれが現行版か判断できます。これは整理整頓の話ではありません。承認した写真が、そのまま送った写真であることを示す、最も安価な証拠です。

以下では、5年使えるパターン、実際に情報を運ぶトークン、ファイル名が壊れる3つの箇所、そして稼働中のリスティングを壊さずに既存ライブラリを改名する順序を説明します。

製品画像の命名規則が満たすべき3つの役割

ファイル名には3つの仕事があり、多くのサプライヤーは1つ目しか設計していません。

費用がかかるのは3つ目です。承認ファイルを示せない瞬間、バイヤーの「合意した仕上げと違う」に対して反論の余地がほとんどなくなります。仕上げが完全に正しくても同じです。「最新のファイル」が (1) という名前のフォルダでは、3月に何を送ったかを誰も再現できません。

5つのトークンと、その順序

語彙よりも順序が重要です。順序を固定すれば、単純なアルファベット順で実用的な一覧になります。同じSKUが固まり、アングルが決まった順に並び、最新版が最後に来ます。

完成形は SM-CB-1200_front_v03_2026-10-29.jpg です。38文字、空白なし、エスケープが必要な記号なし。Finder、エクスプローラー、クラウドストレージのどこでも正しく並びます。

SKUを先頭に置くのは、バイヤーの保管体系がSKUを軸に組まれているからです。SKUは発注書に載る番号です。製品名で始める名前（walnut-cabinet-1200mm-2.jpg）は、同じキャビネットを2つの仕上げで売った瞬間に、1つのSKUの写真をアルファベット全体に散らばせます。日付を独立させるのは、バージョンが「何が変わったか」、日付が「バイヤーがいつ見られたか」を語るからです。半年後にクレームが来たとき、決めるのは日付です。

**この一文だけ覚えてください：**ファイル名はラベルではなく、どの写真を承認したかの唯一の記録です。

アングルのトークンは「閉じたリスト」で決める

アングルを自由記述にした瞬間に、命名規則は死にます。実際に公開する値だけに絞ってリストを閉じます。

この9つでBtoBの問い合わせはほぼ足ります。10個目が必要になったら、誰かが使う前に文書でリストへ追加してください。一人の頭の中にある取り決めは取り決めではありません。

dim と scale はよく混同されます。dim は実測の寸法図、scale は参照物つきの情景カットです。搬入口を通るかを確認するバイヤーが要るのは scale、見積を埋めるバイヤーが要るのは dim です。両方が1つの名前で済まされると、転送されるのはたいてい間違った方です。

バージョンと日付は別のフィールド

バージョンは「以前と同じ製品か」、日付は「いつからそのファイルが正式版になったか」に答えます。製品が変わらない撮り直し（背景をきれいに、仕上げの光を良く）で両者はずれます。そしてこれが最も揉めやすいケースです。製品がわずかに違って見えるため、バイヤーは仕様が動いたと解釈します。

チームの見える場所に、3つのルールを書いてください。

• バージョンは製品・仕上げ・寸法が変わったときだけ進める。 光だけ変えた撮り直しはバージョンを据え置き、日付だけ更新。両方残すなら末尾に -res：SM-CB-1200_front_v03_2026-10-29-res.jpg。
• 承認済みファイルの名前は永久に変えない。 新しいファイルを作ったら、古い方は archive/ に名前ごと移す。old に改名しない、上書きしない。
• archive/ からは何も送らない。 前シーズンの写真を求められたら、その日付のまま改名して送る。ファイルは自分を説明し続けます。

最後のルールこそバージョンの存在理由です。同名で上書きされたファイルは検証できません。何を送ったかも、何を受け取ったかも証明できません。同じ規律は製品仕様変更チェックリストにも現れます。バージョンは全書類に同時に届かなければ意味がありません。

実例：1件の引き合い、6つのファイル

バイヤーが1,200 mmのウォールナットキャビネット、900 mm版、扁平梱包の外箱を求めてきたとします。返信は6ファイル、名前だけで選べます。

40枚の整理されていない写真では得られないことが、表から2つ読み取れます。2モデルの撮影日が2週間離れていること（900 mmに新しいヒンジが入ったかという質問に効きます）、そして各ファイルが自分の役割を名乗っているので、エンジニア、フォワーダー、ショールーム責任者が追加のメールなしに必要なものを取れることです。

これは1 SKU 1ページの仕様書と同じ原則です。1つのSKU、1ページ、1つの役割。製品画像の命名規則は、そのページを組み立てるファイルに同じ原則を当てることであり、家具リスティングの注釈事例が一度きりの実演ではなくカタログ全体に再現できる理由でもあります。プラットフォーム間で製品画像を使い回す前提でもあります。どの資産がどのチャネルのものかを推測しなくて済みます。

ファイル名が壊れる3つの箇所

どれも美意識の話ではありません。どれも図書館を静かに二つに割ります。

1. パス長：Windowsの260文字

Windowsのフルパス上限は260文字、単一ファイル名は255文字です。テスト用フォルダでは開けたファイルが、バイヤーのダウンロード先で3階層深くなった途端に開けなくなります。長い説明的な名前と深いフォルダは、こうして良いファイルを「ファイルが見つかりません」に変えます。

名前は60文字以内、パスは150文字以内に収めれば、問題は起きません。製品タイトルを名前に入れない実務的な理由もここにあります。長く、SKUと重複し、最初に切り捨てられる部分だからです。

2. 予約文字・空白・大文字小文字

Windowsは < > : " / \ | ? * を禁止し、CON、PRN、AUX、NUL などのデバイス名も予約しています。URLに入れると残りも壊れます。空白は %20 になり、# はフラグメントでリンクを切り、? は以降をクエリ文字列に変えます。手元では開くファイルが、チャットで送ると404になります。

さらに静かな罠が大文字小文字です。WindowsとmacOSは既定で大文字小文字を区別しないため、SM-CB-1200_front.jpg と sm-cb-1200_front.jpg はMacでは同一ファイル、Linuxサーバーでは別オブジェクトです。両方アップロードすると、リスティングがどちらを表示しているか言えなくなります。

使うのは小文字、数字、ハイフン、ドットだけ。ハイフンはあらゆるクライアント、ゲートウェイ、URLパーサを通ります。アンダースコアと空白は通りません。

3. アクセント記号とUnicode正規化

見た目が同じでもバイトが違う文字があります。「é」は合成済み1文字にも、e と結合アクセントにもなります。macOSはファイル名を正規化を区別せず比較しますが、Linuxサーバーやクラウドストレージは通常区別します。Macからサーバーへフォルダをコピーすると、アクセント付きの名前が2ファイルになるか、さらに悪いことに片方が他方を上書きします。

カタログにアクセントや中国語が含まれるなら、ファイル名はASCIIに保ち、現地語名は製品データ側に置いてください。そうすれば同じファイルが経路のどのマシンでも使えます。

名前そのものではない4つ目の破綻もあります。CDNはURLでファイルを返すため、同じパスで差し替えてもキャッシュが古い画像を返し続けます。名前のバージョンがこれを無料で解決します。新版は新URLなので、失効させる古いものが存在せず、URL自体が監査記録になります。

すでにあるライブラリの改名手順

既存ライブラリに命名規則を当てる作業は、誰もが後回しにします。4,000ファイルから始めないでください。生きているファイルから始めます。

1. SKU一覧は見積システムから出力する。写真フォルダから取らない（在庫SKUが欠け、廃番が残っている）。
2. 直近12か月にリスティング、カタログ、見積に出たSKUを印で囲う。通常はライブラリの10〜20%です。
3. そこだけ改名する。承認済みの新しいファイルから着手し、旧版は名前を保ったまま archive/ へ。
4. 参照は当日中に更新する。改名は新URLなので、旧パスを指したままの場所は静かにではなく目に見えて壊れます。
5. 長い尾は必要になるまで放置する。200の稼働SKUで実行されたルールは、誰も守らない完璧な規則に勝ります。

一括改名の失敗パターンは決まっています。金曜にフォルダを改名し、週末にリスティングが空白になり、その規則は「サイトを壊した例のあれ」として捨てられます。公開済みのものから順に進めれば、移行は一週間ではなく一時間で終わります。

送信前チェックリスト

• 名前がSKUで始まり、カートンと見積の印字と完全に一致している
• アングル値は固定リストから取得し、記憶で打っていない
• バージョンは製品・仕上げ・寸法の変化だけで進めた
• 日付は承認日で、撮影日ではない
• ハイフンのみ、小文字、空白・アクセント・#・? なし
• 名前は60文字以内で、3階層下でも開ける
• 旧版は archive/ に原名のまま残っている
• 稼働中のリスティング、カタログページ、送信済み見積が現行ファイルを指している
• dim と scale を入れ替えていない

FAQ

製品画像の良い命名規則は何ですか？

SKU_アングル_バージョン_日付.拡張子 を小文字・固定順で使います。同僚やバイヤーが必要とする4つの事実（どの製品、どのアングル、何版目、いつ承認）を運び、データベースなしでもどのファイルブラウザでも正しく並びます。

ファイル名の先頭はSKUと製品名のどちらにすべきですか？

必ずSKUです。発注書、カートン、請求書に載る番号であり、バイヤーの保管体系の鍵だからです。製品名は市場、仕上げ、言語で変わります。製品名順に並べると、仕上げが2つになった瞬間に1つのSKUがアルファベットの両端に裂けます。

製品画像のファイル名で避けるべき文字は？

空白、#、?、%、&、<、>、:、"、/、\、|、*、そしてアクセントや非ラテン文字を避けます。Windowsが禁止するものもあり、空白はURLで %20 になり、# はリンクを静かに切ります。最も安全な区切りはハイフンです。

同じ製品の違うアングルの写真はどう命名しますか？

各アングルに固定リストの1語を与えます。front、main、dim、detail、scale、pack、assembled、packed、break。単発の依頼で新しい語を作らないでください。このリストがあるからこそ、アルファベット順がコンタクトシートのように機能し、1つのSKUの全アングルが常に同じ順で並びます。

写真が変わったとき、バージョン番号はどこに入れますか？

アングルの直後、日付の前に置きます。進めるのは製品・仕上げ・寸法が変わったときだけで、照明が良くなったときは進めません。露出だけ変えた撮り直しはバージョン据え置きで新しい日付を取ります。ファイル自体を変える必要がありバージョンを動かせないときは、-res のような接尾辞を付けて二つのファイルを永久に区別できるようにします。

寸法変更でバージョンが跳ぶ場合、改名では解決しません。古い図の数字はもう製品と一致していないからです。ここでワークフローが効きます。一度測り、その値を写真上の製品の実際のエッジに固定し、各チャネルが求めるサイズで書き出す。新しい版は目で描き直すのではなく同じ出所から生まれます。生成したシーンは見栄えを整えられますが、dim ファイルに載せてよいのは測った値だけです。

出典・参考資料

• Microsoft Learn — Naming Files, Paths, and Namespaces（予約文字、予約デバイス名、260文字のパス上限）
• RFC 3339 — Date and Time on the Internet: Timestamps（ISO 8601由来のYYYY-MM-DD形式）
• GS1 — GTIN（取引商品の識別キー）
• Unicode Standard Annex #15 — Unicode正規化形式（合成済み文字と結合文字）
• RFC 3986 — URI：予約文字とパーセントエンコーディング
• AWS — CloudFrontでのファイル無効化（キャッシュはリクエストパスをキーにする）