Claude Code のエージェントを40体つくり、役割を分けてルールを書いて階層もつくった。1ヶ月後、ぜんぶやめた。こはく氏（@Kohaku_NFT）の実体験レポートから、AIエージェント大量運用が構造的に壊れる理由と、そこから見えた「壊れない設計」の考え方を整理する。

やったこと

  • Claude Code の Max プラン（月$200）1アカウントで検証
  • リーダー、ライター、リサーチャー、コーダー、レビュアーなど40体のエージェントを構築
  • 役割分担、ルール、階層、性格設定まで丸2日かけて設計

最初の3日間は動いた。指示を出せばちゃんと返ってくる。SNS でスクショをあげようとした矢先に崩壊が始まった。

壊れる3つの構造的理由

理由1: Context Rot（記憶の腐敗）

Context Rot とは、コンテキストウィンドウに情報が溜まるほど古い情報の精度が落ちる現象のこと。Anthropic の公式ドキュメントにも「トークン数が増えるほど、精度と想起（思い出す力）が劣化する」と明記されている。

  • 1000ページの社内マニュアルと同じ構造 — 人間が全ページを暗記できないように、AIも情報が多すぎると処理しきれなくなる
  • 「100万トークン入る」と「安定して使える」は別物 — 公式でさえ「文脈は大きければいいわけではない」と警告している
  • こはく氏の実測では、10万トークンを超えるとブレが目立ち始めた

ルール、コード、会話履歴が積み上がるほど再現性は低下する。

理由2: Compaction 後に構成が崩れる

長時間運用すると、コンテキストウィンドウの容量を確保するために前半の会話内容が自動で要約・圧縮される仕様（compaction）がある。Claude Code の公式リリースノートにも「圧縮後に一部のエージェントが消えたり、重複して生成される不具合」が明記されている。

  • 会話の流れの中だけで役割や引き継ぎを設定していると、圧縮が走った瞬間にその前提ごと消え去る
  • 会社でいうと「引き継ぎなしの二重配属」 — 過去の議事録を読まずに中途配属され、すでに同じ業務をしている人がいることも知らない状態
  • 40人体制で3時間回せば、ほぼ確実に圧縮が走る。そのたびに「今、誰が消えた？」を人間が確認するハメになる

理由3: テキストのルールは絶対命令じゃない

「自分で作業するな。指示だけ出せ」と書いても、Claude が毎回きれいに従うとは限らない。

LLM にとってルール文は、絶対命令ではなく、文脈の一部として処理される。履歴、途中のやりとり、直前の出力に引っ張られて解釈がズレる。

最近の評価研究でも、LLM は「どの指示を優先するか」の判断や長い文脈での安定した instruction following に弱さがあると報告されている。ルールが増えて競合し始めるほどズレる前提で見たほうがいい。

厳密に書けば書くほど、今度はルールが長くなって context rot が進む。この構造そのものが、人数を増やしたときの壁になる。

「育てれば良くなる」は順番の問題

「使い込むほど育つ」とよく聞くが、ここで否定しているのは育成そのものではなく順番の話。

guidelines を育てるということは、ファイルが増えるということ。ファイルが増えるということは、コンテキストが重くなるということ。つまり context rot が加速するだけ。

壊れやすい仕組みの上に知識を積んでも、崩れやすくなるだけだ。

人間の会社で考えても同じ:

  • エスカレーションルールがない
  • トラブル時の判断基準がない
  • 報告のかたちもない

そんな会社は人を増やすほど混乱する。AI組織もまったく同じ構造。

エージェントには視野がない

ここが核心。

エージェントはAのタスクを動かせる。Bのタスクも動かせる。ただし、AがBに影響して、BがCを壊して、CがDに連鎖する。この全体像を把握できるやつが、40人の中にいない。

40人いても、全員が自分のコンテキストの中だけで動いている。隣のエージェントが何をやっているか知らない。自分の出力が他にどう影響するか見えていない。

「じゃあチーフエージェントを置けばいい」と思うかもしれないが、チーフにも同じ問題がある。チーフもコンテキストの範囲でしか判断できない。会社でいうと、部長も課長も自分の部署しか見ていない状態。トップの判断をする人がいない。

経営者の役割が変わる

ここがAI時代に経営者が担うべき役割の核心:

  • 全体を見わたして、意思決定する
  • AとBの矛盾に気づく。Cの出力がDを壊すことを予測する
  • 「何をやるべきか」「何をやめるべきか」の判断
  • 優先順位をつけて、リソースを配分する意思決定

AIの実行力はすさまじい。1人で10人分の作業をこなせる。ただし全体を見る仕事は、現時点のAIには難しい。コンテキストの壁がある限り、仕組みとして難しい。

経営者の時間の使い方が変わる。プレイヤーから監督者へ。この転換ができるかどうかがAI時代の分かれ目になる。

AIの出力がポンコツなのはプロンプトのせいじゃない

AIがうまく使えないと感じている人の多くは、プロンプトを疑う。「書き方が悪かったのかな」「もっと詳しく指示すればよかったのかな」と。

問題はプロンプトじゃない。「一発で完璧に」を求めていることが原因。

人間の部下に5秒で企画書を作れと言ったら、まともなものは出てこない。あたりまえ。AIにも同じことをしている。

精度を上げるルールは2つだけ:

1. 「待て」 — 一発で完成させようとしない

1回目の出力は下書き。そこからフィードバックして、磨いていく。レビューと修正をくり返させることで品質は大きく変わる。

2. 「検証しろ」 — 作ったやつと別のやつにチェックさせる

自分で作ったものを自分でチェックしても、ミスに気づきにくい。これは人間もAIも同じ。作成と検証を分離するだけで精度は跳ね上がる。

こはく氏はこの2つを徹底してから、やり直し率が体感で7割は減ったという。

まとめ: 40人より、1人の設計

  • 40人は構造的に壊れやすい（context rot / compaction / 指示の限界）
  • 育てる前に壊れない土台が先
  • 「動く」と「使える」は別物（検知・特定・修正・担当の4条件）
  • 全体を見る仕事は、現時点では人間が担うべき
  • プロンプトじゃなくて「待て」と「検証しろ」で精度は上がる
  • AI導入は、自社の組織設計の診断でもある

AI社員を40人雇うのは、1人を使いこなしたあとでいい。まず1人から始めよう。