はじめに
Waka です！
CRE チームでエンジニアをしています。
CRE の仕事は、現場の困りごとを仕組みで解いていく役割です。
日々の業務は、問い合わせ対応から運用改善、データ分析の支援まで幅広く、ひとつの専門領域に閉じない動き方が求められます。
ただ、何でも得意かというとそうではなく、未踏の領域があります。
インフラや基盤まわりがそれで、アプリ寄りの守備範囲で仕事をしてきた私にとって、Terraform や CI/CD パイプラインは「読めるけれど自分で設計するのは怖い」領域でした。
そんな私がこの数か月、Redash（Web UI 上で SQL を書いて可視化するツール）のクエリを Git で管理する「GitOps 化」に踏み込みました。
本記事では、未踏領域に踏み出すうえで AI がどう効いたかを書きます。
1. 越境のきっかけ — トイル根絶という旗
きっかけは、CRE のミッションに掲げた「トイル根絶」でした。
Redash の ad-hoc 運用は、その温床です。
- 権限過多: 誰でも編集でき、本番運用クエリが無断で書き換わる
- 属人化: 作成者の異動で、意図を説明できる人がいなくなる
- レビュー不在: ロジックの誤りが、本番ダッシュボードに乗る
「これは仕組みで解くべきだ」と直感はしたものの、肝心の GitOps 設計は私にとって本来の畑ではない領域。以前なら、ここで誰かに丸投げしていたと思います。
2. 詰まったのは「既存資産との接続」
着手して最初に詰まったのは、新規導入ではなく 既存クエリ群との接続 でした。
素朴に一括同期すると、state と Redash 上の実体が乖離し、同じクエリが重複作成される。既存ダッシュボードは古いクエリ ID を参照しているため、表示が壊れる。
辿り着いた答えは、地味な 4 ステップでした。
| ステップ | 内容 |
|---|---|
| 棚卸し | 既存クエリのメタデータ（作成者・最終実行・参照先）を全件出力 |
| 仕分け | 作成者本人に「必要／不要」を判断してもらう |
| 段階移行 | 必要なものだけリポジトリに取り込み、不要は廃棄 |
| Drift 検知 | 取り込み済みは UI 編集禁止。CI で差分を検知して通知 |
3. AI が「越境のハードル」を下げてくれた
ここで効いたのが AI でした。私が AI に頼ったのは、コードを書かせることよりも、むしろ 「分からないことを分からないまま前に進める」 部分です。
- terraform state の挙動を、自分の語彙で何度も聞き直せる
- 設計案を出すと、想定外の壊れ方を先回りで指摘してくれる
- 畑違いの領域でも「とりあえず一案」を出せるので、議論が前に進む
以前の私なら、なじみのなさでそもそも着手しなかった領域です。
AI のおかげで、「やったことがない」が踏み出さない理由にならなくなった。
これが一番大きい変化でした。
学び: 私にとって AI は、既存スキルの拡張というより、越境のハードルを下げてくれるものだった。畑違いの領域に一歩踏み出す回数が増えれば、CRE のように横断が前提の役割では、効ける範囲そのものが広がる。
おわりに
GitOps の華やかな話の裏で、私が得た一番の収穫は、技術そのものではなく 「未踏領域に踏み出す回数が増えた」 という感覚でした。
最後までお読みいただき、ありがとうございました。