KSK2の初期トラブル、海外10事例、特許庁の失敗と再出発から考える刷新の条件
行政の巨大システムが止まると、その影響は画面の向こう側に広がります。税務署で証明書を受け取れない。給与が正しい金額で支払われない。給付金の返還を求められ、身に覚えのない債務の説明をしなければならなくなる。システムの不具合は、人々の生活や企業活動を直接揺さぶります。
2026年9月24日に更改された国税庁の国税システムでも、稼働後に窓口手続きの遅延やe-Taxの不具合が公表されました。次世代システム「KSK2」は、納税者の利便性向上と課税・徴収の効率化・高度化を支える基盤として整備されてきたものです。その刷新に伴う混乱は、大規模なシステム導入の難しさを改めて示しています。［1・2］
海外には、深刻な失敗の一方で、税務基盤を全面的に入れ替え、安定運用や行政サービスの改善につなげた例もあります。日本の特許庁も、一度は開発を中断しましたが、計画と体制を立て直し、主要システムを順次稼働させてきました。巨大な刷新の成否は、初回の結果だけでは捉えきれません。
成否を分けるのは何でしょうか。技術力、予算、経営層の関与、現場の理解、移行の進め方。どれも関係しますが、個別の項目を並べるだけでは実態をつかめません。重要なのは、それらがどのようにつながり、問題を発見し、被害を抑え、計画を修正できる仕組みになっているかです。
本稿では、KSK2について確認できる事実と原因に関する仮説を整理し、海外の失敗6事例と、成功・長期運用の成果が確認できる4事例を紹介します。続いて、特許庁の開発中断、契約の決着、その後の再企画・構築・稼働までをたどり、成否を分ける十の要素を考えます。各案件の比較は、公的な監査・年次報告などから得られる示唆を整理したものです。統計的に選んだ標本による因果分析ではなく、個々の教訓がそのままKSK2の原因を示すものでもありません。
1．KSK2をめぐり、公開情報から何が分かるのか
システムの更改と、業務の安定は別の出来事です
国税庁は、2026年9月24日に国税システムを更改したと公表しています。申告書・納付書等の様式、通知を特定する番号、電子交付の手続きなどにも変更がありました。国税庁レポートでは、KSK2を税務行政のデジタル化を支えるインフラとして位置付けています。［1・2］
更改後、e-Taxのお知らせには、ログイン、納付、手数料納付、ソフトの更新等に関する不具合と解消の案内が掲載されました。ここで留意したいのは、国税の基幹システム、e-Tax、外部の決済・認証サービスなどは、利用者からは一続きのサービスに見えても、技術的には複数の構成要素であることです。同時期の不具合を、すべて同じ内部原因によるものと断定することはできません。［3］
10月19日更新の国税庁の案内では、現金領収や納税証明書の交付など、税務署窓口の手続きに通常より時間がかかる場合があるとしています。e-Taxで請求した証明書についても時間を要し、電子交付を希望しても書面交付になる場合があるとの説明です。［4］
これは、更改作業を終えたことと、利用者が従来どおりに業務を完了できることの間に、隔たりが生じたことを示しています。
確認された影響と、その先にあるリスク
公開情報で確認できる主な事象を整理すると、次のようになります。
| 事象 | 確認できる影響・対応 | 公表上の状況 |
|---|---|---|
| 窓口手続きの遅延 | 現金領収、納税証明書の交付等に時間を要する場合がある | 10月19日更新の案内で改善への取組を継続 |
| 納税証明書の電子交付への影響 | e-Tax請求でも遅延や書面交付となる場合がある | 電話番号登録と税務署からの連絡を案内 |
| 手数料納付の不具合 | インターネットバンキングで手数料を納付できない事象 | 10月5日更新で解消を案内 |
| 振替納税結果の表示問題 | 結果表示を一時停止して改修 | 10月13日更新で正しい情報を表示していると案内 |
| 贈与税関係情報の機能提供見合わせ | 10月19日に情報反映予定だった追加機能を利用できない | 10月16日更新で当分の間の見合わせを案内 |
出典：国税庁・e-Taxの各案内。［4〜7］
また、10月2日の国税庁発表についての報道によると、9月24日から25日にかけ、79人分の贈与税申告書等が本人以外から閲覧できる状態となり、贈与者や税理士などを含む203人の個人情報が関係したとされています。これは処理の遅さとは性質が異なり、情報の機密性に関わる事象です。件数等は当該発表を伝えた報道に基づきます。［8］
一方、証明書の遅延によって融資が実行されなかった、入札に参加できなかった、という個別の損失事例や全国の被害総額まで、今回確認した資料から明らかになったわけではありません。
納税証明書は融資や入札などで求められることがあるため、交付の遅延が企業活動に波及する可能性はあります。しかし、「波及し得るリスク」と「実際に発生したと確認された損失」は区別する必要があります。振替結果の表示問題についても、誤表示をきっかけとする二重納付などは想定し得るリスクですが、今回の資料から発生件数や金額を確認したものではありません。
現時点で、原因をどこまで言えるのか
個々の不具合の告知から、問題が生じた機能はある程度分かります。しかし、KSK2全体の詳細な障害分析や、設計・テスト・移行判断に関する第三者検証まで確認できたわけではありません。
したがって、以下で挙げるデータ移行、連携、性能、業務体制などの問題は、巨大システムで考えられる仮説です。KSK2で実際に起きた原因や、特定の組織・事業者の責任を示すものではありません。
2．巨大システムでは、何が起こり得るのか
データは移せても、意味や処理状態が引き継がれていない
データ移行の確認というと、件数や金額の一致を想像しがちです。しかし、件数も合計額も一致しながら、業務上は誤っていることがあります。
例えば、正しい金額が別の納税者に紐付く。入金済みの金額は移ったものの、未納という状態が残る。申請書自体は存在するのに、誰が承認を待っているかが失われる。こうした問題は、単純な集計比較では見つけにくいものです。
特に難しいのは、移行時点で処理途中にある案件です。申請中、照会中、審査中、支払指示済み、入金確認待ちなど、業務には多くの途中段階があります。過去の履歴と現在の状態を、矛盾なく引き継ぐ必要があります。
一つ一つの機能は動いても、業務全体が完了しない
証明書の交付であれば、申請、本人確認、納付状況の確認、手数料、発行、受け渡しが連続します。どれか一つの連携に問題があるだけでも、利用者は目的を達成できません。
また、送信に成功した後で応答だけが途切れることもあります。このとき再実行してよいのか、同じ支払や申請を二重に作らないか。単にエラーを表示するだけでは業務を守れず、処理の成否を確認し、安全に再開する仕組みが必要です。
本番の組み合わせと量が、テストの前提を超える
新しいシステムでは、データの一元化によって参照先が増え、職員が一度に確認できる情報が広がることがあります。その結果、特定の検索、集計、帳票発行に負荷が集中する可能性があります。
一件ずつなら動く処理も、全国の窓口で同時に使われ、夜間処理や外部連携と重なれば、応答時間が悪化するかもしれません。性能はサーバーの台数だけでは決まらず、データへのアクセス方法、処理の順序、待ち合わせなどにも左右されます。
新しい操作と厳格なチェックが、現場の処理能力を下げる
新システムへの移行では、入力が以前より正確になる代わりに、不備があると次へ進めなくなる場合があります。制度上は正しいチェックでも、入力に必要な情報が現場にそろっていなければ、案件は止まります。
そこへ操作習熟の遅れ、問い合わせ、臨時対応が重なると、システムの処理性能が足りていても業務は滞留します。利用者から見える「遅い」という現象には、技術上の待ち時間と、人による確認の待ち時間が混在し得ます。
これらの仮説は、画面上の症状だけでは判別できません。原因を絞るには、処理段階ごとの時間、エラー、データの不整合、滞留量、現場の作業内容を合わせて調べる必要があります。
3．海外で起きた六つの失敗事例
カナダ・Phoenix：納期と予算を守る判断が、必要な機能と検証を削った
連邦政府の給与システムPhoenixは、2016年に導入されました。カナダ会計検査院の監査では、予算と日程に収めるために重要な給与機能を削減・延期し、テストや体制も縮小したことが指摘されています。
重大な不具合があり、試行導入を予定どおりに行えなくなった際には、本番稼働を延期せず、試行自体を取りやめました。稼働後には給与の誤りや未処理案件が拡大しました。［9］
この事例が示すのは、予算内に収めること自体が悪いという話ではありません。必要な機能や検証を減らしたなら、期待する業務効果と稼働判断も見直す必要があった、ということです。計画の外形を維持しながら、その計画が成立する前提が失われていました。
豪州・クイーンズランド州保健当局：複雑な給与制度と現場運用の不整合
2010年に稼働した保健当局の給与・勤務管理システムでは、複雑な給与規則と業務運用の問題が重なりました。会計検査院は、役割や責任の混乱、入力の遅さ、短い給与処理期間、未処理データの蓄積などを指摘しています。［10］
新システムは厳格な業務規則を持ち、勤務表が入力されていなければ支払処理を進められないなど、従来とは異なる条件がありました。正確な処理のための規則も、情報の準備や現場の運用が追い付かなければ、給与支払を止める要因となります。
ここから得られる教訓は、ソフトウェアの設定と、データを用意して期限までに処理する人の仕事を、一体として設計する必要があることです。
デンマーク・EFI：債権回収を自動化する基盤の行き詰まり
税務当局SKATの統一債権回収システムEFIは、問題の解決に至らず、2015年9月8日に自動回収が停止されました。その後、案件は手作業を中心に処理され、EFIの計画は断念されました。2017年の会計検査院のフォローアップでも、その経過が確認されています。［11］
債権回収では、金額が登録されているだけでなく、時効や法的な有効性などの確認が欠かせません。統合・自動化の土台にある情報や判断が不確かであれば、処理量を増やすほど問題の影響も拡大し得ます。
自動化の期待が大きい業務ほど、止めた後の手作業の負担も重くなるという点が、重要な示唆です。
米国・Healthcare.gov：要件、テスト、監督がそろわないまま公開
2013年に公開された医療保険加入サイトHealthcare.govは、開始時に深刻な利用障害に直面しました。米国GAOは、要件管理、稼働前テスト、プロジェクト監督の不備を指摘しています。テスト資料には、合否を判断する基準などの欠落もありました。［12］
サイトが表示できることと、本人確認や加入手続きまで完了できることは別です。複数の機能・組織が関わるサービスでは、全体として動くことを確かめる責任が必要です。
その後の対策によって性能問題は大きく改善したとも報告されています。初期の失敗と、その後のサービスの価値は、分けて評価する必要があります。
英国・農業補助金：支払システムの問題が、受給者の資金に及んだ
英国の農業補助金では、2015年分の基本支払制度をめぐり、支払不足や処理上の問題が生じました。NAOは2015–16年度の会計に関する報告で、約1万3,000人の農業者に対し、少なくとも2,530万ポンドの追加支払義務があると当局が見積もっていることを示しました。［13］
給付・補助金システムの遅延は、受給者にとって入金の遅れや資金負担になります。行政側では「処理中」であっても、受給者は日々の支払を続けなければなりません。
業務システムの品質を考える際、処理件数と正確性に加え、約束した時期に資金を届けることも重要です。
豪州・Robodebt：自動化された判断の前提が不適切だった
Robodebtは、福祉給付の過払い回収をめぐる事例です。税務上の所得情報を平均化して給付対象期間の所得を推定し、それを根拠に債務を算定する手法が問題となりました。所得の平均化だけに基づく債務算定は違法とされ、制度は2019年に終了し、王立委員会による検証が行われました。［14］
例えば年収が同じでも、毎月一定の収入がある人と、一時期だけ働いた人とでは、特定の期間に受け取った所得が違います。年間の情報を機械的に配分すれば、その期間の給付資格を誤って判断する可能性があります。
この案件は、基幹システム更改時の障害とは異なります。判断の制度的・法的な前提に問題があれば、システムが設計どおり動いても深刻な被害につながる、という例です。
4．巨大システムで成果を出している四つの事例
失敗事例だけを見ると、大規模な刷新は避けるべきだと思えてきます。しかし、老朽化したシステムを使い続けることにも、保守、人材、障害、制度変更への対応といったリスクがあります。刷新を成功させる条件を考えるため、成果が確認できる例も見ておきます。
なお、前半の二つは税務基幹システムの刷新、後半の二つは長期にわたり成果を出す国家的な業務・連携基盤です。同じ意味での「移行成功」ではなく、稼働開始時に一切の障害がなかったと確認したものでもありません。
ニュージーランド：税務・給付基盤を段階的に刷新
内国歳入庁のBusiness Transformationは、1980年代からの基幹システムを刷新した事業です。4段階・6回のリリースを経て旧システムを廃止し、2022年6月に終了しました。当局は各リリースを計画どおり、予算内で実施したと報告しています。事業全体の終了時期には、コロナ対応に伴う当初計画からの若干の遅れがありました。［15］
2023–24年度の評価では、電子チャネルの可用性99.9％、累計5億NZドル超の行政コスト削減などが報告されています。一方、中小企業の税務対応時間の削減は、目標18時間に対して実績4時間でした。［16］
この事例は、導入完了に加えて、稼働後の効果と未達事項まで確認できる点で参考になります。また、初回導入の経験を踏まえ、その後の設計レビューには現場職員60人が参加しました。段階導入を、学んで進め方を変える機会として使っています。［17］
フィンランド：70以上の税務アプリを統合し、手続きも整理
税務当局のValmisは、70以上の税務アプリケーションを既製の税務ソフトウェアに段階的に置き換え、2020年3月に完了しました。年次報告では、5段階の導入を成功させ、スケジュール・予算・目標を守ったとしています。法令と業務手続きの簡素化、職員研修も並行して実施しました。［18］
オンライン窓口MyTaxでは、2020年時点で税務サービス利用の89％を扱い、個人納税者の80％超が申告書をMyTaxで完成させていたと報告されています。［19］
参考になるのは、ソフトウェアへの移し替えとともに、統合を難しくする業務側の複雑さにも取り組んだことです。既製品の採用だけを成功理由とみなすことはできません。
シンガポール：TradeNetで貿易申請を一つの窓口へ
1989年に導入されたTradeNetは、貿易に関する申請情報を一つの窓口で受け付け、税関や関係当局の手続きを進める基盤です。長期にわたり更新され、税関の公開FAQでは、許可申請・変更申請の99％超を10分以内に処理すると説明しています。これは貨物の検査や搬出までを含む全工程の時間ではありません。［20］
2007年の更新では、処理手数料の引き下げにより、企業側が年間約400万シンガポールドルを節約できると政府が報告しました。［21］
この事例は、省庁内の効率化を越えて、企業の手続き負担と待ち時間を減らす基盤を継続して運用してきたものとして評価できます。
エストニア：各機関のシステムを接続するX-tee
エストニアのX-teeは、X-Road技術を使って行政機関や企業のシステム間でデータを交換する基盤です。データの管理主体を維持しながら連携する構成で、例えば警察が交通当局の運転免許情報を照会できます。［22］
2021年の会計検査院の監査では、2020年の照会件数は15億7,000万件、直近3年間に中央部分に起因した大きな影響のある停止は1件で、中核サービスの信頼性はおおむね確保されていると評価されました。一方、接続する民間企業の情報セキュリティ確認には問題があるとも指摘されています。［23］
フィンランドがアプリケーションを統合したのに対し、こちらは独立したシステムを共通の仕組みでつないでいます。集中と分散のどちらにも成果を出す構成があり、業務の性質や責任の境界に合わせて選ぶ必要があります。
5．特許庁：開発中断から、段階的な刷新と稼働へ
日本にも、巨大システム開発が行き詰まり、その後、進め方を変えて主要業務の刷新を実現した例があります。特許庁の事例です。同じ行政機関の中で、開発中断と立て直しの双方を追える点で、海外の成功・失敗事例をつなぐ重要なケースです。
５年以上たっても基本設計が終わらなかった
特許庁は、長年の制度改正や個別改修によって複雑になったシステムを再構築し、情報の一元化、機能の集約、業務の迅速化、経費削減を目指していました。2006年12月に始まった「特許庁運営基盤システム」の開発では、当時の東芝ソリューションが全体設計・基盤機能の開発を、アクセンチュアが進捗管理や業者間調整などの管理支援を担当しました。特許庁は発注者として全体を統括する立場でした。［25］
| 当事者 | 担当 | 当初契約額 | 中断までの支払額 |
|---|---|---|---|
| 東芝ソリューション | 全体設計・基盤機能の開発 | 約99.23億円 | 約24.87億円 |
| アクセンチュア | プロジェクト管理支援 | 約34.34億円 | 約29.64億円 |
| 合計 | 上記の設計・開発および管理支援契約 | 約133.57億円 | 約54.51億円 |
金額は会計検査院の資料に基づきます。約133.57億円はこれらの当初契約の合計であり、将来の運用・保守まで含む生涯費用ではありません。［25］
この案件は、2012年１月に開発中断となりました。作業開始から61か月が経過しても基本設計が完了していなかったと、会計検査院は指摘しています。したがって、KSK2のような稼働後の初期トラブルとは、問題が表面化した段階が異なります。特許庁では、刷新したシステムの稼働に到達できませんでした。［25］
業務理解と設計上の前提を固められなかった
技術面で示唆的なのは、共通機能の設計を共通化する作業が進まず、開発規模が既存の約2,300万行に対して約6,000万行になると見積もられていた点です。これは完成したコードの実測値ではなく、当時の見積もりです。行数だけで品質を判断することはできませんが、簡素化という目的を実現するための設計が、大きな課題になっていました。［26］
情報システム学会の提言は、業務要件の確認が未完成の段階で1,300人が投入されていたことを挙げ、要件定義・設計・品質確保の工程管理に問題があったと分析しています。これは学会側の評価であり、司法判断による責任認定ではありません。［27］
ここからは私の考察です。何を作るか、どの機能を共通にできるかが固まらないまま人を増やすと、それぞれが異なる前提で作業を進める可能性があります。後になって解釈の違いが判明すれば、調整と手戻りが増えます。上流工程の不確実性を、人員の追加だけで解消することは困難です。
共通化が計画全体の成立条件であるなら、代表的な通常業務と難しい例外業務を使い、早期に成立を確かめる必要があります。多数の設計書を作った後に前提を見直すほど、変更の影響は広くなります。
管理支援を、是正の意思決定につなげられたか
この案件では、発注者の管理能力を補うため、管理支援会社も起用されていました。情報システム学会はその点を踏まえ、特許庁と開発会社に加え、アクセンチュアの管理支援の実効性も検討すべきだと論じています。同学会は、完成が困難な場合に中断や中止を判断することも、プロジェクトを立て直す管理の一部であると指摘しました。［27］
一方、会計検査院は、発注者である特許庁自身の管理も十分でなかったとしています。専門家を雇うことと、その専門的な評価を使って業務や計画の判断を下すことは、両方が必要です。［25］
私がこの点から重視するのは、問題の発見から是正までを一続きにする仕組みです。誰が業務要件を確定し、誰が設計変更を決め、何をもって改善したと認めるのか。改善できない場合に、どの条件で範囲、日程、契約を見直すのか。管理支援の価値は、その判断を改善できたかによっても評価する必要があります。
遅延対応が後工程に影響した点も見逃せません。管理支援契約では工数の振替により、予定されていたテスト支援・検証が当初の約10分の１、業務試行・研修支援が約６分の１になっていました。これは管理支援業務の予定工数の話であり、システム全体のテストを実際に９割削減したという意味ではありません。［26］
前工程の遅延への対応で、後工程の品質確認や導入準備に使う資源まで消費する。この構造は、Phoenixなど海外事例の教訓とも重なります。
契約代金は回収されたが、失った時間は残った
会計検査院は、約54.51億円の支払全額を不当事項として指摘しました。その後、2013年８月に解約で合意し、９月に利息相当分を含む56.2億円が解決金として特許特別会計に支払われました。国会答弁では、両社の負担割合は事業者間で決められたものであり、経済産業省として把握していないと説明されています。［25・28］
したがって、約55億円がそのまま未回収のまま残ったという説明は正確ではありません。ただし、職員や関係者が費やした時間、更新が遅れたことによる負担、実現できなかった利便性や効率化まで返金で取り戻せるわけではありません。これらの損失を今回の資料だけで金額に換算することはできませんが、契約代金の回収と分けて評価する必要があります。
また、この開発中断により特許権が大量に失われたといった直接被害は、今回確認した資料では確認できません。稼働前の開発中断による損失と、本番での誤処理による利用者の権利への被害は、区別して論じる必要があります。
公式な総括は、技術力・調達・一括更新の三つ
政府は、第三者委員会による原因の指摘を、①事業者の技術力・プロジェクト管理能力の不足、②調達時にその能力を十分確認できていなかったこと、③大規模な一括更新という技術的難易度の高さ、の三つに整理しています。［29］
再計画では、業務単位に開発を分割し、調達評価で技術点を価格点の３倍の重みにすること、外部専門家をCIO補佐官として登用すること、業務を網羅的に文書化することなどが採られました。2013年３月に新たな開発計画が策定されています。［29］
複数の開発を見渡す特許庁PMOの設置や、段階刷新に用いるアーキテクチャの指針、設計・開発の標準工程の整備も進められました。立て直しは、開発作業に加え、発注者側の体制と、システム全体を整合させる仕組みにも及んでいます。［30］
再計画後は、主要システムの稼働に到達した
その後の特許庁は、実際に構築・稼働へ進んでいます。主要な実績と、最後に残る確認事項を整理すると、次のようになります。
| 時期 | 対象 | 公表資料から確認できること |
|---|---|---|
| 2020年１月 | 特許・実用新案の審査業務のうち分類付与部分 | サービス開始 |
| 2021年５月・７月 | 同システムの方式審査・実体審査部分 | サービス開始。進捗報告では安定稼働と報告 |
| 2022年１月 | 四法公報システム | 新システムで公報発行を開始。その後、安定稼働に移行 |
| 2025年１月 | 審判システム | 刷新・本格稼働を実施 |
| 2026年９月予定 | 意匠・商標システム | 2026年版年次報告書では、現行の最適化計画を締めくくる刷新と位置付け。今回確認した一次資料では、予定どおり完了した実績までは未確認 |
出典：特許庁の技術検証委員会資料、審判関連の公表資料、特許行政年次報告書2026年版。［31〜34］
特許・実用新案の審査業務では、システム構造の簡素化と共有データベースの構築が実施されました。公報や審判に加え、審査という中核業務でも刷新後のシステムが使われる段階に到達したことは、立て直しの具体的な成果です。［31］
ただし、再出発後も問題はありました。四法公報システムの振り返りでは、2022年１月のサービス開始直後に多数の課題が発生し、約２か月で収束したと報告されています。４月以降は障害管理を通常の運用体制へ移し、安定稼働を実現したとしています。稼働開始から業務の安定までを管理した例として読むことができます。［32］
特許庁の歩みは、失敗した行政機関が、発注体制と開発方法を見直し、長期間をかけて主要システムの稼働へ到達した事例と評価できます。一方、刷新全体の投資効果や当初期待した経費削減を十分達成したかは、稼働実績とは別に評価する必要があります。また、意匠・商標システムについて、予定日を過ぎたことだけを根拠に全体完了とは判断しません。
失敗と立て直しが、十の要素にどうつながるか
この事例を、次章で整理する十の要素に当てはめると、関係の強い部分と、直接の評価が難しい部分が見えてきます。以下は、資料を踏まえた私の評価です。
| 要素 | 特許庁の事例から得られる示唆 |
|---|---|
| ① 成功の定義 | 作業の進捗、稼働の達成、投資効果をそれぞれ確認する必要がある |
| ② 業務の例外の理解 | 業務を文書化し、共通化する部分と個別に残す部分を決めることが設計の土台になる |
| ③ 発注側の権限と能力 | 専門家の支援を受けながら、発注者自身が判断できる体制が必要 |
| ④ 悪い情報と計画変更 | 問題の把握を設計・範囲・日程の変更、必要な場合の中断につなげる |
| ⑤ 不確実性の早期検証 | 計画を支える共通化や開発規模の前提を、早い段階で確かめる |
| ⑥ 業務完了・復旧を確かめるテスト | 遅延対応で後工程の検証資源を消費する危険がある。ただし、中断案件自体は本番テストの失敗を実証する事例ではない |
| ⑦ 段階導入と学習 | 再計画では業務単位に開発を分け、順次稼働する方法に転換した |
| ⑧ 稼働直後の現場の余力 | 中断案件では直接評価できない。再計画後の公報システムでは、稼働後の課題を収束させる過程が確認できる |
| ⑨ 契約と予算 | 調達時の能力評価と、遅延時の資源配分を、全体の成果と結び付ける必要がある |
| ⑩ 出力の正しさと権利保護 | 中断案件では本番の誤処理による権利被害を確認しておらず、直接の証拠として扱わない |
同じ組織でも、体制と進め方を変えれば、異なる結果に到達し得ます。過去の失敗を評価することと、その後の改善を確かめることを、両方続ける必要があります。
6．成否を分ける十の要素
海外の失敗・成功事例と、特許庁の中断・立て直しを合わせて見ると、技術、業務、組織、契約の関係が見えてきます。ここからは、それらを踏まえた私の考察です。十の要素は、案件の状態を確かめ、改善策を考えるための診断の観点として整理します。
① 成功の定義が、業務と投資効果まで届いているか
プロジェクトの成功には、少なくとも三つの面があります。
| 面 | 確認する内容 |
|---|---|
| 計画の遂行 | 予算、日程、合意した機能を守れたか |
| 業務の成立 | 正しい対象・金額・期限で処理し、現場が業務を回せるか |
| 投資効果 | 利用者負担、運用コスト、制度変更への対応力が改善したか |
予定日に稼働しても、支払が誤れば業務は成立しません。安定して見えても、その裏で大量の手作業を続けていれば、投資効果は小さくなります。
逆に、稼働時期を変更した案件でも、被害を避け、長期の効果を出したなら、その判断を評価する余地があります。どの成功を測っているかを明確にすることで、表面的な達成と実際の価値の混同を防げます。特許庁についても、主要システムの稼働に到達した事実は評価できますが、刷新全体の費用対効果には別の検証が必要です。
② 業務の例外を理解し、残すものと整理するものを決めているか
巨大システムは、長年の制度改正と例外処理を抱えています。通常の処理が簡単でも、訂正、遡及、取消、相殺、承認の差戻しなどが組み合わさると難しくなります。
現行業務の調査には、仕様書のほか、Excel、担当者の確認手順、独自の照合も含める必要があります。従来のシステムの弱さを、人が補っている場合があるからです。
そのうえで、法令・権利保護のために必要な例外、制度や業務を変えればなくせる例外、管理された手作業で残せる例外を分けます。すべてを自動化しようとすると、費用と複雑さが膨らむ可能性があります。
ただし、少数者に必要な処理を件数の少なさだけで省けば、その人々に負担を押し付けます。簡素化には、権利と実務の両方を見た判断が必要です。
③ 発注側に、業務を決める権限と能力があるか
開発会社が優秀でも、どの部門の手順を標準にするか、誰の負担増を認めるか、どの例外を残すかという判断には限界があります。これらは発注側の業務責任です。
各部門が要望を出し、開発会社が調整する一方、組織全体の優先順位を決める人がいなければ、個別要望は満たせても全体は複雑になります。会議体が多くても、決定権が曖昧なら前には進みません。
発注側には、業務、技術、データ、契約をつなぎ、説明された選択肢の意味を判断する能力が必要です。英国NAOも、経営幹部のデジタル変革への理解不足を、繰り返される問題の背景として指摘しています。［24］
特許庁の案件は、管理支援会社を起用していても、発注者の判断能力が重要であることを示しました。専門家の評価を理解し、部門間の対立を解き、範囲や日程の変更を決める責任者が必要です。外部支援を有効に使うためにも、発注者側に判断の中核を残すことが求められます。
④ 悪い情報が届き、計画変更につながるか
現場では「このままでは回らない」と分かっていても、報告の過程で「課題はあるが対策中」に変わることがあります。納期、公表済みの政策、予算、担当者の評価が絡むと、関係者が少しずつ楽観的な解釈を選ぶ誘因が生まれます。
必要なのは、問題の報告を促すだけでなく、その情報によって範囲、順序、日程、体制を変更できることです。第三者の検証も、指摘を受けて意思決定を変える仕組みと組み合わせて初めて意味があります。
もちろん、延期にも旧システムの障害や維持費のリスクがあります。重要なのは、予定どおりに進める場合と変更する場合を同じ基準で比較できることです。稼働を見送る条件と、その判断者を事前に決めておく必要があります。
この考え方は、稼働直前に限りません。特許庁のように基本設計が進まない場合にも、次へ進むための証拠と、立て直しを判断する期限が必要です。解決の見通しを確かめながら継続できる仕組みを、開発の初期から設けます。
⑤ 重要な不確実性を、早い段階で確かめているか
失敗リスクの高い部分ほど、後回しにすると対応の選択肢が減ります。データの品質、複雑な計算、主要な外部連携、ピーク時の処理能力などは、早い段階で実物や実データに近い条件を使って確かめる価値があります。
大量の画面を作り終えた後で基幹処理の前提が崩れると、周辺の設計にも修正が広がります。反対に、初期の調査や試作で難しさを確認できれば、範囲や予算を修正できます。
特許庁で課題となった共通化も、こうした検証の対象です。簡素化できるという構想を、代表的な業務や例外処理で確かめ、開発規模の見積もりに反映してから体制を拡大する必要があります。
初期の検証費用は、完成品の機能に直接見えないことがあります。しかし、後戻りの大きい判断をする前に、不確実性を減らすための費用として考えるべきです。
⑥ テストが、利用者の業務完了と失敗からの復旧を確認しているか
登録、承認、支払、計上、通知を個別に確認しても、一連の処理が最後まで正しく動くとは限りません。実務の時間軸と関係者の操作を含めて確かめる必要があります。
とりわけ、通信断、タイムアウト、二重送信、途中取消、権限変更、過年度訂正を含む処理は重要です。正常時に動くことに加え、途中で失敗しても記録を壊さず、正しい状態から再開できることを確認します。
テストの消化率が高くても、対象に重要な業務が入っていなければ安心材料になりません。どのリスクを、どの条件で確認し、どの結果なら合格にするかを示すことが必要です。
特許庁の中断案件に見られた、遅延対応で後工程の支援工数を消費する問題も、この観点から捉えられます。工程の遅れを取り戻す際にも、稼働に必要な検証と教育を実施できる資源が残るかを確認しなければなりません。
⑦ 段階導入が、影響の限定と学習につながっているか
段階導入は有効ですが、回数を分けるだけでは不十分です。Phoenixも2回に分けて導入されました。
最初の導入で生じた問題を確認し、次の段階を変えられることが必要です。また、一部を止めても他を動かせるか、旧新システムのデータをどちらが更新するか、併存期間をどれだけ続けられるかも重要です。
特許庁の再計画では業務単位で刷新を進め、審査、公報、審判などを順次稼働させました。一部を完成させて使い始めることには、成果を得る意味と、次の開発を見直す材料を得る意味があります。
分割すると移行の影響を抑えられる一方、連携や二重運用は増えます。全国一斉切替にも段階導入にも固有の負担があり、業務上の境界とデータの整合性を見て選ぶ必要があります。
⑧ 稼働直後に、現場が問題を吸収する余力を持っているか
仮に1日10万件の処理のうち1％が人による確認を必要とすると、毎日1,000件の確認作業が発生します。処理能力が1日600件なら、未処理は毎日400件ずつ増えます。これは実際の案件の数値ではなく、滞留の仕組みを示す仮定です。
滞留が増えると問い合わせも増え、問い合わせ対応によって処理能力が下がり、さらに滞留する可能性があります。再申請や訂正が加われば、どれが最新かの確認も難しくなります。
この状態では、ソフトウェアを修正しても、蓄積した案件はすぐには消えません。障害の解消と業務の正常化は、別に管理する必要があります。
稼働直後には熟練者、問い合わせ要員、修正担当者などの余力を用意し、習熟に伴う一時的な生産性低下も見込みます。期待した効率化を先取りして人員を減らすと、回復する能力まで失いかねません。
⑨ 契約と予算が、全体の成果を促しているか
発注側が年度内の予算執行、開発会社が契約範囲の納品、業務部門が現行手順の維持を優先すると、利用者の業務を最後まで成立させる責任が曖昧になります。
複数のベンダーが関わる場合は、境界で起きた問題を誰が調べ、誰が解決まで統括するかを決める必要があります。担当範囲の説明ができることと、全体を動かせることは異なります。
費用には、開発に加えて、データ整備、移行、教育、併存運用、安定化、旧システム廃止まで含める必要があります。初期費用を抑えても、運用側に大きな作業を残せば、組織全体では高くつく可能性があります。
調達時には、提案の良さに加え、その規模と難しさに対応する中核人材、業務理解、設計力、品質確保の方法を確認します。特許庁の再計画で技術評価が重視されたことは、価格と実現可能性を合わせて判断する必要性を示しています。
⑩ 出力の正しさと権利保護を、継続して検証しているか
行政システムは、税額、給付、債務、資格などの判断を支えます。誤りがあれば、利用者は時間や資金を使って訂正しなければなりません。
そのため、システムが出した金額を正しいとみなす前に、根拠を説明できること、異議を申し立てられること、訂正後に関連する処理も修復できることが重要です。Robodebtは、判断の前提を検証せずに大規模な処理を進める危険性を示しています。
また、稼働後の効果は平均値だけで見るべきではありません。平均の処理時間が短くなっても、例外案件の一部が長く止まっていることがあります。処理時間の分布、長期滞留、誤処理、苦情、手作業の量まで見ることで、サービスの実態に近づけます。
7．大きな失敗は、複数の要素が連鎖して生まれる
典型的な悪循環は、次のように考えられます。
- 業務とデータの複雑さを過小評価する。
- 開発や移行準備が遅れる。
- 期限と予算を変更できず、テストや教育を圧縮する。
- 未解決の問題を残して稼働する。
- 手作業と問い合わせが現場の能力を超える。
- 滞留と訂正が増え、復旧作業が難しくなる。
これはすべての案件に当てはまると断言できる法則ではありません。特許庁の中断案件は、稼働前に行き詰まったため、上記の全段階をたどったものでもありません。それでも、遅延対応が将来の検証資源を圧迫するなど、途中から回復する選択肢が狭くなる構造は共通します。個々には小さく見えた判断が重なると、問題を見つける機会と回復する能力を同時に失い得ます。
反対に、最初の見積もりが外れても、早い段階で難しさを把握し、範囲、順序、日程、体制を変更できれば、大きな被害を避けられる可能性があります。成功を支えるのは、当初の計画の精度と、学びに応じて計画を更新する能力の両方です。
8．「パッケージ」「アジャイル」「分散構成」だけでは判断できない
成功事例を見たとき、採用した技術や開発方式をそのまま答えにしたくなります。しかし、同じ方式でも、業務や組織の条件が変われば結果は変わります。
| 選択 | 期待できる利点 | 成立させるために確認すること |
|---|---|---|
| パッケージの採用 | 共通機能の再利用、保守の継続性 | 業務をどこまで標準に合わせられるか、追加改修が膨らまないか |
| 短い周期での開発 | 早い確認と修正 | 業務責任者が継続して判断できるか、全体の整合性を保てるか |
| システムの分割 | 変更や障害の影響を限定しやすい | 境界が適切か、連携失敗やデータ不整合を扱えるか |
| 集中・統合 | データと処理の共通化 | 全体障害の影響、権限管理、共通部分への負荷を抑えられるか |
| クラウドの利用 | 基盤調達や拡張の柔軟性 | アプリケーションの性能、運用、費用、復旧を設計できているか |
技術的な選択は、問題を解くための手段です。何を共通化し、どこに独立性を残し、どの不確実性を早く調べるか。その判断と一体で評価する必要があります。
9．民間企業のSaaS導入やAI活用にも共通する
国家規模の税務システムと、中堅企業の会計・販売管理システムでは規模が違います。しかし、業務、データ、組織、外部サービスがつながるという構造は共通します。
受注システムから請求システム、会計へデータを送る連携でも、通常の登録は比較的分かりやすい一方、請求後の値引き、取消、締め後の訂正、入金済み案件の変更になると難しくなります。
APIの接続テストに成功しても、それだけで連携する業務が完成したとは言えません。通信が切れたときに何が確定しているか、同じデータを再送しても二重登録にならないか、担当者が変わっても失敗に気付き修復できるかまで考える必要があります。
AIエージェントによる自動化でも同じです。生成や実装が速くなれば、試作や検証の機会を増やせます。一方、誰の権限で何を確定するか、判断に使うデータは正しいか、誤りをどう訂正するかという業務上の課題は残ります。
自動化の速度が上がるほど、誤った処理も速く広がり得ます。実行範囲を限定し、結果を確認し、必要な段階で人が判断する設計が重要になります。
10．KSK2をこれからどう評価していくか
KSK2については、現時点の公開情報だけで、海外の失敗案件と同じ原因だと結論付けることはできません。窓口の遅延やe-Taxの個別不具合があったことと、刷新全体の長期的な成否も分けて見る必要があります。
今後の評価では、次の点が重要になります。
- どの業務に、どの程度の遅延・誤りが発生したのか。
- システムの不具合と、操作・業務体制の問題がどう関係したのか。
- 修正後、滞留案件と問い合わせがどの程度解消したのか。
- 情報の紐付けや権限管理について、再発防止をどう検証したのか。
- 稼働判定時の懸念と判断、その後の教訓をどう説明するのか。
- 安定化後、納税者負担と行政コストをどの程度減らせたのか。
これらを公表することは、利用者の不安を減らし、今後の改善を評価する土台になります。海外の監査や特許庁の公表資料が役立つのも、何が起き、どう判断し、何が不足し、その後どう変えたのかを追えるからです。特許庁の公報システムのように、稼働直後の課題をどう収束させたかを示すことも、評価に役立ちます。
巨大システムの導入には、すべてを事前に予測することが難しい面があります。それでも、重要な不確実性を早く確かめ、悪い情報を意思決定につなげ、現場の回復能力を残すことはできます。
成功した案件も、途中で多くを学び、進め方を変えています。特許庁の経験は、一度の大きな失敗を経ても、業務を把握し、発注者の体制を整え、開発を分割して、主要システムの稼働へ進めることを示しています。その歩みには、長い時間と多くの負担が必要でした。だからこそ、問題が小さい段階で学び、計画を修正する価値があります。
私がこれらの事例から最も強く感じるのは、巨大システムを支えるのは、技術を選ぶ力と同時に、組織として現実を把握し、判断を更新する力だということです。稼働の前にも後にも、その力が問われ続けます。
出典・参考資料
※ 本稿の事実関係は2026年10月28日に確認できた公開資料に基づきます。公表ページは更新される場合があります。KSK2の原因仮説や各事例からの教訓は、資料そのものの結論と区別して記述しています。海外の費用・効果は原資料の通貨・対象期間で示し、国や案件間の直接比較には用いていません。
- 国税庁「国税システムの更改について」。
- 国税庁「国税庁レポート2025」。
- e-Tax「お知らせ一覧」。
- 国税庁「税務署窓口における各種手続について」（2026年10月19日更新）。
- e-Tax「インターネットバンキングで手数料納付ができない事象について」（解消、10月5日更新）。
- e-Tax「『振替納税結果表示』画面に『振替不能』等と表示された方へ」（解消、10月13日更新）。
- e-Tax「マイページの『贈与税関係情報』が更に便利になります。」（10月16日更新）。
- テレビ朝日「『e−Tax』で他人の贈与税情報が一時閲覧可能に 国税庁」、ASCII.jp「e-Taxで不具合、他人の個人情報が一時閲覧可能に」。
- カナダ会計検査院「Building and Implementing the Phoenix Pay System」（2018年）。
- クイーンズランド州会計検査院「Information systems governance and control, including the Queensland Health Implementation of Continuity Project」（2010年）。
- デンマーク会計検査院「Opfølgning i sagen om SKATs systemmodernisering」（2017年10月）。
- 米国GAO「Healthcare.gov: CMS Has Taken Steps to Address Problems, but Needs to Further Implement Systems Development Best Practices」。
- 英国NAO「Department for Environment, Food and Rural Affairs and Rural Payments Agency Accounts 2015-16」。
- 豪州「Royal Commission into the Robodebt Scheme — Report」、Victoria Legal Aid「An in-depth look at our robo-debt test case」、Services Australia「Information about Robodebt」。
- ニュージーランド内国歳入庁「Business Transformation」、監査への回答「Follow-up on audit of Benefits Management」（2022年）。
- 同庁「Outcomes of the Transformation Programme」（2023–24年度評価）。
- 同庁「Scope and detailed design」「Governance forums」。
- フィンランド税務当局「Annual report 2019」「Annual report 2020」。
- 同庁「Annual report 2020 — Positive taxpayer experience」。
- シンガポール税関「TradeNet」「How long does Customs take to approve the permit application and amendments submitted via TradeNet?」。
- シンガポール財務省「APEC Customs Business Dialogue 2009での講演」（2009年8月1日）。
- エストニア情報システム庁「Data exchange layer X-tee」。
- エストニア会計検査院「X-teeの信頼性と接続する民間企業のセキュリティに関する監査公表」（2021年3月2日）。
- 英国NAO「The challenges in implementing digital change」（2021年）、「Digital transformation in government: addressing the barriers to efficiency」（2023年）。
- 会計検査院「特許庁運営基盤システムの構築に当たり、発注者として必要なプロジェクトの管理を十分に行っていなかったことなどのため所期の目的の達成が困難となっているもの」（平成23年度決算検査報告）。
- 会計検査院「第３ 特許庁運営基盤システムの構築について」（同報告）。
- 情報システム学会企画委員会・提言検討チーム「政府のソフトウェア調達の改善について」（2013年３月22日）。公式な政府総括とは区別して参照。
- 衆議院「第186回国会 経済産業委員会 第11号」（2014年４月18日）。契約解約、解決金、原因分析、再計画に関する政府答弁。
- 衆議院「第196回国会 経済産業委員会 第10号」（2018年５月11日）。開発中断の原因と調達・開発体制の改革に関する政府答弁。
- 特許庁「特許行政年次報告書2016年版 第２部第５章」、「特許庁アーキテクチャ策定指針」、「システム開発関連情報の公表」。
- 特許庁「2020年10月以降のシステム開発プロジェクト進捗報告及び2021年度の予定」（第31回技術検証委員会・資料１）。特実審査業務システムの段階稼働に関する報告。
- 特許庁「四法公報システム刷新プロジェクトについて」（第34回技術検証委員会・資料２）。稼働・安定化の振り返り。
- 特許庁「審判に関する特許情報標準データのデータ形式変更について」。2025年１月の審判システム刷新を明記。
- 特許庁「特許行政年次報告書2026年版 第２部第５章」。意匠・商標システムは2026年９月刷新予定と記載。予定の記載を完了実績として扱っていない。
コメント