TerraformやOpenTofuを使ったInfrastructure as Code（IaC）は、アプリケーションコードと同じようにPull Requestでレビューできます。ただし実際の現場では、差分が多い、providerの挙動が読みにくい、tfstateに触れる操作が怖い、plan結果の読み解きが属人化する、という理由でレビュー負荷が高くなりがちです。
この記事では、Claude Codeを「インフラ変更レビューの補助者」として使い、Terraformのplan差分、ポリシー、CIログ、runbookを横断して確認する標準手順をまとめます。Claude Codeそのものについては公式のOverviewで、コードベースを読み、ファイル編集やコマンド実行、開発ツール連携を行うエージェント型コーディングツールとして説明されています。本記事ではその前提を、業務導入したいエンジニア向けにIaCレビューへ落とし込みます。
重要なのは、Claude Codeに本番環境の変更を丸投げしないことです。人間がレビュー責任を持ち、Claude Codeには「差分の要約」「リスクの列挙」「確認コマンドの提案」「PRコメントの草案化」「チェックリストとの突合」を担当させます。架空の削減率やベンチマークは置かず、まず再現性の高いレビュー手順として設計するのが安全です。
この記事の結論
Terraform変更レビューでClaude Codeを使うなら、最初に決めるべきことは「どの操作を任せるか」ではなく「どの操作を任せないか」です。planの読み解き、設定ファイルの探索、変更意図とリスクの整理は相性が良い一方、apply、state操作、credential閲覧、productionへの破壊的変更は明示的に人間承認へ寄せるべきです。
- Claude CodeはPR単位で起動し、対象ブランチの差分、Terraform plan、関連runbook、過去の障害メモを読み込ませる。
- 権限は公式のpermissionsに沿って、読み取り・validate・plan中心に限定する。
- レビュー観点は「削除」「公開範囲」「IAM」「ネットワーク」「データ保持」「コスト影響」「ロールバック可否」に固定する。
- 標準化の前提として、チーム共通の設定はsettingsのProject scopeやリポジトリ内ドキュメントで管理する。
- 最終判断は必ず人間のインフラ担当・SRE・サービスオーナーが行う。Claude Codeの出力はレビュー補助資料として扱う。
Claude Codeを全社導入する全体像は、別記事のClaude Code業務導入ガイドでも整理しています。本記事はその中でも、エンジニアが最初に標準化しやすい「インフラPRレビュー」に範囲を絞ります。
なぜTerraformレビューは属人化しやすいのか
Terraformのレビューは、単なるHCLの差分確認では終わりません。見た目は小さな変更でも、実際のplanではreplaceやdestroyが発生することがあります。moduleの入力値が変わると、呼び出し先のresource群まで影響が広がります。providerのバージョン差、workspace、backend、remote state、外部データソースもレビュー対象です。
HashiCorpの公式ドキュメントでは、terraform validateは設定の構文や内部整合性を検証するコマンド、terraform planは実行計画を作成し、Terraformがどの変更を行うかを確認するコマンドとして説明されています。つまりvalidateだけでは運用リスクは判断できず、planの読み解きとサービス文脈の理解が必要です。
エンジニア組織でよく起きる課題は、レビュー観点が人によって変わることです。ある人はIAMだけを見る。別の人はネットワークだけを見る。忙しい時は「CIが通ったからOK」に流れます。Claude Codeはこのばらつきを減らすためのチェックリスト実行役として使えます。毎回同じ観点で差分を見せ、リスクを箇条書きにし、確認できていない点を明示させることで、人間レビューの抜け漏れを下げる設計にできます。
ただし、Claude Codeの回答を自動承認の根拠にしてはいけません。IaCは実行結果がクラウド環境に直結します。レビュー補助は便利ですが、productionのapply権限、stateの書き換え、secretの閲覧は別レイヤーの統制が必要です。
対象シナリオと前提条件
ここで扱う想定シナリオは、SaaS企業や受託開発会社のインフラリポジトリです。GitHubでPull Requestを作り、CIでterraform fmt、validate、planを実行し、plan結果をPRに添付します。レビュー担当者はClaude Codeを使って、変更意図、plan、関連ドキュメント、障害対応runbookを読み合わせます。
- 対象はTerraformで管理されたAWS、Google Cloud、Azure、またはSaaS設定の変更。
- PR作成者は変更理由、対象環境、ロールバック方針をテンプレートに記入する。
- CIはterraform fmt、validate、planを実行し、plan結果をartifactまたはコメントで残す。
- Claude Codeはローカルまたは安全な開発環境で起動し、本番credentialを持たせない。
- レビュー担当者はClaude Codeの要約を読み、必要な追加確認を人間の判断で行う。
「本番credentialを持たせない」は特に大事です。Claude Codeにcloud providerの管理者権限を渡す設計にすると、レビュー補助ではなく変更実行エージェントになります。最初の導入では、planの生成自体はCIまたは人間の端末で行い、Claude Codeには生成済みplanと差分を読ませるだけでも十分です。
類似するCI/CD設計はCI/CDパイプライン自動構築の記事でも扱っています。今回の違いは、パイプライン自体を作る話ではなく、パイプラインが出したIaC変更情報をレビュー可能な形に整える点です。
5手順の導入フロー
導入は一気に自動化しない方が安全です。最初からPRコメント自動投稿や自動修正まで行うと、レビュー責任の所在が曖昧になります。おすすめは、読み取り専用のレビュー補助から始め、チームが出力品質を確認してから段階的に広げることです。
- レビュー観点をCLAUDE.mdまたはdocs/iac-review.mdに固定する。
- CIでplan結果を機械可読な形と人間可読な形の両方で保存する。
- Claude Codeに差分、plan、PRテンプレート、runbookを読ませ、リスク一覧を作る。
- レビュー担当者がClaude Codeの出力を確認し、PRコメントに転記・編集する。
- 十分に安定したらHooksやCI連携で要約生成だけを半自動化する。
この5手順は、技術的には地味です。しかし業務導入では「地味に同じ確認を毎回やる」ことが効きます。IaCレビューは派手なコード生成より、変更の文脈化、確認観点の固定、未確認事項の明示が価値になります。
最初の1か月は、Claude Codeのレビュー出力をそのまま承認に使わず、人間レビューのメモとして保存する運用が現実的です。どの観点が役立ったか、どの観点が過剰だったか、どのresourceで誤読が起きたかを記録し、CLAUDE.mdを改善します。
リポジトリ構成をClaude Code向けに整える
Claude Codeはコードベース全体を読めますが、読むべき情報が散らばっているとレビュー品質が安定しません。インフラリポジトリには、レビューに必要な文脈を置く場所を決めておきます。たとえば、環境一覧、moduleの責務、命名規則、禁止操作、申請が必要な変更、ロールバック手順をリポジトリ内に明文化します。
infra/
envs/
production/
staging/
modules/
docs/
iac-review.md
rollback-runbook.md
network-policy.md
.github/
pull_request_template.md
CLAUDE.mdCLAUDE.mdには、Claude Codeがレビュー時に守る前提を書きます。たとえば「applyは提案しない」「state操作は提案しても実行しない」「削除、置換、公開範囲変更、IAM権限拡大を最優先で確認する」「不明点はOKとせず未確認として列挙する」といったルールです。これはモデルへのお願いではなく、レビュー手順のドキュメント化でもあります。
Claude Codeの設定スコープは公式ドキュメントでManaged、User、Project、Localに分かれて説明されています。チーム全員で共有するレビュー前提はProject scopeやリポジトリ内ドキュメントに置き、個人の端末固有設定や検証用credentialはLocalに寄せるのが安全です。詳しい考え方はClaude Code settingsを確認してください。
この整理をしておくと、レビュー担当者が変わってもClaude Codeに同じ前提を渡せます。逆に、前提が口頭やSlackにしかない状態だと、Claude Codeは差分の表面だけを見てしまい、組織固有の禁止事項を拾えません。
レビュー用プロンプトの基本形
プロンプトは長くしすぎるより、毎回同じ形式で渡す方が運用に乗ります。以下のように、入力、確認観点、出力形式、禁止事項を分けます。特に出力形式を固定すると、PRコメントへ転記しやすくなります。
このPRのTerraform変更をレビューしてください。
入力:
- git diff: 現在のブランチ差分
- terraform plan: ci/plan-production.txt
- ルール: docs/iac-review.md
- ロールバック: docs/rollback-runbook.md
確認観点:
1. destroy / replace が発生していないか
2. IAM権限が広がっていないか
3. public access / security group / firewall が変わっていないか
4. database / storage / backup / encryption に影響がないか
5. 変更意図とplan結果が一致しているか
6. ロールバック手順が現実的か
出力:
- 要約
- 高リスク
- 中リスク
- 未確認事項
- レビュー担当者が実行すべき確認コマンド
禁止:
- terraform apply を実行しない
- credentialやsecretを表示しない
- 不明点を推測でOKにしないこのプロンプトで大事なのは、Claude Codeに「結論を急がせない」ことです。レビューでは、問題なしと言い切るより、未確認事項を正直に出す方が価値があります。たとえば「planに削除は見当たらないが、module内部のprovider差分は未確認」「backup retentionの変更意図がPR本文にない」といった形です。
また、レビュー結果には証拠を添えさせます。「どのファイルのどのresourceを見たか」「planのどの行でreplaceを確認したか」「どのrunbookにロールバック手順があるか」を短く書かせます。証拠がない指摘はPRコメントとして使いにくく、レビューの説得力も落ちます。
CIでplanを残す設計
Claude Codeレビューを安定させるには、CI側でplan結果を毎回同じ場所に残す必要があります。GitHub Actionsを使う場合、pull_requestイベントでterraform validateとplanを実行し、artifactやPRコメントとして保存します。GitHubの公式ドキュメントではpull_requestイベントがワークフローを起動するイベントとして説明されています。
name: terraform-review
on:
pull_request:
paths:
- "infra/**"
jobs:
plan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Terraform fmt
run: terraform fmt -check -recursive infra
- name: Terraform init
run: terraform -chdir=infra/envs/staging init -input=false
- name: Terraform validate
run: terraform -chdir=infra/envs/staging validate
- name: Terraform plan
run: terraform -chdir=infra/envs/staging plan -no-color -out=tfplan
- name: Export plan text
run: terraform -chdir=infra/envs/staging show -no-color tfplan > plan-staging.txt上の例は最小形です。実運用では、OIDC、backend、workspace、secrets、matrix、artifact保存、PRコメント投稿などをチームの環境に合わせて追加します。ここで大事なのは、Claude Codeが読むplanの形式を固定することです。毎回ファイル名や出力形式が変わると、レビュー手順がブレます。
planをJSONでも保存しておくと、削除や置換の検出をスクリプトで補助できます。一方で、JSONは人間には読みにくいので、Claude Codeに読ませる本文としてはテキスト版も残すのが現実的です。機械チェックとLLMレビューを競合させるのではなく、機械チェックで明確な違反を落とし、Claude Codeで文脈レビューを補助する設計にします。
Claude Codeに任せるレビュー観点
IaCレビューでClaude Codeに任せやすいのは、広い文脈を読んで観点ごとに整理する作業です。たとえば「PR本文ではstagingの変更と書いているが、production配下の変数も変わっている」「security groupのCIDRが広がっている」「database parameter groupの変更に再起動が必要か確認が必要」といった指摘です。
- 変更対象の環境、module、resource種別を一覧化する。
- destroy、replace、force replacement、public exposure、IAM privilege expansionの候補を拾う。
- PR本文の変更意図とplan結果の不一致を指摘する。
- runbookにロールバック手順があるか確認する。
- reviewerが追加で見るべきファイルやコマンドを提案する。
- PRコメントの草案を、強すぎない表現で作る。
逆に、Claude Codeの出力だけで判断しない方がよいものもあります。クラウドproviderの最新仕様、組織固有の例外ルール、プロダクトの停止許容時間、法務・監査上の判断、費用見積もりは、外部情報や人間の確認が必要です。Claude Codeには「確認が必要」と明示させるだけに留めます。
セキュリティ観点を深掘りする場合は、内部リンクのClaude Code法人導入セキュリティチェックリストも合わせて使えます。IaCレビューでは、ツール導入セキュリティとインフラ変更セキュリティの両方を分けて見ると抜け漏れが減ります。
権限設計と禁止コマンド
業務導入で最も重要なのは権限設計です。Claude Codeの公式ドキュメントでは、読み取り、Bashコマンド、ファイル変更などに対して許可・確認・拒否の考え方が整理されています。IaCレビューでは、読み取り、git diff、terraform fmt -check、terraform validate、terraform planのような確認系を中心にし、applyやstate変更は明示的に禁止します。
レビュー補助で許可する例:
- git diff
- git status
- terraform fmt -check
- terraform validate
- terraform plan -no-color
- terraform show -no-color tfplan
禁止または人間承認にする例:
- terraform apply
- terraform destroy
- terraform state rm / mv / push
- cloud provider CLIでの直接更新
- secretやcredentialの表示
- production backendへの書き込み「planなら安全」と考えるのも危険です。planを作るためにprovider credentialが必要な場合があります。remote data sourceやexternal data sourceがある場合、plan実行時に外部へアクセスすることもあります。最初はCIで生成済みのplanをClaude Codeに読ませる方式にして、Claude Codeの実行環境にはクラウドcredentialを置かない方が安全です。
権限はドキュメントだけでなく、実際の実行環境でも制限します。開発container、read-only token、sandbox、OIDCの権限分離、環境変数のマスキング、ログ保管方針を合わせて設計します。Claude Codeの出力にsecretが混ざらないよう、入力ファイル側でもsecretを含めない運用が必要です。
Hooksで半自動化する場合の注意
Claude CodeにはHooksがあり、SessionStart、PreToolUse、PostToolUseなどのライフサイクルイベントに合わせてコマンドやHTTPエンドポイントを実行できます。IaCレビューでも、セッション開始時にレビュー対象ファイルを案内したり、危険なコマンドを検知したり、レビュー完了時にログを保存したりできます。
ただし、Hooksを使うほど便利になる一方、運用の見通しは悪くなります。どのタイミングで何が実行されたかを追跡できないと、レビュー補助のはずがブラックボックスになります。最初は手動プロンプトで十分です。チーム内で出力品質が安定してから、読み取り系の補助、ログ保存、禁止コマンド検知の順に広げます。
Hooks設計の詳細はClaude Code Hooks完全ガイドでも扱っています。本記事の文脈では、Hooksは「自動レビューを完成させる仕組み」ではなく、「レビュー前後の定型処理を忘れないための補助」と考えるのが安全です。
- PreToolUseでterraform applyやdestroyを検知してブロックする。
- SessionStartでdocs/iac-review.mdとPRテンプレートを読むよう促す。
- PostToolUseでplan出力の保存先を確認する。
- SessionEndでレビュー要約をローカルログに残す。
PRコメントに載せる出力フォーマット
Claude Codeのレビュー結果は、PRコメントへそのまま貼れる形式に整えます。長すぎるコメントは読まれません。高リスク、中リスク、未確認、推奨確認コマンドの4ブロックに絞ると、レビュー担当者とPR作成者のやり取りが短くなります。
## Claude Code IaCレビュー補助メモ
### 要約
- stagingのALB listener ruleとECS task definitionを変更
- plan上はdestroyなし、task definitionの更新あり
### 高リスク
- なし。ただしproduction配下の変数変更は未確認
### 中リスク
- security groupのegressが広がっている可能性。意図をPR本文に追記推奨
- task CPU/memory変更によりデプロイ時の挙動確認が必要
### 未確認事項
- ロールバック手順がdocs/rollback-runbook.mdに未記載
- 変更後のアラート閾値が適切か未確認
### reviewer向け確認
- plan-staging.txtのaws_security_group差分を確認
- ECSサービスのデプロイ方式とロールバック手順を確認ポイントは「Claude Codeが承認した」と書かないことです。あくまで補助メモであり、最終承認者は人間です。また、PRコメントに機密情報やcredential、内部URL、顧客名が含まれないようにします。Claude Codeに渡す入力の時点でマスキングし、出力前にも人間が確認します。
PRコメントを半自動投稿する場合も、最初はdraft commentやartifact保存に留めるのがおすすめです。人間が確認してから投稿する方が、誤指摘や過剰な表現で開発体験を損ねるリスクを下げられます。
MCPや外部ツール連携を使う場合
MCPを使うと、Claude Codeからチケット、ドキュメント、監視、クラウド管理ツールへ接続しやすくなります。IaCレビューでは、JiraやLinearの変更要求、DatadogやGrafanaのアラート、Confluenceの運用手順、GitHubのPR情報を参照したい場面があります。
ただし、外部ツール連携は便利さとリスクが同時に増えます。最初からクラウド管理APIや監視APIへ広く接続せず、まずは読み取り専用のドキュメントやチケット参照に限定します。MCP自体の導入はClaude Code MCP実践ガイドを確認し、許可するツール、スコープ、監査ログを明確にしてから進めます。
特にIaCレビューでは、Claude Codeが「現在の本番状態」を直接見に行けると便利に見えます。しかし、それは同時に本番情報の取り扱い範囲が広がるということです。レビュー補助に必要なのは、まずPR差分とplanとrunbookです。外部接続は、運用が固まってから最小権限で追加します。
レビュー品質を測る指標
この記事では架空のベンチマーク数字を書きません。代わりに、チームごとに実測できる運用指標を置きます。Claude Code導入後に何が良くなったかを判断するには、導入前後で同じ基準のログを取る必要があります。
- PRレビューで見つかったIaCリスクの種類と件数。
- reviewerが後から差し戻した理由の分類。
- plan差分の読み落としがpost-mergeで発覚した件数。
- PRテンプレートの記入漏れ率。
- ロールバック手順の未記載件数。
- Claude Codeの指摘が有効だったか、過剰だったかのレビュー後評価。
ここで重要なのは、Claude Codeの正答率だけを追わないことです。レビュー品質は、人間、CI、ドキュメント、権限設計の合計で決まります。Claude Codeはその中の文脈整理役です。たとえば「ロールバック手順の未記載に気づけた」「PR本文とplanの不一致を早く見つけた」といった具体的な改善を記録します。
定量化するなら、自社のPRログから導入前後を比較します。ただし、記事や社内報告で数字を出す場合は、対象期間、対象リポジトリ、母数、除外条件を明記してください。数字だけが独り歩きすると、ツール効果を過大に見せる危険があります。
よくある失敗と対策
失敗パターンの多くは、Claude Codeの性能ではなく運用設計にあります。特に、権限を広げすぎる、プロンプトが毎回違う、planが保存されない、PR本文が空、レビュー観点が暗黙知、という状態では出力が安定しません。
失敗1：applyまで任せようとする
レビュー補助の段階でapplyまで任せると、事故時の責任分界が曖昧になります。最初はapply禁止、state操作禁止、credential非共有を原則にします。applyは既存のリリース手順と承認フローに残し、Claude Codeは確認メモの作成に限定します。
失敗2：PRテンプレートが空のまま
Claude Codeは差分を読めますが、変更意図までは自動で確定できません。PR本文に目的、対象環境、影響範囲、ロールバック方針がなければ、Claude Codeは推測するしかありません。推測を禁止し、未記載は未確認として出すルールにします。
失敗3：レビュー観点が多すぎる
最初から100項目のチェックリストを作ると、レビューが形骸化します。削除、公開範囲、IAM、データ保持、コスト、ロールバックのように、事故につながりやすい観点から始めます。チームで実際に役立った観点だけを残し、過剰な項目は削ります。
失敗4：Claude Codeの指摘をそのまま貼る
出力をそのまま貼ると、文体が強すぎたり、未確認なのに断定していたりする場合があります。PRコメントは人間が読みやすい表現に直します。「可能性があります」「確認してください」「PR本文に追記するとよさそうです」のように、協力的な表現に整えると導入摩擦が減ります。
導入チェックリスト
最後に、チームで導入前に確認するチェックリストを置きます。ここまで準備できていれば、Claude CodeをIaCレビュー補助として試す土台は整っています。
- PRテンプレートに変更目的、対象環境、影響範囲、ロールバック方針がある。
- terraform validateとplanがCIで毎回実行され、結果が保存される。
- Claude Codeに渡す入力からsecretやcredentialが除外されている。
- apply、destroy、state操作をClaude Codeに実行させないルールがある。
- CLAUDE.mdまたはdocs/iac-review.mdにレビュー観点が書かれている。
- 高リスク、中リスク、未確認事項、確認コマンドの出力形式が決まっている。
- レビュー担当者が最終判断を行う運用になっている。
- 導入後の改善記録を残す場所がある。
このチェックリストを満たせない場合でも、Claude Codeを試すこと自体はできます。ただし、業務導入としては準備不足です。まずは1リポジトリ、1環境、読み取り専用、PRコメント手動転記から始めるのが現実的です。
まとめ：Claude CodeはIaCレビューの型を作る道具
TerraformのIaCレビューは、差分を読むだけでなく、plan、環境、権限、ロールバック、運用ルールを横断する仕事です。Claude Codeは、その横断確認を毎回同じ型で実行する補助として使えます。
導入のポイントは、読み取り専用から始めること、レビュー観点をリポジトリに明文化すること、planをCIで保存すること、危険な操作を禁止すること、最終判断を人間に残すことです。この設計なら、Claude Codeを「便利な自動化」ではなく「レビュー品質を安定させる仕組み」として導入できます。
もしチーム全体の導入設計から整理したい場合は、Claude Code業務導入ガイドとセキュリティチェックリストを先に確認してください。IaCレビューは、Claude Code導入の中でも成果が見えやすい一方、権限設計を誤ると危険になりやすい領域です。小さく始めて、レビューの型を育てるのが近道です。
よくある質問
Claude Codeにterraform applyを実行させてもよいですか？
初期導入では推奨しません。apply、destroy、state操作は既存の承認フローに残し、Claude Codeはplanや差分のレビュー補助に限定する方が安全です。
plan結果だけを読ませれば十分ですか？
plan結果は重要ですが、それだけでは変更意図やロールバック方針は分かりません。PR本文、runbook、docs/iac-review.md、関連moduleのREADMEも合わせて読ませるとレビューが安定します。
CIで自動コメントまで行うべきですか？
最初は人間が確認してから転記する運用をおすすめします。出力品質が安定し、機密情報が混ざらないことを確認してから、draft commentやartifact保存などの半自動化へ進めます。
Terraform以外のIaCにも使えますか？
考え方はCloudFormation、Pulumi、Kubernetes manifest、Helm chartにも応用できます。ただし、それぞれplan相当の出力や差分確認の方法が違うため、レビュー観点と禁止操作は別途定義してください。
Claude Code導入相談
Claude Codeをインフラレビュー、CI/CD、セキュリティチェック、開発ワークフローに組み込みたい場合は、まず対象リポジトリ、権限、CI、レビュー観点を棚卸しするところから始めるのがおすすめです。お問い合わせから、現在の開発体制と導入したい業務を共有してください。小さく安全に始める設計から整理します。
