ガバメントクラウドのR2要件とは？5つのモダン化要件から設計する

前回は、ガバメントクラウドにおけるR1・R2・R3の違いを整理しました。その中で、CSPから提示された「R2基本形」のリファレンスアーキテクチャを使えば自動的にR2になるわけではない、という話をしています。

では、逆に考えます。ガバメントクラウドのR2要件を満たすアーキテクチャとは、具体的に何を作ればよいのでしょうか。

この記事では、実際にある行政系システムのガバメントクラウド移行で構成検討と概算見積を行った経験をもとに、R2アーキテクチャをレイヤーごとに分解していきます。

この記事でわかること

• GCASが定めるR2（Rebuild）の5つのモダン化要件
• 5要件を構成図レベルへ落とし込んだR2論理アーキテクチャ
• ステートレス化とデータ保存先の分離の考え方
• 障害単位で可用性を設計する方法
• リファレンスアーキテクチャと実要件が衝突する箇所

R2要件とは？GCASが定める5つのモダン化要件

GCASガイドでは、R2（Rebuild）に対してモダン化の定義として5つの項目を示しています。

1. APIベースのシステム構成：RESTful API等を用いた疎結合なシステム連携で、組織横断的なデータ連携を促進する
2. ステートレスなアーキテクチャ：状態を保持しないことで、どのサーバーでも同じ結果を返し、可用性向上とコスト削減を実現する
3. サービスレベルの定義・計測：KPIとサービスレベルを定義・計測し、継続的な振り返りと改善を行う
4. 運用のコード化・自動化：IaCによるインフラ管理、定型作業の自動化、本番環境へのログインと手作業の抑制
5. マネージドサービスの活用：監視、ログ管理、バックアップ、セキュリティ、データベース、オブジェクトストレージ化のマネージドサービスを活用する

さらにシステム移行ガイドでは、R2のコンピュートについてサーバレスまたはコンテナを用いることを前提とし、マイクロサービス化、フロントエンドとバックエンドAPIの分離、イベントドリブン化などを基本形として示しています。

この5項目を読むだけなら、それほど難しくありません。難しいのは、これを実際の構成図へ変換することです。

「R2構成」という製品は存在しない

最初に押さえておきたいのは、R2は特定のクラウドサービスの組み合わせではない、という点です。

• コンテナを使った
• マネージドDBを使った
• Terraformを使った

からといって、それだけでR2になるわけではありません。

GCASが提供するリファレンスアーキテクチャも、完成品ではなく設計の出発点とされています。行政システムに共通する機能をブロックとして整理し、各システムの要件に応じて必要な機能を追加・変更する考え方です。特殊なシステムについては、リファレンスを参考にしながら独自に設計することも想定されています。

実際の設計でも、まず製品を選ぶのではなく、「5つのモダン化要件を満たすためには、どの機能が必要か」から逆算するほうが整理しやすくなりました。

R2アーキテクチャをレイヤーに分解する

大きく分けると、縦방向のデータフローはこうなります。

利用者 → CDN / WAF → Frontend → API → Application / Container → Database / Storage

これに横断機能として、Monitoring / Logging、Security、Secrets / Key Management、CI/CD、IaC、Backup、SLO / SLI が加わります。

つまりR2は、単純な三層構造をクラウドへ持っていく話ではありません。実行基盤、データ、セキュリティ、運用まで含めてクラウド前提で分解する必要があります。

1. APIベースのシステム構成

従来型システムでは、画面・アプリケーション・DBが密接に結び付いていることがあります。R2では、Frontend → API → Backend → Database のように役割を分離します。

GCASはRESTful API等による疎結合化だけでなく、以下もモダン化の対象として挙げています。

• フロントエンドとバックエンドの分離
• 非同期処理
• API定義の公開
• データ管理責任範囲の明確化
• バッチ処理のイベントドリブン化

ここで重要なのは、「API Gatewayを置けばAPIベースになる」わけではないということです。アプリケーション自体の責務を分割し、画面・業務ロジック・データを疎結合にする必要があります。

2. コンピュートは「落ちても困らない」構成へ

次がステートレス化です。R2のコンピュートでは、サーバレスまたはコンテナの利用が前提とされています。

ここで重要なのはコンテナそのものではなく、特定のサーバに状態を持たせないことです。どのコンテナへアクセスしても同じ処理結果になり、セッションやファイルをコンテナ自身に保存しない。その結果、負荷に応じたコンテナの増減、つまりオートスケールが可能になります。

障害時も同様です。1台が停止しても別インスタンスで処理できるため、サーバそのものを守る設計から、サービスを継続する設計へ変わることになります。

3. 状態をコンピュートの外へ出す

ステートレスにすると、当然「ではデータはどこに置くのか」という話になります。

構造化データはDatabase、ファイルはObject Storage、一時キャッシュはCache、非同期処理はMessage Queueへ、といった形で役割を分離します。

これは、1台のサーバがApplication・Session・File・Batch・Local Diskをすべて抱えるオンプレミス時代の構成とは大きく異なります。R2では、データの性質によって保存先を分けること自体がアーキテクチャ設計になります。

なお、アプリケーションのアクセス方式によっては、共有ファイルをオブジェクトストレージへ単純置換できない場合があります。この点は後述します。

4. マネージドサービスをどこまで使うか

5つ目のモダン化要件がマネージドサービスの活用です。GCASは特に、監視、ログ管理、バックアップ、セキュリティ、データベース、オブジェクトストレージについてマネージドサービスの利用を求めています。

理由は分かりやすいです。DBをVMへ自前構築すると、OS管理、DBインストール、パッチ、バックアップ、レプリケーション、障害検知、フェイルオーバー、監視までを利用者側で実装・運用する必要があります。マネージドDBなら、この一部をCSPへ移せます。

R2では、「作れるか」ではなく「自分たちで持つ必要があるか」を考えることが重要になります。

ここで実システムとの衝突が起きる

リファレンスアーキテクチャ上では、Database → Managed Database と非常にきれいに書けます。

しかし実システムには、データ容量、DBエンジン、I/O性能、バックアップ、移行方法、既存アプリケーションとの互換性といった条件があります。その結果、要件に合うマネージドサービスが存在しないケースが出てきます。

すると、理想のManaged Databaseに対して、現実はVM + PostgreSQL、という判断が必要になります。前回の記事で「今回の構成を簡単にR2とは言えない」と書いた理由の一つもここです。

この「マネージドサービスが使えない場合にどうするか」は、第4回で詳しく扱います。

可用性は「サーバ台数」ではなく障害単位で考える

R2構成を考えるとき、もう一つ大きかったのが可用性です。単純に「サーバ2台」と書くだけでは十分ではありません。何の障害に耐えるのかを分けて設計します。

ここで、マルチゾーンとマルチリージョンは別物という点に注意が必要です。また、全システムを無条件にマルチリージョンへすればよいわけでもありません。サービスレベル、RTO、RPO、コストから必要な構成を決めます。

監視ではなく「サービスレベルを計測する」

R2の中で、インフラエンジニアが忘れやすいのがこれです。GCASでは、サービスレベルの定義・計測そのものがモダン化要件になっています。

CPU使用率80%、メモリ使用率70%といった指標だけでは、利用者がサービスを正常に使えているかは分かりません。GCASの運用モダン化ガイドでも、CPUやメモリではなく、レスポンスタイム、エラー率、利用者操作の成功率など、利用者体験に直接関係するSLI/SLOを設定することを重視しています。

たとえば「API成功率99.9%以上」「レスポンスの95%以上が2秒以内」といった形です。

つまりR2の監視基盤では、Infrastructure Monitoring、Application Monitoring、Service Level Monitoring の3層まで考える必要があります。

運用のコード化はIaCだけではない

Terraformを書けばR2になる、という話でもありません。

GCASが求める運用モダン化には、IaC、定型作業の自動化、本番環境へのログイン・手作業の抑制、デプロイ自動化、障害対応の自動化、リモート運用までが含まれています。

したがって、Git → CI / Test → Build → Deploy というアプリケーションのCI/CDと、Git → Terraform → Plan / Apply → Cloud というインフラのパイプラインの両方を構成する必要があります。

目標は、本番環境を人がコンソールから作る必要がない状態です。

R2論理アーキテクチャの全体像

以上をまとめると、概念的には次の構成になります。

設計の順序としては、まずこの論理構成を作り、そのうえで必要機能 → CSPのサービスへマッピングと進めます。

逆に、CSPのサービス一覧から使えそうなサービスを並べる進め方をすると、R2の要件と構成の関係が分かりにくくなります。

R2セルフチェックリスト

設計時には、最低限この表で確認できます。

この表に「はい」と答えるための構成を作るのがR2設計だと考えると、整理しやすくなります。

リファレンスアーキテクチャは「正解」ではなく「スタート地点」

GCAS自身も、リファレンスアーキテクチャについて、すべての機能を網羅するものではなく、各システム要件に応じて必要なブロックを追加し、特殊なシステムでは独自に検討するよう説明しています。

実際に設計してみても、そのとおりでした。リファレンス構成を見た時点では「これを作ればよい」ように見えます。ところが実要件を入れると、

要件 → R2論理構成 → CSPサービスへマッピング → 「このサービスでは要件を満たせない」 → 構成を再検討

という作業になります。そして、このCSPへのマッピングが次の問題です。

次回：さくらのクラウドでR2構成を実現できるか

ここまでの話は、特定のCSPに依存しないR2の論理構成です。では、コンテナ、CDN/WAF、Database、Object Storage、NFS、Monitoring、KMS、Secrets、CI/CD、IaC、Multi Zone を、さくらのクラウドではどのサービスで実現するのでしょうか。

さくらのクラウドは2026年3月27日に全技術要件305項目への適合が確認され、ガバメントクラウドの対象クラウドサービスとして正式に採択されています。一方で、AWSやGoogle Cloudとサービス体系が同じわけではありません。

実際にサービスを一つずつ当てはめてみると、そのまま実現できるもの、少し設計を変える必要があるもの、別の方法で補完する必要があるものが見えてきました。

次回は「さくらのクラウドでR2構成を実現できるか？」を、実際のサービスへマッピングしながら検証します。

本連載の構成

1. ガバメントクラウドのR1・R2・R3とは？
2. R2要件を満たすアーキテクチャは何か？（本記事）
3. さくらのクラウドでR2構成を実現できるか？
4. R2構成でネックになるサービスと代替案
5. GSS接続のネットワーク設計
6. LGWAN／LGCS接続のネットワーク設計

よくある質問

コンテナを使えばR2になりますか？

なりません。R2ではコンテナ／サーバレスの利用に加え、APIベース、ステートレス、サービスレベルの計測、運用のコード化・自動化、マネージドサービスの活用まで含めて、システム全体をモダン化する必要があります。

マイクロサービス化は必須ですか？

GCASのR2基本形の一つとしてマイクロサービスアーキテクチャが示されています。一方で、フロントエンドとAPIを分離したイベントドリブン構成など、別の基本形も示されています。

R2ではVMを一切使えませんか？

「VMが1台でもあれば失格」と単純化するのは適切ではありません。ただし、R2のコンピュートはサーバレスまたはコンテナを前提としており、マネージドサービスの活用も求められています。そのため、VMを残す部分については要件上の理由を整理しておく必要があります。

マルチリージョンはR2の必須要件ですか？

R2そのものを意味する要件ではありません。必要な可用性、RTO/RPO、サービスレベル等から冗長化方式を決定します。サービスレベルは実現可能性やコストとのバランスを考えて設定することがGCASでも推奨されています。

リファレンスアーキテクチャをそのまま使えばよいですか？

GCAS自身が、リファレンスアーキテクチャは設計の出発点であり、各システムの要件に応じてブロックを追加・変更する前提だとしています。

参考資料

• デジタル庁 GCASガイド「ガバメントクラウドにおけるモダン化の定義」
• デジタル庁 GCASガイド「ガバメントクラウド概要解説」
• デジタル庁 note「ガバメントクラウドにおけるモダン化の意味と定義」
• デジタル庁「ガバメントクラウド」

※本記事は、公開情報および実際のアーキテクチャ検討の経験をもとに、実務上の論点を整理したものです。ガバメントクラウドに関する個別要件や対応可否については、案件ごとに確認が必要です。