> ## 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.

# Goal 駆動

Quest で **Goal** モードを選ぶと、達成したい目標を記述するだけで、Quest が自律的に経路を計画し、継続的に反復しながら結果を検証します。複数ステップで進める必要があり、「逐一指示する」のではなく「成果を納品してほしい」タスクに適しています。

## コア機能

<CardGroup cols={2}>
  <Card title="目標駆動の自律実行" icon="bullseye">
    * 目標を記述すれば、Quest がタスクを自ら分解し、実行経路を計画して継続的に推進します。逐次的な指示は不要です。
    * Quest は各ラウンドの実行後に現在の進捗を評価し、目標が達成されたかどうかを判断します。未達成の場合は自動的に次のラウンドの反復へ進みます。
  </Card>

  <Card title="柔軟なプロセス制御" icon="sliders">
    * 実行中はいつでも一時停止、目標の編集、タスクの削除ができます。一時停止後も完全なコンテキストと中間成果物が保持されます。
    * 目標を編集すると、Quest は次のラウンドから新しい目標に沿って実行を続けます。既存の進捗はリセットされません。
  </Card>
</CardGroup>

## 適用シーン

* **長時間実行のコーディングタスク**：明確な成功条件と検証ループがある作業 — テストカバレッジの向上、パフォーマンスチューニング、ファイル横断の一貫性修正など。Quest が自律的に反復・検証し、目標達成まで継続します。
* **大規模なリファクタリング**：コード移行、リポジトリ全体のフレームワーク移行、一括 API 置換など、各ステップを事前に網羅できないタスク。Goal で期待する終状態を記述すれば、Quest が経路を計画し継続的に推進します。

## 使い方

<Steps>
  <Step title="Goal モードを有効化">
    入力ボックスの「**+**」ボタンから **Goal** スイッチをオンにするか、入力ボックスに `/goal` と入力します。
  </Step>

  <Step title="目標を記述">
    達成したい最終状態を自然言語で記述します。目標は具体的なステップではなく**期待する結果**を記述してください。Quest が実行経路を自ら計画します。

    例：`/goal プロジェクトのテストカバレッジを 80% まで引き上げる`
  </Step>

  <Step title="自律実行">
    目標を送信すると、Quest は自律実行ループに入ります：

    * 入力ボックス上部に Goal 進捗カードが現れ、現在の目標と実行状態を表示します
    * Quest は各ラウンドの実行後に進捗を評価し、未達成なら自動的に続行します。目標が達成されると自動的に終了します
  </Step>

  <Step title="実行中のタスク管理">
    Goal 進捗カードは次の操作に対応します：

    * **編集**：カード右上の編集ボタンをクリックして目標の記述を変更します。実行中の編集は現在のラウンド終了後に反映され、一時停止中の編集は即座に反映されます。
    * **一時停止と再開**：一時停止すると完全なコンテキストとすべての中間成果物が保持され、再開をクリックすると中断箇所から実行を再開します。
    * **削除**：現在の目標タスクを削除すると、会話は通常の対話状態に戻ります。生成済みのファイルとメッセージは削除されません。
  </Step>
</Steps>

<Note>
  目標駆動実行はデフォルトで最大 **10 ターン** まで実行し、上限に達すると自動的に終了します。**設定 → 統合 → 組み込み機能 → 目標駆動実行** から最大ターン数を引き上げて、タスクの複雑さに合わせて実行の深さを調整できます。
</Note>

## Goal と Spec の違い

|             | Goal 駆動                          | Spec 駆動                    |
| ----------- | -------------------------------- | -------------------------- |
| **位置づけ**    | 目標を起点に、Agent が経路を自律的に計画          | 仕様を設計図に、既定のプランに沿って項目ごとに実装  |
| **入力**      | 期待する最終状態を記述                      | 構造化された方案の記述                |
| **実行方式**    | Agent が自律的に反復し、完了度を自ら判断          | Spec のタスクリスト順に実行           |
| **典型的なシーン** | テストカバレッジ向上、コードのリファクタリング、性能チューニング | 新機能開発、デザイン案どおりの実装、明確な要件の納品 |

## ベストプラクティス

* **検証可能な最終状態を記述する**：良い目標は「いくつかテストを書く」ではなく「テストカバレッジを 80% にする」です。Quest は達成を判断するために明確な完了基準を必要とします。
* **重要な制約を加える**：変更してほしくない部分があれば、目標の中で明示してください。例：「公開 API を変更せずに内部実装を最適化する」。
* **範囲を適切に絞る**：「プロジェクト全体をより良くする」のような大きすぎる目標は、Quest が焦点を定めにくくなります。具体的で測定可能なサブ目標に分割するほうが効果的です。
* **スケジュールタスクと組み合わせて実行する**：時間のかかる Goal タスクは夜間の実行にも向いています。`/schedule` で [スケジュールタスク](./scheduled-tasks) のトリガーを設定しましょう。