AI モデルからエージェントへ：システムを「エージェント的」たらしめるものは何か？
AI モデルやLLM（大規模言語モデル）は近年、言語の生成や理解における自然言語処理の分野で驚異的な進歩を遂げてきました。しかし、現在まさに起こっている真の変革は、エンドツーエンドのタスクを計画・実行する最新のAI エージェントの開発にあります。1997年のIBMのチェスエンジン「ディープ・ブルー」のような、かつての専用AI システムとの違いを考えてみましょう。これらは人間のチャンピオンを難なく打ち負かすことができましたが、特定の1つのタスクに特化していました。 これに対し、今日の確率論的かつツールを活用するAI エージェントは、「来週、1,000ドル以内でサンフランシスコへの旅行を予約する」といった、曖昧で多くのステップを要し、その過程で自律的な意思決定を必要とするエンドツーエンドのタスクを計画・実行することができます。
私は最近、「Claude Certified Architect, Foundations」の認定を取得しましたが、そのプロセスは、エージェント型AI の構造や複雑さ、そしてその可能性を理解する上で非常に貴重な経験となりました。その中核となる原則のいくつかを、ぜひ皆さんと共有したいと思っています。
まず、エージェント型AI アーキテクチャが、従来のAI とどのように異なるのかを定義することから始めましょう。エージェントの重要な特徴は、モデルや外部ツール、メモリを活用して、その基盤となっている大規模言語モデルの基本機能を拡張できる点にあります。 エージェントは、自律的に目標を計画し、複雑なワークフローを多段階のタスクに分解することを重視し、多くの場合、並列実行を可能にすることで機能します。後述するように、この最後の点はエージェント型アーキテクチャの最も魅力的な側面の一つです。つまり、専門的なスキルや目標を持つ異なるエージェントを活用することで、オーケストレーターはタスクを効果的に委任し、その結果を統合することができるのです。これは、単一のユーザーリクエストで複雑な問題を解決しようとするよりも、はるかに強力なアプローチです。
エージェントについて考えるもう一つの方法は、エージェントが処理できるクエリの種類を通じてです。LLMは単一のクエリを受け取り、多くの場合、印象的で、一見思慮深い結果を生成することができます。 一方、エージェント型システムは、複雑なタスクを解決するという課題を受け取ることができ、その解決には「知覚 → 推論 → 行動 → 観察 → 記憶の更新 →目標が達成されるまで繰り返し 」という反復ループが必要となります。さらに、エージェントはLLM内に閉じ込められることなく、外部システムと連携して知識を拡張し、行動を起こします。ユーザーの好みに応じて、多くのエージェントは最小限の人的入力で動作することが可能です。
ビジネスの観点から見ると、近年、組織がチャット形式のコパイロットから自律的なワークフローへの移行を図ったことで、エージェント型AI システムが企業における議論の主流となりました。エージェントのスキルが企業規模で社内データにアクセスできるようになるにつれ、タスクの自動化や複雑化したタスクへの対応能力が高まることで、企業内のさまざまな分野においてその活用範囲が大幅に拡大する可能性があります。
AI のコア・エージェント的アーキテクチャ構成要素
ほとんどのエージェント型AI アーキテクチャは、4つの中核的な機能に分解することができますが、解決すべき問題の具体的な性質に応じて、各タイプは1つのエージェントで構成される場合もあれば、複数のエージェントで構成される場合もあります。
- オーケストレーション層 は、タスク全体の管理と、コンポーネントをサブエージェントに委譲する役割を担う
- 認識 これらの課題は、課題の内容や意図を理解し、関連情報を見つけるために、多くの場合重要なデータ源となる情報を処理することに重点が置かれている
- 推論 推論課題は、課題の理解と、推論を行い、理想的な行動方針を決定するための素材を必要とする
- アクション指向のタスク 利用可能な機能を公開している外部サービス（多くの場合、MCP（Model Context Protocol）サーバーを介して）に接続し、外部でのアクションを可能にします。
以下のセクションでは、これらの構成要素をそれぞれ詳しく検討し、エージェント型AI システムがどのように構築されているか、また、エージェント型システムを成功させ、効率的に運用するために必要な数多くの独自の設計上の側面について理解を深めていきます。本ブログでは、エージェント型システムを接続するために使用されている無数の技術標準やインターフェース、あるいは多くの分散システムの複雑な環境について網羅することを目的とはしていません。むしろ、現在採用されている重要なトレードオフや典型的な設計アプローチについて、全体的な概要を紹介することを目的としています。
知覚：エージェンティック・システムが世界をどのように取り込み、理解するか
知覚とは、エージェントAI が世界を理解するための「感覚」の層である。目の前のタスクの文脈を理解するために、エージェントは、以下に示すような幅広い種類のデータを読み取り、理解する必要がある：
- チャットでの入力、電子メール、サービスチケットなどの自然言語による入力
- 仕様書、ウェブページ、PDFなど、構造化されていないドキュメントの入力データ。 この種の情報密度が高く、構造化されていないコンテンツを、エージェントアーキテクチャが理解可能な入力データに変換することは、AI のエージェントが、人間が通常認識するような文脈を把握できるようにするため、特に重要です。
- SQLデータベース、センサーデータ、音声、動画、その他のオブジェクトストレージ形式など、構造化データの入力。
あらゆるデータ型において、根本的な課題は、それらを推論エンジンが効率的に処理できる構造化された表現に変換することにある。
オーケストレーションと推論：AI エージェントの認知エンジン
エージェントアーキテクチャの中心にあるのは 、 オーケストレーション層と推論層です。推論層は 、AI エージェントの「脳」に相当し、目標を選択し、それを計画に分解し、ツールを選定し、タスクが「完了」したタイミングを判断します。現在、LLM（GPT-4.1、Gemini Pro、Claude、LLaMAの各バリエーションなど）が代表的な推論エンジンとして機能しており、その中核を成しています。
単一のLLM呼び出しとエージェント型アプローチの違いは、全体を統括するオーケストレーターを含む推論層が、タスクをサブゴールに分解し、他のエージェントに委任するタイミング、人間に尋ねるタイミング、ツールを使用するタイミング、そして目標が達成されていない場合に終了するタイミングを決定する点にあります。 エージェント型システムでは、マルチエージェント構成における各サブエージェントには、全体的なミッションよりも焦点を絞った特定のミッションが割り当てられます。その特定のミッションには、エージェントが集中し、専門的なタスクをより効果的に達成できるよう支援するための、独自のカスタマイズされた役割、システムプロンプト、およびスキルが付随しています。
タスクに応じて、推論エージェントは、LLMの制約の範囲内で作業範囲が達成可能となるよう慎重に設計されています。プロンプトの最大文字数に達した場合、データが非構造化形式で提供された場合、あるいは単にタスクの規模が大きすぎる場合、幻覚現象や重要な事実の「忘却」が発生する可能性があります。 そのような場合、大規模なタスクを、より小さなサブセットを処理する直列または並列のエージェントに再構成する、マルチエージェント・ワークフローが必要になることがあります。マルチエージェント間の連携の複雑さは、サブタスクの管理にあり、これによりオーケストレーターの調整の複雑さが増大します。
記憶：主体性に基づくAI システムの短期および長期の文脈
エージェント型AI もまた、エージェントがタスクの進捗状況を追跡できるようにするために、必然的にパーシステントメモリに依存しています。これは特に、エージェントが時間をかけて、複数のステップ、セッション、あるいは連続するタスクにわたって動作する場合に当てはまります。その中でも最も単純な例が会話履歴であり、LLMは本質的にステートレスであるため、エージェントフレームワークはこれを推論層に提供しなければなりません。タスクの進行に伴い会話が溢れ出さないようにするためには、構造化されたコンテキスト管理が必要となります。
会話履歴そのものの短期記憶とは別に、永続ストレージの外にある長期記憶があります。これには 、ユーザープロファイル、過去のインシデント、プロジェクト履歴、あるいはベクトルデータベース、ナレッジグラフ、リレーショナル／SQLストアを通じて実装されたドメイン固有のドキュメントなどが含まれます。この長期記憶を活用することで、AI のエージェントはRAG（検索拡張生成）パイプラインを構築できるようになります。これにより、例えばカスタマーサポート担当者は、過去のチケットや購入履歴を取得して、応答をパーソナライズすることが可能になります。
行動：道具の使用、実行、および現実世界への影響
エージェント型AI の根幹をなすのは、AI を、ツール、API、データベース、あるいは他のエージェントを呼び出したり、コード、チケット、設定変更を生成したりすることで、意思決定と現実世界の変化と結びつける能力です。本稿執筆時点では、ツールは多くの場合、AI が利用可能なツールを公開し、入力および出力のための構造化されたスキーマを提供するMCPによって公開されています。
ツールの使用には重要な意味合いが伴います。現時点では、あまりにも多くのツールを割り当てたり、過度に複雑なスキーマを設定したりすると、混乱を招き、推論エンジンが誤ったツールを選択したり、コンテキストウィンドウに負荷をかけすぎたりするリスクがあります。エージェントを専門化されたタスクに分割し、各サブタスクに適切なツールを割り当てることは、成功率を高めるための戦略の一つです。
同様に重要なのは、エージェントが承認されたツールにのみアクセスできるよう十分なセキュリティを確保すること、そして不確実性が高い領域、リスクが高い領域、財務的影響が大きい領域などについては、人的な監督を行うことです。エラー処理は、ツールが正常に完了することを確実にするため、また、完了しなかった場合にエージェントが（管理された再試行などにより）状況を適切に処理できるようにするため、そしてツールへの呼び出しがビジネスロジックやセキュリティポリシーに準拠していることを保証するためのガードレールを提供するためにも重要です。
アーキテクチャの種類：シングルエージェント、マルチエージェント、およびハイブリッドシステム
エージェントシステムの複雑さは様々です。現在、単一エージェントシステムは特定のワークフローを処理でき、マルチエージェントシステムは複雑または大規模な問題に用いられ、ハイブリッド構成では、各レイヤーにわたって人間とAI のエージェントが組み合わされています。
- 単一エージェントアーキテクチャ： 独自の推論機能、メモリ、およびツールを備え、ループ内で実行される1つのAI エージェント。代表的な例としては、カスタマーサポートエージェント、ドキュメント作成用の社内アシスタント、およびレポート生成エージェントなどが挙げられる。
- マルチエージェントアーキテクチャ： これらは、メッセージを介して連携する複数の特化型エージェント（例：「研究者」、「計画者」、「実行者」、「審査者」）で構成される。マルチエージェントAIの設計パターンには、階層型（コーディネーター＋ワーカー）、分散型のピア・ツー・ピア・ネットワーク、およびタスクの文脈に応じて主導権が移り変わるハイブリッド型などがある。それぞれに独自の利点と複雑さが伴う。
不必要な複雑さを避けるため、まずは単一エージェントシステムから始め、特定の追加要件（例えば、専門化、並列化、検証の必要性など）に対応する場合にのみ、マルチエージェントシステムに移行するのがベストプラクティスである。
見通し
AgenticAI は、新機能の開発を加速させることができ、多くの業界や利用形態で広く導入されています。入力や出力アクションを問わず、エージェントがサービスにアクセスできるようにするMCPインターフェースを公開するサービスが増えるにつれ、エージェントの科学と機能は急速に進化しています。Sonatus はこの分野に多額の投資を行っており、生産前の テストや検証からアフターサービスに至るまでのユースケースをサポートする、複雑なマルチエージェントシステムを提供しています。 当社は、この新しいタイプのコンピューティングが持つ可能性、そしてそれがお客様にもたらす可能性に大きな期待を寄せています。
