- 2019年には、ほとんどのソフトウェアエンジニアは機械学習が自分たちの仕事にどう役立つかを想像するのが難しかった
- しかし2024年には、AIがコード作成を支援する方法に広く熱狂が集まっている
- 多くのエンジニアが、社内ツールや商用製品でMLベースの自動補完を試したことがある
- この記事では、Googleの社内ソフトウェア開発ツールが継続的に変化する中で、最新のAIベースの改善を紹介する
- 今後5年間に予想されるさらなる変化についても議論する
- また、プロフェッショナルなソフトウェア開発に価値をもたらすAI製品を構築するための方法論も提示する
- このチームは、IDE、コードレビュー、コード検索など、Googleのエンジニアが大半の時間を過ごすソフトウェア開発環境を担当している
- こうした改善が、開発者の生産性と満足度に直接影響し得ることを示している
課題
- AI技術は急速に進化しているため、どのアイデアを先に探るべきかを予測するのが難しいことが、この領域における継続的な課題である
- 技術的に実現可能なデモと、製品化の成功との間には、しばしば大きな隔たりが存在する
- アイデアを製品として展開するためのアプローチには、3つの指針がある:
- 技術的実現可能性とインパクトに基づいて優先順位を付ける: 技術的実現可能性がすでに証明されており、エンジニアのワークフローに高い（測定可能な）影響を与えると見込まれるアイデアに取り組む
- 迅速に学び、UXとモデル品質を改善する: 開発者の生産性と満足感を損なわないようにしつつ、素早く反復し、得られた教訓を引き出すことに重点を置く。ユーザー体験はモデル品質と同じくらい重要である
- 効果を測定する: 目標は生産性と満足度の指標を高めることなので、これらの指標を広範囲に監視する必要がある
LLMをソフトウェア開発に適用する
- トランスフォーマーアーキテクチャの登場とともに、LLMをソフトウェア開発に適用する方法の模索が始まった
- LLMベースのインラインコード補完は、ソフトウェア開発に適用されるAIの中で最も人気のある応用である
- コードそのものを学習データとして使うことは、LLM技術の自然な応用である
- UXは開発者にとって自然に感じられる。単語レベルの自動補完は長年にわたりIDEの中核機能だったためである
- AIによって書かれた新規文字の割合といった、インパクトのおおまかな測定が可能である
- こうした理由から、LLMのこの応用が最初に展開されるのは理にかなっている
- 以前のブログでは、コード補完によってユーザー体験を改善する方法と、その影響を測定する方法を説明している
- その後、他の企業環境と同様の継続的で急速な成長を示した
- ソフトウェアエンジニアの採用率は37%で、コード文字の50%を補完するのに役立っている
- 主な改善は、モデルとUXの両方からもたらされた
- このサイクルは、合成的な定式ではなく実際の行動から学ぶために不可欠である
- さまざまなツールから得たログデータと、ユーザーの好みや要件を捉えた利用データを活用して、コーディングツール（例: IDE）のAIベース機能を改善している
- AI支援によって生成されたコードの割合は継続的に増加している
- これは、AIベースの提案から受け入れられた文字数を、手動入力した文字数とAIベースの提案から受け入れられた文字数の合計で割った値として定義される
- 注目すべき点は、コピー&ペーストで持ち込まれた文字は分母に含まれないことである
- 複数のツールにまたがって長年キュレーションしてきた、社内ソフトウェアエンジニアリング活動に関する膨大で高品質なログを利用している
- このデータにより、細粒度のコード編集、ビルド結果、ビルド問題を解決するための編集、コードのコピー&ペースト作業、貼り付けたコードの修正、コードレビュー、レビュアーの指摘解決のための編集、リポジトリへの変更提出などを表現できる
- 学習データは、入力と出力の両方にタスク別の注釈が付いた、整列済みのコードコーパスである
- 次に重要な展開は、コードレビューコメントへの対応解決（現在8%以上がAIベース支援で処理）と、貼り付けたコードを周辺コンテキストに自動適応させること（現在IDE内コードの約2%を占める）だった
- 追加の展開には、自然言語でIDEにコード編集を指示することや、ビルド失敗に対する修正を予測することが含まれる
- 類似パターンに従うコード可読性向上のためのヒント予測のような、他の応用も可能である
- これらの展開済みアプリケーションは総じて、Googleにおいて成功し広く利用されるアプリケーションとなり、実際の産業環境で生産性に測定可能な影響を与えた
学んだこと
- これまでの取り組みを通じて、いくつかのことを学んだ:
- ユーザーのワークフローに自然に溶け込むUXが、最も高いインパクトを達成する。上記のすべての例では、提案がユーザーに提示され、1回のタップまたはクリックでワークフローの次の段階へ進める。ユーザーが機能をトリガーする必要があることを覚えておくよう求める実験は、拡張できなかった
- AIベースの提案により、コード作成者は次第にレビュアーになっていることを観察した。レビューコストと付加価値のバランスを見つけることが重要である。通常は採用率の目標によってトレードオフを解決する
- オフライン指標はしばしばユーザー価値の粗い代理指標にすぎないため、オンラインA/B実験による迅速な反復が鍵である。AIベース機能を社内ツールに露出させることで、容易にリリースと反復を行い、利用データを測定し、UXリサーチを通じてユーザーに直接体験を尋ねられる点に大きな利点がある
- 自社機能との相互作用を含む、ソフトウェアツール全体にわたるGoogleエンジニアの活動から得られる高品質データは、モデル品質に不可欠である
- UXとモデル改善を活用して中間段階のボトルネックを取り除きつつ、機会（主にユーザー活動で、下のファネル上部に表示）からインパクト（適用されたAI支援、ファネル下部）への転換を最適化することが重要である
What's Next
- これまでの成功に後押しされ、最新の基盤モデル（Geminiシリーズ）を、開発者データ（上述のDIDACTの一部）と組み合わせて、GoogleのソフトウェアエンジニアリングにMLを適用する既存および新規アプリケーションを強化することに注力している
- 業界全体で、MLベースのコード補完はソフトウェア開発者に大きな助けを提供してきた
- コード生成を改善する余地はなおあるが、次の段階の恩恵は、テスト、コード理解、コード保守のような、より広範なソフトウェアエンジニアリング活動におけるML支援から生まれると期待される
- 後者はエンタープライズ環境で特に関心が高い
- こうした機会は、自分たち自身の進行中の取り組みにも示唆を与えている
- 業界で見られる2つのトレンドを強調している:
- 人間とコンピュータの相互作用は一般的なモダリティとして自然言語へ移行しており、ソフトウェアエンジニアリング作業のインターフェースとして言語を使い、IDEに統合されたソフトウェア開発者の情報要求へのゲートウェイとして使う方向に転換している
- 問題診断から修正適用までの大規模タスクに対するMLベースの自動化は、初期的な実現可能性の証拠を示し始めている
- こうした可能性は、エージェントとツール使用の革新によって後押しされており、それにより、より大きなタスクを実行するために1つ以上のLLMを構成要素として使うシステムを構築できるようになる
- 上記の成功を次世代機能へ拡張するために、このテーマを研究する実務家と研究者のコミュニティは、分野を実用的なエンジニアリング作業へ進める助けとなる共通ベンチマークの恩恵を受けられる可能性がある
- これまでベンチマークは主にコード生成（例: HumanEval）中心だった
- しかしエンタープライズ環境では、コード移行や本番デバッグのような、より広範なタスクに対するベンチマークが特に価値を持ち得る
- バグ修正（例: SWEBench）のためのベンチマークと、そのようなベンチマークを対象とするプロトタイプ（例: Cognition AI）が発表されている
- より広範なソフトウェアエンジニアリング作業をカバーするため、さらに多くのベンチマークを提案するようコミュニティが協力することを促している
GN⁺の意見
- AIの急速な進化: AI技術は急速に進歩しているため、最新技術を継続的に学習し適用することが重要である。
- UXとモデル品質: ユーザー体験とモデル品質は、AIツールの成功における重要な要素である。
- データの重要性: 高品質データがAIモデルの性能を大きく左右する。
- 未来の可能性: AIはソフトウェアエンジニアリングのさまざまな側面で、より大きな役割を果たす可能性がある。
- 業界トレンド: 自然言語インターフェースと大規模タスク自動化が、ソフトウェア開発の未来を牽引していくだろう。
1件のコメント
Hacker Newsの意見
AIは適切に使われると、2つの役割を果たす: 1) 議論の余地のない修正で開発者の時間を節約し、認知負荷を減らす。2) 提案を通じて、ユーザーをより賢く、知識豊富にする。たとえば、コード補完機能がうまく動作するときがある。
AIツールは、ユーザーが機能をトリガーしなければならないときに「スケールしない」という興味深い主張がある。IDE内でAIが設計レベルや概念的なアイデアを有用に提案する方法について考えている。
AIベースの提案によって、コード作成者が次第にレビュアーになっていく現象が観察されている。レビューのコストと付加価値のバランスを見つけることが重要だ。
GPT-4を使ってReact UIとPython UIを数分で生成し、コードをレビューしてその動作を理解するのが有用だと感じた。
人間の限られたRAMのため、アイデアは外部メディアに載せる必要がある。AIの提案は初期段階をより速く進める助けになる。
LLMs（大規模言語モデル）がプログラミングに有用であることは否定できない。よりスムーズにするための適切なUXが重要な課題だ。自動補完機能を試したが、提案の大半が良くなかったため無効化した。
ChatGPTデスクトップアプリを使ってコードについて質問するほうが、より有用だと感じた。しかし、そのたびに詳細を説明しなければならないのが煩わしい。
AI支援によるコード作成の比率が50%まで増加している傾向は興味深い。
AIは依頼された作業のやり方は教えてくれるが、それが悪いアイデアだとは教えてくれない。ML生成コードの品質は訓練データに左右される。
AIがGoogleのソフトウェアエンジニアを完全に置き換えるまでにどれくらいかかるのか気になる。
AIの究極的な目標は、システムを運用し、アプリをデバッグし、データストアを管理し、ユーザーフィードバックや要件説明に基づいてアプリのコードを書くことだ。
AIツールを試すのは良いことだが、ほかの人が盲目的にコピーするのは悪影響を及ぼす可能性がある。LLMを使ったコード作成の主なセールスポイントを見つけるのは難しい。