【Claude CodeとAWSで作るAIエージェントの土台第2回】AWS を4つのアカウントに分け、Google Workspace でログインする

2026年5月11日2026年11月1日

前回は、AI エージェントに仕事を任せるために「AI にはトークンだけを渡し、資料とパスワードは API 側に置く」という設計を説明し、権限の表を書きました。

なぜ1つのアカウントにしないのか

1つのアカウントに確認用と本番を同居させると、次のようなことが起きやすくなります。

確認用のつもりで消したものが、本番のものだった
確認用のために付けた広い権限で、本番のデータも触れてしまう
請求書を見ても、どこにいくらかかっているのかが分かりにくい

AWS のアカウントは、権限と費用の「境界」です。アカウントを分ければ、アカウントをまたいだ操作は、許可を明示しない限りできません。AWS 自身も、用途ごとにアカウントを分ける構成を勧めています。

📰 出典：Organizing Your AWS Environment Using Multiple Accounts（AWS Whitepaper）

4つのアカウントの役目

アカウント	役目	GitHub Actions から
管理	請求、IAM Identity Center（ログイン）、組織全体の記録	使わない
共通	コンテナイメージの置き場（ECR）	main のジョブから、置き場への書き込みだけ
確認用	main に取り込んだら自動で反映する。外部への書き込みは止める	main のジョブから
本番	人が v で始まるタグを作ったときだけ反映する	タグのジョブから

管理アカウントには何も動かさない：ここには請求とログインの設定だけを置きます。管理アカウントは組織全体に強い力を持つため、アプリを動かしたり、GitHub Actions から入らせたりはしません
共通アカウントにコンテナイメージを置く：確認用で確かめたのと同じイメージを、本番でもそのまま使えます。「確認用では動いたのに、本番用に作り直したら動かない」を防ぎます
確認用は外への書き込みを止める：サンプルでも、確認用では WordPress に「公開」を頼まれても下書きにする作りにします（第7回）

ECR（Elastic Container Registry）は、コンテナイメージ（＝アプリと動かすのに必要なものをまとめた箱）を置くサービスです。連載のサンプルは、簡単にするため、CDK がイメージを各アカウントの置き場に自動で作る形にしています（第4回）。

当社のお客様への提案も同じ4つの分け方なので、社内基盤はその予行演習を兼ねています。

AWS Organizations でアカウントを作る

アカウントは AWS Organizations（＝複数のアカウントをまとめて管理するサービス）で作ります。最初に作ったアカウントを管理アカウントにして、そこから残りの3つを作ります。

画面の言語：英語（日本語表示では名前が異なる場合があります）

管理アカウントにルートユーザーでサインインし、AWS Organizations の画面で組織を作る
「Add an AWS account」から「Create an AWS account」を選び、共通・確認用・本番の3つを作る（アカウントごとに別のメールアドレスが要ります）
作ったあとは、各アカウントのルートユーザーを使わない。ふだんは次の IAM Identity Center から入る

ルートユーザー（＝アカウントを作ったときのメールアドレスで入る、何でもできる利用者）は、多要素認証（MFA）を設定したうえで、請求の手続きなどの限られた場面でだけ使います。

Google Workspace のアカウントで AWS に入る

社員ごとに AWS 専用のユーザーとパスワードを作ると、入社・退職のたびに AWS 側の手続きが要り、消し忘れも起きます。当社は、AWS IAM Identity Center（＝複数のアカウントへのログインをまとめるサービス）に Google Workspace をつなぎ、Google のアカウントでログインする形にしました。

📰 出典：Use Google Workspace with IAM Identity Center（AWS Documentation）

設定の流れは次のとおりです（手順の細部は上の公式ドキュメントに沿って進めてください）。

管理アカウントで IAM Identity Center を有効にする
「Settings」の「Identity source」で、ID ソースを「External identity provider」に変える。Google 管理コンソール側で AWS 用の SAML アプリを作り、互いのメタデータ（＝つなぐための設定情報）を交換する
「Automatic provisioning」を有効にし、表示された SCIM のエンドポイントとアクセストークンを Google 管理コンソールに入れる。これで Google のユーザーが AWS 側に自動で作られる
「Permission sets」で許可セット（＝権限のまとまり）を作る。当社は「管理者」「閲覧」「請求」の3つ
「AWS accounts」で各アカウントを選び、ユーザー（またはグループ）と許可セットを割り当てる

SAML は、ログインを別のサービス（ここでは Google）に任せるための決まりごとです。SCIM は、ユーザーの作成・削除を自動で同期するための決まりごとです。

落とし穴：グループは同期されない

実際に設定して、いくつかつまずきました。

つまずき	対処
SCIM で同期されるのはユーザーだけで、Google のグループは AWS 側に来なかった	IAM Identity Center の側でグループを作り、そこにユーザーを入れた
同期されないユーザーがいた	各ユーザーに姓・名・表示名が要る。Google 側で入っているかを確かめた
IAM Identity Center の画面でユーザーを直せない	SCIM を有効にすると、ユーザーの情報は Google 側で直す決まりになる
SCIM のアクセストークンは1年で切れる	切れる前に作り直す予定を、カレンダーに入れておいた

グループの同期については、AWS のドキュメントにも「Google Workspace からの自動のプロビジョニングはユーザーに限られる」旨の説明があります。グループで権限を割り当てたい場合は、AWS 側でグループを作る手間を見込んでおきましょう。

📰 出典：Automatic provisioning（AWS IAM Identity Center User Guide）

落とし穴：請求の画面が見えない

IAM Identity Center から入ったユーザーに「請求」の許可セットを割り当てても、最初は請求の画面が見えませんでした。管理アカウントの「Account」の画面で、「IAM user and role access to Billing information」を有効にする必要があります。これはルートユーザーでしか変えられない設定です。

ふだんの入り方

設定が終わったら、ふだんは次のように入ります。

AWS access portal（IAM Identity Center が用意するログイン画面）を開き、Google のアカウントでログインする
使いたいアカウントと許可セット（例：確認用 × 閲覧）を選んで、管理画面に入る
アクセスキー（＝プログラムから AWS を使うための長く使える文字列）は作らない。プログラムからの反映は、次回の GitHub Actions（OIDC）で行う

退職者が出たときも、Google のアカウントを止めれば AWS にも入れなくなります。

動作確認

この回はコードを変えていません。前回のプロジェクトで、検査とテストが通るままであることだけ確かめておきます。

ruff check .
pytest -q

AWS 側は、次の3点を確かめます。

AWS access portal に Google のアカウントでログインでき、4つのアカウントが一覧に出る（割り当てた許可セットの分だけ）
確認用のアカウントで「閲覧」の許可セットを選ぶと、ものを作る操作がはじかれる
「請求」の許可セットで、請求の画面が見える

つまずきやすい点・セキュリティ上の注意

管理アカウントでアプリを動かさない：管理アカウントは組織全体に影響する強い権限を持ちます。ここには請求とログインの設定だけを置きます
ルートユーザーには MFA を設定し、アクセスキーを作らない：ルートユーザーのアクセスキーが漏れると、アカウントのすべてを操作されます
許可セットは「閲覧」から始める：最初から全員に「管理者」を割り当てず、必要な人にだけ広い権限を割り当てます

発注者向けメモ

AWS を使うシステムを開発会社に頼むとき、アカウントの持ち方は最初に決めておきたいところです。後から分けるのは手間がかかります。

アカウントの持ち主：AWS のアカウントは発注者（自社）の名義で作り、開発会社には自社の IAM Identity Center から入ってもらう形にすると、契約が終わったときに権限を外すだけで済みます
アカウントの分け方：「確認用と本番はアカウントを分けますか」「本番に反映できるのは誰ですか」を確認しましょう
ログインの方法：「社員や開発会社の担当者ごとに、AWS 専用のパスワードを作りますか。自社の Google（や Microsoft）のアカウントでログインできますか」
費用の見え方：アカウントを分けると、確認用と本番の費用が別々に見えます。月次の報告で両方を出してもらうと、費用の増え方に早く気付けます

アカウントの数が増える、既存のアカウントから移す、社外の人のログインを管理する、といった条件があると、設定の工数が増えやすくなります。

まとめと次回予告

AWS は「管理・共通・確認用・本番」の4つのアカウントに分けると、確認用で何をしても本番に届かず、権限と費用も環境ごとに見える
ログインは IAM Identity Center にまとめ、Google Workspace のアカウントで入る。AWS 専用のパスワードやアクセスキーは作らない
SCIM で同期されるのはユーザーだけ。グループは AWS 側で作る

次回は、GitHub Actions からアクセスキーを置かずに AWS へ入る仕組み（OIDC） と、新しい GitHub の組織で実際につまずいた落とし穴を説明します。