Claude Code / Codex / Kiro に AWS 権限を 渡すとき、何を設計すべきか

Claude Code / Codex / Kiro などのコーディングエージェントが AWS を操作するとき、AWS 側に残るのは IAM プリンシパルと API 実行の記録だけです。「AIが実行した」という情報はどこにも自動では残りません。

本資料では、コーディングエージェントから AWS API に届くまでの経路を整理し、人間用ロールを流用したときに何が説明できなくなるかを示します。その上で Claude Code / Codex / Kiro をエンタープライズ統制の観点（強制できるもの・監査の入口・停止単位）で比較し、AWS 側での設計順序（短命認証情報・MCP 経路識別・ロール分離・ログ対応づけ・停止 runbook）を解説します。

最初に決めるべきことは3つ——誰に何を許すか、何を記録するか、どう止める・戻すか。この3点を本番許可前に答えられる状態にすることがゴールです。

対象: コーディングエージェントに AWS 権限を渡している、または渡そうとしている開発者・SRE・セキュリティ担当
イベント: Security-JAWS DAYS 2026 Day 1 / Level 300 / 2026-05-16
https://s-jaws.connpass.com/event/383751/

Transcript

1. SECURITY-JAWS Claude Code / Codex / Kiro に AWS 権限を 渡すとき、何を設計すべきか コーディングエージェントにAWS権限を渡すとき、許可・記録・停止を設計する Security-JAWS DAYS 2026 Day 1 / 2026-05-16 Kazuki-Adachi / 足立 和生
2. 自己紹介 Kazuki-Adachi / 足立 和生 アジアクエスト株式会社 / X: @k_adachi_01 2025 Japan AWS Jr. Champion 2025 Japan All AWS Certifications Engineer AWS Community Builder (Dev Tools) JAWS-UG配信部 普段は客先常駐でPMOとして、要件の橋渡しをしています。好きなAWSサービスはAWS CDKとKiroです。 今日の視点: 開発者体験とAWS統制の間で、AIエージェントの操作経路をどう説明できる形にするか 2
6. 今日話すこと 1 コーディングエージェントがAWSへ届く経路を定義する 2 人間用ロールを流用すると何が説明できなくなるかを見る 3 Claude Code / Codex / Kiro をエンタープライズ統制で比べる 4 導入前に、許可・記録・停止をどう決めるか ここでのAIエージェントは、Claude Code / Codex / Kiro のようなコーディングエージェントを指す。今日の ゴールは、AWSに届く操作を、誰に許すか、何を記録するか、どう止めるかで説明できるようにすること。 6
7. 今日話さないこと 一般的な安全設定の網羅 Claude Code / Codex / Kiro を 安全に使うための一般ベストプ ラクティスは公式ドキュメント を参照する。 .env / secret管理の詳細 秘密情報の置き場所、漏えい防 止、ローテーション手順そのも のは深掘りしない。 サンドボックス実装の詳 細 devcontainer、権限プロンプ ト、端末上のpermission制限の 作り込みは扱わない。 参照先: Claude Code Security、Codex Agent approvals & security、Kiro Privacy and security。ここ ではAWS APIに届く操作経路に絞る。 Claude Code Security: https://code.claude.com/docs/en/security Codex Agent approvals & security: https://developers.openai.com/codex/agent-approvals-security Kiro Privacy and security: https://kiro.dev/docs/cli/privacy-and-security/ 7
8. 最初に決めるのは3つ 1 誰に何を許すか 2 何を記録するか 3 どう止める・戻すか 8
9. 今日話すこと 1 コーディングエージェントがAWSへ届く経路を定義する 2 人間用ロールを流用すると何が説明できなくなるかを見る 3 Claude Code / Codex / Kiro をエンタープライズ統制で比べる 4 導入前に、許可・記録・停止をどう決めるか 9
10. 本番AWSへのアクセス経路が増えている AIコーディング エージェント >_ CLI ローカル端末 / aws cli </> SDK / API boto3・AWS SDK・API 呼び出し Cloud SaaS / Hosted Agent / Remote Runtime </> IDE / 拡張機能 IDE連携から実行 aws IAM / Identity Center STS CloudShell Lambda S3 CloudWatch 経路ごとに 実行場所・認証情報・到達先・監査方法 が異なる 10
11. 事故は「消した」だけではない 見る 必要以上のlog groupや期間を読 む。ReadOnlyでも本番情報の取 得になる。 変える 調査のつもりでpolicyやtrust policyを変える。将来の権限経 路が変わる。 通す workflowやOIDC roleを緩め る。今AWS APIを呼ばなくても 次回deployに効く。 削除APIを呼んでいなくても、機密情報の取得、権限経路の変更、次回deployへの影響は事故として扱う 11
12. AWSから見えるのは、AIエージェントではなく IAMプリンシパル と API実行 12
13. 今日話すこと 2 人間用ロールを流用すると何が説明できなくなるかを見る 1 コーディングエージェントがAWSへ届く経路を定義する 3 Claude Code / Codex / Kiro をエンタープライズ統制で比べる 4 導入前に、許可・記録・停止をどう決めるか 13
14. CloudTrailにはAIの名前は残らない AWS CloudTrail AWS IAM eventTime 2026-05-16T01:03:42Z eventName FilterLogEvents userIdentity arn:aws:sts::123456789012:assumed-role/AgentObservationRole/session-abc sourceIPAddress 203.0.113.10 requestID 7a6b-...-91f2 CloudTrailは土台。依頼文、承認、ツール実行ログとつなげて初めて説明できる 14 確認日: 2026-05-16 / AWS CloudTrail User Guide
16. この発表では、認証情報を使ってAWS APIを呼べ る状態を「AWS操作」と呼ぶ 16
17. AIがAWSを操作するまでの過程 欠けた部分があるほど、 「なぜそのAPIが呼ばれたか」を後から説明しにくくなる 1 依頼 本番5xxの原因を見て 2 承認 prod logs readを許可 3 ツール aws logs filter-log-events 4 IAM AgentObservationRole 5 AWS API FilterLogEvents 17
18. AWS操作はdeployだけではない 調査 logs、metrics、config、 security findingsを見る 変更案 IaC、IAM、GitHub Actions workflowの差分を作る 実行 AWS CLI、SDK、MCP、CI/CD からAWS APIを呼ぶ deployしていなくても、prod情報・IAM・workflowに触るなら本番影響として扱う 18
19. Claude Code / Codex / Kiro を、エンタープライ ズ向けの統制で比べる 19
20. 今日話すこと 3 Claude Code / Codex / Kiro をエンタープライズ統制で比べる 1 コーディングエージェントがAWSへ届く経路を定義する 2 人間用ロールを流用すると何が説明できなくなるかを見る 4 導入前に、許可・記録・停止をどう決めるか 20
21. ユーザー向け機能は比較軸にしない ルール / Steering リポジトリごとの指示、組織ル ール、コーディング規約の読み 込み。 MCP / Skills 外部ツール、ドキュメント、 AWS API、社内システムへの接 続。 Hooks / memory / subagents 実行前後の制御、履歴の活用、 タスク分担の仕組み。 これらは数か月で近い機能が実装されやすい。比較対象は、組織が何を強制でき、何を監査できるかに寄せる。 21
22. 比較軸はエンタープライズ統制に寄せる 1 誰のIDで使わせるか 2 MCPや外部ツールをどこまで許すか 3 approval / sandbox を組織側で強制できるか 4 監査ログをどこから取得し、CloudTrailとつなげるか 5 問題時にどの単位で止められるか 22
23. Claude Code は端末上の実行制御を細かく縛る Claude Code OpenTelemetry AWS CloudTrail 強制できるもの managed settingsで permissions、hooks、MCP、 network、skillsを組織側から制 御する。user / project / CLIより 上位に置ける。 監査の入口 tool activity、metrics、 events、ConfigChange hooks をOpenTelemetryやログ基盤へ 送る。 AWSとの接続点 端末上のAWS profile、環境変 数、MCP Server、CI/CDへの変 更を分けて見る。 最初に疑うこと: prod profileが見える端末で、そのまま本番調査をしていないか 23 確認日: 2026-05-16 / Claude Code Security and Monitoring docs
24. Codex はsandboxとapproval policyを管理する Codex AWS CloudTrail GitHub / CI/CD 強制できるもの local / cloudの実行場所、 sandbox、approval policy、 web search、MCP allowlistを managed requirementsで制御 する。 監査の入口 Compliance API、Analytics API、GitHub連携ログ、taskや workspaceの履歴を見る。 AWSとの接続点 ChatGPT認証とAPI key認証で監 査境界が変わる。CloudTrail、 PR、CI/CD run idを対応づけ る。 Codex側ログだけ、またはAWS側ログだけで説明を閉じようとしない 24 確認日: 2026-05-16 / OpenAI Codex security and Compliance API docs
25. Kiro はAWS管理プレーンに寄せて統制する Kiro IAM Identity Center Amazon S3 強制できるもの IAM Identity Center、Kiro console、shared settings、 models、MCP registry、API keys。 監査の入口 S3へのプロンプトログ、AWS管 理プレーン、IAM Identity Center、CloudTrailを確認す る。 注意点 MCP governanceはclient-side enforcementの注意がある。 IDE、CLI、Webで適用される設 定も分けて確認する。 「KiroならAWS統制に寄せやすい」は、どのクライアントかを添えて話す 25 確認日: 2026-05-16 / Kiro docs: IAM Identity Center, MCP governance
26. 提携が進むほど管理境界は変わる 発表日: Claude Platform on AWS は 2026-04-16、OpenAI on AWS は 2026-04-28。どちらもAWS側の IAM、請求、監査へ寄せる流れ。 Claude Platform on AWS AWS IAM、AWS billing、CloudTrail監査を組み合わ せて、AnthropicのClaude Platformへアクセスする 選択肢。Bedrockとは分けて見る。 OpenAI on Bedrock OpenAI models、Codex on Amazon Bedrock、 Bedrock Managed Agents powered by OpenAI は 限定プレビューとして扱う。 現時点の比較は固定ではない。AWS側に残るログと提供元側に残るログを分けて見る。 26 確認日: 2026-05-16 / AWS, Anthropic, OpenAI announcements
27. 3ツール比較はこの粒度にする 問い Claude Code Codex Kiro 管理の中 心 Claude組織 + 端末managed settings ChatGPT Enterprise + local/cloud config AWS + IAM Identity Center + Kiro console 強制した いこと permissions、hooks、MCP、 network、skills sandbox、approval policy、web search、MCP allowlist models、MCP registry、API keys、Web tools 監査の入 口 OpenTelemetry、config change、CloudTrail対応 Compliance API、Analytics API、 GitHub、CloudTrail対応 S3 prompt logs、AWS管理プレ ーン、CloudTrail対応 注意点 端末管理が前提 AWS側ログだけではCodex由来と断 定しない Kiro WebとIDE/CLI governance を分ける 結論: 同じ「コーディングエージェント」でも、強制できる場所、ログ、停止単位が違う 27
28. 今日話すこと 4 導入前に、許可・記録・停止をどう決めるか 1 コーディングエージェントがAWSへ届く経路を定義する 2 人間用ロールを流用すると何が説明できなくなるかを見る 3 Claude Code / Codex / Kiro をエンタープライズ統制で比べる 28
29. ここからAWS側で決める順番 1 認証情報を短命化する 2 MCP経路を識別する 3 roleを人間 / AI / CIで分ける 4 ログを対応づける 5 停止と戻し方をrunbookにする 29
30. Agent Toolkit for AWS は統制部品 AWS DevOps Agent AWS CloudTrail AWS IAM 発表日: 2026-05-06。Agent skills、fully-managed AWS MCP Server、agent pluginsをまとめた、AI coding agent向けのAWS公式ツールキット。 AWS MCP Server managed MCP経由でAWSドキ ュメント検索やAWS API実行へ つながる。 Agent skills / plugins Claude Code、Codex、Kiroな どのMCP対応エージェントで使 う部品になる。 見るべき点 どのIAM権限で実行し、 CloudTrailにどう残り、どう止 めるか。 ここからの順番: 短命認証情報、MCP識別、ロール分離、ログ対応づけ、停止runbookへ落とす 30 確認日: 2026-05-16 / AWS Agent Toolkit for AWS docs
31. AWS側で決める順番 2 MCP経路を識別する 1 認証情報を短命化する 3 roleを人間 / AI / CIで分ける 4 ログを対応づける 5 停止と戻し方をrunbookにする 31
32. MCP Proxy for AWS はSigV4の橋渡し MCP client Claude Code / Codex / Kiro > MCP Proxy SigV4 via Proxy > AWS MCP Server AWS managed MCP > AWS API CloudTrail ここで見るのは「MCPかどうか」ではなく「誰の認証情報で、どのAWS APIへ届くか」 32 確認日: 2026-05-16 / AWS MCP Server setup docs
33. AWS MCP Server GAで監査の入口が増えた AWS IAM AWS managed MCP 大きな変更 2026-05-06にAWS MCP ServerがGA。managed serverになり、IAM-based guardrails、 CloudTrail、CloudWatchで扱いやすくなった。 条件キーの扱い aws:ViaAWSMCPService と aws:CalledViaAWSMCP は、AWS managed MCP server経由のリクエストをIAM条件で扱う文脈で使 う。 MCPは安全装置ではなく、経路を識別・制限できる場合がある部品として扱う 33 確認日: 2026-05-16 / AWS MCP Server GA, AWS IAM global condition keys
34. AWS側で決める順番 1 認証情報を短命化する 2 MCP経路を識別する 3 roleを人間 / AI / CIで分ける 4 ログを対応づける 5 停止と戻し方をrunbookにする 34
35. aws login は長期アクセスキーを減らす選択肢 AWS IAM AWS CloudTrail 使いどころ ブラウザからAWS Management Consoleへログイ ンし、AWS CLI / SDK向けの一時認証情報を使う。 残る設計 短命認証情報にしても、AIエージェント用role、許 可範囲、CloudTrail対応づけは別に必要。 アクセスキーを置かないことと、何でも実行できないことは別の問題 35 確認日: 2026-05-16 / AWS MCP Server setup docs
36. AWS側で決める順番 3 roleを人間 / AI / CIで分ける 1 認証情報を短命化する 2 MCP経路を識別する 4 ログを対応づける 5 停止と戻し方をrunbookにする 36
37. IAMロールは追跡と停止の単位でも分ける AWS IAM AWS CloudTrail role 用途 止め方 HumanDeveloperRole 人間の通常開発 人間のSSO権限を保つ AgentObservationRole AIエージェントの調査 AI用profileやpolicyを外す AgentDevWriteRole dev環境の限定変更 devだけ停止する DeployRole CI/CD deploy workflow / environment approvalで止める 最小権限だけでなく、 「CloudTrailで区別できるか」 「AIエージェントだけ止められるか」を見る 37
38. 環境ごとに許す操作を変える dev 限定write、logs read、 sandbox deploy。危険操作は deny。 stg logs read、変更案、限定 deploy。prod role assumeは 禁止。 prod 一部logs read、提案、CI/CD経 由deploy。直deployやdelete は禁止。 同じAIエージェントでも、dev / stg / prodで承認条件を変える 38
39. 承認は危険度で段階化する 自動 dev logs read、コード提案、IaC差分の生成 permission: auto sandbox: local read-only ops 確認 prod logs read、deploy、外部MCP呼び出し permission: ask approval policy Kiro console 拒否 prod IAM変更、trust policy変更、prod direct delete managed deny managed deny IAM deny 全操作を自動化しない。全操作に同じ承認も求めない 39
40. AWS側で決める順番 4 ログを対応づける 1 認証情報を短命化する 2 MCP経路を識別する 3 roleを人間 / AI / CIで分ける 5 停止と戻し方をrunbookにする 40
41. ログは1か所に集まらない AWS CloudTrail Amazon CloudWatch Amazon S3 CI/CD ログ 保管先の例 対応づけに使う情報 AWS API CloudTrail / CloudTrail Lake eventTime、IAMプリンシパル、request id app / infra CloudWatch timestamp、resource、account AIエージェント OpenTelemetry、S3、サービス側ログ user、session、task、time PR / CI/CD GitHub PR number、run id、commit SHA 「ログがあるか」ではなく「どのキーで結合できるか」を導入前に決める 複数ログを結合して可視化している知見がある方、ぜひ後で聴かせてください 41
42. 検知は具体的なルールから始める AWS CloudTrail Amazon CloudWatch CloudTrail / CloudWatch Agent系roleで Delete* 、 PutRolePolicy 、 UpdateAssumeRolePolicy 、prod log大量読取を 検知する。 エージェントログ 承認なしのtool実行、MCP server追加、danger mode、同一promptからの連続失敗を検知する。 CloudTrailのAPI名と、エージェント側のtool / approval / session idを同じアラートに載せる 42
43. 調査は時刻とIDで突合する 10:01 依頼: 本番5xx調査 10:02 承認: prod logs read許可 10:03 ツール: aws logs filter-log-events 10:03 CloudTrail: FilterLogEvents / request id / role session 10:08 PR: workflow変更案 / commit SHA / CI run id 調査票には、prompt id、approval id、tool call id、CloudTrail request id、PR番号を並べる 43
44. 再発防止は設定変更に落とす 経路 MCP allowlist、network allowlist、CI workflow permissionsを直す。 権限 AgentRoleのpolicy、trust policy、session duration、 deny条件を直す。 運用 approval policy、 OpenTelemetry export、 CloudTrail Lake query、 runbookを直す。 「気をつける」ではなく、次に同じ経路で起きない形へ変える 44
45. AWS側で決める順番 5 停止と戻し方をrunbookにする 1 認証情報を短命化する 2 MCP経路を識別する 3 roleを人間 / AI / CIで分ける 4 ログを対応づける 45
46. 停止方法は4つ用意する コーディングエージェント側 AWS側 利用者 IDE / CLI / CI AIコーディング エージェント workspace tool permission MCP / plugin / workflow 認証情報 SSO session / profile / Access Key / AssumeRole AWS SDK / CLI でAPI呼び出し 署名付きリクエスト AWS API IAM評価 identity-based policy / SCP / permission boundary / explicit deny / role trust 各AWSサービス S3 Cloud Formation Bedrock Lambda 1 入口 workspace・tool permission でAIエージェントを止める 2 認証情報 profile削除・SSO session失効・ Access Key rotate 3 権限 policy detach・deny追加・ role trust変更 4 実行経路 MCP server停止・workflow disable・plugin無効化 人間やCI/CDまで全部止めず、AIエージェントだけ止める単位を作る 46
47. 導入前にそろえる問い 1 どこで動き、何を読めるか 2 どのIAMプリンシパルになり、人間操作と区別できるか 3 dev / stg / prodで許可と承認を分けているか 4 CloudTrail、ツールログ、PRを時系列でつなげるか 5 AIエージェントだけ止める手順があるか 網羅チェックリストではなく、本番許可前に最低限答える問いとして使う 47
48. 既に強いAWS権限を渡しているなら 1 AIエージェントからprod Admin profileを見えなくする 2 AIエージェント用profileと観測専用roleを作る 3 MCP / plugin / CI/CD のAWS到達経路を棚卸しする 4 長期アクセスキーをrotateし、短命認証情報へ寄せる 5 CloudTrail、ツールログ、PRの対応表を作る 最初の1時間でやるなら、prod profile除去とMCP棚卸しから始める 48
49. 最初に決めるのは3つ 1 誰に何を許すか 2 何を記録するか 3 どう止める・戻すか 49
50. まとめ AIエージェントのセキュリティは、モデルではなく 誰に許し、何を記録し、どう止めるかの設計問題 50
51. JAWS SONIC 2026 & MIDNIGHT JAWS 2026 開催日時 2026/09/05(土) 12:00 - 2026/09/06(日) 12:00 概要 JAWS-UGによる24時間ぶっ通しのOnline Festivalが、約 6年ぶりに復活。全国のJAWS-UG支部が協力し、24時間 リレー形式で最新技術からコミュニティの知見まで扱い ます。 ハッシュタグ #jawssonic2026 51 確認日: 2026-05-16 / connpass