AWSアカウントは発注者と開発会社どちらが持つ？費用・引き継ぎで後悔しない選び方

「AWSで構築します」と言われたものの、AWSアカウント自体は自社で作るのか、それとも開発会社のアカウントの中で動かしてもらうのか、どちらが正しいのか分からない。AWSを使ったシステムを初めて発注する方の多くが迷うポイントです。

先に結論をお伝えします。長く使うシステムであれば、AWSアカウントは発注者（自社）が持つのが原則です。開発会社には、アカウントそのものではなく「作業に必要な範囲の権限」だけを渡します。ただし、検証段階のシステムや、開発会社が請求代行までまとめて引き受けるプランなど、開発会社のアカウントで進めても実務上問題が少ないケースもあります。

この記事では、2つの持ち方の違いを比較表で整理し、状況別の選び方、開発会社のアカウントで進める場合に確認しておきたいこと、そのまま使えるチェックリストと質問例を解説します。

なぜ「どちらが持つか」が問題になるのか

AWSのようなクラウドサービスでは、システムを動かすための「土台」であるAWSアカウントと、その上に作る「システムそのもの」が別々に存在します。家に例えると、AWSアカウントは土地、その上に建てるシステムは建物にあたります。

土地を借りている状態で建物だけ自社のものにしても、地主（この場合は開発会社）の都合で急に使えなくなるリスクが残ります。逆に、自社で土地を持っていれば、建物の管理を頼む会社（開発会社）を変えることも比較的スムーズです。

こうした事情から、AWSアカウントの持ち方は「今後このシステムをどう運用し、必要なら開発会社をどう変えるか」に直結する、契約以前の重要な論点になります。

もう一つ見落とされがちなのが、セキュリティ責任の所在です。IPA（情報処理推進機構）は中小企業向けのクラウド利用の手引きで、クラウドサービスの安全な利用は事業者と利用者の双方が責任を分担して成り立つ仕組みであることを整理しています。

📰 出典：IPA「中小企業のためのクラウドサービス安全利用の手引き」

AWSアカウントを開発会社が持っている状態だと、「利用者側の責任」を実質的に開発会社が肩代わりしていることになります。それ自体が悪いわけではありませんが、発注者としてどこまでを相手に委ねているのかを、一度は意識しておく必要があります。

なお、開発会社が自社のアカウント内で進めたがるのには、悪意ではなく実務上の理由があることも知っておくと、打ち合わせでの話が進めやすくなります。小規模な案件のたびに発注者へアカウント作成・初期設定を依頼していると、着手までに時間がかかりますし、複数の顧客の環境を自社の使い慣れた構成でまとめて管理した方が、保守の効率が良いという事情もあります。どちらの持ち方にも一定の合理性があるからこそ、発注者側から「今回はどちらにしますか」と最初に確認する姿勢が大切になります。

2つの持ち方の比較

AWSアカウントの持ち方には、大きく分けて2つのパターンがあります。

比較項目	①発注者が自分でアカウントを作る	②開発会社のアカウント内で構築してもらう
請求書の宛先	自社（AWSから直接）	開発会社（開発会社からの請求に含まれることが多い）
利用料金の内訳の見えやすさ	自社のAWS管理画面でいつでも確認できる	開発会社からの報告に依存する
開発会社を変更するときの引き継ぎ	権限を渡し直すだけで比較的スムーズ	アカウントごと移管する手続きが必要、または作り直しになることも
初期の手間	自社でのアカウント作成・支払い設定が必要	開発会社にほぼ任せられる
セキュリティ・権限管理の主導権	自社にある	開発会社に依存する
小規模な検証・お試し利用との相性	ややオーバースペックなことも	手早く始められる

AWSが多数のAWSアカウントを扱う組織向けに公開している設計指針でも、業務ごとにアカウントを分け、それぞれのアカウントの所有と意思決定を、その業務に責任を持つ主体に合わせることが基本的な考え方として示されています。

📰 出典：AWS「Organizing Your AWS Environment Using Multiple Accounts」設計原則

システムの利用者であり費用を負担するのは発注者ですから、この考え方に沿えば、システムを動かすAWSアカウントの所有と意思決定も発注者側にあるのが筋、ということになります。

状況別のおすすめの考え方

長く運用する自社サービス・業務システムの場合 → 発注者が持つ

顧客向けサービスや、何年も使い続ける社内システムであれば、AWSアカウントは発注者が持つことをおすすめします。理由は次の3つです。

• 開発会社を変更・追加するとき、アカウントごと引き継ぐより権限の渡し直しの方が簡単
• 利用料金がいくらかかっているか、開発会社を介さず自社で確認できる
• 万が一その開発会社と連絡が取れなくなっても、システムの土台は自社の手元に残る

短期間の検証・PoC、機能の一部だけを頼む場合 → 開発会社のアカウントでも可

「まず小さく動くものを試したい」「既存システムの一部機能だけをAWS上に追加で作ってもらう」といった小規模・短期間の案件では、開発会社のアカウント内で進めてもらう方が早く始められ、実務上の問題も比較的小さくなります。ただし、後述する確認事項は事前に決めておきましょう。

開発会社が「請求代行・保守込みプラン」を提供している場合 → 契約内容次第

保守運用まで含めて開発会社に一括で任せるプランの中には、AWSの利用料金を開発会社がまとめて支払い、月額費用の一部として請求する形態もあります。この場合はアカウントの持ち方よりも、後述する「請求内訳の開示」「解約時の引き継ぎ手順」が契約に明記されているかがポイントになります。

開発会社のアカウントで進めてもらう場合に確認したいこと

発注者が自分でAWSアカウントを持つ場合も、開発会社に日々の作業をしてもらう以上、開発会社にAWSアカウントの全権限（root権限）をそのまま渡すのは避けたいところです。AWSでは、外部の会社に作業を依頼する際、アカウントの中身を丸ごと渡すのではなく、必要な作業だけを許可する「IAMロール（＝一時的に借りられる権限のかたまり）」を使う方法が推奨されています。

📰 出典：AWS re:Post「Allow cross-account users to access your resources through IAM」

この仕組みを使うと、開発会社は自社のIDでログインしたまま、期限付き・範囲限定の権限で発注者のAWSアカウントにアクセスできます。長期間有効なパスワードやアクセスキーを開発会社に渡す必要がなく、いつでも権限を止められる点がメリットです。

一方、やむを得ず開発会社のアカウント内で進めてもらう場合は、次を契約前に確認しておきましょう。

• 利用料金の内訳（自社のシステムにいくらかかっているか）を月次で開示してもらえるか
• 開発会社を変更・解約するときに、AWSアカウント（またはその中の環境）を発注者側に移管する手順が決まっているか
• データのバックアップ・移行が発注者側で可能な形式で行えるか

なお、AWSアカウントを後から別の管理組織に移す仕組み自体はAWS側に用意されており、開発会社のアカウントの中にある環境であっても、事前に取り決めておけば移管は技術的には可能です。

📰 出典：AWS Organizations「アカウントを別の組織に移行する」

ただし「技術的に可能」であることと「実際にスムーズに移管できる」ことは別です。移管の手順や協力の範囲を契約や覚書に残しておかないと、いざという時に開発会社の協力が得られず、時間も費用もかかることがあります。

やりがちな失敗

• アカウントの持ち方を確認せず、言われるがままに開発会社に任せる：後から料金の内訳が分からなくなったり、解約時にシステムが人質状態になったりします
• 自社でアカウントを持ったのに、開発会社にroot権限のIDとパスワードをそのまま渡す：権限管理の主導権を結局手放してしまいます。IAMロールでの権限付与に切り替えましょう
• 請求内訳の開示や移管手順を、口頭の約束だけで済ませる：担当者が変わると引き継がれず、いざという時に「聞いていない」となりがちです

発注者がやることチェックリスト

• ☐ このシステムを長く運用するか、短期間の検証かを整理した
• ☐ 長く使う予定なら、AWSアカウントを自社名義で作る前提で開発会社に相談した
• ☐ 開発会社にはroot権限ではなく、IAMロールなど必要範囲だけの権限を渡す方針にした
• ☐ 開発会社のアカウントで進める場合、利用料金の内訳を月次で開示してもらえるか確認した
• ☐ 開発会社を変更・解約する場合の引き継ぎ・移管手順を契約や覚書に残した
• ☐ 社内でAWSアカウントの管理担当者（支払い方法・権限付与の最終判断者）を決めた

開発会社への質問例

• 「このシステムのAWSアカウントは、御社と弊社どちらの名義で作るご提案ですか。それはなぜですか」
• 「御社に作業していただく際は、root権限ではなくIAMロールなど必要な範囲の権限で対応いただけますか」
• 「AWSの利用料金の内訳は、月次でどのような形で開示していただけますか」
• 「今後、御社以外の開発会社に運用を引き継ぐことになった場合、どのような手順・費用で移管できますか」
• 「アカウントの管理画面には、弊社からもいつでもログインして確認できますか」

まとめ：長く使うなら自社名義、任せるなら権限の渡し方を決める

AWSアカウントを発注者と開発会社のどちらが持つべきかは、「このシステムをどれくらい長く、どう運用していくか」で判断するのが基本です。

• 長く運用するシステムは、AWSアカウントを発注者（自社）名義で持つのが原則
• 開発会社には、アカウントそのものではなくIAMロールなど必要範囲の権限を渡す
• 短期間の検証など、開発会社のアカウントで進める場合は、料金内訳の開示と解約時の移管手順を事前に確認する

「AWSのことは詳しくないから」とアカウントの持ち方まで丸ごと開発会社に任せてしまうと、後から料金や引き継ぎで困ることがあります。契約前の打ち合わせで、この記事のチェックリストと質問例を使って一度確認してみてください。

あわせて読みたい関連記事