IaCの「コピペ地獄」を終わらせる：AI駆動型リファクタリングによる技術的負債の安全な解消法

導入

「とりあえず動いているから、触りたくない」。

製造現場の設備保全でも、ITインフラの運用でも、この言葉は最も危険なサインです。特にInfrastructure as Code（IaC）の運用が数年続くと、当初は整然としていたTerraformやAnsibleのコードベースが、度重なるコピー＆ペーストによって見るも無残な「スパゲッティコード」に変貌していることは珍しくありません。

ITコンサルタント（AI導入・データ活用支援）として製造現場のデータ活用や予知保全を支援する中で見えてくるのは、ITインフラのコード管理も、物理的な設備のメンテナンスと全く同じ原理が働いているという事実です。重複したコードは、言わば「同じ部品なのに規格が微妙に違うネジ」が乱立している状態です。一つを修正しても、別の場所にある同じような処理が修正漏れとなり、ある日突然、本番環境で障害を引き起こす――これが「コピペ地獄」の正体であり、技術的負債の典型的な姿です。

多くのエンジニアがリファクタリングの必要性を痛感しながらも、二の足を踏むのはなぜでしょうか。それは「動いている環境を壊すリスク」への恐怖と、「膨大なコードを読み解く工数」が確保できないからです。

ここで、AI（生成AI）が強力な味方となります。AIを単なる「コード生成ツール」として使うのではなく、「構造分析とリファクタリングのパートナー」として活用することで、リスクを可視化し、安全かつ効率的に重複を排除することが可能になります。

本記事では、AIを活用してTerraformやAnsibleの重複コードを「安全に」「効率的に」共通化し、技術的負債を解消するための具体的プロセスを、現場の実証データに基づいて解説します。魔法のような一発逆転の方法はありませんが、着実に成果が出る「カイゼン」の手法を持ち帰っていただけるはずです。

IaCにおける「重複」の正体とAIがもたらすパラダイムシフト

なぜIaCにおいて重複がこれほどまでに致命的な問題となるのでしょうか。まずは敵を知ることから始めましょう。従来のテキスト検索（grep）や静的解析ツールでは見落としがちな「意味的な重複」こそが、運用コストを肥大化させる真犯人です。

DRY原則の誤解と「悪い重複」の定義

ソフトウェア開発においてDRY（Don't Repeat Yourself）原則は有名ですが、インフラコードにおいては少し事情が異なります。単に「同じ文字列がある」ことが悪いのではありません。問題なのは「変更理由が同じであるにもかかわらず、分散して管理されているコード」です。

例えば、複数の環境（Dev/Stg/Prod）で似たようなセキュリティグループの設定が書かれているとします。これは一見すると重複ですが、環境ごとに異なるライフサイクルを持つべき設定であれば、あえて分離しておく方が安全な場合もあります（偶発的重複）。

一方で、本来は全環境で統一すべき「社内セキュリティポリシー」や「ログ転送設定」が、個別のリソース定義の中にハードコードされ、散らばっている状態。これこそが排除すべき「構造的重複」であり、悪い重複です。これを放置すると、ポリシー変更時に数十箇所の修正が必要となり、必ず「修正漏れ」というヒューマンエラーを誘発します。

技術的負債の定量化：重複コードが保守コストに与えるインパクト

一般的な製造業の現場において、Terraformのコード行数が2万行を超え、分析の結果その約40%が実質的な重複コードとなっているケースがあります。この状態が運用チームに与える負荷をデータドリブンに試算すると、以下のような定量的な影響が確認されています。

• 変更リードタイムの増大: 単純な設定変更に、通常の3倍の時間がかかる（影響範囲の調査時間を含む）。
• 学習コストの高騰: 新任エンジニアがコードの全容を把握するのに3ヶ月以上を要する。
• 障害リスク: 設定変更時のミスによる障害発生率が、リファクタリング済みのプロジェクトと比較して約5倍。

重複コードは、単にディスク容量を食うだけのゴミではありません。エンジニアの時間を奪い、精神を摩耗させる「負の資産」なのです。

AIは「構造的類似性」をどう検知するか

ここでAI、特にLLM（大規模言語モデル）の出番です。従来のLintツールは構文エラーやスタイル違反は見つけられますが、「この5つのファイルにある設定は、意図として同じことをやろうとしている」という文脈までは理解できません。

AIはコードをベクトル（数値の並び）として捉え、意味的な近さを判定します。変数名が違っていても、リソースの構成パターンや依存関係が似ていれば、「これらは同じロジックの変種である」と見抜くことができます。

例えば、「Webサーバーの構築」というタスクにおいて、Aチームは aws_instance リソースを直接書き、Bチームは独自のモジュールを使っていたとします。AIにコードベース全体を読み込ませることで、「AチームのコードはBチームのモジュールに置換可能である」という提案を引き出すことができるのです。これは、人間が目視で行うにはあまりにも骨の折れる作業ですが、AIにとっては得意領域です。

【実証】AIを活用したTerraform/Ansibleリファクタリングの3段階プロセス

AIを活用したリファクタリングを具体的にどのように進めるべきか。インフラストラクチャの技術的負債を安全に解消するための「3段階プロセス」を解説します。いきなり全てのコードをAIに書き換えさせようとせず、小さく始めて成果を可視化し、段階的にスケールアップして着実に進めることが成功の鍵となります。

フェーズ1：AIによる重複パターンのクラスタリングと可視化

最初に行うべきは「現状把握」です。コードの直接的な修正を急ぐのではなく、まずはAIにコードベース全体を俯瞰させ、「どこに構造的な重複が存在するか」を分析させます。

実践ステップ:

1. リポジトリ内の主要な .tf ファイルや playbook.yml をコンテキストとしてAIに読み込ませます。
2. 重要なポイント: コードの構造解析のような複雑なタスクでは、推論能力と長文処理に優れたAIモデルの選択が重要です。例えば、Claudeの最新環境では100万トークン規模のコンテキストウィンドウや、長大な文脈を自動で要約・圧縮するCompaction機能が提供されています。これにより、大量のインフラ定義ファイルを一度に読み込ませても、文脈を見失うことなく精度の高い重複分析が可能です。
3. 以下のプロンプトを使用して、重複箇所をリストアップさせます。

プロンプト例:
「現在のディレクトリ以下のTerraformコードを分析し、構造的に類似しているリソース定義を特定してください。特に、aws_security_group と aws_s3_bucket の定義において、パラメータが80%以上一致している箇所をリストアップし、それらを共通モジュール化した場合の削減効果（行数）を推定してください。」

このフェーズの分析結果から、「数年前のプロジェクトのコードがそのままコピーされて使われていた」といった技術的負債が明らかになるケースは決して珍しくありません。AIは人間的なバイアスを持たないため、客観的かつ網羅的に重複箇所を指摘します。

フェーズ2：AI生成によるモジュール/ロールの抽象化設計

重複箇所が特定できたら、次は「共通部品（モジュール/ロール）」の設計に移ります。ここで最優先すべきは、ハードコードされた値から変数を抽出（Abstraction）し、再利用性を高めることです。

AIコーディングアシスタントには自律的にコードを修正する機能も搭載されつつありますが、インフラのモジュール設計のような高度なアーキテクチャ判断が求められる場面では、チャットインターフェースを通じて対話的に要件を定義するアプローチが確実です。さらに、Claudeなどに搭載されている「Adaptive Thinking（タスクの複雑度に応じてAIが思考の深さを自動調整する機能）」を活用することで、より堅牢でスケーラブルな設計案を引き出すことができます。

AIにリファクタリング案を作成させる際は、具体的な制約条件を明確に提示することが重要です。

プロンプト例（Terraform）:
「特定された3つのセキュリティグループ定義を統合する terraform module を作成してください。
条件：

1. ingress ルールは動的に設定できるよう dynamic ブロックを使用すること。
2. vpc_id と name_prefix は必須変数とすること。
3. 既存のコードが使用しているデフォルト値は維持すること。
4. メンテナンス性を考慮し、現行のTerraform推奨構文を使用すること。」

AIが生成したコードは、人間がゼロから記述するよりも圧倒的に速く、基本的な構文エラーも排除されます。以下は、AIが提案するモジュール化の一例です。

# AI生成: modules/security_group/main.tf
variable "ingress_rules" {
  type = list(object({
    from_port   = number
    to_port     = number
    protocol    = string
    cidr_blocks = list(string)
  }))
}

resource "aws_security_group" "this" {
  # ... (省略)
  
  dynamic "ingress" {
    for_each = var.ingress_rules
    content {
      from_port   = ingress.value.from_port
      to_port     = ingress.value.to_port
      protocol    = ingress.value.protocol
      cidr_blocks = ingress.value.cidr_blocks
    }
  }
}

Ansibleの場合も同様の手法で、巨大化した tasks/main.yml を複数の roles に分割する提案をAIに行わせます。特に defaults/main.yml の設計はAIが得意とする領域であり、環境依存の値を適切に変数の外出しへと誘導してくれます。

フェーズ3：影響範囲を最小化する段階的置換フロー

ここが実運用において最も重要なポイントです。優れたモジュールを作成しても、既存のリソースを安易に削除して再作成してしまっては、本番環境で致命的なダウンタイムが発生します（Terraformにおける Destroy から Create の挙動）。

Terraformの場合、moved ブロックを活用することで、クラウドリソース自体を削除することなく、Stateファイル内の論理的な紐付けだけを新しいモジュール側に安全に移行できます。AIには、この moved ブロックの生成まで一貫して依頼します。

プロンプト例:
「既存の aws_security_group.web リソースを、新しく作成した module.web_sg 内の aws_security_group.this に移動させるための moved ブロックを生成してください。」

# AI生成: refactoring.tf
moved {
  from = aws_security_group.web
  to   = module.web_sg.aws_security_group.this
}

このように、AIを活用して「リファクタリングを安全に実行するためのコード」まで生成させることで、手作業によるState操作のミスを根本から防ぎます。Ansibleの場合であれば、--check モードで実行したDry Runの長大なログ結果をそのままAIに解析させ、意図しない設定変更や予期せぬ副作用が含まれていないかを検証させると、より安全な移行が実現します。

AI提案モジュールの品質評価と「過剰な抽象化」の回避

AIは非常に優秀ですが、時に「張り切りすぎる」ことがあります。AIに任せきりにすると発生するのが「過剰な抽象化（Over-Abstraction）」です。

AIが陥りやすい「神モジュール」の罠

「あらゆるユースケースに対応できる最強のモジュールを作りました！」とAIが提案してくることがあります。変数が50個もあり、内部で複雑な条件分岐（count や for_each のネスト）が繰り返されているようなモジュールです。

これを「神モジュール（God Module）」と呼び、現場では徹底的に排除します。なぜなら、誰もそのモジュールの全挙動を理解できなくなり、メンテナンス不能になるからです。AIは論理的な整合性があれば複雑さを厭いませんが、人間には認知負荷の限界があります。

可読性と再利用性のトレードオフを判定するチェックリスト

AIが生成したモジュールを採用するかどうか、以下の基準でレビューしてください。

1. 変数の数は適切か？: 1つのモジュールに対する入力変数は、最大でも10〜15個程度に収まっているか。それ以上必要なら、モジュールの責務が大きすぎる可能性があります。
2. 条件分岐の深さ: ternary operator（三項演算子）が3重以上にネストしていないか。AIは平気で複雑なワンライナーを書きますが、可読性は最悪です。
3. デフォルト値の安全性: AIは利便性を優先して、セキュリティ的に緩いデフォルト値（例: 0.0.0.0/0）を設定することがあります。必ずチェックし、安全側に倒してください。

AI生成コードのテスト自動化とバリデーション

モジュールの品質を担保するために、テストコードもAIに書かせましょう。Terraformなら terraform test（v1.6以降）、Ansibleなら molecule のテストケース生成です。

プロンプト例:
「作成したTerraformモジュールのバリデーションテストを書いてください。特に、ingress_rules に 0.0.0.0/0 が含まれていた場合にエラーを出す validation ブロックを追加してください。」

このように、守るべきルールをAIに明示し、それをコードとして実装させることで、品質のガードレールを構築します。

ケーススタディ：保守工数40%削減を実現したIaC改善事例

グローバル50拠点に向けてIoTプラットフォームを展開している製造業の事例を基に、定量的な改善効果を見ていきましょう。このケースでは、IaCの運用が限界を迎えていました。

Before：50環境のコピペ管理による設定漏れ多発

• 状況: 拠点ごとにフォルダをコピーしてTerraformを管理。コード総数は5万行以上。
• 課題: 「全拠点のFW設定を変更せよ」という指示が出た際、50箇所のファイルを修正するのに丸3日かかっていた。しかも、毎回2〜3拠点で設定漏れやミスが発生。
• 心理的負荷: 担当者は「変更作業が怖い」と漏らし、必要なセキュリティパッチの適用すら躊躇する状態。

Transition：AI主導のリファクタリング実施タイムライン

段階的にスケールアップするアプローチを取り、3ヶ月かけてAIを活用したリファクタリングを実施する標準的なタイムラインは以下の通りです。

1. 1ヶ月目（分析）: AIツールを用いて全拠点のコードをスキャンし、共通部分を90%特定。拠点ごとの差異（IPアドレス、インスタンスサイズなど）を変数として抽出。
2. 2ヶ月目（モジュール化）: AIペアプログラミングにより、主要リソース（VPC, EC2, RDS）をモジュール化。この際、moved ブロックを大量に生成し、State移行のテストを徹底。
3. 3ヶ月目（適用）: 拠点ごとに順次モジュールへの切り替えを実施。AIが生成したプルリクエストの解説文が、レビュアーの負担を大幅に軽減しました。

After：プロビジョニング時間の短縮と変更リードタイムの改善

結果として、以下の成果が得られました。

• コード行数: 5万行 → 1.2万行（76%削減）
• 変更リードタイム: 3日 → 4時間（保守工数約40%削減 ※検証時間含む）
• エラー率: 移行後の設定変更ミスはゼロを記録。

特筆すべきは、エンジニアチームの意識変化です。「コピペで凌ぐ」文化から、「共通モジュールを育てる」文化へとシフトしました。AIが面倒な作業（変数の抽出やドキュメント生成）を肩代わりしてくれたおかげで、彼らはアーキテクチャの改善に集中できるようになったのです。

継続的な「きれいなコード」を維持するためのAI運用ルール

一度リファクタリングして終わりではありません。放っておけば、コードは再び腐敗します（エントロピー増大の法則です）。きれいな状態を維持するための仕組みにもAIを組み込みましょう。

CIパイプラインへのAIレビュー組み込み

プルリクエスト（PR）が出された時点で、AIによる自動レビューを走らせる仕組みを導入します。例えば、GitHub Actionsで以下のようなチェックを行います。

• 重複検知: 新規コードが既存のモジュールと類似していないかチェック。
• 命名規則チェック: AIに「この変数名はプロジェクトの規約に沿っているか」を判定させる。
• 解説生成: 変更内容の要約をAIに書かせ、人間のレビュアーが素早く理解できるようにする。

新規コード作成時のAIペアプログラミングガイドライン

「新しくコードを書くときは、まずAIに相談する」というルールを設けるのも有効です。ただし、丸投げは禁止です。「どのようなモジュール設計にすべきか」をAIと壁打ちすることで、初期段階から設計品質を高めることができます。

技術的負債を溜めないための定期的なAI診断

人間ドックと同じように、四半期に一度は「AIコード診断」を実施することをお勧めします。日々の開発では見落としがちな、「全体最適」の視点での改善点をAIに洗い出してもらうのです。

まとめ

IaCの重複コードは、製造現場における「整理整頓されていない工具箱」と同じです。必要な時に必要なものが見つからず、作業効率を落とし、最悪の場合は事故につながります。

AIはこの散らかった工具箱を整理し、使いやすいセット（モジュール）にまとめ直してくれる強力なパートナーです。しかし、最終的にどの工具をどう使うかを決めるのは、エンジニアである皆さん自身です。

本記事のポイント:

• 重複は「構造的」に捉え、AIのパターン認識力を活用して検出する。
• リファクタリングは「分析→抽象化→段階的置換」の3ステップで進める。
• AIの「過剰な抽象化」を警戒し、人間が可読性と安全性の門番になる。
• moved ブロック等の機能を使い、既存環境を壊さずに移行する。

まずは、手元の小さなモジュール一つから、AIとのペアプログラミングを試してみてください。その小さな一歩が、将来の巨大な技術的負債を防ぐ防波堤となるはずです。

もし、より具体的な導入事例や、自社の環境に近い構成でのリファクタリング実績を確認したい場合は、専門家に相談することをおすすめします。他プロジェクトの苦労と成功の軌跡を知ることは、最短距離で成果を出すための最良の近道です。