Claude Code × Terraform｜インフラ下書きと人間レビューの責任分界
目次 クリックで開く
クラウドインフラの構築において、Terraform（IaC）は標準的な地位を確立しましたが、コードの記述量が増えるにつれ、その保守コストやレビュー負荷がエンジニアを圧迫しています。この課題に対し、Anthropic がリリースした Claude Code（CLI ツールとして提供されるコーディングエージェント）は、単なる「コード生成」を超えた、リポジトリ全体を理解する実務的なパートナーとして機能します。
本記事では、Claude Code を用いて Terraform インフラの「下書き」を自動化し、人間がどの範囲でレビュー責任を負うべきかという責任分界点（Demarcation Point）の定義と、具体的な実装ワークフローを解説します。
コードを書かない人の始め方と、任せていい仕事の線引きを、動画にまとめています↓↓
Claude Code と Terraform が変えるインフラ運用のパラダイム
従来の IaC 開発では、エンジニアが公式ドキュメントを読み込み、HCL（HashiCorp Configuration Language）を記述し、terraform plan を叩いてはエラーを修正するという反復作業が中心でした。しかし、Claude Code の登場により、このフローは「エージェントへの意図伝達」と「生成された成果物の監査」へとシフトします。
Claude Code はローカルのリポジトリを直接スキャンし、既存のモジュール構成や変数定義を理解した上でコードを提案します。これにより、インフラエンジニアの役割は「コーダー」から、アーキテクチャの妥当性を判断する「レビュアー」へと一段階抽象化されます。
ブラウザ経由の Claude.ai と異なり、Claude Code は CLI 上で動作するため、リポジトリ内のファイル読み書き、コマンドの実行、さらには Git 操作までを自律的に行えます。Terraform においては、terraform plan の結果をそのまま読み取って「なぜ失敗したか」を自己解決できる点が、圧倒的な実務上のメリットとなります。
責任分界点の設計：AI は「下書き」、人間は「意図」の責任を持つ
AI エージェントをインフラ運用に導入する際、最も重要なのは「誰が最後に責任を取るか」を明確にすることです。Terraform はクラウドのリソースを直接破壊・作成する強力な権限を持つため、Claude Code に全権限を委譲するのは現実的ではありません。
推奨される責任分界モデル
実務においては、以下の表のように役割を分担することが、スピードと安全性を両立させる鍵となります。
| 項目 | Claude Code の責務（AI） | 人間の責務（エンジニア） |
|---|---|---|
| コード記述 | 構文の正確性、モジュール再利用、ボイラープレートの生成 | ビジネスロジックへの合致、特定ベンダー固有の制約確認 |
| セキュリティ | 既知のベストプラクティス（パブリックアクセスの拒否等）の適用 | 組織独自のポリシー、最小権限（IAM）の厳密な定義と承認 |
| 検証・テスト | validate、fmt、plan エラーの自動修正 | plan 結果の差分確認、本番環境への影響度判定 |
| 意思決定 | 代替案の提示、コスト見積もりの概算 | 最終的なプロビジョニング実行（Apply）の承認 |
このように、「Claude Code は最速で最高精度の『下書き』を作るが、最終的なハンコ（Approve）は人間が押す」というフローを徹底します。これは、データの流れにおいて自動化を進めるアーキテクチャと同様に、明確なガバナンスを必要とします。例えば、広告データの自動最適化において、データ基盤が「どの広告を配信するか」を決めても、予算の最終決定を人間が行うのと似た構造です。
関連記事：広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャ
実践：Claude Code で Terraform プロジェクトを爆速で立ち上げる
ここからは、実際にリポジトリ上で Claude Code をどのように動かすか、ステップバイステップで解説します。
1. CLAUDE.md による「憲法」の定義
Claude Code はプロジェクトルートにある CLAUDE.md というファイルを最優先で読み込みます。ここにインフラのコーディング規約を記述しておくことで、AI が出力するコードの品質を均一化できます。
Terraform Project Guide 全てのリソースには Environment と Owner タグを必須とする。 AWS プロバイダーのバージョンは 5.0 以上を使用すること。 機密情報は絶対に variables.tf のデフォルト値に書かず、secretsmanager を参照する構成にする。 コードを変更したら必ず terraform fmt と terraform validate を実行して確認すること。
2. Claude Code でのリソース生成フロー
ターミナルで claude を起動し、以下のような指示を与えます。
「AWS S3 バケットを追加して。静的ウェブサイトホスティングを有効にして、バケットポリシーはパブリック読み取り可能にする。ただし、CloudFront 経由のアクセスのみに制限する OAC 設定も下書きに入れて。」
Claude Code は既存の main.tf や outputs.tf を解析し、新しいリソース定義を追加します。さらに、必要な変数が足りなければ variables.tf を自動で更新します。
3. plan エラーの自律的解決
Claude Code の真骨頂はここからです。生成されたコードに対し、claude のプロンプト内で以下を指示します。
「今の変更を plan してみて。エラーが出たら修正して。」
Claude Code は内部で terraform plan を実行（ユーザーに実行許可を求めます）し、その標準出力を読み取ります。例えば、IAM ロールが既に存在する、あるいは依存関係の定義ミスで plan が落ちた場合、Claude Code はエラーログを分析し、「あ、失礼しました。エイリアスが重複していましたね」と自らコードを修正します。
エージェント駆動型開発フロー：GitHub CLI との連携
Claude Code は単体のツールとしてだけでなく、他の CLI ツールと組み合わせることで「PR 作成マシン」に昇華します。これは、バックオフィスの業務を AppSheet や Google Workspace で自動化する際の、ツール間の「糊」の役割に似ています。
関連記事：Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド
プルリクエストの自動生成ステップ
- ブランチ作成:
claude "チケット #123 のために新しいブランチを切って、VPC 設定を修正して" - コード修正 & ローカル検証: Claude Code が
terraform testや自作のバリデーションスクリプトを実行。 - PR 作成の Skills 呼び出し: Claude Code が
gh pr createコマンドを生成し、変更内容をサマリーとして PR 本文に記述。
この一連の流れにより、人間のエンジニアは「Slack に届いた PR の Diff を確認し、Terraform Cloud の plan 結果を見て Approve を押すだけ」の状態になります。手作業による CSV 連携を自動化して経理業務を効率化するように、インフラの「手作業によるコード記述」もまた、撲滅すべき負債なのです。
関連記事：楽楽精算×freee会計の「CSV手作業」を滅ぼす。経理の完全自動化とアーキテクチャ
インフラリソース種別 × Claude Code活用シナリオ × 人間承認が必要なポイント × リスクレベル 早見表
前のセクションでGitHub CLIとのエージェント駆動型開発フローを説明しましたが、「どのインフラリソースにClaude Codeを当てるか」によってリスクレベルと人間承認の要否が大きく変わります。ステートレスなLambda関数のTerraformコード生成と、本番DBのセキュリティグループ変更では、同じClaude Codeを使っていても人間が介入すべき度合いが根本的に異なります。以下の表はリソース種別ごとの活用指針をまとめたものです。
| インフラリソース種別 | Claude Code活用シナリオ | リスクレベル | 人間承認が必要なポイント | Terraform設計の注意点 |
|---|---|---|---|---|
| Lambda関数・Cloud Functions （ステートレス・イベント駆動） |
「このPythonスクリプトをLambda関数のTerraformモジュールに変換して、S3トリガーの設定も含めて」という指示でClaude Codeがコード生成。IAMロールの最小権限設定も一緒に生成させる | 低（関数は状態を持たないため、誤った設定でも影響範囲がその関数の実行に限定される。削除・再デプロイが容易） | IAMポリシーの権限スコープ確認（最小権限の原則が守られているか）。環境変数として渡すAPIキー・シークレットの取り扱い確認。Lambda timeout・メモリ設定の妥当性確認 | Lambda関数のTerraformコードはClaude Codeで生成しやすいが、`terraform plan`で差分を必ず確認してから`apply`する。既存のLambda実行ロールを流用する場合は、そのロールが他の関数と共有されていないか確認する |
| EC2インスタンス・ECS・GCE （ステートフル・長期稼働） |
「t3.medium×3台のAuto Scalingグループを、最小1台・最大5台・CPU70%でスケールアウトするTerraformで書いて」という具体的な要件でClaude Codeがベースラインを生成する | 中（インスタンスは状態を持つため、誤ったterraform destroyやAMI変更が本番サービスに影響する。Auto Scalingの設定ミスが過剰課金につながるリスクもある） | インスタンスタイプとコストの妥当性確認（想定月額の概算を計算する）。本番環境へのapply前にstaging環境でのテスト確認。AMI IDが正しいリージョンの最新版を指しているか確認。Auto Scalingポリシーのしきい値が適切かのレビュー | インスタンスのTerraform stateファイルは厳重に管理する（S3+DynamoDBでlockingを設定）。Claude Codeが生成したコードで`lifecycle { prevent_destroy = true }`の設定が漏れていないか確認する |
| RDS・Cloud SQL・Firestore （データベース・永続ストレージ） |
「RDS PostgreSQL 14のTerraformモジュール（Multi-AZ・バックアップ7日間）を書いて。パラメータグループでmax_connectionsとshared_buffersも設定して」という詳細要件でClaude Codeが初稿を生成する | 高（DBインスタンスはサービスの心臓部。設定ミスによるダウンタイム・データ損失・セキュリティグループの設定ミスによる外部露出は深刻な事故につながる） | ①セキュリティグループのインバウンドルールが最小化されているか（VPC内からのみアクセス許可）。②バックアップの保持期間と自動バックアップ時刻の設定。③暗号化設定（at_rest・in_transit）。④削除保護の設定（`deletion_protection = true`）。このリソースは本番適用前にシニアエンジニアのレビューを必須とする | DBのTerraformは`terraform plan`の出力で`~`（変更）が本番DBに影響しないかを特に慎重にレビューする。Claude Codeが生成したコードに`force_destroy = true`または`skip_final_snapshot = true`が含まれていないか確認する（誤削除によるデータ損失防止） |
| IAM・セキュリティグループ・KMS （権限・ネットワーク・暗号化） |
「最小権限のIAMポリシーで、S3の特定バケットのGetObject・PutObjectだけ許可するポリシーJSONをTerraformで書いて」という明確な権限要件でClaude Codeが安全なポリシーの初稿を生成する | 最高（IAMポリシーのミスが権限昇格・情報漏洩につながる。セキュリティグループの設定ミスが外部からの不正アクセスにつながる。これらのリソースへの変更は最も慎重に扱う必要がある） | ①ワイルドカード（`*`）の使用箇所の全確認（特にAction: *・Resource: *は絶対に本番不可）。②クロスアカウントアクセスの有無確認。③KMSキーの削除保護設定（`enable_key_rotation = true`・`deletion_window_in_days = 30`）。④セキュリティグループのアウトバウンドルールが全開になっていないかの確認 | IAM・セキュリティ関連のTerraformはClaude Codeが生成した後にセキュリティ専門家のレビューを必ず実施する。AWS Access Analyzer・GCP IAM RecommenderなどのネイティブツールでClaude Codeが生成したポリシーをスキャンする |
この表で最もClaude Codeの費用対効果が高いのが「Lambda関数・Cloud FunctionsのTerraformコード生成」です。ステートレスで削除・再デプロイが容易なため、Claude Codeが生成したコードを`terraform plan`で確認してそのまま`apply`するサイクルが最も安全に回せます。一方でRDS・IAMはリスクが高く、Claude Codeは「最初の設計たたき台」としてのみ使い、シニアエンジニアの詳細レビューを挟む運用ルールを設計段階から設けることが、インフラ事故防止の鍵です。
運用上の壁と解決策：セキュリティとコンプライアンス
Claude Code を導入する上で、情報システム部門が最も懸念するのは「機密情報の取り扱い」です。
1. データの保護とプライバシー
Anthropic の公式ドキュメントによれば、Claude Code（および API 経由の利用）において、送信されたデータがモデルの再学習に使用されることはありません（※Enterprise / Team プラン等の規約に準ずる）。しかし、プロンプトに AWS のシークレットキーを貼り付けるような行為は依然としてリスクです。
2. .claudecode/ignore の活用
リポジトリ内の特定のファイル（例：秘密鍵、機密ドキュメント）を Claude に見せたくない場合は、.claudecodeignore を作成します。これにより、インフラの機密性を保ちつつ、構造的な部分だけを AI に支援させることが可能です。
3. 人間による「最終防衛線」
どんなに Claude Code が優秀でも、terraform apply だけは CI/CD パイプライン（GitHub Actions 等）を通し、人間が環境変数やステートへの影響を最終確認するフローを維持してください。Claude Code はあくまで「最高のアシスタント」であり、インフラの「所有者」ではありません。
まとめ：AI エージェントをインフラの「盾」にするか「剣」にするか
Claude Code × Terraform の運用は、開発スピードを劇的に向上させる「剣」であると同時に、設定ミスや構文エラーを自動で検知・修正してくれる「盾」でもあります。重要なのは、人間が抽象度の高い「意図」と「承認」に集中し、退屈な「実装」と「デバッグ」を AI に任せるという責任分界の再構築です。
この変化は、単なるツールの導入ではなく、組織のエンジニアリング文化そのものをアップデートします。まずは小さなモジュールの作成から Claude Code を使い始め、その「下書き」の精度を体感してみてください。
TerraformのIAMポリシーやセキュリティグループをClaude Codeに下書きさせる場合、ワイルドカード権限の混入を防ぐレビュー手順と、シークレットを本番設定ファイルに書かせない設計が最初に固めるべき責任分界になります。Terraform×Claude Codeの導入方針を整理したい場合は、Claude Code 導入支援にご相談ください。
生成AIの法人導入・セキュリティ設計のご相談
ChatGPTやClaudeなど生成AIのプラン選定・セキュアな全社導入・権限／ログ設計を、貴社の体制に合わせて整理します。すでに導入済みの環境について『この設計で問題ないか』を確認したい、という導入前後のセカンドオピニオンにも対応しています。
AI活用支援
Claude・ChatGPT・Gemini・Copilotのどれをどの業務に使うかの見極めから、社内のAIチャット環境、権限と情報の扱いの設計、MCPやAPIでの既存システム連携、研修・伴走までを支援します。