TROCCO の転送ジョブ・ワークフローを Terraform で IaC 化する

ツール導入前の課題

メドレーでは ETL ツールの一つとして TROCCO を活用していますが、連携対象のテーブルや連携先が増えるにつれて、だんだんと GUI での運用コストが上がっている状態でした。

具体的には、

• カラムの型変換や連携処理の命名などのポリシーが設定した人や時期によってバラバラになる。また途中でポリシー変更をすると全部開き直して一つ一つ修正を適用しないといけない。
• 転送ジョブが増えるとワークフローの設定画面が重くなったり、どのノードがどのジョブかの視認性が著しく低くなる。また依存関係を管理するのが難しい。
• 新規プロダクトが立ち上がった時、数十のテーブル連携を一気に立ち上げる必要があるが一つ一つスキーマ定義をチェックして設定していかなくてはいけない。
• 転送元が抽出用の SQL とセットの場合、転送設定とともに SQL もコード管理対象としたいが GUI 上でしか確認できず、テストと反映が手作業になる。

といった課題がありました。

どのような状態を目指していたか

これらの課題はいずれも GUI 運用に起因するものであり、TROCCO の転送ジョブ・ワークフロー・スケジュール、さらには抽出 SQL までを含めて、すべてコードとして Git 管理下に置く（= IaC : Infrastructure as Code）ことで一挙に解消できると考えていました。

ポリシーをコード上で共通化・テンプレート化し、ワークフローや依存関係も宣言的に定義。また新規プロダクト立ち上げ時にはアプリケーションのスキーマ定義を起点に転送設定を一気通貫で生成・反映できる、そんな状態をゴールとしていました。

決め手になったのは、ちょうど以下の3点が揃ったタイミングだったことです。

1. Terraform Provider for TROCCO のサポート拡充

近年 Terraform Provider for TROCCO の開発 が活発に行われ、転送ジョブ・ワークフロー・スケジュールといった主要リソースをコードで宣言できるようになりました。Provider がなければ TROCCO の IaC 化は成立しないため、これが大前提となります。

2. データ組織内での Terraform 運用実績

私たちのデータ組織では、別途運用しているデータポータル（社内向けデータ活用アプリケーション）のインフラ構成管理に Terraform を採用しており、運用ノウハウが蓄積されていました。TROCCO も同じツールチェーンに乗せられれば、「データに関わる処理と環境を統一的に管理できる」状態が実現でき、既存の型を流用することで導入コストを最小限に抑えられます。

3. 生成 AI による IaC 化の支援

インフラをコードで宣言する IaC は生成 AI との相性が良く、GUI で設定されていた既存リソースを再現するための tf ファイルの構成パターンの解析も可能です。結果として新規の類似連携設定はテーブル定義から直接生成できるようになるなど、一連の生成フロー整備に必要なコストを大きく下げられる見通しが立ちました。

改善したかった課題はどれくらい解決されたか

TROCCO の各種設定を Terraform 配下に置くことで、GUI からの手修正のほとんどをコード経由に寄せられました。導入前に挙げた課題は、いずれも大きく改善しました。

どのような成果が得られたか

• TROCCO 上の設定がほぼすべてコード管理可能になり、変更内容のレビュー・記録が容易になった
• terraform plan による事前差分確認で、本番反映前に意図しない変更を検知できるようになった
• アプリケーション側のスキーマ定義を起点に、テーブル連携からワークフロー組み込みまでを一気通貫で記述できるようになり、新規プロダクト立ち上げ時のリードタイムが大きく短縮された
• 抽出 SQL も転送設定と同じリポジトリでバージョン管理されるようになった
• 生成 AI を組み合わせた設定フローを整備したことで、既存 GUI 資産、並びに新規転送設定のコード化コストを大きく下げられた

TROCCO は長らく GUI 前提で運用してきたため、既存設定から tf ファイルを起こすまでの流れを確立するのが最初の山場でした。どの粒度でコード化し、terraform import とどう突き合わせて差分を潰すか、という型ができるまでに試行錯誤が必要でした。

ここで効いたのが、決め手の3点目にも挙げた生成 AI の活用です。TROCCO の API でリソースを列挙し、スキーマを AI に渡して tf ファイルを自動生成、terraform import → plan で差分を確認する、という流れを Claude Code の Skills として定義しました。一度型を作ってしまえば以降は同じフローに乗せるだけで進められ、既存ジョブのコード化を現実的な工数で回せるようになっています。

最初から全リソースを一気に IaC 化しようとせず、まずは1つのユースケースから始め、terraform import で既存資産を段階的に取り込むアプローチがおすすめです。TROCCO のように GUI 前提で運用されてきたサービスは、既存設定から tf ファイルを起こすフローを確立するのが最初の山場なので、ここは生成 AI との組み合わせが非常に効きます。コード化を AI に任せられる土台を早めに整えておくと、移行作業やその後の新規追加作業は同じ型に乗せるだけで進められます。

また、IaC 化後も GUI からの変更が発生しうるサービスについては、ドリフト前提で運用を設計しておくと安心です。定期的に plan を流して差分を検知する仕組みや、GUI 変更を原則禁止するといった運用ルールを、導入初期から決めておくのが良いかもしれません。

現在は TROCCO のジョブ・ワークフロー・抽出 SQL を Terraform 配下に置く第一段階がようやく軌道に乗ってきた状況です。今後はこれをベースに、アプリケーション側のスキーマ変更を検知して tf ファイルの更新 PR を生成し、terraform plan まで自動で流して人間によるレビュー後に apply、といった一連のフローを生成 AI エージェントに任せられる状態を目指しています。あわせて、ドリフト検知の定期実行も整備していきたいです。

また、Terraform Provider for TROCCO は現在も活発に開発が進められているため、新しくサポートされるリソース・転送先に追従しながら、データ連携領域の IaC カバレッジをさらに広げていきたいと考えています。