---
title: "クラウド・バイ・デフォルト原則とは？デジタル庁の現行方針DS-310と2026年改定案の要点"
url: "https://www.issoh.co.jp/column/details/9362/"
published: 2025-10-17
updated: 2026-10-11
categories: ["ガイドライン"]
publisher: "株式会社一創"
---

# クラウド・バイ・デフォルト原則とは？デジタル庁の現行方針DS-310と2026年改定案の要点

クラウド・バイ・デフォルト原則は、政府情報システムのシステム方式を決めるとき、クラウドサービスの利用を第一候補として検討することを求める政府方針です。所管はデジタル庁で、原則を定めた文書は2022年に抜本改正され、2025年5月27日にも改定されています。多くの解説記事が前提にしている2018年版・2021年版とは、名称も内容も変わりました。ここではデジタル庁が公開する現行文書、[デジタル社会推進標準ガイドライン](https://www.digital.go.jp/resources/standard%5Fguidelines)のDS-310「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」の原文に沿って整理し、2025年9月に示された次期改定案の論点までを扱います。

## まとめ：デジタル庁のクラウド・バイ・デフォルト原則の現在地

- 現行文書はDS-310：「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」。2022年9月30日に初版決定（抜本改定）、直近の改定は2025年5月27日、決定主体はデジタル社会推進会議幹事会。2026年10月時点でデジタル庁の一覧に載る最終改定日も2025年5月27日です。
- 見出しは「クラウド第一原則」：原則自体は現行方針に残っているが、目的は「クラウドに移すこと」から「クラウドを適切（スマート）に使うこと」へ移った。
- Step0〜Step4は現行方針に無い：旧方針の利用検討プロセスは姿を消し、ガバメントクラウドを原則、使わない場合はISMAP等クラウドサービスリストから選ぶ形になった。
- マルチクラウドは避ける側：ハイブリッド構成とあわせ、現行方針が明確に「避けるべき」としている。ロックイン回避のために複数のIaaS/PaaSを併用するという定番の説明は方針の立場ではない。
- 運用まで原則化：2025年改定で3.7「システム運用について」が加わり、利用料の定期確認や夜間バッチの見直しなど11項目が運用費削減の原則になった。
- 次期改定案が公開済み：2025年9月のクラウドTF資料で、SaaS化と生成AIのメリット、公共SaaS、利用終了時のリソース削除を足す案が示されている（決定日は未記載）。
- 自治体は対象外：適用対象は政府情報システム。地方公共団体や独立行政法人等に対しては「参考にされたい」という位置づけで、義務ではない。

以下、名称と定義の変遷、クラウドファーストとの違い、選定の実務、運用原則の実装、そして民間企業が読み替えるときの注意点の順に見ていきます。

## デジタル庁のクラウド・バイ・デフォルト原則の定義とDS-310での位置づけ

### 現行方針DS-310での正式名称は「クラウド第一原則」になった

[DS-310本文（PDF）](https://www.digital.go.jp/assets/contents/node/basic%5Fpage/field%5Fref%5Fresources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/a612d406/20250619%5Fresources%5Fstandard%5Fguidelines%5Fguideline%5F08.pdf)の第2章2.1は「クラウド第一原則（クラウド・バイ・デフォルト原則）」という見出しで、次のように定めています。「政府情報システムは、クラウド第一原則、すなわち、クラウドサービスの利用を第一候補として、その検討を行うものとする。その際、『３ 具体方針』に基づき、単にクラウドを利用するのではなく、クラウドをスマートに利用するよう検討するものとする」。

前段は旧方針とほぼ同文です。変わったのは後段で、旧方針は「３.１クラウドサービスの利用検討プロセス」を参照させて検討手順に落とし込んでいたのに対し、現行方針は「単にクラウドを利用するのではなく」と釘を刺したうえで具体方針全体を参照させています。なお第2章はこの2.1と、アプリケーションのモダン化を求める2.2「モダン技術の利用」の2節だけで構成されており、原則とモダン化が対で置かれた形です。

文書の表紙に並ぶキーワードも入れ替わりました。旧方針は「クラウドサービス、クラウド・バイ・デフォルト、パブリック・クラウド、プライベート・クラウド、IaaS、PaaS、SaaS、政府共通プラットフォーム、ISMAP」の9語でしたが、現行方針は「クラウドサービス、クラウド第一原則、ガバメントクラウド、ISMAP」の4語です。パブリック／プライベートの区別もIaaS/PaaS/SaaSの3層も、政府共通プラットフォームも、表紙からは落ちました。用語の並びそのものが重心の移動を示しています。

DS-310はデジタル庁の標準ガイドライン群の中で「Normative（規範）」に分類されており、政府情報システムの整備・管理で従うべき文書という扱いです。同じ一覧には本文PDFのほか、PDFとWordをまとめた統合版も掲載されています。引用するときは文書番号DS-310と最終改定日をセットで書くと、どの版を指しているかが曖昧になりません。

なお、原則の源流は2017年5月30日に閣議決定された「世界最先端IT国家創造宣言」と一体の、官民データの利用推進に関する基本計画および同日決定の「デジタル・ガバメント推進方針」で、ここでクラウドサービスの利用を第一候補とすることが示されました。これを具体化する文書として2018年6月7日に旧方針の初版が決定されています。デジタル庁の発足（2021年9月）以降は、同庁が事務局を務めるデジタル社会推進会議幹事会が改定を決定しています。

### 適用対象となる政府情報システムと、適用されないシステムの範囲

DS-310の1.2は、デジタル・ガバメント推進標準ガイドラインが適用される政府情報システムの整備・管理を適用対象とします。そのうえで、特定秘密（特定秘密の保護に関する法律 平成25年法律第108号 第3条第1項）および行政文書の管理に関するガイドラインの秘密文書中極秘文書を扱う政府情報システムは、方針の全部が適用対象外です。安全保障や公共の安全・秩序の維持に関わる機微な情報を扱うシステムも、別添を除いて全部が適用対象外とされています。

地方公共団体や独立行政法人等については「ガバメントクラウドの利用を検討する場合には、本方針も参考にされたい」と書かれているだけで、適用対象ではありません。自治体の情報システムを縛るのは地方公共団体情報システムの標準化に関する法律（令和3年法律第40号）に基づく別系統のルールであり、両者を混同すると調達要件を過剰に厳しく設定してしまいます。自治体が使う仕組みや費用負担は[ガバメントクラウドとは？自治体が使う仕組み・対象サービス・費用負担を解説](/column/details/16150/)で別途整理しています。

## 2018年の旧方針から2025年改定までの変遷と決定日の対応表

文書名・決定主体・決定日の対応は次のとおりです。「クラウド・バイ・デフォルト原則」を引用する際は、どちらの文書を指しているかで内容が変わります。

| 決定日           | 文書名                      | 決定主体          | 主な内容                 |
| ------------- | ------------------------ | ------------- | -------------------- |
| 2018年6月7日     | クラウドサービスの利用に係る基本方針（旧・初版） | 各府省CIO連絡会議    | Step0〜Step4の検討プロセス   |
| 2021年3月30日    | 同上（改定）                   | 各府省CIO連絡会議    | ISMAP関連の追加・修正        |
| 2022年9月30日    | 適切な利用に係る基本方針（現行・初版）      | デジタル社会推進会議幹事会 | 抜本改定・クラウドスマート        |
| 2022年12月28日   | 同上（改定）                   | デジタル社会推進会議幹事会 | 機微情報の取扱いの別添          |
| 2023年9月29日    | 同上（改定）                   | デジタル社会推進会議幹事会 | ISMAP-LIU・システム刷新の進め方 |
| 2025年5月27日    | 同上（改定・現行）                | デジタル社会推進会議幹事会 | 間接的なメリット・システム運用      |
| 未定（案は2025年9月） | 同上（次期改定案）                | デジタル社会推進会議幹事会 | SaaS化・生成AI・終了時削除     |

旧方針が「改訂」ではなく「抜本的な改正」と位置づけられている点は、現行方針の1.1に明記されています。旧文書の延長ではなく別文書として読む必要があります。最下段の次期改定案は、決定日が「2026年X月XX日」と空欄のままの案文であり、2026年10月11日時点で決定版としては公開されていません。

### 現行方針に存在しない旧方針のStep0〜Step4と調達仕様での誤り

旧方針で最も引用されてきたのが、表3-1「クラウド・バイ・デフォルト原則に基づく利用検討プロセス」です。Step0で検討準備を行い、Step1でSaaS（パブリック・クラウド）、Step2でSaaS（プライベート・クラウド）、Step3でIaaS/PaaS（パブリック・クラウド）、Step4でIaaS/PaaS（プライベート・クラウド）を順に検討する構造でした。旧方針3.1の本文は、その帰結を「いずれのクラウドサービスもその利用が著しく困難である場合、又はいずれのクラウドサービスの利用メリットがなく、かつ、クラウドサービスによる経費面の優位性も認められない場合のみオンプレミスとする」と定めています。ただし旧方針2.1のなお書きは、技術の進展や新たなクラウドサービスの出現に応じて「各利用検討の内容や順序は、適宜見直しを行うものとする」としており、順序は当初から固定ではありませんでした。

この表は現行方針にありません。旧方針2.2にあった「府省CIO補佐官の関与」も同様です。検索上位の解説記事の多くはいまもStep0〜Step4を図解していますが、それは2021年3月30日版までの方針に記載された内容です。RFPや調達仕様書に「基本方針のStep1に従い」と書くと、現行文書に存在しない条項を参照することになります。現行方針に合わせるなら「DS-310（2025年5月27日改定）3.1に基づき、ガバメントクラウドまたはISMAP等クラウドサービスリスト登録サービスを選定する」のように、文書番号・版・節番号で参照させます。

### 2025年5月27日の改定で新設された1.7と3.7と3.9の追加内容

DS-310巻頭の改定履歴によれば、2025年5月27日の改定で「1.7 クラウド化による間接的なメリット」「3.7 システム運用について」が新設され、3.9に「システム方式（全体アーキテクチャ）の考え方」「刷新時のプロセス（システム計画工程）」と5点の図（図3-1〜図3-5）が追加されました。3.9では閉域網に関する記述と開発規模のスリム化に関する記述が加わり、「広域災害」という語は「リージョン全域にわたる大規模災害」に改められています。3.6のセキュリティ対策も最新化のために修正されました。

新設された3.7の狙いについて、デジタル庁クラウドTFの[2025年9月の改定概要資料（PDF）](https://www.digital.go.jp/assets/contents/node/basic%5Fpage/field%5Fref%5Fresources/fc97ed25-7bbb-4f5c-8ca5-97b344dc36d7/b11b55a1/20250930%5Fpolicies%5Fdevelopment%5Fmanagement%5Foutline%5F01.pdf)は、前回改定の概要として「クラウドに移行しても運用管理についてはオンプレ時代と同様の方式を踏襲し、オンプレ時代と同様の人海戦術的で高コストの運用にとどまっている場合が多いため」と説明しています。DS-310本文の3.7も冒頭で「システムをモダン化して刷新しても、システム運用が従前のままではコスト削減効果は十分に発現しない」と述べ、クラウド利用料の定期確認や夜間バッチの見直しなど11項目を運用費削減の原則として並べました。11項目の中身と実装例は後半の章で扱います。

### 2026年改定案で追加が示されたSaaS・生成AI・終了時削除の論点

デジタル庁クラウドTFは2025年9月付の資料で、次期改定の方向を公開しています。同時に公開された[改定案の文書（PDF）](https://www.digital.go.jp/assets/contents/node/basic%5Fpage/field%5Fref%5Fresources/fc97ed25-7bbb-4f5c-8ca5-97b344dc36d7/6fd4a1b4/20250930%5Fpolicies%5Fdevelopment%5Fmanagement%5Foutline%5F02.pdf)の改定履歴には、決定日が「2026年X月XX日」と空欄のまま、次の追加・修正が並んでいます。

- 1.8「SaaS化によるメリット」と1.9「クラウド利用における生成AIによるメリット」の新設（資料上の表記は「SeeS化」）、1.10「クラウド利用時の留意点」の新設
- 3.1への公共SaaSの追記：ガバメントクラウド（公共SaaSを含む）を原則とする書き方への変更
- 3.2ほかへの最新CRYPTREC「電子政府推奨暗号リスト」の反映
- 3.4への「利用に問題のないマルチクラウド」の明記
- 3.6への「クラウド環境利用終了時のリソースの削除」の追加
- 3.7への海外CSP利用時の為替変動対策の追記
- 3.9への、長期間の改修で複雑化した現行システムへの対策と、画面・帳票の見直しの追記

実務への影響が大きいのは暗号と利用終了時の扱いです。改定概要資料は、電子政府推奨暗号リスト掲載の暗号のうち一定のセキュリティ強度のものは2030年までに、より強度の高い暗号または鍵長への移行の完遂が前提とされている点に留意するよう求め、具体例に2048ビットのRSA暗号と224ビットの楕円曲線暗号を挙げています。利用終了時については、保管データの削除、暗号鍵の破棄による暗号化消去、ユーザーとリソースの削除、契約期間付きサービスの料金発生の確認と解約、操作証跡の保管が列挙された内容です。いずれも案の段階ですが、2027年以降に稼働する政府系システムの要件定義では、決定を待たずに織り込んでおくと手戻りが減ります。

## クラウドファーストとの違い：デジタル庁が示したクラウドスマートへの転換

クラウドファーストとは、システム方式の検討にあたってまずクラウドの利用を検討するという考え方です。クラウド・バイ・デフォルト原則と並べて比較されることが多いのですが、デジタル庁が示した対比軸は別のところにあります。2022年5月24日の[改定説明資料（PDF）](https://www.digital.go.jp/assets/contents/node/basic%5Fpage/field%5Fref%5Fresources/d2a406cb-a8be-472c-8422-eefa6b39a13e/36df3fac/20220524%5Fpolicies%5Fdevelopment%5Fmanagement%5Fpolicy%5Frevision%5F02.pdf)は「旧方針（2018年6月に初版）は、クラウドファースト（先ずはクラウドの利用を検討する）だったが、本方針ではクラウドスマート（クラウドを賢く適切に利用する）を目的とする」と述べており、対比されているのは「クラウドファースト対クラウドスマート」です。クラウド・バイ・デフォルト原則そのものは新方針の「２ 基本方針」にも残っており、別の概念に置き換えられたわけではありません。

この転換の理由は現行方針の1.1に書かれています。旧方針に基づいて多くの政府情報システムがクラウドに移行したものの、「クラウドへの移行そのものが目的化されてしまい、必ずしもクラウドサービスの利用メリットを十分に享受できていないといった例も散見された」ためです。オンプレミスのサーバー群を「雲の向こうにある仮想サーバー群」に置き換えただけの移行では、サーバー構築費も運用の人件費も残ります。

したがって、クラウドファーストのメリットを問う場面では移行先での使い方まで含めて答える必要があります。仮想サーバーを立ててソフトウェアを入れる従来型の使い方をクラウド上で続ければ、現行方針が想定するコスト削減効果は得られません。2025年9月の改定概要資料も「スマートとはモダン技術の利用であり『マネージドサービス』と『IaC (Infrastructure as Code)』が中心」と要約しており、この2つが「スマート」の中身です。IaCの仕組みそのものは[IaCとは？Infrastructure as Codeの仕組み・メリットと導入判断を解説](/column/details/13004/)で整理しています。

| 観点    | クラウドファースト（旧方針） | クラウドスマート（現行）  |
| ----- | -------------- | ------------- |
| 目的    | まずクラウドを検討する    | 利用メリットを十分に得る  |
| 検討手順  | Step0〜Step4の順序 | ガバメントクラウド原則   |
| 構成の中心 | 仮想サーバーへの置換     | マネージドサービスとIaC |
| 運用    | 規定なし           | 3.7の11項目で原則化  |

## クラウドサービスの選び方：ガバメントクラウドとISMAP等リストの順番

現行方針3.1は選定順を次のように定めます。クラウドサービスの利用は[ガバメントクラウド](https://www.digital.go.jp/policies/gov%5Fcloud)を原則とし、ガバメントクラウドを利用しない場合は、セキュリティの観点からISMAPクラウドサービスリストまたはISMAP-LIUクラウドサービスリスト（あわせて「ISMAP等クラウドサービスリスト」）に登録されたものを原則として選定する決まりです。ISMAPの運用は「政府情報システムのためのセキュリティ評価制度（ISMAP）の利用について」（令和2年6月30日 サイバーセキュリティ対策推進会議・各府省情報化統括責任者（CIO）連絡会議決定）に従うこととされています。[ガバメントクラウドの対応ベンダー5社と選定基準｜認定要件と国産クラウドの位置づけ](/column/details/16643/)で、実際に採択されている事業者側の条件を確認できます。データ主権や運用主体の観点でガバメントクラウドと国産クラウドを比べたい場合は[ソブリンクラウドとガバメントクラウドの違い｜データ主権・法域・運用主体で分ける選定基準](/tech/details/16789/)が対になる記事です。

### ISMAPとISMAP-LIUの使い分けとアカウント数課金SaaSの注意点

ISMAP-LIU（ISMAP for Low-Impact Use）は、ISMAPのうちリスクの小さな業務・情報の処理に用いるSaaSを対象とした仕組みです。評価・登録の仕組みがISMAP本体とは異なるため、リストも別に公開されます。登録済みサービスの一覧は[ISMAPポータル](https://www.ismap.go.jp/csm)で確認でき、制度の管理基準や費用は[ISMAPとは？クラウドサービスリスト・管理基準・費用を2026年時点で解説](/column/details/17439/)にまとめています。用語表に加わったのは2023年9月29日の改定でした。SaaSについて方針は「開発量削減の観点から幅広く優先的に、その利用を検討すること」と踏み込んでいます。同時に、アカウント数課金のSaaSでは利用アカウント数の増大で運用等経費が膨らむため、アカウント数の推移想定に注意するよう求めている点も見落とせません。SaaS・PaaS・IaaSの区分そのものを確認したい場合は[SaaS（サース）とは？読み方・意味とPaaS・IaaSの違いを公的資料で整理](/column/details/5276/)が参考になります。

### ISMAP等リストに未登録のクラウドサービスを採用する場合の確認

ISMAP等クラウドサービスリストに未登録のサービスを使う場合は、「政府情報システムのためのセキュリティ評価制度（ISMAP）の暫定措置の見直しについて」（令和3年7月6日 サイバーセキュリティ対策推進会議・各府省情報化統括責任者（CIO）連絡会議決定）に基づき、調達を行う政府機関等の最高情報セキュリティ責任者の責任で要求事項と管理基準の充足を確認します。加えて、方針4.1が挙げる認証・監査フレームワークの取得状況も検討対象です。認証制度としてISO/IEC 27017による認証取得、JASAクラウドセキュリティ推進協議会のCSゴールドマーク、米国FedRAMPの3つ、監査フレームワークとして日本公認会計士協会の保証業務実務指針3850とAICPAのSOC2/SOC3が明示されています。このうちISO/IEC 27017の要件は[ISMSクラウドセキュリティ認証とは｜ISO/IEC 27017の取得要件と2026年改訂動向](/column/details/12664/)で詳しく扱っています。

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

### データセンタの所在地と国外法令への対応で求められる暗号化と鍵管理

方針3.2は、データセンタの設置場所について「国内であることを基本とする」と定めます。可用性や災害対策の観点から冗長化・バックアップ用のデータセンタを海外に置くことが望ましい場合は、準拠法と国際裁判管轄を確認し、具体的な争訟リスクが低いことを確認したうえで契約に利用者データの保護を担保させます。国外に保管する可能性がある場合の対策は2つです。漏えいリスクが明らかな利用者データは最新の[CRYPTREC暗号リスト（電子政府推奨暗号リスト）](https://www.cryptrec.go.jp/list.html)掲載の暗号または同等の暗号で暗号化し、機密性に応じてBYOK等の利用者主体の鍵管理を行うこと。外国法令によるデータの域内保存義務で可用性リスクが予見される場合は、その法令の効力が及ばない国にバックアップを保持することです。

## 政府が挙げるクラウド利用のメリットと直接・間接の効果を捉える3層の区分

現行方針はメリットを3層に分けて記述しています。1.5が旧方針から引き継いだもの、1.6がスマートな利用によって上乗せされるもの、1.7が2025年改定で加わった間接的なものです。

| 区分               | 項目                   |
| ---------------- | -------------------- |
| 1.5 当初からの利用メリット  | 効率性／セキュリティ水準／技術革新対応力 |
| 1.5 同上           | 柔軟性／可用性の向上           |
| 1.6 スマートな利用のメリット | マネージドサービスによるコスト削減    |
| 1.6 同上           | サーバー非構築でのセキュリティ対策費削減 |
| 1.6 同上           | IaCとテンプレートによる構築自動化   |
| 1.7 間接的なメリット     | システム化領域の拡大           |
| 1.7 同上           | 事業者・社会全体の競争力強化       |

金額面で最も具体的なのは1.6の1項目めです。旧世代のクラウド利用では仮想サーバーのクラウド利用料、ソフトウェアのライセンス・保守費用、運用管理の人件費が発生していたのに対し、マネージドサービスを組み合わせる構成では費用がクラウド利用料のみとなり、「その金額は多くの場合、旧世代の数分の１といわれている」と書かれています。従量課金であれば処理量の少ない週末や検証環境ではコストがそのぶん下がる、という説明も添えられています。

セキュリティについても、責任の所在が変わることが利点として整理されています。自らサーバーを構築・運用すると、侵入監視、脆弱性対応、OSのセキュリティ設定管理を自らの責任で行う必要がありますが、マネージドサービスの機能を利用するだけであればこれらは基本的に不要になります。ただし方針が想定するマネージドサービスはISMAPへの登録等で安全性が評価されたものである、という前提付きの説明です。具体策は3.6に、責任共有モデルによる対象の絞り込みからインシデント対応と自動化まで11項目が示されています。

## 現行方針が「避けるべき」と名指しするマルチクラウドと閉域網の構成

クラウド構成の解説記事で推奨されがちな設計のうち、現行方針が明確に否定しているものがあります。政府案件で要件を書く立場なら、ここは反対向きに覚え直す必要があります。

### 方針が避けるよう求めるマルチクラウドとハイブリッド構成の条件

方針3.4は、ひとつの情報システムを複数のクラウドサービス（IaaS/PaaS）上で構成するマルチクラウドについて「構成を複雑にして費用が増大する傾向にあることから避けるべきである」と述べます。避けるべきなのは1システム内での複数IaaS/PaaS併用であり、組織として個々のシステムが別々のCSPを使うことや、SaaS等を特定機能に絞って併用することは問題ないと明記されています。次期改定案でも、3.4に「利用に問題のないマルチクラウド」を明記する修正が予定されている段階です。

ベンダーロックインの扱いも一般的な解説とは異なります。方針3.3は、データの移行性が担保され、合理的な価格体系が公開され、導入プロセスも含めて透明性が担保されている条件を満たすサービスを選ぶことでロックインを回避せよ、としています。そのうえで3.4は「透明性が担保されていればベンダーロックインには該当しない」と述べ、ロックイン懸念を理由に複数のIaaS/PaaSを積極利用する考え方を退けました。技術的・経済的な合理性のないマルチクラウドは「厳に避ける必要がある」というのが結論です。クラウドとオンプレミスを組み合わせる形態も、移行期・多重バックアップ・ネットワーク遅延が許容できない場合を除いて避けるよう求めています。[プライベートクラウドとは？違い・構築技術からOpenStackでの払い出し手順まで実装者向けに解説](/tech/details/13431/)で構築方式ごとの前提を押さえたうえで、この制約に照らして判断するのが安全です。

### 政府情報システムの刷新時に閉域網に閉じた運用と二段階移行を避ける原則

方針3.9は「インターネットへのセキュアな接続を前提とすること」を刷新時の基本的な考え方に挙げ、閉域網に閉じた運用を「適切なセキュリティ対策がとられていない業務システムのみが必要としている」と位置づけます。理由も具体的で、閉域網は外部連携とSaaS利用を大きく阻害し、外字に対応した閉域網内では文字化けが顕在化しないため外字を多用するシステムや高コストな旧来型システムの温存を助長する、と述べています。

移行の回数についても明確です。刷新は1回での移行（Rebuild）と全面的なモダン化を原則とし、二段階移行は「可能な限り避けること」とされています。やむを得ず二段階にする場合の第一段階は暫定対処（Replatform）と位置づけられ、第二段階を計画したうえで実施するという条件です。ただし大規模で難易度の高いシステムは、リスク分散と予算平準化のためサブシステム単位に分割して順次刷新し、一括刷新を避けます。分割後の各刷新はそれぞれ1回で行う、という条件が付きます。

## DS-310の3.7「システム運用について」の11項目をIaCで実装する手順

2025年改定で加わった3.7は、方針の中で最も実装に近い章です。項目は次の11個で、DS-310本文では「運用に係る費用の削減を行うことを原則とする」と書かれています。

| 番号  | 3.7の項目（要約）        | 実装の例            |
| --- | ----------------- | --------------- |
| 1)  | 利用料を定期的に確認する      | 予算アラートの設定       |
| 2)  | 稼働していないリソースの課金抑制  | 夜間・休日の自動停止      |
| 3)  | ピーク想定の大きなリソースを避ける | オートスケール         |
| 4)  | IaCによるインフラ作業の効率化  | Terraform等で構成管理 |
| 5)  | 運用作業の自動化を徹底する     | バックアップ・初期対応の自動化 |
| 6)  | 監視対象を見直す          | アプリ・サービス監視へ     |
| 7)  | 運用報告を見直す          | 月次報告書からダッシュボードへ |
| 8)  | 常駐運用からリモート運用へ     | 遠隔運用を原則化        |
| 9)  | 夜間バッチの必要性を見直す     | 日中の逐次処理へ        |
| 10) | アップデート時の確認テスト見直し  | テスト自動化と事後対応     |
| 11) | 運用作業を定期的に見直す      | 作業時間の分析と自動化     |

5)の本文には「自動で実行可能な単純作業を事業者が人件費を用いて実施しないよう、特に留意が必要となる」とあり、発注側にとっては運用保守の見積りを査定する根拠になります。受注側にとっては、手作業前提の運用体制で提案すると方針と食い違う、という意味です。

### クラウド利用料の定期確認をTerraformとAWS Budgetsで設定する

1)の「利用料を定期的に確認する」と4)の「IaC」を同時に満たす最小構成として、Terraformで月次予算と通知を定義する例を示します。予算の超過見込みを検知する仕組みには[AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html)を使い、リソース定義は[Terraform Registryのaws\_budgets\_budget](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/budgets%5Fbudget)の引数に従っています。リージョンを東京にしているのは3.2の「国内であることを基本とする」に合わせるためです。

```
# main.tf（AWSプロバイダ6系を想定・2026年10月時点）
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

# DS-310 3.2：データセンタは国内を基本とする
provider "aws" {
  region = "ap-northeast-1"
}

# 通知先のSNSトピック
resource "aws_sns_topic" "budget" {
  name = "monthly-budget-alert"
}

# AWS BudgetsからSNSへの発行を許可する
resource "aws_sns_topic_policy" "budget" {
  arn = aws_sns_topic.budget.arn
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "budgets.amazonaws.com" }
      Action    = "SNS:Publish"
      Resource  = aws_sns_topic.budget.arn
    }]
  })
}

# DS-310 3.7 1)：クラウド利用料を定期的に確認する
resource "aws_budgets_budget" "monthly" {
  name         = "monthly-cost"
  budget_type  = "COST"
  limit_amount = "2000"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  # 月末時点の予測が予算の80%を超えたら通知
  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 80
    threshold_type            = "PERCENTAGE"
    notification_type         = "FORECASTED"
    subscriber_sns_topic_arns = [aws_sns_topic.budget.arn]
  }

  # 実績が予算を超えたら通知
  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 100
    threshold_type            = "PERCENTAGE"
    notification_type         = "ACTUAL"
    subscriber_sns_topic_arns = [aws_sns_topic.budget.arn]
  }
}
```

適用は次のコマンドで行います。planの差分を確認してからapplyする流れにしておくと、予算額の変更もコードレビューを通せます。

```
terraform init
terraform plan -out=budget.tfplan
terraform apply budget.tfplan
```

金額の2000（USD）は例示で、実際にはシステムの見積額から決めます。通知先のSNSトピックにはメールやチャットの購読を後から追加します。認証情報の扱いやstateの置き場所まで含めた構築手順は[TerraformでAWSを構築する手順｜aws 6系の認証とS3バックエンド設計](/tech/details/1900/)を参照してください。ガバメントクラウドではアカウントの払い出しや権限の範囲がデジタル庁側の設計で決まるため、上の例をそのまま適用できるとは限りません。考え方の参考として読み替えてください。

### 夜間停止・オートスケール・リモート運用など残る10項目の読み方

2)は休日や夜間など利用しない時間帯にサーバーを止めるよう求め、CSPが提供する自動起動・停止機能の利用を挙げています。3)はピーク時に備えて大きなリソースを常時確保するのではなく、オートスケールで必要な量だけを使うこと、オートスケールが使えない場合は手動で調整することを求めます。6)と7)は監視と報告の考え方を改めるもので、インフラの死活よりアプリケーションやサービスが正常に動いているかを監視し、月次の運用報告書はリアルタイムのダッシュボードに置き換える方向です。

9)の夜間バッチは、法令で基準日が決まっている事務や大量データの一括処理であっても「可能な限り日中の処理を計画し」、複雑なジョブネットを最小化するよう求めています。10)はマネージドサービスの更新に対して、影響の可能性が低い場合は大規模な事前テストより、更新後に問題が起きたときすぐ対応できる体制を優先する考え方です。どちらも、オンプレミス時代の運用設計書をそのまま移すと方針から外れる項目です。

3.7の直後に置かれた3.8「公文書管理との関係への留意」も見落とされがちです。クラウドで管理されている文書も公文書等の管理に関する法律第2条第4項の要件を満たせば行政文書となり得るため、システムの開発や運用に際して「業務システムと公文書管理のルールについて」（令和4年2月16日 内閣府大臣官房公文書管理課長通知）等に留意するよう求めています。データの保存期間や削除の設計は、運用自動化と公文書管理の両方から決める必要があります。

## 民間企業が流用できる規定と過剰になる規定を調達仕様の観点で分ける

DS-310は政府情報システム向けの文書ですが、民間の調達基準として流用できる部分とできない部分があります。流用しやすいのは選定の考え方です。ISMAP等クラウドサービスリストは公開されており、自社に独自の評価基準がない場合の一次スクリーニングとして使えます。4.1に挙がるISO/IEC 27017やSOC2は民間でも一般的な確認材料です。

一方で、そのまま持ち込むと過剰になるのが3.2のデータ所在地要件です。国内配置を基本とする規定は、政府情報システムが扱う情報の性質と国外法令の適用リスクを前提にしています。同じ基準を一般企業の業務システムに課すと、選べるサービスが不必要に狭まります。判断すべきは「国内かどうか」ではなく、扱うデータの機密性と準拠法・国際裁判管轄の確認可否です。

逆に、民間でも積極的に取り入れる価値があるのが3.9の「開発規模のスリム化」です。画面の削減、法定帳票以外の内部帳票の削減、バッチの削減、不要な例外処理の削減、フルスクラッチ開発の削減、そして非機能要件（大量処理、高信頼、セキュリティ）へのフルスクラッチではなくインフラでの対応、という6つの観点が挙げられています。現行システムの規模を前提に見積りを取ると「非常に高額な見積りとなり刷新計画自体が頓挫してしまう」という指摘は、政府に限った話ではありません。3.7の運用11項目も、運用保守費を下げたい民間システムにそのまま当てはまります。オンプレミスとの比較から詰めたい場合は[オンプレミスとクラウドの違いとは？コスト・セキュリティ・拡張性で比較し選び方まで解説](/column/details/13425/)を、移行検討で実際につまずく箇所は[クラウド移行の課題と失敗パターン｜コスト増・セキュリティ・人材不足を移行前に潰す判断軸](/column/details/16389/)を参照してください。

流用の可否を判断する目安を、条件付きでまとめます。

- 採用してよい：ISMAP等リストを一次スクリーニングに使う、1システム内のIaaS/PaaS併用を避ける、IaCとマネージドサービスを前提にする、3.7の運用項目で保守契約を見直す、3.9のスリム化観点で要件を削る
- 条件付きで採用：国内データセンタ要件は、個人情報や機密情報を扱い、かつ国外法令の適用リスクを説明できない場合に限る
- 見送る場面：特定秘密や安全保障に関わる別添の取扱い、府省内の決裁手続を前提にした規定は、民間に持ち込んでも対応する主体がいない

政府系案件の受注や、政府方針に沿ったクラウド構成を自社システムに取り入れたい場合は、方針の読み替えから構成設計・IaC化までまとめて相談できます。一創の[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)では、マネージドサービス中心の構成設計とTerraformによる環境のコード化に対応しています。

## よくある質問

### デジタル庁のクラウド・バイ・デフォルト原則はいつから始まり、最新版はどれですか？

原則自体は2017年5月30日閣議決定の「世界最先端IT国家創造宣言」と一体の、官民データの利用推進に関する基本計画等で示され、具体化した「政府情報システムにおけるクラウドサービスの利用に係る基本方針」の初版が2018年6月7日に決定されました。現行の文書はデジタル庁の標準ガイドライン群にあるDS-310で、2022年9月30日に初版決定、直近の改定は2025年5月27日です。2025年9月には次期改定案が公開されていますが、2026年10月11日時点で決定日は空欄のままです。

### クラウドバイデフォルトの目的とメリットは何ですか？

現行方針の目的は、クラウドへの移行それ自体ではなく、クラウドの利用メリットを十分に得ることで、狙いは主としてコスト削減とセキュリティの向上です。メリットとして挙げられるのは、効率性・セキュリティ水準・技術革新対応力・柔軟性・可用性の向上という5点に、マネージドサービスによるコスト削減、サーバーを構築しない構成でのセキュリティ対策コスト削減、IaCによる環境構築自動化の3点を加えたものです。2025年改定では、削減したコストで新たな領域をシステム化できること、モダン技術の普及が社会全体のIT競争力向上につながる可能性があることが、間接的なメリットとして追加されました。

### クラウドファーストとクラウドスマートは何が違いますか？

クラウドファーストはまずクラウドの利用を検討するという方針で、旧方針の姿勢にあたります。クラウドスマートは移行後の使い方まで踏み込み、マネージドサービスとIaCを軸に組むことでコスト削減とセキュリティ向上を実現しようとする考え方で、2022年の抜本改正で目的に据えられました。クラウドファーストのメリットとして語られるコスト削減は、後者の使い方を伴わなければ実現しない、というのが現行方針の立場です。

### クラウドの欠点や、方針が注意を促している点は何ですか？

方針の文面から読み取れる注意点は、構成を複雑にする使い方をした場合にコストが増えることです。3.4はマルチクラウドを費用増大の要因として避けるべきとし、クラウドとオンプレミスの組合せもシステムの複雑化と高コスト化の要因になると指摘しています。3.1はアカウント数課金のSaaSで利用アカウント数の増大が運用等経費を押し上げる点に注意を促し、3.7は運用をオンプレミス時代のまま続けるとコスト削減効果が出ないと述べています。

### クラウド・バイ・デフォルト原則は地方自治体にも適用されますか？

適用対象は政府情報システムです。地方公共団体や独立行政法人等については、ガバメントクラウドの利用を検討する場合に「本方針も参考にされたい」と記されているにとどまり、適用対象ではありません。自治体システムの標準化やガバメントクラウドへの移行は、地方公共団体情報システムの標準化に関する法律に基づく別系統のルールで進んでいます。

## 関連記事

- [ガバメントクラウドとは？自治体が使う仕組み・対象サービス・費用負担を解説](/column/details/16150/)
- [ガバメントクラウドの対応ベンダー5社と選定基準｜認定要件と国産クラウドの位置づけ](/column/details/16643/)
- [ISMAPとは？クラウドサービスリスト・管理基準・費用を2026年時点で解説](/column/details/17439/)
- [ISMSクラウドセキュリティ認証とは｜ISO/IEC 27017の取得要件と2026年改訂動向](/column/details/12664/)
- [オンプレミスとクラウドの違いとは？コスト・セキュリティ・拡張性で比較し選び方まで解説](/column/details/13425/)
- [クラウド移行の課題と失敗パターン｜コスト増・セキュリティ・人材不足を移行前に潰す判断軸](/column/details/16389/)

---

出典: [クラウド・バイ・デフォルト原則とは？デジタル庁の現行方針DS-310と2026年改定案の要点](<https://www.issoh.co.jp/column/details/9362/>)（株式会社一創）