https://tech.itandi.co.jp/entry/2026/04/08/153253

はじめに

こんにちは、イタンジ株式会社インフラチームの清水です。

イタンジには 20 個を超える AWS アカウントがあり、10 チーム以上の開発チームがイタンジのプロダクト開発を行っています。インフラチームは、開発チームと一緒にプロダクトのインフラに関わる設計・運用・障害対応を実施しており、チームは3名で構成されています。

インフラチームでは、各プロダクトのインフラの設計・運用・招待対応の他に、プロダクト全体のインフラに関わる標準化を進めており、デプロイの標準化、監視の標準化、CI・CDの標準化、開発に関わるメトリクス分析の標準化などを行っています。

標準化することで、少し柔軟性は低下するかもしれませんが、インフラの品質を一定以上に保ち、より少ない工数でより広範囲のインフラを管理できることを目指しています。

今回は、元々別会社のプロダクトだったプロポクラウドのTerraformコードを、イタンジの標準的なTerraformのコード構成に移設した話をお伝えします。

背景：なぜ移行が必要だったか

プロポクラウドは、イタンジがM&Aにより買収した株式会社ハウスマートのプロダクトです。元々別チームで開発・運用されていたため、Terraformの構成もイタンジの標準とは異なる独自の設計で管理されていました。

独自構成を維持し続けることには以下のような課題がありました。

運用工数の増加: イタンジの標準構成とは異なるため、構成の把握や操作に追加の運用工数がかかる
属人化: 独自構成を把握しているメンバーが限られ、対応できる人が絞られる
ツール利用の制限: イタンジでTerraform管理に利用しているツールやワークフローをそのまま適用できない

現在、イタンジのインフラチームは3名体制です。3名でもイタンジの多数のプロダクトのインフラを運用できているのは、インフラ構成の標準化を実施していることなどが理由としてあると思います。より少ない工数でより多くのインフラを効率的に管理するために、プロポクラウドの構成もイタンジの標準構成に合わせることにしました。

イタンジのTerraformディレクトリの標準構成とは

イタンジではitandi-infraリポジトリでTerraformコードを管理しており、AWSアカウント内で共通して利用する設定と、プロダクトごとの設定でディレクトリを分けています。

ここでいう「プロダクト」に厳密な定義はありませんが、イタンジではサービスの機能単位（物件管理、入居者管理など）の大きさでTerraformコードのディレクトリを分けて、プロダクトとして管理しています。

イタンジの標準的なディレクトリ構成

プロダクトのディレクトリの中に、アプリ・デプロイ・モニタリングなど、そのプロダクトの構成に必要な設定がまとめて入っています。

aws account -- common settings
            |
            |- products -- product A
                        |
                        |- product B
                        |
                        |- product C

プロポクラウドのディレクトリ構成

一方、プロポクラウドのTerraform構成は、アプリケーション・デプロイ・モニタリングなどの単位でディレクトリを分け、その中に全プロダクトのリソースが入っている構成であり、プロダクト単位での切り分けはされていませんでした。

aws account -- common settings
            |
            |- application --- common settings
            |               |
            |               |- staging
            |               |
            |               |- production
            |
            |--- deploy ------ common settings
            |               |
            |               |- staging
            |               |
            |               |- production
            |
            |--- monitoring -- common settings
            |               |
            |               |- production
            |
            |--- operation --- common settings
            |
            |--- lambda ---

移設の進め方

インフラ構成の把握

移設を始める前に、まずプロポクラウドのインフラ構成を理解して、どのようなプロダクト単位で分割できそうか検討しました。

プロポクラウドのインフラに関するドキュメントを読み、LLMを利用してコード内容を把握し、Terraformコードからインフラ構成の理解を深める
terraform の各リソースがどのプロダクトに所属しそうか、検討をつける

コード移設先の振り分けと認識合わせ

リソースの振り分け

移設対象のリソースをterraform state listでリストアップし、1,300以上のリソースに対して、どのプロダクト配下に移設するか割り振りを設定しました。とはいえ、1,300のリソース全てに一つ一つ移設先のプロダクトを割り振るのは大変です。そこで、基本的には「同じ.tfファイル内のリソースは同じプロダクトに所属する」という前提で、.tfファイル単位で割り振りを行いました（一部、同じ.tfファイルでも別のプロダクトに割り振ったものもあります）。

また、割り振った結果、リソース数が多くなりすぎたプロダクトについては、より小さな機能範囲でプロダクトの分割を行いました。

認識合わせ

実装を進める前に、移設後のディレクトリ構成のドキュメントを用意して、プロポクラウドのエンジニアリーダーと移設後のディレクトリ構成に関する認識を合わせました。

実装

方針

移設を進めるにあたり、以下の実装方針を定めて進めました。

resource addressの名称は移設前後で変更しない
- resource addressを変更すると、どのリソースが移設済みでどのリソースが未移設なのか把握しにくくなるため
移設に合わせてインフラ構成の改善・設定変更はしない
- 全体の移設工数が増えて移設が中途半端に終わることを防ぐために、気になる設定があってもそのまま移設する（気になった点はメモに残しておいて移設後に対応する）
リソース数が少ないプロダクトから移設を始める
- 想定しなかった移設時の問題が発生するリスクに備えて、小さいプロダクトの移設から着手する
import ブロックを利用して state ファイルへのリソースの import を実施する
- CLIコマンドではなくimportブロックを利用することで、importしたリソースをコードから把握できるようにする
```
import {
    to = aws_iam_user_policy_attachment.xxx_yyy["arn:aws:iam::aws:policy/xxx"]
    id = "zzz/arn:aws:iam::aws:policy/AmazonS3FullAccess"
}
```
移設先のコードは基本的にAIに作成してもらう
- プロンプトファイルの活用: 移設にあたって遵守してほしいルールをプロンプトファイルにまとめ、AI Agentに参照してもらいながらコードの実装を進める
- プロンプトの精度向上: こちらの要件に合うコードが出力されなかった場合は、参照先のプロンプトファイルを修正してコードの再作成を行い、期待するコードの再現性を高める
全プロダクトの移設が完了するまで移設元のコードを残し、移設完了後は時間を置かずに移設元のコードを削除する
- 移設プロジェクトが、万一途中で頓挫した時に、移設元と移設先両方のコードのメンテナンスをしなくて済むように、移設完了までは、移設元のコードをベースにインフラの開発を進める
- プロポクラウドの開発者側で移設元のコードを追加・変更した場合は共有してもらい、移設先のコードにも反映させる
- 移設完了後は、移設元のコードをすぐに削除し、移設元のコードで開発を実施しないようにする

実装の流れ

以下のサイクルをプロダクト単位で回して、Terraformコードの移設を進めました。

移設元の.tfファイルと移設先のディレクトリをAIに指示する
AIでresource/importブロックのコードを生成する
terraform planでimportによるstateファイルへの取り込みの他に、リソース設定の変更など差分の発生しないことを確認する
terraform applyでstateファイルへのimportを実施する
移設したresourceをスプレッドシートに記録する
- 移設前のresource addressのリストと、移設後のresource addressのリストを比較して、resource addressの数が一致することを確認

つまずいたポイントと対処法

AIがこちらのイメージと異なるコードを出力する

AIにコードを作成してもらう際に、意図と異なるコードを出力することがあったため、以下の対応を取りました。

プロンプトファイルの整備: AIが参照するべきルールをプロンプトファイルとして用意
- 必須で作成するファイルのリスト
- 移設先の.tfファイル名
- 移設元のstateファイルを参照元として利用するのは禁止（あとで削除するので）
- data.terraform_remote_stateは利用しない
- resource addressは変更しない
- デフォルトのタグ設定
- 移設後のコードをAI自身にレビューしてもらう時のチェック項目
- などを定義（ただし、いま同じことをするなら、terraform コード移設のためのスキルを作成して進めるかもしれないです）
一度に移設するリソース数を減らす: コンテキスト量が増えると、プロンプトの一部の指示を無視することがあったため、一度に移設するリソースは50個ぐらいに留めるようにする

import　ブロックのARN取得作業

importブロックの作成時にはリソースのARNを記載する必要がありますが、1,300以上のリソースのARNを手作業でコンソールや CLI を利用して収集するのは大変です。

そのため、AI Agentを活用して、AWSリソースのARNを取得する参照系のコマンドを発行してもらい、import ブロックを AI agent に実装してもらいました。よく利用するAWSの参照系コマンドはApproved Listに追加して、AI Agentが自律的にコマンドを実行できるようにしました。

terraform import　時に意図しない差分が発生する

importするリソースの一部では、plan実行時にリソース設定が更新されるケースがありました。そこまで大きな変更ではなかったので、そのまま適用することも検討しましたが、今回は、lifecycleのignore_changesを利用して update されないように対応しました。

実際にかかった工数

移設全体にかかった工数の内訳は以下の通りです。

フェーズ	工数
インフラ構成の把握	約2週間
コード移設先の振り分けと認識合わせ	約2週間
実装	約6〜7週間

AIへの指示に使うプロンプトは、生成されたコードに見られた避けるべきパターンを具体例として組み込む改善を繰り返したことで、実装の後半になるほどやり直しが少なくなりました。そのため、いまもう一度同じ実装を行えば、実装工数を 1/3 ほど削減できるのではないかと思います。

まとめ・今後の展望

移設して良かった点

コードの変更が実施しやすくなった: どこのディレクトリに対応するリソースの設定があるか把握しやすくなり、コードの変更作業を実施しやすくなった
プロポクラウドのインフラの理解が深まった: 副次的な効果ですが、移設の過程で全リソースを確認したことで、インフラ構成の全体像を把握でき、設定の課題なども把握できるようになった

今後の展望

今回はTerraformの構成を移設しただけなので、今後は監視やデプロイの標準化も進める予定です。インフラの標準化を着実に進め、少人数のチームでも多くのプロダクトのインフラを安定して管理できる体制を維持していきたいと思います。

最後までお読みいただき、ありがとうございました。