優先度の低いタスクが後回しになる、というのは一人で 12 年やってきた個人開発でも、社内プロジェクトを抱えるエンジニアの方でも、同じ構造の問題だと感じます。SonicGarden の Misaki Ito さんの記事を読んで、「Claude Code の Skill で社内プロジェクトを仕組み化した話」 — まさに自分が個人開発で組みたかったパターンが整理されていました。
ここでは、SonicGarden さんの実装を起点に、Skill・Subagents・Rules の役割分担と、私が個人開発で運用するために落とし込んだ実装パターンを書き出します。累計 5,000 万ダウンロードのアプリ事業を一人で回してきた立場から、「仕組みのレールを敷くと、後回しタスクが消える」という体験談として読んでいただけると合うはずです。
なぜ「気合い」ではなく「仕組み」なのか
優先度の低いタスクは、気合いでは前に進みません。理由はシンプルで、「気合い」は外部の条件に左右されすぎるからです。当日の集中力、他の業務の状況、体調 — どれか一つが崩れると、優先度の低いタスクが最初に犠牲になります。
それなら、最初から「気合いに依存しない仕組み」を組んでおく方が、長期で安定します。SonicGarden さんの記事では、定例終了後の「後うち」の時間内に、Claude Code の Skill で複数タスクを並列実装まで完了させる、というアプローチが紹介されていました。
私のように一人で運用している場合、この「後うち」を 「週次レビュー枠の 1 時間」 と読み替えると、ぴったり当てはまります。週次レビューで進めたいタスクを洗い出し、その場で Skill を起動して、レビュー終わる頃には PR が出来ている、という流れを組めるのです。
Skill・Subagents・Rules の役割分担
Claude Code の三つの仕組みは、用途を整理すると次のような分担になります。
| 仕組み | 役割 | 寿命 |
|---|
| Skill | エントリーポイントとなるワークフロー定義。引数を受け取って手順を駆動 | プロジェクト〜全環境共有 |
| Subagents | 単一タスクを完結させる作業エージェント。並列実行可能 | 各タスクのライフサイクル |
| Rules | 環境ごとの運用ルール・PROJECT_ID・MCP 設定 | 常時コンテキスト |
この三層を頭の中で分けておくと、後で「ここはどの層で書くべきか」で迷いません。私の手元では次のような階層に整理しました。
~/.claude/
├── skills/
│ └── start/
│ └── SKILL.md ← エントリーポイント
├── rules/
│ ├── project.md ← プロジェクト管理ツール連携
│ └── tools.md ← MCP・PROJECT_ID 等
└── agents/
└── task-implementer.md ← 並列実行用のサブエージェント
SonicGarden さんの構成とほぼ同じですが、私の運用では rules/tools.md に PROJECT_ID を宣言し、Skill 側で「引数なしならここの値を採用してよい」と書く設計を採用しています。引数を毎回明示するのは面倒なので、デフォルト値を Rules に逃がす方が運用が軽くなります。
Skill 側：エントリーポイントの実装
エントリーポイントの SKILL.md は、「順番に走らせるべき手順」と「ユーザーの承認を取るべき停止点」を明示する、ほぼプロセスマニュアルです。
---
description: 週次のレビュー入力からタスクを切り出し、worktree ごとに並列実装する
argument-hint: <PROJECT_ID>
---
# 週次の実装ワークフロー
PROJECT_ID: $ARGUMENTS
以下を **厳密に順番通り** 実行してください。各 USER GATE では必ず停止し、
ユーザーの明示的な承認を待つこと。
## Step 0: レビューサマリの受領
ユーザーに以下を提示し、週次レビューで決まったタスクのサマリを貼ってもらう:
> 週次レビューで決まった、今週着手すべきタスクのサマリを貼ってください。
返ってきたテキストを「週次サマリ」として保持。空であれば停止して再依頼。
## Step 1: タスク候補の抽出
プロジェクト管理ツールから情報を取得し、ユーザーから渡された週次サマリと
照らし合わせて、今週優先して取り組むタスクを 3〜5 件に絞る。
[USER GATE 1: 候補リストを提示し、ユーザーの承認を待つ]
## Step 2: worktree の用意
承認された各タスクごとに、git worktree を作成。
## Step 3: 並列実装の起動
各 worktree に対して task-implementer サブエージェントを並列起動。
[USER GATE 2: サブエージェントの完了報告を待つ]
## Step 4: PR 作成とステータス更新
各サブエージェントが PR を作成、プロジェクト管理ツールのステータスを
「未着手」→「確認中」に変更、PR の URL を担当者メンション付きで投稿。
## Step 5: 完了報告
ユーザーに各タスクの PR URL とステータスを報告。
$ARGUMENTS は Claude Code の組み込み変数で、Skill 呼び出し時に渡された引数を参照します。argument-hint は呼び出し時にどんな引数を渡すべきかを伝えるヒント。これは SonicGarden さんの記事と同じ構造です。
私が個人運用で追加したのは USER GATE です。Skill の途中で必ず人間に確認を取るポイントを明示しておくと、AI が暴走して PR を量産する事故を防げます。1997 年に独学でインターネットを触り始めて以来、私は「自動化と判断」を分離する癖が強く、ここは絶対に譲りません。
Rules 側：PROJECT_ID と運用ルールの分離
Rules はファイル単位で常時コンテキストに載るため、「Skill の中に書かなくて済む情報」を逃がす場所として最適です。
# rules/tools.md
## プロジェクト管理ツールの運用ルール
- PROJECT_ID は環境ごとに次の値を使う:
- 本番: proj-prod-2026
- ステージング: proj-staging-2026
- 個人開発: proj-personal-001
## MCP サーバーの設定
- github: gh の認証情報を共有
- linear: API キーは ~/.config/linear/token に格納
- chrome-devtools-for-agents: 拡張機能のリグレッション用
## 自律レベルのデフォルト
- 読み取り系: always-proceed
- 書き込み系: request-review
- 危険操作: strict
rules/project.md には、プロジェクト管理ツール（Linear / Asana / GitHub Issues など）との連携手順を書きます。これは Skill 側に書くと、Skill が肥大化して読みづらくなる情報です。
Rules に分離する基準は私の場合シンプルで、「環境が変わると変わる情報」は Rules、「ワークフローの順序」は Skill と分けています。
Subagents 側：単一タスクを完結させるエージェント
サブエージェントは、Skill から並列起動される作業要員です。各々が独立した worktree で動き、自分の担当タスクを完結させます。
---
name: task-implementer
description: 単一の開発タスクを worktree 内で完結させる実装担当エージェント
tools: Read, Write, Edit, Bash, Grep, Glob, Skill
---
# 役割
あなたは指定された worktree 内で、与えられたタスクを実装し、テストを書き、
PR まで作成する担当です。次の手順を厳密に守ること。
## 手順
1. worktree のルートで `git status` を確認し、クリーンな状態を担保
2. タスクの仕様を読み、影響範囲を Grep / Glob で特定
3. **既存のテストを先に読む**。テストの書き方を踏襲すること
4. 実装を進める。最小の差分で目的を達成する
5. テストを追加し、`npm test` などのコマンドで通過を確認
6. `git add` → `git commit` → `git push` → `gh pr create`
7. PR の URL と、コミットの一行要約を返す
## 制約
- フレームワーク変更は提案しないこと
- 1 タスクの差分が 500 行を超えた場合は、Skill 側に「分割を提案」して停止
- テストが落ちる状態で PR を作らない
ここで tools に Skill を含めているのは、サブエージェント内でも追加のスキルコマンドを呼べるようにするためです。SonicGarden さんが書かれていた通り、サブエージェントが「単純なコード生成だけをするエージェント」ではなく、「自社の設計〜実装〜テスト作成プロセスに沿って動くエージェント」として振る舞えるようになります。
私が追加した制約は 「フレームワーク変更は提案しない」 と 「500 行を超えたら分割を提案して停止」 の二つです。前者は Claude Lab の他記事でも書いていますが、AI に任せると一足飛びに土台を入れ替えに来る癖があり、それを封じる一行です。後者は、累計 5,000 万ダウンロードのアプリで巨大な PR を踏むと、レビューコストが破綻するので、私の個人運用上の安全弁として効きます。
並列起動の作法：1 つのコマンドで全員分を回す
サブエージェントを並列起動する利点は、「このタスクが終わらないと次に着手できない」依存関係から解放される ことです。SonicGarden さんが書かれていたとおり、「全員分のタスクを一括で並列起動する」のが本質です。
私の個人運用では「全員分」を「自分の今週のタスク全部」と読み替えていますが、それでも 3〜5 件を並列起動できるかどうかで、レビュー後の作業速度がはっきり変わります。
Skill の Step 3 で並列起動する場合、Claude Code の挙動として、サブエージェント同士の通信は明示的に書かない限りありません。これは安全で良い設計ですが、依存関係があるタスクを並列起動してしまうと、後で衝突します。そこで Step 1 の候補抽出時に、「依存関係のないタスクのみを今週枠に入れる」 ルールを Skill に書き込んでいます。
「後うち」の時間を「考える時間」に変える
SonicGarden さんの記事の核心は、「動くもの」を起点に議論できるようになることで、レビューの時間が「コードを動かすこと」ではなく「考えること」に使えるようになる、という点でした。これは私の個人運用にも同じ効きがあります。
私の場合の「考える時間」は、次のようなものに使えるようになりました。
- リファクタリングの方針を腰を据えて決める
- 累計 5,000 万ダウンロードのアプリ群を横断するアーキテクチャ判断
- 新しい MCP サーバーを試して、運用に組み込むかどうかの評価
- ドキュメント整備と、過去の判断記録の見直し
宮大工だった両祖父は、刻みは丁寧に手を動かす作業として、組みは図面と現場の整合性を見極める作業として、明確に分けていました。Claude Code で言うところの「刻み」がサブエージェントの並列実装、「組み」が人間の判断、と読み替えると、自分の感覚に綺麗にフィットします。
トラブルシューティング：私がハマった本番運用の罠
仕組みのレールを敷いた後、本番運用で実際に踏んだ落とし穴を共有しておきます。AI が暴走するわけではないですが、運用者側の油断が事故になります。
罠 1：依存関係のあるタスクを並列起動して衝突
候補抽出の段階で「依存関係なし」と判定したのに、実装に入ったらコンフリクトしました。原因は同じファイルに別々の機能修正が乗ったケースで、Grep ベースの判定では検出しきれませんでした。回避策として、worktree 作成前に git log --name-only で過去 30 コミットの変更ファイルを取得し、候補同士で 50% 以上重なるペアは並列起動しないルールを Skill に追加しました。
罠 2：テスト追加忘れ
サブエージェントが実装だけ進めて、テストの追加を忘れて PR を作ろうとしました。これは AI 側のサボりではなく、Skill 側の手順 5（テスト追加）の優先度が低く書かれていたのが原因です。手順 5 に「テストを追加しなかった場合は停止」と明示し、Subagents の制約にも「テストが落ちる状態で PR を作らない」と入れて解決しました。本番運用ではテスト未追加は即障害なので、ここはガードを二重に張る価値があります。
罠 3：MCP サーバーの認証切れに気づかない
Linear / GitHub の MCP サーバーで認証トークンが切れていると、サブエージェントは「ツールが応答しない」とだけ報告して止まります。これに気づかず 1 週間放置した経験があり、Skill の Step 0 に MCP サーバーの疎通確認を入れて回避しました。
チューニングと運用上の落とし所
仕組みのレールを敷いてから 1 ヶ月ほど運用しての気づきも書いておきます。
- Skill のステップ数は 5〜7 個に収める。10 個を超えると保守がしんどくなる
- USER GATE は 2〜3 箇所まで。多すぎると人間が疲弊して、結局自動化しなくなる
- Subagents の制約はコメントとして書く。AI は制約を読みやすい形で渡されると素直に従う
- Rules はファイル単位で分割する。1 ファイルに詰め込むとコンテキストが膨らんで Claude の応答が遅くなる
- PR は「人間が読める単位」で切る。サブエージェントに「500 行で分割」と書いたのはこれが理由
- 失敗ログを残す。
~/.claude/logs/ に各 Skill の実行ログを残すと、改善のたたき台になる
特に「失敗ログを残す」は、SonicGarden さんの記事で「これからが本番」と書かれていた部分にあたります。私は失敗ログを週次で読み返して、Skill / Rules / Subagents の三層をどこから先にチューニングするかを決めています。
まずは小さく試す
最初から完璧な仕組みを組もうとすると、絶対に頓挫します。最初の 1 週間は、Skill の Step 0 と Step 1（候補抽出）だけ動かす ところから始めるのが私のおすすめです。
「タスク候補を 3〜5 件に絞る」だけでも、週次の意思決定スピードはかなり上がります。並列実装まで自動化するのは、その挙動が安定してから組み足す、で十分間に合います。
2019 年の晩秋に吉祥寺駅の上空で光の輪を見た体験以降、自分は「直感が確信に変わる瞬間」まで立ち止まる癖が強くなりました。Skill の設計でも同じで、最初の候補抽出ステップを 1〜2 週間動かしてみて、「これは安定して効く」と確信したフェーズで、初めて並列実装まで広げています。
Skill のレールを敷くこと自体は、半日で終わります。難しいのはそのレールを 長く運用に乗せる側で、ここは AI ではなく人間の仕事です。Claude Code の三層がそれを支える道具になってきている、というのが私の現在の手応えです。