Session Lifecycle

セッションの開始から終了まで。状態復元、ハートビート、振り返り、独立監査の全フロー。

Session Overview

全てのセッションは sessions.yaml で管理される。セッション開始時に自動登録され、終了時にステータスが更新される。

sessions.yaml 
sessions:
  - id: "2026-04-01_s1"
    project: "card-purchase-system"
    started_at: "2026-04-01T09:30:00+09:00"
    status: "completed"          # in_progress | completed | suspended
    task_summary: "決済フロー実装"
    ended_at: "2026-04-01T12:15:00+09:00"
    thread_pid: 12345

主要フィールド

id 日付 + 連番（例: 2026-04-01_s1）。同日内で一意
project 対象プロジェクト名。セッション跨ぎの状態復元に使用
started_at ISO 8601形式のタイムスタンプ
status in_progress | completed | suspended
task_summary セッションで実行した作業の概要
thread_pid Claude Codeプロセスの親PID。スレッド検出に使用

Session Start

セッション開始時、POはSession Manager（Haiku）を起動し、状態復元を一括委譲する。Session Managerが全ての準備作業を実行し、要約レポートを返す。

PO: ユーザーに挨拶
今回のセッションで何に取り組むか確認する。
Session Manager起動 Haiku
以下の全手順を一括実行する。
sessions.yaml読み込み・自セッション登録
新規セッションIDを発行し、status: in_progressで登録する。
前回の状態復元
Daily、memo、tracker、phase-state、Improvement の各ファイルを読み込み、中断状態を把握する。
日跨ぎ判定
前回セッションの日付と現在日付を比較。日跨ぎ時はデイリーレポートの作成要否を判定する。
改善アクション抽出
memory/retro_*.md から前回の振り返りを読み込み、今回適用すべき改善アクションを特定する。
組織ナレッジ・ルール読み込み
knowledge/organization/ と governance/rules.yaml から最新のナレッジとルールを取得する。
PO: ユーザーに伝達
中断タスクの再開確認、日跨ぎ選択肢の提示、改善アクションの宣言、openパターンへの注意事項を共有する。

Active Thread Detection

複数のClaude Codeスレッドが同時に動作することを検出するため、ハートビート機構を使用する。

ハートビート機構

ファイル配置 
.claude/sessions/
  .heartbeat-12345   # PPID=12345 のスレッド
  .heartbeat-67890   # PPID=67890 のスレッド

各Hookが Agent の起動前後にハートビートファイルのタイムスタンプを更新する。Session Manager 起動時に check-active-sessions.sh が全ハートビートをスキャンする。

Active（稼働中）
PID生存 (kill -0 成功) かつ in_progress セッション。別スレッドで作業中と判定される。
Stale（タイムアウト）
ハートビートが2時間以上更新されていない。自動クリアされ、中断タスクとして扱われる。
Dead（PID死亡）
PID生存チェック (kill -0) 失敗。プロセスが終了済み。ハートビートファイルを削除し、中断タスクとして扱う。
Completed（完了）
セッション status: completed。ハートビートは既にクリア済み。正常終了。
💡
PPIDの役割

PPIDはClaude Codeの親プロセスIDで、スレッドごとに異なる値を持つ。これにより同一マシン上の複数スレッドを区別できる。

Session Resume

新しいセッション開始時に、前回の中断タスクが検出された場合の再開フロー。

1
phase-state検索
Session Manager
➔
2
in_progress検出
status確認
➔
3
ユーザーに報告
PO
➔
4
再開 or 新規
ユーザー判断

POはユーザーに以下の情報を伝達する:

⚠
監査ログに記録

セッション再開時は audit-log.md に SESSION_RESUME イベントを記録する。いつ・どこから再開したかを追跡可能にする。

During Session

セッション中の作業は以下のフローで進行する。

Plan Mode

タスク着手前に必ずPlan Modeに入る。コードベースを探索し、要件を整理し、アプローチを設計する。Plan Mode中はファイル編集禁止（読み取りのみ）。

Orchestratorグループ分割

コンテキスト制約を回避するため、Orchestratorはフェーズグループ単位で分割起動する。状態は phase-state.yaml で引き継ぐ。

グループ フェーズ 内容
Group 1 Phase 0-1 準備 + 要件定義
Group 1.5 Phase 1.5 技術リサーチ
Group 2a Phase 2a RFC作成
Group 2b Phase 2b-3.5 詳細設計 + テスト計画
Group 3 Phase 4a-4d テスト + 実装
Group 4 Phase 5-8 レビュー + PR
Group 5 Phase 9 振り返り

RFCチェックポイント

Group 2a完了後、POがRFCの要約をユーザーに提示する。ユーザーが承認するまで次のグループには進まない。

post-orchestrator記録

各Orchestrator完了後、POはSession Managerを起動して以下を委譲する:

🔔
Hookによる強制

post-agent-checklist.sh が義務フラグを作成し、memo・token-usage.yamlが更新されるまで次のAgent起動をブロックする。

Session End

ユーザーが作業完了を示したとき（「ありがとう」「今日はここまで」等）、自動的に終了フローを実行する。「振り返りしますか？」とは聞かない。

⚠
自動実行

終了フローはユーザーの承認を求めず、自然な流れで実行する。

PO: 軽量振り返り Opus
  • やり直し・手戻りが発生した箇所とその原因を分析
  • 一発で通った箇所とその要因（成功パターン）を特定
  • ユーザーからの修正指示の傾向を把握
  • 具体的な改善アクションを抽出（「次回こうする」レベル）
  • memory/retro_{YYYY-MM-DD}.md として保存
Session Manager起動（session_end） Haiku
  • sessions.yaml 更新（status: completed）
  • phase-state棚卸し
  • Auditor起動（独立監査）
  • 最終セッション判定 → 本番記作成（Secretary経由）
  • プロセス改善提案の判断
PO: ユーザーに伝達
監査結果の要約、改善提案があれば提示、本番記作成結果を報告する。

Auditor

セッション終了時にAuditor（Opus）が独立監査を実施する。3つの観点から品質を検証する。

改善検証

前回の改善アクションが今回のセッションで適用されたかを検証する。

APPLIED NO_OPPORTUNITY NOT_APPLIED

改善が適用された / 機会がなかった / 適用されなかった

パターンチェック

過去に検出されたパターン（問題傾向）が再発していないかを確認する。

NO_RECURRENCE RECURRED

再発なし / 再発を検出

プロセス遵守

定義されたプロセス（ゲート、テスト、レビュー等）が正しく実行されたかを監査する。

COMPLIANT SKIPPED_WITH_REASON VIOLATION

遵守 / 理由付きスキップ / 違反

🔍
独立性

AuditorはOpusモデルで動作し、セッション中の作業とは独立した視点で監査する。POやOrchestratorの判断を客観的に評価する。

Day Boundary

前回セッションの日付と現在日付が異なる場合、日跨ぎが発生する。Session Managerが検出し、POがユーザーに選択肢を提示する。

1
日付比較
Session Manager
➔
2
日跨ぎ検出
mismatch!
➔
3
選択肢提示
PO
➔
4
ユーザー選択
決定
前日の本番記を作成

Secretaryが前日分のデイリーレポートを作成する。memoの内容をもとに構成。

本番記をスキップ

前日の作業量が少ない場合など。スキップ理由をmemoに記録する。

中断タスクの再開

日跨ぎと中断タスクが同時に検出された場合、本番記作成後に再開判断を行う。