生成AIをソフトウェア開発現場に取り入れる取り組みが広がっていますが、実際にやってみると現場がかえって疲弊してしまうなど、さまざまな問題に遭遇します。第3回は、開発へのAI導入で発生しがちな課題と個人、組織レベルの対応策を説明します。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
生成AIの業務活用についてのさまざまな悩みに答える本連載。今回取り上げるお悩みはこちらです。
生成AIをソフトウェア開発に取り入れようとしているが、逆に面倒が増えそうだ。どうすればいいのか
「生成AIを組み込めばソフトウェア開発効率大幅アップ!」
ソフトウェア開発への生成AI導入がブームになっています。しかし、実際に導入した結果、予期せぬ課題が現場で出ることもよくあります。生成AIを導入したことで楽になるはずが、かえって作業が増えてしまい現場が疲弊してしまう。
そのような結果を避けるために、本記事では生成AIをコーディングに利活用する上で発生しがちな課題と、個人・組織それぞれのレベルでの対応策をご紹介します。
「生成AI」という言葉が世に出てから数年経ち、今ではわれわれの日常生活にまで浸透しています。
中でもソフトウェア開発と生成AIとの親和性は非常に高く、多種多様な開発サポート用生成AIサービスが登場しています。GitHubとOpenAIが共同で開発した「GitHub Copilot」、Googleが提供している「Cloud Code」をはじめ、世界中の企業が提供しています。
今や、生成AIをソフトウェア開発に組み込むのは当たり前の世界になってきており、現場のエンジニアたちはこの「新しい当たり前」に対応するために日々奮闘しています。
では、ソフトウェア開発現場では生成AIをスムーズに導入して簡単に効率化できているのでしょうか? 残念ながらそんな甘い話はありません。開発者たちはさまざまな課題に直面しています。
よくある例を幾つか取り上げてみます。
生成AIは、簡単な入力からでも多くのソースコードや設計書を作成してくれますが、出力の全てが正しいわけではありません。必然的に、生成AIの出力結果が正しいかどうかをチェックする人間が必要になります。しかも、生成AIは「もっともらしい結果」を出力することに長けているため、誤りを発見するには有識者が必要になります。現場における有識者の不足は昔からソフトウェア業界における深刻な課題の一つですが、生成AIの登場によってその深刻さが増しているのが現状です。
では、有識者がきちんといる現場であれば問題はないでしょうか? 残念ながらそうではありません。確かに、生成AIによってコード作成速度は劇的に上がります。しかし、最終的にチェックするのが人間である以上、そこで渋滞が起きてしまいます。今まで1日10件のレビューを実施してきた人間に、これからは1日100件レビューしてくれと言ってもできるものではありません。
生成AIを現場に導入するときに、最初からプロンプトレベルでの厳格な運用ルールや利用方法が策定されていることはまずないでしょう。結果、生成AIに入力する内容や求める出力結果の内容は担当者依存となり、チーム内で統一したアウトプットを作成することが困難になります。
ここまで紹介してきた通り、生成AIを現場に取り入れるためには多くの課題があります。しかし、課題があるからといって生成AIの導入を諦めてしまっては、せっかくの業務効率化のチャンスを逃してしまいます。そこで、ここからは開発現場としてどう対応していくべきかをご紹介したいと思います。まずは、個人レベルでできることから紹介します。
生成AIに要求すれば、とても大きなソースコードを一度に出力させることも可能です。しかし、一度に出力させる内容が大きくなればなるほど、誤りが発生したり詳細な部分をごまかしてきたりします。1回のプロンプト入力で全てについて正解を得ようとすると、いわゆる「生成AIガチャ」のような状態に陥り作業が止まってしまうリスクがあります。
※生成AIガチャとは、生成AIのもっともらしい回答とその予測不可能性によって、「いつかは『当たり』が引けるはず」という感覚にとらわれてしまうこと
これを避けるためには、生成AIと1回のやりとりでのアウトプット範囲を絞ることが重要です。特にGitHub Copilotのようなソースコード用の生成AIを利用する場合、エージェント側をリセットしたとしても一度出力したソースコードはきちんと残ってくれるため、何度も生成AIとやり取りして少しずつソースコードを拡張していく方針の方が、生成AIが誤る可能性は低いですし、誤りを人間が発見しやすくなります。
生成AIに出力させたソースコードは人間のチェックが必要になります。しかし、ソースのみの段階でチェックしようとしても、「どんな条件でどんな動きをするのか」「どういう仕様になっているのか」を把握するのは困難です。この対策として、生成AIにソースを作成させた直後に、対応するテストコードも作成させることをお勧めします。
テストコードはソースの仕様を表すものであり、「生成AIが考えている仕様」を表現するものになります。ソースとテストコードを合わせてチェックすることで、人間の考えている仕様と合致しているかが判別しやすくなります。また、一部のテストコードを人間側で先に作っておくのもお勧めです。人間が作ったテストコードがOKになるソースを、生成AIに作成させることにより、上で紹介したアウトプットを絞る効果が期待できます。
これは生成AIの利用方法というより、利用上の注意事項になります。特に、一度機能を完成させて別の機能を作る場合や、既存機能を拡張させる場合には特に注意が必要です。生成AIの出力するソースコードは、基本的には言語のベストプラクティスに従って出力される保守性の高いソースになりますが、あくまで「今、入力として渡された情報の範囲」「今、生成AIが出力したソース範囲」の中でのベストプラクティスになりがちです。そのため、機能追加が進んでいくに従って、似たようなクラス、メソッド、処理があちらこちらに散らばってしまうことがあります。この状態で生成AIに「ソース全体を読み込んでリファクタリングして」と頼んでも、規模が大きいと全てのソースを見てくれません。全体最適な設計については人間側で考えて、リファクタリングが必要であれば手動で実施するか、生成AIに対してより具体的な指示を出す必要があります。
Copyright © ITmedia, Inc. All Rights Reserved.