Devin駆動開発

はじめに

Cognition AI社が開発した自律型AIエンジニア「Devin」は、従来のコード補完ツールとは一線を画す存在です。独自の開発環境を持ち、コーディングからデバッグ、Git操作、PR作成まで一貫して自律的に行えます。この能力を開発プロセスの中核に据えるアプローチを、私たちは「Devin駆動開発」と呼んでいます。

本記事では、直近実施したフルスタックWebアプリケーションの開発で蓄積した427コミットの実績データを基に、Devinの得意・不得意を分析し、効果的な活用方法を解説します。ゼロイチ開発でDevinに全てを任せた結果、何がうまくいき、何がうまくいかなかったのか。その教訓から導き出したベストプラクティスを共有します。

---

コミット分析 – Devin実装可否の仕訳

写真売買マーケットプレイスとして開発したフルスタックWebアプリケーションを開発しました。Next.js、Prisma、AWS Amplifyを採用し、認証、出品、購入、管理画面など多岐にわたる機能を実装しました。

開発期間中に蓄積された356件の非マージコミットを分析したところ、Devinによる実装は128件（36%）、人間による実装は228件（64%）という結果でした。この数字だけを見ると「Devinは3分の1しか貢献していない」と思われるかもしれませんが、実態はより複雑です。Devinが担当したのは大規模な機能実装やインフラ構築が中心であり、人間が担当したのはUI/UXの調整や本番環境のデバッグが中心でした。

以下では、各コミットを「Devinで実装できたもの」「Devinで実装できなかったもの」「タスクが細分化されていればDevinでも実装可能だったもの」の3つに分類し、Devinの得意・不得意を明らかにします。

統計サマリー

---

1. Devinで実装できたもの（128件）

カテゴリ別内訳

---

2. Devinで実装できなかったもの（228件）

カテゴリ別内訳

---

3. タスクが細分化されていればDevinでも実装可能だったもの

推定: 228件中 約60件（26%） は、タスクを細分化すればDevinでも実装可能だった

---

4. Devinが得意なタスク（具体例付き）

得意なタスク一覧

具体的な成功例

# リファクタリング（ボタンコンポーネント統一）
802f2f8|Devin AI|Update ListingForm component to use SecondaryButton for image deletion
c67fe81|Devin AI|Update mypage and wallet/history pages to use shared button components
a487076|Devin AI|Update users/[userId] and mypage/listings/[id] pages to use shared button components
834b96b|Devin AI|Update mypage/follow, purchase/completed, and timeline/[id] pages to use shared button components
...（計20件以上）

このような「パターンが明確で反復的なタスク」はDevinの得意領域です。

---

5. Devinが苦手なタスク（具体例付き）

苦手なタスク一覧

具体的な失敗パターン

# 本番環境のデバッグ（連続したfixコミット）
a836c9e|maro0217|fix login error
9fbdfea|maro0217|add debug
6ae97e3|maro0217|add console
e91e060|maro0217|cleanup the cache
2de21e1|maro0217|fix iam role
31b0d78|maro0217|fix
3c3046f|maro0217|fix prebuild

このような「複数回のトライ&エラーが必要なタスク」はCursorの方が効率的です。

---

6. 結論：Devinの使い分け

Devinに依頼すべきタスク

Cursor/Claudeに依頼すべきタスク

プロジェクトの教訓

1. ゼロイチ開発のPhase 1-5は粒度が大きすぎた → 各Phaseを5-7個のサブPhaseに分割すべきだった
2. UI/UXの調整はCursorで正解 → 視覚的フィードバックが必要
3. リファクタリング（ボタンコンポーネント統一）はDevinで成功 → パターンが明確で反復的
4. 本番環境のデバッグはCursorで正解 → 複数回のトライ&エラーが必要

最適な使い分け:

• Devin: 異なるブランチでの並列実行、パターンが明確なリファクタリング、インフラ構築
• Cursor: UI/UX調整、デバッグ、トライ&エラーが必要なタスク

---

Devinでのゼロイチ開発

開発初期、私はDevinに大きな期待を寄せていました。プロンプトと仕様書を準備し、大規模な機能実装を一気にDevinに任せました。

上記でも示した通り、結果は期待通りとはいきませんでした。コーディング自体は行われていたものの、動いていない箇所や仕様が満たされていない箇所が散見され、結局大半はCursorで実装し直すことになりました。一方で、後半の細かな仕様修正をDevinに依頼したところ、これはうまくいきました。

この明暗を分けた原因は何だったのか。PR #17〜#27を詳細に分析した結果、最大の問題は「PRの粒度が大きすぎた」ことでした。各PRは1000〜2600行の変更を含んでおり、Devinが全体を把握して一貫した実装を行うには大きすぎたのです。

---

PR粒度の詳細分析表

---

評価基準

---

総評

11個のPRのうち、8個が「大きすぎる」、3個が「やや大きい」という結果でした。「適切」と評価できるPRは1つもありませんでした。

Devinのコンテキストウィンドウを考えると、1PRあたり300〜500行が適切です。1000行を超えると、Devinは全体を把握できず、断片的な実装になります。また、各PRに複数のAPIエンドポイントやUIページが含まれており、PRが肥大化していた要因となっていました。

---

ゼロイチ開発 詳細戦略ガイド

改めてゼロイチで開発する場合、どのように実装を分割して進めていくかを詳細に整理しました。

基本原則

– 各フェーズの詳細

Phase 1: Foundation Setup（現状: #17 +2540行 → 5つのPRに分割）

Phase 1-1: Prismaスキーマ定義（+400行）

実装内容: 20モデル、13 Enumの定義のみ

検証: npx prisma validate が成功すること

重要: このPRが全ての参照パターンの基盤になる

Phase 1-2: マイグレーション + シードデータ（+300行）

実装内容: 初期マイグレーション、シードスクリプト

検証: npx prisma migrate dev → npx prisma db seed が成功すること

参照: Phase 1-1で作成したスキーマ

Phase 1-3: Prismaクライアント + DB接続テスト（+200行）

実装内容: src/lib/prisma.ts、簡単なテストAPI

検証: /api/health でDB接続確認

参照: Phase 1-2で作成したマイグレーション

Phase 1-4: S3サービスライブラリ（+300行）

実装内容: src/lib/s3.ts（署名付きURL生成、アップロード）

検証: 環境変数設定後、S3へのアップロードテスト

参照: Phase 1-3のPrismaクライアントパターン

Phase 1-5: Stripeサービスライブラリ（+300行）

実装内容: src/lib/stripe.ts（PaymentIntent作成）

検証: テストモードでPaymentIntent作成

参照: Phase 1-4のサービスライブラリパターン

---

Phase 2A: Core Authentication（現状: #18 +2508行 → 7つのPRに分割）

Phase 2A-1: Cognito統合 + ログイン（+400行）

• src/lib/cognito.ts（Cognitoクライアント）
• POST /api/auth/login
• /login ページ

検証:

curl -X POST http://localhost:3000/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","password":"Test123!"}'

ブラウザで /login にアクセスし、フォームが表示されること

Phase 2A-2: ログアウト + セッション管理（+250行）

• src/lib/cookie.ts（Cookie管理）
• POST /api/auth/logout
• GET /api/auth/session

検証: ログイン後、/api/auth/session でセッション情報が返ること

参照: Phase 2A-1のCognitoクライアント

Phase 2A-3: サインアップ開始（+300行）

• POST /api/auth/sign-up/email
• /signup/email ページ

検証: メールアドレス入力後、Cognitoから認証コードが送信されること

参照: Phase 2A-1のCognitoクライアント、Phase 2A-2のCookie管理

Phase 2A-4: 認証コード確認（+300行）

• POST /api/auth/sign-up/confirm
• POST /api/auth/sign-up/resend
• /signup/code ページ（60秒カウントダウン付き）

検証: 正しいコードで確認成功、間違ったコードでエラー

参照: Phase 2A-3のサインアップ開始

Phase 2A-5: パスワード設定（+300行）

• POST /api/auth/sign-up/password
• /signup/password ページ

検証: パスワード設定後、自動ログインされること

参照: Phase 2A-4の認証コード確認

Phase 2A-6: パスワードリセット要求（+250行）

• POST /api/auth/password/reset/request
• /password/reset/request ページ

検証: メールアドレス入力後、リセットコードが送信されること

参照: Phase 2A-1のCognitoクライアント

Phase 2A-7: パスワードリセット実行（+300行）

• POST /api/auth/password/reset/confirm
• /password/reset/confirm ページ

検証: 新パスワードでログインできること

参照: Phase 2A-6のパスワードリセット要求

---

Phase 2B: Registration & Profile（現状: #19 +981行 → 4つのPRに分割）

Phase 2B-1: 認証コードシステム（+300行）

• src/lib/verification-code.ts
• DBテーブル（VerificationCode）
• 10分有効期限、最大3回試行制限

検証: コード生成 → 検証 → 期限切れテスト

Phase 2B-2: bcryptパスワードハッシング（+200行）

• src/lib/password.ts（hash、verify関数）
• 既存の認証APIに統合

検証: パスワードハッシュ生成 → 検証テスト

Phase 2B-3: ログインボーナスAPI（+300行）

• POST /api/login-bonus/claim
• 7日間連続ログインシステム（1日目〜6日目: 1pt、7日目: 5pt）

検証: 連続ログインでポイントが正しく付与されること

Phase 2B-4: プロフィール編集（+300行）

• GET/POST /api/mypage/profile
• /mypage/profile/edit ページ

検証: プロフィール更新 → 取得で反映確認

---

Phase 3A: Image Upload & Processing（現状: #20 +2195行 → 6つのPRに分割）

Phase 3A-1: S3署名付きURL生成API（+250行）

• POST /api/images/upload-url
• ファイル名、Content-Type検証

検証: 署名付きURLが生成され、S3にアップロード可能なこと

Phase 3A-2: ImageUploadコンポーネント（+350行）

• src/components/ImageUpload.tsx
• プログレス表示、プレビュー、エラーハンドリング

検証: ブラウザで画像選択 → アップロード → プレビュー表示

Phase 3A-3: サムネイル生成サービス（+300行）

• src/lib/thumbnail-generator.ts
• 1:1正方形 300x300px

検証: 様々なアスペクト比の画像で正方形サムネイル生成

Phase 3A-4: AWS Rekognition統合（+350行）

• src/lib/image-analyzer.ts
• コンテンツモデレーション、顔検出

検証: テスト画像でモデレーション結果確認

Phase 3A-5: ブラー処理サービス（+200行）

• src/lib/image-blur.ts
• 20px Gaussian blur

検証: 不適切コンテンツ検出時にブラー適用

Phase 3A-6: 画像処理パイプライン統合（+400行）

• POST /api/images/process
• 全サービスの統合（分析 → サムネイル → リサイズ → ブラー）

検証: エンドツーエンドの画像処理フロー

---

Phase 3B: Listing Management（現状: #21 +1971行 → 7つのPRに分割）

Phase 3B-1: Zodバリデーションスキーマ（+150行）

• src/lib/validations/listing.ts
• 価格: 100-100,000円、タイトル: 3-100文字、画像: 1-5枚、ジャンル: 1-5個

検証: 各バリデーションルールのテスト

Phase 3B-2: ListingService（作成のみ）（+300行）

• src/lib/services/listing.ts（create関数のみ）

検証: 出品作成 → DB確認

Phase 3B-3: 出品作成フォーム（ステップ1: 画像）（+350行）

• /mypage/listings/new ページ（画像アップロードステップ）

検証: 画像アップロード → 次のステップへ遷移

Phase 3B-4: 出品作成フォーム（ステップ2: 詳細）（+350行）

• 詳細入力ステップ（タイトル、説明、価格、ジャンル）
• POST /api/listings

検証: フォーム送信 → 出品作成完了

Phase 3B-5: 出品一覧（+300行）

• GET /api/listings（自分の出品）
• /mypage ページ（ステータスごとのタブ）

検証: 出品一覧が正しく表示されること

Phase 3B-6: 出品詳細/編集（+350行）

• GET/PUT/DELETE /api/listings/[id]
• /mypage/listings/[id]、/mypage/listings/[id]/edit ページ

検証: 詳細表示、編集、削除が正常に動作すること

Phase 3B-7: 管理者承認（+400行）

• POST /api/admin/listings/[id]/approve
• POST /api/admin/listings/[id]/reject
• /admin/listings ページ

検証: 承認 → ステータス変更、通知送信

---

Phase 3C: Timeline & Detail（現状: #22 +1245行 → 6つのPRに分割）

Phase 3C-1: タイムラインAPI（+250行）

• GET /api/timeline（承認済み出品のみ、ページネーションなし）

検証: 承認済み出品のみが返ること

Phase 3C-2: タイムラインページ（基本表示）（+300行）

• /timeline ページ（基本的なカード表示）

検証: 出品カードが正しく表示されること

Phase 3C-3: 無限スクロール（+250行）

• カーソルベースページネーション
• IntersectionObserver

検証: スクロールで追加読み込みが動作すること

Phase 3C-4: フィルタリング（+200行）

• ジャンル、ロケーションフィルタ

検証: フィルタ適用で結果が変わること

Phase 3C-5: 出品詳細ページ（+350行）

• GET /api/timeline/[id]
• /timeline/[id] ページ（画像カルーセル、ストーリーロック）

検証: 購入者/非購入者でストーリー表示が異なること

Phase 3C-6: 通報システム（+250行）

• POST /api/reports
• 重複防止

検証: 通報作成、重複エラー確認

---

Phase 4A: Payment & Purchase（現状: #23 +1519行 → 6つのPRに分割）

Phase 4A-1: Stripe PaymentIntent作成（+300行）

• src/lib/services/payment.ts（createPaymentIntent）

検証: テストモードでPaymentIntent作成

Phase 4A-2: 購入サマリー（+300行）

• GET /api/purchase/summary
• /purchase ページ（サマリー表示）

検証: 価格、手数料、合計が正しく表示されること

Phase 4A-3: 購入確認（+350行）

• POST /api/purchase/confirm
• 購入確認UI

検証: 購入完了 → Order作成

Phase 4A-4: Webhook処理（+300行）

• POST /api/webhooks/stripe
• PaymentIntent成功/失敗処理

検証: Stripe CLIでWebhookテスト

Phase 4A-5: ウォレット/ポイント管理（+350行）

• src/lib/services/wallet.ts
• src/lib/services/point.ts

検証: 残高加算/減算テスト

Phase 4A-6: ダウンロードAPI（+250行）

• GET /api/orders/[id]/download
• S3署名付きURL生成

検証: 購入済み画像のダウンロード

---

Phase 4B: Wallet & Payout（現状: #24 +1357行 → 5つのPRに分割）

Phase 4B-1: ウォレット残高（+300行）

• GET /api/wallet/summary
• /mypage/wallet ページ

検証: 残高が正しく表示されること

Phase 4B-2: 取引履歴（+300行）

• GET /api/wallet/history
• /mypage/wallet/history ページ（日付グループ化）

検証: 取引履歴が正しく表示されること

Phase 4B-3: 銀行口座登録（+300行）

• GET/POST /api/wallet/payout-method
• /mypage/wallet/payout-method ページ

検証: 口座情報の登録/更新

Phase 4B-4: 銀行口座確認（+150行）

• /mypage/wallet/payout-method/confirm ページ

検証: 確認画面の表示

Phase 4B-5: 出金申請（+350行）

• POST /api/wallet/payout/applications
• /mypage/wallet/payout ページ

検証: 出金申請 → 残高減少

---

Phase 5A: Social Features（現状: #25 +1526行 → 6つのPRに分割）

Phase 5A-1: FollowService + API（+300行）

• src/lib/services/follow.ts
• POST/DELETE /api/follows

検証: フォロー/アンフォローが動作すること

Phase 5A-2: フォロー/フォロワー一覧（+300行）

• GET /api/followers、GET /api/follows/status
• /mypage/follow ページ

検証: 一覧が正しく表示されること

Phase 5A-3: NotificationService拡張（+250行）

• src/lib/services/notification.ts（FOLLOW、PURCHASE、PAYOUT_COMPLETED）

検証: 各種通知が作成されること

Phase 5A-4: 通知一覧（+300行）

• GET/PATCH /api/notifications
• /mypage/notifications ページ

検証: 通知一覧、既読処理

Phase 5A-5: 未読バッジ + AppHeader（+250行）

• GET /api/notifications/unread-count
• src/components/AppHeader.tsx（30秒ポーリング）

検証: 未読件数が正しく表示されること

Phase 5A-6: ユーザープロフィール（+350行）

• GET /api/users/[userId]/profile
• /users/[userId] ページ

検証: プロフィール表示、フォローボタン

---

Phase 5B: Admin Console（現状: #26 +2632行 → 6つのPRに分割）

Phase 5B-1: AdminAuditLog + マイグレーション（+200行）

• Prismaスキーマ追加
• マイグレーション

検証: マイグレーション成功

Phase 5B-2: 管理者認証（+400行）

• POST /api/admin/auth/login
• /admin/login ページ

検証: 管理者ログイン成功

Phase 5B-3: RBACミドルウェア（+300行）

• src/lib/admin-middleware.ts
• SUPER_ADMIN、REVIEWER、SUPPORT

検証: 各ロールでアクセス制限テスト

Phase 5B-4: アカウント管理（+400行）

• GET/PATCH /api/admin/accounts
• /admin/accounts ページ

検証: アカウント検索、停止/再開

Phase 5B-5: 出金申請管理（+350行）

• GET/PATCH /api/admin/payouts
• /admin/payouts ページ

検証: 出金申請の承認/却下

Phase 5B-6: 通報管理（+350行）

• GET/PATCH /api/admin/reports
• /admin/reports ページ

検証: 通報のステータス更新

---

Phase 5C: Admin Analytics（現状: #27 +1627行 → 5つのPRに分割）

Phase 5C-1: 売上統計API（+300行）

• GET /api/admin/sales

検証: 期間別売上データ取得

Phase 5C-2: ユーザー統計API（+250行）

• GET /api/admin/users/stats

検証: ユーザー統計データ取得

Phase 5C-3: 分析ダッシュボードUI（+400行）

• /admin/analytics ページ（Recharts）

検証: チャートが正しく表示されること

Phase 5C-4: CSVエクスポート（+300行）

• GET /api/admin/sales/export
• GET /api/admin/users/stats/export

検証: CSVダウンロード、Excel互換性

Phase 5C-5: 法的文書ページ（+250行）

• /legal/terms、/legal/privacy、/legal/commerce

検証: 各ページの表示

---

実行戦略まとめ

1. 参照パターンの確立

Phase 1-1（Prismaスキーマ）を人間/Cursorで作成し、これを全ての参照パターンの基盤とします。Devinには「このパターンに従って実装して」と指示します。

2. 検証サイクルの強化

各サブPhaseで以下を必須とします：

1. ビルド成功（npm run build）
2. 実際の動作確認（ブラウザ、curl、Prisma Studio）
3. 問題があれば修正してから次のサブPhaseへ

3. プロンプトテンプレート

# Devin Task Brief: [機能名] - [サブPhase番号]
 
## 0. Role & Goal
- Objective: [1文で具体的な成果物を記述]
 
## 1. Context
- **対象ファイル**: [作成/修正するファイルを1-3個に限定]
- **参照実装**: [参照すべき既存ファイルを明記]
- **仕様書**: [該当する仕様書のパス]
 
## 2. Task Breakdown
1. [具体的なアクション1]
2. [具体的なアクション2]
（最大3ステップ）
 
## 3. Constraints
- **変更禁止**: [変更してはいけないファイル/ディレクトリ]
- **パターン**: [従うべきコーディングパターン]
 
## 4. Validation
- Run: `[具体的なコマンド]`
- Expected: `[期待する出力]`
 
## 5. Deliverables
- [作成するファイル1]
- [作成するファイル2]

4. 人間の介入ポイント

5. 期待される効果

---

Devinの有用性

「ローカルでの検証と細かい調整がどうしても非効率になるので、CursorやClaudeでやった方が早い」——これは多くの開発者が感じる疑問です。スマートフォンからClaudeを使って開発できる時代に、Devinの有用性はどこにあるのでしょうか。

実際の記事・事例からの分析

1. Nubank（ブラジル最大のデジタル銀行）の事例

We Are Foundersの記事によると、Nubankは6百万行のETLコードのリファクタリングにDevinを活用しました。

従来の見積もり:

• 期間: 18ヶ月
• 必要人員: 1,000人以上のエンジニア
• 対象: 100,000以上のデータクラス実装

Devin活用後の結果:

• 20倍のコスト削減
• 8〜12倍のスピードアップ
• 数ヶ月かかる予定だったマイグレーションを数週間で完了
• エンジニアはレビューのみに集中

成功の鍵: タスクを「数千の小さなチャンク」に分割し、複数のDevinを並列で実行。1人のエンジニアが複数のDevinを監督する形式。

---

2. Builder.io（Steve Sewell）のレビュー

Builder.ioの記事では、$500/月を払ってDevinをテストした結果が報告されています。

Devinの強み:

• 計画→コーディング→テスト→PR作成まで一貫して実行
• 「知識エントリ」を保存し、後続のタスクで参照
• デプロイプレビューを自動生成

Devinの弱み:

• 「15分待ってPRを受け取り、Slack/PRでやり取りするワークフローは好みではない」
• 「AIがまだ十分に信頼できない段階では、非同期で放置するワークフローは最適ではない」
• 「Cursorでローカルで即座に確認する方が好み」

結論: 「Devinが十分に信頼できるようになるまでは、IDEで直接作業する方が効率的」

---

3. Answer.AI（Hamel Husain他）の1ヶ月テスト

Answer.AIの記事では、20以上のタスクをDevinでテストした結果が報告されています。

結果:

• 14件が失敗
• 3件が成功
• 3件が不明確

問題点:

• 「どのタスクが成功するか予測できるパターンがなかった」
• 「タスクが実際には不可能な場合でも、Devinは前に進み続けた」
• 「最もフラストレーションだったのは、失敗したタスクを救おうとして費やした時間」
• 「シンプルなタスクでも、Devinは過度に複雑なコードを生成した」

---

4. Tembo.ioの比較分析

Tembo.ioの記事では、実際のスプリントでの使用経験が報告されています。

Devinが有効な場面:

• 「リポジトリ全体のロギングパターンのリファクタリングで数時間を節約」
• 「GitHubチケットを受け取り、複数ファイルの変更を計画し、テストを実行し、PRを作成」

Devinが非効率な場面:

• 「1ファイルのバグ修正では、委員会の決定を待つようなもの」
• 「即座のフィードバックが必要なタスクには不向き」

Devinが有効な場面（具体的なシナリオ）

シナリオ1: 大規模マイグレーション

状況: 100個のファイルでAPIの呼び出し方法を変更する必要がある

Cursorの場合:

• 同じブランチで順番に作業
• または手動で100個のブランチを切り替え
• 1人の開発者が100回の作業を実行

Devinの場合:

• 100個のタスクを100個のDevinに依頼
• 各Devinが独立したブランチで作業
• 1人の開発者はレビューのみに集中

シナリオ2: チーム全体での活用

状況: PMやデザイナーが「この文言を変更して」と依頼したい

Cursorの場合:

• エンジニアに依頼 → エンジニアがCursorで作業 → PR作成
• エンジニアの工数が必要

Devinの場合:

• PMがSlackで「@Devin この文言を〇〇に変更して」と依頼
• Devinが自動でPR作成
• エンジニアはレビューのみ

シナリオ3: 夜間バッチ開発

状況: 10個の独立したバグ修正を週末に処理したい

Cursorの場合:

• 開発者がPCを開いて作業する必要がある
• または事前にスクリプトを組む必要がある

Devinの場合:

• 金曜日の夜に10個のタスクをSlackで依頼
• 週末は完全に放置
• 月曜日に10個のPRをレビュー

---

Devinが非効率な場面（Cursorの方が良い）

---

結論：Devinの有用性

Devinの真の価値は以下の3点に集約されます:

1. 異なるブランチでの並列実行 – Cursorでは同じブランチ上でしか並列実行できない
2. ネイティブなSlack/GitHub連携 – MCPの設定なしで即座に利用可能
3. 完全な自律性 – 依頼したら完全に放置可能

プロジェクトへの適用:

• ゼロイチ開発: Cursor/Claudeで参照パターンを確立
• Phase 2以降の反復的タスク: Devinに異なるブランチで並列依頼
• UI/UXの調整: Cursorで即座にフィードバック
• 大規模マイグレーション: Devinに100個のタスクを並列依頼、レビューのみに集中

最終的な使い分け:

---

Devin ベストプラクティス

プロジェクトの実績データ、Devin公式ドキュメント、そして外部の実践記事を統合し、Devin活用のベストプラクティスを整理しました。

1. Devinの位置づけ：「無限のエネルギーを持つジュニアエンジニア」

公式ドキュメント・外部記事の共通見解:

“Devin operates like a junior engineer who never gets tired, never pushes back, and never asks clarifying questions unless prompted.” — variantsystems.io

重要なポイント:

• Devinは実行力が強み、判断力は弱い
• 明確な指示を与えれば高速で実行できる
• 曖昧な指示を与えると「合理的に聞こえる推測」で埋める → 予期しない結果に

教訓:

• Phase 1-5のゼロイチ開発で「全部任せる」アプローチは失敗
• 後半の細かな修正（明確な仕様）は成功

---

2. タスクの選定基準：「Wide & Shallow」

公式ドキュメント（docs.devin.ai/use-cases/best-practices）:

理想的なタスクの条件:

1. 90分以内の手動作業に相当 — 大きすぎるタスクは分割
2. 検証可能 — テスト、CI、ビルドで成功/失敗が判定できる
3. 独立している — 他のタスクに依存しない
4. 反復的 — 同じパターンを複数回適用

具体例（成功したタスク）:

• ボタンコンポーネント統一（20ファイル以上を同じパターンで変更）
• カテゴリー/タグのUI変更（チェックボックスへの変更）
• ドキュメント作成（README、テスト計画書）
• インフラ構築（Terraform、Docker）

---

3. プロンプトの書き方：「What + How + Result」

公式ドキュメント（docs.devin.ai/learn-about-devin/prompting）:

## What（何をするか）
タスクの目的を明確に記述
 
## How（どうやるか）
Do's と Don'ts を明示
参照すべきファイル、パターン、ドキュメントを指定
 
## Result（結果の検証）
成功/失敗を判定するコマンド
期待される出力

良いプロンプトの例:

# タスク: ボタンコンポーネントの統一
 
## What
mypage配下の全ページで、MUIのButtonコンポーネントを
共通のSecondaryButtonコンポーネントに置き換える
 
## How
- 参照: `components/ui/SecondaryButton.tsx` を使用
- パターン: `<Button variant="outlined">` → `<SecondaryButton>`
- Don't: スタイルを変更しない、機能を変更しない
 
## Result
- `pnpm run build` が成功すること
- `pnpm run lint` がエラーなしで完了すること
- 変更前後で見た目が同じであること

悪いプロンプトの例:

• ❌ 「パフォーマンスを改善して」（具体的な指標がない）
• ❌ 「認証システムを作って」（範囲が広すぎる）
• ❌ 「うまく動くようにして」（検証方法がない）

---

4. チェックポイントとフィードバック

公式ドキュメント（devin.ai/agents101）:

“Much of the magic of agents comes from their ability to fix their own mistakes and iterate against error messages.”

ベストプラクティス:

プロンプトへの組み込み方:

## チェックポイント
1. 変更前に `git status` を報告
2. 各ファイル変更後に `pnpm run lint` を実行
3. 全変更後に `pnpm run build` を実行
4. ビルドが成功したらPRを作成
 
## ブロック時の対応
- 3回失敗したら一旦停止して報告
- 15分以上進捗がなければ報告

---

5. 並列実行の活用（Devinの独自価値）

Cursorとの違い:

並列実行の活用例:

# 10個の独立したタスクを並列で実行
 
タスク1: feature/button-refactor-mypage
タスク2: feature/button-refactor-admin
タスク3: feature/button-refactor-timeline
...
タスク10: feature/button-refactor-wallet
 
→ 1人の開発者が10個のDevinを監督
→ 各Devinが独立したブランチで作業
→ 開発者はレビューのみに集中

成功例:

• ボタンコンポーネント統一（20ファイル以上）
• 各ページを独立したタスクとして並列実行可能だった

---

6. Devin vs Cursor/Claude の使い分け

実績データに基づく分類:

---

7. 教訓

失敗パターン（Phase 1-5のゼロイチ開発）

成功パターン（後半の細かな修正）

---

8. 具体的なプロンプト例

良いプロンプト（リファクタリング）

# タスク: SecondaryButtonコンポーネントへの統一
 
## Role & Goal
あなたはリファクタリング担当のエンジニアです。
目的: mypage配下の全ページでボタンコンポーネントを統一する
 
## Context
- リポジトリ:
- 参照: `components/ui/SecondaryButton.tsx`
- 対象: `app/mypage/**/*.tsx`
 
## Task Breakdown
1. `app/mypage` 配下の全 `.tsx` ファイルを特定
2. 各ファイルで `<Button variant="outlined">` を `<SecondaryButton>` に置換
3. import文を追加: `import { SecondaryButton } from '@/components/ui/SecondaryButton'`
4. 不要になったMUI Buttonのimportを削除
 
## Constraints
- スタイルを変更しない
- 機能を変更しない
- 既存のテストが通ること
 
## Validation
- `pnpm run build` が成功すること
- `pnpm run lint` がエラーなしで完了すること
 
## Checkpoints
- 各ファイル変更後に `pnpm run lint` を実行
- 全変更後に `pnpm run build` を実行
- ビルドが成功したらPRを作成
 
## Deliverables
- ブランチ名: `feature/button-refactor-mypage`
- PRタイトル: `refactor: mypage配下のボタンをSecondaryButtonに統一`

悪いプロンプト（避けるべき例）

# ❌ 悪い例1: 範囲が広すぎる
「認証システムを作って」
 
# ❌ 悪い例2: 検証方法がない
「パフォーマンスを改善して」
 
# ❌ 悪い例3: 曖昧な指示
「うまく動くようにして」
 
# ❌ 悪い例4: 参照パターンがない
「新しいUIコンポーネントを作って」

---

9. まとめ：Devin活用の3原則

原則1: ジュニアエンジニアとして扱う

• 明確な指示を与える
• 判断を求めない
• チェックポイントを設定する

原則2: Wide & Shallow

• 大きなタスクは分割する
• 反復的なタスクを並列実行
• 各タスクは独立して検証可能

原則3: 適材適所

• Devin: 並列実行、リファクタリング、インフラ構築
• Cursor: UI/UX調整、デバッグ、トライ&エラー

---

参考資料

• Devin公式ドキュメント: Instructing Devin Effectively
• Devin公式ドキュメント: Best Practices
• Devin公式ブログ: Coding Agents 101
• Working with Devin AI: How to Stay in Control
• プロジェクト実績データ（356コミット分析）