AI駆動開発における、マージ・リリースの怖さをDevOps的な視点で軽減する方法を模索中です。以前はClaude Codeを使った方法を試しました。

今回はDevinを使ってやってみます。

タスクを依頼するプロンプト

以前Claude Codeで実践した記事を、GeminiにDevin向けの調整しました。今回もDevOps的な進め方をプロンプト内でできるだけ明確に指示しています。Agent Teamsに相当する機能がないため、並列作業ではなく１つずつPRを作らせることにしました。

要件

ブログページに検索機能を実装します（記事タイトル・抜粋を対象、WP API Search機能を活用）。
開発の進め方（スモールバッチ/TDD実践）

Devinは**「テスト・実装・マージ」を1サイクル**とし、各機能を独立したPRとして順次mainへ統合します。
Phase 1: 逐次スモールバッチ実装（3ステップ）

以下の順で1つずつ完結させます（各<200行、30分以内）：

    API Layer: WordPress Search API実装（lib/wordpress.ts, types/index.ts）

    UI Input: 検索入力UIコンポーネント（components/BlogSearchBox.tsx）

    UI Results: 検索結果UIコンポーネント（components/BlogSearchResults.tsx）

各ステップの必須タスク:

    TDDの徹底: 実装前にテストを作成し、失敗を確認してからコードを書く

    CI/CD監視: PR作成後、gh pr checksでCIパスを30秒毎に確認し、失敗時は即修正

    マージ待機: CI通過後、AskUserQuestionで人間にマージを依頼。マージ完了を確認してから次のステップへ進む

Phase 2: 継続的デリバリーの品質管理

各PRマージ後のタスク:

    git checkout main & git pull で最新化

    マージ後のmainブランチでテストを再実行し、デグレがないことを確認

    gh pr view --json state でステータスが MERGED であることをエビデンスとして記録

Phase 3: 最終統合（配線のみ）

Integrationタスク:

    mainからfeature/blog-search-integrationを作成

    Phase 1でマージ済みのコンポーネントをimportして接続（<100行）

    新規ロジック・コンポーネントの作成は禁止

    E2Eテストの追加、PR作成、CI監視、最終完了報告

成功基準

    4つの独立したPR（各<200行）

    すべてのPRがCI通過し、順次mainにマージ済み

    常に動作可能なmainブランチを維持

    最終的な検索機能が本番相当の環境で動作すること

Ask Devinで事前の調査を実施する

planモードの代わりにAsk Devinを使った事前調査を実施します。実装方法やポイントなどをレポートしてくれるので、直感的に違和感がないかをチェックしておきます。

問題がなさそうでしたので、Construct Devin Promptを使ってプロンプトを生成させます。

プロンプトを生成すると、Send to Devinボタンが出てきます。これでそのままDevinによる開発を指示できます。

Devinで開発を進める

ということでDevinに調整させたプロンプトで開発を開始しましょう。

１つPRを作ったところで、指示待ちになりました。しかしこれは「自律的にやりきれ」と指示したことで続行してくれましたので、指示の出し方次第な様子です。

前提のsmall batch size commitができたので、CIやレビューエージェントの結果を確認させます。問題がなければマージして作業を続行させましょう。

ここまでだいたい１０分から１５分程度でした。統合開発時のレポートでは、画面録画での動作もレポートしてくれました。

あとはissueでコメントやレビューをつけてDevinに修正させます。

問題がないと判断したタイミングで、マージしてリリースします。

初回の作業で一時停止するハプニングはありましたが、その後かなり自律的に作業を進めてくれたなという印象です。

DevinのInsightsで簡単に振り返る

今回のタスクで使ったリソースがこれくらいです。多くもなく、少なくもなくといった感じでしょうか。PRを4つも作成し、レビュー後の修正を含めると３・４ループしていることになりますので、本当に「まぁそんなものか」といった感じです。

セッションサイズがMですので、Devinの基準でも健全な使い方の範囲内っぽい様子でした。

レポートを見ると、ACU消費の15-20%はDevin環境下でのテスト実行とスクリーン録画撮影だった様子です。テスト実行のコストをDevinかCircleCIどっちで支払うかって感じですかね。個人的にはフィードバックサイクルが早くまわるはずなDevin側での実施を選びたいなと思いました。

ちなみにプロンプトの提案については、レビューコメントで入れたUI要件を明記しろというものだけでした。これはまぁ、動かしてみてから気付いたものなので致し方なしですね。

また、セッションの中でナレッジのサジェストがありました。今回のような複数のPRに分割して並列実行できるケースについてのナレッジなので保存しておきます。これで次回からは自律的にやってくれそうな気配です。

以下に原文を貼るので、Devinで試したい方はぜひお使いください。

When multiple PRs touch independent files (e.g., separate new components), create each branch from main and work on them in parallel rather than waiting for each PR to be merged before starting the next. The user explicitly prefers autonomous progress – only stop and wait for merge when there is an actual code dependency (e.g., an integration PR that imports from the other PRs). Create each feature branch from the latest main independently.

あって良かったと思ったもの

今回の開発において事前に設定しておいて助かったと思うものがいくつかあります。

Cloudflare Workersへのプレビューデプロイ

まずはブランチごとにプレビューデプロイ機能です。今回はCloudflare Workersを使っており、PRにpreview urlが表示されていました。

なにより作業中のブランチをチェックできるのが大きいなと思います。実際に動かしてコメントできますし、ローカルにコードをDLしたりしなくて済むのがありがたいですね。

Next.jsのISRをオンにすると、Durable Objectなどの兼ね合いでこれが動かなくなる問題があり、どうしたものか・・・というところではあります。

Devin Machineの事前セットアップ

Devinではアプリを登録する際に、セットアップ手順やリント・テスト・ビルドのコマンドを登録させるDevin Machineのセットアップを勧められます。これによってテストやリント・ビルドをDevinがほぼ間違いなくチェックしてくれるようになりました。これらのチェックがパスした状態でコミット・PRしてくれたのは大きく、CIサービスのコストやそれらの結果を待つステップの時間短縮になっています。

CI側にオフロードするとしたら、Devin側はaffected testだけチェックするような差分ベースのコマンドにしておくとかかなと思います。

自動テスト やCIパイプライン

ユニットテストや統合テストなどを整備し、CircleCIで実行しています。今回はDevin側で検証してくれていたので、100%グリーンでした。ただ、これによって「テストが整備されている既存の動きが壊れていない」という保証があるのは、気持ちの面で大きく、自信を持ってマージできました。

おわりに

Claude CodeのAgent Teamで試したときは、並列実行（Small Batch Size Commit）と直列作業（単体開発と統合開発）を同時に指示したことで混乱を生みました。Devinの場合はそもそも並列実行ができないということもありますが、直列での作業をどう実行するかに絞ることができた分、スムーズに実行できた印象があります。

Claudeのサブスクリプションを使った開発に比べると、費用対効果に迷う部分はあります。ただ、それでも「こんなにポンポンマージしていいものか」と逆に不安になる程度にはスムーズな開発でした。