本記事は 2024/11/07 に開催されたイベント「ソフトウェア品質✕コード✕AI – AI時代のソフトウェア品質管理にどう向き合うか」の内容をもとに執筆されました。
「コード×AI ー ソフトウェア開発者のための生成AI実践入門」(以後「コードAI本」)の著者である服部佑樹と、森崎修司さん、和田卓人さん、山口鉄平さん、金子昌永さんが、AI時代の品質管理について議論しました。（以降敬称略）
本記事は3部構成のうちの中編となります。
AI × 品質管理：プロセス変革へのリアルな視点
服部:
「AIによって開発プロセスは劇的に変わるのか?」この問いに対して、多くのエンジニアが頭を悩ませています。生成AIツールが企業に導入され始めた今、開発現場でも大きな変革の波が押し寄せています。しかし、その実態はどうなのでしょうか。 特に品質管理のプロセスについて、AIをどう活用できるのか、皆さんの見解を伺いたいと思います。
森崎:
そうですね、品質管理のプロセスにAIがどう役立つか。それをふまえて、もし何か変える、改善するポイントがあるとしたらどこかということになりそうですね。
人手でやっている部分を肩代わりさせることで、スピードアップや作業コスト（工数）が減る、というのはまず考えられますよね。得意・不得意がはっきりしてくると、このプロセスは入れ替えた方がいいとか、まとめてやった方がいいとか、そういう再構成のアイデアが出てくる可能性はあります。
ただ現状では、AIに完全に信用できる結果を出させるのはまだ頼りない印象です。だから今の人手によるプロセスをそのまま踏襲し続ける部分は多く、なかなか変わりにくいと思っています。
また、生成AIの結果をノーチェックで使うのは非常にリスキーです。チェックサムのような簡易チェックでも良いのですが、何らかのチェックが必要だと思います。「任せっきりで、気づいたらおかしな成果物ができていた」では困ります。生成AIの出力結果をチェックせずに、そのまま開発が進んでいないか、どこかで振り返る必要がある。そういう意味でプロセスが変わるというよりは、チェックプロセスが追加される感覚ですね。
結局、生成AIを使ったら、チェックばかり増えて人手でやるより遅くなった、みたいなことにならないか。それが短期的な視点かと思います。
長期的には、性能が上がってくればプロセス全体の再構築の話も出てくるかもしれません。最近の生成AIのモデルのアップデートのたびに性能向上を実感しますし、将来的には「全体的にプロセスを変えた方がいい」という議論が出てくる可能性はあると思います。
AIコードレビューへの挑戦とその限界
服部:
結局、AIの書いたコードのレビューをしていると、「自分で書いた方が早かったんじゃないか」問題が起こりますよね。
GitHub Copilotも最近レビュー機能を出したり、CodeRabbitのようなレビュー特化のAIツールもあります。ただ、コードレビューに関しては様々な観点があって、意図を組み込むのは難しいと感じます。
和田:
開発プロセスとの関係ですよね。品質管理プロセスの中で、例えばテストケースが欠落していないかなど、AIをピアとしてダブルチェックさせる形は考えられます。
ただ、もっと前工程、要件定義やお客様とのやりとりをサマライズしたり、仕様をツリー状に落として無矛盾性をチェックしたりする部分の方が、AIの影響は大きいかもしれません。
またマネジメント面もあります。プロジェクトマネジメントをAIに任せることで、人間よりスケーラブルに管理できる、という動きがアメリカでは出てきています。
コードレベルではあまり変わらないかもしれませんが、全体最適を考えると、今後大きく変わってくる可能性はあります。
服部:
ありがとうございます。
コードレベルに関しては、私もコードAI本で「レビューをしやすい形に落とし込み、人間が意思決定しやすくする補助としてAIを使う」といったことを書きました。AIは判断はできないので、判断支援としての位置づけですね。
要件定義や前段階のところでは、AI活用への期待や議題が多いのは確かです。マネジメントの領域でも今後広がる余地があるかもしれません。
森崎:
補足させていただくと、コードコメント生成などは生成AIが得意とするところです。レビュー用コメントは人間が素早くチェックしやすいですし、人間が1から考えるよりサッと出せる。
また、テストコードが整備されているプロダクトコードであれば、長く研究されている自動修正の手法も流用できそうです。「自動修正してみたけど、どうですか？」と提案して、人間が「OK」とマージするプロセスも成立しますよね。
実行トレースを与えると、ソースコードだけを与えるより良い理解が得られ、コードコメント生成も精度が上がるという研究もあります。
逆に、ざっと仕様を書いて大量のコードを生成させると、チェックが大変で人間が「チェックマシン」にならざるを得ない。この点、逐次補完でインタラクティブに進めるのは生成AIの活用として適切だけれど、一括生成は人間の負荷が大きい印象です。
服部:
コメントにも「ハルシネーション（幻覚出力）」が指摘されていますが、確かに明らかに間違ったものはわかりやすいけれど、「より良い」かどうかの判断は難しい。結局トレースしなきゃいけないので手間がかかる。
コードレビューにおいて、プロンプト設計をするなら、どんな点に留意すべきでしょうか。
森崎:
繰り返しになってしまいますが、レビュー対象を絞り、分量を適度に調整することが大切だと思います。典型的なコード（学習データに大量にあるようなコード）であればAIレビューはそこそこ上手くいく印象ですが、特殊なコードになるとスルーされたり、的外れな指摘をすることがあります。
テストコードがあると「このテストが失敗するからここが間違い」と根拠を示せるため、理由とともに問題点を指摘するようなプロンプトが有効かもしれません。
また、「この部分とこの部分を付き合わせて、矛盾がないかチェックしてください」といった、読み方の前提を示す方法もあります。そうすると、AIはその方針に沿って問題を指摘してくれます。
和田:
レビューでは「言っていること」と「やっていること」が整合しているかが重要です。意図は人間が示すとして、コードやコメント、処理内容が一致しているかをAIにチェックさせるわけですね。
AIも、人間も、ノイズに騙されることはありますが、ダブルチェックしながら進めていくようなアプローチが有効かもしれません。
AI時代のコードレビュー：マインドセットと組織カルチャー再考
服部:
ここからはマインドセット的な話になります。
社内でのコードレビューやレビューイー・レビューアーの関係、AI時代には何か変わるのでしょうか？
「AI時代、こういうことを考えた方がいい」という点があれば、山口さん、金子さん、いかがでしょうか。
山口:
社内でもCopilotを使ってコードを書く人は増えています。
ただ、生成されたコードは、意図がコードから読み取りづらい場合が多いんです。人間がコードを書かず、AI任せだと「なぜこうなったの？」と、後から開発者に聞く場面が増えています。
正直、それはあまり良いことではないと思います。開発者がコードの意図を明確に把握していない状態は、コピペしたコードと同じようなレベルですよね。それは内在的品質を保つ上で望ましくない。
服部:
中にはコードをよく読まずに「LGTM」（問題なさそう）と言って承認する人もいるでしょう。これはどう対処すべきでしょうか。
山口:
それは難しい問題です。コードの内部品質や保守性を重視する文化が欠けている組織状態かもしれません。
コードは中長期的なドキュメントでもあるわけで、そういった状況を見かけたら、レビュー時に「本当に大丈夫？」と問いかける必要があります。
金子:
レビューアーとしては、AIに助けられてコードを書いている人が、AIがなくても書ける人なのか、それともAI頼みでコードベースを理解していないジュニアレベルなのか、意識せざるを得ない時代になってきたと思います。
AIがいないと一定のアウトプットが出せない人がチームにいる場合、その人が自力では使えなさそうな文法やライブラリに着目した教育的なサポートが有効でしょう。
さらに、AIに助けられて出したコードでも、自分が責任を持つべきだという意識が必要です。
AI生成テスト活用術：攻めと守りのバランス
服部:
次に、AIの利用用途として大きな期待がある「テスト生成」について伺いたいです。
「AIにテストを書かせたらゴミテストが量産された」「メンテナンス性に乏しいテストができた」などの声もあります。
プロセスや考え方として、どうやってAIにテストを書かせたらよいのでしょうか？何か考えやアイデアがあればお願いします。
森崎:
正常系テストでランダムな入力データを与えて生成させる、などはわりと得意です。
また、ディシジョンテーブルのようなテスト用の元情報を準備して、それに対応するテストを書かせると上手くいく可能性があります。
和田:
人間と同じで、AIは最初に与えた「良いテストコード」を手本にします。最初に良い例がないと、悪いパターンを量産します。
テストはソフトウェア変更の容易性を支えるため、テストコード自身も保守性が必要です。コピペ量産では変更容易性が失われます。
つまり、AIに全部任せて「それでヨシ」とせず、人間が意図的にテスト設計し、不要なものは枝刈りして、パラメタライズするなどメンテを考える必要がある。
昔、オフショアにテストコードを書かせて大量納品させたら、仕様変更でテストが全滅するような事態を経験したことがありますが、同じことがAIにも起こり得るんですよね。
山口:
和田さんがおっしゃる通りで、AIアシストは有効ですが、AIにテストを全部書かせる戦略はあまり良い方向ではないと思います。 むしろ、プロダクトコードをAIで補完し、人間はテストコードでしっかり意図を固めるとか、テストをアシスト程度に留める方がいいのではないかと考えています。
金子:
ユニットテストレベルなら、人間が先に正解を示す形でテストを書く方が妥当だと思います。
しかし、入出力が曖昧でテストコードもない古いプロダクトコードに対しては、AIでテストを叩き台として生成し、それを元に入出力整理をする、といった使い方はあり得るかもしれません。
ただ、統合テストレベルで、ユーザーマニュアルを元に大規模なテストコードを書くといったタスクはまだ厳しい。
入出力がはっきりしないところをAIに叩かせて見当をつける、そこから人間が設計を検討する、といった段階的活用が現実的でしょう。
服部:
「正解を決めるのが人間」という言葉は分かりやすいですね。
森崎:
「こういうバグを見つけられるようなテストを書いてください」とか、ワンショットのテスト生成は比較的やりやすいです。
現時点ではコードの脆弱性検出に関する論文は多く、実績が多い領域です。
ただ、長期的なメンテナンスが必要なテストを書くとなると一気に難易度が上がります。
コーナーケース発見用の一発テストはAIで生成、保守性の要るテストは人間が書く、といった使い分けが良いのではないでしょうか。
服部:
GitHub Copilotもセキュリティ系のレビューに注力していますが、学術的にもその領域はホットなんですね。納得できました。
森崎:
ソフトウェアエンジニアリングでの生成AI系の論文でも特に多いのは、脆弱性のあるコードを生成する、または検出する、といったテーマですね。
和田:
脆弱性のあるコードが学習データ上に多く存在するため、ジュニアエンジニアがAIでコードを生成すると脆弱性も一緒にコミットされてしまいます。
よって、脆弱性検知とセットで使わないと危険です。
攻撃的な手法（悪意あるプロンプトなど）で脆弱性を混入させる研究もあり、イタチごっこが始まっている感じですね。
服部:
GitHubのAdvanced Securityでは静的解析的なチェックや、AIを用いたCICDでの防御機能を用意していますが、やはり後段階で防ぐ流れが現実的なんでしょうね。
AIとの協働について書いたコードAI本は好評発売中。
対談の皆様の著書や翻訳書もぜひご一読ください！
