「西暦２０００年問題」とは、コンピュータの年の扱いが西暦の下２桁表記で ある為に、西暦１９００年代と２０００年代間の日付に関する各種処理が誤動作する 事に端を発し、それが原因で企業の情報処理や設備・インフラ等に影響し、企業活動や 生活が脅かされる恐れがあると言うものです。 この問題は特に数年前になって大きく騒がれており、各社対策活動を行っている 今日このごろです。 問題の詳細解説や、対策の進め方については、私が説明するよりＹ２Ｋ関連リンクの サイトに掲載されている物をご覧いただいたほうが良いとして、私の持つ情報， 装置等の問題について下記に説明します。 なお、「西暦２０００年問題」の事を「Ｙ２Ｋ」と表現する事も多いようです。 これは、「年」すなわち「Ｙｅａｒ」の頭文字の「Ｙ」、そして 「２０００年」の「２０００」を「２キロ」と略して合わせたもので、 「Ｙｅａｒ ２ ｋｉｌｏ」を縮めて「Ｙ２Ｋ」と表現するものです。 （最後「Ｋ」ですが、補助単位の「キロ」（キログラムのキロと同じ）である事 から小文字の「ｋ」を使用するのが適当かも知れません。） 「西暦２０００年問題」はコンピュータの処理の問題だけにとどまらず、企業活動や 生活にも影響を及ぼすおそれがある事から、「コンピュータの西暦２０００年問題」という 狭義な定義を避け、「西暦２０００年問題」と広く表現するのが最近の傾向です。 また、１９００年代と２０００年代を区別できないという問題だけではなく 日付・カレンダー処理に関連する不具合及びその不具合に関連して発生するトラブルを 総称して「２０００年問題」と称する事もあります。 （当然ながら、実際の機器の対策に当たる場合は、問題が起きそうな日・・・ 危険日・・・を特定して対策を行う必要があります。） ２０００年問題のやっかいな所は、問題が同時多発的に発生する可能性がある事と、 その影響がどこまで波及するかがわかりにくい事です。 したがってコンピュータ等の装置そのもの対策だけでなく、ライフライン等への 影響に対する事前準備（危機管理策の検討，必要と思われる物の準備，心がけ）を 行っておく事が大切です。
年号の２桁表記はコンピュータ上で扱うデータベース等でソフトウエアの 内部処理やデータ保存の形式として一般的に使用されていますし、また コンピュータ自身が持っている時計（ＲＴＣ・・・リアルタイムクロック， いわゆるカレンダーチップ）自体が扱える年号も、西暦２桁である事が多く、 不具合の発生が多数予想されています。 この項では各社の情報を基に、発生し得る問題についてまとめてみました。 （この項ではコンピュータそのものにまつわる問題とし、それに起因して 発生する企業活動や生活への支障・影響については後述します。） 発生する問題には、西暦の下２桁だけ扱っていた事により発生する 不具合の他にも、年の入力範囲による制限や、表示，閏年，曜日計算のバグに より発生する不具合、特殊な処理を行うキーワードとして「特殊日」を設定 した事による不具合が潜んでいるようなので、「２０００年」問題に限らず カレンダーや年の処理にまつわる問題にも触れました。
２−１−１．日付のソート，比較による不具合 ・日付順にソート処理を行うと、１９００年代と２０００年代の関係が 逆転してしまう。 ・データの保存等の処理時、１９００年代のデータがあると２０００年代の データが上書き保存できない。（新しいデータに更新できない） ・日付の比較が正しく出来ない（例えば１９９９年３月２１日から、 ２０００年３月２０日までのデータを抽出する処理が出来なかったり、 ２０００年代のデータが出力されない等の不具合が発生） ２−１−２．日付の計算処理の不具合 ・１９００年代と２０００年代にまたがった期間の計算処理に誤りが 発生する。（年齢，期間の計算等） 例１） 正）２００３年−１９９８年＝５年 誤）３年−９８年＝−９５年（更に符号が抜け落ちると ９５年になる。） 例２） １９９９年１２月３１日２３時５０分から２０分後に、イベントを 開始（終了）したい場合、ソフト間の年の桁の扱いに相違があると、 ２０００年１月３１日０時１０分 ≠ ０年１月３１日０時１０分 となり、イベント開始（終了）のタイミング検出が出来なくなる。 ・西暦年から和暦を算出する際、００−８８＝平成８８年 等のような 誤りが発生する。
・１９９９年から２０００年にカウントアップできず、１９００年と して処理した場合や、閏年判断ルーチンの考慮不足の為に２０００年を 閏年と判断できない場合、曜日や年間の日数が実際と異なる場合が 生じたり機器間で差があると動作異常を起こす可能性があります。 閏年の条件は、下記のように言われています。 ・４で割り切れる西暦年は閏年 ・但し１００で割り切れる年は平年であるが、４００で割り切れる年は 閏年。 このうち、最後の「４００で割り切れる年は閏年」という処理が 考慮されていないと、本当は西暦２０００年は閏年なのにもかわらず、 平年として処理されてしまう事になります。 閏年の検出ロジックの不具合により、発生する不具合の例を示します。 ・１年の日数が実際と異なってしまう事により１２月３１日に事故が 発生した。（私の勤務先ではありませんが、そういう事例が過去に あったとの事。） ・曜日の算出が狂ってしまい、曜日による制御が正しく出来なくなる。
・ＲＴＣの値が”００”に戻る事により、ＲＴＣとＯ／Ｓ等の ソフトウエアをとりもつインターフェースソフトや、Ｏ／Ｓ， アプリケーションソフトが「ＲＴＣの値が異常である」と判断し、 システムが起動しない、エラーが発生 といった不具合が起こる。 ・２０００年代の日付が「入力範囲外」となり設定が出来ない。 ・１９００年代と２０００年代を明確にした入力が出来ない。 年の入力桁が２桁である場合に、２０００年代の入力のつもりが、 １９００年代の入力になってしまい、正しい処理が出来なくなる。 （１９００年代に入力した２０００年代の予約が正しくなされない等。） ex)"00"年と入力すると、1900年として処理される。 ・内部で扱える日付データ領域のオーバーフローにより、 データに異常が生じたり、エラーが発生し、それ以降の処理が 継続できなくなる。 （ＵＮＩＸ系の２０３８年問題や、ＧＰＳのカウンタの桁あふれ 問題等） ・ソフトウエアに「９９年９月９日」等といった特殊日を設けて あり、その日付になると、特殊な処理が行われたり誤動作を 引き起こす。 ・ＲＴＣやデータの年の桁が下２桁である為に、Ｏ／Ｓやアプリケーション側で 下２桁の値から上位２桁を生成するロジックを使用している場合、その基準年の 設けかたがアプリケーションによって異なってしまうと１９００年代と ２０００年代を取り違えてしまう。 （例：MS-DOSでは80以上が1900年代,79以下が2000年代として 扱われる。） ・２０００年代になった時、２０００年代の表示が正しくできない。 （上位桁が文字化けしたり、１００年になったりする。） ・とある海外メーカーのＲＴＣでテストモード（ＬＳＩの出荷検査用に用いる 動作試験モード）からみの不具合が報告されている。 これは年の桁が「９９年」の時にテストモードとする設計がなされていた事に 起因するようである。 国産のＲＴＣの場合、テストモード専用のレジスタにデータを書き込む事で テストモードに入るようになっているようなので、おそらく大丈夫か？ ・祝日法改正に伴う、祝日・休日の判定ミス 祝日法の改正により、祝日が新設されたり、従来と異なった日に移動する 休日（移動休日）がある。 休日・祝日の「テーブル」の設定にミスがあると、平日と休日の判定に ミスが生じ、不具合を引き起こす事になります。 ・機種による、カレンダー関係の制約 機種によっては、２０００年以降に制約の生ずる機種がある。 ex)hp9000/300コントローラのRTCの最大値は2000年2月29日であり、3月に なると1900年3月1日に戻る。(hp BASICのみの制約なのかどうかは未確認。） ・年末等「締め日」「開始日」関係の処理 「締め日」や「開始日」等、特定日に行われる処理に不具合があるケース。 通常の日には陰に隠れていた問題が、「締め日」や「開始日」になって 初めて不具合が表面化する。
２−４−１．「暦」自体の表現方法 「暦」自体の表現方法が複数あり、表現方法に関係する不具合や、表現方法の変換処理に より問題が生じ、不具合の発生日や不具合内容にも差が生ずる。 ・「グレゴリオ暦」，「ユリウス暦」 ・西暦，和暦 ・コンピュータ内の「時計」の内部表現 年・月・日・時・分・秒をそれぞれの桁を持って処理するもの。 特定日を"０"として、そこからの通算で表現（秒であったり日であったり）するもの。 ・処理の段階で上記の「暦」や「時計」の形式を別形式に変換 ユリウス暦 対 グレゴリオ暦の変換 西暦 対 和暦の変換 年〜秒表現 対 通算日（通算秒）表現間の変換 ・内部処理系と表示系の「暦」や表現方法の差異から、表面（表示）からは予想出来ない 日に不具合が発生するケースがありうる。
・ハード的なＲＴＣとバックアップ付メモリに日付データを分けて 処理する構造（ＲＴＣが月の桁までで、年の桁はバックアップ付 メモリに保存し、ソフトウエアでカウント）の場合、年の桁が 自動的にカウントされないものや、システムの電源のＯＮ／ ＯＦＦ状態によって、正しく繰り上がりしたりしなかったりする。 ・閏日の処理に関し、ハード的なＲＴＣが機能を持たず、ソフト側で 補正するロジックとなっている場合、システムの電源のＯＮ／ ＯＦＦ状態によって正しく補正処理される場合と処理されない場合が ある。また閏日の次の日に正しく移行しない。 ・隠れたＲＴＣ（ヒドゥンＲＴＣ）が存在し、ＲＴＣが何時を示して いるのか外部から判別できず、上記のような不具合が発生する日が 特定出来ない。 （デバッガを接続しないとＲＴＣの設定が出来ないケース） ・邦暦処理系の昭和１００年問題 「平成」に移行する際に、内部処理は「昭和」のままで表示のみ 「平成」年とし、また年の桁数が２桁のままにしてしまった場合、 昭和１００年に相当する平成37年以降の処理に不具合が発生する。 ・Ｙ１０Ｋ問題 ８０００年後に西暦１万年を迎える時の事です。 ４桁でも間に合わなくなりますが・・・ ・夏時間に関係する時間処理 従来のソフトには「夏時間」が考慮されないのが普通であった為、 もし夏時間が導入された場合は、夏時間に移行または冬時間に移行する （した）際に処理に矛盾や不具合を生ずる可能性が高い。 ・日付を扱う「桁数」に関わる不具合。 ２０００年問題として特に言われてるのが「年の桁が２桁固定」という ケースであったが、実際には月・日を含めたデータの桁数を考慮する必要 がある。（特に内部処理やデータ保存時のデータ桁数。）
我々の身の回りには多数の電子機器が存在し、ＣＰＵ等といった 「マイクロチップ」が内蔵されている物が少なくありません。 機器に内蔵されたチップの事を「組み込みチップ」ともいわれて いますが、それにまつわる西暦２０００年問題について考えてみました。 （一部の文献では「埋め込みチップ」と表現されている物がありますが、 英文のenbeddedを直訳した言葉で、国内では正しい表現とは思えません。）
・時間の概念を持った機器で、「リアルタイムクロック」をハード ウエアもしくはソフトウエアで構成し、年の桁まで処理に含み、その 「リアルタイムクロック」を元に時間に関する処理を行う機器が 基本的には「引っかかってくる」ことでしょう。 （実際には経過時間しか必要としないのに、「リアルタイムクロック」 の時間データから経過時間を作成するという構造の機器であれば モロに影響を受ける事になりそうですが。） ・リアルタイムクロックは持たないが、外部より日付に関するデータを 与えられ、その日付に関する何らかの処理を行う機器。
時間の概念を持った機器の実例を示します。実際にはこれ以外にもあると 思いますし、ここに例示した機器であっても対策済の物や無関係の 物があると思います。３−２−１．家電品
家電品のような民生機器の場合、搭載するチップのメモリの容量制限などの理由から、 年どころか、日の桁だって持たない機器が多いと思われ、年の桁まで持った機器は 限られると思われます。 （ＲＴＣ機能をソフトウエアで作成するとしても、日・月・年の桁の計数処理に必要な プログラムメモリが多く必要になります。特に以前のワッチップマイコンの場合は 元々メモリ容量が少なかった・・・数キロバイトとか・・・だったので結構痛い。） ただし、ハード的なＲＴＣ＋インターフェースソフトの構成にしろ、ソフト的なＲＴＣに しろ、内部的に年の桁まで持っているソフトウエアを、設計時にいろいろな機器で使いまわして いる可能性は否定できないので、特定メーカーの特定時期の特定製品群に限ってトラブルが 発生する というパターンはあり得ます。 ・ＶＴＲの録画予約機能（越年時の録画予約が正しく行われない等。録画予約のみでなく、 閏年の関係で曜日表示機能への影響のある場合も考えられる。またＧコード関係での 不具合が一部で報告されている。） ・ビデオカムの日付表示・記録機能（曜日表示がズレる。閏日が正しく表示されない等。） ・電子レンジや洗濯機のタイマ（せいぜい分オーダーまでの時間しか 必要としない為、２０００年問題はちょっと考えにくいが・・・） ・暖房，冷房，給湯機器，炊飯器等のタイマ （用途的に、年の桁まで処理に入っているとは考えにくいが・・・）３−２−２．機械制御，工場プラント用機器
・シーケンサ等の制御機器 ・ワンボードマイコン ・その他コンピュータ内蔵の制御機器 （いずれもリアルタイムクロック機能を持たない物も多いハズ。 また年の桁まで持っていても、表示のみで、本来の機能には 全く影響しないというケースも有ります。） ・タイマ等の時間を管理する機器 ・時間（日付）に関する計算を行う機器。 実際には、これらの機器がどんな機器の何処にどのように 使用されているかが解っていない為に混乱しているものでしょう。
組み込みチップの２０００年問題を考えるにあたり、チップ（ボード） 上において、どのように「時計」（リアルタイムクロック＝ＲＴＣ）が 作り込まれているのか、実現方法の一例を説明します。 チップ（ボード）での「時計」機能の実現方法には「ハード的なＲＴＣ チップを使用」する場合と、「ソフトウエアによりＲＴＣ機能を構成」する という２種類が考えられます。 前者は、マイクロプロセッサの他に、専用のＲＴＣチップを外付けして 使用するケースです。パソコンのほとんどはこの手法が取られます。 （ＲＴＣをハードで積んでいるマイクロコントローラチップはそれほど 多くはありませんが、ＡＳＩＣのマクロとしてチップに内蔵される 場合はあるようです。） 後者は、マイクロプロセッサのソフトウエアとしてＲＴＣ機能を構成 する方法で、民生機器のように価格を低減の要求がきびしい場合によく 使用されます。 それぞれについて内部の構造を例示します。３−３−１．専用のＲＴＣチップの構造例
ＲＴＣの内部構成について説明します。 （数字は物によって異なると思いますが一例です。） 約３０キロヘルツ（正確には３２７６８ヘルツ＝２の１５乗ヘルツ）の 発振器の信号を２の１５乗分の一で割って１ヘルツ＝１秒の信号を作って ６０進（秒の桁）−６０進（分の桁）−２４進（時の桁）−２８〜３１進（日の桁）− １２進（月の桁）−１００進（年の桁）と接続されたカウンタ群で順次計数して いきます。（年の桁の上に西暦の上位桁を表す桁を持ったものもあります。） 日の桁が２８〜３１進になっているのは大の月，小の月，２月（閏日の有無）で変わるからで 月の桁及び年の桁の値で変わるわけです。 各カウンタにはＣＰＵとのインターフェースが付いていて、カウンタの値をセットしたり、 値を出力したり出来ます。 ＲＴＣと閏年の関係についてですが、ＲＴＣの年のカウンタに百の桁がないものの場合、 ４年毎に閏年とする機能しか持たないようです。 ・・・(1999年10月29日以下補足)・・・ 「百の位がないのですから、１００年毎に平年にする為のロジックを組みようがないの です。」と一時書いてました。が、後で気が付いたのですが年の桁が「００」の時に平年と する事が出来る事に気が付きました。幸い、そういった構造のチップは私の知る範囲では 見受けられないようですが。 ・・・(補足終了)・・・ ＲＴＣチップそのものを製造しているメーカーとしては私が知っている 国内メーカーでは沖電気，ＮＥＣ，リコー，セイコーエプソン等があります。 また（ハード的な）ＲＴＣ機能の内蔵されているマイクロプロセッサを製造している メーカーには東芝があったと思います。 実際には先にも触れましたがＲＴＣのマクロを組んだＡＳＩＣが存在すると思いますが これらは機器メーカーからの要求で設計されたチップ（しかも外部には直接販売されない）で ある為に、外部の者からはその仕様すらわからないのが実態です。３−３−２．ソフトウエアによりＲＴＣ機能の実現例
組み込み用ＣＰＵの場合、「時を刻む」動作をソフトウエアで実現している場合が あります。 時計を構成する為に何桁かのメモリを準備します。 「システムクロック」等のＣＰＵのクロック信号等を整数分の１して１秒の信号を 作り、１秒信号でＣＰＵに対して割り込みをかけます。 （説明を簡単にする為、ここでは１秒信号による割り込みとしましたが、実際には もっと早い周期の信号で割り込みをかけるのが一般的です。） 割り込みルーチンでは秒の桁のメモリをカウントします。 カウントした結果、６０になったたら秒の桁を０にし、分の桁をカウントします。 同様に時の桁(０〜２３），日の桁(１〜２８，２９，３０，３１)，月の桁(１〜１２)， 年の桁を処理します。 計時に対する考え方はハードで構成した場合と変わりませんが、カウントする きっかけを割り込みにより得ている事や、処理がソフトウエアにより行われる事が 異なります。 また上記方法の他に、単純な２進カウンタを何桁か用意し、その値を ソフトウエアにより年・月・日・時・分・秒に変換する構造もあるでしょう。 （閏年等の処理を考えると、結構面倒そうですが。）
３−２項で例示した機器全てに問題が発生するかといったら、 そうではありません。 基本的には機器に「リアルタイムクロック」機能が内蔵されているのか と、どのような使われかたをしているか で影響度が違ってきます。 機器によって、下記の４種類のパターンに分けられると思います。 （１）「リアルタイムクロック」自体を持たない機器 マイクロプロセッサ自身にはハード的なリアルタイムクロック は持たないのが普通ですが、最近見られる周辺チップを取り込んだ アーキテクチャを持ったチップの中には、ハード的なリアルタイム クロックを持つものが一部存在するようです。 ＣＰＵを搭載したボードまたは、システムまで拡大して考えると 積んでいる物、積んでいない物の両方あるでしょう。 また、ワンチップマイコンのように用途によっては後述する手法に よりソフトウエアで実現されている物はあると思います。 いずれにしても「リアルタイムクロック」が無ければ２０００年 問題が起こりようがありません。 （２）「リアルタイムクロック」を持っていても使用していない機器 ハード的にぶら下がっていても、ソフト的には全くアクセスして いない場合や、ソフト的に「リアルタイムクロック」を構成していても、 そのデータを一切使用していない機器。 ちなみに世の中には年の桁を持たない「リアルタイムクロック」や 日付の概念のないリアルタイムクロックさえあります。 いずれにしても「リアルタイムクロック」が有っても使用していない のですから、「リアルタイムクロック」自身にＣＰＵの動作にまで 波及すりようなバグでもあれば別ですが、まず影響ないでしょう。 （３）人間が見るだけのデータ（表示のみ とか）にしか「リアルタイム クロック」のデータを使用しない機器。 表示のみの問題ですから、表示ルーチンや、「リアルタイムクロック」 とのデータの受け渡しに失敗がなければ、本来の制御には全く影響しない はず。（もちろん、リアルタイムクロックとのインターフェースを行う ハード及びソフトが、”００年”時不具合が発生する構造に なっていたらマズいですが・・・ 旧ＰＣ互換機のような・・・） （４）リアルタイムクロックを持ち、その機能を制御に使用している物。 影響がある可能性大です。ただし、実際には年・月等の桁を「無視」 して使用している場合もあるでしょうから、リアルタイムクロックを 使用している機器全てに影響が出るかというと、そうではないと思います。 （５）リアルタイムクロックの有無とは別に、日付に関係する情報を扱う物。 カレンダーとは別の意味での問題が発生するケースが考えられますので 注意が必要です。
２０００年問題関係で、良く聞かれるのが「年月日情報を制御機能に 利用していないから大丈夫」。 その言葉の陰にはいくつかの意味が含まれていると思います。 （当事者でありませんので、あくまでも推定ですが・・・） 実際に「リアルタイムクロック」を持ち、絶対時間から相対時間を 求める構造でシステムが作れますので、そういった構造の機器では ２０００年問題が起こる可能性があります。 もしこのような構成で、しかも「リアルタイムクロック」の設定が 出来ないような機器の場合は、現在の「リアルタイムクロック」の 値がどうなっているのかわからないので、いつ不具合が発生するかの 予測も出来ないわけですし、たとえ不具合が発生したとしても、 見かけは「故障」程度にしか見えないでしょう。 しかし、非常に短い時間（１秒以下）の相対時間を得ようとすると、 リアルタイムクロックからでは通常１秒以下の桁が出力されないので、 システムクロック（水晶発振器からの信号）を整数比で割った信号を、 ２進カウンタに入力して計数しその値から相対時間を生成するとか、 割り込み機能を使用してソフト的に計数しその値から相対時間を 生成するのが「普通」であり、この場合「リアルタイムクロック」 という概念が無い為に２０００年問題とは「無関係」という事 になります。 ただし、「無関係」といってもあくまでも短時間の「相対時間」を 求める場合であって、この手法を元にリアルタイムクロックを 構成する事が出来る（家庭用ビデオ等のように特に価格低減要求の高い 民生用機器に組み込んであるチップの場合、コストダウンの為に 専用のリアルタイムクロックチップを持たずに、ソフト的に処理する 場合が多い）ので、この場合はソフトウエアの計時処理が 正しい記述になっていなれれば、問題が生ずる事になります。 実際には、求めたい「相対時間」がどの位の時間のオーダー （マイクロ秒〜数１０秒程度なのか、数秒から日，月，年の オーダーなのか）によって作成方法が使い分けられているかも 知れません。 とはいえ周辺機器までワンチップ化されたマイクロコントローラ には、システムクロックにより動作するカウンタ機能が 標準的についている位ですから、「絶対時刻」を要求する機器・・・ 昼・夜を判別するタイマとか・・・でもない限り、わざわざ 外付けでリアルタイムクロックをつけて相対時間をリアルタイム クロックのデータから生成するような愚かな設計を行う事は 考えにくいです。（一部には存在するとは思いますが・・・） 組み込み機器に対して（日本国内で）楽観的に見る傾向が 強いのはこの辺の事情からではないでしょうか？
「組み込みチップ」関係の問題ですが、全てとはいいませんが、 用語が混同されたり、間違った知識をベースとした「説」に振り 回されているケースが一部にありますので、注意が必要です。 例えば・・・ （１）「クロック」 ・「リアルタイムクロック」 （実時間を計時するチップまたはソフトウエア） ・「システムクロック」 （プロセッサ及び周辺回路を動作させる同期信号） と、全く性質の異なった２種類の用語があります。 システムクロックはＣＰＵや周辺機器の動作を進めるもので、 ＲＴＣとは直接関係ありません。 （２）「ＣＰＵ」 ・ｍｉｃｒｏ ｐｒｏｓｅｓｓｏｒチップその物を示す場合 ・personal computer等の本体を示す場合（特に大型機やシーケンサ等） といった様に、少なくても２種類の呼び方がなされているかと思います。 「正確な知識」を持って「正しい対応」を行う事が重要ですので、 論理的におかしいデマ情報には、「起こり得ない」という事を反論（立証） する事も必要なようです。
マイクロチップ自体のハードウエア（アーキテクチャ）は半導体メーカーが 把握し、またボードのアーキテクチャはボードメーカーが把握していても、 内部で動作しているプログラムは、半導体チップやボードをシステムに 組み込むシステムメーカー側で作成する事が大半でしょう。 （量産機器を製造する場合は、ボードの設計とプログラム作成は同一メーカー で行っているかと思いますが、制御機器等の場合は上記のような分担に なるケースが多いかと思います。） 半導体を作るメーカーやボードメーカー側では問題を把握できないし、 保証し切れない事になりますので、そうなるとシステムメーカー（我々から見る メーカーになります。）が製品に対する保証をしてくれないといけない事に なります。 ただ、製品を開発した時の資料がきちんと残っていればいいのですが・・・ 開発時下請け任せでプログラムを作成しその資料が残っていない場合や、 プログラマが部門を異動したり退社した際に資料が行方不明になる事が往々にして 有る事が心配です。
実際の機器のボード上を見てＲＴＣ機能を持ったチップの発見が可能で しょうか。 ハード的に専用のＲＴＣチップを外付けしてある場合は、大抵は型番等から判断 できると思います。 （コピー品を製造されないように、製品に組み込む際に、チップの型名を削り取ってから 実装するメーカーもあるので、必ずとは言えませんが。） しかし、ソフトウエアで時計機能を実現している装置の場合は、このチップは 搭載されませんから、外観からＲＴＣ機能の有無の判断は不可能です。 しかもソフトウエアはチップを製造したメーカーで作成したわけではなく、チップの 製造を半導体メーカーに発注したメーカーが作成しますので、チップの型番だけでは 判断がつかないのが普通でしょう。 ２０００年問題に関し何らかの問題（制約）のあるＲＴＣを使用していたとしても、 年の桁には関係のないアプリケーションであったり、ソフトウエアでうまくカバーする事も 可能なので、実際に問題が生ずるかどうかは別問題ですが・・・
電力，交通，電話，水道，下水，燃料，食料等といったライララインが ２０００年問題によりおびやかされる恐れがあると言われています。 企業活動はもとより、生活に対する不安もあります。 もちろん会社や関係機関が対策を進めていますので、大きなトラブルに 発展する事はないとは思うのですが、用心に超した事はないでしょう。 ただし、ライフラインの問題は２０００年問題だけではなく災害等でも 起こりうる事であるので、この機会に一考してみるのも良いでしょう。 なお最新情報は各企業のホームページを参照して下さい。
電力各社が調査・対策を進めているようですので、大きなトラブルは ないと思います。 ・「短期的な問題」の起こる可能性 基本的には夏場の日中の電力のピークにも対応するだけの電力供給 能力の”余力”があるはずですから、仮に一部の発電施設でトラブルが あったとしても全体の系統で電力供給の保証が出来るはずです。 ただ、Ｘデーが冬季の深夜という事で、停止している発電機器を 瞬時に「起こせる」かどうかという問題はあります。 しかし地震等の災害と違って、設備が物理的に壊れるわけでは ないので、長期に渡って復旧出来ないという事はないと思います。 なお、ちょっと気になっている点があります。 というのも最近スイッチング電源や、インバータ機器のような 「定電力負荷」が増加しているのです。 通常のものは電源電圧が低下すると流れる電流も減る特性がある （こういう負荷を「抵抗負荷」という）のですが、「定電力負荷」の 場合は、電源電圧が低下すると負荷電流が増える傾向があるのです。 つまり電力供給システムのダウンにより電力供給能力が低下し電圧が 低下してしまうと、負荷電流が増え、負荷電流が増える事により また電圧が下がる という悪循環を起こし、電力供給系全体をダウン させる恐れがある事です。 実際には、電力系統全体がダウンする事を防ぐ為の保護機構が あると思います。（その場合、一部地区での電力供給をストップする事に なるでしょうから、停電または瞬停するという事になるのかな？） またインバータ機器等も電圧が一定以上低下すると停止する構造に なっている物もあると思いますので、その場合はその機器自体が停止 するだけで、電源系への影響は防げるでしょう。 ・「長期的な問題」の起こる可能性 原油入手の関係で火力発電の燃料が不足する可能性が予想されています。 しかし実際には石油関係は国内消費量の約半年分に相当する「備蓄」がなされて いるようですから、例え問題が発生したとしても備蓄を使い切る前に対策を 行う事が可能ではないでしょうか。 （ただこの問題は、産油国側のいろいろな都合や各種紛争等で影響を受ける事 なので、２０００年問題に限らず、リスキーである事は間違いない話なのでは ありますが。）
鉄道には、車両や信号・ポイント等の保安機器，座席の予約システムや 乗車券類の販売機・自動改札等多数のコンピュータや組み込みチップが 使用されており、問題が発生する可能性があります。 国内の大手鉄道各社に関しては調査・対策を進めているようですし、 ポイント制御関係では「日付」に関する制御がなされていない事や フェイルセーフ機能で「絶対安全」の思想で設計なされているはずですので、 まずは大丈夫だと思います。 ただ、地方や海外の鉄道に関してはやや不安があります。 なおJR東日本では、1999年末から2000年にまたがって運行する列車に ついて、最寄り駅で臨時停車するようです。自社の設備に関しては確認を 行っているようですが、停電等の外的要因による混乱を最小に押さえる事が その最大の目的のようです。（コテンジェンシープランに基づくもの？）（２）船舶
船舶には船舶自体の制御や、ＧＰＳやレーダー等と行った機器に コンピュータや組み込みチップが使用されていると思われます。 国内の大手に籍を持つ船舶は対策なされる事でしょうが、 海外籍の船舶（特に東南アジア系）は不安があります。 タンカーや食料を積んだ輸送船に影響が出て止まるケースは、想定 しておく必要がありそうです。（でも、実際に影響が出れば乗組員だって 何らかの対処を行うはずですから、長期的な影響にはならず最小限で 収まるのではと思われます。・・・なにせ乗組員の方々は「船」に 命を預けているわけですし・・・） また、船舶はシステムとして独立している為に、外部要因の影響を 受け難いという考え方もあるようです。（３）航空機
飛行機にも多数のマイクロチップが使用されていますし、飛行管制する 機器にも多数のコンピュータが使用されていると思われます。 国内航空各社の情報によると、メーカー等による確認・対策が進められて いるようです。 ・・・(1999年10月29日以下補足)・・・ 一部の便で、「需要減」に伴う減便が決まったようですが・・・ ・・・(補足終了)・・・（４）自動車関係
・信号管制辺りは”官”が行っている事ですから・・・ちょっと心配です。 （警察のほうで、チェックを行っているようですが・・・） ・ＧＰＳの桁あふれ ＧＰＳの桁あふれは間違い無く起こり、チップ（ＲＯＭ）交換処置が行われている 製品もあるようなのですが・・・ カーナビやカーオーディオで問題が起こってもどうってことないという 見方もあるのですが、その一方運転中に頼りにしていたナビが突然壊れ、 よそ見をした等による事故の発生が起こらないとも限らないし、間違った 道路を表示した事により事故を誘発しないとも限らないので、一概に 「どうってことない」とも言い切れない面があります。 （日本国内ならまだしも、アメリカ辺りじゃＰＬ訴訟の対象になり兼ねない。） ・・・(1999年10月29日以下補足)・・・ Ｘデーが過ぎましたが、チップ交換がなされなかった物が一部残り、当然 ながら不具合が発生し、メーカーに苦情の電話が・・・というケースが起き ましたが、それが原因で大きな事故につながる事はなかったようです。 対策未了の機器が残ってしまった事に関して、メーカーの広報不足を 問題視する声もありますが、一番はユーザー側の認識不足だと思います。 （確かに、店頭での表示、ホームページでのＰＲ、雑誌・新聞等での広告等 だけでは情報が伝わらないケースは有り得ますのでメーカーとしては 気をつけないといけないようです。） また対策したはずの機器で不具合が発生したケースもあったわけですが、 ＧＰＳというシステムがアメリカ製だけに、機器を設計する側の「仕様の 読み違い」（勘違い？）がその原因という事になりそうです。 信号を作っている相手が、アメリカの軍用衛星という事だけあって、 機器側の試験も完全には出来なかったんでしょうねぇ。 ２０００年問題に関しても、そういうケースが起きなければいいのですが・・・ ・・・(補足終了)・・・ ・自動車本体 組み込みチップの問題で、自動車のエンジンが止まるとかいう「噂」を 耳にします。確かに最近の電子制御化が進んだ車を考えると、影響しそう ですが、実際には以下の理由で考えにくいと思います。 自動車内部で必要とされる時間は、ミリ秒，マイクロ秒単位がほとんど ですので、「リアルタイムクロック」をベースにしているとは思えません。 （マイクロ秒単位の短時間の制御まで要求されるエンジン等のコントロールに 「リアルタイムクロック」を「転用」するという使い方を考えるほうが 無理があります。） ですが、肝心の自動車メーカーがこの問題取り上げて「問題ない」 「問題あり」等と言った情報，「起こり得ない」等という反論等を、 ＷＷＷサイト等で広報している所がない事が心配です。 （もろろん、そんな問題が隠れていたらリコールものですが。） Ｔ社とＮ社のサイトちらっと見たのですが、関係する情報は 探せませんでした。(他社を含めもう少し良く探してみます。 でも、Ｔ社のサイトに検索機能があったので、"Ｙ２Ｋ"とか" ＡＤ２０００"とか"２０００年"とかで引っ掛けようとしたのですが、 相当するページには巡り合えませんでしたからねぇ。） 世間がこれだけの騒ぎになっているので、知らないハズは ないと思うのですが、それに対し何らかの意見表明がないと いうのは私は問題だと思います。 （根拠のない噂話を自ら晴らして欲しいですね。） 製品個々の機器の設計に関しては、設計者の力量や知識に 関わる部分が多く、問題がないとは限らない部分があるかも 知れませんので、業界団体の一般的な情報では納得できぬ話で あり、メーカー自らの「大丈夫である」という情報が大事かと 思います。 ・・・(1999年10月29日以下補足)・・・ 実は、本ページ公開直後、多くの自動車会社のページに２０００年 問題に関するページが開設されている事が判明しています。 ただ、メーカー自らの発表が大事であるという考えには変わりは ありません。 ・・・(補足終了)・・・
２０００年問題はバグや設計ミスとは言え、一種の時限爆弾のような 物ですが、コンピュータの「時限爆弾」と言えばコンピュータウイルス があります。 どうも、便乗したウイルスが現れそうで、気になるのですが・・・ ・・・(1999年10月29日以下補足)・・・ ページ開設時「この話題の根拠は何もありません。」と書いていたの ですが、残念な事にソフトメーカーの名をかたり「２０００年問題を チェックするソフト」だと言ってウイルスをメールの添付ファイルとして 送付する不届者があります。怪しいメールの添付ファイルは開かない事、 そして時々マシンをワクチンでチェックする事をお薦めします。 ・・・(補足終了)・・・
・問題のない製品であっても「２０００年問題に適合しない」と言って 新しい別の商品を押し付ける商売が横行しそう。 また不具合対策の為に法外な料金を請求する悪質企業がいる可能性も・・・ ・９月９日の時もそうでしたが、不安感により株価や相場等への影響が ありましたが、ある程度は止むを得ないんでしょうね。 ・便乗商法というにはふさわしくありませんが・・・ ２０００年問題の対応に当たる人の為に、年末年始のホテルの予約が いっぱいであったり、彼らをあてこんで弁当を販売する所もあるそうです。
Copyright (C) by Y.Wagatsuma
1999/08/12新規作成
1999/10/29更新