Devin AI で実装タスクを丸投げする際のプロンプト設計2026

この記事でわかること

  • 自律型エージェント Devin に渡すタスク仕様の書き方
  • Devin が暴走しない範囲設定（受け入れ条件・スコープ・禁止事項）
  • 複数タスク並列時のレビュー運用フロー

結論

Devin は中級者が「自分の代わりに半日座って書いてくれる別人格のエンジニア」と捉えるのが実態に近いです。プロンプトは Issue テンプレートに近い構造で、受け入れ条件と禁止事項を必ず含めるのがコツ。これがあるかないかで成功率が体感で2倍は変わります。

本題

Devin プロンプトの黄金フォーマット

中級者向けに、毎回最低限埋めるべき項目は次の6つです。

  1. タイトル（1行）: 「Stripe Webhook で plan_id を users テーブルに反映」
  2. 背景: なぜ必要か、関連する既存コード
  3. 完成イメージ: 動いた状態を箇条書きで
  4. 受け入れ条件: テストで通ればOK、という客観基準
  5. スコープ外: 触ってほしくないファイル / リファクタ
  6. 禁止事項: 「依存ライブラリの追加」「マイグレーションの自動実行」など

これを Issue として GitHub に書き、Devin にそのリンクを渡すのが2026年時点で最も安定する流れです。

受け入れ条件は「テスト通過」で書く

Devin に丸投げする上で最重要なのは、合格ラインを Devin が機械的に判定できるようにすることです。

良い例: - npm test -- subscription.spec.ts がすべてパスする - 既存のテストもすべてパスする（リグレッションなし） - 該当エンドポイントを curl で叩いた結果、200 と JSON { status: "ok" } が返る

悪い例: - 「ちゃんと動いていればOK」 - 「いい感じにエラー処理してください」

機械判定可能な条件を 3〜5 個並べると、Devin が自分でテスト → 修正 → 再テストの自律ループを回せます。

スコープ外の明示で暴走を防ぐ

Devin は親切心でリファクタや関係ないファイルにも手を入れがちです。次のような禁止リストを必ず付与します。

  • app/admin/ 以下は一切変更しない
  • パッケージ追加禁止（既存依存のみで実装）
  • マイグレーションファイルを直接編集しない（新規追加のみ）
  • .env.example 以外の環境変数ファイルに触らない

これだけで PR の差分が読みやすくなり、レビュー時間が3割は短縮されます。

並列タスク運用のコツ

Devin は同時に複数タスクを走らせられますが、中級者ほど「最大3並列まで」に絞るのが推奨です。

理由は3つ。 1. 同じファイルを複数タスクで触ると、merge コンフリクトの解決が結局自分の仕事になる 2. レビューが追いつかず、合格ラインの検証ができないまま PR が積み上がる 3. Devin の時間枠（ACU）を浪費する

3並列で運用する場合は、ファイルが衝突しない単位（フロント / バック / インフラ）で切るのが鉄板です。

レビュー時に必ず確認する3つ

Devin の PR は「動いてはいるが微妙」というケースが頻発します。レビュー時の最低限のチェック観点。

  1. 依存追加の有無: package.json / requirements.txt に新規追加がないか
  2. テストの内容: テストが存在するだけでなく、本当に意味のあるアサーションか
  3. マジックナンバー / ハードコード: 環境変数や定数に切り出されているか

ここを通せば、Devin の PR を高速にマージできます。

よくある質問（FAQ）

Q1: Devin にどこまで任せるのが安全ですか？

A1: 「既存テストが整っているリポジトリの、機能追加 or バグ修正」までが安全圏です。テストがない領域や、設計を1から考える必要があるタスクは人間が骨格を決めてから渡すのが鉄則です。

Q2: 月額料金は中級フリーランスでも回収できますか？

A2: 1ヶ月あたり数件の中規模タスクをまるっと任せられるなら回収可能ラインです。1日30分しか使わない人にはコスパが合いません。

Q3: Cursor や Copilot との使い分けは？

A3: Cursor / Copilot は手元で書きながら補助、Devin は自分が席を外している間に進めてもらう用途、と棲み分けるのが2026年時点の主流です。

まとめ

Devin の威力は、丸投げの精度＝プロンプト設計の精度に直結します。Issue テンプレ的な6項目と、機械判定可能な受け入れ条件、スコープ外の明示があれば、半日分のタスクをコーヒー1杯分の時間でレビューまで持っていけます。最初は1並列で運用感を掴み、慣れたら3並列まで広げていきましょう。