今朝は晴れていて、少し風が強い日でした。普段なら好きな天気。でも今日はちょっと違いました。
ジャケットを着て、自転車で駅へ急ぎました。いつもより遅れていて、眠いし、疲れてるし、頭の中はぐちゃぐちゃになった。そのほとんどが、Terraformのこと。
TerraformのSnowflakeプロバイダーをアップグレードしようとして、もう1ヶ月近く経っていました。でもまだ、安心してアップグレードできる方法が見つかっていませんでした。
ちょっとだけバージョンを上げたら、接続が壊れました。接続を直したら、20個のモジュールがエラー。1つ直そうとしたら、「構成が全部互換性ない」と言われた。
なんで、ツールのアップグレードがこんなに大変なんだ？
いつも好きな風も、今日はただ重く感じました。「ほんとにこの地獄から抜け出せるのかな…？」って、本気で思ってました。
Hey what's up, Niko here.
Yes、上の読んだ話はぜんぶ実話です。
前にはTerraformのSnowflakeプロバイダーをアップグレードしようとしたときに本当に起きた出来事です。
もうほんとに悪夢でした…。
あまりにも辛すぎて、このツールに対して“love and hate”の感情がわいてきて、ついには「結婚したい」なんて冗談まで言ってました（笑）。
しかもそれだけじゃなくて、その気持ちを込めてAIでlove songまで作っちゃいました。
とても耳に残る曲なので、よかったら聴いてみてください!
…でも、あれから時間がたって、今では状況がだいぶ変わりました。
Terraformのバージョンアップで地獄を見なくなったんです。
なぜかというと、ある“新しい武器”を手に入れたから。それが AIツール（特にCursor） です。
今回は、そのツールと一緒にどうやってここまでたどり着いたのか、軽めに紹介していきます！
Hope you enjoy this quick read!
terraform-snowflake-providerの問題（と私の問題）
「問題 → 解決」のStoryって面白いですよね。というわけで、まずは問題点から始めましょう。
私たちはずっとTerraformでデータ基盤を管理してきました。Snowflakeもその例外ではありません。なので、当然のように公式のTerraform Snowflake Providerを使っていたのですが、去年あたりから状況が崩れ始めたんです。それはなぜ：
プロバイダーが技術的にまだ不安定
当時のバージョンはまだ0.x台で、壊れる変更があるのはある意味仕方ない状態でした。以前のバージョンでは問題なくモジュールが適用できていたのに、ほんの少しバージョンを上げただけで、すべてが突然崩壊しました。
よくある破壊的変更
開発方針が変わり、開発チームも変わりました。その結果、互換性の問題やドキュメントにない挙動など、私たちに直撃しました。
たとえば、grant系のリソースが非推奨になったケース。私たちはこれらを使って、外部ツールと連携するためのロールを管理していたので、移行はまさに地獄。
🔗 https://github.com/snowflakedb/terraform-provider-snowflake/discussions/2736
他にも、バージョンを上げてapplyを実行すると「schema will be replaced」といったメッセージが表示されることもありました。しかも、Migration Guideに従っていたにも関わらず。謎です。
🔗 https://github.com/snowflakedb/terraform-provider-snowflake/issues/3015
バージョンアップを放置しすぎた...
すべては順調に見えました…あの時までです。定期的なアップデートを怠っていたため、いざやろうとしたときには差が開きすぎていて、結果はカオス。
当時、Kurashiruチームでデータエンジニアをしていたのは私一人だけ。日々の業務に追われ、Terraformのアップグレードはいつも後回し。気づけば、すべてが壊れていました。
Terraform地獄、まさにその真っ只中でした。
Cursorの登場
数週間にわたる苦闘の末、ようやく0.99にアップグレードして、問題のあるリソースを移行することができました。（ちなみに、まだ最新バージョンじゃなかったんです。笑）
ちょうどその頃、delyではAIツールの実験が始まっていました。「もしかして、AIでこのカオスをどうにかできるんじゃないか？」という話に。
そこで試したツールのひとつがCursor。VSCodeベースで、LLMが組み込まれたAI特化型のコードエディタです。
なぜCursor？
実はCursorの前にDevinも使っていました。
Devinは有能でした。リポジトリ全体を読んで、なかなか良いアップグレードプランを作ってくれました。実際、これで1.0.0までは行けました。でも、
- 長時間動かすとハルシネーションが増える（LLMあるある）
- サンドボックス環境で動くため、何をしてるのか見えづらい
- ACU制限で使いづらいこともあり
一方、Cursorはというと：
- ローカル実行なので安定感あり
- VSCodeそのままの使い勝手で拡張機能も使える
- より多くのコンテキストを渡せて、幻覚も抑えられる
結果的に、Cursorは「制御できて信頼できる」ツールでした。ツール選びは本当に人それぞれだと思います。私は手を動かすタイプなので、Cursorが合ってました。
Cursorをうまく使うために：ルール、コンテキスト、構造
さっき少し触れましたが、Devinでアップグレードした時は時間がかかりました。その原因は、十分なコンテキストを与えていなかったこと。
この経験から、AI（CursorでもDevinでも）をただ走らせるだけではダメで、プロジェクトの構造を教える必要があると学びました。
私たちがやったことは以下のとおり：
1. コンテキストを与える
プロジェクトの構成、モジュールの場所、環境の分け方、命名ルールなどをCursorに理解させました。
そのために、cursor.rulesファイルを作成して、日常的な作業内容も含めてまとめました。
Cursor rulesは、自然言語でプロジェクトのルールや構造を伝えるためのファイルです。ドキュメントを見る:
2. llms.txtを活用
llms.txtというファイルも追加しました。
これは一見地味だけど、ドキュメント全体にわたってLLMにコンテキストや期待する振る舞いを事前に読み込ませる強力な仕組みです。
実際のところ、llms.txtはcursor.rulesとかなり似ています。()
ただ、より汎用的な用途を想定していて、全体的なコンテキスト補完に向いています。
今回のケースでは、TerraformプロバイダーのリソースURL一覧をまとめておく用途で使いました。
これによって、Cursorに「モジュールを作って」とか「プロバイダーをアップグレードして」とお願いしたときに、自動で最新のドキュメントをチェックしてくれるようになります。
たぶん参考になると思うので、実際に使っているllms.txtもシェアしておきます：
それから、Cursorのルールにはこんな感じの指示も追加しています：
リクエストに基づいて常にllms.txtを参照し、必要なページを読むこと
3. Migration Guideは必ずダウンロードと参照
最後に、Terraform Snowflake Providerの開発チームは、バージョンアップやマイグレーションに関する情報をちゃんとリポジトリにまとめてくれています。
つまり、「何が変わったか」「何が壊れるかもしれないか」は、すでにドキュメントとして存在しているんです。
なので、私たちはそのマイグレーションガイドをLLMがちゃんと読むようにルールで指示しました。
そうすることで、「このバージョンではこのリソースが非推奨になってるな」「この設定が新しく追加されたんだな」みたいな情報も、AIがちゃんと把握してくれるようになります。
具体的には、Cursorのルールに「必ずマイグレーションガイドをダウンロードして参照すること」という命令を追加しました。こうすることで、どのバージョン間でも確実に変更点をチェックできるようにしています。
snowflakeプロバイダーのバージョンアップグレードのリクエストがある場合は、常に以下を実行すること：
wget https://raw.githubusercontent.com/snowflakedb/terraform-provider-snowflake/refs/heads/main/MIGRATION_GUIDE.md
そして、その内容を適切に参照すること。
これで「ガイドはあるけど誰も読んでなかった問題」も、解決です。
AIに読ませれば、読み忘れもゼロになる（はず）！w
結果 🎉
このセットアップを終えて、Cursorに最新版へのアップグレードをお願いしたところ、
ルールをしっかり読んで、マイグレーションガイドもダウンロードして、きちんと中身まで読んでくれました。
私たちの現在のv1.0.0からv2.1.0へのUpgradeを、大きなトラブルなしで達成。
接続エラーもゼロ。
大規模なリファクタも不要。
Cursorがモジュールごとに丁寧に互換性をチェックしながら進めてくれました。
Terraformのアップグレードが、もはや悪夢ではなくなりました。今では…ちょっと楽しいかも。少なくとも、予測できるものになった。
まとめ
Cursorルールのおかげで、以前なら絶対無理だと思っていた「Snowflakeプロバイダーの安全なアップグレード」ができました。
この経験は、単に時間を節約しただけではなく、開発やツールの考え方そのものに変化をもたらしました。AIは「未来のもの」ではなく、「今日から使える実用的な相棒」だと実感しました。
次にやりたいこと
今回の成功をきっかけに、もっと先に進みたくなっています：
- AIの活用範囲をデータエンジニアリング全体へ拡大 — SQLの自動生成、データ品質チェック、リファクタの提案など
- MCPのようなツールとの連携強化 — よりスマートでモジュール化されたパイプライン作成へ
- AIを活かした開発のベストプラクティスづくり — チーム全体で活用できる仕組みに
まだ始まったばかりですが、もう未来はそんなに怖くない気がします!
読んでくれてありがとうございました！TerraformのUpgradeに悩んでいる人にとって、少しでもヒントになれば嬉しいです。
それではまた。Have a nice and sunny day！ ☀️
Discussion