Vibecodingはめちゃくちゃ使えるが、「安易に」やるべきではないのではと思った話
株式会社DFastについて
歯科医療AIスタートアップ株式会社DFast代表取締役歯科医師の松村勇佑です。
今後弊社の取り組みや技術的な話を少しずつまとめていこうと思います。
弊社は元々ノーコード開発プラットフォームBubbleを使ったアプリ開発の受託事業を行っておりました。
最近では、自社で運営サポートしている歯科医院の内部システムの開発や生成AI活用支援など、私が歯科医師として現場に立ちつつ、技術も理解しているからこそできる事業も行っており、ありがたいことに多くの歯科医院の先生方からお声がえいただくことが増えてきました。
バイブコーディングって便利で怖い
最近よく耳にする「Vibecoding」という言葉ですが、生成AIを駆使して開発するスタイルで今後開発者にとってスタンダードになる（というかもうなってる）はずの開発スタイルです。私自身、もともとフロントはNextJS、バックエンドはPythonで書いていますが、開発効率は異常に上がった気がしますし、短期間で形にできる爆速感にかなり魅力を感じました。しかし同時に、何も理解せずに安易にデプロイすると危険すぎるということも痛感しました。
PostgresSQLのRLS設定がめちゃくちゃに
私が最初にやらかしたのは、PostgresSQLのRLS（Row Level Security）の設定です。PostgresSQLでは、セキュリティの観点で非常に優れており、柔軟な対応ができるのが一つの特徴だと思います。特に弊社では、医療関連の情報を取り扱うこともあり、セキュリティ設定については非常に重きを置いています。しかし、Claudecodeはそんな事業なんて知りません。動くものを作ることばかり考えており、認可まわりをまともに確認していませんでした。その結果、ユーザーごとに制限されるべきデータが丸見え状態になっていました。URLを叩くと普通に見れる状態。結局その修正に時間を取られてしまい、ロスタイムが増えてしまったのは、、、。
RLSについてはXでも一時期話題に上がっていましたが、まさにそれを身をもって体験した形です。動作確認で通ったから安心、というのは完全な思い込みでした。セキュリティ設定は「動くかどうか」ではなく「漏れないかどうか」を基準に考えなければならないと痛感しました。
Webアプリを開発する上で『プロダクト』を形にするだけでは、もちろんダメで安全かつ安定に提供することが重要です。
Vibecodingの魔力と危うさ
Vibecodingには間違いなくメリットがあります。実装スピードは速く、動くものを短時間で形にできるため、アイデア検証やプロトタイピングには最適です。私も「雰囲気でやってみたら意外と動いた」という経験に何度も助けられました。
しかし同時に、Vibecodingには大きな落とし穴があります。設計やセキュリティ、責務分離といった重要な観点がすっぽり抜け落ちやすいのです。特に初学者やチーム開発の現場では、**「動くけど危険なもの」**が量産されてしまう危険性が高いと感じました。
まとめ
今回の経験を通じて強く感じたのは、Vibecodingは「短期的な試作」には非常に役立つ一方で、「責任を持つプロダクション開発」においてはリスクが大きすぎるということです。
今後は、自戒として以下のような姿勢を持ちたいと思います。
- 最低限のセキュリティチェックリストを持ちながら開発する
- 「動くから大丈夫」ではなく「漏れないから大丈夫」を基準に判断する
- ServerとClientの責務分離を理解してから技術を使う
最後に一言。
「動くからヨシ！」は事故の温床です。
Vibecodingのスピード感は魅力的ですが、責任を持つコードを書くのであれば、雰囲気だけでは済まされません。私自身、今後は二度と同じ失敗を繰り返さないように気を引き締めていきたいと思います。
自戒を込めて。
Discussion