ガバメントクラウドのR1・R2・R3とは？「この構成はR2なのか」という疑問から整理する
ガバメントクラウドへの移行を検討すると、必ず「R1」「R2」「R3」という言葉に出会います。
デジタル庁が定義している移行パターンの略号で、定義そのものは数行で説明できます。しかし実際の案件でこの言葉を使おうとすると、思ったほど簡単ではありません。
本連載のきっかけも、まさにそこでした。
ある行政系システムのガバメントクラウド移行案件で構成検討と概算見積を進める中、CSP側から「R2基本形」としてリファレンスアーキテクチャの提示を受けました。ところが実システムの要件を当てはめていくと、次の疑問が出てきました。
- そもそも今回の移行は、R1とR2のどちらとして整理すべきなのか
- R2とは、どこまで満たせばR2と言えるのか
リファレンス構成に「R2」と書いてあるからといって、それを使って組んだ構成が自動的にR2になるわけではありません。
そこで本連載では、まずR1・R2・R3の違いを整理し、そのうえで「R2として構成するなら何が必要か」「さくらのクラウドでそれを実現できるか」を、実際の設計検討をもとに全6回で検証していきます。
第1回となる今回は、言葉の定義を確認したうえで、実際の構成を定義に照らすと何が起きるのかを見ていきます。
R1・R2・R3とは何か
R1・R2・R3は、デジタル庁がガバメントクラウドへの移行パターンとして定義している3分類です。それぞれReplatform、Rebuild、Repurchaseの頭文字を取っています。
R2：Rebuild（アプリ再構築移行）
システム全体をクラウド前提で再設計する移行パターンです。個別にアプリケーションを開発する場合、原則としてこのR2を目指すことになります。
ここで重要なのは、R2が「クラウド向けに作り直す」という漠然とした話ではなく、モダン化の定義として具体的な項目に分解されている点です。GCASガイドでは、R2に対して次の1〜5すべてを求めています。
- APIベースのシステム構成 — RESTful API等を用いた疎結合なシステム連携により、組織横断的なデータ連携を促進すること。非同期処理、API定義の公開、データ管理責任範囲の明確化、フロントエンドとバックエンドの分離などが含まれます。
- ステートレスなアーキテクチャ — 状態を保持しないことで、どのサーバーでも同じ結果を返し、可用性向上とコスト削減を実現すること。コンテナの最適化（ステートレス化、イミュータブル化）とオートスケールの活用も含まれます。
- モダンな運用 — IaCによるインフラ管理、定型作業の自動化、本番環境へのログインおよび手作業の禁止、適切なデプロイ戦略の選択、障害対応の自動化・リモート化を進めること。
- サービスレベルの定義・計測 — KPIとサービスレベルを定義・計測し、継続的な振り返りと改善を行うこと。
- マネージドサービスの活用 — 監視、ログ管理、バックアップ、セキュリティ、データベース、オブジェクトストレージ化のマネージドサービスを活用すること。
R1：Replatform（アプリ一部変更移行）
既存アプリケーションを大きく作り直さず、クラウドへ適応させながら移行する考え方です。
R1に対しては、上記のうち「5. マネージドサービスの活用」を原則として求める位置付けになっています。逆に言えば、API化・ステートレス化・運用のコード化・サービスレベル計測までは必須としていません。
ただしR1はゴールではありません。デジタル庁はReplatformをRebuildへ移行するうえでの一時的な状態と定義しており、R1で移行したシステムも将来的にはRebuildの構成へ再度移行することが求められています。
R3：Repurchase（SaaS利用移行）
既存システムを自分たちで再構築するのではなく、SaaS等の既製サービスへ置き換える方式です。移行対象のシステムがSaaSを利用可能な場合、Rebuildのパターンで移行した場合との総コストを比較したうえで採用可能とされています。
3つは「成熟度の順番」ではない
R1→R2→R3と番号が進むほど高度、という関係ではありません。
- 既存システムを活かしながら移行する → R1
- 独自システムとしてクラウド前提で作り直す → R2
- SaaSで代替する → R3
という、移行戦略の違いです。R1がR2への通過点として位置づけられているのは事実ですが、R3はR2の上位互換ではなく、そもそも自前で作らないという別の選択肢です。
実際の構成を定義に照らすと何が起きるか
ここからが本題です。
今回の案件で検討している構成を、レイヤーごとに整理すると次のようになります。
| レイヤー | 検討中の構成 |
|---|---|
| アプリケーション基盤 | クラウドサービス化 |
| データベース | VM上のPostgreSQL |
| 共有ファイル | NFS |
| バックアップ | オブジェクトストレージ |
| 監視等 | マネージドサービス |
| 構成管理 | Terraform等によるIaC |
| 外部接続 | GSS／LGWAN等の閉域接続 |
さらにデータベースについては、更新頻度の異なるデータを分けて考え、日常的に更新される系統はPrimary／StandbyをOSSでHA制御する構成、参照中心の系統は読み取り専用インスタンスを複数配置する構成を、それぞれ自前で設計しています。
これをモダン化の定義に照らすと、いくつか引っかかります。
データベースがマネージドサービスではない。 「5. マネージドサービスの活用」はデータベースを明示的に含んでいます。今回はデータ容量等の条件からマネージドDBが適合せず、VM上にPostgreSQLを構築してHA化する方式を検討しています。
共有ファイルにNFSを使っている。 デジタル庁はモダン化の定義の中で、アプリケーションサーバから使用する共有ストレージやファイルサーバについて、NFSファイルサーバをそのままクラウドサービスに置き換えると一般的に高価かつ密結合になるとし、オブジェクトストレージに置き換えてAPIベースで連携することを求めています。今回はアプリケーションのアクセス方式の都合でNFSが必要になっており、この方針とは逆を向いています。
つまり、少なくともインフラ構成だけを見て「これはR2です」と言うことはできません。現時点ではR1（Replatform）寄りの構成と見る方が自然です。
ただし、インフラだけでは判定できない
一点、留保が必要です。
R1／R2はデータベース単体ではなく、アプリケーションを含むシステム全体の移行方式で判断されます。アプリケーション開発側が、APIベース、ステートレス、コンテナ／サーバレス、CI/CDとIaC、SLO計測まで含めて全面的に再構築するのであれば、「DBにVMが残ったから即R1」とも言い切れません。
正確に言えるのは、いま手元にある情報だけでは今回の移行をR2として整理する根拠がない、ということです。
そして、CSPから受け取った資料が「R2基本形」と題されていたことが、この混同の一因でもありました。あれはCSPが提示したR2のリファレンス構成であって、それを使う案件がR2になるという意味ではありません。資料自身にも、特定システム用の確定構成ではなく汎用的なモデルであり、実際の要件に応じてリソース・個数・容量を選定する必要があると明記されています。
リファレンス構成は、受け取った時点ではきれいに見える
提示されたR2基本形は、VM中心ではなく、多数のクラウドサービスを組み合わせてシステムを構成する考え方になっていました。コンテナ実行基盤、マネージドDB、オブジェクトストレージ、CDN／WAF、ロードバランサ、共有ファイルサービス、DNS、監視、メッセージング、KMS、シークレット管理、IaC、閉域接続まで、R2の要件を満たすための部品はひととおり揃っています。
一覧として見ると、非常にきれいに見えます。
しかし実際の要件を当てはめていくと、そのままでは成立しない箇所が複数出てきました。
実際に設計して見えた論点
R2をWebで調べると、「コンテナを使う」「マネージドDBを使う」「オブジェクトストレージを使う」「IaCを使う」といった説明が並びます。いずれも間違いではありませんが、実際の設計ではそれだけでは足りませんでした。
1. マネージドDBがそのまま使えないケースがある
CSPが用意するリファレンス構成には、当然のようにマネージドDBが含まれています。しかし実システムでは、必要なDBエンジン、データ容量、性能、バックアップ、冗長化といった条件によって、マネージドDBが適合しないケースが出てきます。
今回もこれが発生しました。ここが、移行方式の整理に迷った最初のきっかけでもあります。
2. 「DBを2台置く」だけではHAにならない
マネージドDBが使えないとなると、冗長化を自分で設計することになります。
必要になるのは、Primary／Standbyの配置だけではありません。レプリケーション方式、障害検知、StandbyのPrimary昇格、Split Brainの防止、アプリケーションから見た接続先の扱い、DB Proxy、クォーラムまで含めて考える必要があります。
「DBを2台作りました」では、高可用性設計は完成しません。サービスの配置ではなく、障害時にシステムがどう動くかまで設計対象になります。
3. データの性質によって冗長化方式を変える必要がある
データをすべて同じDBとして一律に扱うのではなく、日常的に更新されるデータと、過去データとして参照されるがほぼ更新されないデータに分けて考えました。
更新されるデータにはリアルタイムの冗長化が必要です。一方で、ほとんど更新されない巨大なデータまで同じレプリケーション構成に載せると、ストレージ・バックアップ・運用のコストが大きく膨らみます。
そのため、更新頻度や利用方法に応じて、Active系とArchive系で異なるHA・バックアップ方式を採る構成を検討しました。
4. ストレージは「どうアクセスされるか」で選ぶことになる
前述のとおり、モダン化の定義は共有ストレージのオブジェクトストレージ化を求めています。それでもアプリケーションのアクセス方式によっては、共有ファイルシステムが必要になります。
今回も、DB、共有ファイル、バックアップでストレージサービスを分けて考えることになりました。ここは定義と実装が正面からぶつかる箇所で、R2として整理しづらい理由の一つでもあります。
5. マルチゾーンとマルチリージョンを区別する必要がある
リファレンス構成には複数ゾーンが使われています。しかし設計を進めると、マルチゾーンで十分なのか、マルチリージョンまで必要なのかを明確に分けて判断する必要が出てきます。
マルチゾーンはゾーン障害への対策、マルチリージョンはさらに広域な障害への対策です。ガバメントクラウドだから自動的にすべてマルチリージョンにする、という話ではありません。RTO・RPO、コスト、システムの重要度から決めることになります。
6. ネットワークがアーキテクチャを決める
アプリケーションやDBと同じくらい大きな論点になったのがネットワークでした。
行政システムでは、インターネットだけでなく、政府系の閉域網やLGWANからアクセスするケースがあります。これらを同一のクラウド上のシステムへどう収容するかを考えることになります。
さらに、CSP側に目的の閉域接続サービスが存在するかどうかで、構成そのものが変わります。今回も、サービス提供状況を確認したことで、理想の構成と実際に構築可能な構成の間に差があることが分かりました。
「R2を選びます」から本当の設計が始まる
R1・R2・R3の定義だけなら、数行で終わります。
しかし実際の移行では、定義を読んだうえで自分の構成を当てはめた瞬間に、「これはどちらなのか」「どこまで満たせばR2なのか」という問いが立ち上がります。
そして構成を具体化していくと、次の問題が順に出てきます。
- リファレンス構成がそのまま使えない
- マネージドサービスに収まらない要件がある
- DBのHAを自分で設計する必要がある
- データ特性によって冗長化方式を変える必要がある
- ストレージも用途によって使い分ける必要がある
- マルチゾーン／マルチリージョンを選択する必要がある
- 閉域接続サービスの有無が全体構成へ影響する
では、これらを踏まえたうえで、R2として成立させるにはどのようなコンポーネントが必要になるのか。
次回は、実際の検討内容を一般化しながら、「R2要件を満たすアーキテクチャは何か」を構成図レベルで整理します。
本連載の構成（全6回）
- ガバメントクラウドのR1・R2・R3とは？（本記事）
- R2要件を満たすアーキテクチャは何か？
- さくらのクラウドでR2構成を実現できるか？
- R2構成でネックになるサービスと代替案
- GSS接続のネットワーク設計
- LGWAN／LGCS接続のネットワーク設計
なお、さくらのクラウドは2026年3月27日に全技術要件305項目への適合が確認され、ガバメントクラウドの対象クラウドサービスとして正式に採択されています。国産クラウドとしては唯一の採択で、AWS、Google Cloud、Microsoft Azure、OCIに続く5番目です。選択肢として現実的になったからこそ、「実際に組めるのか」を確認する必要があります。
よくある質問
Q. R1とR2の一番大きな違いは何ですか。
A. R2（Rebuild）はモダン化の定義1〜5、すなわちAPIベースのシステム構成、ステートレスなアーキテクチャ、モダンな運用、サービスレベルの定義・計測、マネージドサービスの活用のすべてを求めます。これに対しR1（Replatform）は、このうち「5. マネージドサービスの活用」を原則として求める位置付けです。
Q. VM上にデータベースを構築したら、それだけでR2ではなくなりますか。
A. R1／R2はデータベース単体ではなく、アプリケーションを含むシステム全体の移行方式で判断されます。ただし「5. マネージドサービスの活用」はデータベースを明示的に含んでいるため、VM上にDBを構築する場合はその判断根拠を説明できるようにしておく必要があります。
Q. 共有ファイルにNFSを使うことは問題になりますか。
A. デジタル庁はモダン化の定義の中で、共有ストレージやファイルサーバをNFSのままクラウドへ置き換えると高価かつ密結合になるとし、オブジェクトストレージへの置き換えとAPIベースの連携を求めています。NFSを採用する場合、モダン化の方向性とは異なる選択になります。
Q. R1のまま運用を続けることはできますか。
A. デジタル庁はReplatformをRebuildへ移行するうえでの一時的な状態と定義しており、R1で移行したシステムも将来的にはRebuildの構成へ再度移行することが求められています。R1は終着点ではなく通過点という位置づけです。
Q. CSPから提示された「R2基本形」を使えば、その構成はR2になりますか。
A. なりません。リファレンス構成は特定システム用の確定構成ではなく汎用的なモデルであり、実際の要件に応じてリソースや容量を選定する必要があると資料自身に明記されています。実要件を当てはめた結果としてマネージドサービスから外れる箇所が出れば、その構成はR2の定義を満たさない可能性があります。
参考
- デジタル庁 GCASガイド「ガバメントクラウド概要解説」 https://guide.gcas.cloud.go.jp/general/overview-explanation/
- デジタル庁 GCASガイド「ガバメントクラウドにおけるモダン化の定義」 https://guide.gcas.cloud.go.jp/modernization-guide/modernization-definition
- デジタル庁 note「ガバメントクラウドにおけるモダン化の意味と定義」 https://digital-gov.note.jp/n/n3640f6b7a009
- デジタル庁「ガバメントクラウド」 https://www.digital.go.jp/policies/gov_cloud
※本記事は、公開情報および実際のアーキテクチャ検討の経験をもとに、実務上の論点を整理したものです。ガバメントクラウドに関する個別要件や対応可否については、案件ごとに確認が必要です。