業務別エージェントを何千個も量産するのも、すべての仕事を一つの万能AIに任せるのも——私はどちらも慎重であるべきだと考える。大企業AXの核心はエージェントの数ではなく、運用可能な単位で管理されているかである。
先日、ある動画を見ながら少し長く考え込んでしまった。
動画の要点はおおよそこうだった。企業が「〇〇業務自動化エージェント」を一つずつ作り始めると、結局は数百、数千のエージェントが積み上がり、それは保守の地獄になりかねない、という話だ。だから特定の業務ごとにエージェントを作り続けるSI的な発想から抜け出し、Claude CodeやCodexのような汎用スーパーエージェントを組織全体でうまく活用できるようにすべきだ、という主張だった。
動画の問題意識そのものは理解できる
実際、AI時代に過去のSI方式そのままで「議事録エージェント」「カードニュースエージェント」「リスクアセスメントエージェント」「財務予測エージェント」をそれぞれ別々に構築するやり方は危険になりうる。そうやって作れば機能が重複し、プロンプトも散らばり、権限も散らばり、データも散らばり、誰が保守するのか分からない自動化の断片が社内に積み上がっていく。
その意味で「業務別エージェントの乱立を警戒すべきだ」というメッセージは正しい。
しかし「エージェント4,000個」という前提が引っかかった
だが私が引っかかったのはその先だった。そのリスクを説明するために「大企業がエージェントを300個、400個、4,000個と作るようになる」という前提が敷かれているように聞こえたからだ。
私はこの前提をそう簡単には受け入れられなかった。
私が経験した大企業はそのように動かない。もちろん非効率もあり、部門のセクショナリズムもあり、古いSIの文法もある。しかしだからといって、大企業が何の統制もなく業務別エージェントを数千個も発注し運用する組織ではない。
大企業には次のようなものがある。
- 稟議（りんぎ）
- 予算審査
- セキュリティレビュー
- アーキテクチャレビュー
- 個人情報レビュー
- 運用引き継ぎ条件
- 障害責任
- 保守契約
- 監査ログと権限管理
これらの仕組みが完璧だという意味ではない。しかし少なくとも正式な運用システムに入る瞬間、個別部門の要求がそのまま一つの独立システムとして無限に増殖する構造は、簡単には許されない。
大企業は通常、現場から上がってくる要求を集約し、重複を排除し、共通機能を抽出し、権限体系を統合し、運用主体を定めたうえで、その中でシステムやプラットフォームとしてまとめ上げる。
4,000個の要求 ≠ 4,000個の独立エージェント
だから私の見立てでは、「エージェントが4,000個できる」という表現そのものが少し乱暴だ。
正確に言えば、大企業の中には4,000個の業務要求がありうる。4,000個の業務シナリオ、4,000個のworkflow、4,000個のrule・role・skill・permissionの組み合わせがありうる。
しかしそれがすなわち「4,000個の独立エージェント」を意味するわけではない。
この区別は重要だ。
4,000個の独立エージェントがそれぞれ別々のやり方で動くなら、それは明らかに危険だ。しかし一つの共通プラットフォームの上で4,000個のworkflowやskillが管理されるなら、話はまったく変わってくる。
前者は乱立だ。後者はガバナンスだ。
より危険なのは反作用だ
私が懸念しているのは、この動画を誤って解釈した人々が「業務別の自動化は古いやり方で、これからはスーパーエージェント一つですべてを処理すべきだ」と受け取ってしまうことだ。
これはまた別の危険な単純化だ。
大企業は、自由に何でもできる万能AIを求めているのではない。大企業が求めているのは、担当者が変わっても同じ品質で処理される業務構造だ。誰が依頼しても同じ基準で判断し、同じ手順に従い、同じ水準の結果を出さなければならない。
だから大企業の業務にはharnessが必要だ。テストケースが必要で、承認手続きが必要で、権限分離が必要で、監査ログが必要で、バージョン管理が必要で、例外処理とロールバックが必要だ。
AIが賢いというだけの理由で、これらすべてが消えてなくなるわけではない。むしろAIがより多くの仕事をこなせるようになるほど、こうした統制の仕組みはより重要になる。
「1億個の仕事ができる」より大切な問い
「スーパーエージェント一つが1億個の仕事をこなせる」という言葉は、聞こえはかっこいい。しかし大企業の立場で重要な問いは違う。
- その1億個の仕事のうち、今このユーザーはどの仕事をする権限があるのか?
- この業務は自動実行してよいのか、それとも承認者が必要なのか?
- この結果はどの基準で検証されるのか?
- 失敗したら誰が責任を取るのか?
- データはどこまでアクセスできるのか?
- 監査の時点でどのログを提示できるのか?
- ポリシーが変わったとき、どのworkflowが影響を受けるのか?
この問いに答えられないスーパーエージェントは、大企業の業務オペレーティングシステムにはなりにくい。
ではスーパーエージェントは不要なのか
もちろんそういう話ではない。
ユーザーの要求を受けて適切な業務workflowへルーティングする上位のorchestratorであれば意味がある。複数のツールやシステムをつなぐインターフェースであれば意味がある。社員が自然言語で業務を依頼し、その裏で適切な権限確認とポリシー検証を経て業務が実行される構造なら、十分に必要だ。
しかしその場合でも、スーパーエージェントはすべてを自ら判断し実行する万能の作業者ではなく、全社ガバナンスの中で動作する業務のエントリーポイントに近くあるべきだ。
私が考える現実的な構造
私が考える大企業AXの方向性は、二択ではない。業務別エージェント4,000個でもなく、すべてを処理するスーパーエージェント1個でもない。
より現実的な構造はこうだ。
- 共通のAgent Platformがあり、
- その上に業務別のworkflowとskillがあり、
- 各workflowにはrole・rule・permission・data boundaryが付き、
- 実行結果はevaluation harnessで検証され、
- すべての過程はaudit logとして残り、
- 重要な業務はhuman approvalを経る。
この構造なら、業務が400個だろうと、4,000個だろうと、40,000個だろうと管理できる。逆にこの構造がなければ、エージェントが10個しかなくても危険だ。
だから核心はエージェントの数ではない。核心は運用可能な単位で管理されているかだ。
まとめとして
私は動画の問題意識には同意する。AIエージェントを過去のSIのように一つずつ量産するやり方は、確かに危険だ。そのやり方で進めば保守の地獄がやってくる。
しかしその前提が「大企業はいずれ無責任に数千個のエージェントを作るだろう」だとすれば、私はそこには同意しがたい。それは一部のPoCや現場主導の実験、あるいはshadow AIの領域では起こりうる。しかし大企業の正式なAX運用モデルをそのように前提するのは行き過ぎだ。
そしてより危険なのは、その反作用として「だからスーパーエージェント一つで十分だ」と解釈されることだ。
大企業AXはスローガンでは成し得ない。「AIをたくさん使おう」でも足りない。「Claude Codeを全社で使おう」でも足りない。「トークンをたくさん使おう」も本質ではない。
本当の問いはこうあるべきだ。
- わが社の業務をAIが遂行できるようにするには、どんなデータ構造が必要か?
- どんな権限体系が必要か?
- どんなworkflow registryが必要か?
- どの業務を自動化し、どの業務に承認手続きを残すべきか?
- どの結果を正解とみなすか?
- 誰が運用し、誰が責任を負うのか?
この問いなしにスーパーエージェントばかりを語れば、AIはまた一つの流行語になる。
私はAXの核心が「エージェントを何個作るか」にあるとは考えていない。また「スーパーエージェントを一つ導入するか」にあるとも考えていない。
AXの核心は、企業の業務をAIが扱える形に再設計することだ。その過程で必要なのは、汎用エージェントも、業務別workflowも、共通ガバナンスも、評価体系も、すべて含まれる。どれか一つだけでは解決しない。
だから私はこう整理したい。
業務別エージェントの乱立は危険だ。しかしその代替が万能スーパーエージェント一つだという解釈も危険だ。
大企業AXの答えは「一つですべてやる」ではなく、**「共通プラットフォームの上で、統制可能な単位に分けて運用する」**のほうにより近い。
動画が投げかけた問題意識は重要だ。しかしそのメッセージが誤って解釈されれば、企業はまた別の極端へ走りかねない。かつては業務ごとにシステムを作った。今度はその逆に、すべての業務を一つのAIに任せようという声が出ている。
私が見るところ、どちらも慎重であるべきだ。
企業に必要なのは流行りのツール一つではなく、そのツールを安全に働かせる構造だ。そしてその構造を設計することこそが、これからのAXで最も重要な仕事になるだろう。
コメント
コメントを投稿