# プロンプトエンジニアリング (/ja/docs/verdent-for-vscode/best-practices/prompts)
> 効果的なプロンプトを書くためのベストプラクティス
***
効果的なプロンプトは、AI 支援開発を成功させる基盤です。明確で具体的なリクエストと適切なコンテキストがあれば、Verdent は正確で関連性の高い結果を返せます。
### このページで学べること [#このページで学べること]
* 効果的なプロンプトを書くためのベストプラクティス
* コンテキストの提供方法とよくある間違いの回避方法
* @メンションやサブエージェントへの委任といった高度なテクニック
* 適切に構成されたプロンプトの例
* 反復的に洗練させる戦略
***
## 効果的なプロンプトとは [#効果的なプロンプトとは]
効果的なプロンプトは明確かつ具体的で、Verdent が意図を理解して正確な結果を返すために必要なコンテキストを提供します。
**主な原則:**
* **具体的に書く** - あいまいなリクエストではなく、必要なものを正確に示します
* **詳細を含める** - 好みがある場合は技術仕様を提供します
* **範囲を指定する** - どのファイルやコンポーネントが対象かを明確にします
* **コンテキストを提供する** - Verdent がアーキテクチャを理解できるようにします
* **成果を示す** - 成功した状態がどのようなものかを説明します
* **自然言語を使う** - 特別な構文は不要です
**変換の例:**
**悪い例:**
```
Fix the code
```
**良い例:**
```
Add input validation to the email field in ContactForm.js to reject invalid email formats
```
**悪い例:**
```
Add authentication
```
**良い例:**
```
Add JWT authentication using the same middleware pattern as auth.js, store tokens in httpOnly cookies
```
***
## よくあるプロンプトの間違い [#よくあるプロンプトの間違い]
**プロンプトの例:**
```
Make the app better
```
```
Fix the bugs
```
| 問題 | 解決策 |
| --------------------------------------- | ----------------------------- |
| Verdent はどんな改善を望んでいるのか、どのバグに対処すべきかわからない | 何を改善すべきか、どのバグを修正すべきかを正確に指定します |
**プロンプトの例:**
```
Add authentication
```
| 問題 | 解決策 |
| --------------------------------------------------- | ---------------------- |
| OAuth を使っているのに Verdent が JWT を実装する、またはその逆が起こる可能性がある | 実装方法、既存パターン、技術要件を指定します |
**プロンプトの例:**
```
Build the entire user management system with authentication, authorization, profiles, settings, and admin dashboard
```
| 問題 | 解決策 |
| ------------------------------------ | ------------------------------------------ |
| 複数システムにまたがる複雑なリクエストは、一度で正しく実行するのが難しい | 小さなタスクに分割します。まず認証、次に認可、最後にプロフィールという順序で進めます |
**プロンプトの例:**
```
Update the validation logic
```
| 問題 | 解決策 |
| ------------------------ | -------------------------------------------------------- |
| どのファイルやバリデーションを変更すべきか不明確 | 範囲を指定します。「UserController.js のバリデーションを更新して強力なパスワードを必須にする」 |
**プロンプトの例:**
```
Expecting Verdent to know your specific business rules or constraints
```
| 問題 | 解決策 |
| ------------------------------- | -------------------------- |
| Verdent は固有の要件を反映せず汎用的な解決策を実装する | すべての制約、ビジネスルール、要件を明示的に示します |
**プロンプトの例:**
```
Referencing files without including them in context
```
| 問題 | 解決策 |
| ---------------------------------- | -------------------------------- |
| Verdent が話題にしているファイルにアクセスできない場合がある | @filename.js を使って関連ファイルを明示的に含めます |
**プロンプトの例:**
```
Repeatedly asking for the same thing when Verdent encounters errors
```
| 問題 | 解決策 |
| --------------------- | ----------------------------------- |
| 同じアプローチでは同じエラーが繰り返される | エラーメッセージを読み、何が失敗したかに基づいてプロンプトを調整します |
**プロンプトの例:**
```
Requesting large refactorings or multi-file changes without using Plan Mode first
```
| 問題 | 解決策 |
| ---------------------- | ------------------------------------------ |
| ファイルが変更されるまで全体の範囲が見えない | 複雑なタスクでは Plan Mode に切り替え、実行前にアプローチをレビューします |
複雑な変更では Plan Mode を有効にして実行前にアプローチをレビューしましょう。これにより誤解を早期に発見できます。
**プロンプトの例:**
```
Using Auto-Run or Skip Permission Mode without Git initialized
```
| 問題 | 解決策 |
| --------------------------------- | ------------------------------------- |
| Verdent が望まない変更を加えた場合のセーフティネットがない | 制限の緩いモードを使う前に、必ず Git を初期化してコミットしておきます |
**プロンプトの例:**
```
Providing incomplete requirements and expecting Verdent to guess correctly
```
| 問題 | 解決策 |
| ---------------------------- | ---------------------------------------------------- |
| Verdent がニーズに合わない前提に基づいて実装する | Verdent にヒアリングを依頼します。「プランを作成する前に、要件について確認の質問をしてください」 |
***
## 適切に構成されたプロンプトの例 [#適切に構成されたプロンプトの例]
明確な要件と制約のもとで新しい機能を作成する例:
```
Create a POST /api/tasks endpoint that:
- Accepts task title (required), description (optional), and category_id (required)
- Validates that the category exists in the database
- Returns 400 if validation fails with descriptive error messages
- Saves the task to the database and returns the created task with 201 status
- Add this to the existing tasks router in routes/tasks.js
- Create the controller method in controllers/taskController.js
- Use the existing error handling pattern from other controllers
```
**効果的な理由:**
* 入力とバリデーションに関する明確な要件
* 実装するファイルの具体的な場所
* 一貫性を保つための既存パターンへの参照
* 期待される HTTP ステータスコードとエラー処理
コンテキストと提案する解決策とともに問題を説明する例:
```
Fix the race condition in payment processing at checkout. When multiple users submit payments simultaneously, some transactions fail with "duplicate order ID" errors. The issue appears to be in PaymentController.js around line 45 where we generate order IDs. Implement proper locking or use UUID generation to ensure unique IDs even under concurrent load.
```
**効果的な理由:**
* 症状を含む明確な問題の説明
* 問題の具体的な場所（ファイルと行番号）
* 発生する状況についてのコンテキスト（同時アクセスユーザー）
* 提案された解決アプローチ
動作を維持しつつ実装を変更する例:
```
Refactor the authentication middleware in middleware/auth.js to use JWT tokens instead of session cookies. Keep the same authorization logic, but:
- Replace session validation with JWT verification
- Store tokens in httpOnly cookies
- Maintain the existing user object structure that routes expect
- Update only the authentication mechanism, don't change authorization rules
- Ensure all existing routes continue to work without modification
```
**効果的な理由:**
* 明確な目標（セッションの代わりに JWT を使用）
* リファクタリングする具体的なファイル
* 明示的な制約（変更すべきでないもの）
* 後方互換性の要件
包括的なカバレッジでテストを書く例:
```
Write comprehensive unit tests for the UserService class in services/UserService.js. Cover:
- User creation with valid and invalid data
- Email validation edge cases (empty, malformed, duplicate)
- Password hashing verification
- User lookup by ID and email
- Error handling for database failures
Use Jest and follow the testing patterns in existing service tests
```
**効果的な理由:**
* テスト対象の具体的なクラス／ファイル
* カバーすべきシナリオの完全なリスト
* 指定されたテストフレームワーク
* 既存のテストパターンへの参照
詳細な仕様で UI コンポーネントを構築する例:
```
Create a reusable SearchBar component for the product catalog with:
- Text input with real-time debounced search (300ms delay)
- Category dropdown filter (fetch options from /api/categories)
- Price range slider (min $0, max $1000)
- Clear filters button
- Use Material-UI components to match existing design
- Emit search parameters via onChange callback to parent
- Include PropTypes for all props
```
**効果的な理由:**
* 具体的な詳細を含む完全な機能リスト
* 技術仕様（300ms のデバウンス、価格帯）
* 指定された UI ライブラリ（Material-UI）
* 統合方法（親へのコールバック）
***
## 高度なプロンプトテクニック [#高度なプロンプトテクニック]
特定のファイル、コンポーネント、サブエージェントを参照する例:
```
@auth.js @UserController.js Refactor authentication to use the same validation pattern
```
**メリット:**
* 特定のファイルを明示的に含めることで Verdent に正確なコンテキストを保証します
* 類似したファイル名の多い大規模コードベースでのあいまいさを防ぎます
* 正確なリファクタリングやパターンマッチングのために、関連コードを同時にすべて参照できるようにします
* あるファイルの実装パターンを別のファイルに適用する際に不可欠です
大きな変更では実行前に Plan Mode に切り替えます:
```
Switch to Plan Mode
Refactor the entire API layer to use TypeScript with strict type checking
```
**メリット:**
* ファイルが変更される前に Verdent の完全なアプローチをレビューできます
* 大規模なリファクタリングやアーキテクチャ変更でのコストの高いミスを防ぎます
* 実行が始まる前にプランを反復改善し、制約を追加したり方向性を完全に修正したりできます
* すべての要件を事前に集めるため、Verdent に確認の質問でヒアリングしてもらうよう依頼できます
組み込みまたはカスタムのサブエージェントに専門タスクを委任します:
```
@Code-reviewer Review the security vulnerabilities in authentication flow
@Explorer Find all files that import the deprecated API client
@Verifier Validate the authentication logic in the middleware
```
**メリット:**
* 特定のタスク（探索、検証、コードレビュー）に最適化された専門エージェントを活用できます
* 汎用的な処理よりも専門性が高く、結果が速く得られます
* 複数の分析を並行実行して総実行時間を大幅に短縮できます
* プロジェクト固有の要件向けにドメイン知識を持つカスタムサブエージェントを作成できます
**組み込みのデフォルトサブエージェント:**
* `@Verifier` - 素早いコードチェックと検証
* `@Explorer` - 高速なコードベース探索とファイル検索
* `@Code-reviewer` - コード品質の評価
コードベースに関する質問には @Explorer を、セキュリティ分析には @Code-reviewer を使いましょう。対象を絞った委任は、メインエージェントによるルーティングよりも高速です。
高度な課題のために拡張推論を有効にします:
```
Think: Design the optimal database schema for a multi-tenant SaaS application
```
**メリット:**
* 複雑な問題を複数の角度から深く分析する拡張推論を有効にします
* 代替アプローチやエッジケースをより徹底的に評価します
* 正確さが最優先される場面で堅牢な解決策を生み出します
* 応答は遅くクレジット使用量も増えますが、急ぎで最適でない解決策による高コストな手戻りを防ぎます
Think Hard Mode は、アーキテクチャの決定、複雑なデバッグ、深い分析を要するアルゴリズム問題に優れています。
前回の応答を土台に、段階的に洗練させます:
```
Initial: "Create a dashboard component"
Follow-up: "Add real-time data updates using WebSockets"
Follow-up: "Now add filtering and sorting capabilities"
```
**メリット:**
* 複雑さを加える前に各ステップでテストしながら段階的に開発できます
* 各レイヤーが正しく動作することを検証してから次を構築するため、リスクを減らせます
* 反復が予想外の結果を生んだ場合、すぐに軌道修正できます
* 各反復が小さく独立しているため、どの変更がバグを生んだかを特定しやすくなります
反復的な洗練はリスクを減らします。小さな範囲から始めて結果を検証し、その後徐々に広げましょう。
変更する内容とあわせて、変更しない内容も指定します:
```
Add caching to the API endpoints, but:
- Don't modify the authentication middleware
- Keep the existing error handling unchanged
- Maintain backward compatibility with mobile clients
```
**メリット:**
* 境界を明示し、重要なシステム（認証、決済）の変更を防ぎます
* コンプライアンスやリスク要件のために変更してはならない安定したシステムを保護します
* 変更を実装し、壊れた機能を見つけ、解決策を作り直すという高コストなサイクルを回避します
* 後方互換性を維持し、実績のあるコードを不要なリファクタリングから守ります
実装例として既存コードを指し示します:
```
Implement the new ProductService following the same pattern as UserService.js, including error handling, validation, and database transaction management
```
**メリット:**
* 新しい実装が確立された規約との一貫性を保つようにします
* コードベースの保守性と予測可能性を高めます
* 必要な説明を大幅に減らせます。アプローチを詳細に説明する代わりに例を指し示せます
* 解決策を作り直すのではなく、実証済みのパターンを活用します
* バグを減らし、既存システムとのシームレスな統合を実現します
複雑で多段階のタスクを追跡するために todos.md ファイルを作成します:
```
Create a todos.md file with these tasks:
1. Refactor authentication to use JWT tokens
2. Update all controllers to use new auth middleware
3. Add tests for authentication flow
4. Update API documentation
```
**メリット:**
* レビュー、改善、チームメイトとの共有が可能な、明確な書面のロードマップを作成できます
* プロジェクト全体で要件が変化しても容易に調整できます
* セッションをまたいで保持されるため、作業を一時停止して後で再開し、どこまで進んだかをすぐに把握できます
* 何を計画し、完了し、残しているかを記録するプロジェクト成果物として、今後の保守やオンボーディングに役立ちます
異なる todo の間では新しいセッションを開始して、コンテキストを新鮮に保ちます:
```
After completing todo #1: "Start a new session"
Then: "Let's work on todo #2 from todos.md"
```
**メリット:**
* 前のタスクの詳細が現在の作業に不適切な影響を与えるコンテキスト汚染を防ぎます
* 前のタスクの負担を持ち込まず、現在の todo だけに集中できます
* 不要な会話履歴を読み込まないことでトークン使用量を削減します
* 応答が速くなり、クレジット効率も向上します
* テストとコミットの自然なチェックポイントを作り、きれいな git 履歴を保ち、問題の切り分けを容易にします
MCP（Model Context Protocol）サーバーを使って専門的なコンテキストを注入します:
* プロジェクト固有のドキュメント
* API 仕様（OpenAPI、GraphQL スキーマ）
* フレームワーク固有の知識
**メリット:**
* トレーニングデータに含まれないカスタムフレームワーク、社内ツール、専門ドメインに対する Verdent の理解を高めます
* 組織固有の API 仕様やドキュメントを直接注入することで、カスタムシステムを繰り返し説明する必要をなくします
* プロンプトだけでは伝えきれない社内 API や独自システムの正しい利用を可能にします
***
## プロンプトにコンテキストを含める [#プロンプトにコンテキストを含める]
関連ファイルを明示的にコンテキストに含めます:
```
@models/User.js @controllers/UserController.js Add password reset functionality
```
**使うべき場面:**
* 密結合したファイル（モデルとコントローラー、サービスとテスト）を扱う場合
* あるファイルの実装パターンを別のファイルに適用するために参照する場合
* 複数の関連ファイルにまたがる変更を調整する場合
* 類似したファイル名が多く、自動検出がコンテキストを見落としかねない大規模コードベースの場合
* Verdent に「...と同じパターンに従って」と依頼する際は、正確なコードを参照させるために必ず使用します
スタックに関する高レベルのコンテキストを含めます:
```
This is a MERN stack application (MongoDB, Express, React, Node.js) with JWT authentication. Add role-based access control following our existing middleware pattern.
```
**使うべき場面:**
* 既存の技術スタックと統合する必要がある機能を実装する場合
* コードベースでの初めての作業や、複数レイヤー（フロントエンドからデータベースまで）にまたがる機能の場合
* スタックに強いこだわりがあり（GraphQL と REST、Redux と Context API）、実装の選択に影響する場合
* 汎用的な解決策ではなく、システムに合うアプローチを Verdent に選ばせたい場合
規約を示すコードを指し示します:
```
Follow the same error handling pattern used in ProductController.js - return consistent error objects with status codes and descriptive messages
```
**使うべき場面:**
* 新しいコードを確立された規約（エラー処理、バリデーション、ロギング、テスト）と一貫させたい場合
* コードベースの新しい領域で類似機能を実装する場合
* 既存パターンを学んで再現したい、コードベースの不慣れな部分にオンボーディングする場合
* パターンを詳細に説明するのを避け、言語化しにくいニュアンスを Verdent に捉えてほしい場合
制限や要件を示します:
```
We're using TypeScript with strict mode enabled, React 18 with hooks only (no class components), and Material-UI v5 for styling
```
**使うべき場面:**
* プロジェクトに特定の技術要件がある場合（TypeScript の strict モード、React hooks のみ、外部依存なし）
* レガシーな制約（IE11 サポート、Node.js 14 互換性）を扱う場合
* コンプライアンス要件が選択を左右する場合（WCAG アクセシビリティ、GDPR のデータ処理）
* バージョン間で破壊的変更のある特定のライブラリバージョンを使う場合
* プロジェクトの技術的境界に違反する解決策を Verdent が提案しないようにしたい場合
ドメイン固有のルールを説明します:
```
Users can only view tasks assigned to them or their team. Managers can view all tasks in their department. Admins can view everything.
```
**使うべき場面:**
* コードだけからは Verdent が推測できないドメイン固有のルールを持つ機能を実装する場合
* 認可ロジック（誰が何にアクセスできるか）、ビジネスワークフロー（承認プロセス、ステートマシン）
* バリデーションルール（パスワードポリシー、データ制約）、ドメイン制約（在庫上限、価格ルール）
* エンティティの関係や多重度の説明が必要なデータモデルを構築する場合
* 計算（割引ルール、税計算、コミッション体系）を実装する場合
* 単に機能するコードではなく、組織のビジネスルールを正しく適用させたい場合に Verdent へ伝えます
デバッグ時にはエラーメッセージやログを共有します:
```
Getting "TypeError: Cannot read property 'id' of undefined" at UserController.js:42 when trying to update user profiles. The req.user object exists but doesn't have an id property after the recent auth middleware changes.
```
**使うべき場面:**
* バグ修正時には、常に完全なエラーメッセージ、スタックトレース、ログを含めます
* 実行時エラー（例外、クラッシュ）、ビルド失敗（コンパイルエラー、Lint 違反）
* テスト失敗（アサーションエラー、タイムアウト）、予期しない動作（誤った出力、データ欠落）
* 行番号付きの正確なエラーメッセージと、呼び出し連鎖を示す完全なスタックトレースがある場合
* 発生する状況についてのコンテキスト（常に、断続的に、特定の条件下で）を提供できる場合
* 推測ではなく根本原因を特定する Verdent の能力を大幅に高めたい場合
Verdent はリクエストに基づいて関連ファイルを自動的に読み込みます:
* プロンプト内で名前が言及されたファイル
* 同じディレクトリ内の関連ファイル
* よくアクセスされるプロジェクトファイル
**これに頼ってよい場面:**
* 関係が明白な標準的なファイル参照の場合
* 名前でコンポーネントを言及し、Verdent がその特定ファイルを読み込む必要がある場合
* よく一緒に扱われる同じディレクトリ内のファイルを扱う場合
* 頻繁に使うプロジェクトファイル（package.json、設定ファイル）にアクセスする場合
* よく整理されたコードベースでの分かりやすいシナリオではうまく機能します
* 複雑な複数ファイルのリファクタリング、離れたコードベース部分、あいまいなファイル名の場合は、代わりに明示的な @メンションを使います
ルールファイル（Settings → Rules）で永続的なコンテキストを設定します:
**ユーザールール（VERDENT.md）:**
すべてのプロジェクトに適用されるグローバルな設定
**プロジェクトルール（AGENTS.md）:**
プロジェクト固有の基準 - アーキテクチャパターン、コーディング標準
**プランルール（plan\_rules.md）:**
Plan Mode でのプランの形式と内容をカスタマイズ
**使うべき場面:**
* セッションをまたいで同じコンテキストを繰り返し提供している場合
* 個人の好み（コーディングスタイル、好きなライブラリ、好むパターン）にはユーザールールを使います
* チームの基準（アーキテクチャの決定、命名規約、テスト要件）にはプロジェクトルールを使います
* 新しいチームメンバーのオンボーディングに有用（暗黙知を明文化）
* 大規模チーム全体で一貫性を保ち、プロンプトの冗長さを減らします
* プロジェクトが成熟し、文書化する価値のある確立されたパターンができたら、ルールファイルに投資します
スクリーンショット、モックアップ、図を含めます:
```
@screenshot.png Implement this UI design with React components
```
**使うべき場面:**
* 視覚情報がテキストよりも効果的に要件を伝える場合
* UI/UX の実装（デザインモックアップ、ワイヤーフレーム、ユーザーフロー）
* 視覚的な問題のデバッグ（崩れたレイアウトのスクリーンショット、レンダリングの問題）
* 複雑なアーキテクチャの理解（システム図、データベーススキーマ、フローチャート）
* レスポンシブデザイン、アクセシビリティ分析、エラー再現に不可欠
* Figma や Sketch などのツールのデザインをコードに変換する場合
* 適切に撮影された 1 枚のスクリーンショットは、文章で何段落も要する詳細を伝えることが多いです
外部ドキュメントや例を参照します:
```
Ultrathink: Read this API documentation at https://api-docs.example.com/v1/endpoints and implement the authentication flow
```
**使うべき場面:**
* オンライン公式ドキュメントのある外部 API やライブラリとの統合を実装する場合
* ライブラリに複雑な設定オプションや認証フローがある場合に特に有用
* コード生成の前にウェブコンテンツを取得・分析させるには「Ultrathink:」プレフィックスで Verdent に指示します
* ドキュメントがトレーニングデータより新しい、急速に進化する API には不可欠
* フレームワーク固有のパターン（Next.js App Router、Vue Composition API）に従う場合
* 実装が現在の API バージョンに一致し、公式の推奨事項に従うようにします
***
## 反復的に洗練させる戦略 [#反復的に洗練させる戦略]
**最初のプロンプト:**
```
Add authentication to the API
```
Verdent の応答は汎用的かもしれません。洗練させます:
```
Use JWT tokens stored in httpOnly cookies, implement refresh token rotation, and follow the authentication pattern from our existing UserController
```
**使うべき場面:** 一般的なリクエストから始め、最初の応答に基づいて詳細を追加する場合
Verdent の実装が期待と一致しない場合:
```
The validation logic is good, but use Joi schema validation instead of manual checks. Match the validation pattern in ProductController.js
```
**使うべき場面:** 出力をレビューし、具体的な改善点を特定した後
段階的に構築します:
```
Initial: "Create a UserProfile component"
Follow-up: "Add an avatar upload feature with image preview"
Follow-up: "Add validation - max 5MB, only jpg/png formats"
Follow-up: "Show upload progress with a progress bar"
```
**使うべき場面:** 同じセッション内で機能を段階的に構築する場合
実装が予想外に思える場合:
```
Why did you use Redux instead of Context API? Can you explain the trade-offs for this use case?
```
そして理解に基づいて洗練させます:
```
Actually, use Context API for consistency with the rest of our application
```
**使うべき場面:** 変更を依頼する前に理由を理解する場合
複雑な変更の場合:
```
Switch to Plan Mode
Show me how you would refactor the authentication system to support OAuth providers
```
プランをレビューし、質問し、実行前にアプローチを反復改善します。
**使うべき場面:** レビューが必要な大規模なアーキテクチャ変更
Verdent のスタイルが自分のものと一致しない場合:
```
The component structure is close, but use this pattern instead:
[paste example of your preferred structure]
Apply this same pattern to the remaining components
```
**使うべき場面:** コードスタイルの好みを確立または強化する場合
出力が明示していなかった制約に違反する場合:
```
Good approach, but don't modify the database schema - work within the existing User table structure
```
**使うべき場面:** 最初の実装を見た後に判明した制約を追加する場合
コア機能から始めて、機能を反復的に追加します:
```
Step 1: "Create basic CRUD endpoints for tasks"
Step 2: "Add pagination to the GET endpoint"
Step 3: "Add filtering by status and priority"
Step 4: "Add full-text search across title and description"
```
**使うべき場面:** 各ステップでテストしながら複雑な機能を段階的に構築する場合
***
## よくある質問 [#よくある質問]
あいまいさをなくすのに十分なほど具体的にしつつ、明白な詳細を説明しすぎないようにします。含めるべきは、正確なファイルパス、実装方法、期待される成果、制約です。悪い例:「コードを直して」- あいまいすぎます。良い例:「`ContactForm.js` のメールフィールドに入力バリデーションを追加して無効なメール形式を拒否する」- 範囲と目標が明確です。迷ったときは、より具体的にする方を選びましょう。
Verdent は、プロンプト内で名前が言及されたファイルや同じディレクトリ内の関連ファイルを自動的に読み込みます。`@-mentions`（`@filename.js`）は、ファイルがコンテキストに含まれることを明示的に保証します。これは密結合したファイルを扱う場合、あるファイルのパターンを別のファイルに適用するために参照する場合、大規模コードベースで自動検出がコンテキストを見落とす可能性がある場合に重要です。Verdent に「...と同じパターンに従って」と依頼する際は、正確なコード参照を保証するために必ず `@-mentions` を使いましょう。
次の場合に Plan Mode を使います。大規模なリファクタリングやアーキテクチャ変更、実行前に範囲をレビューしたい複数ファイルの変更、要件が不確かな複雑なタスク、または実装前に Verdent に確認の質問でヒアリングしてほしい場合。次の場合は Plan Mode をスキップします。シンプルで明確に定義されたタスク、素早いバグ修正、定型作業。Plan Mode はオーバーヘッドが増えますが、複雑な作業でのコストの高いミスを防ぎます。
反復的な洗練を使います。出力をレビューし、何が間違っているかを特定し、フォローアッププロンプトで修正を提供します。例:「バリデーションロジックは良いですが、手動チェックの代わりに Joi スキーマバリデーションを使ってください。`ProductController.js` のバリデーションパターンに合わせてください。」説明を求めることもできます。「なぜ Context API ではなく Redux を使ったのですか？」そして理解に基づいて洗練させます。同じプロンプトを繰り返さず、何が失敗したかに基づいて調整しましょう。
いいえ。Verdent はセッション内で会話のコンテキストを維持するため、すでに説明したアーキテクチャの詳細や規約を繰り返す必要はありません。ただし、重要な制約がある場合やセッションが長くなった場合（`100+` のメッセージ）は、重要なコンテキストを再度示します。より良い方法は、プロジェクトルール（`AGENTS.md`）を使って技術スタック、コーディング標準、パターンなどの永続的なコンテキストを文書化することです。そうすれば繰り返す必要がなくなります。
明確な意図、関連するコンテキスト、具体的な制約を備えた、適切に構成されたプロンプトは一貫してより良い結果を生み出します。
***
## 関連項目 [#関連項目]
コンテキストウィンドウの管理と最適化の戦略
さまざまなシナリオに応じた実行モードの理解
エラーの処理と問題のトラブルシューティング