年問題

年問題（ねんもんだい）は、暦上のある年や日付が到来すると、社会や日常生活に深刻な影響が起きる社会問題のことである。「Y年問題」や「Y年M月D日問題」のように呼ばれる。年問題は主に下記の3種類のものがある。 コンピュータの時刻処理における「桁溢れ」などの想定外の事態 人の動きや唐突な社会制度の変化による歪みの発生 暦そのものの構造的な欠陥（旧暦2033年問題など） 年問題という表現の発端は、コンピュータシステムにおける2000年問題が騒がれた出来事であり、それ以後は社会現象などの諸問題にも使われている。 コンピュータは記憶装置の容量や処理能力がいくら大きくとも原理的に有限の数字しか扱えず、想定していない日付を扱おうとした場合や、特定の年月日や時刻になった場合に誤作動を起こす（オーバーフロー、桁あふれ）。このシステム時刻処理に関する問題は、現代のように生活のあらゆる部分にITが行き渡っている時代には、思わぬところで思わぬ問題を起こしかねない。 日本で初めてコンピュータ内部の「年」に関する問題が起こったのは、1989年1月7日に昭和天皇の崩御によって元号が「昭和64年」から「平成元年」に変更された時である。特に公文書などで元号の変更を想定していなかったシステムが多数あったことから、問題が顕在化した。この他、年数を下2桁だけで処理していたシステムの中には、「昭和Y年」または「平成Y年」とみなして処理するものがあり、これにより誤動作が起きる場合もあった。 2000年問題（後述）では、事前に各企業が大量の経費を投入してシステムのチェックを行った上で、2000年が到来した瞬間には多数のソフトウェア技術者が何かあった時のために待機するなどの体制が取られ、世界的な社会現象となった。 なお年問題は、未来の日付を取り扱う必要が出てくると、その年に先んじて問題が顕在化することもある。例えば、10年更新の保険契約を扱う場合は10年前に誤動作が起こりうる。また、未来の日付を取り扱わない場合でも、計算の都合などで時間を数倍することがあり、それにより誤動作が起こりうる場合も存在する。 1999年問題 - 1900年を1年目と内的処理していた場合、年数が2桁から3桁になる。また、年号を下2桁だけで処理していたシステムの一部で年のエントリで99をエラーコードや例外値として扱っているものがあったとされ、そのようなシステムでは1999年になった途端に正当な1999年とエラーとを識別できず不具合をおこすことが懸念された。又、9が5つ並ぶ1999年9月9日にエラーが発生することも懸念された。 1999年8月21日問題 - GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から1,024週後にあふれて0に戻る。 2000年問題 (Y2K) - 年数を下2桁だけで処理していたシステムや、2000年を平年（閏年ではない）と誤解したシステムに問題が起こる。 2001年9月9日問題 - 1970年1月1日0時からの秒数が十進法で9桁から10桁になる。経過秒数を文字列表現に直してソートしたことで、「1,000,000,000 < 999,999,999」と判断してしまい、項目の新旧が正しく処理されない問題が実際に幾つかのシステムで発生した。 2004年1月10日問題 - 2038年問題の派生形で、1970年1月1日0時（Unix epoch）から2038年1月19日までの約21億秒の中間点にあたるこの日に潜在的なバグが発覚した。KDDIの通話料金処理、IIJのSEIL/neuルーター、20行以上の日本国内銀行ATMで、同日または翌日以降にトラブルが発生した。CADソフト「Pro/ENGINEER」は1ヶ月前に誤動作の可能性を発見し、予め対処してトラブルを回避した。 2008年問題 - 2000年以降も年数を下2桁だけで処理していたシステムで、かつ年を文字列で格納していた場合に、先頭が0の場合には八進数として扱われる処理系があり、その場合2008年の時点で年の処理が不正となる場合がある。ごく一部のperlで作成されたネットゲームで誤作動が発生した事例がある。 2010年問題 - 潜在的なバグが発覚した。シチズン製電波時計やソニーのゲーム機「プレイステーション3」（閏年処理）、オーストラリアのクイーンズランド銀行でのシステム誤動作、ドイツジェムアルト社のICカード使用不能など。シチズンのケースでは、年の内部表現に西暦下2桁のBCDを使っていた。 2019年4月7日問題 - GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から2,048週後にあふれて0に戻る。（10ビットでは2回目） 2020年問題 - 2000年問題の1920年起点版。UNIXエポックの1970年1月1日±50年である1920 - 2019年をdate windowとしたシステムで誤動作を起こしている。 2022年問題 - 日時をyymmddHHMMの形式で扱っているシステムで、この値を32ビット符号付き整数（最大値は2,147,483,647）に変換した場合、2022年1月1日にオーバーフローする。Microsoft Exchange Server 2016/2019で問題が発生した。 2036年2月7日問題 - 1900年1月1日0時からの秒数が32ビットからあふれ、NTPに問題が起こる。NTPv4（バージョン4）以降では解決される。　 2038年1月19日問題 - いわゆる2038年問題。Unix等で、1970年1月1日0時（Unix epoch）からの秒数が31ビットからあふれ、32ビット符号付きで処理しているシステムに問題が起こる。ext2、ext3、ReiserFS、UFS1、XFS等の各ファイルシステムのタイムスタンプはこの日までしか扱えない。また、古い32ビット版のミドルウェアやライブラリを利用したアプリケーションにも問題が発生しうる。 2038年4月23日問題 - ユリウス通日を内部日付表現に用いる物のうち、基準日（グレゴリオ暦1858年11月17日正午）からの修正ユリウス日（MJD）を使用し、かつ16ビットで処理しているシステムでは、日数が16ビットからあふれるために問題が起こる。 2038年11月21日問題 - GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から3,072週後にあふれて0に戻る。（10ビットでは3回目） 2040年問題 - MacOS等のファイルシステムHFSのタイムスタンプは2040年2月6日までしか取り扱えない。 2042年問題 - System zのSTCK命令で取得する64ビットのTODクロックは2042年9月17日中にオーバーフローする。 2048年問題 - 2038年問題の1980年起点版。 2053年問題 - 2038年問題の1985年起点版。TRONなど。 2079年問題 - FATファイルシステムのタイムスタンプの起点の1980年1月1日を基点として、年数を下2桁だけで処理するソフトウェアなどは、その起点の99年後（2079年12月31日）までしか正常動作しない。 2100年問題 - 2000年以降に作られた年数を2桁で表すシステムや、2100年を閏年と誤解したシステムに問題が起こる。 2108年問題 - FATファイルシステムのタイムスタンプは2107年12月31日までしか取り扱えない。 2137年問題 - 更新されたGPSは内部処理で週数を13ビットで管理しており、この頃にあふれて0に戻る（正確な日時は未定）。 2155年問題 - ISO 9660ファイルシステム（CD-ROM等）のタイムスタンプ限度。 2286年問題 - 2001年9月9日問題の11桁版。2286年11月20日17時46分40秒予定。 2514年問題 - UNIX等のファイルシステムext4のタイムスタンプ限度。2514年4月25日予定。 3000年問題 - Visual C++において、3000年1月1日以降の日付処理に不具合が生じる。 5138年問題 - 2001年9月9日問題の12桁版。5138年11月16日18時46分39秒予定。 10000年問題 - 西暦が5桁になる西暦10000年1月1日に起こる。 Excel,Google スプレッドシートの日付処理で不具合が生じる。 UDF（光ディスク等）のタイムスタンプ限度（9999年12月31日まで）。 32768年問題 - LibreOffice CalcやWindowsのシステム[要出典]では西暦は16bit符号付きで表すことができるが、32768年にオーバーフローを起こす。 60056年問題 - NTFSのタイムスタンプ限度。 2億9千万年問題 - 292278994年8月17日以降Javaの日付処理に問題が生じる。 2922億7702万6596年問題 - 64ビット符号つきUNIXシステムの上限は292277026596年12月4日15時30分7秒まで。ただし、2013年時点では宇宙の年齢は137億年程度と考えられている。 昭和100年問題（2025年） - 2025年は、内部で年を昭和2桁で管理するシステムでは「昭和100年=昭和0年」と認識され、問題が起こる。 皇紀2700年問題（2040年）- 2000年問題と同じく、システム内部で年を皇紀の下2桁で管理するシステムにおいて、問題が発生する。 平成100年問題（2088年） - 昭和100年問題と同じく、2088年が「平成100年=平成0年」と誤認されることにより、内部で平成2桁で管理されているシステムに問題が起こる。 令和100年問題（2118年） - 昭和100年問題、平成100年問題などと同じく、2118年が「令和100年=令和0年」と誤認されることにより、内部で令和2桁で管理されているシステムに問題が起こる。 民国100年問題（民國100年問題、Y1C） - 中華民国（台湾）で使用している民国紀元で2011年が民国100年となることによる問題。 閏年問題 - 閏年を処理するプログラムのバグにより誤動作する。2008年1月31日以降、日本の約3200台の公衆電話が閏年問題による障害で一時的に使用不能となった。 閏秒問題 - 閏年問題の閏秒バージョン。こちらもプログラムのバグにより誤動作する。 以下は、正確にその年が問題となるものもあるが、数年にわたる現象のピークを示すものや、統計上興味深い変化が予想される場合など、その年に実際に何かが起こるわけではないものもある。また、事前の予測年と事象の実際の発生年が異なった場合や、その事象に関する関係者らの事前の対策や努力などで回避・先送りできたり、あるいは過去に問題の発生が予測・懸念されても、その後の社会の変化などで実際には問題は起こらず単なる杞憂に終わった事象もある。 2007年問題 EUの株式市場に上場する際、2007年以降は域外の企業にも国際財務報告基準（または同等の財務報告基準）に従うことが義務づけられることから生じる、各国企業の対応費用増加をはじめとする問題。 2009年問題 ヨーロッパで国際会計基準の導入に準じた連結財務諸表の開示が義務付けられたことにより日本もこれに基準を変更しなければならない問題。 日本、アメリカ、ヨーロッパにおいて排気ガス規制が強化される問題。 2010年問題 世界の製薬業界において、年間売り上げ1000億円クラスの医薬品が2010年前後に一斉に特許切れを迎える。「2010年問題」を参照。 米国の政府標準暗号の移行問題、IPv4のアドレス空間割り当てが2010年頃に枯渇すると日本で2008年時点に予想された問題、日本のブロードバンド行政上の問題など。「IPアドレス枯渇問題」を参照。 2014年問題 2002年頃以降、Windows XP SP2の登場までに発売された、XPプリインストールのパソコンの一部がVista以降のアップデート要件を満たさないため、同XP SP2のサポートサイクル終了に伴い大量に廃棄等が発生する事に対する問題。「Microsoft Windows XP#概要」を参照。 造船業において2014年頃に受注した船の数がゼロに近づくと懸念される問題。「2014年問題 (造船)」を参照。 1953年問題 - 1953年に公開された映画の著作権の期限が曖昧になった問題。なお実際に問題となる年は著作権法改正がされた2004年以降で、1953年とは、その時に問題の対象となる作品が作られた年になる。解釈を巡る争いから提訴に至り、2003年をもって著作権が消滅したことが判決で確定した。 2003年問題 2003年頃から2007年頃にかけてバブル期に計画された大型プロジェクトが竣工を迎え、東京都心に大規模オフィスビルが大量供給されることにより空室率が上昇すると予想された。 2007年問題 団塊の世代の大量退職に伴う労働力不足などの問題。実際には、定年の延長など雇用形態が変わる・あるいは景気回復で新卒採用者数増加など雇用者数が増加するなど、あまり問題にならなかった。「2007年問題」を参照。 2007年に日本の人口が増加から減少に転じるという問題。予測では2007年であったが、実際は2005年から減少している。 大学全入時代が到来する問題。2007年頃の予想が実際には遅れて2009年問題となっている。「大学全入時代」を参照。 2008年問題 - 1998年に大量に発行された10年国債の償還期限が到来する問題。しかし、事前に対策をとっていたため、2008年に償還が集中する問題は起きなかった。 2009年問題 前述の大学全入時代が到来する問題。「大学全入時代」を参照。 製造業において、派遣労働者が3年の雇用期間に達し、企業が正規採用を迫られた問題。「2009年問題」を参照。 2011年問題 テレビ放送が地上デジタル放送に完全移行し、アナログ放送が停波することに伴う問題。「2011年問題 (日本のテレビジョン放送)」を参照。 大阪で百貨店の新設・増床が出揃い、供給過剰が懸念された問題。「大阪2011年問題」を参照 2012年問題 エレベーターの保守部品供給の停止が相次ぎ設備更改を迫られるとされた問題。 ダイバーシティ東京、渋谷ヒカリエ、東京スカイツリータウンなど都心の大型開発ラッシュにより、ビルの供給過剰が懸念された問題。 2014年問題 - 北陸新幹線が金沢まで延伸開業されることに伴う、上越新幹線の沿線地域の観光・経済への影響。「2014年問題 (新幹線)」を参照。 2015年問題 - マイナンバー制度導入などIT開発案件が増加する一方で、ブラック企業の蔓延やデジタル土方、安易な解雇など劣悪な労働環境や背景にある業界体質の問題からIT業界離れが進行しておりIT技術者が不足するとされた問題。 2016年問題 - 劇場・コンサート会場が建て替え・改修が集中することにより、劇場・コンサート会場の数が足りなくなるとされた問題。 2018年問題 - 日本の18歳人口が2018年ごろから減り始め、2015年現在で定員割れが全体の4割にのぼる多数の私立大学が閉校等の激変期を迎えるとされた問題。 2019年問題 住宅用太陽光発電の固定価格買い取り制度が10年間の期間経過により終了する住宅が増加するとされた問題。 2019年展示場問題。東京ビッグサイトなどの大型展示場が2020年東京オリンピック開催のための準備作業の始まる2019年夏からパラリンピックが閉幕する2020年9月までの期間、他の催しに使用できないため、東京モーターショー、東京おもちゃショー、コミックマーケット等のイベントに影響が出るとされた問題。実際は東京オリンピック・パラリンピックが1年延期となったため、2021年9月まで続いた。 2022年問題 - 1992年以降、3大都市圏の都市部の「生産緑地」に指定されていた農地が、農家の高齢化・後継者不足により同指定を解除され、宅地として不動産市場に大量に供給されることで、地価の下落が懸念された問題。「生産緑地地区#2022年問題」を参照。 2023年問題 - 10月1日導入予定のインボイス制度により、小規模個人事業主が、企業からの取引停止、事務作業・税務判断・書類保存などといった煩雑な事務負担の増加や消費税負担の増加による収入減といったことで廃業の続出が懸念されている問題に加え、同制度に基づく「適格請求書発行事業者」に登録すると、国税庁のサイトに氏名などの非公表の個人情報が公開されることによるプライバシー上の問題。 2024年問題 同年1月予定のNTT（東日本・西日本）のISDNサービス提供終了によって、レガシーEDIシステムの更新を迫られる問題。後述のDX2025年問題と併せて主張されることも多い。 同年4月施行の働き方改革に伴い、トラック残業が制限されることにより、荷物の配達が遅れる問題「物流危機」。 2025年問題 団塊の世代がこの年までに全て後期高齢者（75歳以上）に達することにより、介護・医療費といった社会保障費の急増が懸念されている問題。 経済産業省「デジタルトランスフォーメーションに向けた研究会」が2018年に取りまとめた「DX推進システムガイドライン」において、DXの遅延が同年以降、年当たり最大12兆円の経済損失をもたらすとする試算。 2030年問題 少子高齢化、超高齢化社会がさらに進み、国内人口の3人に1人が65歳以上になると想定され、また、高齢者が増える一方、少子化による生産年齢人口の減少により発生する諸問題。 10億トン近い輸送力不足で、3割以上の荷物がトラックで運べなくなる試算。 2045年問題 - コンピュータ、遺伝学、ナノテクノロジー、ロボット工学、人工知能 (AI) などの技術が収穫加速の法則のように加速度的に発展していることからレイ・カーツワイルが予測している、2045年頃に技術的特異点（シンギュラリティ）に達するとされる問題。 旧暦2033年問題 - 日本のいわゆる旧暦（天保暦）の閏月を決定するルールの不整合により旧暦2033年（2033年〜2034年）の間の暦が決定できない、というもの。