（別添１）

頁番号

行番号

（別紙１）
要件定義書
P54

項目

第４章
９．継続性に関する事項(１) 継続性に係る目標値

1

４ 作業の実施内容(3) 設計仕様書案P8種類

意 見
記載の目標復旧時間及び目標復旧時点の要件は、類似する他システムと比較しても厳しいご要件と見受けられます。本要件は、コスト面へ大きく影響する可能性があることから、これを考慮した要件の再検討や記述内容の詳細化を行われることが望ま
3 しいと考えます。要件の検討においては、本システムと連携する周辺システムの要件についても考慮する必要があると考えます。また、詳細化においては、例えばAZ障害とリージョン障害、それぞれの場合に分けて記載するといったことが考えられます。
現行の要件定義書を土台としながらも、提案時を含め深堀りや改善を行った上で、システム要件定義書の作成や基本設計・詳細設計を行うという記載とすることが望ましいと考えます。
4回答
理 由
現状の記載内容は、類似する他システムと サービスの特性にあわせ、御指摘のとおり、パイロットライト方式とすることにより、復旧時間お比較しても厳しい要件と見受けられ、コスト面へ大きく影響する可能性があるため。 よび復旧時点に余裕を持たせます。

情報システムの移行において、現行システムからのデータ抽出が必要となる認識だが、当該作業については、現行システムの運用事業者にて4 実施いただけるという理解でよいか、ご回答いただきたい。

作業範囲明確化のため。

現状の仕様書の記載は要件定義書の内容を （別紙１）要件定義書 第１章 2.次期システム導すべて満たすことを求めているようにも読 入の目的に、「要件の充足度や新たな要件等に対めますが、コスト面等を考慮すると構成に して、既存要件の実装優先度については相談のうついて見直しが推奨される点も見受けられ え決める」旨を記載しておりますが、御指摘のとます。構成については事業者ごとの創意工 おり仕様書にも同様の内容を記載いたします。
夫により差が生じうる部分であると想定されるため、左記のような対応が望ましいものと考えます。

2

仕様書案
9-4.(6)（別紙１）要件定義書 第４章 13.移行に関する事項 ア.計画書作成要件 （イ）データ移行に、「現行Gビズインフォの運用・保守事業者と協議の上」と記載をしておりますとおり、必要なデータを提示いただいた上で、運用事業者が抽出する想定です。

3仕様書案
16

-

要員に求める資格において、AWS認定 システムアーキテクチャのモダン化など、 御指摘の資格レベルを要件とすることといたしま
資格が定められていますが、各認定 要求要件をより高度に実現するために、必 す。のレベル（Associate 又は要なスキルレベルであると考えるため。
Professional）については定められ2 ていないため、明示的にProfessionalレベルの認定とするのはいかがでしょうか。

5.(2)

4
3. ヘルプデスク業務
3 (2) 次期活動 概要説明
（TO-BE）

145２ 調達案件
9 21～22（5）末尾に以下の文言を追加いただけないでしょうか？
【追加文言（案）】3 なお、問合せ対応業務の高度化には生成AI技術の活用が有効であることから、AI機能の拡張が容易なサービスを選定することが望ましい。
貴室以外で受入れテストを実施される想定の情報システム利用者について、組織と役割を記載願います。
3

問合せ対応業務の効率化を通じた業務コスト 現時点で当該機能は必須ではないため、仕様書のの削減や顧客満足度の向上を実現する上で、 変更は行いません。
生成AI技術が組み込まれたCRMサービスの活用が効果的であると考えられるため。

受入れテスト計画書作成支援の対象とする組織を明確にするため。

現時点では当室の職員に加え、当省が指定する現行システムのAPIユーザー数名による受入テストの実施を想定しております。

「運用計画」、及び「保守作業計画」に 中長期の計画である「運用・保守作業計画」ついて、年次の計画と理解しておりまとの違いを明確にするため。
す。「運用・保守作業計画」との差別化を図るため、理解に誤りがなければ、年3次の旨を記載願います。

御指摘のとおり、「運用保守作業計画」は中長期を想定した方針的な位置づけであり、単年度計画を想定している「運用計画・保守作業計画」とは異なりますので、納品物名として年次を記載いたします。

受入れテスト支援

6２ 調達案件
13 10～15(12) 成果物

724

９ 不開示情報の取扱いについて4～5「は発注者に対し」の「は」という語句 誤字であるため。
を削除することを提案します。

削除いたします。

設計・構築をR7年度中に完了させるのは システム規模に対し、開発期間が短いと思わ期間的に厳しいのではないか。
れる。品質に問題が出て、後の移行・テスト段階でて戻りの作業が発生する可能性が高くなるのではないか。

事前に複数社に一般論として御意見を聴取したうえで、実施可能な範囲の開発期間であると判断しております。

3(1) 情報管理体制

8仕様書
P8４．（１）作業実施内容の概要

1～1449

要件定義書P6

92．(2)①
データリネージの観点

いつ公開されたデータなのかといったメタ情報を持っていないデータは、メタ情報を持つための仕組みを構築する必要が4 ありますでしょうか。

API連携データにおいて、全件洗い替え登録す 出典元が保有していないメタデータについては、る場合、連携先でいつ公開されたデータなの 公開することはできないため、仕組みを実装するか連携データ自身が持っていない限り分から 必要はございません。ただし、データ構造との関ないので、独自に実装する必要があるため。 係を考慮して、当該メタデータが"ない"ということを公表することはありえます。

インプットされるデータの誤り等を検出して排除したり訂正する必要があります
でしょうか？
4 名寄せ、誤り検出を実施する必要はありませんでしょうか。

現状、gBizINFOにデータ登録する際は、名寄せを実施し、人手、目視による誤り検出を実施しているが、新gBizINFOが受領するデータの品質が不明のため作業実施の必要性が判断できないため。

出典元データのクレンジング（品質確保）するう
えで、誤り等の検出・訂正・排除等の処置は必要だと考えております。

要件定義書P62．(2)14 ②データ構造およびデータマネジメントの刷新

移行する場合は新システムに合わせたデータの移行作業が発生するため。

過去データについては②移行を想定しております。

第2章. 1.(2)ア.
8 現行データの移行方針について現行のGビズインフォに登録されているデータ(届出・認定、表彰、財務、特許、調達、補助金)の扱いはどのようになりますでしょうか。
4 ①削除する
②移行する

10

11

要件定義書
P11

12

要件定義書P11

第2章. 1.(2)ア.
9 「補助金交付情報」の入手方法について「補助金交付情報」については、JJ-Grants、手動以外に取得する方法が存在す
Grantsから取得するデータを主とするこ る場合は対応工数に影響があるため。と。各省庁からの手動データ送付は停止する。
とあるが他の入手方法（手動含めて）存4 在しますでしょうか？
※「調達情報」については、GEPSシステムのAPIから取得する。と明言されていますが、「補助金交付情報」に関してはJ-Grantsを主とするという記述があるため、他のシステムやAPIが存在する可能現状、当室内で実施している各省庁から 省庁、部署数により対応工数に影響があるたの手動データ取得の依頼・受領・整理・ め。
登録を運用作業内で実施すること

13

要件定義書
P11

第2章. 1.(2)イ.各省庁から16 の手動取得データ作業の実
施

要件定義書
P11

第2章（２）
18 イ.各省庁からの手動取得
データ作業の実施

令和７年度においてはjGrantsのみとなりますが、その他の入手方法も調査中であり、令和８年度以降に拡張する可能性はあります。

現状の運用においては、下記機関と連携しており、窓口はそれぞれ１部署です。
内閣官房、内閣法制局、人事院、内閣府、宮内庁、公正取引委員会、警察庁、個人情報保護委員会、金融庁、消費者庁、復興庁、総務省、法務省、外務省、財務省、文部科学省、厚生労働省、農林水産省、国土交通省、環境省、防衛省とありますが、現状手動にてデータ取得を依頼している省庁、部署数をご教示く
4 ださい。

14
各府省からの手動取得データの件数を記 作業規模が不明のため。
載していただけますでしょうか。

令和５年度の実績で18万件程度となります。

415

要件定義書
P1210

第2章. 2.(1) ア. データ
利活用施策（案）

実施内容について不明瞭なため。

DMPベンダーとの調整を前提として、データマーケットプレイス上での当サイト掲載データの公表を想定しております。

実施内容について不明瞭なため。

マーケティング・ユースケースの一例として挙げたものであり、マーケティング施策にかかる具体的な取組内容はプロジェクト内で協議の上決定します。

該当箇所について「公開停止・許諾機能」か
ら「公開停止」と「公開許諾」を対として読み進めていたところ、「非公開」と「不許諾」が併記されており、それらの違いが要件定義書上で読み取れなかったため。

公開停止機能は、既に公開されている自社の情報の公開を停止するものです。
公開許諾/不許諾は、外部から取得するデータについて当該システム上に掲載することを許諾/不許諾する機能のことを指します。
データ出典元によっては、事業者の許諾を受けたデータのみを連携するという運用が想定されるために、データ取得以前に、この機能が必要になります。
具体的なユースケースついては検討を進めている
ところですが、一例として、当室職員がGビズインフォの今後の施策検討において参考とするため、アクセス数やAPIの利用元を分析するといったユースケースを想定しています。

ベンダーなどへのGビズインフォデータの公式登録
4
具体的な登録イメージはありますでしょうか。

16

連携交渉とインセンティブ設計
要件定義書
P12

14

第2章. 2.(1) イ.法人情報の収集施策（案）

17

要件定義書
P23

30

第3章.
1.(2) ア.機能一覧
自社データ公開停止・許諾
機能に提供することで、企業情報の管理と4 ローカルで吸い上げた詳細情報の収集を実現するエコシステム構築 等
具体的な登録イメージはありますでしょうか。
「非公開」と「不許諾」は対象項目のステータスとして異なるものでしょうか。
異なるのであればそれらの違いと対象項目のステータスとして現時点で想定する4 種類についてご教示ください。

18
分析データ作成機能について、現在想定 機能の詳細について不明瞭なため。
しているユースケースがあるかご教示く
ださい。
要件定義書
P25

2

第3章. 1.(2) イ.JoB一覧
分析データ作成機能

419

要件定義書
P30

6第3章.3.
(2)帳票ｲﾒｰｼﾞ

現行の帳票は文字主体の帳票となってい 帳票設計ポリシーの記載から「刷新」がどこますが、「帳票レイアウトを刷新するこ までを期待するのかが不明瞭だったため。と」については、帳票レイアウトに罫線や枠組み、表情報のテーブル形式での表4 示等のデザイン変更を含むものでしょうか。

デザイン変更を含む想定です。

20

要件定義書
P45

第4章 2.(1)ウ.ウ.文字コー
16 ド及び文字の符号化形式の方針

21

要件定義書
P46

第4章 2.(1)ウ.文字コード
4 及び文字の符号化形式の方
針

22

要件定義書
P63

表4-8
2段目 第4章 13.(1)移行に係る作業務移 業区分
行23

4

JIS X 0213:2012の範囲外の文字の入力 縮退先がない文字をカタカナで入力させるこはエラーとし、代替文字で入力するよう とは可能だが、当該箇所をカタカナで出力すに案内すること。代替文字は、国税庁の ることは困難と考えるため。
法人番号サイトで提供する文字とし、JIS X 0213の範囲外であるが、代替文字のない法人名については、当該部分をカタカナで記載すること。という記載がありますが、国税庁においては縮退先がない文字は、「＿（アンダーバー）」に置き換え処理をしています。本システムにおいては当該部分をカタカナで入力してもらう。という認識で正しいでしょうか。
•システム処理で氏名を扱う必要がある 「代替文字の入力を戸籍文字に合わせて行場合には、代替文字の入力を戸籍文字に う」という処理内容が不明瞭であったため。
合わせて行うこと。

縮退マップどおりに戸籍の文字をJIS第4 ４水準に縮退するという認識で正しいでしょうか？
その際、入力は入力者が行い、システムではエラーとする方針で良いでしょうか。
Mailディーラーの問合せ内容を移行す
移行対象のスコープが不明瞭であるため。
る。

24

3

第4章 13.(3)ア.(エ)システ
ム移行

御指摘のとおり、縮退マップ通りにJIS第４水準に縮退する想定です。外字については文字情報基盤（以下URL)に準拠する仕様です。
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/4748d2a445c7-45de-a55fdfac4cb04a70/0e0c8a2c/20230609_local_governme
nts_character_specification_materials_01.pdf
また、入力についての方針についても御指摘のとおりです。
当該サービスの継続利用は必須はせず、問合せに内容等についてシステム上に過去データがある場合移行するという方針です。という記載があるが、現行問合せシステ4 ムのメールディーラの使用を継続するという認識で正しいでしょうか？
それとも移行後の問合せシステムは別途検討し、問合せ内容のみ移行するという意味でしょうか。
GビズインフォへアクセスするためのURL 設計方針やテストに影響があるため。
は現行Gビズインフォと同一のものを利用する想定である

要件定義書
P67

御指摘のとおり、カタカナで出力することは困難なため、当該箇所を削除します。

4 とありますが、トップページだけではなく、各ページのURLも現行のものを利用するという認識で正しいでしょうか。

新規ページについては別途URLが必要だと考えております。既存ページについては特段実装上問題がなければ現行のものを利用する認識です。

要件定義書
P30

第3章
4.APIに関する事項

新バージョンのREST APIを開発、公開し 設計方針やテストに影響があるため。
た場合、現行REST APIは停止する方針でしょうか？それとも現行、新バージョン4 平行稼働する方針でしょうか。

新バージョンのREST APIを公開した場合は、現行のREST APIは停止する方針です。

25
新しいREST APIは現行REST APIとの互換 設計方針やテストに影響があるため。
性を保持する必要はありますでしょうか。
要件定義書
P30

第3章
4.APIに関する事項

互換性を保持する必要があります。

426
令和6年度の成果物として定義される「テスト仕様書」について、令和7年度の納品対象とすることを許容していただ
きたい。

1212

テスト仕様書（ ６年度納品）

27

50 表4-428

要件定義書

令和7年度に実施予定の各種テスト（結合テス 御指摘のとおり、テスト仕様書の納品期限を変更
ト、総合テスト、移行テスト、脆弱性検査します。
等）に関するテスト仕様書を令和6年度中に策定するためには、令和6年度中の開発、単体テストの期間と並行させる必要があるが、作業の平準化を考えた場合は令和7年度に実施する
3方が人員効率が良く、コスト低減が可能となる。また、クリティカルパス上にもなく、令和7年に作成しても全体的なスケジュール遅延の懸念は発生しない。よって、テスト仕様書については、令和7年度の納品とする（もしくはテストごとに令和6年度と令和7年度の分割での納品とする）ことを許容していただきた
可用性要件として、稼働率99.9%が定義 Amazon CloudFrontのサービスレベルアグリー 御指摘のとおり、稼働率の要件を99.5%といたします。
されているが、想定アーキテクチャに含 メント（SLA）で保証されている月間稼働率はまれるAmazon CloudFrontを使用する場 99.9%である。
合、理論的に稼働率99.9%は実現できな 他のAWSサービスを組み合わせると、システムい。
全体の稼働率は99.9%未満となる。
そのため、稼働率の要求を下げることが 従って、Amazon CloudFrontを使用するのであれば、稼働率は99.5%程度としたほうがよいと
1 望ましいと考える。
考える。
参考：https://d1.awsstatic.com/legal/amazoncloudfrontsla/Amazon_CloudFront_Service_Level_Agree
ment_2022-05-22_JA.pdf