何故お役所ってオワコンIEが大好きなの？

まさか2020年にもなって、こんな解説を書かねばならぬことになろうとは思わなかったけど、マイナポイントの件で久しぶりに電子申請のIE縛りが話題になってますね。「当時普及していたIEを採用した」（総務省）というコメントが火に油を注いでしまった。わたしが把握している現場の事情としては「キャッシュレス決済との紐付けだから、住民にはスマホを使ってもらうことを想定。自分のスマホを持ってない利用者向けに自治体窓口などで使える端末を用意しており、その環境ではIEが使えるので他ブラウザ対応は後回しにした」という話で、コロナ禍にあってタイトなスケジュールの中でやむを得ない開発の優先順位付けだったと承知している。

TLを見ていると「ばーかばーか」と罵詈雑言を書かれていて、まあ世のWeb Developerから見たらそうとしか思えないよなぁ、今時ChromeやSafari向けにWebサイトつくるよりもIE向けってずーっと難しいよね、そうはいっても、これにはそれなりにちゃんとした理由があって、そこを解消しない限り簡単には直らないんですよ、いちおう3年前に解決したんだけど、まだ広がってないんだよねー、という事情を縷々ご説明したい。

なにを隠そう私もマイクロソフトにいた2006年から3年間くらいWindows VistaのIEからe-Taxできない問題で役所に呼びつけられて文句を言われ続けたり、2017年に自分自身が担当したシステムでIE縛り、Java縛りで炎上したこともあって、この話は本当にトラウマなのですよ。後者の事情はこちらの記事で丁寧に拾っていただいている。

普通は役所のシステムって構築してから5年とか7年は塩漬けにして使うもので、一度やらかしてしまうと名誉挽回の機会なんて向こう数年は与えられないんだけど、こと本件に関しては高市総務大臣から「今すぐ私がマニュアルなしでも使えるように直しなさい」と叱責いただいて、しっかりと予算的なサポートも得られたことで、たったの数ヶ月で立て直すことができた。

この数ヶ月は外部のセキュリティやPKIの専門家の方から様々なサポートをいただいて何とか実現したんだけれども、役所のシステム開発としては非常識というか、極めて難易度が高い案件だった。「え？単にChromeやSafariをサポートするだけでしょ、難しい訳ないじゃん」と思う諸兄は、もうしばらくこの話に付き合って欲しい。

もともとマイナポータルは日本を代表するITベンダーと通信キャリアの3社が開発したんだけど、大臣からの叱責を受け「ちゃんとお金を払うから直してよ」って見積もり依頼したところ「無理です。電子申請にはActive XかJavaを使うのが常識で、それを簡単にするなんてことは技術的に不可能です」と逃げ出されてしまった。国際的な通信網を運用したり、世界一のスパコンを組み上げるよりはずっと簡単なはずで、大臣の手厚いサポートで億単位の予算を用意したにも関わらず本当にケツを捲られた。これは役所の調達としては極めて珍しいことで、自分たちが納品したシステムが調達仕様書に定めた要件を実現できず、それが社会問題となって新聞に大きく載り、大臣が直接叱責するほどの大事件となって、それでも全く責任を取らずにケツを捲るというのは、日本を代表する一流企業の公共営業部隊が常識的にはやることではない。たまたま並行して給付金オンライン申請で世間をお騒がせした「ぴったりサービス」の開発が走っていて、そちらでも同じ課題に直面することが分かっていたので、担当している別の日本を代表するSIベンダーさんと相談したところ「全く技術的な見通しは立たないんですけれども、やり方を一緒に考えてくれるのであれば何とかしましょう」と引き受けて下さったことで、何とか開発をスタートすることができた。

改善前の2017年1月リリース当初のマイナポータルは、担当していた自分がいうのも何だが本当に厄介な代物だった。事前にJavaとJPKI利用者ソフトとマイナポータル設定ソフトの3つをインストールした後、かなりトリッキーな操作で初めて出てくるブラウザのセキュリティを緩めるための画面を出して面倒な設定を行って初めて使うことができた。設計レビューしていた自分でさえ15分から20分マニュアルと首っ引きにならないと設定できなかった。さらにInternet Explorerを64bitモードにしていると動かない罠もあった。もちろん仕様書では主要なブラウザで動くように指定していたのだが、2016年秋頃から雲行きが怪しくなって、気付いたらInternet ExplorerとSafariでしか動かない、年末にかけて非常に煩雑な操作を必要とすることが明らかとなった。「こんなはずじゃ」と日々悪化する状況に頭を抱えながらも、座してリリースを待たざるを得なかった。

数多くの電子申請サイトがInternet Explorerしかサポートしていない背景には一応ちゃんとした理由がある。多くの電子申請が本人確認と改竄防止のために電子署名を行うが、この電子署名に使うデジタル証明書がマイナンバーカードをはじめとしたICカードに格納されていて、これを読み出す必要があるのだが、そのためにマイナンバーカードを発行しているJ-LISがJPKI利用者クライアントソフト（通称：利クラ）を出していて、これを叩くインターフェースとしてActive XとJavaが用意されている。マイナポータルはInternet Explorer以外のブラウザでも動かしたかったので、Active XではなくJavaを採用した。ところが開発中の2016年にChromeとFirefoxが相次いでブラウザ上でJavaアプレットを動かすために必要なNPAPIのサポート打ち切りを発表した。理由はJava VMのセキュリティーホールが発見され続けて品質が改善する見込みは薄く今後も攻撃界面となる虞が強いこと、HTML5が発展したことで、複雑なUIを構築するためにJavaアプレットに頼る必要が薄れたことだった。当時ブラウザでサイトを開くだけで感染してしまうマルウェアが問題になって、その穴を塞ぐためのブラウザの改修が繰り返された。結果として途中まで動いていたログインが後から動かなくなったり、何とか動くブラウザについても面倒な設定変更を要するようになってしまって、いたちごっことなった。そもそもブラウザからICカードリーダーという物理デバイスを叩くこと自体がマルウェアと非常に挙動が似ているので、ブラウザのサンドボックスが強化される度に動かなくなるのは技術的には致し方ないところもあった。ブラウザの仕様変更という不可抗力に起因ということで、マイナポータルの対応ブラウザがどんどん減って設定操作が難しくなることについてベンダーを責めることも難しかった。ICカードを使わずワンタイムパスワードなり他の多要素認証で済めば話は簡単になるのだが、私たちで決められることではなかった。

Javaの動作環境はどんどん狭まってブラウザの設定は難しくなっていく、Active Xに倒せばInternet Explorerでしか動かない、いずれInternet Explorerがなくなる、少なくともJavaやActive Xをサポートしなくなることは設計当初から分かっていた。Javaの開発元であるOracleに相談するとJava Web Startを勧めてきたが、これとてJavaのインストールが必要となる。問題はブラウザから非標準的な方法でICカードリーダーを叩いていることである。マイナンバーカードをOSとブラウザが標準サポートすれば問題なく、米国政府の身分証規格であるPIVにはWindowsもMacもOSレベルで対応している。2015年頃からその可能性について古巣に探りを入れたところ、利クラに含まれるLegacy CSPというドライバのままでは難しく、最新のドライバモデルで書き直せば将来のOSバージョンアップでEdgeブラウザから読めるようになるかも知れないといった感触を得た。ICカードの特定領域に決められたメタデータを埋め込んでおけば、カードを挿しただけでドライバを読み込むこともできる。とはいえ既に1000万枚以上を配ったカードの仕様変更などできるはずもなく、OS標準機構を通じてブラウザから証明書にアクセスする標準規格として期待していたWeb Cryptography Key Discoveryという規格は2016年には暗礁に乗り上げ、2017年1月にはWGごと解散してしまった。新しくWGを再組成して標準化をやってOSでの対応を働きかけるにしても控えめにみて2〜3年は要する。そうこうしているうちに決め手となる解決策が見つからないままに、マイナポータルのリリースを迎えてしまった。

技術的には全く何の見通しも立ってない。2017年10月の改善へ向けて引き受けてくれたベンダーもActive Xに移行するくらいしか腹案がない。とはいえマルチブラウザー対応の旗を降ろすつもりはなく、とりあえず春までに方式設計を終えて秋のリリースを目指すこととなった。3つのアプリのインストールと手動操作が必要でマニュアル首っ引きで20分くらいかかるところ、マニュアル不要で3分以内、利用者がポチポチ押していくだけで複雑な操作なしに使えるようにする。対象とする動作環境はOS標準ブラウザのEdgeとSafariが必須、できればChromeとFirefoxにも対応したい。どうしても連休明けまでに目算が立たなければ対象をInternet Explorerに絞ってActive Xで実装することを受け入れるが、できれば避けたいところ。都合わたしが十数方式くらい考え、それぞれ実現可能かどうかベンダーに評価・試作してもらった。

Web NFCというまさに望んでいる規格があったが接触型ICカードをサポートしておらず、規格が開発中というだけで主要ブラウザに実装される見込みが薄い。（つい最近Android版Chromeで実装された）Web USBやWeb Bluetoothという別の規格があって、こちらはChromeに実装され始めていたが、それなりに有効化するのが面倒で、本来OSが面倒をみてくれるICカードドライバやPC/SCといった低レイヤーを全てJava Scriptで再構築しなければならず、そこの面倒をまるっと見てしまうと開発工数が膨れ上がる上に、カードリーダーとの相性はじめテストが非常に重くなってしまう。

3月末の時点でわたしが最も有力視していたのはカスタムURIスキーマか拡張子との関連付けを行って、ヘルパー・アプリケーションとしてネイティブアプリを立ち上げる方法だった。この方法だとネイティブアプリを立ち上げることはできても電子署名などの処理結果をブラウザに戻すことはできない。とはいえサーバーとの通信はできるので、ポスト先のURIを引数として渡して署名結果をサーバーに投げれば、まあ何とか必要な要件を満たすことができる。90年代からある古典的な機構なので、どんなブラウザでも動かすことができる。だが処理シーケンスをレビューいただいた誰もが知っている外部のセキュリティー専門家からは、フィッシング詐欺による電子署名の窃取に対して脆弱ではないかと指摘を受けてしまった。とはいえ他に妙案も見つからず、4月にはこの方式で試作を進めつつ専門家の説得を試みていた。

2017年4月に入ってWindows 10の春の大型アップデートで、EdgeブラウザがNative Messagingをサポートするという記述を見つけた。これは3月には見つけていたエストニア政府がChromeやFirefox向けに採用していた方法で、Java Scriptからネイティブアプリを起動してパイプで通信する方法だが、ブラウザ拡張のインストールを必要とすることに加えて、OS標準ブラウザであるEdgeとSafariで動かないため候補からは外していた。こちらの方式を使ったシーケンスについて専門家に見てもらったところヘルパーアプリケーション方式よりも安全性が高いという評価を得た。もうだいぶ試作が進んでいた段階で5月の連休を明けても専門家の説得に苦戦する中でベンダーと相談したところ、いずれ課題を指摘されるのであればベターな方式でやった方がいい、パスワード入力ダイアログなど試作したコード資産を活かすことができ、ネットワーク通信がパイプでのプロセス間通信に置き換わってバックエンド開発が不要となるので、テストを含めた総工数で見たら手戻り分を加えても想定のスケジュールに収まるのではないか。Safariだとそのままでは動かないが、プロセス間通信の方法が異なる似たような方式を実装できるとの感触を得て、何とかJava不要でInternet Explorerだけでなく、Chrome、Safari、Edgeにも対応したかたちで秋のリリースを迎えることができた。Microsoft Edge対応はChromeやFirefoxへの対応で先行するエストニアよりも半年近く早く実現した。実は技術的にはFirefoxにも対応できたがシェアが1割近くしかなかったのと、当時Firefoxだけが政府認証基盤 (GPKI) のルート証明書を受け入れず、多くの電子政府サイトで警告画面が出てしまう問題があったことから、初期のリリースからは落とした。その後GPKIがWebサーバー証明書を止めることとなったので今年に入ってFirefoxにも対応させた。そんなこんなで2017年秋からマイナポータルは主要なブラウザとAndroidスマートフォンに対応し、最後に残っていたiOSにも2019年秋に対応させたことで、ようやくChrome OSやLinuxデスクトップを除く主要な環境で、ブラウザからマイナンバーカードを使える環境を整備することができた。相変わらずOSやブラウザの仕様変更でちょくちょく動かなくなるが、今ではOSもブラウザもβ版の段階で問題を見つけて、リリース前に改修する体制が整っている。最近だとFirefoxのブラウザ拡張のインストール方法制限の変更に対応したり、年末に向けてApple Silliconで動くMacでも問題なく動くかどうかの調査を指示したところだ。

今日ではいくつかの電子申請システムや民間のサービスがマイナポータルAPを使って様々なブラウザからマイナンバーカードを使っている。残念ながら今も多くの電子申請システムでは引き続きActive Xを使っていて、Internet Explorerからしか使えないサイトも残っている。政府は2019年3月に「政府情報システムにおいてサービス提供の対象とすべき端末環境及びWebブラウザの選定に関する技術レポート」を標準ガイドライン群の一部として公表し、2020年以降も運用する情報システムでInternet Explorer以外のブラウザをサポートすることを求めるようにしたことから、向こう数年で状況は改善することが見込まれる。普通のブラウザに対応するなんてWeb Developerにとっては当たり前のように簡単だと考えられていて、Internet Explorerにしか対応していない政府はどれほど怠慢なのかと怒っている方も少なからずいらっしゃるのではないかと懸念している。縷々ご説明したように頑張れば実現できることではあるのだけれども、少なくともたった3年前の2017年の時点では、本来責任を取るべき構築ベンダーからは見捨てられ、孤軍奮闘して原課が幾通りも方式設計してプロトタイピングを繰り返さない限り実現できない程度に厄介な仕事だったことは書き残しておきたい。