情報システムに係る政府調達におけるセキュリティ要件策定マニュアル

2022 年７月 29 日
内閣官房 内閣サイバーセキュリティセンター

目次

1章

マニュアルの概要 .................................................................................................................. 4

1.1 背景........................................................................................................................................ 4
1.2 目的........................................................................................................................................ 4
1.3 位置づけ ................................................................................................................................ 5
1.4 想定読者 ................................................................................................................................ 5
1.5 活用範囲 ................................................................................................................................ 5
2章

用語定義 ................................................................................................................................ 6

3章

本マニュアルの使い方 .......................................................................................................... 7

3.1 政府調達における利用のタイミング..................................................................................... 7
3.2 手順の全体像 ......................................................................................................................... 9
3.3 付録及び別冊の構成 .............................................................................................................11
4章

業務要件の検討 ................................................................................................................... 13

4.1 目的及び業務の洗い出し（ステップ 1） ............................................................................ 14
4.2 業務の特徴の整理（ステップ 2） ....................................................................................... 15
4.3 システム概要図の作成（ステップ 3）................................................................................ 18
4.4 定型設問による業務要件の詳細化（ステップ 4） ............................................................. 205章

セキュリティ要件の策定 ..................................................................................................... 225.1 判断条件による対策方針の検討（ステップ 5） ................................................................. 24
5.2 対策要件の決定（ステップ 6）........................................................................................... 26
5.3 調達仕様書への反映（ステップ 7） ................................................................................... 27
6章

その他の考慮事項 ................................................................................................................ 312

目次（図表）図 1 情報システムの調達プロセスにおける本マニュアルの位置づけ......................................... 7
図 2 セキュリティ要件策定手順の全体像 ................................................................................ 10
図 3 別冊．クラウド設計・開発編の位置づけ ........................................................................... 10
図 4 対策要件集における対策区分 ........................................................................................ 22
図 5 判断条件による検討の例 ................................................................................................ 24
表 1 標準ガイドラインが定める調達仕様書に記載する事項 ...................................................... 8
表 2 システム概要図作成のための 3 つの観点....................................................................... 13
表 3 目的と業務の洗い出しの例 （箇条書きの場合） .............................................................. 14
表 4 目的と業務の洗い出しの例 （図示の場合） ..................................................................... 14
表 5 主体の洗い出し及び業務の細分化の例 .......................................................................... 15
表 6 業務の概要及び情報の洗い出しの例.............................................................................. 16
表 7 利用環境・手段の洗い出しの例....................................................................................... 17
表 8 システム概要図の表記ルール及び作成例....................................................................... 18
表 9 システム概要図作成のための「チェックリスト」 ................................................................. 19
表 10 業務要件詳細化のための「定型設問」........................................................................... 20
表 11 対策要件集の構成 ........................................................................................................ 23
表 12 対策方針決定のための「判断条件」 .............................................................................. 25
表 13 本マニュアルの検討結果の記載箇所の例 （標準ガイドラインの記載例の場合） ............ 28

3

1章 マニュアルの概要
この章では、「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル」（以下「本マニュアル」という。）を作成した背景、その目的・位置づけ及び活用範囲について述べる。

1.1 背景政府機関の情報システムにおいて情報セキュリティ対策を適切に講じるためには、情報システムのライ
フサイクル（企画・設計・開発・運用・廃棄）における企画段階（調達段階）から情報セキュリティの観点を意識し、その際に必要となる調達仕様にセキュリティ要件を適切に組み込むことが求められる。
また、調達仕様におけるセキュリティ要件の曖昧さや過不足は、調達側と供給側の相互理解と合意形成を阻害し、調達側と供給側の双方に不利益を発生させる要因となる。これらに起因して、システムの実態によらず網羅的かつ過剰なセキュリティ対策に伴うコスト増加、要件解釈のばらつきによる提案内容の差異からの不公平な競争入札、設計・開発段階での手戻り、運用開始後のセキュリティ事故発生などといった不利益が生じる可能性が考えられる。
このような問題意識を受けて、情報セキュリティ政策会議（議長：内閣官房長官）において議論がなされた。同会議では、「国民を守る情報セキュリティ戦略」を決定し、また、同戦略の下、政府の重点施策の年度計画として決定した「情報セキュリティ 2010」では、「情報システムに係る政府調達に関して、情報セキ
ュリティ対策が適切に組み込まれる仕組みの構築及び組み込むべき情報セキュリティ要件の取りまとめを行う。」とした。
同会議の議論を受け、内閣官房情報セキュリティセンターを事務局とし、経験・知見を有する有識者やベンダーを交えた「情報セキュリティを企画・設計段階から確保するための方策（SBD: Security By Design）に係る検討会」が設置され、情報システムにおける情報セキュリティ対策を考慮したライフサイクル管理強化の実現に向けた具体的な方策について議論が進められた。
本マニュアルは、当該検討会において、上記の課題を踏まえて平成 23 年 3 月に初版を公表した。平成
27 年 5 月には、サプライチェーン・リスク対応についての記載を追記する等の改定を行い、内容の充実を図ってきた。また、令和４年７月には、本マニュアルに関連するドキュメントとの整合を取るとともに、政府においても利用が拡大しているクラウドサービスの「設計・開発フェーズ」で活用できる、基本的なセキュリテ
ィ対策の設定項目等を示した別冊．クラウド設計・開発編の位置づけについての記載を追加する等の改定を行なった。

1.2 目的
本マニュアルは、政府機関における情報システムの調達仕様書に記載する「セキュリティ要件」の策定方法を解説することによって、情報システムの企画段階からセキュリティ対策を適切に組み込むことを目的としている。

4

特に、本マニュアルにおける策定方法は、調達を行う者がセキュリティ要件を自ら責任をもって策定するとともに、重要かつ効果的なセキュリティ要件については、優先的かつ確実に調達仕様書に記載することを重視している。

1.3 位置づけ
政府では、政府情報システムの標準的な整備及び管理について、「デジタル・ガバメント推進標準ガイ
ドライン（令和４年４月 20 日デジタル社会推進会議幹事会決定）」（以下「標準ガイドライン」という。）によって、その手続・手順に関する基本的な方針及び事項並びに政府内の各組織の役割等を定める体系的な政府共通のルールを定めている。
本マニュアルは、政府機関の職員が上記の標準ガイドラインに基づいて情報システムを調達する際に、セキュリティ要件の策定にあたって活用されることを想定したものである。したがって、本マニュアルの導
出対象はセキュリティ要件であって、情報システム全体の要件ではないことに留意する必要がある。

1.4 想定読者
本マニュアルの想定読者は、政府機関の職員のうち、情報システムの調達を担当する調達担当者（以下「調達担当者」という。）及び情報システムを供給する事業者である。本マニュアルを活用することで、調達担当者にとっては、調達仕様書にセキュリティ要件を適切に組み込むことが可能となる。一方、情報シ
ステムを供給する事業者にとっては、調達仕様書に記載されたセキュリティ要件の導出過程における考え方を理解することが可能となる。
なお、本マニュアルは政府機関における情報システムの調達プロセスに沿った記載となっているが、独立行政法人及び指定法人においても、自組織に適用可能な事項については活用されたい。

1.5 活用範囲
本マニュアルの活用範囲（対象として想定している情報システムの範囲）は、基幹 LAN システムや共通
基盤システムなど総合的かつ緻密なリスク分析を要する情報システムを除く、政府機関における「新規構築」及び「更改」を行う情報システム全般であるが、費用等との関係によって、企画段階から情報システム
に関する技術の専門家が参画することが難しい中小規模の情報システムの調達に対して特に有効である。

5

2章 用語定義
用語
実施レベル

語義
セキュリティ対策の実施の程度（強度）を「低位」「中位」「高位」の 3 段階にて表す本
マニュアル独自の尺度のこと。

対策要件「対策要件」は、情報セキュリティ対策のために情報システムが備えるべき機能に求対策要件集められる条件のことであり、「対策要件集」は、対策要件を本マニュアルにて独自に対策区分一覧化したもののこと。対策要件集は、「対策区分」と呼ぶ８種類の区分及び対策区

対策方針

分の中の小区分である「対策方針」によって対策要件を整理している。（5 章参照）

定型設問

情報システムに関する共通的な業務要件について本マニュアルが独自に定めた設問のこと。調達担当者が設問の回答を検討することによって業務要件の詳細化を促すために用いられる。（4.4 節参照）

判断条件

業務要件をあてはめて、優先すべきセキュリティ対策の方向性を導出するための条件のこと。（5 章参照）

利用環境・手段

主体が、情報を処理（作成、保存、送受信等）するために用いる環境・手段のこと。
（4 章参照）

6

3章 本マニュアルの使い方
この章では、調達仕様書に記載すべきセキュリティ要件を導出するための基本的な考え方及び全体の手順について述べる。

3.1 政府調達における利用のタイミング
本マニュアルは、図 1 に示すように情報システムの調達プロセスにおける発注側の調達担当者が、調達仕様書にセキュリティ要件を記載するための手順を定め、作業を支援するものである。 1
標準ガイドラインは、調達仕様書の作成にあたって留意すべき事項として「事業者が提案内容を検討するために不可欠な情報が網羅される」ことを求めている。
調達担当者は、情報システムのセキュリティ要件に関しても同様の点に留意し、各府省庁の情報セキュ
リティポリシーに準ずるとともに、セキュリティ機能の提案に不可欠な情報を曖昧性がない形で調達仕様書に記載する必要がある。本マニュアルはこのような場面での活用を想定している。

受注側（民間事業者）【参考見積もり】【予算要求（準備）】【提案内容及び費用検討】【応札及び落札】【仕様書に基づく
設計】【設計書策定】【契約発注準備】（事業の目的及び予算規模の提示等）

発注側（調達担当者）

予算要求資料（事業概要資料）

業務要件【予算要求】【予算査定】【予算案決定】【予算成立】

調達仕様書

セキュリティ要件の検討支援【標準ガイドライン】 【本マニュアル】【入札公告】【受注者決定】予算編成段階

企画段階

設計・
開発段階

運用
段階

評価
段階

図 1 情報システムの調達プロセスにおける本マニュアルの位置づけ

1

必要な情報セキュリティ対策が予算不足によって実施できない事態を避けるためには、本マニュアルを企画段階に加えて予算編成段階においても活用し、必要なコストを見極めて予算編成に反映することが望ましい。

7

表 1 は標準ガイドラインにおいて定められている「調達仕様書」に記載すべき事項である。
本マニュアルが策定の対象とするセキュリティ要件の記載箇所は、主に「ウ 情報システムに求める要件（非機能要件）」の「(5) 信頼性」、「(10) 情報セキュリティ」、「(12) テスト」、「(16) 運用」及び「(17) 保守」
である。また、セキュリティ要件の策定過程で明らかになる業務要件には、セキュリティ要件を満たすセキ
ュリティ機能を提案する際に不可欠な情報となる可能性が高いものが含まれるため、そのような情報は「ウ情報システムに求める要件（非機能要件）」の「(11) 情報システム稼働環境」及び「エ 作業の実施内容」の「(1) 作業の内容」に記載する。
表 1 標準ガイドラインが定める調達仕様書に記載する事項
項目

主な記載内容ア

調達案件の概要(1) 調達の背景、(2) 目的、(3) 期待する効果、(4) 業務・情報システムの概要、(5) 契約期間、(6)作業スケジュール等

イ

調達案件及び関連調達案件の調達単位、調達の方式等(1) 調達案件及びこれと関連する調達案件の調達単位、(2)
調達の方式、(3) 実施時期等

ウ

情報システムに求める要件（「サ 附属文書」の「(1) 要件定義書」に具体的な内容を記載する。）

業務要件(1) 業務実施手順、(2) 規模、(3) 時期・時間、(4) 場所等、
(5) 管理すべき指標、(6) 情報システム化の範囲、(7) 業務の継続の方針等、(8) 情報セキュリティ

機能要件(1) 機能、(2) 画面、(3) 帳票、(4) データ、(5) 外部インタフェ
ース

非機能要件

(1) ユーザビリティ及びアクセシビリティ、(2) システム方式、(3)規模、(4) 性能、(5) 信頼性、(6) 拡張性、(7) 上位互換性、(8) 中立性、(9) 継続性、(10) 情報セキュリティ、(11) 情報シ
ステム稼働環境、(12) テスト、(13) 移行、(14) 引継ぎ、(15)
教育、(16) 運用、(17) 保守エ

作業の実施内容(1) 作業の内容、(2) 成果物の範囲、(3) 納品期日等

オ

作業の実施体制・方法(1) 作業実施体制、(2) 作業要員に求める資格要件、(3) 作業場所、(4) 作業の管理に関する要領等

カ

作業の実施

(1) 機密保持、(2) 資料の取扱い、(3) 遵守する法令等

キ

成果物の取扱い(1) 知的財産権の帰属、(2) 契約不適合責任、(3) 検収等

ク

入札参加資格(1) 入札参加要件、(2) 入札制限ケ

再委託

(1) 再委託の制限、(2) 再委託を認める場合の条件、承認手
続、監査及び再委託先の契約違反等に関する責任についての定め等

コ

その他特記事項（前提条件、制約条件、要件定義、調達仕様書の変更手順
等）

サ

附属文書

(1) 要件定義書、(2) 参考資料、(3) 事業者が閲覧できる資料
一覧表、(4) 閲覧要領 、(5) 提案書等の審査要領、(6) その他事業者の提案に必要な資料※ 下線部分はセキュリティ要件又はその関連情報の記載が想定される箇所
出典：「デジタル・ガバメント推進標準ガイドライン（令和４年４月 20 日デジタル社会推進会議幹事会決定）」に基づき作
成8

3.2 手順の全体像
情報システムのセキュリティ要件を策定するためには、情報セキュリティに影響を与える「要因の洗い出し」が必要である。そのためには、対象の情報システムにおける保護すべき情報及びその取り扱い方を明らかにすることが不可欠である。これは業務要件を明らかにすることに他ならない。
そこで、本マニュアルが定める手順は、図 2 のようにセキュリティ要件の策定に必要な「（１） 業務要件の検討」を行った後に、「（２） セキュリティ要件の策定」を行うものとしている。それぞれの手順の概要
は下記の通りである。
(1) 業務要件の検討
調達担当者は、情報システムを調達する「目的」及び対象とする「業務」を洗い出した上で、「主体」「情報」及び「利用環境・手段」の 3 つの観点を意識して業務の特徴を整理することによって、情報システムに係る「業務要件」を抽出する。
その上で、調達担当者は抽出した業務要件を「システム概要図」と呼ぶ図に表して俯瞰すること
によって業務要件に不足や矛盾点がないことを確かめるとともに、「定型設問」に回答することによって業務要件の詳細化を図り作業の質を高める。
(2) セキュリティ要件の策定
調達担当者は、(1) にて検討した業務要件を踏まえ、「対策要件集」から調達する情報システムにふさわしいセキュリティ要件を選定して、「調達仕様書」に記載する。対策要件集とは、情報シス
テムの標準的なセキュリティ要件をまとめたものである。
本マニュアルでは、このセキュリティ要件の選定作業を可能な限り定型化するため、優先すべき
セキュリティ対策の方向性を導出する「判断条件」、セキュリティ対策の実施の程度を表す「実施レベル」といった独自の概念を用いた手順を定めている。
なお、業務要件の検討方法として、上記の（１）と同等の検討結果を得る他の方法があれば、それを代替的に用いても構わない。また、既存の情報システムの拡充の場合には、追加部分のみではなく既存部分も含めた情報システム全体を対象に上記の手順を実施する必要がある。 2

2

情報システムに新たな構成要素が加わり、既存部分と追加部分が相互に影響し合うことによって生じるセキュ
リティ課題の検討が必要となるため。

9

(1) 業務要件の検討 ［※ 他の方法による代替可］
ステップ１

ステップ２

目的及び業
務の洗い出し

業務の特徴
の整理

ステップ３
システム概要図の作成

ステップ４
定型設問による業務要件の詳細化

ステップ５

ステップ６

ステップ７

対策方針
の検討

対策要件
の決定

調達仕様書
への反映

（システム概要図を掲載）

【主体】

誰が？

【目的】

(2) セキュリティ要件の策定

・________________【業務】
・______________
・__________
・_____________

何を？

【情報】

【利用環境・手段】
どのように？

インターネット

対策要件集から調達仕様を反映

表記ルールにより見える化

省内LAN【システム概要図】【調達仕様書】

判断結果により対策要件の【実施レベル】
を選定【対策要件集】

回答

業務要件を判断条件に適用【判断条件】【定型設問】【業務要件】（必要に応じて業務要件を掲載）

図 2 セキュリティ要件策定手順の全体像

10

3.3 付録及び別冊の構成
本マニュアルにおける付録及び別冊の位置づけについて述べる。
付録 A から D に関しては、本マニュアルと同様に「調達フェーズ」において活用することを想定している。また、別冊．クラウド設計・開発編に関しては「設計・開発フェーズ」での利用を想定しているが、クラウドサービスの利用を前提とした調達における「調達フェーズ」においても参考とすることが望ましい。
付録 A．対策要件集
本マニュアルの 5 章において示す対策要件集と実施レベルに応じた想定脅威や対策の効果、調達仕様書への記載例等を一覧にまとめたものであり、調達仕様書に記載する対策要件を決定するために使用するもの。
付録 B．政府機関統一基準群対応表
付録 A．対策要件集を参考にして作成した調達仕様書のセキュリティ要件と、「政府機関等のサイバーセキュリティ対策のための統一基準」（以下「統一基準」という。）の各遵守事項との対応関係を確認することができる。なお、確認の結果、調達担当者が調達仕様書のセキュリテ
ィ要件の内容に過不足があると判断した場合には、統一基準の遵守事項等を踏まえ調達仕様書の記載内容を見直すことが可能となる。
付録 C．マニュアル活用例
特定の用途を例とした情報システムを調達する際に本マニュアルの活用例を示したもの。本付録を使用することで、本マニュアルの全体像の概要を把握することができる。
付録 D．用語解説
本マニュアル及び付録 A．対策要件集において使用されている一般用語を解説する。
別冊．クラウド設計・開発編
本マニュアルは、情報システムライフサイクルの「調達フェーズ」を対象とし、政府情報シ
ステムの調達仕様書に適切なセキュリティ要件を盛り込むことで設計・開発フェーズ等における要件の抜け漏れを防止することを目的としている。
他方、別冊クラウド設計・開発編は、情報システムライフサイクルの「設計・開発フェーズ」
を対象とし、本マニュアルで定めたセキュリティ要件に則り、クラウドサービスの基本的設定
項目等を示すことで、設計・開発時のセキュリティ対策の実装を支援することを目的としている。
したがって、別冊クラウド設計・開発編は機関等の担当者がクラウドサービスを利用して情報システムを構築する際に参照するものである。

11

図 3 別冊．クラウド設計・開発編の位置づけ

12

4章 業務要件の検討
この章では業務要件の検討手順を解説する。調達担当者は、以降の手順に従って「システム概要図」と呼ぶ図の作成を通じて基本的な業務要件を洗い出し、その上で「定型設問」に回答することによって業務要件の詳細化を図る。
システム概要図とは、表 2 の３つの観点から、「業務」と「業務における情報の取り扱い方」を中心に視覚化して、業務要件を俯瞰するためのものである。調達担当者は、システム概要図の作成によって、「どのような情報が、どこからどこに、どのような手段を介してやりとりされるのか」といった情報システムの構築に必要な「情報の流れ」を把握することができる。情報の流れの把握は、情報セキュリティに関する脅威が発生しやすい箇所、すなわちリスクを検討すべき箇所の特定に有効である。また、システム概要
図の内容は具体的である方が良いが、業務要件の見通しが悪くなるほどの過度な詳細化は好ましくない。
以降では、調達担当者が実施するシステム概要図の作成手順及び定型設問による業務要件の詳細化の手順について解説する。
表 2 システム概要図作成のための 3 つの観点
観点

説明

例

主体

行政サービスの利用や提供を行う情報

国民、行政事務を担当する者、シス

システム、あるいは当該業務を実施する

テム運用者・管理者等

者のこと
情報

主体が行政サービスや業務を通じて取り申請書、許可証、個人情報等扱う対象であって、送受信等の処理をされる対象のこと
利用環境・手段

主体が、情報を処理（作成、保存、送受端末、サーバ、記録媒体、IC カード、信等）するために用いる環境・手段のこと

ネットワーク等

13

4.1 目的及び業務の洗い出し（ステップ 1）
まず、情報システムの「名称」及び情報システム導入の「目的」を定める。目的の方向性は、例えば、「業務効率の向上」「業務コストの低減」「行政サービスの改善」「新たな行政サービスの実現」などが考えられるが、できるだけ具体的かつ明確な表現を用いて目的を明文化すると良い。
続いて、目的に見合う具体的な「業務」を整理する。業務とは、例えば、行政事務、国民等に対する行政サービスの提供等である。この段階で整理すべき内容は概略を簡潔にまとめたもので良い。同時に業務に関わる人物や付随書類等も整理しておくと後の作業に有効である。
以上の検討結果は、表 3 のように簡単な箇条書きの体裁でまとめる程度で良いが、表 4 のように簡易な図の体裁でまとめておくと客観的により分かりやすいものとなる。

表 3 目的と業務の洗い出しの例 （箇条書きの場合）
項目

内容

名称

国民参加型政策立案システム

目的

インターネットを活用して政策に関する提案・意見を国民から広く募り、参加者同士による議論及び投票等によって、国民参加による政策立案のしくみを確立すること。

業務

(1)

「国民」による政策に関する意見・コメントの投稿(2)「事務局」からの政策に関する情報提供及び利用者の管理

表 4 目的と業務の洗い出しの例 （図示の場合）
項目

内容

名称

国民参加型政策立案システム

目的

インターネットを活用して政策に関する提案・意見を国民から広く募り、参加者同士による議論及び投票等によって、国民参加による政策立案のしくみを確立すること。

業務
政策に関する意見・コメントの投稿

国民政策に関する情報提供及び利用者の管理【国民参加型政策立案システム】

14

事務局

4.2 業務の特徴の整理（ステップ 2）

4.2.1 主体の洗い出し
ステップ 1 にて洗い出した業務に関与する主体（人物、組織、情報システム等）を洗い出す。また、表 5のように業務や行政サービスを細分化しておくと後の作業が進めやすくなる上、主体の洗い出し漏れにも気づきやすい。
細分化にあたっては、対象とする業務領域における特有の業務イベント（例えば、サービスや人事制度
上、特定の時期に集中的に発生する業務等）を洗い出すと、重要な業務の気づきにつながるため有効である。
さらに、情報システムの運用業務を意識し、「情報システムの管理者」、「連携する既存の情報システム」なども必要に応じて主体に加えること。

表 5 主体の洗い出し及び業務の細分化の例
主体

業務

業務 （細分化後）

国民

政策に関す
る意見・コメントの投稿

利用登録

業務（細分化後）の概要

情報

利用環境・手段

意見・コメントの投稿、
投票
意見・コメントの閲覧

事務局

政策に関す
る情報提供
及び利用者
の管理

意見に対する回答、修正事務局からの周知
利用者の管理

シ ス テ
ム管理
者

情報システ
ム の 利用 状
況の把握及び管理

利用状況の把握
不正利用及び障害の監視、追跡システムのバックアップと復旧※

下線部は、表 3 又は表 4 の内容を踏まえ検討を行い新たに追加した部分。灰色の箇所は次節以降にて記入。

15

4.2.2 情報の洗い出し
洗い出した主体ごとに「業務」の概要を明文化し、各業務にて取り扱う「情報」を表 6 のように洗い出す。
業務や行政サービスの「目的」及び「誰の情報が誰から誰に流れるのか」を意識して検討すると、情報の洗い出しの漏れに気づきやすい。
一方、行政サービスの関連制度や行政サービスの利用方法等によって必要書類の書式や処理の流れ等が規定されている場合には、そのような点から情報を洗い出すと検討作業の確実性が増す。
また、ここまでの検討の過程で業務や主体の細分化や追加の必要性に気付く場合があるため、そのような場合は、必要に応じてステップ 1 に戻り手順を繰り返し実施する。
表 6 業務の概要及び情報の洗い出しの例
主体

業務

業務 （細分化後）業務（細分化後）の概要

情報

国民

政策に関す
る意見・コメントの投稿

利用登録

個人情報を登録して、サービスの利用資格を得る。

「個人情報」 （氏名、ニックネーム、性別、
年齢、職種、連絡先
等）

意見・コメントの投稿、投票

新規の意見や他者の意見に対するコメントの投稿及び投票を行う。

「意見」「コメント」 （タイトル、本文、投稿者
名、投稿日時等）

意見・コメントの閲覧

意見やコメントを検索し、閲覧する。

「意見」「コメント」 （タイトル、本文、投稿者
名、投稿日時等）

意見に対する回答、修正

意見に対する事務局回答の投稿及び不適切な意見の削除を行う。

「回答」 （本文、投稿
者名、投稿日時等）

事務局からの周知

サービス停止や注意事
項等の利用者に対する周知を行う。

「お知らせ文面」

利用者の管理利用者の登録情報の確認、修正等の管理業務を行う。

「個人情報」 （氏名、ニックネーム、性別、
年齢、職種、連絡先
等）

利用状況の把握

利用者の登録状況、アクセス状況、意見やコメントの集計を行う。

「利用統計」 （全体及び意見ごとのアクセス
数、利用者の登録数
等）

不正利用及び障害の監視、追跡アクセス状況の監視及びログ等を元にした原因究明を行う。

「履歴」 （アクセス、認証、利用ログ等）

システムのバックアップと復旧システムのデータを定期
バックアップ及び障害時の復旧を行う。

「システムデータ」

事務局

シ ス テ
ム管理
者

※

政策に関す
る情報提供
及び利用者
の管理

情報システ
ム の 利用 状
況の把握及び管理

下線部は、表 5 の内容を踏まえ検討を行い新たに追加した部分。灰色の箇所は次節以降にて記入。

16

利用環境・手段

4.2.3 システム化対象の決定ステップ 1 にて明確化した導入目的を踏まえ、ここまでの作業で明らかにした業務のうちシステム化対象とする業務を決定する。ここで定める範囲がセキュリティ要件の策定対象となる。

4.2.4 業務に用いる環境の決定
システム化対象に定めた「業務」の実施にあたって各主体が用いる「利用環境・手段」を決定し、表 7のように整理する。利用環境・手段とは、例えば、主体が情報システムにアクセスするために用いる機器、情報の作成、保存等に用いる機器及び情報を送受信するためのネットワーク等のことである。
表 7 利用環境・手段の洗い出しの例
主体

業務

業務 （細分化後）業務（細分化後）の概要

情報

利用環境・手段

国民

政策に関する意見・コメントの投稿

利用登録

個人情報を登録して、サービスの利用資格を得る。

「個人情報」 （氏名、ニックネーム、性別、
年齢、職種、連絡先
等）

PC、携帯電話、ス
マートフォン、インターネット

意見・コメントの投稿、投票

新規の意見や他者の意見に対するコメントの投稿及び投票を行う。

「意見」「コメント」 （タイトル、本文、投稿者
名、投稿日時等）

意見・コメントの閲覧

意見やコメントを検索し、閲覧する。

「意見」「コメント」 （タイトル、本文、投稿者
名、投稿日時等）

意見に対する回答、修正

意見に対する事務局回答の投稿及び不適切な意見の削除を行う。

「回答」 （本文、投稿
者名、投稿日時等）

事務局からの周知

サービス停止や注意事
項等の利用者に対する周知を行う。

「お知らせ文面」

利用者の管理利用者の登録情報の確認、修正等の管理業務を行う。

「個人情報」 （氏名、ニックネーム、性別、
年齢、職種、連絡先
等）

利用状況の把握

利用者の登録状況、アクセス状況、意見やコメントの集計を行う。

「利用統計」 （全体及び意見ごとのアクセス
数、利用者の登録数
等）

不正利用及び障害の監視、追跡アクセス状況の監視及びログ等を元にした原因究明を行う。

「履歴」 （アクセス、認証、利用ログ等）

システムのバックアップと復旧システムのデータを定期
バックアップ及び障害時の復旧を行う。

「システムデータ」

事務局

シ ス テ
ム管理
者

※

政策に関す
る情報提供
及び利用者
の管理

情報システ
ム の 利用 状
況の把握及び管理

下線部は、表 6 の内容を踏まえ検討を行い新たに追加した部分。

17

PC、内部ネットワ
ーク

PC、管理用 LAN

4.3 システム概要図の作成（ステップ 3）
前節までの作業結果を元にして、表 8 のように、表記ルールに従ってシステム概要図を作成する。
システム概要図は、利用者と情報システム等の主体同士の関係、利用環境・手段、情報の流れが具体的に分かり、かつ簡潔で見やすいものとなるように工夫する。表 9 のチェックリストを利用して点検を行うと、図の品質が向上する。
表 8 システム概要図の表記ルール及び作成例
表記ルール
1

主体（人やシステム）を表す図形を決定する。

2

調達対象となる情報システムを図の中央付近に記載する。

3

業務（情報のやりとり）が発生する主体の間を矢印で結ぶ。

4矢印の向きと情報の流れができるだけ一致するように業務及び情報の名称（又は略称）を記載する。

5

利用環境・手段のうち、機器は機器を用いる主体の付近に記載し、ネットワークは情報のやりとりを表す矢印の付近（背景部分）に記載する。

6

サーバや端末等の機器が情報を蓄積する場合、その付近にその情報の名称を記載する。

7

すべての情報を書き込み切れない場合は、各ステップの検討結果を別表に整理して採番し、図に番号等を記載する。

8

異なる主体であっても情報や利用環境・手段等に共通点がある場合には、一括して記載するなどして、図が難解にならないように工夫する。

システム概要図

ルール１

ルール３

ルール４

ルール２
内部ネットワーク

国民【環境】
PC、携帯電話、
スマートフォン等【利用登録】
・「個人情報」【投稿・投票】
・「意見」「コメント」

国民参加型
政策立案
システム

【利用者の管理】・「個人情報」

事務局【環境】 PC

システム
運用者

【閲覧】
・「意見」「コメント」

・「意見」「コメント」
・「個人情報」
・「履歴」
インターネット

ルール５【回答・修正】・「回答」【周知】
・「お知らせ文面」

ルール６

18

【利用状況の把握】
・「利用統計」【監視・追跡】
・「履歴」【バックアップ】
・「システムデータ」【環境】 PC
管理用 LAN表 9 システム概要図作成のための「チェックリスト」
項番

チェック内容1

情報システム化の対象とする業務が記載されているか

2

各業務の主体（国民、行政事務を担当する者、システム管理者等）が記載されているか

3

各業務にて取り扱う情報が記載されているか

4

各業務において情報の取扱い及び交換に用いる環境が記載されているか

5

主体、情報システム、関連する他の情報システムの関係を把握できるか19

4.4 定型設問による業務要件の詳細化（ステップ 4）
調達担当者は、セキュリティ要件の導出に必要なレベルにまで業務要件を詳細化するため、完成したシステム概要図を踏まえつつ、表 10 の設問の回答を検討する。設問は、「主体」「情報」「利用環境・手段」の 3 つの観点ごとに設けられている。各設問の回答例を参考にして、ここまでの作業によって洗い出した「主体」の業務ごとに回答を検討する。
なお、主体や業務のバリエーションが多い場合、すべての設問の回答を検討することが難しい可能性がある。そのような場合には、すべての設問に回答することなく 5 章の作業に進み、5 章にて業務要件に不足があると思われた場合に 4 章に再度戻って業務要件を検討する方法でも良い。
また、本マニュアルの設問や回答例にとらわれることなく、本マニュアルの利用組織にて自由に追加、変更などして構わない。

表 10 業務要件詳細化のための「定型設問」
ID

観点

設問

回答例

A-1

主体

【数量】 おおよその人数規模は？

「1 万人未満」A-2【主体分類】 主体の分類は？

「国民」「事務局」「システム管理者」

A-3【集合特性】 特定か不特定か？

「特定（匿名性なし）」「特定（匿名性あり）」「不特定（匿名性なし）」「不特定（匿名性あ
り）」

A-4

【所属】 システム所管との関係は？

「府省庁外」「システム所管の部局に所属している」「システム所管の部局に所属しない
府省庁内」

A-5

【頻度】 １人あたりのアクセス頻度は？

「１日に１回程度」「週に１回程度」「月に１
回程度」

A-6

【利用時間】 １日の主な利用時間帯は？

「日中」「日中及び夜間（0 時以降除く）」「24 時間」

A-7【信頼性】 役割どおりに振る舞えるか？

「誤操作が発生しやすい（マニュアル等を読まない）」「誤操作はあまり発生しない（役
割どおりに振る舞えることが多い）」「運用規定に従って確実な操作を行える（ほぼ確実に役割どおりに振る舞える）」

B-1

情報

【数量】 おおよそのデータ量は？

「1,000 文字以内」

B-2【所有者】 情報の所有者は誰か？

「利用者」「サービス提供者」

B-3【範囲】 公開・提供可能な範囲は？

「制限なし」「制限あり」

20

ID

観点

B-4

設問

回答例

【漏えい】 漏えい時の影響度は？

「利用者に金銭被害が発生」「利用者に回復不可能な被害が発生」「サービス提供者に回復不可能な被害が発生」「特になし」

B-5【改変】 不正改変時の影響度は？

「利用者に金銭被害が発生」「利用者に回復不可能な被害が発生」「サービス提供者に回復不可能な被害が発生」「特になし」

B-6【取扱】 閲覧のみか？変更が発生する「閲覧のみ」「変更あり」

か？
B-7【保存】 システム内に保存するか？

「サーバ内に保存（保存期限なし）」「サーバ内に保存（保存期限あり）」「保存しない」

B-8【検証】 完全性の事後検証は必要か？

「必要」「不要」

C-1

利用環【伝達手段】 情報を送受信する方法は？

「Web ブラウザ」「専用ソフトウェア」「媒体」

C-2

境・手段

【処理環境】 サーバ又は端末の種類「サーバ」「クライアント PC」「携帯電話」

は？
C-3【通信環境】 利用するネットワークは？

「内部ネットワーク」「専用回線」「インターネ
ット」

C-4

【通信環境】 外部からの遠隔利用は必要「必要」「不要」

か？
C-5【信頼性】 異常停止の許容時間は？

「数時間」「半日程度」「１日程度」「数日程度」「１週間程度」「特になし」

21

5章 セキュリティ要件の策定
この章では、4 章にて検討した業務要件を材料として、調達担当者が情報システムに必要なセキュリテ
ィ対策を検討し、調達仕様書に記載するべきセキュリティ要件を策定する。
本マニュアルでは、情報システムにおいて考えられる基本的なセキュリティ対策のための要件を、表11 に示す構成の「対策要件集」にまとめている。
この対策要件集は、セキュリティ対策を、その目的に応じて図 4 のように８種類の大区分（以下「対策区分」という。）に整理し、対策区分の中には、対策の方向性を表す中区分（以下「対策方針」という。）を設けている。さらに、各対策方針には、合致するいくつかの具体的な対策方法の要件の小区分（以下「対策要件」という。）を定め、対策要件ごとにその実施レベル（3 段階）に対応する調達仕様書の記載例を掲載している。
調達担当者は、この対策要件集から、調達仕様書に記載する対策要件を選定する。本マニュアルでは、
この作業をできる限り定型的に行えるようにするため、優先的に実施することが望ましい対策要件を判断するための条件（これを「判断条件」と呼ぶ）を定めている。
次節以降では、このような対策要件集及び判断条件を利用して、調達仕様書にセキュリティ要件を記載する方法を解説する。

【不正アクセス】
侵害対策 （AT）
不正監視・追跡 （AU）
アクセス・利用制限 （AC）

【運用者】

【利用者】
利用者保護 (UP)

データ保護 （PR）
障害対策（事業継続対応） （DA）
物理対策 （PH）

サプライチェーン・リスク対策（SC）

図 4 対策要件集における対策区分22

表 11 対策要件集の構成
対策区分

対策方針

対策要件

判断条件
対応関係
（※）

侵害対策
（AT： Attack）

通信回線対策（AT-1）

実施レベル有無低位

有A or F有

不正通信の遮断 （AT-1-2）

A

有

サービス不能化の防止 （AT-1-4）

不正監視・追跡（AU: Audit）

高位

通信経路の分離 （AT-1-1）
通信のなりすまし防止 （AT-1-3）

不正プログラム対策（AT-2）

中位

不正プログラムの感染防止（AT-2-1）-

不正プログラム対策の管理（AT-2-2）

A or B

有

有

有

有

有
有

セキュリティホール対策（AT-3）

構築時の脆弱性対策 （AT-3-1）-

有運用時の脆弱性対策 （AT-3-2）

A

有

有

ログ管理（AU-1）

ログの蓄積・管理 （AU-1-1）

B or C

有

有

有

有

有

時刻の正確性確保 （AU-1-3）-

有侵入検知 （AU-2-1）

A

有

有

ログの保護 （AU-1-2）
不正監視（AU-2）

サービス不能化の検知 （AU-2-2）
アクセス・利用制限（AC: Access）

データ保護（PR: Protect）

有

主体認証（AC-1）

主体認証 （AC-1-1）

D

有アカウント管理（AC-2）

ライフサイクル管理 （AC-2-1）

D

有

アクセス権管理 （AC-2-2）

E

管理者権限の保護（AC-2-3）-

機密性・完全性の確保（PR-1）

通信経路上の盗聴防止 （PR-1-1）

有有有B or C

保存情報の機密性確保 （PR-1-2）

有保存情報の完全性確保 （PR-1-3）
情報窃取・侵入対策（PH-1）

侵入の物理的対策 （PH-1-2）

障害対策（事業継続
対応）（DA: Damage）

構成管理（DA-1）

システムの構成管理 （DA-1-1）

B

有可用性確保（DA-2）

システムの可用性確保 （DA-2-1）-

有サプライチェーン・リス
ク対策（SC: Supply Chain）

情報システムの構築等の外部委託における対策（SC-1）

委託先において不正プログラム等が組み込まれることへの対策（SC-1-1）-

有機器等の調達における対策（SC-2）

調達する機器等に不正プログラム等が組み込まれることへの対策（SC-2-1）-

有情報セキュリティ水準低下の防止（UP-1）

情報セキュリティ水準低下の防止（UP-1-1）

A

有プライバシー保護（UP-2）

プライバシー保護（UP-2-1）

A

有

-

有
有
有

※ 各対策要件の判断条件対応関係に記載の判断条件が満たされる場合、当該対策要件については「中位」又は「高位」の実施レ
ベルに対応する仕様書記載例の採用を検討し、判断条件対応関係が「－」の対策要件については判断条件の結果によらず「低位」の実施レベルに対応する仕様書記載例の採用を検討することを表す。（5.1 節参照）

23

有
有

物理対策
（PH: Physical）

利用者保護（UP: User Protect）

情報の物理的保護 （PH-1-1）

有5.1 判断条件による対策方針の検討（ステップ 5）
調達担当者は、表 11 の各対策要件について、それぞれ優先的に実施すべき対策であるか否かを検討する。具体的には、4 章にて検討した業務要件を踏まえ、表 11 の各対策要件の「判断条件対応関係」の欄に記載のアルファベットに該当する判断条件（表 12）が満たされるか否かを検討する。
確認の結果、該当する判断条件が満たされていない場合又は「判断条件対応関係」の欄が空欄である場合は、その対策要件については、「低位」の実施レベルに該当する仕様書記載例の採用を次節以降で検討する。
一方、該当する判断条件が満たされる場合は、その対策方針について「中位」又は「高位」の実施レベ
ルの仕様書記載例の採用を次節以降で検討する。
以下は、上記の考え方に基づく判断条件による検討の例である。
 AT-1-1 の場合
表 11 において、AT-1-1 の「判断条件対応関係」の欄には「A or F」と記載されている。例えば、「A」
又は「F」の判断条件が満たされる場合、「中位」又は「高位」の実施レベルに該当する仕様書記載例の採用を検討すること。
一方、指定の判断条件が満たされない場合には、「低位」の仕様書記載例を採用することになるが、AT-1-1 は「低位」の仕様書記載例が定められていないため省略となる。
 AT-2-1 の場合「判断条件対応関係」の欄は空欄（「-」）である。このような対策要件については、判断条件の結果によらず、「低位」の仕様書記載例を採用すること。

各判断条件が満たされるか否かを検討
分類
A. 外部アク
セスの有無

観点分類
利用環境・
手段

判断条件
インターネット等の通信回線を介して外部から情報シ
ステムにアクセスしてサービスの利用、業務の遂行、
情報システムの管理等を行うか。

：

：

：

解説
情報システムが所管組織の外部からアクセスを受ける可能性を検討する。・・・。
：

判断条件 A が満たされる場合

各対策要件の「判断条件対応関係」の指定に基づき実施レベルを検討
対策区分
侵害対策
（AT: Attack）

対策方針
通信回線対策（AT-1）

対策要件

判断条件
対応関係

実施レベル有無
中位

高位

通信経路の分離 （AT-1-1）

A or F有有

不正通信の遮断 （AT-1-2）

A

有【AT-1-1 の場合】 判断条件 A が指定されているため「中位以上」通信のなりすまし防止 （AT-1-3）

低位

有
有

サービス不能化の防止 （AT-1-4）
不正プログラム対策（AT-2）

不正プログラムの感染防止 （AT-2-1）－

不正プログラム対策の管理 （AT-2-2）

A or B【AT-2-1： の場合】 判断条件の指定がないため「低位」：：

図 5 判断条件による検討の例

24

：

有
有

有
有
：

：

：

表 12 対策方針決定のための「判断条件」
名称

観点分類

判断条件

解説

A. 外 部 ア ク セ ス
の有無

利用環境・
手段

インターネット等の通信回線を介して（情報の管理ポリシーが異なる）
外部から情報システムにアクセスしてサービスの利用、業務の遂行、
情報システムの管理等を行うか。

情報システムを所管する組織の外部（情報管理ポリシーが異なる外部）からアクセスを受ける可能性を検討する。判断にあたっては、ステップ 2の利用環境・手段の検討結果、定型設問 C-3、C-4 等を参考にすると良い。

B. 情報の重要度情報漏えいした場合、正常にアクセスで
きな い 場合 或 いは消 失し た場 合に、深刻な損害を被る可能性がある重要性の高い情報を取り扱うか。

漏えい、改ざん、消失等によって発生するプライ
バシー侵害や金銭的被害等の損害の度合いを見極め、情報の重要性を検討する。判断にあたっては、例えば、定型設問 B-3 の情報の取り扱
い範囲、B-4、B-5 の損害度合の回答を参考にすると良い。

C. 情報保存時の安全性

情報

入退室管理等の物理対策だけでなく、情報システムが保存する情報についてより一層の安全を期すた
めに追加的対策をさらに行うべきと考えるか。

情報の重要性が非常に高く物理対策が突破されることも想定する必要がある場合、あるいはモ
バイル PC による情報処理が必要な場合などは追加的対策が重要になる。判断にあたっては、
定型設問 B-7 にてシステム内に保存することを確認している場合かつ定型設問 B-4、B-5 の想
定被害の程度を考慮すると良い。

D. 利用者の限定
要否

主体

情報システムにアクセスする主体
は、利用資格のある者、職員、グループのメンバー等の特定の者に限定されるか。

情報システムのサービスや業務機能を、特定の利用者や運用者のみに提供するか否かを検討する。判断にあたっては、定型設問 A-3 にて確認された主体の集合特性を参考にすると良い。

E. アカウントの多様性

主体

利用者によって利用可能なサービスや業務が異なる等、利用者の特徴にバリエーションがあるか。

利用者や運用者に応じてアクセス権を管理し、アクセス権に応じてサービスや業務機能の提供
内容を制御する必要があるか否かを検討する。
例えば、ステップ 2 にて情報システムの利用者として多様な主体が洗い出され、主体の種類ごとに提供する機能やサービスを切り替える等の制御が必要である場合には本判断条件に合致する可能性がある。

F. 複数部局による利用

主体

情報の取り扱い方や利用目的等が異なる複数の部局等の間で共用されるか。

情報システムを広く共用するが、情報システム
内の情報管理体制の異なる部局ごとに分け、互いにアクセスできない状態を保つ必要性があるか否かを検討する。例えば、ステップ 2 にて情報システムを利用する主体として多様な主体が洗い出され、各主体の所属が情報管理ポリシーの異なる部局である場合に本判断条件に合致する可能性がある。

25

5.2 対策要件の決定（ステップ 6）
調達担当者は、調達仕様書に記載する対策要件を決定する。前節の検討結果に応じて、対策要件ごとに以下のように検討する。
「低位」の実施レベルの仕様書記載例の採用を検討する場合
低位の実施レベルに該当する仕様書記載例の内容や一般的な実現例を参考にして、調達コスト等を勘案し、調達仕様書の記載内容を検討する。低位の仕様書記載例が示されていない対策要件の場合は、調達仕様書に記載すべき対策要件はないとみなす。

「中位」又は「高位」の実施レベルの仕様書記載例の採用を検討する場合「付録Ａ．対策要件集」に記載されている「実施レベルの選定の考え方」を参考にして、「中位」と「高位」のどちらの仕様書記載例を採用するべきかを検討する。また、費用対効果の観点からは、
可能な限り「中位」の実施レベルの仕様書記載例を採用することが望ましい。
なお、検討の結果、「高位」の仕様書記載例を採用する必要はないと判断された対策要件のうち「中位」の仕様書記載例が示されていない対策要件については、記載を省略する。

26

5.3 調達仕様書への反映（ステップ 7）
調達担当者は、仕様記載例を決定した後は、対策要件集の「仕様書記載時の注意事項」の解説及び以下の点に留意して、調達仕様書の該当部分に記載する。
(1) 記載内容のさらなる具体化

本マニュアルの判断条件等によって導出された対策要件の一部については、対策要件集の仕様書記載例のままではなく、調達するシステムのより詳細な特性に応じて記載内容を慎重に検討し、具体化する必要がある。
(2) 対策要件の記載箇所

本マニュアルによる検討結果を調達仕様書に記載する際の記載箇所を表 13 に例示したが、記載箇所に迷う場合は、少なくとも表 13 の「ウ 情報システムに求める要件」の「非機能要件」の「(10) 情報セキュリティ」の項目に記載すると良い。
(3) 既存設備の利用を想定した仕様の調整

既存の情報システムとネットワーク設備を共用する等のように既存の設備を用いる場合で、既存の設備によって満たされている対策要件が存在する場合には、当該対策要件を調達仕様にそのまま記載するのではなく、既存の設備を共用すること及び既存の設備によって当該対策要件に対応することを調達にあたっての前提条件として調達仕様書に記載する。
(4) 記載内容の妥当性の点検

仕様書記載時の注意事項が指定されていない対策要件については、仕様書記載例の例文を修正することなく記載することが可能である。ただし、調達する情報システムの特性を考慮して、記載内容の妥当性を点検することが望ましい。この点検作業にあたっては、各対策要件の解説に記載されている「想定脅威」「対策の効果」「対策の提案例」等の情報を参考にすると良い。
また、最高情報セキュリティアドバイザー及びデジタル統括アドバイザー等に記載内容の妥当性の確認を求め、必要な助言を受けた上で記載内容を改善するなどにより、その妥当性の担保を行
うこと。

27

表 13 本マニュアルの検討結果の記載箇所の例 （標準ガイドラインの記載例の場合）
大項目

小項目

ア

(1) 調達の背景

調達案件の概要

記載内容（※ ステップ 1 の検討結果のうち「目的」を反映）(2) 目的(3) 期待する効果(4) 業務・情報システムの概要（※ ステップ 2 及びステップ 4 の結果を反映）

(5) 契約期間(6)作業スケジュール等
イ

調達案件及び関連調達案
件の調達単位、調達の方
式等(1) 調達案件及びこれと関連する調達案
件の調達単位(2) 調達の方式(3) 実施時期等

ウ

情報システ
ムに求める
要件

業務要件

(1) 業務実施手順(2) 規模(3) 時期・時間(4) 場所等(5) 管理すべき指標(6) 情報システム化の範囲(7) 業務の継続の方針等(8) 情報セキュリティ

機能要件(1) 機能(2) 画面(3) 帳票(4) データ(5) 外部インタフェース

非機能要件(1) ユーザビリティ及びアクセシビリティ(2) システム方式(3) 規模(4) 性能（※ 対策要件 DA-2-1 を求める場合に記入）(5) 信頼性(6) 拡張性

28

大項目

小項目

記載内容

(7) 上位互換性(8) 中立性(9) 継続性(10) 情報セキュリティ（※ 対策要件 AT-1、AT-2、AU-1、
AU-2、AC-1、AC-2、PR-1、DA-11、SC-1-2、UP-1 を求める場合に記入）(11) 情報システム稼働環境（※ ステップ 3 にて作成したシステム
概要図を記載）(12) テスト（※ 対策要件 AT-3-1 を求める場合に記入）(13) 移行(14) 引継ぎ(15) 教育エ

作業の実施内容(16) 運用（※ 対策要件 PH-1 を求める場合に記入）(17) 保守（※ 対策要件 AT-3-2 を求める場合に記入）(1) 作業の内容(2) 成果物の範囲(3) 納品期日等

オ

作業の実施体制・方法（※ 対策要件 SC-1-1 を求める場合に記入）(1) 作業実施体制(2) 作業要員に求める資格要件(3) 作業場所(4) 作業の管理に関する要領等
カ

作業の実施

(1) 機密保持(2) 資料の取扱い(3) 遵守する法令等

キ

成果物の取扱い(1) 知的財産権の帰属(2) 契約不適合責任(3) 検収等

ク

入札参加資格(1) 入札参加要件(2) 入札制限ケ再委託(1) 再委託の制限

29

大項目

小項目

記載内容

(2) 再委託を認める場合の条件、承認手
続、監査及び再委託先の契約違反等に関する責任についての定め等
コその他特記事項（前提条件、制約条件、要件定義、調達仕様書の変更手順等）

サ

附属文書

(1) 要件定義書(2) 参考資料(3) 事業者が閲覧できる資料一覧表(4) 閲覧要領(5) 提案書等の審査要領(6) その他事業者の提案に必要な資料

30

6章 その他の考慮事項（1） 対策要件集及び統一基準との関係について
調達担当者は、対策要件集を参考にして調達仕様書を作成することによって、「付録Ｂ．統一基準
対応表」に示すとおりに統一基準の各遵守事項と対応関係を持つ調達仕様書を作成することができる。
付録Ｂを参考にして調達仕様書を確認した結果、調達担当者が内容に過不足があると判断した場
合には、統一基準の遵守事項等を踏まえ調達仕様書の記載内容を見直すこと。
（2） 開発の環境及び作業実施上のセキュリティ確保について
統一基準の遵守事項 5.2.2(2)(a)には、情報システムの構築に関して「情報システムセキュリティ責任者は、情報システムの構築において、情報セキュリティの観点から必要な措置を講ずること。」と規定されている。
当該遵守事項を踏まえ、表 1 に示した調達仕様書の項目のうち「オ 作業の実施体制・方法」等に必要事項を記載すること。
（3） 政府ドメインの利用について
統一基準の遵守事項 6.3.2(1)(a)及び(b)では、政府機関等の情報システムが使用するドメイン名に関して規定している。当該遵守事項の内容を考慮し、ドメイン名の取得や利用が調達範囲に含まれる
場合には、調達仕様書に必要事項を記載すること。
（4） 暗号アルゴリズムについて
統一基準の遵守事項 6.1.5(1)(b)(ア)では、暗号化及び電子署名に用いる暗号アルゴリズムについて、「「電子政府推奨暗号リスト」に記載された暗号化及び電子署名のアルゴリズムが使用可能な場
合には、それを使用させること。」と規定されている。
調達仕様書において暗号化及び電子署名を用いる対策を求める場合には、この遵守事項及び情報システムの運用期間中の危殆化の可能性が高い暗号アルゴリズムを利用しないことを求める内容も合わせて記載すること。
（5） サプライチェーン・リスクについて
国の行政機関における情報システムに係る調達に当たっては、「IT 調達に係る国等の物品等又は役務の調達方針及び調達手続に関する申合せ」（平成 30 年 12 月 10 日関係省庁申合せ、令和３年９月１日一部改正）に基づき、必要な措置を講ずること。

31