officel · Oct 28, 2026 · Oct 28, 2026
@@ -122,6 +122,7 @@
 <details open>
 <summary>2026 年の記事</summary>
 
+- 2026-10-28 [ [:memo:](articles/2026-10-28_tfstylus_03.md) ] [その３　AIと併走しながら tfstylus を開発して苦労したこと](https://zenn.dev/terraform_jp/articles/2026-10-28_tfstylus_03)
 - 2026-10-27 [ [:memo:](articles/2026-10-27_tfstylus_01.md) ] [その１　なぜ tfstylus を作ったのか](https://zenn.dev/terraform_jp/articles/2026-10-27_tfstylus_01)
 - 2026-10-27 [ [:memo:](articles/2026-10-27_tfstylus_02.md) ] [その２　tfstylus を作り始めた時にわかっていなかったこと](https://zenn.dev/terraform_jp/articles/2026-10-27_tfstylus_02)
 - 2026-10-26 [ [:memo:](articles/2026-10-26_tfstylus.md) ] [terraform のコードを少し整える tfstylus を作ってみた](https://zenn.dev/terraform_jp/articles/2026-10-26_tfstylus)

@@ -0,0 +1,72 @@
+---
+title: "その３　AIと併走しながら tfstylus を開発して苦労したこと"
+emoji: "😫"
+type: "tech"
+topics: ["terraform", "AI", "tfstylus"]
+published: true
+publication_name: "terraform_jp"
+---
+
+# tl;dr
+
+- [terraform のコードを少し整える tfstylus を作ってみた](https://zenn.dev/terraform_jp/articles/2026-10-26_tfstylus) の続きの
+- [その１ なぜ tfstylus を作ったのか](https://zenn.dev/terraform_jp/articles/2026-10-27_tfstylus_01) の続きの
+- [その２ tfstylus を作り始めた時にわかっていなかったこと](https://zenn.dev/terraform_jp/articles/2026-10-27_tfstylus_02) の続き
+- 苦労した点について整理した
+
+# 苦労した
+
+## 大枠はAIが教えてくれるが最新とは限らない
+
+- goreleaser の brew -> homebrew-cask への変更
+- そもそも brew のこうあるべきとかをわかってなかった
+- AIがハルシネーションして homebrew-cask に間違ったパラメーター設定を出してきて、信じてたら裏切られた。ダンジョンの奥地でｗ
+
+## わかってなかったことを１つずつ検索して理解しようとした
+
+- goreleaser も brew も自分で処理するのははじめてで、ちょうどいいページが見つからなかった（ほぼほぼ終わってからkoki先生の記事に届いた。前記事参照）
+- google が悪いのか検索の仕方が悪いのか、最新バージョンに対応できていない記事にあたってしまう
+- ブログ記事に日付やその時点のバージョン等が必要だと再確認した。むしろ手順的な記事はそういうのこそ大事だろう
+- 最新版での変更点や、今後の対応方法を整理しておくことが今後のブログ記事の価値になりそうだなって。公式ドキュメントはあてにできないし、AIはまだそういうの下手だから
+- 他のことについても、わからないことをまず理解しようとして手を止めてしまうケースがあった。ぶっちゃけ後で直せば済むことなら理解は後回しにしたほうが回転は早い（回転する｛させる｝こと前提だけどね）
+
+## 見切り発車
+
+- わかってないことがたくさんあるのはわかってたけど、元々自動化は得意分野なわけで、成功するまでぶん回せばどうにかなるって感じで見切り発車した
+- 昔ならもっと何週間もかかっていたかもしれないことを、一週間かそこらでとりあえず満足する形で動くところまで持っていけたのはAIのおかげ
+- AI時代はがんがん試して失敗してやり直しが可能というか、それを前提にするべき。できるまで繰り返しやる、ダメだったとしてもプロンプトやコンテキストを修正して何度もやる、やり切る力 GRIT が大事（みなさん読みましたか？）
+- ただ、世の中のAIトップランナーの話を見てると、なにもかもAI任せでぶん回すのもAIにやらせているように見える。自分のやり方とはだいぶ違うみたいで、そんな時に期待外れな結果を得ると心が折れそうになるｗ
+- ただひたすら手を動かしてみないとわからないことがたくさんある
+- 設定ひとつとってもそれがなんのためにあるんだ？みたいなことに気を取られすぎたのはオールドタイプゆえか（これが若さか。。。）
+- そもそもダメを前提に、短期間に根気よく改善を繰り返す、それこそイテレーションが1日どころか1時間みたいなスパンで回転できるので、AIの手が空いたら次の指示をしなくちゃ！みたいな感覚に陥ることがあって、注意がいるなって
+
+## 自動化を一周するまでが長かった
+
+- 勉強不足、知見不足のせいで、自動化までが長かった
+- [task](https://zenn.dev/topics/taskfiledev) を使っているので、ビルドやテストはすぐ処理した（何度も手直ししたり横道にそれたりしてるけど）
+- brew にリリースするまでと、[prek](https://zenn.dev/topics/prek) に docker を乗せるまでが長かった
+- brew はどうあるべきか（goreleaserのcaskのところらへん）がわかってなかったせい
+- prek は system と go build は問題なかったんだけど、docker(build)の提供時に GitHub Actions Runner の Ubuntu が 24.04 から 26.04 に更新されたことで golangci-lint が通らなくなるという不運に見舞われて3日もかかってしまった
+- タイミングって言えばそうだけど、常に最新の状態を保ちたい派に属しているので、バージョンダウンを許容できなかった、柔軟性が足りてなかったのは大きな反省でもある
+- 安定して既存の実績を再利用しようと思ったら、最新よりも少しバージョンダウンさせる、のは戦略としてありかもしれない
+- そもそも長かったって書きつつも独り作業で合計2週間程度の話なので、業務として考えたらそれなりに短い話なのではないか
+- 先に書いたことも含め、AI時代の開発は人間側の時間に対する考え方を意図的に人間側に戻さないと、どんどんAI時間での進行になって早く早くになってしまう。もっとも苦労したのはこの点なのかもしれない
+
+## AIの出力結果を信用しすぎた
+
+- 安いからautoはよくないかも。無料枠の範囲で使えるモデル類はものによってまったく役に立たないというケースが何度もあった
+- そもそも設計を壁打ちしている時、実装を計画している時、実装する時で、人がモデルを選んであげないといけない時点でAIとはってなる
+- それこそエンターキーで最適なモデル選択だけを最初に行って、このモデルでいくらでやっていいですかって聞くくらいの親切心が欲しい（欲しくない）
+- まったくわかってないことはAIの意見を受け入れがちなんだけど、しばらくやって理解ができてくると違うんじゃね？みたいなこともよくあった
+- コレに関しては後半で気がついたんだけど、テスト作成済ならそれをいじらず壊さないように、内容だけAI自身に検討・変更させる、のが有効だった。同僚・部下・後輩と違って、何回リテイクさせても心が傷まないｗｗ
+- 逆にちょっとわかってるところは疑いがちで、気になって自分が動いてしまい時間を浪費するケースもあった
+- さらに、理解しているところは改善を要求しがちで、納得できるまでAIをまわして時間とコストを浪費するケースもあった
+
+# まとめと次回予告
+
+- わからないことをわからないまま前に進めるほうがAI時代にはいいのかもしれない
+- わかるまでなんとかしようとするのを後回しにするっていうか
+- AIの正体は既存の集合知に過ぎないので、一番最新で行こうとするとハルシネーションしがち。いざって時はひとつ前に戻るほうが楽かも
+- 自動化がすべてを解決する
+- 次回「気づいた時には始まっていたという話」
+- こうすればよかった、をまとめる予定