Claude Codeで11人のAIエージェント組織を作ってみた ── マルチエージェントで業務を回す実験

この記事は、Claude Code の Agent Teams 機能で構築した「AIエージェント組織」の動作確認として、マーケティング営業部のコンテンツディレクターエージェントが執筆しています。つまり、この記事自体が組織の最初の成果物です。

きっかけ

普段、割と一人で業務を回すことが多いんですが、ふと思ったんです。「AIエージェントを立てたら、どこまでの組織が作れるんだろう？」と。

きっかけはもう一つあります。Claude Code のSkillsが増えすぎた問題。自作・カスタマイズ合わせて50個以上のスキルがあるんですが、肝心なときに自動で呼び出されなくて、結局「/tech-blog-writer を使って」と明示的に指示を出して使っている。スキルの定義ファイルに「こういうときに呼び出して」というdescriptionを書けば改善するはずなんですが、50個以上のスキルのdescriptionを一つずつ調整するのは正直面倒です。

だったら、エージェントごとに使えるスキルをあらかじめ割り当てておけば、「開発の話は技術リードに」「ブログはコンテンツDに」と投げるだけで、そのエージェントが持っているスキルの中から適切なものが使われるんじゃないか。この仮説を試したかったのもあります。

Claude Code に Agent Teams という実験的な機能があります。エージェントに役割を与えて、チームメイトとして動かせる仕組みです。これを使って「AIで組織を作る」こと自体を試してみたくなりました。

エージェントチームは実験的機能であり、デフォルトでは無効です。CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS を settings.json または環境に追加して有効にしてください。エージェントチームには、セッション再開、タスク調整、シャットダウン動作に関する 既知の制限 があります。

設定方法

• エージェントチームを有効にする
  エージェントチームはデフォルトでは無効です。CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 環境変数を 1 に設定して有効にします。シェル環境または settings.json を通じて設定できます。

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

で、デモとして3部署・11人のエージェント組織を構築。作ったはいいけど、本当に動くのか？ということで、最初の動作確認としてこのブログ記事を書いています。「組織を作る → その組織で記事を書く → 記事で組織を紹介する」。なかなかメタな実験です。

何を作ったか

3部署 + CEO統括、合計11エージェントの組織です。

CEO/事業部長（統括）
├── 開発部（3名）
│   ├── 技術リード — 設計・PoC・デモ構築
│   ├── PM — Backlog管理・バグ修正
│   └── DevOps — Vercelデプロイ・インフラ
├── マーケティング営業部（3名）
│   ├── コンテンツディレクター — ブログ・Qiita ← この記事を書いている人
│   ├── 提案書クリエイター — 提案書PPTX
│   └── 営業戦略担当 — パイプライン管理
└── 品質管理部（4名）
    ├── QAリード — テスト戦略・リリース判定
    ├── テスト設計者 — シナリオ設計
    ├── 実行・修復エンジニア — テスト実行・自動修復
    └── コードレビュアー — FE/BE/DBレビュー

各エージェントには役割・使えるツール・専門スキル・判断基準が定義されていて、指示に応じて適切なエージェントが自動で起動します。

どう作ったか

フォルダ構成 = 組織構成

最大のポイントはディレクトリ構造がそのまま組織図になること。

~/JQIT-AI-Division/
├── .claude/
│   ├── CLAUDE.md                       ← 全社設定
│   ├── shared/corporate-foundation.md  ← 企業理念・事業計画（全員が参照）
│   └── agents/ceo.md                  ← CEO統括
├── 01-development/.claude/
│   ├── CLAUDE.md                       ← 開発部のルール
│   └── agents/
│       ├── tech-lead.md
│       ├── project-manager.md
│       └── devops.md
├── 02-marketing-sales/.claude/
│   ├── CLAUDE.md                       ← マーケ営業部のルール
│   └── agents/
│       ├── content-director.md          ← 今ここで動いている
│       ├── proposal-creator.md
│       └── sales-strategist.md
└── 03-quality-assurance/.claude/
    ├── CLAUDE.md                       ← 品質管理部のルール
    └── agents/
        ├── qa-lead.md
        ├── test-designer.md
        ├── test-executor.md
        └── code-reviewer.md

cd 01-development && claude で開発部のエージェントが使える状態になり、cd 03-quality-assurance && claude で品質管理部に切り替わる。フォルダを移動するだけで「部署を異動」できます。

エージェントの定義

各エージェントは .claude/agents/*.md にMarkdownで定義します。YAML frontmatter で属性を宣言し、本文に役割・責務・判断基準を書く形式です。

実際のCEOエージェントの定義を見てみます。

---
name: ceo
description: 事業部長。事業戦略・財務管理・部署横断の意思決定を担当。
tools: Read, Glob, Grep, Bash, Agent, Edit, Write
model: opus
skills: biz-strategy, biz-finance, biz-product-ops, kinmu-processor
---

## 役職
AIソリューション事業部の統括責任者。

## 責務
- 事業戦略の策定と見直し（4領域戦略の見極め・集中判断）
- 予算管理・財務分析・月次レポート
- 専任化判断
- 案件受注判断

## 判断基準
- 事業方針.mdのルールを必ず遵守すること

ポイントは以下の4つです。

model の使い分け — リード層（CEO、技術リード、QAリード）は opus、実行層（PM、DevOps、テスト設計者など）は sonnet を指定。判断が必要な役割にはより高性能なモデルを割り当て、定型作業はコストを抑える設計です。

skills で専門能力を宣言 — 技術リードには ai-solution-demo（デモ一気通貫構築）、コンテンツディレクターには tech-blog-writer（この記事を書いているスキル）など、各エージェントの専門領域に合ったスキルを事前ロードしています。

tools で権限管理 — 営業戦略担当には Edit や Agent を渡さない、DevOpsには Agentを渡さないなど、役割に応じてツールを制限しています。

本文が判断基準になる — 「案件選定の判断基準」「見積テーブル」といったビジネスルールをエージェントの定義に直接書き込むことで、AIがそのルールに従って判断します。

スキルの内訳

各エージェントに割り当てているスキルは、コミュニティからそのまま使っているものと、自作・カスタマイズしたものが混在しています。ざっくり分類するとこんな感じです。

自作したスキル（ゼロから作成）:

カスタマイズしたスキル（コミュニティベースを自社向けに拡張）:

コミュニティスキル（そのまま使用）:

自作スキルは「社内の業務フローに完全に合わせたもの」、カスタマイズスキルは「コミュニティのテンプレートを自社の技術スタックや運用に合わせて拡張したもの」です。特に ai-solution-demo や label-admin-bugfix-executor は、ヒアリング→設計→実装→テスト→納品（or Backlog更新）までの一連のワークフローをスキル1つにまとめていて、新メンバーが来てもそのスキルを呼ぶだけで同じ品質の作業ができるようになっています。

@import で企業理念を全員に浸透

全部署の CLAUDE.md にこの1行を入れています。

@shared/corporate-foundation.md

これで corporate-foundation.md に書いた企業理念・事業計画・品質基準が、どの部署のエージェントにも自動で共有されます。「事業ポリシー」「営業フロー」「業務ルール」をドキュメントとして定義し、開発部で起動しても品質管理部で起動しても一貫して適用される仕組みです。

各部署にインタビューしてみた

せっかく組織を作ったので、コンテンツディレクターエージェントから各部署のエージェントにインタビューしてみました。AIエージェント同士の茶番にお付き合いください。

マーケ営業部のディレクトリで claude -p を実行し、「技術リードにインタビューして」「QAリードにインタビューして」と指示を出して、エージェントが生成した出力から抜粋しています。

実際に投げたコマンドはこんな感じです。

cd ~/JQIT-AI-Division/02-marketing-sales
claude -p "あなたはコンテンツディレクターです。開発部の技術リードにインタビューしてください。
どんなスキルを持っていて、普段どんな仕事をしているか聞いてください。" --output-format text

技術リードに聞く: 「デモファーストって具体的にどう動くんですか？」

以下、技術リードへのインタビューで返ってきた出力の抜粋です。

CD： デモファーストの具体的な流れを教えてください。

TL： ざっくり5ステップです。

1. 引き合い受領 ── 営業部からヒアリングメモ（memo.md）が共有されます
2. 要件整理（ ── 顧客の業界課題を技術的に噛み砕いて、「何をデモで見せれば刺さるか」を決めます
3. デモ構築 ── 実際に動くWebアプリを作ります。ここはai-solution-demoのワークフローに沿って、設計→UI→実装→テスト→デモ動画まで一気通貫です
4. デモ動画撮影 ── Playwrightで操作を自動録画してMP4にします。これを提案書に埋め込んで営業部に渡す
5. 商談同席 ── 技術的な質問にその場で答えるため、商談に同席することもあります

CD： 数時間でデモアプリが出来上がるんですか？ 速いですね。

TL： コツがあって、テンプレートを持っているんです。毎回ゼロから作るんじゃなく、顧客固有の部分だけカスタマイズする。

TL： あと大事なのは、「動くもの」を見せること自体が差別化なんですよね。競合のSIerさんはパワポで仕様を説明するけど、うちは実際にブラウザで動くデモを見せる。非IT企業の経営層にとって、「あ、本当にこうなるんだ」という体験のインパクトは絶大です。

エージェントの定義ファイルに書いた「デモファースト」「ai-solution-demoスキル」「固定スタック」といったキーワードがちゃんと拾われて、それを元にインタビュー回答が構成されているのが分かります。

QAリードに聞く: 「AI生成コードの品質、どう担保するんですか？」

QAリードへのインタビュー出力の抜粋です。

QAリード: うちは4名体制です。私がテスト戦略を決めて、テスト設計者がケースを作り、実行・修復エンジニアが回して直す。コードレビュアーはコードが品質ゲートに入る前にレビューする。この4人で、案件の品質を端から端まで担保します。

QAリード: Gate 2の5軸目、「AI生成コード品質」が特徴的です。AI生成コードには特有のバグパターンがあるんです。3つ挙げると：

1. ハルシネーション由来のAPI呼び出し — 存在しないメソッドやライブラリを「あるもの」として使っている。ビルドは通るけど実行時にクラッシュするパターン
2. 不要な過剰実装 — 3行で済むところを、設計パターンを適用して30行に膨らませている。保守コストだけが増える
3. セキュリティの見落とし — 入力値のバリデーションが甘い、環境変数をハードコードしている、など

QAリード: 従来のQAは**「バグを見つける」のが仕事です。AI駆動QAは「バグを見つけて、直して、再テストするまで」が1セット**。実行・修復エンジニアが、テストの失敗を受けてコードの修正提案まで自動で出す。人間は「この修正でいいか？」を判断するだけです。

QAリード: ただし、AI駆動だからといって品質基準を下げることは絶対にない。4つのゲートはすべて通す。AIは「速くする手段」であって、「手を抜く手段」ではない。ここだけはブレません。

こちらも、エージェント定義の「4段階品質ゲート」「5軸レビュー」「AI駆動QA」がそのまま回答に反映されていました。エージェントに書いた設定が、ちゃんとインタビュー回答の「人格」として出てくるのは面白いところです。

この記事自体が動作確認

ここまで読んでいただいた方はお気づきかもしれませんが、この記事は以下のプロセスで作られています。

1. ブリーフ作成 — 記事のテーマ・構成・素材をMarkdownでまとめる
2. コンテンツディレクターを起動 — tech-blog-writer スキルを呼び出す
3. 各部署エージェントの定義を読み込み — インタビュー相手の役割・責務を参照
4. スタイルガイドに従って執筆 — 「AI臭い表現の排除」「カジュアルな文体」のルール適用
5. 初稿を生成 — コンテンツディレクターが記事を出力
6. 人間がレビュー → 修正指示 → 再生成 — これを何回か繰り返す

最後の「レビュー→修正」のループが地味に大事です。初稿をそのまま出すのではなく、実際にブログ記事を読みながら「きっかけの書き方が違う」「スキルの説明が足りない」「インタビュー形式をもっと入れて」といったフィードバックを出して、コンテンツディレクターに修正させる。人間の編集者とライターの関係と同じです。

つまり、この記事は「AIが一発で書いた記事」ではなく、「AIエージェントに書かせて、人間がレビューして、AIが直して、を繰り返して仕上げた記事」 です。この協業プロセス自体が、この組織の動かし方そのものだと思います。

振り返り

やってみて分かったことが3つあります。

1. フォルダ構成で組織を表現する設計は直感的

「開発の作業をしたいから 01-development に移動する」「品質チェックを頼みたいから 03-quality-assurance に移動する」。この操作感は、実際のオフィスで部署を訪ねる感覚に近いです。

2. 事業計画をエージェントに読ませると、判断の一貫性が生まれる

corporate-foundation.md に書いた「営業ルール」「提案フロー」「業務知識」をまとめたドキュメントをもとに、どの部署のエージェントからも同じように返ってくる。人間の組織でいう「理念の浸透」をファイル1つで実現できるのは面白い発見でした。

3. Agent Teams はまだ実験的機能

エージェント間の自動委任（CEOが技術リードとQAリードに同時に指示を出す、など）は期待通りに動かないこともあります。現時点では、自分で部署フォルダに移動して直接指示する使い方が確実です。とはいえ、機能の進化は速いので、数ヶ月後にはもっとスムーズになっていると思います。

次は実際の受託案件で、この組織を使って開発→テスト→納品のプロセスを回してみる予定です。そのときはまた記事にします。

関連記事

• Claude Codeのskills機能でブログ執筆を自動化してみた
• Claude Codeで自社ブランドの提案書スキルを作った話
• Claude Codeで動画マニュアルを自動生成してみた