SNSや記事で「AIの品質が低い」「レビューが甘い」という話をよく見かけます。自分もそう感じる場面はあります。ただ、議論を追っていると、みんなが言っている「品質」の中身がバラバラだと感じることが増えました。
コードの良し悪しの話なのか、要件との整合の話なのか、業務ドメインの正しさの話なのか。指しているものが違うのに、同じ「品質」という言葉で殴り合っているようにも見えます。
この記事は、そんなモヤモヤを整理したメモをベースに、個人的な考えを書いたものです。正解があるわけではなく、「自分はこう捉えている」という記録に近いです。
自動車の一般化と、原理を知らなくてよい時代
早い馬から、早い乗り物が生まれ、やがて自動車が一般化した、という流れがあります。いまのAIも、似た段階に入りつつあるのではないか、と感じています。
一般の人にとって、車がどういう原理で動いているかは、知らなくてよい。エンジンやトランスミッションの仕組みを説明できなくても、運転して目的地に着ければよい。AIも同じで、中身のモデル構造やプロンプトの設計を理解しなくても、「使えばなんとかなる」領域が広がっています。
ただ、理解しなくてよいと言い切れるわけではありません。難しいラインはあります。「こういう層がある」「ここを変えるとどこまで影響するか」といった全体像は、知らないまま使うのは危ない、という印象です。
大事なのは、なぜこう動くのかの細部より、目的がこうだからこういう形になっている、という全体理解だと感じています。技術的な組み合わせはAIに任せられやすい時代になった。それでも問うべきは、その形が本当にやりたいことに合っているか、という点です。
一方で、知識の差は消えません。車に詳しい人なら「それ、エンジンオイル替えれば直るよ」と言えます。AIでも、出力がおかしいときに「ここを直せば動く」と言えるかどうかで、体験は大きく変わります。
原理や原則、いわゆるナレッジで支えられてきた仕事の一部は、一般には不要になっていく方向にあります。ただ、「使える」と「直せる」のあいだには、これからも溝が残ります。そこが、専門性の残り方の話です。
「品質」は、最初に揃える話
「AIの品質」について議論が出るたびに気づくのは、品質の見る先は領域によって違う、ということです。
あるチームはコードの可読性を品質の中心に置きます。別のチームは障害時の復旧時間を重視します。業務システムならドメインルールの正しさが本体で、toC向けのプロダクトなら体験の一貫性が品質になります。同じ「品質」という言葉でも、指しているものが違います。
そのうえで大事なのは、要件の足並みが揃っていることだと感じています。何を作るのか、何を満たせばよいのかが曖昧なまま、「コードの良し悪し」だけを議論しても、テコ入れになりやすいです。
品質の話をする前に、チームで「どこを品質と呼ぶか」を握っておきます。完了の定義（Definition of Done）、レビュー基準、Skillsのような共有の型でもよい。手段は問いませんが、合意が先です。
だから「品質が低い」と一言で問題化するのは、少し早いのではないか、というのが自分の立場です。まず聞きたいのは、「いま、何を品質と定義しているのか」という問いになります。
「中身の議論」は、すでに終わった領域もある
コードの中身がどうこう、という話は、すでに終わった領域もある、という感覚もあります。
生成系のUIや定型的なCRUDでは、AIが書いたコードを人が細かくレビューするコストと、出す速度のバランスが変わってきています。デザインがその領域に入れるかどうかも、業種やプロダクト次第です。
よくあるデータベースの組み合わせなら、パフォーマンスへの影響は、AIの方が人間より精度高く設計・実装してしまうこともあります。そこで人が見るべきなのは、なぜこう動くのかの細部より、業務ドメインにその構成がフィットしているか、という点だと感じています。
逆に、業務ドメインが重い領域では「何を品質とするか」がまったく違います。会計、医療、製造の現場ルールなど、ドメイン知識そのものが品質の本体になります。AIが入りづらい環境も、まだ多いです。
一概に「AIで品質が上がった／下がった」とは言えません。領域によって、品質の定義も、AIの効き方も違います。だから「品質」という言葉は、かなり広いです。狭く使わないと、議論がすれ違います。
職人気質のエンジニアは、もう希少品か
ここからは、もう少し個人的な話になります。
昔ながら、設計してから実装し、品質を意識して積み上げるタイプのエンジニアがいます。自分の頭の中では職人気質と呼んでいます。丁寧に設計し、品質に妥協しない人のことです。
いまは、経験値を凌駕するほどの出力をAIが返してくれます。だから、コードの良し悪しを正当に指摘できる人は、相当なレベルが要るのではないか、と感じます。
そういう人がチームに一人いれば十分、という時代がありました。いまは、その人が希少品になりつつあるのではないか、という感覚があります。
自虐的に言えば、自分はIQ低めのエンジニアです。AIの出力を見て「ここはダメだ」と言い切れるほどの判断力は、正直、いつもあるわけではありません。経験だけでは足りません。何を品質とするかを決め、AIの結果を評価する。その役割の方が、重くなっている気がします。
残るのは「何を品質とするか」を決める力
まとめると、こんな整理になります。
- AIは自動車のように一般化し、原理を知らなくても使える層が広がる
- それでも「直せるか」の差は残る
- 「品質」は領域・チーム・業務ドメインで定義が違う
- コードの良し悪しより先に、何を品質と呼ぶかの合意が必要
- 職人気質の実力者ほど、AIの出力を評価する責務が重くなる
「AIの品質が低い」と言うとき、自分はまず何を品質と呼んでいるのかを確認したい。そこが揃っていない議論は、打ち合わせの前に地図を共有していない状態に近いです。
品質問題として語る前に、品質の定義を揃えます。当たり前のようで、いまいちばん手間がかかるポイントにあります。