こんにちは。
前回の記事で、「若手エンジニアは、生成AIの出力を判断する基準を持てずに苦しんでいる」という話を書きました。
正直に告白すると、これは他人事ではありません。
私自身、生成AIを使ったシステム開発において、いまだに「これだ」という判断基準を確立できていないのです。２０年以上この仕事をやってきて、なお試行錯誤の真っ最中です。
なので、先に言っておきます。この記事に、明確な結論はありません。
代わりにお伝えしたいのは、２０年選手のエンジニアが、生成AIの出力とどう向き合い、どこで迷い続けているか、その現在進行形の記録です。
なぜ「見極め」が一律の基準にならないのか
生成AIが書き出すコードは、同じ機能を頼んでも、プロンプトの書き方ひとつで全く違うものになります。
さらに厄介なのは、プロンプトが同じだったとしても、生成AIをどれだけ使い込んでいるかによって、出てくるコードの質が変わってくることです。使い込んでいくうちに、モデル側がそのやり取りに合わせて学習していくため、あまり使っていない人との間に、じわじわと差が生まれてしまうのです。
加えて、プログラマ本人の仕様への理解度も人それぞれです。これは人間である以上、当たり前のことです。
つまり、「プロンプト」「AIの使い込み度合い」「仕様の理解度」という３つの変数が絡み合った結果、同じ機能を作っているはずなのに、出てくるコードは毎回まったく別物になるわけです。
こうなってくると、「これさえ見れば大丈夫」という一律のチェックリストは、そもそも成立しません。だったら、いっそ基準そのものを明文化してしまえばいいのでは——私も、生成AIを使い始めた頃はそう考えて、試行錯誤していました。判断基準をスキルファイルとして明文化し、AIに渡す形にしてみたのです。
しかし、基準を盛り込めば盛り込むほどスキルファイルは肥大化し、コードを生成させようとしてもトークンを消費するだけで、肝心の精度は上がらないという結果に終わりました。
こうして、「一律の基準を作る」という発想そのものを一度手放すことになったのですが、それでも現場では毎日何かを判断し続けなければなりません。そこで、基準というより**「今のところ効いている感覚」**として、いくつか持っている判断軸があります。次はそれを紹介します。
現時点で「効いている」と感じるチェックポイント
そんな試行錯誤の末に、今の時点で「これはわりと効いている」と感じているポイントが３つあります。
１つ目は、頭の中にあるロジックを、プロンプトにそのまま書き出すと、ある程度思った通りのコードが生成されるということです。
ただし、これには条件があります。要求定義から詳細設計まで、自分の頭の中できちんと詰め切れている場合に限られます。逆に、曖昧な処理が残ったままプロンプトを書くと、思ってもみないコードが出てきます。つまり、プロンプトを書く側が、詳細設計まで考え切る責任を負うということです。
２つ目は、正常系はAIに任せて大丈夫だが、異常系は必ず確認が必要ということです。
先ほどの「詳細設計まで詰め切る」ほど厳密でなくても、つまり基本設計止まりの状態でも、正常系のコード生成だけならAIに任せられることがあります。うまくいくときと、いかないときがあるのですが、うまくいったときは、正常系の処理はそのまま使えるレベルのコードになります。ただし、異常系は別です。ここは必ず見直しが必要になります。
言い換えると、設計をどこまで詰めたかによって、AIに任せられる範囲が変わってくるということです。詳細設計まで詰めれば異常系も含めて精度が上がりますし、基本設計止まりなら正常系だけは使える、という具合の、いわばグラデーションです。
３つ目は、既存コードの修正やバグ対応は、AIを使うとかなり楽になるということです。
既存のコードがベースにあるぶん、生成されるコードも既存の作りに沿ったものになりやすく、時には自分でも気づいていなかったバグを見つけてくれることさえあります。
特に効果を感じるのは、エラーログをそのままAIに読ませたときです。的確な対応をしてくれる確率がぐっと上がります。
ただし、ここにも注意点があります。修正されたコードに異常系の処理が含まれている場合は、必ず確認してください。生成AIは、どうやら異常系の対応が根本的に苦手なようです。 下手をすると、あらゆるケースを一律に例外処理として片付けてしまうことがあります。ここだけは、油断せずに毎回目を通すようにしています。
まだ迷っている・答えが出ていないこと
実装コードについては、ここまで書いてきたように、ある程度「効いている感覚」を言葉にできるようになってきました。ところが、テストの話になると、とたんに手探りに戻ります。具体的には、ユニットテストと結合テストの２つです。
正確に言うと、「答えが出ていない」というよりも、課題は見えているのに、解決策にまだ辿り着けていないという状態です。
システム開発において、ユニットテストや結合テストは、品質を担保するための重要な工程です。生成AIに「ユニットテストのコードを作って」と頼めば、確かに何かしらのテストコードは出てきます。しかし、生成されたテストが、本来テストすべき条件を網羅できていないことがあるのです。
本来ユニットテストは、正常系・異常系・境界値・組み合わせといった観点で、ロジックに沿ってテストするべきものです。ところが、生成AIが作るテストは、正常系と異常系だけでほぼ終わってしまうことが多く、境界値や組み合わせのケースが抜け落ちがちです。
次に、結合テストです。結合テストは、ブラウザからの入力を起点に、処理が行われ、結果がブラウザに出力されるまでを確認する工程です。
生成AIに結合テストを実行させると、OK/NGという判定は返ってきます。しかし、本当に見たい表示結果になっているかまでは確認できていないのです。ブラウザのエビデンス（スクリーンショット）を取得すればよいのでしょうが、判断に必要なタイミングでのエビデンスがうまく取れていないことが多々あります。
さらに厄介なのは、最終的にシステムを使うのは人間だということです。人は、こちらが想定していない動き方をします。この「想定外の使い方」を織り込んだ結合テストのシナリオ作成が、どうも生成AIは苦手なようです。
つまり、問題の輪郭ははっきり見えているのに、「じゃあどうすればいいか」の答えには、まだ手が届いていません。
失敗談・ヒヤリとした事例
ここで、実際に「疑わずに痛い目を見た」事例を紹介します。
一度、こんなことがありました。プロンプトに製造したい機能の詳細な要件と設計をきちんと書き、製造とユニットテストまでをAIに行わせたのです。生成されたプログラムを確認しても、特に問題なく作成されているように見えたので、実際に動かして確認しました。
すると、依頼した機能自体は正常に動いていました。ところが、まったく別の機能が、いつの間にか壊れていたのです。
厄介なのは、この壊れ方に「気づきやすさの差」があることです。**影響範囲が近い、周辺機能であれば、リリース前のテストで気づくことができます。**しかし、直接関係のない、離れた機能で不具合が起きた場合は、気づくこと自体が難しくなります。
さらに言うと、こちらが想定もしていない箇所で、関連するデータを参照している——といったことも珍しくありません。こうした見えない依存関係が、思わぬ不具合につながることが、実際にありました。
この経験から、動作確認には十分な時間をかけて確認するようになりました。また、データを編集する場合は、先に参照箇所を調査するようになりました。生成AIがどれだけ速くコードを出してくれても、確認と調査にかける時間だけは、削ってはいけないと痛感した出来事です。
結局、何を拠り所にしているか
結局のところ、私が拠り所にしているのは、自分の知識と、これまでの経験です。
これまでの経験を通じて、要件定義から詳細設計が、システム開発でいちばん重要だということを学んできました。生成AIが登場する前は、この工程に十分な時間をかけ、お客様の作業が少しでも楽になるように、システムを作ってきました。
生成AIが登場してからは、設計も含めてすべてをAIに任せる「バイブコーディング」が流行り始め、正直なところ、自分の仕事もAIに奪われていくのではないかと心配していました。
でも、実際に使ってみて感じたのは、これまでに積み上げた知識や経験は、まだまだ使えるということです。
ここまで書いてきた「異常系は必ず疑う」「データを変更する前に参照箇所を調べる」といった判断軸も、突き詰めれば、過去の経験から来ているものばかりです。タイトルの問い「どこまで信じていいのか」に、今の私が出せる答えがあるとすれば、「自分の経験と照らし合わせて、納得できる部分のみを信じる」ということになります。
もちろん、製造からテストにかけては、生成AIのおかげで、生産性が思った以上に上がっています。
将来、生成AIがさらに発展して、もっと簡単にシステム開発ができるようになれば、私たちの仕事は淘汰される運命にあるのかもしれません。
しかし、今は、自分の知識とこれまでの経験を拠り所にして生成AIを使うことで、生産性をより一層高められると考えています。
ただ、ここには大きな課題が残っています。 私には、これまでの知識と経験があります。では、経験の浅い人は、何を拠り所にすればいいのでしょうか。正直なところ、その答えまでは、まだ考えが至っていません。
まとめ
ここまで、生成AIの出力とどう向き合っているかを、迷っている部分も含めて書いてきました。
改めてお伝えすると、私はまだ模索の途中です。「これさえやれば大丈夫」という基準は、２０年この仕事をしていても、見つかっていません。実装コードについては「効いている感覚」がいくつか持てるようになってきた一方で、テストについては、課題は見えていても、答えには辿り着けていません。
だからこそ、みなさんにお聞きしたいのです。
みなさんは、生成AIの出力を、どう判断していますか？
「こういう基準を使っている」「ここで痛い目を見た」「うちではこうしている」など、どんなことでも構いません。コメントで教えていただけると嬉しいです。
特に、先ほど書いた「経験の浅い人は、何を拠り所にすればいいのか」という問いには、ぜひみなさんの知恵をお借りしたいと思っています。
次回は、「自分の技術的判断力を測る方法」について考えてみたいと思います。
コメント