> ## Documentation Index > Fetch the complete documentation index at: https://factory-docs-auto-sync-jp-docs.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Droidとの対話方法 > FactoryのAIエージェントから高品質な結果を得るためのプロンプト作成テクニック。 Droidは明確で具体的な指示で最高のパフォーマンスを発揮します。熟練したエンジニアとペアプログラミングを行うように、コミュニケーションの質が結果に直接影響します。このガイドでは、より少ない反復でより良い結果を得るための実践的なパターンを紹介します。 ## 基本原則 **求めることを明確に示す。**「認証システムを改善できますか？」ではなく、「middleware/rateLimit.tsのパターンに従って、指数バックオフを用いたログイン試行のレート制限を追加してください」と試してみてください。Droidは目標を明確に述べられた時に最高のパフォーマンスを発揮します。 \*\*最初にコンテキストを提供する。\*\*エラーメッセージ、ファイルパス、スクリーンショット、または関連ドキュメントを含めてください。Jiraチケットやデザインドキュメントから何かを実装している場合は、リンクを貼り付けてください。droidはFactoryのダッシュボードで統合したプラットフォームから自動的にコンテキストを読み取ることができます。 \*\*アプローチを選択する。\*\*複雑な機能については、自動プランニングのためのSpecification Modeの使用を検討してください。日常的なタスクについては、droidは直接進めることができますが、それでもレビューのためにすべての変更を表示します。詳細なガイダンスについては[Planning versus doing](#planning-versus-doing)セクションを参照してください。 \*\*成功を定義する。\*\*特定のテストを実行する、サービスがクリーンに開始することを確認する、またはUIがモックアップと一致することを確認するなど、作業が完了したことを確認する方法をdroidに伝えてください。 ## 効果的なプロンプトの書き方 最高のプロンプトは直接的で関連する詳細を含んでいます： ``` Add comprehensive error handling to the payment processor in src/payments/processor.ts. Catch gateway timeouts and retry up to 3 times with exponential backoff. Similar retry logic exists in src/notifications/sender.ts. Run the payment integration tests to verify it works. ``` ``` Run the build and fix all TypeScript errors. Focus on the auth module first. ``` ``` Review my uncommitted changes with git diff and suggest improvements before I commit. ``` ``` The login form allows empty submissions. Add client-side validation and return proper error messages. Check that localhost:3000/login shows validation errors when fields are empty. ``` ``` Refactor the database connection logic into a separate module but don't change any query interfaces. ``` これらの例に注目してください： * 最初の文で目標を明確に述べる * 既知の場合は特定のファイルやコマンドを含める * 役立つ可能性のある関連コードについて言及する * 結果をテストする方法を説明する * 会話的だが直接的に保つ ## プランニング対実行 複雑な機能については、実装前に自動的にプランニングとレビューを提供する[Specification Mode](/jp/cli/user-guides/specification-mode)を使用してください： ``` Add user preferences API with key-value storage following REST conventions. Include validation and comprehensive tests. ``` 簡単なタスクについては、droidは承認のために変更を表示しながら直接進めることができます： ``` Fix the failing test in tests/auth.test.ts line 42 ``` ``` Add logging to the startup sequence with appropriate log levels. ``` ## コンテキストの管理 **AGENTS.mdファイルを使用して**ビルドコマンド、テスト手順、コーディング標準を文書化してください。Droidはこれらを自動的に読み取るため、プロジェクトの規約を繰り返す必要がありません。詳細なセットアップ手順については[AGENTS.md guide](/jp/cli/configuration/agents-md)を参照してください。 **特定のファイルを言及する**コードがどこにあるか分かっている場合。ファイルを直接参照するために`@filename`を使用するか、プロンプトにファイルパスを含めてください。これによりdroidの注意を集中させ、時間を節約できます。 **変更の境界を設定する。**「authディレクトリ内のファイルのみを変更する」または「パブリックAPIを変更しない」といった指示は、スコープを制限するのに役立ちます。 **外部リソースを参照する**チケット、ドキュメント、デザイン、または仕様へのURLを含めることで。Droidはこの情報を取得して使用できます。 ## 一般的なワークフロー **コードの理解：** ``` Explain how user authentication flows through this system. ``` ``` What are the main components in the frontend and how do they interact? ``` **機能の実装：** ``` Add a PATCH /users/:id endpoint with email uniqueness validation. Update the OpenAPI spec and add integration tests. Similar patterns exist in src/routes/users/get.ts. ``` **バグの修正：** ``` Users report file uploads fail randomly. Error in browser console: "Network timeout". Upload logic is in src/upload/handler.ts. Check for timeout handling. ``` **コードレビュー：** ``` Look at git diff and review these changes for security issues and maintainability. ``` **リファクタリング：** ``` Extract the email sending logic into a separate service class. Keep the same interfaces but make it testable in isolation. ``` ## エンタープライズ統合 チケットやドキュメントへのリンクを貼り付けてチームのツールを参照してください： ``` Implement the feature described in this Jira ticket: https://company.atlassian.net/browse/PROJ-123 Follow our security standards from the compliance docs. ``` Factoryのダッシュボードでこれらのプラットフォームを統合している場合、droidはJira、Notion、Slack、その他のソースから自動的にコンテキストを読み取ることができます。追加のツール接続については、droidはMCP統合もサポートしています。 セキュリティに敏感な作業については： ``` Add file upload functionality with proper validation to prevent directory traversal attacks. Follow the security patterns used in our document upload feature. ``` ## セッション管理 コンテキストが乱雑になった場合や関連しないタスクに切り替える場合は、新しい会話を開始してください。失敗した試行から蓄積されたノイズよりも、新鮮なコンテキストの方が多くの場合うまく機能します。 大きなプロジェクトの場合は、作業をフェーズに分けてください： ``` First implement the database schema changes. Don't add the API endpoints yet. ``` その後のフォローアップで： ``` Now add the REST endpoints using the new schema. Include validation and error handling. ``` ## 高度なテクニック **テスト駆動開発：** ``` Write comprehensive tests for the user registration flow first. Don't implement the actual registration logic yet. ``` **プラン駆動開発：** ``` Create a markdown file outlining the plan for updating both backend API and React components. Include the shared data structure and implementation order. Then implement each part following the documented plan. ``` ## 良いプロンプトの例 こちらはうまく機能する実際の例です： ``` Run git blame on the file I have open and figure out who added the rate limiting logic. ``` ``` Look at git diff staged and remove any debug statements before I commit. ``` ``` Convert these 5 React components to use TypeScript. Use proper interfaces for props. ``` ``` Find the commit that introduced the caching mechanism and explain how it works. ``` ``` Add input validation to all the forms in the admin panel. Return 400 with clear error messages. ``` ``` Check the production logs for any errors in the last hour and suggest fixes for the most common ones. ``` ## うまく機能しないもの 曖昧なリクエストは避けてください： * 「アプリを良くして」→ 範囲が広すぎる * 「データベースを修正して」→ 十分に具体的でない * 「フロントエンドを手伝ってもらえますか？」→ 目標が不明確 droidに推測させないでください： * ファイルパスを知っている場合は、それを含める * 実行するコマンドを知っている場合は、それについて言及する * 関連するコードがある場合は、それを指摘する ## より良い結果を得る droidを有能なチームメイトとして扱ってください。タスクに取り組む同僚に提供するのと同じコンテキストとガイダンスを提供してください。品質基準とビジネス要件について具体的に述べてください。 droidは時間をかけてあなたの組織のパターンを学習することを覚えておいてください。コードベース内でより一貫して使用するほど、あなたの規約に従うのが上手になります。 最も重要なことは、droidが提案する変更をレビューすることです。承認ワークフローを通じて完全な制御を維持しているため、変更を理解し、将来のより良い結果のためにフィードバックを提供する時間を取ってください。 これらのパターンを試す準備はできましたか？[Quickstart](/jp/cli/getting-started/quickstart)に戻って、あなた自身のコードで練習してください。