「政府が整備するガバメントクラウドって、結局どの事業者が中心なんだろう」。自治体や省庁のシステムに関わるインフラエンジニアなら、一度は気になったテーマだと思います。2026年6月、その答えが数字としてはっきり示されました。報道によると、ガバメントクラウド上で稼働する新規システムの約85%をAmazon Web Services（AWS）が占めているのです。複数の事業者が認定されているにもかかわらず、実態は一社への集中が進んでいます。
この記事では、まずこの「8割超」という数字の中身を正確に整理します。次に、なぜこれほどAWSが選ばれているのかを、技術要件とISMAP（政府情報システムのためのセキュリティ評価制度）の観点から読み解きます。そのうえで、一社集中が招くベンダーロックイン（特定事業者への囲い込み）の実務的なリスクと、マルチクラウドや移植性をどう設計に織り込むかを、現場のエンジニア目線で考えていきます。GPUをどこから買うかといった調達の話ではなく、「依存のかたちをどう決めるか」という設計の話として扱います。
何が起きたのか｜ガバメントクラウドの85%をAWSが占める
まず事実関係を整理します。報道によると、3月31日時点でガバメントクラウド上の新規システムのうち、約85%がAWSによって占められていました。認定されているクラウドサービスは複数あるにもかかわらず、新規採用の大半が一社に集中しているという構図です。
採用件数の内訳を見ると、その偏りはさらにはっきりします。下の表は報道で示された数字を整理したものです。
| クラウドサービス | 新規システム採用件数 |
|---|---|
| Amazon Web Services（AWS） | 1564件 |
| Oracle Cloud Infrastructure（OCI） | 461件 |
| Google Cloud | 8件 |
| Microsoft Azure | 0件 |
AWSが1564件で突出し、2番手のOCIが461件、Google Cloudは8件、Azureに至っては0件です。複数事業者を認定して選択肢を用意したはずが、現場の採用判断はほぼAWSに流れている。この偏りこそが、今回デジタル庁が課題として受け止めている論点です。
なぜ「選べる」のに「選ばれない」のか
制度の建て付けとしては、ガバメントクラウドは複数の事業者を認定し、自治体や省庁が比較して選べるようになっています。それでも実態が一社集中に向かうのは、認定されているかどうかと、現場が安心して選べるかどうかが別の問題だからです。エンジニアの目線で言えば、選択肢が紙の上に並んでいることと、実際に手を動かして移行・運用できる土台が整っていることは、まったく別の話です。
採用の判断は、料金表だけでは決まりません。設計実績がどれだけ蓄積されているか、参照できるドキュメントや事例が豊富か、トラブル時に頼れる技術者を確保しやすいか。こうした「周辺の厚み」が、結果として一社への集中を後押しします。次の章では、その厚みの正体を技術要件とISMAPの両面から見ていきます。
なぜAWSが選ばれるのか｜技術要件とISMAPの両輪
AWSがこれほど選ばれる背景には、大きく分けて2つの要因があります。1つは技術・実績面の厚み、もう1つは制度面、すなわちISMAPへの早期対応です。この両輪がそろっていることが、現場の採用判断を一方向に傾けています。
技術・実績面の厚み
1つ目は、サービスの幅と実績の蓄積です。AWSは仮想サーバー（Amazon EC2）、オブジェクトストレージ（Amazon S3）、マネージドデータベース（Amazon RDS）といった基本サービスから、サーバーレスやコンテナ基盤まで、行政システムに必要な部品をひととおりそろえています。加えて、国内外で先行して使われてきたぶん、設計パターンや構築事例が豊富で、参考にできる情報が多いという強みがあります。
オンプレミスの経験がある方なら、「枯れた製品ほど情報が出回っていて安心して選べる」という感覚をご存じだと思います。クラウドでも同じで、先行して普及したサービスほどドキュメントや事例が厚くなり、設計や運用の不安が小さくなります。これが、迷ったときにAWSへ流れる大きな理由になっています。新しい技術にあえて飛び込むより、情報が出そろっている定番を選ぶほうが、行政システムのような失敗の許されない現場では合理的に見えるわけです。
制度面｜ISMAPへの早期対応
2つ目は制度面です。ガバメントクラウドに採用されるには、ISMAPに登録されていることが前提になります。ISMAP（Information system Security Management and Assessment Program）は、政府が求めるセキュリティ要求を満たしたクラウドサービスをあらかじめ評価・登録しておく制度で、各府省庁や自治体はこの登録リストの中から調達するのが原則です。
ここで重要なのが、登録には「言明範囲（スコープ）」という考え方がある点です。あるサービスが登録されていても、その登録が及ぶのは事業者が言明した機能の範囲に限られます。AWSは早くからISMAPに対応し、対象とする機能の範囲も幅広く整備してきました。使いたいサービスがすでに評価対象に入っているなら、エンジニアはその確認作業に時間を取られず、設計に集中できます。この「制度の関門を通過しやすい」という安心感が、採用を後押ししています。
オンプレ案件にたとえると、サーバーを発注する前に情報セキュリティ規程との適合性を確認する作業に近いものです。あらかじめ規程をクリアしている製品なら、稟議も設計もスムーズに進みます。逆に、後から「この機能は監査対象外でした」と判明すると、やり直しが発生します。ISMAPの言明範囲を早期に広げてきた事業者が選ばれやすいのは、この手戻りの少なさが効いているからです。
PR
こうすればうまく進む 自治体システム標準化＆ガバメントクラウド（三木浩平・吉本明平 著）
ガバメントクラウドの制度面を、国が出している情報を図表で整理しながら実務目線で解説した一冊です。なぜ標準化とクラウド移行がセットで語られるのか、自治体とベンダーの作業分担はどうなるのか。AWS集中の背景にある制度設計を押さえたい方の入門書として役立ちます。
デジタル庁の見解｜「事業者間のバランス」と移行の容易さ
この一社集中の状況を、デジタル庁はどう受け止めているのでしょうか。報道によると、デジタル庁の担当者は「ガバメントクラウド利用では、異なる事業者間でバランスを保つ必要がある」との考えを示しています。特定の事業者に集中しすぎることへの問題意識を、制度の運営側がはっきり持っているということです。
あわせて重視されているのが、クラウド間でデータを移行する際の容易さ、つまり互換性です。仮に一社に集中していても、いざというときに別のクラウドへ移れる状態が保たれていれば、依存の度合いは下げられます。逆に、移ろうにも移れない状態こそが本当のリスクだという認識です。報道では、今後の課題として「利用のしばり」、すなわちベンダーロックインが重視される可能性も指摘されています。
ここはエンジニアにとって示唆に富む論点です。「どの事業者を使うか」よりも、「使ったあとに抜けられるか」を制度の側が気にしている。これは民間のクラウド戦略にもそのまま当てはまる考え方で、依存先を一社に決めることそのものより、その依存をいつでも見直せる状態を保っておくことのほうが本質だと言えます。なお、国産クラウドの推進方針や具体的な予算については、現時点で確たる一次情報が示されているわけではないため、ここでは「事業者間のバランスと移行容易性を重視する」という方向性の確認にとどめておきます。
ベンダーロックインの実務リスク｜何が「縛り」になるのか
ベンダーロックインとは、特定の事業者のサービスに深く依存し、他社へ乗り換えるのが難しくなる状態を指します。オンプレミス時代にも、特定メーカーのサーバーやストレージに縛られる囲い込みはありました。クラウドでも本質は同じですが、縛りの効き方が変わっています。具体的にどこが縛りになるのか、実務の視点で分解してみます。
縛りが生まれる3つの層
クラウドのロックインは、単一の原因で起きるわけではありません。いくつかの層が重なって、抜けにくさを生みます。主なものを挙げます。
・マネージドサービスへの依存: 運用を肩代わりしてくれる便利な独自機能を使い込むほど、その事業者ならではの作り込みがシステムに染み込みます。便利さと引き換えに、移行時には設計の作り直しが必要になります。
・データの取り出しにくさ: 大量のデータを別のクラウドへ移すには、転送の手間に加えて、転送量に応じた料金（egress、データ転送の出口料金）が発生します。データが大きいほど、移行のハードルとコストが上がります。
・運用ノウハウと人材の偏り: 一社の環境に最適化した運用体制を組むほど、その事業者に詳しい人材ばかりになります。組織としての乗り換え能力が下がり、これも見えにくい縛りになります。
これらは目に見えにくいのが厄介な点です。物理的な機器なら縛りに気づきやすいのですが、クラウドの独自サービスは「便利だから」と使ううちに、知らないあいだに依存が深まります。気づいたときには、その事業者を前提にした作りになっていて、簡単には離れられない。だからこそ、依存が深まる前に「どこまで縛られているか」を可視化しておくことが、エンジニアの腕の見せどころになります。
一社集中が招く調達・交渉リスク
縛りの問題は、技術だけにとどまりません。一社にすべてを預けると、料金改定やサービス仕様の変更に対して交渉の余地が小さくなります。複数の選択肢を持っていること自体が、価格や条件の交渉材料になるからです。行政システムの文脈で言えば、国民の税で運営される基盤が一社の方針に大きく左右されること自体が、ガバナンス上のリスクとして意識されています。デジタル庁が「事業者間のバランス」を口にする背景には、この交渉力の問題もあります。
規模はまるで違っても、考え方の構造は中小企業のクラウド戦略と地続きです。一社に深く依存していると、値上げや障害、サービス終了といった事態に対して打てる手が限られます。逆に、別の選択肢を持っていれば、状況に応じて柔軟に対応できます。「抜けられる状態」を確保しておくことが、結果として安定した運用につながるのです。
移植性をどう設計するか｜IaCとコンテナで「抜けられる」状態を保つ
では、ロックインを和らげ、いざというときに移行できる状態を保つには、設計で何ができるのでしょうか。完全にどの事業者でも動くようにする「フルポータビリティ」は理想ですが、現実にはコストとのバランスで考える必要があります。ここでは、現場で効果が出やすい2つの軸、IaC（インフラのコード化）とコンテナを取り上げます。
IaC（Infrastructure as Code）で構成を持ち運ぶ
IaCは、サーバーやネットワークの構成を手作業のコンソール操作ではなくコードで定義する考え方です。構成がコードになっていれば、環境の再現が容易になり、別のクラウドへ移す際の出発点になります。代表的なツールであるTerraformは、複数のクラウドに対応しており、事業者をまたいだ構成管理に向いています。一方で、各クラウド純正のツール（AWSのAWS CloudFormationなど）は、その事業者の機能を深く使える反面、他社への移植性は限られます。
ここで現実的に押さえておきたいのは、IaCにしたからといって、コードをそのまま別のクラウドに貼り替えれば動く、というほど単純ではない点です。各クラウドでサービス名も設定項目も異なるため、移行時には書き換えが必要になります。それでも、構成が文書化・コード化されているだけで、「今どういう作りになっているか」が一目で分かり、移行の見積もりや作業範囲の特定が格段にやりやすくなります。何も残っていない手作業の構成と比べれば、抜けやすさは大きく変わります。
コンテナでアプリ層の依存を薄くする
もう1つの軸がコンテナです。アプリケーションをコンテナ（DockerやKubernetesで動く実行単位）にまとめておくと、アプリ本体は特定のクラウドに依存しにくくなります。コンテナは「どこでも同じように動く箱」のようなもので、AWS・Azure・Google Cloudのいずれにもコンテナを動かす基盤が用意されています。アプリをこの箱に収めておけば、土台を入れ替えても中身はそのまま動かしやすくなります。
ただし、ここにも落とし穴があります。コンテナにしても、データベースやストレージ、認証といった「周辺の部品」を各クラウドの独自サービスで固めてしまうと、結局そこが縛りになります。移植性を意識するなら、アプリ本体はコンテナで可搬にしつつ、周辺サービスのどこを共通技術で組み、どこを割り切って独自サービスに任せるかを、最初に線引きしておくことが大切です。すべてを移植可能にしようとするとコストと手間が跳ね上がるので、「ここは抜けられるようにしておく」「ここは深く使い込んでよい」を意識的に決めるのが現実解です。
実務チェックリスト｜自社の「依存のかたち」を点検する
最後に、自社や担当システムの依存度を点検するための観点を整理します。明日からでも見直せる項目です。
・構成は文書化・コード化されているか: 手作業頼みの構成は、移行の見積もりすら立てられません。まずIaCで現状を可視化することから始めます。
・データの持ち出し手段とコストを把握しているか: 主要なデータの量と、別クラウドへ移す際の転送料・手間を概算しておきます。「移せるかどうか分からない」状態を放置しないことが第一歩です。
・独自サービスへの依存箇所を棚卸ししているか: どの機能が特定事業者でしか動かないかを一覧化し、縛りの強い箇所を把握します。
・アプリ層は可搬な形になっているか: コンテナ化など、アプリ本体を土台から切り離せる構成になっているかを確認します。
・運用ノウハウが一社に偏っていないか: 特定クラウドにしか詳しくない体制は、組織としての乗り換え能力を下げます。学習機会の分散も中長期の備えになります。
大切なのは、最初から完璧なマルチクラウドを目指すことではありません。「いざとなれば抜けられる」状態を、コストと相談しながら少しずつ確保していくことです。政府クラウドのAWS集中という事例は、規模こそ違え、依存設計の重要性をあらためて突きつけています。自社の構成を一度棚卸しし、縛りの強い箇所から優先的に手を打つ。その積み重ねが、特定事業者の事情に振り回されない運用につながります。
PR
かんたん理解 正しく選んで使うためのクラウドのきほん AWS・Azure・Google Cloudを横断的に理解しよう（高橋秀一郎・大澤文孝 著）
ベンダーロックインを避けるには、まず各クラウドの「共通点」と「独自部分」を見分ける目が必要です。本書はAWS・Azure・Google Cloudを横断的に整理しており、どこが乗り換えやすく、どこが縛りになりやすいかを俯瞰できます。移植性を意識した設計判断を始める前に押さえておきたい一冊です。
よくある質問（FAQ）
ガバメントクラウドではAWSしか使えないのですか？
いいえ。複数のクラウドサービスが認定されており、自治体や省庁は比較して選べます。ただし2026年3月末時点では、新規システムの約85%がAWSに集中しているのが実態です。選択肢はあるものの、実績や情報の厚み、ISMAP対応の早さから、現場の採用判断がAWSに流れている状況です。
なぜAzureの採用が0件なのですか？
報道で示された新規システムの採用件数では、AWS 1564件、OCI 461件、Google Cloud 8件に対し、Azureは0件でした。認定されていても採用件数がゼロという結果は、認定の有無と現場での採用判断が別物であることを示しています。理由の断定は避けますが、実績の蓄積や設計事例の量が採用判断に大きく影響していると考えられます。
ベンダーロックインは具体的に何が問題なのですか？
主な問題は3つあります。1つ目は、独自サービスを使い込むことで他社への移行が技術的に難しくなること。2つ目は、データを別クラウドへ移す際の手間と転送コストがかさむこと。3つ目は、一社依存により料金改定やサービス変更に対する交渉力が下がることです。いずれも「いざというときに抜けられない」状態が本質的なリスクになります。
中小企業のクラウド運用にもこの話は関係しますか？
はい、地続きです。規模は違っても、一社に深く依存すると値上げや障害、サービス終了に対して打てる手が限られるという構造は同じです。最初から完璧なマルチクラウドを目指す必要はありませんが、構成をコード化して可視化し、「いざとなれば抜けられる」状態をコストと相談しながら確保しておくことは、企業規模を問わず有効です。
マルチクラウドにすれば必ず安全になりますか？
いいえ、「分散すれば安心」という単純な話ではありません。複数のクラウドを併用すると、それぞれの運用知識が必要になり、管理の手間とコストが増えます。メリット（障害・値上げへの耐性、交渉力、適材適所）とコストを天秤にかけ、どこを共通技術で組み、どこを割り切って一社に任せるかを意識的に設計することが大切です。
本記事のまとめ
ガバメントクラウドの新規システムの約85%をAWSが占めるという数字は、複数事業者を認定して選択肢を用意しても、実績・情報・制度対応の厚みがある事業者へ採用が集中しやすいことを示しています。デジタル庁も「事業者間のバランス」とデータ移行の容易さを重視しており、今後はベンダーロックイン、すなわち「利用のしばり」が課題として意識されていく方向です。
エンジニアにとっての示唆は明確です。どの事業者を使うかよりも、使ったあとに抜けられる状態を保てるかが本質だということ。IaCで構成を可視化し、コンテナでアプリ層の依存を薄くし、独自サービスへの依存箇所を棚卸しする。これらを一度に完璧にやる必要はありません。縛りの強い箇所から優先的に手を打ち、コストと相談しながら「抜けられる余地」を少しずつ確保していく。その積み重ねが、特定事業者の事情に振り回されない、しなやかなクラウド運用につながります。
自社のクラウド、どこまで「抜けられる」状態ですか？
クラウド実務に役立つ「Cloud Architecture」カテゴリの記事を他にもまとめています。あわせて読みたい関連記事はこちらからどうぞ。
