こんにちは。アンドパッドでプロダクト開発をしている宇田川です。フロントエンド・バックエンドの開発を担当しています。
わたしのチームでは、マイクロサービスとして切り出された歴史ある5つのリポジトリを運用しています。これらのリポジトリの急なバグ修正やライブラリ更新には、「うーん、このリポジトリどうなってるんだっけ…」と、毎回大きな調査コストと心理的な負担がかかっていました。この課題を、クラウドで自律して動くコーディングエージェントで解決できるか試したく、今回Devinを使ってみることにしました。 Devinを3ヶ月ほど使ってみて、この辺りの作業がかなり楽になったなと感じたので、今回はその知見をシェアできればと思います。
※ 本記事の内容は、2025年8月時点のものです。
複数のリポジトリを管理する上で、直面していた課題
マイクロサービス化によってリポジトリが増えてくると、「知見のないリポジトリでのバグ修正」や「ライブラリのバージョンアップ対応」にかかるコストが悩みでした。
私たちのチームでも、活発に開発しているリポジトリがある一方、長年大きな変更が加えられていないものも少なくありません。
Devinでこう変わった！ 2つの事例
事例1：見慣れないリポジトリでのバグ修正がスムーズに
Devinを導入して一番大きく変わったのは、やはり知識が少ないリポジトリの改修に対する心理的ハードルがぐっと下がったことだと感じています。以前であれば知見のあるメンバーを探すところから始めていたような修正も、Devinとペアプロする感覚で気軽に手を出せるようになりました。
例えば、修正したい画面のスクリーンショットを渡すだけで、Devinは関連するコンポーネントを特定してくれます。このとき、もし余裕があれば、デベロッパーツールでクラス名やコンポーネント名が見えるようにしておくと、より精度が上がる印象でした。QAで挙げられた軽微なエラーなら、すぐに解決されたPRを作成してくれました。
もし修正がうまくいかなくても、チャットで「どんなデータで問題が起きるか」「最終的にどうなってほしいか」といった情報を追加で伝えてあげると、ちゃんと軌道修正してくれます。
途中で「あ、この方針やっぱり違うな」となった時も、セッションの中でPRを破棄して、新しいPRを作り直すことができました。こういう柔軟な対応ができるのも、Devinのいいところだなと思います。
事例2：「Playbook」機能でパッケージアップデートの調査タスクを自動化
日々の運用業務も、Devinがかなり助けてくれました。特に便利だったのが、決まった手順を「Playbook」として再利用できる機能です。
私たちのリポジトリではDependabotから日々大量のPRが作られるのですが、そのひとつひとつに対して破壊的変更がないか、影響範囲はどこまでかを調べるのは、なかなかに骨の折れる作業です。そこで、PRのリリースノートの破壊的変更をチェックしたり、ビルドログの差分を確認したりする、今までやっていた一連の確認項目をPlaybookにしてみました。
確認項目の中に、バージョンアップによって警告やエラーが増えていないかどうか、ビルド時などのログをdevelopブランチと作業ブランチでdiffをとって比べるという項目があります。既存の警告なども混ざったログをわざわざ見比べるというのは決して楽しい作業ではありませんでした。このような地道な作業もDevinが行ってくれるのはありがたいです。体感では調査にかかっていた時間が1時間以上は短縮できたと思います。
このおかげで、日々の確認作業が半自動化されてぐっと楽になり、フロントエンドのライブラリ更新に慣れていないメンバーでも、安心してPRをマージできるようになりました。
Devinの他に使ってみたツールについて
ローカルのVSCodeで動作する「GitHub Copilot Chat Agent Mode」と GitHub Actions環境で動く「GitHub Coding Agent」などのCopilotのサービスも使ってみました。あくまでもわたしが使ったプロンプトやタスクの話になってしまうので、この限りではないこともあると思いますがご了承ください。
1つのタスクから複数PRへの分割
作業方針が変わってPRを作り直したいケースで、Devinではセッション内で「新しいブランチを切ってPR作成をやり直して」といった指示で柔軟に対応できました。一方、GitHub Coding Agentでは、Agentページやパネルから「Issue#xxxのタスクを実行して。PR#yyyのzzz部分以外は参考にして」などの指示をすることで、実現できました。個人的には、同じセッション内で続けて指示ができるDevinのほうが使いやすく感じました。
また、大きなタスクを複数PRで実行するケースに関しては、両者ともに実現できました。Devinではセッション内で指示を出して、そのままPRが複数作られます。WebのGitHub Copilot Chatではプロンプト送信後に専用のUIからsub issueの作成ができ、かつ作成前にプレビューもできるので、より柔軟にissueの作成ができました。
ナレッジや手順書の横断利用
DevinのPlaybookやナレッジは、リポジトリをまたいで使えるので「複数のリポジトリで同じPRテンプレートや手順書を使いたい」という私たちのケースでは便利でした。 一方Coding Agentでは、複数のリポジトリで共通したPRテンプレートを使う設定は難しそうでした。(Publicリポジトリなら可能)
再利用可能な手順書
DevinのPlaybookと似た機能として、GitHub Copilot Chat Agent Modeには「Reusable Prompt File」があります。どちらもコマンド（!や>）ですぐに呼び出せる手軽さは同じでした。
ちなみに、Devinにはデフォルトで「Community playbooks」という、誰でも使用できる手順書が登録されていました。わたしはまだ使っていませんが、他の人の使い方を参考にできるのは良い点かもしれません。
導入して分かった、Devinの現実的な付き合い方
Devinでタスクを進めるための工数は依然として必要
指示一発で完璧なPRが完成するわけではなく、方針については都度確認しないと、変な方針でバグ修正に向かってしまい、PRができてから気がつくこともあります。
なので、「最後まで自律的にお願いする」のか、「手綱を握って都度承認しながら進める」のかは、うまく判断していく必要がありそうです。「作業する前に私からの承認をもらってください」と一言添えるだけで、confirmボタンを押すまで待ってくれるので、コスト管理の面でもこの指示はよく使いました。
また、Devinはブラウザを起動して動作確認を行います。そのためには、モックサーバーなどの環境を整えてあげる手間もかかります。
有益なナレッジやドキュメントを整備していくコストも含め、チームとして「Devinを育てる」という意識が大事になってくると感じました。
Devinの貢献度って、どう測る？
Devinには「Productivity」タブがあって、マージされたPR数などが見えるのですが、この数字がそのままチームへの貢献度かというと、少し違うなと感じています。
というのも、コミットログが乱れたからPRを一度閉じて作り直したり、複雑な部分の初期調査だけをお願いして実装は人間が引き継いだり、というケースが結構多いからです。
最終的なアウトプット（マージされたPR数）だけを見るのではなく、調査時間がどれだけ短縮できたか、私たちがより本質的な作業に集中できたか、といったプロセス全体で貢献度を見る必要があると思いました。
まとめ：私達がみつけたDevinの使い所
今回、Devinを3ヶ月使ってみて、私たちが抱えていた「知見のないリポジトリの運用」や「定型業務の自動化」といった課題に対して、Devinは力を発揮してくれることが分かりました。まだ、新規機能の開発のようなアイテムは任せられていないので、そこは検証の余地があると思います。 同じような課題をお持ちのチームの皆さんにとって、この記事が少しでも参考になれば嬉しいです。
そして、アンドパッドでは Coding Agent の活用方法を探りながら開発を楽しめるエンジニアを歓迎しています。
