オンプレミスでサーバーの設計や構築、障害対応を重ねてきた経験は、クラウド案件の条件を見た瞬間に自信を失わせることがあります。求められる言葉の多くは「権限」「監視」「暗号化」といった見慣れたものなのに、中身の粒度がまるで違うからです。政府がまとめた基本方針は、その差をオンプレとクラウドの対比という形で具体的に整理しています¹。積み上げてきた設計の勘所がどこまで通用し、どこから学び直しが要るのかを、この文書に沿って順に確かめていきます。

1. そのまま使える部分と、中身が違う部分

境界で守ってきた考え方には限界があった

オンプレミスの設計では、社内ネットワークの境界を固めて守る考え方が主流でした。ファイアウォールで外周を囲い、内側は信頼できる前提で組み立てる構成を、実際に担当してきた実感を持つ人もいるはずです。

そこには根拠があります。オンプレミスでは境界の外側を強く意識するあまり、内部についての対策が十分に届いていない場合があったと、政府の基本方針は振り返っています¹。守りの重心が外側に寄っていたということです。

この経験は無駄になりません。境界の内側で何を守るかを言語化する力や、通信の流れを図で説明する力は、クラウドでもそのまま生きる土台です。ここから先に何が変わるかだけを押さえれば、経験を持ち込む立場で読み進められます。

境界を固める発想は、当時の制約の中では合理的な選択でした。ネットワークの外側だけを強く意識する設計は、限られた予算と人員の中で最大の効果を出す工夫でもあったはずです。今から当時の判断を否定する必要はありません。むしろ「なぜその設計を選んだのか」を筋道立てて説明できる力こそ、クラウド案件でもそのまま評価される土台になります。

全ての層を見る考え方への転換

クラウドの基本方針は、全てのレイヤーで対策を検討し、動的な監視や認証を組み合わせる姿勢を示しています²。境界の内も外も、同じ重さで見る発想です。

境界だけを固めるオンプレの発想よりも、層ごとに独立して確かめる発想のほうが、クラウドでは効きます。ネットワークの層、アカウントの層、データの層——それぞれに同じ強さの対策を置く発想への切り替えが、最大の違いです。

層ごとに見る発想へ切り替えるとき、最初につまずきやすいのが「どこまで細かく分けるか」という感覚です。オンプレで境界という一つの線を引いてきた経験を、ネットワークの層、アカウントの層、データの層という具合に、層の数だけ繰り返す作業として分解して考えると、迷いなく進めやすくなります。焦って全部を一度に見ようとしないことが、かえって近道になります。

図の作成：Remogu編集部。境界で守る発想と層ごとに守る発想の違いを整理したもので、統計データではありません

この転換は難しい理論ではありません。これまで境界の設計で培ってきた「どこを、なぜ守るか」を説明する力を、層の数だけ繰り返す作業に近いものです。次章では、その中でも真っ先にぶつかる「責任の切り分け」を見ていきます。

2. 守る範囲を切り出す——責任共有

自分が担う分だけを切り出す

クラウドに移ると、守るべき範囲が急に広がった錯覚を持つ人がいます。実際にはクラウド事業者側が担う部分と、案件側が担う部分に切り分けられており、全体を一人で背負う設計ではありません。

基本方針が挙げる対応の一つが、責任共有モデルによって対象を絞り込むことです³。境界の外にある部分まで気にする必要はなく、自分が担当する範囲をまず線引きすることが最初の一歩になります。

この線引きさえできれば、オンプレ時代に培ってきた「守る範囲を定義する」力がそのまま使えます。次に効くのが、守る対象そのものを減らす選択です。

この線引きは一度決めて終わりではありません。案件によって構成やクライアントとの取り決めが変わるたびに、自分の担当範囲がどこまでかを都度確認し直す習慣が、クラウドの現場では欠かせなくなります。境界が固定されていたオンプレの感覚のままでいると、担当範囲の境目を見誤りやすくなる点には注意が必要です。

サーバーを持たない選択で対象を減らす

基本方針は、サーバーを構築しないアーキテクチャを選ぶことも対応の一つに挙げています¹¹。サーバーという管理対象そのものを持たなければ、OSの更新や不正アクセスの監視といった作業自体が要らなくなります。

守る範囲を削る発想は、オンプレの延長で守る量を増やす発想よりも効きます。ここで比較表1に、責任共有モデルによる分担の考え方を整理しました。

サーバーを持たない構成を選ぶかどうかは、案件ごとの要件や制約によって変わります。それでも「守る対象そのものを減らせる選択肢がある」ことを知っているかどうかは、設計の引き出しの数として現場での提案の幅に直結します。守る量を増やす発想しか持たない設計者との違いは、ここに表れます。

担う範囲	従来のオンプレの発想	クラウドでの整理
物理的な機器や設置場所	自分たちで確保し管理する	クラウド事業者側が担う範囲
OSやミドルウェアの土台	自分たちで構築し保守する	サーバーを持たない構成を選べば管理対象から外れる
権限設定やデータの扱い	自分たちで設計し運用する	引き続き自分たちが担う中心の範囲

表の分担は案件ごとの契約や構成によって変わりますが、「自分の担当範囲はどこか」を最初に確認する姿勢は、どの案件でも共通して求められます。

3. 「最小権限」は同じ言葉、違う粒度

言葉は同じでも対象が違う

「最小権限で設計する」という言葉自体は、オンプレの時代から聞き慣れたものです。だからこそ、クラウド案件の条件に同じ言葉が並ぶと、経験がそのまま通じると感じやすくなります。

基本方針も、業務に必要な最小限の権限だけを与えることを予防的統制の一つに挙げています⁵。ここまではオンプレでの実践と変わりません。

違うのは、その権限を割り当てる単位です。オンプレではサーバーやアカウントという大きな単位で権限を区切ることが中心でした。

同じ言葉が並んでいるからこそ、油断すると見落としが起きやすい場面でもあります。「最小権限だから大丈夫」と言葉の一致だけで安心してしまうと、実際に割り当てる単位を確認しないまま設計が進んでしまいます。言葉の一致に頼らず、対象の単位を一つずつ確かめる姿勢が、参画後の板挟みを防ぐ最初の一歩になります。

操作の単位まで割り当てが細かくなる

クラウドではAPIを介して個々の操作を呼び出せるため、権限もその操作の単位で割り当て可能なことが多いと基本方針は述べています⁶。サーバー単位よりも操作単位のほうが、絞り込みは細かくなります。

その結果、サーバーの構築と運用だけで数百の操作や権限が定義されている場合もあると基本方針は述べています⁷。一つずつ手作業で確認できる数ではありません。

ここで問われるのは、権限を丸ごと渡すか絞るかという二択ではなく、操作の単位で設計図を描けるかどうかです。図2に、単位の違いによる広がり方を整理しました。

操作単位で権限を設計する作業は、地道で根気の要る作業に見えるかもしれません。しかし、この地道さこそが、オンプレの現場で細かい設定項目を一つずつ積み重ねてきた経験と重なる部分でもあります。数の多さに気後れせず、単位を分解して考える姿勢自体は、これまで培ってきたものと変わりません。

図の作成：Remogu編集部。権限を割り当てる単位の粗さの違いを整理したもので、統計データではありません

4. 守ると動けない——現場の板挟み

絞りすぎると業務が止まる

権限を絞り込むほど安全になる、とは限りません。本番環境で障害の切り分けをする場面を想像すると、そのことがよく分かります。

基本方針も、様々な操作を制限されたユーザーでは業務を遂行することが困難になる場合があると述べています⁹。守りを固めすぎた結果、肝心なときに手が動かせなくなる矛盾です。

この板挟みは、オンプレの現場でも形を変えて経験してきたはずです。承認の手続きが厳しすぎて障害対応が遅れた経験は、権限設計にも同じ構図で表れます。

この矛盾に気づかないまま設計を進めると、緊急時になって初めて権限が届かず身動きが取れないという事態に直面します。平時の安全と緊急時の対応力は、放っておくと両立しません。あらかじめどちらを優先する場面かを想定しておくかどうかが、現場での対応力を大きく分けます。

厳密さを場面ごとに調整する

基本方針が示す答えは、権限設定の厳密さを一律にせず、開発の段階や運用環境の種類、業務の内容に応じて調整することです⁸。

平時の運用環境よりも、障害対応が起きる場面のほうが、一時的に権限を広げる判断が要ることもあります。大切なのは、その判断をあらかじめ設計しておくことです。

厳密さを調整する仕組みは、その場の判断任せにせず、あらかじめ手順として決めておくことで初めて機能します。誰がどの場面で権限を広げてよいのかが決まっていないと、緩めたままの状態が長く残ってしまう恐れがあります。決めておく作業そのものが、次の統制の話につながります。

比較表2と図3に、場面によって求められる厳密さの違いを整理しました。次章では、この調整を支える二つの統制の役割を見ていきます。

場面	権限設定の厳密さ	理由
平時の運用	絞り込みを優先する	不適切な設定や操作を未然に防ぐため
開発や検証の環境	用途に応じて調整する	環境の種類によって求められる対策が変わるため
障害対応など緊急時	一時的に緩める判断を含める	業務の遂行が困難になる事態を避けるため

図の作成：Remogu編集部。場面によって求められる厳密さの違いを整理したもので、統計データではありません

厳密さを変える対象は、権限そのものではなく「どの場面で、どこまで緩めるか」という設計です。ここを言語化できると、守ると動けないという板挟みは、調整できる設計課題に変わります。

5. 止める統制と、見つける統制

設定ミスを前提に、未然に防ぐ

基本方針は、不適切な設定や操作を未然に防ぐための対策を予防的統制と呼んでいます⁴。権限を絞ることも、この予防的統制の一部です。

予防的統制は、設定を作る段階で効かせる対策です。一度仕組みに組み込んでしまえば、その後は特別に意識しなくても効き続ける点が、人の注意力や慣れに頼る対策とは違います。仕組みに任せられる部分を増やすほど、見落としの余地は減っていきます。

オンプレの現場では、設定ミスは「起きないように注意する」ことで防ぐ発想が中心でした。クラウドでは、設定ミスは起こり得るという前提に立ち、仕組みで止める設計に置き換わります。

基本方針は、予防的統制と発見的統制の実施を併せて挙げています¹⁰。止めるだけでなく、見つける仕組みも同時に備える構えです。

見つける仕組みを自動化と組み合わせる

その見つける仕組みについて、基本方針はインシデント対応と自動化を挙げています¹⁶。見つけた後の対応まで自動で進む形を目指す内容です。

見つける統制を後回しにしてきた現場ほど、障害が起きたときの原因特定に時間がかかる傾向が見えます。止める仕組みと見つける仕組みは、どちらか一方だけでは役割を果たせません。オンプレで障害の切り分けを担ってきた経験は、この見つける統制の設計にそのまま生きてきます。

止める統制よりも、見つける統制のほうが後回しにされがちです。しかし障害の一次原因を特定する場面では、見つける統制の設計が経験を最も生かせる領域になります。

図4に、止める統制と見つける統制の役割分担を整理しました。次章では、この仕組みを人手に頼らず保つ方法を見ていきます。

図の作成：Remogu編集部。止める統制と見つける統制の役割分担を整理したもので、統計データではありません

6. 人手で守らない——既定にする

対策を最初から組み込んでおく

統制を整えても、確認を人手に頼る運用は長く続きません。担当が替わるたびに抜け漏れが生まれやすくなります。

基本方針は、IaCとテンプレートの適用によって主要な対策を既定にし、構成を管理することを挙げています¹²。最初から安全な状態を組み込んでおけば、確認そのものの負担が減ります。

人が毎回確認する運用よりも、最初から既定にしておく運用のほうが、抜け漏れは起きにくくなります。

既定にする作業自体は、決して華やかではありません。テンプレートを一つずつ整えていく地道な作業は、オンプレで手順書や運用マニュアルを整備してきた経験と重なります。過去に手順書として書いてきた内容を、仕組みとして組み込み直す作業だと捉えると、取り組みやすくなります。

データの保護と、状況を測る仕組み

データの保護については、暗号化技術の利用が挙げられています¹³。権限の設計だけでなく、保存されるデータそのものを守る層も別に用意する考え方です。

状況を把握する仕組みとしては、定量的な計測とダッシュボードによる可視化が挙げられています¹⁴。既定にした対策が実際に効いているかどうかを、感覚ではなく数値で確かめる発想です。

データの保護と状況の可視化は、別々の対策に見えて実は繋がっています。守る対策が効いているかどうかを数値で確認できて初めて、次にどこを直せばよいかという改善点も見えてきます。感覚だけに頼った運用から抜け出す一歩が、この二つの組み合わせです。

比較表3に、既定にする対策と、その狙いを整理しました。次章では、この体制を保ち続けるための考え方を見ていきます。

既定にする対策	狙い
IaCとテンプレートの適用	主要な対策を最初から組み込み、構成を管理する
データの暗号化技術の利用	保存されるデータそのものを守る
定量的な計測とダッシュボード	対策が効いているかを数値で可視化する

既定にする対策は一度作って終わりではなく、環境が増えるたびに適用範囲を広げていく前提のものです。

7. 終わらない作業と、確かめ方の違い

対応に終わりがないという前提

基本方針は、継続的なアップデートへの対応を挙げています¹⁵。既定にした対策も、その場限りで終わる作業ではありません。

オンプレでは、構築が終われば一区切りという感覚を持ちやすいものでした。クラウドでは構築後も対応が続くという前提に立つほうが、現場の実態に近づきます。

終わりがないという前提を最初に受け入れておくと、案件に参画した後の心構えが変わります。一度作って終わりではなく、環境の変化に合わせて育て続ける仕事だと捉え直せると、日々の対応を負担ではなく積み重ねとして受け止められます。

確かめ方そのものが変わる

確かめ方についても、基本方針はクラウドに最適化した自己点検・監査を挙げています¹⁷。オンプレで使ってきた確認の手順そのままでは、届かない部分が出てきます。

地域の要件が関わる場合もあります。外国にあるサーバーに保有個人情報が保存されるときは、外的環境の把握などの対応が必要になる点に留意が必要だと基本方針は述べています¹⁸。

確かめ方が変わるという事実は、身構えるほど大きなことではありません。オンプレで培ってきた「手順を疑い、実際に確かめる」という姿勢そのものは、クラウドの自己点検や監査でも変わらず必要とされる力だからです。手順の中身は変わっても、確かめる習慣そのものは持ち込めます。

終わらない作業だからこそ、経験を積んだ人が長く関われる領域でもあります。設計の時点で終わる仕事ではなく、運用が続く限り価値が積み重なる仕事です。

積み上げてきたオンプレの経験は、クラウドで消えてなくなるものではありません。境界から層へ、サーバー単位から操作単位へ、人手から既定へ——変わるのは対象の粒度であり、経験そのものではないというのが、ここまで確かめてきた内容です。Remoguに集まる案件の90%以上がフルリモート可能です。場所に縛られず、この粒度の違いに向き合う案件を探せる環境でもあります。

自分の経験がどの粒度で通用するのか、次の一歩は案件の条件を実際に見比べてみることです。まずはRemoguに登録して、自分の設計経験に近いクラウド案件の条件を確かめてみましょう。

オンプレの経験だけでクラウド案件に参画できますか

権限設計や監視の考え方など、オンプレで培った土台はそのまま生きます¹。ただし、操作単位での権限設計など、粒度の違いを理解した状態で臨むほうが、参画後の板挟みを避けやすくなります⁶。

権限を絞りすぎると何が起きますか

本番環境で障害の切り分けをする場面で、操作を制限されたユーザーでは業務を進めることが難しくなる場合があります⁹。だからこそ、権限設定の厳密さを場面ごとに調整する設計が求められます⁸。

クラウド案件で何を確かめておくとよいですか

既定にする対策がIaCやテンプレートでどこまで組み込まれているかを確かめておくとよいでしょう¹²。加えて、継続的なアップデートへの対応がどう回っているかも見ておくと、参画後の板挟みを減らせます¹⁵。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」持ち込む前提（2026年）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」切り替える点（2026年）
＊3 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」範囲の決め方（2026年）
＊4 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」止める側（2026年）
＊5 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」最小権限（2026年）
＊6 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」粒度の違い（2026年）
＊7 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」数の違い（2026年）
＊8 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」一律にしない（2026年）
＊9 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」現場の板挟み（2026年）
＊10 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」2種類の統制（2026年）
＊11 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」作らない選択（2026年）
＊12 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」既定にする（2026年）
＊13 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」データ側の守り（2026年）
＊14 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」見えるようにする（2026年）
＊15 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」終わらない作業（2026年）
＊16 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」起きた後（2026年）
＊17 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」確かめ方（2026年）
＊18 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」置き場所（2026年）