生成 AI エージェントのアーキテクチャについて考えてみた(2025年版)

生成 AI、そしてそれを利用した AI エージェントの利活用が非常に早い速度で成長しています。その中で、「じゃあどんな風にエージェントを作る、設計する、構成すれば良いのか?」という悩みや議論が2025年下半期で目につくように感じました。

個人的な認識としてですが、マイクロサービスやモノリスなどのソフトウェアアーキテクトに関する変遷を振り返ると、AIエージェントも同じ道のりを辿る予感がしています。例えば「どれくらいの粒度でツールやサブエージェントに分割するのか」、「ミニマムではモノリシックなエージェントでよいのではないか」のような議論は、アプリケーションの設計について議論する際にでてきた話と似通っているのではないでしょうか。

このあたりは、先日開催された POST Dev 2025でのt-wadaさんのセッションでも触れられていたと思います。セッションでは、生成 AI を利用した開発も、生成 AI を使う開発もこれまでの開発やアーキテクティングにおいて直面・解決してきた問題と向き合う必要があると紹介がありました。

このように考えると、AIエージェントの開発やその設計についても、馴染みのないものに向き合うというよりは、これまでのソフトウェア開発での理論や考え方をうまく見立てていくことで解決できるのではないかと思います。

エージェントはモノリスから始めるべき?

このように考えると、AI エージェントについてもまずはモノリス的な考えや設計からはじめるのがよいように感じます。いきなりマイクロサービスで複雑なものを作るのではなく、Ruby on Rails や Laravel、 Next.jsなどで素早く作って市場に投入するという考え方に近い進め方になるのではないでしょうか。マイクロサービスの文脈でも、Lambdalithという「1つのLambdaに機能を全部まとめるところから始めよう」という運動・考え方が広まったのはとても印象的でした。

初期からマイクロサービスで複雑なものを作って、保守で大変な思いをしたことがあるのですが、それと同様のことがマルチエージェントシステムでも今後起きるのではないかという漠然ととした懸念を少し感じています。 過度な最適化を避けて、必要になるまではまず1エージェントで作る。その上で必要になったらエージェントを分割していくというトライアンドエラー・アジャイル的な進め方を目指すことになるように思います。

エージェントとツール

AI エージェントシステムのアーキテクチャについてもう1つ考えないといけないのが、ツール機能です。エージェントに持たせる機能(Tool)をどれくらいの粒度にするのか問題も、この辺のアーキテクチャ知識が必要になります。 プリミティブなAPIラッパーでよいのか、それともトランザクションやワークフローベースで設計すべきなのか。 プリミティブすぎるとエージェントが迷子になって課題解決できる確率が下がるかもしれませんし、反対にガッチリワークフローを作ってしまうと、そもそも必要とされていなかった場合やワークフローの一部が変わった時などの変化に弱くなるかなと思います。

このあたりについては、はじめはプリミティブなAPIラッパー的ツールと、1つのエージェントからはじめるのがいいかもしれません。実現したいワークフローが達成できないとなった時点ではじめて、ツールかエージェントどちらかを分割していく。 アプリがモノリスからマイクロサービスへと移行していく流れに乗るようなイメージが近いかなと思います。

エージェントの境界や粒度をどこに設けるのか

モノリスからマルチエージェント・ツールに分割するスタイルを実現するには、「どこで分割するのか」を見極める必要があります。マイクロサービスアーキテクチャにおいても、サービスを小さくしすぎて不必要な依存や通信を多数発生させてしまうケースは少なくありません。マイクロサービスの設計をベースにエージェントを分割するとした場合、以下の3つが分割の基準になるはずです。

  • 目的: 何を達成するためのエージェント・ツールなのか?
  • トランザクション: エージェントやツールがどの「取引」を、どこまで処理するのか?
  • コレオグラフィ: AIエージェントにおけるSupervisorパターン

この辺りは、ソフトウェアアーキテクチャの基礎を参考に、自分の理解を書き足しました。本当にそのまま当てこんで良いのかという議論はありますが、目的や取引をベースに分割するというのは、そこまで筋の悪い考え方ではないでしょう。

半年後、答え合わせがしたい

と、ここまで最近読んだ本や聞いたセッションなどを元に考えを書き出してみました。基本的にはジェフ・ベゾス氏の言葉にもある「10年経っても変わらないもの」は何かを考えるのがよいと思っていて、ソフトウェアが長年積み上げたアーキテクチャに関するナレッジなどを思考のスタート地点にするのがよいと思っています。一方で技術革新やモデルの成長速度が上がっているため、ゲームのルール自体をひっくり返すような変化が発生する可能性も否定できません。

ここに今自分が考えていることを書き残し、半年後1年後どんな状況になっているかを振り返ってみたいと思います。

PAGE TOP