ループ・ゴール型 秘書システム適用パターン設計

結論サマリ

• daily-triage で実証済の「needs_review に保管 → 人判断 → resolved に記録 → 次回プロンプトに注入」の3段ループを、秘書配下の7システムへ横展開する設計。
• 共通モジュール（needs_review.json 標準形式 + resolve.sh CLI + past_decisions プロンプト注入）を1セット作れば、各システム側は薄いアダプタだけで済む。
• 即着手は orchestrator / FX週次 / AI情報digest の3本。コスト小・効果大・既存稼働中で学習燃料が即日溜まる。

1. ループ・ゴール型の最小定義

AIが「判断に迷ったもの」を捨てず保管し、人間の最終判断を蓄積として再利用することで、次回の同種判断を自動化していく仕組み。

3要素： 1. 曖昧度の自己申告（AIが「これは自信ない」と明示する） 2. 保管 → 人判断 → 記録（needs_review に積み、後で人が解決を書き戻す） 3. 次回プロンプトへの注入（過去解決事例を few-shot として食わせる）

daily-triage から抽出した本質は「判断を捨てない」こと。曖昧なものを「とりあえず分類した」「とりあえず除外した」で流すと改善燃料がゼロになる。

2. 共通アーキテクチャ

2.1 データフロー

[入力] → [AI処理] → [自信スコア/曖昧度]
                          │
              ┌───────────┴───────────┐
        高(>0.8)                   低(<=0.8)
              │                       │
        [自動完結]              [needs_review.json に保管]
                                      │
                              [Telegram通知 / 朝の一覧]
                                      │
                              [人がresolve.sh実行]
                                      │
                              [resolved に記録]
                                      │
                          [次回プロンプトに past_decisions として注入]

2.2 needs_review.json 標準形式

{
  "_updated_at": "2026-06-28",
  "_system": "<system_name>",
  "items": [
    {
      "id": "短いhash",
      "created_at": "2026-06-28 09:00:00",
      "context": "判断対象の生データ（短く）",
      "ai_guess": "AIの暫定判断",
      "confidence": 0.62,
      "reason": "なぜ自信がないか（1行）",
      "status": "pending|resolved|deferred",
      "resolution": null,
      "resolved_at": null,
      "resolver": "human|ai_auto"
    }
  ]
}

2.3 resolve.sh 標準形式

共通CLIを ~/.claude/scripts/loop_resolve.sh に置く想定。

loop_resolve.sh <system> <item_id> <resolution>
# 例:
loop_resolve.sh fx_weekly abc12345 "duplicate_of: 手法007"
loop_resolve.sh orchestrator def67890 "missing_field: 締切"
loop_resolve.sh ai_digest gh112233 "category: tool/image-gen"

resolution のプレフィックス（duplicate_of: / category: / alias_for: 等）で書き戻し先（aliases / categories / blacklist 等）を自動分岐させる。

2.4 past_decisions プロンプト注入

各システムのプロンプト先頭に以下を挟む：

## 過去の人間判断（最新N件）
- "<context>" → "<resolution>"
- "<context>" → "<resolution>"
（同種を見たら同じ判断をしてください）

resolved の上位N件（システムごとに5〜20件）を自動抽出するヘルパー loop_past_decisions.sh <system> <N> を共通モジュール側で提供。

3. 各システムへの適用案

3.1 orchestrator

• needs_review挿入箇所: Telegram依頼の要件確認フェーズ。AIが「7W2H+α」で不足を埋めようとするが、ユーザー回答が曖昧／矛盾／省略されたまま実行に入ったケース。
• 人判断対象: 「この依頼の Whom / When / 完成イメージ が読めなかった」を後でしずやさんが補う。
• 次回反映: 「過去の似た依頼ではこういう前提を補った」を few-shot 注入。同じ言い回しの依頼が来たら自動で前提補完。
• インパクト: 精度向上（ヒアリング漏れ削減）＋工数削減（再ヒアリング往復減）両方。
• コスト: S（既存orchestrator.shに保管フック1つ追加するだけ）

3.2 FX週次情報収集

• needs_review挿入箇所: 5並列調査エージェントの戻りを仕上げエージェントが束ねる段。「重複っぽいが微妙に違う」「ジャンル分類が境界線」のもの。
• 人判断対象: 重複判定 / ジャンル決定 / 採否（30件枠の取捨選択）。
• 次回反映: duplicate_of: を蓄積 → 来週の重複検出ヒント。category: を蓄積 → 来週の自動分類精度UP。
• インパクト: 工数削減大（しずやさんの目視チェック時間が半減見込み）。
• コスト: M（仕上げエージェントのプロンプト＋出力JSON設計に手を入れる必要）

3.3 NewsPicks-design

• needs_review挿入箇所: 5軸抽出時の「新規性が低そう／既出パターンと類似」判定。
• 人判断対象: 「これは新規ナレッジとして残す／既出に統合する／捨てる」の3択。
• 次回反映: 「既出パターンの特徴量」を蓄積 → 重複抽出の自動カット精度UP。
• インパクト: 蓄積の質改善（ノイズ削減）。即効性は小だが長期的に効く。
• コスト: S

3.4 fx-ea-builder

• needs_review挿入箇所: 30件の手法txtからEA化する際の「ロジック解釈が複数ありえる」「パラメータ範囲が曖昧」ケース。
• 人判断対象: ロジック解釈の確定（例: 「ブレイクアウトの定義は直近20本高値で良いか」）。
• 次回反映: interpretation: を蓄積 → 似たロジック表現が来たら自動採用。
• インパクト: 精度向上（EA挙動の安定）。ただし手法ごとに固有性が高くfew-shot効きにくい面あり。
• コスト: M

3.5 AI情報digest

• needs_review挿入箇所: 重要候補抽出時の「これBOSS文脈で価値あるか不明」判定。
• 人判断対象: 採否 + カテゴリ（MS番号紐付け / 横断ナレッジ / 捨て）。
• 次回反映: relevance: と ms_link: 蓄積 → 翌日以降の自動振り分け精度UP。
• インパクト: 工数削減（しずやさんの朝の選別時間が短縮）＋精度向上両方。
• コスト: S

3.6 mail-writer

• needs_review挿入箇所: トーン・刺激ワード選択の境界判定（「この案件でこの表現を使っていいか」「PSで機能↔感情のどちらに振るか」）。
• 人判断対象: 表現採否、トーン方向の最終決定。
• 次回反映: 案件別の「OK表現 / NG表現」蓄積 → 案件固有プリセットが自動進化。
• インパクト: 精度向上（しずやさんの「直し」工数が減る）。
• コスト: M（案件別ストレージ設計が必要）

3.7 allbloom-sales-deck

• needs_review挿入箇所: 各社個別最適化Webリサーチで「この事実をスライドに載せて良いか（裏取り済か）」判定。
• 人判断対象: 事実の採否、表現の柔らかさ調整。
• 次回反映: 業種別の「使ってOKな訴求軸」が蓄積 → 同業種への提案時に自動採用。
• インパクト: 精度向上＋ブランド毀損リスク低下。
• コスト: M

4. 優先順位マトリクス

5. 共通モジュール化

~/.claude/scripts/loop/ 配下に集約する想定。

共通化することで、各システム側は 「保管時に loop_save、プロンプト先頭に loop_past_decisions の出力を差し込む」 の2行追加だけで済むようになる。

6. メトリクス

各システムについて週次で計測：

集計は週次 launchd で loop_metrics.py → Obsidian の週次レビューに自動追記する想定。

7. 次アクション3つ

1. 共通モジュール v0.1 雛形作成：~/.claude/scripts/loop/ に loop_save.py / loop_resolve.sh / loop_past_decisions.sh の3本を実装。schema.json も同時定義。所要1日。
2. orchestrator に最小組込：要件確認フェーズの曖昧検出箇所に loop_save を1行差し込む。past_decisions 注入も同時。1週間運用して needs_review率と解決時間を計測。所要0.5日 + 観測1週間。
3. FX週次への組込設計レビュー：仕上げエージェントのプロンプト＋出力JSONを書き換える設計レビューを秘書側でドラフト化し、しずやさん承認を取ってから来週の金曜走行に間に合わせる。所要0.5日 + 承認待ち。

（設計者: 秘書 / 2026-06-28 / 次回見直し: Phase1完了時）