アプローチを選ぶ
バイブコーディングと従来のコーディングを比べるとき、重要なのはどちらが正当な手法かではありません。要件が変わったり問題が起きたりしたとき、誰が結果を説明し、テストし、保守できるかです。
呼び名ではなく、仕事の内容から考えましょう。以下の選択は、誰かが成果物を使う前にあなたが確認することを前提としています。
ビジュアルプロトタイプ、小規模な社内ツール、本番環境向けの機能という、よくある3つの仕事を考えてみましょう。どちらのアプローチも、条件なしにすべてで優れているわけではありません。
ビジュアルプロトタイプには選択肢になります。社内ツールには条件付きで使い、生成された出力だけで本番公開できるとは考えないでください。
得意なこと
注意点
本番環境で使う機能にはこの方法を選び、重要なデータを扱う社内ツールにも採用します。プロトタイプでの全面的な実装は、必要な場合に限ります。
適している点
トレードオフ
ワークフローの名称だけでは、成果物の妥当性は保証されません。以下の限界は、人がすべてのコードを書く場合にも、生成されたコードをレビューする場合にも当てはまります。
画面は正しく見えても、エンドポイントを通じてデータが漏れたり、ユーザーが他人の記録にアクセスできたりする可能性があります。プロンプトは、サーバー側でのアクセス権限の確認に代わるものではありません。
代わりにすべきこと
各操作と記録に誰がアクセスできるかを整理し、正常なケースだけでなく、アクセスが拒否されるケースもテストします。
空の状態、不正な入力、リクエスト失敗時の復旧方法を誰も指定していなければ、人が書いたテストも生成されたテストも、それらを確認することは期待できません。
代わりにすべきこと
実装を受け入れる前に、期待する動作と失敗するケースを記述する。
整理されたファイルでも、ビジネスルールが重複したり、依存関係が隠れたり、既存のリポジトリの規約と衝突したりすることがある。
代わりにすべきこと
周辺のコードと照らし合わせて変更をレビューし、分かりにくい判断を文書化し、差分を小さく保つ。
プロトタイプでは、監視、バックアップ、アクセシビリティのレビュー、不具合への対応計画が省略されがちだ。コードを手作業で書いても、そうした不足は解消されない。
代わりにすべきこと
リリースは別個の判断として扱い、独自の確認項目と担当する保守者を定める。
Vibe Codeは、アイデアを具体的な形にして検討するのに役立つ。以下の比較では、その下書き作成の利点と、動作するシステムを検証する責任を分けて示す。
| Vibe Codeを使ったプロンプト主導の下書き作成 | 開発者主導の実装 | |
|---|---|---|
| 最初に与えるもの | 望むインターフェースや動作を説明し、生成されたものを確認する。 | 要件をコードに落とし込み、実装上の判断を直接行う。 |
| 視覚的なプロトタイプ | 主な関心が、アイデアの見た目や使い心地が適切かどうかにある場合に有用。 | プロトタイプを既存のデザインシステムやコードベースに適合させる必要がある場合に有用。 |
| 動作の変更 | 依頼内容を修正し、影響を受けるフロー全体に意図しない変更がないか確認する。 | 関連するロジックを編集し、影響を受けるフローとテストを確認する。 |
| コードの理解 | レビューを通じて深める必要がある。使える出力が得られても、その内容についての説明は得られない。 | 通常は実装中に形になりますが、ドキュメントとレビューにも依存します。 |
| セキュリティ上の責任 | 結果をレビューし、デプロイする人が負います。 | 結果を設計し、レビューし、デプロイする人が負います。 |
| 既存のリポジトリ | 現在の設計パターンや依存関係との互換性を慎重に確認する必要があります。 | 既知の設計パターンや依存関係の範囲内で、意図的に変更できます。 |
| 長期的な保守責任 | 生成後に結果をデバッグ、更新、サポートする人が必要です。 | リリース後に結果をデバッグ、更新、サポートする人が必要です。 |
実際には、どちらが優れているかを競うよりも、引き継ぐ形が有効なことがよくあります。まずドラフトでアイデアを明確にし、結果の重要性に応じて慎重なエンジニアリングを取り入れます。
選択肢 1
プロンプトを使ったドラフトから始めましょう。
レビュアーは具体例を見て意見を出せます。実際のデータとは切り離し、見た目の承認を技術的な承認と混同しないようにしてください。
選択肢 2
開発者主導の設計とレビューを中心に据えましょう。
最初のコードを誰が作成したかにかかわらず、担当する保守者はリリース前にデータの流れを説明し、障害時のケースをテストし、制御策を検証する必要があります。
選択肢 3
両方のアプローチを組み合わせましょう。
草案を意図を示すものとして残し、そのコードを確認し、リポジトリに合わせて調整し、テストを追加したうえで、リリースするかどうかを明確に決めます。
Vibe Codeを使って、内容を確認できる草案を試作しましょう。成果物を実際の製品に組み込む場合は、実装をレビューし、重要な動作をテストし、今後の変更に責任を持つ担当者を決めてください。
いいえ。プロンプト主導の作業では、望む結果を説明し、AIの支援を受けて生成されたコードを確認します。開発者主導の作業では、実装上の判断を自分で直接下します。どちらも編集、テスト、デバッグを伴うことがあり、リリースするものにはいずれも人間が責任を負います。
アーキテクチャを細かく制御する必要がある場合、既存のコードベースに統合する場合、または責任の所在を明確にしてリリースまで進める必要がある場合は、開発者主導の実装を選びましょう。権限、機密データ、ほかの人が頼りにする機能では、特に重要です。
はい。ただし、本番環境への移行には、動作するプレビューだけでは不十分です。依存関係とデータの流れを確認し、想定どおりの動作と障害時の動作をテストし、セキュリティとアクセシビリティをチェックし、アプリの保守担当者を明確にしてください。
いいえ。生成されたコードと同様に、人間が書いたコードにもバグや安全でない思い込みが含まれることがあります。品質を左右するのは、明確な要件、十分な知識に基づくレビュー、適切なテスト、継続的な保守です。
はい。たとえば、プロンプトを使ってインターフェースを試作し、その後、プロジェクトの規約に合わせて実装を修正し、リリース前にテストできます。重要なのは、AIがファイルの草案作成を手伝ったかどうかではなく、誰かが成果物を検証し、責任を持てるかどうかです。