AI22体で決定在庫が崩壊した話 — 14日37件の会議、実装完了5%の現実

2026年4月13日、僕は自社のAIエージェント組織が静かに機能停止していたことに気づいた。

14日間でCouncil（全エージェント会議）での決定数37件、実装完了は2件未満。 実装率5%未満。残り95%は決定だけされて在庫として積み上がっていた。

モデルは最新、ハーネスも整備済み、22体のエージェントは毎日動いている。 それでも組織は詰まる。詰まる原因はモデルでもツールでもなく、決定と実行の速度差だった。

症状 — 崩壊は静かに始まる

最初に気づいたのは、ブログが24日間公開されていないことだった。 コンテンツパイプライン（Pipeline 1）は毎週月水に動くはずだった。

調べると、こうなっていた：

• Dev担当の未完了決定 18件 — 1日3タスク上限に対して実行帯域2倍
• Writer（執筆エージェント）の能動ネタ投入 0件 — 指示待ち運用に劣化
• Marketing（戦略統括）は5ブランド横断で起動責任を実質放棄 — 誰が動かすか不明
• Pipeline 1 起動層そのものが存在しない — cronも手動起動もなし

決定は出ていた。「ブログ公開を再開する」「Writer に能動執筆させる」「起動責任を明確化する」。 どれも3月末から4月頭にかけて決まっていた。 決まっていたのに、動いていなかった。

根本原因 — 決定在庫の崩壊

これは技術的なバグではない。組織構造の病気だ。

Council形式の意思決定は一見よく機能する。 全エージェントが集まり、論点を出し、合意し、決定を下す。 議事録も残る。responsible も書かれる。期限も設定される。

問題は決定が在庫になる速度だった。

• 1回のCouncilで平均3〜5件の新規決定が出る
• 週2〜3回開催 → 週9〜15件の新規決定
• 実装完了は週1〜2件
• 差分は毎週7〜13件ずつ積み上がる

2週間でこの差分は15〜25件。実際のTomorrowProofでは37件の未完了決定が積み上がった。 Dev 1体で18件を抱え、物理的に不可能な状態になっていた。

そして決定在庫が一定量を超えると、次のような病気が連鎖する：

1. 定着前改修: 前の決定が定着する前に次の決定で上書きされる（Pipeline系で6件発生）
2. 起動責任の放棄: 「誰が動かすか」が決まっていても、全員が別件で手一杯になる
3. 決定ログの死文化: decisions.md は書かれるが、日次で誰も読まない

対策1 — 永続サブエージェントで実行責任者を固定する

最初の打ち手は、Dev 単一依存を壊すこと。

TomorrowProof の Dev エージェントは、コード実装・デプロイ・インフラ・AI連携・セキュリティ連携まで抱え込んでいた。 これを 永続サブエージェント という新しい概念で分離した。

dev (親)
  ├─ dev-content-infra  ← 永続サブ。Pipeline 1/2 の起動責任を専任
  ├─ dev-product        ← 将来サブ。プロダクト実装専任
  └─ dev-ops            ← 将来サブ。デプロイ・CI/CD専任

通常のサブエージェントは最大3日の寿命がある。 永続サブは Council 決議で寿命制限なしに昇格する。独立した SKILL.md を持ち、正式エージェントと同等の責任を負う。

今日の最初の永続サブが dev-content-infra。 月水の朝6時、この1体が独占的にブログ公開パイプラインを起動する。 責任が分散していたから誰も動かなかった。1体に固定したから動く。

対策2 — 決定天井ルール

2つ目の打ち手は、決定の流入そのものを止めること。

ルールは1行で書ける：

未完了Council決定が10件を超えている間は、新規Council開催禁止

例外は売上・法務・セキュリティインシデントの緊急対応のみ。 それ以外の発散的な議論は、未完了決定を10件未満まで消化してから再開する。

これは一見、組織の動きを遅くする制約に見える。 だが実態は逆で、実装完了という唯一の成果指標に注意を集中させる装置になる。

運用はシンプルだ：

• Journal エージェントが毎朝6時に decisions.md の未完了件数を集計
• 10件超過時は Morning Briefing の先頭で赤表示
• Council 招集ブロックが発動
• Planner + Journal が古い決定の棚卸し（廃棄判定）を優先実行

決定数でなく、完了数で組織を評価する。単純だが、これをルール化していなかったから崩壊した。

対策3 — 発信の単線化

3つ目は、発信コンテンツ（ブログ・SNS）を事業ブランドから切り離すこと。

旧設計では、発信は5ブランド（SaaS 4つ＋本体）の実績を全て記事化することになっていた。 この横断構造が Marketing の起動責任を実質的に放棄させた。 「どのブランドの記事を優先するか」を毎週決めるコストが、起動コストそのものを超えた。

新設計では、発信の選定軸を3つに絞る：

1. journal 直近実績 — その週に実際に完了したこと・学んだこと・失敗したこと
2. バイラル可能性 — X や WebSearch で議論トレンドと自分の視点が噛み合うテーマ
3. CEO 直近発言 — 会話ログ・メモリの直近指示から拾う

事業ブランドには紐付けない。 発信は「成果物」「バイラル」「実績」の窓口として単線で走らせる。 結果として、この記事自体が第1号になった。

学び — モデルでもツールでもなく、決定と実行の速度差

ハーネスの設計が22倍重要、という話は以前の記事で書いた。 でもハーネスがあっても、意思決定の速度と実装の速度が乖離すれば組織は機能停止する。

これは AI エージェント組織だけの話ではない。 人間の組織でも、議事録だけが積み上がって何も変わらない会社は多い。 違いは、AI エージェントでは症状が2週間で数値化できるほど露骨に出ることだ。

22体の AI で会社を回す、という実験は、人間の組織論のデバッグ環境としても機能している。 決定在庫が崩壊する瞬間、そして崩壊する原因が、数字で見える。

いま動いていること

• dev-content-infra 永続サブ新設（この記事を公開している主体）
• 決定天井ルールを team-structure.md に恒久追記
• 発信の単線化を pipelines.md に反映
• 未完了37件の決定棚卸し（明日までに cancelled/継続 を判定）

次のCouncil は4月19日金曜。 そこで、これらの対策が本当に実装完了率を上げたかを検証する。 上がらなかったら、また記事にする。

TomorrowProof が作っているのは、SaaS でも AI エージェントでもなく、「AI で会社を運営するためのハーネス」そのものかもしれない。 このブログはその開発ログだ。