こんにちは。てぃろです。
今回は話題になって仕方がないAIについて使ってみた感想などを書いていきます。
１人ユニコーンの可能性 = １人エンジニアチームの可能性
Youtubeを見ていると広告などでホリエモンがよく出てきます。ホリエモンがそのどこかで「AIで１人ユニコーンが作れるよ」というようなことを言ってました。
ユニコーンは、スタートアップのユニコーン企業のことだと思いますが、その規模の会社を１人で作れるくらいには生産性が上がる可能性があるよね、と言ってるものと思います。スタートアップを経験した身としては、ユニコーン企業になるには血反吐を吐いて開発以外もやらなきゃいけないと思うと、少しハードルあるなと思ってしまいます…。
しかしながら、ここで言いたいのは「１人でユニコーン企業になりうる品質のプロダクトが作れるくらいにAIで生産性を高めることができるよ」ということだと思います。つまり、１人で従来の数人のエンジニアチームと同等のプロダクト開発ができるようになるよね、ということです。
そこで今回は１人エンジニアチームをAIと一緒に作ることを目指して、DevinとCopilotエージェントを使ってみたので、その感想や得たノウハウの一部をご紹介したいと思います。
DevinとGitHub Copilotエージェントの違い
DevinとCopilotエージェントが何かということの解説は、以下の公式やGoogle検索やAI検索などに任せるとして、ここでは私が今回使ってみて思う使い分けなどを書いてみたいと思います。
前提
今回開発していたプロダクトは個人プロダクトで、使用言語はGo言語、インフラはCloud Functionsがメインです。IaCとしてTerraformを使用してはいますが、非常に小さなプロダクトになります。
GitHub Copilotについては無料版を使用しています。使用できるモデルは記事執筆時点で、Claud 3.5、GPT-4.1、GPT-4oですが、基本的にはGPT-4.1を使用しています。
Devinは開発環境の準備が必要
GitHub Copilotエージェントの場合は、現在の開発環境にそのまま入ってくれるのでエージェントを使用するための環境準備は必要ありません。
Devinに関しては、Devinが開発を実施するためのVirtual Machineを用意してやる必要があります。つまり、Devinくんに開発マシンを用意してあげるということですね。
必要なソフトウェアやコマンドのインストールを事前にしてあげないと、必要な開発コマンドが使えない、または都度自分でインストールするので、その分Devinの稼働時間が増えてコストが上がるということになります。Virtual MachineはUbuntuなので、そこで実行できるコマンドで環境を用意しましょう。
この点においては、少しDevinは面倒な部分もありますが、あとのことを考えれば特に大きなデメリットというわけではないでしょう。
GitHub Copilotエージェント x Windowsの場合、Gitbashを使おう
GitHub Copilotエージェントでも、Windowsで使用する場合には少し必要になるケースがあります。
GitHub Copilotエージェントはたまにディレクトリを作成するなどでコマンドの実行をしようとしますが、そのコマンドはlinuxコマンドであることがほとんどです。
GitHub Copilotエージェントはターミナルを自分用に開きますが、それは既定値のターミナルが使われます。PowerShellやコマンドプロンプトが既定値の場合にはlinuxコマンドを実行しても失敗してしまいます。すると、Windows環境であることを考慮してPowerShell用のコマンドを作ってくれますが、それでも結構失敗します。
そのため、特別な理由がない限りGitHub Copilotを一緒に使うときには既定値のターミナルをGitbashにしておくのがよいでしょう。Visual Studio Codeの場合、以下を参考にしてみてください。
実装力と調査力はほとんど一緒
GitHub Copilotエージェントでは使用するモデルが複数あるので、一概には言えないところもありますが、Devinと比較しても実装力や調査力はほとんど一緒に思います。
主観的な感想ですが、出力されてくるコードの品質は大きな違いがなく、少し意図と違ったり、手作業が必要になったりということは変わりません。Devinがジュニアエンジニア相当というのは実感値としても大体あってます。
CopilotエージェントのほうはAIモデルを複数使えることからモデルによっては現在でもDevinよりうまくいくケースはあります。人間が目の前にいるので細切れに指示したり結果を見たりできるのも大きいです。AIモデルがどんどん増えますし、いろんな開発元のモデルを使える分、問題解決能力が上がりやすいような気がします。
一方、Devinについてもかなりの速度で開発が進んでいるそうなので、また１年以内に3.0が出るかも知れないですから、それに期待ですね。
ペアプロ相手のエージェントと、ホウレンソウが少し苦手なDevin
GitHub CopilotエージェントとDevinの最大の違いは、ご存知の通り、一緒にやるか放置するかの違いです。
GitHub Copilotエージェントの場合には、普段のエディタの中で動いてくれるので、いわゆるバイブコーディングと言ってもいいかもしれないですが、私のイメージではAIとのペアプロというほうがしっくりきます。
私がペアプロのナビゲータで、エージェントがペアプロのドライバーという感じですね。私が指示や示唆を出して、エージェントがコーディングをする。たまに私が動かしてみたり手直しをしていく。そんな進め方ができるようになりました。
また、エージェントはファイルやディレクトリの作成や削除のコマンド実行について都度承認を求めてきます。それが面倒ではあるものの、勝手にファイルを消されたりしない安心感もあります。ホウレンソウできすぎなくらい。
一方、Devinの場合はタスクを任せるとやっておいてくれる自律駆動型です。タスクとなるプロンプトを渡せば自分で勝手にやってくれるので楽ちんです。
しかし問題もあります。Devinくんは非常にホウレンソウが苦手です。ドツボにハマって何度も同じ修正を繰り返してしまうなど、無駄に時間とコストを浪費してしまうケースがあります。ホウレンソウできてない…。
例えば、単体テスト実装において、外部接続が必要となるケースの実装を進める中で、認証が必要なケースの場合に認証が通らないというだけなのになにかしら頑張ってしまってました。実際、そこでACUが尽きてしまうので結構お金が無駄になってしまいました…。
lintの修正でも、エラー文を見れば未使用のimportを消せばいいだけとすぐに分かるものなのに、それもできずに別の修正を繰り返してしまうことがありました。様子を見ていたので途中で明確に指示してあげた結果その通りの修正をしましたが、完全に放ってはおけないというのが今の状態かなと思います。
もちろんプロンプトをもっと練り上げるなどの対策はあると思いますが、それだとプロンプトエンジニアリングが必要になるのでそのコストを考えると本末転倒なようにも思います。どこにコストをかけるかという塩梅が難しいところです。
また、DevinはCIを成功させる、などのわかりやすいタスクの完了条件がないとうまく動けないみたいです。逆に言えばそういう完了条件が明確なケースが得意なので、使い所はそういうところになりそうです。
GitHub Copilotエージェントが安上がり！Devinも月額20$からに！
今のところ、GitHub Copilotエージェントは無料でも使えますので、Devinを使うよりも安上がりです。しかし、プランを上げれば他のもっと強力なモデルや様々な機能を使えます。魅力的ですよね…。
Devinも最近のアップデートで月額20$から使えるようになりました。なので今回こんな検証をプライベートでやっていくことができたわけですが、未だうまく使えてる感じもないので、費用対効果でいうとまだメリットを感じきれてません。
もっと良い使い方をできるようになれば、コストメリットを感じることができるのかなという期待感はあります。3.0へのアップデートで機能だけでなく価格もよくなることに期待したいところです。
まとめ
ここまで見てきて思うのは、安野さんも言ってましたが、エージェントがスケールアップ、Devinはスケールアウトというのは適切な表現だなということです。
ペアプロ相手のエージェントは、自分の開発効率を上げてくれる。Devinはエンジニアがもう一人いるような形ですからね。また、Devinは10セッションくらいは作成できるらしいので、極めれば1人エンジニアチームとして11人分の働きができるようになるかも知れないということです。
とはいえ、ジュニアエンジニア10人に指示をするだけでも結構大変ですから、プロンプトエンジニアリングをするようなことを考えると実際のところどこまで扱い切れるのかはまだまだ未知数ですね。
Devinについてはまだまだ使いきれてないと思うので、以下を試していきたいと思ってます。
- PRを作成したら、自動でPRレビューしてもらう
- GitHub Projectで管理するissueで指示して、実装からPR作成までやってくれる
以下の記事を見るとPRレビューができるように設計可能ということですが、それをPR作成と同時に自動でやってほしいんですよね。
あとは、1人エンジニア「チーム」というからには、プロダクトマネジメントとプロジェクトマネジメントが必要です。Devinへの指示で毎回Slackに指示を書いていては、指示した内容も流れてしまいます。
Devinはissueとの連携もできるみたいなので、その辺の使い心地を試してみれば、Devinをエンジニアとしつつ、自分はテックリード兼プロダクトマネージャーとして振る舞えばいいという世界観に近づくなと思っています。
