Issue GraphとPMBOKで読む、開発組織のスケール論 AIは増やせる。
組織は増やせない。

きっかけは、Zennで読んだ「ローカルでの開発やめませんか？Claude Code / Cursorで開発の8割をクラウドに移した話」という記事だった。ローカルのPC上でAIに指示を出す運用から、リポジトリごとクラウドの実行環境へ持っていく運用への転換を扱っている。

Claude Code on the webでは、GitHubのリポジトリをクラウド上の隔離VMへcloneし、複数のタスクを並列実行して、変更をbranchとしてpushできる。Cursor Cloud Agentsはさらに一歩進み、エージェントごとにデスクトップ環境つきのVMを用意する。ブラウザやアプリを実際に操作し、スクリーンショット・動画・ログをPRへ残すところまでやってくれる。

個人で1〜2体のエージェントを使っているぶんには、この転換は素直にありがたい。だが、この記事はもう一段先を考えたい。エージェントの全体像そのものは以前「AIエージェントとは何か」で整理した。今回はその続き——組織で大量に使い始めたとき、何が起きるかを考える。

ここで生成AI以前の大規模開発の知見が効いてくる。全員が全員とコミュニケーションしなければならない組織を単純化すると、主体がN個あるときの通信経路の数は「N人×(N−1)人÷2」で増えていく。

もちろん実際の組織が完全結合になるわけではない。だが主体を増やすだけでは、調整コストが急激に増えるという感覚は、これで掴みやすくなる。

これは昔から知られている問題でもある。『人月の神話』で知られるBrooksの法則——「遅れているソフトウェアプロジェクトに人員を追加すると、さらに遅れる」——の背景には、仕事の再分割・教育・コミュニケーションといった調整コストがある。AIエージェントが大量に使えるようになったとしても、この問題そのものが消えるわけではない。むしろ100体、1000体とWorkerを増やせるようになるほど、「誰と誰を通信させないか」のほうが重要になる。

そこで効いてくるのが、AIエージェントを組織の構成員として一体ずつ扱わないという発想だ。内部で何体のAIが動いていても、外から見えるのは1つの責任主体でいい——エージェントハーネスの内部で書いたSubAgentの仕組みは、まさにこの入れ子構造を実装レベルでやっている。

クラウドエージェントによって計算能力は増やせても、人間組織の認知能力まで同じ速度で増えるわけではない。Team Topologiesが、小さく安定した5〜9人程度のチームや、チームの認知負荷を重視しているのも同じ文脈で理解できる。Claude Codeは「分ける」より「混ざらない設計」が大事で書いた話も、単位を人からエージェントに変えれば、そのままここに接続する。AI時代にも人間チーム自体を巨大化するのではなく、小さい人間チームが扱える計算能力だけを増やす方向になるのではないかと思う。

ここでPMBOKなど、従来のプロジェクトマネジメント知識が急に面白く見えてくる。各Issueの所要時間をどれだけ短くしても、プロジェクトの最短完了時間はCritical Path——依存関係を辿った、最も時間のかかる一本の鎖——より短くはならない。

10個の100時間タスクが完全に独立していれば、10体のAgentで並列化して約100時間まで短縮できる。ところが同じ10個が直列に依存していれば、Agentが1000体いようと1000時間である。AIが速くするのは主に各ノードの実行時間。しかし依存関係そのものはAgentを増やしても消えない。モデルが速くなればなるほど、「コードを書く速度」より「仕事をどう分解するか」の方が支配的になっていく。

この限界は、並列計算で有名なAmdahlの法則にも似た形で現れる。プロジェクト全体のうち並列化可能な割合をP、Agent数をNとすると、Agentを無限に増やしても短縮率は(1−P)分の1で頭打ちになる。

P=0.8なら、Agentを100倍用意しても5倍の壁は越えられない。つまりAIエージェントを100倍用意するより、P=0.8を0.95へ——仕事そのものを並列化しやすく設計するほうが効く場合がある。ここでソフトウェアアーキテクチャとプロジェクトマネジメントがつながってくる。理想的には、誰が誰と調整するか（Communication Graph）とどのモジュールが何に依存するか（Code Dependency Graph）とどのIssueが何の完了を待つか（Issue Graph）の3つがある程度一致している方がいい。1つのIssueを終えるのにフロントもバックエンドも決済もインフラも触る必要があるなら、単にIssueの切り方が悪いだけでなく、システムの境界自体が並列開発しにくい可能性がある——これはConwayの法則の裏返しでもある。

PMBOK第8版は2025年11月に公開され、Governance・Scope・Schedule・Finance・Stakeholders・Resources・Riskという7つのPerformance Domainを扱い、AIについての記述も拡充されている。もちろん、AI時代だから巨大なWBSや詳細なガントチャートへ戻る、という意味ではない。価値が上がるのは、複雑な仕事を、制御可能な構造へ変換する知識の方だと思う。

これはかなり現代的な使い方に見える。プロジェクト全体のコストを雑に、実行コスト＋調整コスト＋統合コスト＋意思決定コスト＋失敗コストと考えると、生成AIが猛烈な勢いで下げているのは主に実行コストだけだ。実装が10倍速くなっても、何を作るか・どの順番で作るか・誰がどこを触るか・どう統合するか・何をもって正しいとするか・どこまでAIへ権限を与えるか——というコストは自動的には消えない。むしろ実装能力が大きくなればなるほど、こちらがボトルネックになる。

比喩的に言えば、Claude CodeやCursor、CodexといったエージェントがWorkerだとすると、Scope・Issue Graph・Resources・Risk・Governance・Quality GateはControl Planeになる。KubernetesでPodを大量に実行できるからこそSchedulerやResource Limitが必要になるのと似ている。

今回調べながら考えた結果、面白いのはその多くが全く新しい知識ではないことだった。Brooksの法則、Conwayの法則、PMBOK、Critical Path、Team Topologies、DORA、Small Batch、CI/CD。生成AI以前の大規模開発で培われてきた知識が、AIエージェント時代になって別の意味を持ち始めている。つまり、AIエージェントを何体動かせるかではなく、何体を安全に並列稼働させられる組織を作れるか。ここが本当の競争になっていくのかもしれない。