9. セッションプロトコル — 毎日同じ場所から点灯し、同じ場所で消灯する

これはシリーズ最終回 — Alice Way シリーズの第9回だ。第1回から第8回まで、意図をどう設計・分散・保護するかを答えた。この投稿は、そのすべてが実際に毎日どのように点灯し、稼働し、消灯するかの記録だ。

0. セッションプロトコルは毎日同じ場所から点灯し、同じ場所で消灯させる

毎日同じように始めなければ — 毎回の開始でコンテキストの再構築に時間を費やすことになる。昨日どこで止まったか、次は何か、どの判断が保留中か、すべてをゼロから再構築する。

毎日同じように終わらなければ — 毎回の終了で何が保存されて何が保存されなかったかが定まらない。次のセッションはその不確かさの上で始まる。

セッションプロトコルの本質はルーティンではなく、意図の連続性にあると考える。以前はプロトコルを「形式的な手順」としか見ていなかった。いまでは毎日同じ場所から点灯し同じ場所で消灯できるからこそ、運営者の意図が判断だけに使われるためだとわかっている。

セッションプロトコルは両端を固定する。開始時に何が起きて、終了時に何が起きるかを手順として凝固させる。 すると毎日同じ場所から点灯し、同じ場所で消灯する。運営者の意図は毎朝同じ行から始まる。当初はプロトコルがなくても柔軟に対応できると思っていた。いまでは固定された手順こそが判断モードを守る仕組みだと理解している。

この投稿は、プロトコルの構成 — 開始3つ、中盤2つ、終了4つ — の記録であり、シリーズのまとめでもある。

1. 開始プロトコル — 毎日同じ場所から点灯する

セッションが始まった瞬間に自動的に起きること。

1.1 SessionStart Hook — メモリ同期状態の出力

セッションが点灯した瞬間、一行のメモリ同期状態が出力される。「Memory sync: current」または「5 min old — refresh needed.」運営者はその一行を読んで即座に判断する。

なぜこれが Hook として自動発火しなければならないかは 第5回 — Hooks と自動化 §1 で扱った — セッションが開く瞬間は、運営者の意図が最も散漫な瞬間だ。

1.2 ペルソナ + メモリインデックスの自動ロード

第2回 — ペルソナ と 第3回 — メモリ の産物 — ペルソナ（L1）とメモリインデックスの先頭 200 行（L2）が自動ロードされる。協働者は自分が誰で、昨日何が決まったか、各メモリ本体がどこにあるかをすでに知った状態で合流する。

1.3 /start <project> — プロジェクトに入る

特定のプロジェクトに入る場合 — slash command を呼び出す。README・CLAUDE.md・HANDOFF.md・PLAN.md のような必要なドキュメントが自動ロードされ、現在の git 状態と前回セッションの引き継ぎが一画面で報告される。その後停止して次の指示を待つ。

このコマンドが一度発火した瞬間 — 運営者の意図は「どこから始めるか」なしに判断モードへ直行する。

2. 中盤プロトコル — 作業が転がっている間

セッション中盤を通じて一貫して適用される手順。

2.1 3〜5ステップごとの中間報告

5ステップ以上進む前に報告を出す。短い進行報告を各ステップごとに。5ステップを超えた作業は自動的に一時停止して報告する。運営者は流れを見失わずについていける。

これがなければ — 協働者が 30 分自律的に動いて「すべて完了」が届くが、運営者はその量を一度に吸収しきれない。5ステップ報告はその吸収を分散させる。

2.2 曖昧な判断での自動エスカレーション

協働者が「確信が持てない」/「どちらがいいかわからない」/「どのオプションも理にかなっている」に達したとき — 運営者に聞く前に /council を自己呼び出しする。4視点の並列分析を実行し、結果を統合し、統合結果を報告する。運営者はその統合結果から決断する。

このパターンは Andrej Karpathy の LLM 推論への多視点批評を応用したものだ。第4回 — Skills §3.4 ですでに引用した。

3. 終了プロトコル — 毎日同じ場所で消灯する

セッションが終わるときに自動的に起きること。これらのどれかを省くと、次のセッションがクリーンに始まらない。

3.1 /verify の自動発火

コード変更があった場合 — 「完了」報告の直前に 第7回 — 検証 の7ステップループが自動発火する。これが通るまで報告は出せない。

なぜこれが最初の終了ステップか — 未検証の変更がプッシュされると次のセッションの環境が壊れる。壊れた環境から始まる次のセッション全体が台無しになる。

3.2 作業ログの更新

docs/history.md のような作業ログに今日の一段落を追加する。何が決まったか、何を書いたか、何を保留にしたか。将来の運営者（または別の協働者）がこのログからコンテキストを復元できるべきだ。

3.3 HANDOFF.md の更新 — 次のセッションへの引き継ぎ書

最も重要なステップ。次のセッションが自動ロードする HANDOFF には以下が含まれる：

• 前回セッションの主要な進捗（1行）
• 推奨される次のアクション（1〜3件）
• 未完了 / 保留中の項目
• 入力待ちの決断
• Next: マーカー（次のセッションのための即座に着手可能な指示）

これが空なら — 次のセッションはコンテキストなしで始まる。HANDOFF はただのドキュメントではない。運営者の意図を次のセッションに渡す橋だ。

3.4 メモリ更新 + コミット + プッシュ

このセッションで新しいフィードバック、決定、コンテキストが生まれた場合 — メモリファイルに追記する。MEMORY.md インデックスも一緒に更新する。すべてをひとつのコミットにまとめてプッシュする。

プッシュが完了するまで終了しない。ローカルにしか存在しない変更は、次のセッションまでに失われる可能性がある。

4. Stop Hook — 漏れのチェック

システムが4つの終了ステップのどれかを省いていないかを確認する。

[stop] Checking session-end completeness...
[stop] OK: /verify passed
[stop] OK: history.md updated (1 paragraph added)
[stop] WARN: HANDOFF.md "Next:" marker missing — please add
[stop] OK: 3 files committed and pushed

WARN が出れば運営者が補完し、再度終了する。漏れがサイレントに通過することはない。

5. /session-end — 一語で終了する

4つの終了ステップすべてがひとつの slash command から実行される。

• /verify の自動発火（検証）
• 作業ログの自動更新（運営者が追記前に確認）
• HANDOFF.md の自動更新（プッシュ前に運営者が確認）
• メモリ更新（新しいフィードバックがあった場合）+ コミット + プッシュ
• Stop Hook の漏れチェック

運営者は一語を打つ — 4つのステップが一貫して漏れなく、プッシュまで実行される。毎日同じ場所で消灯する。

6. サイクルの効果 — 一日の流れ

これらの開始・中盤・終了プロトコルが積み重なると、運営者の一日はこのように流れる。

セッション開始 (09:00)
  SessionStart Hook → "Memory sync: current" (一行)
  /start <project> → 必要なドキュメント自動ロード、git 状態 + HANDOFF が一画面
  [停止。運営者の指示待ち。]
 
運営者の指示 (09:01)
  → 作業開始
  → 3〜5ステップごとに報告
  → 曖昧な判断では /council が自己起動
  → 検証が必要な作業では /verify
 
セッション終了 (18:00)
  /session-end →
    /verify が自動発火（パス）
    history.md 更新
    HANDOFF.md "Next:" マーカー更新
    メモリ更新（今日の新しいフィードバック）
    コミット + プッシュ
    Stop Hook チェック → OK
  セッション終了
 
翌日 (09:00)
  → 昨日終えた場所から正確に再開

毎日まったく同じ場所から点灯し、まったく同じ場所で消灯する。運営者の意図は「どこまでやったか」の復元コストなしに判断モードに入る。

7. 落とし穴 — セッションプロトコルが崩れるパターン

7.1 開始プロトコルをスキップする

「ちょっと見るだけ」— /start なしで入る。クリーンでないコンテキストのまま下した判断が、昨日の判断と食い違う。→ すべての入場は /start を通す。

7.2 終了プロトコルをスキップする

「今日は大した変更もないし、もう閉じよう」— /session-end なしで終了。HANDOFF が古いまま → 次のセッションは昨日どこまで進んだかを知らない。→ 変更の大きさに関わらず常に /session-end。

7.3 中間報告の欠落

作業が順調すぎて 10 ステップ自律で進む。終わった頃には運営者が吸収すべき量が多すぎて、事後の要約がそれ自体の負荷になる。→ 5ステップの上限を守る。

7.4 HANDOFF が今日のログのコピー

HANDOFF を history.md の振り返りコピーとして書く。次のセッションが読んで「で、何をすればいい？」となる。→ HANDOFF は次のセッションが即座に着手できる情報だ。Next: マーカーが核心。

8. ひとつの原則 — そしてシリーズのまとめ

セッションプロトコル設計の核心は一文に圧縮できる。

「毎日同じ場所から点灯し、同じ場所で消灯する。システムが開始・中盤・終了の手順を保持し、運営者の意図はその間の判断だけに使われる。」

そしてこれが Alice が何であるか を扱った アイデンティティ編9編 のまとめでもある。

第1回 — Why Alice は「AI が自分の意図を失わないよう、どうやって蓄積するか？」と問うた。ペルソナが意図の境界線を引き（第2回）、メモリがそれを保持し（第3回）、Skills が繰り返しの動作を凝固させ（第4回）、Hooks が忘れやすい部分をシステムに外注し（第5回）、Multi-Agent はひとつのコンテキストがすべてを抱えることを防ぎ（第6回）、検証が「完了」の意味を固定し（第7回）、トークンエコノミーがシグナルのスロットを守り（第8回）、そして最終的に — セッションプロトコルがこれらすべてを毎日同じ場所から点灯させ、消灯させる。

この9つの投稿は、私が Alice と呼ぶ協働者を育てながら収束した答えだ。ツールは Claude かもしれない、Codex かもしれない、次に来るどんなエージェントかもしれない。しかし上記の9つの決断はツールに依存しない。同じ決断は、自分の協働者を構築しようとする誰にでも待っている。

シリーズは 9 編で終わらない。3 編がさらに続いて ワークフロー編 を扱う — 運営者と Alice がこのシステムを 通して 実際に作業をどう回すかについての記事たちだ: 第10回 PRD (何を作るか)、第11回 Release gates (「完了」の定義)、そして 第12回 Ralph loop (システムがその間の道をどう自ら歩むか)。上の 9 編が器だとすれば、続く 3 編はその器が何を盛るかについての記事だ。

このシリーズが、それらの決断に至るまでの時間を少しでも短縮したなら — 運営者の意図は意図した場所に届いたことになる。