自律性の階段 ─ 5 段階モデル
「自律的に動かす」は単一のスイッチではない。段階的に登る階段として捉えると、自分の現在地と次の一歩が見える。この章では 5 段階モデルを提示する。
このモデルはこの後の章すべての地図になる。L1 = ch03、L2 = ch04 … と章番号と対応させているので、必要な段だけ読む使い方もできる。
L0：対話 ─ 出発点
まず登る前の地点を確認しておく。
L0 = ターミナルで claude を打って対話するモード。指示を出し、結果を確認し、次の指示を出す。Cursor の中で会話するのも L0。これは「自律」ではなく「伴走」だ。
L0 でも十分価値はある。だが、人間が常にそこにいる必要がある。離席すれば止まる。睡眠中は動かない。これが「自律的でない」状態の定義になる。
L1〜L5 の概観
graph TB
L0[L0: 対話<br/>人間が常時介在]
L1[L1: 型化<br/>Skill / Slash Command]
L2[L2: 自己監視<br/>Hooks]
L3[L3: Event-driven<br/>GitHub Actions]
L4[L4: 時間切り離し<br/>Scheduled / Routines]
L5[L5: 多体化<br/>Sub-agent / MCP]
L0 --> L1 --> L2 --> L3 --> L4 --> L5
style L0 fill:#fff
style L1 fill:#e1ffe1
style L2 fill:#d1f4e1
style L3 fill:#b1ecd1
style L4 fill:#91e4c1
style L5 fill:#71dcb1色の濃さ = 自律性の強さ。下に行くほど人間の介在が減り、その分設計の責任が重くなる。
L1：型化 ─ Skill と Slash Command
変える対象：自分自身の指示の出し方
毎回似たようなことを Claude に頼んでいるなら、それは型化できる。.claude/commands/ または .claude/skills/ に SKILL.md を置けば、/<command> 一発で再現可能になる。
# Before（毎回フルプロンプトを書く）
$ claude
> このディレクトリの変更を git diff で確認して、コミットメッセージを Conventional Commits 形式で 3 案出して
# After（型化済み）
$ claude
> /commit-msgこれが L1。自律というより自己反復の効率化だが、自動化の出発点として極めて重要。型がないと L2 以降に進めない。
| 項目 | 内容 |
|---|---|
| 主な機能 | Slash Command / Skill (.claude/commands/*.md、.claude/skills/<name>/SKILL.md) |
| 効果 | 同じ作業を 30 秒 → 3 秒に圧縮 |
| 必要な学習 | YAML frontmatter / dynamic context (!`cmd`) / arguments |
| リスク | 型が曖昧だと毎回違う結果 ─ 型を磨く |
詳細は ch03：L1 Skill と Slash Command で。
L2：自己監視 ─ Hooks
変える対象：Claude の行動の前後
L1 までは「何を頼むか」を整えた。L2 では「頼んだ後に Claude が約束を守っているか」を機械的に検証する。これが Hooks の本懐。
graph LR
P[ユーザー入力] --> UPS[UserPromptSubmit Hook]
UPS --> C[Claude]
C --> PRE[PreToolUse Hook]
PRE -->|許可| T[Tool 実行]
PRE -->|拒否| Block[blocked]
T --> POST[PostToolUse Hook]
POST --> C
C --> S[Stop Hook]
style PRE fill:#fff4e1
style POST fill:#fff4e1
style UPS fill:#fff4e1
style S fill:#fff4e1典型用途：
- PreToolUse：危険な
rm -rfを block する、特定ディレクトリへの書き込みを止める - PostToolUse：ファイル編集後に lint / format / test を自動実行
- UserPromptSubmit：ユーザー入力に project context を inject する
- Stop：会話終了時に「ルール違反していないか」を別 LLM で検閲
| 項目 | 内容 |
|---|---|
| 主な機能 | .claude/settings.json の hooks セクション、shell script |
| 効果 | 「CLAUDE.md を忘れる」問題を機械的に防ぐ、品質ゲートを自動化 |
| 必要な学習 | jq での JSON 操作、exit code の意味、matcher 正規表現 |
| リスク | Hook が複雑すぎると debug 困難、実行時間で session が遅くなる |
詳細は ch04：L2 Hooks で。
L3：Event-driven ─ GitHub Actions
変える対象：起動するタイミング
L2 までは「自分が claude を起動する」前提だった。L3 では GitHub Actions のイベント（PR 作成 / Issue オープン / push） が起動トリガーになる。これで「人が起動しなくても動く」状態になる。
# .github/workflows/claude-pr-review.yml
on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: anthropics/claude-code-action@v1
with:
prompt: "Review this PR for security issues and suggest improvements"
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}公式 claude-code-action には 2 つのモードがある：
- Interactive：PR / Issue で
@claudeメンションすると返答 - Automation：YAML に prompt を書いて headless 実行
| 項目 | 内容 |
|---|---|
| 主な機能 | claude-code-action / claude -p headless mode |
| 効果 | PR レビュー / Issue triage / 依存更新 を「人がいなくても」進める |
| 必要な学習 | GitHub Actions 構文、API key の secret 管理、permission rules |
| リスク | 暴走で大量コミット / 大量コメント、API コスト |
詳細は ch05：L3 GitHub Actions で。
L4：時間軸の切り離し ─ Scheduled / Routines
変える対象：時間との結びつき
L3 はイベント駆動 ── 何かが起きたら動く。L4 は 時間駆動 ── 「毎朝 9 時に動く」「毎週月曜にトレンド記事を出す」という cron 的な仕組み。
Claude Code には 2026 年に追加された Scheduled Tasks がある：
| 種類 | 動作場所 | あなたの PC が落ちていても動くか |
|---|---|---|
| Cloud Routines | Anthropic クラウド | ✅ 動く |
| Desktop Scheduler | あなたの PC | ❌ 落ちると止まる |
/loop skill | あなたの session 内 | ❌ session を閉じると止まる |
「あなたが寝ていても動く」のは Cloud だけ。これが L4 の core。
| 項目 | 内容 |
|---|---|
| 主な機能 | Cloud Routines / Desktop Scheduler / /loop |
| 効果 | 「寝ている間に成果が出る」状態 |
| 必要な学習 | cron 構文、token コスト管理、エラーハンドリング設計 |
| リスク | 暴走 → token 枯渇、失敗が見えない（誰も画面を見ていない） |
詳細は ch06：L4 Scheduled / Routines で。
L5：多体化 ─ Sub-agent と MCP
変える対象：Claude を 1 体から N 体に
L4 までは Claude が 1 体で動く前提だった。L5 では 複数の Claude が役割分担して動く。さらに MCP でデータベース / Slack / GitHub などの外部システムを 道具として 持たせる。
graph TB
Main[Main Claude<br/>調整役]
Main --> A1[Sub-agent A<br/>generator]
Main --> A2[Sub-agent B<br/>validator]
Main --> A3[Sub-agent C<br/>researcher]
A1 -.MCP.-> DB[(Database)]
A2 -.MCP.-> Slack[Slack]
A3 -.MCP.-> Web[Web Search]
style Main fill:#e1f5ff
style A1 fill:#fff4e1
style A2 fill:#fff4e1
style A3 fill:#fff4e1Anthropic 社内の Growth Marketing チーム は、広告コピーを「generator + validator」の 2 体で大量生成している ── generator が文案を書き、validator が文字数制約や禁止語リストを機械的にチェックする。これが多体化の典型例。
| 項目 | 内容 |
|---|---|
| 主な機能 | Sub-agent (.claude/agents/) / MCP server (.claude/mcp.json) |
| 効果 | コンテキスト isolation、専門化、外部システム統合 |
| 必要な学習 | agent 定義、MCP プロトコル、tool permission 設計 |
| リスク | デバッグ困難、コスト増、調整役 Claude のボトルネック化 |
詳細は ch07：L5 Multi-agent と MCP で。
段階別の比較表
5 段階を一覧で：
| Level | 主な技法 | 人間の介在 | コスト | 典型用途 |
|---|---|---|---|---|
| L0 | 対話 | 常時 | 低 | 探索・学習 |
| L1 | Skill / Slash | 起動時のみ | 低 | 定型作業の高速化 |
| L2 | Hooks | ルール違反時のみ | 低 | 品質ゲート、ルール強制 |
| L3 | GitHub Actions | 異常時のみ | 中 | PR レビュー、Issue triage |
| L4 | Scheduled | 結果確認のみ | 中〜高 | 週次レポート、依存更新 |
| L5 | Sub-agent + MCP | 設計時のみ | 高 | 大量生成、複雑ワークフロー |
コスト は token / 設計時間 / 運用負荷の総合。
「どこまで登るべきか」の判断軸
階段はあるが、全員が L5 まで登る必要はない。判断軸は 4 つ：
graph TB
Q1[繰り返し頻度<br/>週 3 回以上か?] -->|Yes| L1[L1 を検討]
Q1 -->|No| Stop1[L0 のままで OK]
Q2[ルール違反が頻発する?] -->|Yes| L2[L2 を検討]
Q3[人がいない時間に<br/>動かしたい?] -->|Yes| L3L4[L3/L4 を検討]
Q4[1 体では捌けない<br/>複雑なタスク?] -->|Yes| L5[L5 を検討]
style Stop1 fill:#fff
style L1 fill:#e1ffe1
style L2 fill:#d1f4e1
style L3L4 fill:#b1ecd1
style L5 fill:#91e4c1「自動化のためにコストをかけるなら、繰り返し頻度がそれを正当化するか」を最初に問う。週 1 回しかやらない作業を L4 に乗せると、設計時間の方が浮いた時間を上回る。
アンチパターン：先走って L5 に飛ぶ
副業煽り記事は「Multi-agent で月100万」のように、いきなり L5 を売りつける。だが現実はその逆：
推奨：L1 → L2 → L3 → L4 → L5（必要があれば）
NG：いきなり L5（設計負債で破綻）L1 〜 L2 を飛ばして L3 以上に行くと、Claude が「何をすべきか」の型を持たないまま自動実行されて、結果が散らかる。型化（L1）と自己監視（L2）が固まってから上に登るのが健全な順序。
この章の要点
- 自律性は 5 段階の階段。下から順に登る
- L1 = 型化、L2 = 自己監視、L3 = event-driven、L4 = 時間切り離し、L5 = 多体化
- コストは段階に応じて上昇。**「繰り返し頻度がコストを正当化するか」**で判断
- いきなり L5 は破綻。L1 → L2 を固めてから上へ
- 5 段階は地図。次章から階段を 1 段ずつ登る
次章への問いかけ
階段の地図は描けた。最初の一段、L1 はどう登るのか。
次章では Skill と Slash Command で「型」を持つ 具体的な実装を扱う。SKILL.md の書き方、動的コンテキスト挿入、引数設計。「毎回同じプロンプトを書いている」状態から抜け出す。