#１．はじめに
クラウド人事労務ソフトウェアサービスであるSmartHRに組み込まれているライブラリkijiは、Rubyで作成されたOSSであり、誰でも入手・改造・再頒布が可能です。
SmartHR kiji

本記事では、ライブラリkiji（以下、kiji）を使って署名付きxmlを生成し、curlコマンドでe-Gov電子申請システム（以下、e-Gov）に送信する事を試みます。対話的にe-Govを動かすので、e-Govの仕様を深く理解できると考えています。さらにはe-Govの問題点を定義し、マイナポータルでの改善の可能性について考察します。
なお、ここで動作確認したe-Govとは、ソフトウェア開発事業者向けに公開されている検証環境である点に留意する必要があります。

今回は全４回のうちの１回目として、e-Gov仕様を紹介します。２回目はe-Gov公開資料編、３回目は実行環境構築編、４回目は実機確認編と続きます。

動作環境については、windows10、ruby 2.6.5p114 (2019-10-01 revision 67812) [x64-mingw32]、curl 7.58.0 (x86_64-pc-win32) libcurl/7.58.0 WinSSL zlib/1.2.11です。

#２．想定する読者
次のような読者を想定しています。

ソフトウェアサービスを開発するためにe-Govの仕様を理解したい人
普段から電子申請を利用している人で、e-Govの仕様を理解したい人
xml署名を体験してみたい人
kijiを動かしてみたい人

#３．e-Gov外部連携APIとは
電子申請とは、紙によって行われる申請や届出などの行政手続を、インターネットを利用して自宅や会社のパソコンから行えるようにするものです。e-Govでは、ソフトウェア開発事業者が開発するソフトウェアサービスに対して、各府省が所管する様々な行政手続に関する電子申請を行うための外部連携APIの仕様を公開しています。

e-Govでは、①～④の流れに沿って、手続申請を処理します。このうち、①④についてのAPI仕様が公開の対象となります。
①利用者は、作成済み申請データをe-Govに送信し、到達確認を受ける
②e-Govは、到達済みの申請データを手続所管府省へ送信する
③手続所管府省は、申請データを審査し、その結果をe-Govに登録する
④利用者は、e-Govに照会し、審査結果や公文書データ等を確認する

e-Gov外部連携APIとしては、①利用者ID登録API、②利用者認証API、③各種電子申請処理APIの３つに大きく分類できます。ソフトウェアサービスでは、これらの外部連携APIを組み合わせて呼び出す事で、目的とする申請手続を進める事ができます。

e-Gov外部連携APIを以下に示します。いくつかのAPIについては、実機確認編にてcurlコマンドで動作を確認します。

NO	e-Gov外部連携API	内容	実機確認
1	利用者ID登録	e-Govに利用者IDを登録する	－
2	利用者認証	e-Govにて利用者を認証する	〇
3	一括申請	複数手続をまとめて一括申請する（各手続毎に到達番号が割り振られる）	〇
4	送信案件一覧情報取得	送信案件一覧を取得する	〇
5	申請案件一覧情報取得	申請案件一覧を取得する	－
6	状況照会	指定した到達番号の申請に対して状況を照会する	〇
7	取下げ	指定した到達番号の申請を取り下げる	－
8	補正通知一覧取得	補正通知一覧を取得する	－
9	補正（再提出）	指定した到達番号の申請に対して再提出を行う	－
10	補正（部分補正）	指定した到達番号の申請に対して部分補正を行う	－
11	補正（補正申請）	指定した到達番号の申請に対して補正申請を行う（厚生労働省所管の手続のみ対象）	－
12	公文書・コメント一覧取得	指定した到達番号の申請に対して公文書・コメント一覧を取得する	〇
13	公文書取得	指定した到達番号の申請の公文書をZIP形式にまとめて返す	〇
14	公文書取得完了	e-Govに対して公文書取得完了を通知する	－
15	公文書署名検証	公文書の官職証明書および官職署名を取得する	－
16	コメント通知取得	指定した到達番号の申請のコメント通知を取得する	－
17	コメント通知取得完了	e-Govに対してコメント通知取得完了を通知する	－
18	電子納付対応金融機関一覧取得	国庫金の電子納付が可能な金融機関一覧を取得する	－
19	納付情報一覧取得	指定した到達番号に発行された手数料等の納付情報を取得する	－
20	電子納付金融機関サイト表示	金融機関のネットバンキングに遷移する	－
21	証明書識別情報追加	e-Govに証明書識別情報を追加する	－
22	証明書識別情報更新	e-Govで管理する証明書識別情報を更新する	－
23	証明書識別情報削除	e-Govで管理する証明書識別情報を削除する	－

##３．１利用者ID登録API
利用者IDとは、ソフトウェアサービスを利用して電子申請を行うユーザを一意に識別するためのIDです。e-Govでは、各ユーザについて最初の１回のみ、利用者IDを登録します。

ソフトウェアサービスでは、e-Govに対して、秘密鍵で利用者IDを署名したXMLを送信します。e-Govでは、XML署名の検証を行い、利用者IDと公開鍵証明書の識別情報を対応させて登録します。

##３．２利用者認証API
e-Govでは、各種電子申請処理APIを実行する前に利用者認証を行います。

ソフトウェアサービスでは、秘密鍵で利用者IDを署名したXMLを、e-Govに送信します。e-Govでは、利用者IDがシステムに登録済みであること及び利用者IDと証明書識別情報の対応関係を確認した上で、問題がなければアクセスキーを発行します。

これ以降、ソフトウェアサービスでは、各種電子申請処理APIを呼び出す際、HTTPヘッダ部にアクセスキーを設定する必要があります。アクセスキーには有効期間があり、有効期間を経過してアクセスキーが失効した場合、各種APIへのアクセスが許可されません。この場合、再度、利用者認証を行って、新しいアクセスキーを取得する必要があります。

##３．３各種電子申請処理API
ユーザがソフトウェアサービスを利用して電子申請手続を進めるシナリオを考えた場合、関連するAPIを組み合わせる事で大きく５つに整理できます。

まず、ユーザは一括申請から状況照会を行います。その後、状況照会の結果より、必要に応じて申請の取下げ又は補正を行います。さらに手続審査の進捗が進む事で発出される公文書・コメントを取得します。
上記とは別のタイミングで、ユーザは必要に応じて電子納付利用可能金融機関一覧及び納付情報一覧を取得したり、e-Govに登録されている証明書識別情報の保守を行います。

以上の内容をまとめます。

NO	シナリオ	電子申請処理API
1	一括申請から状況照会まで	一括申請送信案件一覧情報取得申請案件一覧情報取得状況照会
2	申請の取下げ又は補正の実施	取下げ補正（再提出、部分補正、補正申請）
3	公文書・コメントの取得	公文書・コメント一覧取得公文書取得公文書署名検証公文書取得完了コメント通知取得コメント通知取得完了
4	電子納付利用可能金融機関一覧及び納付情報一覧の取得	電子納付利用可能金融機関一覧取得納付情報一覧取得
5	証明書識別情報の保守	証明書識別情報追加証明書識別情報更新証明書識別情報削除

#４．ソフトウェアサービスに求められる情報セキュリティ対策
ソフトウェアサービスは、e-Gov外部連携APIを利用するために、次の情報セキュリティ対策を行う必要があります。

ソフトウェアサービスとe-Govの通信経路については、SSL/TLSで暗号化する
ソフトウェアサービスは、e-Govにて送信者自身の真正性及び送信データ改ざんの有無を確認するため、電子申請で送付する申請データ及び添付ファイルに対してデジタル署名を行い、決められた書式に格納した上で、e-Govに送信する
ソフトウェアサービスでは、ソフトウェアＩＤ、利用者ＩＤ、アクセスキーを暗号化・難読化する
ソフトウェアサービスを利用する際、利用者のアカウント・パスワードによる主体認証を行う
ソフトウェアサービスにて、主体認証情報を保存する場合は、その内容を暗号化する

詳細については、「外部連携API　情報セキュリティ要求仕様書」に記載があります。

#５．e-Govの外部接続インターフェース

e-Govの外部接続インターフェースを入出力という視点から整理します。

分類	内容
入力	各API毎のリクエストURI URIパラメタ（APIバージョン、送信番号、送信期間、到達番号等） HTTPヘッダ（アクセスキー、ソフトウェアID、Basic認証用ID及びパスワード） HTTPリクエストボディ（POSTコマンド時のみ申請データ等を指定）
出力	HTTPレスポンスコード（正常時、エラー発生時） HTTPレスポンスボディ（応答結果XML）

ここでは、入出力データについて整理をした上で、申請データ及び署名付きxmlについて詳細に説明します。

（１）入力

ソフトウェアサービスは、e-Gov外部連携APIを利用するため、各API毎に定められたリクエストURIにアクセスします。リクエストURIにアクセスする際、HTTPヘッダにアクセスキー及びソフトウェアIDを指定します。また、検証環境のみ、Basic認証用ID及びパスワードを合わせて指定します。

POSTコマンドでリクエストURIにアクセスする場合、リクエストのボディ部に申請データ等を指定して送信することで、e-Govに申請手続を依頼する事ができます。申請データとは、申請データセットをe-Govで受付可能な形式に変換したものです。また、GETコマンドでリクエストURIにアクセスする場合、URIパラメタに必要な情報を指定する事で、e-Govから様々な情報を取得する事ができます。

POSTコマンドを利用するe-Gov電子申請APIをまとめます。これらのAPIについては、リクエストのボディ部に①申請データ、②署名付きxml、③その他のいずれかを指定します。

NO	電子申請処理API	申請データ	署名付きxml	その他
1	利用者ID登録	×	〇	×
2	利用者認証	×	〇	×
3	一括申請	〇	×	×
4	取下げ	〇	×	×
5	補正（再提出）	〇	×	×
6	補正（部分補正）	〇	×	×
7	補正（補正申請）	〇	×	×
8	公文書署名検証	×	×	〇
9	電子納付金融機関サイト表示	×	×	〇
10	証明書識別情報追加	×	〇	×
11	証明書識別情報更新	×	〇	×
12	証明書識別情報削除	×	〇	×

（２）出力

e-Govは、ソフトウェアサービスの依頼に対して、レスポンスを返します。レスポンスには、レスポンスコード及びレスポンスボディ（応答結果XML）が含まれます。ソフトウェアサービスは、各APIのレスポンスに応じて後続の処理を行います。

公文書取得API又はコメント取得APIのレスポンスボディ（応答結果XML）の<FileData>タグにはZip形式ファイルをBase64形式でエンコードしたデータが含まれます。これは手続所管府省が発出した公文書又はコメント通知であり、ソフトウェアサービス側でBase64形式でデコードを行い、Zip形式ファイルを解凍して利用者に見せる手段を提供する必要があります。

５．１申請データセット及び申請データ

「申請データセット」とは、構成管理XML、申請書XML、添付ファイルから成るデータセットであり、一括申請、取下げ申請、補正申請で用いられます。

ソフトウェアサービスでは、e-Govで送信者自身の真正性及び送信データ改ざんの有無を確認するため、構成管理XMLに対して署名を行います。さらに、署名が行われた構成管理XML（署名付きxml）を含む申請データセットをzipファイル化してBase64形式にエンコードします。

「申請データ」とは、zipファイルをBase64形式にエンコードした結果をXMLの<FileData>タグに格納したものであり、e-Govが受付可能な形式です。申請データの形式は、各種API毎に定義されています。詳細については、「e-Gov電子申請システム外部連携API　API(Version 1)仕様書」に記載があります。

次に構成管理XML、申請書XML、添付ファイルについて説明します。

（１）構成管理XML

申請書のデータ全体の属性情報を格納する論理単位として、申請書XMLに含まれない申請情報やデータ全体の論理単位の関連などを管理します。

構成管理情報の物理ファイルは「構成管理XML」といい、取下げ依頼以外については、申請データセットに必ず１つ含まれます。

一括申請、取下げ依頼、取下げ申請、補正の各申請毎に構成管理XMLの構造が定義されています。また、後述する個別ファイル署名形式においては、申請書XMLに対する構成管理XML、補正に対する構成管理XML、添付書類に対する構成管理XMLについて、それぞれ構成情報のタグ構造が定義されています。

（２）申請書XML

各行政手続において、申請・届出事項を記入する様式です。e-Govでは、申請・届出事項等を格納するXML様式を「申請書」、その物理ファイルを「申請書XML」といいます。

（３）添付ファイル

各行政手続において、申請・届出事項に応じて申請書に添えて提出することが求められる別添文書です。e-Govでは、申請書に格納しないその他の文書等のことを「添付書類」、その物理ファイルを「添付ファイル」といいます。

５．２署名付きxmlについて

e-Govでは、公開鍵基盤（PKI:Public Key Infrastructure）に基づいて、本人性の確認や文書の改ざんの有無の検知を行うため、ユーザID毎に使用する電子証明書（公開鍵）をユーザIDに紐づけて管理します。そのため、ソフトウェアサービスでは、申請データに対して、ユーザID毎に管理されている電子証明書に対応する秘密鍵を使って署名付きxmlを作成する必要があります。

署名付きxmlとは、xmlファイルに対して電子署名情報を付与したものです。xml署名については、デジタル署名のXML構文を規定するW3C勧告になっています。

電子署名情報とは、①署名値の計算及びダイジェスト計算に使用するアルゴリズムに関する情報、②文書の改ざんを確認するためのハッシュ値、③ハッシュ値に対する電子署名、④電子証明書（公開鍵）です。電子署名情報の形式については、次のとおりです。

Wikiからxml署名の各タグ要素の説明を転載します。e-Govもこの内容に従っています。

SignedInfo要素は署名の対象および使用するアルゴリズムを指定する。SignatureMethodおよびCanonicalizationMethod要素はSignatureValue要素により使用され、改ざんから保護するためにSignedInfoに含まれる。
Reference要素のリストは署名されるリソースをURIで指定する。Transforms要素においてハッシュを計算する前にリソースに対し適用する全ての変換を、(DigestMethod要素において)ダイジェスト(ハッシュ)アルゴリズムを、リソースに対して適用した結果(これはDigestValue要素においてBase64エンコードされている)を指定する。
SignatureValue要素は署名のBase64エンコードされた値である。この値は、SignedInfo要素をCanonicalizationMethod要素で指定されたアルゴリズムによりシリアル化した後の(SignatureMethodの指定により生成される)署名である。(正規化に関する詳細はXML正規化の節を参照のこと)
KeyInfo要素は、署名の受信者に対し署名を検証するのに必要となる鍵を取得できるようにするオプション要素である。一般的には一連のX.509証明書を入れることができる。存在しない場合、受信者はデータの内容から鍵を特定することが求められる。

e-Govの署名付きxmlについては、申請データセットに含まれる署名付きxmlと、HTTPボディ部に直接指定する署名付きxmlの２種類があります。前者は一括申請API等、後者はユーザ登録・認証API等に用いられます。

５．２．１　申請データセットに含まれる署名付きxml

申請データセットに含まれる構成管理XMLに対して署名を付与する場合、①申請データ全体に対する署名を付与する「標準形式」、②申請書・添付ファイルそれぞれに対する署名を付与する「個別ファイル署名形式」の２種類があります。

電子署名情報の形式については、「e-Gov 電子申請システム外部連携 API　申請データ仕様共通データ仕様書」に記載があります。

（１）標準形式

標準形式の申請データは、次の３ファイルから構成されるデータセットです。

構成管理XML（署名情報を含む）
申請書XML
添付書類

これらのファイルは次の関連を持ちます。

ソフトウェアサービスでは、次の手順で署名を行い、申請データを作成します。
①構成管理XMLの構成管理情報からハッシュ値を計算する
②申請書XMLからハッシュ値を計算する
③添付書類からハッシュ値を計算する
④秘密鍵でハッシュ値全体を署名する
⑤秘密鍵に対応する証明書情報（公開鍵）を付与する
⑥データセットをzip形式に固めて、Base64形式でエンコードする
⑦申請データに格納する

e-Govでは、受け取った申請データより、次の手順で本人確認及びデータ改ざんの有無を検証します。
①申請データより、データセットのBase64形式エンコード結果を取り出す
②Base64形式デコードを行い、zip形式のデータセットに変換する
③zipを解凍し、構成管理XMLを取得する
④構成管理XMLの証明書とe-Govで管理する証明書を比較し、送信者の真正性を確認する
⑤署名値を証明書（公開鍵）で復号して、ハッシュ値を取り出す
⑤構成管理XML、申請書XML、添付ファイルについて、それぞれハッシュ値を計算する
⑥ハッシュ値を比較して、一致していればデータ改ざんが無いと判定する

なお、標準形式に対応する申請手続については、以下があります。

雇用保険被保険者資格取得届／電子申請
雇用保険被保険者資格喪失届（離職票交付なし）／電子申請
雇用保険被保険者氏名変更届／電子申請
雇用保険の事業所の各種変更届出／電子申請
保険関係成立（継続）／電子申請
雇用保険の事業所設置の届出／電子申請
健康保険・厚生年金保険被保険者資格取得届、船員保険・厚生年金保険被保険者資格取得届／電子申請
健康保険・厚生年金保険被保険者氏名変更（訂正）届、船員保険・厚生年金保険被保険者氏名変更訂正届／電子申請
健康保険・厚生年金保険事業所関係変更（訂正）届／電子申請
健康保険・厚生年金保険新規適用届、船員保険・厚生年金保険新規適用船舶所有者届／電子申請
健康保険・厚生年金保険適用事業所所在地名称変更（訂正）届（管轄内）（管轄外）、船員保険・厚生年金保険船舶所有者氏名（名称）住所（所在地）変更届（管轄内）（管轄外）／電子申請

（２）個別ファイル署名形式

個別ファイル署名形式の申請データは、以下５ファイルから構成されるデータセットです。

構成管理XML
申請書XML
申請書に対する構成情報XML
添付書類
添付書類に対する構成情報XML

これらのファイルは次の関連を持ちます。

申請書XMLから計算したハッシュ値に対して署名を行い、申請書に対する構成情報XMLに署名値を付加します。また、添付書類から計算したハッシュ値に対して署名を行い、添付書類に対する構成情報XMLに署名値を付加します。標準形式と異なり、構成管理XMLに署名値が存在しません。

ソフトウェアサービスでは、次の手順で署名を行い、申請データを作成します。

①申請書に対する構成情報XMLの構成管理情報からハッシュ値を計算する
②申請書XMLからハッシュ値を計算する
③それぞれのハッシュ値から秘密鍵で署名値を作成する
④秘密鍵に対応する証明書情報（公開鍵）を付与する
⑤添付書類に対する構成情報XMLの構成管理情報からハッシュ値を計算する
⑥添付ファイルからハッシュ値を計算する
⑦それぞれのハッシュ値から秘密鍵で署名値を作成する
⑧秘密鍵に対応する証明書情報（公開鍵）を付与する
⑨データセットをzip形式に固めて、Base64形式でエンコードする
⑩申請データに格納する

e-Govでは、受け取った申請データより、逆の手順で本人確認及びデータ改ざんの有無を検証します。

なお、個別ファイル署名形式に対応する申請手続については、以下があります。「連記式」とは、複数名を記述できる書式です。

保険関係成立（継続）／電子申請
雇用保険被保険者資格取得届（連記式）／電子申請
雇用保険被保険者資格喪失届（連記式）／電子申請
雇用保険被保険者資格喪失届（離職票交付あり）／電子申請
下請負人を事業主とする認可／電子申請
雇用保険被保険者資格喪失届提出後の離職票交付の申請／電子申請
雇用保険高年齢雇用継続給付（高年齢雇用継続基本給付金）の申請／電子申請
健康保険・厚生年金保険被保険者報酬月額算定基礎届（ＣＳＶファイル添付方式）／電子申請
国民年金被保険者資格取得・種別変更・種別確認（第３号被保険者該当）届書／電子申請

５．２．２　HTTPボディ部に直接指定する署名付きxml

利用者ID登録、利用者認証、証明書識別情報追加・更新・削除に係るAPIについては、HTTPボディ部に署名付きxmlを直接指定します。

電子署名情報の形式については、「e-Gov電子申請システム外部連携API　API(Version 1)仕様書」に記載があります。

これらの署名付きxmlは、<ApplData>タグ全体のハッシュ値を計算して、そのハッシュ値に対して署名を行うという点で共通しています。次のような手順で署名情報を付与します。
①<ApplData>タグ全体でハッシュ値を計算する
②ハッシュ値を秘密鍵で署名する
⑤秘密鍵に対応する証明書情報（公開鍵）を付与する

なお、利用者ID登録、利用者認証の場合、<ApplData>タグに公開鍵証明書を指定しません。

#６．電子申請処理の状態遷移について
e-Govでは、申請処理の進捗状況に応じて、メインステートとサブステートに分けて、状態を管理します。

##６．１　メインステート
各手続については、進捗状況に応じて（処理中）→（到達）→（審査中）→（審査終了）→（手続終了）の順に状態が遷移します。

各状態は次の意味があります。

状態名	内容
処理中	申請データに対して、各種チェックを行っている状態
到達	申請データが正常に受付された状態
審査中	申請データに対して、府省側で審査を行っている状態
審査終了	申請データに対する府省側の審査が終了している状態
手続終了	申請データに対する手続が終了している状態

e-Govは、申請データに対して、各種チェックを行います。各種チェックとは、ファイル構成チェック、XMLスキーマチェック、整合性チェック、形式チェックです。問題なければ、（処理中）から（到達）に遷移します。
府省側の審査が始まると、（到達）から（審査中）に遷移します。
府省側の審査が完了すると、（審査中）から（審査終了）に遷移します。
ソフトウェアサービスで公文書を取得した後、e-Govに対して公文書取得完了を通知すると、（審査終了）から（手続終了）に遷移します。

##６．２　サブステート
###（１）取り上げ
（到達）又は（審査中）において、ソフトウェアからe-Govに手続の取り下げを要求すると、サブステートが（なし）→（取下げ処理中）となり、最終的にはメインステート（手続終了）＋サブステート（取下げ済み）となります。

###（２）補正
（審査中）において、手続所管府省より申請データに対して補正指示が出た場合、（サブステート）が（なし）→（補正処理待ち）となります。補正指示の内容に応じて、ソフトウェアサービスは次のように後続するシーケンスを切り分ける必要があります。

補正種別が"再提出"の場合、ソフトウェアサービスが補正（再提出）を要求すると、メインステート（手続終了）＋サブステート（再提出済み）となります。
補正種別が"部分補正"の場合、ソフトウェアサービスが補正（部分補正）を要求すると、サブステート（なし）となります。

以上を状態遷移図に表現します。

次はe-Gov公開資料編に続きます。