複数のAIが役割分担して働く“エージェント組織”の作り方
Claude Codeを使っていて「あれもこれも同じ会話の中で頼んでいたら、話が噛み合わなくなってきた」という経験はありませんか。
調べものを頼んだと思ったら、次の瞬間にはコードを書かせて、そのまま文章の校正までお願いする。
1つのAIに何でも同時に頼むと、途中で指示がごちゃ混ぜになって、AIも「あれ、今何の作業でしたっけ」と迷子になることがあります。私自身、最初にClaude Codeを触り始めた頃は、まさにこの状態でした。
何でも1つのチャットに詰め込んで収拾がつかなくなり、「もう一回最初から説明しよう」と手が止まる。あの感覚、結構ストレスです。
実はこの問題、Claude Codeの「サブエージェント」という機能を使うと、かなりの部分が解決します。
しかも、1体作って終わりではなく、複数のサブエージェントに役割を分担させて「小さな会社」のように動かすところまでやると、驚くほど作業が整理されます。
この記事では、営業・実務・校正・秘書のような役割を持つ複数のAI(サブエージェント)を配置し、案件を受け渡しながら仕事を進めていく仕組みの作り方を解説します。
私が普段運用している「執筆会社」という仕組みをベースに、後半では架空の題材でゼロから組織を組み立て、簡単な案件を1つ完成させるところまで実演します。
はじめに — なぜ「1体のAI」から「組織」へ進化させるのか
Claude Codeのサブエージェント機能自体は、すでに様々なSNS上でも「サブエージェントとは何か」「作り方」を解説する記事がいくつも出ています。
この記事はそれらとは少し視点を変えて、「1体作った後、それをどう組み合わせれば“組織”として機能するか」に焦点を当てます。
たとえるなら、サブエージェント1体を作るのは「アルバイトを1人雇う」ことに近いです。
それだけでも便利ですが、仕事が増えてくると「営業は営業、経理は経理」と役割を分けたくなりますよね。
それぞれが自分の持ち場に集中し、前工程から仕事を受け取り、後工程に渡していく。これが「組織化」です。
Claude Codeでも同じことができます。1つのAIに全部を背負わせるのではなく、複数のサブエージェントに「営業(企画)」「実務(執筆)」「校正」「秘書(進行管理)」のような役割を割り振り、案件を工程ごとに受け渡していく。そうすることで、それぞれの担当が余計な情報に惑わされず、自分の仕事に集中できます。
イメージとしては、次のような違いです。

この記事で作るもの — 完成イメージを先に見せる
具体的に何を作るのか、先に完成イメージをお見せします。この記事で組み立てるのは、次のような「案件が工程を渡り歩いていく」仕組みです。
1. 企画担当が、何をテーマにするか・誰に向けて書くかを考えて提案書を作る
2. 実務担当が、その提案書に沿って実際に本文を書く
3. 校正担当が、誤字や表現、事実関係をチェックする
4. 秘書担当が、各工程の成果物を検収し、進行状況を管理して、完成を見届ける
それぞれの担当は、Claude Code上では「サブエージェント」という単位で表現されます。人間の会社に置き換えると、秘書が案件を受け取って各部署に仕事を割り振り、出来上がったものを確認しながら次の部署に回していくイメージです。

このあと、実際に組み立てるための準備を7つのステップに分けて説明し、最後に「個人ブログ運営会社」という架空の題材でゼロから組織を組み立て、1案件を完成させるところまでを実演します。
準備1 — フォルダ構成という「会社の型」を作る
まず土台になるのが、フォルダ構成です。Claude Codeは、今開いているフォルダ(プロジェクトフォルダ)を1つの「現場」として認識します。
そのフォルダの中に部門ごとのサブフォルダを作っておくと、成果物の置き場所が整理され、迷いがなくなります。
たとえば私が運用している「執筆会社」では、次のような構成にしています。
執筆会社/
├── CLAUDE.md … 会社全体のルール
├── MEMORY.md … 蓄積してきた事実・決定事項
├── .claude/agents/ … サブエージェント(スタッフ)の定義ファイル置き場
├── 営業
├── 実務
├── 校正 … 各部門の成果物置き場
└── 秘書/進行管理表.md … 案件の進行状況を管理する表
ポイントは2つです。
1つ目は、「.claude/agents/」というフォルダに、サブエージェントの定義ファイルをまとめて置くこと。ここはClaude Codeが「このプロジェクト専用のスタッフの詰め所」として認識してくれる特別な場所です(詳しくは準備3で説明します)。
2つ目は、案件ごとに連番のID(001、002、003…)を振って、各工程の成果物ファイル名にそのIDを含めておくことです。「003_タイトル_提案.md」「003_タイトル.docx」のように同じ番号で紐づけておけば、あとから「あの案件、どこまで進んだっけ」と探すときにも迷いません。実はこの記事自体も、社内的には「案件003」として管理されています。
準備2 — CLAUDE.mdと「記憶」の役割分担
Claude Codeには、セッション(会話)をまたいで情報を覚えておくための仕組みが2つ用意されています。公式ドキュメント「How Claude remembers your project」によると、これは次のように整理されています。
• CLAUDE.mdファイル: 人間(あなた)が書く、Claude Codeへの指示・ルール
• 自動メモリ(Auto memory): Claude Code自身が、あなたの訂正や好みをもとに自動で書き溜めていく学習内容
どちらも毎セッションの開始時に読み込まれますが、性質はまったく違います。CLAUDE.mdは「いつも守ってほしいルール」を人間が明文化する場所、自動メモリは「Claudeが勝手にメモを取ってくれる」場所というイメージです。
たとえるなら、CLAUDE.mdは新人研修で渡す「業務マニュアル」、自動メモリはベテラン社員が現場で自然に覚えていく「暗黙知のメモ帳」といった感じでしょうか。
ここで一つ、正直にお伝えします。私が運用している「執筆会社」では、CLAUDE.mdとは別に「MEMORY.md」というファイルを自分たちで作り、「行動を規定するルールはCLAUDE.mdへ、変わりうる事実・決定事項はMEMORY.mdへ」という使い分けをしています。
ただしこれはClaude Code公式の機能ではなく、私たちが独自に採用している運用の工夫です。
公式の自動メモリは「Claudeが自動で書く」ものですが、MEMORY.mdは「人間(私)が指示した事実を秘書役が書き込む」手動版の記憶ファイル、という違いがあります。
この記事でも同じ発想で進めますが、公式の自動メモリを使うか手動メモファイルを使うかはどちらでも構いません。
CLAUDE.mdにはもう一つ、階層構造という大事な性質があります。
公式ドキュメントによれば、組織全体で管理されるもの → ユーザー(自分)の全プロジェクト共通のもの(~/.claude/CLAUDE.md) → プロジェクト単位のもの(./CLAUDE.md) → 自分だけのローカル設定(./CLAUDE.local.md)という、広い範囲から狭い範囲へ段階的に読み込まれる順序になっています。
さらに、プロジェクトフォルダの中にサブフォルダがある場合、そのサブフォルダにもCLAUDE.mdを置くことができ、Claudeがそのサブフォルダのファイルを扱うタイミングで追加読み込みされます。
私の「執筆会社」でいえば、プロジェクト全体のCLAUDE.mdに加え、「営業」「実務」「校正」の各フォルダにそれぞれのCLAUDE.mdを置き、「全体のルール+部門固有のルール」を両方守らせる構成です。
就業規則(全社共通)と各部署のマニュアル(部署別)を重ねるイメージです。
なお公式ドキュメントは、CLAUDE.mdを「1ファイルあたり200行程度を目安に」ともすすめています。
長くなるとAIが読み込む情報量が増え、逆に指示が守られにくくなるためです。
改めて整理すると、この2つの記憶の仕組みは次のように役割が分かれます。

準備3 — サブエージェント(スタッフ)の役割定義を作る
いよいよ、組織の「スタッフ」にあたるサブエージェントを作ります。サブエージェントは、「.claude/agents/」フォルダの中にMarkdownファイルとして定義します。
公式ドキュメント「Create custom subagents」によると、このファイルの先頭には「フロントマター」と呼ばれる設定部分を書き、その後にそのサブエージェント専用の指示文(システムプロンプト)を続けます。基本の型は次のようになります。
---
name: 実務
description: 提案文をもとに記事本文を執筆する担当。記事執筆が必要なときに使う。
tools: Read, Write, Edit, Grep, Glob
---
あなたは「実務」です。営業が作成した提案文を読み、読者ファーストで記事を書き上げてください。
書き上げたら .docx 形式で保存し、秘書に完了報告してください。
フロントマターのうち、「name」(サブエージェントの名前)と「description」(どんな時にこのスタッフへ仕事を振るかの説明)の2つは必須項目です。Claude Codeは何かを依頼されたときに「description」の内容を見て「この仕事はこのサブエージェントに振ろう」と自動判断します。
つまり「description」は、スタッフの「名刺の肩書き」のようなもので、ここが曖昧だと仕事の振り分けがうまくいきません。
「tools」は、そのサブエージェントが使える機能を絞り込む項目で、省略すると原則すべての機能を使える状態になります。
ここを絞ることで、たとえば「営業担当にはファイルの編集をさせない」「校正担当には本文の大幅な書き換えをさせない」といった役割の壁を作れます。人間の会社で「経理担当に開発サーバーの管理権限を与えない」のと同じ発想です。
ほかにも使うAIモデルを指定する「model」など細かく調整できる項目がありますが、まずは「name」・「description」・「tools」の3つを押さえておけば十分です。
なお「.claude/agents/」に置いたサブエージェントはそのプロジェクト専用になり、「~/.claude/agents/」(ユーザーのホームフォルダ配下)に置くと自分のすべてのプロジェクトで共通して使えます。
「このプロジェクトだけの専門スタッフ」か「どこにも連れて行ける自分専属スタッフ」かを、置き場所で使い分けられます。
準備4 — サブエージェントへの指示(委任プロンプト)の出し方
スタッフを作ったら、次は「仕事の頼み方」です。
委任のしかたには、「この記事を書いて」と普通に頼んで「description」から自動的に振り分けてもらう方法、「実務にこの記事を書かせて」と担当を名指しする方法、特定のサブエージェントとして会話全体を進める方法、といった段階があります。
初心者の方には、まずは自然な会話で頼む方法から試すことをおすすめします。「description」さえきちんと書いておけば、そこまで身構えなくてもClaude Codeが適切に振り分けてくれます。
ただし、委任するときの「頼み方」自体は丁寧に作り込む価値があります。私が実務で使っている型は次の4点です。
• 背景: なぜこの仕事が必要なのか
• 目的: 何を達成したいのか
• 成果物の置き場所: どこに何のファイル名で保存するか
• 完了条件: 何をもって「終わり」とするか
一言でまとめると「新人に仕事を頼むときと同じ気配りをAIにもする」ということです。
人間の新人に「あれやっといて」とだけ言っても迷わせてしまうのと同じで、AIも背景や完了条件が曖昧だと見当違いの成果物を作ってしまいます。
逆にこの4点さえ書いておけば、驚くほどスムーズに仕事が進みます。
準備5 — 案件管理・進行管理表を作る
案件が増えてくると、「どの案件が今どの工程にいるか」が分からなくなってきます。そこで用意したいのが、進行管理表です。やり方はシンプルで、案件ID・タイトル・現在の工程・状態(進行中/差し戻し/完了)を並べた表を1つのMarkdownファイルにまとめておくだけです。

ここで大事なコツが1つあります。この表を「誰が更新するか」を最初から1人に決めておくことです。
複数の担当が思い思いに書き換えると、すぐに情報が食い違って表が信用できなくなります。私の「執筆会社」では、進行管理表の更新は秘書役だけが行うというルールにしています。
受付や事務局が1つの窓口に一本化されているのと同じ理屈です。
準備6 — 検収(品質ゲート)と差し戻しの仕組み
組織として機能させる上で、地味に一番重要なのがこのステップかもしれません。前の工程の成果物を、無条件に次の工程へ渡さないということです。
たとえば、企画担当が作った提案書に肝心のタイトル案が入っていなかったとします。それに気づかないまま実務担当に「これを書いて」と渡してしまうと、的外れな記事を書き始めてしまうかもしれません。
人間の会社なら「ここが埋まってないから差し戻すね」と誰かが止める場面ですが、AI同士のやり取りでも同じチェック役が必要です。
そこで、各工程に「これが揃っていなければ次に進めない」という合格基準(品質ゲート)をあらかじめ決めておきます。私の運用では、実務担当の成果物(記事原稿)を校正担当に渡す前に、次のような基準で秘書役がチェックしています。
• 提案書の構成・ターゲットに沿っているか
• 出典の一覧が添えられているか
• 執筆担当自身のセルフチェックが済んでいる申告があるか
基準を満たしていなければ、そのまま突き返す(差し戻す)。この一手間があるかないかで、最終的な成果物の品質はまったく変わってきます。

準備7 — 納品とGit連携(バージョン管理)
最後の準備は、記録を残す仕組みです。ここでは「Git(ギット)」という、ファイルの変更履歴を記録できる仕組みを使います。
ざっくり言うと、作業のたびに「ここまでの状態」をスナップショットとして保存しておける機能で、あとから「いつ、何を、なぜ変えたのか」を辿れます。
区切りの良いタイミングで「コミット」という単位で記録を残し、そのときに何を変えたのかを一言メモ(コミットメッセージ)として添えます。
Word文書のようなファイルはGitでは中身の変更点までは読み取れないため、このメモに変更点をしっかり書いておくのがコツです。
大きな節目には「タグ」という目印も付けておくと、あとから「この時点の状態」を簡単に呼び出せます。
これまで小難しい説明が並んでいて難しそうと思った方、心配いりませんAIに丸投げできます。
簡単に言うと、それぞれのフォルダに「あなたはこういう役割です」と指示を入れていくだけで、AIがその役割になりきってくれます。難しい設定は必要ありません。
・「秘書」フォルダを作って、ここでは仕事の振り分けや私とのやり取りをお願いします、案件は連番で管理してください
・「執筆」フォルダを作って、ここでは、依頼に応じて記事を作成する、フォルダに雛形があればそれを参考にしたり完成度の高い納品物を生成する
・「校正」フォルダを作って、ここでは、執筆フォルダに記事のベースがあるので、秘書の指示に従って文章の校正を行います
・「秘書」には進捗スケジュール管理もお願いします
・「秘書」以外のサブは、報・連・相を「秘書」に伝える、私からの指示は、「秘書」として受けて、指示内容から適切なサブに仕事を依頼し進捗管理を行う
その他Gitの初期化、CLAUDE.md作成、サブエージェント機能の有効化などあれやって・これやってと、指示を入れていけば組織が出来上がります。
私はこの仕組みを作る過程で.md(マークダウンファイル)やコードを一切触っていません。指示を出しただけです(笑)
このエージェント組織の肝は、秘書に司令塔の役割を持たせることです。
実際執筆を行うときは
私が秘書に指示を出す
秘書がその指示内容を読み取り、リサーチ・執筆・校正など、適切な部署(サブエージェント)に仕事を割り振る
各サブエージェントは、進捗や気づいたことを秘書に報告する(いわゆる「報・連・相」ですね)
秘書がそれを取りまとめて、進捗スケジュールを管理する
いよいよ実演 — ゼロから「個人ブログ運営会社」を作ってみる
ここまで7つの準備を説明してきましたが、文字だけ読んでいてもピンとこない部分もあると思います。ここからは、架空の題材を使って、実際に手を動かしながら組織を組み立てる様子を実演します。
あらかじめお断りしておくと、ここから先に登場する「ブログ工房」という会社は、この記事の中だけで完結する架空のデモ組織です。
私が実際に運用している「執筆会社」そのものの内部情報ではなく、読者のみなさんが自分のブログ運営や副業に応用しやすいよう、あえて別の題材に置き換えたものだとご理解ください。
題材は、個人でブログを運営している「ブログ工房」という小さな会社です。ブログ運営は多くの読者にとって「発信を効率化したい」という関心と重なりやすく、自分ごととして捉えやすい題材だからです。
役割構成は、秘書・企画・執筆・校正の4役+本人という、ここまで説明してきた執筆会社と同じ型を使います。「営業」を「企画」と呼び変えているのは、販売色を薄めて身近な言葉にするためです。
アレンジでアプリ開発ならば「開発」「技術」「エンジニア」等
ブログ工房/
├── CLAUDE.md / MEMORY.md
├── .claude/agents/(秘書・企画・執筆・校正の定義ファイル)
├── 企画
├── 執筆
├── 校正
└── 秘書/進行管理表.md
役割の相関はシンプルで、秘書が中心にいて、企画・執筆・校正の3役へ順番に案件を受け渡し、出来上がったものを秘書が確認していく形です。
この構成を作るために、まず「.claude/agents/」フォルダに企画・執筆・校正それぞれの定義ファイルを準備3の型(name・description・tools)に沿って用意し、「CLAUDE.md」に会社全体のルールを、「MEMORY.md」に決定事項を書いておきます。これで「ブログ工房」という小さな組織の骨格は完成です。
実演2 — 簡単な案件を1つ、実際に完成させてみる
骨格ができたところで、実際に案件を1つ流してみましょう。今回のお題は「ブログ運営のコツ」という、当たり障りのない小さなテーマです。
まず、秘書役に次のように一言お願いします。
依頼(社長役 → 秘書):
「ブログ運営のコツ」というテーマで、新しいブログ記事を1本作りたい。案件を起票して、企画から進めて。
これを受けて、秘書役は案件ID(たとえば「001」)を振り、企画担当へ委任します。委任の中身は、準備4で説明した「背景・目的・成果物の置き場所・完了条件」の型に沿ったものになります。
委任(秘書 → 企画):
案件001「ブログ運営のコツ」の企画をお願いします。ブログ初心者向けに、続けるコツを3つ程度に絞って紹介する構成にしてください。成果物は「企画/001_ブログ運営のコツ_提案.md」に保存し、完了したら秘書へ報告してください。
企画担当はこれを受けて提案文を作成し、秘書に報告します(想定読者はブログ初心者、構成は「なぜ続かないのか→続けるコツ3つ→今日からの一歩」の3段構成、といった要約が返ってくるイメージです)。秘書は「タイトル案・構成・ターゲットが揃っているか」という品質ゲートを確認し、問題がなければ執筆担当へ引き継ぎます。
委任(秘書 → 執筆):
提案文「企画/001_ブログ運営のコツ_提案.md」に沿って、本文を書いてください。成果物は「執筆/001_ブログ運営のコツ.docx」に保存し、セルフチェックの上、完了報告をしてください。
執筆担当が本文を仕上げて報告すると、秘書は同様に検収し、校正担当へ引き継ぎます。校正担当が誤字・表現・トーンを整えて「校正/001_ブログ運営のコツ_校正.docx」として保存し、秘書に報告します。最後に、秘書は校正済みの原稿を確認し、進行管理表の該当行を「完了」に更新し、Gitでコミットを打ちます。
完了報告(秘書 → 社長役):
案件001「ブログ運営のコツ」、企画→執筆→校正まで完了しました。進行管理表を更新し、コミットも打ちました。投稿の確認をお願いします。
ここまでが「完成」の状態です。案件が各部署の手を経て、進行管理表がクローズし、変更履歴がGitに刻まれている。この流れが一度回れば、あとは同じ型を使い回すだけで、次の案件も同じようにスムーズに進められます。
おわりに — 小さく始めて、少しずつスタッフを増やす
ここまで、複数のサブエージェントを配置して「組織」として動かす方法を、準備7ステップと実演を通して見てきました。
最初から4役すべてを揃える必要はありません。
まずは「秘書1人+実務1人」のような最小構成から始めて、仕事が増えてきたら少しずつスタッフ(サブエージェント)を追加していく、という育て方で問題ありません。私自身も、最初はもっと小さな構成から始めて、必要に応じて役割を足していったり、画像生成と連携させたりしてきました。
みなさんがこの仕組みを使う目的は、アプリ開発かもしれませんし、SNS運用かもしれませんし、資料作成かもしれません。目的に応じて役の名前や工程を自由に組み替えて構いません。
大事なのは「1体に全部背負わせない」「工程ごとに検収を挟む」という考え方そのものです。
今日からできる一歩としては、まずは「秘書役」と「実務役」の2つのサブエージェント定義を書いてみることから始めてみてください。きっと、1体のAIに何でも頼んでいた頃とは違う景色が見えてくるはずです。
出典・参考資料
Claude Code公式ドキュメント「Create custom subagents」(2026年7月6日にClaude in Chromeで再確認) https://code.claude.com/docs/en/sub-agents
Claude Code公式ドキュメント「How Claude remembers your project」(2026年7月6日にClaude in Chromeで再確認) https://code.claude.com/docs/en/memory
いいなと思ったら応援しよう!
応援よろしくお願いいたします! 