9年ぶりのQiita投稿です。
生成AIを使った開発体験や生産性向上について考えることが増えてきたので、今回はGoogle Researchにて発表されたAIを使った開発についての最新論文について読み解きながら考察を得ていきたいと思います。
Understanding and Designing for Trust in AI Powered Developer Tooling
タイトルは 「AIを活用した開発者向けツールの信頼性：その理解と設計」
AIを活用した開発者支援ツールはv0やCursorなど、日々便利なものが出ていますが、ベースとして開発者がその支援ツールに対して「こいつは使える、信頼できるコード生成/Reviewを支援してくれる」という信頼ありきで成立しているとも言えます。
- そもそも提案されたコードは正しいのか？
- 今の状況にマッチしたコードなのか？
こういう不安は少なからずともみなさん持っていると思います。
不信感が募ると、もはや生産性向上どころか開発者のストレス要因となり、「やっぱAIは信頼できない」といって、AIの享受を拒否する事態になりかねません。もったいないですよね。
そこについて我々は、どう向き合っていくんだろう、という内容です。
- 翻訳はClaude 3.5 Sonnetを使いました
- 要所要所、投稿者による意訳/補足/省略が入っています
本題: AIに対する開発者の信頼とは
開発者は人間で、それ故にAIへの信頼というのは、当然開発者それぞれで物差しが異なります。
例えば、Googleの研究によると信頼を確立する要因は、
- 開発者自身のコーディング力、在職期間
- 開発者が今どのような開発状況にあるか
- 本番環境に近いコードを書いているのか
- テストコードを書いているのか
- 重大なバグの修正中なのか
- 新機能の開発中なのか
- AIが提示するコードや解決策の特徴や性質
の3つが影響することがわかっています。つまりAIが提示する解決策の中身だけではなく、それを使う開発者の状況に大きく依存するということです。そして、個々のニーズに合った適切なAIとの信頼関係を築く必要があります。
ここで以下の調査を行いました
- 過去3ヶ月間で、開発作業でAI支援ツールのアウトプットに対してどれぐらい信頼していますか？
- 開発者として、AI支援ツールがどのような影響を与えたか？
AIへの信頼度と開発生産性に関するフィードバック
調査の結果、以下のような特徴がでました
| AIへの信頼度: 低 | AIへの信頼度: 高 | |
|---|---|---|
| 開発生産性の自己評価: 低 | 複数のパターンがあった 1. そもそもAIを利用できていない人 2. 意図的にAIを避けている人 3. コスト対効果に疑問を持っている人 フィードバック: 「一見求めている解決策を提示してくれるが、実は発見しにくい細かなエラーが含まれていることが多い。結局、デバッグに時間がかかりむしろ生産性が下がってしまう」 |
AIに対する理解があり、広範囲な活用を望んでいる人 フィードバック: 「AIは単純な変更やリファクタリングに関して優れており、退屈な作業を減らすことができる。これらのツールが進化することで、より興味深い問題に取り組む時間が確保できる」 |
| 開発生産性の自己評価: 高 | AIに対して高い期待値を寄せていて（エラーに対する許容度が低い）、提案/回答が不正確だと不満だと感じる人 フィードバック: 「自動補完の提案は多少は役立ちますが、一貫して間違いが含まれているため、もはや全く信頼していません。結局、すべて手作業で書く方を好んでいる」 |
AIが出力する内容に寛容で、補助的に小さく活用することの利点を強調する人 フィードバック: 「AI搭載のコード補完ツールは、挿入すべきコードをほぼ正確に予測することができた。また、Geminiは問題に対する良い出発点やテンプレートを提供してくれ、よりよいコードにすることができた。これらにより、全体的な開発速度が向上した。」 |
上記マトリクスからわかるように、AI支援の開発者ツールを考えるうえで、
-
AIへの信頼度が低い開発者の場合：
- 不正確な提案によって作業が中断されやすい
- 提案の表示数を減らすオプションが必要
- 特定の状況でのみ提案を表示する設定が有用
-
AIへの信頼度が高い開発者の場合：
- 提案が完全に正確でない可能性があってもより多くの提案を見ることを望む
- より広範な開発プロセスへの統合を期待
といった様に、状況や開発者の特性に合わせて細かくカスタマイズできることが重要です。
本論文では、続いて、IDEでAI支援機能をどう細かくカスタマイズしていくと、活用されるのかをTry&Errorしています。
IDE内でのAI設定とは？
例えばですが、
- 細かいAI支援の無効化機能
- 例えば、特定のプログラミング言語では無効化されるなど
- 特定条件下で無効化の制御ができる
- AIの支援するトリガーの調整機能
- 提案がされるタイミング
- 提案を表示の仕方
- AIへの信頼度の調整
- AIの提案に対する開発者の信頼度を設定し、信頼性が高いと判断された提案のみを表示する機能
といった内容です。
しかしながら、そもそもIDEの設定は開発者が頻繁に触る部分ではなく、仮に一旦、AIの機能をOFFにしてしまったら、もう二度と設定を見直すチャンスがなくなるだろうという点に触れています。
そこで論文では、簡単に設定ができることと、設定したあとに、定期的に利用状況に合わせて、「AIの提案頻度減らしますか？」といった通知をさせる試みをしています。
何れにしても、開発者の好みに合わせて、且つ、継続的なAIの介入を調整していくことが大事なのかなという印象を受けます。
What do developers want from AI?
タイトルは「開発者はAIにどのような期待をしているのか？」
Google社内（開発者の1/3を対象）に開発者向けのAIツールに対してどのような期待をしているかを調査した内容です。
開発生産性を妨げる要因
Googleの開発者が報告した開発生産性を妨げる要因を以下のグラフに示します。
トップ3の課題：
技術的負債（24%）
ドキュメントの不備・欠如（22%）
新しい技術やインフラの学習（20%）
テスト関連の課題：
不安定なテスト（14%）
Presubmitテストの遅延（13%）
ビルド・テストサイクルの問題（12%）
遅いテスト実行（11%）
プロセスや組織的な課題：
複雑なプロセスや形式的な手続き（18%）
チームや組織起因（16%）
コードレビュー（11%）
開発者はAIに何を期待しているのか
開発者は単にコード生成をAIに期待しているのではなく、開発フロー全体での障壁除去に期待しているようです。
- ドキュメント生成の支援
- コードレビューとテストの支援
- 新しいプラットフォームやフレームワークの学習支援
考察
フィードバックを見ると、
- 単純な変更作業
- リファクタリング
- テンプレート
- 考える起点/アイデア
- 技術的なキャッチアップ
- ドキュメンテーション
といった、本丸のコーディングそのものというよりは周辺系での活用に対して既に、効果を感じ取っているのかなという印象でした。逆に、「AI使えないな」と感じている人は、期待値が高く、全部まるっと解決してくれるんでしょう？完璧な回答をしてくれるんでしょう？という前提で取り組んでいるようです。
そういう意味では、生成AI関連のエンジニアリング支援ツールの向き合い方としては、
やはり周辺系に意識的に活用を割り切り、本丸のコーディングに対する時間をしっかり割いていくことが相性が良いと見られます。
また少なくとも2024年現在において、生成AIがエンジニアに代替するのは程遠い、つまり引き続き技術や経験を磨き、良い開発をしていくことが、いいサービスを生む基本であることには変わらないということが見えてきます。
（つまり、生成AIによってエンジニア不足が解決されることはない）