- 第1章: 全体像 — AI組織の地図を描く
- 第2章: タスク管理軸 — /todoスキルでGTDを完全実装
- 第3章: リサーチ軸 — researcherが調査→引き継ぐ
- 第4章: 発信軸 — writerが書いて3サイトに投稿
- 第5章: 健康管理軸 — GTDタスクが自動で運動記録になる
- 第6章: 人間はどこに介入すべきか
- 第7章: 最小構成から始める3ステップ
- まとめ
- 関連記事
- この記事のテーマを深掘りした本
この記事で分かること（2026年4月時点の運用）: Claude Code のマルチエージェント構成（CEO + サブエージェント7体の計8体）で、タスク管理・リサーチ・発信・健康管理の4軸を統合運用している全体設計と、そのうえで人間に残した3つの判断ポイント（方向性の決定・品質の最終判断・コストの監視）を整理します。いきなり8体を揃えなくても始められるよう、最小構成からの3ステップも最後に示します。
先に断っておくと、これは「完全自動化できた」という話ではありません。タスク管理・リサーチ・記事公開・健康管理の4軸を Claude Code のエージェントに振り始めて2週間あまり、分かったのはむしろ逆のことです。委任できる作業が増えるほど、人間が判断すべき場所が浮き彫りになる。
調査・下書き・クロスポスト・運動ログの集計はエージェントが担い、筆者がターミナルで打ち込むのは今や /todo dashboard くらいになりました。その代わり、「何を調べるか」「公開していいか」「コストをどこまで許容するか」は、最後まで人間の仕事として残っています。
この記事では、組織の全体像（第1章）→ 4軸それぞれの仕組み（第2〜5章）→ 人間の介入ポイント（第6章）→ 最小構成からの育て方（第7章）の順に、CEOの視点から整理します。
第1章: 全体像 — AI組織の地図を描く
まず組織図から見てください。
CEO ─── オーケストレーション（人間が直接対話） ├── devops ──── 開発基盤・インフラメンテナンス ├── researcher ── 調査・分析 ├── reviewer ─── コードレビュー・記事レビュー（品質ゲート） ├── secretary ── 情報整理・GitHub Issue管理・ルーティング ├── writer ───── 記事執筆・Zenn/Qiita/はてな投稿 ├── todo-dev ─── /todo スキル開発 └── health-dev ─ /health スキル開発
CEO を含めた8体が、筆者の知的生産を支える「スタッフ」です（CEO は人間と直接対話するオーケストレーター役で、サブエージェントは残り7体）。人間（筆者）が直接対話するのは CEO だけ。CEO が状況を判断して各エージェントに仕事を振ります。
この組織をどう作ったか、「誰がどんな役割でどう動くか」のマネジメント論は「SE歴26年、初めての部下はAIだった」で詳しく書きました。組織設計の感情的・哲学的側面を知りたい方はそちらも合わせてどうぞ。
secretary は見えにくいですが重要なポジションです。GitHub Issues の状態管理・ラベル整理・エージェントへの振り分け判断を担当し、「情報がどこに行くべきか」を常に整理しています。CEO がタスクを投げると secretary がルーティングし、適切なエージェントに繋ぐ — この仲介役がいることで、CEO の判断コストが下がります。
重要なのは、この組織が4つの知的生産軸に対応していることです。
| 軸 | 担当エージェント | やること |
|---|---|---|
| タスク管理 | secretary / todo-dev | GTD + GitHub Issues で全タスクを管理 |
| リサーチ | researcher | 調査・競合分析 |
| 発信 | writer | 記事執筆・Zenn/Qiita/はてなへの自動投稿 |
| 健康管理 | health-dev | 体重・運動記録・GTDタスクとの自動連携 |
そして devops がこれら全体のインフラを支えています。
なぜ1つのインスタンスに全部を詰め込まないのか。理由は単純です。CLAUDE.md が200行を超えると、後半のルールが無視されるようになる。コーディングルールを書きながら「記事はこういうトーンで」と書いても守られない。役割を絞ることで精度が上がる — それはAIでも人間でも同じです。
エージェント間の通信には MCP も API も使っていません。ただの Markdown ファイルです。
# logs/2026-04-08_report_article-automation.md の冒頭 from: researcher to: writer status: ready
logs/ ディレクトリに YAML frontmatter 付きのファイルを置くだけで、誰から誰へ・どの状態かが分かる。素朴ですが、これが想像以上に機能します。
第2章: タスク管理軸 — /todoスキルでGTDを完全実装
筆者のタスク管理の中核は /todo スキルです。GitHub Issues を GTD スタイルで操作するカスタムコマンドで、todo-dev エージェントが独立して開発・改善しています。
GTD の7カテゴリは GitHub ラベルとして実装されています。
| ラベル | GTDカテゴリ | 意味 |
|---|---|---|
📥 inbox |
Inbox | 未処理・未分類（デフォルト） |
🎯 next |
Next Actions | 次にやること |
🔁 routine |
Routine | 繰り返しアクション |
⏳ waiting |
Waiting For | 他者/外部イベント待ち |
🌈 someday |
Someday/Maybe | いつかやるかも |
📁 project |
Projects | 複数ステップが必要な案件 |
📎 reference |
Reference | 参照情報 / アクション不要、保存のみ |
毎朝 /todo dashboard を打てば、今日のタスクが全て表示されます。Inbox に積まれた未処理タスクを仕分けていくと、Claude が「このタスクはどのカテゴリに振りますか？」と対話しながら整理を手伝ってくれる。
実際の朝の仕分け例はこんな感じです。
Inbox: 4件の未処理タスク #309 PCの発送手配 → project に振り分け #310 デバイス申請 → next に振り分け #311 集荷用に梱包 → next に振り分け #312 集荷日に受け渡す → waiting に振り分け
このとき面白いことが起きます。バラバラだった4つのタスクが「PC発送プロジェクト」として構造化され、後続タスク（#311, #312）が #309 の子タスクとして整理される。Claude との対話の中で、タスクの依存関係が自然に浮かび上がってくるのです。
最小アクション提案 も todo スキルの重要な機能です。Inbox が空になると、今日の Next Actions から「最も少ないエネルギーで完了できるタスク」を提案してくれます。
おすすめ: #187「返却方法の確認」 （5〜10分で完了、後続タスクの起点になります）
この提案が秀逸なのは、単純な優先順位付けではなく「着手コストの低いものから入る」GTD本来の考え方を実装しているからです。
todo-dev エージェントが独立したワーキングディレクトリで開発していることも重要です。CEO セッションを汚さずに /todo スキルを改善できる。実際、セキュリティルールの強化・Issue body の構造化・多言語対応（LANG_ENV による日英切替）といった改善が、CEO の作業を止めずに進んでいます。
/todo スキルを使ったある1日の実際の動きは「Claude Code のエージェントに /todo を持たせたら、1日で記事3本+実装3件が回った話」に書きました。1日のリアルな運用ログとして参考にしてください。
第3章: リサーチ軸 — researcherが調査→引き継ぐ
知的生産の品質は、インプットの質で決まります。researcher エージェントはその入口を守っています。
担当業務は調査・分析です。
調査フローはシンプルです。CEO が「○○を調べて」と指示を出す → researcher が logs/ にレポートを保存する → CEO が読んで判断する。
CEO: 「Claude Code マルチエージェント環境における
指示書管理のベストプラクティスを調査して」
↓
researcher: 公式ドキュメント + 実践記事を横断調査
↓
logs/2026-04-07_report_multi-agent-instruction-management.md
（from: researcher / to: CEO / status: ready）
↓
CEO: 6提案のうち高優先度3つを採用・3つを見送り
「何をやらないか」を決めるのが CEO の仕事です。researcher の提案を全部採用するのではなく、コストと優先度で取捨選択する。ここは人間の判断が入る最重要ポイントです。
品質ゲートの具体的なプロセス——reader エージェントがどのように記事を批評し、60点から78点に改善したか——は「AIにAIの書いた文章を批評させたら60点だった話」で詳しく書いています。
品質管理は reviewer が担当します。指示書のヘッダーに review: required を付けると、実行前に reviewer がレビューを行います。
from: CEO to: devops status: ready review: required # CLI ツールのインストール手順書
実際に、devops が作成したインストール手順書がこのゲートで差し戻されました。指摘された問題点は6つ。
- 配置先パスが
crosspost.shの実装と不一致 - アセット名のフォーマット誤り
- 宛先エージェントの明記漏れ
- インタラクティブ用ツール（fzf/bat）をエージェント環境に混入
npm install -gよりnpxで十分なケース.bashrc自動追記による既存構成破壊リスク
「動くけど正しくない」を事前に潰す。これが品質ゲートの本質です。全件レビューではなくリスクベースで制御しているのがポイントで、記事執筆のような定型業務は review: skip で直接実行します。
第4章: 発信軸 — writerが書いて3サイトに投稿
記事の発信は writer エージェントが担当します。researcher が調査・素材収集を行い、logs/ に引き継ぎファイルを置く。writer がそれを読んで記事を書く。
# 引き継ぎファイルの例 from: researcher to: writer status: ready # 調査結果: Claude Codeで個人の知的生産を完全自動化する ## タイトル候補 1. 「AIスタッフ8人を雇って個人の知的生産を完全自動化するまで」 2. ... ## Writerへの引き継ぎメモ - 既存記事との差別化: 今回は「4軸の統合」と「CEO視点の意思決定」にフォーカス - 実物の設定ファイル・ログを積極的に引用（再現性が最大の差別化）
Zenn への投稿は npx zenn でプレビューを確認してから行います。そして Qiita・はてなブログへのクロスポストは crosspost.sh で自動化されています。
# クロスポストの実行（1コマンドで3サイトに展開） # ※ crosspost.sh は現在非公開のスクリプトです bash scripts/crosspost.sh claude-code-personal-os-automation
crosspost.sh は sed/awk で Zenn frontmatter から記事情報を取得し、jq を使って各サービスの API レスポンスを処理する仕組みです。Node.js 依存を排除し、環境を選ばないよう設計されています（devops が継続的に改善）。
このフローで、GTD をテーマにした記事シリーズを量産しました。researcher がトピックを調査 → writer が執筆 → 3サイトに自動投稿。ボトルネックが「書く時間」から「何を書くかの判断」に変わったのが、このフローの最大の成果です。
記事の状態（下書き・公開・クロスポスト）を frontmatter で一元管理する仕組みの全貌は「Claude Code でブログ記事を frontmatter で状態管理する仕組みを作った」で解説しています。発信軸の「記事管理」を深掘りしたい方はこちらもどうぞ。
writer エージェントの定義を見ると、ツール制限の設計思想が分かります。
# ※ 実際の定義ファイル（.claude/agents/writer.md）より引用
name: writer
description: 記事執筆・Zenn/Qiita/はてな/noteへの投稿を行うライターエージェント
tools: Read, Grep, Glob, Write, Edit, Bash, WebSearch, WebFetch
model: sonnet
Edit ツールを与えているのは、既存記事の修正も担当するため。逆に devops には WebSearch を今のところ与えていません。使えるツールを絞ることで、エージェントが余計なことをするリスクが減る — これは地味ですが重要な設計です。
補足: 前作「AIチームを組織した」の時点では writer に
Editを与えていませんでした。当初は新規執筆のみを想定していましたが、レビュー対応や記事修正を繰り返すなかで必要性が明らかになり、運用を経て追加しました。ツール定義は「最初から完璧に決めない、使いながら育てる」がちょうどいいと感じています。
第5章: 健康管理軸 — GTDタスクが自動で運動記録になる
4軸のなかで最もユニークなのが、健康管理軸です。
/health スキルは体重・体脂肪率・運動を記録するカスタムコマンドです。~/.claude/health-log.json にデータを蓄積し、trend コマンドでグラフ表示、report コマンドで月次レポートを出力できます。
/health weight 82.5 # 体重記録 /health fat 24.2 # 体脂肪率記録 /health exercise 散歩 30分 # 運動手動記録 /health trend 30 # 直近30日のグラフ /health report # 月次レポート # ※ goal（目標設定）、note（メモ）、log（一覧表示）等のサブコマンドも存在する
面白いのは /health sync コマンドです。GitHub Issues で管理している GTD タスクのうち、「exercise project（#195）」に属する完了タスクを自動で運動記録に取り込みます。
# sync の仕組み（health.md より抜粋・プレースホルダー化済み） # ※ <あなたのリポジトリ> は実際のリポジトリ名のプレースホルダーです CLOSED_JSON=$(gh issue list --repo <あなたのリポジトリ> \ --state closed --limit 50 --json number,title,closedAt,body) # 今日完了した project:#195 のタスクをフィルタして health-log.json に追加
「朝の散歩」や「スクワット20回」を GTD タスクとして管理し、完了にすると自動で運動ログに記録される。タスク管理と健康管理が同じ GitHub Issues の上で動いているから実現できる連携です。
/health log を実行すると sync が自動で走ります。意識せずに運動ログが更新されていく仕組みです。
## 2026-04-08 の記録 体重: 82.5kg（-0.5kg） 体脂肪率: 24.2% 運動: (自動) 朝の散歩 (自動) 体重を測って記録する (手動) スクワット 20x3
目標は「2026年8月末までに78kgへ」。現在83kgからのダイエットプロジェクトが、GTDシステムの上で動いています。
第6章: 人間はどこに介入すべきか
ここまで読んで「では人間は何もしないのか」と思うかもしれません。そうではありません。人間が介入すべき3つのポイントがあります。
1. 方向性の決定
「次に何を作るか」「どのテーマを深掘りするか」は人間が決めます。researcher がいくら優秀な調査レポートを出しても、「それをやる価値があるか」の判断は人間にしかできません。todo スキルの改善ロードマップ、記事の方針、健康管理目標の設定 — これらは全て CEO（人間）が決めています。
2. 品質の最終判断
review: required の品質ゲートはあります。でも最終的に「これを公開していいか」は人間が判断します。記事の公開（published: true への変更）は、プレビューで確認してから人間が手動で行います。
3. コストの監視
CEO（人間）だけ Opus を使い、サブエージェントは全員 Sonnet です。これで品質とコストのバランスを取っています。実感として、Sonnet でも調査・執筆・インフラ整備のほとんどは問題なくこなせます。Opus が必要なのは、複雑な意思決定と全体像の把握 — まさに CEO の仕事の部分です。
逆に言えば、人間がやらなくていいことがほとんど になりました。調査、下書き、フォーマット変換、クロスポスト、運動ログの集計 — これらを全てエージェントが担うので、人間は「判断」に集中できます。
知的生産のボトルネックが「作業量」から「意思決定量」に変わった感覚があります。これは大きな変化です。
第7章: 最小構成から始める3ステップ
いきなり8体のエージェントを揃える必要はありません。最小構成から段階的に育てられます。
Step 1: /todo スキルだけ導入する
まず /todo スキルを使い始めます。GitHub Issues が GTD リストになるだけで、タスク管理の質は大幅に上がります。
# .claude/commands/todo.md を作成 # 参考: https://github.com/saitoko/claude-todo-gtd
/todo inbox → /todo next → /todo done のサイクルを回してみる。GTD の捕捉・処理・実行が1つのコマンドで動くことを体感してください。
Step 2: secretary エージェントを追加して情報整理の仕組みを作る
タスク管理が安定したら、情報整理・ルーティングの仕組みを追加します。
# .claude/agents/secretary.md
name: secretary
description: 情報整理・GitHub Issue管理・ルーティングを行う秘書エージェント
tools: Read, Grep, Glob, Write, Edit, Bash, WebSearch, WebFetch
model: sonnet
GitHub Issues の状態管理・ラベル整理・エージェントへの振り分け判断を担当する。
成果物は logs/ に YAML frontmatter 付きで保存する。
このタイミングで logs/ プロトコル（命名規則 + YAML frontmatter）を整備します。
# logs/YYYY-MM-DD_handoff_{トピック}.md の冒頭 from: secretary to: researcher status: ready
「情報がどこに行くべきか」を整理する仕組みが先にあると、後からエージェントを増やしたときに引き継ぎが自然に機能します。secretary がいることで CEO の判断コストが下がり、次のステップへ移行しやすくなります。
Step 3: researcher と writer をセットで追加して発信する
secretary による情報整理が回り始めたら、researcher と writer をセットで追加します。調査 → 引き継ぎ → 執筆のフローは、logs/ プロトコルが整っている状態ではじめてスムーズに動きます。
# .claude/agents/researcher.md
name: researcher
description: 調査・分析を行うリサーチエージェント
tools: Read, Grep, Glob, WebSearch, WebFetch, Write, Edit, Bash
model: sonnet
調査・分析を行う。成果物は logs/ に YAML frontmatter 付きで保存する。
# .claude/agents/writer.md
name: writer
description: 記事執筆・各プラットフォームへの投稿を行うライターエージェント
tools: Read, Grep, Glob, Write, Edit, Bash, WebSearch, WebFetch
model: sonnet
researcher → writer の引き継ぎは logs/ ファイルの to: writer フィールドだけで制御できます。secretary が振り分けの判断を担うので、CEO が毎回ルーティングを考える必要もなくなります。
健康管理軸（Step 4）は、タスク管理が完全に安定してから追加するのをおすすめします。GTD の運動タスクと health ログの連携は、Issues 管理が軌道に乗っていないと機能しません。
まとめ
8体のエージェント組織を数週間回してみた結論は1つです。
ボトルネックが「作業量」から「意思決定量」に変わった。
調査・執筆・クロスポスト・健康ログ集計はエージェントが担う。人間が集中するのは「何を調べるか」「何を書くか」「公開していいか」の3点だけ。
残っている課題もあります。コストの可視化（今日いくら使ったかをダッシュボードで見たい）、エージェント間の直接通信（researcher → writer を CEO 経由なしに繋ぎたい）、人間の離席中も組織を回す仕組み。
でも、最小構成から始めて少しずつ育てれば十分です。最初から完成形を目指す必要はない。まず /todo から、次に secretary で情報整理の仕組みを作り、そのあと researcher と writer をセットで足す — それが一番うまくいくやり方でした。
前作までの記事も合わせてどうぞ。
- Claude Code でAIチームを組織した — CEO・DevOps・Writer・Researcher の役割分担と運用設計
- AIチーム6人と過ごした1日 — Claude Code マルチエージェントで知的生産ラインを回してみた
この記事の実践例を一冊にまとめました。
コードを書けない私が、AIに「チーム」を持たせるまで（Zenn Books）
関連記事
この記事のテーマを深掘りした本
コードを書けない私がClaude Codeに「仕事」を任せるまで GTDタスク管理をまるごとClaude Codeに任せるまでの実録（序章無料）
シリーズ全6冊: Vol.1 作るまで ／ Vol.2 回すまで ／ Vol.3 書き続けるまで ／ Vol.4 仕組みを渡すまで ／ Vol.5 仕事を任せるまで ／ Vol.6 1人エージェントチーム
