LASSIC Media らしくメディア

2026.10.27 らしくコラム

Google Cloud導入支援で頼める5つの作業と選び方

監修・編集責任者:牛尾 昭昌(株式会社LASSIC 執行役員)

窓ぎわでタブレットのクラウドの構成図を見ながら外部に頼む作業を考える情報システムの課長

この記事の結論

  • Google Cloud導入支援は、組織とID、権限、課金、フォルダとプロジェクト、ログとネットワークを使い始める前に整える支援です。
  • 新しい組織ではドメイン全体にプロジェクトを作る権限が与えられているため、権限の見直しと階層の設計が最初の要になります。
  • 支援会社はパートナーの区分を目安にしつつ、特権管理者の扱いと引き渡し後の見直しの手順まで確かめて選びます。

※ 本記事は2026年10月時点の公式情報(省庁・公的機関、および製品やサービスを提供する事業者が公開している資料)に基づきます。

Google Workspaceは使っているが、Google Cloudは何から設定すればよいのか分からない。部署ごとにプロジェクトを作り、どこで何が動いているのか分からない——。初めてGoogle Cloudを業務で使う会社では、こうした戸惑いが起こりがちです。Google Cloud導入支援は、使い始める段階で、組織とID、権限、課金、プロジェクトの分け方といった土台づくりを外部の専門家と進める支援です。

土台を先に整えれば、後の移し替えを減らせます。ただし万能ではなく、任せきりにすると権限や課金の持ち方を社内で説明できなくなります。本記事では、初めてGoogle Cloudを使う会社の情報システムの担当者に向けて、導入支援で頼める5つの作業、組織・フォルダ・プロジェクトの関係、導入の進め方、そして外部に頼むときに確認したい点を整理します。

Google Cloud導入支援とは

Googleは、Google Cloudでシステムを動かす前に、管理者が「Google Cloud の設定」というガイド付きの手順で基盤を整えることを勧めています。基盤とは、資源を整理し管理するための基本の設定です。*1 基盤は、目的に合わせて次の3つから選びます。

  • 概念実証:大きな契約の前に試すための軽い基盤で、組織と課金の作業が中心です
  • 本番環境:セキュリティと規模の拡大を考えた基盤で、ガイドの作業をすべて行います
  • 強化されたセキュリティ:本番環境の作業に、暗号鍵の管理の設定を加えた基盤です

Googleの導入の手引き(Google Cloud Adoption Framework)は、クラウドへの備えを「学ぶ・率いる・広げる・守る」の4つのテーマで整理し、「学ぶ」に経験のあるパートナーの力で社内のIT部門を補うことを含めています。*2 導入支援は、主に本番環境の基盤づくりを外部の専門家と進める支援です。

導入支援で頼める5つの作業

Google Cloudの設定の手順をまとめると、導入支援で頼める作業は次の5つです。どれもシステムを載せる前に済ませる部分です。

夜の自席でモニターの階層の図の枠をマウスで選ぶ手元

Google Cloud導入支援で頼める5つの作業
作業 中身 社内で決めること
1. 組織とIDの準備 Cloud IdentityかGoogle Workspaceを会社のドメインにつなぎ、ドメインの所有を確かめて組織を作る 特権管理者を誰にするか
2. 管理者グループと権限 組織の管理者や課金の管理者のグループを作り、IAM(権限を管理する仕組み)のロールを割り当てる 誰をどのグループに入れるか
3. 課金の設定 請求先アカウントを作るか既存のものをつなぎ、予算の通知を置く 支払い方法と通知の受け取り手
4. フォルダとプロジェクトの設計 フォルダを作ってプロジェクトを置き、推奨される組織のポリシーを当てる 環境で分けるか、部署やチームで分けるか
5. ログとネットワークの土台 監査ログを1か所に集め、共有VPC(複数のプロジェクトで使う共通のネットワーク)を作る ログの保存期間と使う地域(リージョン)

Googleは、組織で使う請求先アカウントを1つにすることを勧めています。ログは何もしなければ30日間の保存で、大規模な企業には365日間の保存を勧めています。*1 30日を超える保存には料金がかかるため、どこまで残すかを最初に決めておきます。

組織・フォルダ・プロジェクトの関係

Google Cloudでは、資源を組織・フォルダ・プロジェクトの階層で整理します。組織を使うにはGoogle WorkspaceかCloud Identityのアカウントが必要で、1つのアカウントに1つの組織が結び付きます。*3

Google Cloudの管理の単位と導入時に決めること
単位 役割 導入時に決めること
組織 会社全体を表す最上位の単位。ここで与えた権限と組織のポリシーは下のすべてに受け継がれる 組織の管理者を誰にするか
フォルダ 部署や環境ごとにプロジェクトを束ねる単位。管理の権限を部署の責任者に任せられる 何で分けるか、何段にするか
プロジェクト サービスやAPIを有効にし、課金と権限を管理する基本の単位 名前の付け方と持ち主
請求先アカウント どのプロジェクトの費用を誰が払うかを決める どのプロジェクトをつなぐか

新しい組織では、最初からドメイン全体の利用者に、プロジェクトを作る権限と請求先アカウントを作る権限が与えられています。*3 導入支援では、この権限を誰に残すかを早い段階で見直します。また、請求先アカウントとプロジェクトのつながりは支払いの関係にとどまり、プロジェクトが請求先アカウントの権限を受け継ぐことはありません。*4

組織を使うと、プロジェクトは作った社員ではなく組織のものになり、社員が退職しても残ります。*3 AWSやAzureとの比較はAWS導入支援の範囲と支援会社の選び方とAzure導入支援で頼める範囲が参考になります。

導入支援の進め方

初めてGoogle Cloudを使うときは、次の4つのステップで進めると、プロジェクトを後から移し替えずに済みます。

  • ステップ1:基盤の型を選ぶ。試すだけなら概念実証、業務のシステムを載せるなら本番環境を選びます
  • ステップ2:組織と権限を整える。ドメインの確認、管理者グループ、請求先アカウントまでを済ませます
  • ステップ3:階層と共通の土台をつくる。フォルダとプロジェクト、組織のポリシー、ログ、ネットワークを設定します
  • ステップ4:費用と見直しの仕組みを置く。予算の通知と、設計を点検する場を決めます

Google Cloud導入支援の4つのステップを左から順に並べた流れ図。STEP1 基盤の型を選ぶ、STEP2 組織と権限を整える、STEP3 階層と共通の土台をつくる、STEP4 費用と見直しの仕組みを置く。

選んだ構成は、Terraform(設定をファイルで管理する道具)の構成ファイルにまとめられ、そのまま展開することも、取り出して手直しすることもできます。*1 引き渡し後のファイルの持ち主も決めておきます。考え方はクラウド基盤のランディングゾーン構築にまとめています。

ステップ4の予算は、費用が予算の一定の割合を超えると通知メールを送る仕組みで、初めは予算の半分・9割・予算額の3つの時点に置かれます。予算を作っても、使用量や支出に上限がかかるわけではありません。*5 設計の点検には、セキュリティ・信頼性・費用の最適化など6つの柱で見直すGoogle Cloud Well-Architected Frameworkが使えます。*6

外部に頼むときに確認しておきたい点

Googleは、基盤となるネットワークとインフラはクラウドの提供者が、アクセスの方針とデータは利用する側が、常に責任を負うと説明しています。*7 権限を誰に与えるかを決める責任は自社に残るため、見積もりの前に次の点を確かめます。

会議室でタブレットを差し出して受け渡す2人の手元

  • 特権管理者の扱い:Cloud Identityの特権管理者を誰が持ち、作業中に支援会社へどこまでの権限を渡すか
  • 設計の文書:フォルダとプロジェクトの分け方、グループと権限の割り当て表を設計書として残すか
  • 既存のアカウントとの関係:社員が個別に作ったプロジェクトや、すでに使っているGoogle Workspaceをどう扱うか
  • 費用の通知:予算のしきい値と通知先、超えたときに判断する人を決めるか
  • 引き渡し後の見直し:構成ファイルの持ち主と、設計を点検する間隔を決めるか

支援会社を探す手がかりには、Google Cloudのパートナーの区分があります。実績の幅を示すSelect・プレミア・ダイヤモンドの3段階と、インフラストラクチャやセキュリティなどの分野ごとのコンピテンシーです。*8 区分は目安にとどめ、上の5点に具体的に答えられるかで選びます。費用の見直しはGCPコスト最適化をCUD/BigQuery診断で外注する進め方で扱っています。

まとめ:Google Cloud導入支援で確かめておきたい3つの点

Google Cloud導入支援を頼むうえで、確かめておきたい点は3つに整理できます。第一に、Cloud IdentityとGoogle Workspaceのどちらで組織を作り、特権管理者を誰が持つかを決めること。第二に、プロジェクトを作る権限を見直し、フォルダとプロジェクトの分け方を設計書に残すこと。第三に、予算の通知とログの保存期間を、使い始めた後に誰が見て判断するかを決めておくことです。この3点を踏まえておけば、「誰が何を作ったのか分からない」という事態を避けやすくなります。土台の設計に迷いがあれば、外部の手を借りるのも一つの選択肢です。

LASSICに相談するメリット

LASSICは2006年の創業以来、システムの運用・保守に特化したプライム(一次請け)のシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。日本ニアショア開発推進機構の認定ベンダーとして、全国のリモート人材による開発・運用の体制を整えています。

Cloud IdentityまたはGoogle Workspaceと組織リソースのつなぎ方、特権管理者の持ち方を最初に決め、IAMのロールはグループ単位で必要な階層に絞って割り当てます。フォルダの分け方、共有VPCのホストプロジェクト、ログバケットの保存期間は運用体制を見て決め、構成はTerraformで管理します。引き渡し前に権限と予算の通知を確かめ、運用ではWell-Architected FrameworkとRecommenderの推奨をもとに見直しを提案します。

よくある質問

Google Workspaceを使っていなくても組織を作れますか

作れます。Cloud Identityの無料版を設定し、会社のドメインの所有を確かめると、Google Cloudの組織が自動で作られます。*1 ドメインの設定を変えられる担当者を先に確かめておきます。

ドメインの確認にはどのくらい時間がかかりますか

確認が終わるまでに数時間かかることがあります。*1 確認が済むまで組織は作られないため、導入の初日にドメインの設定を変えておくと、その後の作業を待たずに進められます。

予算を超えたら自動で止める設定はありますか

予算の機能そのものには、使用量に上限をかける働きはありません。費用の発生を抑えたい場合は、APIの使用量に上限を設ける方法が別に案内されています。*5

Google Cloudの使い始めの土台づくりのご相談

組織とIDの準備、権限と課金の設計、フォルダとプロジェクトの分け方から見直しまで、元請(プライムベンダー)としてご提案します。

2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。

無料相談はこちら

出典

  1. *1 参考:Google Cloud ドキュメント「Google Cloud の設定のガイド付きフロー」(https://cloud.google.com/docs/enterprise/setup-checklist?hl=ja)。出典:3つの基盤オプション、組織・ユーザーとグループ・管理者権限・課金・階層とアクセス・セキュリティ・ロギング・ネットワークの各タスク、請求先アカウントを1つにする推奨、4つの階層の型、ログの既定の保存期間(30日)と365日の推奨、Terraform構成ファイル、ドメイン確認の所要時間の記述を参照(2026年10月確認)
  2. *2 参考:Google Cloud「Google Cloud Adoption Framework」(ホワイトペーパー)(https://services.google.com/fh/files/misc/google_cloud_adoption_framework_whitepaper.pdf)。出典:Learn・Lead・Scale・Secureの4つのテーマと、経験のあるパートナーでIT部門を補う記述を参照(2026年10月確認)
  3. *3 参考:Google Cloud ドキュメント「リソース階層について」(https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy?hl=ja)。出典:組織・フォルダ・プロジェクトの役割、Google WorkspaceまたはCloud Identityのアカウントと組織の関係、新しい組織の最初の許可ポリシー、社員の退職後もプロジェクトが組織に残ることの記述を参照(2026年10月確認)
  4. *4 参考:Google Cloud ドキュメント「Cloud Billing の概要」(https://cloud.google.com/billing/docs/concepts?hl=ja)。出典:請求先アカウントとプロジェクトの支払いリンク、プロジェクトが請求先アカウントの権限を継承しないことの記述を参照(2026年10月確認)
  5. *5 参考:Google Cloud ドキュメント「予算と予算アラートの作成、編集、削除」(https://cloud.google.com/billing/docs/how-to/budgets?hl=ja)。出典:予算アラートのメール通知、既定の3つのしきい値、予算が使用量や支出の上限を設定しないこと、API使用量の上限設定の案内を参照(2026年10月確認)
  6. *6 参考:Google Cloud ドキュメント「Google Cloud Well-Architected Framework」(https://cloud.google.com/architecture/framework?hl=ja)。出典:オペレーショナルエクセレンス、セキュリティ、信頼性、費用の最適化、パフォーマンスの最適化、サステナビリティの6つの柱を参照(2026年10月確認)
  7. *7 参考:Google Cloud ドキュメント「Google Cloud における責任と運命の共有」(https://cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate?hl=ja)。出典:基盤となるネットワークとインフラはクラウドプロバイダが、アクセスポリシーとデータはお客様が常に責任を負うとの記述を参照(2026年10月確認)
  8. *8 参考:Google Cloud「Google Cloud パートナー ネットワーク」(https://cloud.google.com/partners?hl=ja)。出典:Select・プレミア・ダイヤモンドの3段階と、コンピテンシーの区分の記述を参照(2026年10月確認)




View