はじめに

皆様こんにちは、あかいけです。

先日、「Claude Codeセミナー インフラ構築編｜最新機能の検証とインフラ構築をAIで加速させる」にて、
「Terraformを安全に効率よく書くためのClaude Code活用術」というタイトルで登壇しました。

https://classmethod.jp/seminar/260512-claude-code-webinar/

IaC（Terraform）とAI（Claude Code）を組み合わせた実践的な活用術として、「効率よく書く方法」と「安全に書く方法」の2軸でお話ししました。

登壇資料

コメント

「AI（Claude Code）に直接インフラを触らせるのは 冪等性が保てない = ほぼガチャ なので、IaC（Terraform）を介することで安全かつ再現性のあるAI活用ができる」、というのが本セッションの主旨です。
具体的には以下のような内容をお話しました。

• CLAUDE.mdによるコンテキスト管理
  • プロジェクト固有のルールを事前に持たせる
  • ただし多くても200行程度に抑えて、詳細ルールは.claude/rules/に切り出す
• MCPの活用
  • terraform-mcp-serverとAWS MCP Serverで正確なドキュメントを参照させ、ハルシネーションを抑える
• Skillsでプロンプトをテンプレート化
  • コードレビューやセキュリティレビューなど定常プロンプトはチームでSkillsとして共有する
  • それ以外でも日常的に行う定常作業はまずはSkillsにしてみる
• HooksでToolを確実に実行
  • terraform fmt / terraform validateなどの定期的に実行するツールはHooksに仕込んで漏れなく実行させる
• IAM権限はReadOnly基本
  • AIに渡す認証情報は専用プロファイルでReadOnlyに絞る
• PermissionsとSandboxで権限制御
  • Claudeがツールで何をできるか（Permissions）と、呼び出されたBashプロセスが何にアクセスできるか（Sandbox）を組み合わせて制御する

本セッションはClaude Codeの機能をベースにTerraformへの適用例を紹介する内容のため、基本的な使い方が中心となっています。
AIとIaCの組み合わせに取り組む最初の一歩として参考にしていただければ幸いです。

質疑応答

たくさんのご質問をありがとうございました！
セミナー中に回答しきれなかったご質問の回答をまとめます。

---

Q. AWSのみで考えるとCFnの方が細かな指定を出来るイメージなのですが、クラウド基盤はAWSしか利用予定がない場合でもTerraformの方がお勧めでしょうか？

CloudFormationには明確に優位性がある領域があります。
特にAWS Organizationsと組み合わせたStackSetsはその代表例で、複数アカウント・複数リージョンへの一括デプロイが宣言的に行えます。
新規アカウント立ち上げ時のベースライン設定はCloudFormationとStackSetsの組み合わせが最も自然です。

一方、持続的に更新が発生するインフラであればTerraformをおすすめします。
最大の理由はstateファイルによる管理です。Terraformは「今何がデプロイされているか」をstateで把握しているため、差分の検出・部分的な更新・リソースのリファクタリングがやりやすくなっています。

まとめると「アカウント立ち上げや組織管理はCloudFormation（StackSets）、継続的に育てていくアプリケーション基盤はTerraform」というように使い分けるのが現実的かなと思います。
あくまで私の観測範囲ではありますが、実際に用途に応じて共存させているユースケースも多くあります。

---

Q. AWS で Terraform を使う場合と比べて、OpenTofu のメリット・デメリットはどのようになるか、お教えいただけますと幸いです。

まずOpenTofuはTerraformのBSLライセンス変更を受けてLinux Foundation傘下でforkされたOSSです。
（知らない方も多い方と思うので念の為…）
主なメリットデメリットとしては以下が考えられます。

• OpenTofu のメリット

  • MPL 2.0 ライセンスによる制限なしの商用利用
    • OSI 認定のオープンソースライセンスであり、BSL のような「競合製品への組み込み禁止」条項がない
    • Terraform と機能が重なる SaaS プロダクトへの組み込みや再配布も、ライセンス上の制約なく行える
  • OpenTofu 独自機能による先進性
    • ネイティブ State 暗号化（v1.7〜）: Backend側の機能（S3バケットの暗号化など）に依存せず State ファイルを暗号化でき、機密情報の漏洩リスクを低減
    • 変数・ローカルの早期評価（v1.8〜）: バックエンドやモジュールソースの設定を変数で動的に記述可能になり、Terragrunt などのラッパーツールへの依存を減らせる
    • Terraform リポジトリで長年放置されていた機能リクエストを積極的に取り込んでいる

• OpenTofuのデメリット

  • 公式マネージドサービスが存在しない
    • Terraform Cloud / HCP Terraform に相当する公式 SaaS はなく、リモート State 管理・リモート実行環境・ポリシー管理（Sentinel 相当）・監査ログの一元管理には Spacelift / env0 などサードパーティツールを利用するか自前構築が必要
  • コミュニティドリブンゆえの追随コスト
    • HashiCorp（IBM）の専任開発リソースと比べると、新プロバイダー対応や新機能の取り込みにラグが生じる場合がある

ただ正直なところ、どちらを選んでも基本的な使い勝手はほぼ変わりません。
個人的な所感ではありますが、判断の分かれ目は以下かなと思います。
（明確にOpenTofuを利用したい理由がなければ、Terraformでいいかなと思います）

• OpenTofu を選ぶ場合

  • BSL によるライセンスリスクを避けたい（競合 SaaS への組み込みや法務上の懸念がある）
  • ネイティブ State 暗号化をシンプルに導入したい
  • オープンソース継続性・ベンダーロックイン回避を重視する

• Terraform を選ぶ場合

  • Terraform Cloud / HCP Terraform・Sentinel をすでに活用している
  • HashiCorp エンタープライズエコシステム（Vault・Consul 連携など）に深く依存している

---

Q. IaC実装時のインプットとなるファイルはどのようなものを準備するのでしょうか？コード＝設計書とするのであればspecにはパラメータのように設定値と設定項目(1:1)などは記載しない認識であっていますか？

認識は合っています。
また前提として、IaCはパラメータシートそのものを置き換えるものと考えると良いかと思います。

例えば従来の「設計書 → パラメータシート → 構築」という流れでIaCを導入しても、コードとパラメータシートの二重管理になってしまい、少しずつ乖離していきます。
IaC中心のワークフローでは構成値はコードに集約されており、それ自体がパラメータシートとして扱えます。
なのでspecや設計書に書くのは「なぜこの構成にするのか」という意図・制約・判断の根拠であり、設定値の1:1列挙は必要ないと思います。

もし既存のパラメータシートがある場合はインプットとして活用できますが、
変換後は パラメータシートの更新をやめ、Terraformコードだけを正として管理する のが良いと思います。

---

Q. 自宅でClaudeCodeを活用してみる際に、初心者におすすめの事例はどういったものでしょうか？

ご質問いただいた「自宅」とは「業務ではなくプライベートで使ってみる」という前提でお答えします。
（認識間違っていたらすみません…）

シンプルに「自分が作ってみたいもの」に使ってみるのがいちばんです。
ポートフォリオサイト・個人アプリ・日常作業を自動化するスクリプトなど、失敗しても困らない題材であれば何でも構いません。
また自分が実際に使うものだと出力の良し悪しが体感しやすく、プロンプトの書き方も自然と身についていきます。

完璧な成果物を最初から目指すより、「動いた」という体験を積み重ねる方が長続きすると思うので、思いついたらすぐ実装してみるのがいいと思います。

---

Q. MCPツールの利用は構築エージェントに利用させますか？

はい、積極的に活用しています。
また構築エージェントに限らず、技術的な調査・実装全般でMCPサーバーを使うのが良いかと思います。

AWSのサービス仕様やTerraformのリソース定義は頻繁に更新されるため、WebFetchやモデルの学習時点の知識だけに頼るとどうしてもハルシネーションが発生します。そのためMCPで正確なドキュメントを参照させることで、存在しない属性の使用や廃止APIの参照を大幅に減らせます。

そのためコードレビュー・セキュリティ調査・エラー調査など、技術的な判断が伴う場面ではMCPをセットで使うことをおすすめします。

---

Q. claudecodeはmcp利用指示記載のhooksをhigh think opus 4.7 1mで無視することが多いのですが対策はこうじていますか？また、レビューはcodexとのクロスAIレビューを実施していまか？

まず整理として、settings.jsonのhooks（PreToolUse/PostToolUse）はシェルコマンドを実行する仕組みであり、基本的にはモデルへの行動指示を書く場所ではありません。
「MCPを使うこと」のような指示はhooksに書いてもモデルは読まないため、その指示はプロンプトやCLAUDE.mdやRulesに書く必要があります。
もしご質問通り、「hooksに書いたMCP利用指示が無視される」という状況であれば、書く場所が違っている可能性が高いです。

その上でCLAUDE.mdに書いたMCP利用指示が無視されるケースは、コンテキストが長くなるほど冒頭の指示が埋もれて無視されやすくなるという一般的なLLMの挙動（いわゆる「Lost in the Middle」問題）が主な原因として考えられます。high-think modeではthinkingのトークンも積み重なるため、コンテキスト消費が特に激しく、この問題が起きやすいと思われます。

対処としては以下が考えられます。

• セッションが長くなってきたら/compactでコンテキストを圧縮する
• permissionsでWebFetchを制限し、MCPを使わざるを得ない環境にする
• CLAUDE.mdの指示を「必ずMCPを使用すること」と命令形で具体的に記載する
• extended thinkingは必要な場面に限定し、常時ONにしない

Codexとのクロスレビューは私は現状やっておらず、Claude Code内でのセルフレビュー（差分と関連コードを渡して自身にレビューさせる）を主に活用しています。ただしクロスAIレビュー自体は有効な手法であり、社内でも取り組んでいるメンバーもおり、選択肢としてはありだと思います。

---

Q. チーム内でのskillsの共有の仕方についてどのような形で共有されていますか？github等？それともsharepointなどでしょうか。今のチームはインフラ、アプリ関連のメンバーが入り混じっているので、skillsの共有の仕方に迷っています、、

「誰が使うのか」によって最適な方法が変わるため、まずそこを整理するのがポイントです。
以下はあくまで一例ですが、利用者の範囲に応じて共有方法を検討されるのが良いかと思います。

• エンジニアのみ
  • GitHubリポジトリでコードと一緒に管理するのがシンプルでおすすめです、PRレビューをそのままSkillsの品質管理に使えます
  • SkillsはPluginsという仕組みでパッケージとして配布することも可能で、汎用的なSkillsを組織内で横展開したい場合に有効です
• 非エンジニアも含む全社利用
  • Skillsファイル自体はGitHubで管理しつつ、使い方ガイドはSharePointやConfluenceなどドキュメントとして置く構成が現実的かなと思います

---

Q. 実際のサービスで使用されるプロンプトの品質について、どのように評価・改善し続けていたりされていますでしょうか？評価の自動化などもされているのでしょうか？もし一例があればご教示いただけると幸いです。ハルシネーションのお話が一部ありましたが、実務的な対策はどんなことをされていますでしょうか？

プロンプト（Skillsなど含め）の改善は「失敗を即座にフィードバックとして取り込む」サイクルが最も効果的かと思います。

具体的に実践していることの一つは、Skillsがうまく機能しなかったセッションの終了前にAI自身に振り返りをさせることです。
「今のセッションでどの指示が曖昧だったか、どの部分が意図通りに動かなかったか、Skillsをどう改善すればよいか」など問いかけ、その回答をSkillsへ反映させます。
ユーザーがゼロから改善点を考えるより精度が高く、Skillsの陳腐化を防ぐのに効果的です。

前述のQAとも内容がかぶってしまいますが、ハルシネーション対策として最も効果的なのはMCPの活用です。
WebFetchに頼らずMCPで正確なドキュメントを参照させることで、存在しない属性や廃止APIの定義を大幅に減らせます。
加えてHooksでのツール自動実行と、Claude Codeへの自己レビュー（Skillsなど）の組み合わせで、実用上問題ないレベルに抑えられています。（それでも細かい修正が発生することも多いですが…）

さいごに

以上、Terraformを安全に効率よく書くためのClaude Code活用術の紹介でした。
正直なところ今回のセッションはかなり広めにざっくりお話しした内容のため、「実際にどこから始めればよいか」「自分たちの環境にどう適用するか」という部分まで踏み込めませんでした…。

そんな方に向けて、AI駆動インフラ開発支援サービス（仮） を2026年6月頃から提供予定です。
「生成AIを活用したインフラ開発のノウハウが社内に蓄積されていない」「IaC × AIの開発フローを整備したい」「ハンズオンで実践的に学びたい」といったニーズをお持ちの方や組織に向けて、
勉強会・ハンズオン・ガイドライン整備・テンプレートリポジトリ作成など幅広くご支援できればと思っています。

もっと深い話を聞きたい・実際に支援してほしいという方は、お気軽にご連絡ください。