システムを動かしているAWSのアカウントが、開発会社の名義のまま。請求書も開発会社経由で届く。そろそろ自社でちゃんと持ちたいけれど、「移すと本番のシステムが止まるのでは」と心配で、言い出せないまま時間が過ぎている——そんな状況は珍しくありません。
「AWSのアカウントを開発会社が作ったまま運用している。自社に所有者を移したいが、止めずに移せるのか」
先に結論をお伝えします。アカウントの「中身」（サーバーやデータ）は、移す方法を選べば止めずに引き継げます。ただし、移し方は「いまのアカウントがどういう状態か」で変わります。まず確認すべきなのは、次の3点です。
- そのアカウントは、開発会社の請求まとめ（組織）に入っているか、それとも単独のアカウントか
- アカウントの入り口である「ルートユーザー」のメールアドレスは、誰のものか
- そのアカウントに、他のお客様のシステムも同居していないか
この記事では、AWSに詳しくない発注者の方が、開発会社と相談しながら進められるように、移管の進め方を5ステップで整理します。なお、AWSの契約やアカウントの扱いは、利用状況や契約形態によって異なります。最終的な手続きは、開発会社とAWSの公式窓口（または販売パートナー）に確認してください。
なぜ「開発会社名義」のままになりやすいのか
最初に、開発会社を責める話ではない、という点を押さえておきます。開発会社名義のアカウントが多いのには、構造的な理由があります。
- 立ち上げが早い：発注者のアカウントを作ってもらうより、開発会社がすでに持っている仕組みで作るほうが、開発をすぐ始められる
- 請求をまとめたい：開発会社が請求を一括して受け取り、発注者に月額で請求する形（いわゆる「請求代行」）にすると、発注者は支払い手続きを簡単にできる
- 発注時に決めていなかった：「アカウントは誰のものか」を契約書や見積もりに書かないまま、構築が進んだ
関連して、アカウントを発注者と開発会社のどちらが持つかの考え方は、次の記事で詳しく解説しています。
つまり、いまの状態は「間違い」ではなく、あとから決め直す必要が出てきただけと考えると、開発会社にも話を切り出しやすくなります。
移管の前に知っておきたい「3つの入り口」
AWSのアカウントには、誰がどこまで操作できるかを決める入り口がいくつかあります。ここを整理すると、何を自社に移せばいいかが見えてきます。
| 入り口 | 一言でいうと | 自社が持つべき理由 |
|---|---|---|
| ルートユーザー | アカウントの「持ち主」としての最上位のログイン（登録メールアドレスで本人確認される） | パスワード再設定や解約、メールアドレス変更など、最終判断ができる唯一の入り口のため |
| 請求の窓口（支払い方法） | 誰のクレジットカード・請求書に請求が行くか | 料金の支払い責任は、アカウントの所有者にあるため |
| 管理用のユーザー（IAMなど） | 日々の運用で使う、権限を絞ったログイン | 開発会社の担当者が入れ替わっても、自社で入れ替えや停止ができるようにするため |
AWSの公式ドキュメントでも、ルートユーザーのメールアドレスを変更する操作は、スタンドアロン（単独）アカウントならルートユーザーとしてのサインインが必要で、管理者用のIAMユーザーでは実行できないと説明されています。
📰 出典：AWS「ルートユーザーの E メールアドレスの更新」（AWS アカウント管理 リファレンスガイド）
つまり、ルートユーザーのメールアドレスが開発会社のものである限り、最終的な主導権は開発会社側にあるということです。逆に言えば、ここを自社のアドレス（個人ではなく、担当者が変わっても受け取れる共有アドレス）に変えられれば、所有者の移管はほぼ済んだと考えられます。
止めずに移す5ステップ
ここからは、一般的な進め方です。アカウントの状態によって順番や方法が変わるため、必ず開発会社と一緒に「うちの場合はどのパターンか」を確認しながら進めてください。
ステップ1. 現状を棚卸しする（作業前に必ずやる）
まず、次の4点を開発会社に書面（メールで構いません）で教えてもらいます。
- AWSアカウントIDと、ルートユーザーの登録メールアドレス
- 単独のアカウントか、開発会社の組織（AWS Organizations＝複数アカウントの請求や管理をまとめる仕組み）に入っているか
- 請求の方法（AWSから直接か、開発会社が代行しているか）と、現在の月額
- そのアカウントに入っているシステムの一覧（自社のもの以外が同居していないか）
ステップ2. 移管の方法を決める
状態によって、大きく2つの進め方に分かれます。
| いまの状態 | 進め方の例 | ポイント |
|---|---|---|
| 単独のアカウント（組織に入っていない） | アカウントそのものを残し、ルートユーザーのメールアドレスと連絡先、支払い方法を自社のものに変更する | 中身（サーバーやデータ）は動かさないため、止まりにくい |
| 開発会社の組織に入っているメンバーアカウント | 組織から外して単独のアカウントにしたうえで、メールアドレスや支払い方法を自社のものにする。または、自社のアカウントを新しく作って、中身を移す | 外す前に、支払い方法・連絡先・サポートプランの登録が必要。中身を移す場合は、移行作業と費用がかかる |
組織から外す場合のAWSの公式な説明では、外してもアカウント自体は閉鎖されず、単独のアカウントになります。ただし、外す前にサポートプラン・連絡先情報・有効な支払い方法が登録されている必要があり、外したあとに発生する料金と支払い方法の責任は、アカウントの所有者が負うとされています。
📰 出典：AWS「組織からメンバーアカウントを削除する」（AWS Organizations ユーザーガイド）
また、組織から外すと、組織のポリシーによる制限がなくなり、これまで見えていたコストの情報がメンバーアカウントからは見られなくなるなど、変わる点もあります。切り替えの日を決めて、その前後で何が変わるかを開発会社と確認しておきましょう。
ステップ3. ルートユーザーと連絡先を自社に移す
ここが「所有者の移管」の中心です。
- ルートユーザーのメールアドレスを、自社の共有アドレス（例：担当者個人ではなく部署のアドレス）に変更する
- 主要連絡先と、請求・運用・セキュリティの各連絡先を、自社で受け取れるアドレスに変える
- ルートユーザーのMFA（＝パスワードに加えて、スマートフォンなどで行う追加の本人確認）を、自社の管理下にある端末や方法で設定し直す
メールアドレスの変更では、新しいアドレスに届く確認コードの入力が必要で、変更がすべての場所に反映されるまで最大4時間かかることがあると案内されています（2026年10月時点）。変更作業は、システムの稼働に影響しにくい時間帯に、開発会社と同席（または画面共有）で行うと安心です。
連絡先（主要連絡先と、請求・運用・セキュリティの代替連絡先）の更新方法は、次のAWS公式ドキュメントで確認できます。
📰 出典：AWS「アカウントの連絡先情報の更新」（AWS アカウント管理 リファレンスガイド）
ステップ4. 請求と支払いを切り替える
請求代行を使っている場合は、AWSから自社に直接請求が来る形に変えます。
- 自社のクレジットカード、または請求書払いなどの支払い方法を登録する
- 切り替えの月の請求が、開発会社と自社でどう分かれるか（締め日、日割りの有無）を確認する
- 開発会社が請求代行で上乗せしていた手数料や、割引の扱いがどうなるかも確認する
AWS請求の月額が見積もりより高くなる原因は別の記事でまとめています。移管後の費用の見方の参考にしてください。
ステップ5. 権限を入れ替えて、運用ルールを残す
最後に、日々の運用に使うユーザーを整理します。
- 開発会社の担当者用のユーザー（IAMユーザーなど）は、権限を必要な範囲に絞って残す（保守を続けてもらうため）
- 退職した担当者や、使われていないユーザー・アクセスキーを停止する
- 組織から外した場合は、組織が作ったアクセス用のIAMロールが残るため、不要なら削除する
- 「誰が、どの権限で入れるか」と「緊急時の連絡先」を1枚の表にして、自社で保管する
AWSの公式ドキュメントでも、組織が作った管理アカウントからのアクセス用ロール（例：OrganizationAccountAccessRole）は自動では削除されないため、以前の管理アカウントからアクセスされないよう、手動で削除するよう案内されています。
移管でつまずきやすい3つのケース
ケース1. 他のお客様のシステムも同じアカウントに入っている
開発会社の1つのアカウントに複数のお客様のシステムが同居している場合、アカウントごと譲ってもらうのは現実的でないことが多くなります。この場合は、自社用のアカウントを新しく作って、システムを移す（再構築または移行）ことになります。費用と期間の見積もりを、移管の前に別途もらうようにしましょう。
ケース2. 「請求代行」に割引や手数料が含まれていた
開発会社を通した契約には、割引や手数料が組み込まれていることがあります。どちらが得かは契約の内容によるため、移管の前後で、月額がどう変わるかを数字で比べてもらうのが確実です。
ケース3. 契約書に、アカウントの扱いが書かれていない
契約書や保守契約にアカウントの所有について書かれていない場合は、移管の作業が「保守の範囲」なのか「別料金」なのかが曖昧になります。法律的な解釈は契約ごとに異なるため、判断に迷う場合は弁護士などの専門家に確認してください。
発注者がやることチェックリスト
- ☐ アカウントIDとルートユーザーの登録メールアドレスを、開発会社から文書で教えてもらった
- ☐ 単独アカウントか、組織（メンバーアカウント）か確認した
- ☐ 他のお客様のシステムが同居していないか確認した
- ☐ 自社側の受け皿（共有メールアドレス、支払い方法、MFAの管理担当）を決めた
- ☐ 切り替えの日時と、作業の立ち会い者（自社・開発会社）を決めた
- ☐ 移管の前後で、月額費用がどう変わるかの試算をもらった
- ☐ 移管後の権限の一覧と、緊急時の連絡先を自社で保管した
- ☐ 契約書・保守契約に、今後のアカウントの持ち主と範囲を書き足した
開発会社への質問例
- 「現在のAWSアカウントは単独ですか、それとも御社の組織に入っていますか？」
- 「ルートユーザーのメールアドレスを弊社のものに変更したいのですが、本番のシステムが止まる可能性はありますか？」
- 「移管の作業にかかる工数と費用は、保守契約に含まれますか、別料金ですか？」
- 「請求を弊社のカードに切り替えた場合、月額や割引は今とどう変わりますか？」
- 「切り替えのあとも、保守のために御社が入れる権限を、どの範囲で残すのがよいと考えますか？」
まとめ：「止めずに移す」は、棚卸しと日取りの相談から
AWSアカウントの名義を自社に移すときのポイントは、次の4つです。
- 中身を動かさず、ルートユーザー・連絡先・支払い方法を自社に移せば、システムを止めずに引き継げる場合が多い
- 組織に入っているアカウントは、外す前に支払い方法や連絡先の登録が必要
- 他のお客様と同居しているアカウントは、新しく作って移す（再構築）が必要になる
- 移管後も、保守のための権限は範囲を絞って残す
「言い出しにくい」と感じる必要はありません。まずは、現状の棚卸し（アカウントIDと登録メールアドレスの確認）を、開発会社にお願いするところから始めてみてください。
あわせて読みたい関連記事
