「これもAIに頼めば？」と思うたびに委任してきたら、いつの間にか人間がやることが変わっていました。
タスク管理・リサーチ・記事公開・健康管理。この4軸を Claude Code のエージェントに振り始めて数ヶ月。筆者がターミナルで打ち込むのは今や /todo dashboard くらいです。今日のタスクが整理され、secretary エージェントが昨日の続きを引き継いでいる。
では、人間は何をしているのか。
「AIが全部やるなら人間いらないでしょ」と思うかもしれません。実際はその逆で、委任できる作業が増えるほど、人間が判断すべき場所が浮き彫りになってきます。 この記事では、AIに振った結果として「人間がどこに判断を残したか」を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 が状況を判断して各エージェントに仕事を振ります。
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本来の考え方を実装しているからです。GTD の考え方を詳しく知りたい方にははじめてのGTD ストレスフリーの整理術が出発点としておすすめです。
todo-dev エージェントが独立したワーキングディレクトリで開発していることも重要です。CEO セッションを汚さずに /todo スキルを改善できる。実際、セキュリティルールの強化・Issue body の構造化・多言語対応（LANG_ENV による日英切替）といった改善が、CEO の作業を止めずに進んでいます。
第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 の提案を全部採用するのではなく、コストと優先度で取捨選択する。ここは人間の判断が入る最重要ポイントです。
品質管理は 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サイトに自動投稿。ボトルネックが「書く時間」から「何を書くかの判断」に変わったのが、このフローの最大の成果です。
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 マルチエージェントで知的生産ラインを回してみた
この記事は はてなブログ からのクロスポストです。