本記事は 2024/11/07 に開催されたイベント「ソフトウェア品質✕コード✕AI – AI時代のソフトウェア品質管理にどう向き合うか」の内容をもとに執筆されました。
「コード×AI ー ソフトウェア開発者のための生成AI実践入門」(以後「コードAI本」)の著者である服部佑樹と、森崎修司さん、和田卓人さん、山口鉄平さん、金子昌永さんが、AI時代の品質管理について議論しました。（以後敬称略）
本記事は3部構成のうちの前編となります。
AI時代のソフトウェア：「AIに優しいコード」とは何か？
服部：
まず和田さんにお伺いしたいんですけれど、良いコードって何ですかね。ざっくりとしたところからのスタートで恐縮なんですけれども。
和田：
AI時代の良いソフトウェアって、実はAI時代じゃないときの良いソフトウェアとあまり変わらないんですよね、結論から言うと。
結局、解析性や理解容易性が高くて、修正性・変更容易性が高くて、モジュール化されている、といった点は同じです。AIが扱うのが得意なソフトウェアは、人間にとっても優しいコードなんです。人間にとって優しいコードやソフトウェアが、AIにとっても優しい。結局、あまり変わらないという感じですね。
服部：
ちょうど森崎さんにもお聞きしたいんですけれど、AI時代の良いソフトウェアってどうですかね？
森崎：
和田さんの後に話すのはちょっと緊張しますが（笑）。
あまり変わらないというのは僕も賛成です。リーダビリティとかメンテナビリティって、今まで人間視点で「可読性」や「保守しやすさ」と言っていました。でも「AIリーダブル」なコードみたいな概念が、これから出てくるんじゃないかなと思うんですよね。 僕もいろいろ試しているんですけど、例えば名前の付け方によってAIが混乱することがあります。本来の用途と全然違う変数名を付けたコードだと、簡単なソートのプログラムを読ませてもトンチンカンな回答を生成AIが返すことがあって。コードがある程度モジュール分割されていれば大丈夫なんだけど、それが雑に混ざっていると、変な解釈をするケースがあります。 もう一つ付け加えると、学習データに含まれていそうな「典型的なコード」であれば、割と良い結果を生みやすいんですよね。特殊な書き方をすると、学習データにその並びがなくて、不適切な出力をすることもあるようです。
服部：
なるほど、ありがとうございます。確かに今後は「AIリーダブルなコード」っていう観点で見ると、コードだけでなくフレームワークやその周辺も変わるかもしれないですよね。
森崎：
そう思います。例えばダイアグラムも、できればAIが解釈しやすい形で表現する。UMLの図とかも、マルチモーダル対応の生成AIであってもビットマップだと厳しいので、Mermaidのようなテキストベースの記述にしてAIにも扱いやすいようにする。そういう点は大事かなと思います。
和田：
そうですね。テキスト表現になっていることや、コード自体が「ローコンテクスト」な形で書かれていることが重要かもしれません。つまり、背後にある人間の暗黙知をあまり前提としない、情報量が多めでも「読んだら分かる」コードになっているほうが、AIにとっても読みやすい。初見の人間に優しいコードは、AIにとっても読みやすいコードという感覚ですね。
これまでは「コードを読めば分かるコードにはコメントはいらない」と言われてきましたが、コメントの有無でAIの読みやすさが結構変わる感触があります。その辺のバランスや可読性・理解容易性への配慮は、これからシーソーのように傾くのではと予想しています。
森崎：
今の和田さんの話で思い出したんですけど、コードに実行履歴やプロファイラの出力結果をつけてそれを生成AIに読ませると、つけないときよりも正しくコードを理解できる、というような研究もありました。
僕ら人間がいきなりプロファイラの結果を渡されても「うーん」となるんですが、生成AIだとそれをうまく活用してくれる場合もある。与える情報を適切に増やすことで、可読性や理解が向上しそうですね。
服部：
ゼロショットで処理できる情報量、つまりフロントエンドのフレームワークでBootstrapが使われているとか、そういう「AIが知っている」という前提があることで、AIが楽になるケースはありそうですね。
この前のGitHub Universeで「GitHub Spark」という、自然言語だけでアプリが生成できるサービスのプロトタイプが発表されました。実際触ってみると、使えるフレームワークや機能に制約をもたらすことで、逆に安定して色々と創造性を膨らませられるようになっているんです。今後そういった「ガード付きフレームワーク」が増えるんじゃないかなと思いました。
新たな品質指標の可能性：AIから見たわかりやすいコード
服部：
良いコードを作るとき、「じゃあ何が良いコードなのか？」って抽象的ですよね。変更容易性などの指標がありますが、新しい品質指標はあり得るんでしょうか？ それとも既存の指標で十分なんでしょうか？
森崎：
外部品質、つまりユーザが感じる品質はそんなに変わらないと思います。
内部品質、例えば拡張性や可読性など、そういったところは考慮しなきゃいけない要素が増えるかもしれないです。これまではサイクロマティック複雑度とか条件分岐の多さなど、人間が追いかけられた指標があった。でも生成AIだと、どこかで追いかけるのをやめちゃう可能性がある。
あるいはCI/CDパイプラインに、生成AIを組み込んで「このコードはAI的に可読性が高いか？」といったチェックを入れることも必要かもしれません。
和田：
僕もそこは期待してます。これまでの内部品質の指標は本当に機械的なものばかりでした。サイクロマティック複雑度とかメンテナビリティインデックスとか、構造的な側面しか測れなかった。
意味のわかりやすさや名前付けの妥当性といった「認知的な側面」は、定量化が難しくて人間のレビュー頼みだったんですが、今後はAIでそういう認知的側面の評価もある程度自動化できる可能性がある。
数年後には、名前がわかりやすいか、一貫性があるか、といった評価をAIで行えるようになるかもしれません。
森崎：
そうですね、人によって「わかりやすさ」が変わるのが、AIだとある程度安定して評価できるかもしれない。読みやすさは今まで主観的だったけど、ちょっと客観視できるようになる可能性があります。
この前試したとき、生成AIに「このコードは人が書いたものか、生成AIが書いたものか？」と聞いたら、「生成AIが書いたものですね、なぜなら○○」と理由づけてくれたりして、意外と特徴をつかんでいるんですよ。
今までは「この人はこうだから」みたいな人間特有のバイアスがあったけど、AIの視点を使えばそれを分離できる仕組みが作れるかもしれない、と思っています。
和田：
最終的には、解析性や理解容易性って人間のためのものですが、今後はコードを読むのは人間だけではなく、AIも読むことを前提にできる。
AIが読みにくいと判断すれば、第三者的な「悪者」をAIに担わせて「AIが読みにくいって言ってるから直そう」というふうにチームで品質底上げが図れるかもしれないですね。
今までもlintツールやstatic analysisツールを「悪者」にすることで品質を底上げする流れがあったけれど、今度は認知的側面にもそれを適用できるかもしれない。面白い時代になってきたと思います。
服部：
GitHub Copilotも、最初は文字列類似度メインでしたが、今はCopilot Editなど（検索ベースですが）ある程度依存関係を見てコードを直そうとしたり、解析と生成を組み合わせる方向に進化していますよね。
今後は検索＋生成だけでなく、コード解析＋生成という形が増えて、「AIに優しいコード」がさらに明確な価値を持つようになるかもしれませんね。
品質維持と進化：AI時代における実務へのインパクト
服部：
ではここからもう少し実務的な視点に移りたいと思います。 実務でAIを使う際、楽になる領域・ならない領域、注意が必要な部分はありますか？
山口：
和田さんもおっしゃっていましたが、実はそんなに大きくは変わらないと思っています。AIは道具で、ブーストをかけるもの。
簡単なことはより簡単になるし、難しいことはそう簡単には楽にならない。ハルシネーションはもちろん気をつけなければなりませんが、従来できなかったことが突然すごく簡単になる、というよりは、あくまで補助的な位置づけかなと。
特に注意点としては、分からなくてもAIが「とりあえず動くもの」を生成できてしまう点です。従来は書けなければ何も出てこなかったけど、今は何か出てきてしまう。そこをきちんとコントロールする必要はあると思います。
金子：
コードそのものと、それ以外のところで分けて考える必要があると思います。
コード面では、従来の静的解析ツールが担っていた領域はAIがある程度カバーできるでしょう。メモリリークやヌルポインタ参照の検出、古い文法やライブラリを使っていないか、セキュリティ上の問題がないかなど、ルールベースだった部分をより柔軟に評価できるようになるかもしれません。
一方で、コード以外の部分、例えばユーザー要望の分析やテスト設計の手助けをAIにさせてみても、今のところ劇的な改善は感じていません。チケットやリポジトリといった時系列を持つ情報の扱いも、まだ難しいと感じます。
AI時代の品質とスピード
服部：
品質とスピードは、エンジニアリングで長年議論されているトピックです。「12月までにリリース必須！」みたいな追い込みで、AIツールでUIをサクッと作ってしまう選択肢も現実にはあります。
でも、品質とスピードはトレードオフではない、という意見もあります。AI時代にあらためて考えてみましょう。
最近はAIツールで手間が省けて、小規模なプロジェクトには魅力的ですよね。
山口：
使い方次第だと思います。自分用のツールや一時的な用途なら、AIでパッと作っちゃうのはアリです。「使い捨ての張りぼて」と割り切るわけですね。
でもビジネスで使う本格的なプロダクトは別で、現時点でAIツールだけに頼るのは危険です。プロトタイプのような試行錯誤段階で使うのが現実的だと思います。
金子：
「品質とスピード」は本来、バランスをとるべきものではないと思っています。本当に重要なのは「顧客が受け入れられる品質は何か」という点です。
顧客が受け入れない品質で早く出しても、後で作り直しになる。逆に、顧客が求める以上の品質を目指し過ぎて時間をかけるのも問題です。
要は、当たり前品質で十分なときと、顧客を感動させる品質が必要なときではアプローチが違う。それを見極めるのがプロダクトマネジメント上の重要な判断です。
和田：
僕は以前から品質とスピードはトレードオフではないと主張してきました。プロトタイピングは特にそうで、山口さんに同意します。
プロトタイプは「学びを得てすぐ捨てる」ことが本質で、その文脈ではAIの「雑だけど速い」という特性が強みになる。これは「捨てる」前提があるからこそです。
こうしてみると、AIツールは品質とスピードの関係に新たな視点をもたらしています。重要なのは使用目的を明確にし、適切なコンテキストで使うこと。
「捨てる前提」のプロトタイプではAIの特性が活きる。一方、本格的な開発では「顧客価値」を軸に品質とスピードを考えるべきで、AIはその判断を支援する道具の一つとして位置づけるのが良いでしょう。
服部：
これからのソフトウェア開発は、AIツールの特性を理解して、適材適所で活用する戦略が必要になりそうですね。皆さん、ありがとうございました！
AIとの協働について書いた**コードAI本は好評発売中。
対談の皆様の著書や翻訳書もぜひご一読ください！
