koba · 稼働ログ

ループ・ゴール型 設計の組込みロードマップ叩き台

📚 ナレッジ · 2026-06-25_ループゴール型ロードマップ叩き台
← 戻る

ループ・ゴール型 設計の組込みロードマップ叩き台

作成日: 2026-06-25 作成者: 秘書（しずやさん専属AI秘書） 案件: BOSS / AI Visionaries タグ: #boss #ナレッジ #wip

30秒サマリ（Naka森MTG提示用）

1. 経緯

1.1 Naka森さんからの提案（2026-06-24 08:16）

1.2 既存の実証ケース（2026-06-24完成）

daily-triage に auto_resolve 機構 を実装済みです。新キーワード検出 → 自動解決判定 → needs_review.json 更新 → Telegram通知という流れで、人間が見るまでもない案件をAIが自分でクローズしていく仕組みが既に動いています。これが今回のロードマップの最小実証ケースになります。

2. 「ループ・ゴール型」技術トレンドサマリ（2025-2026）

WebSearchで確認した最新動向は以下です。

パターン 概要 強み 弱み
ReAct Reason + Act を交互に回す基本ループ。LangChain/LangGraph標準 実装容易・信頼性高 単純タスクではオーバーヘッド
Reflexion 実行結果を自己評価して次回に活かす 改善学習が組み込める 評価関数の設計が肝
Tree of Thoughts (ToT) 複数の思考ブランチを探索 数学・推論タスクで圧倒的 トークン10〜100倍コスト
AutoGPT系（後継） 完全自律ループ 完全自走 無限ループ・コスト暴走で大半が頓挫
LangGraph グラフ構造でループ・分岐を明示設計 本番運用に耐える 学習コストあり
Loop Engineering (2026) 終了条件・予算・スコアリングを設計の中心に据える新潮流 暴走しない 設計者の腕が試される
Self-Healing Agent 失敗を自己診断して次回挙動を更新 UI変更等に強い 評価ループ必須

2026年の業界コンセンサス: 「ループは作れる」フェーズは終わり、「ループをいかに暴走させず、終了条件とゴール評価関数を設計するか」（Loop Engineering） が論点です。AutoGPTが廃れた理由（無限ループ・APIコスト暴走）の反省を踏まえ、LangGraphベースの「明示的グラフ＋自己評価＋終了条件」が主流になっています。

3. daily-triage auto_resolve の構造分解（実証ケース言語化）

6/24に完成した auto_resolve を「ループ・ゴール型」の言語で再記述します。

3.1 構造

[Telegram投稿] 
   ↓ 
[Haiku仕分け] ─→ 新キーワード検出 ─→ needs_review.json
   ↓                                       ↓
[公開]                              [auto_resolve.sh 起動]
                                           ↓
                                  [自動解決判定ループ]
                                           ↓
                          ┌────────┴────────┐
                          ↓                 ↓
                  [解決可能] → クローズ  [要確認] → Telegram通知

3.2 ループ・ゴール型の構成要素対応

構成要素 対応箇所
ゴール 「needs_review.json の pending を 0 に近づける」
ループ 新着検出 → 自動解決判定 → 結果書き戻し
自己評価 「このキーワードは過去に同種があるか／単独で判定可能か」
終了条件 解決可能なものは閉じる／不明なら人間にエスカレ
改善メカニズム 解決履歴が次回の判定材料になる（暗黙の学習）

3.3 何が「自己改善」なのか

→ Loop Engineering の良いお手本になっています。

4. 既存秘書システムへの適用候補マッピング

システム ループゴール型 組込み案 優先度 想定効果
daily-triage 既に実装済（auto_resolve）。次は「分類精度のA/B自動改善ループ」 中 仕分け精度の継続改善
fx情報収集 30件収集 → 重複検出 → 不足ジャンル自動補填ループ → 質スコアでフィルタ 高 重複削減・カバレッジ最適化
秘書orchestrator 要件確認 → 不足検出 → 追加ヒアリング自動生成ループ 中 ヒアリング漏れ削減
daily_ai_digest 13ソース収集 → 重複統合 → 重要度スコアで上位N選定ループ 中 ノイズ削減
NewsPicks-design 巡回 抽出 → 既存ナレッジと比較 → 新規性スコアで採否ループ 低 蓄積の質改善
sns_weekly_digest Bookmarks/Favorites収集 → カテゴリ自動分類 → 自分の関心軸との適合度評価ループ 中 週次レビューの自動化

横断パターン: どれも「収集 → 評価 → 改善 → 再収集」の4サイクル構造になります。共通フレームを1つ作れば横展開が早いです。

5. MS15 営業自動化（河端案）への先行組込み設計

MS15は未着手のため、最初からループ・ゴール型で設計できる絶好の対象です。

5.1 基本フロー（既存案）

地域別営業リスト → HPなし企業抽出 → 自動DM → 新規HP案＋紹介動画

5.2 ループ・ゴール型を組み込んだ拡張設計

[ゴール定義]
  目標: 月間100件のアポイント獲得（または反応率5%以上）

[Outer Loop: 営業対象選定ループ]
  地域リスト → HPなし企業抽出 → 優先度スコアリング → 上位N抽出
            ↑                                              ↓
            └── 反応データを優先度モデルに反映 ──────────┘

[Inner Loop: DM文面改善ループ]
  企業情報入力 → DM文面生成 → 配信 → 反応計測（開封/返信/拒否）
       ↑                                            ↓
       └── 反応スコアで文面パターンを自己評価・更新 ┘

[終了条件 / 暴走防止]
  - 1日の送信上限（例: 50件）
  - 月間予算上限（API+配信コスト）
  - 反応率が閾値を下回ったら一時停止＋人間レビュー

[自己改善メカニズム]
  - DM文面の勝ちパターン蓄積（業種別・地域別）
  - 反応した企業の特徴抽出 → 次回優先度モデルに反映
  - 紹介動画のクリック率 → 動画パターンの自動切替

5.3 なぜMS15に先行組込みすべきか

6. 段階導入ロードマップ

Phase 1: 既存システム1つに先行組込（所要2週間）

Phase 2: 横展開3件＋MS15先行設計（所要1ヶ月）

Phase 3: MCP化・サービス化（所要2〜3ヶ月）

7. Naka森MTG提示用 1枚絵（テキスト版）

┌─────────────────────────────────────────────────────────┐
│  ループ・ゴール型 BOSS秘書システム 組込みロードマップ    │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  【業界トレンド】                                       │
│   ReAct / Reflexion / LangGraph / Loop Engineering      │
│   → 「ループ＋ゴール評価＋終了条件」が2026主流         │
│                                                         │
│  【既存資産】                                           │
│   ✅ daily-triage auto_resolve（6/24完成・実証済）      │
│                                                         │
│  【ロードマップ】                                       │
│                                                         │
│   Phase 1 (2週間)                                       │
│   └ fx情報収集に先行組込＋共通フレーム雛形             │
│                                                         │
│   Phase 2 (1ヶ月)                                       │
│   └ 3システム横展開＋MS15 PoC                           │
│                                                         │
│   Phase 3 (2〜3ヶ月)                                    │
│   └ MCP化＋MS15本番＋サービスパッケージ化               │
│                                                         │
│  【最優先】                                             │
│   MS15 営業自動化に最初からループ・ゴール型を組込み    │
│   → BOSS発の差別化資産化                                │
│                                                         │
└─────────────────────────────────────────────────────────┘

後ほどPPTX化する場合は、上記をスライド3枚（トレンド／実証ケース／ロードマップ）に分解すれば十分です。

8. 結論：次の一歩は何か

  1. Naka森MTGで本ドキュメントを提示し、方向性の合意を取る
  2. Phase 1（fx情報収集への先行組込） を秘書側で着手し、共通ループフレームの雛形を作る
  3. MS15 設計書ドラフトを並行で作成し、河端さんとの認識合わせに使う
  4. Phase 1 完了時点で 「ループフレーム v0.1」を Notion / Obsidian に蓄積 し、Phase 2 の横展開を高速化する

秘書から見た最優先導入候補（明示）

最優先: MS15 営業自動化への先行組込み

理由は3つです。 - 未着手なのでレガシー負債ゼロで設計できる - 「反応率」という明確なゴール関数が立てやすい - BOSSの差別化資産・営業パッケージ化につながる

次点で Phase 1の fx情報収集 を選んだのは、既存稼働している分リスクが低く、共通ループ・フレームの試作場として最適だからです。MS15本番投入前に、フレームを fx情報収集で叩いて完成度を上げる二段構えがおすすめです。

参考資料（WebSearch 2026-06-25）