エージェント型AIアーキテクチャ：よりスマートなAIシステムを構築するための実践ガイド

エージェント型AIアーキテクチャとは、複数の専門化されたAIエージェントを組織化し、各エージェントがより大きなタスクの異なる部分をそれぞれ処理することで、その総合的な成果が単独で動作するどの単一モデルよりも優れたパフォーマンスを発揮するように設計されたシステムです。

「基本的に、これらのLLMをエージェントと捉え、各エージェントがこのタスクの一部を担っていると考えてください」 と、InterSystemsの社長であるドン・ウッドロックは、自身の 『Code to Care』シリーズで説明しています。

単一のプロンプトに対して単一の出力を返す従来のAIとは異なり、エージェント型AIシステムは、計画を立て、ツールを活用し、記憶を保持し、複数のステップにわたって自律的な意思決定を行うことができます。

1つのモデルにすべてを任せるのではなく、専門的な役割ごとにインテリジェントエージェントを割り当てます。 1人が下書きする。 別の者が批判する。 3人目は校正を行う。 中には言語モデルですらないものもあり、検索エンジンやAPI、計算機といったツールもあります。 オーケストレーターは、それらすべてを共通の目標に向けて調整します。

何がこれを実用的なものにしたのでしょうか？ 大規模言語モデルは、信頼性の閾値を超えました。 以前のモデルは、自律的なサブタスクを任せることができませんでした。話題から外れたり、制約をでっち上げたりしていたからです。 現代のAIエージェントは、複雑な指示を十分に正確に実行できるため、大規模なシステム内でそれぞれに専門的な役割を割り当て、環境を認識し、すべての段階で人間の介入なしに行動を起こすことができます。

大規模言語モデルは、1トークンずつ出力を生成し、常に前方へのみ進みます。 1回のモデル呼び出しには、修正処理は組み込まれていません。

実際にマーケティング計画をどのように策定するか、考えてみてください。 まずは概要から始めるといいでしょう。 下書きを書いてください。 確認してください。 フィードバックをもらいます。 修正してください。 まずは試しにやってみて、それから最終版を作成するのはどうでしょうか。 複数のパス処理を行い、その都度、前回の結果を改良していきます。

LLMは、これらすべてを1回のフォワードパスで実行します。 アウトラインなし。 批判なし。 修正なし。 出力は、モデルが単語ごとに予測した内容そのものであり、一歩引いて再考する余地はありません。

エージェント型アーキテクチャは、このギャップを埋めます。 各エージェントが異なる段階を担当するように連鎖させることで、単一のモデルだけでは処理できない複雑なワークフローを、AIシステムが立案、評価、改良できるようになります。

思考連鎖プロンプティングに関する研究（ Wei et al., 2022; Kojima他、 2022年の)では、LLMに中間的な推論ステップを踏ませることで、複雑なタスクにおける精度が大幅に向上することが実証されました。 エージェント型アーキテクチャは、この原則を単一のプロンプト手法からシステム全体の設計へと拡張したものです。つまり、1つのモデルに「一旦停止して考える」よう求めるのではなく、本質的に段階的に動作するエージェントのチームを構築するのです。

まずは、ドンが「複合AI」と呼ぶ手法から始めましょう。つまり、単一のLLMに頼るのではなく、複数のLLMを組み合わせて活用するのです。 最も単純なバージョンでは、3つのモデルを順次使用します：

1. ドラフトエージェント：初期出力を生成する
2. レビューエージェント：そのドラフトを当初の要件に照らして評価する
3. 最終エージェント：講評に基づいて修正を行う

「これ、本当にうまくいくんだ。」 こうすれば、はるかに良い結果が得られます。 「実は、ChatGPTを使えば、自分で試してみることができますよ。」 - ドン・ウッドロック

重要な転換点：LLMへの各呼び出しを「AIそのもの」として捉えるのをやめること。 それぞれを、役割を持つ「エージェント」――つまり「起草者」「批評家」「仕上げ役」――として捉えてみてください。 3つすべてに同じモデルを使用してもよいですし、バラエティや視点を広げるために異なるモデルを組み合わせて使用することもできます。 この複合的な結果は、どの単一のコールよりも優れた成果を上げています。

エージェントという観点で考え始めると、次に気づくのは、すべてのエージェントが言語モデルである必要はないということです。

「こうしたエージェントの中には、Google検索を行ったり、APIを呼び出して予約を入れたり、計算用APIを使って計算を行ったりするようなツールも含まれるでしょう。」 - ドン・ウッドロック

ドンの例では、「データリクエストエージェント」が、マーケティング計画を強化するためにどのような統計データが必要かを特定します。 別のエージェントがウェブ検索を実行してそれらを見つけ出します。 検索エージェントはAPI呼び出しです。 しかし、システム内では、その役割は同じです。つまり、タスクを受け取り、それを実行し、結果を返すということです。

これこそが、エージェント型システムとプロンプトチェーンを区別する点です。 このアーキテクチャは、あらゆる種類の処理（例：言語モデル、検索エンジン、データベース、計算機、外部APIなど）に対応しており、それらがすべて単一の目標に向けて連携しています。

最後の飛躍：ワークフローをハードコーディングする必要はない。

固定の6段階のパイプラインを定義する代わりに、オーケストレーター・エージェントに対して、目標、利用可能なエージェントのセット、および一般的な指示を与えます。 それによって順序が決まります。 さらなる調査のために、再びこの件に戻ってくる可能性もあります。 必要のない手順を飛ばしてしまう可能性があります。 それは状況に応じて適応します。

オーケストレーターを探偵のような存在だと考えてみてください。 刑事はチェックリストに従うのではなく、目標（事件の解決）を追求し、一つひとつの証拠に基づいて次に何を調べるべきかを判断していきます。 見込み客の反応が薄くなったら、改めて連絡を取ります。 目撃者が新たな手掛かりを提示すれば、彼らはそれを追います。 オーケストレーターも同様の仕組みで動作します。つまり、まず目標を設定し、次にシーケンスを決定します。

これこそが、エージェント型アーキテクチャを従来の自動化と一線を画す点です。 このシステムは、あらかじめ決められた手順通りに動いていません。 それは目標を追求しているのです。

あらゆるエージェント系システムは、その複雑さにかかわらず、4つのコアモジュールと、それらを結びつけるオーケストレーション層を備えています。

知覚モジュールは、システムの感覚層として機能し、API、データベース、センサーからのフィード、あるいはユーザーインターフェースからリアルタイムのデータを収集し、そのデータを実用的な表現へと処理します。 ここでは、自然言語処理がテキスト入力を解析し、コンピュータビジョンが画像を解釈し、データコネクタがエンタープライズシステムから構造化されたレコードを取り出します。 認識層は、その下流にあるすべての処理の上限を決定します。 エージェントのパフォーマンスは、アクセスできるデータの質に左右されます。

医療分野では、 InterSystems HealthShareのような統合データプラットフォームを採用している組織が、 FHIR^®やHL7®といった標準規格を通じて複数のEHRベンダーの記録を集約することで、断片化されたサイロからデータを取得している組織に比べ、エージェントにはるかに充実したデータ基盤を提供しています。

認知モジュールは、エージェントの現在の目標を踏まえて、知覚層からの入力を解釈します。 ここで、機械学習モデル、思考連鎖ロジック、および計画アルゴリズムが動作します。

大規模言語モデルの推論能力により、熟考型エージェントの実用化が可能となりました。 彼らは選択肢を比較検討し、中間目標を設定し、作業の途中で計画を調整することができます。

しかし、推論こそが、物事がうまくいかなくなる原因でもあります。 データを誤って解釈したり、誤った部分目標を設定したりするモデルは、その誤りを下流へと連鎖させてしまいます。

メモリシステムは、エージェントに現在のプロンプトを超えた文脈を提供します。 短期記憶は、アクティブなセッションのコンテキストや中間結果を追跡します。 ドラフト担当者はこれまでにどのような成果を上げてきたのでしょうか？ これまでにどのようなデータが取得されていますか？

長期記憶には、過去の結果、ユーザーの好み、蓄積された知識が保存され、これによりシステムは時間の経過とともに改善されていきます。 過去のやり取りや環境の状態を記録として保持するエージェントは、長期的な推論を行うことができ、それによって今日のタスクを、過去のタスクから得た教訓と結びつけることができます。

エージェント間のコンテキスト管理は、マルチエージェント環境における最も困難な技術的課題の一つです。各エージェントの知識の範囲を適切に設定し、必要な情報を確実に把握しつつ、無関係な情報に圧倒されないようにする必要があります。

アクションモジュールは、テキストの生成、APIの呼び出し、データベースレコードの更新、あるいは次のエージェントへの引き継ぎといった処理を実行します。 ドンの枠組みでは、「草案」「批評」「最終版」の各エージェントが、同じ目標を達成するためにそれぞれ異なる行動をとります。

アクションは、予約のスケジュール設定、チケットの発行、CRMレコードの更新、分析パイプラインへのデータ送信など、外部ソフトウェアシステムにおける下流のプロセスをトリガーすることもできます。 アクション層は、エージェント型AIが現実世界とつながる場所です。

オーケストレーション層は、他のすべてのモジュール間のデータおよび制御の流れを調整し、次にどのエージェントを実行するか、またそのエージェントがどのような情報を受け取るかを決定します。

その下にはフィードバックループが存在します。これは、システムが自身の進捗状況を評価し、論理的な誤りを特定し、環境からのフィードバックに基づいてリアルタイムで戦略を調整することを可能にする仕組みです。 エージェントシステムは、強化学習のループを通じて、データをより多く取り込み、反復ごとにエージェントの行動を洗練させていくことで、時間の経過とともに改善されていきます。

エージェントシステムは、個々のエージェントがどのように設計されているか、および複数のエージェントがどのようにシステムとして組織化されているかという、2つのレベルで分析することができます。

個々のエージェントが情報を処理し、意思決定を行う方法は、そのエージェントが対応できる範囲を決定づけます：

パターン	仕組み	おすすめ
反応性	記憶や予測に頼ることなく、即座の刺激に反応します。 モデルベースの反射型エージェントは、知覚情報を直接行動にマッピングします。	シンプルで迅速なタスク：アラートのルーティング、しきい値に基づくトリガー
審議型	理由や計画を立て、世界に関する内部モデルを用いて判断を下します。 動作は遅いですが、はるかに高性能です。	多段階の計画が必要な複雑な問題：調査、分析
認知	人間のような思考を模倣する。これには、推論、学習、自律的な意思決定に加え、短期記憶および長期記憶が含まれます。	適応が必要なタスク：パーソナライズされたレコメンデーション、反復的なコンテンツ作成

現代のAIエージェントの多くは、熟考型あるいは認知型です。 大規模言語モデルの推論能力のおかげで、こうしたパターンは5年前には実現できなかったような形で実用化されるようになりました。

エージェントの組織体制によって、その連携の仕方や意思決定を行う主体が決まります：

パターン	構造	おすすめ	トレードオフ
シングルエージェント	ツールとシステムのプロンプトを活用して、1人のエージェントが集中的な意思決定を行います。 シングルエージェントシステムは、タスク全体を単独で処理します。	明確に定義されたタスク：情報検索のサポート、文書の要約、コードレビュー	構築やデバッグが簡単 1人のエージェントの能力による制約
パイプライン（垂直）	リーダーエージェントはサブタスクを監督し、複数の専門エージェントを順番に指揮します。 階層型AIエージェントは、結果を上位の階層へ報告します。	一連のワークフロー：コンテンツ作成、データ処理、レポート作成	予測可能かつ検証可能 タスクの途中で要件が変更された場合、柔軟に対応できません。
ピア（水平）	分散型システムでは、エージェントは対等な立場で活動しており、唯一のリーダーは存在しません。 エージェントは独立して活動し、交渉の結果を決定する	創造的な課題：ブレインストーミング、レッドチーム／ブルーチームによる評価、学際的な分析	多様な視点 一つの答えに収束するのが難しくなる
ハイブリッド	体系的なリーダーシップと協調的な柔軟性を兼ね備えており、これにより、体系的な要求と創造的な要求の間でリーダーシップの役割のバランスが取れています。 タスクの段階に応じたリーダーシップの切り替え	体系的な実行と自由度の高い探求を組み合わせた複雑なプロジェクト	最も有能 構築とデバッグが最も複雑

ドンの「草案・批評・修正」の例は、ワークフローがあらかじめ決められた順序に従う一連のプロセスです。 彼のオーケストレーターの例は、各ステップで生成される結果に基づいてシステムが適応するハイブリッド型です。

理想的なエージェントアーキテクチャは、アプリケーションの要件によって異なります。 明確に定義されたタスクについては、まずはシングルエージェントアーキテクチャから始めましょう。 タスクの複雑さから、専門化、並列実行、あるいは領域間の連携などが求められる場合にのみ、マルチエージェントアーキテクチャに移行すべきです。

マルチエージェントアーキテクチャにおいて、課題となるのは個々のエージェントを連携させることです。

マルチエージェント間の連携を実現するには、通信、調整、リソース共有という3つの課題を解決する必要があります。

エージェントは、構造化されたメッセージのやり取りを通じてコミュニケーションを行います。 あるエージェントの出力が、別のエージェントの入力となります。 通信プロトコルは、これらのメッセージの形式、ルーティング、および優先順位を定義します。

垂直型システムでは、リーダーエージェントの指揮下にあるエージェントは、ハブ・アンド・スポーク型の構造に従います。 水平型システムでは、エージェント同士がピアツーピアで通信を行います。

モデルコンテキストプロトコル（MCP）などの標準規格は、エージェントがツールやデータソースに接続する方法を標準化するために考案され、エージェント開発チームの統合作業の負担を軽減しています。

シングルエージェントアーキテクチャと比較して、マルチエージェントシステムの主な特徴の一つは並列処理です。 異なるエージェントが、それぞれ別のサブタスクを同時に処理することができます（例えば、1つのエージェントが調査を行い、別のエージェントが草案を作成し、さらに別のエージェントがデータベースを検索するなど）。

これにより、AIエージェントは、単一のモデルが順次処理を行う場合よりも、複雑な問題をより迅速に解決できるようになります。 しかし、並列実行には同期に関する課題が伴います。エージェントは、矛盾や重複が生じることなく、結果を整合性を持って統合する必要があります。

マルチエージェントアーキテクチャにおける主な課題は、調整です。 堅牢な同期メカニズムがなければ、エージェントはリソースを非効率的に共有したり、作業の重複が生じたり、矛盾した出力が生成されたりすることになります。

これは、ワークフローの途中でタスクの要件が変化するような動的な環境において、特に深刻な問題となります。 システムレベルのパフォーマンス監視（つまり、どのエージェントがボトルネックになっているか、どのエージェントがアイドル状態か、どこでエラーが蓄積しているかを追跡すること）は、システムの規模拡大に伴いAIのパフォーマンスを維持するために不可欠です。

マルチエージェントシステムは、コンプライアンス審査、市場調査、ワークフローの最適化、あるいは分析、創造、運用に関する専門知識を単一の成果物に集約する必要がある部門横断的なプロジェクトなど、多様なスキルセットにわたる連携が求められる分野に非常に適しています。

エージェント型AIが常に最適な選択肢とは限りません。 文書の要約、サポートチケットの分類、テキストの翻訳などは、LLMを1回呼び出すだけで問題なく処理できます。 これらのタスクに担当者を割り当てても、有意義な改善にはつながらず、かえって負担が増えるだけです。

エージェント型アーキテクチャは、次のような場合にその複雑さを発揮する：

• タスクには、調査、分析、統合という複数の段階を順を追って行う必要があります。
• 外部データは不可欠です。システムは、ワークフローの途中でデータベース、API、またはリアルタイムのデータソースからデータを取得する必要があります。
• 自己修正は成果を向上させる：批判ループは成果物の品質を測定可能なレベルで高める
• システム間の連携が必要である。エージェントは 、さまざまなプラットフォームからデータを取得し、またそれらへデータを送信しなければなりません。

タスクの入力と出力がそれぞれ1つずつで、中間的な決定がない場合、適切に設計されたプロンプトは、エージェント型システムよりもはるかに低いコストと遅延で、それ以上の性能を発揮します。

エージェント型AIシステムは、自律的な意思決定や複雑な多段階のワークフロー管理を必要とする、自由度の高い問題の解決に優れています。 企業環境において、これは測定可能な効果として現れます。

コンプライアンスチェック、データ照合、顧客オンボーディングといった運用ワークフローのタスク自動化をエージェント型システムが担当することで、各組織はビジネスプロセスの30％から50％の高速化を実現していると報告しています。

実際には、これは特定の業務機能に合わせてカスタマイズされたエージェントを意味します。 ドンが説明しているように、「組織のポリシーやブランド基準に照らし合わせてチェックを行うモデル」を構築することで、コンプライアンス審査やブランドガバナンスを、手作業によるボトルネックから、エージェント主導のワークフローにおける自動化されたステップへと変えることができます。

エージェント型AIは、複数のソースにわたる非構造化データの分析、判断の決定、例外への適応など、従来のAIモデルでは処理できない知識集約的なタスクを自動化できます。

これらのシステムは24時間体制で稼働し、人員を増やすことなく、データや問い合わせの急激な増加にも対応できる拡張性を備えています。 反復的な知的作業を外部に委託することで、従業員は付加価値の高い戦略立案や創造的なイノベーションに注力できるようになります。

医療分野において、能動型AIは業務効率と臨床的意思決定の両方を向上させます。 医療画像を分析し、患者の病歴と照合し、新たな症例から学習するエージェントは、時間の経過とともに診断精度を向上させることができます。

エージェント型AIを既存の企業システムに統合することで、あらゆる業界において競争優位性を強化することができます。

InterSystems IRIS Data Platformのようなプラットフォームは、医療分野をはじめとするさまざまな分野でこれらのエージェントに必要な相互運用性の基盤を提供し、ベンダーを問わず FHIR や HL7 などの標準規格を通じてシステムを連携させます。

サプライチェーンの運用においても、同様のメリットが得られます。 需要の変動を感知し、フルフィルメントをリアルタイムで調整するエージェントは、昨日の倉庫データではなく、リアルタイムの取引データに対して分析を実行する必要があります。 InterSystems IRIS は、 トランスリタリカル処理を通じてこれをネイティブにサポートしており、ETL による遅延なしに、同一のデータ上でトランザクション処理と分析処理の両方のワークロードを実行できます。

エージェント型AIシステムを導入するには、特定のAI機能やビジネス目標に沿ったエージェントの種類、ツール、およびエージェント型AIフレームワークを慎重に選択する必要があります。 エコシステムは急速に成熟しました。

のエージェントフレームワークは、エージェントのロジック、連携、およびツールの使用を処理します：

フレームワーク	以下によって管理：	Approach
LangGraph	LangChain	グラフベースのワークフロー。 エージェントをノード、遷移をエッジとする。 柔軟性は最大だが、習得には時間がかかる。
CrewAI	オープンソース（AIファンド）	役割に基づく「クルー」。 エージェントに役割、目標、そして背景ストーリーを割り当てます。 マルチエージェント・プロトタイプ作成への最短ルート。
Microsoft Agent Framework	マイクロソフト	統合フレームワーク（AutoGenとSemantic Kernelの統合）。 Deep Azureとの緊密な連携。 企業向け。
Google ADK	Google	組み込みツール、Model Context Protocol のサポート、およびビジュアルデバッグ UI を備えたコードファースト・ツールキット。 Vertex AIと連携します。

これらのフレームワークは、エージェントのロジックと連携を処理します。 しかし、エージェントには、データベース、相互運用性エンジン、リアルタイム分析システムなどに分散している企業データへのアクセスも必要です。 InterSystems IRISのようなプラットフォームは、エージェントがクエリを実行し、それに基づいて動作するためのデータインフラストラクチャ層を提供し、開発者が既存のソフトウェアシステムにエージェント型 AI 機能を組み込むことを可能にします。

保守性と拡張性に優れたシステムを構築するには、実用的なフレームワークの選択が不可欠です。 適切な選択は、チームの専門知識、クラウド環境、そして既製のエージェントパターンが必要か、それとも最大限のカスタマイズが必要かによって異なります。

まずはここから始めましょう：1つのフレームワークを選び、Leap 1の「草案作成・批評・修正」というパターンに基づいて構築してください。 3つのエージェントすべてに、単一のLLMを使用します。 動作するようにしてください。 次に、展開してください。

エージェント型システムを構築すると、単一モデルアプローチでは回避できるトレードオフが生じます。 組織は、実行を成功させるために、極めて複雑な技術的課題に対処する必要があります。

• レイテンシーが累積する。 各エージェントが1回の往復を追加します。 3つのエージェントによるパイプラインでは、単一の呼び出しに比べてレイテンシがおよそ3倍になります。 エージェントを追加する前に、許容可能な応答時間を確保できるよう設計してください。
• エラーは連鎖する。 草案エージェントからの欠陥のある出力が批評エージェントに送られても、批評エージェントではそれを検出できない場合があります。 検証チェックを、最終段階だけでなく、各引き継ぎの段階でも組み込むようにしてください。
• コストは規模に応じて変動します。 エージェントが増えれば、API呼び出し数も増え、コストが高くなります。 タスクごとのコストを測定し、品質の向上度と比較します。 場合によっては、よく練られた単一のプロンプトの方がコストが安く、十分な効果を発揮することもあります。
• デバッグはもっと難しい。 5つのエージェントからなるシステムで問題が発生した場合、どのエージェントに不具合があったのかを特定する必要があります。 各エージェントの境界ごとに構造化ロギングを行うことは不可欠です。
• リターンの逓減はあっという間に訪れる。 4人目、5人目、6人目のエージェントを追加しても、最初の3人を強化するほど大きな効果はほとんど得られません。

スケーラビリティは、エージェント型AIアーキテクチャにおける最大の課題の一つであり、特に単一エージェントシステムからマルチエージェントシステムへ移行する際には、その課題が顕著になります。 エージェント型AIシステムでは、より大きなワークロードを処理し、エージェント間の円滑な通信を確保するために、堅牢なインフラストラクチャが必要となります。 3つのエージェントからなるプロトタイプでうまく機能していたものが、20のエージェントになると機能しなくなる可能性があります。 メッセージキューが溢れ、コンテキストウィンドウが満杯になり、調整にかかるオーバーヘッドがボトルネックとなります。

エージェント型AIのテストには、堅牢性と信頼性を確保するために、合成データセットと実世界データセットの両方が必要となります。 合成データを使用することで、制御された環境下でエッジケースや故障モードに対するストレステストを行うことができます。 実世界データからは、システムが実際に直面することになる、複雑で予測不可能な入力情報が明らかになります。 まず各エージェントを個別にテストし、その後、システム全体をエンドツーエンドでテストしてください。 エージェント間の相互作用により、ユニットテストでは見落とされがちな問題点が明らかになります。

主体性を持つAIアーキテクチャの設計プロセスは、反復的なものです。 ワークロードの特性が変化するにつれて、アーキテクチャを定期的に見直すべきです。 当初は単純なパイプラインだったものでも、タスクの複雑さが増すにつれて、動的なオーケストレーションが必要になる場合があります。

ドンが述べているように、その目標は、「コードやアプリケーション内でフロー全体を事前に考え抜くのではなく、1つまたは複数のエージェントが次の処理を指示できるようなワークフローを構築すること」です。 まずは、機能する最もシンプルなアーキテクチャから始めましょう。 進化は経験に導かれるべき。

エージェント型AIアーキテクチャは、AIを単一のプロンプトツールから、専門化されたエージェントからなる協調的なチームへと変革します。

ドンが指摘するように、その核心となる洞察は単純明快です。まずLLMをエージェントとして捉え、すべてのエージェントがLLMである必要はないことを認識し、各ステップをハードコーディングするのではなく、システム自身にワークフローを決定させるのです。 まずは「下書き→批評→推敲」というサイクルを確立しましょう。 ツールを追加します。 オーケストレーションを追加します。 システムの複雑さは、ニーズに先んじるのではなく、ニーズに合わせて拡大させていきましょう。