自律型AIエンジニア「Devin」テンプレート集

作成日: 2025年5月9日

📋 Devinとは？

Devinは、Cognition社が開発した完全自律型のAIソフトウェアエンジニアです。単なるコード生成AIではなく、プロジェクトの計画から実装、テスト、デプロイまでを自律的に実行できます。GitHubやSlackと連携して、人間のエンジニアと同じようにプルリクエストを作成したり、質問に応答したりすることが可能です。

2025年4月のバージョン2.0リリースにより、従来の月額500ドルから最低20ドルから利用できるようになり、より手軽に導入できるようになりました。

主な特徴

  • 自律的なコーディング能力（計画立案からコード生成、テスト実行まで）
  • リアルタイムのエラー修正機能
  • GitHub/Slackとの連携によるチーム開発サポート
  • Knowledgeシステムによる組織固有の知識の蓄積と活用
  • マルチプロジェクト対応とコンテキスト理解能力
Devinのイメージ画像
Devin - 自律型AIソフトウェアエンジニア（出典：Cognition）

💰 料金プラン比較

プラン 料金 特徴 向いている用途
Coreプラン 最低20ドル〜（従量課金）
  • 基本的なAIエンジニア機能
  • 最大10セッション同時利用可能
  • チャットベースのインターフェース
  • API・Slack連携なし
 個人開発者、お試し利用、学習目的
Teamプラン 月額500ドル（250ACU含む）
  • Coreプランの全機能
  • Slack/GitHub連携機能
  • API連携
  • IDE拡張機能
  • 優先サポート
 開発チーム、企業利用、継続的な開発プロジェクト
Enterpriseプラン 要問合せ（カスタム料金）
  • Teamプランの全機能
  • Enterprise版Devin
  • カスタムDevin
  • VPC内デプロイ
  • 専任アカウントチーム
  • カスタム契約条件
 大規模企業、セキュリティ要件の厳しい環境

ACU（Agent Compute Unit）について：

1ACUは約15分の作業時間に相当します。Teamプランの250ACUは約62.5時間の作業が可能で、時給換算で約1,200円となります。追加のACUは1つあたり2ドルで購入できます。

🔧 テンプレート集

以下のテンプレートを使って、Devinに効率的に作業を依頼しましょう。各カテゴリごとに、Devinの得意分野に合わせたテンプレートを用意しています。

🐛 バグ修正

発生しているバグの詳細と修正方針を指示するテンプレート

@Devin リポジトリ [リポジトリ名] で発生しているバグを修正してください。 【バグの詳細】 - 問題が発生しているファイル: [ファイルパス] - 現象: [バグの現象] - 再現手順: [再現方法] - 期待される動作: [本来の正しい動作] 【修正方針】 - [可能であれば修正の方向性を記載] - テスト方法: [テストコマンドやテスト手順] 修正が完了したら、以下の形式でPRを作成してください: - ブランチ名: fix/[簡潔な問題の説明] - PRタイトル: 「fix: [簡潔なバグ修正の説明]」 - PR説明文には問題と解決策の概要を日本語で記載してください テストが成功することを確認してからPRを作成してください。
自律度: 高 ACU目安: 1-3

✨ 機能追加

新機能の実装を依頼するテンプレート

@Devin リポジトリ [リポジトリ名] に新機能を追加してください。 【機能の概要】 - 追加する機能: [機能の説明] - 関連するファイル: [ファイルパスや関連コンポーネント] - 実装の要件: 1. [要件1] 2. [要件2] 3. [要件3] 【実装の参考】 - 類似機能: [類似した既存機能へのパス] - APIの仕様: [必要に応じてAPI仕様] - デザイン仕様: [UIに関する要件があれば] 【動作確認方法】 - [テスト方法やテストコマンド] - [期待される動作の説明] 実装が完了したら、以下の形式でPRを作成してください: - ブランチ名: feature/[機能名] - PRタイトル: 「feat: [機能の簡潔な説明]」 - PR説明文には機能概要と実装アプローチを日本語で記載してください テストが成功することを確認してからPRを作成してください。
自律度: 中〜高 ACU目安: 3-8

🧪 テスト作成

既存コードのテストを作成するテンプレート

@Devin リポジトリ [リポジトリ名] にテストを追加してください。 【テスト対象】 - 対象ファイル: [ファイルパス] - テスト種類: [単体テスト/統合テスト/E2Eテスト] - テストフレームワーク: [Jest/Mocha/その他] 【テスト要件】 - カバーすべき機能: 1. [機能1] 2. [機能2] 3. [エッジケース1] 4. [エラーケース1] 【参考となるテスト】 - [類似コンポーネントのテストファイルパス] 【テスト実行方法】 - [テスト実行コマンド] 以下のベストプラクティスに従ってください: - モックの使用方法: [モックに関する指示] - テストの命名規則: [プロジェクトのテスト命名規則] - カバレッジ目標: [カバレッジの目標値] テストが完了したら、以下の形式でPRを作成してください: - ブランチ名: test/[対象コンポーネント名] - PRタイトル: 「test: [テスト対象の説明]」 - PR説明文にはテスト内容と特に注意したポイントを日本語で記載してください
自律度: 高 ACU目安: 2-5

♻️ リファクタリング

コードのリファクタリングを依頼するテンプレート

@Devin リポジトリ [リポジトリ名] のコードリファクタリングをお願いします。 【リファクタリング対象】 - 対象ファイル: [ファイルパス] - 問題点: [現状のコードの問題点] - リファクタリングの目的: [パフォーマンス改善/可読性向上/保守性向上] 【リファクタリング要件】 - [具体的な改善ポイント1] - [具体的な改善ポイント2] - [具体的な改善ポイント3] 【制約条件】 - 機能的な変更を加えないこと - パフォーマンスを低下させないこと - 既存のテストがすべて通ること 【リファクタリングアプローチ】 - [望ましいアプローチがあれば記載] - [参考にすべきプロジェクト内の実装があれば記載] リファクタリングが完了したら、以下の形式でPRを作成してください: - ブランチ名: refactor/[対象コンポーネント名] - PRタイトル: 「refactor: [リファクタリング内容の説明]」 - PR説明文には変更内容と改善されたポイントを日本語で記載してください テストが成功することを確認してからPRを作成してください。
自律度: 高 ACU目安: 3-10

📝 ドキュメント生成

コードのドキュメントを作成するテンプレート

@Devin リポジトリ [リポジトリ名] のドキュメントを作成してください。 【ドキュメント対象】 - 対象: [ファイル/モジュール/API/機能] - ドキュメントの種類: [README/API仕様書/開発者向けガイド] - 言語: [日本語/英語] 【ドキュメントの要件】 - 含めるべき項目: 1. [概要] 2. [インストール方法/使用方法] 3. [設定オプション] 4. [APIリファレンス] 5. [トラブルシューティング] 【参考情報】 - [参考にすべき既存ドキュメント] - [社内の命名規則や記述スタイル] 【フォーマット要件】 - Markdownフォーマットで作成 - コード例を含める - 図表が必要であれば説明付きで提案してください ドキュメントが完了したら、以下の形式でPRを作成してください: - ブランチ名: docs/[ドキュメント名] - PRタイトル: 「docs: [ドキュメントの説明]」 - PR説明文にはドキュメントの概要と特記事項を日本語で記載してください
自律度: 高 ACU目安: 2-5

📄 文言修正

アプリケーション内の文言を修正するテンプレート

@Devin リポジトリ [リポジトリ名] の文言修正をお願いします。 【修正内容】 - 修正対象: [ファイルパス、または対象画面/機能] - 現在の文言: [現在の文言] - 修正後の文言: [修正後の文言] 【追加の修正が必要な場合】 - [同様のパターンがある場合は一括修正してください] - [翻訳ファイルも修正が必要か確認してください] 【注意点】 - HTMLやCSSのレイアウトを壊さないように注意してください - 翻訳キーの変更が必要な場合は、関連する全ファイルを修正してください 文言修正が完了したら、以下の形式でPRを作成してください: - ブランチ名: fix/text-update - PRタイトル: 「fix: 文言修正 [簡潔な説明]」 - PR説明文には変更した文言の一覧と修正理由を日本語で記載してください
自律度: 高 ACU目安: 1-2

🔌 APIエンドポイント実装

新しいAPIエンドポイントを実装するテンプレート

@Devin リポジトリ [リポジトリ名] に新しいAPIエンドポイントを実装してください。 【エンドポイント仕様】 - HTTPメソッド: [GET/POST/PUT/DELETE] - パス: [/api/v1/resource] - 認証要件: [必要/不要] - 入力パラメータ: - [パラメータ名1]: [型] - [説明] - [パラメータ名2]: [型] - [説明] - レスポンス形式: ```json { "status": "success", "data": { // 期待されるデータ構造 } } ``` - エラーレスポンス: ```json { "status": "error", "error": { "code": "ERROR_CODE", "message": "エラーメッセージ" } } ``` 【実装要件】 - [関連するモデル/サービス] - [必要なバリデーション] - [エラーハンドリング] - [パフォーマンス要件] 【テスト要件】 - 正常系テスト - 異常系テスト（バリデーションエラー、認証エラーなど） - パフォーマンステスト（必要に応じて） 実装が完了したら、以下の形式でPRを作成してください: - ブランチ名: feature/api-[リソース名] - PRタイトル: 「feat: API [エンドポイントの説明] の実装」 - PR説明文にはAPIの仕様と使用例のサンプルを日本語で記載してください テストが成功することを確認してからPRを作成してください。
自律度: 中〜高 ACU目安: 3-8

⚡ パフォーマンス最適化

コードのパフォーマンスを改善するテンプレート

@Devin リポジトリ [リポジトリ名] のパフォーマンス最適化をお願いします。 【対象箇所】 - 対象ファイル/機能: [ファイルパス/機能名] - 現状の問題: [レスポンス遅延/メモリ使用量過多/CPU使用率高] - 測定されたパフォーマンス: [具体的な測定値] - 目標とするパフォーマンス: [目標値] 【最適化方針】 - [重点的に取り組むべき点] - [既知の問題点があれば] - [考慮すべき制約条件] 【検証方法】 - [パフォーマンス測定方法] - [使用するツール/コマンド] - [ベンチマークの基準] 以下の観点で最適化を検討してください: - アルゴリズムの改善 - 不要な処理の削減 - キャッシュの活用 - 非同期処理の適用 - データ構造の最適化 最適化が完了したら、以下の形式でPRを作成してください: - ブランチ名: perf/[対象コンポーネント名] - PRタイトル: 「perf: [最適化内容の説明]」 - PR説明文には改善前後のパフォーマンス比較と実装アプローチを日本語で記載してください 実装した最適化がテストに成功し、パフォーマンスが改善されていることを確認してからPRを作成してください。
自律度: 中 ACU目安: 5-15

🛠️ 環境構築自動化

開発環境の構築を自動化するテンプレート

@Devin リポジトリ [リポジトリ名] の環境構築を自動化するスクリプトを作成してください。 【要件】 - 対象OS: [Windows/macOS/Linux] - 自動化する項目: 1. 依存パッケージのインストール 2. 環境変数の設定 3. データベースのセットアップ 4. 開発サーバーの起動 5. テストの実行確認 【制約条件】 - [使用可能なツール/言語] - [必要な権限レベル] - [互換性を保つべきバージョン] 【成功基準】 - 新規環境で一度のコマンド実行で環境構築が完了すること - エラーが発生した場合は適切なメッセージを表示すること - 冪等性を保ち、複数回実行しても問題が発生しないこと 【想定するユーザー】 - [初心者向け/開発者向け] - [想定される技術レベル] 環境構築スクリプトが完了したら、以下の形式でPRを作成してください: - ブランチ名: chore/setup-automation - PRタイトル: 「chore: 環境構築の自動化」 - PR説明文にはスクリプトの使用方法と注意点を日本語で記載してください スクリプトが正しく動作することを確認してからPRを作成してください。
自律度: 中 ACU目安: 3-8

🔍 コードベース調査

既存コードベースの調査を依頼するテンプレート

@Devin リポジトリ [リポジトリ名] のコードベース調査をお願いします。 【調査目的】 - [特定の機能の仕組みを理解したい] - [技術的負債を発見したい] - [依存関係を把握したい] 【調査対象】 - [モジュール/機能/ディレクトリ] - 特に注目すべき点: [パフォーマンス/セキュリティ/保守性] 【調査項目】 1. アーキテクチャ概要 2. 主要コンポーネントとその責務 3. データフローの把握 4. 潜在的な問題点や改善点 5. コードの重複や複雑度の高い箇所 【成果物】 - 調査結果のサマリーを日本語でまとめてください - アーキテクチャ図やフロー図があるとベターです - 技術的負債がある場合は、改善提案も含めてください 調査が完了したら、結果をMarkdown形式でレポートとして作成し、以下の形式でPRを作成してください: - ブランチ名: docs/codebase-analysis - PRタイトル: 「docs: [対象]のコードベース分析」 - PR説明文には主な発見事項を簡潔に日本語で記載してください
自律度: 中 ACU目安: 3-10

🗑️ 機能廃止

不要になった機能を安全に廃止するテンプレート

@Devin リポジトリ [リポジトリ名] の機能廃止作業をお願いします。 【廃止対象】 - 機能名: [機能名] - 関連ファイル: [ファイルパスのリスト] - 廃止理由: [代替機能への移行/不要になった/セキュリティ上の問題] 【廃止要件】 - 関連するUIコンポーネントの削除 - バックエンドAPIの削除 - データベースマイグレーション（必要に応じて） - 関連するテストコードの削除または修正 【注意事項】 - 他の機能への影響がないことを確認してください - 廃止に伴い必要な移行処理があれば実装してください - 設定ファイルやドキュメントも更新してください 【検証方法】 - [テスト方法] - [動作確認のポイント] 機能廃止が完了したら、以下の形式でPRを作成してください: - ブランチ名: refactor/remove-[機能名] - PRタイトル: 「refactor: [機能名]の廃止」 - PR説明文には廃止した機能の概要と影響範囲、テスト結果を日本語で記載してください テストが成功することを確認してからPRを作成してください。
自律度: 高 ACU目安: 3-8

🖼️ 新規画面作成

新しい画面の基本構造を作成するテンプレート

@Devin リポジトリ [リポジトリ名] に新しい画面を作成してください。 【画面概要】 - 画面名: [画面名] - 目的: [画面の目的] - 配置場所: [アプリケーション内の位置] 【画面要素】 - コンポーネント: 1. [ヘッダー] 2. [フォーム] 3. [一覧表示] 4. [詳細表示] - データ連携: - 表示データ: [データソース/API] - 更新方法: [POST/PUT APIなど] 【参考】 - 類似画面: [既存の類似画面へのパス] - デザイン要件: [UIフレームワーク/スタイルガイド] - コンポーネント構成: [Atomic Design/その他設計手法] 【コーディング規約】 - [プロジェクト固有のコーディング規約] - [ファイル命名規則] - [ディレクトリ構成] 新規画面の作成が完了したら、以下の形式でPRを作成してください: - ブランチ名: feature/screen-[画面名] - PRタイトル: 「feat: [画面名]画面の実装」 - PR説明文には画面の概要と実装アプローチを日本語で記載してください テストが成功することを確認してからPRを作成してください。 また、スクリーンショットがあると確認しやすいので、できればPR説明文に含めてください。
自律度: 中 ACU目安: 5-15

📦 依存関係更新

プロジェクトの依存パッケージを更新するテンプレート

@Devin リポジトリ [リポジトリ名] の依存関係を更新してください。 【更新対象】 - [特定のパッケージ名と更新するバージョン] - [または、すべての依存関係を最新に更新] 【更新の優先度】 - セキュリティ修正が含まれているパッケージを優先 - 破壊的変更がないメジャーバージョンの更新は慎重に - 非推奨警告の解消 【注意事項】 - 破壊的変更がある場合は、それに対応するコード修正も行ってください - 変更ログを確認し、重要な変更点を報告してください - テストが通らない場合は、原因を特定して修正してください 【検証方法】 - 全テストが通ることを確認 - アプリケーションが正常に起動し、主要機能が動作することを確認 - パフォーマンスの低下がないことを確認 依存関係の更新が完了したら、以下の形式でPRを作成してください: - ブランチ名: chore/update-dependencies - PRタイトル: 「chore: 依存パッケージの更新」 - PR説明文には更新したパッケージのリストと重要な変更点、破壊的変更への対応を日本語で記載してください テストが成功することを確認してからPRを作成してください。
自律度: 高 ACU目安: 2-8

🔄 コードマイグレーション

コードを新しい技術スタックに移行するテンプレート

@Devin リポジトリ [リポジトリ名] のコードマイグレーションをお願いします。 【マイグレーション内容】 - 移行元: [言語/フレームワーク/ライブラリ] - 移行先: [言語/フレームワーク/ライブラリ] - 対象範囲: [ファイル/モジュール/コンポーネント] 【マイグレーション要件】 - 機能的に同等であること - パフォーマンスが低下しないこと - 新技術の特性を活かした実装にすること - 既存のテストを新実装でも動作するよう修正 【マイグレーション戦略】 - 一括移行 or 段階的移行 - 共存期間の考慮 - 後方互換性の維持方法 【参考資料】 - 移行ガイド: [公式ドキュメントなど] - 移行ツール: [利用可能なツール] - 既存の移行例: [社内の類似プロジェクト] マイグレーションが完了したら、以下の形式でPRを作成してください: - ブランチ名: refactor/migrate-to-[新技術] - PRタイトル: 「refactor: [旧技術]から[新技術]への移行」 - PR説明文には移行内容の概要と主な変更点、マイグレーション過程で解決した課題を日本語で記載してください テストが成功することを確認してからPRを作成してください。
自律度: 低〜中 ACU目安: 10-30

💡 効果的な利用ポイント

Devinを最大限に活用するコツ

  1. タスクを適切に分割する：大きすぎるタスクは分割し、明確な指示を出しましょう。Devinは「ジュニアレベル」の作業を得意としています。
  2. 具体的な要件を提示する：曖昧な指示ではなく、具体的な要件や期待する結果を明確に伝えましょう。
  3. 参考例を提示する：Few-shotプロンプティング（類似例を示す）を活用して、Devinの理解を助けましょう。
  4. Knowledgeを活用する：組織固有のルールや開発手法をKnowledgeとして蓄積し、Devinに学習させましょう。
  5. 段階的に確認する：複雑なタスクでは、中間段階で進捗を確認し、方向性を調整しましょう。
  6. Playbook機能を活用する：繰り返し行う作業はPlaybookとして登録し、効率化しましょう。

⚠️ 注意点と制限事項

  • UIデザイン系のタスクが苦手：視覚的なUIの調整やデザイン要素の実装は苦手としています。
  • 大量のファイル修正に時間がかかる：数十〜数百ファイルの修正は時間と費用がかかる場合があります。
  • 要件が曖昧なタスクは苦手：明確な指示がないと、想定外の実装になる可能性があります。
  • ACU消費と費用管理：セッションが長くなるほどACU消費が増えるため、費用管理に注意しましょう。
  • Slackでは「SLEEP」コマンドで停止：応答待ちの状態でも課金されるため、作業完了後は明示的に停止しましょう。