私たちはAIを使ってコードを書いています。それも、かなり全面的に。それでもお客様に自信を持ってシステムを納められるのは、「AIに書かせる」と「品質を確認する」を切り離さずに運用しているからです。この記事では、私たちがAI開発で実際にやっていること、やらないと決めていることを書きます。
バイブコーディングという言葉
「vibe coding（バイブコーディング）」という言葉があります。AIにざっくり指示を出し、生成されたコードを読まずに動かしてみて、エラーが出たらまたAIに投げる——中身を理解しないまま「雰囲気」で開発を進めるスタイルのことです。
誤解のないように言うと、これ自体が悪いわけではありません。使い捨てのプロトタイプや個人ツールなら、むしろ合理的なやり方です。動けば目的を果たすものに、コードの美しさは要りません。
問題は、顧客の業務を支えるシステムをこのやり方で作ってしまうことです。誰も中身を理解していないコードは、障害が起きたときに誰も直せません。セキュリティホールが混ざっていても気づけません。半年後に仕様変更が来たとき、どこを触ればいいか誰にもわからない。バイブコーディングで作られたシステムは、納品された瞬間から技術的負債です。
私たちのやり方：小さく書かせて、すべて読む
私たちがAIを使うときの原則はシンプルです。AIに書かせる単位を小さく保ち、生成されたコードはすべて人が読んで理解する。 具体的にはこうしています。
関数単位・モジュール単位で書かせる。 「このアプリ作って」とAIに丸投げはしません。設計——どんなデータ構造で、どう責務を分割するか——は人間が決めます。そのうえで「この入力からこの出力を返す関数」という粒度でAIに書かせます。単位が小さければ、生成されたコードの正しさは人間が判断できます。逆に単位が大きくなるほど、確認は「なんとなく動いてそう」に退化していきます。
枯れたデザインパターンに沿って書かせる。 設計で奇抜さは狙いません。実績のあるデザインパターンと、そのプロジェクトの既存コードの書き方に揃えてAIに書かせます。AIは自由にさせると同じ処理でも毎回違う書き方をしてきますが、パターンを指定すれば出力は予測可能になり、レビューは「パターンから外れていないか」の確認に集中できます。コードベース全体が同じ形に揃っていることは、それ自体が保守性であり品質です。
説明できないコードはコミットしない。 生成されたコードは必ず読み、なぜそう書かれているかを理解してから取り込みます。「AIがこう書いたので」は私たちのチームでは理由になりません。お客様に「この処理はなぜこうなっているんですか」と聞かれて答えられないコードを、お客様のシステムに入れるわけにはいかないからです。
型とテストで機械的に検証する。 人間のレビューは思い込みで漏れます。だからTypeScriptの厳格な型チェック、自動テストといった機械的な検証を通します。AIが書いたコードもAIを使わず書いたコードも、同じ基準で同じパイプラインを通る。出どころで検証を緩めることはしません。
確認にもAIを使う。 AIは書くだけの道具ではありません。テストケースの洗い出し、エッジケースの指摘、コードレビューの一次チェック。人間が見落としやすい部分をAIに探させ、最終判断は人間がする。書く速度だけ上げて確認が追いつかなくなるのが一番危ないので、確認側も同じだけ加速させます。
速さと品質はトレードオフではなくなった
「AIで速く作る」と「品質を確保する」は、よく対立するもののように語られます。しかし実際にやってみると、この2つは両立します。むしろAIを正しく使うと両方が上がります。
実装が速いから、テストを書く時間が確保できる。プロトタイプを早く現場に当てられるから、作り込む前に方向の間違いに気づける。レビューにAIが入るから、人間は設計判断のような高次の確認に集中できる。速さは品質を削って得るものではなく、品質を確認する余裕を生むものになりました。
使い分けもします。要件を探るためのプロトタイプ段階では、スピードを最優先にして荒く作ることもあります。ただしそれは「これは検証用で、本番ではこの部分を作り直す」と顧客と合意したうえでの話です。プロトタイプの荒さが、なし崩しに本番コードに紛れ込むことを許さない。ここの線引きが、AI時代の開発の規律だと考えています。
まとめ
AIはコードを書きますが、責任は取りません。責任を持つのは人間です。私たちのAI開発は「AIに任せて楽をする」ためのものではなく、設計と検証という人間がやるべき仕事に集中するために、書く作業をAIに任せるという分業です。
AIを使った開発に興味はあるが品質が不安、という方こそお話ししたいです。お問い合わせからお気軽にどうぞ。