独立して最初に受けた業務委託の仕事を終え、取引先を離れる日の打ち合わせでのことです。「管理者のアカウントが、まだ自分の名前のままですね」と言われました。組織の中でクラウドの基盤を担当していたころは、環境の持ち主が自分であることに何の問題もなかったはずです。クラウドエンジニアが独立するとき、取引先の環境をどこまで自分が抱え、何を手元に残せるのか、迷う人は少なくないでしょう。この記事の答えは一言で、取引先の環境は取引先に残し、自分は型だけを持ち運びます。

1. 組織の中のクラウド担当と、独立後の立場の違い

持ち主の感覚で成り立っていた組織の中

組織の中でクラウドの基盤を担当していると、アカウントの発行も、設定の変更も、運用の手順も、すべて自分の側にあります。何か変えたいときは自分で変え、記録も自分の頭と手元にたまっていきます。ここでは、この状態を「持ち主の感覚」と呼びます。

この感覚は、組織の中では合理的です。環境を一番よく知っている人が、環境のすべてを持っているからです。ただし、これは筆者の見立てですが、独立後もこの感覚のまま仕事を受けると、取引先の環境まで自分のものとして抱え込む形になりかねません。

冒頭の場面は、その行き着く先の一つです。作業が終わっても、管理者のアカウントが自分の名前のまま残っていると、離れる側も受け取る側も、どちらかが手間を負うことになります。

独立後は持ち物が二つに分かれる

独立して業務委託で仕事を受けると、持ち物は二つに分かれます。一つは取引先の環境に属するもので、アカウントと設定、管理担当者、利用を終えるときのデータの扱いです。もう一つは自分の手元に残るもので、テンプレートの型と確認の手順です。

前者は取引先の事業のための環境なので、持ち主は取引先です。後者は、取引先ごとの固有の情報を含まない形で自分が作るものです。この仕分けは筆者の見立てで、資料が定めた決まりではありません。

図の作成：Remogu編集部。筆者の見立てを整理したもので、統計データではありません

では、取引先の側に残るものと、自分の側に残るものを分ける手がかりは、どこにあるのでしょうか。次の節で、国の資料にある責任共有モデルの考え方から確かめます。

2. 責任共有モデルで見る、利用する側の責任の範囲

インフラ作業の在り方が変わったという認識

デジタル庁は、標準ガイドラインの附属文書で、政府情報システムにおけるクラウドサービスの適切な利用を扱っています。この文書は、環境構築と運用の自動化が進み、インフラ作業である構築・運用・保守の在り方そのものが変化していると述べています¹。

ただし、この文書は政府情報システム向けの整理です。民間企業の義務でも、フリーランスへの指示でもありません。ここでは、クラウドの運用の考え方を知る資料として借ります。この文書をもとに独立後の仕事が増えるかどうかを言うことはできません。

責任共有モデルと利用する側の責任の範囲

同じ文書は、責任共有モデルを次のように整理しています。クラウドが提供するものについてはクラウド事業者（CSP）が責任を負い、利用する側のシステムは、その利用についてのみ責任を負うという考え方です¹。

そのうえで、利用する側のシステムの責任は、業務アプリケーション・利用者端末・運用・クラウド利用における設定・アカウント等に限られると書かれています¹。基盤そのものではなく、基盤を使う側で決めることが、利用する側の持ち分です。

この区分で責任を分け合っているのは、クラウド事業者と、利用する側のシステムです。フリーランスと取引先の分担を決めた資料ではないため、その点を取り違えないようにします。

区分ごとに責任を持つもの

下の表は、デジタル庁の附属文書にある責任共有モデルの整理を、区分ごとに並べたものです。右の列には、この記事での読み方を添えています。政府情報システム向けの整理であることは、変わりません。

区分	責任を持つもの	この記事での読み方
クラウド事業者（CSP）	クラウドが提供するもの	利用する側が直接は触らない部分
利用する側のシステム	業務アプリケーション・利用者端末・運用・クラウド利用における設定・アカウント等	独立後に業務委託で触る部分。持ち主は取引先という見立て

出典：デジタル庁の基本方針（2025年5月27日改定）をもとに作成。政府情報システム向けの整理です

独立後に触る部分の持ち主

独立後に業務委託で触るのは、多くの場合、この表の利用する側のシステムに当たる部分です。アカウントの管理や設定の変更、運用の手順がそこに含まれます。ここは筆者の見立てですが、その持ち主は取引先だと考えると、残すものと持ち運ぶものを分けやすくなります。

組織の中のクラウド担当は、環境の持ち主と担当者を兼ねていました。独立すると、この二つが別の人になります。持ち主は取引先で、自分は取引先の環境で作業を任された外部の担い手です。

次の節からは、取引先に残すものを一つずつ見ていきます。まずは、最初に確かめたいアカウントと設定です。

3. 取引先に残すもの1：アカウントと設定

最小限の権限という考え方

デジタル庁の附属文書は、予防的統制の一つとして、担当する業務に必要な最小限の権限だけを利用者に与える最小権限の原則を挙げています¹。事故を起こしてから対処するのではなく、起きにくい形をあらかじめ作る考え方です。

この原則は、政府情報システムの統制の例として書かれたものです。独立者に渡す権限を最小限にしなければならない、という義務の形では書かれていません。状況に応じた調整があり得る点も、頭に置いておきたいところです。

そのうえで、筆者の見立てを加えます。外部の担い手として入るなら、作業に必要な範囲の権限を受け取り、それ以上は求めない姿勢が、取引先との信頼のもとになります。権限の渡し方そのものは、別の記事で詳しく扱っています。

アカウントの名義と最上位の権限は取引先に

アカウントの名義と、最上位の権限は、取引先が持つ形を基本に考えます。これは筆者の見立てです。環境は取引先の事業のためにあり、利用を続けるのも、やめるのも取引先だからです。

自分が受け取るのは、作業に必要な最小限の権限です。作業が終われば、その権限は返します。冒頭の場面のように、終わったあともアカウントに名前が残ると、返し忘れがあるのか、残してよいのかが取引先から見えなくなります。

図の作成：Remogu編集部。筆者の見立てを整理したもので、統計データではありません

設定は取引先の環境に残す

設定も同じ考え方で整理できます。取引先の環境にある設定の値や、認証に使う情報は、取引先の環境の一部です。自分の手元に控えを置かず、取引先の側で管理してもらいます。

自分の手元に残すのは、設定の値ではなく、設定を決めるときの考え方や確認の手順です。その型は、あとの節で扱います。次の節では、取引先に残すもののうち、管理担当者と利用終了時のデータを確かめます。

4. 取引先に残すもの2・3：管理担当者と利用終了時のデータ

管理担当者を取引先の中に置く

IPAの中小企業向けの手引きは、クラウドサービスを利用する側の確認ポイントを示しています。運用するときの確認として、クラウドサービスの特性を理解した管理担当者を社内に確保しているかを挙げています²。

これは、中小企業が自分の組織の中で確かめる項目です。独立者を管理担当者にしてはいけない、とは書かれていません。そこで、取引先の中に名前のある担当を置いてもらう形を望ましいと見るのは、筆者の見立てです。

理由は、環境の変更や止まったときの判断を、最終的に引き受ける人が取引先の中にいるほうが、話が早く進むからです。外部の担い手が離れても、取引先の側で環境を回し続けられます。

利用終了時のデータの扱い

同じ手引きは、利用する側の確認として、サービスの利用が終了したときのデータの取扱い条件を確認したかを挙げています。例として、全データの返却や残留データの消去などが示されています²。

この項目は、クラウドサービスの利用を終えるときの確認です。独立者が取引先を離れるときの手順を定めたものではありません。ここでは、離れるときの引き渡しを考える手がかりとして借ります。

手引きの確認項目と、取引先に残しておきたい形

下の表は、手引きにある二つの確認項目と、独立者として取引先に残しておきたい形を並べたものです。真ん中の列は手引きの中身、右の列は筆者の見立てです。二つの列を混ぜないように、分けて示します。

確認項目	手引きにある中身	取引先に残しておきたい形（見立て）
管理担当者	クラウドサービスの特性を理解した管理担当者を社内に確保しているか	取引先の中に、名前のある担当を置いてもらう
利用終了時のデータ	全データの返却・残留データの消去などの取扱い条件を確認したか	データの置き場所と返し方を、取引先の側で決めておいてもらう

出典：IPA「中小企業のためのクラウドサービス安全利用の手引き」（2026年6月）をもとに作成。右の列は筆者の見立てです

取引先に残すものは、アカウントと設定、管理担当者、利用終了時のデータの三つに整理できました。では、自分の手元に持ち運べるものは何でしょうか。次の節で、その型を確かめます。

5. 自分で持ち運ぶ型：テンプレートと手順

テンプレートで人為的なミスを減らす

デジタル庁の附属文書は、あらかじめセキュリティ対策の設定を組み込んだテンプレートを使うことで、人為的なミスを減らせるとしています¹。毎回、手で設定を重ねるよりも、決まった形から始めたほうが、抜けや間違いが入りにくいという考え方です。

この文書が述べているのは、ミスを減らせるところまでです。テンプレートを持ち運べば、独立後に仕事が取れるとは述べていません。型を持つ意味は、仕事の取りやすさではなく、どの取引先でも同じ確かさで作業を始められる点にあります。これは筆者の見立てです。

持ち運ぶ型の中身

持ち運ぶ型は、三つに分けて考えられます。取引先の固有の情報を含まないテンプレートの雛形、作業の前後に確かめる手順、そして点検の観点です。どれも、特定の取引先の環境を知らなくても書ける内容にします。

この型は、独立後に自分で作るものです。取引先の環境で作業をしながら、毎回同じ形で使えるところだけを取り出し、固有の名前や値を抜いて雛形にしていきます。最初から完成した型を持っている必要はありません。

一方で、組織の中で作ったものは、その組織のものとして残します。独立後の型は、自分の言葉で書き直し、自分の観点で組み立て直したものを指します。

持ち運ばないもの

反対に、持ち運ばないものもあります。取引先の設定値、認証に使う情報、データは、取引先の環境に属します。取引先のために書いたコードは、権利の扱いを契約で決めておく対象です。権利の考え方に踏み込まず、書き手の立場では、契約で決めると押さえるにとどめます。

図の作成：Remogu編集部。筆者の見立てを整理したもので、統計データではありません

型の側に置くものと、取引先に置いていくものが分かれたら、次に取り決めの場面を考えます。

6. 受ける前に取り決めておくこと

仕事を受ける前の取り決めの範囲

取引先に残すものと、自分が持ち運ぶものは、頭の中で分けているだけでは不十分です。仕事を受ける前に、取引先とのあいだで言葉にしておくと、冒頭の場面のような食い違いを避けやすくなります。これは筆者の見立てです。

取り決めの項目は、ここまで整理した三つの残すものと、持ち運ぶ型の扱いから出てきます。細かい条件は取引先ごとに違いますが、決めておきたい論点は共通しています。

決めておく6つの項目

下の表は、受ける前に決めておきたい項目を、具体例とともに並べたものです。右の列には、その項目を決めておく理由を筆者の見立てとして添えています。資料が定めた必須の項目ではありません。

決めること	取り決めの例	決める理由（見立て）
アカウントの名義と最上位の権限	誰が持つか	離れるときに返す相手を明らかにするため
自分に渡す権限	権限の範囲と、返す時期	作業に必要な範囲に絞り、返し忘れを防ぐため
クラウド利用料の請求先	取引先の名義で支払う形かどうか	名義を取引先に置くと、アカウントを返しやすいため
管理担当者	取引先の中の担当者の名前	環境を引き受ける人を取引先の中に置くため
作ったテンプレートやコードの権利	契約での扱い	取引先のために書いたものの扱いを後で争わないため
離れるときに引き渡すもの	手順書、構成の記録	取引先が自分で環境を回せる状態で終えるため

出典：Remogu編集部の見立てをもとに作成。資料が定めた項目ではありません

クラウド事業者からの出口とは別の話

この表の取り決めは、取引先と自分のあいだの話です。取引先がクラウド事業者を乗り換えるときの出口の考え方は、別の記事で扱っています。ここでは、独立した外部の担い手として、取引先の環境をどう預かり、どう返すかに絞ります。

そのため、請求先や権限の返し方のように、仕事を受ける前に決められるものから順に話すのが現実的です。決まらない項目があれば、その仕事を受けるかどうかを考える材料にもなります。

取り決めの項目がそろったところで、独立までの順番を整理します。

7. 独立までの順番

持ち物の仕分けから契約まで

独立までの順番は、四つに分けられます。まず、組織の中で自分が持っていたものを書き出します。アカウント、設定、運用、手順のどれを、どこまで自分で抱えていたかを、自分の言葉で並べます。

次に、書き出したものを、取引先に残すものと、持ち運ぶ型に仕分けます。仕分けの目安は、これまでの節で見てきたとおりです。環境そのものは取引先に残し、考え方と手順を型として手元に置きます。

三つ目は、型を固有の情報のない形で作り直すことです。ここは、独立してから取引先の環境で作業をしながら進めてかまいません。最後に、仕事を受ける前に、表3の項目を取引先と取り決めます。

図の作成：Remogu編集部。筆者の見立てを整理したもので、統計データではありません

冒頭の場面に戻って

冒頭の場面を思い出してください。離れる日の打ち合わせで、管理者のアカウントが自分の名前のまま残っていました。あの場面は、組織の中の持ち主の感覚のまま仕事を受けると起こりやすい食い違いです。四つの順番を踏んでおけば、あの日の打ち合わせは確認だけで終わります。

取引先の環境は取引先に残し、自分は型だけを持ち運びます。環境の持ち主ではなく、環境を預かる外部の担い手として入ると、離れるときに返すものが明らかになり、次の取引先でも同じ型で作業を始められます。

Remogu（株式会社LASSIC運営）は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です。まず登録して、自分の経験に近い条件の案件を眺めてみてください。取引先に残すものと持ち運ぶ型を頭に置いたまま見ると、案件の条件の読み方が変わります。

8. よくある質問

AWS・Azure・Google Cloudのどれか一つの経験でも独立できますか

この記事で整理した、責任の分け方と、残すものと持ち運ぶ型の考え方は、クラウドの種類を問いません。これは筆者の見立てです。アカウントと設定、管理担当者、利用終了時のデータは、どのクラウドでも取引先に残す対象になります。

そのため、一つのクラウドの経験でも、型の作り方は他のクラウドに生かせます。特定のクラウドの優劣は、この記事では扱いません。

クラウドの利用料を自分で立て替えることはありますか

立て替えるかどうかは、契約で決める事柄です。筆者の見立てでは、請求を取引先の名義にしておくと、離れるときにアカウントを返しやすくなります。表3の請求先の項目で、受ける前に確かめておきたいところです。

独立前に組織の中で準備しておけることは何ですか

組織の中で作ったものは持ち出さず、自分の言葉で手順や観点を整理しておく準備が考えられます。これも筆者の見立てです。何をどの順で確かめるかを自分の言葉で書いておくと、独立後に型を作るときの出発点になります。

独立の手続きそのものは、別の記事で扱っています。この記事では、取引先に残すものと持ち運ぶ型の整理に絞りました。

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

出典・参考情報

＊1 デジタル庁「クラウドサービスの適切な利用」（2025年5月27日・2026年10月確認）
＊2 独立行政法人情報処理推進機構「中小企業のためのクラウドサービス安全利用の手引き」（2026年6月・2026年10月確認）