GCPエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのGCPエンジニアがつまずきやすいのは、費用の責任があいまいなままリソースを作ること、組織のポリシーで作業が止まること、権限を広く持ちすぎること、移行や障害対応での稼働の膨らみです。どれも、Google Cloudでは一つの設定が請求や組織全体に直結しやすいことと、外部の立場で一人で判断を抱えやすいことから起きます。

対策の基本は、つまずきの種を契約と参画初期の取り決めで小さくしておき、現場では変更の記録と早めの共有で自分を守ることです。この記事では、契約・現場・技術・お金の順に、GCPエンジニアならではの場面と対策を整理します。独立前の準備はGCPエンジニアがフリーランスになるにはで扱っているので、ここでは「参画してから起きやすい場面」に絞ります。

契約でのつまずき

「GCP環境の構築」の中身が人によって違う

契約書には「Google Cloud環境の構築支援」とだけ書かれ、現場ではネットワーク、IAM、CI/CD、監視、データ基盤の権限設計まで期待されていた、という食い違いはよく起きます。Google Cloudの仕事は隣のチームとの境目があいまいで、引き受けた範囲が少しずつ広がりやすいのが特徴です。

対策：参画前に、担う範囲（例：プロジェクトとIAMの設計、Terraformのコード、監視の設定）と、担わない範囲（例：アプリのコード、BigQueryの分析用のSQL）を言葉で確かめておきます。範囲の外の依頼が来たときの扱いは業務範囲が変わったときの記事をご覧ください。

費用や障害の責任を背負わされそうになる

作ったリソースの請求が想定より膨らんだ、設定の変更で障害が起きた、といったときに「構築した人の責任」と言われることがあります。準委任契約で参画している場合、約束の中身は業務を専門家として通常求められる注意を払って行うことですが、契約書の書き方によっては責任の範囲が広く読めることもあります。

対策：署名の前に、損害賠償の範囲や上限についての条項を読み、気になる文言はエージェントや発注側に確かめます。考え方は損害賠償の上限の記事で解説しています。判断に迷う場合は弁護士などの専門家に相談するのが安全です。

指揮命令の形が社員と変わらなくなる

発注側の社員と同じチャットや当番表に入り、作業の手順や勤務時間まで細かく指示されるようになると、準委任の契約と実態がずれてきます。考え方は偽装請負の記事で整理しています。

現場でのつまずき

組織のポリシーで作業が止まる

Google Cloudでは、組織の管理者が組織のポリシーで、サービスアカウントの鍵の作成や、外部のアカウントへの権限付与などを制限できます。2024年5月3日以降に作られた組織では、サービスアカウントの鍵の作成やアップロードの禁止、ドメインによるアカウントの制限などが既定で有効になっています（2026年10月時点、Google Cloudのドキュメントによる）。前の現場の手順どおりに鍵を作ろうとして止まる、外部のアカウントを追加できない、といった場面はここから起きます。

対策：参画の初期に、組織のポリシーで何が制限されているかを確かめ、例外が必要なときの申請先と承認の流れを把握しておきます。鍵を使わない認証の方法に切り替えられないかを先に考えると、例外の申請そのものを減らせます。

変更の影響を説明しないまま反映する

階層の上でIAMや組織のポリシーを変えると、下のすべてのプロジェクトに影響します。外部のエンジニアが説明の足りない変更を入れると、問題が起きたときに真っ先に疑われます。

対策：変更はTerraformのコードとレビューを通して入れ、影響するプロジェクトとチームを一言添えます。Google Cloudでは、設定の変更などの管理アクティビティの監査ログは常に書き込まれ、無効にできません（Google Cloudのドキュメントによる）。記録は残る前提で、変更の理由を自分の側でも残しておくと、説明を求められたときに困りません。

隣のチームの依頼を全部引き受ける

データ分析やアプリ開発のチームから「権限をください」「この環境を作ってください」と直接頼まれ、窓口を通さずに対応し続けると、作業量も責任も見えないまま増えていきます。

対策：依頼の受け口をチケットなどに一本化し、発注側の窓口が優先度を決める形にしてもらいます。参画初月の進め方はGCPエンジニアの参画初月にやることで整理しています。

技術でのつまずき

権限を広く持ちすぎる

作業を早く進めたいあまり、オーナーや編集者のような広いロールを付けてもらうと、意図しない変更をしてしまったときの影響が大きくなります。外部の立場では、広い権限を持っていること自体が疑いの種にもなります。

対策：作業に必要な権限だけを付けてもらい、強い権限が要る作業は期間を区切って依頼します。権限の付け方を最小限にする考え方は、そのまま面談で話せる実績にもなります。

前のクラウドや現場の作り方を持ち込む

AWSや他の環境の経験が長いと、アカウントの分け方やネットワークの作り方をそのまま当てはめたくなります。Google Cloudでは、プロジェクトと階層で権限と費用を管理し、ネットワークを複数のプロジェクトで共有する構成もあるため、同じ作り方が合わないことがあります。

対策：既存の構成がなぜそうなっているかを先に聞き、変えるときは違いを説明したうえで提案します。他のクラウドとの違いはGCPで求められるスキルの記事で整理しています。

お金でのつまずき

予算を設定すれば費用は止まると思い込む

Cloud Billingの予算は、アラートだけの設定では利用や請求を自動で止めません（Google Cloudのドキュメントによる）。検証のつもりで作ったリソースや、重いBigQueryのクエリで請求が膨らみ、誰の責任かが問題になることがあります。

対策：検証用のリソースは作る前に費用の扱いを担当者と決め、終わったら消す手順まで用意します。ラベルを付けて、自分が作ったものを後から特定できるようにしておくと安心です。

移行の切り替えや障害対応の稼働が精算されない

切り替えの夜間作業や、障害の発生時の対応で稼働が延びても、精算の取り決めがないと報酬に反映されないことがあります。

対策：精算幅の上限を超えたときの扱いと、夜間・休日の作業の有無を、契約の段階で確かめます。考え方は精算幅の記事をご覧ください。

構築の完了で契約が突然終わる

構築や移行が終わると、運用は社内のチームが引き取り、契約が終わることがあります。フリーランス法では、6か月以上の業務委託を解除したり更新しなかったりする場合、発注側は少なくとも30日前までに予告することになっています（2026年10月時点、公正取引委員会の案内による）。詳しくは契約解除の予告の記事で解説しています。

対策：構築の終わりが見えてきた段階で、運用の引き継ぎに残るのか、契約を終えるのかを早めに相談し、次の案件探しを並行して始めます。

よくある質問

参画してから、聞いていた範囲より広い作業を頼まれました。どうすればよいですか？

まず、頼まれた作業が契約の業務範囲に入るかを確かめます。入らない場合は、引き受けるかどうかと、引き受けるなら稼働や報酬の扱いをどうするかを、エージェントや発注側の窓口と話し合ってください。その場で引き受けて既成事実にしないことが大切です。

自分の設定変更で障害が起きたら、損害賠償を求められますか？

契約の形と条項、変更までの手順によって変わるため、一概には言えません。レビューと承認を経た変更だったか、手順に沿っていたかは、話し合いの材料になります。個別の判断は弁護士などの専門家にご相談ください。

組織の管理者権限を渡されそうになったら、受けたほうがよいですか？

作業に本当に必要かを先に確かめることをおすすめします。必要な場合でも、期間や対象を区切り、作業が終わったら外してもらう形にすると、自分を守ることにもつながります。