Claude CodeでETLジョブ実行テス トを自動化してみた 2026-04-24 / kasama 

kasama Classmethod データエンジニア 専門: AWSデータ基盤 最近の関心事: Claude Codeで業務自動化 自己紹介 2 

Claude Code で AWS 操作を含むテストを安全に自動実行する ための設計の 勘所 dontAsk mode で 自動実行 devcontainer で実行環境を隔離 IAM policy で AWS 側の最終ガード → 事故なく自動実行を成立させる このLTで伝えたいこと 3 

1. テスト対象のETLパイプライン 2. 前提環境 3. 自動化前のテスト手順と課題 4. 自動化の全体像 5. 検討ポイント① 実行方式（Ralph Loop vs 現方式） 6. 検討ポイント② 権限モード（→ dontAsk ） 7. 補足: auto mode の評価フロー 8. 補足: auto mode の進化（v2.1.118） 9. 検討ポイント③ 隔離環境（→ devcontainer）+ 認証フロー 10. 検討ポイント④ AWS 側のIAM権限（最終ガード） 11. 最後に 目次 4 

AWS 認証 IAM ユーザー（MFA デバイス設定済み、アカウントA） スイッチロールしてアカウントBの IAM Role で操作（1時間セッション、MFA必須） aws-vault + 1Password CLI を credential_process 経由で使用 aws ... --profile で認証完了する状態 ローカル環境（macOS） AWS CLI v2 / Python 3.9+ / Node.js 18+ / pnpm VS Code + Dev Containers 拡張機能 aws-vault + 1Password CLI + 生体認証のチェーンは macOS 固有のためホスト側で動作 前提環境 5 

EventBridge → Step Functions（Lambda呼出）→ DuckDBでCSV→Parquet変換 → Icebergテーブル更新 テスト対象のETLパイプライン 6 

従来は AWS Management Console から手動実行。画面を順に操作する必要があった。 1. Step Functions 画面で「新しい実行の開始」 2. ジョブ完了まで画面を眺める（数分待機） 3. Athena 画面でクエリ実行、Iceberg テーブルの書込内容を検証 4. S3 画面で archive パスにファイル移動されたか確認 5. テスト失敗 → 1 からやり直し 課題: 画面遷移・入力・目視確認の往復で疲弊。エビデンスの取得も手作業 → Claude Code で 自動化できないか？ がスタート地点 自動化前のテスト手順と課題 7 

自動化の全体像 8 

Claude Code を自動実行する方法は主に2つ。 claude -p + --allowedTools （Ralph Loop）: shell scriptから claude -p をループで呼 出、glob で allow-list claude --permission-mode dontAsk + permissions.allow / deny ← 採用: 単一セッション で実行、allow-list を JSON で集中管理 Ralph Loop を採用しなかった理由 skill ベースの宣言的ワークフロー管理を優先（Ralph Loop は shell script で workflow 実装 が必要） 単一セッションでのコンテキスト維持を優先（複数ステップで状態・前提を共有できる） 参考: https://ghuntley.com/loop/ 検討ポイント① 実行方式（Ralph Loop vs 現方式） 9 

モード 未マッチツールの挙動 deny 評価 allow 評価 default / plan プロンプト表示（対話必要） ✓ ✓ acceptEdits 編集とファイル操作 Bash（mkdir/mv/cp/rm 等）は自 動、他の Bash はプロンプト ✓ ✓ auto 分類器で判定 + カスタム allow/soft_deny で補強可 ✓ ✓ bypassPermissions すべて実行（無防備） ✗ ✗ dontAsk ← 採用 自動拒否 ✓ ✓ → dontAsk のみ「allow-list に無い = 自動拒否」で、完全自動実行に適する 参考: https://code.claude.com/docs/en/permission-modes 検討ポイント② 権限モード 10 

auto mode は 2段階ゲートでツール呼び出しを判定する Stage 1: permissions （パターンマッチで即決） 記述: ツールパターン（例: Bash(aws s3 ls:*) / Read(/tmp/*) ） 一致すれば即確定: deny = ハードブロック、 allow = 即承認 一致しなければ Stage 2 へ委譲 Stage 2: 分類器 / autoMode （分類器に"方針"を自然言語で指示） 分類器がツール呼び出しを自然言語ルールに照らして判定 autoMode.soft_deny = 原則ブロックしたい行為のリスト（会話の明示意図で覆せる＝ソフト） autoMode.allow = soft_deny でブロックされた行為のうち「これは OK」と例外を指定するリスト 違い: permissions.* は正確なツール名で即決（堅い）／ autoMode.* は分類器への方針指示 で、意味レベルで判定される（柔軟だが曖昧） 参考: https://code.claude.com/docs/en/auto-mode-config 補足: auto mode の評価フロー 11 

v2.1.118〜: 独自ルールでビルトイン安全ルールが完全に上書きされていたものが "$defaults" でビルト インを継承可能に { "autoMode": { "soft_deny": [ "$defaults", "Never modify files under infra/terraform/prod/" ], "allow": [ "$defaults", "Editing infra/terraform/prod/staging-mirror/ is allowed" ] } } 使い分け: permissions.allow / deny を網羅できれば auto も決定論的に動く。未指定ツールが来た場 合、 dontAsk は即拒否（決定論）／ auto は分類器判定（非決定論） 。今回は未知のツールを確実に拒否 したかったため dontAsk を採用 補足: auto mode の進化（v2.1.118） 12 

隔離環境 判定 備考 ホスト直接 ✗ Claude がログインユーザの全権限で動作。~/.ssh、~/.aws、どこでも読み書きできる /sandbox ✗ Bash からのプロジェクト外への「書き込み」と未許可ドメインへの「通信」だけ制限。 「読み取 り」と Read/Edit/Write は無制限 devcontainer ◎ ← 採用 Docker コンテナの中で動作。ホスト側はプロジェクトフォルダしか見えない、他は一切触れな い devcontainer を選んだ理由 被害は mount 先に限定: ホスト全体のファイルシステムを守れる 参考: https://code.claude.com/docs/en/sandboxing 検討ポイント③ 隔離環境 13 

IAM アクセスキーはホスト側に留め、一時認証情報だけをコンテナに渡す ホスト macOS 1. aws-vault exec --duration=2h -- code . で VS Code を起動 2. aws-vault が Keychain から IAM アクセスキーを読取 3. op read で 1Password から MFA TOTP を自動取得（Touch ID で 1Password unlock） 4. sts:AssumeRole で一時認証情報を発行 → VS Code プロセスに export devcontainer devcontainer.json の containerEnv で ${localEnv:AWS_*} を forward 一時認証情報はメモリ上の環境変数のみ、ディスクには書かれない 2時間で期限切れ → VS Code を閉じる → aws-vault exec で再起動 → Rebuild Container 検討ポイント③（続き）devcontainer の認証フロー 14 

Claude Code 側の allow-list は補助。万一突破されても AWS 側の IAM ロールで止まる 設計。 Claude Code 側（補助） permissions.allow : Bash(aws s3 *) 等、利用想定のサブコマンドのみ permissions.deny : Bash(rm -rf *) / Bash(aws s3 rm *) / Bash(cdk destroy *) 等 IAM ロール（最終ガード） ReadOnlyAccess + 必要な write のみ許可（ states:StartExecution / athena:StartQueryExecution / s3:PutObject / glue:StartJobRun / events:PutEvents ） 。そ れ以外は default deny 検討ポイント④ AWS側のIAM権限をガードレールに 15 

まとめ Claude Code の Skills + Hooks で ETL テストを 一気通貫で自動化（テスト計画生成 → ジョ ブ実行 → エビデンス記録 → サマリ作成） dontAsk mode × devcontainer × IAM policy の多層防御で安全に自動実行可能に 自動テスト後のAIフィードバックで改善提案が自動で検出・記録されるのは AI ならではのメリッ ト 実装詳細・実際の動作はブログを参照してください Claude CodeでETLジョブ実行テストを自動化してみた | DevelopersIO 最後に 16 

ご清聴ありがとうございました