[キャッチアップ] e-Gov 電子申請 API

だいぶニッチな話だけど、業務で使用しているため、ぼちぼち体系的に理解したく、公式ドキュメントに目を通す。
- e-Gov は色んな事ができるけど、本スクラップではその中の電子申請APIにのみ着目する
- 概念理解が目的なので、ハンズオンは少なめ
- 当たり前だが、具体的なプロダクトに関する話はここでは一切しない

電子申請について
従来、紙によって行われていた行政手続きの申請や届出を、インターネット経由で行えるようにした仕組み。
まぁ今回はそれを API 経由で利用する際の仕組みの話に着目するので、本来の使い方などは割愛する。

電子申請 API について
電子申請では、選択した行政手続について、電子申請を行い、形式チェック後に到達した申請等の事務処理状況を照会します。申請等の結果として公文書が発出された場合、これら公文書を取得できます。また、申請等に関連して行政手数料などの納付が求められる場合、電子納付(情報リンク方式)に必要な情報を取得できます。このほか、電子申請API対象手続の所管行政機関から通知、案内等が発行されている場合、これらの情報を取得できます。
- 申請する
- 申請結果の取得
- 発行された公文書の取得
- 手数料など支払い料リンクの取得
などができる。
利用者認証では、OAuth2及びOpenID Connectに準拠したユーザー認可、アクセストークンの取得/再取得、アクセストークンの検証及び発行済みトークンの無効化が可能です。
らしく、まぁ一般的な API 連携の仕組みに準じてはいそう。

電子申請 API 仕様
意外とモダンに redoc で生成されてる。
これは具体的なエンドポイントごとの仕様レベルの話なので、本スクラップではそこまで踏み込まない。

e-Gov Developer について
- 開発者向けのポータルサイト
- API キーの管理とかもここで行う
- 基本的に電子申請API について調べるときはここから辿れそう
リニューアルされたe-Gov電子申請サービスの機能をAPI経由でフルに活用するには、電子申請APIへの移行が必要です。
電子申請APIは、アカウントの登録とAPIキーの取得によって利用できるようになります。
外部連携APIを利用したソフトウェア等の新規開発申込み受付は、既に終了しており、2024年1月31日をもってサポート終了といたします。
レガシー版もあったみたいだから情報の混在に気をつけようね。

e-Gov アカウントについて
- 電子申請を利用するためには e-Gov アカウントが必要
- 正確には GビズID / Microsoftアカウント といった異なるアカウントで紐付けることも可能
- GビズID は e-Gov に限らず、様々な法人向け行政サービスで利用できるサービス(後述)
- Microsoftアカウントについてはここでは触れない
e-Gov アカウントの新規登録
e-Gov アカウントだけなら個人でも審査なしでもできそう。
2要素認証か秘密の質問が必要らしい。本来は2要素認証使うべきだけど、おそらくまともに使わないアカウントだから秘密の質問で済ませておこう。

GビズID について
- 様々な法人向け行政サービスで利用できるサービス
- 法人及び個人事業主向けの共通認証システム
- GビズID / gBizID 表記ゆれが多いっぽい
- 使えるサービス一覧
- GビズIDには3種類のアカウント体系がある
- プライム
- 会社代表・個人事業主向け
- 書類審査あり
- メンバー
- プライム取得者組織の従業員向け
- 書類審査不要
- エントリー
- 事業してる人なら誰でも取得可能
- 書類審査不要
- プライム
- アカウント体系ごとに利用できるサービスは異なるが、e-Gov についてはいずれも可能

e-Gov API キーについて
- 電子申請 API を使用するために必要となる API キー
- 発行には e-Gov アカウントでのログインが必須
- 当然申請者ごとに API キーは必要
- 実際の API 利用のためには、API キーをもとに認可を受けたアクセストークンを使用する必要がある
- (おそらく) APIキーはソフトウェア単位で、アクセストークンは申請者(ソフトウェアユーザー) 単位で必要
API キー発行のためには法人情報の入力が必要そうだけどテスト用ってことで試しに作成してみる。
xxxxx-yyyyy-zzzz-ffff-fdddd
みたいな形式の API キーが取得できた。このキーに、さっき入力した法人情報が紐づく。

どうやら先に検証環境用のアクセスキーを発行して、それを使ったソフトウェアの最終試験に合格しないと本番環境用は使えないらしい。
ので、本スクラップではもちろんそんなことまでやらないので、このAPIキーというか eGov アカウントごと削除しちゃって検証環境のほうで進めることに。

電子申請 API 利用ガイド
PDF なので雑にポイント抑えていく
- API 利用ソフトウェアを開発するにあたって、まずは検証用 API キーを使用し、検証環境で開発する
- 開発完了後、最終確認試験を申し込み、試験に合格することで本番環境用APIキーを取得できるようになる
- もちろん本スクラップではそこまでのことはしないので、へぇそうなんだレベルの認識で流す
検証環境
(Basic認証の情報はPDF内に記載)こちらで eGov アカウントと API キーを作り直して有効状態になったのを確認。
最終試験の流れとかは今回はどうでも良いのでスキップ。

共通仕様
通信仕様
- IPv4 / IPv6
- HTTP 1.1
- TLS 1.2
- RESTful Web API での提供
API 認可方式
e-Gov アカウントまたは GビズID (or MS アカウント) の利用した、OAuth 2.0 準拠の認可フローを使用する。
- アクセストークンの有効期限は60分
- リフレッシュトークンの有効期限は180日
つまり180日に1回は、API利用ソフトウェアを通じて再認証をする必要がある。
メッセージの基本構造
- 認証・認可情報は HTTP ヘッダで渡す
- リクエスト内容及びバイナリデータは HTTP ボディ (JSON) で渡す
- バイナリデータは BASE64 でテキストデータにエンコードしたものとする
キーとなる番号
- 申請データが e-Gov に到達すると、
到達番号
が付与され、以降申請状況の確認などではこのユニーク番号を使用する - 一つの申請データ内に複数の申請が含まれるケースの場合、それぞれに
送信番号
が付与される- 個々の申請は非同期で形式チェックされ、特段のエラーが検出されなかった場合はそれぞれに
到達番号
も付与される
- 個々の申請は非同期で形式チェックされ、特段のエラーが検出されなかった場合はそれぞれに
- 申請に対する提出先行政機関からの通知については、それぞれに
通知通番
が付与され、これに基づいて通知を取得できる - 行政手続所管府省による案内には
お知らせID
が付与され、お知らせを取得できる
その他
- APIエンドポイントでは、ソフトウェアID + APIキーによる APIクライアント認証が最初に行われる
- API へのリクエストは同時並列処理で対応される
- そのため、送信順が処理順になるとは限らない

データ仕様
データの種別は3つに分けられる
- 申請データ
- 手続きを申請するためのデータ
- 補正データ
- 申請済みの手続きにて、内容の不備などを理由に一部を訂正するためのデータ
- 取り下げ依頼データ
- (取り下げが許容されている手続きについて) 取り出せ依頼を行うためのデータ
いずれもデータ形式に従った複数のファイルをまとめた zip ファイルとする。
データの構成は手続きや署名種別によって様々だが、概ね以下のファイルを含む
-
構成管理情報
: 各構成要素を管理するための管理情報で申請のメタデータや申請書に含まれない利用者情報などを含んだXMLkousei.xml
-
構成情報
: 個別ファイル署名形式の場合にそれぞれの申請に対応する構成管理情報のようなものkousei202001010123456123.xml
-
申請書XML
: 手続きごとの手続内容を含んだ XML999999999999999999_01.xml
-
取り下げ依頼情報
: 取り下げ時に取り下げ対象の申請案件の情報を定義したファイルtorisageirai.xml
- `スキーマ~: 申請書様式の構造を定義するスキーマファイル
999999999999999999schema.xsd
正直わからない単語をわからない単語で説明しているフシがあるけど少しずつ理解していこう。

対象手続き一覧
e-Gov 電子申請 API で申請可能な手続き一覧
申請データ形式と手続きIDをここから確認する。

検証環境用の電子証明書
ダウンロードリンク からダウンロード可能。
ご丁寧に期限切れ・失効済みの証明書まで含まれてて異常系の検証もできるようになってる。
基本的には e-GovEE01_sha2.pfx
を使えば良さそう。

だいたいわかったのでこのぐらいでいいかな。