同一のIssue、Merge Request（MR）、Pull Request（PR）に対して、過去にコーディングエージェントが処理を行った際の最終要約を引き継ぎ、処理の継続性と効率性を向上させる機能を提供します。
本機能は、通常モードと計画実行モード（Planning Mode）の両方で動作します。
現在のコーディングエージェントは、タスクごとに新しいUUIDを生成し、独立したコンテキストで処理を開始します。しかし、同一のIssue/MR/PRに対して再度処理が発生した場合（例：追加のコメント対応、再処理の要求など）、過去の処理内容を把握していないため、非効率な処理が発生する可能性があります。
特に計画実行モードでは、過去の計画・実行履歴を参照することで、より効果的な計画立案と実行が可能になります。
- 処理の効率化: 過去の会話履歴や実行結果を参照することで、重複作業を削減
- 文脈の継続性: 過去の議論や決定事項を踏まえた一貫性のある応答
- 品質の向上: 過去の試行錯誤や学習内容を活用した処理品質の向上
- ユーザー体験の向上: 「以前話した内容」を理解しているエージェントとしての振る舞い
- 計画の継続性: 過去の計画と実行結果を参照した、より効果的な計画立案（Planning Mode）
同一のTaskKey（Issue/MR/PR）を持つ過去のコンテキストが存在する場合、以下の条件を満たせば引き継ぎを行います：
- ステータスが完了または停止: status="completed"またはstatus="stopped"であること
completed: タスクが正常に完了した場合stopped: ユーザーが明示的にタスクを停止した場合
- 有効期限内: 設定されたcontext_expiry_days以内であること（デフォルト: 90日）
以下のデータを引き継ぎ対象とします：
| データ | 説明 | 引き継ぎ方法 | 対象モード |
|---|---|---|---|
| 最終要約（summaries.jsonl） | 過去の会話の最終要約 | 初期コンテキストに組み込み | 通常/Planning |
| 計画履歴（planning/） | 過去の実行計画と結果 | 参考情報として提供 | 通常/Planning |
| メタデータ（metadata.json） | 過去の処理設定情報 | 参考情報として提供 | 通常/Planning |
| ツール実行履歴（tools.jsonl） | 過去のツール実行記録 | 参考情報として提供 | 通常/Planning |
| 検証結果（verification） | 過去の検証フェーズ結果 | 参考情報として提供 | Planning |
| リフレクション履歴（reflection） | 過去の振り返り結果 | 参考情報として提供 | Planning |
| 再計画判断（replan_decision） | 過去の再計画判断 | 参考情報として提供 | Planning |
前提条件: 本機能では、タスク完了時に必ず最終要約を生成・保存します。引き継ぎは最終要約が存在することを前提とします。
注意:
- 現在のコンテキスト（current.jsonl）および全メッセージ履歴（messages.jsonl）は、トークン制限の観点から直接引き継ぎません。代わりに最終要約を使用します。
- 「参考情報として提供」はLLMが必要に応じて参照可能という意味で、初期コンテキストには最終要約のみが含まれます。
以下の条件に該当する場合、コンテキストを引き継ぎません：
- 失敗したタスク: status="failed"のコンテキストは引き継ぎ対象外
- 一時停止中のタスク: status="paused"のコンテキストは引き継ぎ対象外（別途リジューム機能を使用）
- 有効期限切れ: context_expiry_daysを超えた古いコンテキスト
| ステータス | 説明 | 引き継ぎ | 最終要約 |
|---|---|---|---|
| running | 実行中 | - | - |
| completed | 正常完了 | ○ | 作成 |
| stopped | ユーザーによる明示的な停止 | ○ | 作成 |
| failed | エラーによる失敗 | × | 作成 |
| paused | 一時停止（リジューム可能） | × | - |
flowchart TD
A[タスク処理開始] --> B[TaskKey生成]
B --> C[過去コンテキスト検索]
C --> D{過去コンテキスト存在?}
D -->|No| E[新規タスクとして処理]
D -->|Yes| F[過去コンテキスト読み込み]
F --> G[最終要約を初期コンテキストに設定]
G --> H[今回のユーザー依頼を追加]
H --> I[タスク処理実行]
E --> I
I --> J[処理完了]
J --> K[最終要約を生成・保存]
過去コンテキストの検索と引き継ぎを管理する新しいクラスを追加します。
classDiagram
class ContextInheritanceManager {
-base_dir: Path
-config: dict
+__init__(base_dir, config)
+find_previous_contexts(task_key): list[PreviousContext]
+get_inheritance_context(task_key): InheritanceContext | None
+create_initial_context(inheritance_context, user_request): list[Message]
}
class PreviousContext {
+uuid: str
+task_key: TaskKey
+status: str
+completed_at: datetime
+final_summary: str
+metadata: dict
}
class InheritanceContext {
+previous_context: PreviousContext
+final_summary: str
}
ContextInheritanceManager --> PreviousContext
ContextInheritanceManager --> InheritanceContext
- TaskKeyで検索: TaskKeyの各フィールド（task_source、owner、repo、task_type、task_id）を使用してtasksテーブルを検索
- フィルタリング: status="completed"またはstatus="stopped"のレコードのみを対象、かつ有効期限内
- ソート: completed_atの降順でソート（最新のものを優先）
- 選択: 最新の1件のみを使用
tasksテーブルの既存カラムを使用して検索します。以下はクエリの概念例です：
SELECT * FROM tasks
WHERE task_source = ?
AND owner = ?
AND repo = ?
AND task_type = ?
AND task_id = ?
AND status IN ('completed', 'stopped')
AND completed_at >= datetime('now', '-' || ? || ' days')
ORDER BY completed_at DESC
LIMIT 1- task_source: タスクソース（github/gitlab）
- owner: リポジトリオーナー
- repo: リポジトリ名
- task_type: タスクタイプ（issue/pull_request/merge_request）
- task_id: タスクID（Issue番号等）
- 最終要約の取得: 過去コンテキストのsummaries.jsonlから最終要約を取得
- 初期コンテキストの構築: 最終要約を最初のコンテキストとして設定
引き継ぎコンテキストのトークン数が設定値を超える場合、以下の優先順位で削減します：
- 古い要約を優先的に除外
- 詳細な計画履歴を概要に置き換え
- ツール実行履歴を省略
引き継ぎコンテキストは、コンテキストの最初に以下の順序で追加します：
- 前回の最終要約（assistantロールとして）
- 今回のユーザー依頼（userロールとして）
これにより、LLMは前回の処理内容を把握した上で、今回の要求に対応できます。
注意: 前回の最終要約はassistantロールで追加されますが、これは引き継ぎ情報であり現在の会話の応答ではありません。要約テキストには「前回の処理要約:」などのプレフィックスを付けて区別します。
[コンテキスト開始]
├── 前回の最終要約（assistant）
│ └── "前回の処理要約: " + 前回処理の要約テキスト
└── 今回のユーザー依頼（user）
└── Issue/MR/PRの内容 + 新規コメント
タスク完了時に、次回の引き継ぎのために必ず最終要約を生成・保存します：
- 現在のコンテキストから最終要約を生成
- summaries.jsonlに保存
- これにより、次回同一タスクが処理される際に引き継ぎが可能になる
context_inheritanceセクションで以下を設定します：
| 設定項目 | 型 | デフォルト値 | 説明 |
|---|---|---|---|
| enabled | boolean | true | 引き継ぎ機能の有効/無効 |
| max_inherited_tokens | integer | 8000 | 引き継ぎコンテキストの最大トークン数（注1） |
注1: max_inherited_tokensは、使用するLLMモデルのコンテキストウィンドウサイズに応じて調整することを推奨します。一般的なモデルでは、コンテキストウィンドウの5〜10%程度（例：128Kモデルで8000〜12800トークン）が適切です。
context_inheritance:
enabled: true
context_expiry_days: 90
max_inherited_tokens: 8000過去コンテキストを引き継いだ場合、処理開始時に以下の形式で通知コメントを追加します：
📋 **過去のコンテキストを引き継ぎました**
- 引き継ぎ元: #{過去のコンテキストUUID（短縮形）}
- 前回処理日時: {日時}
- 引き継ぎ内容: 最終要約
過去の処理内容を考慮して、現在の要求に対応します。
| エラー種別 | 対応 |
|---|---|
| ファイル破損 | 該当コンテキストをスキップし、新規タスクとして処理 |
| ディレクトリ不存在 | 新規タスクとして処理 |
| パース失敗 | ログ出力後、新規タスクとして処理 |
| エラー種別 | 対応 |
|---|---|
| トークン数超過 | 優先度に基づいて内容を削減 |
| 最終要約未生成 | 新規タスクとして処理（引き継ぎなし） |
| エラー種別 | 対応 |
|---|---|
| 接続失敗 | リトライ（最大3回）後、新規タスクとして処理 |
| クエリエラー | ログ出力後、新規タスクとして処理 |
- 過去コンテキストへのアクセスは、同一TaskKeyに対してのみ許可
- 異なるIssue/MR/PR間でのコンテキスト共有は行わない
- ユーザー情報は引き継ぎコンテキストから除外
- 有効期限を過ぎたコンテキストは自動的にクリーンアップ対象
- 機密情報を含む可能性のあるツール実行結果は、引き継ぎ時にサニタイズ
| ログレベル | 出力内容 |
|---|---|
| INFO | 引き継ぎコンテキストの検出・使用 |
| DEBUG | 検索クエリ、フィルタリング結果 |
| WARNING | 読み込みエラー、スキップしたコンテキスト |
| ERROR | データベースエラー、重大な処理失敗 |
計画実行モードでは、過去のコンテキストに加えて、計画・実行・検証・振り返りの履歴を引き継ぐことで、より効果的なタスク処理を実現します。
通常モードの引き継ぎデータに加え、以下のPlanning Mode専用データを引き継ぎます：
| データ種別 | ファイル/場所 | 説明 |
|---|---|---|
| 計画（plan） | planning/{uuid}.jsonl | 過去の実行計画 |
| 修正計画（revision） | planning/{uuid}.jsonl | 計画の修正履歴 |
| リフレクション（reflection） | planning/{uuid}.jsonl | 振り返り結果 |
| 検証結果（verification） | planning/{uuid}.jsonl | 検証フェーズの結果 |
| 再計画判断（replan_decision） | planning/{uuid}.jsonl | 再計画の判断履歴 |
flowchart TD
A[タスク処理開始<br/>Planning Mode] --> B[TaskKey生成]
B --> C[過去コンテキスト検索]
C --> D{過去コンテキスト存在?}
D -->|No| E[新規計画立案]
D -->|Yes| F[過去コンテキスト読み込み]
F --> G[最終要約を初期コンテキストに設定]
G --> H[今回のユーザー依頼を追加]
H --> I[過去の計画履歴読み込み]
I --> J{過去計画の活用判断}
J -->|参考のみ| K[過去計画を参考に新規計画立案]
J -->|継続可能| L[過去計画の継続/拡張]
K --> M[目標の理解フェーズ]
L --> M
E --> M
M --> N[タスク分解フェーズ]
N --> O[行動系列生成フェーズ]
O --> P[実行フェーズ]
P --> Q[検証フェーズ]
Q --> R[監視/修正フェーズ]
R --> S[タスク完了]
S --> T[最終要約・計画履歴保存]
過去のコンテキストはコンテキストの最初に含まれているため、LLMは自然に過去の処理内容を把握した上で目標を理解します。
過去の計画を参照して、以下を考慮したタスク分解を行います：
- 過去の成功パターン: 過去の計画で成功したアプローチを優先
- 過去の失敗パターン: 過去に失敗したアプローチを回避
- 依存関係の継承: 過去の計画で明らかになった依存関係を考慮
- 推定複雑度の調整: 過去の実行結果に基づいて複雑度を調整
過去の実行履歴を参照して、以下を考慮したアクション計画を生成します：
- 成功したツール使用パターンの継承
- 失敗したアクションの代替手段検討
- エラー回復戦略の強化
実行フェーズでは、各アクション実行前に以下の過去情報を参照可能とします：
- 同様のアクションの過去実行結果
- 関連するツールの過去使用状況
- 過去の実行で発生したエラーと対処法
リフレクションフェーズでは、過去の振り返り結果を参照して評価の精度を向上します：
- 過去の計画修正理由
- 過去の問題特定パターン
- 成功した修正アプローチ
過去の検証結果から、以下を継承します：
- 検出されたプレースホルダパターン
- 成功基準の達成判定基準
- 追加作業の特定パターン
検証結果は累積的に管理し、同一Issue/MR/PRに対する検証の一貫性を保ちます。
PlanningCoordinatorクラスに以下のメソッドを追加します：
| メソッド | 説明 |
|---|---|
_load_inherited_planning_context() |
過去の計画コンテキストを読み込み |
_build_initial_context_with_inheritance() |
引き継ぎ情報を含む初期コンテキストを構築 |
_evaluate_previous_plan_applicability() |
過去計画の適用可能性を評価 |
_merge_with_previous_learnings() |
過去の学習内容を現在の計画にマージ |
既存のPlanningHistoryStore.get_past_executions_for_issue()メソッドを活用して、同一Issue/MRの過去の計画履歴を取得します。
Planning Modeで引き継ぎが発生した場合、以下の構造で初期コンテキストを構築します：
[コンテキスト開始]
├── 前回の最終要約（assistant）
│ ├── 前回処理の要約テキスト
│ ├── Previous Plan Summary
│ │ └── Goal, Subtasks, Completion Status
│ ├── Execution History
│ │ └── Successful/Failed Actions, Key Failures
│ ├── Verification History
│ │ └── Verification Rounds, Issues Found/Resolved
│ └── Recommendations for Current Processing
└── 今回のユーザー依頼（user）
└── Issue/MR/PRの内容 + 新規コメント
context_inheritanceセクションに以下のPlanning Mode専用設定を追加します：
| 設定項目 | 型 | デフォルト値 | 説明 |
|---|---|---|---|
| planning.inherit_plans | boolean | true | 過去の計画を引き継ぐか |
| planning.inherit_verifications | boolean | true | 過去の検証結果を引き継ぐか |
| planning.inherit_reflections | boolean | true | 過去のリフレクションを引き継ぐか |
| planning.max_previous_plans | integer | 3 | 参照する過去計画の最大数 |
| planning.reuse_successful_patterns | boolean | true | 成功パターンを再利用するか |
context_inheritance:
enabled: true
context_expiry_days: 90
max_inherited_tokens: 8000
planning:
inherit_plans: true
inherit_verifications: true
inherit_reflections: true
max_previous_plans: 3
reuse_successful_patterns: true文書バージョン: 2.0
最終更新日: 2024-11-29
ステータス: 設計中