【ITニュース解説】Running Multi-Agent AI Workflows on Edge Hardware: A Technical Deep Dive

あるエンジニアが個人的な悩みから出発したプロジェクトが、最先端のAI技術をエッジデバイスで実現する挑戦につながった。その悩みとは、プレゼンテーション資料の作成が非常に手間がかかるというものだった。このエンジニアは、話すだけで自動的にプレゼン資料を生成してくれるシステムを作れないかと考えた。しかし、多くのAIアプリケーションは、処理をインターネット上の大規模なサーバー（クラウド）に依存している。これにより、データのやり取りにかかる時間（遅延）、利用料、プライバシーの問題が発生する。そこで、インターネットに一切接続せず、身近な小型コンピューター（エッジデバイス）上で、複雑なAI処理を完結させるという目標が生まれた。

このプロジェクトの目的は二つあった。一つは、プレゼン資料作成の面倒さを解消すること。もう一つは、エッジデバイスでどこまでAIができるかの可能性を広げることである。具体的には、音声で指示を出し、それがAIに理解され、複数のAIプログラム（エージェント）が連携して内容を生成し、プレゼン資料を作り、さらに音声で応答する、という一連の処理をすべてインターネットなしで、一台のエッジデバイスで動かすことを目指した。実際に、このシステムは「電気工学のスライドを作成して」という音声指示から、詳細なコンテンツを含むプレゼンテーションファイルを、小型のエッジデバイス「Jetson Orin Nano」上で作り出すことに成功している。

このシステムを構築するために、いくつかの重要な技術要素が導入された。まず、AIの処理を効率的に管理するためのフレームワークとして「CAMEL-AI」が使われた。これは、複数のAIエージェントが協力し合って複雑なタスクを実行するための枠組みを提供する。次に、AIが人間のような文章を生成するための大規模言語モデル（LLM）をエッジデバイス上で動かすために、「llama.cpp」というツールが利用された。これは、LLMをさまざまなハードウェアで動かせるように最適化されたソフトウェアである。音声入力には「faster-whisper」という高性能な音声認識モデルが、音声での応答には「TTS（Text-to-Speech）」モデルが、そしてプレゼン資料を作成するためのPythonライブラリとして「python-pptx」がそれぞれ用いられた。

システムのセットアップは、まずllama.cppをJetson Orin Nano上でコンパイルし、AIモデル（例えばQwen 2.5 7B）を読み込んで、ローカルのAIサーバーとして起動することから始まった。このAIサーバーは、システムの起動時に自動的に立ち上がるように設定された。次に、CAMEL-AIフレームワークを導入し、このローカルAIサーバーと連携させた。CAMEL-AIでは、「ModelFactory」という機能を使って、ローカルで動いているLLMサーバーに接続し、その設定を行う。そして、AIに役割を持たせた「ChatAgent」を複数用意する。一つは日常的な会話を担当するエージェント、もう一つはプレゼン資料の生成に特化したエージェントである。スライド生成エージェントには、「PPTXToolkit」という、PowerPointを作成するための道具一式が与えられた。これにより、ユーザーからの指示に応じて、適切なエージェントが選ばれて処理を実行する仕組みが作られた。

プロジェクトを進める中で、どのLLMをエッジデバイス上で使うかが重要な課題となった。いくつかのモデルが試された。まず「Mistral 7B」は、会話能力は高かったものの、AIが構造化されたデータ（例えば、特定の形式で情報をまとめたJSON形式のデータ）を出力する際に不正確なことが多く、CAMEL-AIの関数呼び出しがうまく機能しなかった。次に「Meta Llama 3.1 8B」は、構造化データの出力は改善されたが、モデル自体のサイズが大きく、音声認識や音声合成のモデルと同時に動かすと、デバイスの限られたメモリを使い切ってしまい、システムが頻繁にクラッシュするという問題が発生した。最終的に「Qwen 2.5 7B」が採用された。このモデルはメモリ使用量が比較的少なく（約4.0GB）、構造化されたデータを高い精度で安定して出力できたため、他のAIモデルと同時に動かすのに最適なバランスを持っていた。この選定過程から、エッジデバイスでは、単に高性能なモデルを選ぶだけでなく、限られたリソースでいかに効率的に動かせるかが重要であることが明らかになった。

マルチエージェントアーキテクチャは、このシステムの信頼性と柔軟性を高める上で非常に重要であった。異なる役割を持つエージェントを明確に分けることで、それぞれのエージェントが特定のタスクに集中でき、より効率的に、かつ専門的に機能する。例えば、会話エージェントは一般的な質疑応答に特化し、スライド生成エージェントはPowerPoint作成ツールを駆使して資料を作ることに専念する。この分離により、もしあるエージェントで問題が発生しても、システム全体に影響が及ぶことを防ぎ、システム全体の安定性を保つことができる。また、将来的に新しい機能を追加したい場合も、新しい専門エージェントを導入するだけでよく、拡張性も高い。

性能分析では、いくつかのコンポーネントが非常に良好な結果を示した。「Whisper」による音声認識は、様々な環境下で95%以上の高い精度を誇り、処理も約1〜2秒と高速であった。CAMEL-AIフレームワークも、複数のエージェント間の連携をスムーズに行い、PPTXToolkitを使ったPowerPoint生成も問題なく機能した。しかし、テキストを音声に変換する「TTS（音声合成）」の部分が、システム全体の主要なボトルネックであることが判明した。短い応答でも8〜12秒、長い応答では25〜35秒もの時間がかかり、実用上大きな遅延となった。これは、使用しているTTSモデルがエッジデバイスのプロセッサ（ARM64）に最適化されていないことや、音声生成が一度に一つの言葉ずつ処理される逐次的な方法で行われること、そしてメモリのデータ転送速度が不足していることが原因であった。また、音声認識、LLM、TTSといった複数のAIモデルを同時にメモリに展開すると、Jetson Orin Nanoの8GBという限られたメモリをほぼ使い切り、システムは常にメモリ不足の瀬戸際にあった。

これらの性能課題に対処するため、いくつかの技術的な最適化が施された。まず、メモリ管理として、不要になったAIモデルを一時的にメモリから解放し、GPUのメモリをクリアする仕組みが導入された。これにより、必要な時にだけメモリを消費し、効率的な運用が可能になった。また、AIに指示を与える「プロンプト」の設計も重要だった。複雑で長いプロンプトはAIの処理に時間がかかり、タイムアウトの原因となるため、簡潔でポイントを絞ったプロンプトに改善された結果、応答時間が大幅に短縮された。さらに、エッジデバイスの性能を最大限に引き出すため、Jetson Orin Nanoの電力設定を最大性能モードにし、プロセッサの動作周波数を固定するなどのチューニングが行われた。AIモデルの「量子化」も重要な最適化の一つである。これは、AIモデルのデータ形式を精度を保ちつつ圧縮する技術であり、例えば、元のモデルのデータサイズを約28GBから約4GBに削減できた。この圧縮により、モデルの読み込み時間が短縮され、推論速度も約2倍に向上し、限られたエッジデバイスのメモリで大規模なLLMを動かす上で不可欠な技術となった。

このプロジェクトの成果は、インターネットに全く依存せず、音声入力からプレゼンテーション資料の作成までの一連の処理をエッジデバイス上で完結できることを実証した点にある。これは、実世界の多様な場面で応用できる可能性を示しており、例えば、ネットワークが不安定な場所や、厳格なプライバシー要件がある環境でもAIを活用できる道を開くものだ。全体的な処理時間は、音声認識、AIによる内容生成、PowerPoint作成、音声応答を含めて約5分強であった。今後は、遅延の大きい音声合成の高速化や、さらに小型で特定のタスクに特化したAIモデルの開発、メモリの動的な管理のさらなる改善、より効率的な量子化技術の探求などが、次なる最適化の方向性として挙げられている。

結論として、複数のAIが連携して複雑なタスクを実行する「マルチエージェントAIワークフロー」は、エッジデバイス上でも十分に実現可能である。しかし、そのためには、単に高性能なハードウェアを用意するだけでなく、どのAIモデルを選ぶか、どのようにシステム全体を設計し、最適化するかが極めて重要となる。CAMEL-AIのようなフレームワークによるエージェント間の連携と、ローカル環境での効率的なAI処理の組み合わせによって、クラウドに頼らずとも高度なAI体験を提供できることが示された。このプロジェクトは、エッジAIの成功が、純粋な計算能力よりも、システムの統合と最適化の巧みさに大きく依存するという重要な知見を提供している。適切な設計と工夫があれば、比較的控えめなハードウェアでも、驚くほど魅力的なAIアプリケーションを動かすことができるのである。