最近話題のバイブコーディング。
弊社でも、ボチボチとCursorを導入しはじめ、いくつかのプロジェクトでその力を試しているところです。今回はプログラミングを10年ほどやってなかった私(最近またちょっとだけやってる？w)がEC-CUBEのプラグイン開発をやってみました。
8割までは一瞬。でも、そこからが長い。
まず結論から言うと、AIは優秀だけど、魔法の杖ではないです。
たとえば、EC-CUBE 4.3のプラグインで「動画を販売できるようにしたい」という要件でバイブコーディングしてみたところ、基本的なファイル構成・エンティティ定義までは、驚くほどスムーズに進みました。おそらく8割くらいまでは、ほんの数分で生成できます。
でも、そこから先が大変w
コントローラのコンテナ登録漏れ、Twigでの動的レンダリング調整、拡張対応…
地味で泥臭い作業が、AIにはまだちょっと苦手みたいです。
結局、“完成”まで持っていくには知識がある程度必要。
AIに「やってほしくないこと」をやらせないために
バイブコーディングをうまく活用するには、「ルール設計」が命です。
あいまいな指示をすると、AIは意図しない実装をします。
たとえば…
・Twigファイルの場所を勝手にapp/Resource/templateに置かれたり。
・カスタムエンティティのRepositoryが自動登録されてなかったり。
・さわってほしくないコードを勝手にさわってわけわからなくしたり。
・EC-CUBE4.3なのにEC-CUBE2とか３とかのプログラムで書き出したり。
AIに悪気があるわけではないけど。。。
むしろ、「書いてないことは知らない」のがAIの特性。
だからこそ、“やってほしくないこと”は最初に明記する必要がある。
“やってほしいこと”は、詳細に構造化して伝える。
伝えてもすぐに忘れるのでルールファイルに必ず記述しておく。
Cursorだと.cursorruleに記述しておく。これ大事です。
この手間を惜しむと、結局あとから手直し地獄に陥ります。まじで陥るからw
「共通化しよう」とすると、逆にハマるw
AIに「汎用的にして」「共通化して」と指示すると、
思った以上にうまくやれない。
たとえば、商品登録フォームの拡張を共通Traitで処理しようとすると、
EC-CUBEの内部仕様との“相性問題”が発生しました。
そんな沼にハマることもしばしば。いやずっと沼にハマめられまくり。
結論としては、「共通化」は後回しでよい。
まずは1つをきちんと動かす。
動いたあとでパターンを抽出して共通化する方が圧倒的にラクです。
プログラミング知識が少しでもなければ、たどり着けない現実
「AIがコードを書いてくれる」とはいえ、実装の成否を握るのはやっぱり、まだ人間。
少しでも知識がなければ、AIが出してくれたコードが正しいのかどうかすら判断できない。
つまり、「AI任せで完成」は無理。
まとめ：ある程度知識がないと無理w
今回、バイブコーディングでEC-CUBEプラグインを開発してみて実感したのは、
AIは8割までを爆速にしてくれる。でも、最後の2割は人間の知恵と汗が必要。
正直、簡単には作れませんでした（笑）。
でも、開発スピードは確実に上がるし、
社内でのナレッジ共有やドキュメント整備も進んでいる実感はあります。
今後は、もっとAIとの“共創”をうまくデザインして、
開発全体のUXを上げる仕組みづくりにシフトしていきたいところです。
あっプラグインは一応できました！何回かやり直ししてるうちにだんだんプログラムを思い出してきたのと
知識もついたのでw
動画をストリーミングで販売できるプラグインです。
保証はできないけど、野良でダウンロードできるよにしようかなw
