--- title: "アカウントの分け方。本番・検証・開発を分ける設計｜アメリア・テクノロジー株式会社" url: https://www.ameliatechnology.co.jp/blog/cloud-account-structure/ description: "クラウドでは、本番・検証・開発の環境を、AWS のアカウント、Azure のサブスクリプション、Google Cloud のプロジェクトの単位で分けるのが基本です。分ける理由、束ね方、分け方の例を説明します。" updated: 2026-11-14 publisher: "アメリア・テクノロジー株式会社" --- # アカウントの分け方。本番・検証・開発を分ける設計 クラウドでは、本番・検証・開発の環境を、AWS のアカウント、Azure のサブスクリプション、Google Cloud のプロジェクトの単位で分けるのが基本です。分ける理由、束ね方、分け方の例を説明します。 2026.11.14 [クラウドと運用](https://www.ameliatechnology.co.jp/blog/category/cloud/) 執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO） クラウドと運用（CLOUD & OPERATIONS）のコラム ## この記事の要点 - アカウントなどの単位は、権限・費用・障害の影響の境目になるため、本番とそれ以外を分けると事故の広がりを抑えられます。 - AWS は Organizations の組織単位、Azure は管理グループ、Google Cloud はフォルダで、複数の単位を束ねて決まりを当てます。 - はじめから細かく分けすぎず、本番・本番以外・共通の基盤の3つ程度から始め、必要に応じて増やします。 クラウドでは、本番・検証・開発の環境を、同じ1つのアカウントの中で分けるのではなく、アカウントなどの単位ごとに分ける設計が基本です。アカウントは、権限・費用・障害の影響の境目になるため、分けておくと、開発の作業の誤りが本番に及ぶことや、費用の内訳が混ざることを防げます。 使い始めの時期は、1つのアカウントにすべてを置いても困りません。ただ、利用が広がった後で分け直すのは手間がかかるため、早い段階で分け方を決めておくほうが、後の負担が小さくなります。こうした最初の土台の設計は、[ランディングゾーン](https://www.ameliatechnology.co.jp/glossary/landing-zone/)と呼ばれます。 ## 分ける理由 AWS は、複数のアカウントを使う利点として、次のような点を挙げています。 - 本番と本番以外を別のアカウントにすると、既定の状態で、資源とデータがほかの環境から分かれる - アカウントは、セキュリティ・アクセス・請求の境目になり、1つのアカウントで設定の誤りや不正な操作が起きても、影響をそのアカウントの中に抑えられる - 費用は、既定でアカウントごとに分けて集計される - サービスの利用の上限（クォータ）はアカウントごとに決まるため、1つの処理が上限を使い切っても、ほかに及びにくい - 事業を買い取った場合、その事業のアカウントをそのまま自社の組織に移せる 出典：[Benefits of using multiple AWS accounts（AWS）](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html) 1つのアカウントの中で、権限の細かな設定で環境を分けることもできますが、設定が複雑になり、誤りに気づきにくくなります。アカウントの単位で大きく分け、その中で[最小の権限](https://www.ameliatechnology.co.jp/glossary/least-privilege/)を設定するほうが、管理が単純になります。M&A の後に別の会社の環境をまとめる場面での考え方は、[M&Aの後のクラウドの統合。アカウントと権限をどうまとめるか](https://www.ameliatechnology.co.jp/blog/post-ma-cloud-integration/)で説明しています。 ## 各クラウドの単位と束ね方 3つのクラウドは、環境を分ける単位と、複数の単位を束ねる仕組みの名前が違います。 | クラウド | 環境を分ける単位 | 束ねる仕組み | |---|---|---| | AWS | アカウント | AWS Organizations の組織単位（OU） | | Microsoft Azure | サブスクリプション | 管理グループ | | Google Cloud | プロジェクト | 組織とフォルダ | ### AWS AWS は、組織単位（OU）の構成の例として、組織全体のセキュリティの決まりを当てるアカウントを置く「Security」、共通のネットワークなどの基盤を置く「Infrastructure」、業務の処理を置く「Workloads」、試しや開発のための「Sandbox」などを示しています。Workloads には本番と本番以外の両方を置く例になっており、Sandbox は本番の資源への接続を限った試しの場とされています。どう分けるかは、それぞれの会社が自社の要件に合わせて決める、と AWS は説明しています。 出典：[Recommended OUs and accounts（AWS）](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/recommended-ous-and-accounts.html) ### Microsoft Azure Microsoft は、サブスクリプションを管理・請求・規模の単位とし、統制と分離のための管理の境目になる、と説明しています。開発・検証・本番の環境は管理の面で分けられることが多く、開発の環境は本番より緩い決まりで運用されることがあるため、サブスクリプションは Azure Policy の決まりを当てる境目として使われます。同じ決まりと権限を当てるサブスクリプションは、同じ管理グループの下に置き、管理・セキュリティ・接続・認証の基盤のサブスクリプションは、1つにまとめずに分けるよう勧めています。 出典：[Subscription considerations and recommendations（Microsoft Learn）](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-subscriptions) ### Google Cloud Google Cloud では、組織（会社）・フォルダ・プロジェクトの階層で資源を整理します。フォルダは部署・チーム・アプリケーションを表すのに使え、組織の中の小さな組織のように、分離と管理の委任の境目になります。フォルダに与えた権限は、その下のプロジェクトに引き継がれます。 出典：[Resource hierarchy（Google Cloud）](https://docs.cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy) ## 分け方の例 中堅・中小の会社で始めやすい分け方の例を示します。会社の規模や業務に合わせて、増やしたり減らしたりしてください。 たとえば、ログの保管とセキュリティの確認を担う共通の基盤のアカウントを1つ、業務のシステムの本番のアカウントを1つ、検証と開発のための本番以外のアカウントを1つ置き、これらを束ねる仕組みの最上位で、組織全体の決まりを当てる形です。新しい技術を試すための試しのアカウントは、本番の資源につながらないようにしたうえで、必要になった時点で加えます。 始めやすい分け方の例 - **共通の基盤**：ログの保管とセキュリティの確認 - **本番**：業務のシステム - **本番以外**：検証と開発 - **試し（必要になった時点で）**：新しい技術を試す。本番の資源につながらないようにする これらを束ねる仕組みの最上位で、**組織全体の決まりを当てます** 本番と本番以外を分けたうえで、ログの保管やセキュリティの確認のためのアカウントを、業務の処理とは別に置くと、業務のアカウントで管理者の権限を持つ人がいても、記録を消されにくくなります。ログの扱いの基本は、[ログの取り方と見方。何を、どのくらい残すか](https://www.ameliatechnology.co.jp/blog/log-management-basics/)で説明しています。 分ける単位が増えるほど、それぞれに権限・監視・費用の通知を設定する手間も増えます。単位を作るたびに同じ設定を手で行うのではなく、[インフラのコード化（IaC）とは。手作業の構築をやめる理由](https://www.ameliatechnology.co.jp/blog/infrastructure-as-code-why/)などで、決まった設定を自動で当てる仕組みを用意すると、設定のばらつきを防げます。 ## 始めるときの注意 アカウントの分け方を決めるときは、次の点に気をつけます。 1. **はじめから細かく分けすぎない**：本番・本番以外・共通の基盤（ログ・セキュリティ）の3つ程度から始め、事業やシステムが増えたら足します 2. **管理者の権限を持つ人を絞る**：束ねる仕組みの最上位（AWS の管理アカウントなど）に入れる人は、ごく少数にし、多要素認証をかけます 3. **費用の通知を単位ごとに設定する**：開発のアカウントで消し忘れた資源が費用を生むことがあるため、予算の通知を設定します 4. **名前の付け方をそろえる**：単位の名前に、環境（本番・検証・開発）とシステムの名前を入れ、[タグ](https://www.ameliatechnology.co.jp/glossary/resource-tagging/)の付け方も決めておきます 5. **作った単位の一覧を管理する**：誰が責任者で、何に使っているかを記録します 2つ目の束ねる仕組みの最上位は、一般の業務には使わず、組織の管理だけに使うのが基本です。管理者のアカウントの守り方は、[管理者アカウントの守り方。多要素認証と緊急用のアカウント](https://www.ameliatechnology.co.jp/blog/protecting-admin-accounts/)で詳しく説明しています。 ## 当社のご支援 当社は、AWS・Microsoft Azure・Google Cloud の環境の分け方の設計と、決まった設定を自動で当てる仕組みづくりを、[クラウドの構築と運用管理](https://www.ameliatechnology.co.jp/service/cloud/)でお手伝いしています。すでに1つのアカウントにさまざまな環境が混ざっている場合は、いまの状態の整理から、分け直す順番の計画までご一緒します。いまの状態を確かめたい場合は、[クラウドの自己診断](https://www.ameliatechnology.co.jp/diagnosis/cloud/)（無料）もお使いいただけます。 - クラウド - アカウント設計 - ランディングゾーン - 権限管理 ## この記事に出てくる用語 - [クラウド](https://www.ameliatechnology.co.jp/glossary/cloud/) - [ランディングゾーン](https://www.ameliatechnology.co.jp/glossary/landing-zone/) - [AWS（Amazon Web Services）](https://www.ameliatechnology.co.jp/glossary/aws/) - [Microsoft Azure](https://www.ameliatechnology.co.jp/glossary/azure/) - [Google Cloud](https://www.ameliatechnology.co.jp/glossary/google-cloud/) - [ログ](https://www.ameliatechnology.co.jp/glossary/log/) - [監視](https://www.ameliatechnology.co.jp/glossary/monitoring/) - [Infrastructure as Code（IaC）](https://www.ameliatechnology.co.jp/glossary/infrastructure-as-code/) この記事を書いた人 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/) グループCTO インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。 このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。 ## あわせて読みたい - [Windowsサーバーと Active Directory を Azure へ移すときの考え方](https://www.ameliatechnology.co.jp/blog/windows-ad-to-azure/) - [Google Cloud を選ぶ場面。データ分析と Google Workspace とのつながり](https://www.ameliatechnology.co.jp/blog/when-to-choose-google-cloud/) - [Well-Architected の柱で、いまの構成を確かめる](https://www.ameliatechnology.co.jp/blog/well-architected-review/) [クラウドと運用のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/cloud/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/) ## 次の一歩 ### クラウドの構築と運用を任せる AWS・Microsoft Azure・Google Cloud の設計・構築・移行から、監視・運用・セキュリティまでを一つのチームで受け持ちます。監視は仕組みで24時間365日自動に回し、原因の調査と再発の防止は当社が担います。 [クラウドの構築と運用管理を見る](https://www.ameliatechnology.co.jp/service/cloud/) ### クラウドの状態を、無料で確かめる 15の設問に答えると、構成と管理・権限・守り・障害への備え・費用と体制の5つの分野の点数と、最初に取り組むことをまとめたレポートをその場でお届けします。 [クラウドの自己診断（無料）を受ける](https://www.ameliatechnology.co.jp/diagnosis/cloud/) ## ご関心に合わせて、お選びください。 [情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis) --- 出典：アメリア・テクノロジー株式会社「アカウントの分け方。本番・検証・開発を分ける設計｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/cloud-account-structure/