アセット管理

PSD / AI ファイルの命名規則ベストプラクティス

「最終_final_v3 (2).psd」 文化を卒業するための、 NG 名 10 パターン分析と推奨命名 3 方式を実例で解説します。

#命名規則#PSD#AI#ベストプラクティス#Figma
整理されたファイルラベルと命名規則のイラスト

「最終_final_v3 (2).psd」 — こんなファイル名を一度は目にしたことがあるはずです。 笑い話のようでいて、 実際には納品ミス、 修正の手戻り、 検索性の低下を引き起こす 実害のあるパターン です。

この記事では、 個人にもチームにも使える命名規則の 3 パターン、 PSD のレイヤー命名 5 ルール、 エンジニアとの連携を楽にする命名、 そしてチームに浸透させる手順までを解説します。 よく見かける NG 名 10 パターン の分析、 自動化とリネーム実例、 実際の失敗事例も収録しました。

なぜ命名規則が業務効率を決めるのか

ファイル名は、 未来の自分とチームへのメッセージ です。 命名規則を整えることで得られる効果は、 大きく 4 つに分かれます。

  1. 検索性の劇的向上: 統一された命名は、 OS のファイル検索、 タグ検索、 ソート機能、 すべてで威力を発揮します。 「260609_」 のような日付プレフィックスがあるだけで、 時系列での発見スピードが 3-5 倍になることも
  2. 誤納品の防止: 最新版が一目で分かれば、 古いバージョンを送ってしまう事故を防げます。 実際、 制作会社の品質トラブルの中で「ファイル選定ミス」 は上位に入る原因です
  3. 引き継ぎの円滑化: チームメンバーや将来の自分が、 ファイルの位置と意味をすぐ理解できます。 フリーランス案件で過去資料を引き継ぐ際、 命名規則の有無で対応スピードが 2 倍以上違います
  4. エンジニア協業の摩擦軽減: 書き出しファイル名・レイヤー名が整理されていれば、 エンジニアの実装工数も削減。 「icon-map.svg」 のような統一名は、 そのまま実装で使えます

NG 名 10 パターン分析

まずは「絶対に避けたい」 命名パターン 10 個を見ていきましょう。 心当たりがある方は、 今日から修正することをおすすめします。

NG 1. 「最終」 系の名前

最終.psd、 本当に最終.psd、 もう最終.psd。 これらが並ぶ瞬間、 どれが本当に最新か誰も分からなくなります。

NG 2. スペースや特殊文字

image (2).png、 新規ファイル☆.ai。 OS によって表示が崩れたり、 zip 圧縮時に文字化けする原因になります。

NG 3. 大文字小文字の混在

Hero_Banner.psd と hero_banner.psd。 macOS は区別しませんが、 Linux 系サーバーでは別ファイル扱いになり、 デプロイ事故の原因に。

NG 4. 意味のない名前

image1.psd、 untitled.ai、 新規 PSD ファイル.psd。 将来の自分が解読できないため、 ほぼ確実にゴミ箱行きの予備軍になります。

NG 5. 長すぎる名前

80 文字を超える名前は、 一部の OS で切り詰められたり、 zip 解凍時にエラーが出ることがあります。 理想は 50 文字以内。

NG 6. 1 桁の番号

v1, v2, ..., v10, v11。 ソートすると v10 が v2 より先に並びます。 最初から 2 桁ゼロ詰め (v01) が安全。

NG 7. 日本語ファイル名

春のキャンペーン_メインビジュアル.psd。 クライアント納品時、 メール添付時、 GitHub 等へのアップロード時に文字化けトラブルの温床に。 可能なら 英数字ベース にしましょう。

NG 8. 略語の乱用

kv_mv_hb_v01.psd。 略語は便利ですが、 ルールが共有されていないと意味不明です。 略語を使うならチームで辞書を整備しましょう (例: kv = key visual, mv = main visual)。

NG 9. 連番のみで意味なし

file001.psd、 file002.psd 〜 file230.psd。 連番だけでは内容を判別できず、 結局全部開くハメに。

NG 10. 改行や絵文字

banner🎨.psd、 改行を含むファイル名。 ターミナル操作や CI/CD で予期せぬエラーを引き起こします。 絵文字は OS 間で表示が変わることもあるため避けましょう。

ファイル命名規則の NG 例と推奨例の比較イラスト

推奨される 3 つの命名パターン

用途やチーム規模に応じて、 次の 3 パターンから選びましょう。

パターン 1. 日付プレフィックス方式 (個人〜小規模向け)

ファイル名の先頭に日付を入れる方式です。 個人や小規模案件で扱いやすく、 OS の標準ソートで時系列に並びます。

260609_acme_hero_v01.psd
260612_acme_hero_v02.psd
260615_acme_hero_v03.psd

日付は YYMMDD (6 桁) が省スペースで実用的です。 西暦下 2 桁にしても、 ソートに支障はありません。 フリーランスや個人デザイナーに最適。

パターン 2. プロジェクトコード方式 (中規模チーム向け)

クライアントや案件にコードを割り当て、 ファイル名の先頭に置く方式です。

P0042_hero_v01.psd
P0042_banner_a_v01.psd
P0042_banner_b_v01.psd

プロジェクトコードと案件名の対応表 (台帳) を別途用意する必要がありますが、 ファイル名がコンパクトに収まる利点があります。 制作会社やデザインエージェンシー向け。

パターン 3. セマンティック方式 (デザインシステム向け)

ファイルの意味を言葉で表現する方式です。 ロゴ・アイコン・コンポーネントなど、 再利用前提の素材に向いています。

logo_horizontal_white.svg
logo_horizontal_black.svg
icon_search_24px.svg
icon_search_16px.svg

検索性が非常に高く、 デザインシステムの素材管理にも適しています。 順序は 「カテゴリ → バリエーション → 修飾子」 にすると、 ソートしたときにまとまります。

PSD レイヤー命名の 5 つのルール

ファイル名が整っていても、 PSD 内部のレイヤー名が レイヤー 1 や copy のままでは、 開いた瞬間に絶望します。 レイヤー命名も同じ思想で整えましょう。

  1. 必須トップ階層を 3 つ作る: header / content / footer のように、 HTML の構造に沿った階層を必ず最上位に置く
  2. 役割名 + 種類: btn-submit / icon-map / image-hero のように、 「何の」「何か」 が分かる名前
  3. 状態は接尾辞で: btn-submit_hover / btn-submit_active のように、 状態をアンダースコアで区切る
  4. 非表示レイヤーは色ラベル: 「ボツ案」「修正用ストック」「hover 状態」 などをラベル色で区別。 開いた人がすぐ理解できる
  5. スマートオブジェクト化: 使い回す画像はスマートオブジェクトに。 PSD の容量を抑え、 編集時の劣化を防ぐ

参考にした LIG 社の「PSD ルール」 でも、 上位 header / content / footer 必須化、 hover を含むレイヤーの命名、 単語のハイフン区切りなど、 シンプルだが効果的なルールが提唱されています。

エンジニア連携を楽にする命名

デザインから実装に渡すとき、 ファイル名・レイヤー名・アートボード名がそのまま実装側のクラス名やファイル名になることがあります。 連携を楽にする工夫:

  • CSS / JS で使える文字種に: 半角英数 + ハイフンのみ。 アンダースコアを使うか、 ハイフンを使うかはチームで統一
  • サイズはピクセル付きで: icon_search_24px.svg のように、 サイズが明示されていると実装側が混乱しない
  • ガイドラインを PSD 内に: 別レイヤー「guide」 に色コード・フォント・字間など、 実装に必要な情報を記載
  • 書き出し時の自動命名: Photoshop の「ジェネレーター」、 Illustrator の「アセット書き出し」 で、 レイヤー名そのままで書き出せる仕組みを使う

この工夫だけで、 デザイン → 実装の打ち合わせ時間が 30% 以上短縮できる、 という制作会社の実例もあります。

チームに浸透させる 5 ステップ

命名規則は「決めただけ」 では浸透しません。 次の 5 ステップで段階的に進めるのがコツです。

  1. Step 1. ルールを 1 ページの文書にまとめる: Notion や Google Docs に、 良い例・悪い例を並べて記載。 サンプルが多いほど浸透しやすい
  2. Step 2. 新規案件から適用する: 既存案件を一気にリネームすると業務が止まる。 まずは新規案件に限定
  3. Step 3. レビューに「命名チェック」 を組み込む: 週次レビューや成果物確認時に、 命名規則違反がないかをチェック項目に追加
  4. Step 4. ツールで自動化する: Adobe Bridge のリネーム機能、 macOS の「複数名称変更」、 または専用スクリプトで一括リネームを支援
  5. Step 5. 月次で振り返る: 守れていない部分があれば、 ルールが不便か浸透が不足かを議論。 ルールは育てるもの

ツールチェーンとの相性

命名規則は、 使用するデザインツールとの相性も考慮しましょう。

Figma

Figma はファイル名よりも「ページ名」「フレーム名」 が検索対象になります。 ファイル名は「260609_acme_lp.fig」 のようにシンプルに、 内部のフレーム名で「Hero」「Pricing」 のように構造化するのが基本です。

Adobe (Photoshop / Illustrator)

レイヤー名、 アートボード名にも同じ命名規則を適用すると、 書き出し時のファイル名と整合します。 Photoshop のジェネレーター機能や、 Illustrator のアセット書き出しで自動化できます。

Sketch

シンボル名、 ページ名に命名規則を適用。 Sketch の Symbol 命名は「icon/social/twitter」 のように / で階層化できる仕様があるため、 パターン 3 (セマンティック方式) と相性抜群です。

Digift

アセット管理ツールに保存する際は、 ファイル名そのものが検索キーになります。 命名規則を整えておくほど、 タグ検索やコレクション検索と組み合わせたときの威力が倍増します。

自動化と一括リネームの実例

手作業で何百ファイルもリネームするのは現実的ではありません。 自動化の選択肢を紹介します。

1. macOS の「項目名を変更」 機能

Finder で複数ファイル選択 → 右クリック → 「○ 項目の名前を変更」 で、 検索置換・連番付け・形式変更が GUI で実行可能。 シンプルだが強力。

2. PowerToys PowerRename (Windows)

Windows の公式ツール PowerToys に含まれる PowerRename は、 正規表現での一括リネームに対応。 「image (1)」 のような乱れた名前を一気に整えるのに最適。

3. Adobe Bridge のバッチリネーム

Bridge は Adobe ファイル管理の老舗。 「ファイル → バッチリネーム」 で、 連番・日付・既存名の組み合わせを GUI で簡単に設定できる。

4. シェルスクリプト (上級者向け)

mv コマンドや rename コマンドを使えば、 数千ファイルを数秒でリネーム可能。 ただし操作ミスで取り返しがつかないので、 必ずバックアップ後に実行。

失敗事例 3 つに学ぶ

事例 1. 「最終 _final_v5_本当に最終.psd」 を送って大事故

フリーランスデザイナー A さんが、 修正版だと思ったファイルを送ったところ、 実は 1 つ前のバージョンだった。 クライアントが印刷に回してしまい、 数十万円の刷り直しに。 教訓: 「最終」 系の名前は禁句。 バージョン番号で管理。

事例 2. レイヤー名が日本語で実装エラー

Photoshop のジェネレーター機能で書き出したファイル名に日本語が含まれていて、 CI/CD パイプラインで文字化け。 デプロイ直前にエラーが頻発。 教訓: レイヤー名も英数字ベースで。 特に書き出しに使うものは厳格に。

事例 3. スペース入りファイル名で URL がエンコードされ広告のクリック率低下

バナー画像のファイル名に半角スペースを含めていたら、 配信先で URL が %20 にエンコードされ、 一部広告 SDK で正しく読み込まれなかった。 教訓: スペースは絶対に使わない。 アンダースコアかハイフンで区切る。

よくある質問

Q1. 日付は西暦下 2 桁と 4 桁、 どちらが良いですか?
2 桁で十分です。 ファイル管理の現場では数十年単位で過去のファイルを扱うことは稀で、 ソート性も損なわれません。 将来 2100 年問題が気になる方は 4 桁 (20260609) でも構いません。
Q2. バージョンは v1 と v01 どちらが良いですか?
必ず v01 のように 2 桁ゼロ詰めを推奨します。 1 桁だと v10 が v2 より前に並ぶソート崩れが起きます。 ファイル数が多くなる前提なら、 最初から 3 桁 (v001) でも可。
Q3. チーム全員にルールを浸透させるには?
命名規則をドキュメント化し、 プロジェクト開始時に共有しましょう。 良い例と悪い例を並べて示すと、 浸透が早まります。 さらにオンボーディング資料に含めると新メンバーにも漏れなく伝わります。
Q4. 既存の散らかったファイルもリネームすべきですか?
一度に全部やる必要はありません。 「直近 3 ヶ月で触ったファイル」 から段階的に進めるのが現実的。 全リネームは時間の浪費になりがちなので、 「使うときに名前を整える」 が実用的です。
Q5. 命名規則とタグ管理、 どちらが大事ですか?
両方大事ですが、 まずは命名規則を整える方が即効性があります。 タグ管理はサービス依存の機能なので、 サービスを乗り換えると失われるリスクがあります。 ファイル名は OS と環境を超えて残り続ける、 最も基本的なメタデータです。
Q6. アンダースコアとハイフン、 どちらを使うべき?
用途によります。 Web 公開時 (URL になる) ならハイフン (-)、 完全に内部用ならアンダースコア (_)。 SEO 観点では、 Google はハイフンを推奨。 チーム内で 1 つに統一することが何より重要です。
Q7. PSD ファイル名とアートボード名は別物?
はい。 PSD ファイル名は「案件単位」、 アートボード名は「画面単位」 で命名するのが標準。 P0042_lp.psd の中に hero / about / pricing のアートボードがある、 という構造が読みやすい。
Q8. クライアントから「日本語ファイル名で」 と指定された場合は?
納品時のみ日本語ファイル名に変換し、 作業中は英数字で運用するのが安全。 ジェネレーター機能や書き出し時のスクリプトで自動変換できれば、 二重管理の手間が減ります。
Q9. 既存案件にも遡って適用しますか?
運用負荷を考えると、 新規案件から徐々に。 既存案件は「リネームしたら品質が上がる」 と判断できるものだけ手をつけるのが現実的。

まとめ

ファイル名はちょっとした工夫で、 制作効率と納品の信頼性が大きく変わります。 NG 名 10 パターンを避け、 3 つの命名パターンから自分に合うものを選び、 レイヤー命名や自動化も組み合わせる — それだけで、 デザイナー本人もチームもストレスが激減します。

まずは自分の手元のファイルから、 1 つのパターンを選んで試してみてください。 数週間続けると、 「探す時間」 だけでなく「気持ちのモヤモヤ」 も減ることに気づくはずです。 命名規則は地味ですが、 デザイナーの仕事品質を陰で支える 最も重要な土台 です。