2022年11月にリリースされたChatGPTをきっかけに、生成AIを利用しはじめた個人や会社も多いだろう。
本記事では、「Developer eXperience Day 2024」（主催：日本CTO協会）にておこなわれた講演を紹介する。株式会社リンクアンドモチベーション ソフトウェアエンジニア 鵜木 義秀さんが、「生成AIに振り回された3か月間の成功と失敗」をテーマに講演した。
生成AIを用いた具体的な事例やアイデアについて、成功・失敗談を包み隠さず発表してくれた。
鵜木 義秀 さん
株式会社リンクアンドモチベーション ソフトウェアエンジニア。2017年にシンプレクス株式会社に入社。FX・仮想通貨アプリのフロントエンド開発やデザインに従事。2020年に株式会社リンクアンドモチベーションへ入社し、フロントエンド領域の機能開発に取り組む傍ら、フロントエンド横断組織を立ち上げて開発生産性の向上に取り組む。2023年より、イネーブリングチームに所属。影響力を開発組織全体へ拡大し、開発者体験・開発生産性の向上に尽力している。
目次
登壇テーマを生成AIに決めた理由
僕はリンクアンドモチベーションのイネーブリングチームに所属し、各プロダクトを横断して生産性の向上に日々取り組んでいます。実は3か月前までは、生成AIに対してどちらかというと否定的なスタンスでした。たとえば、「プロンプトエンジニアじゃないし」とか「生成AIを使わなくてもユーザーに価値のあるアプリケーションつくれるし」みたいなことを言っていました。
今回の登壇の話をいただいたタイミングでCTOと一緒に食事をする機会があり、そこで登壇テーマについて相談をしたんです。なにを思ったのかCTOは、生成AIにポジティブではない僕に対して、ライブラリのアップデートを生成AIで解決した事例を勧めたんです。
「生成AIは、わからないから難しい」と言ったんですけど、「『わからないからやらない』は、やらない理由にならない」と言われ、その言葉が僕の心に響きました。
それをきっかけに、生成AIをテーマに登壇することを決めました。今回のセッションは、2つの事例とまとめの3段構成になっています。
事例1 ライブラリのアップデート工数削減
1つ目に紹介する事例は、OpenDevinでライブラリアップデート工数の削減に取り組んだ事例です。
OpenDevinを一言で表すと自律的に機能するAIアシスタントです。同じ環境にあるソースコードを扱えます。ローカルで起動した場合はローカルにあるソースコードを扱えて、EC2で起動した場合はEC2にあるソースコードを扱えます。それとは別にLLMがあり、OpenAIのAPIやClaudeのAPIを通じて扱う形です。
OpenDevinは左側にあるグレーのチャット欄から、人間の出す指示とソースコード情報を踏まえて、LLMに入力を投げます。その結果、変更されたソースコードの情報やテストの実行結果を見て、再度アクションを考えてくれます。
このとき必要に応じて、再度LLMを使うかどうかの判断を自律的に実行してくれるんです。そして、途中結果や完了報告を人間に返してくれます。
以前は人間が手動でおこなっていたライブラリのアップデート時に必要となるコードの修正を、OpenDevinにお願いできないかなと思い、今回取り組んでみました。
ライブラリのアップデート工数削減に取り組んだ結果
取り組んだ結果を一言で表すと、失敗でした。成功率は5％以下という結果です。ただ、この数字は3か月前くらいに検証した結果となります。生成AIは3か月で大きく状況が変わりますので、この数字は現在とは異なる可能性が高いです。
プロンプトを送ったあとに想定外の挙動をしたときは、チャットを通じて修正依頼をする流れで検証を進めていました。失敗した原因は、アプリケーションコードに関する情報が不足していたからです。
たとえば、コーディングルールや技術スタック、レイヤー構造や依存ルールが欠如していました。行動に関する指示がなかったので、OpenDevinは自分で必要な情報を探し、「この辺りの修正をすればいいのかな」と修正して、僕にレビューを投げます。
そこで、僕は「ここがコーディングルールに従っていないですよ」と指摘をします。でも、OpenDevinからすると、そんなことは指示になかったので「聞いてないよ」となるわけです。
3か月前の生成AIにくわしくなかった僕は、OpenDevinやLLMを活用して、この問題をうまく解消できませんでした。
いまとなっては当たり前かもしれませんが、このときに「生成AIを使う際には、具体的に指示することが重要」という仮説が生まれました。
この仮説を持って、アプリケーションコード情報に関しても具体的に指示したプロンプトをつくり直し、再度OpenDevinに作業依頼しました。その結果がこちらです。
プロンプトをつくり直して再挑戦した結果
また失敗です。成功率は、ほとんど変わりませんでした。なにが問題だったのかを考えると、アプリケーションコードの情報がまだ不足していました。というのも、このときに僕が扱っていたソースコードベースの問題が大きかったんです。実は、このときに扱っていたプロダクトは、最初にリリースされてから6-7年が経っていました。明文化されているコーディングルールや依存ルールなどから逸脱しているものが結構あったんです。
OpenDevinは指示と違うアプリケーションコードの情報があるから、よしなに考えて修正してくれたんですけど、それが僕の期待値と異なっている状態が発生しました。
今回の取り組みは、3か月という期間を決めて試験的におこなわれました。なので、より多くのトークンが入力できるLLMを選定したり、それにともなうセキュリティの問題を検討したりできなかったんです。
そこで、アプリケーションコードに関する情報を広く具体的に指示することは諦め、影響範囲をある程度特定できるESLintのIgnore解消に作業対象を変更しました。
事例2 ESLintのIgnore解消工数の削減
2つ目の事例を紹介します。当社では、以前からESLintを活用しており、Ignoreの設定をされているファイルが100くらいあったので、これを生成AIに解消させようと考えたんです。
その際、利用するツールをOpenDevinからDifyに変更しました。取り組む対象が変わり、不確実性が小さくなったことで自律性が活かしにくい状況になったためです。
Difyにはワークフローの概念があり、そのなかでLLMを扱ったり外部のREST APIを実行できたり、ちょっとしたスクリプトを実行できたりします。ただ、スクリプトの処理をする際に扱えるライブラリのパターンは限られています。
今回はソースコードエディットサーバーという、ソースコードの編集やGitHubにプルリクエスト作成するアプリケーションを別途用意しました。Difyはワークフローのなかから、ソースコードエディットサーバーのAPIを通じ、コードの修正やGitHubのプルリクエストを作成するといった処理になります。
やっていることはシンプルです。まずは修正対象となるGitHubのリポジトリをチェックアウトしていきます。そのなかから、Ignoreの解消対象となるファイルを取得します。この際にエラーハンドリングして、失敗した場合には処理を止める分岐にしました。
次にIgnoreの削除とESLintの実行をし、その結果を確認します。
真ん中にある赤枠の分岐では、Auto Fix ModeでESLintの実行をしています。ここで修正が完了した場合には、プルリクエストを作成してワークフロー終了です。
オートフィックスモードでの修正が完了しなかった際には、LLMによる修正をおこない、プルリクエストを作成します。
こうしたワークフローを使って取り組んできた結果がこちらです。
ESLintのIgnore解消工数の削減に取り組んだ結果
成功率が50％以上という数字が出て、ようやく成功と言える結果になりました。5分程度の時間で1PRが作成可能になったのは、すごくよかったなと思う点です。
この結果をもって、「生成AIを使う際には、具体的に指示することが重要」という仮説検証を完了させました。
ただ、成功したにも関わらず、2つ目の仮説を生み出したトラブルが発生します。それが、「レビューコストの問題」です。
5分に1PRの作成が可能になったので、1時間に12PRをつくれるようになりました。でも、それだとエンジニアがパンクしてしまいます。そこで、20分に1PR程度にしようと考えました。つまり、1人のエンジニアが1時間に3PRくらいのレビューならパンクしないだろうと考え、運用を試してみたわけです。1PRのレビュー工数は2-3分、長くても5分くらいと予想しました。
結果、1PRのレビュー工数に10-20分かかるという状況になりました。それだとレビューだけで1日が終わってしまう、困った状況になってしまったんです。
なぜこうなったのかを確認すると、「生成AIによる修正はどこか不安になるため、慎重にレビューしたい」というレビュアーの方が結構いたんです。信用できないがゆえに、ローカルで一応動作確認するという運用を見かけました。
ヒアリング結果から見えてきた2つのポイント
この、「生成AIによる修正はどこか不安になる」という部分をもう少し掘り下げたヒアリング結果から、2つのポイントが見えてきました。
1つ目は、「人間には期待値があるが、生成AIにはない」です。たとえば、「◯◯さんが修正したなら、おそらくこの辺は大丈夫であろう」といった期待値が人間に対してはありますが、生成AIに対してはありません。
2つ目は、「生成AIは実装者として責任を取ることができない」です。前提として誤解していただきたくないのですが、当社のエンジニアはコードレビューに対して責任を持っています。そのうえで、レビュアーとしての責任感がいつも以上に強くなりました。
これらの情報から生まれたのが、「生成AIを扱う際は、対人間以上に信頼度を高めるための工夫が必要かもしれない」という仮説です。
この仮説を検証するために、2つのソリューションを考えました。1つ目は「作業プロセスが間違っていないことを証明して、信頼度を高める」。2つ目は「十分にテストが実施されていることを証明して、信頼度を高める」です。この2つの信頼度を高める工夫については、今日までに効果を検証できませんでした。申し訳ございません。
仮説検証の結果については、当社のテックブログなどで公開したいと思っています。
まとめ 成果と学び、今後取り組みたいこと
本日までに得られた成果として、1ファイルの修正にかかる工数が20分から5分に削減されています。開発者体験は、これまでの能動的に修正するものから、受動的にプルリクエストを確認するのみに変わっていく兆しを見せています。
個人的な所感として、能動的にリファクタリングするのはメイン業務とのスイッチングコストもあり、心理的に抵抗を感じることが結構ありました。それが、受動的な体験に変わったことは、開発者体験としていい方向に進んでいると感じています。
ただし、重要なのはこれからです。今回の取り組みだけを見ると、インパクトは結構小さいと思います。重要なのは経験やナレッジをしっかりと転用して、次の対象を自動化していく仕組みづくりです。
たとえば、TypeScriptへの移行やUnitテストカバレッジの向上、リアーキテクチャにともなう横断的なリファクタリングなどの自動化がポイントになります。検証した内容では、これらの取り組みを実現することは難しいので、今後も引き続き検証していかなければなりません。
今回、このような機会をいただいて生成AIを活用した結果、その有用性を知りました。これまで解消できなかったことを解消できるような、希望に近い可能性を感じています。
生成AIに限らず、エンジニアであれば新しい技術が登場したときに、触ってみて初めてわかる発見があると思います。3か月前の僕のように抵抗を持っている人もいると思いますが、今日のセッションを通して生成AIを活用していただきたいです。
取材後記：貴重な現場の失敗談
今回のセッションで、鵜木さんは生成AIの取り組みについて発表してくれた。よくある成功談とは違い、赤裸々に失敗談を話してくれたことはとても貴重だ。失敗にこそ再現性があると思うので、共有してくれることで失敗を避けられる。
「生成AIを扱う際は、対人間以上に信頼度を高めるための工夫が必要かもしれない」という仮説については、現在検証中と話していた。リンクアンドモチベーションのテックブログなどで公開される予定とのこと。どのような結果になったのか、ぜひチェックしていただきたい。
（取材／文：川崎博則）
