ループエンジニアリングに向けた課題

[mapserver2007]

ループエンジニアリング化に向けた課題整理

日付: 2026-07-06
ステータス: 調査メモ（設計判断の入力）
文脈: preCompact handoff migration プランの設計レビュー中に、将来のループエンジニアリング化を見据えた議論から抽出

---

前提：アーキテクチャ構成

[Layer 3] オーケストレーター（新規作成）
    ↓ スキル起動・結果収集・次タスク判断
[Layer 2] Agentic workflow（既存スキル群 + 設計）
    ↓ セッション内のタスク実行
[Layer 1] セッション管理機構（preCompact, handoff, CHECKPOINT, MemPalace）
    ↓ セッション境界の検知・状態保全
[基盤] plan.md（SoT）+ ファイルベースの状態管理

• 既存の harness engineering ベースの Agentic workflow を流用する
• 既存スキルをほぼそのまま使い、上位にオーケストレーターを新規作成する
• AskQuestion は Agent が推奨選択肢を自発的に選択（人間の判断を挟まない）
• セッション管理は kit の既存機構を拡張して対応する

評価結果サマリ

• 全体構成は妥当。致命的な設計不備はない
• Layer 1/2 は「ループで使えるプリミティブ」として十分機能する
• ボトルネックは Layer 3 の設計（オーケストレーター自身のライフサイクル管理、スキル間依存制御）
• 3 つの構造的ギャップと 1 つのプラットフォーム制約がある

---

Gap 1: 既存機構の「人間前提」interface の変換

現行の各機構は人間がループ内にいることを前提に設計されている。ループ化にあたり interface を変換する必要がある。

機構	現行の人間前提	ループ化の方針	要改修度
handoff	人間が Cmd+N で新規チャットを開く	Agent がしきい値検知時に自動で別 Agent を起動し、古い Agent を破棄	中
AskQuestion	人間が選択肢を選ぶ	Agent が推奨選択肢（Recommend）を自発的に選択。人間の判断は挟まない	低（スキル側の改修不要、オーケストレーターの指示で対応可能）
Yellow/Red	人間に「区切りを意識して」と伝える	Agent が別の Agent（SubAgent）を起動し、現在の Agent は破棄	中
Quality Gate	人間がコマンド結果を確認	AI 自動判定可能なゲートと人間判断必須のゲートを分離する	高（QG の分類体系の設計 + 既存ゲートの分類が必要）

評価: これらは interface の変更であり、基盤の再設計ではない。Layer 1 のプリミティブ（state file, handoff manifest, preCompact 検知）はそのまま使え、消費側の interface をオーケストレーターに向けて追加することで解決可能。

---

Gap 2: オーケストレーター自身のライフサイクル管理

最も深刻なギャップ。 オーケストレーターが Cursor セッション内で動く場合、オーケストレーター自体が LitM / compact に晒される。

問題の構造

Orchestrator A → Skill 1 起動 → 結果収集
              → Skill 2 起動 → 結果収集
              → ...
              → [Orchestrator A 自身が LitM に到達]
              → 劣化したオーケストレーターが次の判断を下す ← 致命的
              → 誰がオーケストレーターを再起動する？

kit 拡張で解決できる部分

kit の状態管理プリミティブはオーケストレーターのライフサイクルにそのまま使える。

kit の既存機構	オーケストレーターでの役割
plan.md（SoT）	オーケストレーターの進行状態・タスクグラフ・判断記録
handoff manifest	オーケストレーター交代時の揮発情報引き継ぎ
CHECKPOINT	オーケストレーターの定期的な状態外部化
preCompact	オーケストレーターのコンテキスト圧迫検知
session-bootstrap	新オーケストレーターへの状態注入

kit 拡張では解決できない部分（プラットフォーム制約）

Cursor の Task サブエージェントには Hook が適用されない。

Kit のセッション管理スタック:

[Hook 依存層]     preCompact / CHECKPOINT / Yellow/Red / session-bootstrap
                   → Cursor のチャットセッションでのみ機能
                   → Task tool のサブエージェントでは動かない

[Hook 非依存層]   plan.md / handoff manifest / state files
                   → ファイルベースなのでどこからでもアクセス可能

オーケストレーターの交代手段と制約:

手段	新コンテキスト	Hook 有効	人間不要
Task tool でサブエージェント起動	✓	✗	✓
ユーザーが Cmd+N で新規チャット	✓	✓	✗
Cursor SDK で外部から新セッション作成	✓	✓	✓

解決策の方向性

方式	LitM 耐性	実現コスト	既存基盤との親和性
A. ステートレスオーケストレーター — 毎イテレーション plan.md を re-read し、コンテキストに蓄積しない	高い	低い	高い
B. 自己 handoff — オーケストレーター自身に proxy/preCompact を適用し、Yellow で自己交代	中	中	高い
C. 外部オーケストレーター — SDK / スクリプトで Cursor の外から管理	最も高い	高い	低い

推奨: 初期は A（ステートレス）で始め、限界が見えたら C に移行する段階的アプローチ。

プロトコルモードの必要性

サブエージェントリレーで交代する場合、Hook が使えないため「プロトコルモード」が必要。

機構	Hook モード（チャットセッション）	プロトコルモード（サブエージェント）
CHECKPOINT	stop hook が自動発火	オーケストレーター指示書に「N 回ごとに plan.md 更新」と記載
Yellow/Red	stop hook が followup_message	オーケストレーター指示書に「N 回で自己交代」と記載
preCompact	preCompact hook が自動検知	検知不可 — proxy（イテレーション数）で代替
状態外部化	handoff manifest + plan.md	同左（ファイルベースなのでモード不問）

リスク: プロトコルモードは AI の自己規律に依存する。LitM が進行すると指示自体を忘れるリスクがある。これが Gap 2 の本質的な難しさ。

---

Gap 3: スキル間の依存関係とエラー伝播

問題

現行スキルは独立実行を前提としているが、ループでは依存関係が生じる。

Skill A の結果 → Skill B の入力 → Skill C の入力
                                      ↑
                              A が失敗した場合、B と C はどうなる？

必要な設計要素

• スキル間の依存グラフの定義
• エラー分類（リトライ可能 / 人間判断必要 / 致命的）
• 現行の plan.md には「スキル間の依存関係」という概念がない

評価: これは Layer 3（オーケストレーター）の責務として新規設計が必要。Layer 1/2 の変更ではない。

---

LitM に関する設計上の考慮事項

対話型 vs ループ型でコスト構造が逆転する

	対話型（現行の設計対象）	ループ型
false positive のコスト	高い — 人間の作業を中断	低い — ループが自動リスタートするだけ
false negative のコスト	中 — 人間が劣化に気づける	高い — 誰も気づかず劣化した作業が蓄積
最適な戦略	精度重視（不要な中断を減らす）	再現率重視（見逃しを減らす）

LitM 防御は現状ベストエフォート

現行 API 制約では、どの設計でも LitM 防止はベストエフォートになる。

設計	LitM 防止の性質
現行（proxy Yellow/Red）	ベストエフォート（早いが不正確）
preCompact + proxy fallback	ベストエフォート（正確だが遅い）
Phase 2（毎ターン token%）	準決定論的（Cursor API 拡張が前提）

ループ型では Prevention が重要

CHECKPOINT（Mitigation）だけでは不十分な理由:

1. 劣化が複利で蓄積 — 劣化した判断の上にさらに判断が積み重なる
2. CHECKPOINT 自体が劣化 — LitM 状態の AI が書く判断ログは品質不明
3. 自己検知のパラドックス — 劣化した AI は劣化指示を忘れる

結論: ループ型では proxy Yellow/Red を保険として残すべき。2 モード設計（interactive / loop）で切り替え可能にしておくのが安全側の判断。

---

段階的な実装戦略

Phase 1（現在）: Kit 基盤の品質向上

preCompact handoff migration プランの実装。

• preCompact 観測 + compact-events.jsonl（校正データ収集）
• pending-handoff マーカーパターン
• proxy fallback の維持（将来のループ設計で必要になる可能性が高い）
• CHECKPOINT の維持
• MemPalace 共存設計

成果物: 高品質なセッション管理基盤 + compact 発火パターンの実データ

Phase 2（将来）: ループエンジニアリング設計

Phase 1 の基盤と収集データを前提に設計。

• Layer 3 オーケストレーターの設計・実装
• Gap 1 の interface 変換
• Gap 2 のオーケストレーターライフサイクル（初期はステートレスオーケストレーター）
• Gap 3 のスキル間依存・エラー伝播
• Quality Gate のゲート区分改修
• 2 モード設計（interactive / loop）の導入
• プロトコルモード（Hook なし環境用）の設計

前提: Phase 1 の compact-events.jsonl のデータに基づくセッション境界戦略

Phase 3（Cursor API 拡張後）: 決定論的 Prevention

• stop / beforeSubmitPrompt に context_window フィールドが追加された場合
• 毎ターン token% 判定で LitM Prevention を決定論的に実行可能
• proxy を完全に fallback に降格

---

未解決の設計判断（Phase 2 着手時に決定）

1. オーケストレーターの実行位置（Cursor 内 vs SDK 外部）
2. プロトコルモードの信頼性（AI 自己規律の限界をどこで受容するか）
3. スキル間依存グラフの表現形式（plan.md 内 vs 別ファイル）
4. ループモードでの proxy 閾値の値（Phase 1 の compact-events データに基づいて決定）
5. Quality Gate のゲート区分の分類体系
6. AskQuestion の自動選択時に「推奨なし」の場合の振る舞い
7. エラー分類の粒度と各分類のリカバリ戦略

---

関連ドキュメント

ドキュメント	役割
.cursor/plans/precompact_handoff_migration.plan.md	Phase 1 の実装プラン
tmp/proposal-token-based-handoff.md	ADR 草案 + Phase 1/2 設計
tmp/claude-compact.md	compact 問題と対策の記事要約
docs/session-handoff-guide.md	現行 handoff 機構の使い方
AGENTS.md > Context Budget Protocol	現行のセッション管理方針