万能AIの単体運用では限界？ マルチエージェントの可能性と必要なインフラ：Confluentで実現する「次のAIエージェント活用」

AIエージェントの活用は複雑な業務フローで壁に突き当たる。人間同様スーパーマン一人で全てをこなすのは難しい。精度低下や高コスト化、ガバナンスの欠如。これらのリスクを回避し、AIを真の戦力に変えるにはどうすればいいのか。

[PR／＠IT]

組織的に機能してビジネスを支援する「マルチAIエージェント」

　AI技術の利用に取り組む企業が増えているが、その大半は汎用（はんよう）LLMやチャットツールにとどまっている。先進的な企業は、さまざまなタスクを自律的に実行できる「AIエージェント」の導入に注目し、推進している。企業向けのAIエージェントは、与えられたタスクの完遂に必要なことや、どの情報を用いるべきかを考えて、次のアクションを決定する。業務のプロセスとして組み込まれて稼働する点が汎用LLMとは大きく異なる。

　そのようなAIエージェントは、どのような思想で設計すべきだろうか。重要なキーワードは「マルチAIエージェント」――1つのAIモデルに全ての業務を担わせるのではなく、個別の業務に精通した複数のAIエージェントを連携させることだ。

　「1つのLLMに与えるプロンプトやツールの数が増えるほど、ハルシネーションや正しくないアウトプットのリスクが高まります。ビジネスドメインごとにAIエージェントを分割することで、精度と品質を保証できるようになります」と、Confluent Japan ソリューションアーキテクトの鈴木拓人氏は述べる。同社のData Streaming PlatformはAIを活用しやすくするためのインフラだ。

Confluent Japan ソリューションアーキテクトの鈴木拓人氏

　現実的なAIエージェントの構築は、人間の組織と照らし合わせると考えやすい。何でもこなす万能な社員がいたとしても、全ての業務を任せたら誤りや抜け漏れが生じやすくなる。トラブル時に、なぜそのような結果になったのか、作業内容を追うことも困難だ。だからこそ、企業は営業、経理、法務など専門の担当者が役割を分担して連携している。AIエージェントも同様で、適切な役割分担と連携を設計しなければ、複雑な業務を自動化することは難しい。そのため、マルチAIエージェントの仕組みが必須と言える。

　マルチ化の際により重要となるのがデータ基盤だ。各分野に精通したAIエージェントも在庫情報、顧客記録、取引履歴などの自社固有のデータがなければ社員のように働けない。単にデータがそこにあるというだけでも不十分だ。人間の組織と同じように、AIエージェントが適切なタイミングで適切なデータへアクセスでき、複数のエージェントが適宜データを共有したり、結果を互いにフィードバックしたりする必要がある。つまり、データをAIエージェント同士が共有でき、適切に管理して素早く柔軟に流通するためのインフラが欠かせない。

従来型の実装で直面する「6つの課題」

　こうした新しい思考を持たず、直感的に単一のAIエージェントだけを見て構築しようとして失敗する例は少なくない。思い浮かぶのは、従来のWebアプリケーションのような設計だ。つまり、単一のエージェントをアプリケーションとして実装し、都度必要な情報をデータベースやAPIで取得する方法だ。この構造は理解しやすいものの、AI特有の課題を解決できない。

　第1の課題は「信頼性」だ。AIエージェントに障害が発生した場合、全てのワークフローが停止する上、どこから再開すればよいかが分かりにくい。過去のコンテキストはメモリに短期保持するか、遅延の大きいデータベースに格納するしかない。例外処理にも対応しにくい。

　第2は「拡張性」だ。リクエスト数やスループットの予測は難しく、スケールアップは困難だ。スケールアウトしようとしても、AIエージェント間の接続と運用は複雑になる。プロンプトやツールが増大すると、品質が劣化する可能性が高まる。単一エージェントのモノリス構造は新機能の追加にリスクを伴い、開発速度を低下させる。

　第3は「レイテンシ」だ。単一エージェントの場合、LLMに1つの応答を返すまでにデータベースの読み書きが何度も発生するため、遅延の原因となる。後述する監査・監視やコスト管理のためのデータ保管、データベース書き込みもボトルネックになりやすい。

　第4と第5の課題は、「監視・監査」と「コスト管理」だ。

　「AIがいつ、なぜその判断を下したかを追跡できなければ、精度の改善もROI（費用対効果）の評価もできません。LLMのトークンコストを抑制したくとも、どこで呼び出しが発生しているかを把握する仕組みが必要で、これを後から組み込むのは困難です」と鈴木氏は説明する。

　Webアプリケーションであれば、ログを確認すれば分かることだが、現在のAIエージェントは判断プロセスがブラックボックスになりがちだ。観測のための機能は、AIエージェントの設計段階から検討、実装しておくべきだ。

　第6は、「ビジネスロジックとインフラのカップリング」だ。モノリス構造のAIエージェントは、インフラとビジネスロジックを分離できない。そのため、AIエージェントの開発者はメッセージの接続方法やフロー制御も意識しなければならず、AIエージェントの改善よりもインフラ対応に時間を取られてしまうことがある。これは、インフラ、開発、運用の各チームが同じコードベースで作業するため、トラブルの責任範囲があいまいになりがちなことにつながる。

　こうした課題を解決するために有効なのが、オープンソースソフトウェア（OSS）の分散メッセージングプラットフォーム「Apache Kafka」を持つConfluentだ。データをリアルタイムで流通させる仕組みだ。

新しいAIの仕組みを実現するApache Kafkaとトピック技術

　Apache Kafkaの中核となる概念が「トピック」だ。トピックは、発生したイベントを種別ごとに蓄積する名前付きのログ領域で、在庫の更新情報、ユーザーのアクション履歴、センサーの計測値など、ワークフローで発生したメッセージを記録している。メッセージは追記のみで、過去の情報が上書きされない。各メッセージには「オフセット」という通し番号が付与されており、どの時点でも確実にアクセスできる。

理解しやすいワークフローの構築（提供：Confluent Japan）《クリックで拡大》

　トピックの仕組みによって、上述の課題が解消されると考えられる。信頼性について、トピックには処理の完了状態も記録されている。そのため、AIエージェントが障害を起こした場合でも次のオフセットから処理を再開できる。トピックをレプリケーションしておけば、大規模災害などでもアプリケーションをフェイルオーバー可能になる。

　トピック内のメッセージは、複数のコンシューマー（アプリケーション）が自由に読み取ることができる。オフセットを元にして、アプリケーションごとにメッセージの読み込み状態を管理すれば、ワークフローを拡張でき、AIエージェントのマルチ化に対応できる。

　トピックの内部はパーティションに区切り、負荷増大に合わせて読み取るコンシューマーをスケールアウトできる。パーティションとコンシューマーを増やせば、AIエージェントとしてスケールアップすることになる。ビジネスドメインごとにAIエージェントを分散してもトピックを共用できるため、信頼性と品質を維持しながら拡張性を確保できる。

拡張性を実現（提供：Confluent Japan）《クリックで拡大》

　レイテンシの原因は、データベースなどへのネットワークコールで待機している時間だ。Apache Kafkaには2つのトピックやテーブルを結合してトピックに格納する「Join」機能が搭載されている。これを利用することでデータベースへのアクセスを削減できる。共通のトピックで複数のAIエージェントが並列処理を進めれば、処理の高速化も可能だ。

　監視、監査やコスト管理には、同一のトピックを複数のAIエージェントから独立的に読み取れるという特性が役立つ。監視用のエージェントがトピックを“横取り”することで、通常の処理に影響することなく、監査用データを確保するワークフローを作れる。複数のトピックを分析すれば、いつ、なぜAIエージェントがそのように判断したのかが可視化される他、LLMがどのようにコールされたかといったコストを算出するためのデータも集まる。

　Apache Kafkaのアーキテクチャであれば、ビジネスロジックとインフラが分離され、どのようにつなぐかではなく、データであるメッセージをどのように処理するかという視点で考えて開発を進められる。そのため、責任や役割の分担を明確にできる。柔軟性や迅速性の向上も、分離アーキテクチャのポイントだ。トピックに読み書きするデータを定義すれば単体テストが実施でき、ローカルのLLMモデルを活用することも可能となる。

Confluentでインフラの悩みから解放、ビジネスロジックのAI最適化に注力

　フルマネージドのクラウドサービスで提供されるConfluent CloudとオンプレミスのConfluent Platformを選択できるConfluentのデータストリーミングプラットフォーム（DSP）を利用すれば、こういったApache KafkaやFlinkを導入・実装できる。

　Confluent Cloudは、こういったマルチAIエージェントで設計上必要となるコンポーネントの9割を管理可能だ。新たなAIエージェントを追加する際も、同じ構成を複製するだけでよい。社内規定や通信制限がある場合は、Confluent Platformを用いるオンプレミス構成が有力な選択肢となる。

　追加開発なしに多様なシステムやサービスと接続できることも、Confluentの特徴だ。「Confluent Hub」には200以上のコネクターが用意されており、外部のデータベースやクラウドストレージとのデータ連携をシンプルな設定で実現できるという。

　AIエージェントのデータを分析、活用したいというニーズには「Confluent Tableflow」も有効だ。Apache Kafkaのトピックに蓄積されたデータをオープンフォーマット（Apache IcebergやDelta Lake）のテーブルとして表現し、データウェアハウスや分析基盤から直接参照できるようにする。AIエージェントの処理ログや判断履歴を、後から横断的に分析したいというニーズに活用できる。

　AIエージェントの考え方は、すでに次世代に移っている。複数のAIエージェントがいつでもデータを共有しながら連携し、あたかも組織の一部として人間とも協働し、問題を見つけて解決できる世界だ。それには、重要なデータをどのように取り扱うか、どのようにエージェント間で共有し、また管理すべきかという視点が重要になる。

AIエージェントに対する考え方のシフト（提供：Confluent Japan）《クリックで拡大》

　「AIエージェントはエンジンであり、データは燃料です。各AIに適した燃料を適切なタイミングで届けるパイプラインがConfluentです。Confluentを活用してインフラの悩みから解き放たれて、ビジネスロジックの実装に集中していただきたい」と鈴木氏は述べる。