はじめまして、バイセルのテクノロジー戦略本部 開発 2 部でバックエンドのテックリードをしている藤澤です。 普段は主に Go／TypeScript／GCP／PostgreSQL を使って、バックエンド開発を中心に実装と設計やコードレビュー、技術選定などを担当しています。
今回の記事では、社内で少しずつ使われ始めていた AI エージェント「Devin」 を実際の開発に本気で投入してみた体験を共有します。
Devin に触れ始めたのは 2025 年 2 月ごろ。ちょうどチーム内では「これ、ちゃんと使えるのか？」という雰囲気の中、 だったら一回、全力で任せてみようというノリと興味から、今回の取り組みがスタートしました。
実際にやってみたからこそ分かったこと、良かった点やつまずいた点を正直に書いていきます。 これから Devin を使ってみたい、もしくはすでに一部使っているという方の参考になれば嬉しいです。
記事の概要
本記事では、約 2 ヶ月かかる規模のバックエンド API 開発において、 その実装とローカルでの動作確認をまるごと Devin に任せてみたというチャレンジについて紹介します。
設計や仕様策定、最終的なレビュー・総合テストなどは人間が担当し、 「コードを書く」「ローカルで動かす」「ちゃんと動くか確かめる」といった実装フェーズをDevin に全振りしてみました。
この取り組みは、単なる実験ではなく、 「本当に Devin を実用レベルで使い倒すにはどうしたらいいのか？」という仮説検証でもありました。
記事の中では、以下のようなポイントを順を追って紹介していきます：
- なぜ全部任せてみようと思ったのか（背景と課題）
- Devin に任せるためにやった準備と工夫（具体的なアプローチ）
- 実際にやってみて良かったこと／うまくいかなかったこと
- 最終的にたどり着いた運用スタイルとチームへの影響
結論を先に一言で言うなら、「全部任せてみたからこそ、より良い AI との開発の方法がわかってきた」という感じです。
背景と課題
今回 Devin を“本気で”使ってみようと思ったきっかけは、 社内で Devin を部分的に使う事例が徐々に増えてきた中で、 「実装と動作確認まで全部任せたらどうなるんだろう？」という純粋な興味からでした。
対象としたのは、私がアサインされたバイセルグループ内で利用する在庫管理システムのバックエンド機能追加。 扱う API の数や複雑さから、人力で実装・検証を進めると約 2 ヶ月はかかる規模感の開発でした。
チームは約 10 名。開発はすでにプロジェクトの佳境に差し掛かっており、スピード感が非常に求められるフェーズでした。 一方で、リソースは限られており、「実装・検証で手が取られてしまい、コードレビューに時間が割けない」という現場のリアルな悩みもありました。
また、AI エージェントの導入については、 「ちょっと使ってみたけど、意外と手間が増える」「レビューが逆に大変だった」 といったうまく使いこなせていない空気感もあると感じていました。
そこで思ったのが、
どうせやるなら、中途半端にじゃなくて一回全部任せてみよう。 > “使いこなせたらどこまでできるか”を本気で見てみたい。
ということでした。
Devin を「便利な補助ツール」としてではなく、 “実装と動作確認を任せられるメンバー”として扱うにはどうすればいいか？
この問いに対して、手間をかけて Devin を育てる覚悟で、実装フェーズをまるごと任せるというチャレンジをしてみることにしました。
仮説
今回の取り組みでは、Devin にコードの実装とローカルでの動作確認をすべて任せてみることで、 以下のような効果が得られるのではないか、という仮説を立ててスタートしました。
- 人間は設計やレビューなど、より上流の思考に集中できるようになるのでは？
- Devin が作業を進めている間に、人間が別のタスクに取り組めるため、同時並行で複数のタスクが回るのでは？
- 実装中に発生しがちな細かい検証や環境立ち上げにかかる時間を減らせるのでは？
- スクラムの中で培った“タスク分解のスキル”を活かすことで、Devin を最大限に活用できるのでは？
特に最後のポイントは重要で、 私がこれまで所属していたチームでのスクラム運用の中で、タスクを細かく切って管理する習慣がすでにあり、それが「AI が扱いやすい単位に分けて渡す」という観点でもうまくハマるのではないかと考えていました。
さらに、Devin を使うなら中途半端に一部だけ任せるのではなく、 「実装をまるごと信じて任せる」ことで本当の使い方が見えてくるのでは？という仮説もありました。
便利な補助ツールではなく、“一人の開発者”として Devin をどう使いこなすか。 それを突き詰めてみたくて、この取り組みを始めました。
具体的なアプローチ
この取り組みでは、Devin に「コードを書く作業」と「動作確認」を一任するために、 以下の 5 つの工夫を行いました：
- タスクの渡し方の最適化
- ローカルでの動作確認の自動化
- Devin の行動パターンを育てる Knowledge 機能の活用
- PR 提出プロセスの定型化
- プロジェクトの暗黙知の文章化と共有
タスクの依頼方法を最適化
当初は Slack にタスクの内容を直記載して依頼していましたが、途中から以下の運用に切り替えました：
- Jira にチケットを作成し、要件や背景を整理
- Slack ではJira チケットのリンクのみを Devin に渡す
- Devin の Playbook 機能を使って依頼を定型化
このフローによって：
- 指示の粒度やフォーマットが毎回統一され、出力品質が安定
- 依頼文を手打ちする手間が大幅に削減
という効果が見込めました。 また、元々チームでは Jira でタスクを管理ししていたため、これによって人間と Devin でのタスク管理に差異がなくなり、自然な形で Devin を開発フローに組み込むことができました。
また、途中からはタスクの記載内容そのものも工夫しており、Devin Search を使ってプロジェクトのコードベースを検索し、必要な作業内容を洗い出した上で依頼プロンプトを自動生成し、それをそのまま Jira に転記する運用としました。これにより、コードベースとのコンテキストの齟齬を抑えつつ、人間がタスク依頼をするための時間の削減ができるのではと考えていました。
ローカルでの動作確認もすべて自動で実行
Devin には、開発環境が整ったワークスペースを用意でき、以下のような手順で動作確認を行わせています：
- API サーバーを立ち上げ、
curlで対象エンドポイントへリクエスト - レスポンスをチェックし、正常系・異常系の挙動を確認
- 必要に応じてテスト用のデータを挿入し、
psqlコマンドで DB の中身を確認 - テストが通ったら、次のステップへ進む
これによってテストデータの投入〜動作確認〜状態確認までを一通り自動化できます。
以下は実際に Devin が作成した PR の動作確認結果です。
Knowledge 機能を使って Devin を“育てる”
今回の取り組みの中で最も重要だったのが、Devin の Knowledge 機能をフル活用して「行動の型」を学習させたことです。
Devin とのやりとりの中で出した指示に対し、 Devin が自動的に「Knowledge として取り込む候補」を提示してくれる機能があります。 これを根気よくひたすらチェック＆反映し続けることで、次回以降の作業に同じ指示を繰り返す必要がなくなりました。
さらに応用として、
- あえて誤った行動を取らせて、それを正すことで意図的に Knowledge を生成させる
- 失敗例も含めて記録し、「やってはいけないこと」も含めた学習データとして扱う
といった形で、ナレッジを構造化して蓄積するような運用を行いました。
この「指示と修正のループ」を通じて、Devin は徐々に私たちのチームに最適化された動きを学習していき、 単なるツールではなく、“育てられるメンバー”としての立ち位置が明確になっていきました。
プロジェクトの“暗黙知”を文章化し、事前共有
Devin との連携を円滑にする上で非常に効果があったのが、 プロジェクトの前提知識（いわゆる“暗黙知”）を文章化したことです。
具体的には：
- プロジェクト特有のアーキテクチャ設計の方針
- API 設計や命名、レスポンスの扱いなどの実装ルール
- チーム内で共有されていたが、ドキュメントとしては存在していなかった設計思想や技術的な判断基準
これらを明文化することにしました。チームでは Cursor も利用していたため、共通化の目的も含めて、下図のようにCursor の .cursor/rules に蓄積していきました。
それぞれのルールには以下のような内容をまとめました。
| ルールファイル名 | 内容 |
|---|---|
| coding-guide.mdc | チーム内のコーディング規約 |
| general.mdc | AI のための作業ルール集 |
| gorm.mdc | ORM に特化したプロジェクト固有の実装ルール |
| manual.mdc | アプリケーションの動作確認方法などのマニュアル |
| project-structure.mdc | プロジェクトで採用しているアーキテクチャに関する資料 |
Devin にもこの内容を実装前に読み込ませるようにしたことで、
- Devin が既存のコードベースとズレたスタイルや構造でコードを書くのを防止
- チームの技術的意思決定が AI によってブレることを回避
といった効果が得られました。
この取り組みは結果的に、人間にとっても「このプロジェクトはどういう前提で動いているか」を言語化して再確認する機会になり、 オンボーディングの促進やチームの技術的共通理解が一段深まるといった副次的な効果もありました。
PR の提出もチームのルール通りに
Devin には、実装が完了したら GitHub に PR を出してもらっています。
このとき PULL_REQUEST_TEMPLATE.md に沿って人間が出す PR を同じフォーマットで、以下のように記載させています：
他にもブランチ名など細かい開発上のルールについても人間と同じルールに則るように Knowledge の育成を実施しました。 これによって、人間のレビュー担当者がすぐに状況を把握できるようになり、 レビュー速度の向上と認識齟齬の削減に役立ちました。
うまくいったこと
ここからは、Devin に実装と動作確認を一任してみて「うまくいった」と感じた点をいくつか紹介します。
自分の時間が“考えること”に集中できた
Devin にコードの実装を任せることで、自分の作業が設計とレビューに集約され、 「手を動かすより、頭を使う」時間が明らかに増えました。
他のチームメンバーの PR レビューにもしっかり時間を割けるようになり、 結果的にチーム全体としての技術的な精度も底上げされた感覚があります。
PR が毎日大量に届き、レビューが回るサイクルができた
Devin は、タスクを投げれば淡々と実装し、curl で動作確認まで行って PR を提出してくれます。 Description には動作確認ログがきっちり貼られており、人間が迷わずレビューできる状態が自然に整いました。
下図は、今回の取り組みの機能開発を対象として Devin が作成した PR 数の推移ですが、リポジトリには 1 日で複数の PR が届くようになり、コードのアウトプットサイクルが以前よりも明確に加速しました。
特に後半では、Devin Searchを活用してコードベースから直接必要な情報を洗い出し、それをもとに依頼プロンプトを作成するという手法が確立されたことで、タスク依頼の作成スピードが格段に上がりました。この仕組みによって、担当者が手作業で説明を構築する手間が減り、かつ Devinに渡すコンテキストの質も高まったことで、アウトプットの精度も明確に改善された実感があります。
実装スタイルの統一感が保てた
事前に .cursor/rules にアーキテクチャ方針や実装ルール、命名規則などの暗黙知をまとめたことで、
Devin が書くコードが既存のコードベースと大きくズレることはほとんどなくなりました。
特に、例外処理の流れやレスポンス構造の揃え方など、人間がレビュー時に突っ込みがちだった箇所が先回りで整っているのはとても助かりました。
時間外や休憩中も、作業が進む
Devin の強みのひとつは、人間が手を離している時間でもタスクを処理し続けてくれることです。 業務時間外や昼休みに投げたタスクが、次に PC を開いたときには実装＋確認済みで PR になっているというのは想像以上に便利でした。
「放っておいても開発が進んでいる」状態は、心理的にも大きな安心感がありました。
複数のタスクを同時並行で進めやすくなった
Devin がタスクをこなしてくれることで、自分は別の仕様策定や実装レビューに同時並行で取り組めるようになり、 開発タスク全体の並列度が上がったと感じています。
これは AI を単なる補助ツールとしてではなく、明確な担当者として扱うことで初めて得られる効果だと実感しました。
細かい検証や環境立ち上げの負担を軽減できた
仮説としていた「実装中に発生しがちな細かい検証や環境立ち上げにかかる時間を減らせるのでは？」という点は、想像以上に効果がありました。
複数のタスクを同時に進める場面でも、Devin がそれぞれのワークスペースで動作確認を進めてくれるため、 人間側で毎回ローカル環境を切り替える必要がなくなり、コンテキストスイッチの負荷が大幅に軽減されました。
スクラムで培った“タスク分解スキル”がそのまま Devin に活きた
もうひとつの仮説「スクラムの中で培った“タスク分解のスキル”を活かすことで、Devin を最大限に活用できるのでは？」も非常に有効でした。
例えば、バックエンドの API を 1 本開発するという実装でも、以下のようにタスクを細かく分解していました。 設計と総合テスト以外のタスクは Devin に依頼し、curl や psql コマンド、デバッグログ、テスト実行を通じて動作確認を行ってもらっています：
| タスク内容 | 担当 | 確認方法・アプローチ |
|---|---|---|
| API の定義 | 人間 | OpenAPI で設計、仕様を JIRA に記載 |
| ハンドラの大枠の実装 | Devin | ルーティング・パラメータの受け取りをデバッグログで確認 |
| 入力バリデーションの実装 | Devin | リクエストパターンを変えてバリデーションエラーを確認（デバッグログ） |
| トランザクション処理の実装 | Devin | ローカルの PostgreSQL に接続し、psql で DB 状態を確認 |
| テストコードの実装と実行 | Devin | 単体テストを実行し、curl やログで動作確認 |
| 結合テスト | Devin | curl を使って API レスポンスの整合性を確認 |
| 総合テスト | 人間 | GUI 上でアプリケーション全体の挙動を確認 |
このようにしていたので、1 タスクあたりの期待値が明確であり、Devin の作業精度やコードの一貫性が向上したと実感しました。
- 意味のある最小単位でタスクを切り出す努力が、そのまま Devin の作業範囲を明確化し、出力の精度向上につながった
- Devin が出す大量の PR に対して、内容が整理されているためレビューもスムーズに行えた
- 結果的に、タスク分解という「人間の生産性を上げるために実施していた努力」が、そのまま機械の生産性を引き上げることに直結したと実感しました
うまくいかなかったこと
もちろん、すべてがスムーズにいったわけではありません。 Devin を使い倒す過程では、いくつかのつまずきポイントや制約に直面しました。
Devin が“育つ”までは正直かなり大変
Devin の Knowledge 機能は非常に便利ですが、それが効果を発揮するまでの期間は、かなり根気のいるフェーズでした。
- 最初は理想とはまったく異なるコードを出力してくる
- 細かい設計意図が伝わらず、何度もやり直しや手戻りが発生
- Knowledge に書いてある内容でも、条件や文脈が違うだけでうまく機能しないケースが多発
そのため、「これは違う」「こうしてほしい」といった指摘や再実行のやりとりを何度も繰り返す必要がありました。
人間であれば 1 回の説明で済むことも、Devin には“複数回・少しずつ・明文化して”教える必要があるという実感があり、 ある意味では、育成コストがかかる AI エンジニアとして向き合う必要がありました。
具体例を示すと、下図のように 1 つのタスクをレビュー準備完了にするまでに、作業中の slack のやり取りで 85 件のコメントのやり取り、PR の指摘数で 38 件のやり取りが発生してしまうようなこともありました。
“万能ではない”ことを前提に運用設計する必要がある
Devin は非常に優秀な実装パートナーですが、やはり非機能要件や例外的な仕様の理解は苦手です。
- 仕様が変更されたときの対応が遅い
- ある程度複雑なユースケースでは、コードは書けても意図がズレる
指示に記載した、インプットとアウトプットを守ってはいるが、中身のロジックが想定と違うという場面が何度かあり修正コストがかかってしまいました。
軌道修正にかかるコストが大きい
特に感じたのが、Cursor との Devin の違いによる“軌道修正の手間”の差です。
例えば、意図がズレた出力が返ってきた場合、 Cursor であれば その場でエディタ上のコードを見ながらすぐに修正・追記ができるため、 会話感覚で方向性を整えることができます。
一方で Devin の場合は、次のようなフローになります：
- PR が出てくる
- コメントで「ここはこうしてほしい」とフィードバック
- Devin が修正 → 再コミット・再 Push
- もう一度 PR レビュー
Devin の Session の画面に張り付いて Devin の動作を監視し続けない限りは、どうしても上記のような手順になってしまいます。 この一連のやり取りにはどうしても時間と手数がかかるため、 特に条件分岐や例外処理が多く、細かい判断が必要な複雑な API の実装においては、Cursor の方がスピード感があったというのが正直な実感です。
Devin は「明確なゴールに向かって淡々とこなす」場面で真価を発揮しますが、 柔軟に方向修正が必要な開発では、インタラクティブなエージェントの方が適していると感じることも多くありました。
最終的な運用モデル
ここまでの取り組みを通じてたどり着いたのは、 「AI を適材適所で活かす、ハイブリッドな開発手法」でした。
Devin は非常に強力なツールですが、すべてのケースで万能というわけではありません。 そのため、最終的には次のような役割分担が良いと考えています。
タスクの規模・性質でエージェントを使い分ける
シンプルな CRUD API や、実装パターンが明確なタスク → Devin にまるごと任せることで高速に並列でアウトプットが得られる
複雑なロジックや、頻繁に方向性の調整が必要なタスク → Cursor などインタラクティブなエージェントで人間と一緒にエディタ上で柔軟に進めるのが効率的
タスクを事前に設計し、規模や性質に応じて「Devin」「Cursor」「人間」へ適切に振り分けることが、 全体のスループットを最大化する鍵になると感じています。
人間は“思考”に特化し、生産性を最大化
人間が担うべきなのは、以下のような思考と判断が求められる部分です：
- 要件のすり合わせと仕様設計
- 技術的な方針決定（アーキテクチャ選定など）
- 最終的な品質レビューと統合テスト
- タスクの分解と優先度整理
「手を動かす」から「構造をつくる・意思決定する」役割へと自然にシフトできたのは、Devin をチームに組み込んだからこその変化でした。
AI との連携を支えるナレッジ整備が基盤
Devin を最大限に活かすためには、以下の取り組みが不可欠でした：
- JIRA・Slack・Playbook の連携によるスムーズなタスク運用
- Knowledge 機能での行動パターン学習と精度向上
- ドキュメント整備を通じたプロジェクトの暗黙知の文章化
これらの整備によって、Devin が単なるツールから「共通認識を持った実装者」へと進化し、再現性の高い開発が可能になりました。
LLM やエージェントを前提にした“新しい開発設計”へ
最近では、実装だけでなく、仕様設計や技術方針の検討フェーズでも LLM を活用しようという動きがチーム内で出てきています。
例えば：
- 「この要件に対して、どんな設計パターンがありうるか？」
- 「他社の事例としては、どのような技術選定がされているか？」
- 「この API 設計で考慮すべき落とし穴は？」
といった、方針を考える初期段階から LLM とディスカッションするスタイルが少しずつ定着しつつあります。
これによって、
- 属人的になりがちな設計の初期検討を言語化・構造化しやすくなる
- 人間と AI がアイデアのたたき台を一緒につくるという協働プロセスが可能になる
- 設計の透明性と再利用性が上がる
といった副次的な効果も見え始めています。
Devin のように「手を動かす AI」だけでなく、“考える AI”として LLM を使う流れも確実に加速しているのを感じています。
今回の成果
今回の私の取り組みでは、約 2 ヶ月の期間で Devin が 64 件の Pull Request を作成し、対象機能の実装と検証をすべて完遂しました。 単なる試験導入ではなく、本番の開発プロジェクトで AI エージェントが実働した成果として、大きなインパクトを持つ事例になったと感じています。 また、執筆時点で会社全体ではマージ済みの PR が累計 258 件を超えており、Devin の利用は着実に広がりを見せています。
下図は社内全体での、Devin が作成したマージ済み PR 数の推移です。
まとめ
今回の記事では、Devin を使って約 2 ヶ月分のバックエンド API 実装と動作確認をまるごと任せてみた取り組みについて紹介しました。
Devin を使いこなすには、最初にそれなりの準備と学習コストがかかります。 指示の出し方、タスク設計、ナレッジの蓄積など、「ただ投げて終わり」ではうまくいかない場面も多くありました。 ですが、それらを乗り越えて環境が整ってくると、 Devin は実装パートナーとして確かな役割を果たしてくれる存在になります。
さらに、Devin だけでなく、他の LLM ツールも組み合わせることで、 開発プロセス全体を再設計し、より少ない人数でも高いアウトプットを実現できる体制に近づける手応えも感じました。 最後に、この記事で一番伝えたいのはこの一言です：
本気で取り組んでみると見える世界がある。
この記事が、これから Devin や LLM エージェントを開発に取り入れていく方々のヒントになれば幸いです。 バイセルではエンジニアを募集しています。少しでも気になった方はぜひご応募お待ちしています。
