Devinが最低限ワークするようになるまでにやったこと

こんにちは、Energy Marketing Devチームの細木です。

前回の福田さんの記事では、SlackからGoogleサイト公開までをAIエージェントで自動化するワークフロー構築プロジェクトについて読ませていただきました。Notion AI → Cursor → Googleサイトの連携により、従来エンジニアに依存していたWebページ作成を非エンジニアでも効率的に行えるようになったとのこと、とても興味深かったです！

特に印象的だったのは、AIエージェント同士の連携パターンを確立し、再現可能なワークフローを構築できた点です。単体のAIツールを使うだけでなく、複数のAIエージェントを組み合わせることで、より大きな価値を生み出せることを実感されていたのが素晴らしいと思いました。

今回は、Devin導入当初の苦労から最低限ワークするようになるまでの改善過程をお話ししたいと思います。結論から言うと、最初は使いにくい部分も多かったのですが、適切な環境構築とワークフロー設計により、開発効率が大幅に向上しました。

Devin導入のモチベーション

Devinを導入した理由は、CursorやClaude Codeと違い自律的にタスクをこなしてくれる点にあります。これにより、さらなる工数削減が期待できると考えました。

特に期待していたのは以下の2点です：

自律的な開発タスクの実行能力
- 単体でテスト実行、コードフォーマット、システムの動作確認まで行える
- 人間の介入なしに一連の開発フローを完結できる
定期タスク・メンテナンスタスクの自動化
- 複数リポジトリで同じような対応が必要になる定期タスクの自動化
- メンテナンスタスクの効率化

最初に導入した際の課題

Devinの導入当初は、自身のローカルでの開発と完全に並行してタスクを依頼できる便利な面はありましたが、使いにくい部分も多々ありました。

1. 見当違いな実装をする

具体例：電気料金のシミュレーションエンドポイントの計算ロジック修正

期待していた修正: 本来は計算を行っているサービスクラスの修正
実際の修正: コントローラーで値を修正した風なレスポンスに加工

このように、タスクを深く理解して根本的な解決をしてくれないことが頻発しました。

2. CIの失敗など、低レベルなレビューが発生

主な問題：

Devinの実行環境でRailsのセットアップができておらず、最低限のテスト実行もしないでpushしてくる
その結果、CIで単純なテスト失敗を何度も繰り返す
「テストをしないでpushしてCIで失敗して差し戻し」という低レベルのレビューが頻発

これらの課題により、当初はDevinの活用が思うように進まない状況でした。

ワークしてもらうためにやったこと、結果

1. Devin's Machineの設定

まず最初に取り組んだのは、Devinが自身のローカル環境でテストやコードフォーマット、システムの動作確認をできるようにすることでした。

設定のポイント：

Devinの実行環境の構築
コードフォーマットツールの設定
システムの動作確認プロセスの整備

効果：

テストをしないでpushされることが激減
CIでの単純なテスト失敗による差し戻しが大幅に削減
レビューの質が向上し、より本質的な議論に集中できるように

課題と改善点： テストに時間がかかると、結果を待たずにpushを含む次のステップを進めてしまうことがあるため、knowledgeによるフロー制限やテストの実行時間短縮が必要だと感じています。

Devin's Machine の設定方法についてはzennの方に詳しく記載しています。

2. クラスの細分化・責務の明確化

AIを導入しAIがコードを書くことで実装時にコード量が多いことがデメリットにならなくなったため、クラスの構造を整理することにしました。まだ試行錯誤の段階ですが、例えば以下のような方針で進めています。

具体的な取り組み：

Validators配下のクラス: booleanを返すバリデーションメソッドのみを実行
サービスクラス: メソッドの引数は対応したパラメータークラス（パラメーター管理・バリデーション）を受け取るようにする、そうすることでメソッドに渡された値が確からしいことを保証する

期待される効果：

各クラスの役割が明確になり、レビューの負担を軽減
人間がコーディング、AIへの指示をする際も「この処理はどこに書くべきか」といったことで悩むコストの削減

現状の課題： AI導入をしてから機能開発のついでに進めているため、定量的な成果はまだ出せていません。しかし、ちゃんと整備すればレビューだけでなく実装の負担も減らせそうという肌感覚を持っています。

3. Cursorとの連携ワークフロー設計

大きいタスクをDevinに任せたい時は、まずCursorで実装計画を練ってから、その一部をDevinに渡すようにしました。

ワークフローの詳細：

Cursorで実装計画を策定: 全体の設計とアーキテクチャを決定
Step単位での分割: 大きなタスクを小さな単位に分割
Devinへの段階的委譲: 実装計画自体はGitHubにはpushせず、step単位を単一のタスクとしてDevinに渡す
結果の検証と調整: 必要に応じてCursorで微調整

効果：

大きく道を外れることが少なくなった

課題： Step分割が甘いと余計なやり取りが発生することがあるが、やらないよりはだいぶマシな結果が得られるようになった。分割の精度を上げるなどの改善が必要ではあると感じています。

実際にやってもらったタスク

1. 機能追加の分割された一部の実装

アプローチ：

Cursorで実装計画を練ってから、その一部をDevinに渡す
100%Devinにやらせようとすると結構手間でACUも消費する
機能追加の大枠やテスト実装をDevinにやってもらい、残りはCursorで調整するのが最も効率的

学んだこと：

アウトプットがイメージ通りでなかった場合、修正してもらうよりPRを破棄して新しいセッションでやり直した方がスムーズ
総合的に一番効率がいいのは、DevinとCursorの使い分け

2. リファクタリング

効果的な使い方：

スコープの狭いリファクタリングならかなりワークする
DevinならローカルのHEADブランチを気にしなくていいので、気づいたらすぐに修正タスクを渡せる

メリット：

即座にリファクタリングを実行できる
ブランチ管理の負担が軽減される

3. テスト失敗の修正

活用方法：

ローカルやCIのテスト失敗のログをそのまま渡して修正してもらう
機能変更などでテストの期待値を変えるシチュエーションは精度が高くて便利

注意点：

原因を探ってテストが通るように実装を直してもらうのは変な修正をしがち

4. コードレビュー

現状：

PR URLを渡してレビューしてもらう
依頼方法によってはCopilotで十分な場合もある

今後の課題：

レビューの精度向上
より効果的なレビュー依頼方法の模索

おわりに

Devinの導入当初は課題も多々ありましたが、適切な環境構築とワークフロー設計により、開発効率が大幅に向上しました。特に、自律的なテスト実行とリファクタリングの能力は期待以上でした。