AIチーム6人と過ごした1日 — Claude Code マルチエージェントで知的生産ラインを回してみた

今日の組織図（おさらい）
朝：GTDから1日が始まる
- 8:00 — ダッシュボードで今日を俯瞰
- 8:15 — 最小アクション提案
午前：リサーチフェーズ
午後：実装フェーズ
- 13:00 — インフラ整備（+448行の変更）
夕方：レビューと差し戻し
夜：引き継ぎフェーズ
1日の流れを振り返る
回してみてわかったこと
- よかった点
- 改善したい点
あなたも始められる
まとめ
関連記事
この記事のテーマを深掘りした本

今朝、6人のAIチームに「出社指示」を出しました。

といっても Slack に「おはよう」と書いたわけではなく、Claude Code のターミナルを開いて仕事を振っただけです。リサーチャーに調査を頼み、レポートを受け取って精査し、インフラを整備して、指示書をレビューして差し戻して、記事ネタを収集して、ライターに渡す。これが1日で全部回りました。

前回の記事ではマルチエージェント組織の設計思想を紹介しました。今回はその続編として、実際に1日を通してこの組織がどう動いたかを時系列で追います。設計図は描けた。では、本当に動くのか？

今日の組織図（おさらい）

CEO ─── オーケストレーション（人間が直接対話）
├── devops ──── 開発基盤・インフラメンテナンス
├── resarcher ── 調査・分析・レビュー（品質管理）
├── secretary ── 情報整理・GitHub Issue管理
├── writer ───── 記事執筆・Zenn/Qiita/はてな投稿
├── todo-dev ─── /todo スキル開発
└── health-dev ─ /health スキル開発

人間（CEO）が対話するのはメインの Claude Code インスタンスだけ。そこから各エージェントに仕事が流れていきます。

朝：GTDから1日が始まる

8:00 — ダッシュボードで今日を俯瞰

1日の最初にやることは /todo dashboard です。secretary エージェントが GitHub Issues ベースのタスク管理を動かしていて、今日のタスクが一覧で出てきます。

今日やること:
- #314 体重を測って記録する
- #313 朝の散歩
- #279 最小アクション選び
- #278 メール確認

Inbox: 4件の未処理タスク

Inbox に4件溜まっていました。GTD の原則では Inbox の処理が最優先。Claude と対話しながら1件ずつ仕分けていきます。

#	タスク	振り分け先
#309	PCの発送手配	project
#310	デバイス申請	next
#311	集荷用に梱包	next
#312	集荷日に受け渡す	waiting

途中、#309 を一度 next に振り分けた後で「これ project のほうがいいな」と修正しました。こういう柔軟な修正がチャットの中で自然にできるのが、対話型GTDのいいところです。

8:15 — 最小アクション提案

Inbox が空になると、Claude が今日の Next Actions から「最小アクションの候補」を提案してくれます。

おすすめ: #187「返却方法の確認」（5〜10分で完了、後続タスクの起点になります）

提案をきっかけに、バラバラだった4つのタスク（#187, #310, #311, #312）が「PC発送プロジェクト」として構造化されました。最小アクションの提案が、タスクの整理を自然に促す。これは設計時には想定していなかった嬉しい副産物です。

午前：リサーチフェーズ

9:00 — resarcher へ調査指示

朝のタスク整理で「マルチエージェント環境の指示書管理を改善したい」という課題が浮かび上がりました。CEO から resarcher に調査を依頼します。

テーマは「Claude Code マルチエージェント環境における指示書管理のベストプラクティス」。CLAUDE.md の階層設計、.claude/agents/ の活用法、.claude/rules/ によるモジュール化など、公式ドキュメントと実践知を横断的に調べてほしいという内容です。

10:30 — レポート受領

resarcher がレポートを logs/ に保存しました。ファイル名は 2026-04-07_report_multi-agent-instruction-management.md。冒頭の YAML frontmatter はこうなっています。

from: resarcher
to: CEO
status: ready

status: ready は「CEO が読める状態です」という意味です。ステータスは draft（作業中）→ ready（利用可能）→ in_progress（着手済み）→ done（完了）の4段階。インフラ系の指示書には review: required を付けて、実行前に resarcher のレビューを必須にすることもできます。このシンプルなプロトコルで、エージェント間の非同期通信が成立します。

レポートの中身（抜粋）

レポートには具体的な改善提案が優先度付きで整理されていました。

優先度: 高 1. .claude/agents/ にサブエージェント定義を追加 — 自動委任、ツール制限、永続メモリが使えるようになる 2. ルート CLAUDE.md のスリム化 — 参照情報を .claude/rules/ に分離 3. 反復ワークフローを .claude/commands/ にスラッシュコマンド化

優先度: 中 4. .claude/rules/ ディレクトリの導入 5. CLAUDE.local.md の活用

優先度: 低 6. サブエージェントのモデル分離（sonnet / opus の使い分け）

11:00 — CEO の判断

6つの提案のうち、全部を一度にやると混乱するので、高優先度の3つだけを採用しました。

提案	判断	理由
`.claude/agents/` 定義	採用	最も効果が大きい
CLAUDE.md スリム化	採用	ルール遵守率に直結
commands/ 化	採用	日常のワークフロー改善
CLAUDE.local.md	見送り	開発者1人なので不要
モデル分離	見送り	現時点でコスト問題なし

「何をやらないか」を決めるのがCEOの仕事です。レポートの提案を全部実行するのではなく、優先度とコスト感覚で取捨選択する。ここは人間の判断が入るポイントです。

午後：実装フェーズ

13:00 — インフラ整備（+448行の変更）

午前中の判断に基づいて、CEO 自ら（メインの Claude Code セッションで）インフラを整備しました。

やったこと 1: `.claude/agents/` にサブエージェント定義を作成

4つのエージェント定義を新規作成しました。実際のファイルの1つを紹介します。

# .claude/agents/resarcher.md
name: resarcher
description: 調査・分析・レビューを行うリサーチエージェント
tools: Read, Grep, Glob, WebSearch, WebFetch, Write, Bash
model: sonnet

調査・分析を行うリサーチエージェント。加えて、他エージェントの
成果物に対するレビューも担当する。

ポイントは model: sonnet です。CEO だけ opus を使い、サブエージェントは全員 sonnet。コストを抑えつつ、品質は CEO のレビューで担保するという設計です。

やったこと 2: ルート CLAUDE.md を 50行 → 20行に圧縮

Before（50行）の CLAUDE.md にはエージェント組織図の詳細やパス方針が全部入っていました。After（20行）ではコアルールだけを残し、詳細は .claude/rules/ に分離。

# CLAUDE.md — パートナープロジェクト

このプロジェクトはClaude Codeの中心的なオーケストレーションハブです。

## 基本ルール

- 常に日本語で応答する
- 作業ログは `logs/` に記録する（命名規則・引き継ぎヘッダーは `logs/README.md` 参照）
- エージェントへの指示書は `agents/` に保存する
- 重要な決定事項はメモリに保存する

## エージェント組織

詳細は `.claude/rules/agent-roles.md` を参照。

CEO ─ devops / resarcher / secretary / writer / todo-dev / health-dev

## パス記述方針

詳細は `.claude/rules/path-policy.md` を参照。

- 絶対パスを避け、相対パスまたは `$HOME` ベースを使う
- `.exe` 参照は `$OSTYPE` 判定で OS 分岐する

「詳細は別ファイルを参照」と書くだけで、ルート CLAUDE.md のトークン消費が半分以下になりました。短いほど遵守率が上がるので、これだけで組織全体のパフォーマンスが改善します。

やったこと 3: `.claude/commands/` にスラッシュコマンドを追加

毎日使うワークフローをコマンド化しました。

コマンド	用途
`/daily-research`	デイリーリサーチの実行
`/gtd-collect`	GTD収集＆仕分け

commands はポインタとして機能し、詳細手順は既存の agents/ 指示書を参照する構成です。二重管理を避けるための工夫です。

整備後のディレクトリ構成

.claude/
├── agents/
│   ├── resarcher.md    ← NEW
│   ├── writer.md       ← NEW
│   ├── secretary.md    ← NEW
│   └── devops.md       ← NEW
├── commands/
│   ├── daily-research.md ← NEW
│   └── gtd-collect.md    ← NEW
└── rules/
    ├── agent-roles.md  ← NEW
    └── path-policy.md  ← NEW

1回のセッションで13ファイル、+448行の変更をコミットしました。

夕方：レビューと差し戻し

16:00 — 指示書レビュー

ここが今日のハイライトです。組織が本当に機能しているかは、品質ゲートが動くかどうかでわかる。

DevOps エージェントが作成した install-cli-tools.md（CLI ツールのインストール手順書）を CEO がレビューしました。結果は――差し戻しです。

必須修正：3点

1. 配置先の不一致

指示書: $HOME/bin/blogsync.exe crosspost.sh の実装: $HOME/Documents/hatena-content/blogsync.exe

crosspost.sh に合わせるか、変更するなら明記すること。

2. アセット名が不正確

blogsync_windows_amd64.zip と書いているが、実際のリリースは blogsync_v{VERSION}_windows_amd64 形式。

3. 対象エージェントの明記

指示書のヘッダーに 対象: devops を明記すること。他の指示書と同様のフォーマットに揃える。

要検討：3点

fzf / bat / fd はインタラクティブ用ツールで、エージェントが使う場面がない
npm install -g ではなく npx で十分ではないか
.bashrc への自動追記は既存構成を壊すリスクがある

この差し戻しが意味すること

「動くけど正しくない」を見逃さないこと。これが品質ゲートの本質です。

blogsync のパスが違っていても、テスト環境では偶然動くかもしれません。でも本番で壊れる。こういう「静かに壊れるバグ」を事前に潰せるかどうかが、組織の成熟度を示します。

差し戻しのやりとりも、他のログと同じ logs/ プロトコルで記録されます。

from: CEO
to: resarcher
status: done

修正依頼も、修正結果も、全部追跡可能なファイルとして残る。これが組織の透明性です。

夜：引き継ぎフェーズ

19:00 — resarcher が記事ネタを収集

1日の作業が一段落したところで、resarcher に「今日の成果物を記事にできないか調べて」と依頼しました。

resarcher は2つのことをやりました。

競合調査 — Zenn / Qiita / 英語圏のマルチエージェント記事を調べ、空白地帯を分析
ネタ帳作成 — 5本の記事候補を整理し、推奨優先順位をつけた

競合調査で見つかった空白地帯

空白	説明
「1日の時系列」で見せる体験記	機能紹介や構築記は多いが、朝から夜まで追った記事はほぼない
知的生産ワークフロー全体	既存記事は「コード開発」限定が大半
CEO視点の意思決定プロセス	「どう作るか」は多いが「どう判断するか」はない
差し戻しの具体的なやりとり	「レビューした」と書く記事はあるが、具体例はない

つまり、この記事そのものが空白地帯を埋めるコンテンツです。

20:00 — writer へ引き継ぎ

resarcher が記事ネタと素材をまとめ、writer エージェントに引き継ぎました。引き継ぎファイルの中身はこうです。

from: resarcher
to: writer
status: ready

ネタ帳、競合調査レポート、素材ファイルの一覧が添えられていて、writer はそれを読んで記事を書き始める。今まさにこの記事がその成果物です。

1日の流れを振り返る

08:00  secretary  ─ GTD整理（Inbox 4件→0件、プロジェクト構造化）
09:00  resarcher  ─ 指示書管理のベストプラクティス調査
10:30  CEO        ─ レポート精査、高優先度3項目を選定
13:00  CEO        ─ インフラ整備（+448行、13ファイル）
16:00  CEO        ─ 指示書レビュー→差し戻し（必須修正3点+要検討3点）
19:00  resarcher  ─ 記事ネタ収集・競合調査
20:00  writer     ─ 記事執筆開始

1日でリサーチ→判断→実装→品質管理→記事化のサイクルが1周しました。

回してみてわかったこと

よかった点

1. 「判断」に集中できる

人間がやるのは「どの提案を採用するか」「この品質で出せるか」の判断だけ。調査も実装も記事化も、各エージェントがやってくれる。CEO の仕事は指示と判断とレビュー。手を動かすのではなく、頭を使う時間が増える。

2. logs/ プロトコルが想像以上に機能する

YAML frontmatter の from/to/status だけで、エージェント間の引き継ぎが成立する。素朴だけど壊れにくい。MCP サーバーが落ちる心配も、API のレートリミットに引っかかる心配もない。

# 未処理タスクの確認はこれだけ
grep -rl "status: ready" logs/

3. 差し戻しが品質を担保する

install-cli-tools の差し戻し事例が象徴的です。「動くけど正しくない」を放置すると、後から壊れる。品質ゲートが機能していることが、組織として信頼できる証拠になります。

改善したい点

1. 人間のボトルネック問題

全てのレビューを CEO（人間）が行うので、人間が離席すると組織が止まる。resarcher にレビュー権限を委譲して、一次レビューは自動化できるかもしれません。

2. エージェント間の直接通信

現在は CEO を経由して全てのやりとりが行われています。「resarcher → writer」の引き継ぎも CEO が中継している。信頼できるフローは直接通信にして、CEO の介入ポイントを減らしたい。

3. コスト可視化

1日のトークン消費量を正確に把握できていません。Opus と Sonnet の使い分けは実装しましたが、「今日いくらかかったか」をダッシュボードで見たい。

あなたも始められる

始め方の詳細は前回の記事で紹介しています。最小構成は「CEO + 1エージェント」から。2体で回してみて、「もっと分けたい」と思ったら増やす。この記事で紹介した6体制も、最初は1体のアシスタントから育てたものです。

回してみて改めて感じたのは、組織は設計より運用で育つということです。最初から完璧なロール定義を書こうとしても、実際に動かすまでどこが壊れるかは分からない。install-cli-tools の差し戻しも、動かしたからこそ見つかった不整合でした。まずは小さく始めて、壊れたところを直す。そのサイクルが組織を強くしていきます。

まとめ

マルチエージェント組織で1日を回した結果、わかったことは3つです。

設計図は動く。CLAUDE.md、.claude/agents/、logs/ プロトコルという3つの仕組みだけで、リサーチから記事化まで回せる
品質ゲートが命。レビュー→差し戻し→修正のサイクルがないと、「動くけど正しくない」成果物が量産される
人間の仕事は判断。調査・実装・記事化はエージェントに任せて、何をやるか・何をやらないか・品質は十分かを判断するのが CEO の役割

この記事自体が、マルチエージェント組織の成果物です。resarcher が調査し、CEO が判断し、writer が書いた。そしてこの後、resarcher がレビューします。

組織は最初から完成形を目指す必要はありません。まずは1体から。必要に応じて育てるのが、一番うまくいくやり方でした。

Claude Code のマルチエージェント構成をより体系的に学びたい方は、ClaudeによるAIエージェント開発入門が参考になります。

この記事は Zenn からのクロスポストです。

マルチエージェントで1日を回してみると、次の問いが出てくる——このチームをどう設計すれば、最初から正しく動くのか。

私は試行錯誤しながら6体制にたどり着いたが、エージェント定義の書き方・CLAUDE.md の階層設計・ログプロトコルの設計思想については、体系的にまとめた本を書いた。Vol.1「コードを書けない私がClaude Codeで『AIチーム』を作るまで」は、マルチエージェント組織の設計と初期セットアップを序章・第1部まで無料で読める。

コードを書けない私がClaude Codeで「AIチーム」を作るまで（Zenn Books）（序章・第1部無料）

この記事のテーマを深掘りした本

コードを書けない私がClaude Codeで「AIチーム」を回すまで 「作る」の次。運用・三層品質ゲート・事故対応の設計（序章無料）

シリーズ全6冊: Vol.1 作るまで／ Vol.2 回すまで／ Vol.3 書き続けるまで／ Vol.4 仕組みを渡すまで／ Vol.5 仕事を任せるまで／ Vol.6 1人エージェントチーム

コードを書かないSE日誌

SE歴26年。コードを書かずにClaude Codeで8体のAIエージェントチームを動かしています。AIエージェント・自動化・GTDの実験日誌。

AIチーム6人と過ごした1日 — Claude Code マルチエージェントで知的生産ラインを回してみた

今日の組織図（おさらい）

朝：GTDから1日が始まる

8:00 — ダッシュボードで今日を俯瞰

8:15 — 最小アクション提案

午前：リサーチフェーズ

9:00 — resarcher へ調査指示

10:30 — レポート受領

レポートの中身（抜粋）

11:00 — CEO の判断

午後：実装フェーズ

13:00 — インフラ整備（+448行の変更）

やったこと 1: `.claude/agents/` にサブエージェント定義を作成

やったこと 2: ルート CLAUDE.md を 50行 → 20行に圧縮

やったこと 3: `.claude/commands/` にスラッシュコマンドを追加

整備後のディレクトリ構成

夕方：レビューと差し戻し

16:00 — 指示書レビュー

必須修正：3点

要検討：3点

この差し戻しが意味すること

夜：引き継ぎフェーズ

19:00 — resarcher が記事ネタを収集

競合調査で見つかった空白地帯

20:00 — writer へ引き継ぎ

1日の流れを振り返る

回してみてわかったこと

よかった点

改善したい点

あなたも始められる

まとめ

関連記事

この記事のテーマを深掘りした本

今日の組織図（おさらい）

朝：GTDから1日が始まる

8:00 — ダッシュボードで今日を俯瞰

8:15 — 最小アクション提案

午前：リサーチフェーズ

9:00 — resarcher へ調査指示

10:30 — レポート受領

レポートの中身（抜粋）

11:00 — CEO の判断

午後：実装フェーズ

13:00 — インフラ整備（+448行の変更）

やったこと 1: .claude/agents/ にサブエージェント定義を作成

やったこと 2: ルート CLAUDE.md を 50行 → 20行に圧縮

やったこと 3: .claude/commands/ にスラッシュコマンドを追加

整備後のディレクトリ構成

夕方：レビューと差し戻し

16:00 — 指示書レビュー

必須修正：3点

要検討：3点

この差し戻しが意味すること

夜：引き継ぎフェーズ

19:00 — resarcher が記事ネタを収集

競合調査で見つかった空白地帯

20:00 — writer へ引き継ぎ

1日の流れを振り返る

回してみてわかったこと

よかった点

改善したい点

あなたも始められる

まとめ

関連記事

この記事のテーマを深掘りした本

やったこと 1: `.claude/agents/` にサブエージェント定義を作成

やったこと 3: `.claude/commands/` にスラッシュコマンドを追加