自律エージェント
WORK/IDLE フェーズと自動クレーム機能を持つ、独立して動作するエージェントを構築する。
学ぶこと
ほとんどの AI インタラクションは会話的です：人間が入力し、AI が応答し、繰り返す。自律エージェントはこのパターンを打ち破ります。作業のチェック、タスクのクレーム、実行、結果の報告、再チェックという連続的なループで動作します — すべて人間の介入なしに。
このセッションが終わるまでに、以下のことを理解できるようになります：
- 自律エージェントとインタラクティブエージェントの違い
- WORK/IDLE フェーズサイクル
- 自動クレーム：共有キューからのタスク取得
- ライブネス監視のためのハートビートパターン
- 自律エージェントを制御下に置くための安全性制約
問題
インタラクティブエージェントにはボトルネックがあります：人間です。エージェントが完了するたびに、次の指示を待ちます。
SCENARIO 1: Test Watcher
Developer changes code → tests need to run
But developer is writing more code → tests sit unexecuted
SCENARIO 2: Code Review Pipeline
3 PRs need review. Agent finishes PR #1, then stops.
PRs #2 and #3 wait for human to say "now do the next one"
SCENARIO 3: Multi-Feature Sprint
5 independent features. Sequential assignment wastes time:
Assign #1 → wait → done → assign #2 → wait → done → ...
Could be: define all 5 → agents work in parallel → all done核心的な問題：手動タスク割り当てが人為的なボトルネックを生み出す。 タスクが明確に定義され独立しているなら、エージェントが自動的にそれを取得すべきです。
仕組み
インタラクティブ vs 自律
INTERACTIVE AUTONOMOUS
Human: "Fix the login bug" Agent: [check queue] → task found
Agent: [works] → "Done." Agent: [claim] → [work] → [report]
Human: "Now add error messages" Agent: [check queue] → task found
Agent: [works] → "Done." Agent: [claim] → [work] → [report]
Human: "Run the tests" Agent: [check queue] → empty
Agent: [works] → "All passing." Agent: [idle] → [wait] → [check]
↑ Stops after each task ↑ Loops until queue is emptyWORK/IDLE フェーズサイクル
すべての自律エージェントは2つのフェーズを交互に繰り返します：
┌──────────────────────────────────┐
│ │
▼ │
┌───────────┐ no tasks available │
│ IDLE │◀──────────────────┐ │
└─────┬─────┘ │ │
│ check task queue │ │
▼ │ │
┌───────────┐ nothing found │ │
│ CHECK │──────────────────▶│ │
└─────┬─────┘ │
│ task found → claim it │
▼ │
┌───────────┐ │
│ WORK │ execute task │
└─────┬─────┘ │
│ complete → report result │
└──────────────────────────────────┘IDLE フェーズでは、エージェントは設定可能な間隔で再チェックするまで待機します。WORK フェーズでは、エージェントはクレームしたタスクに対して完全な権限を持ちます — ファイルの読み取り、コードの記述、コマンドの実行。
自動クレーム：キューから実行へ
自動クレームは、自律エージェントが未割り当てのタスクを取得する方法です：
SHARED TASK QUEUE
┌─────────────────────────────────────────────┐
│ [task-1] status: done assignee: A │
│ [task-2] status: done assignee: B │
│ [task-3] status: ready assignee: — │ ◀── Agent C claims this
│ [task-4] status: ready assignee: — │
│ [task-5] status: blocked assignee: — │
└─────────────────────────────────────────────┘
RULES:
1. Only claim tasks with status "ready" (skip "blocked")
2. Claim ONE task at a time (prevents hoarding)
3. Set assignee atomically (prevents double-claim)
4. Respect priority order (higher priority first)ハートビートパターン
エージェントが自律的に動作しているとき、それがまだ稼働しているかどうかをどう知るのでしょうか？
Agent C (autonomous) Monitor
│ │
│ ♥ { agent: "C", task: "task-3", │
├───── status: "working" } ──▶ recorded: alive
│ ... 30 seconds ... │
│ ♥ { agent: "C", task: "task-3", │
├───── progress: "60%" } ──▶ recorded: alive
│ ... 30 seconds ... │
│ (no heartbeat) │
│ ──▶ 60s without heartbeat
│ │ → agent presumed dead
│ │ → unassign task-3
│ │ → task returns to queueハートビートは、ライブネス検出（クラッシュしたエージェントのタスクが回収される）と進捗追跡（オーケストレータが完了状況を監視できる）を提供します。
デーモンモード
一部の自律エージェントは、キューをドレインするのではなく、イベントを監視して無期限に実行されます：
DAEMON AGENT: Test Watcher
WATCH: file system changes
TRIGGER: *.ts file modified
ACTION: run related tests, report pass/fail
LOOP: forever (until explicit stop or session end)
EXIT: stop signal, session end, or 3 consecutive fatal errors安全性制約
自律エージェントにはガードレールが必要です。自律性はすべてか無かではなく、段階的に付与されます：
┌─────────────────────────────────────────────────┐
│ 1. SCOPE LIMITS │
│ allowed_paths: ["src/", "tests/"] │
│ max_files_modified: 10 │
│ │
│ 2. APPROVAL GATES │
│ auto_approve: read, test, lint │
│ require_review: write, delete │
│ blocked: deploy, publish │
│ │
│ 3. KILL SWITCHES │
│ max_runtime: 300s per task │
│ max_iterations: 50 │
│ error_threshold: 3 consecutive failures │
│ │
│ 4. RESOURCE BUDGETS │
│ max_tokens_per_task: 100,000 │
│ max_tool_calls: 200 │
└─────────────────────────────────────────────────┘エージェントは安全な操作（読み取り、テスト）に対しては完全に自律的でありながら、破壊的な操作（ファイルの削除、デプロイ）に対しては承認を要求できます。
キーインサイト
自律エージェントは、Claude Code 内での CI/CD ライクなワークフローの構成要素です。インタラクティブなコーディングと自動化されたパイプラインの間のギャップを埋めます。
重要な転換は精神的なものです：インタラクティブエージェントは人間をスケジューラーとして扱います（「次は何をすべき？」）。自律エージェントは人間をアーキテクトとして扱います（「ここにキューがあり、ここに制約がある、独立して実行せよ」）。
これは、品質がタスク定義に依存することを意味します。明確な入力、期待される出力、成功基準を持つ明確に定義されたタスクは自律的に実行できます。「コードベースを改善する」のような曖昧なタスクはできません。自律エージェントを有効にする前に、タスク分解（セッション7）とプロトコル（セッション10）に投資してください。
実践例
自律的に動作するテストランナーエージェント：
SETUP: Define the agent
──────────────────────────────────────
Agent: "test-runner"
Mode: autonomous
Constraints:
allowed_actions: [read_file, run_tests, report_result]
denied_actions: [write_file, delete_file]
max_runtime: 120s per task
heartbeat_interval: 30s
CYCLE 1: Claim and execute
──────────────────────────────────────
[CHECK] Query queue → status: "ready", type: "test"
[CLAIM] task-17: "Run integration tests for auth module"
[WORK] Read tests/auth/ → run pnpm test tests/auth/
[REPORT] { passed: 12, failed: 1,
failure: "tests/auth/refresh.test.ts:45" }
[♥] Heartbeat sent at 30s mark
CYCLE 2: Next task
──────────────────────────────────────
[CHECK] Query queue → task-22 found
[CLAIM] "Run unit tests for payment module"
[WORK] Read tests/payment/ → run pnpm test tests/payment/
[REPORT] { passed: 8, failed: 0 }
CYCLE 3: Queue empty
──────────────────────────────────────
[CHECK] No tasks available
[IDLE] Wait 10s → check again → still empty → wait...良い自律エージェント設計 vs 悪い設計
GOOD: BAD:
Single responsibility Multiple responsibilities
Clear success criteria "Make it better"
Bounded execution time "Keep going until perfect"
Structured results Unstructured text output
Example: Lint checker Example: "Code improver"
Input: file path Input: entire codebase
Action: run linter Action: ??? (too broad)
Output: { errors, warnings } Output: "I made some changes"チームプロトコルとの接続
自律エージェントはセッション10と同じプロトコルメッセージを使用します。唯一の違いは、誰が開始するかです：
INTERACTIVE: Human → "Review this PR" → Agent works → responds
AUTONOMOUS: Agent → [checks queue] → [claims] → [works] → responds
Same message format. Same request_id. Different trigger.変更点
| インタラクティブエージェント | 自律エージェント |
|---|---|
| 人間が各タスクを割り当て | エージェントがキューからクレーム |
| 毎タスク後に停止 | 継続的にループ |
| 人間が進捗を監視 | ハートビートがライブネスを通知 |
| すべてのアクションが許可 | 操作ごとの安全性制約 |
| ボトルネック：人間の応答時間 | ボトルネック：タスクキューの深さ |
次のセッション
セッション12ではワークツリー分離を扱います。git worktree が各エージェントに独自のブランチ上の独自の作業ディレクトリを与え、マージコンフリクトなしに真の並列開発を可能にする方法を学びます。