生成AIを活用したソフトウェア開発における実践的な知見を共有する目的で開催された11月13日のオンラインイベント「コード品質はどうなる?生成AIとの最適な協働とは?〜コード×AI疑問解消会〜」。GitHubでシニアアーキテクトを務める服部さんと、名古屋大学大学院情報学研究科准教授の森崎先生にご登壇いただきました。
本イベントでは、事前アンケートやリアルタイムのチャットを通じて、予想を上回る多くの質問が寄せられました。イベント中に可能な限り回答いただきましたが、時間の関係で回答しきれない質問も残りました。
通常はそのまま終わってしまうことが多いこうした未回答の質問ですが、今回は特別にご登壇者のお二人がイベント後に改めて集まり、それぞれの見解を詳しくまとめてくださいました。
この記事では、参加者の疑問に対するお二人の視点を通じた具体的な回答をお届けし、当日の議論をさらに掘り下げます。イベント参加者の皆さまはもちろん、当日参加できなかった方も、ぜひイベント本編のレポート記事と併せてお読みいただき、生成AI活用のさらなるヒントを見つけていただければ幸いです。
▼イベントレポート
当日回答いただいたQ&Aについては、以下の記事に掲載しています。
https://findy-code.io/engineer-lab/code-ai
※掲載の質問文は、内容に影響を与えない範囲で一部表現を調整しています。
Q&A
当日の質問
イベント当日、チャット欄・Xを通じて寄せられた質問
Q. フロントエンドのような進化の早い世界の話についてですが、ざっくりと知っているCSSで作って、AIで洗練させていくのが効果的というお話で合っているでしょうか?
(質問への回答は「正しいです」になります。当日の流れや前提がかなりあって、ご質問者の理解が正しいですかという質問なので、流れや前提を書くのは割愛します。)
Q. AIが作ったコードが、ちゃんとセキュリティや例外処理等の実装がされているかの判断が難しいです。その点みなさんどうされているのでしょうか?結局エンジニアが知っているかが大事になってくるのでしょうか?
森崎 知っているかが大事になると思います。ほとんどの部分で問題がなさそうに見えるコードを対象に判断しないといけないので、難しいですよね…。生成AIを使う側で知っていること/気づけることが大事になると思います。生成AIが出力したコードに脆弱性があることを報告している論文は多いです。知らないと漏れてしまうし、生成AIへの学習時点では脆弱性がなかった(見つかっていなかった/周知されていなかった)コードが出力されうるので、新しく見つかった脆弱性への対策はされていない場合もあります。
服部 そうですね。私は人間とAIの協働が重要だと考えています。コード品質については、従来通りの人間によるレビューをAIと組み合わせて行うことが効果的です。 セキュリティ面では、CI/CDパイプラインの中で脆弱性検出を自動化することが重要です。最近では、GitHub Copilot Autofixのような、AIが脆弱性を発見し修正提案までしてくれるサービスも登場しています。今後はこういったAI機能が開発プロセスの様々な場面に組み込まれていくでしょう。AIを上手く活用することで、セキュリティ対策の作業がより効率的になることが期待できます。
事前質問
イベントお申し込み時のアンケートに寄せられた質問
Q.生成AIは同じスクリプトを入力しても生成結果に差異(間違いという意味ではなく)が出ることがあり、ソフトウェア開発プロセスの中に生成AIを組み込んでいく場合、可読性等の面でも一定のルールに沿ったコード生成を求められるケースが多い気がします。その辺り、生成AIからの生成結果の再現性を確保することは可能なのでしょうか?
森崎 「スクリプト」は「プロンプト」と読み替えますね。同じプロンプトを与えたらおおよそ同じような回答が得られるようにすることはできるか?という質問ですね。
服部 再現性を高めるためには、2つの重要なポイントがあります。1つ目はプロンプトの適切な調整、2つ目は正確なコンテキストをAIに伝えることです。特にコンテキストについては、AIツールを活用しながら、適切な情報が確実にAIに伝わっているか確認することが重要です。
森崎 実際のところ、回答のブレはどれくらい起こるんでしょうか。5回くらい試すとばらつきがわかるという話を聞いたことがあります。
服部 そうですね。例えばPythonの場合、開発対象によって異なりますが、GitHub Copilotの一般的なアクセプタンスレート(ユーザーが提案を受け入れる率)は30%から40%程度です。私の経験では、3回程度試してみて、うまくいかない場合は、プロンプトやコンテキストを見直す必要があると判断しています。
森崎 そうなんですね。再現性を重視したいときは何度か試してみて、同じような結果が出てるかというのが判断基準になりそうですね。
Q. これから生成AIにより、作成された機械学習のコードやDeep Learningのコードで作成したものを自身の功績にするような事が起こると思われます。このように、次世代のプログラマー評価はプロンプト力で判断されていくような価値変化は起こるでしょうか?
森崎 「プロンプト力(りょく)」も含まれるとは思います。ですけど、プロンプト力が評価の主要因になることは現時点では考えにくいです。自分の開発作業から生成AIに向いている作業を切り分けて、任せるというスキルは必要になりそうです。これをプロンプト力と言えなくはないと思います。このあたり、服部さんが本*1にも書かれていて、まさにと思ったんですよね。
服部 そうですね。プロンプトの書き方自体、エンジニアとしての基本的な能力に大きく依存します。これは技術力の本質に関わる議論になりますね。
森崎 単純に「プロンプト力」のみを鍛えるというよりは、エンジニアとしての総合的な実力を鍛えると、それにつれてプロンプト力も上がるんじゃないですかね。エンジニアのスキルとの相関が高いように思います。プロンプトはプロンプトで、ある程度はスキルを伸ばさないといけないのですが。
Q. 普段使用している生成AIと、そのAIを使用する理由を教えてください
服部 私は主にGitHub Copilotを使用しています。Visual Studio Code(以下、VS Code)の拡張として利用できて、コード作成もドキュメント作成も便利なんです。特に、インクリメンタル(段階的)に文章を調整できる点が気に入っています。GitHub CopilotではClaude、Geminiなども使えるので、用途に応じて使い分けられるのが魅力ですね。
森崎 文章書きや表現方法に関して使うことが多いので、Azure OpenAI、ChatGPT、Claude、Geminiを使っています。モデルのアップデートによって結果が変わることが多いので、まんべんなく使うようにしています。GitHub Copilotも使いますが、コードを書く機会が少ないので他より頻度は低いです。
Q. 今後リードクラス以上のエンジニアしか要らなくなり、ジュニアクラスは経験を積むこと自体が難しくなると予想しています。 ここについて、個人や組織としてはどのように向き合っていくとよいと考えられますか?
服部 重要なのは、生成AIを学習ツールとしていかに活用できるかというポイントですね。AIを使って学習効率を高められるので、好奇心旺盛に取り組めるエンジニアはAIから大きなメリットを得られると考えています。
森崎 生成AIがジュニアクラスの人の代替になるかっていうと、必ずしもそうではないと思います。ここでの代替は完全に置き換わることを指します。生成AIの出力結果が常に正しいとは限らない状況が続くのであれば、リードクラス、ジュニアクラスそれぞれの仕事の中でチェックは求められると思います。なので、手を動かす量は減るかもしれないのですが、チェックするための力量は同じように求められると思います。手を動かす経験は減るかもしれませんが、チェックの経験は同じか増えるのではないかと。
服部 組織としては、エンジニアのパフォーマンス向上を考慮した適切なツール選定と、使いこなせているかどうかの継続的なアセスメントが必要です。気づかないうちに十分に活用できていない、あるいは生産性向上の余地を見逃している可能性もあるので、組織としてそういった部分のケアも重要だと思います。
森崎 使われ方の変化とかモデルのアップデートとかで気が付くとちょっと変わっていることがありそうなので軽量で高頻度にアセスメントすることで効果が大きくなりそうですね。
Q. 今後のプログラマーに必要な技術は何か(AI活用含め)
森崎 基本的には変わらないけれど、生成AIを適切に使って効率化することでしょうか。
服部 その通りですね。プログラミングの基本的なスキルセットは昔も今も大きくは変わっていません。ただし、いくつか注意すべき点があります。まず、単にライブラリの使い方を知っているとか、表面的な知識だけではやはりプログラマーとしては不十分でしょう。実際のユースケースや、プログラミング言語やフレームワークに関する仕様の背景、それらが及ぼす影響など、より深い理解が重要になってきます。
特に、AIが判断できない領域での的確な判断力は、そういった個別の技術の深い理解や実務経験から培われるものです。ですから、基礎的な部分は一つ一つしっかりと積み上げていく必要があるでしょうね。
森崎 生成AIに作業を任せるとほぼ期待どおりの回答が得られると変わってくるかもしれないですね。
Q. GitHub Copilot が他のAI支援ツールと違うところを教えてください
服部 最大の特徴は、GitHubというプラットフォームと密接に統合されている点です。GitHub自体が開発者向けのプラットフォームですから、単なるコードエディタにおける支援だけでなく、開発ライフサイクル全体をAIでサポートできる環境が整っています。実際、そういった機能が次々とリリースされていますね。
Q. AI開発ツールでソースコード生成する際に、理想的な使い方や精度を上げるために必要な準備や注意すべき点を教えてください
森崎 『コード×AIーソフトウェア開発者のための生成AI実践入門』に書かれている内容はまさにこのご質問への回答だと思います。「本を読んでください」という回答でもいいのですが、もし可能なら代表的なものをいくつか挙げていただけますか?
服部 主なポイントとしては、まずAIへの適切な期待値を持つことが重要です。次に、トライ&エラーを重ねながら、自分がコーディングの主導権を保持すること。そして、AIの出力を観察しながら自己の成長につなげていくことですね。
少しメンタル面の話が中心になってしまいましたが(笑)、より技術的な詳細や実践的な内容については、ぜひ書籍をご覧いただければと思います。
森崎 簡潔なまとめをありがとうございます。服部さんの書籍のレビューアーとして、まさにこの部分が読み応えがあるところだと感じていました。
Q. Editor や IDE による差はどれぐらいあるのか? 今、AI 協働的観点でのベター環境は?(主にGitHub Copilotからの観点で構わないので)
服部 GitHub Copilotは現在、VS Code、JetBrains製品群、Xcodeなど、主要な開発環境に対応しています。コードの自動補完といった基本機能については、どの環境でもほぼ同様の体験が得られます。
ただし、より高度な活用を目指す場合は、私はVS Codeをお勧めしています。特にプロンプトエンジニアリングの観点から、きめ細かな制御が必要な場合には、VS Codeの豊富な設定オプションが役立ちます。
森崎 生成AIと一般的なチャットをしたいときがあると思うんですけど、そういうときはどうしたらいいんですかね?
服部 GitHub Copilot Chatを使うのが便利です。最近では、Claude、Geminiなど、様々な生成AIモデルにも対応するようになってきました。開発環境の中で直接対話できるので、とても使い勝手がいいですよ。
Q. コード生成に適したLLM(またはSLM)の選定のポイントはありますでしょうか?
服部 そうですね。現在は次々と新しいモデルが登場している状況なので、まずは実際に自分で色々試してみることをお勧めします。 特定のフレームワークに関しては、モデルによって出力精度に差が出る可能性があります。また、アルゴリズムやロジックを実装したい場合は、より高度な推論能力を持つモデルを選択するのも一つの方法だと思います。
実際の例を挙げると、GitHub Copilotでは用途によって異なるモデルを使い分けています。コーディング中の素早い自動補完機能では高速なレスポンスを重視したモデルを、一方でチャットではより正確な回答を重視したモデルを採用しているんです。
森崎 モデルのアップデートも早いですよね。最近だと。
ソフトウェアエンジニアリングの論文では、3年以上前だと生成AIを使った方法ではソースコードを学習させた専用のモデルが使われていました。たとえばCodeBERTのようなモデルです。今は汎用モデルでも同じかそれ以上の性能が出ているように思います。
服部 はい。ですので、開発者の皆さんには様々なモデルを実際に試していただくことをお勧めします。それぞれのモデルの特徴や強みを理解することで、プロジェクトに最適なものを選択できるはずです。
Q. AIコード生成とAIコードレビューで仕組みを作り、人間がコードをレビューしないという選択肢はないか?常に有識者がレビューできない環境においては一定の品質を保てるのでは?
森崎 レビューの本*2を書いているので私が先に答えさせてください(笑)。ハルシネーションが起こらない/少ないという前提だと、この選択肢は出てくると思います。現状では、生成AIが安定して適切な指摘ができるタイプの指摘を見つけるところからはじまるんじゃないかと思います。ここでのタイプというのは指摘の分類でレビューの着眼点とも言い換えることができます。それが見つかれば生成AIで代替できると思います。私もどういうタイプがあるかを研究テーマとして探っています。それがわかるようになれば、人間のレビューアーがそのタイプ以外の指摘がないか確かめるというやり方になると思います。現時点ではまだ確立されていません。
服部 大規模言語モデルやその出力を直接活用したい場合は、やはり人間によるレビューが必要になってくると考えています。ただし、ローコードやノーコードのソリューションを活用するなど、ある程度の制約を受け入れる場合であれば、かなり限定的なレビューで実装可能な領域も出てくるのではないでしょうか。
お二人よりメッセージ
真剣に考えておられる質問が多くて、回答を考える上で服部、森崎とも気付きが多かったです。イベントでご質問、ご参加いただいた方ありがとうございます。生成AIに限らないことではありますが、こうした新しい技術をうまく使いこなしていきたいですね。