月次資料のファイル名は「対象月」で付ける|配布月で命名すると1か月ズレる。過去分は中身から確定してから直す
月次資料のファイル名は「対象月」で付ける|配布月で命名すると1か月ズレる。過去分は中身から確定してから直す
毎月お客様に渡すレポート、毎月受け取る請求書。ファイル名に年月を入れているお店・会社は多いと思います。ところがその年月が「対象月」なのか「作った月」なのかが決まっていないと、半年後に必ず探せなくなります。
先に結論を書きます。
ファイル名に入れる年月は、必ず「対象月」で付けます。資料を作った月でも、お客様に配った月でもありません。9月にまとめた8月分の売上レポートは 2026-08 です。フォルダ名も同じ対象月に揃えます。そして、ファイル名は人が読むラベルではなく機械が読むキーになることを前提に設計します。
この記事では、graciauto(名古屋のWEB制作会社)が多店舗の美容サロンFC本部向けに構築・運用している月次書類ポータルでの実運用をもとに、月次資料の命名ルールの決め方と、すでにズレてしまった過去分の直し方をまとめます。毎月同じ種類の資料を作る・受け取るすべての業種で同じ話です。
結論:年月は「対象月」。作った月でも配った月でもない
月次資料の年月には、候補が3つあります。
| 候補 | 例(8月分の売上を9月3日に作成・9月5日に配布) | 採用 |
|---|---|---|
| 対象月(中身が何月のデータか) | 2026-08 | ◎ これを使う |
| 作成月(ファイルを作った月) | 2026-09 | × |
| 配布月(相手に渡した月) | 2026-09 | × |
採用するのは対象月ひとつだけです。理由は単純で、あとから資料を探す人は必ず「何月分か」で探すからです。「9月に配ったやつ」で探す人はいません。
作成月・配布月は、どうしても必要ならファイルの更新日時やフォルダ内の作業用メモに残せば足ります。お客様に渡す提出物のファイル名は素直な形がいちばん扱いやすく、版数や作業日を混ぜると受け取る側が迷います。
なぜ配布月で命名すると事故になるのか
配布月で命名する運用が危ないのは、「1か月ズレている」ことに誰も気づけないからです。中身を開くまで分からず、開いても「先月分だっけ」と一瞬考えないと判別できません。
実際に起こりうるのは次の2段階です。
第1段階:フォルダ名がズレる。月次資料を月ごとのフォルダにまとめている場合、フォルダ名が作成月で付いていると、8月に作った7月分が「2608」フォルダに入ります。一方、運用を見直して対象月に切り替えたあとは、9月に作った8月分が「2608データ」フォルダに入ります。同じ階層に「2608」と「2608データ」が並び、中身の対象月は1か月違うという状態です。
この状態は実務でそのまま混乱を生みます。資料を探した人が新しいほうのフォルダを開き、7月分が見当たらないので「作られていない」と判断する——名前が似ているぶん、別物だと気づけません。
第2段階:ファイル名の年月もズレる。さらに厄介なのは、フォルダだけでなくファイル名の _YYYY-MM も配布月で付いている場合です。実際に過去分を棚卸しした結果が次の表です。
| フォルダ名 | ファイル名の年月 | 中身の対象月(表の最終列) | 判定 |
|---|---|---|---|
| 2604データ | _2026-05 | 2026/04 | ズレ |
| 2605データ | _2026-06 | 2026/05 | ズレ |
| 2606データ | _2026-06 | 2026/06 | 一致 |
| 2608(旧) | _2026-08 | 2026/07 | ズレ |
| 2608データ | _2026-08 | 2026/08 | 一致 |
フォルダ名・ファイル名・中身の3つが、月によってバラバラに一致したりズレたりしている。これが「配布月で命名する運用」を数か月続けた結果です。一括でリネームしようにも、規則が月ごとに違うので機械的には直せません。
だからこそ、最初の1か月目から対象月で統一しておく価値があります。
命名の型は3つの要素で決まる
実務で破綻しにくい型は次の形です。
{対象}_{種別}_{YYYY-MM}.pdf
例:〇〇店_技術売上_2026-08.pdf
〇〇店_顧客区分別_2026-08.pdf
△△商店_ご請求書_2026-08.pdf
決めるのは3点だけです。
1. 対象(誰の/どこの資料か)
店舗名、オーナー名、クライアント名。既存のフォルダで使っている呼び方に厳密に合わせます。ここで新しい略称を作ると照合が外れます。
2. 種別(何の資料か)
「技術売上」「顧客区分別」「ご請求書」のように、社内で口頭でも使っている言葉をそのまま。種別名に「月次_」のような接頭辞を足したくなりますが、既存の呼び方と違う名前を混ぜないほうが安全です。
3. 対象月(YYYY-MM)
ゼロ埋めのハイフン区切り。2026-08 であって 2026-8 や 202608 ではありません。ゼロ埋めにするのは、ファイル一覧を名前順に並べたときに正しい時系列になるからです。ハイフン区切りは、あとで機械的に切り出すときに扱いやすい形です。
そしてフォルダ名も同じ対象月に揃えます。2026-08データ/〇〇店_技術売上_2026-08.pdf のように、フォルダとファイルで同じ年月が2回出てくる状態が正解です。冗長に見えますが、フォルダから出して単体で渡されたファイルでも対象月が分かるという意味があります。
| 良い例 | 避けたい例 | 理由 |
|---|---|---|
| 〇〇店_技術売上_2026-08.pdf | 技術売上(8月分)最新版.pdf | 「最新版」は翌月に嘘になる |
| 〇〇店_技術売上_2026-08.pdf | 20260903_技術売上_〇〇店.pdf | 先頭が作成日=名前順が対象月順にならない |
| 2026-08データ/ | 2608 と 2608データ の並存 | 似た名前で対象月が違う |
ファイル名は「人が読むラベル」ではなく「機械が読むキー」になる
命名ルールを軽く扱ってはいけない最大の理由がここです。月次業務を少しでも自動化すると、ファイル名がそのまま処理の判断材料になります。
実際に運用しているオーナー向け書類ポータルでは、PDFを複数まとめて、あるいはZIPのまま管理画面に投げ込むと、ファイル名の「店舗名」「種別」「年月」を読んで、年月×店舗×種別のマトリクスへ自動で振り分けます。照合できなかったものだけが手動割当の対象として残ります。つまり命名が揃っていれば投入は数十秒で終わり、揃っていなければ全部手作業に落ちます。
日次データでも同じです。革製品ブランドのEC向けに作った在庫計算の仕組みでは、販売データのExcelを 販売_YYYY-MM-DD.xlsx という名前で所定のフォルダに置く決まりにしています。ここで重要なのは、シート名が Sheet1 のままでも、ファイル名の日付を採用するという設計です。中の書式は現場によってブレますが、ファイル名は運用ルールで統一できるからです。
あわせて、同じ日付のファイルが複数あったら1件だけを採用するルールも入れておきます。優先度と更新日時で1件に絞り、同じ日の売上を二重に足してしまう事故を防ぎます。ファイル名を処理のキーにするなら、キーが重複したときの決着方法までセットで決めるのが正しい設計です。
命名を「見た目の問題」だと思っていると、自動化した瞬間に登録されない・別の月に入る・二重に計上されるという形で表面化します。逆に言えば、命名が揃っているだけで自動化の難易度は大きく下がります。
人が月を選び間違えない画面にしておく
ファイル名を揃えても、アップロード画面で月を選ぶ場面があると、そこが新しいズレの入口になります。
対策は2つです。
年月の初期値を「前月」にする。月次資料を登録するのはたいてい翌月です。カラー剤の請求書を倉庫スタッフが登録する専用ページでは、年月の既定値を前月にしてあります。9月に開けば 2026-08 が最初から入っている状態です。何もしなければ正しい月になるので、選択ミス自体が起きにくくなります。
登録状況を件数で見せる。「13オーナー中 n件 登録済み」のように、その月に何件そろったかを画面に出します。月を間違えて登録すると、本来の月の件数が増えないのでその場で気づけます。登録した本人が異常に気づける形にしておくのが、後工程で探すより何倍も安い対処です。
外部のスタッフに渡す画面なら、種別を固定してしまうのも有効です。倉庫向けのリンクでは登録できる種別を「カラー剤請求書」だけに限定しており、種別の取り違えは構造的に起きません。
すでにズレている過去分を直す4ステップ
過去分が配布月で命名されている場合、いきなり一括リネームをかけてはいけません。前述のとおり月によってズレ方が違うため、一律の変換では別の月を上書きします。
ステップ1:棚卸し表を作る
フォルダ名・ファイル名の年月を機械的に一覧化します。この時点ではまだ中身を見ていないので「自称の年月」です。
ステップ2:中身から対象月を確定する
ここが本題です。PDFなら1ページ目のテキストを抜き出し、「最新月:2026/07」のような記載か、表の最終列の年月を読みます。Excelなら日付列の最大値です。ファイル名ではなく中身が真という前提で、1件ずつ対象月を確定します。
ステップ3:対照表を目で確認してから改名する
「現在の名前 → 変更後の名前」の一覧を先に出力し、人が見て納得してから実行します。この一手間があるだけで、ステップ2の判定ロジックがおかしかった場合に本番ファイルを壊さずに済みます。
ステップ4:旧フォルダをどうするか決める
過去分をすべて移動するか、古い分は元の場所に残して索引だけ作るか。判断はどちらでも構いませんが、決めて記録することが重要です。記録がないと、次に探した人がまた同じ迷い方をします。実際の運用でも、7月分だけ旧フォルダに残したまま「移すかは判断待ち」と記録し、どこに何があるかは分かる状態にしています。
名前の照合が滑る3つの落とし穴
ファイル名で自動照合する仕組みを作ると、命名は合っているのに一致しない事象が起きます。原因はだいたい次の3つです。
1. 名前に余分なスペースが入っている
マスタ側の店舗名に全角スペースが混ざっていると、単純な文字列一致が外れます。表示上は気づけません。実際に、店舗名にスペースが入っている1店だけ毎月「資料が未生成」と表示され続けた例があります。対処は、照合前に空白を除去して比較することと、可能ならマスタ側の名前を正すことです。
2. 呼び方が途中で変わる
資料の種別名は運用の中で変わります。たとえばお客様向けの表記を「AIレビュー」から「分析結果」へ改めた場合、過去のファイルは旧名のままです。照合には別名テーブルを持たせ、「分析結果」「AIレビュー」「分析」「レビュー」のどれでも同じ種別として拾えるようにします。表示名は変えてよいが、照合は互換を残す。これが安全な変更の仕方です。
3. 日本語ファイル名の濁点(macOS特有)
macOSはファイル名の濁点・半濁点を分解した形(NFD)で保存することがあります。「ズ」が「ス+濁点」の2文字として扱われるため、プログラム側に書いた文字列(NFC)と一致しません。ファイルは画面上に見えているのに、スクリプトからは見つからないという状態になります。
対処は、日本語ファイル名を扱う処理では必ず正規化してから比較することです。Pythonなら unicodedata.normalize('NFC', name) を通します。ファイル一覧の取得は通るのにコピーや検索で滑るときは、まずこれを疑ってください。
根本策は「生成元を一本化する」
ここまでルールの話をしてきましたが、命名がズレなくなる一番の対策は、手で名前を付ける工程をなくすことです。
手作業で月次資料を作っている間は、どれだけルールを決めても「今月は急いでいたから」で崩れます。前掲の棚卸し表でズレが出ているのは、いずれも1枚ずつ手元で生成していた時期の分です。生成をポータル側の一括出力に切り替え、対象月をシステムが決めてファイル名まで組み立てる形にしてから、フォルダ名・ファイル名・中身の3つが一致する状態が続いています。
一括出力に切り替えるときに、あわせてやっておくべきことが1つあります。資料の中の月名をコードに直接書かないこと。「8月の運用ポイント」「7月は…8月は…」といった文言をハードコードしていると、翌月に生成しただけで中身が嘘になります。対象月を引数で受け取り、そこから月名を計算する作りにしておけば、月替わりは対象月の指定を変えるだけで済みます。
まとめ:この6項目だけ決めれば崩れない
- 年月は対象月で付ける。作成月・配布月は使わない
- 型は
{対象}_{種別}_{YYYY-MM}。ゼロ埋め・ハイフン区切り - フォルダ名も同じ対象月に揃える。似た名前のフォルダを並存させない
- ファイル名は機械が読むキー。同じキーが重複したときの決着方法まで決める
- 登録画面の年月は初期値を前月にし、登録件数をその場で見せる
- 過去分は中身から対象月を確定し、対照表を確認してから改名する
命名ルールは地味ですが、月次業務を自動化するときの土台になります。ここが揃っていないと、どんなに良い生成の仕組みを作っても、最後の「どこに入れるか」で人手に戻ります。逆に、この6項目を最初に決めておけば、あとから自動化する余地がそのまま残ります。
月次のレポート作成や書類の受け渡しを仕組みにしたい方は、お問い合わせからご相談ください。現在の運用をうかがったうえで、どこから自動化できるかをお伝えします。