アセット管理で失敗しない画像ファイル命名規則｜現場で使える実践テクニック

こんにちは！

今日は「アセット管理で失敗しない画像ファイル命名規則」について解説します。

僕が経験した「命名規則なし」の地獄

これ、ほんまに話したくない失敗談なんですが……めっちゃ初期のころの僕、画像ファイルをテキトーに命名していたんです。
photo.jpgとかimage1.jpgとかbanner_new.jpgとか。
最初は個人案件だったから気にならなかったんですよ。

ところが、チーム開発になった瞬間、地獄が始まりました。
デザイナーがphoto.jpgを更新したのか、それともphoto_old.jpgが最新なのか、誰もわからない。
banner_new.jpgは何が新しいんだ？前のバージョンはどれだ？
画像をGitで管理していたから、どのファイルが本当に必要なのか判断できなくて、不要な古い画像がめっちゃ溜まりました。

さらに悪いことに、別の案件では同じファイル名を使ってしまって、デプロイの時に上書きされるトラブルまで発生。
その時に気づいたんです。「あ、命名規則って技術じゃなくて、チームのコミュニケーション問題や」と。

実務で使える画像命名規則の基本ルール

その失敗から学んで、今の現場で実装している命名規則をお教えします。
これはほんまに効果的でして、チーム内で混乱が減りました。

1. 階層構造を命名に反映させる

まず大切なのは、ファイル名だけで「それがどこに使われるのか」がわかることです。
例えば、ヘッダーに使う画像ならheader_で始めるとか、フッターならfooter_で始める、みたいな感じですね。

具体例を挙げると：

• header_logo.png ：ヘッダーのロゴ
• hero_mainvisual_lg.jpg ：ヒーロー画像、大サイズ版
• card_thumbnail_sm.jpg ：カード型コンポーネントのサムネイル、小サイズ版
• footer_bg.jpg ：フッターの背景画像

このルールがあれば、/imagesフォルダを眺めるだけで、各ファイルの役割が一目瞭然なんです。

2. サイズ情報を含める（特に複数バージョンの場合）

WebやレスポンシブデザインでCSSメディアクエリを使う場合、画像も複数サイズ用意することがありますよね。
その時は必ずサイズを記載するといいですよ。

• _sm ：小（スマートフォン、例：max-width 768px）
• _md ：中（タブレット、例：768px～1024px）
• _lg ：大（デスクトップ、例：1024px以上）

例：

• product_image_sm.jpg
• product_image_md.jpg
• product_image_lg.jpg

僕も最初、product_image.jpgとproduct_image@2x.jpgみたいに区別してたんですが、後からレスポンシブ対応が必要になって、大慌てしました。
最初から複数サイズを想定して命名しておくと、あとあと楽ですよ。

3. バージョン管理は「日付」を使う

デザイナーの修正で画像が更新される場合、古い命名法だとbanner_new.jpg→banner_newer.jpgみたいに無限に増えてしまいます。
そこで、バージョン管理は日付を使うといいですよ。

• hero_mainvisual_20250115.jpg ：2025年1月15日版
• hero_mainvisual_20250120.jpg ：2025年1月20日版

日付を使えば、どっちが新しいのか一目瞭然。
そして古いバージョンは確実に削除できるから、ファイルが溜まることもありません。
Git管理も楽になります。

4. 英数字のみ、小文字、ハイフンで区切る

これは細かいようですが、めっちゃ大事です。
日本語や大文字、アンダースコア、スペースが混在するとサーバー環境によって問題が起こることがあります。

良い例：

• header-logo.png
• hero-mainvisual-lg.jpg
• card-thumbnail-sm.jpg

悪い例：

• Header Logo.png （スペースと大文字）
• hero_main_visual_lg.jpg （アンダースコア、区切り多すぎ）
• card-thumbnail-sm(2).jpg （括弧が入ってる）

チーム開発における命名規則の運用ポイント

ルールを作るだけじゃなくて、それを運用し続けることが大事です。
ここからは、現場でよく見かける問題と対策を紹介します。

命名規則ドキュメントを作る

自分たちの命名ルールを、チーム全体で共有できるドキュメントにしておくといいですよ。
Notionとか、Confluenceとか、README.mdでもいいです。
新しいメンバーが入ってきた時に、「こういうルールでやってるよ」と説明できるようになります。

ドキュメントには以下を含めるといいですよ：

• 命名規則のルール全体
• 実例（良い例・悪い例）
• 各セクション（header, footer, card等）の前置詞
• サイズ略語の定義

デザイナーとの連携

ほんまに大事なのが、デザイナーとのすり合わせです。
デザイナーはPhotoshopやFigmaで素材を管理しているから、Webのファイル命名規則とズレることがあるんですよ。

プロジェクトの初期段階で、デザイナーと「画像ファイルはこういう命名で納品してね」と共有しておくと、あとあとめっちゃスムーズになります。

定期的に不要なファイルをクリーンアップ

古い画像ファイルが溜まると、後から見たときに「これどれが最新だっけ？」ってなります。
日付ベースの命名をしていれば、定期的に古いバージョン