DevinでAI駆動開発はどこまでできる？現場で試してわかったリアルな強みと弱み

本記事で紹介しているDevinはversion1のものです。

はじめに

2024年3月にCognition AI社がリリースした自律型AIエンジニア「Devin」。リリースから1年経った今、実際の開発現場でどれくらい使えるのか気になっている人も多いのではないでしょうか。

従来のコード生成AIとは違って、Devinは独自の開発環境を持ち、コーディングからデバッグ、さらにはgit操作まで一貫して行える点が大きな特徴です。GitHub Copilotなどと比べると、より自律的にタスクを実行できるという触れ込みですが、実際のところどうなんでしょう？

今回は実際の業務プロジェクトで、Web-E2Eテスト開発にDevinを活用してみた結果をシェアします。Page Object Modelパターンを使ったPlaywrightテストの実装過程で見えてきた、Devinの実力と限界について掘り下げていきます。

検証方法

実際のプロジェクトで必要だったWeb-E2Eテストの開発過程で、以下の5種類のタスクをDevinにやらせてみました。

1. Playwright環境の構築と基本設定
2. 規模が小さいページ（ログインページ）のPage Object実装
3. 規模が大きいページ（販売画面）のPage Object実装
4. 販売ページと構成が似ている別の販売関連ページのPage Object実装
5. 販売ページと構造が類似した買取画面のPage Object実装

各タスクで以下の点を見ていきました：

• 実際にかかった時間（人間がやる場合と比べてどれくらい速い/遅い？）
• 出力されたコードの品質（使えるの？使えないの？）
• どれくらい人間が手を出す必要があったか
• 既存コードをちゃんと理解できているか
• フィードバックにどう対応するか
• 一度教えたことを覚えて次に活かせるのか

検証結果

1. Playwright環境構築タスク

タスク内容: Playwrightの環境構築と基本的なテストスケルトンの作成

結果:

• 完了時間: 約15分
• 人間の介入: 最小限（数回の確認質問への回答のみ）
• コード品質: 小規模プロジェクトには不必要に複雑な設計傾向あり

考察:
人間が同じタスクを行う場合と比較して約7割の時間で完了できました。Devinは基本的なGit操作（ブランチのチェックアウト、コミット、PR作成など）を問題なく行えることが確認できました。特筆すべきは、作業を一方的に進めるのではなく、必要に応じてユーザーに質問を行い、対話的に進める姿勢を見せた点です。

2. ログインページのPage Object実装タスク

タスク内容: シンプルなログインページのPage Object実装

結果:

• 完了時間: 約30分
• 人間の介入: ディレクトリ構造に関するレビュー指摘
• コード品質: 概ね良好、いくつかの設計上の問題点あり

考察:
既存コードを適切に参照できており、指示なしに正しくlogin.tsxファイルを参照できていました。しかし、小規模なテストに対して不必要に複雑なディレクトリ構造を提案する傾向が見られました。人間+ChatGPTの組み合わせであれば5分程度で完了できるタスクに30分かかりましたが、そのうち20分はレビュー対応の時間でした。

3. 販売ページのPage Object実装タスク

最初の大きめのチャレンジとして、販売ページのPage Object実装をやらせてみました。

3.1 丸投げパターン（情報少なめ）

結果:

• かかった時間: 最初のPRが上がってくるまで約5分
• コード品質: 正直ひどい。ほぼ使い物にならなかった
• 人間の介入: なし

実際どうだったか:
複雑なページ構造を理解するには、Devinのコンテキストウィンドウの大きさが足りなかったようです。参照できたのはたった6個のファイルだけ。ページを構成する主要コンポーネントの一部しか見れていませんでした。結果として「これっぽいかな？」という断片的な理解に基づいた「キメラ」コードが生まれました。

3.2 タスク分解して具体的に指示するパターン

結果:

• かかった時間: 約60分（レビュー対応含む）
• コード品質: まあまあ良い
• 人間の介入: かなり必要（レビューでの修正依頼多数）

実際どうだったか:
人間がタスクを小分けにして、具体的な指示を与えると、だいぶマシなコードを生成できました。面白かったのは、レビューで指摘したことを学習する能力です。最初は10個くらい指摘点があったのに、後のタスクでは3つくらいに減りました。ただし、たまに「あれ、さっき教えたのに…」ということもありますが笑。

3.3 2回目以降の類似タスク

結果:

• かかった時間: 約30分（人間+ChatGPTでやるのと同じくらい）
• コード品質: ほぼ問題なし
• 人間の介入: ほとんど必要なし

実際どうだったか:
一度学習したプロジェクト特有のコーディングルールを次のタスクでもちゃんと適用できていました。2回目以降はほぼレビュー不要でコードが出てくるようになったのは印象的でした。

4. 販売関連ページのPage Object実装タスク

販売ページと構成が似ている別の販売関連ページの実装も試しました。

結果:

• かかった時間: 約30分（人間+ChatGPTと同等）
• コード品質: レビューがほとんど不要なレベル
• 人間の介入: 最小限

実際どうだったか:
販売ページで学習したパターンを活かして、スムーズに実装できていました。以前指摘したlocatorの取得方法などのプロジェクト固有のルールもきちんと守られていました。レビュー指摘は数点程度で済み、時間効率も人間がChatGPTを使って実装する場合と変わらないレベルまで向上していました。

5. 買取ページのPage Object実装タスク

試したこと:
ここで興味深い実験をしました。買取ページは販売ページとかなり構造が似ているので、「これくらいなら自分でうまくタスク分解してくれるかな？」と思い、あえて最小限の指示だけで丸投げしてみました。

結果:

• 一度に7つ以上のファイルを含む大規模なPRを作ってきた
• でも自発的にタスクを小分けにする発想はなかった(あるのだが、適切に使えていなかった東野が正しそう)
• コンテキストウィンドウの限界で必要なファイルを全部参照できず、結局不完全なコードに

何がわかったか:
販売ページと構造が似ているのに、その経験を活かして自分でタスク分解するという知恵はなさそう(というか、あるにはあるがまだ弱い)。結局、大きなタスクは人間が適切に分割してあげる必要がありそうです。

Devinの良かった点と微妙だった点

微妙だった点

1. コンテキストウィンドウが狭い
   「自律型AI」と聞いて期待していたのですが、実はコンテキストウィンドウの大きさはChatGPTとそれほど変わらなそうな印象をうけました。大きなコードベースだと、必要なファイルを全部読み込めず、断片的な理解に基づく「なんちゃって実装」になりがち。販売画面や買取画面のように複雑なページだと、この限界がモロに出ました。
2. 自分でタスク分解できない
   複雑なタスクを「これは大きすぎるから分割しよう」と自発的に考える能力はなさそうです。具体的にはあるにはあるがまだ力が弱い。特に買取ページ実装では、販売ページとの類似性があるのに、自分のコンテキスト制限を考慮したタスク分解ができませんでした。
3. 時間効率が思ったほど良くない
   単純なタスクなら速いんですが、中〜大規模のタスクだと人間+ChatGPTの組み合わせよりも時間がかかるケースが多かったです。特にPR作成までの時間やレビュー対応の時間が長く、「全部Devinに任せたら早くなる！」とはなりませんでした。
4. オーバーエンジニアリングが好き
   小さなプロジェクトなのに、妙に複雑なディレクトリ構造や抽象化を持ち込む傾向があります。「いやいや、そこまで要らないから…」というシーンが何度かありました。

良かった点

1. 既存コードをちゃんと読める
   ちゃんと指示すれば、既存コードを読んで理解する能力は高いです。特に単一ファイルや関連性が明確なファイル群なら、それに基づいた実装ができます。
2. Gitの操作が堅実
   ブランチのチェックアウト、コミット、PR作成などのGit操作は実用レベル。普通に開発フローに乗せることができます。この点は期待以上でした。
3. 学習能力がある
   一度指摘したことは概ね覚えてくれます。最初はレビューで10個指摘してても、続けて使うと3個くらいに減っていくのは良かったです（たまに忘れることもありますが）。

Devinに向いている仕事

検証した結果、Devinが活躍できそうな場面はこんな感じです：

1. 環境構築とか初期設定
   Playwright環境構築のタスクでは、人間より7割くらいの時間で済みました。新規プロジェクトの立ち上げやCI/CD設定など、ある程度定型的な初期化作業は任せられそうです。
2. 小さくて明確なコンポーネント実装
   ログインページみたいな「やることが明確」なコンポーネントの実装は得意です。特に既存のパターンがある場合は効率良く実装してくれます。
3. 似たような作業の繰り返し
   一度やり方を覚えると、似たようなコンポーネントの実装は最小限のレビューで済むレベルのコードを出してくれます。「同じパターンの繰り返し」が多い開発だと力を発揮します。
4. テストコード書き
   今回のように既存実装を参照したE2Eテストの作成は、Devinの得意分野です。特にPage Object Modelのようにパターン化されたテスト設計だとスムーズに進みます。
5. プロジェクト固有のルールを学習して適用
   「このプロジェクトではセレクタをこう取る」「ディレクトリ構造はこうする」といったルールを一度教えると、以降はちゃんと守ってくれます。コードの一貫性維持に役立ちます。

まとめ：Devinはどう使うべきか

今回の検証を通じて、Devinは従来のAIコーディングアシスタントよりも一歩進んだ存在ではあるものの、まだまだ「完全自律型」とは言えないことがわかりました。GitHubとの連携や自前の開発環境は便利ですが、大規模コードの理解や自発的なタスク分解といった点では期待したほどではありませんでした。

実際に使うなら、次のアプローチが効果的だと思います：

1. 人間がタスクを小分けにして与える
   「全部任せる」よりも「適切に分割して指示する」方が良い結果になります。
2. 最初は細かくレビューする
   初回は丁寧にレビューして、プロジェクトのルールを教えることで、以降のタスクの質が上がります。
3. 得意な領域で使う
   環境構築、小〜中規模のコンポーネント実装、パターン化されたテストコードなど、Devinの強みを活かせる領域で使いましょう。

コンテキストウィンドウの大きさが今後改善されれば、より複雑なタスクにも対応できるようになるでしょう。現時点では「万能の代替エンジニア」ではなく「特定領域で力を発揮する協力者」と考えるのが現実的です。

今後のアップデートに期待しつつ、上手に付き合っていきたいと思います。