落とし穴① コントリビュートモジュールで済む話をカスタム開発してしまう
何が起きたか
あるプロジェクトで、コンテンツの表示を条件によって切り替える機能が必要になりました。AIに「こういう機能を作りたい」と伝えると、すぐにカスタムモジュールのコードを生成してくれます。それっぽく動くものができあがります。
しかし後から調べると、同じ要件を満たすコントリビュートモジュール（Drupalのオープンソースコミュニティが提供するモジュール）がすでに存在していました。
カスタムモジュールでの実装は、
- バグが出たとき自分たちで直さなければならない
- Drupalのバージョンアップ時に動作確認・改修が必要
- 担当者が変わったとき、コードを読み解くコストがかかる
という負担をずっと抱え続けることになります。コントリビュートモジュールであれば、コミュニティが継続的にメンテナンスしてくれるため、長期運用コストが大幅に下がります。
なぜAI駆動開発でこれが起きやすいか
AIはリクエストに対して「作る」方向で答えようとします。「既存モジュールで対応できるか調べる」という判断は、AIではなく人間がしなければなりません。バイブコーディングのスピード感の中では、この「立ち止まって探す」ステップが抜けやすくなります。
✅ 教訓：実装に入る前に「これはコントリビュートモジュールで実現できないか？」を必ず確認する。AIへの指示は「実装して」より先に「既存モジュールで対応できるか調べて」から始める。
落とし穴② 見つけたモジュールがDrupal 7時代の遺産だった
何が起きたか
今度は逆のケースです。コントリビュートモジュールを調べようとAIに相談すると、それらしいモジュール名を提案してくれました。ところが実際にdrupal.orgで確認してみると、そのモジュールはDrupal 7までの対応で、現行のDrupal 10/11には未対応でした。
Drupalは長い歴史を持つCMSで、Drupal 7時代に作られたモジュールが今もdrupal.org上に存在しています。AIの学習データにはこれらの情報も混在しているため、「古いが現役のように見えるモジュール」を自信満々に提案してくることがあります。
開発者がそのまま信じて導入を進め、後になって「このモジュールはもう使えない」と発覚した場合、予定していたスケジュールやリソースでは対応できないという状況に陥ってしまいます。
なぜこれが問題か
モジュール選定のミスは早期に発覚すれば傷が浅いですが、開発がある程度進んでから発覚すると手戻りが大きくなります。特にモジュールを前提としたデータ設計やUI設計まで進めてしまった後では、影響範囲が広がります。
✅ 教訓：AIが提案したモジュールは必ずdrupal.orgで現行バージョン対応を確認する。「Releases」タブで直近のリリース日と対応バージョンを目視確認することを習慣にする。
落とし穴③ バイブコーディングには「設計」が追いつかない
何が起きたか
これが最も本質的な落とし穴かもしれません。
AIと一緒に開発を進めると、「とりあえず動くもの」が驚くほど速くできあがります。画面を見せてフィードバックをもらい、また実装して…というサイクルを繰り返していくと、機能的には要件を満たしているように見える成果物が生まれます。
しかし実際に運用担当者や営業担当者が使い始めると、「なんか使いにくい」という声が出てきます。
- コンテンツの入力項目が多すぎて迷う
- 情報の管理単位がバラバラで、更新作業が煩雑
- サイトの一部を変えたいとき、どこを触れば良いかわからない
これらは機能の問題ではなく、情報設計・コンテンツ設計が甘かった問題です。AIはリクエストされたものを作りますが、「本当に使いやすい構造になっているか」「運用担当者が日常的に使うことを想定した作りになっているか」を考える視点は持っていません。
「動いている」がメンテナンスを難しくする
運用が始まった後に「ここを少し変えたい」という要望が出るのは、どんなプロジェクトでも避けられません。バイブコーディングで作られたシステムでよく起きるのが、「どこを触れば良いかわからない」状態です。
動くことを優先して実装されたコードは、なぜそう作ったかの意図が伝わりにくくなりがちです。担当者が変わったとき、あるいは数ヶ月後に自分が見返したときでも、修正箇所の特定に時間がかかります。
Drupalはコントリビュートモジュールを組み合わせて柔軟に構成できるのが強みですが、裏を返せば「どこに何を持たせるか」の設計判断が運用・保守のしやすさに直結します。AIはこの判断を代わりにしてくれません。
大規模プロジェクトではスコープ設計の失敗も起きる
外部システムとの連携が伴う大きなプロジェクトでは、さらに深刻な問題が起きることがあります。
「とりあえずAIと一緒に実装してみよう」というアプローチで進めると、自社（Drupal側）が担うべき責務と、連携先システムが担うべき責務の境界線を曖昧なまま実装してしまうケースがあります。
「できることをできる場所に実装する」という進め方は、後から見ると責任の所在が不明確なコードを生む原因になります。連携先システムの仕様変更が起きたとき、「Drupal側に影響するのかどうか」すら判断できない状態になってしまいます。
なぜAI駆動開発でこれが起きやすいか
バイブコーディングは「作りながら考える」スタイルです。それ自体は悪くないのですが、設計の判断を後回しにし続けると、積み重なったツケが運用フェーズに一気に表れます。
AIは目の前の実装に答えてくれますが、「このシステム全体をどう設計するか」「誰が・どう使うか」「5年後に誰がメンテナンスするか」という問いには答えられません。開発のスピードが上がるほど、設計なしに進んだ距離も伸びます。気づいたときには、作り直すコストが最初からきちんと設計するコストをはるかに超えていた、というのがバイブコーディングの典型的な末路です。
✅ 教訓：実装に入る前に、コンテンツ設計・情報設計・システム間のスコープ定義を人間が明確にする。「誰が運用するか」「誰がメンテナンスするか」を最初に決めることが、AI駆動開発を本当の意味で速くする投資になる。
まとめ：AIは「速く作る道具」、設計は「人間の仕事」
3つの落とし穴を整理すると、共通するメッセージが見えてきます。
AI駆動開発は、間違いなく開発のスピードを上げてくれます。しかしそれは、設計と判断をきちんとした上で使うからこそ速いのであって、設計を飛ばして速くなるわけではありません。
「動いた」で終わらず「使えて・保守できる」ものを作るために、AI駆動開発でこそ設計の重要性が増していると弊社は感じています。
アクレットではDrupalを活用したWebサイト構築・運用を支援しています。設計段階からのご相談も歓迎しております。お気軽にお問い合わせください。
