開発全般に生成AIを使ってみて思うこと

この記事は、「ヌーラボブログリレー2025 夏」のTechブログ 6日目の記事です。

はじめに

みなさん、生成AIを使っていますか？ 自分はここ最近、様々な場面で生成AIを試しています。その中で、生成AIが得意なこと、不得意なことが見えてきたり、色々と思うところも出てきたので、この機会に一度まとめてみようと思います。

生成AIを使った開発、どんなのやってきた？

ここでは、実際に自分が生成AIを使ってどのような開発を行ってきたのか、具体的な事例を挙げていきたいと思います。

ChatGPTでちょっとしたPerlスクリプトを書く

現場で自分があまり詳しくないPerlスクリプトを書く際に、ChatGPTにサンプルを書いてもらいそれを参考にしながら目的のスクリプトを実装しました。

具体的にはPerlで書かれたアプリケーションからSlackに送る必要が出てきたので、使用しているPerlモジュールを使用してサンプルを書いて欲しいとChatGPTに依頼し、生成されたコードを参考にしながら実装しました。ただし、生成されたサンプルでは非推奨のAPIを使用していたり、APIドキュメントに書かれた内容と異なる部分があったりしたので、都度ChatGPTとやり取りしながら、最終的に動くサンプルに仕上げました。

サンプルを生成してもらったあとは、実際にアプリケーションに組み込んで動作確認を行い、必要に応じて修正を加えました。最終的には無事にSlackに通知が送れるようになりました。自身でAPIドキュメントを読み解きながら実装するよりも、ChatGPTにサンプルを書いてもらう方が、遥かに効率的だと感じました。1週間程度と見込んでいた作業が2日ほどで完了し、開発体験が大幅に向上しました。

Backlog MCP serverを介して、Clineで実装計画からPR作成まで行う

ある機能について追加の開発が発生した際に、途中までチームメンバーに課題を振り分けて実装を進めていました。しかし人が十分に実装できる情報があれば、生成AIを使用して実装を手早く終わらせられるのでは？と仮説を立てて、最終的にClineによってBacklogの課題から実装計画を立ててもらい、最後PRを作成してもらうところまで行いました。ざっくり流れとしては以下のような感じです。

• 人のターン
  • Backlogの課題を立てる
  • チームメンバーで課題の詳細をリファインメントして、人にとって必要な情報を取り揃える
• Clineのターン
  • Backlogの課題をもとに、実装計画を立ててもらう
  • 実装計画をもとに、またすでに実装されているコードを参考にしてもらって実装を行う
  • ローカルでのレビューが終わったのち、PRを作成してもらう

情報を詳細化するところは、各チームメンバーの前提条件を合わせることを目的として人が行うこととしてます。これ自体はチームとしていつも行っていることなので特別に導入されたものではありませんが、ここで取り揃えた情報によってどのチームメンバーもClineに同じ情報を与えられるようにしています。

Backlogの課題情報は途中まで人がClineにCopy&Pasteで渡していたんですが、Backlog MCP serverが 公式で！ 登場したことで、よりスムーズに情報を渡せるようになりました。

全体として実装についてはかなりうまくいきました。当初の見立て通り、ある程度の情報が揃っていたり、実装するコードのパターンがある程度決まっているような場合には、生成AIを使うことでかなり効率的に実装ができることがわかりました。一方で、非常に大きなファイルを編集する際にはうまく扱えなかったり、テストコードの実装精度が低かったりと、課題も多いと感じています。前者についてはコードベースが適切にモジュール化されている必要があり、後者についてはテストが目指すべき状態（期待値）が曖昧であることが原因だと考えています。

gemini cliでコード調査を行う

なんらかの障害から原因調査した結果、コード内で伝搬するデータがどこが由来なのかを調査する必要が出てきました。BacklogはScalaで実装されており、型をたどることで比較的調査しやすいのですが、今回は調査対象のコードベースが非常に大きかったため、gemini-cliを利用しました。

実装の詳細としてイベント駆動のアプローチをとっていることを知っているため、gemini-cliに対してあるイベント群が発生した際に伝搬するデータがどこからきたのかを調査しました。結果的にうまくいったのですが、要因としては以下のようなことが挙げられます。

• 元々の設計としてイベントと一対一対応したデータのクラスを定義していたので、そもそも人も調査しやすい構造になっていた
• 一度に全てのコードを調査するのではなく、あるクラスに対応したイベントは何か、次にそのイベントに格納されたデータはどこから発生するのか、というように段階的に調査を行った
  • いわばある種のペアプロような形で進めたので、調査の方針を都度見直しながら進められた

おそらくgemini-cliを使わずに調査した場合、自分の見立てでは4営業日ぐらいはかかるだろうと思いましたが、使用することで調査開始した日には調査結果をまとめることができ、また追加の内容が来ても即座に結果が返ってくるので、かなり効率的に調査ができました。

gemini cliでE2Eテストを移植する

ここ最近取り組んでることの一つに、gemini-cliを使用してSelenium+JavaのE2EテストをPlaywright+TypeScriptに移植するというのがあります。これも元になるコードが存在しているので、ベタ移植するだけでもすぐに終わるのでは？と思い、取り組んでいます。

現状かなりうまくいっている状態で、現在Selenium+Javaにある全てのテストケースを移植完了しています。動作できる状態になるまでは取り組み始めて数時間でできてしました。ただ、テストの不安定さ（flakeyさ）を解消し、安定動作させるという観点では、レンダリング完了を待つ処理（wait）を追加する必要がありました。このあたりは、Playwrightの実装方法を学習する意味も込めて、AIとペアプログラミングのような形式で進めました。こういった形で進めた移植時に発生したこととして、修正がうまくいかないとドツボにハマっていく様子が観察できたので、その場合は外からレンダリングのhtmlの構造情報を与えてみたり、Playwright MCP serverを導入して実際にgemini cliにE2Eテストと同様の操作をマニュアルでやってもらいながら、改善点を考えてもらうなどして、軌道修正していきました。また、gemini-cliに限りませんが、長時間やりとりを続けると、一度立てた計画から逸れて途中で処理が止まったり、脱線したりすることが増える傾向にありました。現状今の生成AIではしかたないところもあり、都度続けるよう指示したり脱線した場合は元のプランに戻るよう促すことが多かったです。

一つできると面白いなと思ってベタ移植と合わせて取り組んだこととして、Playwright MCP serverを使用してgemini-cliによるマニュアルテストを行ったのち、それをE2Eテストに落とし込む、というのを試してみました。一つ単純な例として、Backlogのプロジェクトを作成して削除するという単純なシナリオを試してみたところ、うまくいきました。もっと複雑な例も試してみたいところです。

結論

結論。箇条書きで書いていくならこんな感じでしょうか。

• 生成AIで開発効率を上げるためには、結局のところ技術的な筋肉が必要、ないとプロダクトを継続的に開発していくのは難しい
• 特に大事なのが、ソフトウェアアーキテクチャーなどに代表されるような、システム全体を俯瞰して捉える力
• 上記を他者に伝えるための手段。例えばADRを書くことが個人にも、組織的にも根付いているか

元も子もない話かもしれませんが、生成AIによる効率化を論じる前に、まず開発者自身の技術力、いわば「技術的な筋肉」がこれまで以上に求められます。そして、それを組織として活用するための環境がしっかりと整備されている必要があります。これは生成AIに限らず、組織としてプロダクトを開発していくために必要であり、以前から言われていたことでもあります。つまりそういう環境が整っている組織にいる人は、生成AIで爆速開発！とかが実現できるわけですね。

この辺の話はここ最近至るところで言われていることでもあり、特に目新しい話ではないと思います。ただ過去に人工知能の研究室であれこれやっていた人間として、人であれAIであれ上記のような話が大事なのではないかとぼんやり考えていたことが実際に今のところ重要だろうとある種の確信を持って言えるようになったのは、個人的には結構大きな収穫でした。

一方でサクッとスクリプトを書いて、ちょっとした作業を自動化するとか、生成AIは独壇場だなと感じています。今まであれば、ちょっと時間がかかるのでめんどくさいなと思っていたことが、ある程度の精度であればすぐに目に見える状態に持っていけるというのはかなり大きな変化であると感じています。