
アイキャッチ画像の命名規約 — 350枚超を破綻させない管理
GDE・GCVP・GPRMの3ブログ記事は、すべて1つのリポジトリ(GeoMediaHub)にまとめて格納しています。3サイト分の画像が1か所に集まると、真っ先に問題になるのがファイル名の衝突と迷子です。今回は、実際にどんな命名規約と運用ルールで画像を管理しているかを紹介します。
素朴に管理すると何が起きるか
複数サイトの画像を1リポジトリにまとめる場合、ありがちな失敗は「slugと同じ名前のファイルを、サイトを気にせず置いていく」運用です。GDE・GCVP・GPRMは題材が近い(測地系・座標変換)だけに、記事タイトルも似通いやすく、heatmap-guide.pngのような汎用的な名前は簡単に衝突します。衝突すると、後から追加した画像が既存の画像を上書きしてしまう、あるいは「このファイルはどのサイトの記事用か」がファイル名だけでは分からなくなる、という事態が起きます。
採用している命名規約
アイキャッチ画像は、次の形式に統一しています。
images/eye/<製品接頭辞>-<記事slug>.png
製品接頭辞は gcvp / gprm / gde(UwView関連は uvp)の4種類。例えば、GPRMのbenchmark-types-learningという記事のアイキャッチならgprm-benchmark-types-learning.pngとなり、ファイル名を見ただけでどのサイトのどの記事のものかが判別できます。
保存先フォルダもサイトごとに分離しています。
| 製品 | アイキャッチ保存先 |
|---|---|
| GCVP | 4-post/gcpro/images/eye/ |
| GPRM | 4-post/gmp/images/eye/ |
| GDE | 4-post/gde/images/eye/ |
本文中に埋め込むタグは、widthをアイキャッチは80%、本文中の補足図は50〜70%程度に分けて指定するのが定番のスタイルです。
<img style="width:80%;max-width:100%;height:auto;display:block;margin:0 auto;" src="../images/eye/gde-slug-name.png" alt="...">
本文中スクリーンショットは製品ごとにフォルダ構成が異なる
アイキャッチ以外の、アプリ画面スクリーンショットや解説図は、実は3サイトでフォルダ構成が微妙に異なります。これは各サイトが別々の時期に立ち上げられ、後から命名規約を統一したという経緯によるものです。
| 製品 | スクリーンショット等の保存先 |
|---|---|
| GCVP | 4-post/gcpro/image/(旧blog/txt/から移設・単数形のimage) |
| GPRM | 4-post/gmp/images/(複数形のimages。動画は4-post/gmp/*.mp4) |
| GDE | 4-post/gde/images/(複数形のimages) |
GCVPだけimage(単数形)というのは統一し損ねた名残ですが、アイキャッチ用のimages/eye/サブフォルダは3サイトとも複数形で揃えているため、実務上の混乱は起きていません。
現在の画像数(2026-07-30時点)
各フォルダの実際の枚数を数えると、次のようになっています。
| フォルダ | 枚数 |
|---|---|
GCVP image/(本文用) |
40枚 |
GCVP images/eye/(アイキャッチ) |
59枚 |
GPRM images/直下(本文用) |
58枚 |
GPRM images/eye/(アイキャッチ) |
32枚 |
GDE images/直下(本文用) |
24枚 |
GDE images/eye/(アイキャッチ) |
44枚 |
合計で250枚を超える画像が、この命名規約に沿って管理されています。
grepで探せるカタログ、ただし対象範囲に注意
画像索引(image-index.md)というカタログファイルも運用しています。各画像を1枚ずつ目視してキーワード化したもので、「能登」「ジオイド差分」のようなキーワードでgrep検索すれば、流用できそうな既存画像をすぐ見つけられる仕組みです。
ただし、このカタログは2026-07-06作成時点でGCVPとGPRMの画像(352枚)のみを対象にしており、GDEの画像は対象範囲外という既知のギャップがあります。命名規約自体は3サイト共通ですが、目視カタログ化の作業はGCVP・GPRMを先に進めた経緯によるものです。GDE記事で画像を再利用したい場合は、現状はカタログではなくフォルダを直接lsして探す運用になっています。
命名規約が効いている場面
- 記事作成時の再利用判断が速い:「この記事に合いそうな画像はないか」を探すとき、接頭辞でサイトを絞り込めるため、無関係なサイトの画像を誤って本文に埋め込むミスが起きにくい
- 相対パスの参照ミスを防ぎやすい:本記事の基本方針にもあるとおり、画像は同一サイト内のものしか相対パスで参照できません。接頭辞がサイトを明示していることで、「別サイトの画像を誤って参照する」ミスにファイル名の時点で気づきやすくなります
- 接頭辞導入前の画像との共存:
proj-geocore-comparison.pngのように接頭辞のないレガシーな画像ファイルも残っていますが、新規画像はすべて接頭辞付きで統一しているため、新旧が混在していても実害はありません
まとめ
- アイキャッチ画像は
images/eye/<接頭辞>-<slug>.png形式(接頭辞はgcvp/gprm/gde/uvp)で3サイト共通管理している - 本文用スクリーンショットの保存フォルダ名は、立ち上げ時期の違いから
image/imagesとサイトごとに微妙に異なる(実害はない) - 2026-07-30時点で合計250枚超の画像を管理しており、image-index.mdによるgrepカタログはGCVP・GPRM限定という既知のギャップがある
関連記事
- なぜWordPressブログを3つに分けたのか — 製品別マルチサイト運営の判断(GeoDiveExa)
- 日付入りパーマリンクの功罪 — 内部リンク404を防ぐ運用(GeoDiveExa)
- 正典ファイル1枚でAIに文脈を渡す — レジストリ方式のすすめ(GeoPrism JP)
- 進捗.mdで制作ログを残す — AI協働時代の作業記録術(GeoConverterPro)
- ブログの技術図解はすべてAI生成——依頼するだけで完成する時代(GeoConverterPro)
開発者より: アプリ・Kindle本・オープンソースの一覧は GitHub: amru195704 にまとめています。
お願い
本記事の情報は参考目的で掲載しており、正確性・完全性を保証するものではありません。誤記・不正確な情報がございましたら、コメント欄よりご指摘いただければ、確認のうえ修正いたします。

コメントを残す