【Claude CodeとAWSで作るAIエージェントの土台第9回】構成図で振り返る：AI に鍵を渡さない土台の全体像と6つの考え方

2026年11月9日

前回までの8回で、AI エージェントに仕事を任せるための土台を、サンプルのプロジェクトで作りました。

この土台は何のためのものか

社内基盤は、ブログの投稿と営業の資料づくりを、Claude Code（AI エージェント＝指示を受けて、自分でファイルを読み書きしたりコマンドを実行したりする AI）に任せるためのものです。

Claude Code の環境を「役割」ごとに分けています。今はブログが6つ、営業が1つの、合わせて7つです
それぞれの環境は、自分の役割のトークンを1つだけ持ちます。トークンは Claude Code の環境の Network secrets（第5回）に入れ、AI からは値が見えません
当社がお客様に提案している「共通の土台」と同じ考え方で作り、お客様の環境に反映する前の予行演習と、動く見本を兼ねています

構成図

実線はリクエストやデータの流れ、点線は管理・監視・反映の流れです。アカウント番号・ドメイン・しきい値（回数の上限など）は省いています。アイコンは AWS Architecture Icons（AWS の公式のアイコン）と Simple Icons（各サービスのロゴ）を使っています。

図の読み方

利用する人（左）

社員は Google Workspace のアカウントで AWS にログインします（第2回）。AWS 専用のパスワードやアクセスキーは持ちません
Claude Code は、役割ごとの環境で動きます。th という小さなコマンドで API を呼び、資料を手元と S3 の間でやり取りします（pull で取得、push で書き戻し。書き戻すときは、取得したときから他で書き換えられていないかを確かめます）

AWS（中央）：アカウントは4つ

アカウント	置いているもの
管理	4つのアカウントを束ねる AWS Organizations、人のログインをまとめる IAM Identity Center、請求
共通（shared）	API のコンテナの置き場（ECR）と、コンテナの脆弱性の検査（Amazon Inspector）と、その週1回のまとめのメール
確認用（staging）	本番と同じ形。外部への書き込みの中継は止め、WAF は置かない
本番（production）	下の「本番の流れ」のとおり

本番の流れ

呼び出しは、WAF → API Gateway → Lambda（API のコンテナ） の順に届きます。

WAF（＝Web の呼び出しを、ルールに合わせて通す・止めるサービス）で、呼び出しの回数を制限します（第8回）
API Gateway が HTTPS の入口です。連載のサンプルでは ALB と ECS Fargate を使いましたが、当社は2026年11月4日に API Gateway と Lambda に移しました（次回、第10回で扱います）
Lambda の中で、API が「トークン → 役割 → できること」を判定します。何ができるかの決まりは roles.py の1か所だけにあります
API の IAM ロール（＝AWS の中での権限のまとまり）は、その環境の S3・表・鍵だけを扱えます。確認用の API から本番の資料は見えません

API でできること

できること	中身
資料の読み書き	S3 の置き場所ごとに、読める役割が決まっている。版を残すので、書き換えても戻せる
指示書を渡す	共通の指示書と、その役割の指示書だけを返す（第6回）
ブログの投稿の中継	WordPress への投稿。パスワードは API が付け、AI からは見えない（第7回）
ネタの台帳	記事のネタを登録するときに、似たものが無いかを確かめる
ナレッジの検索と追記	汎用のナレッジに書くときは、お客様の社名が入っていないかを API が確かめて止める
Drive への中継	提案資料のアップロード（営業の役割だけ）
画像づくり	記事のアイキャッチの背景を AI で作る（使える役割だけ）

S3 の分け方

S3 のキー（＝保存場所の名前）の先頭で、誰が読めるかが決まります。

置き場所	読める役割
`blogs/<サイト>/`	そのブログの役割だけ
`sales/`	営業だけ
`knowledge/`（汎用のナレッジ）	許された役割。お客様の名前は書かない
`instructions/_common/` と `instructions/<役割>/`	共通はだれでも、役割の分はその役割だけ（書き込みはどの役割もできない）

この決まりは、役割を足すたびに「他の役割から見えないこと」をテストで確かめています。

そのほかの AWS の部品

DynamoDB：トークンは元に戻せない形（ハッシュ）だけを置きます（第5回）。呼び出しの記録も置き、90日で自動で消えます
Secrets Manager：WordPress のパスワードや Google の APIキーの置き場です。値は人が画面で入れます
CloudWatch と SNS：API の記録と、知らせのメールです。サーバーや API でエラーが出たとき、処理が詰まったとき（Lambda の同時に動ける数の上限に当たったとき）、トークンの認証の失敗が続いたとき、WAF が呼び出しを止めたときに知らせます
Bedrock：アイキャッチの背景画像を作る AI です。使っているモデルが東京リージョンに無いため、米国のリージョンを呼んでいます

外部の Web サービス（右上）

WordPress、Google Maps、Google Drive、Google の画像生成（Imagen）には、すべて API が中継します。鍵は API が Secrets Manager から取り出して付けるので、Claude Code の環境には鍵がありません。

Google Workspace（右）

Google Apps Script（＝Google のサービスの中で動かせる小さなプログラム）に、2つの仕事を任せています。

提案資料の書き換えの知らせ：Drive の提案資料のフォルダを1時間ごとに見て、他の人が書き換えたファイルを Gmail で知らせます（読むだけ）
見積書づくり：10分ごとに案件のフォルダを見て、置かれた見積もりのデータ（JSON）から、同じフォルダにスプレッドシートと PDF の見積書を作ります。データが変わったら、リンクは変えずに中身だけを差し替えます。金額の計算はリポジトリの中の1か所（Python のプログラム）で済ませ、Apps Script は並べるだけです。単価が2か所に分かれないようにするためです

Apps Script は持ち主の Google アカウントの権限で動くので、鍵の置き場所が増えません。社内基盤の API は呼びません。トークンを Apps Script に置かないためです。Apps Script が使う権限（Google のサービスへのアクセスの範囲）は5つに固定し、増えていないことを自動のテストで確かめています。どちらも2026年11月から動かしています。

GitHub（下）：変更から反映まで

変更はすべてプルリクエストにします。テスト（API・CDK・設定の検査）が通ったものを人が確認し、main に取り込みます。取り込んでも、AWS には反映しません
反映を始めるのは、人が GitHub の画面でタグを作ったときだけです。確認用は v…-rc…、本番は v… の形です
GitHub Actions が OIDC（第3回）で各アカウントのロールに一時的に入ります。確認用のタグでは、共通のアカウントでコンテナを作って置いてから確認用に反映し、本番のタグでは同じコンテナを使って本番に反映します

反映の手順そのものは、当社の別のリポジトリ（共通の土台のひな形）にある共通のワークフローを、版をタグで固定して呼んでいます。お客様の環境でも同じ手順を使うためです。Apps Script だけは、プルリクエストを取り込んだあとに人が手元から clasp push（Apps Script にコードを送るコマンド）で反映します。Google の鍵を GitHub に置かないためです。

連載の第3回では「main に取り込んだら確認用に反映」としていましたが、当社は2026年11月に、確認用もタグで反映する形に変えました。取り込むたびにコンテナを作ると置き場に増えていき、脆弱性の検査の費用も増えたためです。急ぎの直しのために、確認用のタグを作らずに本番のタグだけで出す道も残しています。

変えても崩さなかった6つの考え方

考え方	構成図のどこで守っているか
1. 鍵を渡さない	外部の鍵は Secrets Manager にだけ置き、API が付ける。AWS への反映も OIDC で、長く使えるアクセスキーをどこにも置かない
2. 権限は1か所で決める	役割と、置き場所ごとに必要な権限を `roles.py` だけに書く。トークンには役割しか記録しない
3. AI エージェントは範囲の中だけで使わせる	役割ごとにトークンと指示書を分け、範囲の外は API が断る。お客様の社名も API が止める
4. 反映を始めるのは人	タグを作るのは人だけ。トークンの発行、鍵の値の入力、S3 への一括の移行も人が行う
5. 道具ごとに受け持ちを分ける	Claude Code は作業、API は判定と中継、AWS は保管と鍵、GitHub は変更の記録と反映、Apps Script は Google の中で完結する短い処理
6. お客様の前に自社で試す	お客様に提案している構成で先に作り、運用してつまずいたところを提案に戻す

1. 鍵を渡さない

AI エージェントの環境に置くのは、役割のトークン1つだけです。トークンが漏れても、できるのはその役割の範囲のことだけで、WordPress のパスワードや Google の鍵には届きません。万一のときは、トークンを失効させれば止まります。

2. 権限は1か所で決める

当社は11月に、技術ブログの役割にも汎用のナレッジへの追記と画像づくりを許しました。直したのは roles.py の1行と、そのテストです。トークンを作り直す必要はありませんでした。決まりが1か所にあると、「今だれが何をできるか」をこのファイルを見るだけで答えられます。

3. AI エージェントは範囲の中だけで使わせる

指示書で「こうしてほしい」と伝えるだけでなく、API が範囲の外を断ります。指示書に書き忘れや読み違いがあっても、見えない資料は使いようがありません。役割の指示書には、その役割で読める場所だけを書き、ほかの役割の場所を案内していないこともテストで確かめています。

4. 反映を始めるのは人

AI はプルリクエストまでを作り、取り込みとタグは人が行います。AI が書いたコードでも、どの版をいつ本番に出すかは人が決める、という分担です。

5. 道具ごとに受け持ちを分ける

見積書づくりを Apps Script に置いたのは、Google の中で完結する短い処理だからです。社内基盤の API に乗せると、Apps Script にトークンを置くことになり、考え方の1と3が崩れます。「どの道具でもできる」ときほど、鍵と権限がどこに増えるかで置き場所を決めています。

6. お客様の前に自社で試す

ECS から Lambda への移行も、まず自社で ECS の構成を一通り動かし、確認用と本番で切り替えを試してから行いました。費用・止め方・つまずいた点は、そのままお客様への提案の材料になっています。

連載のあとに変えたこと（2026年11月）

変えたこと	理由
API を ECS Fargate と ALB から、API Gateway と Lambda に移した	呼び出しのない時間は費用がかからず、確認用を止める手間もなくなるため（第10回）
確認用もタグで反映し、コンテナはタグのときだけ作る	置き場のコンテナと検査の費用が増えていたため
鍵の置き場を、反映のときに「無ければ空の形だけ作る」ようにした	人が手でスクリプトを動かす手間を省くため。値は今までどおり人が入れ、反映で上書きしない
コンテナの脆弱性を週1回まとめてメールで知らせる	使っている部品の脆弱性に気付くため。毎日だと多かったので週1回にした
背景画像を作る AI を、設定1つで Bedrock と Imagen から選べるようにした	AWS の中で完結させる方向を試すため
Apps Script で、提案資料の書き換えの知らせと見積書づくりを足した	社内基盤の API を通さずに済む、Google の中の短い処理のため

画像を作る AI を、設定1つで切り替える

背景画像づくりは、最初は Google の Imagen で作り、その2日後に AWS の Bedrock でも作れるようにして、Bedrock を使う設定にしました。どちらで作るかは設定ファイルの1か所で決まり、API がそれに合わせて作り分けます。

切り替えのときに、次のことが分かりました。

AWS 自身の画像モデル Amazon Nova Canvas は、2026年9月30日で提供が終わっていました。そこで Stability AI のモデル（Stable Image Core）を使うことにしましたが、東京リージョンには無いため、米国のリージョンのものを呼んでいます
このモデルは、AWS の各アカウントで、人が一度 Bedrock の画面から使えるようにしておく必要がありました。まだのときは、API が「人がすること」を書いたエラー（503）を返すようにしています
API のロールが呼べるのは、設定した1つのモデルだけです。Imagen を使う設定のときは、Bedrock を呼ぶ権限そのものを持ちません

AI のサービスは、提供の終了や置き場所の違いで、使えるものが変わりやすい部品です。中継を API の1か所にまとめておいたので、Claude Code の側の手順はほとんど変えずに済みました。

発注者向けメモ

AI エージェントの土台を開発会社に頼むときは、構成図を1枚もらい、次を確認すると全体が見えます。

「AI エージェントの環境には、どんな鍵やトークンが置かれますか。漏れたときに止める手順はありますか」
「だれが何をできるかの決まりは、どこに書かれていますか。テストで確かめていますか」
「本番への反映は、だれの、どの操作で始まりますか」
「使っている AI のサービスが提供を終えたとき、どこを直せば切り替えられますか」
「外部のサービス（Google など）で動かす処理は、社内の鍵やトークンを持ちますか」

役割の数が多い、外部のサービスへの中継が多い、お客様ごとに資料を分ける必要がある、といった条件があると、権限の表とテストが大きくなり、工数が増えやすくなります。

まとめと次回予告

構成図は、「鍵がどこにあるか」「権限がどこで決まるか」「反映をだれが始めるか」を確かめるための地図として描く
AI にはトークンだけを渡し、資料と鍵は AWS 側に置く。部品を変えても、この骨組みは変えない
AI のサービスや動かす場所は変わりやすい。中継と設定を1か所にまとめておくと、切り替えが小さく済む

次回は、ECS から Lambda へ、同じコンテナのまま移す 話です。当社が実際に移したときの手順と、つまずいた点を、サンプルのプロジェクトで再現します。

この連載の記事一覧

この記事は連載「Claude CodeとAWSで作るAIエージェントの土台」の1回です。連載のほかの回は次のとおりです（連載の一覧ページ）。

システム発注の相談をする

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

この記事を書いた人

TomonoTakaaki

問い合わせ

【Claude CodeとAWSで作るAIエージェントの土台第9回】構成図で振り返る：AI に鍵を渡さない土台の全体像と6つの考え方

この土台は何のためのものか

構成図