シェア
はてブ 
生成AIを活用したソフトウェア開発への関心は高まる一方、新しい領域のため情報が少なく、手探りの部分が多いのが現状です。業界全体のスキル向上につなげるためには、知見や経験を共有し、議論を重ねていく必要があります。
そこでFindyでは、2024年11月13日にオンラインイベント「コード品質はどうなる？生成AIとの最適な協働とは？〜コード×AI疑問解消会〜」を開催。GitHubでシニアアーキテクトを務める服部さんと、名古屋大学大学院情報学研究科准教授の森崎先生にご登壇いただきました。
お二人は『コード×AI ソフトウェア開発者のための生成AI実践入門』の著者とレビュアーという立場から、生成AIを活用したソフトウェア開発における実践的なアプローチと課題について議論を展開。本レポートでは、現場で活かせる知見が盛り沢山のイベントの模様をお伝えします。
- 登壇者
- LT「AI時代のコード品質向上: 生成AIを活用した新しいアプローチ」｜GitHub Japan Sr.Architect 服部 佑樹
- パネルディスカッション「コード×AI 疑問解消会」
- Q&A
- 未回答Q&A
- アーカイブ動画
登壇者
服部 佑樹
GitHub Japan Sr. Customer Success Architect
マイクロソフトにてソリューションアーキテクトとして7年間勤務した後、2023年から現職。 オープンソース文化やプラクティスを企業に取り入れ、組織内のサイロを取り除く「インナーソース」の推進にも注力している。この取り組みにより、米国の非営利組織であるInnerSource Commonsファンデーションのヴァイスプレジデントを務め、世界的なインナーソースの発展に寄与している。
森崎 修司
名古屋大学 大学院情報学研究科 准教授
2001年に博士号取得後、インターネットサービスプロバイダにてオンラインストレージサービスの企画・開発、無線ICタグの国際標準化活動に従事する。奈良先端科学技術大学院大学助教等を経て、2013年10月より現職。IPA(独立行政法人 情報処理推進機構)の「つながる世界の品質指針検討ワーキング・グループ」をはじめ3つのワーキング・グループの主査を務める。国内外のソフトウェア開発企業に勤める社会人博士の学位取得の支援や審査に従事。ソフトウェア開発活動における生成AI活用の研究に取り組み、ソフトウェアエンジニアの方やエンジニアコミュニティの協力を得ながら実証的に効果を確かめている。
LT「AI時代のコード品質向上: 生成AIを活用した新しいアプローチ」｜GitHub Japan Sr.Architect 服部 佑樹
2024年9月に『コード×AIーソフトウェア開発者のための生成AI実践入門』（以下、コードAI本）を上梓しました。コードAI本では、生成AIとの基本的な取り組み方から実践的な協働手法まで、100以上のプラクティスを紹介しています。組織での生成AI活用のロードマップを知りたい方は、ぜひ手に取っていただければ幸いです。
プロンプトエンジニアリングを学ぶ必要性
最近、「プロンプトエンジニアリングを学ぶ必要があるのか」という質問を受けることが増えました。プログラマやエンジニアの日常業務の多くは一回性が高く、ユニークなタスクです。完璧なプロンプトを作る必要はなく、むしろ即興で使い捨てのプロンプトを組んでいく必要があります。つまり、数％でも精度を上げるための細かいプロンプトエンジニアリングの「テクニック」よりも、問題の本質を見抜く力のほうがより重要になってきます。
生成AIと協働するために大切なこと
生成AIとの協働においては、作業単位を小さく分割することをおすすめしています。これは、エンジニアのレビュー能力の限界とAIの出力精度の限界を考慮し、作業に適切なサイズを見つけることが重要だからです。例えば、効果的なレビューには1時間あたり500行以内、1回のレビューで400行以内に抑えることが望ましいという調査*1もあります。AIが大量の出力を可能にしても、人間のレビュー能力を過信しないことが大切です。
ただし、分割サイズは開発対象によって変わってきます。フロントエンド開発のように視覚的に確認しやすい場合は、大規模なコードでも受け入れられることがあります。一方、ビジネスロジックなど設計と突き合わせての確認が必要な場合は、より小さな単位での慎重なレビューが求められます。
また、AIとの効果的な協働には、AIに理解しやすい命名とツールによる検索最適化も重要です。社内独自の規約よりも、PythonのPEP8やGoogle Java Style Guideなど、AIがよく知る標準的な規約を優先することをおすすめします。さらに、自律的なAIエージェントが多くのタスクを一度にこなす未来も見えてきています。これは、AIによるコード改変へのエンジニアの介入機会が減ることを意味します。この将来に備え、AIが扱いやすい、つまり検索性が高く文脈が明確なコードベースを整備することが重要になってくるでしょう。
AI活用で守るべき設計原則と品質管理のポイント
AIにコードの編集を依頼する際は、必ずしも期待通りの結果が得られるとは限りません。そのため、人間による確認が容易で、AIによる誤変更を防止できる設計が重要です。具体的には、深いネストを避け、ガード節による早期リターンを活用するなど、AIと人間の両方が扱いやすいシンプルな設計を心がけることをお勧めします。また、コードをカプセル化してAIが触れなくてもよい部分を作成することも効果的な方法です。
リファクタリングをAIに依頼する際は、単に「リファクタリングしてください」と伝えるのではなく、業界のベストプラクティスに基づいたガイドを求めることが有効です。AIはSOLID原則のような標準的な知識や、マーチン・ファウラーのリファクタリングカタログなどのプラクティスに関する知識を持っているため、これらを活用した具体的な問いかけをすることで、より良い結果が得られます。
テストコードの作成においても、直接「テストコードを書いて」と依頼するのではなく、まずは必要なテストケースを整理することをおすすめします。ディシジョンテーブルや状態遷移図などの中間成果物をAIに出力してもらうことで、必要なテストを人間が確認しやすくなります。マークダウンのテーブルやMermaidなどの視覚的表現を活用することで、テストが必要な部分をより直感的に理解することができます。そうすることで、不必要なテストを大量に作ってしまう状況を避けることができます。
パネルディスカッション「コード×AI 疑問解消会」
Findy運営 ここからは、コード×AIに関する疑問に回答するパネルディスカッションに入ってまいります。コードAI本の著者の服部さんと、コードAI本のレビューを担当された森崎先生にご登壇いただき、みなさまからの疑問にディスカッション形式でご回答いただきます。
「自分で書いたほうが早い？」生成AIを最大限に活用する方法
森崎 生成AIにコードを書かせようとすると、結局自分で書いた方が早かったのではと感じることがあると思います。生成AIをうまく活用してスピードを上げたいと考えている方も多いと思いますが、具体的にどういう場合にスピードが上がるのか、逆にどういう時は自分でやった方が良いのか、教えていただけますか？
服部 正直、これはタスクによって異なるので、自分で感覚を掴むしかないと思います。重要なのは、初期段階でそのタスクがAIにとってどの程度難しいのかを判断することです。プロンプトを10行、20行と書き続けて、結局できないとわかった時の失望感は大きいですから。最初に1〜2行程度の簡単なプロンプトで試してみて、できないと判断したら、自分でやるべき部分を見極めることが大切です。
森崎 具体的な方法は本に詳しく書かれていますが、要は「早めの見極め」が重要ということですね。プロンプトの作り込みに時間をかけても、良い回答が得られない場合があるということでしょうか？
服部 そうですね。タスクの難易度だけでなく、モデルの更新によっても変わってきます。例えば初期の大規模言語モデルである GPT-3.5 Turbo でもだいぶ多くのことができましたが、いまではさらに様々なモデルの選択肢があり、より難しいタスクも扱えるようになりました。使用するモデルも判断の要素の1つになります。
森崎 モデルは継続的にアップデートされていくということと、タスクも同じものを繰り返すわけではないので、素早く試してフィードバックを得て、AIに任せるか自分でやるか早めに見極めることが重要だということですね。
服部 そうですね。例えば、フロントエンド開発の分野では、AIの効果的な活用が実証されています。具体例として、UI開発においては多くの開発者がAIを活用し、より高次元の実装を実現しています。業界の進展を見ながら、自分のタスクがAIに適しているかどうかを判断することも大切です。
森崎 つまり、生成AIにも得意不得意があり、それを理解することでより効率的に活用できるということですね。
服部 はい、その通りです。
生成AI活用への期待値と課題への向き合い方
森崎 生成AIを活用する上でのアンチパターン、つまり「こういうことはやめた方がいい」というような例を教えていただけますか？まだ始まったばかりで確立されたものは少ないかもしれませんが、皆さん興味があると思います。
服部 AIに対して間違った期待を抱くことは避けるべきです。現在の言語モデルには限界があり、100枚もの詳細設計書から完璧なバックエンドロジックを自動生成できるとは限りません。また、大量のソースコード数万行を一度にプロンプトとして与えたうえで正確な回答を得ることもまだ難しいです。 このように、AIに対して過度な期待を持たないことが大切です。
森崎 これは先ほどと同じように、ある程度の経験が必要ということですね。
服部 はい。現在のAIはトークン長が長いものや依存関係の多い大きなものを扱うのが苦手です。そういった場合は、コンテキストを絞って対応する必要があります。
森崎 以前、服部さんと和田さん（@t_wada）と一緒に実験した際、生成AIを使ってコードを読む実験をしましたが、AIの回答が間違っているとエンジニアも同じように間違えてしまう、という現象が起きました。この対策としても、タスクの分解は有効なのでしょうか？
服部 はい、有効です。ただし、単純な分割能力だけでなく、分割したコンポーネントの内容理解と、AIの知識範囲の把握、この両方が必要です。残念ながら銀の弾丸はないので、一つ一つ対応していく必要があります。
森崎 ドキュメンテーションに関してはいかがでしょうか？
服部 コードの読解は、生成AIの活用で楽になった一方、補足情報や背景情報の重要性が増しています。古い情報や誤った情報が残っていると、AIがノイズとして捉えて誤った理解をする可能性があります。ドキュメンテーションやコメントの書き方、そして、何を書くか、逆に何を書かないかも含めて整理が必要な時代になってきているかもしれません。
森崎 つまり、AIにとっての可読性という新しい観点も考慮する必要があるということですね。
服部 はい。とくにプロプライエタリなコードを扱う場合、AIはそのコードの詳細な情報を持ち合わせていない可能性があります。AIからの適切なサポートを得るためには十分な文脈の提供が重要です。そういった文脈がコードの変数名やコメント、ドキュメントなどに記載されていると、AIとのコミュニケーションもより良いものになるはずです。
森崎 最近は経営陣も含めて生成AIへの理解があり、導入に前向きな印象です。昔は構成管理ツールの導入でさえコストの観点から難しかったのに比べると、大きな変化ですね。ただ、「何でもできる」という過度な期待や、「エンジニアは不要になる」といった極端な見方もあるようですが、この点についてはどうお考えですか？
服部 難しい問題ですね。例えばノーコード・ローコードが流行した際も同様の議論がありました。しかし、どの分野においても、システムのメンテナンスを行う人材は必要不可欠です。また、AIが生成したコードをカスタマイズするためには、コードを理解できる人材が必要となります。ただし、これまでより少ない人数でより多くの成果を上げられる可能性は十分にあります。
業界や業務内容によっても状況は異なります。日本の製造業やドメイン特化の特殊なソフトウェアを開発している企業では、技術自体が競争優位性の源泉となっているため、AIでは代替できない領域を追求していく必要があります。一方、ビジネス系のツール開発が主な業務である場合は、特定の技術よりもむしろ、業務知識や経験が重要視される可能性があります。このように、新時代における「エンジニア」に求められるスキルセットも変化していくことでしょう。
森崎 コード品質への影響について質問をいただいていますが、この点についてはいかがでしょうか？
服部 まず「コード品質とは何か」という定義自体が難しい問題です。例えばセキュリティの観点では、大規模言語モデルの研究が進んでおり、脆弱性の検出などでは進展が見られます。GitHub でも脆弱性の解決や依存関係の明確化などを通じて、全体的な品質向上を目指しています。
ただし、これらはコード品質の一側面に過ぎません。企業全体を見ると、まだ生成AIを活用したコード品質向上についての議論は十分ではありません。今後、社内での生成AI活用の浸透とともに、品質向上の具体的な取り組みが出てくるでしょう。
森崎 AIが書いたコードと人間が書いたコードの判別は可能でしょうか？
服部 正直、判別は難しいですね。この質問の背景には、エンジニアの生産性測定という目的がある場合が多いのですが、コードの行数で作成したソフトウェアの価値を測ることには意味がありません。
重要なのは、AIが生成したコードであっても、最終的な責任はエンジニアにあるという認識です。「AIが書いたから」という言い訳は通用しません。企業としても、その方針を明確にし、エンジニアに説明責任を持たせる必要があります。
森崎 現時点では判別は難しく、またその目的を明確にする必要があるということですね。文章の生成AI検出に関する研究でも、まだ精度は高くないようです。
生成AIの弱点と得意分野を見極める
森崎 AIの得意不得意について、特に「AIが生成するコードの弱点」について教えていただけますか？
服部 大規模言語モデルは十分に賢いので、依存関係も含めた正しい情報と適切なプロンプトがあればある程度正しく推論してくれるはずです。問題は、人間が適切なプロンプトやコードの依存関係の情報を言語モデルに提供できていないこと、そしてツールがその情報収集を完璧には行えていないことにあります。つまり、AIの得意不得意というよりも、人間やツールの限界に注目すべきかもしれません。
例えば「言語モデル」自体には脆弱性を含むコードを生成してしまう可能性があります。しかしこれは人間であっても同じことです。AI開発ツールの中には、フィルタリング機能を実装することで、リスクのあるコードが含まれないよう対策を講じているものもあります。そのため、言語モデルが脆弱なコードを生成する可能性を一方的に批判するのではなく、言語モデル自体の特性と、それを補完するエディタのフィルタリング機能など、多角的な視点から評価することが重要です。
また、コードの脆弱性については、従来通りCI/CDパイプラインでの検証プロセスによって対応することも重要です。セキュリティは常に変化するものであり、昨日まで安全とされていたコードが、今日も安全とは限りません。新たな脆弱性が発見される可能性は常にあるのです。重要なのはAIの能力そのものだけではありません。人間がツールの特性を十分に理解した上で、そのツールの弱点をいかにカバーしていくかという点が本質的な課題となります。
森崎 開発言語や開発対象による得意不得意についてはいかがでしょうか？
服部 これは言語ごとに差がありますね。例えば、COBOLからJavaへのマイグレーションなどは、追加のテクニックや工夫が必要になることもあります。これは言語に関する十分な知識をAIモデルが持っていないことが原因です。JavaやC#、Pythonなどは比較的得意な印象があります。
また、フレームワークによっても差異が存在します。BootstrapやTailwind CSSといったCSSフレームワークは、学習データに豊富に含まれているため、AIはこれらについて詳しい知識を持っています。しかし、AIが持つ知識量はフレームワークごとに異なるため、AIに対して必要な文脈を適切に提供できているかを特に気にする必要があります。
森崎 つまり、特定の言語、フレームワーク、ドメインの組み合わせが確立している場合は得意で、逆に用途が多岐にわたる場合は、異なる領域の知識を誤って適用してしまう可能性があるということですね。
Q&A
Q1: 生成AIが出力するコードの精度と出力量に相関関係はありますか？
A: コードの書き方が丁寧な場合、AIの理解度も高くなる傾向にあります。ただし、出力量が増えるほど、意図した通りのコードが生成される可能性は低くなります。インクリメンタルなアプローチ、つまり段階的に出力を確認しながら進めることが重要です。
Q2: 複数のLLMを使ったコード開発はどうあるべきですか？
A: 複数のLLMを活用したコードレビューは有効な手法です。チーム内で適切に知見を共有し、プロジェクト全体の品質向上につなげることが重要です。
Q3: 作成したいアプリケーションを適切に生成AIに伝えるには、どのようなフォーマットや内容を記述すべきですか？
A: モデルによって最適なフォーマットは異なりますが、要件を適切にチャンク分割し、プロンプトにおける優先順位を明確にすることが重要です。例えば「すべてが重要」と示すと、AIは本当に重要な要素をスキップする可能性があります。
Q4: ジェネレーティブアートのようなクリエイティブな協働におけるコード生成の品質向上には何が必要ですか？
A: 人の介入を適切に行い、適切なフレームワークの選択が重要です。また、推論やプランニングが得意なモデルを選定することで、品質向上が期待できます。
Q5: リポジトリレベルのコードを一括で読ませる方法はありますか？
A: 現状では、ファインチューニングが最も有望な方法です。ただし、コストや最新のコードへの対応を考えた場合、RAGを使用して必要な文脈のみを渡す方がコスト効率が高いと言えるでしょう。
Q6: コード作成のためにAIを学習させる際、何が必要ですか？
A: 最も重要なのは、適切にメンテナンスされたコードです。組織内でどのように品質の高いコードを育てていくかという視点が重要です。
Q7: 今後のプログラマーに必要な技術は何ですか？
A: 二つの方向性があると思います。AIが判断できない高度な技術領域を追求するか、AIを使いこなして生産性を圧倒的に向上させたAIネイティブなプログラマーになるか。プログラマーとして基礎体力を付けつつ、自身の方向性を明確に持つことが重要です。
未回答Q&A
イベント内で回答がかなわなかった質問について、以下の記事内でご登壇者のお二人の回答をまとめています。 findy-code.io
アーカイブ動画
アーカイブ動画も公開しています。こちらもあわせてご覧ください。
*1:SmartBear “Best Practices for Peer Code Review” https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
