2026年春。
Claude Code界隈が大きく揺れた。
Agent SDK課金。
月額制限。
“無制限AI労働力” の終わり。
Redditには怒りが溢れ、
Xには「Anthropicは終わった」が並んだ。
だが、
この騒動を単なる値上げ問題として見ると、
本当に重要な変化を見落とす。
Claude Code界隈で起きていたのは、
「AIが賢くなった」
ことではない。
“AIが組織化し始めた”
という変化だった。
そして興味深いことに、
その瞬間AIは、
人類が何百年もかけて作ってきた
「会社」という構造を、
驚くほど忠実に再演し始めたのである。
AI Agentは、なぜ“会社”になってしまったのか
人々は、
AI Agentを“万能労働力”だと思っていた。
AIに指示を出せば、
自律的に考え、
自律的に設計し、
自律的に開発し、
人間は完成を待つだけ。
そんな未来像が、
ここ1〜2年、繰り返し語られてきた。
しかし、
Claude Code時代に実際に現れたものは、
もっと奇妙な存在だった。
それは、
“デジタル社員”
だった。
Claude Code界隈で起きていたことを、
冷静に分解すると面白い。
そこでは、
- Planner Agent
- Reviewer Agent
- Refactor Agent
- Documentation Agent
- Test Agent
といった役割分担が、
ごく自然に発生していた。
しかも、
それは単なる概念ではない。
OpenCode。
Hermes。
ACP。
独自 orchestration harness。
ユーザー達は、
Claudeを“会話AI”として使っていたのではなく、
“AI労働力”
として編成し始めていた。
repo全体を解析させ、
Issueを分解し、
sub-agentへタスクを振り、
parallel reviewを走らせ、
最後に統合する。
そこに現れていたのは、
もはやチャットUIではない。
“組織”そのものだった。
興味深いのは、
この構造が、
人類の組織論を極めて忠実に再演していたことだ。
Agent数を増やすと、
確かに開発速度は上がる。
しかし同時に、
奇妙な問題が発生し始める。
同じファイルを何度も読む。
同じ推論を繰り返す。
互いの結論を検証し合う。
レビューが多重化する。
そして最終的に、coordination cost が爆発する。
これは、
企業組織で何十年も繰り返されてきた問題と、
驚くほど同じだった。
人類は長い時間をかけて、
“組織”という仕組みを作ってきた。
なぜか。
一人の人間では、
contextを保持しきれないからだ。
巨大プロジェクトになるほど、
- 設計
- 実装
- テスト
- ドキュメント
- インフラ
- UI
- セキュリティ
は分業化される。
Claude Codeが突破した問題も、
実は同じだった。
それは、
“1モデル万能論”の限界だった。
当時、多くの人は信じていた。
context windowさえ増えれば、
AIはrepo全体を理解し、
巨大コードベースを完全把握できるのだと。
しかし現実には、
contextが巨大化するほど、
- attentionは薄まり
- 重要情報は埋もれ
- reasoningは漂流し
- tokenコストは膨張する
巨大な会議室に1000人を詰め込んでも、
会議が賢くなるわけではない。
Claude Codeが示したのは、
“contextを増やす”
ではなく、
“contextを分業する”
という発想だった。
これは本質的には、
“LLM版マイクロサービス”
だった。
そして、
ここからが重要だ。
Agent数を増やせば、
確かに賢くなる。
しかし、
同時にコストも増える。
しかもそのコストは、
単なるAPI利用料ではない。
推論。
同期。
検証。
レビュー。
context transfer。
つまり、
“AI人件費”
だ。
Redditで、
「Claude burns tokens like crazy」
という声が溢れていたのは、
実に象徴的だった。
多くの人は、
これを単純な“価格問題”として見ている。
しかし本質は違う。
Claude Code界隈で起きていたのは、
“AI組織の運営”
だった。
sub-agentを10体走らせれば、
確かに仕事は速くなる。
だが同時に、
- reasoning が重複し
- verification が増え
- synchronization が発生し
- context transfer が必要になる
つまり、
AI社員を100人雇えば、“AI社員100人分の管理コスト”が発生する。
極めて当たり前の話だ。
しかし界隈は、
初めてそれを“体感”した。
そして、
ここで多くの人が誤解している。
Anthropicは、
単に“値上げ”したわけではない。
むしろ彼らは、
“AI組織化”
を初めて現実へ持ち込んだ。
だからこそ、
コスト問題が表面化した。
これは失敗ではない。
むしろ、
成功したからこそ起きた問題だった。
さらに興味深いのは、
ここで人類の古典的問題まで再現され始めたことだ。
- 無能な会社ほど、会議が増える。
- 曖昧な指示ほど、確認コストが増える。
- 責務分離が曖昧な組織ほど、無駄なコミュニケーションが増殖する。
AI Agentも全く同じだった。
Claude Codeは、
確かに大量のcontextを消費する。
だが、
その前に疑うべきものがある。
CLAUDE.md。
workflow。
repository構造。
責務境界。
documentation。
つまり、
“人間側の組織設計”
だ。
Agentの数が増えれば強い。
そんな単純な話ではない。
重要なのは、
“context flow をどう設計するか”
だった。
そして、
それは驚くほど、
人間組織のマネジメントと似ていたのである。
「AI社員100人」の夢 ─ 人々は何に熱狂していたのか
Claude Code界隈を外から見ていた人々は、
時々、不思議そうな顔をしていた。
「そんなに大量のAgentを走らせて、
本当に必要なのか？」
「結局、全部読むのは人間なのでは？」
その疑問自体は、間違っていない。
しかし、
実際にCC文化へ深く浸かった人々が熱狂していたのは、
単なる“自動化”ではなかった。
彼らが本当に体験していたのは、
“時間の圧縮”
だった。
これは、
実際に触った人間にしか分かりにくい。
repo全体解析。
migration。
documentation整備。
test生成。
dependency調査。
影響範囲確認。
従来なら、
数日〜数週間かかっていた作業が、一晩で終わる。
しかも、その速度は単なる“速い”ではない。
人間が思考する際の、“待ち時間”そのものが消える。
例えば、
巨大repoを解析している時。
人間だけでやれば、
- grep
- ドキュメント確認
- 依存関係追跡
- 実装確認
- テスト影響調査
を延々と繰り返す。
context switching は発生し、
集中力は削られ、
脳は徐々に疲弊していく。
しかし、
Agent群を走らせると、
- UI側
- backend側
- DB migration
- test
- API影響
を並列で調査できる。
つまり、
“思考待ち”
が消える。
ここで重要なのは、
Claude Code文化が売っていたものは、
“コード生成”ではなかったことだ。
本当に売っていたのは、
“認知負荷の外部化”だった。
人間の脳は、
万能ではない。
repoが巨大化するほど、
- 何を見たか
- どこを読んだか
- 何を確認したか
- どこが危険か
を保持し続けることが難しくなる。
Claude Code文化は、
この問題に対して、
“AIへ思考の並列化を委譲する”
という方法を提示した。
これは、
単なる便利ツールではない。
一種の、
“認知拡張”
だった。
だからこそ、
界隈は熱狂した。
Redditには、
毎日のように、
「repo-wide analysis が革命的だ」
「夜中にsub-agentを走らせて、
朝にはmigrationが終わっていた」
「もはや一人で小企業レベルの開発ができる」
そんな声が溢れていた。
彼らは、
単にAIへ夢を見ていたわけではない。
実際に、
“個人の生産限界”
が変わり始めていることを、
体感していた。
だから、
現在起きている「高い」という怒りも、
単純なクレーマー心理ではない。
むしろ逆だ。
人々は、
“既に価値を体験してしまった”
のだ。
これは極めて重要なポイントである。
例えば、
従来のSaaS値上げなら、
人々は比較的冷静だ。
多少不便でも、
代替はある。
しかし、
Claude Code文化が提供していたものは、
単なる機能ではなかった。
それは、
“時間”
だった。
しかも、
人間にとって最も回復しづらい資源である、
“集中力のある時間”
だった。
だから、
界隈の怒りには、
ある種の切実さがある。
「もうこの速度を知ってしまった」
「もう以前の開発へ戻れない」
「AI無しで巨大repoを読むのが苦痛になった」
これは、
単なる依存ではない。
道具が身体へ統合され始めた時に起きる、
典型的な反応だ。
だが、
ここで非常に興味深い逆転現象が起きる。
人々は、
「AIが全部やる世界」を夢見ていた。
しかし実際に起きたのは、
“AI管理職問題”
だった。
Agent数が増えるほど、
- 誰が何をやっているか
- どこまで確認済みか
- どのAgentが正しいか
- どこでhallucinationが混入したか
を管理する必要が出てくる。
つまり、
“AI組織のマネジメント”
が発生する。
これは極めて皮肉だ。
なぜなら、
多くの人は、
「人間管理コストを消したい」
と思ってAgentへ熱狂していたからだ。
しかし結果として現れたのは、
“AI版中間管理職問題”
だった。
そして、
ここでようやく、
PMという存在の意味が逆照射され始める。
PMは、
単なる進行管理係ではない。
本質的には、
“巨大なcontextを交通整理する存在”
だった。
Claude Code時代になって、
初めて多くのエンジニアが、
「なぜ組織にPMが必要なのか」
を、体感として理解し始めたのである。
「全部AIにやらせればいい」は、なぜ崩壊したのか
AI Agent文化が加熱し始めた頃、
界隈には独特の空気が漂っていた。
「もう人間がコードを書く時代は終わる」
「AIが設計し、AIが実装し、AIがレビューする」
「人間は完成を待つだけになる」
そうした言葉は、
半ば本気で語られていた。
実際、
Claude Code時代初期の衝撃は、
それほど強かった。
repo全体を解析し、
複数ファイルを横断修正し、
READMEを書き換え、
testを生成し、
Issueを解決する。
その姿は、
従来の“コード補完AI”とは明らかに違っていた。
人々は、
そこに“労働力”を見た。
しかし、
時間が経つにつれ、
奇妙な現象が起き始める。
Agentを増やすほど、
人間の監督負荷が増えていくのだ。
これは非常に皮肉だった。
本来、
Agent化の目的は、
“人間を管理から解放すること”
だったはずである。
しかし実際には逆だった。
例えば、
巨大repoに対して、
複数Agentを並列投入する。
すると、
確かに開発速度は上がる。
しかしその一方で、
- どのAgentが何を変更したか
- どの結論が正しいか
- どのreviewが古いか
- どのhallucinationが混入したか
を追跡する必要が生まれる。
しかも厄介なのは、
Agent達が“それっぽく”動いてしまうことだ。
これは、
実際に使った人ほど分かる感覚だと思う。
Agentは、
時々驚くほど賢い。
本当に人間の熟練エンジニアのような修正をする。
repo構造を理解し、
命名規則を読み取り、
設計思想を推測し、
「なぜそう実装されているか」まで考慮する。
しかし同時に、
時々とんでもないことをする。
3000行を壊す。
存在しないAPIを作る。
古いcontextを信じ込む。
未確認の仮定を前提化する。
しかも、
その出力は極めて自信満々だ。
ここで多くの人が、
初めて気付き始める。
問題は、“AIの能力不足”ではなかった。
問題は、“人間がAIをどう監督するか”だった。
この時点で、
界隈には二種類の人間が現れ始める。
一つは、
「全部AIに任せたい」
と考え続ける人々。
もう一つは、
「AIは極めて優秀だが、
最終責任は人間が握るべきだ」
と理解し始めた人々。
この差は、
かなり大きかった。
特に面白かったのは、
Claude Code文化が、
“PMという職能”
を逆照射し始めたことだ。
従来、
PMは時々軽視されていた。
コードを書かない。
直接成果物を作らない。
会議ばかりしている。
そんな風に見られることも多かった。
しかし、
Agent組織が巨大化し始めると、
突然PMが必要になる。
なぜか。
“誰かがcontextを交通整理しないと、全体が崩壊する”
からである。
ここで重要なのは、
PMの本質が、
“進捗管理”
ではなかったことだ。
本当の役割は、
“意味の整合性維持”
だった。
- このrepoは何を目指しているのか
- この変更は本当に必要か
- どこで妥協するのか
- どの設計思想を優先するのか
これらを決める存在がいなければ、
Agentはどれだけ増えても、
方向を見失う。
そして、
ここでさらに重要な問題が現れる。
多くの人は、
「Claudeがtokenを無駄遣いしている」
と批判した。
確かにそれは一面では正しい。
Claude Codeは、
大量のcontextを読む。
sub-agentを増やせば、
token消費は爆発する。
だが、
その前に疑うべきものがある。
CLAUDE.md だ。
曖昧な前提。
雑なworkflow。
責務分離の欠如。
放置されたREADME。
散乱したdocumentation。
人間組織でも、
構造が悪い会社ほど、
無駄な会議が増える。
確認が増える。
報告が増える。
重複作業が増える。
AI Agentも、
驚くほど同じだった。
つまり、
問題は単純な“モデル性能”ではない。
本当に重要だったのは、
“context flow の設計”
だった。
Agentの数が増えれば強いわけではない。
どの情報を、
誰へ、
どの粒度で、
どう受け渡すのか。
そこに設計思想が無ければ、
Agent組織は急速に濁り始める。
これは非常に興味深い現象だった。
なぜなら、
AIは会社を消滅させるどころか、
“なぜ会社という構造が存在していたのか”
を、
人類へ逆に教え始めたからである。
Codexは、なぜ“静か”だったのか
Claude Code文化が、
“AI組織論”
だとするなら。
Codexが提示したものは、
かなり違っていた。
それは、
“人間PM中心論”
だった。
Claude Codeへ熱狂していた人々が、
Codexへ移住して最初に感じたもの。
それはしばしば、
「おとなしい」
という感覚だった。
勝手にrepoを徘徊しない。
突然architectureを書き換えない。
大規模refactorへ暴走しない。
READMEを勝手に全面改稿しない。
Claude Code文化に慣れた人間ほど、
最初は物足りなさを覚える。
そこには、
あの“魔法感”が薄かった。
しかし、
しばらく使い込むと、
別の感覚が現れ始める。
「あれ…壊れにくい」
のである。
これは、
単なるモデル性能差ではない。
思想そのものが違う。
Claude Code文化は、
本質的に、
“AIへ裁量を渡す”
方向だった。
一方、
Codex文化は逆だ。
“人間が裁量を保持する”
のである。
この違いは、
実際のworkflowへ強く現れる。
Claude Code文化では、
- repo-wide解析
- autonomous planning
- multi-agent orchestration
- broad refactor
- exploratory reasoning
が自然に発生する。
しかしCodex文化では、
- 小さなdiff
- 局所修正
- patch単位管理
- review前提
- 人間主導設計
が中心になる。
つまり、
Codexは、
“AIへ全権委任しない”
のである。
これは一見、
保守的に見える。
だが、
実務では非常に重要な差になる。
なぜなら、
巨大repoにおいて本当に恐ろしいのは、
“賢い間違い”
だからだ。
Agentが最も危険なのは、
明らかなhallucinationではない。
むしろ、
“8割正しい”
時である。
repo構造を理解し、
設計思想を読み取り、
命名規則を守り、
綺麗なコードを書く。
しかし、
根本前提を一つだけ誤解している。
この状態が、
最も危険だ。
なぜなら、
人間レビューをすり抜けやすいからである。
Codex文化は、
ここをかなり強く警戒しているように見える。
だから、
- diffを小さくする
- 変更範囲を限定する
- 人間reviewを前提化する
- patch単位で積み上げる
方向へ寄っている。
これは、
Agent幻想から一歩引いた設計思想とも言える。
興味深いのは、
ここで“context”の扱い方まで変わることだ。
Claude Code文化では、
contextをAgent群へ分散した。
しかしCodex文化では、
contextそのものを外部化する。
GitHub。
Issue。
README。
ADR。
PR。
CI。
つまり、
“AIの脳内へ閉じ込めない”
のである。
これは極めて重要な転換だった。
なぜなら、
AIのcontextは揮発性だからだ。
どれほど長contextになっても、
AI内部の理解は、
永続的な組織記憶にはならない。
しかし、
- Issue
- documentation
- PR history
- architecture note
は残る。
つまりCodex文化は、
“AI組織”
ではなく、
“AI開発ライン”
へ近い。
ここで、
界隈にもう一つの誤解が生まれる。
「CodexはAgentとして弱い」
という声だ。
しかし実際には、
単に目指している方向が違う。
Claude Codeが追求したのは、
“AIへ仕事を委譲する世界”
だった。
Codexが目指しているのは、
“人間の設計能力を増幅する世界”
に見える。
だから、
Codexは時々、
奇妙なほど“静か”だ。
勝手に盛らない。
勝手に夢を見ない。
勝手にrepo哲学を書き換えない。
しかしその代わり、
- reviewしやすい
- rollbackしやすい
- reasoningを追いやすい
- 差分管理しやすい
という、
極めて現実的な強さを持つ。
ここで、
界隈はようやく気付き始める。
本当に重要なのは、
“AIが全部やること”ではなかった。
本当に重要だったのは、
“人間が巨大contextを扱えるようになること”
だったのである。
そして、
この地点まで来ると、
AI Agent論は、
単なる自動化論ではなくなる。
それは次第に、
“人間とAIの責務分離”
という、
極めて古典的なテーマへ近づいていく。
AIは、会社を消滅させなかった
AIが進化すれば、
会社は不要になる。
管理職はいなくなる。
会議は消える。
中間承認も不要になる。
そうした未来予測は、
ここ数年、繰り返し語られてきた。
特にAgentic AIブームの頃には、
「AI社員100人」
という言葉が、
半ば本気で語られていた。
一人の人間が、
大量のAI Agentを従え、
会社そのものを圧縮する。
それは確かに、
魅力的な夢だった。
そして実際、
その夢は部分的には実現した。
これは重要だ。
Claude Code文化を、
単なる幻想として片付けるべきではない。
実際に、
- 開発速度
- repo解析
- migration
- documentation
- テスト生成
- 調査能力
は、劇的に向上した。
一人で扱えるrepo規模も、
確実に拡大している。
従来なら、
10人〜20人必要だった開発が、
一人 + AI
で成立し始めている。
これは誇張ではない。
実際に、
世界中でその現象が起きている。
しかし、
そこで人類が見たものは、
意外な光景だった。
AIは、会社を消滅させなかった。
むしろ逆に、
“なぜ会社という構造が存在していたのか”
を、再演して見せたのである。
Agentを増やすほど、
coordination cost が増える。
役割分担が必要になる。
責務分離が必要になる。
documentation が必要になる。
review が必要になる。
そして最終的に、
“誰かが全体責任を持たなければならない”
という、
極めて古典的な問題へ戻ってくる。
これは、
非常に象徴的だった。
なぜなら、
AI Agent文化の一部には、
「もう人間管理はいらない」
という空気が、
確かに存在していたからだ。
しかし実際には逆だった。
Agent組織が巨大化するほど、“PM”の重要性が増していく。
ここで、
PMという職能の意味が、
改めて見えてくる。
PMは、
単なる進行管理係ではない。
本質的には、
“巨大な意味構造を維持する存在”
だった。
repoは、
単なるコードの集合ではない。
そこには、
- 設計思想
- UX哲学
- 命名文化
- 妥協点
- 禁止事項
- 優先順位
- 歴史的経緯
が存在する。
そして、
それらの多くは、
documentationへ完全には書き切れない。
つまり、
巨大プロジェクトとは本来、“意味の維持”そのものだった。
AI Agentは、
驚異的な速度でコードを書ける。
しかし、
「何を作るべきか」
までは決めてくれない。
もっと正確に言えば、
決めている“ように見える”ことはある。
だが、
その判断の最終責任は、
結局、人間へ戻ってくる。
これは、
AI能力不足の話ではない。
むしろ逆だ。
AIが強くなればなるほど、
“最後に誰が決めるのか”
という問題が、
より重くなる。
例えば、
Agentが完璧に近いCRMを構築したとする。
workflow。
権限管理。
検索。
CSV。
通知。
dashboard。
技術的には、
もはや十分可能だ。
しかしその瞬間、
新しい問題が現れる。
- この権限設計で良いのか
- この顧客データを扱って良いのか
- このログ保持期間で問題ないのか
- 障害時に誰が説明責任を負うのか
つまり、
“社会的責任”
である。
ここで、
AnthropicやOpenAIが最近強く押し出している、
- governance
- monitoring
- security
- policy
- auditability
の意味も見えてくる。
彼らは単に、“安全性アピール”をしているわけではない。
本当に恐れているのは、“能力不足のAI”ではない。
“能力が高すぎるAIを、人間が雑に運用すること”
なのである。
そして、
この地点まで来ると、
AI時代の競争軸も変わり始める。
重要なのは、
“どれだけ多くのAgentを持っているか”
ではない。
本当に重要なのは、
- context flow
- 意思決定構造
- documentation
- 責務境界
- PM能力
つまり、
“AI組織設計”
だった。
AIは、会社を消滅させなかった。
むしろ、
「会社というものが、
なぜ何百年も存在してきたのか」
を、私たちへ逆照射し始めたのである。
「AIが全部やる世界」は、本当に幸福だったのか
ここまで、
Claude Code文化とAgent組織論について語ってきた。
しかし、
この話にはもう一つ、
非常に重要な側面がある。
それは、
“人間は本当に、
全部をAIへ委譲したかったのか？”
という問題だ。
AI Agent文化が加熱していた頃、
界隈には独特の陶酔感があった。
「寝ている間に開発が終わる」
「朝起きたらPRが積まれている」
「repo解析が一晩で終わる」
その感覚は、
確かに革命的だった。
実際、
そこには強烈な快感がある。
なぜなら、
人間にとって最も苦しいものの一つが、
“認知負荷”
だからだ。
巨大repoを読む。
dependencyを追う。
影響範囲を確認する。
古いコードを解析する。
これらは、
創造的というより、
持久戦に近い。
Claude Code文化は、
そこから人間を解放し始めた。
しかし、
ここで奇妙な現象が起きる。
Agent化が進むほど、“人間の手触り”が失われ始めるのである。
これは、
実際にAgent運用を深くやった人ほど、
どこかで感じ始める。
AIは、
驚異的な速度で仕事を進める。
だが、
大量のAgentが並列で動き始めると、
「いま何が起きているのか」
を、
人間側が把握しづらくなる。
repo-wide reasoning。
parallel planning。
background task。
multi-agent orchestration。
それらは確かに強力だ。
しかし同時に、
“自分が作っている感覚”
が薄れていく。
これは非常に興味深い逆説だった。
なぜなら、
多くの人が求めていたのは、“開発から解放されること”ではなかったからだ。
本当に求めていたのは、“苦痛から解放されること”だった。
ここを混同すると、
Agent幻想は暴走する。
- AIが全部設計する
- AIが全部実装する
- AIが全部レビューする
- AIが全部意思決定する
そこまで進むと、
人間は次第に、
“開発者”
ではなく、
“監査役”
へ近づいていく。
そして、
ここで多くの人が気付き始める。
「それって、本当に面白いのか？」
と。
プログラミングという行為には、
元々、
奇妙な快楽がある。
設計する。
構造を整理する。
UIを考える。
名前を付ける。
データを流す。
それは単なる労働ではない。
一種の、
“意味の構築”
だ。
だから、
Codex文化が静かに支持を広げている理由も、
実はここにあるのかもしれない。
Codexは、
Claude Codeほど派手ではない。
勝手に世界を書き換えようとはしない。
しかしその代わり、
“人間の設計権”
を残す。
これは、
単なる安全設計ではない。
ある意味では、
“人間の創造感覚を残す設計”
でもある。
ここで、
AI時代の極めて重要な問題が見えてくる。
AIは、
確かに人間の能力を増幅する。
しかし、
増幅しすぎると、
今度は人間側が、
“主体感”
を失い始める。
これは、
単なるエンジニア論ではない。
もっと広い話だ。
AIによって、
文章を書く速度は上がる。
デザイン速度も上がる。
開発速度も上がる。
だが、
その先にあるのは、
“何を作るべきか”
という、
極めて人間的な問題である。
Agentを増やせば、
開発速度は上がる。
しかし、
幸福まで比例するとは限らない。
むしろ、
AI時代になって初めて、
“人間は、
どこまでをAIへ委譲したいのか”
という問いが、
現実問題として現れ始めている。
そしておそらく、
これから本当に重要になるのは、
“AIをどれだけ自動化したか”
ではない。
“人間が、
どこへ意味を残すのか”
なのだと思う。
AIは、人類の「組織」を映し出した
Claude Code騒動を、
単なる「値上げ問題」として見ることはできる。
実際、
SNSには怒りが溢れていた。
「高すぎる」
「制限が厳しい」
「Anthropicは裏切った」
そうした声は、
これからもしばらく続くだろう。
しかし、
この数ヶ月で本当に起きていたことは、
もっと大きい。
人類は初めて、
“AI組織”
を実務レベルで運営し始めた。
そして、
その結果見えてきたものは、
驚くほど古典的だった。
Agentを増やせば、
coordination cost が増える。
役割分担が必要になる。
documentation が必要になる。
責務境界が必要になる。
review が必要になる。
そして最終的に、
“誰かが全体責任を持たなければならない”
という、
極めて人間的な問題へ戻ってくる。
これは皮肉でもあり、
同時に非常に重要な発見でもある。
AIは、
会社を消滅させなかった。
むしろ、
“なぜ会社という構造が存在していたのか”
を、
逆に人類へ教え始めた。
Claude Code文化は、
確かに偉大だった。
初めて、
“AIによる組織化”
を、
現実へ持ち込んだからだ。
人々はそこに熱狂した。
なぜなら、
実際に価値があったからだ。
repo-wide analysis。
parallel reasoning。
background orchestration。
巨大repo解析。
認知負荷の外部化。
そこには、
単なるコード補完ではない、
“時間圧縮”
が存在した。
だからこそ、
現在の怒りも、
単純なクレームではない。
人々は既に、
“AI組織化による速度”
を知ってしまった。
もう、
昔の開発速度へ戻れない。
巨大repoを、
一人で延々grepしていた時代へは、
戻りたくない。
その感覚は、
よく分かる。
しかし同時に、
人類はもう一つの事実にも気付き始めた。
Agent数を増やせば、
すべてが解決するわけではない。
むしろ重要だったのは、
“context flow の設計”
だった。
無能な会社ほど、
会議が増える。
AI Agentも同じだった。
曖昧なCLAUDE.md。
整理されていないrepo。
不明瞭な責務分離。
散乱したdocumentation。
そうした構造の上では、
Agentは無限に迷い始める。
つまり問題は、
“AIが無駄にtokenを使うこと”
ではない。
“人間が、
どんな組織を設計していたか”
だった。
そして、
ここでようやく、
PMという存在の意味も見えてくる。
PMとは、
単なる進行管理係ではない。
巨大なcontextを整理し、
- 何を優先するのか
- どこで妥協するのか
- どの思想を守るのか
- どこへ責任を置くのか
を決める存在だった。
つまり、
“意味を維持する役割”
だったのである。
AIは、
驚異的な速度でコードを書ける。
だが、
最後に残る問題は、
今も昔も変わらない。
「何を作るべきか」
である。
AI時代になって、
コードを書くコストは急速に下がり始めた。
しかしその一方で、
“意味を決める能力”
の価値は、
むしろ上がっている。
- 発想力
- 設計力
- 優先順位
- UX感覚
- 世界観
- 責任感
そうしたものが、
これからの時代の本当の差になる。
だから、
AI時代の競争は、
単純な自動化競争ではない。
どれだけ多くのAgentを持つかでもない。
本当に問われ始めているのは、
“どれだけ巨大な意味構造を、
人間が維持できるか”
なのだと思う。
そして、
その問いは、
実は極めて古典的でもある。
AIは、未来そのものというより、
“人類がずっと抱えてきた問題”
を、高速に再演する鏡なのかもしれない。
