自分専用AI社員チームをClaude Codeで作った話
X(Twitter)でこんな投稿を見た。「自分のPCの中に仮想チームを作って、話しかけるだけで複数のAIエージェントが並列で動き出す」──ブックマーク3,000件・インプレッション50万超え。気になって仕組みを調べていったら、自分でも作れたので、やってみたことをつらつらと。
claude.aiとClaude Codeは別物だった
最初、アプリとしてダウンロードしている(もしくはブラウザでログインしている)claude.aiのチャットに話しかければ仮想チームが動かせると思っていた。けど違ったって話。
仮想チームを動かすのはターミナルで起動するClaude Codeのほうだ。
※ ターミナルとは、キーボードでコマンド(命令文)を入力してパソコンを操作する画面のこと。Macでは「ターミナル」、Windowsでは「PowerShell」が標準で搭載されています。
Claude Codeとclaude.aiは双子の兄弟みたいな存在。同じClaudeというAIから生まれてるけど、できることも動く場所も違う。例えばClaude Codeという兄が書いた日記はclaude.aiという弟は勝手に見ることはできない。弟がおやつをつまみ食いしようとしていても兄はこっそり覗き見なんてしない。お互いに干渉しない。情報のやり取りも勝手にしない。でも2人とも仲良しだから、お互いに「こんなことやったよ」「こんな話したよ」って情報を伝えあったら、すぐに理解して共有できる。そんな関係に似てる気がする。
Claude Codeはファイルを読み書きできるし、調べ物もできるし、スクリプトも動かせる。さらに自分の中から別のClaude Codeを起動する機能がある。これを使うと、1つの指示で複数のエージェントが同時に動き出す。(画像は作れなかった)
※ エージェントとは、AIが特定の役割を持って自律的にタスクをこなす仕組みのこと。「企画担当」「技術調査担当」のように役割を割り振ることで、人間のチームメンバーのように動いてくれます。
ちなみにターミナルのことも最初は全くわからなかったので、その都度claude.aiに聞きながら進めた。わからないことはclaude.aiで調べて、実際の作業はClaude Codeで動かす──この方法だとピンポイントで知りたい情報が手に入る。
実際の作り方──最初の一言から始まった
「どんなプロンプトを投げたか」を知りたい人も多いと思う。ただ正直に言うと、手順書通りに進めたわけじゃない。最初にClaude Codeへ送ったのはこういう一言だった。
「Xでclaudeで自分のPCの中にチームを作って、業務の効率化を図ったという話を読んだんだけど、同じように作ってもらえる?」
それだけ。
するとClaudeは「どんなチームにしますか?」と聞き返してきた。そこから先は、Claudeが過去の会話履歴やファイルを読んで「こういう業務をやってますよね?」と提案してくる形で進んだ。自分が業務リストを書き出したわけじゃない。Claudeが「Web制作やってますよね」「プロダクト開発もありますよね」「SNS発信もしてるから担当者いますか?」と確認しながら、チームの形を組み上げていった。
自分がやったのは、Claudeの提案に「それでOK」「それは違う」「これも追加して」と答えることだけ。気づいたら7部門・18エージェントのチームができていた。
途中でディレクトリ(フォルダの場所)の設定を間違えていて少し手戻りがあったけど、それ以外は特につまずかなかった。Claudeが「ここはこうした方がいいですね」と整理しながら進めてくれるので、全体像を自分で設計する必要はほとんどなかった。
重要な注意点として、同じ一言を送っても同じチームにはならない。Claudeは過去の会話履歴や手元のファイルを読んで提案してくるので、環境や会話の積み重ねによって提案内容が変わる。この記事を参考にするなら「プロンプトをコピペして再現する」ではなく「こういう流れで話しかけると作れる」という感覚で読んでほしい。
できたチームの構成──7部門・18エージェント
最終的にできたのはこういう構成。
| 部門 | エージェント | 役割 |
|---|---|---|
| Web制作 | web-implementer | WordPress・PHP実装 |
| Web制作 | web-designer | サイト構造・ワイヤー設計 |
| Web制作 | web-improver | SEO・UX改善提案 |
| プロダクト | product-planner | アプリ・プラグイン企画 |
| プロダクト | product-dev-support | タスク分解・開発進捗管理 |
| プロダクト | product-qa | テスト・品質チェック |
| コンテンツ | content-blog | ブログ記事執筆・リライト |
| コンテンツ | content-sns | X投稿・SNS告知 |
| コンテンツ | content-translator | 翻訳・ローカライズ |
| 案件管理 | project-estimator | 見積・ヒアリング |
| 案件管理 | project-tracker | 進捗管理・優先度整理 |
| 案件管理 | project-proposer | 提案書作成 |
| リサーチ | research-tech | 技術調査・実装方法調査 |
| リサーチ | research-market | 競合・市場・トレンド調査 |
| 経営管理 | management-accounting | 経費・確定申告・仕訳 |
| 経営管理 | management-revenue | 売上・収益分析 |
| グッズ | making-planner | 3Dプリント・グッズ企画 |
| グッズ | making-sales | EC出品・販売戦略 |
各エージェントはMarkdownファイル(.md)として保存されている。ファイルの中身は「このエージェントの役割」「トーン」「行動ルール」「出力形式」といった定義書。人間で言えば、採用基準と業務マニュアルを合わせたようなものだ。
フォルダ構成
npc-team/ ├── CLAUDE.md # 司令塔の行動原則・設定 ├── .claude/ │ ├── settings.local.json # Claude Code ローカル設定 │ ├── hooks/ # フック設定 │ ├── rules/ │ │ ├── routing.md # エージェントルーティングテーブル │ │ ├── workflows.md # 複合タスクのワークフロー定義 │ │ └── lessons-learned.md # 複利型学習ルール蓄積 │ └── agents/ # エージェント定義(18種) │ ├── content-blog.md │ ├── content-sns.md │ ├── content-translator.md │ ├── making-planner.md │ ├── making-sales.md │ ├── management-accounting.md │ ├── management-revenue.md │ ├── product-dev-support.md │ ├── product-planner.md │ ├── product-qa.md │ ├── project-estimator.md │ ├── project-proposer.md │ ├── project-tracker.md │ ├── research-market.md │ ├── research-tech.md │ ├── web-designer.md │ ├── web-implementer.md │ └── web-improver.md ├── agents/ # エージェント定義(同内容、参照用) │ └── (上と同じ18ファイル) ├── guidelines/ # ガイドライン集 │ ├── about-azu.md # プロフィール・仕事スタイル │ ├── brand-npc.md # ブランドルール │ ├── client-style.md # クライアント対応スタイル │ ├── output-standards.md # アウトプット品質基準 │ └── tools.md # 使用ツール・データ管理 └── templates/ # アウトプットテンプレート ├── blog-post.md # ブログ記事テンプレ ├── estimate.md # 見積書テンプレ ├── proposal.md # 提案書テンプレ └── sns-post.md # SNS投稿テンプレ
使えば使うほど賢くなる「複利型学習」の仕組み
このチームで個人的に気に入っている仕組みが「複利型学習」だ。
仕組み自体はシンプルで、lessons-learned.md というファイルにミスや学びを蓄積していく。エージェントが失敗したとき、自分に訂正されたとき──そのたびに「何が起きた → なぜ問題だったか → 今後のルール」という形式で記録を追加していく。
Claude Codeは毎回このファイルを読んでから動くので、同じミスを二度しなくなる。使えば使うほど精度が上がる構造になっている。人間のチームでいえば「議事録と業務改善メモを兼ねたドキュメント」が常にアップデートされ続けているイメージだ。
実際に記録されたルールの例:
FlutterFlowのUIは頻繁に変わる。操作手順を書くときは「〇〇をクリック」のような固定的な記述を最小限にし、「テキスト入力欄から変数を設定する」のような目的ベースの記述を優先する。
これ以降、FlutterFlow関連の手順書はこのルールに沿って書かれるようになった。チームが育っていく感覚がある。
実際に動かしてみた──3Dプリンタのグッズ企画
試しに「3Dプリンタで売れそうなグッズを考えてほしい」と話しかけてみた。
すると司令塔(CLAUDE.md で定義したルーティング役)がリクエストを分類し、making-planner(グッズ企画担当)と research-market(市場調査担当)を並列で起動した。2つのエージェントが同時に動き、それぞれの結果を司令塔が統合して返してきた。
「3Dプリンタで売れそうなグッズを考えてほしい」
↓
司令塔がリクエストを分類
↓
making-planner(企画担当)とresearch-market(市場調査担当)が並列起動
↓
2人の結果を司令塔が統合して報告
自分はターミナルで話しかけるだけ。並列処理は意識しなくていい。この仕組みのおかげで、ひとりで動かしているのに「チームに相談した感覚」になる。
ちなみにこの記事自体も、content-blog エージェントに書かせている。
まとめ
仮想チームを作るのに、難しいプロンプト設計は必要なかった。最初の一言を投げたら、あとはClaudeが過去の文脈を読んで「こういう業務をやってますよね?」と提案してくれた。自分がやったのは確認と調整だけ。
- 仮想チームを動かすのはClaude Code(ターミナル起動)。claude.aiとは別物
- 最初の一言だけ投げれば、Claudeが会話履歴から業務を推測して提案してくれる
- エージェントはMarkdownファイルで定義。役割・トーン・行動ルールを書いておく
- 複利型学習でミスを蓄積→次回から同じ失敗をしなくなる
- この記事のプロンプトをコピペしても同じ結果にはならない。重要なのはプロンプトの正確さではなく、自分の業務を把握していること
今後は各エージェントの精度をさらに上げていきたいのと、エージェント同士の連携ワークフローを増やしていきたい。チームが育つにつれて、自分の仕事のやり方も変わってきている気がする。
※この記事はNPCの中の人の実務経験をもとに書いています。