この記事ではClaude Codeに特化して解説します。Claude Code全般は Claude Code完全ガイド2026：インストールから本番運用まで をご覧ください。
実験の概要
こはく氏（@Kohaku_NFT）がClaude Code Maxプラン（月$200）の環境で、40体のAIエージェントを構築して1ヶ月間運用した実験の記録。Claude Codeの基本的な使い方と設計思想についてはClaude Codeベストプラクティスガイドを参照。
エージェントの構成:
- リーダー — 全体の指揮・タスク振り分け
- ライター — 文章生成
- リサーチャー — 情報収集
- コーダー — コード実装
- レビュアー — 品質チェック
役割分担、ルール設定、階層構造の設計に丸2日。40体分のguidelinesファイルは合計数万トークン。
時系列: どう壊れていったか
Day 1-3 ✅ 正常稼働。指示通りに返ってくる
Day 7 ⚠️ 出力の再現性が低下。同じ指示に違う結果
Day 7-14 🔴 役割を逸脱するエージェントが出現
Day 14 🔴 40人中どれが崩れているか特定不能。ログ追跡 2-3h/日
Day 30 💀 全廃止。ログ確認だけで週10時間以上
こはく氏の言葉:
作業時間を減らすために作ったのに、気づけばログ確認だけで週10時間以上溶けた
壊れる3つの構造的理由
理由1: context rot（記憶の腐敗）
トークン数が増えるほどLLMの精度と想起力が劣化する現象。Anthropic公式ドキュメントでも「文脈は大きければいいわけではない」と明記されている。
Claude Codeの現行仕様では、コンテキストの約83.5%（200Kウィンドウで約167Kトークン）に達するとcompactionが発動する。2026年3月時点で1Mコンテキストが一般利用可能になったが、Anthropic CPOのJon Bell氏によるとcompactionイベントは15%減に留まる。
トークン数と安定性の関係（実測ベース）:
~50K tokens ████████████████████ 安定
~100K tokens ████████████████ ブレ始める
~150K tokens ██████████ 明確に劣化
~200K tokens ████ compaction発動
こはく氏の実測: 10万トークンを超えると出力のブレが目立ち始めた。
理由2: compaction後の構成崩壊
長時間運用で会話履歴が自動圧縮（compaction）される。Claude Codeの公式リリースノートにも「圧縮後に一部のエージェントが消えたり、重複生成される不具合」が報告されている。
会話の流れの中だけで役割や引き継ぎを設定していると、圧縮が走った瞬間にその前提ごと消え去る。
こはく氏の表現:
「3人が消えて、2人が重複して、残りの35人はそれに気づかない」
実測: 40人体制で3時間回すとほぼ確実に圧縮が走り、崩壊する。
理由3: テキストのルールは絶対命令ではない
「自分で作業するな。指示だけ出せ」と書いても、LLMにとってルール文は文脈の一部として処理される。履歴、途中のやりとり、直前の出力に引っ張られて解釈がズレる。
学術研究でも裏付けられている。AIエージェントフレームワーク比較2026でも触れた通り、マルチエージェント設計にはフレームワーク選定が重要だ。2025年の論文「Why Do Multi-Agent LLM Systems Fail?」では、マルチエージェントの失敗を14のモードに分類。主要な3カテゴリ:
| 失敗カテゴリ | 内容 | 例 |
|---|---|---|
| 仕様・設計の失敗 | タスク仕様違反、役割逸脱 | 「レビューだけしろ」と言ったのにコードを書き始める |
| エージェント間の不一致 | 情報隠蔽、タスク逸脱 | AがBに必要な情報を渡さない |
| タスク検証・終了の失敗 | 早期終了、検証不足 | バグがあるのに「完了」と報告 |
この論文ではChatDevの正確性が25%程度と報告されており、マルチエージェントの信頼性がまだ低い段階であることを示している。
なぜ「人数を増やす」が機能しないのか
Googleの2026年3月のレポート「Scaling Principles for Agentic Architectures」でも、マルチエージェントのスケーリングにおける3つの効果が報告されている:
| 効果 | 内容 |
|---|---|
| ツール調整トレードオフ | 多くのツールを使うタスクほど、マルチエージェントのオーバーヘッドで性能が下がる |
| 能力飽和 | エージェントを追加しても効果が逓減する |
| トポロジー依存のエラー増幅 | 中央集権型のほうがエラーが少ない |
こはく氏の実体験もこの研究結果と一致する。40体の分散型アーキテクチャは、理論的にも実践的にもスケーリングの壁にぶつかる構造だった。
「育てれば良くなる」は順番が違う
guidelinesを育てる = ファイルが増える = コンテキストが重くなる = context rotが加速。
こはく氏:
壊れやすい仕組みの上に知識を積んでも、崩れやすくなるだけ。エスカレーションルールもない会社に人を増やすのと同じ。
エージェントには全体視野がない
40人全員が自分のコンテキストの中だけで動いている。隣のエージェントが何をやっているか知らない。
こはく氏:
全体をみわたして意思決定する。AとBの矛盾に気づく。Cの出力がDを壊すことを予測する。これは2026年では人間の仕事。
出力の精度を上げる2つのルール
AIの出力がポンコツに見える原因は、プロンプトではなく「一発で完璧に」を求めていること。
ルール1: 「待て」
一発で完成させようとせず、レビューと修正を繰り返す。1回目の出力は下書き。
ルール2: 「検証しろ」
作ったエージェントと別のエージェントにチェックさせる。自分で作ったものを自分でチェックしてもミスに気づきにくい。これは人間もAIも同じ。
この2つを徹底してからやり直し率が体感で7割減。
関連記事: Claude Code完全ガイド2026：インストールから本番運用まで
まとめ: 40人より1人の設計
| 教訓 | 詳細 |
|---|---|
| 40人は構造的に壊れやすい | context rot / compaction / 指示の限界 |
| 育てる前に土台 | 壊れない設計が先、知識の積み上げは後 |
| 「動く」≠「使える」 | エラー検知・特定・修正・担当の4条件が必要 |
| 全体視野は人間 | 現時点ではAIに全体最適の判断は難しい |
| プロンプトが悪いのではない | 「待て」と「検証しろ」で精度は上がる |
AI社員を40人雇うのは、1人を使いこなしたあとでいい。
参考リンク
- AI社員40人を作って、1ヶ月で全部やめた話（こはく氏 / X Article）
- Context Windows — Claude API Docs（公式）
- Claude Code Context Buffer: The 33K-45K Token Problem
- Why Do Multi-Agent LLM Systems Fail?（論文、2025）
- Google: Scaling Principles for Agentic Architectures（2026）
この記事はAI関連コンテンツの解説記事です。
