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

# 規画エージェント

# **概要**

Planning 機能により、エージェントモードはコード変更やコマンド実行の前に**実装案と計画**を作成します。\
中〜大規模なタスク(複数ファイルにまたがる機能開発、リファクタリング、高リスクな変更など)に対して、Planning は明確な可視性、制御可能な実行フロー、明確な実装パスを提供します。

Planning を有効にすると、Qoder は自然言語による要件から構造化された提案と計画を生成します。この計画をレビュー・調整した後、エージェントが自動的にステップごとに実行します。

## **適用シーン**

以下のシーンで Planning の使用をお勧めします:

* 複数のモジュールやファイルにまたがる**複雑な機能**を扱う場合。
* **複数回の反復**(設計、実装、テスト、クリーンアップなど)が予想される場合。

小さな変更(例:「スペルミスの修正」「変数名の変更」など)の場合は、Planning を使わず直接エージェントで実行して時間を節約できます。

## **エージェントモードでの使用方法**

Planning エージェントはエージェントモードに組み込まれており、個別の設定は不要です。2つの方法で呼び出せます:

* 自動呼び出し:エージェントモードがリクエストに基づいて計画が必要かどうかを判断します。
* 明示的呼び出し:/plan コマンドで Planning エージェントを明示的にリクエストします。

詳細な使用手順は以下の通りです:

### **1. タスクを記述する**

/plan で明示的に呼び出すか、または自然言語で直接要件を説明します。記述する際は以下の情報を含めることをお勧めします:

* 変更の目標や実装する機能。
* 制約条件(例: 「既存の API を壊さない」「レガシーパスの現在の動作を維持する」など)。
* オプション: 重要なファイルやモジュールのパスに言及する。

説明が明確で具体的であるほど、生成される計画は実際のニーズに合致します。

### **2. 計画を生成する**

セッションで Planning が有効な場合、Qoder は次の処理を行います:

* 要件と関連するエンジニアリングコンテキストを解析。
* 要件に基づいて、目標、技術アプローチ、技術スタック、実装計画などを含む完全な計画を生成。

この段階では、ファイルの変更やコマンド実行は行われません。出力されるのはレビュー可能な計画のみです。

### **3. 計画をレビュー・調整する**

実行開始前に、期待に応じて計画を変更できます。例えば:

* 提案内容を編集して、より正確で理解しやすくする。
* AI がカバーしていないが重要だと考えるステップを追加する。

また、自然言語で Qoder と直接協力して計画を調整することもできます。例:「最後にドキュメント更新のステップを追加して」。

### **4. 実行を開始する**

計画が正しいと確認したら、実行を開始できます:

* エージェントは通常のエージェントモードと同様に、ファイルの読み取り、コード変更、コマンド実行、MCP ツールの呼び出しを行います。
* To-do のステータスはチャット下部でリアルタイムに更新されます(未開始/進行中/完了)。

設定によっては、特にターミナルコマンドや MCP ツールの呼び出しなど、一部の操作は実行前に手動確認が必要な場合があります。

### **5. 実行中の調整**

計画実行中:

* 各 To-do のステータス変化をいつでも確認できます。
* 計画自体や実行結果に問題がある場合は、一時停止してチャットで新しい要件を説明し、Qoder に計画を更新してから続行させることができます。
* ブロッキング問題(テスト失敗、依存関係の欠落など)がある場合、Qoder は会話内で明確に指摘し、それに応じて次のステップを計画します。

このように、意思決定権は常にあなたが保持し、エージェントが具体的な機械的作業を担当します。

### **6. 終了とレビュー**

すべての To-do が完了した後(または実行を能動的に終了した後):

* Qoder に、この実行中にステップごとにどのような作業が完了したか(例:各 To-do でどのファイルが変更されたか)を要約させることができます。
* diff ビュー、ローカルテスト、PR ワークフローを組み合わせて、最終結果の通常のコードレビューを実行できます。
* フォローアップ作業の要件がある場合は、再度新しい Planning プロセスを開始して反復を続けることができます。

## **ベストプラクティス**

* **目標を明確に記述する**:同僚にタスクを割り当てるようにプロンプトを書き、スコープ、制約、受け入れ基準を説明します。
* **高リスクタスクにはデフォルトで Planning を有効にする**:リファクタリング、インターフェース調整、コアパスに関わる変更など。
* **計画を反復的に最適化する**:最初のバージョンの計画が理想的でない場合、Qoder に調整を依頼できます。例:「テスト部分にもっと焦点を当てて」「公開インターフェースへの変更を最小限に」。
* **各ステップを十分小さく保つ**:良い To-do アイテムは、比較的小さな diff 内でその影響範囲を確認できるものです。

Planning を活用することで、エージェントの高効率を維持しながら、慎重に設計された実装提案を得て、安全性と効率のより良いバランスを実現できます。