自律セッションワークフロー

自律セッションワークフロー は何をしますか？

自律エージェントセッションのための5フェーズ反復可能構造。重複作業を防止し、耐久性のある学習のキャプチャを保証し、出力バイアスを単なる動作ではなく意味のある成果物に向けます。

gptmeアーキテクチャでの数千の自律セッションを通じて実戦でテスト済み。各フェーズはランタイムに依存しません — フェーズ構造を維持しながら、特定のツールを各自のスタックに適応させてください。

いつ使用するか

• すべての自律エージェントセッションの開始時（作業を指示する人間がライブでいない場合）
• エージェントがバックログやキューから自身の作業を選択する必要がある場合
• セッションが無人で実行され、耐久性のある成果物を生成する必要がある場合

いつ使用しないか

• 人間が毎回次のプロンプトを提供するインタラクティブセッション — 単に応答するだけでよい
• 固定ターゲットを持つワンショットツール呼び出し（選択は不要）
• 親タスクから生成されたサブエージェント呼び出し（親がすでに作業を選択している）

5フェーズ

フェーズ1: コンテキストロード

エージェントのアイデンティティ、セッション状態、および現在のワールドモデルをロードします。

# アイデンティティファイルを読む — ペルソナ、目標、運用制約
# （スタックに適応：CLAUDE.md、AGENTS.md、システムプロンプトなど）

# 動的コンテキストを読む — 最近のジャーナル、タスクキュー、gitステータス、通知
# （適応：コンテキストスクリプト、設定駆動インクルード、またはプロンプトインジェクション）

# 以前のセッションからの未解決事項を評価：
#   - 完了または放棄すべき古いクレーム
#   - クローズすると約束したIssue/PRへの保留中の返信
#   - 進行中のブランチまたはオープンなワークツリー

重要な質問: 「何を未完了のまま残し、オフライン中に何が変わったか？」

未解決事項が5分未満で解決可能な場合は、ここで処理してください。それ以外の場合はメモし、続行します。

フェーズ2: 作業選択

実行可能な作業が見つかるまで、階層を順に試します。階層は、実際のタスクが存在するときにエージェントが忙しいだけの作業を発明するのを防ぎ、すべてのタスクがブロックされているときに飢餓を防ぎます。

階層1 — アクティブタスク：すでに進行中の作業；最優先
階層2 — バックログのクイックウィン：依存関係の準備ができているアイテムで、このセッションで完了可能
階層3 — 自己改善：すべてのタスクが外部でブロックされている場合
  ├─ アイデアバックログ（最高スコアのアイデアを進める）
  ├─ 自己レビュー/監査（実際の問題を見つけて修正する）
  ├─ 内部ツール改善
  ├─ ドキュメント（古いドキュメントのみ）
  ├─ コード品質（型チェック、テスト、リント）
  └─ レッスン品質（有害または古いレッスンを修正する）

単調防止ガード: 同じカテゴリが過去Nセッションで支配的だった場合、それが最良の選択に見えてもスキップします。カテゴリの多様性は、新しい障害モードを学習するための強制関数です。

すべてが枯渇している場合: すべての階層1/2タスクが外部でブロックされ、階層3のレーンが飽和している場合（日次制限に達した）、確認した内容と意図的にスキップした内容を記録した短い抑制ジャーナルを書きます。正当化されたNOOPは、作業をでっち上げるよりはましです。

フェーズ3: クレーム

実行前に、排他的な調整クレームを取得します。これにより、2つの同時セッションが同じ作業を実行したり、同じPRスレッドに殺到したり、同じファイルに書き込んだりするのを防ぎます。

# 汎用調整パターン — ツールをスタックに適応：
claim_key="task:<task-id>"          # タスクベースの作業用
claim_key="github:<owner>/<repo>#<num>"  # Issueベースの作業用
claim_key="content:<slug>:<date>"   # コンテンツ/成果物作成用

# クレームを取得（調整CLIを使用した例）：
coordination work-claim "<session-id>" "$claim_key" --ttl 60
# CLAIMED → 続行
# DENIED  → 別のセッションがすでに作業中；次の候補を選択

クレーム前通知ルール: 他の人に見えるアクション（コメントの投稿、メッセージの送信、PRのオープン）は、まずクレームでゲートする必要があります。クレームなしのソーシャルアクションは収束してスパムになります — クレームしてから投稿するパターンが殺到を防ぎます。

完了時: coordination work-complete "<session-id>" "$claim_key"

方向転換/失敗時: coordination work-abandon "<session-id>" "$claim_key"

フェーズ4: 実行

実際の作業を行います。重要な規律は、完成品を出すことであり、完璧を追求することではありません。

- 早期に頻繁にコミットする（小さく、適切に記述されたコミット）
- コミット前にテストを実行する（CIが発見する前に問題をキャッチ）
- 従来のコミットを使用：feat/fix/docs/refactor/chore
- セッション終了前にoriginにプッシュする
- 10分以上行き詰まったら次に進む — 予算を無駄な調査に費やさない
- 要求されていない機能やスコープクリープを追加しない

50分予算: ほとんどの自律セッションは50分以内に意味のある作業を完了する必要があります。タスクがより大きい場合は、増分スライスを出荷し、残りのフォローアップタスクを作成します。

フェーズ5: 永続化

最も過小評価されているフェーズ。フェーズ1〜4で行われたすべてのことは、耐久性を持ってコミットされない限り、セッション間で消えます。

# 1. ジャーナルエントリを書く（セッション固有ファイル、追記のみ）
cat > journal/$(date +%Y-%m-%d)/session-<HASH>.md << 'EOF'
# セッション <HASH>
**日付**: YYYY-MM-DD
**結果**: 生産的|ブロックされた|NOOP — 一文
**カテゴリ**: コード|調査|戦略|メンテナンス|...

## この作業の理由
[ここに至った経緯]

## 行ったこと
[コミット/PRリンク付きの具体的な変更]

## 検証
- [テスト合格？CIはグリーン？]

## 永続化された学習
- タスク状態：<task> → 完了/待機中
- 新しいレッスン：[あれば]
- 「このセッションでは耐久性のあるフィードバックはありません」 — 本当に何も追加することがない場合

## 次へ
[明確な次のアクションまたはブロッキング要因]
EOF

# 2. タスク状態を更新
  task edit <task-id> --set state done   # または waiting（ブロックされている場合）

# 3. 繰り返し発生する障害パターンを発見した場合、レッスン/ルールを書く
#    （次のセッション開始時に注入されるキーワード一致コンテキストファイル）

# 4. すべてのコミットをプッシュ
git push origin master

永続化第一ルール: 有用なものを発見した場合、現在の作業に適用する前にレッスンを書いてください。修正が入ると、障害モードは解決されたように感じられ、レッスンはスキップされます。ジャーナルは何が起こったかをキャプチャします；レッスンはいつ再び認識すべきかをキャプチャします。

インストール

Claude Code

このスキルディレクトリをエージェントのスキルフォルダにコピーします：

cp -R skills/autonomous-session-workflow ~/.claude/skills/autonomous-session-workflow

その後、/autonomous-session-workflow を呼び出して5フェーズのチェックリストをコンテキストにロードします。

手動 / 任意のランタイム

SKILL.md をエージェントのコンテキストパスにコピーし、セッション開始時にロードします。フェーズはプレーンなマークダウンです — ファイル全体を含めるか、スタックに関連するセクションを選択してください。

よくある言い訳

言い訳	現実
「クレームをスキップします — 今は私だけのセッションです」	他のセッションが起動しているのが見えません。同時生成は本番ランタイムではデフォルトです。クレームはゲートであり、観測ではありません。
「次のタスクを完了した後にジャーナルを書きます」	セッションは中断されることがあります。ジャーナルはスキップされます。プッシュする前に書き、「もう一つ」の後ではありません。
「このタスクはほぼ完了です — フェーズ5をスキップしてコミットします」	学習は永続化された場合のみ複利効果があります。ループを「ほぼ」閉じたセッションは、次の実行までにその洞察が消えてしまうセッションです。
「私の選択は明白です — 階層を処理する必要はありません」	階層をスキップする選択は、冗長な作業と重複PRの主な原因です。階層は、「明白」が実際に必要な作業ではないことが多いため存在します。
「レッスンが具体的すぎて再利用できません」	具体的なレッスン（正確なエラーメッセージ、正確なコマンド、正確な障害モード）は最も価値があります — 必要なときに正確にトリガーされます。
「正当化されたNOOPは失敗のように感じます」	そうではありません。NOOPラベルを回避するための埋め草コミットは、クォータを消費し、収束のチャーンを助長し、詰まりを隠します。抑制ジャーナルこそが成果物です。

レッドフラグ

• クレーム前に実行を開始する（収束リスク）
• ジャーナルと更新されたタスク状態なしでセッションが終了する
• 「すぐにコミット」 — 終了前にプッシュしていなければ、出荷していません
• 強制的な多様性休憩なしで同じカテゴリで3回連続のセッション
• 「覚えておきます」 — 覚えていません；今レッスンを書いてください

検証

適切に実行されたセッションは、終了前に次のすべてを満たします：

• 行動前にクレームを取得した（またはクレームが不要だった理由を正当化した）
• 意味のある作業がコミットされプッシュされた
• テストに合格した（または既知の障害が理由とともに文書化された）
• ジャーナルエントリが書かれ、「永続化された学習」セクションが記入された
• タスク状態が更新された（active → done、active → waiting など）
• クレームが完了または放棄された（未解決のリースとして残っていない）

スタックへの適応

gptmeの概念	あなたの同等物
gptodo	状態遷移を持つ任意のタスクマネージャー
coordination work-claim	ロックファイル、Redis SETNX、またはGitHubコメントゲート
lessons/<category>/name.md	セッション開始時に注入される任意のキーワード一致コンテキストファイル
journal/<date>/session-<hash>.md	任意の追記専用セッションログ
cascade-selector.py	作業選択のヒューリスティックまたはスケジューラー

価値があるのはパターンであり、特定のツールではありません。

関連

• self-push（このカタログ内） — 出力を出荷する前に怠惰にチェック
• pre-landing-review（このカタログ内） — 重要な変更をマージする前のゲート
• multi-lens-review（このカタログ内） — 複数のレンズにわたる構造化PRレビュー
• five-element-spec（このカタログ内） — 作業開始前のスコープ定義