令和8年度防災情報ネットワーク事業システム要件定義書作成業務

令和8年度防災情報ネットワーク事業システム要件定義書作成業務 - 1 -入札公告次のとおり一般競争入札に付します。 令和８年１月13日支出負担行為担当官関東農政局長 菅家 秀人◎調達機関番号 018 ◎所在地番号 11１ 調達内容(1) 品目分類番号 71、27(2) 購入等件名及び数量 令和８年度防災情報ネットワーク事業システム要件定義書作成業務 一式(3) 調達案件の仕様等 入札説明書及び仕様書による。 (4) 履行期間 令和８年４月24日から令和８年10月30日まで。 (5) 履行場所 関東農政局土地改良技術事務所(6) 入札方法 落札者の決定は総合評価落札方式をもって行うので、提案に係る性能、機能、技術等に関する書類(以下「総合評価のための書類」という｡)を提出すること。 なお、- 2 -落札決定に当たっては、入札書に記載された金額に当該金額の10パーセントに相当する額を加算した金額(当該金額に１円未満の端数があるときは、その端数金額を切り捨てるものとする｡)をもって落札価格とするので、入札者は消費税及び地方消費税に係る課税事業者であるか免税事業者であるかを問わず、見積もった契約金額の110分の100に相当する金額を入札書に記載すること。 ２ 競争参加資格(1) 予算決算及び会計令(昭和22年勅令第165号。以下「予決令」という｡)第70条の規定に該当しない者であること。 なお、未成年者、被保佐人又は被補助人であって、契約締結のために必要な同意を得ている者は、同条中、特別の理由がある場合に該当する。 (2) 予決令第71条の規定に該当しない者であること。 (3) 令和７・８・９年度農林水産省競争参加資格(全省庁統一資格)「役務の提供等」にお- 3 -いて、「Ａ」、「Ｂ」、「Ｃ」又は「Ｄ」の等級に格付けされている競争参加有資格者であること。 (4) 関東農政局長から、関東農政局物品の製造契約、物品の購入契約及び役務等契約指名停止等措置要領(平成26年10月２日付け26関総第575号)に基づく指名停止を受けている期間中の者でないこと。 (5) その他の競争参加資格については、入札説明書による。 ３ 入札書の提出場所等(1) 入札書の提出場所 〒330－9722 埼玉県さいたま市中央区新都心２－１さいたま新都心合同庁舎２号館 関東農政局総務部会計課審査係 電話048－740－0328(2) 契約条項を示す場所、入札説明書の交付場所及び問い合わせ先 〒330－9722 埼玉県さいたま市中央区新都心２－１さいたま新都心合同庁舎２号館 関東農政局農村振興部防災課 国営防災係 電話048－740－0565- 4 -(3) 入札説明書の交付方法 上記３の(2)の交付場所及び電子調達システムにて無料で交付する(ただし、上記３の(2)の交付場所の場合は、行政機関の休日に関する法律(昭和63年法律第91号)第１条に定める行政機関の休日を除く。 )。 (4) 入札説明会の日時及び場所 令和８年２月２日午前10時 関東農政局11階第２会議室(5) 入札書の受領期限 令和８年３月５日午後５時までに電子調達システムにて送信若しくは、上記３の(1)の提出場所へ持参又は郵送(書留郵便に限る。)すること。 なお、郵送の場合は同日時、上記３の(1)あてに必着とする。 (6) 開札の日時及び場所 令和８年４月15日午前10時 関東農政局12階入札室４ その他(1) 入札及び契約手続において使用する言語及び通貨 日本語及び日本国通貨。 (2) 入札保証金及び契約保証金 免除。 - 5 -(3) 入札者に要求される事項 この一般競争に参加を希望する者は、封印した入札書に入札説明書で示した競争参加に必要な証明書類を添付して入札書の受領期限までに提出しなければならない。 入札者は、開札日の前日までの間において、支出負担行為担当官から当該証明書類に関し説明を求められた場合は、それに応じなければならない。 当該証明書類に関し説明の義務を履行しない者は落札決定の対象としない。 また、提出された総合評価のための書類を審査した結果、当該案件を履行できると認められた者に限り落札決定の対象とする。 (4) 入札の無効 本公告に示した競争参加資格のない者の入札、申請書又は資料等に虚偽の記載をした者の入札、入札に関する条件及び関東農政局競争契約入札心得第４条の３の規定に違反した者の入札は無効とする。 (5) 契約書の作成の要否 要。 (6) 落札者の決定方法 本公告に示した調達案- 6 -件を履行できると支出負担行為担当官が判断した証明書類を添付して入札書を提出した入札者であって、予決令第79条の規定に基づいて作成された予定価格の制限の範囲内であり、かつ支出負担行為担当官が入札説明書で示す総合評価のための書類の評価項目における技術点の基礎点を満たしている入札者の中から、総合評価の方法をもって落札者を決定する。 ただし、落札者となるべき者の入札価格が予決令第85条に基づく調査基準価格を下回る場合は、予決令第86条に基づく調査を行うものとする。 また、落札者となるべき者の入札価格によっては、その者により当該契約の内容に適合した履行がなされないおそれがあると認められるとき又はその者と契約を締結することが公正な取引の秩序を乱すこととなるおそれがあって著しく不適当であると認められるときは、予定価格の制限の範囲内の価格をもって入札した他の者のうち評価の最も高い者を落札者とすることがある。 - 7 -(7) 手続きにおける交渉の有無 無。 (8) 詳細は入札説明書による。 ５ Summary(1) Official in charge of disbursement ofthe procuring entity : KANKE Hideto, Di-rector General of Kanto Regional Agricu-ltural Administration Office(2) Classification of the services to beprocured : 71, 27(3) Nature and quantity of the services tobe required : Requirements, definitiondocument creation for the Disaster prev-ention information system in the fiscalyear 2026 1 set(4) Fulfillment period : From 24 April,2026 through 30 October, 2026(5) Fulfillment place : The Land Improvem-ent Technique Office in the Kanto Regio-nal Agricultural Administration Office. (6) Qualification for participating in th-- 8 -e tendering procedures : Suppliers elig-ible for participating in the proposedtender are those who shall :① not come under Article 7O of the Ca-binet Order concerning the Budget, A-uditing and Accounting. Furthermore,minors, Person under Conservatorshipor Person under Assistance that obta-ined the consent necessary for concl-uding a contract may be applicable u-nder cases of special reasons withinthe said clause. ② not come under Article 71 of the Ca-binet Order concerning the Budget, A-uditing and Accounting. ③ have the Grade "A","B","C" or "D" interms of qualification "Provision ofservices" for participating in tende-rs by Ministry of Agriculture, Fores-try and Fisheries (Single qualificat-- 9 -ion for every ministry and agency) inthe fiscal year 2025, 2026 and 2027. ④ Prove not to be a period of receivi-ng nomination stop from the contracti-ng officer etc. ⑤ meet the other qualification requir-ements by the tender documentation. (7) Time limit for tender : 5:00 P.M., 5March, 2026 (tenders submitted by mail :5:00 P.M., 5 March, 2026)(8) Contact point for the notice : Disast-er Prevention and Restoration Section,Disaster Prevention and Restoration Div-ision, Rural Policy Promotion Departmen-t, Kanto Regional Agricultural Administ-ration Office, 2－1 Shintoshin Chuoku S-aitama city Saitama prefecture 330－9722Japan. TEL 048－740－0565 令和８年度防災情報ネットワーク事業システム要件定義書作成業務仕様書(案)農林水産省 関東農政局i目 次第1章 総 則.. 1第1-1 調達件名.. 1第1-2 調達背景.. 1第1-3 調達目的及び調達の期待する効果.. 1第1-4 調達範囲.. 1第2章 作業概要.. 1第2-1 作業概要.. 1第2-2 スケジュール.. 2第3章 防災情報ネットワークシステムの概要.. 2第3-1 システムの概要.. 2第3-2 現状の課題.. 2第4章 作業条件.. 3第4-1 業務実施場所等.. 3第4-2 新システムのクラウドサービス環境.. 3第4-3 使用する機器等.. 3第4-4 情報セキュリティ.. 3第4-5 業務責任者及び業務担当者等.. 4第4-6 提出書類.. 5第4-7 業務実施計画書の作成.. 5第4-8 制限事項.. 6第4-9 調達案件及び関連調達案件の調達単位、調達方式等.. 6第4-10 作業の実施体制・方法.. 8第4-11 情報資産管理標準シートへの情報提供.. 9第4-12 クラウドサービス利用時の情報システムの保護に関する事項.. 9第5章 業務実施内容.. 9第5-1 業務内容.. 9第5-2 業務実施に当たっての留意点.. 11第6章 貸与資料等.. 13第6-1 貸与資料.. 13第7章 成果物.. 15第7-1 成果物.. 15第7-2 成果物の納品方法等.. 16第8章 入札参加資格に関する事項.. 18第8-1 競争参加資格.. 18第8-2 公的な資格や認証等の取得.. 18第8-3 受注実績等.. 18第8-4 複数事業者による共同入札.. 18第8-5 入札制限.. 19ii第9章 契約変更.. 19第10章 再請負に関する事項.. 19第11章 環境関係法令等の遵守.. 20第11-1 環境法令の遵守.. 20第11-2 環境負荷低減に係る遵守事項.. 20第11-3 行政の進化と革新のための生成AIの調達・利活用に係るガイドラインへの対応.. 20第11-４ IT調達に係る国の物品等又は役務の調達方針及び調達手続に関する申合せ.. 21第12章 定めなき事項.. 211第1章 総 則第1-1 調達件名令和８年度 防災情報ネットワーク事業システム要件定義書作成業務第1-2 調達背景現行の国営造成土地改良施設防災情報ネットワークシステム(以下「現行システム」という。)は、国営造成土地改良施設の有する水位等の観測情報や気象情報を迅速に収集、伝達、蓄積及び分析整理するためのシステムとして平成 21 年度に開発したものであり、令和７年度にリホストによるクラウド移行を行ったところである。 しかしながら、オンプレミスサーバー時のシステム構成を踏襲したことによりクラウドの特性を十分に活用できておらず、情報セキュリティの確保やシステムの運用・保守に要する年間費用について課題を抱えている。 また、現行システムが抱えるデータ容量等の制限の最適化や、最新デバイスに適応した閲覧情報の改良など、ユーザビリティを向上させるための改善が求められている。 このため、現行システムを刷新し、新たな防災情報ネットワークシステム(以下「新システム」という。)を構築する必要があり、本業務は新システムの要件定義書を作成するものである。 平成30年６月には、「政府情報システムにおけるクラウドサービスの利用に係る基本方針」が決定(最終改定は、令和７年５月27日)された。 この中で、「クラウド・バイ・デフォルトの原則」が政府方針として出されている。 これらの状況を踏まえ、本システムはパブリッククラウドを利用する。 第1-3 調達目的及び調達の期待する効果本業務は、現行システムで課題となっている機能や、新たに活用したい機能の要件を整理し、優先順位を付けて新システムの要件定義書を作成することを目的とする。 これにより、システムのクラウドネイティブ化に伴う情報セキュリティの向上及び運用コストの低減並びに操作性・利便性の向上が図られるほか、将来の改修が容易となる新システムの構築が可能となる。 第1-4 調達範囲本調達では、新システムに係る要件定義書一式を作成する業務を行うものとし、受注者の責任範囲は、必要機能の整理から要件定義書一式の作成までの一連の要件定義全てとする。 なお、上記は責任分界の基本である。 責任範囲の調整が必要となった場合には、発注者と協議の上、決定することとする。 第2章 作業概要第2-1 作業概要主な作業概要は以下のとおりであり、詳細な作業内容は第5章に示す。 (1) 業務実施計画書の作成(2) 現状の調査及び課題整理(3) 要件定義書一式の作成2(4) 設計・開発及び運用・保守に係る概算費用(5) 定例会(6) 業務結果報告書の作成第2-2 スケジュール本業務の期間は、令和8年4月24日から令和8年10月30日とし、発注者が想定している作業スケジュール(案)は図１のとおりである。 主なマイルストーンは(2)現状の調査及び課題整理の取りまとめ時点及び(3)要件定義書一式の作成に関する中間報告時点である７月中に設定する。 なお、本業務の対応は、土曜、日曜、国民の祝日に関する法律(昭和23年法律第178条)に規定する休日及び年末年始(令和8年12月29日から令和9年1月3日)を除く8時30分から17時15分を原則とするが、システム障害などの緊急時の対応は、監督職員の指示により、上記時間外に実施する場合がある。 作業概要2026年(R8) 2027年(R9)備考4 5 6 7 8 9 10 11 12 1 2 3(1)業務実施計画書の作成(2)現状の調査及び課題整理(3)要件定義書一式の作成(4)設計・開発及び運用・保守に係わる概算費用(5)定例会(6)業務結果報告書の作成※関連スケジュール設計・開発業務(R9年度予定)図１ 作業スケジュール(案)第3章 防災情報ネットワークシステムの概要第3-1 システムの概要防災情報ネットワークシステムは、別紙１「防災情報ネットワーク対象地区一覧表」に示すとおり、令和７年３月時点で185地区において運用されている。 現行システムの利用環境は別紙３「システム利用環境等」に示すとおりであり、(別図１)「現行の国営造成土地改良施設防災情報ネットワークシステム概念図」及び(別図２)「現行の国営造成土地改良施設防災情報ネットワークシステム機器構成図」により、気象情報提供者から調達する気象情報を取り込むほか、全国の各国営事業地区の中央管理所で個別に開発導入されたデータ転送システムを通じて、中央管理所の計測情報・状態監視情報を取り込み、利用者に提供するとともに、内閣府が運用する総合防災情報システムに情報提供している。 新システムでは、システムのクラウドネイティブ化を図り、ガバメントクラウドで稼働する環境に移行する。 第3-2 現状の課題現行システムの操作性・利便性に関する内容において、現状抱えている課題として把握している内容は以下のとおり。 (1)機能上の課題①現行システムのメール配信登録は１件ずつ入力する必要があるが、入力ミス防止の観点から外部見積依頼 調達仕様書等作成 調達手続きマイルストーン3メールサービスを併用しており、クラウドシステム上のメールサービスとの一貫性がない。 ②ブラウザバックによる戻る操作により、表示エラーが頻繁に発生し作業が中断される。 ③スマートフォン等の最新デバイスでの操作閲覧が困難。 (2)非機能上の課題①観測値をダウンロードする際、データ量が大きい場合にダウンロードエラーが生じるため、ユーザー側でダウンロードサイズを想定した観測期間等の設定を試行する必要がある(性能)。 ②オンプレミスサーバー時のシステムでは、サーバ容量等から登録地区数を制限していたが、現行システムでも登録地区数の制限が踏襲されている(拡張性)。 ③バックアップシステムへの切替え・切戻し作業において、現行システムでは切替え開始後３営業日間の時間を要している(継続性)。 第4章 作業条件第4-1 業務実施場所等本業務は原則として受注者側拠点で行うものとする。 本業務の作業場所及び作業に当たり必要となる設備、備品、消耗品等については、受注者の責任において用意すること。 また、必要に応じて担当職員が現地確認を実施することができるものとする。 第4-2 新システムのクラウドサービス環境新システムで用いるクラウドサービスはガバメントクラウドとする。 ガバメントクラウドの詳細は、デジタル庁HPのGCAS Guide(https://guide.gcas.cloud.go.jp/)を参照すること。 ガバメントクラウドのクラウドサービスプロバイダーは、AWS、Azure、Google cloud、Oracle Cloud の４種類である。 なお、現行システムのクラウドサービス環境はAmazon Web Services(以下「AWS」という。)東京リージョンを基盤(2AZ(アベイラビリティゾーン)構成)であり、クラウド構成図は、別紙３のとおりである。 第4-3 使用する機器等受注者側の拠点において本業務を実施するための機器、ＯＳ、開発ツール等の環境は受注者によって整備するものとする。 第4-4 情報セキュリティ(1) 受注者は、別に貸与する「農林水産省における情報セキュリティの確保に関する規則」(平成27年3月31日農林水産省訓令第４号)及び「国営造成土地改良施設防災情報ネットワークシステムのセキュリティ確保について(案)」に記載された関連項目を遵守し業務を実施しなければならない。 なお、「農林水産省における情報セキュリティの確保に関する規則」及び「国営造成土地改良施設防災情報ネットワークシステムのセキュリティ確保について (案)」が改定された場合には、それらに基づき実施すること。 (2) 別紙４「情報セキュリティの確保に関する共通基本仕様」に基づき作業を行うこと。 なお、「情報セキュリティの確保に関する共通基本仕様」が改定された場合には、それらに基づき実施すること。 (3) 本業務の実施に当たっては、セキュリティ上問題となりうるおそれのあるソフトウェアを使用してはならない。 4(4) 本業務で使用する全ての情報に関して、アクセス制限を明確にしなければならない。 (5) 本業務で知り得た情報は、業務の遂行に使用する以外に使用し、又は提供してはならない。 (6) 業務を行う上で預託した情報については、業務完了時に返還(又は廃棄)しなければならない。 (7) 監督職員の求めに応じ、情報の管理状況について報告又は監査することを許諾すること。 (8) 業務実施期間中に情報セキュリティに関わる事項に違反した場合は、契約を打ち切り損害賠償の請求を行うことがある。 (9) 受注者は本業務で、システムの設置場所へ機器の搬入出を行う場合には、監督職員の立会いのもと行うと共に、内容の確認を受けなければならない。 (10) 本業務に従事する全ての者に対して、退職後も有効な守秘義務契約を個別に締結すること。 (11) マニュアル類は定められた場所に保管し、業務を遂行するに当たり知り得た情報は第三者に漏らしてはならないものとする。 業務において知り得た情報の漏洩等の事案が発生した際には、発注者に電話、口頭等による報告を行うとともに、書面にて提出すること。 なお、事案の発生後は事態の収拾及び拡大防止の措置を迅速かつ適切に行うこと。 (12) 「農林水産省における情報セキュリティの確保に関する規則」は、政府機関等の情報セキュリティ対策のための統一基準群(以下「統一基準群」という。)に準拠することとされていることから、受注者は、統一基準群の改定を踏まえて規則が改正された場合には、本業務に関する影響分析を行うこと。 また、適切な措置が講じられていることを確認するため、遵守状況の報告を求めることや、必要に応じて発注者による実地調査が実施できること。 (13) 生成 AI システム特有のリスクケース等が発生した場合、受注者は関係するデータの提供、調査等に協力すること。 (14) 本業務の開発・運用において、ソースコード解析やソースコード生成、ソースコードの管理を行う際には、セキュリティ・バイ・デザイン(DS-200)を元に、情報セキュリティ対策の責任者を定め、開発環境や開発工程等も含めたすべてのライフサイクルに対してぬけ漏れなく情報セキュリティ対策を実行すること。 (15) クラウドアーキテクストのベストプラクティス(AWS の場合 Well-Architected Framework、Azure の場合 Azure Well-Architected Framework、Google Cloudの場合 Google Cloud ArchitectureFramework、Oracleの場合 Well-architected framework for Oracle Cloud Infrastructure)及び「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル 別冊クラウド設計・開発編」に準拠すること。 (16)以下の現行システムのセキュリティ対策要件を参照し、システムのセキュリティ対策要件を点検すること。 ・AWS設定確認リスト(別紙５)・Webシステム／Webアプリケーションセキュリティ要件書(別紙６)第4-5 業務責任者及び業務担当者等(1) 受注者は本業務の実施に当たり業務責任者、チームリーダー及び業務担当者を定め、発注者に通知するものとする。 また、業務責任者を変更するときは発注者の承認を得ること。 (2) 受注者は、本業務の業務責任者及び担当者等の役割に応じて次に示すスキル・経験を持つ人員を充て、プロジェクト全体として全ての要件を満たす作業実施体制とすること。 (3) 業務責任者は契約図書等に基づき、業務の技術上の管理及び統轄を行うものとする。 (4) 業務責任者は、情報処理技術者試験のうちプロジェクトマネージャ試験の合格者、PMI本部が認5定するＰＭＰ資格又は技術士(情報工学部門又は総合技術監理部門(情報工学を選択科目とする者))の資格を有すること。 ただし、当該資格保有者等と同等の能力を有することが経歴等において明らかな者については、これを認める場合がある(その根拠を明確に示し、農林水産省の理解を得ること)。 なお、業務期間中に業務責任者を専任で支援する要員が保有していることでも可とする。 (5) 業務責任者及び業務担当者は、情報ネットワークのシステム構築業務又はシステム改良業務などの経験を１件以上有するものとする。 (6)チームリーダー及び業務担当者は以下の資格を有するものを含めること。 チームリーダーは、パブリッククラウドに係る全ての技術領域において当該提案予定のクラウドサービスプロバイダーの認定技術者としての上級資格[*1]を有する者を1 名以上配置すること。 なお、チームリーダーの資格はパブリッククラウド上での情報システム構築期間中に専任でチームリーダーを支援する要員が保有していることでも可とする。 または、クラウドサービスプロバイダーが提供するサポートサービス(AWS プロフェッショナルサービス、Azure 有償サポート、PSO プロフェッショナルサービス、Oracle プロフェッショナルサービス)の利用での対応も可とする。 業務担当者は、パブリッククラウドに係る全ての技術領域において当該クラウドサービスプロバイダーの認定技術者としての中級資格[*2]以上を有する者を1名以上配置すること。 例として、以下のような資格が挙げられる。 *1 AWS Certified Solutions Architect - Professional / Microsoft Certified: Azure SolutionsArchitect Expert / Google Cloud Professional Cloud Architect / Oracle CloudInfrastructure 2024 Certified Architect Professional*2 AWS Certified Solutions Architect - Associate / Microsoft Certified:Azure AdministratorAssociate Google Cloud Associate Cloud Engineer / Oracle Cloud Infrastructure 2024Certified Architect Associate(7) 本業務を行う担当者は、業務を効率的、効果的に推進するために求められる業務遂行能力を有すること。 ・情報や意見を的確に交換できるコミュニケーション能力・課題・改善点を識別し、改善する能力・担当する職務に応じた技術力(クラウド業務を実施する場合は、AWS等のスキル)(8) 本仕様書に記載されている監督職員との協議事項等を業務責任者に委任しない場合は、書面により発注者に報告しなければならない。 第4-6 提出書類受注者は、発注者が指定した様式により、契約締結後に本仕様書及び契約書類に示す書類について、監督職員を経て発注者に遅延無く提出しなければならない。 受注者が発注者に提出する書類で様式が定められていないものは、受注者において様式を定め、提出するものとする。 ただし、発注者がその様式を指示した場合は、これに従わなければならない。 第4-7 業務実施計画書の作成(1) 受注者は、契約締結後14日以内に業務実施計画書及び業務実施要領の案を作成し、監督職員の承認を受けること。 6なお、業務実施計画書及び業務実施要領の記載内容は、「デジタル・ガバメント推進標準ガイドライン」(以下「標準ガイドライン」という。)「第７章設計・開発」で定義されている事項を踏まえ、以下の内容を記述し、作業実施計画書の内容に変更の必要が生じた場合は、変更の理由及び変更内容とともに修正された作業実施計画書を担当部署に書面にて届け出て承認を得ること。 また、標準ガイドラインの改定があった場合には、これに対応すること。 また、受注者は、承認を得た作業実施計画書に基づき、本業務に係るコミュニケーション管理、体制管理、作業管理、リスク管理、課題管理、システム構成管理、変更管理、情報セキュリティ対策を行うこと。 ① 全体スケジュール(作業工程名、各作業工程の実施内容、実施期間、作業担当、各作業工程の完了条件を含む。)② WBS及び詳細スケジュール(作成したWBSを元に、各作業の関連性(作業間の依存関係が明確になるようにスケジュールをガントチャートとして記述し、明確にすること。)、作業担当、開始・完了日等の制約、各作業項目の作業内容と成果物の関係を踏まえ整理するもの。 )③ プロジェクト体制図(要員数、要員の経験・スキル、連絡先、作業計画と要員配置との対応関係も含む。)④ 会議体ルール⑤ 要件定義手法⑥ コミュニケーション管理(手段、様式を含む。)⑦ 本業務の成果物を詳細に定義したドキュメント体系⑧ ドキュメント管理(採番ルール、版数管理を含む。)⑨ 情報セキュリティ管理(委託先等を含む。)⑩ 作業体制の管理手法⑪ 品質管理、品質基準の設定⑫ リスク管理⑬ 課題管理⑭ 変更管理⑮ その他(実施における前提条件、時間、予算等の制約条件等)(2) 受注者は、業務計画書の内容を変更する場合には、監督職員に了解を得ることとし、重要な内容の変更をする場合には、その都度監督職員に変更業務計画書を提出しなければならない。 (3) 受注者は、監督職員が指示した事項については、さらに詳細な業務実施計画書に係る資料を提出しなければならない。 第4-8 制限事項本業務を遂行するにあたり、知り得た情報は外部に漏らしてはならない。 第4-9 調達案件及び関連調達案件の調達単位、調達方式等本調達案件及び関連する調達案件の調達単位、調達方式、実施時期等は表1のとおりである。 表１ 関連する調達案件7No 調達案件名(予定)調達の方式 実施時期(予定)又は受注者名1防災情報ネットワーク事業システム要件定義書作成業務(本業務)一般競争入札(総合評価落札方式)入札公告：R8.1月頃※調整中落札者決定：R8.4月頃2防災情報ネットワーク事業システム運用・保守・クラウドサービス提供業務(履行期間R8.4.1-R9.3.31予定)一般競争入札(総合評価落札方式)入札公告：R7.12月頃落札者決定：R8.3月頃3防災情報ネットワーク事業気象情報利用業務(履行期間R8.4.1-R9.3.31予定)一般競争入札(最低価格落札方式)入札公告：R8.3月頃落札者決定：R8.3月頃また、表１に示す調達案件以外の関連業務が発生した場合、関連業務契約の都度、監督職員より通知するものとする。 8PMO本省内閣府デジタル庁本業務受注者業務責任者チームリーダー業務担当者気象情報提供業者連絡・相談連絡・調整支援第4-10 作業の実施体制・方法本件受注者に求める作業実施体制は図２及び表２のとおりである。 なお、受注者内のチーム編成については想定であり、受注者決定後に協議の上見直しを行うが、業務実施にあたり、別途契約の受注者の協力が必要な場合は、発注者が受注者間の調整を行う。 また、受注者の情報セキュリティ対策の管理体制については、作業実施体制とは別に作成すること。 図２ 作業実施体制表２ 組織または要員の役割No 組織または要員 役 割1 担当部署 防災情報ネットワークシステムの管理組織として、本業務の進捗等を管理する。 2 本業務受注者 本業務を実施する。 3 現行システム運用・保守事業者 現行システムの運用保守を行う。 4 気象情報提供業者 防災情報ネットワークシステムへ気象データの提供を行う。 5 内閣府総合防災情報システム担当課 総合防災情報システムと防災情報ネットワークシステム間の情報連携に当たり、担当部署と調整、情報共有等を行う。 6 PMO 農林水産省の全体管理組織。 クラウド利用を含む情報システムに関する各PJMOからの問い合わせを受け、対応、助言・指導等を行う。 7 MAFFクラウドCoE 担当部署・受注者に対してパブリッククラウド全般及びMAFFクラウド利用に係る技術的な支援を行う。 利用システムに対して、全体クラウドCoE から提示された方針や基準を実施できるように支援を行う。 本システム関係者・関係事業者農林水産省現行システム運用・保守事業者土技所PJMO指導・助言(発注者)MAFFクラウドCoE9No 組織または要員 役 割8 デジタル庁 ガバメントクラウドの所管組織。 全体クラウドCoEとして、以下の3つの役割を担う。 ・ガバメントクラウドの方針や基準等の戦略を立案し、各府省クラウドCoEに提示を行う。 ・政策優先度の高いプロジェクトに対して、ガバメントクラウドの方針や基準を実施できるように支援を行う。 ・各府省クラウドCoE体制不足時の支援を行う。 9 業務責任者 本業務全体を統括し、必要な意思決定を行う。 また、各関連する組織・部門とのコミュニケーション窓口を担う。 10 チームリーダー 作業状況の監視・監督を担う。 11 業務担当者 要件定義の作業を担当する。 第4-11 情報資産管理標準シートへの情報提供(1) 受注者は、標準ガイドラインの「別紙３ 調達仕様書に盛り込むべき情報資産管理標準シートの提出等に関する作業内容」に基づく情報資産管理を行うために必要な事項を記載した情報資産管理標準シートを提出すること。 (2) 受注者は、標準ガイドラインの「別紙２ 情報システムの経費区分」に基づき区分等した契約金額の内訳が記載されたエクセルの電子データを契約締結後速やかに提出すること。 なお、人件費については人件費単価ごとに工数を提示すること。 再委託先がある場合は再委託先の法人番号と再委託金額を提示すること。 最大何次請負、再委託総額、累計契約額(前年度まで)、年度契約金額を提示すること。 第4-12 クラウドサービス利用時の情報システムの保護に関する事項(1) 情報システム、情報システムで取り扱うデータ等の情報資産の所有権その他の権利がクラウドサービスプロバイダーに帰属せず、また、発注者からクラウドサービスプロバイダーに移転されるものでないこと。 (2) クラウドサービスの利用にあたり、情報資産が漏えいすることがないよう、必要な措置を講じること。 (3) 現在利用しているクラウドサービスの解約に伴うデータの削除については、クラウドサービスプロバイダーが定めるデータ消去の方法で、データ削除し、削除したことを証明する資料を提出すること。 なお、クラウドサービスの契約を移管する場合は当たらない。 第5章 業務実施内容第5-1 業務内容本業務における業務内容は以下のとおりである。 (1) 現状の調査及び課題整理1) 現行システムの現状・課題の整理受注者は、発注者が提供する現行システムの操作マニュアル、各種設計書等の既存資料の情報や利用者の要望事項を基に本システムの現状と課題を把握し、整理する。 10なお、本作業においては、課題の詳細を把握するため、現行システム利用者(５団体程度)へのヒアリングを実施する。 2) 課題に対する対応方針の検討受注者は、上記1)で整理した現状と課題を踏まえ、それぞれの課題への対応方針を検討する。 3) 検討結果の取りまとめ受注者は、上記 1)～2)の整理及び検討結果をもとに、課題改善後の新たな業務フロー図及びシステム化範囲等を検討し、要件定義書一式の基礎資料となるよう取りまとめる。 (2) 要件定義書一式の作成受注者は、上記(1) の結果を基に、新システムに必要な要件(業務要件、機能要件、非機能要件)について検討する。 本業務において検討したリファレンスアーキテクチャによる実装方式は、発注者と協議の上、決定する。 また、必要に応じMAFFクラウドCoEと事前協議すること。 これらの結果を要件定義書一式として取りまとめ具体的な内容を記載するとともにシステム構成図を作成する。 要件定義書一式の作成に当たっては、政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」(2023 年9 月29 日版)、及びGCAS Guide への準拠を前提に、標準ガイドライン」、「デジタル・ガバメント推進標準ガイドライン解説書」、「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」及び「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル(2022 年 7 月 29 日 内閣サイバーセキュリティセンター)」を用いて要件定義内容をチェックするとともに別紙７ の様式で記載する。 また、要件定義書一式は、新システムの設計・開発の調達仕様書作成において重要な基礎資料となることから、マイルストーンを設置し要件定義書一式に関する中間報告書を作成する。 併せて中間報告会を7月中に実施し、方向性の確認を行う。 (3) 設計・開発及び運用・保守に係る概算費用受注者は、上記(2) の成果を基に、設計・開発及び運用・保守に必要な概算費用について自社のこれまでの実績から算出する。 (4) 定例会受注者は、進捗会議を隔週に１回開催し、業務の進捗状況等を報告すること。 なお、開催方法は対面形式又はリモート会議形式を状況に応じて適宜決定する。 発注者から要請があった場合、又は、受注者が必要と判断した場合、必要資料を作成の上、定例会とは別に会議を開催すること。 受注者は、会議終了後、３日以内(行政機関の休日(行政機関の休日に関する法律(昭和63年法律第91 号)第１条第１項各号に掲げる日をいう。 )を除く。 )に議事録を作成し、発注者の承認を受けること。 定例会の参加者は、以下のメンバーとする。 ・農林水産省関東農政局土地改良技術事務所(発注者)・農林水産省農村振興局整備部防災課 災害・減災対策室・農林水産省大臣官房デジタル戦略グループ情報管理室なお、初回の定例会において、受注者は実施計画書に基づき説明を行い、土地改良技術事務所から現行システムの説明を受けること。 (5) 業務結果報告書の作成受注者は、以下の内容を含む業務結果報告書を作成し、発注者の承認を得ること。 11・本調達の概要・上記(1)～(4) で作成した資料第5-2 業務実施に当たっての留意点(1) 本業務の遂行に当たっては、「デジタル社会推進標準ガイドライン群」のうち標準ガイドライン(政府情報システムの整備及び管理に関するルールとして順守する内容を定めたドキュメント)に該当する以下の①から⑥に基づくこと。 また、具体的な作業内容及び手順等については、「デジタル・ガバメント推進標準ガイドライン解説書」を参考とすること。 なお、デジタル社会推進標準ガイドライン群が改定された場合は、最新のものを参照し、その内容に従うこと。 ① DS-100 デジタル・ガバメント推進標準ガイドライン② DS-310 政府情報システムにおけるクラウドサービスの適切な 利用に係る基本方針③ DS-500 行政手続におけるオンラインによる本人確認の手法に関するガイドライン④ DS-900 Webサイト等の整備及び廃止に係るドメイン管理ガイドライン⑤ DS-910 安全保障等の機微な情報等に係る政府情報システムの取扱い⑥ DS-920 行政の進化と革新のための生成AIの調達・利活用に係るガイドライン(2) インターネット公開するシステムは原則として政府系ドメイン(go.jp)を用いること。 (3) 本業務の遂行に当たっては、農林水産省が定めるプロジェクト計画書との整合を確保して行うこと。 また、本業務における検討結果をプロジェクト計画書に適宜反映するとともに、プロジェクト計画書を段階的詳細化し、内容変更の支援をすること。 (4) 新たな要件の策定にあたっては、政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針記載の留意事項等を参考に、クラウドサービスの利用に適した刷新に向け、適切に作業を進めること。 (5) アーキテクチャ実装方式を検討する際、CI/CD を原則とする開発・運用方式を検討すること。 (6) 合理的な調達単位の検討において、CI/CD実施による開発と運用保守の一体化等、担当部署による調達単位の整理を技術的観点から支援すること。 (7) アーキテクチャ実装方式を検討する際、以下の１)から３)の観点に基づき、実装方式を検討(又は見直し)すること。 その際、ガバメントクラウドが用意するリファレンスアーキテクチャ等を積極的に活用すること。 ただし、デジタル庁ＨＰ(https://guide.gcas.cloud.go.jp/)に掲載されているGCAS Guideの「リファレンスアーキテクチャ」に記載された構成を参考に各ブロックを単純に組み合わせたり、アーキテクチャイメージを単純に踏襲したりするだけでなく、本システムに最適化された構成での提案を行うこと。 なお、当該提案内容は、各府省におけるシステム品質向上のため、ベストプラクティスとして共有されうる旨留意すること。 また、UXを担うフロントエンドと業務処理を担うバックエンドは独立的に検討すること。 上記検討内容は、発注者に加え、必要に応じてMAFFクラウドCoEと事前協議すること。 １)旧来技術からの脱却旧来型のセキュリティ対策、多階層の大規模な画面構成、クライアントサーバ方式、Web 三層モデル、シンクライアント(VDI 等)、法定帳票以外の多数の帳票、夜間バッチ、紙での月次運用報告等、人海戦術的な運用作業等の排除を検討すること２)システムやアプリケーションのモダン化３)アジャイルと CI/CD を原則とする開発・運用方式のモダン化(8)合理的な調達単位の検討において、CI/CD実施による開発と運用保守の一体化等、担当部署によ12る調達単位の整理を技術的観点から支援すること。 (9)費用見積について、開発及び運用に係る概算見積を作成すること。 当該見積りには、ガバメントクラウドに係るクラウド利用料も含めること。 (10) ガバメントクラウド利用には、デジタル庁の技術審査が必要とされる。 加えて、「設計・開発、運用・保守に係る概算費用」に基づく投資対効果の分析の結果、ガバメントクラウドに係るクラウド利用料変動が生じる場合、デジタル庁の承認が必要となる。 また、当省PMO(MAFFクラウドCoE)は、当省内各システムによる予算要求の取りまとめ、モダナイズを通じたコスト適正化及び進捗管理を実施しており、新システム構築に向けて調整等を実施することが求められる。 上記を踏まえ、担当部署がデジタル庁、当省PMOその他の関係者と調整等を実施する際、資料作成、会議参加等必要な支援を行うこと。 (11)「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル(2025年７月１日国家サイバー統括室)」の点検を行い、要件定義書に反映すること。 (12) 受注者は、要件定義の作業経緯、残存課題等を文書化し、担当部署に対して確実な引継ぎを行うこと。 (13) 当該調達案件の業務の管理に当たっては、農林水産省が定めるプロジェクト管理要領との整合を確保して行うこと。 (14) 情報システム監査の実施本調達において整備又は管理を行う情報システムに伴うリスクとその対応状況を客観的に評価するために、農林水産省が情報システム監査の実施を必要と判断した場合は、農林水産省が定めた実施内容(監査内容、対象範囲、実施者等)に基づく情報システム監査を受注者は受け入れること(農林水産省が別途選定した事業者による監査を含む。)。 情報システム監査で問題点の指摘又は改善案の提示を受けた場合には、対応案を担当部署と協議し、指示された期間までに是正を図ること。 (15) 当該調達案件の業務遂行に当たっては、担当部署が定めるプロジェクト計画書との整合を確保して行うこと。 (16) 当該調達案件の業務の管理に当たっては、担当部署が定めるプロジェクト管理要領との整合を確保して行うこと。 (17) 受注者は、要機密情報を取り扱う場合、クラウドサービス選定においては「政府情報システムにおけるセキュリティバイデザインガイドライン 別紙 5 政府情報システムにおけるクラウドセキュリティ要件策定、審査手順」に従い、クラウドサービスの選定を行うこと。 (18) パブリッククラウド上に保管されたデータについては、 ISMAPで規定された方法でデータが消去されていること、それが正しく運用されているか第三者による監査により証明されていること。 (19) パブリッククラウド利用時の情報システムの構成やインスタンスタイプ、利用するマネージドサービスが記載されているか。 MAFFクラウドCoEに相談し、事前に方針を確認すること。 (20)ガバメントクラウドについて不明点等がある場合は、担当部署及び全体クラウドCoEと協議の上、作業を進めること。 (21) 農林水産省が本システムの更改を行う際には、次期の情報システムにおける要件定義支援事業者及び設計・開発事業者等に対し、作業経緯、残存課題等に関する情報提供及び質疑応答等の協力を行うこと。 (22) その他特記事項本調達仕様書と契約書の内容に齟齬が生じた場合には、本調達仕様書の内容が優先すること。 13第6章 貸与資料等貸与資料等は下記のとおりであり、監督職員の請求があった場合はその時点で、それ以外は完了検査時に一括返納しなければならない。 第6-1 貸与資料(1) 「農林水産省における情報セキュリティの確保に関する規則」 (平成27年３月31日農林水産省訓令第４号)(2) 国営造成土地改良施設防災情報ネットワークシステムのセキュリティ確保について(案)(3) 現行システムの関係資料1) 令和2年度国営造成土地改良施設防災情報ネットワーク事業システム改良業務 報告書(現行システムの「システム要件定義書」、「ソフトウェア方式設計書」、「切替え・切戻し手順書」を含む)2) 令和7年度防災情報ネットワーク事業 システム運用・保守・クラウドサービス提供業務 報告書(現行システムの「運用・保守計画」、「運用・保守実施要領」を含む)3) その他関係資料は以下のとおりである。 ・平成19年度 国営造成土地改良施設防災情報ネットワークの構築に係る業務・システム最適化計画の策定等委託業務 報告書・平成20年度 国営造成土地改良施設防災情報ネットワークの構築に係る調査検討・実証等委託業務報告書・国営造成土地改良施設防災情報ネットワーク防災中央データセンターシステム開発業務 報告書・国営造成土地改良施設防災情報ネットワーク情報提供システムデータ等整備業務 報告書・国営造成土地改良施設防災情報ネットワーク防災中央データセンターシステム連携開発業務 報告書・平成23年度国営造成土地改良施設防災情報ネットワークシステム運用業務 報告書・平成23年度国営造成土地改良施設防災情報ネットワークシステム保守業務 報告書・平成23年度国営造成土地改良施設防災情報ネットワークシステム運用支援業務(その１) 報告書・平成23年度国営造成土地改良施設防災情報ネットワーク事業・国営造成土地改良施設防災情報ネットワークシステム機能検討業務(その１) 報告書・平成23年度国営造成土地改良施設防災情報ネットワーク事業・国営造成土地改良施設防災情報ネットワークシステム機能検討業務(その２) 報告書・平成23年度国営造成土地改良施設防災情報ネットワーク事業・国営造成土地改良施設防災情報ネットワークシステム機能検討業務(その３) 報告書・平成24年度国営造成土地改良施設防災情報ネットワーク事業 システム運用業務 報告書・平成24年度国営造成土地改良施設防災情報ネットワーク事業 システム保守業務 報告書・平成24年度国営造成土地改良施設防災情報ネットワーク事業 システム接続支援業務 報告書・平成24年度国営造成土地改良施設防災情報ネットワーク事業 システム改良検討業務 報告書・平成25年度国営造成土地改良施設防災情報ネットワーク事業 システム運用業務 報告書・平成25年度国営造成土地改良施設防災情報ネットワーク事業 システム保守業務 報告書・平成25年度国営造成土地改良施設防災情報ネットワーク事業 システム改良検討業務 報告書・平成26年度国営造成土地改良施設防災情報ネットワーク事業 システム運用業務 報告書14・平成26年度国営造成土地改良施設防災情報ネットワーク事業 システム保守業務 報告書・平成26年度国営造成土地改良施設防災情報ネットワーク事業 システム詳細設計業務 報告書・平成27年度国営造成土地改良施設防災情報ネットワーク事業 システム運用業務 報告書・平成27年度国営造成土地改良施設防災情報ネットワーク事業 システム保守業務 報告書・平成27年度国営造成土地改良施設防災情報ネットワーク事業 システム開発業務 報告書・平成28年度国営造成土地改良施設防災情報ネットワーク事業 システム運用業務 報告書・平成28年度国営造成土地改良施設防災情報ネットワーク事業 システム保守業務 報告書・平成28年度国営造成土地改良施設防災情報ネットワーク事業 情報活用検討業務 報告書・平成29年度国営造成土地改良施設防災情報ネットワーク事業 システム設定業務 報告書・平成29年度国営造成土地改良施設防災情報ネットワーク事業 システム運用業務 報告書・平成29年度国営造成土地改良施設防災情報ネットワーク事業 システム保守業務 報告書・平成30年度国営造成土地改良施設防災情報ネットワーク事業 システム運用業務 報告書・平成30年度国営造成土地改良施設防災情報ネットワーク事業 システム保守業務 報告書・平成30年度国営造成土地改良施設防災情報ネットワーク事業 システム詳細設計業務 報告書・平成31年度国営造成土地改良施設防災情報ネットワーク事業 システム保守業務 報告書・平成31年度国営造成土地改良施設防災情報ネットワーク事業 システム設定業務 報告書・令和元年度国営造成土地改良施設防災情報ネットワーク事業 防災情報ネットワークシステム改良業務 報告書・令和元年度国営造成土地改良施設防災情報ネットワーク事業 防災情報ネットワーク接続支援業務 報告書・令和2年度国営造成土地改良施設防災情報ネットワーク事業 システム運用業務 報告書・令和2年度国営造成土地改良施設防災情報ネットワーク事業 システム保守業務 報告書・令和2年度国営造成土地改良施設防災情報ネットワーク事業 システム改良業務 報告書・令和2年度国営造成土地改良施設防災情報ネットワーク事業 接続支援業務 報告書・令和3年度国営造成土地改良施設防災情報ネットワーク事業 システム運用・保守業務 報告書・令和4年度防災情報ネットワーク事業 システム運用・保守業務 報告書・令和5年度防災情報ネットワーク事業 システム運用・保守業務 報告書・令和5年度防災情報ネットワーク事業 防災情報ネットワークシステムデータベースのクラウド移行に向けた検討業務 報告書・令和6年度防災情報ネットワーク事業 システム運用・保守業務 報告書・令和6年度防災情報ネットワーク事業 防災情報ネットワークシステム設定業務 報告書・令和７年度防災情報ネットワーク事業 システム運用・保守・クラウドサービス提供業務 報告書・令和７年度防災情報ネットワーク事業 システム改修業務 報告書・令和７年度防災情報ネットワーク事業 システム改良検討業務 報告書(4) 閲覧に当たっては、複写や写真撮影等による閲覧内容の記録は禁止する。 また、閲覧を希望する資料によっては、情報セキュリティ確保等の観点から閲覧できない場合がある。 ガバメントクラウドを利用する場合は、以下のGCASサイトにアクセスし情報を確認してください。 https://guide.gcas.cloud.go.jp/閲覧に供する資料の例を次に示す。 15・プロジェクト計画書、プロジェクト管理要領・プロジェクト標準(標準コーディング規約、セキュアコーディング規約等)・農林水産省クラウド利用ガイドライン及び関係資料・関連する他の情報システムの操作マニュアル、設計書、各種プロジェクト標準第7章 成果物第7-1 成果物本業務の成果物は、以下のとおりであり、改定の無い文書も添付する。 なお、成果物の原著作権及び二次的著作物の著作権(著作権法第21条から第28条に定める全ての権利を含む。)は、受注者が本調達の実施の従前から権利を保有していた等の明確な理由によりあらかじめ提案書等にて権利譲渡不可能と示されたもの以外は、全て発注者に帰属するものとする。 受注者に帰属する知的財産権を利用して本業務を行う場合、発注者及びシステム利用者に受注者の知的財産権の利用を許諾する範囲及び制約を受注者が周知すること。 発注者は、成果物について、第三者に権利が帰属する場合を除き、自由に複製し、改変等し、及びそれらの利用を第三者に許諾することができるとともに、任意に開示できるものとする。 また、受注者は、成果物について、自由に複製し、改変等し、及びこれらの利用を第三者に許諾すること(以下「複製等」という。)ができるものとする。 ただし、成果物に第三者の権利が帰属するときや、複製等により発注者がその業務を遂行する上で支障が生じるおそれがある旨を契約締結時までに通知したときは、この限りでないものとし、この場合には、複製等ができる範囲やその方法等について協議するものとする。 本調達に係る成果物の権利(著作権法第21条から第28条までに定める全ての権利を含む。)及び所有権は、検収に合格した成果物の引渡しを受けたとき受注者から発注者に移転するものとする。 納品される成果物に第三者が権利を有する著作物(以下「既存著作物等」という。)が含まれる場合には、受注者は、当該既存著作物等の使用に必要な費用の負担及び使用許諾契約等に関わる一切の手続きを行うこと。 この場合、本業務の受注者は、当該既存著作物の内容について事前に発注者の承認を得ることとし、発注者は、既存著作物等について当該許諾条件の範囲で使用するものとする。 なお、本仕様に基づく作業に関し、第三者との間に著作権に係る権利侵害の紛争の原因が専ら発注者の責めに帰す場合を除き、受注者の責任及び負担において一切を処理すること。 この場合、発注者は係る紛争等の事実を知ったときは、受注者に通知し、必要な範囲で訴訟上の防衛を受注者に委ねる等の協力措置を講じるものとする。 受注者は発注者に対し、一切の著作者人格権を行使しないものとし、また、第三者をして行使させないものとする。 受注者は使用する画像、デザイン、表現等に関して他者の著作権を侵害する行為に十分配慮し、これを行わないこと。 生成AI を活用したシステムを構築・運用する場合、生成AI で作成したアウトプットや本業務で作成した生成AI向けの指示文については、農林水産省に権利が帰属するものとする。 受注者は、本業務の改修要件を満たすための詳細設計を行い、既存の各種設計書類に反映をし、成果物について担当部署の承認を得ること。 受注者に帰属する知的財産権を利用して本業務を行う場合、発注者及びシステム利用者に受注者の知的財産権の利用を許諾する範囲及び制約を受注者が周知すること。 16(1) 業務報告書成果物は以下に示すとおり計画しているが、成果物に追加・削除が生じた場合は、監督職員と協議するものとする。 表４ 成果物一覧No. 成果物名 内容及び納品数量納品期日1 本業務での起票シート 一式令和8年10月30日2 作業報告一覧表3 協議の記録等4 リリースノート5 契約金額の内訳 契約締結日から14日以内 6 業務実施計画書7情報資産管理標準シート 担当部署から依頼された場合、速やかに提出8 業務フロー 令和8年10月30日9 業務結果報告書第7-2 成果物の納品方法等(1) 成果物の納品方法1) 成果物は、全て日本語で作成すること。 ただし、日本国内においても英字で表記されることが一般的な文言については、そのまま記載しても構わないものとする。 2) 用字・用語・記述符号の表記については、「公用文作成の考え方(令和4年1月11日内閣官房長官通知)」を参考にすること。 3) 情報処理に関する用語の表記については、日本産業規格(JIS)の規定を参考にすること。 4) 作成した成果物は担当部署が指定したサーバへ納品(例：PrimeDrive又はSharePoint等)すること。 なお、納品の際は、検収が終了したファイル一式を時点がわかるような形式(例：zip等)で提出すること。 5) サーバ納品について、Microsoft Office又はPDFのファイル形式で作成すること。 6) 納品後、農林水産省において改変が可能となるよう、図表等の元データも併せて納品すること。 7) 成果物の作成に当たって、特別なツールを使用する場合は、担当職員の承認を得ること。 8) 成果物が外部に不正に使用されたり、納品過程において改ざんされたりすることのないよう、安全な納品方法を提案し、成果物の情報セキュリティの確保に留意すること。 9) 不正プログラム対策ソフトウェアによる確認を行うなどして、成果物に不正プログラムが混入することのないよう、適切に対処すること。 10) 上記に加えて紙媒体についても作成し、発注者から特別に示す場合を除き、原則紙媒体は２部を納品すること。 11) 紙媒体による納品について、用紙のサイズは、原則として日本産業規格A 列４番とする17が、必要に応じて日本産業規格A列３番を使用すること。 (2) 成果物の納品場所原則として、成果物は次の場所において引渡しを行うこと。 ただし、発注者が納品場所を別途指示する場合はこの限りではない。 〒332-0026埼玉県川口市南町2-5-3農林水産省関東農政局土地改良技術事務所 防災・災害対策技術課(電話：048-278-4683)(3) 契約不適合責任1) 農林水産省は検収(「検査」と同義。以下同じ。)完了後、納入された成果物について調達仕様書との不一致(バグも含む。以下「契約不適合」という。)が発見された場合、受注者に対して当該契約不適合の修正等の履行の追完(以下「追完」という。)を請求することができる。 この場合において、受注者は、当該追完を行うものとする。 ただし、農林水産省が追完の方法を指定して追完を請求した場合であって、農林水産省に不相当な負担を課するものでないときは、受注者は農林水産省が指定した方法と異なる方法による追完を行うことができる。 2) 前記1)の場合において、追完の請求にも関わらず相当の期間内に追完がなされないときは、農林水産省は、その不適合の程度に応じて支払うべき金額の減額を請求することができる。 3) 前記2)の規定にかかわらず、次に掲げる場合には、農林水産省は、相当の期間の経過を待つことなく、直ちに支払うべき金額の減額を請求することができる。 ア 追完が不能であるとき。 イ 受注者が追完を拒絶する意思を明確に表示したとき。 ウ 特定の日時又は一定の期間内に履行をしなければ本調達の目的を達することができない場合において、受注者が追完をしないでその時期を経過したとき。 エ アからウまでに掲げる場合のほか、農林水産省が追完の請求をしても追完を受ける見込みがないことが明らかであるとき。 4) 農林水産省は、当該契約不適合(受注者の責めに帰すべき事由により生じたものに限る。)により損害を被った場合、受注者に対して損害賠償を請求することができる。 5) 当該契約不適合について、追完の請求にもかかわらず相当期間内に追完がなされない場合又は追完の見込みがない場合であって、当該契約不適合により本契約の目的を達することができないときは、農林水産省は本契約の全部又は一部を解除することができる。 6) 前記1)から5)までの規定にかかわらず、受注者が種類又は品質に関して契約の内容に適合しない成果品を農林水産省に引き渡した場合において、農林水産省が検収完了後１年以内に当該契約不適合について通知しないときは、農林水産省は、本仕様書に定める契約不適合責任に係る請求をすることができない。 ただし、成果品を納入した時において受注者が当該契約不適合を知り、若しくは重過失により知らなかったとき、又は当該契約不適合が受注者の故意若しくは重過失に起因するときはこの限りでない。 7) 前記1)から5)までの規定にかかわらず、契約不適合が農林水産省の与えた指示によって生じたときは適用しないこと。 ただし、受注者がその資料等又は指示が不適当であることを知りながら告げなかったときはこの限りでない。 (4) 検収1) 本業務の受注者は、成果物等について、納品期日までに農林水産省に内容の説明を実施して検収を受けること。 182) 検収の結果、成果物等に不備又は、誤り等が見つかった場合には、直ちに必要な修正、改修、交換等を行い、変更点について農林水産省に説明を行った上で、指定された日時までに再度納品すること。 第8章 入札参加資格に関する事項第8-1 競争参加資格ア 予算決算及び会計令第70条の規定に該当しない者であること。 なお、未成年者、被保佐人又は被補助人であって、契約締結のために必要な同意を得ている者は、同条中、特別の理由がある場合に該当する。 イ 公告日において令和７・８・９年度全省庁統一資格の「役務の提供等」の「A」、「B」、「C」又は「D」の等級に格付けされ、競争参加資格を有する者であること。 第8-2 公的な資格や認証等の取得ア 入札参加者は、品質マネジメントシステムに係る以下のいずれかの条件を満たすこと。 (ア) 品質マネジメントシステムの規格である「JIS Q 9001」又は｢ISO9001」(登録活動範囲が情報処理に関するものであること。)の認定を、業務を遂行する組織が有しており、認証が有効であること。 (イ) 上記と同等の品質管理手順及び体制が明確化された品質マネジメントシステムを有している事業者であること(管理体制、品質マネジメントシステム運営規程、品質管理手順規定等を提示すること。)。 イ 入札参加者は、情報セキュリティに係る以下のいずれかの条件を満たすこと。 (ア) 情報セキュリティ実施基準である「JIS Q 27001」、「ISO/IEC27001」又は「ISMS」の認証を有しており、認証が有効であること。 (イ) 一般財団法人日本情報経済社会推進協会のプライバシーマーク制度の認定を受けているか、又は同等の個人情報保護のマネジメントシステムを確立していること。 (ウ) 個人情報を扱うシステムのセキュリティ体制が適切であることを第三者機関に認定された事業者であること。 第8-3 受注実績等入札参加者は、以下の要件をすべて満たしていること。 ア 入札参加者は、パブリッククラウドサービス上に、システムの要件定義又はWebアプリケーションの設計・開発、運用保守に係る業務実績を過去５年以内に有すること。 イ 入札参加者は、レガシーシステムをモダンなアプリケーションへの刷新に向けた基本構想策定又は要件定義を支援した実績を過去５年以内に有すること。 第8-4 複数事業者による共同入札ア 複数の事業者が共同提案する場合、その中から全体の意思決定、運営管理等に責任を持つ共同提案の代表者を定めるとともに、本代表者が本調達に対する入札を行うこと。 イ 共同提案を構成する事業者間においては、その結成、運営等について協定を締結し、業務の遂行に当たっては、代表者を中心に、各事業者が協力して行うこと。 事業者間の調整事19項、トラブル等の発生に際しては、その当事者となる当該事業者間で解決すること。 また、解散後の契約不適合責任に関しても協定の内容に含めること。 ウ 共同提案を構成する全ての事業者は、本入札への単独提案又は他の共同提案への参加を行っていないこと。 エ 共同事業体の代表者は、品質マネジメントシステム及び情報セキュリティに係る要件について満たすこと。 その他の入札参加要件については、共同事業体を構成する事業者のいずれかにおいて満たすこと。 第8-5 入札制限ア 本業務に関連する調達間での入札制限は設けない。 イ 本業務を直接担当する農林水産省IT アドバイザー(デジタル統括アドバイザーに相当)、農林水産省全体管理組織(ＰＭＯ)支援スタッフ及び農林水産省最高情報セキュリティアドバイザーが、その現に属する事業者及びこの事業者の「財務諸表等の用語、様式及び作成方法に関する規則」 (昭和38年大蔵省令第59号)第8条に規定する親会社及び子会社、同一の親会社を持つ会社並びに請負先等緊密な利害関係を有する事業者は、本書に係る業務に関して入札に参加できないものとする。 第9章 契約変更請負契約書に規定する発注者と受注者による協議事項は次のとおりとする。 ただし、軽微な変更については、協議の上契約変更しないものとする。 (1) 第4章に示す「作業条件」に変更が生じた場合(2) 第5章に示す「業務実施内容」に変更が生じた場合(3) 第7章に示す「成果物」に変更が生じた場合(4) 履行期間に変更が生じた場合第10章 再請負に関する事項(1) 再請負の制限及び再請負を認める場合の条件ア 本業務の受注者は、業務を一括して又は主たる部分を再請負してはならない。 イ 受注者における業務責任者を再請負先事業者の社員や契約社員とすることはできない。 ウ 受注者は再請負先の行為について一切の責任を負うものとする。 エ 再請負先における情報セキュリティの確保については受注者の責任とする。 オ 再請負を行う場合、再請負先が「8-5入札制限」に示す要件を満たすこと。 (2) 承認手続ア 本業務の実施の一部を合理的な理由及び必要性により再請負する場合には、 あらかじめ再請負の相手方の商号又は名称及び住所並びに再請負を行う業務の範囲、再請負の必要性及び契約金額等について記載した別添の再請負承認申請書を農林水産省に提出し、あらかじめ承認を得ること。 イ 前項による再請負の相手方の変更等を行う必要が生じた場合も、前項と同様に再請負に関する書面を農林水産省に提出し、承認を得ること。 ウ 再請負の相手方が更に請負を行うなど複数の段階で再請負が行われる場合 (以下「再々請負」という。)には、当該再々請負の相手方の商号又は名称及び住所並びに再々請負を行う業務の範囲を書面で報告すること。 20(3) 再請負先の契約違反等再請負先において、本仕様書の遵守事項に定める事項に関する義務違反又は義務を怠った場合には、受注者が一切の責任を負うとともに、農林水産省は、当該再請負先への再請負の中止を請求することができる。 第11章 環境関係法令等の遵守第11-1 環境法令の遵守受注者は、物品・役務(委託事業を含む)の提供に当たり、関連する環境関係法令を遵守するものとする。 (1) エネルギーの節減・エネルギーの使用の合理化及び非化石エネルギーへの転換等に関する法律(昭和54 年法律第49号)(2) 廃棄物の発生抑制、適正な循環的な利用及び適正な処分・廃棄物の処理及び清掃に関する法律 (昭和45年法律第137号)・国等による環境物品等の調達の推進等に関する法律 (平成12年法律第100号)・プラスチックに係る資源循環の促進等に関する法律(令和３年法律第60号)(3) 環境関係法令の遵守等・労働安全衛生法 (昭和47年法律第57号)・地球温暖化対策の推進に関する法律 (平成10年法律第117号)第11-2 環境負荷低減に係る遵守事項受注者(受注者)は、役務(委託事業を含む)の提供に当たり、新たな環境負荷を与えることにならないよう、事業の最終報告時に別紙８の様式を用いて、以下の取組に努めたことを、環境負荷低減のクロスコンプライアンス実施状況報告書として提出すること。 なお、全ての事項について「実施した／努めた」又は「左記非該当」のどちらかにチェックを入れるとともに、ア～エの各項目について、一つ以上「実施した／努めた」にチェックを入れること。 (1) 環境負荷低減に配慮したものを調達するよう努める。 (2) エネルギーの削減の観点から、オフィスや車両・機械などの電気、燃料の使用状況の記録・保存や、不必要・非効率なエネルギー消費を行わない取組(照明、空調のこまめな管理や、ウォームビズ・クールビズの励行、燃費効率の良い機械の利用等)の実施に努める。 (3) 廃棄物の発生抑制、適正な循環的な利用及び適正な処分に努める。 (4) みどりの食料システム戦略の理解に努める。 第11-3 行政の進化と革新のための生成AIの調達・利活用に係るガイドラインへの対応本業務の遂行に当たっては、生成AIを活用する場合、「デジタル社会推進標準ガイドライン DS-920 行政の進化と革新のための生成 AI の調達・利活用に係るガイドライン 別紙３調達チェックシート」の基本項目を満たすこと。 本業務においては、国民等による農林水産省外利用の場合、個人情報、プライバシー、知的財産を取り扱う場合の要件についても対応すること。 行政の進化と革新のための生成AI の調達・利活用に係るガイドラインが改定された場合は、最新のものを参照し、その内容に従うこと。 21第11-４ IT調達に係る国の物品等又は役務の調達方針及び調達手続に関する申合せ本業務の遂行に当たっては、生成AIを活用する場合、納入候補となる機器・役務等について、令和８年３月５日(又は提案書、証明書等の提出期限)までに、担当部署へ機器等リスト(区分(ノートPC等)、業者・役務実施業者名、製造業者の法人番号、製品名・役務実施場所、型番等を記載したリスト)を提出することとし、農林水産省においてサプライチェーン・リスクに係る懸念が払拭されないと判断した場合には、速やかに担当部署に確認した上で、代替品の選定等、納入候補となる機器・役務等を見直すこと。 第12章 定めなき事項本仕様書に定めのない事項又は、本業務の施行に当たり疑義が生じた場合は、必要に応じて、監督職員と速やかに協議しなければならない。 本調達仕様書と契約書の内容に齟齬が生じた場合には、本調達仕様書の内容が優先するものとする。 防災情報ネットワーク対象地区一覧表局名 県名 地区名 現況 局名 県名 地区名 現況 局名 県名 地区名 現況東北 青森 津軽北部 運用中 北陸 石川 珠洲 R7予定 北海 北海道 上磯 運用中東北 青森 浪岡川 運用中 北陸 福井 日野川用水(一期) (二期) 運用中 北海 北海道 厚沢部川 運用中東北 青森 平川 運用中 東海 愛知 新矢作川用水 運用中 北海 北海道 渡島中央 運用中東北 青森 岩木川左岸 運用中 東海 愛知 新濃尾 運用中 北海 北海道 駒ヶ岳 運用中東北 青森 小田川 運用中 東海 岐阜 西濃用水第二期 運用中 北海 北海道 知内 運用中東北 青森 八戸平原 運用中 東海 三重 中勢用水 運用中 北海 北海道 双葉 運用中東北 青森 浅瀬石川 運用中 東海 三重 宮川用水第二期 運用中 北海 北海道 共和 運用中東北 岩手 山王海 運用中 近畿 滋賀 野洲川 運用中 北海 北海道 北後志 運用中東北 岩手 藤沢 運用中 近畿 滋賀 日野川 運用中 北海 北海道 余市 運用中東北 岩手 豊沢川 運用中 近畿 滋賀 湖北 運用中 北海 北海道 ペーパン 運用中東北 岩手 馬淵川沿岸 運用中 近畿 滋賀 愛知川 運用中 北海 北海道 神居 運用中東北 岩手 岩手山麓 運用中 近畿 京都 巨椋池 運用中 北海 北海道 共栄近文 運用中東北 岩手 雫石川沿岸 運用中 近畿 兵庫 北淡路 運用中 北海 北海道 フラヌイ フラヌイ二期 運用中東北 宮城迫川上流 (荒砥沢ダム)(小田ダム)運用中 近畿 兵庫 東条川 運用中 北海 北海道 空知川右岸 運用中東北 宮城 迫川上流(一の堰頭首工) 運用中 近畿 兵庫 加古川 運用中 北海 北海道 ぴっぷ 運用中東北 宮城 旧迫川 運用中 近畿 奈良 大和高原北部 運用中 北海 北海道 しろがね 運用中東北 宮城 中田 運用中 近畿 奈良 十津川紀の川 運用中 北海 北海道 当麻 運用中東北 宮城 角田 運用中 近畿 奈良 五条吉野 運用中 北海 北海道 美瑛川 運用中東北 宮城 大崎 運用中 近畿 和歌山 南紀用水 運用中 北海 北海道 風連(御料ダム、風連ダム) 運用中東北 宮城 鳴瀬川 運用中 中四 鳥取 大山山麓 運用中 北海 北海道 ふらの 運用中東北 秋田 男鹿東部 運用中 中四 鳥取 東伯 運用中 北海 北海道 温根別 運用中東北 秋田 能代開拓 運用中 中四 岡山 児島湾周辺・岡山(海岸保全) 運用中 北海 北海道 天塩川上流 運用中東北 秋田 仙北平野 運用中 中四 岡山 笠岡湾 運用中 北海 北海道 早来 運用中東北 秋田 旭川水系 運用中 中四 岡山 勝英 運用中 北海 北海道 三石 運用中東北 山形 寒河江川農水 運用中 中四 岡山 小阪部川 運用中 北海 北海道 鵡川沿岸 運用中東北 山形 白川 運用中 中四 広島 広島中部台地 運用中 北海 北海道 勇払東部 運用中東北 山形 最上川下流沿岸 運用中 中四 広島 芦田川 運用中 北海 北海道 十勝川左岸 運用中東北 山形 新庄 運用中 中四 島根 横田 運用中 北海 北海道 芽室 運用中東北 山形 最上川中流 運用中 中四 愛媛 南予 運用中 北海 北海道 幕別 運用中東北 山形 泉田川 運用中 中四 愛媛 道前道後 道後平野地区 運用中 北海 北海道 中士幌 運用中東北 山形 月山山麓 運用中 中四 愛媛 道前道後 面河地区 運用中 北海 北海道 札内川 運用中東北 山形 米沢平野二期 運用中 中四 愛媛 道前道後 道前平野地区 運用中 北海 北海道 女満別 運用中東北 山形 赤川 運用中 九州 福岡 耳納山麓 運用中 北海 北海道 斜里 運用中東北 福島 郡山東部 運用中 九州 福岡 筑後川中流 床島地区 運用中 北海 北海道 斜里(二期) 運用中東北 福島 会津宮川 運用中 九州 福岡 筑後川中流 山田地区 運用中 北海 北海道 雄武中央(一期)(二期) 運用中東北 福島 会津北部 運用中 九州 佐賀 佐賀中部 運用中 北海 北海道 北見 運用中東北 福島 雄国山麓 運用中 九州 佐賀 上場 運用中 北海 北海道 西網走 運用中東北 福島 白河矢吹 運用中 九州 佐賀 嘉瀬川 運用中 北海 北海道 苫前 運用中東北 福島 阿武隈上流 運用中 九州 佐賀 多良岳 運用中 北海 北海道 天塩沿岸 運用中東北 福島 安積疏水(新安積) 運用中 九州 長崎 諫早湾 運用中 北海 北海道 羽幌 運用中東北 福島 請戸川 運用中 九州 熊本 八代平野 運用中 北海 北海道 羽幌二股 運用中東北 福島 母畑 運用中 九州 大分 駅館川 運用中 沖縄 沖縄 石垣島 運用中関東 栃木 鬼怒中央 運用中 九州 大分 大野川上流 運用中 沖縄 沖縄 羽地大川 運用中関東 栃木 那須野原 運用中 九州 宮崎 大淀川右岸 運用中関東 栃木 芳賀台地 運用中 九州 宮崎 大淀川左岸 運用中関東 群馬 渡良瀬川中央・沿岸 運用中 九州 宮崎 一ツ瀬川 運用中関東 群馬 鏑川(大塩貯水池･竹沼貯水池) 運用中 九州 宮崎 都城盆地 運用中関東 群馬 鏑川(丹生貯水池) 運用中 九州 宮崎 尾鈴 運用中関東 茨城 那珂川沿岸 運用中 九州 宮崎 西諸 運用中関東 茨城 霞ヶ浦用水 運用中 九州 鹿児島 出水平野 運用中関東 埼玉 大里 運用中 九州 鹿児島 曽於東部 運用中関東 山梨 釜無川 運用中 九州 鹿児島 曽於南部 運用中北陸 新潟 新川流域／西蒲原 運用中 九州 鹿児島 曽於北部 運用中北陸 新潟 亀田郷 運用中 九州 鹿児島 笠野原 運用中北陸 新潟 白根郷 運用中 九州 鹿児島 肝属中部 運用中北陸 新潟 刈谷田川右岸 R7予定 九州 鹿児島 徳之島用水 運用中北陸 新潟 関川 運用中 九州 鹿児島 南薩 運用中北陸 新潟 阿賀野川用水 運用中 北海 北海道 幌向川 運用中北陸 新潟 阿賀野川右岸 運用中 北海 北海道 音江山(芦別北部) 運用中北陸 新潟 信濃川下流 運用中 北海 北海道 新雨竜(一期)(二期) 運用中北陸 新潟 新津郷 運用中 北海 北海道 雨竜川中央 運用中北陸 新潟 佐渡 運用中 北海 北海道 北空知 運用中北陸 新潟 柏崎周辺 運用中 北海 北海道 樺戸(二期) 運用中北陸 新潟 加治川 運用中 北海 北海道 多度志 運用中北陸 新潟 苗場山麓第一 運用中 北海 北海道 恵岱別 運用中北陸 新潟 苗場山麓第二 運用中 北海 北海道 当別 運用中北陸 富山 氷見 運用中 北海 北海道 南月形 運用中北陸 富山 常願寺川沿岸 運用中 北海 北海道 幌新 運用中北陸 富山 小矢部川 運用中 北海 北海道 幌加内 運用中北陸 石川 河北潟 運用中 北海 北海道 野花南 運用中北陸 石川 手取川 運用中 北海 北海道 高岡シップ 運用中北陸 石川 珠洲第二 運用中 北海 北海道 北檜山右岸 運用中運用中 185地区Ｒ７接続予定 2地区別紙１クラウド構成図AWS 1リージョン 2AZ・RDS構成別紙２AWS CloudPublic SubnetAvailability Zone (ap-northeast-1a)インアウトAWS WAF東京リージョ現行の"関東農政局土地改良技術事務所" 想内閣府総合防災外部連携観測値計測情報10分おき(霞が関、 立川)現行と同じドメインの利用可能気象情報提供者注意報・警報／発表時(随時)指定河川洪水予報／発表時(随時)高解像度降水ﾅｳｷｬｽﾄ／5分おき1kmﾒｯｼｭ解析雨量GPV／30分おき1kmﾒｯｼｭ降水短時間予報GPV／30分おきアメダス／10分おき震源・震度に関する情報／発表時(随時)外部連携MAFFクラウドデータの経路 運用保守事業者操作運用のフロー内部TrustedAdvisorCostExplorer BudgetsCloudWatcS3CloudTrailConfigSNSGuardDutySecurityFlow logsS3MAFFクラウドConfigGuardDutySecurity hubEventBridgeRDSマルチAZデプロイによるレプリケーションWeb SubnetWeb・APサーバ(運用サーバ)apache/tomcat防災情報WebサイトVPCインターネットゲートウェイALBACMNAT Gateway国土地理院外部連携国土地理院からの地図情報取得中央管理所(200地区想定)外部連携観測値計測情報10分おき施設状態情報随時(状態発生EC2DB SubnetAmazonRDS instanceAWSBackupSystemsManagerManagementSESAmazon Route53AmazonCloudFrontNAT GatewayAvailability Zone (ap-northeast-1c)ACMEC2(踏み台)NLBNLB利用者運用保守事業者パソコンWeb・APサーバ(運用サーバ)apache/tomcat防災情報WebサイトWeb Subnet運用 DB (プライマリ)DBBK SubnetAmazonRDS instance運用 DBBK (プライマリ)DB SubnetAmazonRDS instance運用 DB (スタンバイ)DBBK SubnetAmazonRDS instance運用 DBBK (スタンバイ)緊急点検データファイルの同期処理ALBPublic SubnetEC2VPC Endpoint(s3 gateway)VPC Endpoint VPC Endpoint VPC EndpointMAFFクラウド共通機能で利用SystemsManagerEmail通常時未作成(スタンバイ側への切り替え時に作成)別紙３ システム利用環境等１ システムの利用環境本システムの利用環境は下表のとおりである。 (１)利用者本システムの利用者は、以下のとおりである。 利用者 主な利用目的① 関東農政局土地改良技術事務所全国の防災情報の収集と提供、防災中央システム／バックアップシステムの管理②農林水産本省 全国の防災情報の参照③地方農政局等(北海道開発局、沖縄総合事務局含む)関係地区の防災情報の参照④土地改良調査管理事務所等(北海道開発局各開発建設部含む)関係地区の防災情報の参照⑤道府県 関係地区の防災情報の参照⑥市町村 関係地区の防災情報の参照⑦施設管理者 関係地区の防災情報の参照⑧内閣府全国の防災情報の収集(内閣府総合防災情報システム)(２)システム環境データ転送システム(中央管理所)のシステム環境は、地区により異なるため未記載とする。 (３)ソフトウェア環境ソフトウェア環境は、以下のとおりとする。 システム名 サーバ名 構 成 内 容防災中央システム／バックアップシステムWeb・アプリケーションサーバOS Red Hat Enterprise Linux 8(64bit)Webサーバ Apache HTTP Server 2.4アプリケーションサーバJavaApache Tomcat 9.0Amazon Corretto 17データベースサーバサービスDBMSAmazon RDSPostgreSQL 15データベース(ダウンロード用)兼バックアップサーバサービス Amazon RDSDBMSPostgreSQL 15データ転送システム(中央管理所)転送サーバ OS Windows Server 2022 StandardWindows Server 2019 StandardWindows Server 2016 Standard(４)システム概念図システム概念図は別図１に示すとおり。 ２ 用語の定義本業務で使用する主な用語の定義は、次のとおりとする。 用語 定 義AWS MAFF クラウド上で稼働するクラウドサービス。 「Amazon WebServices」の略。 東京リージョンを基盤(2AZ(アベイラビリティゾーン)構成)とする。 データ転送システム 既存の国営造成土地改良施設に設置されている中央管理所から防災情報をインターネット経由で防災中央システムへ転送するためのシステム。 情報提供システム データ転送システムで転送されてきた各国営造成土地改良施設固有の情報を表示するシステムであり、防災中央システム上で稼動する。 防災中央システム AWSの東京リージョンアベイラビリティゾーン1に設置され、中央管理所から転送された防災情報を迅速かつ、一元的に管理し、収集した防災情報を別紙３の１(１)に記載された利用者へ情報を提供するためのシステム。 バックアップシステム AWS の東京リージョンアベイラビリティゾーン２に設置され、防災中央システムが被災し機能が停止した場合、代わってシステムを稼働させるバックアップシステム。 中央管理所 国営造成土地改良施設の情報を一元的に管理し、施設管理者が国営造成土地改良施設の遠隔操作を行うことを目的に各国営地区に設置された施設。 国営造成土地改良施設 農業用ダム、頭首工、排水機場等の基幹的土地改良施設水管理システム 中央管理所で国営造成土地改良施設の情報を監視・制御するシステム総合防災情報システム 防災機関が横断的に共有すべき防災情報の形式を標準化し、国、地方公共団体等の各機関や住民等の情報を共通のシステムに集約する共通基盤気象情報提供者 気象情報及び地震情報を提供する者計測情報 国営造成土地改良施設の操作、制御とそれに伴う施設の状況変化を把握するために必要な情報 例)水位、雨量、ポンプ翼開度など状態監視情報(SV) 国営造成土地改良施設の状態、操作モード、警報関係などの情報例)ゲート開・閉、ゲート故障、水位異常など(別図１)国営造成土地改良施設防災情報ネットワークシステム概念図ダム排水機場ゲート中央管理所MAFFクラウド防災中央システム総合防災情報システム情報の提供(Ｗｅｂ)正確かつ迅速な防災情報の提供・共有水位・流量・雨量などの観測(水管理システム)中央管理所(水管理システム)(200地区を予定)対象地区中央管理所(水管理システム)アメダスデータ国営造成土地改良施設(観測機器)土地改良区本省・農政局市町村土地改良技術事務所土地改良調査管理事務所道府県内 閣 府データ連携データ転送システムバックアップシステムAWSアベイラビリティゾーン２データ同期・計測情報 ・状態監視情報(SV)データの収集ルーターXMLHUB情報提供システムUPSデータ転送用サーバXML変換PCデータ転送用PCAWSアベイラビリティゾーン１(別図２)国営造成土地改良施設防災情報ネットワークシステム機器構成図運用DBAmazon RDSinstanceSubnet2 (プライベート)総合防災情報システム利用者対象地区(200地区を予定)インターネットダウンロードWeb閲覧CSVダウンロードデータ転送システムXML CSV国営土地改良施設(観測機器)・計測情報・状態監視情報(SV)HUB HUBデータ転送内閣府メール中央管理所気象情報提供者アメダスＭＡＦＦクラウド国営造成土地改良施設防災情報ネットワークシステム機器構成図AmazonEC2/home、/usr …Subnet1 (パブリック)AmazonEBSWeb・APサーバ1(運用サーバ)apache/tomcat防災情報Webサイト各・全データ・差分データ・緊急点検防災中央システム(AWSアベイラビリティゾーン１)運用DBBKAmazon RDSinstanceSubnet3 (プライベート)運用DBAmazon RDSinstanceSubnet2 (プライベート)AmazonEC2/home、/usr …Subnet1 (パブリック)AmazonEBSWeb・APサーバ1(運用サーバ)apache/tomcat防災情報Webサイト各・全データ・差分データ・緊急点検運用DBBKAmazon RDSinstanceSubnet3 (プライベート)バックアップシステム(AWSアベイラビリティゾーン２)(別図３)- 1 -別紙４ 情報セキュリティの確保に関する共通基本仕様Ⅰ 情報セキュリティポリシーの遵守１ 受託者は、担当部署から農林水産省における情報セキュリティの確保に関する規則(平成27 年農林水産省訓令第４号。以下「規則」という。)等の説明を受けるとともに、本業務に係る情報セキュリティ要件を遵守すること。 なお、規則は、政府機関等のサイバーセキュリティ対策のための統一基準群(以下「統一基準群」という。)に準拠することとされていることから、受託者は、統一基準群の改定を踏まえて規則が改正された場合には、本業務に関する影響分析を行うこと。 ２ 受託者は、規則と同等の情報セキュリティ管理体制を整備していること。 ３ 受託者は、本業務の従事者に対して、規則と同等の情報セキュリティ対策の教育を実施していること。 Ⅱ 応札者に関する情報の提供１ 応札者は、応札者の資本関係・役員等の情報、本業務の実施場所、本業務の従事者(契約社員、派遣社員等の雇用形態は問わず、本業務に従事する全ての要員)の所属・専門性(保有資格、研修受講実績等)・実績(業務実績、経験年数等)及び国籍に関する情報を記載した資料を提出すること。 なお、本業務に従事する全ての要員に関する情報を記載することが困難な場合は、本業務に従事する主要な要員に関する情報を記載するとともに、本業務に従事する部門等における従事者に関する情報(○○国籍の者が△名(又は□％)等)を記載すること。 また、この場合であっても、担当部署からの要求に応じて、可能な限り要員に関する情報を提供すること。 ２ 応札者は、本業務を実施する部署、体制等の情報セキュリティ水準を証明する以下のいずれかの証明書等の写しを提出すること。 (提出時点で有効期限が切れていないこと。)(１)ISO/IEC27001等の国際規格とそれに基づく認証の証明書等(２)プライバシーマーク又はそれと同等の認証の証明書等(３)独立行政法人情報処理推進機構(IPA)が公開する「情報セキュリティ対策ベンチマーク」を利用した自己評価を行い、その評価結果において、全項目に係る平均値が４に達し、かつ各評価項目の成熟度が２以上であることが確認できる確認書Ⅲ 業務の実施における情報セキュリティの確保１ 受託者は、本業務の実施に当たって、以下の措置を講ずること。 なお、応札者は、以下の措置を講ずることを証明する資料を提出すること。 (１)本業務上知り得た情報(公知の情報を除く。)については、契約期間中はもとより契約終了後においても、第三者に開示し、又は本業務以外の目的で利用しないこと。 - 2 -(２)本業務に従事した要員が異動、退職等をした後においても有効な守秘義務契約を締結すること。 (３)本業務に係る情報を適切に取り扱うことが可能となるよう、情報セキュリティ対策の実施内容及び管理体制を整備すること。 なお、本業務実施中及び実施後において検証が可能となるよう、必要なログの取得や作業履歴の記録等を行う実施内容及び管理体制とすること。 (４)本業務において、個人情報又は農林水産省における要機密情報を取り扱う場合は、当該情報(複製を含む。以下同じ。)を国内において取り扱うものとし、当該情報の国外への送信・保存や当該情報への国外からのアクセスを行わないこと。 (５)農林水産省が情報セキュリティ監査の実施を必要と判断した場合は、農林水産省又は農林水産省が選定した事業者による立入調査等の情報セキュリティ監査(サイバーセキュリティ基本法(平成 26 年法律第 104 号)第 26 条第１項第２号に基づく監査等を含む。 以下同じ。 )を受け入れること。 また、担当部署からの要求があった場合は、受託者が自ら実施した内部監査及び外部監査の結果を報告すること。 (６)本業務において、要安定情報を取り扱うなど、担当部署が可用性を確保する必要があると認めた場合は、サービスレベルの保証を行うこと。 (７)本業務において、第三者に情報が漏えいするなどの情報セキュリティインシデントが発生した場合は、担当部署に対し、速やかに電話、口頭等で報告するとともに、報告書を提出すること。 また、農林水産省の指示に従い、事態の収拾、被害の拡大防止、復旧、再発防止等に全力を挙げること。 なお、これらに要する費用の全ては受託者が負担すること。 ２ 受託者は、委託期間を通じて以下の措置を講ずること。 (１)情報の適正な取扱いのため、取り扱う情報の格付等に応じ、以下に掲げる措置を全て含む情報セキュリティ対策を実施すること。 また、実施が不十分の場合、農林水産省と協議の上、必要な改善策を立案し、速やかに実施するなど、適切に対処すること。 ア 情報セキュリティインシデント等への対処能力の確立・維持イ 情報へアクセスする主体の識別とアクセスの制御ウ ログの取得・監視エ 情報を取り扱う機器等の物理的保護オ 情報を取り扱う要員への周知と統制カ セキュリティ脅威に対処するための資産管理・リスク評価キ 取り扱う情報及び当該情報を取り扱うシステムの完全性の保護ク セキュリティ対策の検証・評価・見直し(２)本業務における情報セキュリティ対策の履行状況を定期的に報告すること。 (３)本業務において情報セキュリティインシデントの発生、情報の目的外使用等を認知した場合、直ちに委託事業の一時中断等、必要な措置を含む対処を実施すること。 (４)私物(本業務の従事者個人の所有物等、受託者管理外のものをいう。)の機器等を本業務に用いないこと。 - 3 -(５)本業務において取り扱う情報が本業務上不要となった場合、担当部署の指示に従い返却又は復元できないよう抹消し、その結果を担当部署に書面で報告すること。 ３ 受託者は、委託期間の終了に際して以下の措置を講ずること。 (１)本業務の実施期間を通じてセキュリティ対策が適切に実施されたことを書面等により報告すること。 (２)成果物等を電磁的記録媒体により納品する場合には、不正プログラム対策ソフトウェアによる確認を行うなどして、成果物に不正プログラムが混入することのないよう、適切に対処するとともに、確認結果(確認日時、不正プログラム対策ソフトウェアの製品名、定義ファイルのバージョン等)を成果物等に記載又は添付すること。 (３)本業務において取り扱われた情報を、担当部署の指示に従い返却又は復元できないよう抹消し、その結果を担当部署に書面で報告すること。 ４ 受託者は、情報セキュリティの観点から調達仕様書で求める要件以外に必要となる措置がある場合には、担当部署に報告し、協議の上、対策を講ずること。 Ⅳ 情報システムにおける情報セキュリティの確保１ 受託者は、本業務において情報システムに関する業務を行う場合には、以下の措置を講ずること。 なお、応札者は、以下の措置を講ずることを証明する資料を提出すること。 (１)本業務の各工程において、農林水産省の意図しない情報システムに関する変更や機密情報の窃取等が行われないことを保証する管理が、一貫した品質保証体制の下でなされていること(例えば、品質保証体制の責任者や各担当者がアクセス可能な範囲等を示した管理体制図、第三者機関による品質保証体制を証明する書類等を提出すること。)。 (２)本業務において、農林水産省の意図しない変更が行われるなどの不正が見つかったときに、追跡調査や立入調査等、農林水産省と連携して原因を調査し、排除するための手順及び体制(例えば、システムの操作ログや作業履歴等を記録し、担当部署から要求された場合には提出するなど)を整備していること。 ２ 受託者は、本業務において情報システムの運用管理機能又は設計・開発に係る企画・要件定義を行う場合には、以下の措置を実施すること。 (１)情報システム運用時のセキュリティ監視等の運用管理機能を明確化し、情報システム運用時に情報セキュリティ確保のために必要となる管理機能や監視のために必要な機能を本業務の成果物へ適切に反映するために、以下を含む措置を実施すること。 ア 情報システム運用時に情報セキュリティ確保のために必要となる管理機能を本業務の成果物に明記すること。 イ 情報セキュリティインシデントの発生を監視する必要がある場合、監視のために必要な機能について、以下を例とする機能を本業務の成果物に明記すること。 (ア)農林水産省外と通信回線で接続している箇所における外部からの不正アクセスやサ- 4 -ービス不能攻撃を監視する機能(イ)不正プログラム感染や踏み台に利用されること等による農林水産省外への不正な通信を監視する機能(ウ)端末等の農林水産省内ネットワークの末端に位置する機器及びサーバ装置において不正プログラムの挙動を監視する機能(エ)農林水産省内通信回線への端末の接続を監視する機能(オ)端末への外部電磁的記録媒体の挿入を監視する機能(カ)サーバ装置等の機器の動作を監視する機能(キ)ネットワークセグメント間の通信を監視する機能(２)開発する情報システムに関連する脆(ぜい)弱性への対策が実施されるよう、以下を含む対策を本業務の成果物に明記すること。 ア 既知の脆(ぜい)弱性が存在するソフトウェアや機能モジュールを情報システムの構成要素としないこと。 イ 開発時に情報システムに脆(ぜい)弱性が混入されることを防ぐためのセキュリティ実装方針を定めること。 ウ セキュリティ侵害につながる脆(ぜい)弱性が情報システムに存在することが発覚した場合に修正が施されること。 エ ソフトウェアのサポート期間又はサポート打ち切り計画に関する情報を提供すること。 (３)開発する情報システムに意図しない不正なプログラム等が組み込まれないよう、以下を全て含む対策を本業務の成果物に明記すること。 ア 情報システムで利用する機器等を調達する場合は、意図しない不正なプログラム等が組み込まれていないことを確認すること。 イ アプリケーション・コンテンツの開発時に意図しない不正なプログラム等が混入されることを防ぐための対策を講ずること。 ウ 情報システムの構築を委託する場合は、委託先において農林水産省が意図しない変更が加えられないための管理体制を求めること。 (４)要安定情報を取り扱う情報システムを構築する場合は、許容される停止時間を踏まえて、情報システムを構成する要素ごとに、以下を全て含むセキュリティ要件を定め、本業務の成果物に明記すること。 ア 端末、サーバ装置及び通信回線装置等の冗長化に関する要件イ 端末、サーバ装置及び通信回線装置並びに取り扱われる情報に関するバックアップの要件ウ 情報システムを中断することのできる時間を含めた復旧に関する要件(５)開発する情報システムのネットワーク構成について、以下を全て含む要件を定め、本業務の成果物に明記すること。 ア インターネットやインターネットに接点を有する情報システム(クラウドサービスを含- 5 -む。)から分離することの要否の判断及びインターネットから分離するとした場合に、分離を確実にするための要件イ 端末、サーバ装置及び通信回線装置上で利用するソフトウェアを実行するために必要な通信要件ウ インターネット上のクラウドサービス等のサービスを利用する場合の通信経路全般のネットワーク構成に関する要件エ 農林水産省外通信回線を経由して機器等に対してリモートメンテナンスすることの要否の判断とリモートメンテナンスすることとした場合の要件３ 受託者は、本業務において情報システムの構築を行う場合には、以下の事項を含む措置を適切に実施すること。 (１)情報システムのセキュリティ要件の適切な実装ア 主体認証機能イ アクセス制御機能ウ 権限管理機能エ 識別コード・主体認証情報の付与管理オ ログの取得・管理カ 暗号化機能・電子署名機能キ 暗号化・電子署名に係る管理ク 監視機能ケ ソフトウェアに関する脆(ぜい)弱性等対策コ 不正プログラム対策サ サービス不能攻撃対策シ 標的型攻撃対策ス 動的なアクセス制御セ アプリケーション・コンテンツのセキュリティソ 政府ドメイン名(go.jp)の使用タ 不正なウェブサイトへの誘導防止チ 農林水産省外のアプリケーション・コンテンツの告知(２)監視機能及び監視のための復号・再暗号化監視のために必要な機能について、２(１)イの各項目を例として必要な機能を設けること。 また、不正な変更が発見された場合に、農林水産省と受託者が連携して原因を調査・排除できる体制を整備していること。 ３ 機器等の設置時や保守時に、情報セキュリティの確保に必要なサポートを行うこと。 ４ 利用マニュアル・ガイダンスが適切に整備された機器等を採用すること。 ５ 脆(ぜい)弱性検査等のテストが実施されている機器等を採用し、そのテストの結果が確認できること。 ６ ISO/IEC 15408 に基づく認証を取得している機器等を採用することが望ましい。 なお、当該認証を取得している場合は、証明書等の写しを提出すること。 (提出時点で有効期限が切れていないこと。)７ 情報システムを構成するソフトウェアについては、運用中にサポートが終了しないよう、サポート期間が十分に確保されたものを選定し、可能な限り最新版を採用するとともに、ソフトウェアの種類、バージョン及びサポート期限について報告すること。 なお、サポート期限が事前に公表されていない場合は、情報システムのライフサイクルを踏まえ、販売からの経過年数や後継ソフトウェアの有無等を考慮して選定すること。 ８ 機器等の納品時に、以下の事項を書面で報告すること。 (１)調達仕様書に指定されているセキュリティ要件の実装状況(セキュリティ要件に係る試験- 14 -の実施手順及び結果)(２)機器等に不正プログラムが混入していないこと(最新の定義ファイル等を適用した不正プログラム対策ソフトウェア等によるスキャン結果、内部監査等により不正な変更が加えられていないことを確認した結果等)Ⅸ 管轄裁判所及び準拠法１ 本業務に係る全ての契約(クラウドサービスを含む。以下同じ。)に関して訴訟の必要が生じた場合の専属的な合意管轄裁判所は、国内の裁判所とすること。 ２ 本業務に係る全ての契約の成立、効力、履行及び解釈に関する準拠法は、日本法とすること。 Ⅹ 業務の再委託における情報セキュリティの確保１ 受託者は、本業務の一部を再委託(再委託先の事業者が受託した事業の一部を別の事業者に委託する再々委託等、多段階の委託を含む。以下同じ。)する場合には、受託者が上記Ⅱの１、Ⅱの２、Ⅲの１及びⅣの１において提出することとしている資料等と同等の再委託先に関する資料等並びに再委託対象とする業務の範囲及び再委託の必要性を記載した申請書を提出し、農林水産省の許可を得ること。 ２ 受託者は、本業務に係る再委託先の行為について全責任を負うものとする。 また、再委託先に対して、受託者と同等の義務を負わせるものとし、再委託先との契約においてその旨を定めること。 なお、情報セキュリティ監査については、受託者による再委託先への監査のほか、農林水産省又は農林水産省が選定した事業者による再委託先への立入調査等の監査を受け入れるものとすること。 ３ 受託者は、担当部署からの要求があった場合は、再委託先における情報セキュリティ対策の履行状況を報告すること。 Ⅺ 資料等の提出上記Ⅱの１、Ⅱの２、Ⅲの１、Ⅳの１、Ⅴの６、Ⅴの７、Ⅴの８、Ⅵの１(５)、Ⅵの１(６)、Ⅵの１(８)、Ⅷの１及びⅧの６において提出することとしている資料等については、最低価格落札方式にあっては入札公告及び入札説明書に定める証明書等の提出場所及び提出期限に従って提出し、総合評価落札方式及び企画競争方式にあっては提案書等の評価のための書類に添付して提出すること。 Ⅻ 変更手続受託者は、上記Ⅱ、Ⅲ、Ⅳ、Ⅴ、Ⅵ、Ⅶ、Ⅷ及びⅩに関して、農林水産省に提示した内容を変更しようとする場合には、変更する事項、理由等を記載した申請書を提出し、農林水産省の許可を得ること。 AWS/Azure設定確認リスト 凡例：〇：責任者、△：サポートMAFFクラウド管理者(PMO) PJMOIDおよびアクセス管理組織が許可したアカウントの管理 〇管理者アカウントに対する多要素認証の利用 △ 〇 多要素認証を設定していない限りあらゆるAWS/Azureリソースの操作が出来ないよう設定管理者アカウントに紐づく最新の連絡先の登録と定期的な見直し △ 〇 年度末に実施必要最低限の管理者権限の割当て △ 〇AWS：Configを利用して実施Azure：Azure Policyを利用して実施グループを利用した権限の設定 〇管理者アカウントに関する復旧手段の確保 〇すべてのアカウントへのパスワードポリシーの適用 △ 〇AWS：Configを利用して実施Azure：Azure Policyを利用して実施アクセスキー、サービスアカウントキー等の適切な管理 〇管理者アカウントと日常的に使用するアカウントの分離 〇 ユーザーの払い出しはPJMO管理アカウント・権限・認証情報の定期的な見直し 〇 年度末に実施AWSにおいて考慮すべき設定AWS サポートセンターへのアクセス設定 〇IAMに保存されているサーバ証明書の管理 〇IAM Access analyzerの有効化 〇Azureにおいて考慮すべき設定Microsoft Azure サポートセンターへのアクセス設定 〇Azure App Serviceに保存されているサーバ証明書の管理 〇ログの記録と監視ログの有効化及び取得 △ 〇 MAFFクラウド管理者側で有効化の為の手順を作成し、PJMOに配布ログの一元管理 △ 〇ログの保護 △ 〇 管理者アカウントで保管ログの監視/通知の設定 △ 〇AWS：アクセスログなどは管理者アカウント側でGuardDutyを用いて対応。 Azure：アクセスログなどは管理アカウント側でMicrosoft Defender for Cloudを用いて対応。 そのほかのログについてはPJMOに一任。 ネットワークロードバランサの接続設定 〇仮想マシン最新のOSパッチの適用確認 〇不正プログラム対策ソフトウェアの導入 〇攻撃対象となるネットワークポートへのアクセス制限 〇ストレージ匿名/公開アクセスの禁止 △ 〇 不適切設定を有効化し、管理者アカウントで監視ストレージアクセスの通信設定 △ 〇 不適切設定を有効化し、管理者アカウントで監視AWSにおいて考慮すべき設定Amazon RDSの暗号化 △ 〇 不適切設定を有効化し、管理者アカウントで監視MFA Deleteの有効化 △ 〇 不適切設定を有効化し、管理者アカウントで監視Amazon EBSの暗号化 △ 〇 不適切設定を有効化し、管理者アカウントで監視Azureにおいて考慮すべき設定Azure Databaseの暗号化 △ 〇 不適切設定を有効化し、管理者アカウントで監視MFA Deleteの有効化 △ 〇 不適切設定を有効化し、管理者アカウントで監視Azure Disk Storageの暗号化 △ 〇 不適切設定を有効化し、管理者アカウントで監視【PaaS/IaaS】基本的な設定すべきセキュリティ対策(AWS/Azure)担当役割分担に関する補足別紙5Webシステム／Webアプリケーションセキュリティ要件書 Ver.4.0項⽬ ⾒出し 要件 備考 必須可否1 認証・認可 1.1 ユーザー認証 1.1.1 特定のユーザーや管理者のみに表⽰・実⾏を許可すべき画⾯や機能、APIでは、ユーザー認証を実施すること特定のユーザーや管理者のみにアクセスを許可したいWebシステムでは、ユーザー認証を⾏う必要があります。 また、ユーザー認証が成功した後にはアクセス権限を確認する必要があります。 そのため、認証済みユーザーのみがアクセス可能な箇所を明⽰しておくことが望ましいでしょう。 リスクベース認証や⼆要素認証など認証をより強固にする仕組みもあります。 不特定多数がアクセスする必要がない場合には、IPアドレスなどによるアクセス制限も効果があります。 OpenIDなどIdP(ID Provider)を利⽤する場合には信頼できるプロバイダであるかを確認する必要があります。 IdPを使った認証・認可を⾏う場合も他の認証・認可に関する要件を満たすものを利⽤することが望ましいです。 必須1.1.2 上記画⾯や機能に含まれる画像やファイルなどの個別のコンテンツ(⾮公開にすべきデータは直接URLで指定できる公開ディレクトリに配置しない)では、ユーザー認証を実施すること必須1.1.3 多要素認証を実施すること 多要素認証(Multi Factor Authentication: MFA)とは、例えばパスワードによる認証に加え、TOTP (Time-Based One-Time Password：時間ベースのワンタイムパスワード)やデジタル証明書など⼆つ以上の要素を利⽤した認証⽅式です。 ⼿法については NIST Special Publication 800-63B などを参照してください。 推奨1.2 ユーザーの再認証 1.2.1 個⼈情報や機微情報を表⽰するページに遷移する際には、再認証を実施することユーザー認証はセッションにおいて最初の⼀度だけ実施するのではなく、重要な情報や機能へアクセスする際には再認証を⾏うことが望ましいでしょう。 推奨1.2.2 パスワード変更や決済処理などの重要な機能を実⾏する際には、再認証を実施すること推奨1.3 パスワード 1.3.1 ユーザー⾃⾝が設定するパスワード⽂字列は最低 8⽂字以上であること 認証を必要とするWebシステムの多くは、パスワードを本⼈確認の⼿段として認証処理を⾏います。 そのためパスワードを盗聴や盗難などから守ることが重要になります。 必須1.3.2 登録可能なパスワード⽂字列の最⼤⽂字数は64⽂字以上であること パスワードを処理する関数の中には最⼤⽂字数が少ないものもあるので注意する必要があります。 必須1.3.3 パスワード⽂字列として使⽤可能な⽂字種は制限しないこと 任意の⼤⼩英字、数字、記号、空⽩、Unicode⽂字など任意の⽂字が利⽤可能である必要があります。 必須1.3.4 パスワード⽂字列の⼊⼒フォームはinput type="password"で指定すること基本的にinputタグのtype属性には「password」を指定しますが、パスワードを⼀時的に表⽰する可視化機能を実装する場合にはこの限りではありません。 必須1.3.5 ユーザーが⼊⼒したパスワード⽂字列を次画⾯以降で表⽰しないこと(hiddenフィールドなどのHTMLソース内やメールも含む)必須別紙6Webシステム／Webアプリケーションセキュリティ要件書 Ver.4.0項⽬ ⾒出し 要件 備考 必須可否1.3.6 パスワードを保存する際には、平⽂で保存せず、Webアプリケーションフレームワークなどが提供するハッシュ化とsaltを使⽤して保存する関数を使⽤すること関数が存在しない場合にはパスワードは「パスワード⽂字列＋salt(ユーザー毎に異なるランダムな⽂字列)」をハッシュ化したものとsaltのみを保存する必要があります。 (saltは20⽂字以上であることが望ましい)パスワード⽂字列のハッシュ化をさらに安全にする⼿法としてストレッチングがあります。 必須1.3.7 ユーザー⾃⾝がパスワードを変更できる機能を⽤意すること 必須1.3.8 パスワードはユーザー⾃⾝に設定させることシステムが仮パスワードを発⾏する場合はランダムな⽂字列を設定し、安全な経路でユーザーに通知すること推奨1.3.9 パスワードの⼊⼒欄でペースト機能を禁⽌しないこと ⻑いパスワードをユーザーが利⽤出来るようにするためにペースト機能を禁⽌しないようにする必要があります。 推奨1.3.10 パスワード強度チェッカーを実装すること 使⽤する⽂字種や⽂字数を確認し、ユーザー⾃⾝にパスワードの強度を⽰せるようにします。 またユーザーIDと同じ⽂字列や漏洩したパスワードなどのリストとの突合を⾏う必要があります。 ⼿法については NISTSpecial Publication 800-63B などを参照してください。 推奨1.4 アカウントロック機能について 1.4.1 認証時に無効なパスワードで10回試⾏があった場合、最低30分間はユーザーがロックアウトされた状態にすることパスワードに対する総当たり攻撃や辞書攻撃などから守るためには、試⾏速度を遅らせるアカウントロック機能の実装が有効な⼿段になります。 アカウントロックの試⾏回数、ロックアウト時間については、サービスの内容に応じて調整することが必要になります。 必須1.4.2 ロックアウトは⾃動解除を基本とし、⼿動での解除は管理者のみ実施可能とすること推奨1.5 パスワードリセット機能について 1.5.1 パスワードリセットを実⾏する際にはユーザー本⼈しか受け取れない連絡先(あらかじめ登録しているメールアドレス、電話番号など)にワンタイムトークンを含むURLなどの再設定⽅法を通知すること連絡先については、事前に受け取り確認をしておくことでより安全性を⾼めることができます。 使⽤されたワンタイムトークンは破棄し、有効期限を12時間以内とし必要最低限に設定してください。 必須1.5.2 パスワードはユーザー⾃⾝に再設定させること 必須1.6 アクセス制御について 1.6.1 Web ページや機能、データをアクセス制御(認可制御)する際には認証情報・状態を元に権限があるかどうかを判別すること認証により何らかの制限を⾏う場合には、利⽤しようとしている情報や機能へのアクセス(読み込み・書き込み・実⾏など)権限を確認することでアクセス制御を⾏うことが必要になります。 画像やファイルなどのコンテンツ、APIなどの機能に対しても、全て個別にアクセス権限を設定、確認する必要があります。 これらはアクセス権限の⼀覧表に基づいて⾏います。 CDNなどを利⽤してコンテンツを配置するなどアクセス制御を⾏うことが困難な場合、予測が困難なURLを利⽤することでアクセスされにくくする⽅法もあります。 必須Webシステム／Webアプリケーションセキュリティ要件書 Ver.4.0項⽬ ⾒出し 要件 備考 必須可否1.6.2 公開ディレクトリには公開を前提としたファイルのみ配置すること 公開ディレクトリに配置したファイルは、URLを直接指定することでアクセスされる可能性があります。 そのため、機微情報や設定ファイルなどの公開する必要がないファイルは、公開ディレクトリ以外に配置する必要があります。 必須1.7 アカウントの無効化機能について 1.7.1 管理者がアカウントの有効・無効を設定できること 不正にアカウントを利⽤されていた場合に、アカウントを無効化することで被害を軽減することができます。 推奨2 セッション管理2.1 セッションの破棄について 2.1.1 認証済みのセッションが⼀定時間以上アイドル状態にあるときはセッションタイムアウトとし、サーバー側のセッションを破棄しログアウトすること認証を必要とするWebシステムの多くは、認証状態の管理にセッションIDを使ったセッション管理を⾏います。 認証済みの状態にあるセッションを不正に利⽤されないためには、使われなくなったセッションを破棄する必要があります。 セッションタイムアウトの時間については、サービスの内容やユーザー利便性に応じて設定することが必要になります。 また、NIST Special Publication 800-63B などを参照してください。 必須2.1.2 ログアウト機能を⽤意し、ログアウト実⾏時にはサーバー側のセッションを破棄することログアウト機能の実⾏後にその成否をユーザーが確認できることが望ましい。 必須2.2 セッションIDについて 2.2.1 Webアプリケーションフレームワークなどが提供するセッション管理機能を使⽤することセッションIDを⽤いて認証状態を管理する場合、セッションIDの盗聴や推測、攻撃者が指定したセッションIDを使⽤させられる攻撃などから守る必要があります。 また、セッションIDは原則としてcookieにのみ格納すべきです。 必須2.2.2 セッションIDは認証成功後に発⾏すること認証前にセッションIDを発⾏する場合は、認証成功直後に新たなセッションIDを発⾏すること必須2.2.3 ログイン前に機微情報をセッションに格納する時点でセッションIDを発⾏または再⽣成すること必須2.2.4 認証済みユーザーの特定はセッションに格納した情報を元に⾏うこと 必須2.3 CSRF(クロスサイトリクエストフォージェリー)対策の実施について2.3.1 ユーザーにとって重要な処理を⾏う箇所では、ユーザー本⼈の意図したリクエストであることを確認できるようにすること正規ユーザー以外の意図により操作されては困る処理を⾏う箇所では、フォーム⽣成の際に他者が推測困難なランダムな値(トークン)をhiddenフィールドやcookie以外のヘッダーフィールド(X-CSRF-TOKENなど)に埋め込み、リクエストをPOSTメソッドで送信します。 フォームデータを処理する際にトークンが正しいことを確認することで、正規ユーザーの意図したリクエストであることを確認することができます。 また、別の⽅法としてパスワード再⼊⼒による再認証を求める⽅法もあります。 cookieのSameSite属性を適切に使うことによって、CSRFのリスクを低減する効果があります。 SameSite属性は⼀部の状況においては効果がないこともあるため、トークンによる確認が推奨されます。 必須3 ⼊⼒処理 3.1 パラメーターについて 3.1.1 URLにユーザーID やパスワードなどの機微情報を格納しないこと URLは、リファラー情報などにより外部に漏えいする可能性があります。 そのため URLには秘密にすべき情報は格納しないようにする必要があります。 必須Webシステム／Webアプリケーションセキュリティ要件書 Ver.4.0項⽬ ⾒出し 要件 備考 必須可否3.1.2 パラメーター(クエリーストリング、エンティティボディ、cookieなどクライアントから受け渡される値)にパス名を含めないことファイル操作を⾏う機能などにおいて、URL パラメーターやフォームで指定した値でパス名を指定できるようにした場合、想定していないファイルにアクセスされてしまうなどの不正な操作を実⾏されてし まう可能性があります。 必須3.1.3 パラメーター要件に基づいて、⼊⼒値の⽂字種や⽂字列⻑の検証を⾏うこと各パラメーターは、機能要件に基づいて⽂字種・⽂字列⻑・形式を定義する必要があります。 ⼊⼒値に想定している⽂字種や⽂字列⻑以外の値の⼊⼒を許してしまう場合、不正な操作を実⾏されてしまう可能性があります。 サーバー側でパラメーターを受け取る場合、クライアント側での⼊⼒値検証の有無に関わらず、⼊⼒値の検証はサーバー側で実施する必要があります。 必須3.2 ファイルアップロードについて 3.2.1 ⼊⼒値としてファイルを受け付ける場合には、拡張⼦やファイルフォーマットなどの検証を⾏うことファイルのアップロード機能を利⽤した不正な実⾏を防ぐ必要があります。 画像ファイルを扱う場合には、ヘッダー領域を不正に加⼯したファイルにも注意が必要です。 必須3.2.2 アップロード可能なファイルサイズを制限すること 圧縮ファイルを展開する場合には、解凍後のファイルサイズや、ファイルパスやシンボリックリンクを含む場合のファイルの上書きにも注意が必要です。 必須3.3 XMLを使⽤する際の処理について 3.3.1 XMLを読み込む際は、外部参照を無効にすること ⼿法についてはXML External Entity Prevention Cheat Sheetなどを参照してください。 https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html必須3.4 デシリアライズについて 3.4.1 信頼できないデータ供給元からのシリアライズされたオブジェクトを受け⼊れないことデシリアライズする場合は、シリアライズしたオブジェクトにデジタル署名などを付与し、信頼できる供給元が発⾏したデータであるかを検証してください。 必須3.5 外部リソースへのリクエスト送信について 3.5.1 他システムに接続や通信を⾏う場合は、外部からの⼊⼒によって接続先を動的に決定しないこと外部から不正なURLやIPアドレスなどが挿⼊されると、SSRF(Server-Side Request Forgery)の脆弱性になる可能性があります。 外部からの⼊⼒によって接続先を指定せざるを得ない場合は、ホワイトリストを基に⼊⼒値の検証を実施するとともに、アプリケーションレイヤーだけではなくネットワークレイヤーでのアクセス制御も併⽤する必要があります。 推奨4 出⼒処理 4.1 HTMLを⽣成する際の処理について 4.1.1 HTMLとして特殊な意味を持つ⽂字( " ' &)を⽂字参照によりエスケープすること外部からの⼊⼒により不正なHTMLタグなどが挿⼊されてしまう可能性があります。 「<」→「<」や「&」→「&」、「"」→「"」のようにエスケープを⾏う必要があります。 スクリプトによりクライアント側でHTMLを⽣成する場合も、同等の処理が必要です。 実装の際にはこれらを⾃動的に実⾏するフレームワークやライブラリを使⽤することが望ましいでしょう。 また、その他にもスクリプトの埋め込みの原因となるものを作らないようにする必要があります。 XMLを⽣成する場合も同様にエスケープが必要です。 必須4.1.2 外部から⼊⼒したURLを出⼒するときは「http://」または「https://」で始まるもののみを許可すること必須Webシステム／Webアプリケーションセキュリティ要件書 Ver.4.0項⽬ ⾒出し 要件 備考 必須可否4.1.3 .要素の内容やイベントハンドラ(onmouseover=””など)を動的に⽣成しないようにすること.要素の内容やイベントハンドラは原則として動的に⽣成しないようにすべきですが、jQueryなどのAjaxライブラリを使⽤する際はその限りではありません。 ライブラリについては、アップデート状況などを調べて信頼できるものを選択するようにしましょう。 必須4.1.4 任意のスタイルシートを外部サイトから取り込めないようにすること 必須4.1.5 HTMLタグの属性値を「"」で囲うこと HTMLタグ中のname=”value”で記される値(value)にユーザーの⼊⼒値を使う場合、「”」で囲わない場合、不正な属性値を追加されてしまう可能性があります。 必須4.1.6 CSSを動的に⽣成しないこと 外部からの⼊⼒により不正なCSSが挿⼊されると、ブラウザに表⽰される画⾯が変更されたり、スクリプトが埋め込まれる可能性があります。 必須4.2 JSONを⽣成する際の処理について 4.2.1 ⽂字列連結でJSON⽂字列を⽣成せず、適切なライブラリを⽤いてオブジェクトをJSONに変換すること適切なライブラリがない場合は、JSONとして特殊な意味を持つ⽂字( " \, : { } [ ] )をUnicodeエスケープする必要があります。 必須4.3 HTTPレスポンスヘッダーについて 4.3.1 HTTPレスポンスヘッダーのContent-Typeを適切に指定すること ⼀部のブラウザではコンテンツの⽂字コードやメディアタイプを誤認識させることで不正な操作が⾏える可能性があります。 これを防ぐためには、HTTPレスポンスヘッダーを「Content-Type: text/html; charset=utf-8」のように、コンテンツの内容に応じたメディアタイプと⽂字コードを指定する必要があります。 必須4.3.2 HTTPレスポンスヘッダーフィールドの⽣成時に改⾏コードが⼊らないようにすることHTTPヘッダーフィールドの⽣成時にユーザーが指定した値を挿⼊できる場合、改⾏コードを⼊⼒することで不正なHTTPヘッダーやコンテンツを挿⼊されてしまう可能性があります。 これを防ぐためには、HTTPヘッダーフィールドを⽣成する専⽤のライブラリなどを使うようにすることが望ましいでしょう。 必須4.4 その他の出⼒処理について 4.4.1 SQL⽂を組み⽴てる際に静的プレースホルダを使⽤すること SQL⽂の組み⽴て時に不正なSQL⽂を挿⼊されることで、SQLインジェクションを実⾏されてしまう可能性があります。 これを防ぐためにはSQL⽂を動的に⽣成せず、プレースホルダを使⽤してSQL⽂を組み⽴てるようにする必要があります。 静的プレースホルダとは、JIS/ISOの規格で「準備された⽂(PreparedStatement)」と規定されているものです。 必須4.4.2 プログラム上でOSコマンドやアプリケーションなどのコマンド、シェル、eval()などによるコマンドの実⾏を呼び出して使⽤しないことコマンド実⾏時にユーザーが指定した値を挿⼊できる場合、外部から任意のコマンドを実⾏されてしまう可能性があります。 コマンドを呼び出して使⽤しないことが望ましいでしょう。 必須4.4.3 リダイレクタを使⽤する場合には特定のURLのみに遷移できるようにすることリダイレクタのパラメーターに任意のURLを指定できる場合(オープンリダイレクタ)、攻撃者が指定した悪意のあるURLなどに遷移させられる可能性があります。 必須4.4.4 メールヘッダーフィールドの⽣成時に改⾏コードが⼊らないようにすることメールの送信処理にユーザーが指定した値を挿⼊できる場合、不正なコマンドなどを挿⼊されてしまう可能性があります。 これを防ぐためには、不正な改⾏コードを使⽤できないメール送信専⽤のライブラリなどを使うようにすることが望ましいでしょう。 必須Webシステム／Webアプリケーションセキュリティ要件書 Ver.4.0項⽬ ⾒出し 要件 備考 必須可否4.4.5 サーバ側のテンプレートエンジンを使⽤する際に、テンプレートの変更や作成に外部から受け渡される値を使⽤しないことサーバ側のテンプレートエンジンを使⽤してテンプレートを組み⽴てる際に不正なテンプレートの構⽂を挿⼊されることで、任意のコードを実⾏される可能性があります。 外部から渡される値をテンプレートの組み⽴てに使⽤せず、レンダリングを⾏う際のデータとして使⽤する必要があります。 また、レンダリング時にはクロスサイトスクリプティングの脆弱性が存在しないか確認してください。 必須5 HTTPS 5.1 HTTPSについて 5.1.1 Webサイトを全てHTTPSで保護すること 適切にHTTPSを使うことで通信の盗聴・改ざん・なりすましから情報を守ることができます。 次のような重要な情報を扱う画⾯や機能ではHTTPSで通信を⾏う必要があります。 ・⼊⼒フォームのある画⾯・⼊⼒フォームデータの送信先・重要情報が記載されている画⾯・セッションIDを送受信する画⾯HTTPSの画⾯内で読み込む画像やスクリプトなどのコンテンツについてもHTTPSで保護する必要があります。 必須5.1.2 サーバー証明書はアクセス時に警告が出ないものを使⽤すること HTTPSで提供されているWebサイトにアクセスした場合、Webブラウザから何らかの警告がでるということは、適切にHTTPSが運⽤されておらず盗聴・改ざん・なりすましから守られていません。 適切なサーバー証明書を使⽤する必要があります。 必須5.1.3 TLS1.2以上のみを使⽤すること SSL2.0／3.0、TLS1.0／1.1には脆弱性があるため、無効化する必要があります。 使⽤する暗号スイートは、7.2.1を参照してください。 必須5.1.4 レスポンスヘッダーにStrict-Transport-Securityを指定すること Hypertext Strict Transport Security(HSTS)を指定すると、ブラウザがHTTPSでアクセスするよう強制できます。 必須6 cookie 6.1 cookieの属性について 6.1.1 Secure属性を付けること Secure属性を付けることで、http://でのアクセスの際にはcookieを送出しないようにできます。 特に認証状態に紐付けられたセッションIDを格納する場合には、Secure属性を付けることが必要です。 必須6.1.2 HttpOnly属性を付けること HttpOnly属性を付けることで、クライアント側のスクリプトからcookieへのアクセスを制限することができます。 必須6.1.3 Domain属性を指定しないこと セッションフィクセイションなどの攻撃に悪⽤されることがあるため、Domain属性は特に必要がない限り指定しないことが望ましいでしょう。 推奨7 その他 7.1 エラーメッセージについて 7.1.1 エラーメッセージに詳細な内容を表⽰しないこと ミドルウェアやデータベースのシステムが出⼒するエラーには、攻撃のヒントになる情報が含まれているため、エラーメッセージの詳細な内容はエラーログなどに出⼒するべきです。 必須Webシステム／Webアプリケーションセキュリティ要件書 Ver.4.0項⽬ ⾒出し 要件 備考 必須可否7.2 暗号アルゴリズムについて 7.2.1 ハッシュ関数、暗号アルゴリズムは『電⼦政府における調達のために参照すべき暗号のリスト(CRYPTREC暗号リスト)』に記載のものを使⽤すること広く使われているハッシュ関数、疑似乱数⽣成系、暗号アルゴリズムの中には安全でないものもあります。 安全なものを使⽤するためには、『電⼦政府における調達のために参照すべき暗号のリスト(CRYPTREC暗号リスト)』や『TLS暗号設定ガイドライン』に記載されたものを使⽤する必要があります。 必須7.3 乱数について 7.3.1 鍵や秘密情報などに使⽤する乱数的性質を持つ値を必要とする場合には、暗号学的な強度を持った疑似乱数⽣成系を使⽤すること鍵や秘密情報に予測可能な乱数を⽤いると、過去に⽣成した乱数値から⽣成する乱数値が予測される可能性があるため、ハッシュ関数などを⽤いて⽣成された暗号学的な強度を持った疑似乱数⽣成系を使⽤する必要があります。 必須7.4 基盤ソフトウェアについて 7.4.1 基盤ソフトウェアはアプリケーションの稼働年限以上のものを選定すること脆弱性が発⾒された場合、修正プログラムを適⽤しないと悪⽤される可能性があります。 そのため、⾔語やミドルウェア、ソフトウェアの部品などの基盤ソフトウェアは稼働期間またはサポート期間がアプリケーションの稼働期間以上のものを利⽤する必要があります。 もしアプリケーションの稼働期間中に基盤ソフトウェアの保守期間が終了した場合、危険な脆弱性が残されたままになる可能性があります。 必須7.4.2 既知の脆弱性のないOSやミドルウェア、ライブラリやフレームワーク、パッケージなどのコンポーネントを使⽤すること利⽤コンポーネントにOSSが含まれる場合は、SCA(ソフトウェアコンポジション解析)ツールを導⼊し、依存関係を包括的かつ正確に把握して対策が⾏えることが望ましいでしょう。 必須7.5 ログの記録について 7.5.1 重要な処理が⾏われたらログを記録すること ログは、情報漏えいや不正アクセスなどが発⽣した際の検知や調査に役⽴つ可能性があります。 認証やアカウント情報の変更などの重要な処理が実⾏された場合には、その処理の内容やクライアントのIPアドレスなどをログとして記録することが望ましいでしょう。 ログに機微情報が含まれる場合にはログ⾃体の取り扱いにも注意が必要になります。 必須7.6 ユーザーへの通知について 7.6.1 重要な処理が⾏われたらユーザーに通知すること 重要な処理(パスワードの変更など、ユーザーにとって重要で取り消しが困難な処理)が⾏われたことをユーザーに通知することによって異常を早期に発⾒できる可能性があります。 推奨7.7 Access-Control-Allow-Originヘッダーについて7.7.1 Access-Control-Allow-Originヘッダーを指定する場合は、動的に⽣成せず固定値を使⽤することクロスオリジンでXMLHttpRequest (XHR)を使う場合のみこのヘッダーが必要です。 不要な場合は指定する必要はありませんし、指定する場合も特定のオリジンのみを指定する事が望ましいです。 必須7.8 クリックジャッキング対策について 7.8.1 レスポンスヘッダーにX-Frame-OptionsとContent-Security-Policyヘッダーのframe-ancestors ディレクティブを指定することクリックジャッキング攻撃に悪⽤されることがあるため、X-Frame-OptionsヘッダーフィールドにDENYまたはSAMEORIGINを指定する必要があります。 Content-Security-Policyヘッダーフィールドに frame-ancestors 'none'または 'self' を指定する必要があります。 X-Frame-Options ヘッダーは主要ブラウザーでサポートされていますが標準化されていません。 CSP レベル 2 仕様で frame-ancestors ディレクティブが策定され、X-Frame-Options は⾮推奨とされました。 必須Webシステム／Webアプリケーションセキュリティ要件書 Ver.4.0項⽬ ⾒出し 要件 備考 必須可否7.9 キャッシュ制御について 7.9.1 個⼈情報や機微情報を表⽰するページがキャッシュされないよう Cache-Control: no-store を指定すること個⼈情報や機密情報が含まれたページはCDNやロードバランサー、ブラウザなどのキャッシュに残ってしまうことで、権限のないユーザーが閲覧してしまう可能性があるためキャッシュ制御を適切に⾏う必要があります。 必須7.10 ブラウザのセキュリティ設定について 7.10.1 ユーザーに対して、ブラウザのセキュリティ設定の変更をさせるような指⽰をしないことユーザーのWebブラウザのセキュリティ設定などを変更した場合や、認証局の証明書をインストールさせる操作は、他のサイトにも影響します。 必須7.11 ブラウザのセキュリティ警告について 7.11.1 ユーザーに対して、ブラウザの出すセキュリティ警告を無視させるような指⽰をしないことブラウザの出す警告を通常利⽤においても無視させるよう指⽰をしていると、悪意のあるサイトで同様の指⽰をされた場合もそのような操作をしてしまう可能性が⾼まります。 必須7.12 WebSocketについて 7.12.1 Originヘッダーの値が正しいリクエスト送信元であることが確認できた場合にのみ処理を実施することWebSocketにはSOP (Same Origin Policy)という仕組みが存在しないため、Cross-Site WebSocket Hijacking(CSWSH)対策のためにOriginヘッダーを確認する必要があります。 必須7.13 HTMLについて 7.13.1 html開始タグの前にを宣⾔すること DOCTYPEで⽂書タイプをHTMLと明⽰的に宣⾔することでCSSなど別フォーマットとして解釈されることを防ぎます。 必須7.13.2 CSSファイルやJavaScriptファイルをlinkタグで指定する場合は、絶対パスを使⽤することlinkタグを使⽤してCSSファイルやJavaScriptファイルを相対パス指定した場合にRPO (Relative Path Overwrite) が起きる可能性があります。 必須8 提出物 8.1 提出物について 8.1.1 サイトマップを⽤意すること 認証や再認証、CSRF対策が必要な箇所、アクセス制御が必要なデータを明確にするためには、Webサイト全体の構成を把握し、扱うデータを把握する必要があります。 そのためには上記の資料を⽤意することが望ましいでしょう。 必須8.1.2 画⾯遷移図を⽤意すること 必須8.1.3 アクセス権限⼀覧表を⽤意すること 誰にどの機能の利⽤を許可するかまとめた⼀覧表を作成することが望ましいでしょう。 必須8.1.4 コンポーネント⼀覧を⽤意すること 依存しているライブラリやフレームワーク、パッケージなどのコンポーネントに脆弱性が存在する場合がありますので、依存しているコンポーネントを把握しておく必要があります。 推奨8.1.5 上記のセキュリティ要件についてテストした結果報告書を⽤意すること ⾃社で脆弱性診断を実施する場合には「脆弱性診断⼠スキルマッププロジェクト」が公開している「Webアプリケーション脆弱性診断ガイドライン」などを参照してください。 推奨令和XX年度XXXシステム要件定義書令和XX年XX月農林水産省要件仕様書標準テンプレート(2024/08/27)【凡例】黒字：標準記載多くの案件で汎用的に利用できる文章青字：任意追加記載調達案件の内容、条件に応じて追記する文章別紙71. 業務要件定義.. 1業務実施手順.. 1業務の規模.. 3業務実施の時期・時間.. 4業務の実施等.. 5業務観点で管理すべき指標.. 5情報システム化の範囲.. 6業務の継続の方針等.. 6情報セキュリティ対策の方針等.. 72. 機能要件定義.. 7機能に関する事項.. 7画面に関する事項.. 9帳票に関する事項.. 12データに関する事項.. 13外部インタフェースに関する事項.. 173. 非機能要件定義.. 17ユーザビリティ及びアクセシビリティに関する事項.. 17システム方式に関する事項.. 21システム規模に関する事項.. 24性能に関する事項.. 25信頼性に関する事項.. 27拡張性に関する事項.. 28上位互換性に関する事項.. 28中立性に関する事項.. 29継続性に関する事項.. 30情報セキュリティに関する事項.. 32情報システム稼働環境に関する事項.. 34テストに関する事項.. 37移行に関する事項.. 43引継ぎに関する事項.. 47教育に関する事項.. 50運用に関する事項.. 51保守に関する事項.. 5711. 業務要件定義業務実施手順(1) 業務範囲本システムは原則として現行システムが対象とする業務範囲を踏襲する。 一部業務は業務効率化の観点から機能自体の見直しを想定している。 本システムではXXX機能が新たに業務範囲として追加されるため、留意すること。 現行の本システムが対象とする業務及び情報システム化の範囲を下表に示す。 表 1 業務の範囲(業務機能とその階層)階層０ 階層１ 階層2 新情報システム適用対象候補項番 名称 項番 名称 項番 業務ID 名称1 図書貸出業務1-1 貸出申請1-1-1 A0001 申請作成○1-1-2 A0002 申請提出1-2貸出申請受理1-2-1 A0003 申請受理○1-2-2 A0004 申請内容確認1-3 貸出申請承認 1-3-1 A0005 貸出承認 ○・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・(2) 業務フロー現行システムが対象とする業務及び情報システム化の範囲を下表に示す。 図 1 業務フロー(現行)の定義例2また、次期システムが対象とする業務及び情報システム化の範囲を下表に示す。 なお、本システムで変更予定の業務フローについては該当箇所を明示している。 図 2 業務フロー(将来)の定義例(3) 業務の実施に必要な体制本システム関連業務の実施に現段階で想定する体制について、下表に示す。 表 2 業務の実施体制項番 実施体制 業務概要 補足1サービス課(窓口担当者)窓口における各種手続の受付及び審査、督促等を行う。 XXX2サービス課(貸出承認者)貸出等の最終承認を行う。 XXX3 管理課 蔵書に関する管理業務を行う。 XXX… … … …(4) 入出力情報項目及び取扱量本サービス運用開始後 1 年間程度の入出力情報及び取扱量に関する現段階における見通しを下表に示す。 なお、本システム並びに関連するシステムの利用範囲の拡大に伴い、データの範囲と種類、容量が拡大する可能性もあることを、あらかじめ留意すること。 表 3 入出力情報項目及び取扱量項番 業務処理入出力情報名入出力情報概要入出力の区分主な入出力情報項目取扱量 用途取得元/提供元補足1 貸出申請 貸出申請書 貸出手続の 入力 申請年月 年間約 貸出申請 申請者 XXX3申請書 日、氏名、住所、貸出希望書籍名20,000件2貸出申請承認貸出承認書貸出手続の審査結果通知出力受理年月日、氏名、住所、審査結果等年間約20,000件貸出申請結果通知申請者/サービス課XXX3 蔵書更新蔵書更新情報蔵書の更新を記した帳票入力年月、書籍名、著者名、格納場所等毎月50件 蔵書管理 管理課XXX4 … … … … … … … … …(5) 管理対象情報一覧対象業務で管理すべき情報(管理対象情報)を下表に示す。 表 4 管理対象情報一覧項番管理対象情報名管理単位 主たる用途 主な属性 補足1 書籍情報 書籍情報番号ある書籍のタイトルに紐づく情報を持つ書籍名、ISBN、著者、出版社名、版数、出版年月日、絶版の有無書籍初回購入時に付番2 書籍書籍番号(書籍情報番号＋枝番)ある書籍(物理的な印刷物など)個体に関する情報を持つ購入年月日、貸出回数、廃棄予定日書籍購入時ごとに付番3 貸出申請貸出番号(日付＋連番)利用者が提出した申請書に関する情報を持つ申請年月日、利用者氏名、貸出希望書籍名申請受理時に付番4 利用者 利用者番号利用者に関する情報を持つ氏名、住所、連絡先、利用回数利用者登録時に付番5 ・・・ ・・・ ・・・ ・・・ ・・・業務の規模本システムで実現する業務で想定される規模について、以下に示す。 なお、本システムで実現する業務は、システム構築と合わせて令和 XX 年度以降に新しく開始される予定である。 以下の内容についても、過去の業務実績等に基づく値ではなく、本調達時点の想定に基づく値である点に留意すること。 (1) サービスの利用者数及び情報システムの利用者数本サービス及び情報システムの利用者について、下表に示す。 表 5 サービスの利用者数及び情報システムの利用者数(想定)項番 利用者利用者の種類主な利用拠点 サービス提供時間帯 利用者数 補足 サービス利用者情報システム利用者1 市民 ○ ○ 全国 9:00～17:00 約100,000人 XXX2図書館サービス窓口担当者－ ○ 本省 24時間 約10人 XXX3図書館管理課担当者－ ○ 本省 24時間 約5人 XXX4項番 利用者利用者の種類主な利用拠点 サービス提供時間帯 利用者数 補足 サービス利用者情報システム利用者4 … … … … … … …(2) 処理件数現行システムを用いた主な業務の処理件数は下表のとおりである。 表 6 主な業務の処理件数項番 項目処理件数補足定常時 ピークの特性1貸出申請件数(令和XX年度)約100件/日約300件/日午前中と夕方に集中XXX2 ・・・ ・・・ ・・・ ・・・業務実施の時期・時間(1) 業務実施時期・期間及び繁忙期本サービスに係る業務実施時期・期間は、原則として開庁日(土日及び祝日、年末年始を除く)とする。 本サービスに係る業務の通常時と繁忙期を下表に示す。 なお、繁忙期においてもレスポンスの低下等を招かないよう、十分な処理性能を確保すること。 表 7 業務の通常期、繁忙期項番 実施時期・期間 補足1 通常期 下記以外 XXX2 繁忙期 3月～4月、6月～7月 XXX(2) 業務の実施・提供時間本システムについては、主管課の責任のもとで運用・保守事業者が運用作業を実施する。 なお、本システムのサービス提供時間、運用時間、システム障害時の対応については以下のとおりである。 ア サービス提供時間本サービスは計画停止を除き、24時間365日サービスを提供できること。 利用者ごとのサービス提供時間帯は「表５ サービスの利用者数及び情報システムの利用者数(想定)」に記載の通り。 イ 運用時間運用・保守業者の運用時間は平日(土日及び祝日、年末年始を除く)の9時から17時までとする。 ただし、システムの監視は24時間365日行うこと。 夜間や休日におけるシステム障害時の連絡体制については、運用時間と同等の体制を維持することは求めないが、障害の重要性に応じた機動的な体制を提案すること。 ウ システム障害時の対応システム障害時は復旧を優先し、一次対応を速やかに実施すること。 障害の原因究明・恒久的対策は、原則としてシステム復旧後、翌開庁日の運用時間内にシステム保守として実施すること。 5【プロジェクトの特性上ミッションクリティカルである場合】システム障害時は復旧を優先し、一次対応を速やかに実施すること。 障害の原因究明・恒久的対策についても速やかに実施し、結果を主管課に報告すること。 (3) ヘルプデスク業務ヘルプデスク業務における問合せ対応の受付時間を下表に示す。 表 8 ヘルプデスク業務の問合せ対応時間項番 問い合わせ方法 受付時間 回答時間 補足1 電話開庁日9:00~17:00開庁日9:00~17:00XXX2 メール 24時間365日 同上 XXX3 Web フォーム 同上 同上回答はメールにて実施する。 回答メールの内容は主管課と協議して定める。 4 … … … …業務の実施等本システムにおける業務の実施場所に関する要件について、以下に示す。 表 9 利用者の業務の実施場所項番 場所名 実施体制 実施業務 所在地1XXX図書館管理課 蔵書に関する管理業務を行う。 XXX県XXX市XXX町XXX番地2 サービス課情報システムを利用した貸出申請に対する受付、審査、督促等を行う。 3 ・・・ ・・・ ・・・ ・・・業務観点で管理すべき指標本サービスに係る達成度評価指標(KPI：Key Performance Indicator)を下表に示す。 なお、本サービスの利用動向を踏まえ、必要に応じて更にKPI を追加または変更する場合がある。 KPIの追加または変更により「2.4.(8) モニタリング対象データ一覧」および「3.16.(5) 主な運用作業一覧」に変更があった場合は、対応範囲を主管課と協議の上で決定、対応すること。 表 10 達成度評価指標(KPI：Key Performance Indicator)項番 指標の種類 指標名 計算式 単位 目標値 計測方法 計測周期1業務(サービス)効果指標平均審査期間対象案件における以下の平均値(結果通知日)－(申請受付日)日7日(開庁日・閉庁日を含める)現状:平均20日本システムの統計機能から取得する月次2業務処理時間の削減XXX業務処理1件あたりの削減時間「現行業務処理時間」－「業務・サービス改革実施後の業務処理時間」時間２時間現状:5時間業務ログから1件当たりの処理時間を取得する。 四半期に１度3 … … … … … … …6情報システム化の範囲(1) 情報システム化の範囲本調達の範囲は、下図の赤枠部分に示す範囲である。 図 3 業務概要図(サンプル)業務の継続の方針等システムの継続に関しては「3.9継続性に関する事項」に記載する対策を講じること。 【障害によるシステム停止時にも最低限継続すべき業務がない場合】本システムでは障害によるシステム停止時にも最低限継続すべき業務はないため、本章は特に定めない。 【障害によるシステム停止時にも最低限継続すべき業務がある場合】本項目では業務の継続に関する要件を記載する。 (1) システム停止時を想定した業務本システムが全面的に利用できなくなった場合でも、業務を継続するために最低限必要となる情報については、主管課の指示に従い、電子媒体もしくは紙資料に別途保存すること。 保存の頻度は１か月に一回を想定する。 7情報セキュリティ対策の方針等本システムの情報セキュリティ対策に係る具体的な要件は、「3.10 情報セキュリティに関する事項」を参照すること。 (1) 情報セキュリティ対策の基本的な考え方表 11 システムで扱う情報の特徴項番 主な情報情報の機密性その他(情報の完全性、可用性等) 情報の取扱いで考慮すべき関連法令補足特徴 格付の区分 特徴格付の区分1貸出申請書個人情報が含まれる。 情報漏えい等が発生した場合、利用者に財産上の被害を与えるおそれがある。 当該業務において最も機密性の高い情報。 機密性２情報－ － XXX法 XXX2貸出承認書個人情報が含まれる。 情報漏えい等が発生した場合、一定程度の社会的批判を受けるおそれがある。 機密性２情報情報の改竄により業務に一定の影響を受けるおそれがある。 (電子署名の付与等の対策が必要)完全性２情報XXX法 XXX3 … … … … … … …2. 機能要件定義機能に関する事項(1) 機能一覧本調達で要求する主要な機能を下表に示す。 詳細な機能構成は、要件定義工程にて主管課と協議の上決定すること。 表 12 機能一覧項番 機能ID 機能分類 機能名機能概要処理方式利用者区分現状の機能との差異該当業務 補足入力 処理 出力1 BP1110 XXX 利用者登録XXX XXX XXXオンラインXXX XXX業務ID：Z0001XXX2 BP1121 XXX 貸出申請XXX XXX XXX オンラインXXX XXX XXX XXX3 BP1122 XXX 申請書確認XXX XXX XXX オンラインXXX XXX XXX XXX4 BP1123 XXX 申請書承認XXX XXX XXX オンラインXXX XXX XXX XXX5 BP1130 XXX 返却XXX XXX XXX オンラインXXX XXX XXX XXX6 BP1140 XXX申請情報連携XXX XXX XXXバッチXXX XXX XXX XXX… … … … … … … … … … … …8【受託者から提案を受ける場合】受託者は、「表 12 機能一覧」を踏まえ、具体的な機能及びその実装の方法(機能の単位、画面構成・遷移等を含む。)等について、提案するシステム方式等に応じて適切なものを提案すること。 その際には、現行システムの実装方法(機能の単位、画面構成・遷移等を含む。)を単純に踏襲するのではなく、現時点で広く使われている技術を前提として、ユーザビリティや開発効率性の観点から優れた方法を選択するよう留意すること。 より適切な他の手段により実質的に想定機能の一部又は全部を代替可能な場合(外部サービスの利用、ノンプログラミングによる画面生成等プロトタイピング用のツール等を採用する場合など、既存の機能・サービスで置き換えることが可能な場合を含む。)には、当該代替可能な機能と当該手段を示すこと。 また、想定機能は、受託者が提案する方法で実質的に代替可能であることを客観的かつ具体的に確認できる提案となっていること。 (2) 技術検証現在、実現性、性能、セキュリティ、利便性、運用性等の観点から技術検証を行っている。 当該技術検証の結果を踏まえ、本システムを設計・開発すること。 なお、技術検証の状況については、本調達時点の技術検証状況を閲覧資料として提供する予定である。 (3) 機能の主な追加・変更点本システムでは下表の観点での機能見直しを行う予定である。 表 13 機能の主な追加・変更点項番 変更区分 主な観点 説明 メリット1 新規追加 スマートフォンによる利用者登録機能の実装現行システムにおいては PC からのみ利用者登録が可能だったが、次期システムではスマートフォンからも利用者登録を可能とする。 利用者の利便性が向上する。 2 変更 本システム及び外部連携システム間の連携項目の追加法制度の変更に伴い、XXX 情報を追加で取得する必要があるため、連携項目を追加する。 法制度に準拠した対応ができる。 3 … … … …(4) 今後の機能追加を踏まえた構成本調達で要求する機能ではないが、将来追加が必要となる機能を下表に示す。 これらの機能追加を想定した構成とすること。 なお、拡張性については、「3.6拡張性に関する事項」も参照すること。 表 14 将来追加する必要のある機能一覧項番 機能分類 機能名 概要1 XXX 督促 返却期限が迫る貸出本を借りている利用者をシステムで洗い出し、登録されているメールアドレス宛に自動で督促に係るメールを送信する機能を搭載する。 2 … … …(5) 機能構成概念図本サービスの機能構成概念図を以下に示す。 なお、図の記載内容が過度に複雑化することを避けるため、下図では機能分類に着目し、各機能の位置関係と情報フローに焦点を当てて表現することとしている。 9図 4 機能構成概念図例画面に関する事項前述の「2.1 機能に関する事項」を実現するために必要な画面については、本システムの受託者の提案を踏まえ、設計時点で決定する。 画面レイアウト等の設計に当たっては、予めワイヤーフレーム(画面の完成イメージを線や枠で表現したもの)などを作成し、主管課の了承を得た上で設計を行うこと。 なお、主管課ではワイヤーフレーム作成環境としてFigmaを採用しているため、受託者側でも Figmaを使用できる環境を準備すること。 (1) 画面一覧本サービスの画面一覧を下表に示す。 なお、個別具体のユーザーインタフェースとして実装する際の画面構成、画面レイアウト、画面タイトル等のラベル、画面遷移等の詳細は基本設計工程で定める。 本要件定義書では画面設計に当たっての基本的な方針を定めている。 表 15 画面一覧(想定)項番 画面ID 画面名 画面概要 該当機能 補足1 XXXXXX申請書作成XXX申請者が利用するXXX申請書の作成画面機能ID:XXX XXX2 XXXXXX申請書確認XXX申請者が利用するXXX申請書の作成確認画面機能ID:XXX XXX3 … … … … …(2) 画面イメージ本サービスの基本的・代表的な画面イメージを下図に示す。 紙面スペースの制約上、一部を抜粋したものとしているが、全体像については、調達仕様書に基づく資料閲覧を行う際に確認することが可能である。 なお、以下に示す表示イメージは、デザインプロトタイプとして作成したものである。 個別具体のユーザーインタフェースとして実装する際の画面構成、画面レイアウト、画面タイトル等のラベル等については、本サービスの設計・開発段10階で行う UX 開発において改めて設計を行う。 また、画面表示イメージに表現されている内容は、デザインを明確にする観点から便宜的に当てはめたものである。 図 5 画面イメージ(3) 画面遷移の基本的考え方基本的・代表的な画面遷移として、トップ画面遷移図を以下に記載する。 図 6 画面遷移図11(4) 画面設計ポリシー画面設計における要件を以下に示す。 ア UXデザインUXデザインについては、以下の要件を満たすこと。 加えて「3.1ユーザビリティ及びアクセシビリティに関する事項」の要件も考慮すること。  本サービス想定利用者の目的を満足する観点から、本サービスを構成する機能、コンテンツの設計に当たっては、適切なユーザー調査によって利用者の要件を把握すること。  本サービスに係るUXデザインは、UXに影響を及ぼす要素を5階層によって把握するUX5階層モデルの考え方を導入する。 本サービスのWebサイト及びWebアプリケーションについて、本サービスの目的を基底として、体系的かつ一貫性のあるUXを確保できるようにすること。 イ 画面の表示画面の表示に関して、利用者に正しく内容を伝達するために、以下の要件を満たすこと。  画面の表示にはHTMLを利用し、Webブラウザ上で正常に表示されることを確認すること。 また、JavaScript を無効にした状態でも最低限のコンテンツ情報を閲覧可能とすること。  画面の表示で使用するWebブラウザには追加でプラグイン等のインストールを必要としないこと。  Webブラウザのバージョンの更新があった際は、基本的には更新前のバージョンへの対応を保ちつつ、更新後のバージョンに対応させること。 やむを得ず、双方のバージョンへの対応が困難な場合は、対応を優先するバージョンは主管課が判断を行うものとする。  利用者が他に起動しているWebブラウザの動作に干渉しないように配慮すること。  Webブラウザや利用端末の要件については、「3.11.情報システム稼働環境に関する事項」の「(7)利用端末の要件」を参照すること。 ウ 入力負荷の軽減画面での入力操作は以下の要件を満たすこと。  画面での入力操作は、業務特性に応じて、入力負荷の軽減及び誤操作防止等に配慮すること。  日付を入力する項目については可能な限りカレンダーから日付を選択できること。 エ 誤操作の防止利用者認証情報を取り扱う重要性を考慮し、誤操作によるデータの消失や誤った情報の登録等を防止する為、以下の要件を満たすこと。  Webブラウザ自体が備えている「戻る」、「更新」等のボタンを押下しても、二重登録などの不具合が発生しないこと。  Webブラウザで表示する画面内のボタンを連続で押下しても、二重登録などの不具合が発生しないこと。  検索処理中に再度の検索実行が行われないこと。 (検索処理中は検索実行ボタンを非活性化する等)オ メニューメニューについては、以下の要件を満たすこと。  各画面の上部に統一的な操作メニューを表示し、他の画面への遷移を可能とすること。  現在の画面のメニュー体系における位置を階層的に表示し、他の画面への遷移を可能とすること。  利用用途(一般利用、システム管理等)、利用者(承認者、担当者等)により操作可能な画面が異なるため、権限設定に応じたメニュー表示を可能とすること。 12帳票に関する事項【帳票を作成する機能がないシステムの場合】本システムでは、帳票(紙帳票、PDF 等の電子帳票の双方を指す)を作成する想定はない。 ただし、利用登録の初期発行、失効等の各種処理完了時には、利用者に対して、画面やメール等で通知を行う仕組みを設けること。 【帳票を作成する機能を持つシステムの場合】本システムの帳票に関する要件を「表 16 帳票一覧」「図 7 帳票イメージ」に示す。 なお、法定帳票以外の帳票については、代替手段を積極的に提案して帳票の削減を提案すること。 (1) 帳票一覧原則として、各帳票間で基本レイアウトの統一を図ること。 なお、帳票の実装方式については、現時点で広く使われている技術を前提として、ユーザビリティや開発効率性の観点から優れた方法を選択するよう特に留意すること。 表 16 帳票一覧項番 帳票ID 帳票概要 入出力形式 該当機能 補足1 XXX XXX申請用 紙(A4) 機能ID:XXX XXX2 XXX XXX申請用 PDF 機能ID:XXX XXX3 … … … … …(2) 帳票イメージ本サービスの基本的・代表的な帳票イメージを下図に示す。 図 7 帳票イメージ13データに関する事項本システムで管理する各種情報については、以下に示す情報・データを概念レベルでの基本とする。 なお、情報・データの修正が必要になる場合や、関係する組織やシステム等とのデータ授受方法の詳細については、設計工程で主管課と協議の上で対応すること。 (1) データモデル本システムのデータモデルを下図に示す。 図 8 データモデル図 9 データモデルの凡例(2) データ一覧本システムのデータ一覧を下表に示す。 なお、下表のデータ一覧については、主管課が定める DS-400 政府相互運用性フレームワーク(GIF)を参照して作成している。 受託者も同フレームワークを十分に理解し、作14業を進めること。 ア マスターデータ表 17 マスターデータ一覧イ マスターデータ以外(トランザクションデータ、入出力ファイル等)表 18 マスターデータ以外のデータ一覧(3) データ定義本システムのデータ定義を下表に示す。 表 19 データ定義15(4) CRUDマトリクス本システムのCRUDマトリクスを下表に示す。 (5) コード一覧本システムで使用するデータのコード一覧を下図に示す。 表 21 コード一覧(6) コード内容定義本システムで使用するデータのコード内容定義を下表に示す。 表 20 CRUDマトリクス16表 22 コード内容定義(7) オープンデータ一覧本システムのオープンデータを下表に示す。 (8) モニタリング対象データ一覧「1.5.業務観点で管理すべき指標」に記載したプロジェクトの目標について、実績値を適時に確認するデータとして、現時点の案を示す。 表 24 モニタリング対象データ一覧(想定)No. データ名 分析軸となる項目 目的1 サービスに関する登録者のユニークな数性別、年代、アカウント種別など サービスの利用意向者の数およびその特徴が把握できること2 サービスサイトへアクセスしたユーザーのユニークな数性別、年代、アカウント種別など サービスの利用意向者の数およびその特徴が把握できること3 サービスに関する申請の数 申請種別、申請の受付種別など サービスの利用件数およびその詳細が把握できること4 Webページや特定コンテンツの閲覧数、ダウンロード数コンテンツ種別など サービスのアクセス件数およびその詳細が把握できること5 API のリクエスト数 API種別など システムからの利用件数およびその詳細が把握できること6 … … …表 23 オープンデータ一覧17外部インタフェースに関する事項本システムの外部インタフェースに関する要件を以下に示す。 なお、一部のインタフェースは機能要件の変更に合わせて修正が必要になることが想定される。 新たに追加となった機能への対応を含め、外部インタフェースの修正が必要になる場合については、設計工程で主管課と協議の上で対応すること。 なお、インタフェースについてはAPI連携を原則とし、旧来型のインタフェースについてはAPI化を積極的に提案すること。 (1) 外部インタフェース一覧本サービスは、下表に示す他の情報システム等と連携する。 なお、外部インタフェース一覧における記載内容は現在の想定である。 設計工程において、連携先システム担当と調整の上、決定すること。 表 25 外部インタフェース一覧(想定)項番外部インタフェースID外部インタフェース名外部インタフェース概要相手先システム送受信区分送受信データ種別送受信タイミング送受信の条件補足プロトコル文字コード1 XXX申請者情報連携申請の審査に関わる申請者の情報を取得XXXシステム受信API(REST)リアルタイムHTTPS UTF-8 XXX2 XXX申請結果一括連携審査において承認された申請情報を提供XXXシステム送信ファイル(CSVファイル形式)日次 FTPS UTF-8 XXX3 … … … … … … … … … …3. 非機能要件定義ユーザビリティ及びアクセシビリティに関する事項(1) 情報システムの利用者の種類、特性本システムの利用者の種類、特性について、下表に示す。 18表 26 情報システムの利用者の種類、特性項番 利用者区分 利用者の種類 利用イメージ 特性1 利用者利用者(マイナンバーカードの有効な署名用電子証明書を保有しており、スマートフォン用電子証明書の発行を希望する国民)本システムで開発するスマートフォンのアプリケーションを用いて、スマートフォン用電子証明書の発行申請等を行う。 スマートフォンの操作に不慣れな利用者も想定されるため、分かりやすいユーザーインタフェースを考慮する必要がある2 行政担当者 本システムの運用管理担当者本システムの運用管理に当たり、必要に応じて本システムの操作を行う。 パソコンの操作について、事務作業等に係る一定の知識・スキルはあるが、情報システムの運用管理に関する専門的、技術的な知識・スキルは多くはないため、ユーザビリティ上留意する必要がある。 3 事業者本システムと連携する行政・民間業務アプリのサービス提供者本システムが提供する連携方法(アプリ間連携及びブラウザ連携を想定)を利用して、自組織が提供するアプリにおいて、公的個人認証サービスを利用する。 (具体的な連携方法等は技術検証、検討会等で今後検討)本システムを介して、自組織が提供しているアプリにおいて公的個人認証サービスを利用する。 4 … … … …(2) ユーザビリティ要件「表 26 情報システムの利用者の種類、特性」に示す役割・業務内容に基づき、各利用者の特性を十分に留意する。 また、利用者が想定する流れに沿った操作手順、画面遷移、画面レイアウト、帳票レイアウト等とする。 表 27 ユーザビリティ要件項番 ユーザビリティ分類 ユーザビリティ要件1画面の構成(直感・シンプル) 利用者が何をすればよいか直感的に理解できるデザインにすること。  無駄な情報、デザイン、機能を排したシンプルでわかりやすい画面にすること。 2画面の構成(フォント及び文字サイズ) 十分な視認性のあるフォント及び文字サイズを使用すること。  画面サイズや位置を変更できること。  一度に膨大な情報を提示して利用者を圧倒しないようにすること。 3画面の構成(マルチデバイス対応) スマートフォン、タブレット端末により本サービスを利用する利用者を想定し、これら端末の特性を考慮した画面にすること。  レスポンシブデザインにより、PC、タブレット端末、スマートフォン等の利用環境を問わず、同一の情報をグリッドレイアウト等の適切なレイアウトにより表示できるようにすること。 4画面の構成(表示/非表示) 情報の優先順位をつけ、重要度の低い情報、特定の利用者層に対して提示する情報は、利用者が必要に応じて表示/非表示を切替え可能とする等の工夫をすること。 5画面の構成(クリックやチェックができる箇所) 画面上でクリックやチェックができる箇所とできない箇所の区別を明確にすること。  タップ操作が可能なタブレット端末やスマートフォンの場合は、タップ操作の結果(どの部分をタップしたのか)を適切にレスポンスできること。 6 画面遷移 利用者が次の処理を想像しやすい画面遷移とすること。  無駄な画面遷移を排除し、シンプルな操作とすること。 7画面表示・操作の一貫性(統一) 機能、用語、レイアウト、操作方法は統一すること。 8画面表示・操作の一貫性(視認性) 必須入力項目と任意入力項目の表示方法を変えるなど各項目の重要度を利用者が認識できるようにすること。  見やすさを考慮し、画面のフォントサイズを決定すること。  画面ごとに異なるフォントを使わないこと。 9 操作方法のわかりやす  無駄な手順を省き、使いやすく、利用者が効率的に作業できるようにすること。 19項番 ユーザビリティ分類 ユーザビリティ要件さ  利用者が操作しやすい手順にするため、画面上の情報項目を上から下へ、左から右へ流れる順番に配置すること。  利用者の操作を軽減できるよう、画面の初期表示時、入力項目、選択項目等に適切な既定値を設定すること10操作方法のわかりやすさ(操作説明) 原則としてマニュアルを参照しなくても操作できるようにすること。 11操作方法のわかりやすさ(Tabキー) Tab キー等による画面上のフォーカスの移動順序について、利用者が操作しやすい順序となるようにすること。 12操作方法のわかりやすさ(画面遷移) 利用者が同じ情報の入力や操作を何度も行う必要がないよう、画面が遷移しても情報がその後の手順に反映されるようにすること。  利用者の手間を軽減するため、利用者の手順に即した画面遷移に留意し、可能な限り不要な画面遷移を行わないようにすること。 13操作方法のわかりやすさ(マルチデバイス対応) スマートフォン、タブレット端末等の狭い表示領域、タッチインタフェースでも効率的に作業できる操作性を実現すること。 14指示や状態のわかりやすさ ユーザーインタフェース及び UX に関する一般的に使われているデザイントレンドを取り入れ、アイコン・図表のグラフィック表現を適切に適用すること。  本サービスが処理している内容や状況を、利用者が把握できるようにすること。 15指示や状態のわかりやすさ(外部ドメインへの遷移) ドメインを異にする他の Web サイトへの遷移を行う際は、離脱メッセージを表示する等、利用者が認識できるようにすること。 16 メッセージ出力 利用者に分かりやすいメッセージとすること。  必要に応じて、登録・変更・削除等の操作を行う場合には、確認画面等で表示し、利用者の注意を促すこと。  処理時間がかかる操作では、処理中であることが分かるようにすること。 17メッセージ出力(次の操作) 指示メッセージは、次操作が具体的にイメージできるようなメッセージ出力を行うこと。 18 エラーの防止と処理  利用者が操作や入力を間違えないデザインや案内を提供すること。 19エラーの防止と処理(エラー防止) 利用者の誤操作を想定し、入力チェック機能によりエラーを防止すること。  入力値が選択できる場合には、プルダウンメニュー等を活用し、極力キーボード入力操作をなくすこと。 20エラーの防止と処理(エラーメッセージ) エラーメッセージは、その内容が分かりやすく表示されるとともに、利用者が何をすればよいかを示すこと。 21エラーの防止と処理(エラー表示と解決策) 入力内容の形式に問題がある項目については、利用者がその都度該当項目を容易に見つけることができるようにすること。  エラーが発生した時は、利用者が迷わずに問題解決できるよう、操作の続行に必要な選択肢を利用者が適切に理解できるようわかりやすく提示すること。  入力内容の形式に問題がある項目については、それを強調表示する等、利用者がその都度その該当項目を容易に見つけられるようにする。 22エラーの防止と処理(確認画面) 必要に応じて、登録、更新、削除等の処理の前に確認画面を用意し、利用者が行った操作や入力のやり直し、取り消しがその都度できるようにすること。  重要な処理については、事前に注意喚起し、利用者の確認を促すこと。 23エラーの防止と処理(画面遷移) 入出力の過誤があった場合、次の画面へ遷移しないこと。 24エラーの防止と処理(情報保持) タブレット端末等、屋外での使用を考慮し、電波受信状況の悪い場所においても操作不能とならないよう工夫すること。 25 ヘルプ 利用者が必要とする際に、ヘルプ情報やマニュアル等を容易に参照できるようにする。  ヘルプ情報やマニュアル等についても、利用者が必要な情報を容易に検索できるようにする。 26既存のシステムとの統合 本システムで開発するシステム(またはアプリ)は、既存の XXX システムと統合を行う。 そのため、既存の XXX システム(もしくはアプリ)の UI/UX との統一感を意識したデザインとすること。  必要に応じて、既存の XXX システムに係る担当部局及び関連事業者からの要望対応の20項番 ユーザビリティ分類 ユーザビリティ要件検討、連携を行うこと。  技術検証の結果を反映して、統合後の機能構成を示すこと。 27デザイナーによるUI/UX検討 本システムで開発するスマホアプリの UI/UX 検討に当たっては、利用者の利用動機に着目し、サービスデザイン思考の観点から検討を行うこと。  UI/UX 検討に当たっては、民間スマホアプリ等の経験を有する専門の UI/UX デザイナーを体制に組み入れること。 28画面遷移、操作ログ等の分析 運用・保守工程において継続的に UI/UX の改善を検討できるよう、利用者の画面遷移、操作ログ等を分析できる仕組みを整備すること。 29 言語対応  本情報システムでは、日本語のほか、XXX語で記述されたコンテンツに対応すること(3) アクセシビリティ要件アクセシビリティに関する要件を下表に示す。 表 28 アクセシビリティ要件項番 アクセシビリティ分類 アクセシビリティ要件1 基準等への準拠 広く国民に利用され公益性の高い情報システムであるため、日本産業規格 JISX8341 シリーズ、「みんなの公共サイト運用モデル」(総務省)に準拠し、以下を前提とすること。 https://www.soumu.go.jp/main_sosiki/joho_tsusin/b_free/guideline.html JIS X 8341-3:2016「高齢者・障害者等配慮設計指針－情報通信における機器，ソフトウェア及びサービス－第 3 部：Web コンテンツ」の適合レベル AA に準拠することを目標とする。 また、レベルAAAのうち、以下の達成基準についても可能な範囲で適用すること。 ➢ 2.1.3 キーボード(例外なし)の達成基準➢ 2.3.2 3回のせん(閃)光の達成基準➢ 2.4.8 現在位置の達成基準➢ 3.2.5 要求による状況の変化の達成基準 注記：本仕様書における「準拠」という表記は、情報通信アクセス協議会Web アクセシビリティ基盤委員会「Web コンテンツの JIS X 8341-3:2016 対応度表記ガイドライン(令和3年4月版)」で定められた表記による。  また、スマートフォン等での操作を行うユーザーが増えていることを踏まえ「WebContent Accessibility Guidelines (WCAG) 2.1」で追加された達成基準についても、可能な範囲で適用すること。 ➢ 1.3.4 表示の向き(レベルAA)➢ 2.5.1 ポインタのジェスチャ(レベルA)➢ 2.5.2 ポインタのキャンセル(レベルA)➢ 2.5.4 動きによる起動(レベルA)➢ 4.1.3 ステータスメッセージ(レベルAA) デジタル庁が整備する「ウェブアクセシビリティ導入ガイドブック」を参考にすること。 2指示や状態の分かりやすさ 色の違いを識別しにくい利用者(視覚障がいのかた等)を考慮し、利用者への情報伝達や操作指示を促す手段はメッセージを表示する等とし、可能な限り色のみで判断するようなものは用いないこと。 ただし、業務の利用用途から、画面色での振り分けを行うことを予定していることから、適用範囲及び配色については主管課及び関係省庁と協議し、決定すること。  Web ブラウザ等の音声読み上げ機能を活用し、視覚障がいの方でも問題なく利用可能なUIとすること。 3 マルチデバイス対応 解像度の低い機種、画面サイズの小さい機種でも、業務継続が可能な UI とすること。  OS の設定でフォントサイズ・表示サイズをそれぞれ最大とした場合でも、業務継続が可能な UI とすること。  スタイルシートを利用しないユーザーと利用するユーザーにおいて得られる情報に差21(表示されない文字や画像がある等)がないこと。 レイアウトにおいても大きな差がないことが望ましい。 システム方式に関する事項(1) システム方式についての全体方針システム方式についての全体方針を下表に示す。 本システムはクラウドネイティブの構成として、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針(以下、「クラウド方針」という。 )」に準拠し、クラウドサービスの提供機能を最大限活用するようデザインされたアーキテクチャとすること。 特に、信頼性、拡張性(スケーラビリティ)、継続性等の向上に寄与するクラウドサービスと構成を選定すること。 使用する IaaS/PaaSはガバメントクラウドを原則とし、SaaSについても積極的に活用すること。 表 29 システム方式についての全体方針項番 観点 全体方針1 システムアーキテクチャ 本システムのシステムアーキテクチャはクラウドサービス上に用意されるWeb アプリケーションから構成される。 Web アプリケーションは利用者の端末に追加的なソフトウェアのインストール等を行うことなく、一般に利用されている Web ブラウザで処理を行うものとする。  本システムや業務機能等の特性を十分に検討し、クラウドサービスプロバイダが提供するリファレンスアーキテクチャに準拠した形で PaaS、SaaS、IaaS 等の最適なサービスを採用し、システムを構築する。  クラウドサービスプロバイダが提供するマネージドサービスを最大限活用することを基本とし、アプリケーションプログラムの作り込みを削減できる設計とする。 特にデータベース、認証、セキュリティ機能や運用管理機能はクラウドサービスが提供する機能を最大限活用すること。  クラウドサービスが責任共有モデルとして提供されている前提を踏まえ、クラウドサービスを利用するに当たって必要となる考慮事項について検討を行い、安全かつ効率的にシステムを構築する。  予防的統制と発見的統制を実施すること。 また、クラウドサービスを利用するために作成する各種アカウントについては、ガバナンスやセキュリティに係るポリシーを設定の上で、権限管理を確実に行うこと。 管理者アカウントについては、多要素認証を必須とすること。 多要素認証はハードウェア方式を原則とするが、ソフトウェア方式も許容する。 ハードウェア方式の場合は対応するワンタイムパスワード用のデバイスを利用システム側で調達すること。  リソース使用量の変動等に柔軟に対応するとともに、コスト削減を図るため、民間クラウドサービスの利用を原則とする。  全体構成及び利用するクラウドサービスについては、受託者において移行、引き継ぎ、確実なサービス提供等について問題が生じないことをクラウドサービスプロバイダに応札前に確認し、本調達の要件を踏まえ、確認結果と合わせて適切なものを提案する。 2アプリケーションプログラムの設計方針 マイクロサービスアーキテクチャ、API、クラウドネイティブ、クラウドサービスのマネージドサービスのみによる構成等、モダン技術を前提として構築する。  クライアントサーバ方式、専用端末のシンクライアント(VDI)等の旧来技術は、高コスト化の要因となるため採用しないこと。  原則としてバッチ処理を採用せず、リアルタイム処理を基本とすること。 バッチ処理が必要となる場合は、その理由について主管課の承認を得た上で採用すること。  情報システムを構成する各コンポーネント(ソフトウェアの機能を特定単位で分割したまとまり)間の疎結合、再利用性の確保を基本とする。 22 システムが取り扱うデータの保管・管理に際して、データの容量、更新頻度、保存期間等を考慮し最適なストレージサービスを選定の上、利用する。 またデータの保管・管理方針が変更となった際に、ストレージサービス間でのデータの移行が容易となるよう設計上考慮する。 3 ソフトウェア製品の活用方針 SaaS については、開発量削減の観点から幅広く優先的に、その利用を検討すること。 ただし、ニーズにマッチしているか、開発量削減に貢献するか、セキュリティ対策は十分か、費用対効果は十分に得られるか等を慎重に考慮すること。  ソフトウェア製品については、広く市場に流通し、利用実績を十分に有するものを活用する。 広く市場に流通し、利用実績を十分に有するソフトウェア製品を活用する。  アプリケーションプログラムの動作、性能等に支障を来たさない範囲において、可能な限りオープンソースソフトウェア(OSS)製品(ソースコードが無償で公開され、改良や再配布を行うことが誰に対しても許可されているソフトウェア製品)の活用を図る。 ただし、それらのOSS製品のサポートが確実に継続されていることを確認しなければならない。  ノンプログラミングによる画面生成等プロトタイピング用のツール等を利用することにより、システムライフサイクルコストの削減等が見込める場合には、積極的に採用を検討する。 (2) クラウドサービスの選定、利用に関する要件ア セキュリティ確保のため、本システムで用いるクラウドサービスは、原則として ISMAPクラウドサービスリストまたは ISMAP-LIUクラウドサービスリストに登録されているクラウドサービスを選定すること。 なお、例外的に ISMAPクラウドサービスリスト、または ISMAP-LIUクラウドサービスリストに登録されていないクラウドサービスを選定する場合は、受託者の責任において、当該クラウドサービスが「ISMAP管理基準」の管理策基準における統制目標(3桁の番号で表現される項目)及び末尾にBが付された詳細管理策(4桁の番号で表現される項目)と同等以上のセキュリティ水準を確保していることものを選定すること。 イ 要機密情報を取り扱うクラウドサービスの選定、利用に関しては、「政府機関等のサイバーセキュリティ対策のための統一基準 (令和5年度版)」の「4.2.1 クラウドサービスの選定(要機密情報を取り扱う場合)」「4.2.2 クラウドサービスの利用(要機密情報を取り扱う場合)」の内容を遵守すること。 ウ 情報資産を管理するデータセンタの設置場所に関しては、国内であることを基本とする。 設置場所の考え方についてはクラウド方針を参照すること。 エ 契約の解釈が日本法に基づくものであること。 オ クラウドサービスの利用契約に関連して生じる一切の紛争は、日本の地方裁判所を専属的合意管轄裁判所とするものであること。 カ 主管課の指示によらない限り、一切の情報資産について日本国外への持ち出しを行わないこと。 情報資産を国外に設置されるクラウドサービスに保管する際の考え方についてはクラウド方針を参照すること。 なお、マスク済みデータは、主管課及び各事業者と調整の上、取得すること。 427セキュリティテスト不正侵入やWeb特有の攻撃への対策、データベースへの不正アクセスなどに対する対策、データの持ち出しに対する対策、マルウェア(ウィルス)対策等のセキュリティ要件を満たしているか脆弱性検査、インシデントレスポンステスト等を実施し確認する。 8運用・保守テスト運用・保守作業全般を通して、運用・保守事業者が円滑に日々の業務を実施できることを確認する。 また、運用・保守における正常時、異常時の運用に関する動作を確認し、特に異常時の対応として、エラーメッセージやログ等を基に、運用・保守事業者が業務を行えることを確認すること。 イ 総合テストに用いるテストデータには、本番運用を想定した疑似データを作成して使用すること。 ウ キーワード駆動テストの適用により、総合テストの効率化を図ること。 エ システム停止に伴うシステムバックアップやシステム停止、リストア、システム起動等については、受託者が主体的に実施すること。 オ 総合テスト実施時は、テスト結果を検証するための証跡を採取すること。 カ 総合テストは、原則として検証環境または本番環境において実施すること。 (4) 受入テスト受入テストは、要件に対するアプリケーションの充足性確認を目的として行い、主管課は構築された情報システムが要件定義書に記載した事項を適切に実現しているか、構築された情報システムを用いて実際のサービス・業務を正しく実施できるかといった観点でテストを実施する。 受入テストに用いるテストデータには、本サービスが原則として公開情報を取扱うことを踏まえ、可能な限り本番環境に近い複製データを使用する。 ただし、受入テストの目的を担保可能であることを条件に、疑似データを使用することも可能とする。 受託者は調達仕様書にある通り以下の支援を行うこと。 ア 受託者は、主管課が実施する受入テスト計画書作成作業を支援するために、受入テスト計画書(案)を作成すること。 主管課は受入テスト計画書(案)を基にして受入テスト計画書を作成する。 なお、受入テストの実施期間は十分に確保したスケジュールとすること。 イ 受託者は、主管課が実施する受入テスト仕様書作成作業を支援するために、テスト項目、使用するテストデータ、合格判定基準等を示した受入テスト仕様書(案)を作成すること。 主管課は受入テスト仕様書(案)を基にして受入テスト仕様書を作成する。 ウ 受託者は、主管課及びプロジェクト関係者が受入テスト計画書及び受入テスト仕様書に基づき実施する受入テストの実施支援を行う。 エ 受入テストは、原則として検証環境または本番環境において実施すること。 受入テストの実施に当たり、必要に応じて本システムの運転スケジュール、環境設定、テストデータ等の変更を行うこと。 オ 受入テストの実施に当たり、主管課からの質問に対する問合せ対応を行うこと。 カ 受入テストで発生したすべての障害が解消されている、または問題を特定した上で対応策について主管課の承認を得ていること。 43移行に関する事項本サービスに関する現段階での移行要件を以下に示す。 (1) 移行に関する前提条件移行における前提条件を下表に示す。 ア データの移行漏れを防止するため、データ移行時には現行システムを停止する必要がある。 業務停止に当たっては、主管課に対して移行に係る時間や制約条件等を報告し、事前に十分な調整を行うこと。 イ 新システムの要件等に伴い、移行対象データの作成や加工が必要な場合においては、移行元システムの運用・保守事業者と協力し、調整の上で、確実に実施すること。 なお、移行実施体制と役割分担については下表を参照の上、移行作業が円滑に進むよう適宜調整すること。 表 48 移行に向けた作業手順及び役割分担項番 作業名主管課工程管理支援事業者現行システム運用・保守事業者次期システム設計・開発事業者(受託者)…1 移行計画の作成 ■ ● △ ◎ …2移行データ準備・提供◎、■ ● ◎ △ …3 移行データ分析 ■ ● △ ◎ …4 移行設計 ■ ● ◎ …5データ移行サーバ・ツールの開発■ ● ◎ …6 移行リハーサル ■ ● △ ◎ …7 移行判定 ◎、■ ● ◎ …8 本番移行 ■ ● △ ◎ …9 稼働判定 ◎、■ ● ◎ …◎：主体者、●：確認者、■：承認者、△：支援者ウ 移行時期については、令和XX 年XX月を想定する。 具体的な移行時期については、本サービスの設計・開発着手後に別途定める。 エ 本番環境への移行作業は、システム停止を伴うことから、システム運用時間外の土日祝日に実施する予定である。 移行作業中に障害が発生する場合も想定し、連絡体制・現場対応体制を確保すること。 (2) 移行計画の作成移行等に関しての計画をまとめた「移行計画書」を作成し、主管課の承認を得ること。 「移行計画書」には、下記を含めること。 なお、移行計画は本プロジェクト関係者以外の第三者にも容易に理解可能でかつ継承可能な形式で作成すること。 表 49 移行計画書の記載内容項番 項目 補足441主管課及び各事業者の移行実施体制と役割 移行作業は、受託者が主体となり実施するものとする。 2移行に係る詳細な作業及びスケジュール 受託者は、主管課に最終的な移行スケジュールを提示し、確定した内容を移行計画に反映させること。 3 移行対象  データ名称、保管環境、容量、など4移行環境／移行方法／移行ツール 移行可能期間の制約も踏まえた上で、一括移行、差分連携等の手法を組み合わせて、円滑に移行が行えるように留意すること。  業務停止に当たっては、主管課に対して移行に係る時間や制約条件等を報告し、事前に十分な調整を行うこと。  移行方式は、原則として一括移行(or 複数回の分割移行)とする。 5移行作業、移行に伴い発生する各種設定を行うための各種手順書・マニュアル 移行する際の移行手順及び、機能改修のリリースに係る移行手順を作成し、主管課の承認を得ること。 具体的な移行方法や手順は、主管課との協議の上で確定し、必要に応じて手順やツールの操作方法等に関するマニュアル等を受託者が作成すること。  移行手順は、本システムと連携する XXX システムにも影響があることを踏まえ、主管課経由で調整等を実施した上で作成すること。 6 切り戻し基準、切り戻し手順書 令和XX年1月～3月(3か月間)は、現行システムをバックアップシステムとして並行稼動させる。  本システムの不具合等により現行システムへの切り戻しが必要となった場合に対応できるよう、切り戻し基準や切り戻し手順書をあらかじめ定めること。  切り戻し手順書には、切り戻した後の両システムの運用方法、データの整合性を確保する方法、再度本システムに切替える際の移行手順等も含めること。 7 移行判定基準 移行開始時に満たすべき移行判定基準を定めること。 なお、移行判定基準には以下を含め詳細は主管課と協議の上決定すること。 ➢ 計画した全てのテストケースを消化し、摘出された全ての障害(バグ、不具合等を含む)が除去されていること。 仮に除去されていない障害がある場合は、その対処方針が明確となっていること。 ➢ 移行計画書及び移行リハーサルの結果が適正であること。 ➢ 切り戻し基準や切り戻し手順書を定めており、主管課の承認を得ていること。 ➢ 稼働後の運用準備が整っていること。 8 連携先の外部システム システム移行に当たっては、XXX システム関係者と連携すること。 その際、システム連携の現状を把握し、新システム移行に伴うテスト計画を作成し、テストに向けた事前合意形成を行い、テストフェーズでも進捗管理、課題管理を行って、テスト結果の取りまとめを行うこと。 その際に、必要な資料等の作成を行うこと。 また、システム停止を伴うことから、XXX システム関係者と連携し、利用者に対する通知方法、通知内容の検討等について、受託者が主体的に実施すること。 9移行リハーサルの実施場所(システム環境) 移行リハーサルについては、必要に応じて、XXX システム関係者と調整の上、検証環境及び本番環境で実施すること。 なお、移行リハーサルにおいて本番環境を利用しない場合は、可能な限り本番環境に近い環境を準備した上で移行リハーサルを実施すること。 移行計画書に加えて下表の計画も作成すること。 表 50 計画の種類項番 計画の種類 概要1 移行リハーサル計画移行の設計内容、データ移行用サーバ及び移行用インポートサーバの設計内容､連携業務 AP の接続切替え方法、移行リハーサルにおける方針、スケジュール、実施体制、実施手順、検証方法等を定めたもの452 移行(本番)計画本番移行時の方針､スケジュール､実施体制､実施手順､作業結果判定方法､移行作 業時のセキュリティ対策等を定めたもの3 並行稼動計画並行稼働における方針、スケジュール、実施体制、実施手順、検証方法、切戻しを行う際のコンティンジェンシープラン等を定めたもの(3) 移行データ準備・提供主管課は、現行システム運用・保守事業者の支援を受けつつ移行対象となるデータを整理し受託者に提供する。 受託者は、移行対象データを受領し内容を確認すること。 (4) 移行データ分析受託者は、移行対象データを分析し、データ・クレンジング等の加工作業が必要であるか確認の上、結果について主管課に報告すること。 (5) 移行設計受託者は、「移行計画書」を踏まえ、以下の点に留意して移行設計書を作成の上、主管課の承認を得ること。 また、業務実施部門が本システムを利用するために必要となる準備事項について、提案や支援を行うこと。 ア システム移行、データ移行、稼働の方式を設計すること。 イ 本番移行等、各移行作業に関しての見込み時間を記載すること。 その際は、部分的なデータを送信して所要時間を計測するなど、必ず事前に計測を行い、本番移行の見込み時間の妥当性を証明すること。 ウ 現行サービスから次期サービスへ接続切替えを実施する方法に関する設計を行うこと。 なお、接続切替えを実施するために、他のシステム等に設定変更等を依頼する場合には、依頼内容を整理した上で、主管課を通じて、担当事業者、担当府省との調整を行うこと。 エ データ移行を含む移行に係る作業を抽出し、システム移行フローを組み立て、タイムスケジュール化等を行うこと。 (6) データ移行サーバ・ツールの開発「移行設計書」の内容に基づき、データ移行ツールの開発及びテストを実施すること。 なお、既製のソフトウェア製品の機能をそのまま利用してデータ移行を実施する場合は不要であるが、利用には主管課に報告の上、承認を得ること。 なお、移行対象データに対し、データ・クレンジング等の加工作業が必要な場合は当該作業を実施すること。 (7) 移行リハーサルシステム移行、データ移行のリハーサルでは以下の点に留意すること。 ア 移行リハーサル設計書及び移行リハーサル手順書の内容を最終確認し、XXXシステムの担当府省と最終的な意識合わせを行うこと。 イ XXXシステム側に設定変更等を依頼する場合は、依頼書を準備し、期間的な余裕を持って、主管課経由で依頼すること。 46ウ 受託者は、移行リハーサルの実施後、移行に係る作業手順、作業時間見積もり等を評価し、「移行リハーサル結果報告書」を作成すること。 また、その内容について主管課に説明し、承認を得ること。 エ 移行計画書及び移行手順書に問題がないことを検証するため、最低１回以上移行リハーサルを実施すること。 なお、移行リハーサル実施後における使用データの扱い(移行リハーサル後に使用データを削除等)についても検討すること。 オ 受託者は、移行リハーサルの結果として移行リハーサルの結果を分析し、本番移行に向けた課題などを明確にすること。 カ 作業品質に改善及び再検証を要する問題点を確認した場合、必要に応じて移行リハーサルの再実行を検討すること。 キ 受託者は、主管課の指示がある場合、修正した移行リハーサル計画書及び移行リハーサル手順書を基準として移行リハーサルを再実行すること。 ク 受託者は、移行リハーサル評価結果に基づき、本番移行までに解決を要する課題について整理すること。 (8) 移行判定主管課は、移行開始判定を目的とした会議を招集し、「(2) 移行計画の作成」にて定めた移行判定基準を満たしているか確認した上で、移行判定を行う。 受託者は、主管課が移行判定を適切に実施できるよう、報告には「(2) 移行計画の作成」に記載した移行判定基準を満たしているか分かるような情報を含めること。 (9) 本番移行本番移行では以下の点に留意すること。 ア 本番移行に向けて、移行リハーサルの実施結果を元に移行計画書及び移行手順書を修正すること。 また、その内容について主管課に説明し、承認を得ること。 イ 移行計画書には、チェックポイントを設定し、作業の進捗度と経過時間などを元に、切り戻しの判断基準を設けること。 ウ 受託者は、本番移行及び稼働に係る作業過程において作成する提出物及び成果物の内容について、主管課に説明を行い、承認を得ること。 エ 受託者は、本番移行に伴う作業状況について、事前にチェックポイントを設定し、適切なタイミングで主管課に報告すること。 万一、作業の実施中に不具合等を生じた場合は、速やかに主管課に報告するとともに、必要な対応を行うこと。 オ 受託者は、本番移行開始判断を受け、稼働のための作業を実施し、本番稼働を開始すること。 カ 受託者は、稼働関連作業の完了後、本サービスの稼働状況を確認すること。 また、稼働以降安定運用までのXか月程度の期間、QA 対応を主体とした運用支援を行うこと。 特に、本番稼働後X週間は、問合せ対応、インシデント対応等に手厚い対応体制をとること。 47キ 令和XX年 XX月XX 月～XX月XX日(Xか月間)は、次期サービスの不具合等により、 現行サービスへの切り戻しが必要となった場合には、移行設計書内の並行稼働実施計画に記載する対応方針に基づき、次期サービスから現行サービスへの切替え処理を行うこと。 ク 移行リハーサル、本番移行の実施結果を「移行結果報告書」として取りまとめ、主管課の承認を得ること。 (10) 稼働判定主管課は、サービスインを判断(稼働判定)する。 その際、受託者は、本番環境への移行の実施結果が適正であり、新しい情報システムへ切り替えても業務に支障が生じないことを主管課が判断するための資料を提出すること。 (11) 移行対象データ【新規システムの場合】本システムは新規開発するシステムであるため、旧システムからのデータ移行は発生しない。 【更改システムの場合】移行対象データを下表に示す。 表 51 移行対象データ項番 移行元 移行対象データ 件数 提供方法 補足1XXX申請システムXXXテーブル XXX CSV形式での提供 XXX2 XXX申請ファイル XXX CSV形式での提供 XXX3 XXX申請情報 XXX CSV形式での提供 XXX… … … … … …(12) 移行対象業務移行対象業務は、XXXからXXXまでの範囲に該当する全ての業務とする。 引継ぎに関する事項本システムの運用は、別途調達する本システムの運用・保守事業者が実施する予定である。 現時点で想定する引継ぎ要件を以下に示す。 (1) 引継ぎ計画書の作成本システムの関連事業者に対する引継ぎの開始前に、本システムの引継ぎに係る引継ぎ対象、引継ぎ体制、引継ぎ内容、引継ぎ方法、引継ぎスケジュール、理解度確認方法、完了条件等を記載した「引継ぎ計画書」を作成し、主管課の承認を得ること。 (2) 引継ぎ方法48ア 受託者は、「引継ぎ計画書」に従い、十分な時間的余裕を持って、必要な運用引継ぎを行うこと。 その際は、引継ぎ対象者の理解度を確認し、必要な場合には、「引継ぎ計画書」に記載したスケジュール等の変更を行うこと。 イ 本サービスは、その保守や将来の拡張等の業務を他事業者に引き継ぐことが可能であること(引き継ぎのために必要となる各種ドキュメントを整備する等)。 第三者による保守性を向上させるため、成果物等は標準的に利用されているドキュメント作成ソフトウェアを用い、編集可能な形式で納品すること。 ウ ドキュメントには設計結果のみを記載するのではなく、設計根拠等も明示し、検討経緯を可視化すること。 エ 並行稼働期間中(引継ぎ期間中)における当該システムの運用・保守事業者からの問合わせにも対応すること。 オ 期間内に引継ぎが完了しない場合は、原則として受託者の責任と負担において引継ぎを完了すること。 カ 連携先システムである、XXXのアプリケーション保守事業者に対しては、必要となる知識等について引継ぎを行うこと。 引継ぎは約X時間/回をX回程度実施することを想定している。 (3) 引継ぎ対象本システムの引継ぎ対象を下表に示す。 なお、引継ぎに際しては主管課の指示に基づき書面又は電子媒体で行うこと。 表 52 本システムの引継ぎ対象項番 引継ぎ期間 引継ぎ先 引継ぎ内容 引継ぎ手順 補足1令和XX年XX月XX日～令和XX年XX月XX日本システムの運用・保守事業者(令和XX年度後半に調達予定) ソースコード(テスト・構成管理・環境構築等に利用するコード含む) 開発環境に必要となる各種ツール 各種設計書・ドキュメント類 運用課題(管理簿) 仕様課題(管理簿) インシデント状況(管理簿) 連携業務アプリケーション対応状況(管理簿) ヘルプデスク作業 各種運用・保守作業 その他成果物一式 (クラウドサービスの管理に必要なアカウントや鍵情報、また IaC(Infrastructure as Code)に基づくシステム構築・管理等に係る構成管理ファイル等情報を漏れなく含む)受託者は、引継ぎ計画書の内容に基づいて、引継ぎ作業を行う。 XXX2令和XX年XX月XX日～令和XX年XX月XX日連携先システムであるXXXシステムのアプリケーション保守事業者必要となる知識等受託者は、引継ぎ計画書の内容に基づいて、引継ぎ作業を行う。 XXX3 … … … … …(4) クラウドサービスを利用する場合の引継ぎ49本システムでは、本調達の契約期間終了後も、クラウドサービスの契約期間終了前に契約の延長又は他の引継ぎ先事業者(運用・保守事業者を想定)への引継ぎ等を行うことで、クラウドサービスをそのまま継続利用することを想定している。 引継ぎに際しては、必要に応じて引継ぎ先事業者及びクラウドサービスプロバイダとの間で書面による契約等を行い、しかるべく管理者権限の引渡し等を行うこと。 (5) 引継ぎ結果報告書の作成引継ぎ作業の完了時に、本システムの、他事業者等への引継作業の実施結果について記載した「引継ぎ結果報告書」を作成し、主管課へ報告を行うこと。 【前任事業者から既存システムの運用を引き継ぐ場合】(6) 前任事業者からの引継作業受託者は、本業務を実施するために必要な情報について、引継元である前任の運用・保守事業者からの引継ぎを受けること。 引継ぎ完了後は、受託者が引継ぎ完了報告書(確認者、確認日時、完了条件の適合性等を記載)を作成し、主管課の承認を得ること。 50教育に関する事項(1) 教育計画の策定教育訓練の対象者、スケジュール、実施内容、実施方法(集合研修、テキスト配布等)、教材等に関する教育訓練実施計画書を作成し、主管課からの承認を得ること。 (2) 教育対象者本システムの教育対象者を下表に示す。 詳細は本システムの開発時点で決定する。 表 53 教育対象者項番 教育対象者 教育内容 教育対象者数1 システム部門職員 運用業務の全体概要、システム部門職員の業務手順等 XXX2 業務部門職員職員の業務に関する本システムの操作手順、画面遷移、UI 表示仕様、エラー発生時の対応等XXX3 運用・保守事業者運用・保守業務の全体概要、運用・保守事業者の業務手順等運用・保守要員の業務内容等XXX4 … … …(3) 教育の実施時期教育訓練の実施スケジュールについては、主管課を介した調整により、受講対象者と事前に調整した上で確定すること。 ただし、遅くとも本サービス運用開始の 4 週間前までに教育を完了し、本サービスを利用した業務開始前までに十分な習熟期間を確保できるようにすること。 (4) 教育の方法教育訓練の実施方法は、主に講義形式又はマニュアル配布を想定している。 以下に、各教育訓練方法についての要件を示す。 ア 講義における講師は、受託者が実施すること。 イ 講義に必要な教材については、受託者が準備すること。 必要な機材(プロジェクタ等)は、主管課と協議の上、必要に応じて受託者が準備すること。 ウ 講義会場及びWeb会議環境は、主管課側で準備するものとする。 詳細については主管課と協議の上、決定とする。 エ 講義は録画を行い、必要に応じて、掲載等を行うこと。 また、録画データは納品の上、主管課が再利用することを妨げないこと。 オ 講義開催日数は、２回(2日×１回)を想定している。 講義開催時間は、概ね２時間とすること。 カ 講義参加予定人数分の教育教材を用意すること。 なお、必ずしも紙媒体で教材を準備する必要はなく、受講者が確認しやすい形態であれば電子データを配布する形でも構わない。 キ 講義終了後、15分程度の質疑応答の時間を設けること。 51ク 講義では受講者がシステム操作を実体験できるようにすること。 ただし、本番環境以外に研修用の環境を構築するなどし、本番稼動に影響を与えずに研修を実施できるよう主管課と調整すること。 ケ 講義、マニュアルに関するアンケート用紙を作成の上、講義後に受講者に回答を依頼すること。 なお、アンケート内容は事前に主管課と調整すること。 (5) 教材の作成上記の教育対象者に対して、操作マニュアル、運用・保守手順書、教育資料(システムの概要資料、操作動画、FAQ 等を想定)を作成すること。 詳細は教育実施計画書の策定時に、主管課と協議の上決定する。 教育資料の概要を下表に示す。 表 54 教育資料の概要項番 教材 教材の概要 対象者 補足1システムの概要資料 情報システムや関連業務の概要を取りまとめた資料システム部門職員業務部門職員運用・保守事業者対象者毎に教材を作成2操作動画 情報システムの操作方法について動画に取りまとめたもの業務部門職員 XXX3FAQ よくある質問や回答を取りまとめた資料システム部門職員業務部門職員運用・保守事業者対象者毎に教材を作成4 … … … …ア 教育資料の作成に当たっては、情報システムやスマートフォンの操作に不慣れな者でも分かりやすいような構成、内容とすること。 イ 利用者(国民)向けの操作マニュアル等については、サービスデザイン思考、UI/UX等の観点から、民間スマートフォンアプリ等の経験を有する専門のUI/UXデザイナーを体制に組み入れること。 ウ 教育資料については、主管課のレビューを経て承認を得ること。 (6) 教育訓練実施結果報告教育訓練の実施結果を教育訓練実施結果報告書にて主管課に報告し、承認を得ること。 運用に関する事項現時点で想定する運用要件を以下に示す。 (1) 運用・保守計画運用・保守の設計で検討した内容を踏まえて、以下の要件が含まれる形で運用・保守計画書及び運用・保守実施要領の確定版を作成すること。 52表 55 運用・保守計画書の記載内容項番 項目 補足1 作業概要・ 監視、運用・保守作業の対象範囲、管理対象、作業概要等を記載する。 2 作業体制に関する事項・ 運用・保守業務を実施するための体制について、管理体制図、本件受託者の要員(責任者、作業者、役割分担)、連絡手段等について記載し、全体的な運用管理体制を明確にすること。 3 スケジュールに関する事項・ プロジェクト計画書及び調達仕様書に基づき、運用・保守を行う上で基本とする作業内容、関係するほかの作業工程、そのスケジュール等について記載すること。 ・ 日次、週次、月次等の定型的な業務について、作業内容を記載すること。 また複数回発生した非定型業務の報告及びその定形業務化(手順書の作成等)の提案を含めること。 ・ 年次の作業内容には、運用業務の中で発生した運用上の課題、作業量の多い作業等について整理報告し、その改善(例えば自動化等)の提案を行う作業、情報システム運用継続計画の見直し作業、運用・保守計画書の見直し作業を含めること。 4 成果物に関する事項・ 運用・保守業務にて納品する成果物の内容、担当者、納品期限、納品方法、納品部数等について記載する。 5 運用・保守形態、運用・保守環境等・ 運用において採用する運用形態(オンサイト、リモート等)、運用環境(本番環境、検証環境、研修環境等の有無)等を記載する。 こと。 6 管理対象 受託者は本業務で開発するXXXシステム及びドキュメントについて保守を行うこと。 7 クラウドサービスの利用 運用作業、運用手順及び運用管理用のソフトウェアも含め、可能な限り統一化を図るとともに、自動化された機能及びクラウドサービスが提供する機能等を利用し、運用に係る役務を可能な限り効率化すること。  利用しているクラウドサービスの機能や性能等に変更が発生した場合、受託者側でクラウドサービスの変更に伴う開発中システムへの影響を確認し、システムの改修が必要な場合は、原則対応すること。 ただし、改修規模が大きい又は影響範囲が広い場合は主管課と協議の上対応を検討・実施すること。 8 サービスレベル 運用・保守業務で達成目標とするサービスレベル項目及びサービスレベルを主管課が協議の上、決定すること。  運用におけるリソース使用状況に基づき､毎年のリソース計画を策定する。 月間の運用実績を評価し、達成状況が目標に満たない場合はその要因の分析を行うとともに、サービスレベル達成状況の改善に向けた対応策を提案すること。 9 その他 上記に掲げる事項のほか、運用・保守を行う上での前提条件、時間、予算、品質等の制約条件等について記載する。 表 56 運用・保守実施要領の記載内容53項番 項目 補足1 コミュニケーション管理・ 運用・保守業務を実施する上で必要となるコミュニケーション手段について、会議体(会議体 名称、開催目的、開催スケジュール、出席者、報告内容等)、インシデント発生時 の報告ルート等について記載し、効率的かつ円滑なコミュニケーションを実現すること。 2 体制管理・ 運用・保守に携わる事業者における作業体制の管理手法等について記載する。 3 作業管理 ・ 運用・保守作業及びその品質の管理手法等について記載する。 4 リスク管理 運用・保守における作業を阻害する可能性のあるリスクを適切に管理するため、リスク認識の手法、リスクの管理手法、顕在時の対応手順等について記載すること。 5 課題管理 運用・保守において解決すべき問題について、発生時の対応手順、管理手法等について記載すること。 6 システム構成管理 運用・保守における情報システムの構成(ハードウェア、ソフトウェア製品、アプリケーションプログラム、ネットワーク、外部サービス、施設・区域、公開ドメイン等)の管理手法等について記載すること。 7 変更管理 運用・保守により発生する変更内容について、管理対象、変更手順、管理手法等について記載すること。 8 情報セキュリティ対策  運用・保守における情報漏えい対策等について記載すること。 (2) 運用・保守準備運用・保守に当たって、以下の準備作業の実施等を行うこと。 ア 監視設定運用業務を効率的に実施するため、監視、アラートについて、システムの特性、各種アラート発生時の重要度に応じたチューニング(マッチング文字列、閾値、アラート検知結果の重要度など)を行い、定量的な計測に基づいて監視を行うこと。 また、アラートの通知先、通知手段等は主管課と協議の上、決定すること。 イ バックアップサービスサービスの故障復旧に必要なデータのバックアップを定期的に取得すること。 また、故障復旧時における必要なデータのリストア作業の手順、役割分担等を事前に決定し、故障発生時には実施すること。 ウ 運用・保守手順書運用・保守実施要領及び運用・保守計画書に基づき、運用・保守手順書を作成すること。 (3) 共通的な要件ア 運用・保守期間稼働後、令和XX年XX月XX日まで運用・保守を行うこと。 イ 運用・保守報告書の作成運用・保守業務の実施結果を運用・保守報告書として取りまとめ、主管課が指定した日時までに納品すること。 ウ 情報セキュリティ対策の実施「3.10.情報セキュリティに関する事項」を踏まえて実施した情報セキュリティ対策の対応結果を情報セキュリティ対策実施報告書に取りまとめ、主管課が指定した日時までに納品すること。 54(4) システム稼働要件本システムの本番稼動に係る要件は「1.3業務実施の時期・時間」を参照すること(5) 主な運用作業一覧現時点で想定する主な運用作業の一覧について、以下に示す。 以下の内容を基に、本システムの設計及び開発時に、運用・保守計画書、運用・保守設計書及び運用・保守マニュアルの案を作成すること。 表 57 主な運用作業一覧項番運用作業の分類主な運用作業の内容1 パッチ適用 保守におけるパッチ適用要否の判断結果に基づき、パッチを適用の上、適用後の稼働確認を行う。 2ログ管理業務 操作ログやアクセスログ等のシステムログ、例外事象の発生に関するログを取得すること。  ログ解析機能の活用を前提として、適切なキャパシティ管理を行うこと。 キャパシティの改善が必要と判断された場合、キャパシティ改善提案を行うこと。  収集したログを一元的に管理し、不正侵入や不正行為の有無の点検・分析を効率的に実施すること。 3ジョブ管理業務 ジョブの登録・更新、ジョブの起動スケジュール(カレンダー)を登録し、ジョブの実施結果を確認、報告する。  主管課が必要性を認めた際は、主管課の指示に従い、ジョブの手動実行を行う。 4システム監視 サービスの運用状況を監視し、障害の発生またはその兆候を検知するとともに、障害を検知した際には重要性等で分類した上で、メールなどにより自動で通知する仕組みを構築すること。 監視には、例として以下のものがある。 ジョブ監視、死活監視、性能監視、リソース監視、障害監視、ログ監視(監視対象のログを監視し、特定の文字列パターンと一致した場合に障害とする方式)、セキュリティ監視、クラウドの構成監視(クラウドサービスを構成する要素を監視する方式)、外形監視(当該システムを利用するユーザーと同じ方法でアクセスし正常に動作しているか監視する方式)等 各種監視結果を定期的に集計・分析し、監視方法や閾値、通知の見直し等が必要な場合は、主管課の承認を得た上でこれに係る設計を行い、対応を実施すること。 ※システムサイジングについても定期的に分析を行い、主管課の承認を得た上で見直すこと。 5 問題管理 本サービスに対し、重大な影響を与えるインシデントや将来的に重大なインシデントに発展する可能性がある問題について影響評価を行った上で、緊急度及び優先度を定め、根本原因の調査及び解決策の立案を行うこと。 6 変更管理 課題管理機能の活用を前提として、適切な変更管理を実施すること。  構成要素を追加、変更又は廃棄する場合は、変更依頼書を起票すること。 7 リリース管理 主管課とリリース作業の日程、作業内容、依頼事項等の調整を行い、実施の計画をリリース計画書に記載すること。  リリースを実施した際、リリースに関する情報を「リリース管理台帳」にて管理すること。  「リリース管理台帳」には以下の項目を管理し、履歴を確認することとし、その管理が必要な項目についても管理する仕組みとすること。 ➢ 実施計画の内容➢ リリーステストの実施有無及び結果➢ リリース時期➢ 各種レビューの実施有無及び結果➢ リリース内容 リリース計画書については、リリース予定日より十分な期間を確保の上、前もって主管課の承認をもって提出すること。 なお、緊急なリリースを要する場合は主管課と協議すること。 8システム構成管理 本システムに係る全ての構成品目について、適切な構成管理を実施すること。  システム構成管理対象を特定し、管理レベルを定めること。 なお、システム構成管理対象は、本システムを構成するクラウドサービス、ソフトウェア製品、ソフトウェアのバージョン、アプリケーションプログラム、通信回線、公開ドメインのほか、本システムの運用・保守に係る全ての文書及55項番運用作業の分類主な運用作業の内容びデータとすること。 ただし、本システムの外部から提供を受けるものであり、運用・保守において変更を行わないものは、システム構成管理の対象外とする。  システム構成管理対象の変更について、変更履歴を追跡可能であること。  本番環境・検証環境の維持管理を行うこと。  本システムのアプリケーションはCIツールで管理すること。 9 バックアップ システムバックアップ、データバックアップを取得すること。  必要に応じてシステムリストア、データリストアを実施すること。 10 業務支援 主管課の指示に基づき、利用者の利用状況のデータを集計し、主管課に定期的に報告すること。  必要に応じて、データベースやディレクトリ等に施されるアクセス制御の設定変更を実施すること。  運用に必要な端末は受託者が用意すること。  ヘルプデスク担当者からの問合せ、またはサービスデスクからの問合せに対する FAQ を作成すること。 11 障害対応 障害発生時は、発生から解決までの一連の作業(受付、問題判別、業者間調整、調査解析、修復方法の検討、障害原因アプリケーションの再設計・製造・試験、再発防止・品質向上作業、報告書作成・報告実施、アプリケーション保守環境反映)を行うこと。  本システムの連携先システムにおいて障害が発生し、業務影響が発生した場合においても、連携先システム担当が実施する原因調査､代替策、解決策の検討及び処置を必要に応じて支援すること。  システム障害と想定される連絡を受け付けた際、別途、主管課より指示する担当者へ速やかにエスカレーションすること。  府省内担当者との応答内容の記録を残すこと。 12ヘルプデスク業務 本サービスの利用方法に関する問合せの受付からクローズまでを一元管理するヘルプデスクを設け、本サービス利用者からの問合せを受け付けること。  問い合わせの要件は以下に示す。 ➢ 受付時間・方法：「1.3業務実施の時期・時間」に記載➢ 平均処理時間：XXX➢ 平均応答速度：XXX➢ 一日の問い合わせ想定量：XXX ヘルプデスク担当者のスケジューリング等の運営を適切に行うこと。  ヘルプデスク担当者による対応手順、サービスレベル等を統一するため、ヘルプデスク運用マニュアルを作成し、主管課の承認を得ること。  ヘルプデスク運営の中でFAQ は適宜追加、更新等、メンテナンスを行うこと。  受け付けた問合せは、質問、インシデント、サービス要求、作業依頼等に分類した上で、対応日時、問合せ元、内容、回答状況等とともに記録すること。 なお、具体的な運用方法については、本サービスの設計開始以降に改めて検討する。  問い合わせ記録は受付件数、問い合わせ者情報、問い合わせ内容、回率、回答に要した期間、回答内容等を適切な粒度で整理した上で、定期的に問題発生状況を分析し、必要な対応を行うこと。  運用･保守の計画及び実施状況について、主管課の定める報告様式に従って取りまとめ、主管課に報告を行うこと。 (原則、月次での報告)13設計・開発事業者による報告・問合せ対応 問合せに関する調査完了後、ヘルプデスクへの回答を行うこと。  その他、適宜、主管課と必要に応じて密に連携を図り、ヘルプデスクの円滑な運営に資すること。 14インシデント管理 情報セキュリティインシデントが発生した場合は、「運用・保守実施要領」等に定めた手順に従ってインシデント対応を行うこと。 対応に当たっては、主管課、関係事業者と適宜調整の上で対応を行うこと。 15バージョンアップ対応 保守におけるバージョンアップ対応要否の判断結果に基づき、バージョンアップ対応を実施し、稼働後の動作確認を行うこと。 16 大規模災害  大規模災害等への対応訓練を行うこと。 56項番運用作業の分類主な運用作業の内容等対応訓練 ➢ 大規模災害対応訓練シナリオ見直し本番運用・保守の計画で定義されている訓練シナリオ・手順書を適宜見直し、必要に応じて、設計・開発事業者に確認を依頼すること。 訓練シナリオ・手順書を変更した場合は、主管課の承認を得ること。 ➢ 大規模災害対応訓練の実施受託者は、大規模災害発生時から復旧に係る作業について、主管課及び関係する事業者が迅速かつ適切に作業を実施できるよう、年に 1 回、訓練シナリオ・手順書に基づき、訓練を実施すること。 実施に当たっては、主に連絡ルートの確認を実施し、結果を「大規模災害等対応訓練完了報告書(本番運用開始後)」に記載し、主管課に報告すること。 なお、訓練への参加は、受託者と主管課のみとし、他事業者や外部連携システムは対象外とする。  情報漏洩への対応訓練を行うこと。 ➢ 情報漏洩対応訓練の実施受託者は、情報漏洩等に係る情報セキュリティインシデント対応について、主管課及び関係する事業者が迅速かつ適切に作業を実施できるよう、年に1 回、訓練シナリオ・手順書に基づき、訓練を実施すること。 実施に当たっては、主に連絡ルートの確認を実施し、結果を「情報漏洩等対応訓練完了報告書(本番運用開始後)」に記載し、主管課に報告すること。 なお、訓練への参加は、受託者と主管課のみとし、他事業者や外部連携システムは対象外とする。 17 運用改善 受託者は、システムの状況を主管課が定期的に把握できるように仕組みを整えること。 ➢ プロジェクトの目標とする指標、システムの利用者の利用状況➢ クラウドのリソース等、システムの利用状況・コストの発生状況 システムの利用状況については、少なくとも以下の項目および「2.4.(8) モニタリング対象データ一覧」に記載した項目を実施し、利用状況の分析とその後の改善策に資する項目を含めること。 ➢ 運用管理・保守業務の作業別の所要時間➢ 自動化や効率化が可能と思われる作業の洗い出し➢ システム及び運用・保守業務の改善提案 アイドリングなどの無駄／過剰なリソースを発見し、コスト削減につながる仕組みを整え、アドバイスも指摘すること 受託者は、システムの利用拡大や利便性向上のため、実績に基づいた定量的なデータや利用者からの問合せ内容等を分析し、多くの利用者が操作方法に迷う部分や誤操作を誘発する部分を把握した上でシステムの改善策を検討すること。 また主管課と協議の上、システムの改善を実施すること。 18サービスオペレーション支援 本サービスが動作するに当たり、必要となるデータベースの各種マスタ情報を維持管理すること。 また、マスタ情報管理のための GUI を具備しないマスタ情報の場合、変更依頼を前提として情報の登録、検索、更新、削除のための SQL を作成し、これを実行すること。  計画停止、保守作業、障害対応等により利用者への影響が生じる場合、本サービスのWeb サイトにお知らせを掲載するなどの方法により周知連絡を行うこと。  作業影響を生じる範囲について、不測の運用障害を回避する観点から、メンテナンス機能を利用してサービス閉塞・閉塞解除運用を実施すること。  アプリケーションの障害を防ぐため、システムメンテナンスの一環として、サーバを定期的に再起動する。 再起動後はサービスの動作確認等を行い、問題が無いことを確認すること。 再起動のタイミングは主管課と協議の上、決定すること。 19情報セキュリティ監査 主管課が情報セキュリティ監査を実施する場合がある。 その際はセキュリティ監査事業者との調整・ヒアリングへの協力を行うこと。 20アカウント管理 受託者は、主管課からの指示に基づき、ユーザーID(特権 ID 含む)の払い出し、削除、パスワード再発行を実施すること。  アカウントの利用状況の棚卸を実施すること。 実施するタイミングは、年1 回程度を想定しているが、具体的な時期については主管課と協議の上、決定すること。 21 その他業務  サーバ証明書の更新、ドメインの管理等を行うこと。 57保守に関する事項受託者は、運用・保守計画書及び運用・保守実施要領に基づき以下の作業を適切に実施すること。 (1) 保守業務の実施保守業務として以下を実施すること。 ア 問合せの受付時間は、「1.3業務実施の時期・時間」に記載の通りとする。 ただし、主管課が緊急かつ業務に支障を来すと判断した場合はこの限りではない。 イ 受け付けた問い合わせをインシデントとして管理し、インシデントのクローズまで、対応を継続すること。 ウ 障害について対応したときは、障害報告書を作成し、主管課に報告すること。 (2) 保守設計保守設計として以下を実施すること。 ア 役割分担の整理役割分担を行う際に以下の点に留意すること。  保守業務の設計に際し、受託者の責任範囲及びクラウドサービスを含めた関連事業者間の役割分担を整理すること。  新システムがクラウドサービス上で稼働することを踏まえ、各業者間の役割分担を考慮した上で、保守設計を行うこと。 イ クラウドサービスの利用クラウドサービスを利用する際に以下の点に留意すること。  保守設計を実施する上で、クラウドサービスの標準機能を可能な限り活用すること。  クラウドサービスによる自動化等により、省力化を実施すること。  運用・保守実施要領、運用・保守計画書及び運用・保守手順書については、クラウドサービスが提供する各サービスを活用することにより、作業のみならずドキュメント類についても効率的に作成すること。  利用するクラウドサービスにおいて、提供サービスの仕様上必要となるアップデートパッチの適用やメンテナンス等の対応に際して、システムへの影響度に鑑み、主管課と協議の上対応を行うこと。 または、自動適用を行う等の対応が可能となるよう、必要な仕組み(検知、適用、等)を準備すること。 (3) アプリケーションの保守アプリケーションの保守として以下を実施すること。 ア インシデント管理運用管理・監視等作業におけるインシデント管理と適切な連携を図ること。 イ 是正保守アプリケーションに起因した障害発生時、監査指摘事項への対応時等、アプリケーションの是正が必要な場合に、是正保守を行うこと。 58ウ 適応保守OS、ブラウザ、ミドルウェア等のバージョンアップ対応等、利用環境の変更への対応が必要な場合、アプリケーションに係る適応保守を行うこと。 エ 予防保守本サービスのアプリケーションに潜在的な問題が発見され、当該問題除去を目的とした変更が必要な場合又はアプリケーションコンポーネントについて新たに脆弱性が報告された場合に、予防保守を行うこと。 オ 改善措置上記イ～エに伴う改善措置を実施する際には以下の点に留意すること。  国民等の利用者に影響がある保守作業を実施する場合は、アプリケーション保守の実施効果、現在及び将来の利用者に対する影響の分析を行うこと。  アプリケーションに係る機能性、信頼性、使用性、効率性、保守性、移植性等の改善が必要な場合に、対処を行うこと。  Web 解析結果に基づき、本サービスのユーザーインタフェースについて、ユーザビリティ又は UX に関する課題を識別した場合、課題解決に資する是正保守、予防保守を行うこと。  Web サーバ、データベース等について、「表 57主な運用作業一覧 17運用改善」の結果を踏まえ、必要に応じて稼働環境の改善等に伴う設定変更を実施すること。 カ 根本原因の分析根本原因を分析する際に以下の点に留意すること。  是正保守及び予防保守の実施に当たり、障害、監査指摘、潜在する問題等に係る根本原因の分析を行うこと。 キ 検証修正したアプリケーションを本番環境へ展開(デブロイ)する前に、修正が適切に実施されているか否かについて検証環境において検証すること。 ク 文章の修正アプリケーション保守に伴い、ドキュメント(設計書、マニュアル等)の修正を要する場合は、速やかに修正を行うこと。 なお、改修等に伴い画面等に発生する変更が軽微な場合は、ドキュメントの更新方針等について別途主管課と協議すること。 (4) クラウドサービスの保守クラウドサービスの保守として以下を実施すること。 ア 利用しているクラウドサービスにおいて脆弱性及び不具合が確認された場合は、その対応について主管課と協議し、パッチ適用要否を判断すること。 イ クラウドサービスにおいてバージョンアップ等の情報が公開された場合には、バージョンアップに伴う影響調査を実施した上で、主管課と協議し、適用等の可否を決定すること。 なお、実施することとなったバージョンアップに伴う機器・サービス等の停止は計画停止に準ずるものとして扱う。 また、バージョンアップに起因して改修が必要な場合には、対応について別途主管課と協議すること。 59ウ クラウドサービスで利用している環境の最新化や更新は、原則として IaC(Infrastructure asCode)を活用しコードを変更し、変更後のコードを実行することにより実施すること。 エ 修正パッチ適用やバージョンアップ等を行う場合には、事前に検証環境において本サービスの運用に影響が生じないことを十分に検証し、環境更新の事前評価を実施すること。 (5) ソフトウェア保守ソフトウェアの保守として以下を実施すること。 ア ソフトウェア最新化本サービスを構成する全てのソフトウェアについて、製品不具合や情報セキュリティに関する脆弱性を修正するため、主管課と協議の上、ソフトウェア実行環境の形態に応じてソフトウェアを最新化すること。 イ 修正プログラム修正プログラム適用の際は以下の点に留意すること。  情報セキュリティや安定稼働の観点から緊急性が高いと考えられる修正プログラムについては、緊急適用を計画すること。 緊急性が低い修正プログラムについては、定期保守作業の中での適用を計画すること。  使用しているクラウドサービスの内容に変更が発生する際には、クラウドサービスより提供する情報を元にシステムへの影響範囲を調査の上、修正プログラムの適用可否を主管課へ報告すること。 適用が必要と判断された場合、クラウドサービスより提供されるソフトウェアに対する修正プログラムの適用作業を実施すること。 ウ 検証・デプロイ検証・デプロイを行う際は以下の点に留意すること。  ソフトウェア保守に当たっては、事前に検証環境において本サービスの運用に影響が生じないことを十分に検証すること。  ソフトウェア保守に伴い、本サービスの安定稼働に影響が生じる事態が予測される場合、主管課の指示に基づいてデプロイ実施の是非を判断すること。 エ 設計書への反映ソフトウェア保守によりソフトウェア構成に変更が生じた場合、設計書等へ変更内容を反映すること。 オ 保守条件保守条件は、「製品の導入や使用方法」、「製品の互換性や相互操作性」、「製品資料の解釈」、「構成サンプルの提供」、「修正策の情報提供」、「製品プログラム、製品コードに起因する障害」等の保守が提供されることを想定しているが、最終的な保守条件は、主管課と調整の上、保守設計において決定すること。 (6) 保守実績の評価及び改善保守実績の評価及び改善として以下を実施すること。 ア 本サービスの運営に関わる関係者間で本サービスの保守に係る情報や問題認識を共有し、保守業務の品質を継続的に維持・向上させること。 60イ 本システムが使用するアプリケーション、クラウドサービス、ソフトウェア等の保守実施状況について、日々の保守業務の中で収集する定量的な管理指標を定め、主管課と合意すること。 ウ ログ解析機能等を活用し、指標値の収集、評価及び管理を効率的に行うこと。 エ 管理指標の達成状況を評価し、未達の場合は原因分析を行い、改善措置を検討すること。 また、これらの実績、評価、改善措置について、定期報告すること。 オ ログ解析機能、Web 解析機能の活用を前提として、モニタリング及び運用過程を通じて得られた利用状況を分析することにより、ライフサイクルコスト低減の観点から、利用するクラウドサービスの所要量及びソフトウェアライセンスの削減可能性を検討すること。 また、利用状況の実績、評価、コスト削減可能性について、定期報告すること。 (7) ドキュメントの保守設計・開発関連ドキュメント及び運用・保守関連ドキュメントが、受託者の契約期間において、最新の状態であるよう維持・更新等を行う。 (8) 軽微な改修運用・保守の期間中に必要となる軽微な改修として以下を実施すること。 ア 運用・保守の期間中に、利用者からの要望対応、不具合の改善、環境変化への対応等の目的で軽微な改修を行うことを想定している。 改修への対応工数(必要に応じて教育訓練等を含む)として、合計X人月の作業を見込むこと。 イ 個々の改修に当たっては、改修範囲、影響範囲等を分析して必要工数を事前に見積もった上で、主管課の承認を得た上で作業を実施すること。 ウ 月次の定期報告において、個々の改修の実施状況(工数の消化状況等)について報告すること。 また、改修が必要と考えられる事項が受託者においてある場合は積極的な提案を行うこと。 エ 個々の改修が完了した後に、工数実績を提示すること。 また、計画工数と実績工数の差異を分析した上で、その後の改修案件のおける見積精度向上と改修生産性向上に努めること。 様式環境負荷低減のクロスコンプライアンス実施状況報告書以下のア～エの取組について、実施状況を報告します。 ア 環境負荷低減に配慮したものを調達するよう努める。 具体的な事項実施した／努めた左記非該当・対象となる物品の輸送に当たり、燃料消費を少なくするよう検討する(もしくはそのような工夫を行っている配送業者と連携する)。 ☐ ☐・対象となる物品の輸送に当たり、燃費効率の向上や温室効果ガスの過度な排出を防ぐ観点から、輸送車両の保守点検を適切に実施している。 ☐ ☐・農林水産物や加工食品を使用する場合には、農薬等を適正に使用して(農薬の使用基準等を遵守して)作られたものを調達することに努めている。 ☐ ☐・事務用品を使用する場合には、詰め替えや再利用可能なものを調達することに努めている。 ☐ ☐・その他( )・上記で「実施した／努めた」に一つもチェックが入らず(全て「左記非該当」)、その他の取組も行っていない場合は、その理由( )イ エネルギーの削減の観点から、オフィスや車両・機械などの電気、燃料の使用状況の記録・保存や、不必要・非効率なエネルギー消費を行わない取組(照明、空調のこまめな管理や、ウォームビズ・クールビズの励行、燃費効率の良い機械の利用等)の実施に努める。 具体的な事項実施した／努めた左記非該当・事業実施時に消費する電気・ガス・ガソリン等のエネルギーについて、帳簿への記載や伝票の保存等により、使用量・使用料金の記録に努めている。 ☐ ☐・事業実施時に使用するオフィスや車両・機械等について、不要な照明の消灯やエンジン停止に努めている。 ☐ ☐・事業実施時に使用するオフィスや車両・機械等について、基準となる室温を決めたり、必要以上の冷暖房、保温を行わない等、適切な温度管理に努めている。 ☐ ☐・事業実施時に使用する車両・機械等が効果的に機能を発揮できるよう、定期的な点検や破損があった場合は補修等に努めている。 ☐ ☐・夏期のクールビズや冬期のウォームビズの実施に努めている。 ☐ ☐・その他( )・上記で「実施した／努めた」に一つもチェックが入らず(全て「左記非該当」)、その他の取組も行っていない場合は、その理由( )ウ 廃棄物の発生抑制、適正な循環的な利用及び適正な処分に努める。 具体的な事項実施した／努めた左記非該当・事業実施時に使用する資材について、プラスチック資材から紙などの環境負荷が少ない資材に変更することを検討する。 ☐ ☐・資源のリサイクルに努めている(リサイクル事業者に委託することも可)。 ☐ ☐・事業実施時に使用するプラスチック資材を処分する場合に法令に従って適切に実施している。 ☐ ☐・その他( )・上記で「実施した／努めた」に一つもチェックが入らず(全て「左記非該当」)、その他の取組も行っていない場合は、その理由( )エ みどり戦略の理解に努めるとともに、機械等を扱う場合は、機械の適切な整備及び管理並びに作業安全に努める。 具体的な事項実施した／努めた左記非該当・「環境負荷低減のクロスコンプライアンスチェックシート解説書 －民間事業者・自治体等編－」にある記載内容を了知し、関係する事項について取り組むよう努める。 ☐ ☐・事業者として独自の環境方針やビジョンなどの策定している、もしくは、策定を検討する。 ☐ ☐・従業員等の向けの環境や持続性確保に係る研修などを行っている、もしくは、実施を検討する。 ☐ ☐・作業現場における、作業安全のためのルールや手順などをマニュアル等に整理する。 また、定期的な研修などを実施するように努めている。 ☐ ☐・資機材や作業機械・設備が異常な動作などを起こさないよう、定期的な点検や補修などに努めている。 ☐ ☐・作業現場における作業空間内の工具や資材の整理などを行い、安全に作業を行えるスペースを確保する。 ☐ ☐・労災保険等の補償措置を備えるよう努めている。 ☐ ☐・その他( )・上記で「実施した／努めた」に一つもチェックが入らず(全て「左記非該当」)、その他の取組も行っていない場合は、その理由( )