開発対象で必要になる認証方式に注意が必要
省庁内部で使うシステムではほとんど気にすることはありませんが、インターネットを経由してアクセスするユーザーが存在するシステムに関しては、それなりの認証基盤が必要となります。2009年前後に作成するシステムでは認証方式が移行時期ということもあり、それを考慮した認証の仕組みを構築する必要があります。2009年以降では政府認証基盤（GKPI）を使用するようになっており、既存システムからの移行などとの絡みも発生するので、認証方式については省庁との協議の上で行うことが肝要となります。
厚生労働省の場合
例えば、厚生労働省認証局からは次のようなお知らせが2008年に行われています。
- ブリッジ認証局との相互認証の解消について
厚生労働省認証局は、平成20年9月22日、政府認証基盤におけるブリッジ認証局との相互認証を解消しました。相互認証解消後は、厚生労働省認証局から発行された証明書は効力を有しません。
2009年以降に構築するシステムには影響がないようにも思えますが、既存システムから新システムにデータを移行する際には、証明書の扱いなどについて省庁と協議し、移行方法などを検討・計画することになります。ちなみに、電子申請に関しては「e-Gov電子申請システム」に移行しました。
社会保険・労働保険関係手続きについては仕様書（「社会保険・労働保険関係手続の電子申請・届出等の仕様」）も公開されており、申請などに使用するXMLのスキーマなどを開発する上で必要な情報を得ることができます。仕様公開の目的は、仕様書に次のように記述されています。
...e-Gov電子申請システムの使い勝手を向上させるための取組の一環として、利用者の方のご意見・ご要望を踏まえ、以下のような考えに基づき、社会保険・労働保険関係手続の電子申請・届出等に係る電子申請システムの仕様を公開することとしました。
- 社会保険労務士等の業務とe-Gov電子申請システムの間をつなぐソフトウェア製品等の開発・提供を促す
- 事業主、社会保険労務士などが、上記ソフトウエア製品などを利用して申請・届出データを一括して送信できるようになり、利用者側の電子申請・届出に係る作業負担の軽減を図る
- オンラインで手続を行う事業主、社会保険労務士などが増加し、オンライン利用率が拡大する
申請のデータ仕様書はもとより、XMLのスキーマなど仕様を公開することで、利用者とe-Gov電子申請システムを連携するソフトウェアの開発・提供を促したことは非常に評価すべき点です。技術編第1回でも紹介しましたが、XMLのスキーマはW3C XML Schemaが必須となることには注意が必要です。
財務省の場合
財務省では、申請の種別により申請方式が異なっています。電子申請の場合は先述の「e-Gov電子申請システム」を、税関手続きの申請の場合は「税関手続申請システム（CuPES）」を使用したりと目的により申請方法が異なるため、同じ省でも複数の認証システムを利用することがあります。
また、新着情報なども常に把握しておく必要があります。最近では、税関手続申請システム（CuPES）の仕様変更が2009年6月1日に行われています。
金融庁の場合
金融庁の場合も「e-Gov電子申請システム」を利用していますが、利用できる認証局の一覧が公開されています。認証局ごとにITベンダーが行う認証局間の手続きが異なるため、入念な確認が必要です。落札前に認証局との接続方法やその基盤を作成するための作業が発生しますが、落札者のみに公開される情報などもあるため、工数が見積もりづらいなどという点がリスクとなります。
同じ届出・申請をインターネットで受けつける時には注意を
同じ届出・申請と言えども、各地方公共団体を経て省庁に提出される場合があるようです。地方自治体経由で省庁に提出される場合は、LGWANという自治体を結ぶLANから霞が関WANへ、さらには各省庁という流れになり、第3者を想定する必要がありませんので、今回の認証基盤とは関係ありません。各地方自治体や省庁とは関係のない第3者がシステムにアクセスするにはインターネットを経由することになります。この場合、従来のユーザーID・パスワード方式に加え、公的個人認証サービスが使用されつつあります。ここでは、以前筆者が利用した公的個人認証サービスについて説明します。
単なる電子証明書と思いきや
住基カードを利用して、パソコンで確定申告書を作成して税務署に提出されている方や、会社のパソコンにログインする際、IDを入力せずに、カードをカードリーダーにかざし、パスワードを入力することでパソコンを利用される方も多いのではないでしょうか。会社のカードは公的個人認証には使用できませんが、住基カードなどの本人確認ができるものについては、市区町村の窓口で電子証明書の手続きを行うことで電子証明書の取得ができます。届出等の提出先に利用申請をすることにより、IDの代わりにカードに格納されているデータ（電子証明書）をもとに届出等の処理をパソコンからインターネットを介して行うことが可能です（ただし、公的個人認証用のカードリーダー・ライターが必要です）。住基カードを基にした認証を「公的個人認証」と呼んでいます。仕組みは電子証明書となんら変わりはありません。ただし、困ったことがあります。それは公的個人認証に関する重要事項は、落札者にのみ渡される点です。
ここで政府認証基盤（GKPI）と公的個人認証サービス（JPKI）との関係が分かりにくくなっているかと思います。これは認証局がさらに上位の認証局を利用しているという連鎖が原因かと思われます。認証局の最上位に位置するものがルート認証局と呼ばれるもので、GKPIや公的個人認証サービス（JPKI）に係る認証局です。お互い、ルート認証局という意味では同じで、対象とするものが異なると考えていただければと思います。
公的個人認証の落とし穴
一見なんともないようなことですが、公的個人認証の場合、次のことは必ず調達仕様書を受け取った後に確認してください。
- 各自治体システムの入力と出力のインターフェースは統一されているか？
特に、出力がCSVやXMLなど異なったフォーマットを使用している場合は、データの移行に関する工数は十分に見ておく必要があります。 - システムで使用しているコードは各都道府県で統一されているか？
コード体系を一致させるという難問題が存在します。 - 自治体内部で独自の機能追加を行っていないか？
独自機能をどう扱うかを提案前に検討する必要があります。全地方自治体の独自機能を盛り込むことは現実的ではありません。
以上のような質問に対し「NO」が返って来た場合、それは単なるシステムの一本化などではなく、システム統合と呼ばれる非常に難しい部類の開発となります。それも47都道府県のシステムの調査が必要となり、データ移行だけでも膨大な工数を要しますので、くれぐれも注意してください。システム統合の意識がなく受注した場合、予算の数倍以上という途方もないコストが発生し、大赤字プロジェクトになるのは必至と考えられます。
さらなる問題が
公的個人認証をクリアしたと思ったら、次なる問題が待っていました。それは利用者が入力したデータに対し電子署名を付加しなければならないという点です。結局選択した技術は、Java AppletとRMIですが、これは想像以上に大変な作業でした。厚生労働省の例でも述べましたが、XMLスキーマを公開どころか作成する時間もなく、非常に保守が難しい作りとなってしまいました。現在、プロトコルとしてRMIは推奨されていないことから考えると、他の方法で実装する必要があります。
教育も忘れずに
電子証明書や電子署名は、やはり根本的な仕組みを理解しないといけません。基盤が提供するクラス群を利用するだけでは、開発の生産性はよくても、間違った使い方をすることも多々あります。公開鍵暗号方式などからじっくりと教育することが肝要で、別のプロジェクトでそのプロジェクトの基盤作りを任されても大丈夫なくらいにしておくと、省庁系システム開発が若干楽になるはずです。自分の知識は惜しみなく後輩に伝えましょう！ ただし、落札者にのみ公開される資料を見せてはいけないことだけは肝に銘じてください。
次回は本編の続きに戻り、省庁系システム開発を成功させるための「開発手法」を紹介します。
