クラウドアカウントを会社で管理する。外注先から最初に受け取る権限

クラウドアカウントを会社で管理するには、外注先から管理者のIDとパスワードだけを受け取っても足りません。僕なら、まず契約主体と請求を会社へ戻し、次に会社管理の連絡先で最上位の管理権限を確保し、最後に復旧メールと電話を確かめます。旧管理者を外すのは、その後です。

受領完了の基準は、会社側が自力で請求を確認し、通常の管理作業を行い、緊急時には復旧へ進めることです。「設定を変更した」という報告に加えて、各操作の証拠をそろえれば、非エンジニアの経営者でも判定できます。ただし、請求できる状態とシステムを管理できる状態は別物です。この二つをどう分けて受け取るかが、引き継ぎの要点です。

クラウドアカウントの会社管理は、契約・請求から始めます

最初の確認対象は、支払責任を負う法的主体と、請求書類・支払手段を扱う人です。サービス上の表示名だけでは判定しません。外注先による立て替え、担当者個人の支払い情報、会社側が閲覧できない請求書のいずれかが残る間は、管理者権限の移管も継続中と扱います。

製品固有の公式仕様で見ると、Google CloudではCloud Billing accountが対象リソースの支払者を定めます。関連するGoogle payments profileは請求に責任を負う法的主体を表し、主体の種別・名称・住所などを保持します。Google payments accountには支払方法、請求サイクル、書類送付先が保持されます。Google CloudのCloud Billing概要で、2026年9月21日時点に確認できる仕様です。

ここで迷いやすいのが、請求を会社名義へ変えれば、クラウド全体も会社所有になったと考えてよいかです。請求名義だけでは足りません。同じ公式資料では、Organization・Cloud Billing account・projectの間に、IAM権限の継承を表すownershipと、どの請求アカウントがprojectの料金を支払うかを表すpayment linkageがあり、両者は別の関係だと説明されています。異なるOrganizationが所有するprojectを、別のOrganizationが所有するCloud Billing accountで支払う構成も可能です。

請求情報だけで「会社管理になった」とする判定は早計です。請求主体が外注先のまま管理権限だけを受け取ると、支払者と管理者の違いが引き継ぎ資料から消えてしまいます。そこで僕は、まず法的主体の名称と住所、対象の請求アカウント、請求書類を閲覧できる会社側担当者を確認し、その後に管理権限へ進む順番を提案します。公式仕様を根拠に組み立てた実務上の受領順であり、Google Cloudが指定する移管手順ではありません。

確認資料には、法的主体の名称・住所が分かる画面または書類、対象の請求アカウントを識別できる画面、会社側の閲覧者が分かる権限画面を残します。カード番号などの秘密情報は台帳へ転記せず、適切な保管先で扱います。経営者は、会社が支払責任と請求書類を管理できる状態かを、この三つの資料で判定します。

最上位の管理権限は、会社の入口で受け取ります

請求を確認したら、会社管理のドメインまたはグループメールを入口にして、最上位の管理権限を確保します。「外注先から管理者を一人追加してもらった」だけでは、外注先が持つ上位権限や、アカウント全体の入口が会社へ移ったか分かりません。

AWSでは、アカウント作成時のroot userが、アカウント内の全AWSリソースへ完全なアクセス権を持つ既定の認証主体です。同時にAWSは、日常作業では別の管理ユーザーを作ることを推奨しています。AWSのroot userに関するベストプラクティスで、2026年9月21日時点に確認できる内容です。つまり、会社は最上位の入口を保持しつつ、普段の作業には通常用の管理権限を使う、という二層を分けて確認する必要があります。

Google Cloudでは、Organizationリソースがリソース階層のルートです。Google WorkspaceまたはCloud Identityのドメインに関連付けると自動作成され、初期アクセスは各ドメインのsuper administratorが担います。そのうえで、Organization Administratorロールをユーザーまたはグループへ付与して運用権限を委任できます。Google CloudのOrganization設定手順で、2026年9月21日時点に確認した仕様です。

製品ごとにボタン名は違っても、受領条件は共通化できます。外注先を外す前に、対象のアカウントやOrganizationが識別済みで、会社管理のメールまたはドメインが最上位の入口を保持し、会社側担当者が通常用の管理権限で実際にログイン済みであることです。確認資料は、対象識別子、会社側管理者へのロール付与画面、会社管理メールへの通知到達記録にします。AWSとGoogle Cloudの仕様を組み合わせた、僕の実務提案です。

技術担当と経営者の間で「最上位」の意味がずれる場合は、権限名だけを会議へ持ち込まないことです。誰が契約を引き継ぎ、誰が通常運用を行い、誰が緊急復旧を承認するかまで、経営の言葉に直します。この役割が社内で空いている場合は、経営と技術をつなぐ人がいないと、会議は決まらないで、判断材料を決裁できる形へ整える考え方も確認できます。

受領台帳は、四つの状態と証拠を分けます

引き継ぎ表を「アカウント名、ID、パスワード」の一覧にすると、請求責任と復旧経路が抜けます。僕なら、一つのクラウド環境につき次の欄を持つ受領台帳を作ります。値そのものだけでなく、誰が、何を見て、受領済みと判定したかを残す台帳です。

• 契約主体：会社の正式名称と住所、確認した画面または契約書類、確認担当者
• 請求主体：請求アカウントの識別子、支払書類の会社側閲覧者、確認した画面
• 最上位管理者：対象のアカウントまたはOrganizationの識別子、会社管理のメールやドメイン、権限付与画面
• 通常管理者：会社側担当者、付与された管理ロール、ログイン確認記録
• 復旧メール：会社管理の受信先、通知が届いたことの確認記録
• 復旧電話：会社管理下の番号、製品の公式手順に沿って利用可能と確認した記録

六欄は情報収集のための一覧ではなく、契約主体、請求主体、最上位管理者、復旧手段を別々に判定するチェック欄です。一欄でも外注先や退職者の個人情報に依存していれば、引き継ぎは継続中と扱います。

条件例を具体化します。請求書は会社が閲覧でき、通常管理者も会社側へ付与された一方、最上位の入口に使うメールだけが外注先のアドレスだったとします。この場合、日常作業はできても受領完了ではありません。反対に、最上位の入口だけ会社が持ち、会社側担当者が通常用の管理権限でログインできなければ、毎日の運用をroot userなどへ寄せることになります。公式仕様が勧める権限の分離にも合いません。両方の条件を満たして初めて、管理権限の欄を受領済みにします。

台帳の確認資料は、後任者が同じ結論をたどれる粒度にします。スクリーンショットだけでは対象や撮影理由が分からなくなるため、対象識別子、確認日、確認者、判定を添えます。結論だけでなく判断の根拠を残す考え方は、CTO代行を入れた後の意思決定の測り方にもつながります。

復旧を会社だけで始められたら、旧権限を外します

最後は、平常時のログインに加えて復旧可能性を判定します。AWSはroot userに会社管理のグループメールアドレスを使うことを推奨し、復旧のためにその受信箱へアクセスできること、登録電話番号とメールを最新かつ利用可能に保つことを求めています。すべてのMFAを失った場合には、登録電話番号とメールの両方が必要になると説明しています。2026年9月21日時点のAWS公式仕様です。

以上から導く完了条件は明快です。外注先や退職者の個人連絡先を使わず、会社管理の復旧メールと電話で、製品の公式手順に従って復旧開始に必要な段階へ進めることです。確認記録を台帳へ残してから、外注先の旧権限を削除します。AWSの要件を根拠にした条件例であり、Google Cloudを含む各製品の復旧操作が同じだという意味ではありません。実際の手順は、移管時点の各公式仕様で再確認してください。

旧権限を削除する条件は、外注先への依存が消えたと四つの状態から確かめられることです。契約・請求は会社が責任を負い、書類を閲覧できる状態にします。最上位の入口は会社のメールまたはドメインに置き、会社側担当者は通常用の管理権限でログインできる状態にします。復旧メールと電話も会社管理下に置き、確認資料を台帳にそろえます。以上の状態なら、担当者の説明に頼らず、会社自身の操作によってクラウドアカウントの会社管理を証明できます。

外注先へ最初に求めるものは、契約主体と請求の証拠です。そこから最上位権限、通常権限、復旧経路へ進みます。万能な管理者パスワード一つで済ませる受領では、支払責任や復旧連絡先が抜け落ちます。四つの状態を別々に受領し、最後に復旧可能性を確かめます。その条件を満たしてから旧権限を外せば、会社名義と会社による復旧を同じ台帳で管理できます。