スターフェスティバル株式会社 エンジニアのDPon です。こんにちは。
AIが盛り上がってる昨今、開発スタイルも大きく変わってきてきていますね。
今回は、自律型のAIエージェント「Devin」を使って開発を行った体験談をお話しします。
※2025年4月ごろの体験談です。
Devinとは
自律型というくらいなので、こちらの指示をもとに自走で開発を行ってくれます。
縛りプレイをやってみる
さてDevinに限らずAIにコードを書いてもらう場合に、実装したい内容を指示することになるわけですが、やはり慣れも必要ですぐさま精度の高いコードを出力できるわけでもありません。
これもあり慣れないうちはついつい自分で書いた方が早いとなりがちです。
覚えると便利であろうことは想像しつつも、初手の面倒さなども相まって腰も重くなりがちです。
ただそれだといつまでたっても使い方を覚えられません。
実装の最中であったOpenSearchを利用した検索機能をdevinに全振りすると制約をかけて取り組んでみることにしました。
初手 APIエンドポイントの作成
初手として検索機能のAPIエンドポイントの作成をdevinに依頼してみました。
一部加工、省略していますが雰囲気としては下記のような指示を出しました。
hoge-productで新規のapiエンドポイントを作成します。
## 事前条件
- .clinerules に技術スタックやディレクトリ構成を簡単に記載しているので、読み込んで理解をしておいてください
## APIの定義
- パス： `api/search/product`
- GETメソッド
- 概要：商品検索用のapiエンドポイント
### クエリパラメータ
```
pref : 都道府県コード (例: 13)
city : 市区町村コード (例: 13101)
min_price : 予算下限 (例: 500)
max_price : 予算上限 (例: 1296)
quantity : 個数 (例: 30)
free_delivery : 配送無料のみ (例: 1)
genre[] : ジャンル（複数指定可能）(例: washoku, youshoku, chuka,etc...)
※※割愛※※
```
### レスポンス
```json
{
"total_count": 整数, // 総件数
"current_page": 整数, // 現在ページ
"products": [ // 商品配列
{
"id": "商品ID",
"product_code": "商品コード",
"product_detail": "商品詳細",
"product_name": "商品名",
※※割愛※※
}
// 複数の商品情報が配列として続く
]
}
```
## タスクの完了条件
- apiのエンドポイントを作成して、200のステータスが返ること
- apiの詳細実装は行わず、ダミーのレスポンスが出来ていれば良い
- ただしリクエスト、レスポンスの型は定義しておくこと
- apiのテストを実装して、テストが通過することを確認する
- テストが通らない場合に、無闇矢鱈に試行錯誤せず3回以上失敗するようであれば、draftでPRを出しても良い。
## その他
- 不明点があれば質問をしてください
- テスト実装前にテストケースを考えて提案してください。
You only need to look in the following repo: stafes/sales-product
こちらの指示で1.58ACUでPRが作成されました。作成されるまでに7分ほど。人間にはできない早さですね。
※ACU（Agent Compute Unit）はDevinの作業量を表す単位です。
※2025年4月時点ではTeamプランが $500/month で 250ACU/month という設定なので、1ACUあたり $2 という計算になります。
そこから2点ほど修正のコメントを入れると、キャッチして引き続き修正を行ってくれました。
検知したら目玉のリアクションしてくれるのも人間くさくて良いですね。
この修正を含め、最終的に2.84ACUで完了しました。
初手課題
実はこの段階でdevinの環境でテスト実行できるようにうまく設定できておらず、テストが成功しているかはPR作成後CIの結果を監視して行っていたようでした。
無駄にGitHub Actionsの時間とACUの消費にもつながるので、最初に環境を整えておくべきでした。
CIでOpenSearchまわりのテストも対応
続いてテスト周りの準備です。
OpenSearchにリクエストを投げることになるので、OpenSearchのコンテナを立てて、テストデータを投入する仕組みを整える必要があります。
`api/search/product` の実装を進めていきます。
今回はOpenSearchのクライアントでクエリを叩けるところまでを目指しています。
実装する前に先にテストでOpenSearchが参照できるような仕組みを構築していきたいです。
## 事前条件
- .clinerules に技術スタックやディレクトリ構成を簡単に記載しているので、読み込んで理解をしておいてください
- app/routes/sample.opensearch.tsx ですでにopensearchのクライアントを使用したサンプルはあるので参考にしてください
## タスクの完了条件
- テスト用のOpenSearchのコンテナを構築
- テストでOpenSearchにテスト用のデータを投入する仕組み
- ローカルでテストが通過する
- 既存のワークフロー .github/workflows/app_test.yaml
- こちらでもOpenSearchのコンテナを設定する
- OpenSearchのテストデータを投入するステップを追加する
- CIが通過することを確認する
### OpenSearchに投入するデータの参考
添付ファイルは、phpで開発された別プロジェクトのものですが、テストデータは同じ定義になります。参考にしてください
### ブランチ名
feat/opensearch_testing
## その他
- 不明点があれば質問をしてください
- テスト実装前にテストケースを考えて提案してください。
こちらも15minほどでPRが作成され、いくつかコメント入れ修正してもらい2.16ACUで完了しました。
成果物の精度も悪くなかったです。
この手のワークフローは恐らく学習のサンプルも多いでしょうし、事業ドメインに依存しないので、devinも得意な分野だったのかもしれません。
PR量産期
ここからしばらく検索条件ごとにOpenSearchのクエリを実装するタスクを依頼しつづけました。
- 実装の際に必ずテストも書かせている
- 参考となるPHPのコードも提示
いずれも1.5 ~ 2ACU前後でPRが作成されていきました。
調子の良いときは1日に6PRほどマージできました。このときはもう
- devinに指示出し
- 作業してもらってる間に、次のdevinの指示まとめ
- そうしてる間にPRがあがってくる
という流れで私がブロッカーになってしまうという状況になってきました。
低迷期
さて順調に進んではいたのですが、テストこける→修正、をひたすら繰り返すタスクが出てきました。
一応設定でのリミットはあるので即破産につながりはしませんが、ほっとくと10ACUも消費していました。
引き取って自身で動作確認をしていたところ突破できなかった要因としては
- 指示の曖昧さ
- 参考となったテストのテストデータ自体に不備があった
といった点がありました。
指示の曖昧さ
しばしば人とやりとりする際、相手の察し能力に頼って簡易なコミュニケーションになることがあります。
例えば"ここのコードを参考にして"と伝えてそこから辿れば、この部分も理解して進めてくれるだろう、といった暗黙の期待をして指示を省いたりした部分がありました。
この際に拾ってくれると期待していた部分が抜け落ちてしまい、期待した結果にならなかったり。
参考にしたテストデータの不備
既存コードを参考にして実装を進める傾向があるため、参考にしたテストデータの不備がそのままdevinの実装に影響してしまっていました。
これまで通過していたテストが、実装が進むにつれ検索条件の判定が増え、既存テストデータに不足が出てきてしまい落ちるようになっていました。
抜け落ちてる部分を検知することがdevinには難しかったようで、最終的に引き取って解消しました。
しれっと嘘をつかれたやりとり
さてテストでこけて作業し続けていたのですが、実は事前の指示で
テストが通らない場合に、無闇矢鱈に試行錯誤せず3回以上失敗するようであれば、draftでPRを出しても良い。
このような指示を出してACUの過剰な消費を防ごうとしていました。
にもかかわらず、3回以上失敗してもPRを出さずに作業を続けていました。
修正を行いpushしたらカウントリセットしたりしてるんでしょうか。これも指示の仕方が悪かったのかもしれません。
相手はAIでイライラするだけ無益なのですが、これを人間として捉えると目前で堂々と嘘を吐く姿に見えてしまい、口調にキツさが現れてしまったように思います。
※普段は温厚です。ほんとだよ？
最終結果とあれこれ所感
さてそんなこんなで試用期間を終えてしまいました。
最終的にdevinは以下のような成果を上げてくれました。
- 稼働期間：7.5営業日
- 作成PR数：34
- マージPR数：28
- 1日でマージした最大PR数：6
縛りプレイと言いつつ、後半の複雑なところの実装はどうしても突破できず手を入れてしまいましたが、最終8割くらいはdevin製のコードになった感じです。
開発のスピード感
最大で1日6PRマージできましたが、実際その日の開発はスピードの高まりを感じており、開発の未来の姿を垣間見ることができました。
これはすぐ片付けられるなと甘く考え出した矢先、テストで詰まり出す事例も出てきてしまい最終的に生産性n倍！みたいなスピードには至りませんでした。
それでも全体として十分なスピードで仕上がったので、devinに向いてるタスクかどうかを見極めて、人間とうまく分担できるとより効率的に開発が進められるかと思います。
テストは必須
別にdevinに限らずテストは書いておいたほうがいいのはいいなんですが、必須になってくると思います。
レビューを行う身としてdevinが書き上げたコードの挙動を把握するためにも、テストが書かれていると安心してレビューできます。
課題の分解能力
devinに効果的な指示を出すポイントは以下ドキュメントにも記載があります。
Why: Breaking down complex tasks into smaller checkpoints helps Devin stay focused and reduces errors.
How:
Split tasks into verifiable sub-tasks, and start one Devin session for each sub-task.
一部抜き出しますが、複雑なタスクを検証可能なサブタスクに分解して、各サブタスクごとにDevinセッションを開始することが推奨されています。
自身で開発しているときは多少の曖昧さがあるなかでも書き進めていくことはできたのですが、ドキュメントにあるとおりdevinの精度をあげるには細分化するのが重要となってきます。
このため課題から具体的な作業へ分解する能力はこれまで以上に重要となってきます。
※分解に相応の脳のリソースを使うのでdevinに作業してもらいながらもそこそこの疲弊もします。
意識的に並列にする
せっかく自律的に動いてもらうので、なるべく自分が何かしら作業を行うタイミングで指示できるように意識しておきたいところです。
私の場合
- MTGに行く前
- 重めのコードレビューを行うタイミング
- カンファレンス用の資料作成
といった裏でdevinに作業してもらうように意識していました。
devinに任せられる範囲
体感としては公式が言及してるとおりジュニアなエンジニアで、簡単なタスクは完了まで仕上げられる一方、少々複雑なものとなると7割くらいの完成度で、残りはこちらでブラッシュアップ、という感じでした。
このあたりの見極めはある程度触れないとわかりにくい部分かもしれませんが、見極められるとグッと効率よく作業を進められると思います。
簡単なリファクタリング
途中散らかってきたコードを簡単にリファクタリングさせたりもしました。
このあたりはそれなりにサクッとやってくれます。
実装時にテストも用意してくれてたので、挙動もしっかり担保しながら仕事を任せられました。
その他反省点
人間のレビュー待ちが作業ブロッカーになる
タスクがしっかり分解できていれば人間では絶対叶わないスピードで成果物をあげてきます。
こうなると人間のレビュー待ちがブロッカーになってしまいます。
作業してもらう課題によっては、レビュー自体も簡略化できるかもしれませんが、そこの落としどころはまだ模索中であり今後の課題と感じています
Knowledgeの育て方
Devinは自身が行った作業から、Knowledgeをいくつか提案してきます。そこから有用なやつがあれば採用して、以降別のセッションにも活かされていきます。
ここであげてくるKnowledgeがあまり後続のタスクでは有用でなく、採用率は高くありませんでした。
devin自身が提案してくるのは面白い機能ではあるのですが、こちらから具体的にKnowledgeを追加していったほうが効果的なのではないかと感じました。
指示は明確に
人間くさい行動をしてくれるので、ついつい作業指示においても暗黙の部分の理解を期待するようなコミュニケーションをとってしまうことがありました。
結果として成果物の精度は下がるので、1から10まで伝える意識が必要です。
おわりに
というわけで縛りプレイを通じて、Devinの得意、不得意な部分を体感することができました。実践記事は多く出てきていると思いますがやはり自身での体感が一番わかりやすいですね。
2025年6月現在では、 Claude Code も盛り上がっており、日々追いかけるのも大変な過渡期ではありますが、意識的に縛って触れてみることで他の類似サービスの理解も深まりやすくなると思います。
これに限らず新しい技術のキャッチアップにぜひ縛りプレイを取り入れてみてください。
最後まで読んでいただきありがとうございました。
Discussion