なぜマイクロサービスはマルチエージェントシステムへと進化したのか――そして、なぜRuntime OSが必要なのか？

Knowledge Base Archive この記事は Chinoba Knowledge Base の技術アーカイブです。 Chinoba.orgを見る →

🎥 YouTubeでも公開しています

Agent Frameworkを比較しても意味がない理由｜OpenAI・Claude・AutoGen・LangGraphの本当の役割

Agent Frameworkを比較しても意味がない理由｜OpenAI・Claude・AutoGen・LangGraphの本当の役割

books: 実践 Multi-Agent Systems: OpenAI Agents SDK・Claude Agent SDK・AutoGen・LangGraphを統合するChinoba Decision Runtime実装ガイド

近年、**マルチエージェントシステム（Multi-Agent Systems）**は、AI業界で最も注目されているテーマの一つとなっています。

OpenAI Agents SDK、Claude Agent SDK、AutoGen、LangGraphをはじめとする多くのフレームワークが登場したことで、複数のAIシステムが協調しながら複雑な業務タスクを実行するという考え方が、現実のものになりつつあります。

しかし、この流れは突然生まれたものではありません。

現在のマルチエージェントシステムの多くは、過去20年間にソフトウェア業界で洗練されてきたマイクロサービスアーキテクチャの考え方を受け継いでいます。

一方で、マルチエージェントシステムは、従来のマイクロサービスでは想定されていなかった、まったく新しい課題も生み出しています。

本記事では、次の4つの問いについて考えていきます。

  • マイクロサービスは何を解決したのか
  • マルチエージェントシステムは何を解決したのか
  • マルチエージェントシステムには、まだどのような課題が残っているのか
  • なぜRuntime OSが必要なのか

第1世代：モノリシックシステム

従来の企業システムの多くは、モノリシックなアプリケーションとして構築されていました。

ERP System
├── 顧客管理
├── 在庫管理
├── 会計
├── 調達
├── 営業
└── 請求

すべての機能が、一つの巨大なアプリケーションの中に実装されていました。

システムが大規模化するにつれて、いくつかの問題が生じました。

  • 一つのコンポーネントの変更が、アプリケーション全体に影響する
  • デプロイが次第に困難になる
  • 障害がシステムの広い範囲に影響する
  • 開発チーム間の依存関係が増大する

第2世代：マイクロサービスの登場

これらの問題を解決するため、ソフトウェア業界では**SOA（Service-Oriented Architecture：サービス指向アーキテクチャ）**が登場し、その後、マイクロサービスへと発展していきました。

注文サービス
↓
在庫サービス
↓
決済サービス
↓
配送サービス

一つの巨大なアプリケーションを構築するのではなく、機能を小さく独立したサービスへ分割し、それぞれを個別に開発、デプロイ、スケーリングできるようになりました。

マイクロサービスが解決した5つの問題

課題 マイクロサービスによる解決
巨大なコードベース 機能分割
デプロイの困難さ 独立したリリース
スケーラビリティの限界 サービス単位のスケーリング
障害の連鎖 障害の分離
チーム間の依存 サービスごとのオーナーシップ

マイクロサービスは、ソフトウェア開発のあり方を根本的に変えました。

しかし、重要な限界が一つ残っていました。

マイクロサービスは意思決定できない

簡単な顧客割引ポリシーを考えてみましょう。

if customer_type == "VIP":
    discount = 20
else:
    discount = 10

これはルールベースの処理です。

では、次のような要素を考慮しなければならない場合はどうでしょうか。

  • 顧客の過去の購買履歴はどうなっているか
  • 競合他社は現在どのような条件を提示しているか
  • 現在の在庫状況はどうなっているか
  • 契約上の制約は存在するか
  • 法的なリスクはないか

従来のマイクロサービスは、これらの要素を総合的に考慮して、文脈に応じた判断を行うことはできません。

マイクロサービスは、あらかじめ定義されたルールを実行します。

自ら推論するわけではありません。

マルチエージェントシステムはマイクロサービスから直接進化したわけではない

ここで、よくある誤解があります。

マルチエージェントシステムは、マイクロサービスから直接進化したものではありません。

その起源は、分散人工知能（Distributed Artificial Intelligence）研究にあります。

この分野では、主に次のようなテーマが研究されてきました。

  • 自律エージェント
  • 協調
  • 交渉
  • 合意形成
  • 分散問題解決

つまり、

マイクロサービスは、ソフトウェア工学から進化したものです。

一方、

マルチエージェントシステムは、人工知能研究から進化したものです。

両者は、異なる進化の道筋をたどってきました。

LLMが2つの世界をつないだ

大規模言語モデル、LLMの登場によって、この状況は大きく変わりました。

従来のシステムは、比較的単純な実行モデルに従っていました。

入力
↓
ルール
↓
実行

これに対して、LLMベースのエージェントは、まったく異なるワークフローを導入しました。

観察
↓
推論
↓
計画
↓
ツール選択
↓
実行

ソフトウェアコンポーネントが、単に事前定義された命令を実行するだけではなく、

「何をすべきか」を推論できるようになったのです。

Agentは既存のマイクロサービスをToolとして使い始めた

現代の企業システムでは、既存のインフラをAIによって全面的に置き換えることはほとんどありません。

その代わりに、AI Agentが既存の企業サービスと連携します。

Sales Agent
↓
CRM API

Pricing Agent
↓
Pricing Service API

Inventory Agent
↓
Inventory Service API

Legal Agent
↓
Contract Service API

マイクロサービスがなくなったわけではありません。

その上に、新しい知能レイヤーが追加されたのです。

現在の企業アーキテクチャは、次第に次のような3層モデルへと近づいています。

AI Layer

Sales Agent
Legal Agent
Pricing Agent
Risk Agent

↑↓

Enterprise APIs

CRM
ERP
Inventory
Billing
SCM

↑↓

Infrastructure

Kubernetes
Docker
Service Mesh
Databases

マルチエージェントシステムが解決したこと

1. 専門知識の分散

Sales Agent

Legal Agent

Risk Agent

Finance Agent

異なるAgentが、それぞれ異なる専門領域を担当できます。

2. 動的な意思決定

あらかじめ定義されたルールに従うだけではなく、Agentは変化する状況に応じて推論できます。

3. 自律的なタスク実行

Agentは自律的に、

  • 調査
  • 分析
  • 計画
  • 実行

を行うことができます。

これによって、企業ソフトウェアが実現できることの範囲は大幅に広がりました。

しかし、マルチエージェントシステムは新しい問題を生み出した

最終的な意思決定をするのは誰か？

Sales Agent

「15%の値引きを推奨します」

最終的に、この提案を承認するのは誰でしょうか。

実行を許可するのは誰か？

AI Agent
↓
契約を締結する

AI Agent
↓
支払いを実行する

AI Agent
↓
メールを送信する

AI Agentには、どこまでの権限を与えるべきでしょうか。

誰が責任を負うのか？

Sales Agent
↓
Pricing Agent
↓
Legal Agent
↓
Execution Agent

問題が発生した場合、誰が責任を負うのでしょうか。

誰が監査するのか？

後から、次のことを確認できるでしょうか。

  • なぜその判断が行われたのか
  • どのデータが使われたのか
  • 誰が承認したのか
  • なぜ実行が許可されたのか

現在のAgent Frameworkは、Agentを動かすための実行環境を提供しています。

しかし、意思決定そのもののガバナンスについては、まだ十分に解決されていません。

だからRuntime OSが必要になる

Runtime OSの目的は、単にAgentを管理することではありません。

その本質的な目的は、意思決定を統制することです。

Signal
↓
Evaluation
↓
Decision
↓
Human Gate
↓
Command Permit
↓
Execution
↓
Decision Trace

Runtime OSは何を提供するのか？

課題 Runtime OSによる解決
誰が意思決定するのか？ Decision Authority
誰が意思決定を承認するのか？ Human Gate
誰が実行を許可するのか？ Command Permit
誰が責任を負うのか？ Delegation Contract
意思決定をどのように監査するのか？ Decision Trace Ledger
制御不能な動作をどう防ぐのか？ Fail-Closed

結論

私は、企業システムの進化を次のように整理しています。

Monolith
↓
Microservices
（分散処理）

↓

Multi-Agent Systems
（分散知能）

↓

Runtime OS
（統制された意思決定）

つまり、

マイクロサービスは、計算・処理を分散した。

マルチエージェントシステムは、知能を分散した。

Runtime OSは、分散された意思決定を統制する。

という進化です。

今後、企業AIにおいて最も重要な問いは、

「どのAgent Frameworkを選ぶべきか？」

ではなくなっていくでしょう。

本当に重要な問いは、

「誰が、何に対して責任を持つのか？」

です。

これは、もはや単なるAIの問題ではありません。

組織設計の問題なのです。

参考文献

  • Moving From Monolithic To Microservices Architecture for Multi-Agent Systems（arXiv）
  • Multi-Agent AI Systems: Evolving From Microservices to Modular Intelligence（TEKsystems）
  • Multi-Agent Reference Architecture（Microsoft）
  • The Agent Operating System (AOS): A Reference Operating Architecture for Distributed Agentic Systems（arXiv）

Related Research

この記事は Chinoba Knowledge Base の一部です。

Chinoba Research
Chinoba-lab Open Source
Books and Library

コメント

タイトルとURLをコピーしました