Skip to main content

新しいタスクツール

new_taskツールとコンテキスト管理戦略​

概要​

Clineには、特に複雑または長時間実行されるタスクにおいて、ワークフローの継続性とコンテキスト保存を管理するために設計された強力な内部ツールnew_taskが含まれています。このツールは、Cline自体のコンテキストウィンドウ使用量の認識と.agents/contextの柔軟性と組み合わせることで、作業の分割とタスクセッション間のシームレスな移行を確保する洗練された戦略を可能にします。

この機能を効果的に活用するには、コア機能とカスタムルールとの相互作用を理解することが重要です。

コア機能​

高度なコンテキスト管理を可能にする2つの基本機能：

  1. new_taskツール：
    • 機能： ユーザーの承認により、Clineが現在のタスクセッションを終了し、すぐに新しいセッションを開始できます。
    • コンテキスト事前読み込み： 重要なことは、Clineがツールの<context>ブロック内で提供された特定のコンテキストで、この新しいタスクセッションを事前読み込みできることです。このコンテキストは、Clineまたは.agents/contextファイルが定義するもの（要約、コードスニペット、次のステップ、プロジェクト状態など）であることができます。
  2. コンテキストウィンドウ認識：
    • 追跡： Clineは、タスク中に現在使用されている利用可能なコンテキストウィンドウのパーセンテージを内部的に追跡します。
    • 可視性： この情報は、Clineのプロンプトで提供されるenvironment_detailsで確認できます。

/newtaskスラッシュコマンドの使用​

Clineがnewtaskツールを提案したり複雑なルールを定義したりする代わりに、スラッシュコマンドを使用してプロセスを直接開始することができます。

  • 方法： チャット入力フィールドに単に/newtaskと入力します。
  • 動作： Clineは新しいタスクの作成を提案し、通常は現在のセッションに基づいたコンテキストを提案します（ツールを使用する際のデフォルト動作と同様）。新しいタスクが作成される前に、コンテキストを確認し潜在的に修正するためのask_followup_questionプロンプトが表示されます。
  • 利点： Clineが提案するのを待つことなく、分岐探索や長時間セッションの管理のためにnew_task機能を活用する、ユーザー主導の高速な方法を提供します。
ℹ️Note

/newtaskスラッシュコマンドの使用に関する詳細については、新しいタスクコマンド ドキュメントを参照してください。

デフォルトの動作（.agents/contextなし）​

デフォルトでは、特定の.agents/contextがその動作を指示していない場合：

  • ツールの利用可能性： new_taskツールが存在し、Clineはそれを使用することを_選択できます_。
  • コンテキスト認識： Clineは、そのコンテキスト使用率のパーセンテージを_認識しています_。
  • 自動トリガーなし： Clineは、コンテキスト使用量が特定のパーセンテージ（50%など）に達することだけに基づいて、タスクハンドオフを自動的に開始することはありません。new_taskの使用を提案する決定は、全体的なタスクの進行とプロンプト指示に基づくAIモデルの推論から来ます。
  • 基本的なコンテキスト事前読み込み： <context>ブロック構造を定義する特定のルールなしでnew_taskが使用される場合、Clineは現在の理解に基づいて関連情報を事前読み込みしようとします（例：進捗と次のステップの基本的な要約）が、これはルール駆動のアプローチよりも包括的でない場合があります。

.agents/contextの力：カスタムワークフローの有効化​

コア機能はデフォルトで存在しますが、真の力、自動化、カスタマイゼーションは、new_taskとコンテキスト認識を.agents/contextで定義されたカスタムワークフローと組み合わせる際に現れます。これにより、Clineがコンテキストとタスクの継続性を管理する_タイミング_と_方法_を正確に制御できます。

.agents/contextをnew_taskで使用する主な利点：

  • 自動コンテキスト管理： 特定のコンテキストパーセンテージ（例：>50%、>70%）またはトークン数で自動的にハンドオフをトリガーするルールを定義し、最適なパフォーマンスを確保してコンテキスト損失を防ぎます。
  • モデル固有の最適化： 異なるLLMの既知のしきい値に基づいてハンドオフトリガーを調整します（例：特定のトークン数を過ぎると劣化することが知られているモデルに対して早期にトリガー）。
  • インテリジェントなブレークポイント： コンテキストしきい値を通過した_後に_、論理的な停止点（例：関数またはテストの完了後）を見つけるようルールを介してClineに指示し、よりクリーンなハンドオフを確保します。
  • 構造化されたタスク分解： プランモードを使用してサブタスクを定義し、.agents/contextを使用して各サブタスクの完了時にClineがnew_taskを介して自動的に新しいタスクを作成し、_次の_サブタスクのコンテキストを事前読み込みします。
  • カスタムコンテキストパッケージング： 非常に詳細で一貫性のあるハンドオフのために、.agents/contextで<context>ブロックの正確な構造と内容を義務付けます（以下の例を参照）。
  • 改善されたメモリ永続性： セッション間で情報を永続化する主要な統合方法としてnew_taskコンテキストブロックを使用し、ファイルベースのメモリシステムを潜在的に置き換えるか補完します。
  • ワークフロー自動化： 特定の種類のタスクを開始する際に、常に特定のセットアップ指示またはプロジェクトボイラープレートを事前読み込みするなど、特定のシナリオのルールを定義します。

ルール駆動ワークフローの例：タスクハンドオフプロセス​

以下の例のような特定の.agents/contextによって駆動される一般的なワークフローには、以下のステップが含まれます：

  1. トリガー識別（ルールベース）： Clineは、ルールで定義されたハンドオフポイント（例：コンテキスト使用量 > 50%、タスク完了）を監視します。

  2. ユーザー確認： Clineはask_followup_questionを使用して新しいタスクの作成を提案し、しばしばルールで定義された意図されたコンテキストを表示します。

    <ask_followup_question>
    <question>[特定の成果]を完了し、コンテキスト使用量が高く（XX%）なっています。[残りの作業]を続行するために新しいタスクを作成し、以下のコンテキストを事前読み込みしますか？</question>
    <options>["はい、新しいタスクを作成", "最初にコンテキストを修正", "いいえ、このセッションを続行"]</options>
    </ask_followup_question>

  3. ユーザー制御： 新しいタスクが作成される前に、承認、拒否、またはコンテキストの修正をClineに求めることができます。

  4. コンテキストパッケージング（new_taskツール）： 承認された場合、Clineはnew_taskを使用し、.agents/contextで義務付けられた構造に従ってコンテキストをパッケージ化します。

  5. 新しいタスクの作成： 現在のタスクが終了し、指定されたコンテキストで事前読み込みされた新しいセッションがすぐに開始されます。

ハンドオフコンテキストブロック（ルール定義構造）​

ルール駆動ハンドオフの効果は、.agents/contextが<context>ブロックをどのように定義するかに大きく依存します。包括的な構造には通常以下が含まれます：

  • ## 完了した作業: 成果、変更/作成されたファイル、重要な決定の詳細なリスト。
  • ## 現在の状態: プロジェクトの状況、実行中のプロセス、主要なファイルの状態。
  • ## 次のステップ: 残りのタスク、実装詳細、既知の課題の明確で優先順位付けられたリスト。
  • ## 参考情報: リンク、コードスニペット、パターン、ユーザー設定。
  • 実行可能な開始: 次の即座のアクションに対する明確な指示。

潜在的な使用例とワークフロー​

new_taskと.agents/contextの組み合わせの柔軟性により、多くの可能性が開かれます：

  • プロアクティブなコンテキストウィンドウ管理: 最適なパフォーマンスを維持するために、特定のパーセンテージ（例：50%、70%）またはトークン数でハンドオフを自動的にトリガー。
  • インテリジェントなブレークポイント: コンテキストしきい値を通過した_後に_、論理的な停止点（例：関数またはテストの完了後）を見つけるようClineに指示し、よりクリーンなハンドオフを確保。
  • 構造化されたタスク分解: プランモードを使用してサブタスクを定義し、.agents/contextを使用して各サブタスクの完了時にClineがnew_taskを介して自動的に新しいタスクを作成。
  • 自動化されたセッション要約: 以前のセッションの主要な議論点の要約を常に含むように<context>ブロックを設定。
  • ボイラープレート/セットアップの事前読み込み: 標準的なセットアップ指示またはファイルテンプレートで事前読み込みされた特定のプロジェクトに関連する新しいタスクを開始。
  • 「メモリバンク」の代替: セッション間で情報を永続化する主要な方法としてnew_taskコンテキストブロックを使用し、ファイルベースのメモリシステムを潜在的に置き換え。

あなたのニーズに最も適したワークフローを発見するために、.agents/contextでの実験をお勧めします！

.agents/contextの例：タスクハンドオフ戦略ガイド​

以下は、コンテキストウィンドウ管理のためにnew_taskの使用に特に焦点を当てた.agents/contextファイルの例です。これは1つの特定の戦略に過ぎないことを覚えておいてください。コアnew_taskツールは他のカスタムルールで異なる方法で使用できます。

# `new_task`ツールを使用する必要があります：タスクハンドオフ戦略ガイド

**⚠️ 重要な指示 - これらのガイドラインに従う必要があります ⚠️**

このガイドは、複雑なタスクを効果的に分解し、タスク間のスムーズなハンドオフプロセスを実装するための**必須**の指示を提供します。継続性、コンテキストの保存、効率的なタスク完了を確保するために、これらのガイドラインに**従う必要があります**。

## ⚠️ コンテキストウィンドウの監視 - 必須アクション ⚠️

環境詳細に表示されるコンテキストウィンドウの使用状況を**監視する必要があります**。使用量が利用可能なコンテキストウィンドウの50%を超えた場合、`new_task`ツールを使用してタスクハンドオフを**開始する必要があります**。

200Kコンテキストウィンドウで50%を超えるコンテキストウィンドウ使用量の例：

\`\`\`text

# コンテキストウィンドウ使用量

105,000 / 200,000 トークン (53%)
モデル: anthropic/claude-sonnet-4 (200Kコンテキストウィンドウ)
\`\`\`

**重要**：コンテキストウィンドウ使用量が50%以上になった場合、以下を**実行する必要があります**：

1. 現在の論理的ステップを完了する
2. `ask_followup_question`ツールを使用して新しいタスクの作成を提案する
3. 承認された場合、包括的なハンドオフ指示を含む`new_task`ツールを使用する

## プランモードでのタスク分解 - 必須プロセス

プランモードは、複雑なタスクを分析し、管理可能なサブタスクに分解するために特別に設計されています。プランモードでは、以下を**実行する必要があります**：

### 1. 初期タスク分析 - 必須

-   **必須**：ユーザーのリクエストの全範囲を徹底的に理解することから始める
-   **必須**：タスクのすべての主要コンポーネントと依存関係を特定する
-   **必須**：潜在的な課題、エッジケース、前提条件を考慮する

### 2. 戦略的タスク分解 - 必須

-   **必須**：全体的なタスクを論理的で個別のサブタスクに分解する
-   **必須**：依存関係に基づいてサブタスクに優先順位を付ける（最初に完了する必要があるもの）
-   **必須**：単一セッション内（15〜30分の作業）で完了できるサブタスクを目指す
-   **必須**：コンテキスト切り替えが意味を持つ自然な分岐点を考慮する

### 3. タスクロードマップの作成 - 必須

-   **必須**：ユーザーに明確で番号付きのサブタスクリストを提示する
-   **必須**：サブタスク間の依存関係を説明する
-   **必須**：可能な場合、各サブタスクの時間見積もりを提供する
-   **必須**：役立つ場合は、Mermaid図を使用してタスクフローと依存関係を視覚化する

\`\`\`mermaid
graph TD
A[メインタスク] --> B[サブタスク1: セットアップ]
A --> C[サブタスク2: コア実装]
A --> D[サブタスク3: テスト]
A --> E[サブタスク4: ドキュメント]
B --> C
C --> D
\`\`\`

### 4. ユーザー承認の取得 - 必須

-   **必須**：提案されたタスク分解についてユーザーのフィードバックを求める
-   **必須**：ユーザーの優先順位または追加要件に基づいて計画を調整する
-   **必須**：どのサブタスクから始めるかを確認する
-   **必須**：実装の準備ができたらアクトモードに切り替えるようユーザーに依頼する

## タスク実装とハンドオフプロセス - 必須手順

アクトモードでタスクを実装する際は、効果的なタスクハンドオフのために以下のガイドラインに**従う必要があります**：

### 1. 集中的な実装 - 必須

-   **必須**：現在のサブタスクを完全に完了することに集中する
-   **必須**：コメントとコミットメッセージを通じて進捗を明確に文書化する
-   **必須**：論理的な完了ポイントでチェックポイントを作成する

### 2. 完了ポイントの認識 - 重要

以下の場合、自然なハンドオフポイントを**特定する必要があります**：

-   現在のサブタスクが完全に完了した
-   より大きなサブタスク内で論理的な停止ポイントに達した
-   実装が予想よりも長くかかっており、後で続行できる
-   タスクスコープが元の計画を超えて拡大した
-   **重要**：コンテキストウィンドウ使用量が50%を超えた（例：200Kコンテキストウィンドウで100,000+トークン）

### 3. ハンドオフプロセスの開始 - 必須アクション

完了ポイントに達したら、以下を**実行する必要があります**：

1. これまでに達成されたことを要約する
2. 残りの作業を明確に述べる
3. **必須**：`ask_followup_question`ツールを使用して新しいタスクの作成を提案する：

\`\`\`xml
<ask_followup_question>
<question>[特定の成果]を完了しました。[残りの作業]を続行するために新しいタスクを作成しますか？</question>
<options>["はい、新しいタスクを作成", "いいえ、このセッションを続行", "考えさせてください"]</options>
</ask_followup_question>
\`\`\`

### 4. コンテキスト付き新しいタスクの作成 - 必須アクション

ユーザーが新しいタスクの作成に同意した場合、包括的なハンドオフ指示を含む`new_task`ツールを**使用する必要があります**：

\`\`\`xml
<new_task>
<context>

# タスク継続：[簡潔なタスクタイトル]

## 完了した作業

-   [完了した項目の詳細なリスト]
-   [変更/作成された特定のファイルを含める]
-   [行われた重要な決定を記録]

## 現在の状態

-   [プロジェクトの現在の状態の説明]
-   [実行中のプロセスまたは環境セットアップ]
-   [主要なファイルとその現在の状態]

## 次のステップ

-   [残りのタスクの詳細なリスト]
-   [対処すべき特定の実装詳細]
-   [認識すべき既知の課題]

## 参考情報

-   [関連ドキュメントへのリンク]
-   [従うべき重要なコードスニペットまたはパターン]
-   [現在のセッション中に記録されたユーザー設定]

[特定の次のアクション]によって実装を続行してください。
</context>
</new_task>
\`\`\`

### 5. 詳細なコンテキスト転送 - 必須コンポーネント

新しいタスクを作成する際は、常に以下を**含める必要があります**：

#### プロジェクトコンテキスト - 必須

-   **必須**：プロジェクトの全体的な目標と目的を含める
-   **必須**：主要なアーキテクチャの決定とパターンを含める
-   **必須**：技術スタックと依存関係を含める

#### 実装詳細 - 必須

-   **必須**：現在のセッションで作成または変更されたファイルをリストする
-   **必須**：実装された特定の関数、クラス、またはコンポーネントを説明する
-   **必須**：従っているデザインパターンを説明する
-   **必須**：テストアプローチの概要を示す

#### 進捗追跡 - 必須

-   **必須**：完了した項目のチェックリストを提供する
-   **必須**：残りの項目のチェックリストを提供する
-   **必須**：遭遇したブロッカーまたは課題を記録する

#### ユーザー設定 - 必須

-   **必須**：ユーザーが言及したコーディングスタイルの設定を記録する
-   **必須**：ユーザーが要求した特定のアプローチを文書化する
-   **必須**：ユーザーが特定した優先領域を強調する

## 効果的なハンドオフのベストプラクティス - 必須ガイドライン

### 1. 継続性の維持 - 必須

-   **必須**：タスク間で一貫した用語を使用する
-   **必須**：以前の決定とその根拠を参照する
-   **必須**：明示的に方向を変更しない限り、同じアーキテクチャアプローチを維持する

### 2. コンテキストの保存 - 必須

-   **必須**：ハンドオフに関連するコードスニペットを含める
-   **必須**：前のセッションの主要な議論を要約する
-   **必須**：該当する場合、特定のファイルと行番号を参照する

### 3. 明確な次のアクションの設定 - 必須

-   **必須**：明確で実行可能な次のステップでハンドオフを開始する
-   **必須**：残りのタスクに優先順位を付ける
-   **必須**：行う必要がある決定を強調する

### 4. 仮定の文書化 - 必須

-   **必須**：実装中に行われた仮定を明確に述べる
-   **必須**：ユーザー入力が必要になる可能性がある領域を記録する
-   **必須**：潜在的な代替アプローチを特定する

### 5. 再開可能性の最適化 - 必須

-   **必須**：次のセッションがすぐに作業を開始できるようにハンドオフを構造化する
-   **必須**：環境設定が必要な場合はセットアップ指示を含める
-   **必須**：迅速なコンテキスト復元のために上部に簡単な要約を提供する

## タスクハンドオフの例

### 例 #1 効果的なタスクハンドオフ：

\`\`\`xml
<new_task>
<context>

# タスク継続：ユーザー認証システムの実装

## 完了した作業

-   基本的なExpress.jsサーバー構造を作成
-   MongoDBconnectionとユーザースキーマを実装
-   パスワードハッシングを使用したユーザー登録エンドポイントを完成
-   Joiを使用した入力検証を追加
-   登録エンドポイントの初期テストスイートを作成

## 現在の状態

-   サーバーはポート3000で正常に実行中
-   MongoDB接続が確立されている
-   登録エンドポイント（/api/users/register）が完全に機能している
-   すべての登録シナリオでテストスイートが合格

## 次のステップ

1. ログインエンドポイント（/api/users/login）の実装
    - bcryptを使用してパスワードを比較
    - ログイン成功時にJWTトークンを生成
    - 無効な認証情報の適切なエラー処理を追加
2. 認証ミドルウェアの作成
    - JWTトークンの検証
    - ユーザー情報の抽出
    - 期限切れトークンの処理
3. 認証が必要な保護されたルートを追加
4. パスワードリセット機能の実装

## 参考情報

-   JWTシークレットは.envファイルに保存する必要があります
-   routes/users.jsの既存のエラー処理パターンに従ってください
-   ユーザースキーマはmodels/User.jsで定義されています
-   テストパターンはtests/auth.test.jsで確立されています

登録エンドポイントで確立された同じパターンに従って、ログインエンドポイントの実装を続行してください。
</context>
</new_task>
\`\`\`

### 例 #2 非効果的なタスクハンドオフ：

_（注：元のルールで提供された「YOLO MODE実装」を示す例は、直接的なハンドオフコンテキストブロックというよりは、将来の考慮事項を含む一般的なステータス更新のように見えます。真に非効果的なハンドオフは、「現在の状態」または「次のステップ」に詳細が欠けているかもしれません。）_

## タスクハンドオフを使用するタイミング - 必須トリガー

以下のシナリオでタスクハンドオフを**開始する必要があります**：

1. **重要**：コンテキストウィンドウ使用量が50%を超えた場合（例：200Kコンテキストウィンドウで100,000+トークン）
2. **長期実行プロジェクト**：単一セッションを超えるもの
3. **複雑な実装**：複数の明確なフェーズがあるもの
4. **コンテキストウィンドウ制限**：近づいている場合
5. **フォーカス領域の切り替え**：より大きなプロジェクト内
6. **異なる専門知識**：タスクの異なる部分に有益な場合

**⚠️ 最終リマインダー - 重要な指示 ⚠️**

環境詳細セクションのコンテキストウィンドウ使用量を**監視する必要があります**。50%を超えた場合（例：「105,000 / 200,000トークン（53%）」）、`ask_followup_question`ツールに続いて`new_task`ツールを使用してタスクハンドオフプロセスを**積極的に開始する必要があります**。`new_task`ツールを使用する**必要があります**。

これらのガイドラインに厳密に従うことで、タスク間のスムーズな移行を確保し、プロジェクトの勢いを維持し、複雑なマルチセッションプロジェクトに取り組むユーザーに最高の体験を提供できます。

```markdown
## ユーザー対話とワークフローの考慮事項

-   **リニアフロー**: 現在、`new_task`の使用はリニアシーケンスを作成します。古いタスクが終了し、新しいタスクが開始されます。古いタスク履歴はバックトラッキングのためにアクセス可能であり続けます。
-   **ユーザー承認**: いつでも制御でき、ハンドオフを承認し、Clineが引き継ぐことを提案するコンテキストを修正する機会があります。
-   **柔軟性**: コア`new_task`ツールは柔軟なビルディングブロックです。`.agents/context`で実験して、厳格なコンテキスト管理、タスク分解、またはその他の創造的な使用など、あなたのニーズに最適なワークフローを作成してください。
```