具体方針

クラウドサービスの選択

クラウドサービスの利用についてはガバメントクラウドを原則とするが、ガバメントクラウドを利用しない場合については、セキュリティの観点より、ISMAPクラウドサービスリスト又はISMAP-LIUクラウドサービスリスト（以下、「ISMAP等クラウドサービスリスト」という。）に登録されたものを原則として選定する。なお、ISMAP関連の詳細については、「政府情報システムのためのセキュリティ評価制度（ISMAP）の利用について」（令和２年６月30日サイバーセキュリティ対策推進会議・各府省情報化統括責任者（CIO）連絡会議決定）に従うこと。

また、サプライチェーン・リスクについて注意を要する場合は、「IT調達に係る国等の物品又は役務の調達方針及び調達手続きに関する申合せ」（平成30年12月10日関係省庁申合せ）に従い事前確認を行うこと。オープンソース等、外部で開発されたソフトウェアを用いるクラウドサービスを利用する場合には、内部にバックドア等の潜在的リスクがないことが事前に確認されていることが望ましい。

SaaSについては、開発量削減の観点から幅広く優先的に、その利用を検討すること。SaaS利用のみで全ての要件が満たせる場合だけでなく、開発する場合においても特定機能をSaaSに依存する形態が想定される。ただし、ニーズにマッチしているか、開発量削減に貢献するか、セキュリティ対策は十分か、費用対効果は十分に得られるか等を慎重に考慮すること。特に、アカウント数に対して課金されるSaaSや高額なSaaSにおいては、利用アカウント数の増大で運用等経費が増大するため、利用アカウントの推移を想定する際、十分注意すること。

その際、ISMAP等クラウドサービスリストに未登録である場合は、「政府情報システムのためのセキュリティ評価制度（ISMAP）の暫定措置の見直しについて」（令和３年７月６日サイバーセキュリティ対策推進会議・各府省情報化統括責任者（CIO）連絡会議決定）に基づき、当該調達を行う政府機関等における最高情報セキュリティ責任者の責任において、本制度の要求事項や管理基準を満たしていることをそれぞれの政府機関等で確認を行い、加えて、「４．１ ISMAP以外のクラウドセキュリティ認証等」で示される認証を取得しているものについても検討すること。

クラウド利用者のデータが所在する地域と適用される法令等について

クラウドの利用にあたっては、国内法以外の法令及び規制が適用されるリスクを評価し、情報が取扱われる場所及び契約に定める場所と準拠法・国際裁判管轄に留意する必要がある。このため、こうしたリスクを低減する観点から、利用するサービスや、データセンタの設置場所等を選択する必要がある。

政府情報システムが利用する場合、クラウドのデータセンタの設置場所に関しては、国内であることを基本とする。

ただし、システムの可用性、データの保存性、災害対策等から、冗長化やバックアップ用のデータセンタを海外に設置することが望ましい場合もある。その際は、準拠法や国際裁判管轄を確認し、具体的な争訟リスクが低いことを確認する必要がある。加えて、契約等において利用者データの保護が適切に担保されるようにする。

なお、利用者データ（利用者が作成・管理するデータ）を国外に設置されるクラウドに保管する場合、もしくは保管される可能性がある場合は以下の対策を行うこと。

・利用者データの保護

公開情報ではなく、漏えいした場合のリスクが明らかな利用者データを保管する場合は、最新の「CRYPTREC暗号リスト（電子政府推奨暗号）」に掲載されている暗号又は同等の暗号を用いて利用者データの暗号化を行うこと。また、利用者データの機密性によっては、利用者自身の暗号鍵によるデータの保護と鍵管理（クラウドの鍵管理サービス提供の利用者が主体的に管理する鍵の利用やBYOK等）を行い、クラウド（CSP）や監督権限を持った政府等が利用者データを判読不能とする措置を行うこと。

・利用者データ可用性の確保

利用者データに可用性が要求され、外国の法令に基づいてデータの域内保存義務が課されること等により可用性におけるリスクが予見される場合には、当該法令の効力の及ばない場所（国）にバックアップ等を保持すること等により当該リスクを回避又は低減すること。

ベンダーロックインについて

データの移行性が担保され、合理的な価格体系が公開された上で、その導入プロセスも含めて透明性が担保されている等の条件を満たすクラウドサービスを選択することにより、CSPによるベンダーロックインを回避すること。

マルチクラウド等について

一つの情報システムを複数のクラウドサービス（IaaS/PaaS）上で構成する「マルチクラウド」は、構成を複雑にして費用が増大する傾向にあることから避けるべきである。他方、組織として個々の情報システムが各々に異なるクラウドサービス（IaaS/PaaS）を利用することで、複数のクラウドサービス（IaaS/PaaS）を併用することは問題ない。

前述のように、個々の政府情報システムが主たる環境として利用するIaaS/PaaSのCSPを複数とするマルチクラウドは避けるべきだが、SaaS等を中心に特定機能に特化して他のクラウドを併用することは問題ない。

CSPによるベンダーロックインを懸念して、複数のIaaS/PaaSのCSPを積極的に使用する考え方もあるが、「３．３　ベンダーロックインについて」のようにデータの移行性が担保され、合理的な価格体系が公開された上で、その導入プロセスも含めて透明性が担保されていればベンダーロックインには該当しない。

いずれにせよ、技術的な合理性と経済的な合理性を持たないマルチクラウドは厳に避ける必要がある。

クラウドとオンプレミスを組み合わせてデータを処理・保存する利用形態については、オンプレミスからクラウドへの移行期、データの多重バックアップ、ネットワーク遅延が許容できない場合を除いては、システムの複雑化と高コスト化の要因となるため、その適用を避けること。

アプリケーションとシステム刷新について

クラウドへの移行時における刷新の考え方を以下に示す。新規システムの場合については、ここで記述されている刷新後のシステムを当初から開発する前提で読み替えられたい。また、全体的な事項についてはデジタル・ガバメント推進標準ガイドラインに準拠し、クラウドに関する部分については、本指針を優先されたい。

見積りの取得時の留意点

従来型の業務システムを、多種多様なマネージドサービスを利用し、自らサーバーを構築しない業務システムとするには、アプリケーションのモダン化、刷新が必要となる。

この際、刷新時のアプリケーション開発コスト（整備経費）の増加分と刷新後のランニングコスト（運用経費）の減少分を総合的に評価する必要があるが、その費用見積りについては、モダン技術に明るい事業者（担当者）に依頼することが不可欠となる。仮に見積り可能な事業者が現行事業者しか存在せず、現行事業者がモダン技術に明るくない場合には、現行事業者が体制強化、自己学習、トレーニング受講、資格取得等を実施する時間を想定しておく必要がある。

モダン技術に明るくない事業者による見積りは、従来方式を墨守するためのものが多く、正しい意思決定を阻害するため、技術的な妥当性に加え、比較対象が適切か否か、特定の意図を持った恣意的な見積りとなっていないか等、特に留意が必要となる。

納品物についても、必要性の低いドキュメントを納品物と定義して、利用されない大量ドキュメントに工数（費用）と作業期間を割くのではなく、クラウドの場合は、まず、実機環境で開発構築してみて、試行錯誤や評価の後に、確定した内容のみを真に必要なドキュメントとして納品物とすることが重要である。

クラウド移行に向けた刷新

これまでの情報システムにおいては、調達や構築・刷新において、アプリケーションとインフラを分離して考えることが一般的であった。しかし、特にオンプレミスで一般的であったアプリケーションとインフラを分離した調達は、アプリケーションのモダン化とスマートなクラウド利用を阻害する要因となるため、クラウドでは見直しが必要となる。なお、本節でのインフラはクラウド環境（オンプレミスではサーバー環境）を指しており、ネットワークや端末等を指すものではない。事業者や調達についてはSIerによる開発等の役務のみを指しており、物品やその付帯作業等を指すものではない。

システムの刷新においても、オンプレミスでは、ハードウェアの老朽化により、アプリケーションの改修を最小限にとどめてインフラのみを刷新（サーバー更改）する方式が多かったが、これはクラウドへの移行では好ましくない。アプリケーションの改修を前提としない刷新では、マネージドサービスの利用も自らサーバーを構築しない構成も非常に困難になってしまう。

クラウド移行に向けた刷新においては、インフラとアプリケーションを同時に刷新することが合理的である。また、事業者や調達についてもインフラとアプリケーションを原則として分離するべきではない。なお、ここでのアプリケーション刷新は、後述の「5）クラウド上で稼働するアプリケーションについて」への対応であり、BPRやビジネスロジックの刷新を要求しているものではないが、BPRやビジネスロジックの刷新についても、システム本来の在り方から、可能な限り同時に実施されたい。

インフラとアプリケーションの同時刷新が困難と考えられる場合は、スケジュールの見直しを行い、刷新時のアプリケーション開発コスト（整備経費）の増加分と刷新後のランニングコスト（運用経費）の減少分を総合的に評価する必要があるが、事業者から取得した見積りが適切なものか否かを事業者の姿勢や能力から再確認し、必要であれば「1）見積り取得時の留意点」の対応を実施すること。

アプリケーションの刷新に時間を要し、同時刷新がスケジュール的に困難な場合は、刷新スケジュールの見直しが必要となる。

事業者の対応能力で同時刷新が困難な場合は、事業者の体制、自己学習、トレーニング受講、資格取得等の状況を確認したうえで、より一層の競争環境醸成を行う必要がある。

システム規模が大きいために競争環境の十分な醸成が困難な場合には、マイクロサービスアーキテクチャを採用し、疎に連携するサービスを基本として調達単位を分割することも有効である。

上記の対応を行った上で、それでも同時刷新が困難で、アプリケーションの改修を最小限にとどめてインフラのみをクラウド化する刷新を選択しなければいけない場合については、これを第一段階と考え、第二段階でアプリケーションも含めた刷新を行うことを当初から計画しておくものとする。

また、第一段階においても、コスト削減の観点から、データベースと運用管理系の機能については、マネージドサービスの利用を優先的に検討するものとする。やむを得ず、サーバー構築のためのインスタンス（仮想サーバー）を利用する際には、その稼働を必要最小限とし、サーバーが実稼働していないときの利用料発生を抑制すること。インスタンスの容量・能力については、事前評価に加え運用開始後においても、実際の運用状況から継続的に評価と見直しを行うこと。インスタンスの長期使用契約を選択する場合は、前述を踏まえた上で、慎重な検討を行うこと。

小規模なシステムにおける刷新

小規模なシステムにおいては、単独での刷新（クラウド移行）よりも他システムへの統合や廃止を検討するべきである。近々に統廃合される予定のシステムについては、刷新せずに現行システムを統廃合まで維持した方が合理的である可能性が高い。

単独での継続が必要なシステムについては、SaaSの採用を優先されたい。

組織ごとに独立していたシステムの刷新

同じ根拠法によるにもかかわらず、オンプレミスでは府省や地方公共団体など組織ごとに独立したシステムとして運用されていたシステムについては、クラウド利用により物理的な統合が容易になることから、システム更改などの機会に効率化の手段として１システムへの統合を検討するべきである。長年の個別運用によって組織ごとに相違が生じている可能性が高いが、データ構造、アプリケーション、運用についても積極的に統合・一元化を図り、システムの統合を積極的に検討する必要がある。

クラウド上で稼働するアプリケーションについて

オンプレミスにおけるアプリケーションとクラウド上のアプリケーションでは、以下の点で大きく異なるため、新規開発時やアプリケーション刷新時には特に留意されたい。

・モダンアプリケーションとする（モダン化）

自らはサーバーを構築せずマネージドサービスの組合せだけでシステムを構成する、IaCを使う、インターネット接続（閉域網依存からの脱却）、フロントエンド・バックエンド分離型のWebシステム（クライアントサーバー方式やWeb3層モデルからの脱却）、APIで連携する、自動化の徹底（テスト、変更、デプロイ、運用管理）、動的なリソース管理（その時点で必要な分のみ）など、クラウドならではの考え方とする。マイクロサービスアーキテクチャの採用や継続的な改善（開発）もモダンアプリケーションでは一般的である。

既存のアプリケーションを改修してモダン化するには大規模な改修が必要となる場合が多く、改修によるイニシャルコストを削減されるランニングコストで回収するには、一定の投資回収期間を要するが、回収後にはランニングコストの削減効果が顕在化する。特に新規開発や適切に実施される刷新時であれば、イニシャルコストとランニングコストの双方が削減される。

・オンプレミス環境の旧来技術・運用を単純に踏襲しない

クラウド環境では、オンプレミス環境で一般的であった技術や運用方法をそのまま踏襲すると、コスト増加やセキュリティリスクなどの問題が発生する可能性がある。旧来の技術や運用方法は、クラウド環境では適さない場合が多いため、クラウドの特徴を活かした新しい技術や運用方法のベストプラクティスに沿って見直し、システムを設計・開発する必要がある。例えば、クライアントサーバー方式などは、今日のクラウドへの移行を想定するべきではない。処理やデータをサーバー側に集中させ、クライアント側を軽量化するなど、クラウドの特徴を活かしたアーキテクチャを採用することが重要である。特に、セキュリティの要求水準が高いシステムでは、最新の技術や運用方法を採用することが重要である。旧来の技術や運用方法を継続して使用する場合には、それが将来的にシステム改修や運用を困難にする「技術的負債」となる可能性があることに留意する必要がある。

見直すべき技術・運用の例:

クライアントサーバー方式、シンクライアント専用端末（VDI等）、踏み台サーバー、境界型セキュリティのみに依存したセキュリティ対策、非効率な監視ツール、定期保守のための予定断、不必要な夜間バッチ、SaaSやマネージドサービスで代替できるミドルウェア等

・人海戦術的な人手に頼った方式を踏襲せず自動化する

オンプレミス環境で一般的であった、人手に頼った作業方法は、クラウド環境では自動化する。インフラ環境の構築 (IaC)、CI/CD パイプライン、インフラのテスト、システム監視、運用、セキュリティ監視などを、クラウドの機能を活用して自動化する。

・システムの価値に直結する定量的計測を行う

従来のシステム監視では、サーバーやネットワークなどのインフラが停止しないことや、処理能力を超過させないことを主な目的として、インフラリソースの監視やログの監視が行われてきた。しかし、クラウド環境では、インフラの障害発生時に自動的に復旧する機能や、必要な処理能力を柔軟に調整できる機能が提供されているため、インフラを監視することの必要性は低くなる。クラウドサービスでは、システムの様々な状態を監視できる機能が標準で提供されており、これらの機能を組み合わせることで、従来のシステム監視よりも高度な監視を実現することができる。具体的には、システムが提供する業務レベルでの価値を明確に定義し、その価値を実現するために必要なシステムの状態を指標として設定する。そして、業務レベルでのサービス改善につながる運用につなげていく。

・セキュリティ対策もクラウドに最適化させる

オンプレミスとクラウドでは、セキュリティ対策も大きく異なるため、クラウドに最適化したセキュリティ対策とする必要がある。詳細は「３．６　セキュリティについて」を参照のこと。

・開発プロセスはクラウド環境に合わせて最適化する

従来のオンプレミス環境では、インフラ環境をすぐに利用することができなかったり、一時的に利用する場合でもコストがかかったりするため、アプリケーションの開発プロセスについても、これらの制約に依存したものとなっていた。

クラウド環境では、インフラ環境を低コストで利用できるため、机上で検討を重ねるよりも、実際にシステムを構築して検証を行う方が効率的な場合が多くある。設計についても、あらかじめ詳細な文書を作成するよりも、実際に動作するシステムを作成して検証を行う「プロトタイピング」を優先し、詳細設計の文書化は後回しにする方が効率的な場合が少なくない。また、クラウドの機能で自動生成可能なドキュメントは積極的に自動生成を行うべきである。

・稼働日で完成ではなく日々の運用で改善していく

従前はシステムを本番稼働させたタイミングで開発が一旦、終了し、その後は運用フェーズと位置付けてシステムを稼働させるだけだったが、クラウド環境では後からのリソース追加やサービス追加などに柔軟な対応が可能なため、本番稼働した後もサービス改善を続け、より利用者に便利なサービスとなるように改善していくべきである。そのため、アプリケーション開発は本番稼働後の運用フェーズも含めて日々改善していくことを前提に予算、体制、スケジュール等を計画しておく必要がある。

マネージドサービス等、クラウドから提供されるサービスのアップデートへの対応についても、義務的な改修負担としてイベント的に捉えるのではなく、通常のアップデートと捉えて日常的に対応していく必要がある。

アプリケーションが利用するクラウド機能（サービス）について

市場シェアの大きいクラウドでは、サービス開始当初からの古い機能（サービス）も継続して提供されているため、クラウドが提供する全てのサービスが必ずしもモダンなものではない。また、クラウドが提供する全てのサービスをそのまま使ったとしても必ずしもモダンなアーキテクチャになるわけではない。

サーバー構築を前提とするものなど、使用を避けるべきサービスもあるため、適切なクラウドサービス上でのシステム構築であっても、事業者からの提案が本方針に沿ったものであるか否かについて留意する必要がある。

クラウド移行後のシステム刷新タイミング

オンプレミス環境では、ハードウェアの寿命が業務システムのライフサイクルを大きく支配しており、ハードウェアの更改時にシステムを刷新する方法が一般的であった。しかしながら、クラウドにおいては、ハードウェアの寿命を利用システムが意識する必要がなくなったため、システム刷新タイミングの考え方も見直す必要がある。

マネージドサービスだけを組み合わせて構成するモダンなアプリケーションでは、アジャイル的なアプローチで継続的な改善（開発）が行われるため、アプリケーション自体も陳腐化しにくい。

よって、クラウドに移行後のシステム刷新は、以下のタイミングで行われることが好ましい。

・環境の変化（根拠法の大規模な改正を含む。）に伴い業務システムを在り方レベルで大きく見直す必要が生じたタイミング

・構築時から大きな技術変化（利用可能サービスの革新的な変化）があり、継続的な改善（開発）ではなく抜本的な刷新が必要となったタイミング。旧世代のクラウド利用から今日のスマートなクラウド利用への切替えも含む。

・競争性の確保のため、競争的な調達によって事業者の見直しを行うタイミング

システムを継続使用する間の運用保守事業者については、継続的な改善（開発）を行うシステムについては国庫債務負担行為（複数年契約）での調達が合理的である。単年度での契約を繰り返す場合は、事業者変更時の対応、メリット・デメリットを十分に評価しておく必要がある。

セキュリティについて

「セキュリティと利便性とコストでバランスをとる」、「扱う情報の機密性等に応じたセキュリティ対策をとる」等の基本的な方針は普遍であり、「政府機関等のサイバーセキュリティ対策のための統一基準群」や個人情報の保護に関する法律等の個人情報等の適正な取扱いに関する関係法令等への準拠が求められる[^1]ことはオンプレミスと変わらないが、オンプレミスとクラウド（特に今日のクラウド）では、セキュリティ対策の具体的な考え方や技術で大きく異なる点がある。クラウドを利用する政府情報システムについては、以下を踏まえたセキュリティ対策を行うことを原則とする。

責任共有モデルによる対象の絞り込み

従前のアプリケーションでは、システムを構成するハードウェア、OS、ミドルウェア、業務アプリケーションから、設備・運用も含め、全てのセキュリティ対策を考慮する必要があったが、クラウドにおいては、責任共有モデルにより、クラウドが提供するものはCSPが責任を負い、利用システムはその利用についてのみ責任を負う。

利用システムの責任は、業務アプリケーション、利用者端末、運用、クラウド利用における設定（利用者データの保護に係るものを含む。）、アカウント等に限定される。OSSも含めて業務アプリケーションや利用者データに係るセキュリティ対策はシステム構築側の最終的な責任となるため、システム構築者が自らその対策を行う必要がある。

ISMAP等クラウドサービスリストに登録されたクラウドサービスについては、クラウドが提供する部分のセキュリティレベルを利用システムが特に検証を行う必要はないが、ISMAP等クラウドサービスリストに登録されていない場合は、「４．１　ISMAP以外のクラウドセキュリティ認証等」の対応が必要となる。

ベストプラクティスへの準拠

ガバメントクラウドに選定されているクラウドや一部のクラウドにおいては、CSPによって、そのクラウド利用に最適な考え方や方式がベストプラクティスとして用意されている。従前のセキュリティ対策の踏襲を基本とするのではなく、利用するクラウドのベストプラクティスに準拠した最新の対策を行う必要がある。また、ガバメントクラウドが用意するリファレンスアーキテクチャを活用することで、より具体的な実装も可能となる。

境界型セキュリティのみに依存しないセキュリティ対策を行う（ゼロトラスト）

オンプレミスでは境界型セキュリティの考え方に基づいてネットワークセキュリティを重視して、危険な外部と安全な内部を遮断するといった対策方法が主流であったため、内部についてのセキュリティ対策が十分でない場合があった。クラウド利用時においては、ゼロトラストの考え方に基づいて全てのレイヤーでセキュリティ対策を検討し、エンド・ツー・エンドで、データの秘匿・保護を行い、動的に監視や認証等を実施することが推奨される。

予防的統制と発見的統制の実施

予防的統制とは、潜在的なリスクを事前に予測し、不適切な設定や操作を未然に防ぐための対策を指す。例えば、担当する業務に必要な最小限の権限のみをユーザーに与え、必要以上の情報へのアクセスや誤操作を防ぐことは、予防的統制の一つである（最小権限の原則）。ただし、クラウドではサーバーやストレージなどのITリソースの細かな操作をプログラムからAPIを介して呼び出せるように、権限もその操作の単位で割り当て可能なことが多く、サーバーの構築・運用だけで数百の操作や権限が定義されている場合もある。

クラウド環境では、システムの開発段階、運用環境の種類、業務の内容などに応じて、権限設定の厳密さを調整することが重要である。例えば、本番環境でシステムの障害の切り分けを行う際には、様々な操作を制限されたユーザーでは業務を遂行することが困難になる場合がある。このような場合は、業務効率を優先し、一時的に広範囲な権限をユーザーに与えることも考えられる。このような予防的統制への補完として求められるのが発見的統制である。

発見的統制とは、組織で定めたポリシーの準拠状況（暗号化やログ取得の実施状況、外部公開設定など）やリスクの発現につながる操作等を監視して検知し、必要に応じて修正する統制を指す。クラウドではポリシーへの準拠状況等を点検し、ログの監視が可能なマネージドサービスが提供されており、それを活用することが望ましい。前述の幅広な権限の割り当て時は、発見的統制の一環でログの点検で不要なサービスや操作へのアクセスの有無を検知することが望まれる。

サーバーを構築しないアーキテクチャの採用

自らサーバーを構築し運用すると、そのサーバーにおけるセキュリティに関する監視や運用を自らの責任で行う必要がある。システムで求められるセキュリティ監視、運用機能を具備したクラウドが提供するマネージドサービスを利用することで、サーバー構築が不要となると、サーバーのセキュリティ対策もサービス（サーバー）を運用するCSPが実施することになり利用システムでは不要となる。

サーバーを構築しないこと自体が利用システムのセキュリティ対策であり大きなリスク軽減となる。ただし、アプリケーションやデータなどに関するセキュリティ対策は利用システム側の責任において実施する必要があるため、「1）責任共有モデルによる対象の絞り込み」等を参考に利用システムで検討すること。

また、自らがサーバーを構築すると、その部分については前述の予防的統制と発見的統制、セキュリティ対策のデフォルト化、自動化についても阻害される場合があるので特に留意が必要となる。

IaCとテンプレート適用による主要セキュリティ対策のデフォルト化と構成管理

セキュリティ対策を効率的かつ確実に実施するために、予防的統制と発見的統制の設定を組み込んだテンプレートとIaC（インフラストラクチャ・アズ・コード）の活用が重要となる。IaCとは、サーバーやネットワークなどのインフラ環境の構築を、コードを用いて自動化するという手法である。あらかじめセキュリティ対策の設定を組み込んだテンプレートを利用することで、人為的なミスを減らし、セキュリティレベルを向上させることができる。

IaCを活用することで、検証環境や本番環境など、用途に応じた複数のクラウド環境を容易に構築・管理できる。また、IaCによってインフラ環境の構築プロセスを自動化することで、人為的なミスを減らし、効率的かつ低コストでインフラ環境を構築・運用することが可能になる。例えば、従来のオンプレミス環境では、ログの取得状況を一つずつ確認し、場合によっては、担当者が手作業でログを取得する設定を行ったり、人手では全てのログを検査できないため、一部のログを抽出して検査したりしていた。しかし、クラウド環境では、提供されている機能を利用することで、全てのログを保管し、設定したルールに基づいて自動的に分析することが可能になる。これにより、人為的なミスによるログの見落としや分析の遅れなどを防ぎ、セキュリティ運用コストの削減も期待できる。

また、IaCではコードによってインフラ環境を構築するため、構築されたインフラ環境がコードの内容と一致していることが保証される。そのため、コードの内容を適切に管理することで、インフラ環境のセキュリティを維持することができる。

データ保護に関する暗号化技術の利用

クラウド環境では、データを暗号化する機能を提供するサービスが充実しており、オンプレミス環境よりも容易かつ安全に暗号化技術を利用することができる。データの機密性や想定される脅威に応じて、通信中のデータや保管されているデータを暗号化することを検討する必要がある。暗号化を行う際には、「電子政府推奨暗号リスト」に基づいた暗号アルゴリズムを選択し、適切な方法で暗号鍵を管理する必要がある。クラウドでは暗号鍵管理をクラウドの利用者が自ら実施できることを考慮し、取り扱うデータに求められるセキュリティ要件に基づいて運用方式と実装を検討する。例えば、クラウドの暗号鍵管理サービスの提供する利用者が主体的に管理可能な暗号鍵では、アクセス権の設定を含む鍵のライフサイクルを管理する。「BYOK(Bring Your Own Key)」と呼ばれる方式では、利用者自身が作成した暗号鍵をクラウド環境に持ち込み、クラウドサービス事業者が提供する鍵管理サービスを利用して、その暗号鍵を管理し暗号化処理を行う。また、HYOK(Hold Your Own Key)と呼ばれる方式では、利用者が保有する鍵管理システム上で保管・管理されている暗号鍵をクラウドサービス事業者のサービスから利用して暗号化処理を行う。いずれの場合も、利用者自身がクラウド以外で暗号鍵を作成・保管・管理する場合は**、**サービスに組み込まれた標準的な方法を利用する場合と比べて運用負荷や処理の複雑さが大幅に増すため、導入前に十分な検討が必要となる。

定量的計測とダッシュボードによる状況の可視化

セキュリティ対策の自動化を実施しても、管理者や関係者が速やかに状況を把握する必要性は変わらない。大規模なシステムや影響の大きいシステムについては、定量的計測とダッシュボードにより、可視化された情報が自動で提示されることが望ましい。

継続的なアップデートへの対応

前述のセキュリティ対策の多くはクラウドが提供する機能に依存し、その機能は絶えずアップデートされている。利用システムにおいては、アップデート対応を義務的な改修負担としてイベント的に捉えるのではなく、通常のアップデートと捉えて日常的に対応を行い、適宜、設計の見直しも実施する必要がある。意図しない範囲まで情報が公開されるなど、特に機密性の低下を招かないよう注意する必要がある。

インシデント対応と自動化

インシデント対応のプロセスを定義し、適切な訓練を実施することは、オンプレミス環境だけでなく、クラウド環境においても重要である。クラウド環境では、どのような種類のインシデントが発生する可能性があり、その影響範囲はどの程度なのか、誰がどのような対応を行うべきなのかを、事前に明確に定義しておく必要がある。発生が予想されるインシデントについては、具体的な対応手順をまとめた「プレイブック」を作成し、訓練を実施することで、迅速かつ適切な対応が可能になる。また、クラウド環境では、インシデント発生時の調査に必要な環境を自動的に構築する機能が提供されている場合があり、このような機能を活用することで、インシデント対応の迅速化・効率化を図ることができる。

クラウドに最適化した自己点検・監査

クラウド環境において利用システムが自己点検を行う、または監査を受ける場合、前述の「責任共有モデル」を考慮した対応が考えられる。利用システム自身が構築している範囲は従来通りの自己点検や監査対応が必要だが、クラウドサービス事業者が提供するマネージドサービスなどを利用している範囲はCSPが受けている独立した第三者の監査法人による監査内容の確認を自己点検とすることや確認結果等を監査者に示すことで対応の効率化を検討できる。なお、利用システム自身の構築範囲においては、クラウドサービス事業者が提供するセキュリティ監視機能などを活用することで、セキュリティ設定の適用状況を迅速に把握することが可能な場合もある。

システム運用について

システムをモダン化して刷新しても、システム運用が従前のままではコスト削減効果は十分に発現しない。クラウドを利用する政府情報システムについては、以下を踏まえたシステム運用を行い、運用に係る費用の削減を行うことを原則とする。

クラウド利用料を定期的に確認する

クラウドサービスの利用料金は、実際に利用した分だけ課金される仕組みになっている。無駄なコストが発生していないか、利用料金を定期的に確認するようにする必要がある。

稼働していないリソースへの課金を抑制する

クラウドサービスでは、サーバーなどのリソースが稼働している間は、常に料金が発生する。そのため、休日や夜間など、システムを利用しない時間帯には、サーバーを停止するなどして、稼働していないリソースへの課金を抑制する必要がある。クラウドサービス事業者が提供する自動起動・停止機能などを活用することで、効率的に課金を抑制することができる。

ピーク時を想定した大きなリソースを通常時に使用しない

クラウドサービスでは、アクセスが集中するピーク時に備えて、あらかじめ大きなリソースを確保しておく必要はない。アクセス状況に応じて自動的にリソースを調整する「オートスケール」機能を活用することで、必要な時に必要な量のリソースだけを利用することができる。オートスケール機能を利用できない場合は、運用コストが過大とならない範囲で、手動でリソースの調整を行う必要がある。

IaCによるインフラ作業の効率化

IaCを活用することで、インフラ環境の変更や、類似した環境の構築を、コードの修正と実行だけで行うことができるため、従来のように手作業で設定を行う必要がなくなる。また、人為的なミスを減らし、検証作業にかかる時間も短縮できるため、開発期間の短縮やコスト削減に繋がる。さらに、検証用の環境を容易に構築できるため、テストを効率的に実施することも可能になる。

運用作業の自動化を徹底する

クラウドサービスでは、バックアップ、システムの状態監視、アラート発生時の初期対応など多くの運用作業を、CSPが提供するマネージドサービスや自動化ツールなどを活用することで自動化することができる。人手に頼っていた運用作業を自動化し、運用コストの削減とヒューマンエラーの防止を図る必要があるため、自動で実行可能な単純作業を事業者が人件費を用いて実施しないよう、特に留意が必要となる。

監視対象を見直す

従来のオンプレミス環境では、サーバーやネットワークなどのインフラの状態を監視することが重要視されていたが、クラウド環境では、インフラの監視よりも、アプリケーションやサービスが正常に動作しているかを監視することが重要になる。CSPが提供する監視ツールなどを活用して、システムの稼働状況やパフォーマンスなどを監視し、サービスの品質維持や業務レベルでの価値向上に努める必要がある。

運用報告を見直す

従来のオンプレミス環境では、月次で運用報告書を作成し、前月のリソース使用状況や運用作業の内容などを報告することが一般的であった。しかし、クラウド環境では、システムの稼働状況やパフォーマンスなどをリアルタイムに確認できるダッシュボードが提供されているため、月次報告書を作成する必要性は低くなる。ダッシュボードで確認した内容を基に、迅速に問題点の解決やサービス改善に取り組む必要がある。また、運用に関する記録の保管は必要最小限のコストで対応し、システムの価値に直結する定量的計測の結果と評価についても併せて実施すること。

常駐運用からリモート運用へ

クラウドでは、発注者拠点での常駐運用にオンプレミス時のような必要性はない。システムの運用管理を遠隔地から行うリモート運用を原則とすべきである。常駐体制よりもリモートでの速やかな対応や報告等を優先させるべきである。

夜間バッチの必要性を見直す

クラウド環境では、リソースを柔軟に増減できるため、従来のように夜間バッチ処理を行う必然性は低くなる。特に、業務時間外に処理を実行する必要がない場合は、ピーク時の負荷軽減やシステムメンテナンスとの連携を考慮する必要もなく、業務によるデータ更新が発生しない時間帯に逐次処理を行うことで、より効率的な運用が可能となる。処理の要件として直列性が要求される場合、法令に基づいて基準日の決められている事務や、大量のデータを一括処理する必要がある場合においても、可能な限り日中の処理を計画し、夜間オペレータや夜間の自動処理に必要な複雑なジョブネットの最小化を図るべきである。

マネージドサービスのアップデート時等における確認テストの最適化

CSPが提供するマネージドサービスは、定期的にアップデートが行われる。アップデートによってシステムに何らかの影響が出ないかを確認するテストは、影響が出る可能性が高い場合には必要だが、可能性が低い場合には事前に大規模なテストを行うよりも、アップデート後に問題が発生した場合に迅速に対応できる体制を整えておくことが有効である。いずれにしても、テストの自動化、テストコードの整備を開発時に行っておくことが望まれる。また、アップデートによって問題が発生しやすい特殊な実装は、当初から避けることが望ましい。

運用作業を定期的に見直す

システムの運用作業は、定期的に見直し、効率化を図ることが重要である。運用作業にかかっている時間や労力を分析して自動化すべき部分がないか検討し、手作業を継続的に削減していく必要がある。

公文書管理との関係への留意

クラウドで管理されている文書についても、公文書等の管理に関する法律（平成21年法律第66号）第２条第４項の要件を満たせば行政文書となり得る。クラウドの特性を踏まえ、遺漏なく法令等に基づいて公文書管理が行われるよう、システムの開発や運用に際しては、公文書管理に関する法令のほか「業務システムと公文書管理のルールについて」（令和４年２月16日内閣府大臣官房公文書管理課長通知）等に留意する必要がある。

　システム刷新の進め方

クラウドへの移行時におけるシステム刷新の進め方を以下に示す。新規システムの場合については、ここで記述されている刷新後のシステムを当初から開発する前提で読み替えられたい。また、全体的な事項についてはデジタル・ガバメント推進標準ガイドラインに準拠し、クラウドに関する部分については、本指針を優先されたい。

システム刷新実施時の基本的な考え方

モダン化の実現には意識変革が必要である。旧来技術の温存はモダン化を大きく阻害する。以下の考え方に留意すること。

・モダン化では技術の最新化と変化を追求すること

モダン化においては、最新の技術を積極的に取り入れ変化を意図的に促すことが基本となる。まず、職員がこの意識を持つことが重要となるが、事業者についてもモダン技術に明るく変化に積極的な事業者を選定することが重要である。

・インターネットへのセキュアな接続を前提とすること

従来のオンプレミス環境では、システムを外部ネットワークから隔離した閉域網で運用することが一般的であった。これは、管理されていないコンピュータがシステムに接続された場合に、セキュリティ上のリスクが高まることを防ぐためである。適切にクラウドを利用するシステムでは、システムやデータをセキュアなクラウド環境内に配置するため、データのコンピュータからコンピュータへのリレーが発生しない。クラウド内やクラウド間の通信は全て暗号化が基本であり、API連携も認証と暗号化が前提となる。クラウドと利用端末間も認証と暗号化が行われる。クラウド自身についてはCSPの責任で不正アクセス等から守られている。よって、クラウドに処理を集約させること自体が安全対策となる。

また、セキュリティ対策の考え方も、従来の「境界型セキュリティ」から「ゼロトラスト」へと変化している。境界型セキュリティは、外部からの攻撃を防ぐことに重点を置いていたが、内部からの攻撃には脆弱であった。一方、ゼロトラストは「すべてのアクセスを信頼せず、常に検証を行う」という考え方であり、より強固なセキュリティ対策を実現できる。さらに、最新のセキュリティ対策を実施するためには、インターネット接続が不可欠になっている。

よって、クラウド利用については、インターネットへのセキュアな接続を前提とすること。旧来型の業務システムではアプリケーションや各機器で十分なセキュリティ対策をとっていなかったので境界型セキュリティによる防御（閉域網に閉じた運用）を必要としたが、今日の業務システムにおいては、適切なセキュリティ対策がとられていない業務システムのみがセキュリティ対策として閉域網に閉じた運用を必要としていると考えるべきである。

閉域網に閉じた運用は、システムの外部連携やSaaS利用を大きく阻害し、外字に対応した閉域網内では文字化けが顕在化しないことから外字を多用するシステムや高コストな旧来型システムの温存を助長する。インターネットへのセキュアな接続を前提とすることはコスト削減の観点でも重要となる。

・二段階移行は可能な限り避けること

システム刷新（クラウドへの移行）については、１回での移行（刷新：Rebuild）、全面的なモダン化を原則とすること。対象システムのシステムライフサイクルを前提に、様々な環境を踏まえ、適切な時期での刷新を検討すること。

二段階移行については、２回の移行作業によってトータルコストが増大するおそれがあることから、刷新については、システムの規模や移行の難易度等を踏まえ、各システムのライフサイクルの適切なタイミングで実施することを前提としつつ、可能な限り１回での刷新を目指すこと。

また、本方針で記載するシステム刷新は原則として１回での刷新を指す。二段階移行における第一段階（暫定対処：Replatform）の場合は二段階目の移行を計画した上で「3.5 アプリケーションとシステム刷新について」を踏まえ可能な範囲での対応、部分的なモダン化とし、計画に従って二段階目（刷新）を実施すること。

・大規模なシステム等、難易度の高いシステムについては一括刷新を避けること

システム刷新については、可能な限り一括での刷新を検討するべきだが、大規模なシステム等、難易度の高いシステムについては、リスクの分散化と予算の平準化を目的に、刷新する単位（サブシステム等）を分割し、優先度を十分に検討した上で、順次、刷新を行い、一括刷新を避けること。

なお、大規模なシステム等をサブシステム単位等に分割して順次、刷新する場合についても、各々の刷新は１回での実施とし、二段階移行は避けること。

・現行システムの機能や実装の単純継続を前提とせず、データ移行のある新規システムとして考えること

刷新においては、現行システムの機能や実装の単純継続を前提とした移行は行わない。そもそも現行システムを前提とすることは、後述の業務観点の見直しとシステム観点の見直しを行わないことになる。

現行システムからは、基本的に現行システムの仕様と現行データのみを抽出するだけとする。抽出された現行仕様については業務の見直しを行って新仕様を策定する際の参考情報にとどめ、単純な流用は行わない。現行データについても、必要なもののみに限定してデータ移行を行うものとする。現行システムのソースコード流用を前提とした移行は刷新の大きな妨げになるため厳に避けること。

特に現行システムが旧来のクライアントサーバー方式やWeb三層モデルを採用して多数の画面や、多くの帳票、大量のバッチ処理等によって大規模化（以下「肥大化」という。）している場合については、肥大化した現行システムの規模を前提に刷新の見積りを取得すると非常に高額な見積りとなり刷新計画自体が頓挫してしまう。

よって、肥大化した現行システムではなく業務観点の見直しとシステム観点の見直し後の新仕様を前提にデータ移行のある新規システムとして見積もりを取得すること。

業務観点の見直しとシステム観点の見直し（後述）を行った上で刷新を行うことができれば、現行システムと比較し刷新後のランニングコスト（運用等経費）の減少を見込むことができ、刷新に要したコスト（整備経費）の回収期間について適切な評価が可能になる。

・開発規模のスリム化を徹底すること

現行システムは肥大化していることが多く、刷新時には現行システムの規模を決して前提とせず、スリム化されたシステムを新規開発することを前提に見積りを取得し、要件定義等を実施すること。スリム化の観点としては以下が想定される。

画面の削減（真に使いやすいGUIをフロントエンド・バックエンド分離型Webシステムで実装）
帳票の削減（法定帳票以外の内部帳票は原則不要）
バッチの削減
不要な例外処理の削減
フルスクラッチ開発の削減（SaaSとマネージドサービスの活用）
特に非機能要件（大量処理、高信頼、セキュリティ）への対応はフルスクラッチ開発ではなくインフラ（マネージドサービス）で対応する

・業務観点の見直しとシステム観点の見直しの双方を実現すること

刷新においては、業務とシステムの双方の観点から見直しを行うこと。

「業務観点の見直し」

サービスデザイン思考を採用し、法律等のルールを単純に実装するのではなく利用者視点でサービスを見直し、制度（法令、省令、内規、通知等）の変更も視野に入れて検討する
業務の高度化やサービス向上を合理的に実現する
業務処理から無駄や不合理を省く（システムの計算結果を電卓で確認する等の無用のチェック、過度の複数チェック、紙出力による確認や押印等）
外部システムと必要なデータを連携させ、デジタル第一原則（デジタルファースト）によって個々の手続・サービスが一貫してデジタルで完結させる
届出一度きり原則（ワンスオンリー）として、一度提出した情報は、二度提出することを不要とする

「システム観点の見直し」

旧来技術からの脱却（旧来型のセキュリティ対策、多階層の大規模な画面構成、クライアントサーバー方式、Web三層モデル、シンクライアント（VDI等）、法定帳票以外の多数の帳票、夜間バッチ、紙での月次運用報告等、人海戦術的な運用作業等の排除）
システムやアプリケーションのモダン化
アジャイルとCI/CDを原則とする開発・運用方式のモダン化

システム観点の見直しにおいては、クライアントサーバー方式から脱却することが特に重要となる。クライアントサーバー方式の場合、画面生成に埋め込んでいた同じコードの繰り返しで規模が肥大化するだけでなく、クラウド技術にも馴染まないためモダン化の阻害要因になってしまう。更には、クライアント側に保管される業務データをセキュアに管理するため、シンクライアント（VDI等）導入の要因にもなりやすい。

画面については「フロントエンド・バックエンド分離型Webシステム」の採用を検討されたい。分離型にすると以下のメリットが期待される。

これまで画面生成に埋め込んでいた同じコードの繰り返し再利用による無駄（開発規模の肥大化）を解消でき、開発コストを削減できる
利用者体験（ユーザエクスペリエンス）を踏まえた全体アーキテクチャ検討の後に、UX設計をワイヤーフレーム（画面レイアウト）まで具体化したフロントエンドを作成することで、真に使いやすいシステムにできる。使いやすいシステムは多階層の大規模な画面構成とならないため、開発規模の適正化（開発コスト削減）にも寄与する
フロントエンドとバックエンドをAPIによって独立させ、疎結合にすることで変更に強いアーキテクチャとなる。画面表示の修正はフロントエンドのみの修正、業務処理の修正はバックエンドのみの修正となり、将来の改修時の改修対象が限定、極小化され、保守費用が削減される
分離型にすると、バックエンドではインタフェースがAPIのみとなるのでアーキテクチャがシンプルになり、画面処理もなくなるのでセッション情報の維持なども減る。また、これまでサーバー側で処理していたレンダリング（画面生成）をクライアント側で行うので、サーバー（クラウド）側に必要なコンピュートリソースも少なくなってコスト削減につながる
更には、クライアントとサーバー（クラウド）間の通信も最小化され処理の高速化、ネットワーク負荷の軽減にも寄与する

・システムのスコープ（対象、範囲）と制度の見直しを行うこと

刷新においては、１システム単独では実現できない、より広いスコープでの検討が必要となる場合がある。よってシステムを広範に見直すタイミングにおいて、より広いスコープでの見直し、統合の検討を行うこと。統廃合されるシステムはその旨を将来の計画としてプロジェクト計画書に記すこと。

組織ごとに独立して実装していたシステムの統合
上流業務や下流業務との統合
類似業務、関係性の深い業務の統合
追加開発された機能が別システム化しているものの統合等

また、統合や業務観点での見直しに際して必要となる制度（法令、省令、内規、通知等）の変更、関連組織等との調整については、情報システム部門だけでなく、制度所管部門・業務実施部門が主体的に、広く関係者と連携して実施すること。

・クラウドに適した災害対策を行うこと

クラウド利用システムにおける災害対策は、オンプレミスとは異なり、データコピーの容易性、環境構築の俊敏性、リソースの柔軟性等、クラウドの特徴を活用し検討することに加え、災害対策のために利用する各リージョンで利用できるサービスに不足がないことを確認しながら設計することが必要となる。また、システムアーキテクチャ、システム構成及びコストに大きな影響を与えるため、関東圏全域といったリージョン全域にわたる大規模災害への対策を必要とするか否かも重要な要素となる。以下の選択肢を基本として、各々のシステム特性・ニーズをもとに検討する必要がある。

(1) リージョン全域にわたる大規模災害ではなく部分災害への対策に限定し、費用対効果が高く冗長性を担保したマルチゾーンパターン（シングルリージョン構成）

(2) リージョン全域にわたる大規模災害を想定し、データをクラウドの機能で遠隔保管することで費用対効果の高いバックアップパターン（シングルリージョン構成＋リージョン外へのデータ保管）

(3) コストはかかるものの災害対策用リージョンでは最小限の構成を保持しておき、リージョン全域にわたる大規模災害時には災害対策用リージョンで稼働を続けるウォームスタンバイパターン（マルチリージョン構成）

(4)リージョン全域にわたる大規模災害時にコストをかけてでもサービスを変わらず継続する必要のあるアクティブ-アクティブパターン（マルチリージョン構成）

職員向けシステムや、一部の国民向けサービスは、基本的にパターン(1)か(2)になり、広く国民向けサービスのうち、停止すると国民生活に影響のあるもののみ(3)か(4)が想定されるが、各々の業務継続計画（BCP）に沿って目的に即した災害対策を選択するものとする。なお災害対策を目的としたマルチクラウド（複数のCSPによる冗長化）は、費用対効果が特に悪いため、選択しないことを原則とする。

災害時の運用体制についても、自動化、IaC、リモート操作を前提に各々の業務継続計画（BCP）に沿って計画しておくこと。

・ライフサイクルコストを削減する観点から評価方法を工夫すること

刷新にかかるコストを削減するためには、前述の各項目に加えて更なる注意が必要となる。

SaaS利用は開発量の削減となるため強く推奨されるが、無条件に推奨されるわけではない。利用者数の段階的な増加が見込まれる場合等、運用段階でSaaS利用料が高額となるケースもあるため、ライフサイクルコストの観点から真にコスト削減効果が発現するかを慎重に評価する必要がある。例えば、SaaSと同様の機能を他のマネージドサービスで実現することが可能であれば、ライフサイクルコストの観点から両方式を比較して十分に評価すべきである。

調達において、応札価格はその調達の対象、範囲に限定されたものであり、ライフサイクルコストの一部でしかない。事業者は応札価格を下げるために、応札価格に反映されない部分が高額となる提案を行う場合も想定される。そのため、総合評価落札方式の中でライフサイクルコストを低減させる提案を技術点として評価する等、評価方法を工夫することを推奨する。

システム方式（全体アーキテクチャ）の考え方

業務システムの実現方式、全体アーキテクチャについても、旧来方式の単純な継承はモダン化を大きく阻害する。以下の点を考慮して、システムの全体アーキテクチャを設計する必要がある。

・データ処理をクラウド内で完結させる

データ処理はクラウド内で行う原則として、端末やオンプレミス環境にデータを保存しない。ただし、処理速度の向上や災害対策などのために、一時的にデータをキャッシュしたり、バックアップデータを保管したりする場合は、セキュリティ対策を適切に実施する必要がある。

・紙文書の単純な電子化は行わない

紙文書を画像として電子化するのではなく、データとして活用できるように加工する。データ入力は原則としてシステム上で行い、データベースに保存する。申請や審査などのワークフローもシステム上で処理する。申請書や交付書類などの証拠となる文書は、必要に応じて検証可能な形式で生成する。

・作らないアプローチを徹底させる

SaaSとマネージドサービスを徹底し、開発量の削減や開発への生成AIの活用を図る。SaaS化されていないパッケージ利用は将来のサポート終了や提供終了に備えること。

・共通的に利用される機能のSaaS化や共通サービス化を積極的に行う

共通システム、共通業務、共通機能等については、積極的にSaaS化や共通サービス化を行う。また、各システムはこれらのSaaSや共通サービスを利用して開発量を削減させる。

・ウォーターフォールからアジャイルに発想を切り換える

机上での遠大な計画から、実践と測定された事実に基づく継続的な改善にアプローチを変更する。ピークに備えた大きなリソースを通常時に遊ばせておくことはクラウドではコストの無駄遣いとなる。

刷新時のプロセス（システム計画工程）

図 3‑1　刷新時のプロセス（システム計画工程）

・スコープや制度の見直し

スコープや制度の見直しには時間がかかるため、システム計画工程内ですべてを完了できない場合もあるが、この工程から見直しに着手することが重要である。

・新たな要件の方向性を確認

「業務観点の見直し」と「システム観点の見直し」を方向性の確認レベルで実施する。「業務観点での見直し」では、スコープや制度の見直しを前提に、基本的な業務フローの作成までを行う。例外処理等の細部への踏み込みは、本工程では避けるべきである。「システム観点の見直し」では、全体アーキテクチャ、システム構成の作成までをガバメントクラウドが用意するリファレンスアーキテクチャを参照して実施する。現行システムの技術的な分析は行わない。

大規模なシステム等、難易度の高いシステムについては一括刷新を避けるために、サブシステム（サービス）単位での分割と刷新の単位・優先度（順序）の検討を行う。一括刷新であっても、この段階で、システムを疎結合な複数の（サブ）システムに分割することが、これ以降のシステム開発や運用費用削減に資するため、これを試みる。また、システム分割したうえで、一部のシステムについては外部の他システムと統合できるとより効率がよいため、これも検討する。

・投資対効果分析を概算で実施

新たな要件の方向性をベースに、投資対効果分析を行う。現行システムをベースとした費用見積りは行わない。新たな要件の方向性を前提にデータ移行のある新規システムとして見積りを取得すること。システムのスリム化とモダン化でアプリケーション開発コスト（整備経費）を抑制し、運用方式のモダン化、自動化の徹底等でランニングコスト（運用経費）についても抑制すること。

また現行システムと新システムでスコープが異なる場合は、適正な評価となるよう、可能な限りスコープを一致させること。スコープの一致が難しい場合は、スコープの相違を考慮した評価を行うこと。

刷新時のプロセス（要件定義工程）

図 3‑2　刷新時のプロセス（要件定義工程）

・現行システムにおける要件の抽出

設計書等を中心に現行システムの業務要件を抽出する。業務観点で「やらなければいけないこと」「制度からの要求」「継続が必要なもの」を抽出する。統合等でシステムのスコープが拡大される場合は、全体を俯瞰して実施すること。

・現行システムにおけるデータの抽出

設計書や実際のデータベース等を確認して、データ移行されるべきデータの把握を行う。

・新たな要件の策定

以下の詳細プロセスで実施する。

業務要件の仮定：「業務観点の見直し」を行うにあたって、「やらなければいけないこと」を再確認し、「制度からの要求」についても必要であれば見直し、「継続が必要なもの」と不要なもの、改善されるべきものを分類し、新システムで実現されるべき新たな要件を仮定する。
実装方式（アーキテクチャ）の仮定：「システム観点の見直し」を前提にアーキテクチャを新たに検討する。ガバメントクラウドが用意するリファレンスアーキテクチャ等を活用すること。また、UXを担うフロントエンドと業務処理を担うバックエンドを独立的に検討すること。
見直しの実現状況の確認：「業務観点の見直し」と「システム観点の見直し」の実現状況を確認する。
新たな要件の決定：上記の詳細プロセスを反復的に実施し総合的に調整して新たな要件とする。

また、「新たな要件の策定」の実施時には以下に留意すること。

マイクロサービス適用の検討：マイクロサービスの適用が合理的か否かを検討する。大規模なシステムについては、サービスの観点から調達を分割することで調達規模の適正化を検討する。
リファレンスアーキテクチャ適用の検討：システムの特性に応じてガバメントクラウドが用意するリファレンスアーキテクチャの採用を検討する。全面適用しない場合についても、部分適用、エッセンスの活用も含めて検討する。
旧来技術の適用を厳に避ける：閉域網での利用ではなくインターネットでの利用（境界型セキュリティからゼロトラストへ）を原則とする。クライアントサーバー方式は採用せずフロントエンド・バックエンド分離型Webシステムを基本とする。シンクライアント(VDI等)、DaaS(Desktop as a Service)等も避ける。
開発規模の適正化：開発量を削減するためSaaSや他のマネージドサービスの活用を検討する。業務観点の見直しによって法定帳票以外の帳票は極力削減し、帳票印刷処理もBI機能等での代替を原則とする。バッチ処理は設計レベルで見直して、合理性や経済性の観点から必要性が明らかなもののみとする。特に夜間バッチは夜間オペレーターや夜間の自動処理に必要な複雑なジョブネットによる夜間の自動処理を必要とするため、特に厳しく精査を行う。
ローコード・ノーコードツール：従来型のローコード・ノーコードツールの適用は、ツールの有効性と効果、体制、システム開発における生成AI利用との比較等から慎重に検討する。

・合理的な調達単位の検討

新たな要件やアーキテクチャを前提に調達単位の整理を行う。マイクロサービス化による調達の分割、CI/CD実施による開発と運用保守の一体化等を検討する。

マイクロサービスの単位で調達を分割する場合は、１マイクロサービスを数人程度で開発するチームを前提にチーム構成を検討されたい。また、フロントエンド・バックエンド分離型Webシステムではフロントエンドの開発チームを独立させることが前提となる。一方で、調達単位を分割しすぎることで、発注者側の調達に係る負担や事業者の管理・調整に係る負荷が増大することから、プロジェクトの実効性が損なわれないよう留意する必要もある。いたずらに調達単位を分割しすぎず、全体を統括する役割を明確にしながら調達単位の適正化を図られたい。

刷新時のプロセス（設計開発・運用保守工程）

図 3‑3　刷新時のプロセス（設計開発・運用保守工程）

・流用可能資産の調査と評価

現行システムから流用できる資産を調査し、評価する。業務やシステムを抜本的に見直す方針から、要件定義や見積りの段階では、原則として資産の流用は前提としないが、新たな要件確定後の開発時には流用可能な資産（設計ドキュメントやソースコード等）の調査を行う。なお、流用資産は原則として単純流用するのではなく参考情報として活用する。

・アジャイルとCI/CDを原則とする設計開発・運用方式の決定

調達された事業者からの提案をベースにアジャイルとCI/CDを原則とする開発・運用方式、開発ツール等を決定する。

・設計開発と運用保守

前述の要件定義や設計開発・運用方式を用いて設計開発・運用保守を行う。

・システム移行方式とデータ移行、検証方法の検討と実施

システム移行方式、データ移行、結果検証方法等を決定し実行する。

暫定対処時のプロセス（要件定義工程）

図 3‑4　暫定対処時のプロセス（要件定義工程）

・データベースと運用管理機能のマネージドサービス化検討

使用するサービスの検討とシステム構成図の作成を行う。

・アプリケーション実行環境の検討

大規模な改修を要さない場合については、コンテナ化、サーバーレス等のアプリケーション実行環境を可能な範囲で検討する。

・データ保管環境のオブジェクトストレージ化検討

データを共有ストレージに保管するのではなくオブジェクトストレージに保管するよう検討を行う。

・テンプレート適用とセキュリティ対策の検討

ガバメントクラウドで要求されるテンプレートとセキュリティ対策を確認し、実現方法を検討する。

・データ移行の準備

システム移行方式、データ移行、結果検証方法等を概要レベルで検討する。

暫定対処時のプロセス（設計開発・運用保守工程）

図 3‑5　暫定対処時のプロセス（設計開発・運用保守工程）

・設計開発と運用保守

現行システムでの方式にアジャイル要素を加味した設計開発・運用保守を行う。

・システム移行方式とデータ移行、検証方法の検討と実施

システム移行方式、データ移行、結果検証方法等を決定し実行する。