メインコンテンツへスキップ

概要

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