改元のとき、社内の書式を直した記憶がある。「平成」と刷ってあるゴム印を作り直し、システムの表示を直し、在庫の用紙を刷り直した。
あのとき、直さなくてもよかったと知ったら、どう思うだろうか。
政府の申合せに、そう書いてある。存在しないはずの「平成31年5月」という表記も、有効なものとして受け付けることになっていた。
この記事は育ちます。公開後も、会話パート・トーク・補足を足していきます。
公開 2026-10-12 ／ 最終更新 2026-10-12（公開）
水深 — 元号は、法律2行で決まっている
まず前提から。元号の根拠は元号法（昭和54年法律第43号）だ。
条文は、驚くほど短い。
- 元号は、政令で定める
- 元号は、皇位の継承があった場合に限り改める
これだけ。2項しかない。
つまり、元号そのものは法律で決まっていない。政令で決めると法律が言っているだけだ。
だから「令和」は法律ではなく、政令で定められている。平成31年政令第143号「元号を改める政令」。2019年4月1日に公布され、5月1日に施行された。
法律より下の形式で、元号が決まっている。 ここが意外だった。
改元の日付を、正確に並べる
混乱しやすいので、日付を整理しておく。
- 2019年4月1日 新元号「令和」を公表。政令を公布
- 2019年4月30日 天皇退位。この日までが平成31年
- 2019年5月1日 即位。この日から令和元年
だから「平成31年」は4月30日までしか存在しない。5月1日以降は令和元年になる。
ところが、書類にはそれ以降の日付が「平成31年」で書かれていることがある。
- 改元前に作った、5月以降の日付が入った書類
- 「平成31年度」という年度表記
- 有効期限が「平成33年まで」と書かれた証明書
これらをどう扱うか。
政府の申合せ — 有効である
2019年4月1日、「新元号への円滑な移行に向けた関係省庁連絡会議」が申合せを出している。「改元に伴う元号による年表示の取扱いについて」。
そこに、はっきり書いてある。
「平成」を用いて改元日以降の年を表示している場合であっても、当該表示は有効なものであり、改元のみを理由とした一括整理は行わないものとする
さらに、国民が申請する場合についても。
国民が各府省に申請等を行う場合において、改元日以降の年の表示が「平成」とされていたとしても、有効なものとして受け付ける
そして、様式に「平成」が残ってしまう場合についても。
やむを得ず申請、届出等又は処分の通知等の様式に「平成」の表示が残る場合であっても、当該表示は有効なもの
三段構えで「有効」と書いてある。
つまり、
- 改元前に作った書類の「平成31年6月」→ 有効
- 国民が「平成32年」と書いて出した申請 → 受け付ける
- 役所の様式に「平成」が残っている → 有効
改元だけを理由に、書類を作り直す必要はなかった。
なぜ、わざわざこれを決めたのか
理由は想像がつく。やらないと社会が止まるからだと思う。
- 世の中の書類に「平成」と書かれたものが何億枚もある
- 有効期限が平成33年、平成35年と書かれた証明書が出回っている
- 全部を刷り直し、差し替えることは物理的に不可能
「平成31年5月は存在しないから無効」としてしまうと、膨大な書類が一斉に使えなくなる。だから最初に「有効です」と宣言した。
改元の1か月前に、公表と同時にこれを出している。手当てのほうが先に用意されていたことになる。
それでも直したほうがいいもの
有効だからといって、全部そのままでいいわけではない。
直したほうがいいもの
- これから新しく作る書式（新元号で作る）
- 対外的に出す文書（相手に不信感を与える）
- システムの日付計算（和暦の変換ロジック）
急いで直さなくていいもの
- 既に発行済みの書類
- 在庫の用紙（使い切ってから）
- 過去の帳簿、保存されている書類
帳簿の日付を、改元を理由に書き換えるのは、むしろやってはいけない。訂正の痕跡が残らない書き換えになる。作成時点の表記のまま残しておく。
改元のたびに全部を直そうとすると、かえって記録の一貫性が壊れる。
システム側で起きたこと
2019年の改元では、システム対応がかなり大きな話題になった。
Windowsでは、新元号に対応するための更新プログラムが配布された。更新していない端末では、令和1年が「平成31年」のまま表示される、という現象が起きた。
Excelでも同じで、和暦表示の書式（[$-ja-JP]ggge年m月d日 のような指定）を使っている場合、OSが対応していないと令和が出ない。
そして、いまも残っている問題がある。元号が1文字に略される場面だ。
- 明治 → M
- 大正 → T
- 昭和 → S
- 平成 → H
- 令和 → R
「R8.9.27」のような表記になる。ここで困るのが、令和の R と、他の元号との衝突だ。幸い M/T/S/H/R は重なっていないが、次の元号が来たときに同じ頭文字を避けられる保証はない。
一文字略記は、将来にわたって安全とは言えない書き方になっている。
和暦と西暦、どちらで持つか
実務の話に落とす。データとして日付を持つとき、和暦と西暦のどちらにすべきか。
答えははっきりしていて、西暦で持つ。
理由は3つある。
① 和暦は連続していない
昭和64年は1月7日までしかない。平成31年は4月30日まで。同じ年に2つの元号が存在する年がある。並べ替えも期間計算も、素直にできない。
② 将来の日付が表現できない
「令和50年」が存在するかどうかは、誰にも分からない。将来の契約期限を和暦で持つと、改元のたびに意味が変わる。
③ 変換の方向が限られる
西暦から和暦へは、改元日の表さえあれば変換できる。逆は、同じ年に2つの元号がある期間で曖昧になる。
だから、
- データは西暦で持つ
- 表示のときだけ和暦に変換する
Excelなら、セルには西暦で入れて、書式で和暦にする。値は西暦のまま、見た目だけ和暦になる。
日付の話は、だいたい「持ち方」と「見せ方」を分けるという結論になる。Excelのシリアル値の話と同じ構図だった。
「元年」と「1年」
もうひとつ、細かいところ。
改元した最初の年は「令和元年」と書く。「令和1年」も間違いではないが、公用文では「元年」を使う。
システムでは「1」として扱われることが多い。だから、表示のときに1だけ「元」に置き換える処理が要る。ここを作り込んでいないシステムだと、「令和1年」と印字される。
対外文書では気になるところなので、帳票を作るときは確認しておく。
年度と、元号
もうひとつややこしいのが年度だ。
日本の会計年度は4月から3月。改元が5月1日だったので、2019年度は「平成31年度」として始まり、途中で令和元年になった。
このとき、年度の呼び方をどうするか。
結論としては、「令和元年度」と呼ぶのが一般的になった。年度の途中で改元しても、その年度全体を新元号で呼ぶ。
ただし、年度の初めに作った資料は「平成31年度」と書かれている。同じ年度を指す2つの呼び方が並ぶことになった。
過去の資料を探すときは、両方で検索する必要がある。これは今後もずっと残る。
航路 — 手当てのほうが、先にあった
整理する。
- 元号の根拠は元号法（昭和54年法律第43号）。条文は2項だけ
- 元号そのものは政令で定める。令和は平成31年政令第143号
- 平成31年は4月30日まで。5月1日から令和元年
- 政府の申合せは、改元日以降の「平成」表記を有効とし、一括整理は行わないとしている
- 国民からの申請も、「平成」と書かれていても受け付ける
- 帳簿の日付を改元を理由に書き換えてはいけない
- データは西暦で持ち、表示だけ和暦にする
- 年度は「令和元年度」。ただし「平成31年度」と書かれた資料も残る
調べていて意外だったのは、混乱を想定した手当てが、改元の1か月前に用意されていたことだった。
新元号を公表した4月1日に、同時に「平成と書いてあっても有効です」と申し合わせている。混乱が起きてから対応したのではなく、起きることを前提に先に決めてあった。
あのとき慌てて書式を直したのは、必要な作業だったのか。いまとなっては分からない。ただ、直さなくてよかったものまで直していたことは確かだと思う。
和暦と西暦、どちらで書くか
書類を作るとき、どちらを使うか。場面で分かれる。
和暦が求められる場面
- 官公庁の様式に「令和 年 月 日」と刷ってある
- 登記、戸籍、税務の申告書
- 社内の慣行として和暦になっている帳票
西暦のほうがいい場面
- 海外とのやりとり
- システムのデータ
- 長期の計画（5年後、10年後を扱うもの）
- 過去との比較表
公用文でも、西暦の併記が増えている。「令和8年（2026年）」という書き方は、どちらの読み手にも通じる。
迷ったら併記でいい。文字数は増えるが、読み違えは減る。
和暦の変換で、間違えやすいところ
Excelや手計算で変換するときの注意点。
① 改元の年は、2つの元号が同居する
1989年は、昭和64年（1月7日まで）と平成元年（1月8日から）。2019年は、平成31年（4月30日まで）と令和元年（5月1日から）。
「1989年は平成元年」と単純に変換すると、1月のデータがずれる。年だけでなく、月日まで見ないと変換できない。
② 明治より前は、暦が違う
明治5年12月2日の翌日が、明治6年1月1日になっている。太陰太陽暦から太陽暦に切り替わったからだ。明治5年12月3日から12月31日は、存在しない。
古い記録を扱うときは、ここで必ずつまずく。
③ 昭和64年、平成31年は「ある」
短いだけで、存在する。「昭和64年1月5日」は正しい日付だ。システムが弾くようなら、それはシステムのほうが間違っている。
④ 年度と年は違う
「令和7年度」は、2025年4月1日から2026年3月31日まで。年度の後半は、西暦の年が変わっている。
「令和7年度の3月」は2026年3月であって、2025年3月ではない。ここを取り違えると、資料の年が1年ずれる。
官公庁の書類で、和暦が残る理由
なぜ役所は和暦を使い続けるのか。
法令そのものが和暦で書かれているから、というのが大きいと思う。「平成30年4月1日以後に開始する事業年度」のような書き方が、条文にそのまま入っている。
条文を和暦で書いている以上、それを引用する通達も様式も和暦になる。上流が和暦だと、下流も和暦になる。
一方で、政府の文書でも西暦併記は増えている。2019年には、各府省の文書で西暦を併記する動きが出た。完全に切り替えるのではなく、併記で当面しのぐという方向になっている。
これも、原則を変えずに例外を足していく形だった。
システムで和暦を扱うときの設計
自分でシートやツールを作るなら、こうしておくと安全だと思う。
① データは西暦のシリアル値で持つ
Excelなら普通に日付として入れる。書式で和暦にする。
② 変換表を1枚持つ
改元日の一覧を、シートに置いておく。
| 元号 | 開始日 |
|---|---|
| 明治 | 1868-10-23 |
| 大正 | 1912-07-30 |
| 昭和 | 1926-12-25 |
| 平成 | 1989-01-08 |
| 令和 | 2019-05-01 |
（明治の開始日については、改元の詔が出た日と、慶応4年1月1日にさかのぼって適用された扱いの両方があり、資料によって記載が分かれる。実務でさかのぼる必要がある場合は、提出先の扱いを確認したほうがいい。）
③ 表示は書式で、比較は西暦で
並べ替え、期間計算、条件判定は、すべて西暦の値で行う。和暦は最後に文字として出すだけにする。
④ 「元年」の置き換えを1か所にまとめる
複数の場所で置き換えていると、1か所直し忘れる。表示用の関数を1つ作って、そこだけ直せばいいようにしておく。
次の改元に備えるなら
いつ来るかは分からないが、来たときに困らない作り方はある。
- 和暦をハードコードしない（「平成」と直接書いた文字列を式に埋め込まない）
- 改元日の表を、データとして持つ（表に1行足せば対応できる形にする）
- 帳票の元号を、変数にしておく
- 在庫の用紙に元号を刷らない（空欄にして手書き、またはゴム印）
2019年のときに各社が苦労したのは、元号が埋め込まれていたからだった。プログラムの中、帳票の版下、ゴム印、在庫の封筒。
そして政府は「平成のままでも有効」と先に宣言していた。慌てて直す必要は、実はそこまでなかった。
次に備えるなら、いちばん効くのは「急いで直さなくていいものを、あらかじめ知っておく」ことだと思う。有効だと分かっていれば、落ち着いて順番に直せる。
この記事は、まだ書きかけです
この記事は、公開してから足していく形にしています。調べたことを書いた本文がまず先にあって、あとから「聞き手と話し手の会話」「あとで思い出したこと」「読んだ人から教わった補足」が積もっていきます。
だから、同じURLでも半年後には別のものになっているはずです。もし一度読んだことがある記事なら、下の更新ログだけ見てください。増えたところが分かります。
更新ログ
- 2026-10-12 公開（本文のみ。会話パートはこれから足します）
