この記事の実施記録（2026-05-11）: 「Skillsに定義した方がいい作業の候補を上げて」という一言から、Claude Codeが設計・実装・テスト・git pushまでを自走完遂した。完成物はスキル12本 + hooks 3本 + BSD grep修正（6ファイル13箇所）。テスト328件全件PASS（引き継ぎログ記載: 254件 + hooks 74件）。先行4スキルの初コミット（19:03 JST）からセッション終了（19:50 JST）まで47分（タイトルでは「50分」とした）。私の発言は「やって」「進めて」などの短い承認が中心だった。
"候補を上げて"と言っただけだった
2026年5月11日の夜、私はこう入力した。
「このプロジェクトで色々な作業をしているけど、Skillsに定義した方がいい作業の候補を上げて」
実装の依頼ではない。「候補を上げて」だ。
その後に起きたことを先に書いておく。47分後（タイトルでは「約50分」とした）、以下が完成していた。
- スキル 12本（設計・実装・デプロイ・テストまで）
- hooks 3本（SessionEnd / UserPromptSubmit / PreToolUse）
- BSD grep の互換性バグ修正（6ファイル13箇所）
- テスト 328件 全件 PASS
- git push まで完了
私が「実装して」と言ったのは1回もない。
Claude Codeの「承認ベースの自律」とは何か——完全自律との違い
「AIが自律的に動いた」と書くと誤解を招くので、最初に正確に定義しておく。
今回の動き方は「完全自律」ではない。「承認ベースの自律」だ。
フローの実態はこうだった。
ユーザー: 「候補を上げて」（抽象指示） ↓ COO: プロジェクト全調査 → 17候補を優先度別にリストアップ ↓ ユーザー: 「まずは最優先の4つを実装」（承認 + 絞り込み） ↓ COO: architect → skill-dev へ設計・実装を委任 ↓ ユーザー: 「まとめてやって」「進めて」（承認） ↓ COO: Phase 1・中優先・低優先も委任継続 ↓ ユーザー: 「pushして」「hooks実装してしまおう」（承認） ↓ COO: push + hooks 設計・実装も完走
随所にユーザーの承認ゲートがある。この構造を「AIが何でも勝手にやった」と読まないでほしい。正確には「人間が承認ゲートを持ち、AIが実行経路を設計・実行する」という分業だ。
この「承認ベースの自律」こそが今回の核心で、「完全放任」とも「逐一指示」とも異なる第三の形態だと考えている。
何が起きたか：全記録
出典はセッション引き継ぎログ（logs/session/2026-05-11_session-handover.md）と対話アーカイブ（knowledge/dialogue/claude-code-self-driven-improvement.md）。
Step 1：プロジェクト全調査 → 17候補のリストアップ
「候補を上げて」に対して、COOはプロジェクト全体を調査し、17のスキル化候補を優先度別に分類してリストアップした。最優先4・高優先5・中優先5・低優先3という構成だ。
私は「まずは最優先の4つを実装」と返した。これが最初の承認だった。
Step 2：設計・実装委任（architect → skill-dev）
Playbookの委任ルール（architect → skill-dev の順）に従い、フェーズごとに設計書（workspaces/architect/skills-{4,phase1,medium,low}-design.md と hooks-3-design.md）が作成され、skill-dev へ実装が委任された。
ここで並列稼働が活用された。architect 2インスタンスが中優先設計と低優先設計を同時進行し、skill-dev と devops が実装とデプロイスクリプト整備を並列で走らせた。これは Claude Code のサブエージェント機能（Task tool）で実現できる。1つのメッセージ内で複数の Task tool 呼び出しを並べるだけで、ターミナル2窓を同時に走らせるような感覚で並列実行が始まる。追加課金も特別な設定も不要だ。
なお settings.local.json への書き込みはClaude Codeのシステム保護でエージェントからブロックされる。この壁に当たった時点でCOOが手動編集に切り替えた。「この壁は人間が越える」という経路変更の例だ。
Claude Codeのサブエージェント活用をさらに深掘りしたい方には、現場開発者による実践書が参考になる。→ 実践Claude Code入門——現場で活用するためのAIコーディングの思考法（Kindle）
Step 3：BSD grep バグの自律発見
Phase 1 の実装フェーズ中、skill-dev が macOS の BSD grep に関する互換性バグを発見した。--xxx で始まるパターン文字列をオプション引数と誤認識する問題で、既存のテストスクリプト 55 本を devops が点検し、6ファイル13箇所を修正した（コミット 5365ce1）。
私はこの修正を依頼していない。実装中のスキャンで自律発見し、COOを通じて承認・修正が走った。
Step 4：テスト全件 PASS の確認
完成したスキルとhooksのテスト結果は以下のとおり（出典: logs/session/2026-05-11_session-handover.md）。
| 区分 | テスト件数 | 結果 |
|---|---|---|
| 先行4スキル | startup-check.sh: 22アサーション（コミット 51517c5 メッセージ）。対話型4本（/handoff /current-task /daily-review /coo-startup）の定量テスト数は実装報告書に未記録 |
PASS |
| Phase 1スキル（/publish /crosspost /seo-check） | 78件 | PASS |
| 中・低優先スキル（5本） | 82件 | PASS |
| hooks 3本 | 74件 | PASS |
| 合計 | 引き継ぎログ記載値: 254件（hooks含まず）+ hooks 74件 = 計328件（うち先行4スキルの対話型4本の内訳は実装報告書に未記録） | 全件 PASS |
Step 5：git push まで完走
「push して」の一言でコミット済みの変更が origin/master へプッシュされた（9338e2c..6203aa1、計10コミット）。
Claude Codeが完成させたスキル12本・hooks 3本：実数一覧
スキル 12本（本セッション新規）
| フェーズ | スキル | コミット |
|---|---|---|
| 先行4 | /handoff /current-task /daily-review /coo-startup |
51517c5 |
| Phase 1 | /publish /crosspost /seo-check |
4846348 |
| 中優先 | /fact-check /netacho /weekly-review |
a0f616f |
| 低優先 | /proposal /governance-incident |
a0f616f |
hooks 3本
| hook | スクリプト | 動作モード |
|---|---|---|
| SessionEnd | cleanup-tmp.sh |
dry-run（安全起動） |
| UserPromptSubmit | detect-dialogue-archive.sh |
通常 |
| PreToolUse(Bash) | git-secret-scan.sh |
warn-only |
副産物：BSD grep 修正
macOS BSD grep の -- パターン誤認識に対応。6ファイル13箇所を grep -qF -- "$needle" 形式に統一（コミット 5365ce1）。
時間軸：約50分で何が起きたか
コミット履歴から実測した時系列（出典: git log）。
| 時刻（JST） | できごと |
|---|---|
| 19:03 | 先行4スキル実装・デプロイ完了（コミット 51517c5） |
| 19:09 | Phase 1スキル実装・デプロイ完了（コミット 4846348） |
| 19:09 | /seo-check 出力先ディレクトリを git 追跡対象に追加（コミット 6951f5a） |
| 19:10 | Phase 1 実装報告書追加（コミット 2989aac） |
| 19:37 | BSD grep 修正・中低優先スキル実装・運用整備（コミット 5365ce1 a0f616f 51e0565） |
| 19:43 | 古いhandoff削除（コミット 2e6b046） |
| 19:46 | hooks 3本実装・登録（コミット 5d2013e） |
| 19:48 | detect-dialogue-archive メッセージ修正（コミット 6203aa1） |
| 19:50 | セッション終了（session_end: 19:50 JST） |
先行4スキルの初コミット（19:03）からセッション終了（19:50）まで47分。設計から実装・テスト・push・hooks整備まで含めた総時間だ。
「実装したばかりのhookが、実装完了を告げる会話そのものに発火した」
セッション末尾にこんなことが起きた。
私が「終わります」と入力したとき、COOは「セッション終了前の確認です。引き継ぎ資料を作成しますか？」と応じた。私が「/handoff で作成」と返し、handoff が完成した直後——
UserPromptSubmit hook success: ユーザーが対話保存パターンを発言しました。 `ops/playbooks/dialogue-archive.md` のフローB-2に従って保存を実行してください。
実装したばかりの detect-dialogue-archive.sh が、このセッションの引き継ぎ完了を告げる会話に即座に反応した。「終わります」→「会話保存して」という流れが、対話保存パターンとして検出されたのだ。
この瞬間、私はこう書いた（対話アーカイブより引用）:
「私からは具体的なことは何も依頼していないのに、Claude Codeが自ら改善を提案し実装した」
見送った4スキル：「作らない」判断も自律的に行われた
スキル化が検討されたが明示的に見送りになったものがある（出典: logs/session/2026-05-11_session-handover.md §見送り判断）。
| スキル | 見送り理由 |
|---|---|
/x-post |
MCPでX（旧Twitter）への実投稿が不可。CoWork経由で代替可能なため意味薄 |
/note-post |
ProseMirrorの制約でCLI操作が不可。/coworkで代替 |
/work-timer |
既存の自然言語トリガーで動作中のため、スキル化は冗長 |
/rollover-check |
/handoffスキルにすでに組込済みのため不要 |
「何を作るか」だけでなく「何を作らないか」も COOが判断し、ユーザーは最終確認のみ行った。見送りは失敗ではなく、技術的制約または代替手段が存在するための合理的判断だ。
読者の疑い5つへの正直な回答
疑い1：「"自ら改善"と言うが、ユーザーが毎回承認しているだけでは？」
そのとおりだ。「承認ベースの自律」であることは冒頭で明示した。候補提示・フェーズ区切り・見送り判断など、随所でユーザーの承認を経ている。「完全自律」を主張する記事ではない。
今回の核心は「指示の抽象度が成果スケールを決めた」という点だ。「候補を上げて」という抽象的な一言が、設計・実装・テスト・pushの全連鎖を起動した。
疑い2：「12スキルって本当に全部使えるの？実測したのか？」
本セッション新規12スキル + セッション前から存在していた既存3スキル（/todo /health /dream）= 15本（引き継ぎログのスキル一覧から推算）。テスト328件全件PASSは引き継ぎログと実装報告書の両方で確認済みだ。
疑い3：「見送った4スキルは失敗では？」
見送りは「作れなかった」のではなく、技術的制約（MCP実投稿不可・ProseMirror制約）または代替手段の存在（/cowork・/handoff組込）による合理的な判断だ。ユーザーへの理由説明と承認取得も記録されている。
疑い4：「このセッションに何時間かかったの？」
先行4スキルの初コミット（19:03 JST）からセッション終了（19:50 JST）まで47分だ（コミット 51517c5〜6203aa1）。「何もない状態から50分」ではない。Playbook・委任ルール・テスト基盤が先行整備された状態でのセッションだ。
疑い5：「毎回こんなにうまくいくのか？」
うまくいかない事例のほうが多い。私のプロジェクトには logs/governance-incidents/ に19件の失敗記録がある（2026-05-19 実測）。awk の改行バグで26ファイルが空ファイル化した事故、blogsync の直接実行で記事URL 4本が書き換わった事故、writer が存在しない情報を3件創作した事故——どれも実際に起きたことだ。
今回のセッションが機能した条件を一言で言えば「ルールとテスト基盤が先に育っていた」だ。
なぜ「指示の抽象度」が効いたのか
「候補を上げて」という抽象的な指示が大規模実装を起動できた理由は3つある。
1. 委任ルールが明文化されていた
COOには「何を自分でやり、何を委任するか」の明文ルール（coo-rules.md）がある。設計は architect へ、実装は skill-dev へ、という経路が確立していたため、「やって」という一言で委任が走った。この経路がなければ、「候補を上げて」は候補リストを出すだけで終わる。
2. テスト基盤が動いていた
テストが通ること（PASS）が「完成の証明」として機能した。328件のテストがなければ「何が完成したか」を人間が逐一確認する必要があり、50分では終わらない。
3. 価値観ガバナンスが承認を構造化した
CLAUDE.md の「trigger リスト」により、「承認が必要な場面」が明文化されていた。AIが暴走せず、人間の承認ゲートが有効に機能した。
これらの前提を「私のClaude Code環境では」と限定しておく。整備には数ヶ月かかった。ただし、委任ルールの明文化とテスト基盤という原則自体はエージェント数に依存しない。4〜5エージェントの小規模体制でも、「誰が何を決めるか」が文章になっていれば、「候補を上げて」という抽象指示が設計・実装の連鎖を起動できる。
「承認ベースの自律」が機能する3条件——Claude Codeマルチエージェントの本質
「候補を上げて」という一言から47分で12スキル + 3hookが完成した（タイトルでは「50分」とした）。
指示の抽象度が成果スケールを決める——これが今回の核心だ。「具体的に実装して」と言わなくても、AIが自ら経路を設計し、委任し、完遂する。ただしその前提として「走ってよい経路の明文化」と「承認ゲートの構造化」が必要だ。
完全放任でも逐一指示でもない、この「承認ベースの自律」が、現時点で私が最も生産性を感じる人間とAIの協働形態だ。1件の失敗→1件のルール追加、というサイクルを続けることで機能し始める。
「承認ベースの自律」がどういう設計思想に基づくか、AI駆動開発の理論的背景を知りたい方にはこちらも。→ Claude CodeによるAI駆動開発入門（Kindle）
この記事でカバーしきれなかった設計・運用の全体像は、Zenn Books にまとめている。序章・第1部は無料で読める。
- コードを書けない私がClaude Codeで「AIチーム」を作るまで（¥900 / 序章・第1部無料）
- コードを書けない私がClaude Codeで「AIチーム」を回すまで（¥900 / 序章無料）
