> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 良い指示と悪い指示

> うまく機能する指示とそうでない指示

<Note>[When to Use Devin](/ja/essential-guidelines/when-to-use-devin) と [Instructing Devin Effectively](/ja/essential-guidelines/instructing-devin-effectively) を読んで、他の重要なヒントも必ず確認してください。</Note>

<CardGroup cols={1}>
  <Card title="新しい API エンドポイントの追加" icon="server">
    **良いアプローチ**

    <Check>
      "`/users/stats` という新しいエンドポイントを作成し、ユーザー数と平均登録年齢を含む JSON オブジェクトを返してください。PostgreSQL の既存の users テーブルを使用してください。レスポンスの構造は、`statsController.js` の `/orders/stats` エンドポイントを参照してください。新しいエンドポイントが `StatsController.test.js` スイートでカバーされていることを確認してください。"
    </Check>

    **この指示がうまくいく理由:**

    * ルートと期待されるレスポンス形式が明確に指定されている
    * 既存コードをテンプレートとして参照している
    * データソース (users テーブル) が定義されている
    * テストカバレッジの要件が含まれている

    <br />

    ***

    <br />

    **悪いアプローチ**

    <Warning>
      "ユーザー統計のエンドポイントを追加してください。"
    </Warning>

    **この指示が失敗する理由:**

    * どの統計情報を含めるべきかが不明確
    * データソースについての言及がない
    * 既存パターンへの参照がない
    * テスト要件が欠けている
  </Card>

  <Card title="データ表示用のフロントエンド機能" icon="window">
    **良いアプローチ**

    <Check>
      "`UserProfileComponent` に、ユーザーのロール (admin、editor、viewer) の一覧を表示するドロップダウンを追加してください。スタイリングには `DropdownBase` を使用してください。ロールが選択されたら、既存の API を呼び出してユーザーロールを設定してください。選択内容によって DB 上のユーザーロールが更新されることを確認して検証してください。適切なテスト方法については、あなたのナレッジを参照してください。"
    </Check>

    **この指示がうまくいく理由:**

    * 特定のコンポーネント名が明示されている
    * 含めるべきロールが具体的に列挙されている
    * 既存のスタイリング用コンポーネントが参照されている
    * ユーザーの操作フローが定義されている
    * 検証手順が含まれている

    <br />

    ***

    <br />

    **悪いアプローチ**

    <Warning>
      "ユーザープロファイルページをもっとユーザーフレンドリーにしてください。ロールを変更できて、それが動作していると確認できる何かを追加してください。"
    </Warning>

    **この指示が失敗する理由:**

    * 「ユーザーフレンドリー」が主観的で曖昧
    * 具体的な UI コンポーネントが示されていない
    * ユーザーの操作フローが不明確
    * 検証基準が曖昧
  </Card>
</CardGroup>

<div id="more-examples">
  ## その他の例
</div>

<div id="good">
  ### 良い例
</div>

<CardGroup cols={1}>
  <Card title="ユニットテストの作成" icon="vial">
    <Check>
      "AuthService のメソッド `login` と `logout` に対して Jest テストを追加してください。これら 2 つの関数のテストカバレッジが少なくとも 80% になるようにしてください。`UserService.test.js` をサンプルとして参照してください。実装後、`npm test -- --coverage` を実行し、両方の関数でカバレッジレポートが 80% 超になっていることを確認してください。また、有効な認証情報と無効な認証情報の両方でテストが通ること、そして `logout` によってセッションデータが正しくクリアされることも確認してください。"
    </Check>

    **なぜ良いか?** 明確な成功指標 (80% のカバレッジ) 、Devin が参照できるガイド (`UserService.test.js`) 、および具体的な検証手順を含む明確に定義されたスコープがあるためです。
  </Card>

  <Card title="既存コードの移行やリファクタリング" icon="code-branch">
    <Check>
      "`logger.js` を JavaScript から TypeScript に移行してください。すでに `tsconfig.json` と検証用のテストスイート `LoggerTest.test.js` があります。エラーなくコンパイルできるようにし、既存の設定は変更しないでください！ 移行後は、1) `tsc` を実行して型エラーがないことを確認し、2) `npm test LoggerTest.test.js` でテストスイートを実行してすべてのテストが通ることを確認し、3) コードベース全体で既存の logger メソッド呼び出しがすべて、型エラーなしで動作し続けていることを確認してください。"
    </Check>

    **なぜ良いか?** 明確なテンプレート (`tsconfig.json`) と即時フィードバック用のテストスイートがあり、さらにコンパイルと検証の具体的な手順が示されているためです。
  </Card>

  <Card title="API やデータベースクエリの更新" icon="database">
    <Check>
      "pg から sequelize に切り替えています ([https://sequelize.org/api/v6/identifiers](https://sequelize.org/api/v6/identifiers) を読んでください) 。UserModel のクエリを、Sequelize のメソッドを使うように更新してください。このコードベースでの実装方法については `OrderModel` を参照してください。実装後は、1) `npm run test:integration UserModel.test.js` を実行してすべてのインテグレーションテストが通ることを確認し、2) ユーザー 1000 件分のテストデータセットで実行時間を確認し、クエリのパフォーマンスが低下していないことを確認し、3) `npm run test:e2e user-flows.test.js` を実行して、すべての CRUD 操作が引き続きデータ整合性を維持していることを検証してください。"
    </Check>

    **なぜ良いか?** Devin は既存のパターンを踏襲でき、明示的な参照 (`OrderModel.js`) があります。また、Devin が参照できるようドキュメントへのリンクを提供しており、具体的なパフォーマンスおよび機能検証手順と正確なテストコマンドも含まれているためです。
  </Card>

  <Card title="デザインからの機能実装" icon="paintbrush">
    <Check>
      "この Figma ファイル ([https://figma.com/file/abc123/Pricing-Page](https://figma.com/file/abc123/Pricing-Page)) を元に、料金ページを実装してください。「Pricing Section」フレームに注目してください。色と余白には、tailwind.config.ts にある Tailwind の設定を使用してください。`src/components/ui/` にある既存の Card コンポーネントと Button コンポーネントを再利用してください。実装後、開発サーバーを起動し、デスクトップ (1440px) とモバイル (375px) の幅でスクリーンショットを撮ってください。デザインと一致するまでは PR を作成しないでください。"
    </Check>

    **なぜ良いか?** 特定の Figma ファイルへのリンクを指定し、対象となるフレーム名を明示し、プロジェクトのデザインシステムと既存コンポーネントを参照しています。また、PR を作成する前に Devin にデザインと視覚的に一致しているか検証するよう指示しています。[Figma MCP](/ja/work-with-devin/mcp) が接続されていれば、Devin はファイルからデザイントークンを直接読み取ることができます。
  </Card>

  <Card title="本番環境のバグ調査" icon="bug">
    <Check>
      "ユーザーから、チェックアウトページで 500 エラーが発生しているという報告があります。Sentry MCP を使って、payments-api プロジェクトの最新のスタックトレースを取得してください。データベースを確認し、関連するデータの問題がないかチェックしてください。根本原因を特定して修正し、リグレッションテストを追加してください。PR の説明に Sentry の Issue へのリンクを追加してください。"
    </Check>

    **なぜ良いか?** Devin に適切なツール ([MCP 連携](/ja/work-with-devin/mcp)) を指示し、明確な調査プロセスを示し、期待される成果物 (修正 + リグレッションテスト + PR) を定義しているためです。
  </Card>
</CardGroup>

<div id="bad">
  ### 悪い例
</div>

<CardGroup cols={1}>
  <Card title="オープンエンドなコードレビュー" icon="magnifying-glass">
    <Warning>
      「私たちのコードベースの問題を見つけて修正して」
    </Warning>

    **なぜ悪い？** リクエストがあいまいでオープンエンドすぎます。成功基準がなく、Devin が完了を判断する方法もありません。

    **代わりに:** 特定の PR に対する自動コードレビューには [Devin Review](/ja/work-with-devin/devin-review) を使うか、「`src/services/` 内で非推奨になった `oldLogger` API のすべての使用箇所を見つけて修正して」のように、Devin に明確で対象を絞ったタスクを与えてください。
  </Card>

  <Card title="主観的すぎるビジュアル上の依頼" icon="palette">
    <Warning>
      「ランディングページをもっと良く見えるようにして」
    </Warning>

    **なぜ悪い？** 「良く」は主観的な表現であり、Devin が目指すべき基準がありません。Devin は仕様から機能的な UI を構築したりデザインを実装したりできますが、美的な判断を自律的に行うことはできません。

    **代わりに:** Figma のデザイン、参考サイト、あるいは次のような具体的な変更内容を提示してください: 「ヒーローセクションのフォントサイズを 48px に上げて、32px のパディングを追加し、Tailwind の設定にある `indigo-500` カラーを使ってください。」
  </Card>

  <Card title="極めて複雑であいまいなプロジェクト" icon="sitemap">
    <Warning>
      「自社アプリ用に新しいマイクロサービスアーキテクチャを構築して。」
    </Warning>

    **なぜ悪い？** 非常に大きく構造化されていないタスクで、多数のアーキテクチャ上の判断やトレードオフ、そしてプロンプトには含まれていない多くのコンテキストが必要になります。

    **代わりに、小さく分割して進める:**

    1. [Ask Devin](/ja/work-with-devin/ask-devin) を使ってコードベースを調査し、依存関係をマッピングする
    2. Devin にトレードオフも含めた具体的なアーキテクチャ案を提案させる
    3. 各サービスの実装用に個別のセッションを作成し、[managed Devins](/ja/work-with-devin/advanced-capabilities#managed-devins) を使って並行実行する
  </Card>
</CardGroup>