TL;DR
- すでにAIが生み出すコード量は人間がレビューしきれる規模を超えている
- 「本番リリースしてよい」と判断する基準を組織ごとに再設計する必要がある
- 4案から「テスト中心レビュー」が最も現実的だと考えている
はじめに
最近のAIの進化は目覚ましいです。毎日のように新機能が追加され既存のSaaSを急速に侵食していると感じます。
業務でAIを利用するなかで筆者が一番悩んだのは、「AIが書いたコードの信頼性をどうやって担保するか」でした。
本記事は、その問いに対して現時点で考えるいくつかの案をまとめたものである。
これまでの品質担保の難しさ
これまでのソフトウェア開発における品質担保は、おおむね次の方針が主流だったと思います。
- コードレビューと指摘修正を反復することによりコードレベルのバグを潰す
- 結合〜受け入れテストによって残ったバグを潰す
- 本番でのバグは、PMが責任者としてメンバーと対話しながら再発防止を検討する
ところが、AI駆動開発によって1の「コードレビュー工程」が成り立たなくなりつつあります。理由としては、AIの生成するコード量が人間のレビューできる量を遥かに超えるからです。このままの運用ではコードレビューがボトルネックになるか形骸化していくかの二択になりつつあると感じています。
そこで今後は、「本番リリースしてよい」と判断するための新しい指標が必要になると考えます。私はそれを「人間がどこまでレビューに関与するか」という軸で4段階に検討してみました。
4つのレビュー戦略
A案: 全自動レビュー: 人は介在しない
AIにレビューとテスト実行を全て任せ、全テストがパスしたら本番リリースするという運用方法です。
B案: テスト中心レビュー: 人の介在は少なめ
AIとの対話でテスト計画とテスト設計をして、テスト内容とテスト結果を人間がレビューするという方針です。コードレベルのレビューはAIに完全に任せます。
C案: 設計+テストレビュー: 人の介在は多め
B案に加え、設計方針やプロジェクト構成といった範囲もコード単位でレビューするが詳細実装まで踏み込まない方針です。これはアーキテクチャの逸脱だけは人間が止める形となります。
D案: 全コードレビュー: 人の介在が最大
C案に加え、AIでのレビュー + 人のレビューの両方する従来に近い方針です。
各案の比較
| 観点 | A: 全自動 | B: テスト中心 | C: 設計+テスト | D: 全コード |
|---|---|---|---|---|
| 安全性 | × | △ | ◯ | ◎ |
| スピード | ◎ | ◯ | △ | × |
| 個人開発 | ◎ | ◯ | ◯ | △ |
| スタートアップ | △ | ◯ | ◯ | △ |
| 高信頼性が求められる業界 | × | △ | ◯ | ◎ |
個人開発
A案〜C案が現実界だと考えます。完全な個人開発の場合はおおよそA案で問題ないです。ただ機密情報を取り扱う場合、A案はまだ危険すぎると感じるのでB案かC案が落とし所かなと。
企業開発
スタートアップの場合はスピード重視な部分が多いので、こちらもB案かC案が現実界だと考えます。高信頼性が求められる分野ではD案はリスクヘッジの観点で最適解になる場合もあると思います。A案はセキュリティリスクが大きい印象があるので現在のAIでは難しいと感じています。
まとめ
ここまでの見解と現状のAIの能力から、筆者は**B案(テスト中心レビュー) or C案(設計+テスト)**が最も現実的だと考えています。理由は下記のとおりです。
■ A案
AIだけで完結できる水準に達するにはまだしばらく時間がかかると見ています。あくまで全体公開しない個人開発が現実的かと思います。
■ B案
セキュリティの不安はありますが、そこもテストのレビューで担保できると考えているので現実的だと考えます。
■ C案
B案ほど速度を重視しない場合は最適解だと考えます。
■ D案
現在のAIでは過剰になりつつあると感じます。適切なプロンプトとガードレールがあればコードレベルでは十分な品質を出せるので全コードのレビューに人間の時間を使うのはコストパフォーマンスが悪いと考えます。ただ、金融などの業界では残り続けると想定します。
おわりに
信頼性の担保は企業や業種によって大きく異なります。重要なのは、現在の案件での最適解を議論して検討することだと思います。
そして、AIの進化スピードを踏まえればこの最適解は変化するとも感じています。「A案でも回る」状態になったタイミングで、フットワーク軽く移行できるよう準備しておきたいです。