政府CIOポータル標準ガイドライン群
https://cio.go.jp/guides#renkeimodel
行政サービス・データ連携モデル
標準ガイドライン群ID：1016
行政サービス・データ連携モデル（全体編）（β版）2021年6月4日
・・・情報に関わる事業をしている方が、テキストはプレーンテキスト（Windowsのメモ帳など）で良いとコメントされていましたが、アウトラインや目次、改ページ設定を使ったりしないで欲しいと思います。
〔キーワード〕
個人、法人、基本情報、決算情報、財務情報、申請、届出、報告、連絡、通知証明、事例、行政サービス、制度、行政サービス拠点、支援機関、事例、イベント、報告書、会議資料、サービスカタログ、調達、デジタル手続法、ワンスオンリー、ベース・レジストリ
〔概要〕行政機関で個人や法人に関するマスターデータや各種手続に関するシステムを作るときに参照すべき実践的データ連携モデルの全体編。このガイドに従いデータ設計を行うことで、ワンスオンリー、ワンストップ、ベース・レジストリの活用等、他機関とのデータ交換が容易かつ正確に行えるようになり、データ設計に関するコストも削減することができる。
目次
行政機関では多くのデータを管理していますが、そのデータは独自の形式である場合が多く、データの再利用が困難であったり、外部とのデータ連携においても大きな障害になっていたりします。また、データ形式が標準化されていないと、データ連携ができないだけでなく、データの整形に多くのリソースを割くことになり、分析にも支障をきたします。AIやビッグデータの活用が注目されていますが、そのインプットとなるデータが十分に整備されていなければ、目的の結果にたどり着くのが困難になります。
欧州や米国では、行政データの標準化を進めることで、社会全体のデータ標準化につながっていくものと考え、欧州委員会（EC）は、各国の個人、法人、場所情報等が活用できるようにSEMIC[1]という行政データ標準化のプロジェクトを推進しています。米国では同様にNIEM[2]というプロジェクトが進められています。
行政においては、これまでEDINET[3]を通じて上場企業に対してデータの標準化を推進し、法人番号制度の開始と同時に開始した法人情報を収集、公開するgBizINFO[4]は、政府の推進するデータのフレームワークである共通語彙基盤[5]に準拠して開発されています。
デジタル手続法が制定されたこともあり、今後はワンスオンリー、ワンストップの実現が求められてきます。また、社会の基本データとしてのベース・レジストリの整備も進められており、個人、法人、土地の基本データだけでなく、申請情報、資格情報等の社会活動に関連したデータ全体の標準化も必要となっています。
データの標準化は、個人や法人が活動しやすい社会環境を実現するために必須の要素であり、早急な環境整備と普及が望まれています。
個人や法人が活動しやすい社会環境を考える上で、行政機関と社会の間で交換される情報を明確化し体系を整理していきます。
個人に関するデータは、例えば下記のような場面において活用されます。
- 転居、妊娠や出産などの申請について知りたい
- 利用できるイベントや施設について知りたい
- 利用できる支援制度の情報が欲しい
- 相談に行く先が知りたい
このような各場面で利用者が情報を探すためには、各組織からデータを独自の形式で提供するのではなく、比較検討しやすくするために一定の規約に沿った形式でのデータ提供が必要となります。
個人の活動を支えるデータとしては以下のようなものが挙げられます。
・個人基本データ
氏名、住所、世帯等の基本情報
・申請データ
補助金、届出等の各種手続の情報
・・・登記はここ？
・証明書データ
許認可、証明書、通知等の情報
・行政サービス・データ
支援制度、行政サービス案内等の情報
・事例データ
事例集等の事例の情報
・・・判例？
・イベントデータ
展示会やセミナー等のイベントの情報
・行政サービス拠点・支援機関等データ
学校、税務署、保健所等の支援機関の情報
・・・税務署は支援機関？
・報告書・会議資料等データ
調査報告書、レポート等の報告書の情報
また、行政サービスの分類体系でありメニュー体系であるサービスカタログが必要になります。サービスカタログとは、デパートでの「食品」「紳士服」「生活雑貨」のように、行政サービスを整理するときの分類の標準モデルです。欧州では各国横断で行政サービスを検索可能とするように、サービスカタログの開発が積極的に行われています。
企業はライフサイクルの段階に応じて、様々な情報を必要とします。
例えば新しい事業を始めるなら、以下のような情報を集めるでしょう。
- 事業のヒントを得るためのイベント情報や事例情報、報告書情報
- 競合他社や協力企業の候補
- 事業の立ち上げにかかわる手続に関する情報
- 事業の立ち上げにかかわる支援情報
- 相談窓口
また、既存事業を拡大若しくは効率化したいと考える企業も同じような情報を集めるでしょう。
- 事業の着想を得るためのイベントや事例、報告書情報等
- 競合他社や協力企業の候補
- 既存事業の拡大に関する支援情報
- 相談窓口
事業を承継、清算したい企業は、それに関連する以下のような情報を集めるでしょう。
- 譲渡先候補
- 事業承継、清算にかかわる支援情報
- 相談窓口
こうした情報につながる、法人の活動を支えるデータには以下のようなものがあります。
・法人基本データ
法人名、本社所在地等の基本情報
・申請データ
補助金、届出等の各種申請の情報
・財務データ
会計年度ごとの決算の情報
・証明書データ
許認可、証明書、通知、表彰等の情報
・行政サービス・データ
支援制度、行政サービス案内等の情報
・事例データ
事例集等の事例の情報
・イベントデータ
展示会やセミナー等のイベントの情報
・報告書・会議資料等データ
調査報告書、レポート等の報告書の情報
・行政サービス拠点・支援機関等データ
税務署、商工会議所等の支援機関の情報
法人にも、業務の各場面で利用者が情報を探すために、「設備投資」「販路拡大」「雇用・人材」のように、行政サービスを整理するときの分類体系でありメニュー体系であるサービスカタログが必要になります。
個人や法人に関する情報ではありませんが、行政機関の重要な活動として調達があります。調達データの標準は、「行政サービス・データ連携モデル 解説」（標準ガイドライン群ID：1016（2019年（平成31年）3月28日））として公表していましたが、本ガイドの改定に合わせ調達標準も本ガイドに含むこととします。
本データモデルを適用した場合の個人や法人の活動と行政内の活動のイメージは以下の通りです。
図 1 個人の活動のイメージ
図 2 法人の活動のイメージ
このサービスを実現するため、本データモデルは、以下のデータモデル体系で構成します。
図 3 データモデルの全体像
・・・おそらく、私たちがパソコンなどのディスプレイを観たときに、サービスカタログモデルが出てくるのだと思います。
この全体像を効率的に実現するために、共通語彙基盤という政府で推進するデータ連携のための体系をもとに構造化したデータモデルを考えています。
例えば、連絡先を1つのデータ項目で自由記述にしていると、連絡先一覧を作成するようなデータの再利用が難しくなります。部署名、住所、メール等を別々のデータ項目にして、ブロックのように組み合わせることでデータの活用が容易になり、目的に応じた並べ替えや精度の高い検索ができるようになります。
具体的には以下のようにブロックを組み合わせるイメージです。様々な申請・届出データも、あらかじめ準備された基本部品を組み合わせてデータモデルを作っていくことができます。
図 4 データブロックの組み合わせによるデータモデルイメージ
一方、型化されたデータモデルは目的に合わないデータ項目が多くて使いにくいことや、独自データ項目を付け加えたい場合があります。
そこで、実際に導入する際には、目的に合わせて、データモデルをそのまま使ったり、必要な項目だけ部分的に利用（サブセット化）したり、独自ブロックや項目を追加（エクステンション）する等のカスタマイズをすることも可能です。
図 5 データモデルの部分利用や項目追加等のカスタマイズイメージ
・・・住所、氏名、電話番号のゴム印のイメージを持ちます。
カスタマイズで独自のデータ項目を付加した場合には、そのデータ項目は他組織では扱えない可能性があります。データ連携を検討する際には独自のデータ項目を定義している旨、情報提供することが重要です。
データの基本構造
個人に関する情報は、住所などを示す基本情報、法人に関する情報は、法人そのものを表す法人基本情報、それに付随する財務情報が基本となります。
関連情報は類型化することが可能で、「申請・証明系」「ドキュメント系」「施設・イベント系」に分類することができます。
申請、証明系
申請や証明等のデータは、宛先に続き、申請内容や証明事項等の内容のブロックがあり、その後に連絡先と発行者情報のブロックが付く場合が多いです。また、各ブロックの中に個人や法人の情報を含む構造になっています。
・・・不動産、商業法人登記申請は、申請、証明系に分類されそうです。
ドキュメント系
制度や事例などのドキュメントは、表題等の概要の後に内容が続き、法人情報を含む連絡先のブロックで構成されることが多いです。
・・・・ドキュメント系は、官公庁のサイト以外に、どのような場面で利用するのか分かりませんでした。
施設・イベント系
施設やイベントも、表題等の概要の後に内容が続き、法人情報を含む連絡先のブロックで構成される場合が多いです。
・・・イベント系は、引っ越しなどでしょうか。
申請書で入力した内容が、行政手続や内部分析で再利用され、証明書等でさらにデータが再利用される仕組みを目指します。
さらに、公開可能データは、データカタログサイト等で公開をしていきます。
図６ データのライフサイクル
・・・チェック、受領、審査について、勉強・経験する機会があれば良いなと思います。改善と広報と理解できる以外は、外部に漏れない情報だと思うので、どのように管理しているのかは知りたいです。
ワンスオンリーの実現
ワンスオンリーサービスの実現のため、既に登録されている情報があれば、そのデータの活用を検討する必要があります。特に、ベース・レジストリが整備されている分野では、ベース・レジストリのデータを使うことが求められます。
ただし、再利用対象のデータの正確性や最新性に問題があったり、データの取得が困難であったり等の理由で再利用できない場合、クレンジングしたデータを活用する等、別途対応が必要になります。
ワンストップの実現
複数の申請先に提出する必要のある申請をワンストップで行うためには、受付組織から他組織への照会、転送、確認等の処理が必要になります。各機関が独自のデータ形式で照会や転送等を行うと、受け取った側でデータ形式の変換が必要になるため、確認元、確認先の双方の負担になります。また、自動照合等の機械的処理の妨げにもなります。
このような組織間の申請情報や証明情報の連携や交換を円滑に実施できるように標準的なデータモデルを使っていくことが重要になります。
今後、行政機関でベース・レジストリの整備が進んでいきます。ベース・レジストリのデータの基になるのが申請や届出のデータです。
一度登録されたデータは2回目以降の手続では入力不要になるワンスオンリーにより、ベース・レジストリに登録された情報が自動的に申請に転記されます。また、証明データは申請内容との照合が行われます。
ワンスオンリーの実現のために、ベース・レジストリの提供者は、本データモデルに沿ってベース・レジストリを整備するか、本データモデルに合わせたインタフェースを整備することが重要になります。ベース・レジストリ利用者に利便性を提供するのはもちろんのこと、ベース・レジストリ提供者にとっても、データ管理が効率的にすることができます。
また、既存のデータベース等、本データモデルを採用していないベース・レジストリと連携する場合には、コンバータを介してデータ形式を連携可能な形式に変換する場合もあります。
図 7 ベース・レジストリ活用の例
データの設計は、以下の流れになります。
図 8 導入の流れ
１．ニーズ分析
何の目的で、何のためにデータが必要かを精査する。
２．現状データ分析
複数部門の類似データを比較したり、既存データが目的に対して妥当かを確認したりする。
３．テンプレートと比較
本ガイドが提供するデータモデルと比較することでデータの過不足を確認する。役職と氏名を1つのデータ項目にしている等の再利用が困難なデータ項目は、役職と氏名を別のデータ項目に分割することを検討する。
４．不要データの削除、不足データの追加
データ項目の過不足の評価を踏まえ、必要なデータ項目を追加し、不要なデータ項目を削除する。
５．新データモデルで実装
データ定義書を作り、システムを実装する。
新規にシステムを設計する場合には、本ガイドのデータモデルをベースに考えていくことで効率的かつ拡張性、メンテナンス性が高くシステム連携が容易なシステムを構築していくことができます。
図 9 新規システム構築時のイメージ
入力、出力含め、システム全体をデータモデルに沿って構築します。独自データを持つ外部システムと連携する場合には、接続先にデータモデルに沿った形式でのデータの提供を求めますが、自システム若しくは接続先のインタフェース部分の前処理として、データ形式の変換を行うようにし、連携に影響のない仕組みにする必要があります。
メリット
・設計済みのデータモデルを利用するため、データ設計コストを抑えられる
・データモデルによりインタフェースが標準化されるため他のサービスと連携しやすい
・データがモジュール化、標準化されるため、メンテナンス性が高い
・将来のデータ移行も容易である
デメリット
・なし
ただし、超高速処理が必要なシステム等においては、日付の年月を省略し日情報だけで管理する等、システムの目的によっては標準ではないデータを使う場合もある（その場合には、外部との連携処理をする場合にデータを年月日にする等の変換処理をインタフェース部で行う）。
既にシステムがあり、独自データ項目で運用している場合、現在のシステムのデータを本データモデルのデータ形式に置き換えるのはコスト的にも業務的にも負担が大きくなります。現在のシステムの持つインタフェースの外側にデータ形式を変換するインタフェースを整備し、データ形式を整えてシステム連携できるようにしておき、内部システムの標準化はシステム更改等のタイミングで実施するなど中長期で検討を行う必要があります。
図10 既存のシステムへの適用イメージ
メリット
・既存システム自体には手を加えないため、コストや業務面の負担が抑えられる
・インタフェースを介して、連携先に合ったデータ形式に変換されるため他のサービスと連携しやすい
デメリット
・データ形式を変換するインタフェースの整備にコストがかかる
本ガイドでは、システム連携のためのデータモデルを示しています。画面や帳票等ではデータ形式を変換して表示することがあります。
例えば、日付データはシステムには「2019-04-01」で格納し、入出力画面や帳票上では「2019年4月1日」に変換して表示する等、様式や手続等の要件に応じて対応します。
データ項目名も必要に応じて異なる表示をすることがあります。例えば、データ項目名としては「氏名」がよく使われますが、入出力画面や帳票等では「お名前」と表示するなどです。
システムで各種データを扱う前に、文字、日付時刻、住所等の基本データの定義が必要になります。基本的には、文字環境導入実践ガイドブック、行政基本情報データ連携モデル[6]を基にした表記にすることで、様々なシステムとの相互運用性を確保することとなります。
データモデルで使用する文字は、システム間の連携を容易にするため文字環境導入実践ガイドブック[7]に準拠することが重要です。
一般的な情報機器で使用できるJIS X 0213（いわゆるJIS第4水準）の範囲内を使用します。この範囲外の外字については、文字情報技術促進協議会が提供する文字情報基盤縮退マップ[8]で、JIS X 0213の文字に縮退した文字を使います。可読性を高めるために、文字をさらに限定して教員免状のように常用漢字を使用する場合もあります。その場合はその行政手続の規則に従います。
氏名、法人名や地名にはヨミガナを付与します。
氏名、法人名や地名をローマ字表記する場合は、基本的にヘボン式ローマ字を使用します。ただし、従前から慣用的に使われているローマ字などはそのまま使用する場合があります。
数字は基本的に半角数字を使います。
西暦年と月日とします。半角の数字とハイフンのデータとします。曜日はコンピュータが持つカレンダーデータから自動取得できるため省略します。
例： 2019-04-01
画面への表示、印刷で他の形式にしたい場合にはデータを変換して表示、印字します。また曜日を記載したい場合には、データをカレンダーから呼出し、（水）のように日付の後に表示します。
例： 2019年4月1日（月）
期間を表現する場合には１つのデータ項目に「2019-04-01から2019-04-08まで」とするのではなく、開始日「2019-04-01」終了日「2019-04-08」とデータ項目を分けて管理します。
時刻は24時間表記のデータとします。行政データ連携標準を基本とし、半角数字と半角コロンのデータとします。
例： 13:00
時刻に期間がある場合には、日付同様に開始時間「13:00」、終了時間「16:00」とデータ項目を分けて記入します。
コンピュータ処理の中で日付と時刻を1つのデータ項目で扱う場合があります。その場合には、ISOの標準に従い「T」をセパレータとして接続した表記を行います。
例： 2019-06-01T10:00
施設、イベント等では利用可能日を使用します。国際的に、利用可能日を情報提供するのが主流であり、利用日検索の効率化を図るため、休館日等の利用不可日のデータ項目は使わないようにします。
例： 月火木金土日
時期が未定の場合は、該当しそうな月を前広に扱います。例えば桜まつりの場合は、3月、4月が該当するので「3,4」と記入します。季節や旬を表現したい場合には、「行政データ連携モデル（日付及び時刻）」[9]を参照してください。
「金曜日は終了時間が変更」のような特記事項がある場合には、日時備考の項目を設けます。
個人や法人が存在する建物の位置を示すのに「所在地」と「住所」がデータ項目名として使用されますが、所在地は「東京」等のエリアを示す場合があり定義が明確でないため、行政データにおいては「住所」をデータ項目名として使用します。行政データ連携標準（住所）[10]の「3個のデータ項目で管理する場合に準拠します。
住所は、制度上は町名と丁目が一体ですが、丁目以下は漢数字や半角数字などが混在するため、町名までの住所と丁目以下の住所に分割し別々のデータ項目にします。「住所都道府県」は記入又は選択肢で入力し、「住所町名」では郡・市区町村から記入し、丁目以降は省略します。また「住所丁目以下」では半角数字ハイフンつなぎで表記します。
例： 住所 「東京都」「千代田区霞が関」「3-3-1」
ただし、入力時に都道府県を選択した上で市区町村を入力するなどの方法や市区町村コードを利用するなどの工夫は自由にできます。
ビル名等は上記項目とは別途「建物名等」のデータの項目を作り管理します。
例： 建物名等 〇〇ビル９階
郵便番号は、7桁のデータとします。ハイフンは省略します。表示や印字する時には頭に〒を付加して表示します。
例： 郵便番号 1000013
半角で、省略可能な市外局番に（）をつけ、その後の番号はハイフン接続のデータとします。内線、代表等は、電話番号のデータに連続して記入するのではなく、電話番号とは別のデータ項目として管理します。
例： （03)3501-****
１ 基本ブロック
基本情報を組み合わせて定型的に使う基本ブロックの例を示します。
法人情報の基本ブロックは以下の通りになります。
図11 情報の基本ブロック
「氏名」が「氏」と「名」と分離するなどデータ項目は従来に比べて増加していますが、登録済み情報を自動入力したり、審査を自動化したりするための工夫が図られています。
こうすることで、利用者、行政機関の双方の利便性が増し、業務を効率化します。
| 個人番号 | 個人に割り当てられた一意の番号（12桁) |
| 氏 | 個人の氏 |
| 名 | 個人の名 |
| 氏（カナ) | 個人の氏のカナ表記 |
| 名（カナ) | 個人の名のカナ表記 |
| 氏（英字） | 個人の氏の英字表記 |
| 名（英字） | 個人の名の英字表記 |
| 住所都道府県 | 個人の住所の表記（都道府県） |
| 住所町名 | 個人の住所の表記（郡・市区町村から記入し、丁目以下省略） |
| 住所丁目以下 | 個人の住所の表記（丁目以下を半角数字とハイフンで記入） |
| 建物名等 | 個人の住所に建物名等の情報がある場合に使用 |
| 役割 | 代理の場合の、委任先、保護者等の関係性 |
| 氏 | 個人の氏 |
| 名 | 個人の名 |
| 氏（カナ) | 個人の氏のカナ表記 |
| 名（カナ) | 個人の名のカナ表記 |
| 電話番号 | 個人の電話番号（市外局番にカッコをつけ、以降の番号はハイフンで接続。半角） |
| メールアドレス | 連絡先のメールアドレス |
| 住所都道府県 | 個人の住所の表記（都道府県） |
| 住所町名 | 個人の住所の表記（郡・市区町村から記入し、丁目以下省略） |
| 住所丁目以下 | 個人の住所の表記（丁目以下を半角数字とハイフンで記入） |
| 建物名等 | 個人の住所に建物名等の情報がある場合に使用 |
| 郵便番号 | 個人の住所の郵便番号（ハイフンなしの7桁（半角）） |
| 法人番号 | 法人に割り当てられた一意の番号（13桁) |
| 商号又は名称 | 法人の商号又は名称 |
| 商号又は名称（カナ) | 法人の商号又は名称のカナ表記。 株式会社、一般社団法人等の組織種別のカナは省略 |
| 商号又は名称（英字） | 法人の商号又は名称の英字表記 |
| 登記住所都道府県 | 法人登記の所在地の表記（都道府県） |
| 登記住所町名 | 法人登記の所在地の表記（郡・市区町村から記入し、丁目以下省略） |
| 登記住所丁目以下 | 法人登記の所在地の表記（丁目以下を半角数字とハイフンで記入） |
| 登記建物名等 | 法人登記の所在地に建物名等の情報がある場合に使用 |
| 事業所名 | 法人に関する、支店などの名称。本社の場合は、本社とする |
| 事業所住所都道府県 | 法人に関連する、支店などの住所の表記（都道府県） |
| 事業所住所町名 | 法人に関連する、支店などの住所の表記（郡・市区町村から記入し、丁目以下省略） |
| 事業所住所丁目以下 | 法人に関連する、支店などの住所の表記（丁目以下を半角数字とハイフンで記入） |
| 事業所建物名等 | 法人に関連する、支店などの建物名 |
| 事業所郵便番号 | 法人に関連する、支店などの郵便番号（ハイフンなしの7桁（半角）） |
| 役割 | 連絡先の役割 |
| 担当部署 | 担当部署名 |
| 担当者役職 | 担当者の役職 |
| 担当者名の氏 | 担当者の氏 |
| 担当者名の名 | 担当者の名 |
| 担当者名の氏（カナ) | 担当者の氏のカナ表記 |
| 担当者名の名（カナ) | 担当者の名のカナ表記 |
| 電話番号 | 担当部署の電話番号（市外局番にカッコをつけ、以降の番号はハイフンで接続。半角） |
| 内線 | 担当部署の電話番号の内線番号 電話番号に「直通」「代表」と記載したい場合は、この欄に記入 |
| メールアドレス | 連絡先のメールアドレス |
| 住所都道府県 | 連絡先の住所の表記（都道府県） |
| 住所町名 | 連絡先の住所の表記（郡・市区町村から記入し、丁目以下省略） |
| 住所丁目以下 | 連絡先の住所の表記（丁目以下は半角数字とハイフンで記入） |
| 建物名等 | 連絡先の住所に建物名等の情報がある場合に使用 |
| 郵便番号 | 連絡先の郵便番号（ハイフンなしの7桁（半角）） |
| Webフォーム | 連絡先のWebフォームURL |
| 商号又は名称 | 法人の商号又は名称 |
| 商号又は名称（カナ) | 法人の商号又は名称のカナ表記 株式会社、一般社団法人等の組織種別のカナは省略 |
| 商号又は名称（英字） | 法人の商号又は名称の英字表記 |
| 事業所名 | 法人に関する、支店などの名称。本社の場合は、本社とする |
| 事業所住所都道府県 | 法人に関連する、支店などの住所の表記（都道府県） |
| 事業所住所町名 | 法人に関連する、支店などの住所の表記（郡・市区町村から記入し、丁目以下省略） |
| 事業所住所丁目以下 | 法人に関連する、支店などの住所の表記（丁目以下を半角数字とハイフンで記入） |
| 事業所建物名等 | 法人に関連する、支店などの建物名 |
| 事業所郵便番号 | 法人に関連する、支店などの郵便番号（ハイフンなしの７桁（半角）） |
| 担当者部署 | 担当者の部署名 |
| 担当者役職 | 担当者の役職 |
| 担当者名の氏 | 担当者の氏 |
| 担当者名の名 | 担当者の名 |
| タイトル | タイトル |
| サブタイトル | サブタイトル |
| 概要 | 概要（70文字以内） |
| 最終更新日 | 最終更新日（西暦年月日とし、半角数字をハイフンでつなぐ） |
| 産業分類 | 産業分類大分類、可能な場合は中分類 |
２ 留意事項
２.１ 氏名、法人名の漢字表記の扱い
氏名、法人名は、一般の情報機器では扱うことができないJIS X 0213で定められた範囲外の文字（いわゆる外字）で戸籍や登記に登録されていることがあります。政府に登録された正規の表記ですが、既に社会保障・税番号制度の導入に伴い、マイナンバーカードに個人氏名の代替文字が導入され、法人番号公表サイトで法人名の代替文字が提供されています。また、マイナンバーカードには券面入力補助アプリにも代替文字が記録されています。従来の手続と同等の利便性を確保するために、行政サービスや他システム連携データでは、氏名、法人名に代替文字が活用されることがあります。
戸籍や商業登記に基づき登録された文字が法令等に基づき必要な場合には、データ項目に一般の手続に使われる「氏名」の項目と別項目の「戸籍氏名」を設け、商業登記名が必要なときには「法人名」と別項目の「登記名」を設けることで円滑な連携ができるようにするなどの工夫が必要です。
２.２ 氏名、法人名のヨミガナの扱い
氏名や法人名については、法的にはヨミガナが存在しません。しかし、名簿等でのデータのソートは名称の五十音順に行われることが多く、ヨミガナがないと、データのソートや検索に不都合が生じます。
よって、手続では、固有名詞のデータにヨミガナを付与することを基本とします。ヨミガナを付与することでローマ字表記化することも容易になります。
２.３ 本社住所の扱い
本社住所は、商業登記した住所が正式なものです。一方で、変更登記が行われていない法人も多く、住居表示変更等も反映されていない場合もあります。
ワンスオンリー実現の観点から、商業登記した住所を、その後の申請などで使うことが求められていますが、正確な連絡先として使用できない場合があるため、「登記住所」というデータ項目とは別に事業所名「本社」事業所住所「本社住所」と記録できるようにするなどの工夫が必要です。登記変更を促すため申請のデータ項目に追加することで、「登記住所」と「本社住所」が異なる場合に注意を促す運用も可能になります。
・・・事業者情報は、支店・営業所用の情報だと理解していましたが、違うようです。
２.４ 外字の扱い
氏名、法人名、地名等で外字の表示が必須である場合には、コンピュータで処理するデータ項目以外に、外字をイメージで保有する場合があります。その場合にも、データ項目は、JIS X 0213の範囲で運用することが望ましいです。範囲外の文字を使う場合には、連携システムや再利用時の影響評価を実施した上で判断する必要があります。
２.５ 申請者などによる押印の扱い
規制改革推進会議が整理した押印手続の見直しの方針[11]に基づき、押印の必要性を見直します。またデータの真正性証明は、データの場合は電子証明書、サーバーに保存している情報を参照する場合には認証などでのアクセスコントロールで行うことができます。
・・・今まで押印が必要な場面（意思確認）と異なると感じます。
２.６ 公印の扱い
公印に法的な拘束力はありませんが、多くの書類に押印されてきました。書面に印影イメージや「公印省略」を印刷する場合がありますが、証明としての効力は有しないため省略が可能です。BPRの観点から不要な業務プロセスや様式を洗い出し、内部規則などの見直しを図る必要があります。またデータの真正性証明は、データの場合は電子証明書、サーバーに保存している情報を参照する場合には認証などでのアクセスコントロールで行うことができます。
・・・公印省略を省略
[1] https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic
[2] https://www.niem.gov/
[3] https://www.fsa.go.jp/search/20130917.html
[4] https://info.gbiz.go.jp/
[5] https://imi.go.jp/goi/
[6] https://cio.go.jp/guides
[7] https://cio.go.jp/guides
[8] https://moji.or.jp/mojikiban/map
[9] https://cio.go.jp/guides
[10] https://cio.go.jp/guides
[11] https://www8.cao.go.jp/kisei-kaikaku/kisei/imprint/i_index.html
