組織再設計の一環。M層のセッション管理方式の比較分析 + プロジェクトフロー全体のスイムレーン図を再設計する
Section 1
--resume でセッション履歴を引き継げる。ゼロからにはならない| 観点 | 常駐 | 都度起動 + resume | ハイブリッド（推奨） |
|---|---|---|---|
| 起動コスト | 初回のみ | 毎回 数秒〜十数秒 | 引き継ぎ時のみ（1日1〜2回） |
| メモリ消費 | 常時（×6ディビジョン） | タスク実行時のみ | 稼働時間中のみ |
| トークン消費 | アクティブ時のみ （アイドル時は消費なし） |
同左 + resume時の履歴読み込み | 同左（引き継ぎ時にresume分の上乗せ） |
| 実装コスト | 中（stdin pipe管理） | 低（現行の延長） | 中（引き継ぎオーケストレーション） |
| 障害復旧コスト | 高（セッション再構築） | 低（タスク単位で再実行） | 中（直近の引き継ぎ点から復旧） |
Section 2
--input-format stream-json で1プロセスを維持し続ける。即応性は最高だが、stdinパイプ管理が複雑で障害耐性が低い。6プロセス常駐はリソース負荷が大きい。
claude -p --resume <id> で起動。現行アーキテクチャの自然な延長。障害耐性が高い反面、毎回の起動レイテンシが発生する。
@anthropic-ai/claude-agent-sdk でプログラム的に制御。Max Planでは使用不可（APIキー認証が必須）。API課金に移行した場合の将来候補。
| 観点 | A. 完全常駐 | B. 完全都度起動 | C. ハイブリッド | D. SDK |
|---|---|---|---|---|
| レイテンシ | 即座 | 数秒〜十数秒 | 稼働中は即座 | 即座 |
| 文脈保持 | 自然蓄積 | resume依存 | 蓄積 + 引き継ぎ | SDK管理 |
| 障害耐性 | 低い | 高い | 中（引き継ぎ点あり） | 高い |
| 実装コスト | 中 | 低い | 中 | 非常に高い |
| Max Plan対応 | 可 | 可 | 可 | 不可 |
--resume で復旧可能Section 3
引き継ぎ後、新プロセスが --resume で起動 → ライフサイクルの先頭に戻る
| 仕組み | 保持されるもの | 失われるもの | 対策 |
|---|---|---|---|
| コンパクション （自動） |
CLAUDE.md（ディスクから再読み込み） 会話の要旨（サマリー） 直近のやり取り |
古いツール出力の詳細 途中の判断過程の一部 |
重要な判断はCLAUDE.mdまたはメモリファイルに書き出す。 SDKの PreCompact フックで状態退避する（将来） |
| セッション引き継ぎ （定期） |
--resume でセッション全体を復元 |
起動時にレイテンシが発生 ツール権限が再承認必要 |
引き継ぎ頻度を最小限に（12時間 or アイドル2時間）。--allowedTools で権限を事前付与 |
| CLAUDE.md （永続） |
組織ルール・ワークフロー・設計方針の全量 | なし（ディスク上に常に存在） | 重要な設計判断・メモリはCLAUDE.mdに集約。コンパクション後もルールが消えない |
| トリガー | 条件 | 理由 |
|---|---|---|
| 時間経過 | 起動から12時間 | コンパクション蓄積による品質劣化の予防 |
| コンパクション回数 | 自動コンパクション N回目 （初期値: 5回。運用で調整） | 要約の要約の繰り返しを制限 |
| アイドル時間 | 2時間以上タスクなし | リソース解放。次タスク時に新プロセスで起動 |
| エラー検知 | 異常応答・タイムアウト | セッション劣化の兆候として新プロセスに切り替え |
Section 4
| 項目 | 設計 |
|---|---|
| 保存先 | data/m_sessions.json（bot.py再起動でも保持） |
| 構造 | ディビジョン名 → セッションID のマッピング |
| 更新タイミング | M層プロセス起動時にセッションIDを記録。引き継ぎ時に新IDで上書き |
| cwd固定 | --resume はcwd不一致で失敗する。各M層のcwdを固定（例: agents/managers/vdu/） |
| フェーズ | 内容 | 変更箇所 |
|---|---|---|
| Phase 0 現状維持+resume |
都度起動（subprocess）のまま、--resume でセッション引き継ぎを追加 |
bot/claude_runner.py にセッションID管理を追加 |
| Phase 1 常駐化 |
M層を --input-format stream-json で常駐化。stdin経由でタスク投入 |
bot/claude_runner.py の起動・通信ロジック。プロセス監視追加 |
| Phase 2 引き継ぎ |
定期引き継ぎロジック追加。12時間/アイドル2時間でリフレッシュ | セッション保存→新プロセス起動→resumeのオーケストレーション |
| 将来 SDK移行 |
API課金に移行した場合、Claude Code SDK (TS) に置き換え | bot.py → TypeScript化（または別サービス） |
Section 5
| トリガー種別 | 起動条件 | 対象M層 | bot.pyの動き |
|---|---|---|---|
| SlackCEOからの指示 | Slackメッセージ受信 | IF層が判断して適切なM層にルーティング | Slackイベント → IF層起動 → IF層がM層を指名 → bot.pyがM層を起動（or stdin投入） |
| 定時日次経営会議 | 毎日定時（例: 9:00） | 全M層（VDU, BA, H&A, PMO, OA, SA） | cron/scheduler → bot.pyが全M層にアジェンダを投入。各M層が担当領域の報告を準備。IF層が取りまとめ |
| 定時時間トリガー | 月末/月初/特定日 | 該当M層（例: BA=月末経費締め、PMO=週次棚卸） | cron/scheduler → bot.pyが対象M層を起動 |
| イベント外部イベント | GitHub Issue作成、PRマージ、エラー検知等 | 該当M層（Issue→PMO, PR→OA, エラー→SA） | Webhook/ポーリング → bot.pyがイベントを検知 → 対象M層を起動 |
| 連携M層間連携 (REROUTE) | あるM層の完了が別M層を起動 | 起動元M層が指名（例: VDU完了→OA監査） | M層が STATUS: REROUTE を返却 → bot.pyが指名先M層を起動 |
| 継続自律ループ (CONTINUE) | M層が自身の次タスクを宣言 | 宣言したM層自身 | M層が STATUS: CONTINUE を返却 → bot.pyが同M層に次タスクを投入 |
| ステップ | 実行者 | 内容 |
|---|---|---|
| 1 招集 | bot.py (cron) | 定時に全M層へアジェンダを配信 |
| 2 報告準備 | 各M層 | 担当領域の実績・課題・提案を整理 |
| 3 集約 | IF層 | 全M層の報告を受領し、CEO向けサマリーを作成 |
| 4 CEO確認 | CEO | 報告を確認。優先順位・リソース配分を決定 |
| 5 指示反映 | IF層 → 各M層 | CEOの決定を各M層に伝達。タスク着手 |
Swimlane
CEOがSlackで指示 → IF層がルーティング → M層がフェーズ分解・W層実行 → レビュー → IF層が結果整形 → CEO確認。
全M層共通のフロー。VDU/BA/H&A/PMO/OA/SAのいずれにも当てはまる。
STATUS判定: DONE（完了報告）/ CONTINUE（次フェーズ実行）/ REROUTE（他Div連携）/ APPROVAL_NEEDED（CEO承認待ち）/ CONSULT（CEOに相談）
Swimlane
毎日定時にbot.pyが全M層を招集。各M層が報告を準備 → IF層が集約 → CEOに報告 → 決定を反映。
特定のM層だけの仕組みではなく、全ディビジョンに共通のプロセス。
※ 全6ディビジョンが同一フローで参加する。M層レーンは全Divを代表。
※ CEO不在時はIF層がサマリーをSlackに投稿し、CEOは後で非同期確認。
Swimlane
M層がタスク完了後に自らSTATUS: CONTINUEを返却し、次のタスクに連続着手するフロー。
CEO不在時でも自律的に進行。APPROVAL_NEEDEDな操作はCEO待ちで一時停止。
※ CONTINUEループはbot.pyが仲介する。M層のSTATUS:CONTINUEを受けてbot.pyが同M層に次タスクを投入。
※ APPROVAL_NEEDED（コスト発生・外部送信・破壊的操作）はCEO承認まで一時停止。CEOは非同期で確認可能。
Swimlane
あるM層の完了が別のM層を起動するフロー。例: VDU実装完了 → OA品質監査、SA異常検知 → VDU修正。
M層がSTATUS: REROUTEを返却し、bot.pyが指名先のM層を起動する。
※ REROUTE先のM層B内部は通常の実行フロー（フェーズ分解→W層→レビュー）と同じ。
※ 典型例: VDU→OA（品質監査）、SA→VDU（異常修正）、VDU→BA（コスト見積）
| 起動元 | 連携先 | トリガー条件 |
|---|---|---|
| VDU（実装完了） | OA（品質監査） | mainブランチへのPRマージ後 |
| SA（異常検知） | VDU（修正実装） | セキュリティ脆弱性・障害検知時 |
| VDU（新機能設計） | BA（コスト見積） | 外部API利用・インフラ増設が必要な場合 |
| BA（契約レビュー完了） | VDU（実装着手） | 外部サービス契約締結後の統合実装 |
| PMO（PJ起案） | VDU/BA（実行） | 新規PJの実行フェーズ移行 |
| OA（監査NG） | VDU（修正実装） | 品質基準未達の場合 |