AI駆動開発の品質問題は「プロンプト」では解決しない

株式会社ファストコーディングでフロントエンド開発と技術戦略を担当している黒田です。

最近、いろいろな会社のエンジニアやPMの方と話す機会が増えました。話題はだいたい「AI駆動開発をどう取り入れるか」なんですが、そのときに出てくる相談の多くが「品質」に関するものなんです。

うちの働くおかんも別の記事で書いていますが、AIコーディングで一番大変だったのはコーディングそのものではなく「準備」だった、と。現場の体験としてそう感じたのは正直なところだと思います。

今回は、その「なぜ」を技術者の視点で掘り下げてみます。

市場で起きている品質問題

AI駆動開発やバイブコーディングで制作されたフロントエンドについて、他社のエンジニアから聞く話をまとめると、だいたいこういう問題に集約されます。

• 隠れたバグが多い。 見た目は正しいが、特定の条件で壊れる
• 1つ修正すると別のバグが出る。 影響範囲が予測できない
• 人間が追加修正しようとすると、構造が複雑すぎて難しい。 AIが書いたコードを人間が読み解けない
• 機能に対してコードが過剰。 やりたいことに対してオーバースペックな実装になっている
• 設計方針がわからない。 なぜこの構造になっているか、誰にも説明できない

これらの問題を「AIの精度が低いから」と結論づける人が多いんですが、うちのチームの経験からすると、それは少し違います。

原因は「プロンプト」ではなく「ワークフロー」

社内で議論になったのが、「同じAIを使っているのに、なぜうちでは品質問題が出にくいのか」という点でした。

結論から言うと、AIの精度やプロンプトの巧さではなく、AIを動かす前の工程設計──つまりワークフローの有無が決定的に違っていた。

市場でAI駆動開発というとき、多くのチームが考えているのは「プロンプトエンジニアリング」なんです。いかにうまい指示をAIに出すか。いかに精度の高いコードを一発で出力させるか。

プロンプトエンジニアリングがまったく不要だとは思いません。ただ、それは必要条件であって十分条件ではない。

うちのチームでは、プロンプトよりもむしろ以下のことに工数をかけています。

1. どのAIエージェントを、どの順番で使うかを決める

AIを1つだけ使って全工程をやらせる、というやり方はしていません。制作工程と検証工程で別のエージェントを使い、それぞれの得意領域に合わせて配置します。

これは人間のチーム編成と同じ考え方です。コーダー、レビュアー、QCを同じ人がやるとチェックが甘くなる。AIでも同じことが起きます。

2. 検証工程と制作工程を完全に分離する

制作チームと検証チームを別のワークフローとして並行稼働させています。制作チームが作ったものを、まったく別のコンテキストで動いている検証チームがチェックする。

この「分離」が重要なのは、AIが自分で書いたコードのバグを見つけにくい性質を持っているからです。人間でも自分のコードのレビューは甘くなりますが、AIはさらに顕著です。

3. AIが参照する「静的な記憶場所」を設計する

制作途中で出てきた意図しない結果──たとえばこのプロジェクトではこういうパターンでバグが出やすい、といった情報を、AIが効率的に読み込める場所に体系的に格納します。うちではGitLabのWikiを使っています。

人間のチームならSlackで「あの件、こうなったよ」と共有すれば済みますが、AIはSlackを読みません。AIが参照できる形で、論理立てて情報を整理する必要がある。これが「静的な記憶場所」です。

4. 人間がチェックするマイルストーンを事前に定義する

AIに全部任せるのではなく、要所要所で人間のQCやディレクターが確認するポイントを事前に決めています。

「どこまでできたらチェックする」「何を基準にOKとする」を明確にしておくことで、問題が大きくなる前に検知できる。当たり前のように聞こえますが、AIの速度に任せて走らせてしまうと、気づいたときには手戻りが巨大になっている、ということが実際に起きます。

従来のワークフローとの違い

人間だけのチームでも、もちろんワークフローはありました。デザインが来て、コーディングして、チェックして、修正して、納品する。この大きな流れは変わりません。

ただ、従来のワークフローには暗黙知が多かった。

工程と工程の「間」──次のステップに移るタイミングや、細かい判断基準──は、ある程度「阿吽の呼吸」で回っていた部分がある。経験のあるコーダーなら「ここはこう書くよね」とわかるし、レビュアーも「ここは見なくても大丈夫」と飛ばせる。

AIにはそれができません。暗黙知をすべて明示的なルールに変換する必要がある。これがワークフロー設計の本質で、これが最も工数がかかる部分です。

なぜ品質問題がワークフロー不在に起因するのか

冒頭で挙げた5つの品質問題を、ワークフローの視点で見直してみます。

どれも「AIの精度が低い」のではなく、「AIを動かす仕組みが設計されていない」ことに原因があります。

AIの精度はもう十分

正直なところ、AIの精度はもう十分です。少なくともフロントエンドのHTML/CSSコーディングにおいては、コードの生成精度で困ることはほとんどなくなりました。

問題は精度ではなく、いかに効果的なワークフローを定義できるかにかかっている。

うちのチームでは、直近の大規模案件で工数は従来の半分、制作スピードは倍、そしてお客様からのバグ指摘はゼロという結果が出ています。これはプロンプトが上手かったからではなく、ワークフローを事前に設計していたからです。

まとめ

AI駆動開発で品質問題が起きるのは、AIの精度が低いからではありません。AIを動かすためのワークフローが設計されていないからです。

• プロンプトエンジニアリングは必要条件。ただし十分条件ではない
• 品質を決めるのはワークフロー設計──エージェントの配置、制作と検証の分離、静的記憶の整備、人間のチェックポイント定義
• 従来の暗黙知をすべて明示的なルールに変換する作業が、最も工数がかかり、最も価値がある
• AIの精度はもう十分。いかに効果的なワークフローを定義できるかが勝負

現場の体験としてこれがどう感じられたかは、働くおかんの記事が正直に書いてくれています。そちらもあわせてぜひ。

コーディングの品質管理やAI活用の制作工程設計について相談したい方は、株式会社ファストコーディングのお問い合わせフォームからお気軽にご連絡ください。