メインコンテンツへスキップ
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 やコンテナ間の連携について言及します。
  • メリット: 既存のコードや設計アプローチの再利用を促進します。
セッションを作成するときに「Prompt Improvement」ボタンを試してみてください（黄色の警告アイコンをクリックするとフィードバックが表示されます）
Prompt Improvement Button

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

Do: 明確な指示を出す
  • 理由: Devin は、明確な進め方がない場合や、解釈の余地が多すぎる場合に行き詰まることがあります。
  • 方法:
    • Devin のために重要な意思決定や判断を行う。
    • 具体的な設計上の選択や実装戦略を提示する。
    • 明確なスコープ、境界、成功条件を定義する。
  • 例: “order_items テーブルの order_id と product_id 列に複合インデックスを追加して、orderService.js 内の getOrderDetails クエリを最適化してください。product の詳細を取得するため、既存の相関サブクエリを products テーブルへの JOIN に置き換えるようにクエリをリファクタリングしてください。”
Don’t: 判断をあいまいなまま残す
  • 理由: あいまいな指示は、実際のニーズに合致しない解決策を Devin が実装してしまう原因になります。
  • 方法:
    • Devin に対して、指針なしに重要な設計や実装の判断を丸投げするような記述は避けてください。そのような指示は予期しない結果につながる可能性があります。
  • 例: Don’t: “データベースのパフォーマンスを改善してください。”
やるべきこと: Devin が得意なタスクを選ぶ
  • 理由:
    • 成果を最大化する: Devin の能力に合ったタスクを割り当てることで、最小限の労力と ACU 使用量で最大の成果を得られます。Devin の現在の能力から大きく外れたタスクを依頼すると、しばしば望ましくない結果につながります。
  • 方法:
    • このガイドを読む: When to use Devin
    • とくに高度なタスクでは、Devin が参照できるサンプル、モジュール、リソース、テンプレートを提供してください。
      • ドキュメントサイトへの直接リンクを共有し、API リクエストボディや Devin がまだ知らない可能性のある機能などの詳細を読めるようにします。
      • 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 の中核的な得意分野の範囲外のタスクを割り当てる
  • 理由: 高度なドメイン知識や大きな設計上の判断を必要とするタスクを、十分なガイダンスなしに割り当てると、非効率や ACU の無駄遣いにつながります。
  • 方法:
    • 明確な指示や参照なしに、大きなクリエイティブ要素や高度な戦略的判断を求めるタスクは避けてください。
    • 強い視覚的能力を必要とするタスク、たとえば Figma デザインの実装は避けてください。Devin はウェブページを見ることはできますが、完全な視覚能力を持っているわけではありません。
    • Devin はスマートフォンにアクセスできず、自分の作業を簡単にテストできないため、モバイルアプリの作成を依頼するのは避けてください。
  • 例: やってはいけないこと: “Create a new authentication system for my website from scratch.”
  • 例: やってはいけないこと: “Turn this Figma mockup into a React component.”
  • 例: やってはいけないこと: “Build an AI-powered shopping app.”
Do: 部分的なタスクを分担して協業する
  • 理由: タスクの最後の20%は、あなたが仕上げたほうが速い場合があります。
  • 方法:
    • 実装の大部分は Devin に任せ、そのあとであなたが仕上げる。
    • 繰り返しが多いワークフローの部分を Devin に任せ、あなたはより重要な部分に集中する。
  • 例: Do: 「新しい API エンドポイント用の初期のひな型コードを生成して、その後それを既存の認証システムと私が統合します。」
Don’t: 複雑なプロジェクト全体を Devin のみに依存する
  • 理由: 微妙な判断や創造的な問題解決を要するタスクを Devin に過度に依存すると、遅延や最適でない結果を招く可能性があります。
  • 方法:
    • 効果的に完了させるために多くの人間の介入が必要だと分かっているタスクを、Devin に丸ごと割り当てるのは避けてください。
  • 例: Don’t: 「新しい生成 AI 機能向けのバックエンド基盤全体を開発して。」
推奨: 明確で頻繁なチェックを行う
  • 理由: あなたからのフィードバックとテスト／チェック／リンタからのこまめなフィードバックによって、Devin が誤りを効果的に修正できるようになります。
  • 方法:
    • 正しさを確認するためにテスト（単体テスト／統合テスト）を活用する。
    • コード品質のために、ビルド検証、lint チェック、静的解析を常に実行できる状態にしておく。
  • 例: 推奨: “各イテレーションの後に 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: “ちゃんと動くようにして。”
反復的な作業や複雑な作業には、Playbooks を作成し、改善を重ねながら活用することを推奨します。Playbooks を効果的に使う方法 も参照してください。Playbooks は、タスクの委任を効率化するための再利用可能かつ共有可能なプロンプトです。たとえば、Devin に継続的に発生する CI ビルドの失敗に対処させたい場合は、毎回 Devin が従うべき一般的な手順を含む Playbook を作成します。

​
結論

タスクには十分な枠組みと明確さを持たせて、信頼できて納得感のある結果が得られるようにしましょう。