3つの分離方式と特徴

共同利用方式を選択した場合、ASP事業者は以下の3パターンから団体間の分離方式を選びます。各パターンはコスト効率とセキュリティ強度のトレードオフ関係にあります。

分離方式	概要	リソース共有度	コスト効率	障害影響範囲
アカウント分離	団体ごとに個別アカウント（AWS）またはテナンシ（OCI）で環境を分離	低（管理系のみ共有）	低〜中	最小
ネットワーク分離	VPC/VCN単位で団体ごとに分離。サーバー・DBは分離、運用系は共有	中	中	中
アプリケーション分離	アプリケーション・DBを論理的に分離。コンピューティングリソース・DBを最大限共有	高	高	大

アカウント分離（コンパートメント分離）

AWS では「アカウント単位」、OCI では「コンパートメント単位」で団体ごとに環境を完全に分離する方式です。管理系リソースのみを共有し、業務系のリソースは他団体と共有しません。

シングルテナントに近い独立性を持つため、障害発生時に他の共同利用団体への影響が最小限に抑えられます。一方で、リソースをほぼ単独で占有するためコスト削減効果は限定的です。

ネットワーク分離

団体ごとに VPC（AWS）または VCN（OCI）を構築し、ネットワーク単位で分離するパターンです。サーバーや DB などの業務関連リソースは団体ごとに分離されますが、運用・セキュリティ関連のリソースは共有されます。

アカウント分離とアプリケーション分離の中間に位置し、セキュリティと運用効率のバランスがとりやすいとされています。

アプリケーション分離（マルチテナント）

最もリソース共有度が高い方式です。団体ごとに独立した環境を設けず、アプリケーション及び DB を論理的に分離します。コンピューティングリソースや DB は複数の団体で共同利用し、アプリケーション内部の識別子（ID・市町村識別子等）でユーザーを区別してデータアクセスを制御します。

デジタル庁の推奨構成ガイドでは、アプリケーション分離における設計ポイントとして以下の4点が示されています（出典: ガバメントクラウド利用における推奨構成（AWS編・OCI編・Azure編））。

1. ネットワーク分離: 団体ごとに専用ドメインや接続元 IP アドレスの制限を設ける
2. アプリケーション共同利用: 市町村識別子などでユーザーを識別し、適切なデータアクセスを制御
3. ストレージの共同利用: 各団体のデータへのアクセスを制御。暗号鍵は共同利用単位で作成
4. DB の共同利用: テナントごとにスキーマを分離するなどの手法で各団体データを保護

flowchart TD
    A["地方公共団体A"] --> C["共同APサーバー\n（識別子で分離）"]
    B["地方公共団体B"] --> C
    C --> D["共有DB\n（スキーマ分離）"]
    C --> E["共有ストレージ\n（暗号鍵分離）"]
    D --> F["データ保護層\n（暗号化・アクセス制御）"]
    E --> F

マルチテナント（アプリケーション分離）のメリット

1. コスト削減効果（割り勘効果）

複数の団体でコンピューティングリソースや DB を共有するため、インフラコストを自治体数で割り勘できます。特にシステム稼働率が低い小規模自治体ほど効果が大きく、単独でインフラを保持するシングルテナント方式と比較して、クラウド利用費を大幅に抑えられます。

総務省の資料では、複数自治体による「割り勘効果」として自治体クラウドの主要な利点の1つに挙げられています（出典: 000221267.pdf, 総務省）。

2. 運用保守の効率化

ASP事業者がアプリケーションを一元的に管理・アップデートできるため、パッチ適用や機能改修を全利用自治体に一括で展開できます。IaC（Infrastructure as Code）や監視ダッシュボードを共通化することで、運用保守コストも削減できます（出典: AWS Blog, ガバメントクラウドの道案内）。

3. スケーラビリティの確保

繁忙期（確定申告シーズン・年度末の住民異動など）に合わせて動的にリソースをスケールアップし、繁忙期が過ぎればスケールダウンできます。複数団体で共有する大規模なリソースプールから必要な分だけ利用するため、単独利用よりもスケーラビリティが高くなります。

マルチテナント（アプリケーション分離）のデメリット・リスク

1. 他団体への障害伝播リスク

コンピューティングリソースや DB を複数の団体で共有するため、障害発生時に他団体へ影響が及ぶ可能性があります。デジタル庁の推奨構成ガイドでも「障害等発生時の他団体への影響を考慮してデータへのアクセス制御や分離方法を検討する必要がある」と明記されています（出典: ガバメントクラウド推奨構成（OCI編））。

2. コスト透明性の問題

アプリケーション分離では、共有リソース（ストレージ・監視サーバー等）のコストを各団体に正確に按分することが困難です。団体ごとの利用料金を算出するには、タグを用いてリソース利用量を管理する必要があり、タグの命名規則の設計・運用に追加の工数がかかります。

コスト配分タグによる算出が困難なリソースについては「アクセス数等により按分する方法」（出典: ガバメントクラウド推奨構成（Azure編））が採られますが、自治体側にとっては費用の根拠が見えにくくなる点に注意が必要です。

3. 論理分離の保証問題

物理的にリソースを分離するアカウント分離とは異なり、アプリケーション分離は論理的な分離に依存します。設計・実装の誤りがあれば、他団体のデータに誤アクセスするリスクがあります。

2026年3月に公表された「地方公共団体に対するガバメントクラウド移行支援事業 成果報告書」では、せとうち3市（富士通Japan）が共同利用方式のマルチテナント検証を実施し、EFS・EBS のディレクトリやRDS のスキーマを団体ごとに分離する方法で実現可能なことを確認しています（出典: 20260327_policies_local_goverments_goverment-cloud-report_01.pdf, デジタル庁）。

4. データ主権・ガバナンスの課題

アプリケーション分離方式では、自治体が直接クラウドリソースを管理するのではなく、ASP事業者が一元管理します。セキュリティ設定・バックアップ方針・災害対策などを自治体が直接制御できない点で「ガバナンスの放棄」との指摘もあります。

共同利用グループから1団体が離脱する際の対応も課題です。推奨構成ガイドでは、離脱時にはデータの論理削除・アクセス制御の削除・データ消去完了報告書の提出という手順を明確化することが求められています（出典: 20260327_policies_local_goverments_goverment-cloud-report_03.pdf, デジタル庁）。

分離方式の選択指針

どの分離方式を選ぶかは、自治体の規模・セキュリティ要件・コスト優先度によって異なります。

flowchart TD
    Q1{"個人情報DBを\n完全分離したい？"}
    Q1 -->|Yes| A["アカウント分離\n（最高セキュリティ）"]
    Q1 -->|No| Q2{"コスト最優先\nかつ小規模？"}
    Q2 -->|Yes| B["アプリケーション分離\n（マルチテナント）"]
    Q2 -->|No| C["ネットワーク分離\n（バランス型）"]

アカウント分離を選ぶべきケース:

• 独自のセキュリティ要件がある中核市・政令指定都市
• 他団体との障害伝播リスクを許容できない場合
• データ主権を自治体側で確保したい場合

アプリケーション分離を選ぶべきケース:

• コスト削減を最優先する小規模自治体（人口5万人未満）
• 既に信頼できる ASP 事業者との共同利用グループに参加する場合
• システム運用を ASP に全面委任できる体制がある場合

自治体が確認すべきチェックリスト

ASP 事業者から提案を受ける際には、以下の点を必ず確認してください。

確認項目	アカウント分離	アプリケーション分離
他団体障害時の影響範囲	自団体に波及しない	要確認（設計による）
月次コスト明細の粒度	自団体分のみ	タグ集計で按分
団体離脱時のデータ消去手順	簡易	手順書の事前確認必須
暗号鍵の管理主体	自団体	共同利用単位（ASP管理）
災害対策・BCP	独立設計	共同利用グループ設計に依存

FAQ

Q1. マルチテナント方式では、他の自治体のデータが見えてしまうリスクがあるのでしょうか？

正しく設計・実装されていれば他団体のデータは参照できません。デジタル庁推奨構成ガイドでは、識別子によるアクセス制御・暗号鍵の分離・ネットワーク分離の組み合わせで情報漏えいを防ぐ設計が示されています。ただし「正しく実装されているか」を自治体側で検証するのは難しいため、ASP事業者にセキュリティ検証結果の開示を求めることが重要です。

Q2. 共同利用方式を選べば、必ずマルチテナント（アプリケーション分離）になるのでしょうか？

いいえ。共同利用方式の中でも「アカウント分離」「ネットワーク分離」「アプリケーション分離」の3パターンがあります。コストを最大限に下げたい場合はアプリケーション分離、セキュリティを優先したい場合はアカウント分離を選択できます。ASP事業者に提案された分離方式がどのパターンに該当するかを確認してください。

Q3. 小規模自治体でもアカウント分離方式を選べるのでしょうか？

技術的には選択可能ですが、コスト面での割り勘効果が薄れます。共同利用グループの規模や業務システムの利用料金によっては、アカウント分離を選択すると単独利用方式とほぼ同等のコストになる場合があります。コストと安全性のトレードオフを ASP 事業者と十分に協議したうえで判断してください。

Q4. マルチテナント方式で利用できる標準準拠システムの業務はどれですか？

デジタル庁が認定する標準準拠システムでは、基幹系20業務すべてがマルチテナント（アプリケーション分離）方式での提供が可能です。どの業務システムがどの分離方式で提供されているかは、GCInsightのパッケージ一覧（/packages）で確認できます。

まとめ

ガバメントクラウドのマルチテナント共同利用方式は、コスト削減・運用効率化という明確なメリットを持つ一方、他団体への障害伝播リスク・コスト透明性・データ主権という構造的な課題を内包しています。

2026年度以降の本格移行フェーズでは、ASP事業者から提示される「共同利用方式」の中身——どの分離パターンを採用するか——を自治体側が正確に理解したうえで契約することが不可欠です。

各自治体の移行状況・採用クラウドのリアルタイムデータはGCInsightのダッシュボード（/）で確認できます。マルチテナント方式の採用実績や費用対効果の比較を検討中であれば、コスト効果ページ（/costs）も参照してください。

参考文献・出典

• ガバメントクラウド — デジタル庁
• ガバメントクラウド利用における推奨構成（AWS編）— デジタル庁
• ガバメントクラウド利用における推奨構成（OCI編）— デジタル庁
• ガバメントクラウド利用における推奨構成（Azure編）— デジタル庁
• 地方公共団体に対するガバメントクラウド移行支援事業 成果報告書 — デジタル庁（2026年3月）
• ガバメントクラウド全般的ガイド — デジタル庁 GCAS