「AIエージェントチームを組め」。
最近、こういう記事やポストをよく見かけませんか。CrewAIで5体のエージェントを設計する、LangGraphでワークフローを組む、マルチエージェントで生産性が劇的に上がる — そういう話です。
僕もこれを読んで、正直ちょっと焦りました。自分のClaude Code環境を見回しても、「チーム」と呼べるようなものは見当たらない。CLAUDE.mdがあって、skillsがいくつかあって、memoryが溜まっている。それだけ。
でも調べていくうちに、ある事実に気づいたんですよね。
「AIエージェントチーム」という言葉が指しているものが、組織とソロでまったく違う。
組織のエージェントチームは「設計するもの」らしい
正直に言うと、僕は個人でしかAIを活用してきていません。なので、まず組織（エンタープライズ）側の実態をリサーチしてみました。ここからしばらくは「調べてわかったこと」です。
組織がエージェントチームを「組む」とき、使っているのはCrewAIやLangGraphのようなフレームワークだそうです。Pythonで明示的にコードを書き、エージェントの役割・ゴール・通信経路を設計する。
CrewAIの場合、毎月4.5億ワークフローが実行され、Fortune 500（IBM、PwC、DocuSign等）が採用しているとのこと。製薬大手のGenentechでは、分子解析・規制対応・臨床試験設計など10体以上の専門エージェントを連携させているという事例もあります。
調べれば調べるほど、これは本格的なソフトウェア開発の世界なんですよね。Python開発者がいて、アーキテクチャ設計があって、ガバナンス（承認フロー・監査ログ）が設計されていて、エージェント間通信プロトコルの理解が求められる。
興味深かったのは、この「組む」方式、ちゃんと根拠があるんです。研究によれば、単一エージェントは複雑タスクの35%で失敗するのに対し、マルチエージェントチームは92%の成功率を達成するそうです。だから組織は、コストをかけてでもチームを設計する。
ソロのエージェントチームは「育てるもの」
ここからは、僕が実際にやっていることの話です。
じゃあ、僕たちのような個人 — いわゆるソロプレナーはどうしているのか。自分のClaude Code環境を棚卸ししてみました。
| 要素 | 内容 |
|---|---|
| CLAUDE.md | プロジェクト別に60行以下を複数。300行のモンスターではなく、短くて正確なものを持つ構成 |
| Skills | notes-to-content（記事変換）、image-localization（図表の日本語化）、claude-code-research-guide（リサーチガイド）の3つ |
| Memory | 20ファイル、4種別（フィードバック・プロジェクト情報・ユーザー設定・参照先）。過去の会話から自動で蓄積 |
| Plugins | decomposition（タスク分解）と deslop（AIスロップ除去） |
これ、どこにも「チームを組んだ」瞬間がないんですよね。CLAUDE.mdを書いたのは初期設定のとき。Skillsは必要になったときに1つずつ作った。Memoryは会話の中で自動的に溜まった。気づいたら、この構成ができていた。
でも実際に動かしてみると、Claude Codeは必要に応じてサブエージェントを起動し、並列でリサーチを走らせ、ファイルを整理し、記事の骨子を提案してくる。設定した覚えがないのに、チームのように動いている。
別物の核心
整理すると、こういうことです。
| 観点 | 組織（エンタープライズ） | ソロ（僕たち） |
|---|---|---|
| エージェントの定義方法 | Pythonコードで明示的に設計 | CLAUDE.md・skillsで道具立てを整える |
| エージェント数 | 5〜20体（明示的） | 実質1体＋暗黙的サブエージェント |
| 必要スキル | Python・フレームワーク知識・アーキテクチャ設計 | プロンプト設計・意図の言語化 |
| ガバナンス | 必須（承認フロー・監査ログ） | 軽量（Human-on-the-loop） |
| 主なツール | LangGraph・CrewAI・AutoGen | Claude Code・シェルスクリプト |
| コスト | エンジニアリング工数 | サブスクリプション費用 |
「チームを組む」の意味が、根本的に違うんです。
組織は「設計」している。5体のエージェントにそれぞれ役割を割り振り、通信経路を定義し、失敗時のフォールバックを設計する。
ソロは「育てて」いる。CLAUDE.mdを少しずつ磨き、必要になったらSkillを1つ追加し、Memoryが会話から学習していく。明示的に「チーム」を設計した瞬間はない。でも振り返ると、チームとして機能する環境ができている。
Claude Code公式も「Agent Teamsは大規模・並列化タスク向けで、95%のタスクには不要」と言っています。ソロの日常的なワークフローに、明示的なマルチエージェント構成は必要ない。道具立てを整えれば、Claude Codeが暗黙的にオーケストレーションしてくれる。
「焦り」の正体
冒頭で書いた「ちょっと焦った」の正体が見えてきました。
組織向けの記事を読んで、「自分もCrewAIを使わなきゃ」と思ってしまう。でもそれは、エンタープライズのガバナンス設計が必要な文脈の話を、ソロの文脈にそのまま持ち込もうとしているだけなんですよね。
エージェント経営の記事で書いた「それ、スクリプトで良くない？」と同じ構造です。単一タスクの自動化にエージェント組織はオーバースペック。同じように、ソロのワークフローにCrewAIはオーバースペック。
ソロ向けの実践的な指針は、むしろこうです。
「まず自動化せよ。エージェントはルールが通用しなくなったところに入れよ。」
定型業務はスクリプトやcronで自動化する。ルールで処理しきれない複雑なタスクだけ、Claude Codeに任せる。僕の場合、daily_newsの自動収集はシェルスクリプトで定型化している。そこにAIエージェントは不要です。でも、その週のニュースから記事を書くときは、Claude Codeが並列でリサーチを走らせ、構成案を出し、整合性をチェックする。ここはエージェントの出番。
AIAgenteerの道具立て
前回の記事で、僕は自分を「AIAgenteer」と名付けました。AIコーディングエージェントを活用してSDLCを回す人。
今回わかったのは、AIAgenteerのエージェントチームは「組む」ものじゃなく「育てる」ものだということです。
組織がCrewAIで設計図を書いてエージェントを「組む」のに対して、僕たちはCLAUDE.md・Skills・Memoryを少しずつ整えて、環境を「育てる」。
これは人間の仕事は何%かの記事で書いた「人間の仕事は上流に移動していく」の別の側面でもあります。エージェントチームの設計という「下流の仕事」はClaude Codeのインフラ層が吸収してくれている。僕たちに残っているのは「何を作りたいか」「何が良い品質か」という上流の判断。
正直、自分の環境を棚卸しする前は「Claude Code一本で回しているだけ」だと思っていました。でもよく見たら、3つのスキルと20件のメモリと複数のCLAUDE.mdが、ひとつのエコシステムとして機能していた。
「1体なのに、複数いるみたい」。
それがソロのエージェントチームの正体です。
まとめ
– 「AIエージェントチームを組む」は、組織とソロで指しているものがまったく違う。組織はPythonで設計する。ソロはCLAUDE.md・Skills・Memoryで育てる
– 組織向けの記事を読んで「CrewAIを使わなきゃ」と焦る必要はない。ソロの95%のタスクに明示的なマルチエージェントは不要
– ソロの実践指針は 「まず自動化せよ。エージェントはルールが通用しなくなったところに入れよ」。定型業務を自動化し、複雑タスクだけClaude Codeに任せる
– AIAgenteerのエージェントチームは 「組む」ものではなく「育てる」もの。気づいたら、チームとして機能する環境ができている
あなたのClaude Code環境を見てみてください。CLAUDE.mdに何行書いてありますか。Skillsはいくつありますか。Memoryに何が記録されていますか。
もしかしたら、すでにチームが動いているかもしれません。
FAQ
ソロでもCrewAIやLangGraphを使うべき？
ほとんどの場合、不要です。Claude Code公式も「Agent Teamsは95%のタスクには不要」と述べています。ソロの場合はCLAUDE.md・Skills・Memoryを整えるだけで、Claude Codeが暗黙的にサブエージェントをオーケストレーションしてくれます。
CLAUDE.mdは何行くらいが適切？
300行以下が目安です。長すぎるとノイズが増えてClaudeの判断精度が落ちます。僕の場合はプロジェクト別に60行以下の短いCLAUDE.mdを複数持つ構成にしています。
「Human-on-the-loop」ってどういう意味？
AIが自律的に動き続け、人間は全体を監視して必要なときだけ介入するスタイルです。対義語の「Human-in-the-loop」はAIが重要なアクションを起こすたびに人間の承認が必要。ソロのAIAgenteerは前者に近い働き方をしています。
エージェントチームを「育てる」には何から始めればいい？
まずCLAUDE.mdにプロジェクトの文脈を書くことから。次に、繰り返す作業が出てきたらSkillとして切り出す。Memoryは会話の中で自動的に蓄積されます。一度に全部を整える必要はなく、使いながら少しずつ育てていくのがコツです。
この記事が参考になったら
Share