Locale: ja
2026年9月24日、日本の国税システムは大規模更改を実施した。その直後、税務署窓口では現金領収や納税証明書の交付などに「相当の時間」を要する状態が発生し、e-Tax周辺でも複数の不具合と緊急メンテナンスが続いた。巨大な統合システムが切替直後に不安定になること自体は、分散システムや業務自動化を触ったことがある人ほど理解しやすい。一方で、「壊れるのは分かる」と「壊れたときの逃げ道が十分だった」は別問題である。
ある手続きを急いでいた人が、窓口から「システム全体の調子が悪く、復旧時期はまだ分からない。急ぐなら来署すれば対応する」と案内されたとする。
普通なら「じゃあ行けばいいのか」と思う。
しかし少し考えると、嫌な未来が見える。
オンラインや通常処理で済まない人が窓口へ流れる。職員側はシステム不調で一件あたりの処理が遅くなる。来庁者は増えるのに処理能力は落ちる。
「来れば対応できます」は、「来れば秒速で終わります」と同義ではない。
結局、期限に余裕があるなら待つという判断もかなり合理的になる。
そして心の中ではこう叫びたくなる。
「もう紙で受け付けろ。マジで。」
ただし、紙は魔法のバックアップデータベースではない。
1. 2026年9月に何が起きたのか
国税庁は2026年9月24日に国税システムを更改した。次世代システムKSK2の開発コンセプトとして、国税庁は以前から次の三つを示していた。
- 書面中心からデータ中心の事務処理へ移る
- 税目別だったデータベースやアプリケーションを統合する
- 独自OSを使う大型コンピュータ中心の構成から、汎用OSを使うオープンシステムへ刷新する
つまり、単なる画面の模様替えではない。データの持ち方、アプリケーション境界、基盤そのものをまとめて変える大型更改である。
そして更改当日の9月24日、国税庁は「税務署窓口における各種手続の遅延」を公表した。現金領収や納税証明書交付などに相当の時間を要し、e-Taxで納税証明書を請求しても即座に交付できない状態だと説明している。更改自体は完了したものの、窓口業務に必要なシステムの稼働に問題が生じたという。
同じ切替週には、マイナポータル経由のログイン不具合、インターネットバンキング納付の完了表示不具合、e-Taxの一部機能停止、障害対応のための緊急メンテナンスも発生した。e-Taxの一部機能停止については9月27日までに解消が公表されている。
一方で、窓口遅延の告知は9月28日時点でも国税庁サイトの緊急情報として残っていた。詳細な根本原因は、この時点では公表されていない。
さらに重要なのは、予定メンテナンスと障害を混同しないことだ。今回の更改では、もともと9月19日0時から24日8時30分までの長時間停止と、9月26日の終日停止が予定されていた。そこへ切替後の不具合と緊急メンテナンスが重なった。
だから体感として「ずっと止まってない？」となるのは自然だが、その中には計画停止と障害停止の両方が混ざっている。
2. 「お金を扱うちゃんとしたシステム」でも壊れる。むしろ、だから止めることもある
「税金やお金を扱うシステムなら、もっと絶対に止まらないように作るんじゃないのか」
直感としてはその通りだ。
しかし重要システムには、可用性だけでなく整合性がある。
たとえば納付処理で一番怖いのは、画面が5分開かないことだけではない。
- 支払ったのに未納扱いになる
- 一度の処理が二重に登録される
- 古いデータを参照して証明書を発行する
- 片方のシステムだけ更新され、もう片方が取り残される
- 復旧後の再実行で同じ処理がもう一度走る
こうした状態で「とりあえず動かし続けました」は、停止より危険なことがある。
GoogleのSRE資料でも、大規模障害時には根本原因調査より先に被害拡大を止め、データ破損の可能性があるならシステムを凍結する方がよい場合があると説明されている。
金関係なのに止まるのではない。
金関係だから、正しい状態を保証できないまま走らせるより止める判断が必要になることがある。
「再起動してみました？」で全部直るなら、全国基幹システムの運用担当者はもっと早く帰宅できる。
3. 単体テストが全部通っても、統合すると普通に爆発する
統合システムの嫌なところは、それぞれの部品が正常でも全体では壊れることだ。
Aシステムは正常。
Bシステムも正常。
データベースも正常。
認証も正常。
それでも、AからBへ渡す形式が一文字違えば止まる。
旧システムから新システムへ移したデータに例外値があれば止まる。
再試行の途中で応答だけ失われれば、「処理されたのか、されていないのか」が分からなくなる。
古いキャッシュ、古い帳票、外部機関との接続、権限、時刻、バッチ処理、文字コード、旧字体、障害時の再送。境界が増えるほど、単体では見えなかった組み合わせが増える。
個人の小さな自動化ですら、古い状態、二重実行、取りこぼし、外部API差分、再試行の副作用で簡単に事故る。
それを全国の税務署、複数税目、収納、還付、証明、e-Tax、外部機関まで含む基幹システムでやる。
統合の大変さを知っている人ほど、「まあ切替直後は何か出るよな」とは思う。
ただし、それは免罪符ではない。
評価すべきなのは「障害が一件も出なかったか」だけではなく、「障害が出たときにどこまで安全に縮退できたか」である。
4. なぜ「復旧目処が立ちません」になるのか
利用者からすると最も困る言葉の一つがこれだ。
「復旧時期は未定です。」
しかし原因が分からない段階で、適当な時刻を約束する方が危険でもある。
重要システムの復旧では、単にサーバーを起動できれば終わりではない。
まず障害範囲を切り分ける。
次に、データが途中まで書かれていないか確認する。
再実行しても二重処理にならないか確認する。
外部連携先と状態が食い違っていないか確認する。
必要なら切戻しや代替経路を検討する。
復旧後には、停止中にたまった処理を順番に流し、結果を突合する。
特に「送信側では成功に見えたが、受信側では確定していない」のような状態が混ざると面倒だ。
Amazonが公開している分散システム設計でも、再試行を安全にするための冪等性、つまり同じ要求を再送しても副作用が重複しない設計が重要だと説明されている。
復旧時刻を出せないのは、単に担当者が何もしていない証拠ではない。
どこまで壊れたか、どこまで戻せるか、どこから再開すれば二重処理しないかが分からないと、正確な予測そのものが難しい。
5. 「急ぐなら窓口へ」は、待ち行列としてかなり怖い
ここで窓口が登場する。
システム障害中でも「来署すれば対応できます」と言われることはある。
これはありがたい逃げ道だ。
しかし待ち時間の観点では、かなり危険な条件が揃う。
通常時を単純化して考える。
窓口へ来る人の到着量をλ、職員が処理できる量をμとする。
障害が起きると二つのことが同時に起こりうる。
まず、通常ならオンラインや内部処理で済む人まで窓口へ来るため、λが増える。
次に、職員がシステムを使いにくくなり、一件あたりの確認や手入力が増えるため、μが下がる。
需要が増えて供給能力が下がる。
待ち行列にとって最悪の組み合わせである。
しかも税務署職員は障害発生と同時に自動増殖しない。
GoogleのSRE資料でも、システムは過負荷に近づくと単純に少し遅くなるだけではなく、待ち時間増加や連鎖障害によって非線形に悪化することがあるとされる。だから負荷制御や縮退応答が重要になる。
「窓口へ来れば対応可能」は、「窓口が空いている」という意味ではない。
期限に余裕があるなら、障害ピーク日に突撃せず復旧を待つのは、時間コストを考えれば十分合理的だ。
逆に法定期限や緊急性が絡む場合は、自己判断で放置せず、その時点の国税庁・税務署の公式案内で代替手段を確認する必要がある。
6. 「紙でやれ」は半分正しい。紙は受付の逃げ道にはなるが、バックアップDBではない
障害を見ていると、だんだんこう思えてくる。
「紙で受け付ければいいじゃん。」
この発想は完全に間違いではない。
NISTの情報システム継続計画ガイドでも、障害時の代替処理として、短期間なら手作業で業務プロセスの一部または全部を実施する方法が挙げられている。
つまり、手動処理はれっきとした継続策の一つだ。
ただし「紙に書けば全部終わる」とは限らない。
紙でできるのは、たとえば次のような部分だ。
- 申請や相談を受け付けた事実を残す
- 受付日時を確定する
- 必要書類を預かる
- 復旧後に処理するための順番を作る
- 問い合わせ番号や控えを渡す
一方、中央データの照合、納付状態の確認、過去記録の参照、証明書の正確な発行、外部機関との連携などは、基幹システムなしでは完結しない場合がある。
だから理想は「全部紙に戻す」ではない。
「基幹システムが死んでも受付まで死なない」である。
紙はバックアップデータベースではない。
でも、紙の受付票は非常口にはなれる。
7. 本当に欲しいのは「完全停止しない縮退運転」
障害時に強いシステムは、通常機能を100％維持するとは限らない。
むしろ、重要な機能だけ残して簡易モードへ落ちる。
Google SREはこれを段階的な機能低下、いわゆるgraceful degradationとして扱っている。NISTも代替設備、代替拠点、手動処理などを継続計画の選択肢として挙げる。
税務手続に当てはめるなら、理想像はこんな形になる。
- 受付を止めない。 オフラインまたは紙でも最低限の申請情報を受け取れる。
- 受付番号を発行する。 「受け取ったか分からない」をなくす。
- 後処理キューへ積む。 復旧後に順番に再処理できる。
- 二重処理を防ぐ。 同じ申請を再投入しても一回分として扱える識別子を持つ。
- 緊急度を分ける。 期限や生活への影響が大きい処理を優先する。
- 利用者へ状態を見せる。 何が止まり、何が使え、何が復旧したかを分けて公表する。
- 復旧後に突合する。 紙・オフライン受付と本番データを照らし合わせ、取りこぼしと二重処理を検出する。
重要なのは、「障害が起きても何も変わらず動く」という幻想ではない。
壊れ方を設計することだ。
8. では、e-Taxはどのくらいの頻度で不具合を出しているのか
2026年のe-Tax公式お知らせを見ると、1月の納付完了通知遅延、2月のマイナポータル連携不具合やログイン困難、3月のログイン困難、7月のマイナポータル経由の不具合、8月のダイレクト納付等の利用不能、9月の更改直後の複数不具合など、年間を通じて複数の障害告知が確認できる。
ただし、ここは雑に数えてはいけない。
これらは全部同じ障害ではない。
e-Tax本体の問題もあれば、マイナポータル連携、納付、表示、外部サービス側の問題もある。さらに計画メンテナンスは障害ではない。
したがって、公式一覧から言えるのは「部分的な不具合や周辺連携の障害は年に複数回公表されている」ということまでで、「国税システム全体がしょっちゅう全国停止している」とまでは言えない。
2026年9月の件が特に目立つのは、巨大更改の切替週に、長い計画停止と複数の切替後不具合が重なったからだ。
9. 統合の地獄を知ると、怒り方が少し変わる
自分で小さな自動化システムを作ったことがある人は、巨大システム障害を見る目が少し変わる。
以前なら、
「なんでこんなものが止まるんだ。」
で終わる。
一度でも複数サービスをつなぎ、キューを持ち、再試行を入れ、状態を保存し、外部APIと連携すると、
「うわ、統合切替か。これは地獄だな。」
という感想も混ざる。
単体では全部動くのに全体で壊れる。
直したら別の境界が壊れる。
古い状態が残る。
再試行したら二重になる。
ログを見ると昨日の情報だった。
その小型版を経験するだけでも、巨大基幹系の難しさは想像しやすくなる。
しかし理解と評価は別だ。
「難しいから仕方ない」で終了するのではなく、次を見る。
- 切替前にどこまで負荷試験・移行試験をしたか
- 障害時にどこまで縮退運転できたか
- 手動受付はどこまで機能したか
- 状態告知は利用者に十分だったか
- 復旧後に原因と再発防止を公開するか
- 次の切替で同じ種類の事故を潰せるか
複雑だから事故は起こりうる。
複雑だからこそ、事故後の設計と学習が重要になる。
10. 結論――「紙だけで全部やれ」ではなく、「紙でも入口は死なせるな」
税務署の基幹システムが止まると、利用者から見ればかなり理不尽に感じる。
お金と法的手続きを扱う場所なのに止まる。
復旧時刻も分からない。
窓口へ行けばできると言われても、どう考えても混みそう。
そこで「もう紙でやれ」と言いたくなる。
この感覚の中には、かなり重要な設計要求が入っている。
紙だけで税務システム全体を代替するのは現実的ではない。
しかし、システムが落ちた瞬間に受付、記録、優先順位付け、後処理キューまで一緒に死ぬ必要もない。
巨大システムに必要なのは、「絶対に壊れない」という神話ではない。
壊れても、最低限の仕事を残すこと。
二重処理せずに戻せること。
何が使えて何が使えないかを利用者へ伝えること。
そして復旧後に、止まっていた仕事を安全に回収することだ。
つまり最終的な要求はこれである。
「全部紙でやれ」ではない。
「せめて受付だけは紙でも起こせ。マジで。」
参考資料
- 国税庁「税務署窓口における各種手続の遅延について」2026-09-24
https://www.nta.go.jp/files/000041014.pdf - 国税庁「国税システムの更改について」
https://www.nta.go.jp/taxes/shiraberu/sodan/system.htm - 国税庁レポート2025「次世代システム（KSK2）」
https://www.nta.go.jp/about/introduction/torikumi/report/2025/03_5.htm - e-Tax「国税システムの更改に伴うメンテナンス時間について」
https://www.e-tax.nta.go.jp/topics/2026/topics_20260422.htm - e-Tax「お知らせ一覧」
https://www.e-tax.nta.go.jp/topics/ - e-Tax「【解消】e-Taxの利用ができない状況について」
https://www.e-tax.nta.go.jp/topics/2026/topics_20260925_mentenansu.htm - NIST SP 800-34 Rev.1, Contingency Planning Guide for Federal Information Systems
https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final - Google Site Reliability Engineering, Handling Overload / Effective Troubleshooting
https://sre.google/sre-book/handling-overload/
https://sre.google/sre-book/effective-troubleshooting/ - Amazon Builders’ Library, Making retries safe with idempotent APIs
https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/
