Claude Code で築く自律開発の工程手を放す

2026 年、開発者の仕事は静かに重心を移している。コードを書く時間が減り、エージェントが走る場を整える時間が増えている。Claude Code を一日中ターミナルに開いている人なら、その変化に既に気付いているはずだ ── 自分が書いた行数より、エージェントが書いた行数のほうが多くなった日があったことに。

本書はその先を扱う。「Claude Code をどう使うか」ではなく、Claude Code を使わずに済む仕組みを Claude Code でどう作るか。エージェントを起動するキーストロークすら省きたい ── そういう怠惰さこそが、自律開発の正しい入口だ。

各章は「人が今どこに立っているか」と「そこから抜けるための仕組み」の二段構えで書いた。月曜の朝にターミナルを開いたとき、すぐに settings.json や .claude/hooks/ を編集できる形を目指した。コーヒーを淹れて、はじめよう。

II. 実務監督ではなく、庭師として

従来のソフトウェア開発で人がやってきたのは「監督」だ ── タスクを切り、書き、レビューし、デプロイし、また次のタスクを切る。各工程で人間がボトルネックとして座っていた。Claude Code が変えるのは、その座っている場所そのものだ。

新しい役回りは「庭師」に近い。土壌 (環境) を整え、水路 (フック) を引き、種 (計画) を撒く。芽 (エージェント) は自分で伸びる。庭師は毎日剪定するわけではなく、たまに見回って、邪魔な枝を切り、新しい区画を作る。本書はこの庭師の道具一式を扱う。

「監督」の語彙で本書を読まないでほしい。タスクを次々と振る話ではない。振らなくていい状態をどう作るかの話だ。

本書の十二章を貫く骨格は、最初の三十分で押さえてしまうのがいい。Claude Code が「人を介さずに動く」道は、原理的にはたった三つしかない ── イベントに反応するか、時刻に起動されるか、自分で回り続けるか。あらゆる自動化は、この三つの組み合わせに分解できる。

I. 思想反応 (Reactive) ── Hooks

第一の柱は Hooks だ。Claude Code には設定ファイル (~/.claude/settings.json あるいはプロジェクトの .claude/settings.json) で、特定のイベントに対してシェルコマンドを発火させる仕組みがある。種類は数えるほどしかない:

Hook	発火タイミング	典型用途
PreToolUse	ツール実行直前	危険なコマンドのブロック、引数の検査
PostToolUse	ツール実行直後	フォーマッタ・リンタの自動実行
UserPromptSubmit	ユーザー入力の直後	文脈の自動付加、ガードレール
Stop	セッション終了時	ビルド検証、サマリ生成
SessionStart	セッション開始時	前回サマリの読み込み

Hooks の本質は「イベント駆動」だ。ユーザーが何かをしたとき、エージェントが何かをしたとき、その瞬間に決められた手続きを差し込む。これによって「tsc --noEmit を手で叩く」「フォーマッタを思い出して走らせる」といった作業は、書いた瞬間から消える。

I. 思想起動 (Time-driven) ── Scheduled Agents

第二の柱は Scheduled Agents ── 時刻ベースの起動だ。Claude Code には CronCreate 系のスケジューラがあり、リモートで定期的にエージェントを走らせることができる。/schedule スラッシュコマンドで対話的に登録できる。

朝 9 時に「昨日のオープン PR を確認して優先順位を Slack に投稿せよ」というルーチンを組んでおけば、出社前に一日の地図が出来上がっている。深夜 2 時に「依存パッケージの脆弱性スキャンを走らせ、CRITICAL があれば issue を起票せよ」と仕込んでおけば、朝には対応すべき issue だけが Linear に並んでいる。

I. 思想継続 (Self-driving) ── Loops

第三の柱は Loop ── 自律的な反復実行だ。/loop スラッシュコマンドで起動でき、間隔を指定すれば「5分ごとにこの作業をやれ」、間隔を省けば「自分でペースを決めて続けろ」と命じられる。後者の場合、エージェント自身が ScheduleWakeup で次の起動時刻を決める。

典型的な使い道は「ある条件が満たされるまで何度でもトライする」開発タスクだ。失敗したテストが通るまで、ビルドが緑になるまで、評価スコアが閾値を超えるまで ── 人間が「もう一回」と言わなくても、エージェントが自分で勝手に再挑戦する。この継続性こそが、開発に本当の意味の「無人」を持ち込む。

II. 実務三本柱の組み合わせ方

三つは独立ではなく、組み合わせて使う。実例で見せよう。

• 朝のレビュー: 9:00 にスケジュールで起動 (柱2) → オープン PR を一つずつレビュー (柱3 のループ) → レビューごとに PostToolUse でログを Slack に投稿 (柱1)
• テスト自動修復: ファイル保存の PostToolUse で vitest を起動 (柱1) → 失敗したら /loop でテスト修復ループを開始 (柱3) → 全て緑になったら停止
• 夜のクリーンアップ: 深夜 2:00 起動 (柱2) → 古いブランチ削除、依存更新、CI 状態確認 (柱3 で順次) → 問題があれば翌朝向けに issue 起票 (柱1)

この三本柱を頭に入れた上で、以降の章では「どの工程で、どの柱を、どう使うか」を順に見ていく。

自律エージェントの最初の敵は権限プロンプトだ。実行のたびに「このコマンドを許可しますか?」と聞かれていては、人がいない時間にエージェントが止まってしまう。場づくりとは、つまり 「いちいち聞かない」を設計することに他ならない。

I. 思想settings.json の三層

Claude Code の設定は三層構造になっている ── 上から優先される:

ファイル	場所	用途
.claude/settings.local.json	プロジェクト直下 (gitignore)	個人の上書き、秘密
.claude/settings.json	プロジェクト直下 (commit)	チーム共有の設定
~/.claude/settings.json	ユーザーホーム	個人グローバル設定

原則は単純だ ── 個人のホームには「自分専用の癖」、プロジェクトの settings.json には「チームで共有すべき自律装置」を置く。MCP サーバーの API キーや個人的なテーマは前者へ、PostToolUse のフォーマッタ起動やプロジェクト固有の許可コマンドは後者へ。

II. 実務permissions で許可を前倒しする

自律実行を阻む第一の壁は permissions だ。デフォルトでは Bash や Edit のたびに人が許可することになるが、これでは無人化はあり得ない。安全と利便のバランスを設計する。

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Read(//**)",
      "WebFetch(domain:docs.anthropic.com)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Bash(curl:*)"
    ]
  }
}

ポイントは 「読み取り系・ローカル限定・冪等」の三条件を満たすコマンドだけを allow に入れることだ。git status や npm test は何度走らせても副作用がない (冪等) し、外部に影響しない (ローカル限定) し、状態を返すだけ (読み取り系)。これらは無人化しても安全だ。

逆に curl、git push --force、rm -rf のような「外に出る」「破壊的」「不可逆」なコマンドは deny に入れる。エージェントが間違って手を伸ばしても、deny は強い壁として働く。

II. 実務env と statusLine ── 場の調整

settings.json には env でセッション全体の環境変数を、statusLine で常時表示する情報を仕込める。後者は「人間が見にくる回数」を減らすのに効く。

{
  "env": {
    "MAX_THINKING_TOKENS": "20000",
    "BASH_DEFAULT_TIMEOUT_MS": "120000"
  },
  "statusLine": {
    "type": "command",
    "command": "echo \"$(git branch --show-current) | $(git status --porcelain | wc -l) files dirty\""
  }
}

statusLine に「ブランチ名と未コミットのファイル数」を出しておけば、画面を切り替えなくても作業の安全度が分かる。「人に介入させない」自律設計は、同時に「人が見にきたときに必要な情報がそこにある」状態を作ることでもある。

III. 場面どんな時に何を使うか

ここまで道具 ── 三層構造、permissions、env、statusLine ── を並べてきた。次に問うべきは、それぞれを実際の現場でどう使い分けるかだ。代表的な場面ごとに、設定の組み立て方が変わる。

場面1: 夜間に走らせるテスト修復ループ ── 寝ている間にエージェントが赤いテストを直し、朝の差分を確認するだけにする運用。鍵は 長時間動かしても止まらないこと。.claude/settings.json に Bash(npm test:*)、Bash(npm run lint -- --fix:*)、Edit、Write を allow し、env で BASH_DEFAULT_TIMEOUT_MS を 600000 (10分) に伸ばす。重いテストスイートで途中切れを起こさせない。statusLine には「失敗テスト数」を出しておくと、朝に画面を見るだけで進捗が分かる。

場面2: PR コメントに自動応答するエージェント ── レビュー指摘を拾って修正コミットを返す運用。ここでは外への副作用を最小化することが最優先になる。Bash(gh pr view:*) や Bash(gh pr diff:*) は allow、Bash(gh repo delete:*) と Bash(git push --force:*) は deny に入れる。GitHub の個人アクセストークンや MCP の認証情報は .claude/settings.local.json 側に置き、リポジトリにコミットしない。statusLine には「監視中の PR 数」を出し、暴走していないか人がいつでも確認できる状態を作る。

場面3: ドキュメント生成・更新ボット ── コード変更に追従して docs を自動更新する用途。ここの定石は「読み取りはほぼ全許可、書き込みは特定パスのみ」。Read(//**) でリポジトリ全体を読ませる (副作用なし) 一方、Write(./docs/**) と Edit(./docs/**) だけを allow して他のディレクトリには手を出させない。WebFetch も domain:docs.anthropic.com のように取得先を絞り、勝手な外部参照を防ぐ。

場面4: 個人の日常開発 (= 一人で対話的に触る時) ── 自律ループは回さず、その場のやり取りで開発する場合。ここで効くのは ~/.claude/settings.json ── つまりホーム側の設定だ。好きなテーマや常用モデル、Linear / Notion / Slack の個人トークンはすべてここに集約する。プロジェクトを移っても自分の作業環境は変わらない。プロジェクト固有のビルドコマンドや CI 用 allow は .claude/settings.json 側 ── つまりそのリポジトリで完結する設定に置く。

自律性を阻む第二の敵は文脈の喪失だ。エージェントは賢いが、毎回の起動時に「君はこの会社のこのプロジェクトで…」と説明されないと動けないなら、それは自律ではない。本章では、文脈を言葉ではなく構造として据える三つの仕組みを扱う。

I. 思想三層の文脈 ── 永続・記憶・専門知

Claude Code が参照する文脈は、原則として三層ある:

層	仕組み	性質
永続的	CLAUDE.md	セッション開始時に必ず読み込まれる
連続的	Memory システム	会話を跨いで蓄積される事実
専門的	Skills	必要なときだけ呼び出される

この三層を意識的に分けることが、文脈管理の出発点だ。よく見るアンチパターンは、すべてを CLAUDE.md に詰め込んでしまうこと。CLAUDE.md は毎回読み込まれるので、肥大化するとトークン予算を圧迫し、本来集中すべき内容が薄まる。

II. 実務CLAUDE.md ── 「初日の上司」が言うこと

CLAUDE.md には何を書くか。「新人エンジニアが入社初日に上司から言われそうな、しかし聞かないと分からないこと」だけを書く、と覚えるとよい。

• ディレクトリ構成 (見れば分かる以上の意味、例: 「/docs は GitHub Pages の公開ルートだから消すな」)
• 作業のフロー (新しい教科書を作るときの三ステップ、など)
• 絶対にやってはいけないこと (リネーム禁止のファイル、触れてはいけない設定)
• 共有された設計判断 (「テキストの色は --color-ink を使う、ハードコードしない」)

逆に CLAUDE.md に書かないものも明確だ ── ユーザー個人の癖、フィードバックの履歴、外部システムへのポインタ。これらは Memory に書く。

II. 実務Memory ── 「二度言わせない」装置

Memory は会話を跨いで保持される事実の倉庫だ。~/.claude/projects/<path>/memory/ に Markdown ファイルとして保存される。種類はおよそ四つ:

種類	記録するもの	例
user	ユーザーの役割・嗜好・知識	「Go 歴 10 年・React は初心者」
feedback	修正・確認された行動指針	「テストでモック禁止、本番 DB に当てる」
project	進行中の事情・締切・体制	「金曜まで feature freeze」
reference	外部システムへのポインタ	「バグは Linear の INGEST プロジェクト」

feedback 型は特に重要で、ユーザーが「いや、それは違う、こうしてくれ」と言った瞬間に保存する。同じ訂正を二度しなくて済むことが、自律性の前提条件だ。

II. 実務Skills ── 必要なときだけ呼ぶ専門知

Skills は「Django のセキュリティ実践」「Rust の所有権パターン」のように、特定の状況でだけ参照すべき深い専門知識を切り出した仕組みだ。~/.claude/skills/<name>/SKILL.md に書く。常時読み込まれず、関連する作業のときだけ呼び出される。

Skill には「description」フィールドで「いつ呼び出すか」を書く。例えば django-security なら「Django プロジェクトの認証・認可・CSRF・SQL インジェクション対策が必要なとき」と書く。Claude Code はユーザーのプロンプトを見て、必要そうな Skill を自動で読み込む。

第1章で挙げた三本柱の最初、反応を支えるのが Hooks だ。本章ではその全種類を順に組み立て、開発工程から「人が思い出して叩くコマンド」を一つずつ消していく。

I. 思想Hooks は副作用の置き場

Hooks の基本形は次のような JSON だ。matcher (どのツールに反応するか) と command (何を実行するか) を組み合わせる。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "pnpm prettier --write \"$CLAUDE_FILE_PATHS\"" }
        ]
      }
    ]
  }
}

これだけで、Claude Code がファイルを書き換えるたびに Prettier が自動で整形する。あなたは「フォーマッタを忘れた」と二度と言わなくていい。Hooks は副作用の置き場であり、開発工程の脇に小さなスクリプトを並べていく作業だ。

II. 実務PostToolUse の三段重ね

典型的なフロントエンドプロジェクトなら、PostToolUse は三段重ねがいい。format → lint → typecheck の順だ。

{
  "hooks": {
    "PostToolUse": [
      { "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "pnpm prettier --write \"$CLAUDE_FILE_PATHS\"" },
          { "type": "command", "command": "pnpm eslint --fix \"$CLAUDE_FILE_PATHS\"" },
          { "type": "command", "command": "pnpm tsc --noEmit" }
        ]
      }
    ]
  }
}

この順序は無作為ではない ── 整形してからリンタが意味のあるエラーを出し、型チェックがその両方を前提に走る。順序を逆にすると、prettier の前に eslint が文句を言うようなノイズが増える。

II. 実務PreToolUse でガードレールを引く

PreToolUse は実行を止める権限を持つ。終了コード 2 を返すとツール実行がブロックされる。これを使って、危険な行為を構造的に禁じる:

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "Bash",
        "hooks": [
          { "type": "command",
            "command": "node -e \"let d='';process.stdin.on('data',c=>d+=c);process.stdin.on('end',()=>{const cmd=JSON.parse(d).tool_input?.command||'';if(/git\\s+push\\s+--force/.test(cmd)){console.error('[Hook] force push blocked');process.exit(2)}console.log(d)})\""
          }
        ]
      }
    ]
  }
}

permissions の deny でも似たことはできるが、PreToolUse はもっと細かい判断 ── 「この時間帯は本番デプロイ禁止」「このブランチでは破壊的変更を許可しない」── を組み込める。場のルールを動的に強制する装置として使う。

II. 実務SessionStart と Stop で「区切り」を作る

セッション境界に対する Hook はパワフルだ。SessionStart で前回のサマリを自動読み込みし、Stop で最終ビルドを走らせる ── これだけで、会話の連続性と最終品質の両方が無人で担保される。

{
  "hooks": {
    "SessionStart": [
      { "hooks": [
          { "type": "command", "command": "cat .claude/last-session.md 2>/dev/null || echo 'no prior session'" }
        ]
      }
    ],
    "Stop": [
      { "hooks": [
          { "type": "command", "command": "pnpm build && pnpm test --run" }
        ]
      }
    ]
  }
}

II. 実務UserPromptSubmit で文脈を自動付加

ユーザーのプロンプトが送られた瞬間に介入できるのが UserPromptSubmit だ。例えば「Linear のチケット番号を含むプロンプトには、自動でそのチケットの詳細を文脈として付加する」といった補助が組める。

これは「人が貼り付け作業をしなくて済む」方向の自動化だ。プロンプトを書く側の手間を機械的に削っていくと、エージェントを使うコストが時間と意志の両面で下がっていく。

Hooks は「何かが起きたら走る」装置だが、何も起きていない夜中にも走らせたい仕事がある。脆弱性スキャン、依存パッケージの更新確認、古いブランチの掃除、定期レポート ── これらは時刻ベースで起動するのが自然だ。三本柱の第二、Scheduled Agents を組む。

I. 思想Cron の何が新しいか

「Cron なんて 1975 年からある」── その通り。しかし Claude Code の Scheduled Agents は、cron の枠に判断する主体を載せたところが新しい。1975 年の cron は「決まった時刻に決まったスクリプトを動かす」だけだったが、いま cron がトリガするのは「状況を見て、何が必要か判断するエージェント」だ。

これによって、ルーチンと判断の境界が消える。「毎日 9 時に PR をレビューする」というルーチンは存在するが、何をどう優先するかはエージェントが当日に決める。形式は cron、中身は判断。

II. 実務/schedule で対話的に組む

Claude Code には /schedule スラッシュコマンドがあり、対話的にルーチンを登録できる。中で問われるのは三点だけだ ── いつ走らせるか、何をさせるか、結果をどこに置くか。

典型的なものをいくつか挙げる:

• 朝の整列 ── 平日 8:30 に「未マージの PR と Linear のオープン issue を確認し、優先順位を Slack の #daily-standup に投稿せよ」
• 夜の掃除 ── 毎晩 23:00 に「マージ済みのローカルブランチを削除、node_modules の使用量を確認、容量が閾値を超えたら通知」
• 週の総括 ── 毎週金曜 17:00 に「今週のコミット・PR・issue の数を集計、Notion の週報ページに追記」
• 依存の点検 ── 日曜 3:00 に「依存パッケージの脆弱性スキャン、CRITICAL があれば issue 起票」

II. 実務「人が見にくる時間」に揃える

スケジュールの設計で陥りやすい罠は、機械の都合で時刻を選ぶことだ。「リソースが空いている深夜 3 時」「CI が静かな日曜朝」── これは自動化の昔の発想だ。判断する主体としてのエージェントを使うなら、「人が結果を見にくる時間の少し前」に揃えるほうが圧倒的に価値が出る。

朝の整列は出社の 30 分前。夜の掃除は寝る前のレビューに間に合う時刻。週の総括は退勤前。エージェントは判断を済ませた状態で結果を置いておき、人間は出来上がりに目を通すだけになる。

II. 実務RemoteTrigger ── スケジュール以外の起動

時刻起動の親戚として RemoteTrigger がある。これは GitHub Webhook や外部システムからの信号でエージェントを起動する仕組みだ。「PR がマージされたら本番デプロイ前点検を走らせる」「Linear で特定のラベルが付いたら自動で着手する」といった連携が組める。

Scheduled と Remote を組み合わせると、エージェントはカレンダーと外部イベントの両方から目を覚ます存在になる。あなたが起動しなくても、世界の側が起こしてくれる。

三本柱の最後、継続は最も強力で、最も危険でもある。一度動き出したエージェントが、終了条件を満たすまで自分で何度でも回り続ける ── これが自律ループだ。本章では /loop と ScheduleWakeup を使ったループ設計の作法を扱う。

I. 思想Ralph パターン ── ループは思想である

「Ralph」と呼ばれる設計パターンがある。Geoffrey Huntley が提唱したもので、要点は単純だ ── 同じプロンプトを until ループで何度も走らせる。「テストが全部通るまで」「評価スコアが 8 を超えるまで」「TODO が空になるまで」。

これは奇妙に見えて、極めて強い。人間がやろうとすると「もう一回やってくれ」「あと少し」「次はこの観点で」と言い続ける必要がある作業を、ループに置き換えれば一度の指示で済む。終了条件さえ書ければ、その後は機械が回す。

II. 実務/loop の二つのモード

Claude Code の /loop には二つのモードがある:

モード	指定	挙動
固定間隔	/loop 5m <task>	5 分ごとに同じタスクを実行
動的ペーシング	/loop <task>	エージェント自身が次の起動時刻を決める

動的モードでは、エージェントが ScheduleWakeup を呼んで「次は 20 分後に起きる」と自分で決める。プロンプトキャッシュの 5 分 TTL を意識して、CI を見張るような短時間ポーリングなら 270 秒、特に急がない定常監視なら 1200〜1800 秒、というのが定石だ。

II. 実務終了条件 ── ループは終わらせるために設計する

ループを始めるのは簡単だが、終わらせるのが難しい。本書の最も重要な実務的助言を、太字で残しておく:

典型的な終了条件は三種類:

• 達成条件: 目的が満たされた (テスト緑、評価閾値超え)
• 反復上限: 最大 N 回のループで打ち切り
• 時間制限: 最大 X 時間で打ち切り

実務的にはこの三つを OR で組み合わせるのがいい。達成条件だけだと永遠に届かない可能性があり、反復上限だけだと「もう少しで届きそう」を取りこぼす。

II. 実務サーキットブレーカ ── 暴走を止める

終了条件とは別に、異常の検知でループを止める仕組みが要る。これがサーキットブレーカだ。実装はシンプルでいい:

• 連続失敗: 同じエラーで 3 回連続失敗したら停止
• 同じ差分: 直前の反復と全く同じ変更を提案したら停止 (進捗していない)
• 外部信号: .claude/STOP のような halt ファイルが存在したら停止

.claude/STOP のような halt ファイルは特に便利だ。離れた場所からでも、touch .claude/STOP 一発でループを終わらせられる ── ループ自体に「次の起動前にこのファイルを見て、あったら終了」と命じておけば。

II. 実務ループと Hooks の組み合わせ

三本柱の威力は組み合わせで出る。例えば「失敗するテストを通すまで自動で修復する」ループは、こうなる:

1. ファイル保存時の PostToolUse で vitest が起動する (柱1: 反応)
2. テストが失敗したら自動で /loop fix-failing-tests が始まる (柱3: 継続)
3. 各反復で失敗テストを 1 つ修復、再実行
4. 全テスト緑、または最大 10 反復で停止
5. 結果を Slack に投稿 (Hooks で副作用)

このセット一式が一度組まれれば、人間は「テストが失敗した」と気付くこと自体がなくなる。失敗は気付かれる前に直っている状態が常態になる。

三本柱が場の話だとすれば、ここから先は工程の話だ。最初に手放すべきは 計画工程。要件を聞いて、課題を分解して、タスクに落として、見積もる ── 従来は人間の中核的な仕事だったが、Claude Code はこのほとんどを引き受けられる。

I. 思想計画は仕様の翻訳である

「計画」というと創造的な響きがあるが、その実態は仕様 (やりたいこと) を、工程 (やる順序) に翻訳する作業だ。曖昧さは仕様の側に残しておくのが正解で、それを工程に変換するのは機械的な仕事に近い。だからこそ自動化に向く。

II. 実務planner agent と Plan Mode

Claude Code には planner という専用エージェントがあり、複雑な要件を投げると以下を出力する:

• 影響範囲の見立て (どのファイルが変わるか)
• 分解されたタスクリスト
• 各タスクの順序とブロッキング関係
• リスクとトレードオフの整理

これを単独で呼ぶこともできるが、より使いやすいのは Plan Modeだ。Shift+Tab で切り替えると、コードを書かずに計画だけを出してくれる。人間は計画に対して承認・修正をするだけでよくなる。

II. 実務TodoWrite で進捗を見えるようにする

計画が承認されたら、TodoWrite で実装フェーズに移る。これは「タスクの List/Update を Claude Code 側に管理させる」仕組みで、完了するごとに状態が更新される。

このとき重要なのは、TodoWrite はユーザー向けの可視化でもあるが、エージェント向けの自己整理装置でもあること。長いタスクを抱えたエージェントは、TodoWrite を見ながら「次は何をすべきか」を自分で判断する。明示的なタスク分解は、エージェントの自律性そのものを高める。

II. 実務RFC 駆動 ── 大きな仕事は仕様書から書かせる

機能規模が大きくなると、Plan Mode だけでは足りない。RFC (Request for Comments) ドキュメントを起点にする方式が向いている。流れは概ねこうだ:

1. 一行の要件を投げる: 「ユーザー認証を Magic Link 対応にする」
2. エージェントが RFC を起草: 動機・現状・提案・代替案・移行手順・リスク
3. RFC をレビュー (人間が一度だけ介入)
4. RFC を入力として、別エージェントが実装計画を生成
5. 実装計画を入力として、複数のサブエージェントが並列着手 (第8章で扱う)

この方式の妙は、仕様が文書として残ることだ。半年後に「なぜこう作ったのか」と聞かれても RFC を見れば分かる。AI 生成の活動を人間の組織が呑み込むには、こうした記録性が要る。

II. 実務計画と実装の境目を曖昧にしない

もっとも避けたいアンチパターンは、「計画なしの実装ループ」だ。スピードが上がって見えるが、エージェントは方向を見失い、無駄な実装を積み重ねる。Plan Mode で必ず最初に止まる、というルールを CLAUDE.md に書いておくのは有効だ。

計画ができたら、実装。だが「一つの会話で全部書く」のは、現代の Claude Code 利用としては素朴すぎる。本章では並列実行とサブエージェント編成で、開発の時間軸そのものを圧縮する方法を扱う。

I. 思想主と従、context window の分業

Claude Code の Agent ツールは、「サブエージェントを生やす」装置だ。主のエージェントが大局を見て、従のエージェントが特定の作業 (検索、実装、評価) を担当する。これは生産性のためだけではない ── 主の context window を汚さないという重要な意味がある。

例えば「コードベース全体から認証ロジックを探す」作業は、主のエージェントが直接やると数百ファイルの中身が全部 context に流れ込んでしまう。サブエージェントに任せれば、主には「結果のサマリ」だけが返り、context は綺麗に保たれる。

II. 実務並列起動の作法

サブエージェントは並列に走らせられる。一つのメッセージの中で複数の Agent ツール呼び出しを並べると、それらは同時に実行される。独立して動ける作業 ── 別ファイルの実装、別ライブラリの調査、異なる観点からの評価 ── はすべて並列化の対象だ。

典型例として、ある機能を実装するときに以下を並列で走らせる:

• Agent A: バックエンド API のエンドポイント実装
• Agent B: フロントエンドのコンポーネント実装
• Agent C: テストケースの起草
• Agent D: ドキュメントの下書き

四つの作業が同時に進む。それぞれが終わって主のエージェントに戻ってきたところで、つなぎ合わせとレビューだけを主が担当する。時間軸が一本から四本に分かれる。

II. 実務worktree で物理的に隔離する

並列実行で最大の問題は衝突だ。同じファイルを二つのエージェントが同時に編集すれば、片方の変更が消える。これを構造的に防ぐのが git worktreeだ。Agent ツールには isolation: "worktree" オプションがあり、サブエージェントを別の worktree (別ディレクトリ、別ブランチ) で走らせられる。

結果としてサブエージェントの変更はメインの作業ディレクトリに混ざらず、後から git のマージで合流する。並列化はマージで合流させるのが基本フォームだ。

II. 実務専門エージェントの選び方

Claude Code には用途別のサブエージェント型が用意されている。Agent ツールの subagent_type で指定する:

エージェント型	用途
Explore	読み取り専用のコード探索
planner	実装計画の起草
code-reviewer	コード品質レビュー
security-reviewer	セキュリティ脆弱性検出
typescript-reviewer 他	言語別の専門レビュー
build-error-resolver	ビルドエラーの最小修正
tdd-guide	テスト先行開発の指南
e2e-runner	E2E テストの生成と実行
doc-updater	ドキュメント更新

これらは主エージェントを汎用的に保つための分業装置だ。主が「ビルドエラーを直そう」と試行錯誤するより、build-error-resolver に投げて結果だけ受け取るほうが、主の context も時間も節約できる。

II. 実務DevFleet と DAG パイプライン

並列度を上げると、いずれ DAG (有向非巡回グラフ) としての設計が必要になる。「A の完了を待って B と C を並列起動、両方終わったら D を起動」というパターンだ。

Claude DevFleet や Ralphinho RFC パイプラインといった仕組みは、この DAG 実行を専門に扱う。RFC を入力として、フェーズごとに並列化された複数のサブエージェントを順次走らせ、最後に結果を合流させる。人間が指揮棒を振らなくても、計画書が指揮棒を振る状態が作れる。

エージェントが実装するなら、検証もエージェントに任せたい。無人化されていない検証は、人間がボトルネックの一番大きな箇所になる。本章では検証の三層 ── テスト・コードレビュー・セキュリティ ── をすべて自動化する。

I. 思想「自分が書いて自分が見直す」のリスク

素朴な自律実装は、同じエージェントが「実装」と「レビュー」を兼ねがちだ。これは AI の盲点を見落とす最悪のパターンになる。生成と評価は別のエージェント、別のプロセス、別の観点で行う── これが自律検証の鉄則だ。

具体的には三つの層を分けて持つ:

1. テスト層: 仕様レベルで「動くか」を機械的に検査
2. レビュー層: コード品質・パターン・命名を別のエージェントが検査
3. セキュリティ層: 脆弱性パターンを専門エージェントが検査

II. 実務TDD ループの自動化

tdd-guide エージェントは TDD の流儀を機械化したものだ。要件を入れると、まず失敗するテストを書き、それを通す実装を書き、リファクタする ── この赤緑赤緑のループを自分で回す。

これを /loop と組み合わせると、「テストが緑になるまで」を終了条件にした実装ループが作れる:

# 動的ペーシングで、緑になるまで継続
/loop tdd-guide で機能 X を実装し、すべてのテストが緑になるまで続けよ
        ── 最大 15 反復で打ち切り、緑なら停止

これが第6章のループ作法と直結する点だ。検証は「緑」というクリアな終了条件を持っているので、ループ化と最も相性がいい。

II. 実務code-reviewer の常時起動

code-reviewer はコード品質のレビュー専門エージェントで、書かれた直後に走らせるのが原則だ。これを Stop hook あるいは PostToolUse に仕込むと、人間が「あとでレビューしよう」と思う前にレビューが終わっている。

{
  "hooks": {
    "Stop": [
      { "hooks": [
          { "type": "command",
            "command": "claude -p 'code-reviewer agent を起動し、今セッションの差分をレビューせよ' --output-format json > .claude/last-review.json"
          }
        ]
      }
    ]
  }
}

レビュー結果は .claude/last-review.json に置かれ、次のセッション開始時に SessionStart hook で読み込まれる ── 一連の輪が閉じる。

II. 実務security-reviewer は早めに、何度も

セキュリティレビューは「最後にやる」が最悪の流儀だ。実装が深まるほど、修正コストが上がる。security-reviewer は次のような場面で能動的に呼び出す:

• ユーザー入力を扱うコードを書いたとき
• 認証・認可を触ったとき
• 外部 API・ファイルシステム・DB へのアクセスを追加したとき
• 環境変数を新しく追加したとき

PostToolUse で git diff のパターンを見て自動起動する、というルールにしておくと無人化できる。「auth.ts が変更されたら security-reviewer」「.env.* が変更されたら security-reviewer」── 単純なファイル名ベースのトリガで十分効く。

II. 実務品質ゲート ── マージ前の最後の壁

無人化した検証の集大成が品質ゲートだ。マージ可能になるための条件を、機械検証可能な形で列挙する:

• すべてのテストが緑
• カバレッジ 80% 以上
• 型エラーゼロ
• code-reviewer が CRITICAL / HIGH を返していない
• security-reviewer が CRITICAL を返していない
• ビルドが成功

これを verification-loop スキルや /verify-all コマンドにまとめると、一発で全てが走る。人間のレビューに来る前に、機械が通せるものは機械が通す。

無人化のもう一つの壁は外部システムだ。Slack に通知する、Linear に issue を起票する、Notion にドキュメントを残す ── これらが「人間が手でやる作業」として残っていると、自動化は中途半端で終わる。本章では MCP (Model Context Protocol) を使って、外部系を直接エージェントに操作させる。

I. 思想MCP とは何か ── 道具を増やす規格

MCP は Anthropic が公開した、エージェントに新しいツールを与えるためのオープンな規格だ。プロトコルは単純で、サーバ側が「使えるツール一覧」「使えるリソース一覧」「使えるプロンプト一覧」を提供し、Claude Code が必要に応じてそれらを呼ぶ。

2025〜2026 年で公式・サードパーティ製の MCP サーバが急増し、Gmail・Google Calendar・Slack・Notion・GitHub・Sentry・Stripe ── 普段使うサービスのほとんどに繋げられるようになった。これが意味するのは 「ブラウザを開かなくていい仕事」が一気に増えたことだ。

II. 実務典型的な MCP の繋ぎ先

MCP	無人化される作業
Slack	定型通知、レポート投稿、チャネル要約
Gmail	受信トリアージ、下書き作成、定型返信
Google Calendar	予定確認、空き枠提案、ミーティング設定
Google Drive / Docs	ドキュメント生成・更新、共有設定
Notion	議事録、週報、ナレッジベース
Linear / Jira	issue 起票、ステータス更新、コメント
GitHub	PR・issue・レビュー (gh CLI でも代替可)
Sentry	エラー集計、トリアージ、関連 issue 検出

II. 実務「ブラウザを開かない」基準

MCP の使い方の指針は単純だ。「ブラウザを開いて手で操作している作業」を全部リストアップし、それぞれに MCP があるか調べる。あれば繋ぐ。なければ自作するか、当面は半自動 (CLI でラップ) で済ます。

典型的なオフィスワーカーの一日に出てくる作業をこの基準で見ると、半分以上は MCP 経由で消せる。Slack を開いてチャネルを巡回する作業、Linear を見て進捗を更新する作業、Calendar を開いて空きを探す作業 ── これらは全て、エージェントが直接やれる。

II. 実務三本柱との掛け合わせ

MCP は三本柱と組み合わせて初めて真価を発揮する:

• Hooks × MCP: PR が作成されたら自動で Slack に通知 (PostToolUse + Slack MCP)
• Cron × MCP: 毎朝 Linear のオープン issue を集計し、Notion の週報に追記 (/schedule + Linear MCP + Notion MCP)
• Loop × MCP: Sentry のエラーを順に読み、再現可能なものだけ自動で issue 起票 (loop + Sentry MCP + GitHub MCP)

三本柱はエージェントの行動原理、MCP はその行動範囲。両方が揃って初めて、本当の意味での「無人」が成立する。

II. 実務自作 MCP ── 内製システムを繋ぐ

外部 SaaS は MCP 公式があるが、社内の内製システム (社内 API、独自 DB、ドメイン固有のサービス) は自分で MCP サーバを書くことになる。これは TypeScript SDK か Python SDK で書ける ── 数十行から始められる。

自作 MCP の典型用途:

• 社内の顧客 DB を、エージェントから安全に検索可能にする
• 社内 KPI ダッシュボードの値を、エージェントが直接取得できるようにする
• 独自デプロイパイプラインを、エージェントがトリガできるようにする

ここで重要なのは 権限境界だ。MCP サーバは「エージェントが使える社内 API のゲートウェイ」になる。何を許し、何を禁じるかをサーバ側で設計する。エージェントは賢いが、悪意なく危険な操作に手を出すこともある。

無人化された仕組みは、放っておくと同じ失敗を繰り返す。前回のセッションで学んだことが、次のセッションでは忘れられている ── これでは「監督」を呼び戻したくなる。本章では、エージェントが時間をまたいで賢くなる三つの仕掛けを扱う。

I. 思想記憶・instinct・skill の階段

エージェントの学習は段階的に整理できる:

段	名前	性質
1	Memory	個別の事実・指示・好み
2	Instinct	確信度付きの行動傾向 (まだ仮説)
3	Skill	確立された再利用可能な手順

低い段で発見されたことは、信頼度が上がるにつれて高い段へ昇格する。最初は単なる Memory だった「テストでモック使わない」が、何度も似た文脈で適用されて Instinct になり、ある日「testing-no-mocks という名前の Skill に昇格させる」と判断される ── これが Continuous Learning の根幹だ。

II. 実務Memory の書き方

第3章で扱った Memory システムは、自律性のためには能動的に書く必要がある。指示や訂正があったら、その瞬間に保存する。書き方の作法は単純だ:

• feedback 型には Why と How to apply を必ず添える
• project 型には絶対日付を残す ("木曜まで" ではなく "2026-05-15 まで")
• user 型はネガティブ評価を書かない ── 役立てるための情報だけ
• reference 型は URL・チャネル・プロジェクト名のような場所を残す

記憶の負債を作らないコツは 「コード/履歴から復元できる情報は書かない」。アーキテクチャ・最近のコミット・ファイル構造は git や read で取れる。書くべきは取れない情報、つまり判断の理由と外部の事情だ。

II. 実務Continuous Learning の自動抽出

Memory をセッションごとに手で書くのは面倒だ。continuous-learning スキルや continuous-learning-v2 は、これを自動化する仕組みだ。セッション終了時 (Stop hook) にエージェントが会話を振り返り、抽出可能な学びを Memory または Instinct として保存する。

v2 では確信度スコアが導入され、最初は Instinct (仮説) として保存され、同種の文脈で何度か再利用された後に Skill へ昇格する。「一度起きたこと」と「繰り返し起きること」を分けて扱うのがポイントだ。

II. 実務Skill の自作 ── 再利用可能な手順を残す

Instinct が育って「これは何度も使う」となったら、Skill に昇格させる。Skill は ~/.claude/skills/<name>/SKILL.md に書く。description フィールドが「いつ呼び出すか」の判断材料になるので、ここを丁寧に書く。

Skill 化の判断基準は二つだ:

• 同じパターンが少なくとも三回以上現れた
• 呼び出される文脈が明確に書ける

逆に、特定プロジェクト固有の知識は CLAUDE.md に書くべきで、Skill にすべきでない。Skill はプロジェクト横断で使える専門知識の置き場であって、特定の場所の常識ではない。

II. 実務学習の負債を払う

学習システムは、不要な記憶を削除する仕組みも必要だ。時間で陳腐化する事実 (締切、体制) は、定期的にスケジュールでレビューして消す。間違った Memory は積極的に上書きする。Skill は半年に一度棚卸しする (skill-stocktake スキルが助ける)。

無人化のもっとも誤解されやすい点は、「無人」≠「無監視」だ。エージェントが回り続けている以上、何が起きているかを常に観測可能にしておく必要がある。本章は自律システムの観測・介入設計を扱う ── 言い換えれば、庭師が見回りに使う道具の話だ。

I. 思想「見ない」のは「見えない」とは違う

自律化された仕組みは、通常は人間の目に触れない。しかし必要なときに見られる状態は維持しなければならない。これは銀行口座と似ている ── 毎日見るわけではないが、見たいときに残高が分かる必要がある。

観測の設計目標は三つだ:

1. 気付ける: 異常が起きたら、人間が呼ばれる
2. 遡れる: 何が起きたか、後から追える
3. 止められる: 介入したいとき、安全に止められる

II. 実務気付ける ── 通知の設計

気付くべき事象は限られている。通知が多すぎる自律システムは、結局見られなくなる。設計する観点は次のあたり:

• 失敗: ループが終了条件を満たさず最大反復で止まった
• 停滞: 同じエラーが連続して出続けている
• 逸脱: PreToolUse で想定外のコマンドがブロックされた
• 異常コスト: 想定を大きく超えるトークン消費が発生した
• 外部依存: MCP サーバや CI が落ちている

これらだけを Slack や Push 通知に出す。「成功した」は通知しない。成功は静かに済むのが自律システムの美徳だ。

II. 実務遡れる ── ログとアーティファクト

Claude Code のセッションは ~/.claude/projects/<path>/ 配下に保存される。会話ログ、ツール呼び出し、各種出力は復元可能な形で残る。さらに重要な作業 (大きな計画、レビュー結果、ループの集計) は明示的にアーティファクトとしてリポジトリ内に残しておく:

• .claude/plans/<date>-<feature>.md ── 計画 RFC
• .claude/reviews/<date>-<pr>.md ── レビュー結果
• .claude/loops/<date>-<task>.log ── ループの反復履歴

これらを .gitignore ではなくむしろ git に含めるほうが多くの場合いい。後から「なぜこう実装されているか」が追跡できる。

II. 実務止められる ── サーキットブレーカと halt

第6章のサーキットブレーカと連動する形で、観測側からループを止める手段を必ず用意する。シンプルで効果的なのは .claude/STOP ファイルだ:

# 別ターミナルから一発で止める
touch .claude/STOP

各ループの先頭で if [ -f .claude/STOP ]; then exit 0; fi 相当を呼ぶようにしておけば、外部から強制終了できる。Claude Code そのものを kill するより、こちらのほうが安全に状態を残せる。

II. 実務Loop Operator パターン

大規模な自律システムでは、ループそのものを監督する別エージェント (Loop Operator) を置く設計がある。Operator は数十分に一度、走っているループの状態を確認し、進捗のないループを止め、必要なら担当者に通知する。

これは観測の自動化そのものだ。「人間が見回る」を「エージェントが見回り、必要なときだけ人間を呼ぶ」に置き換える。最終層の人間は、Operator が起こしにきたときだけ動く。

II. 実務コスト観測 ── 静かに高くつく罠

自律ループの最大のリスクは「終わらない」と書いたが、その双子に 「終わらないまま課金される」がある。トークン消費は時間に比例するので、深夜にループが暴走すると朝には大きな請求になる。

コスト観測の最低限:

• セッション単位の入出力トークンを記録 (Claude Code は自動で記録する)
• 日次でトークン総量を集計し、閾値超過で通知
• ループには必ず反復上限と時間上限を二重で設定

十二章を辿ってきた。三本柱、場づくり、文脈設計、Hooks、Scheduled Agents、自律ループ、計画委譲、エージェント編成、検証自動化、MCP 連携、継続学習、観測と暴走対策。

これらを揃えると、開発の実行時間から人間はかなり姿を消す。コードはエージェントが書く。レビューもエージェントがする。デプロイはパイプラインが回す。通知はエージェントが送る。ドキュメントもエージェントが起こす。あなたが朝コーヒーを淹れている間に、夜のループが何かを直し終え、何かを記録し終え、何かを通知し終えている。

では、人間に何が残るのか。本書を通して何度か触れた答えを、ここでまとめておく。

I. 思想残るのは三つだけ

無人化を突き詰めても、人間に残る仕事は三つある:

1. 仕様策定: 何を作るか、なぜそれを作るか
2. 価値判断: 複数の選択肢のうちどれを選ぶか
3. 責任引受: 動いたものに対して責任を負う

第一の仕様策定は、「顧客が何を望んでいるか」「組織が何を必要としているか」を聞き取り、言語化する作業だ。エージェントは仕様を翻訳できるが、仕様そのものを発見することはできない。新しい価値の輪郭を引くのは、まだ人間の仕事だ。

第二の価値判断は、トレードオフの中で何を優先するかの選択だ。「速度か安全か」「シンプルさか柔軟性か」「短期成果か長期投資か」 ── これらに正解はない。組織の文脈と歴史の中で、どう判断するかが残る。

第三の責任引受は最も重い。エージェントが書いたコードがバグを起こしても、最終的に責任を負うのは人間だ。自律システムを設計し、回し、結果を引き受けるのは、まだ人間にしかできない。

I. 思想監督ではなく、庭師として

序章で「監督から庭師へ」と書いた。十二章を読んだいま、その意味は明確になっているはずだ。庭師は植物を一本一本世話しない。土壌を整え、水路を引き、季節を読み、剪定の時期を見定める。植物は自分で育つ。

Claude Code の自律的な使い方は、これに似ている。エージェントは自分で考え、書き、検証する。あなたは settings.json を整え、hooks を引き、scheduled agents を仕込み、ループの終了条件を設計する。エージェントは自分で動く。あなたは庭を歩き、新しい区画を作り、枯れた枝を剪定する。

エージェントは書く。
あなたは、書く場所を作る。

本書を読み終えて、いますぐ ~/.claude/settings.json を開きたくなったなら、それがこの本の目的だ。最初の一行のフックを書いてみる。最初のスケジュールを登録してみる。最初の小さなループを回してみる。庭はそこから広がっていく。

あなたの開発工程から、人の手が少しでも抜けますように。
あなたが、もっと上の仕事をできますように。

• Claude Code Documentation ── Anthropic 公式. docs.claude.com/en/docs/claude-code
• Claude Code: Hooks Reference ── Anthropic 公式. docs.claude.com/en/docs/claude-code/hooks
• Claude Code: Settings & Permissions ── Anthropic 公式. docs.claude.com/en/docs/claude-code/settings
• Claude Code: Subagents ── Anthropic 公式. docs.claude.com/en/docs/claude-code/sub-agents
• Claude Code: Memory ── Anthropic 公式. docs.claude.com/en/docs/claude-code/memory
• Claude Code: Skills ── Anthropic 公式. docs.claude.com/en/docs/claude-code/skills
• Model Context Protocol (MCP) Specification ── Anthropic / Open Spec. modelcontextprotocol.io
• MCP Server SDKs (TypeScript / Python) ── GitHub. github.com/modelcontextprotocol
• Ralph: Loop-Driven Coding with Claude ── Geoffrey Huntley, 2025. ghuntley.com/ralph
• Claude Code Best Practices ── Anthropic Blog, 2025. anthropic.com/engineering/claude-code-best-practices
• Building Effective Agents ── Anthropic, 2024-2025. anthropic.com/engineering/building-effective-agents
• 関連: Vol.II 「AI時代の開発手法 ── Karpathy の地図」 ── Software 3.0 とエージェント時代の整理は本書の思想的下敷きとして機能する. 本サイト内

本書は 2026 年 5 月時点の Claude Code (Opus 4.7 系) の挙動と公開仕様に準拠しています。Hooks の matcher 構文、MCP サーバ群、サブエージェント型はバージョンで動くので、自分の環境で /help を当てつつ参照してください。