メインコンテンツへスキップ
Devin に指示を出すときに最も重要なのは、できるだけ具体的に伝えることです。同僚に何かの実装を頼むときに詳細な仕様を書いて渡すのと同じように、Devin に対しても同じレベルの具体性で伝える必要があります。このガイドでは、Devin を効果的に使うために、指示やプロンプトをどのように構成すればよいかを説明します。コーディングエージェントを効果的に活用するための、より包括的な戦略については、Coding Agents 101 guide も参照してください。

​
効果的なプロンプトの書き方

効果的な指示を示すプロンプト例は次のとおりです。
Devin のリポジトリ内で、Devin が動作しているリモートマシンの RAM と CPU 使用状況を監視するツールを構築してください。そのために、次のタスクを実行してください。
  • devin.rs が起動したときに自動的に動き始めるバックグラウンドタスクを作成すること。
  • この Devin セッションで使用されている、フォークされたすべてのリモートマシンへの接続を確立し、それらの RAM と CPU の使用状況を監視すること。
  • 使用率が利用可能なリソースの 80% を超えた場合、それを通知する新しいタイプの Devin イベントを発行すること（Kafka の利用方法を確認すること）。
  • 他の処理をブロックしない、賢いアーキテクチャにすること。Devin のサブエージェント用コンテナ同士がどのように連携しているかを把握しておく必要がある。

​
なぜこれは効果的なのか

有用なコンテキストを提供

  • 詳細: Devin のリポジトリと、より広い目的（リソース使用状況のモニタリング）を明示します。
  • メリット: Devin がスコープとドメインを明確に把握できます。

手順を段階的に示す

  • 詳細: 「バックグラウンドタスクを作成する」「使用率 80% でイベントを発行する」などのタスクを指定します。
  • メリット: 作業を論理的なパートに分解できます。

明確な成功基準を定義

  • 詳細: 使用率 80% に達したときに特定のイベントを発行することを「成功」と定義します。
  • メリット: Devin が達成すべきゴールを正確に理解できます。

既存のパターンとコードを参照

  • 詳細: Kafka やコンテナ間の連携について言及します。
  • メリット: 既存のコードや設計アプローチの再利用を促進します。

​
ベストプラクティス: やるべきこと・やってはいけないこと

Do: 明確な指示を出す
  • 理由: Devin は、明確な進め方がない場合や、解釈の余地が多すぎる場合に行き詰まることがあります。
  • 方法:
    • Devin のために重要な意思決定や判断を行う。
    • 具体的な設計上の選択や実装戦略を提示する。
    • 明確なスコープ、境界、成功条件を定義する。
  • 例: “order_items テーブルの order_id と product_id 列に複合インデックスを追加して、orderService.js 内の getOrderDetails クエリを最適化してください。product の詳細を取得するため、既存の相関サブクエリを products テーブルへの JOIN に置き換えるようにクエリをリファクタリングしてください。”
Don’t: 判断をあいまいなまま残す
  • 理由: あいまいな指示は、実際のニーズに合致しない解決策を Devin が実装してしまう原因になります。
  • 方法:
    • Devin に対して、指針なしに重要な設計や実装の判断を丸投げするような記述は避けてください。そのような指示は予期しない結果につながる可能性があります。
  • 例: Don’t: “データベースのパフォーマンスを改善してください。”
やるべきこと: Devin が得意なタスクを選ぶ
  • 理由:
    • 成果を最大化する: Devin の能力に合ったタスクを割り当てることで、最小限の労力と ACU 使用量で最大の成果を得られます。
  • 方法:
    • このガイドを読む: When to use Devin
    • Devin が参照できるサンプル、モジュール、リソース、テンプレートを提供してください。
      • ドキュメントサイトへの直接リンクを共有し、API リクエストボディや Devin がまだ知らない可能性のある機能などの詳細を読めるようにします。
      • Devin に参照させて学習してほしい特定のファイル名を共有します。
    • MCP インテグレーション を接続し、Figma デザイン、データベース、モニタリングツールなどへ Devin がアクセスできるようにします。
    • 例: やるべきこと: “Refactor state management in the Header component to use React’s useReducer hook for better scalability and maintainability. Ensure that all existing functionality is preserved and add unit tests to cover the new state logic.”
    • 例: やるべきこと: “Use authTemplate.rs as a reference to maintain consistency in error handling.”
    • 例: やるべきこと: “Check out the official Sequelize docs at https://sequelize.org/docs/v6/getting-started/ for migration steps.”
やってはいけないこと: 複雑なタスクでコンテキストの提供を省略する
  • 理由: Devin は複雑な作業もこなせますが、コンテキストと明確な指示を与えたときに最良のパフォーマンスを発揮します。
  • 方法:
    • ドメイン知識を要するタスクでは、関連するドキュメント、サンプル、リファレンスを提供してください。
    • ビジュアルに関するタスクでは、Figma MCP 経由で Figma ファイルを提供し、参照デザインや詳細な仕様も渡してください — Devin はこれらをもとに構築できますが、美的要素をゼロから発明することはありません。
    • モバイルアプリについては、Devin にはスマートフォンエミュレータへのアクセスがないため、明確なテスト基準を提示してください。
  • 例: やってはいけないこと: “アプリの見た目をよくして” — 代わりに、具体的なデザイン仕様や Figma ファイルを提供してください。
  • 例: やってはいけないこと: “データベースのパフォーマンスを改善して” — 代わりに、どのクエリを最適化するか、どの指標を目標とするかを指定してください。
推奨: 明確で頻繁なチェックを行う
  • 理由: あなたからのフィードバックとテスト／チェック／リンタからのこまめなフィードバックによって、Devin が誤りを効果的に修正できるようになります。
  • 方法:
    • 正しさを確認するためにテスト（単体テスト／統合テスト）を活用する。
    • コード品質のために、ビルド検証、lint チェック、静的解析を常に実行できる状態にしておく。
    • Devin Review と Auto-Fix を有効化し、レビューコメントや CI 失敗に Devin が自動で対応できるようにします。これにより、あなたが逐一介入しなくても、PR がマージ可能な品質に達するまで自律的に反復されるクローズドループを構築できます。
  • 例: 推奨: “各イテレーションの後に npm test を実行する。”
  • 例: 推奨: “CircleCI 上のパイプラインが失敗していないことを確認する。”
  • 例: 推奨: “コミットをプッシュする前に ESLint/Prettier のチェックを通過させる。”
非推奨: フィードバックの提供をおろそかにする
  • 理由: フィードバックがなければ、Devin は自分の提示した解決策があなたの基準を満たしているかどうかを判断できません。
  • 方法:
    • 評価基準や評価方法を決めずにタスクを割り当てるのは避ける。
Do: 明確なチェックポイントとサブタスクを設定する
  • 理由: 複雑なタスクを小さなチェックポイントに分解すると、Devin が集中して取り組めるようになり、エラーを減らせます。
  • 方法:
    • タスクを検証可能なサブタスクに分割し、各サブタスクごとに 1 つの Devin セッションを開始します。
    • 各サブタスクの達成条件を定義し、必要に応じてサブタスク内にもチェックポイントを設定します。
    • Devin に、各チェックポイントまたはサブタスクを完了するたびに報告するよう依頼します。
例:
  • 例: Do: “データセットを扱う際は、少なくとも 500 行あり、カラム X, Y, Z を含んでいることを検証してください。”
  • 例: Do: “API を変更する際は、エンドポイントがステータス 200 を返し、必要なフィールドをすべて含んでいることを確認してください。”
  • 例: Do: “UI を更新する際は、コンポーネントがコンソールエラーなしでレンダリングされ、デザイン仕様と一致していることを確認してください。”
Don’t: 具体的なバリデーション要件を省略する
  • 理由: 明確な検証手順がないと、Devin はタスクを確信を持って完了できません。
  • 方法:
    • あいまいな成功基準は避けてください。
    • 検証手順を暗黙のままにしたり、未定義のままにしないでください。
  • 例: Don’t: “ちゃんと動くようにして。”
Devin には、シェル、IDE、ブラウザを備えたフル機能のデスクトップ環境があります。PR（プルリクエスト）を開く前に、自分の作業をテストするよう Devin に指示してください:
  • アプリを起動する: “Run npm run dev and verify the new page renders at /settings.”
  • ブラウザーでのテスト: “Open the browser, navigate to the login page, and confirm the OAuth flow completes successfully.”
  • 見た目の確認: “Take screenshots at desktop (1440px) and mobile (375px) widths and confirm the layout matches the design.”
  • 画面録画: “Record yourself testing the checkout flow end-to-end.”
こうすることで、あなたが PR を確認する前に、Devin 自身があなたと同じように変更内容の QA を実施できるようになります。
反復的な作業や複雑な作業には、Playbooks を作成し、改善を重ねながら活用することを推奨します。Playbooks を効果的に使う方法 も参照してください。Playbooks は、タスクの委任を効率化するための再利用可能かつ共有可能なプロンプトです。たとえば、Devin に継続的に発生する CI ビルドの失敗に対処させたい場合は、毎回 Devin が従うべき一般的な手順を含む Playbook を作成します。すべてのセッションにまたがって Devin に記憶させたい永続的なコンテキスト（コーディング規約、よくあるバグとその修正方法、デプロイのワークフロー、社内ツールの使い方など）には、Knowledge を使用してください。Knowledge アイテムは関連性があるときに自動で参照されるため、毎回同じ指示をプロンプトに書く必要はありません。Knowledge を特定のリポジトリにピン留めすることも、全体に適用することもできます。
Playbooks と Knowledge の使い分け: Playbooks は特定のタスクに紐づく手順書（ステップバイステップのプロセス）として使用します。Knowledge は、複数のセッションにまたがって広く適用される一般的なヒント、規約、コンテキストを保存するために使用します。