こんにちは。ファインディでソフトウェアエンジニアをしている栁沢（@nipe0324a）です。
ファインディでは、25年1月末から転職開発チームにDevinがジョインし、現在2ヶ月ほど一緒に働いています。
Devinのアウトプットとして、プルリクエストのマージ数は「2ヶ月で197件」、「1日あたり平均5.2件」とバリバリ開発をしてもらっています。
Devinの2ヶ月の費用としても約30万（$2,000 = 1,000 ACUs）ほどで、比較的簡易なタスクかつ一部サポートは必要でしたが十分なアウトプットを得ることができました。
今回の記事では、Devinに効果的にアウトプットを出してもらうために
- 試して上手くいったところ
- 上手くいかなかったところ
- 具体的なTips
などをご紹介できればと思います。
ちなみに、ファインディ内でのDevinの利用状況は現在検証中の段階であり、まだ「開発生産性が劇的にあがりました！」といえる状況ではありません。
Devinの１つの利用事例として楽しんでいただければ嬉しいです。
Devinはどこまでできる？
Devinを2ヶ月試した結果として、「ジュニアからミドルレベルのタスクを概ね任せられそう」という感触を得ています。
難易度が易しい〜普通ぐらいのタスクにおいて、要件把握・設計から動作確認までできるポテンシャルを感じています。
しかし、Devinの開発結果に対する品質担保は人の手で行う必要があるため、業務範囲を全部任せるということはまだできません。
そのため、「生産性が大幅にあがりました！」というにはもう少し時間がかかると思っています。
生成AI界隈の動きは激しく、今後のDevinの精度向上やスピードアップのネタは尽きないので、楽しみに待ちながらDevinと引き続き働いていきたいです。
- Devinの継続的なバージョンアップ（現時点では1.3）
- LLMの応答速度や性能向上（最近だとClaude 3.7 など）
- 拡散モデルなどによるコード生成の大幅な高速化
- マルチエージェントの高度化
- などなど
試行錯誤しつつDevinで上手くいったこと
小さなタスクから依頼して試行錯誤しながら、Devinがチームに少しずつ慣れていけるように進めていきました。
基本的な開発ルールやプロセスに慣れてもらう
Devinの開発環境は、次のようになっています。
左側に「Devinと人がやりとりするチャット欄」、右側に「エディタ」、「ターミナル」、「ブラウザ」、「プランナー」があります。
また、Devinへのタスク依頼は、「DevinのWeb画面」、「Slackメンション」、「VS Code」、「API」から実施できます。
チームにJOINしたばかりのDevinはチームの開発ルールを知らないので、まずはチームの開発ルールやプロセスに慣れてもらうことから始めました。
具体的には、システム概要、リンターや自動テストの実行方法、コミットメッセージやプルリクの書き方など覚えていく必要があります。
そのため、文言変更や軽微な改修を通して、開発ルールを教えていきました。
Devinは作業のやり取りを通してKnowledgeという形でルールを学んでいきます。
Knowledgeは特定の条件のときに参照されるプロンプトで、Knowledgeとして学んだルールを次の開発で活かしていくことができます。
次のようにKnowledgeとして「コミット作成」「PR作成」「テスト実行」といったチームのルールにそった開発ができるようになりました。（たまに無視することもありますが...）
開発中に見つけた軽微なタスクを任せる
コードを読んでいるときや実装中に「不要な処理を見つけたから消したい」、「この処理をリファクタしたい」となることはないでしょうか？
VSCodeのDevinプラグイン（https://github.com/CognitionAI/devin-extension）を使うことでこういった軽微な修正をスムーズに対応できます。
プラグインを使うことで、後でやろうから「Devinに依頼 → PRをレビュー → DONE！！」というスムーズな流れに変わります。
軽微なアラート対応やWant対応を任せる
「Mustじゃないけどこのタスクもやりたいよね」、「アラートが気になっているけど忙しいから手がつけられない」といった話はよくあります。
そういったときに、Devinに任せることで、効果的に対応できます。
いろいろ試した結果として、軽微なものであれば、7~8割の精度でイシュー作成〜対応という一連の作業を任せることができました。
Devinにタスクを任せる際の工夫として、過去のプルリクを参考にさせることで、Devinがよりスムーズにタスクを理解し、実行できるようにしています。
例えば、次のようなタスクは概ねDevinに任せることができました。
- 管理画面のフィルター追加・ラベル付与・簡易なバリデーション追加
- Sentryで通知がきたN+1の調査と対応方針検討・対応実施
- 命名ルールの統一
- ログ出力フォーマットの横展開
- Rubocopの対応
- などなど
最近では、技術系の改善イシューは私が書くよりDevinに書いてもらったほうがよいとさえ思っています。
具体例として、Devinに次のようなイシュー作成の依頼をしました。
@Devin AAA, BBB などで XXX に設定するフィールドの名前が yyy になっているのを zzz にしてください イシューテンプレを参考にして、よしなに記載してください
すると、コードを調べて数分後にはGitHubイシューを作ってくれました。
「概要」、「現状の問題点」、「期待される効果」が簡潔に記載されていて素晴らしいと思いました。もちろん、ちょっと気になる部分は調査したり、手直しをすることもあります。
小規模な開発を任せていく
試行錯誤中ですが、私が持っている小規模なタスクにおいては、フロントエンド、バックエンド問わず基本的にDevinに開発をリードしてもらっています。
イメージとしては、watanyさんのスライド内の「コーディングにおける"自動運転"のレベル」におけるレベル3の段階です。（とてもわかりやすかったので勝手ながら引用させていただきました）
具体的には次のような流れでDevinと開発を進めています。
- 1️⃣ Devinがイシューから対応範囲やタスク洗い出しをして、イシューにコメントをする
- 2️⃣ 私がイシューのコメントを見ながらヌケモレがないか確認して、Devinが実行しやすいようにTODOリストを整理する
- 3️⃣ TODOリストのアイテムごとに１つずつDevinに任せる
- 直列で実施する必要がある場合は、作業するbaseブランチを伝えながら作業を進めてもらう
- 並列で実施できる場合は、アイテム単位で依頼することで、5並列ぐらいでDevinに開発を進めてもらう
- 4️⃣ DevinがPRを作成したら、私がコードレビューや動作確認などで品質チェックをして、他の開発者にレビューを依頼する
このような流れでDevinと開発を並走しています。
現状のDevinのタスク精度は50~100点とわりとブレがあります。そのため、レビューコメントでDevinに修正をしてもらったり、作業を引き継いで残りの開発や修正をするということもよくあるため、まだまだ試行錯誤な段階です。
ここが辛いよDevin
ここまででDevinと一緒に働きながら上手くいったところをご紹介しましたが、使っている中でまだまだこれからかなという部分にもふれていきます。
自分でやったほうが早くない？
シニアな方からよく聞きますが、Devinに任せるよりも自分でやったほうが早いので、自分でやってしまうことはよくあります。
次のグラフのように、Devinもスピードは早くなっているのですが、現時点では簡単なタスクでも5~10分ぐらいはかかっている印象です。
devin is now ~2.1x faster – and keeps getting faster every day.
— Silas Alberti (@silasalberti) 2025年2月27日
every night for the last 5 months, we ran devin on the same set of SWE tasks (a private set of tasks inspired by customer use cases). we've shipped a lot since and devin got 10-40% faster every month pic.twitter.com/CGxeXbTo7g
また、精度のブレの問題もあります。100点のPRを作るときもあれば、概ねいいんだけどちょっと気になるなという70~80点ぐらいのPRもあったり、全然だめじゃんという30点ぐらいのPRもあります。
この精度のブレがあるなら、「自分でやったほうがトータル早くない？」という考えになることはとてもわかります。
GitHub CopilotやClineなどのほうが精度良くない？
弊社の多くのエンジニアは、活用度は人それぞれですがGitHub CopilotやClineなどのAIアシスタントやAIエージェントを利用しながら開発をしています。
Devinに頼むよりも、Copilot Editsで編集するほうが精度の高い結果になることもあります。また、ローカルで動作するため、その後のプロンプトのやりとりやコードの修正もしやすいです。
やりとりの手間やコストを考えると、CopilotやClineなどを使ってローカルで開発するほうが良いと考えることもとてもわかります。
レビューに反応して余計な対応をしてしまう
Devinは自律型AIエンジニアということもあり、Devinが作成したPRに対してコメントをすると、コメントの対応をしてくれます。また、CI結果をチェックしてCIを通るように対応をします。
便利な機能ではありますが、Devinが作成したPRでは、デフォルトでレビューコメントへの反応が有効になっています。
「(aside)」をつけたコメントをするとDevinは反応しないのですが、よく間違えて「(aside)」をつけ忘れることで、レビュー時に不要な対応をされることもたまにあります。
Devinと今後どう付き合っていくか？
GitHub Copilot や Clineなどと併用しつつ、引き続きDevinを試していく予定です。
生成AI界隈は動きが早いので、今後どのプレイヤーが登場しどのように進化していくのかわかりません。そのため、Devinを試しつつ、他のAIエージェントやAIアシスタントとも併用しながら、開発生産性を高めていきたいと考えています。
また、個人的には、既存の仕組みを効率化するにとどまらず、AIエージェントと人が協業することで良い意味で開発体験をリビルドしていきたいと考えています。
その結果として、一人のエンジニアがより大きな価値をだせるようになると、いろいろ面白くなってくると思っています。
現に0->1の世界では、生成AIやSaaSサービスをフル活用した開発スタイルで、今までよりも質の高いMVPをどんどん作って検証しているという話もちらほら聞き始めています。
最後に
ファインディでは生成AIやAIエージェントを前向きに試して開発生産性を高めることで、ユーザーにより価値を届けることを推進しています。
こうした新しい技術の利活用に興味がある方は、ぜひカジュアル面談にお越しくださいませ。
