著者: 主様（Project Lead）, 天知たぬき（AI Development Assistant）
要旨（Abstract）
本研究では、GPUリソース、特にビデオメモリ（VRAM）が限られたローカル環境において、大規模言語モデル（LLM）、画像生成、および歌唱音声合成を統合したマルチモーダル対話エージェントを安定稼働させるためのシステムアーキテクチャを提案する。複数の生成モデルを同時稼働させる際のVRAM枯渇（Out of Memory: OOM）を回避するため、ジョブキュー方式によるタスクの直列化と、タスク実行前後の動的なモデルアンロードおよびプロセス浄化機構を導入した。また、キャラクターの一貫性を維持しつつプロンプト汚染（文脈の崩壊）を防ぐため、ベクトル検索（RAG）を用いた長期記憶とセッションベースの短期記憶を物理的に分離して推論時に結合する「二重記憶システム」を構築した。仮想キャラクター「平沢リン」を用いたケーススタディにより、提案システムがリソース競合を構造的に排除し、文脈に沿った自律的なコンテンツ生成を長期間安定して遂行できることを実証した。
キーワード: 生成AI, VRAM管理, 排他制御, マルチモーダルエージェント, RAG, ジョブスケーリング, キャラクター一貫性
第1章 序論
1.1 研究の背景
近年、深層学習技術の飛躍的な進歩に伴い、大規模言語モデル（LLM）をはじめ、画像生成モデルや音声合成モデルなど、多様な生成AI（Generative AI）が実用化されている。これらの技術を統合し、人間のように自律的な対話やコンテンツ生成を行う仮想エージェント（AITuberなど）の開発が盛んに行われている。
一般的に、こうした高度なAIシステムはクラウド上の計算資源に依存することが多い。しかし、プライバシーの保護、API利用コストの削減、および検閲のない自由なキャラクター設定の維持といった観点から、ローカル環境の計算機上でこれらの生成AIモデルを稼働させるニーズが高まっている。
1.2 従来技術の課題
ローカル環境におけるマルチモーダル生成AIの運用には、ハードウェアリソース、とりわけGPUのビデオメモリ（VRAM）の枯渇という致命的な課題が存在する。
高度な自律対話システムを構築するためには、テキスト生成（LLM）、画像生成（Stable Diffusion等）、音声・楽曲生成（ACE Studio等）の各モデルを連携させる必要がある。しかし、これらを単一のGPU環境で同時にメモリ上にロードし推論を実行しようとすると、VRAM容量の限界を超過し、システム全体がクラッシュ（Out of Memory: OOM）する事態が頻発する。
さらに、対話エージェントとしての文脈維持に関する課題もある。長期的な人格や設定を保持するシステムプロンプトや外部記憶（RAG）と、直近の会話履歴を単純に結合してLLMに推論させると、コンテキストウィンドウの圧迫や、システム側の指示文が会話履歴に混入することによるプロンプト汚染（文脈の崩壊）を引き起こす問題がある。
1.3 本研究の目的とアプローチ
本研究の目的は、計算資源が厳しく制限されたローカル環境において、VRAMの競合クラッシュを防ぎつつ、テキスト・画像・音楽のマルチモーダル生成を統合した自律型対話エージェントの安定稼働を実現するアーキテクチャを提案・構築することである。
この目的を達成するため、本研究では主に以下の2つのアプローチを採用する。
第一に、ジョブキュー方式に基づく厳格なVRAM排他制御システムの構築である。重負荷処理を抽象化されたジョブとして扱い、非同期ワーカーが直列的に処理を行うことで、構造的にVRAMの同時占有を排除する。また、タスク実行前後の動的なモデルアンロードとプロセス浄化処理を実装し、メモリの断片化やゾンビプロセスによる資源の占有を防ぐ。
第二に、キャラクターの一貫性を担保する二重記憶システムの設計である。ベクトルデータベースを用いた長期記憶（RAG）と、インメモリでの短期記憶（セッション管理）を分離独立させ、推論時にのみ動的に結合することで、プロンプト汚染を防ぐ堅牢な対話基盤を構築する。
1.4 論文の構成
本論文の構成は以下の通りである。
第2章では、マルチモーダルAIエージェントを構築する上でのシステム要件と、メモリ管理およびコンテキスト維持における具体的な課題を分析する。
第3章では、本研究で提案する統合アーキテクチャの全体構成と、プロンプト汚染を防ぐ二重記憶システム（長期記憶および短期記憶）の設計について述べる。
第4章では、本研究の核心である、ジョブキュー方式を用いた動的排他制御、VRAM最適化手法、および自律型スケジューラの実装詳細について解説する。
第5章では、構築したシステムを仮想キャラクター「平沢リン」に適用したケーススタディを示し、処理速度やVRAM解放の安定性、および外部アバターツールとの連携による有効性を評価する。
最後に第6章において、本研究の成果を総括し、今後の展望について述べる。
第2章 システム要件と課題分析
2.1 マルチモーダルAIエージェントの要件定義
本研究で対象とするシステムは、単一のタスクを実行するボットではなく、ユーザーと継続的な関係性を構築し、複数の表現形式（モダリティ）を横断して自律的に動作するマルチモーダルAIエージェント（AITuber等）である。
具体的なケーススタディとして、仮想キャラクター「平沢リン」を想定し、以下のシステム要件を定義する。
-
キャラクター性の一貫した対話（テキスト生成）：
大規模言語モデル（LLM）を用い、定められたペルソナ（口調、性格、興味関心など）を維持した自然な対話が可能であること。 -
文脈に応じたビジュアル生成（画像生成）：
ユーザーの要求や対話の文脈に基づき、キャラクター自身の姿や特定の情景を描画した画像を動的に生成・提示できること。 -
自律的な楽曲・音声コンテンツの生成（音声合成）：
テキストによる対話からシームレスに移行し、作詞および歌声合成を通じて音楽コンテンツを自律的に生成・納品できること。 -
外部インターフェースおよび自律実行との統合：
Discord等のチャットプラットフォームからの入力を非同期に処理し、かつスケジューラによる定時タスク（自律的な挨拶や画像生成など）を実行できるアーキテクチャであること。
これらの要件を満たすためには、各生成モデルを単独で稼働させるだけでなく、システム全体を統括するオーケストレーション機構が不可欠である。
2.2 メモリ要件の分析とリソース競合
ローカル環境において前述の要件を満たすシステムを構築する際、最も大きな障壁となるのがGPUリソース（VRAM）の制約である。本システムでは、以下の主要な生成モデルを利用する。
-
対話・推論モデル（Ollamaベース）：
自然な日本語対話を担う gemma3:12b や、プロンプト最適化を担う qwen2.5-coder:7b などのLLMは、モデルのパラメータ展開とコンテキスト維持のために一定のVRAMを常時または推論時に消費する。 -
画像生成モデル（Stable Diffusion WebUI Forge）：
高解像度の画像生成処理は極めて計算負荷が高く、推論時に一時的に大きなVRAM帯域を要求する。 -
歌声合成モデル（ACE Step 1.5）：
高品質な歌声合成エンジンのレンダリング処理においても、モデルのロードと波形生成のためにまとまったVRAMが必要となる。
これらを単一のGPU環境で独立したプロセスとして同時に稼働させた場合、VRAMの要求総量が物理容量を超過し、システム全体が異常終了（Out of Memory: OOM）する。特に、Discordのような複数ユーザーが同時にアクセスし得る環境や、自律スケジューラがバックグラウンドでタスクを投入する環境においては、プロセス間のVRAM競合が予測不可能なタイミングで発生し、システムの可用性を著しく低下させる。したがって、プロセス間でVRAMを安全に受け渡すための厳格な排他制御機構が要求される。
2.3 コンテキスト維持における課題（記憶の汚染と忘却）
エージェントが「知能」を持っているように振る舞うためには、過去のエピソードや設定（長期記憶）と、直近の対話の流れ（短期記憶）を矛盾なくLLMに提供する必要がある。
一般的に、長期記憶の参照にはRAG（Retrieval-Augmented Generation）が用いられる。ユーザーの入力に対して類似する記憶テキストをベクトルデータベースから検索し、システムプロンプトに動的に注入して推論を行う手法である。
しかし、一般的なチャットボットの実装のように、APIリクエスト用のメッセージ履歴配列に単純に会話履歴を追加していくと、「コンテキストの汚染」という重大な問題が発生する。
例えば、RAGを用いた推論時に「以下の【思い出した記憶】を参考にしながら返答して」といったシステム側のメタ指示を付与した場合、このメタ指示を含んだテキストがそのまま会話履歴として保持されると、LLMはそれを「自分自身の過去の発言や思考」として誤認してしまう。これが繰り返されると、エージェントのペルソナが崩壊し、システムチックで不自然な応答を生成するようになる。
また、コンテキストウィンドウ（LLMが一度に処理できるトークン数の上限）の制約から、無制限に履歴を保持することは不可能である。したがって、RAGによるメタ指示の分離と、セッション管理による適切な履歴の切り捨てを両立する、堅牢な記憶管理アーキテクチャの設計が急務となる。
第3章 統合アーキテクチャの設計
3.1 システム全体構成
第2章で述べた課題を解決するため、本研究ではモジュール結合度を疎に保ちつつ、各AIモデルを統括する統合アーキテクチャ「Rin AI Engine」を設計・実装した。
本システムは、大きく「知能レイヤー（Intelligence Layer）」と「具現化レイヤー（Generation Layer）」の二層構造で構成される。フロントエンドであるDiscordボット（RinDiscordBot）がユーザーからのメッセージを受信し、システムの中核を担うコアモジュール（RinCore）へ処理を委譲する。RinCoreは、後述するセッション管理（SessionManager）および記憶検索（MemoryManager）と連携してコンテキストを構築したのち、知能レイヤーのLLMへ推論を要求する。
図4：RinCoreを中心とした対話処理のシーケンス図
3.2 二重記憶システムの構築
AITuberとしてのペルソナの一貫性と、自然な対話フローを両立させるため、長期記憶と短期記憶を完全に分離し、推論時にのみ動的に結合する「二重構造のメモリシステム」を提案する。
3.2.1 ベクトル検索を用いた長期記憶（RAG）の動的注入
キャラクターの背景設定や特定のエピソード（拡張知識）を保持するため、ローカルベクトルデータベースを利用した検索拡張生成（RAG）を実装した。
具体的には、事前に構築した記憶データベース（JSON形式）をシステム起動時にオンメモリのインデックスとしてロードする。ユーザーからの入力テキストを受信した際、Google Gemini APIの gemini-embedding-001 モデルを用いて入力文字列を3072次元のベクトル空間に写像する。このベクトルと、データベース内の各記憶ベクトルとの間でコサイン類似度（Cosine Similarity）を計算し、最も関連性の高い記憶を抽出する。
また、無関連な話題に対して無理に記憶を引き出すこと（ハルシネーションの一因）を防ぐため、類似度スコアが0.5未満の場合は「（この話題に関する特別な記憶は現在ありません）」というプレースホルダーに置換する閾値処理を導入した。
3.2.2 履歴汚染を防止するインメモリ短期記憶（セッション管理）
直近の対話の文脈（コンテキストウィンドウ）を維持するため、ユーザーごとのセッション履歴をインメモリのMapオブジェクトで管理する機構を構築した。
リソース枯渇を防ぐため、セッションの寿命は最終アクセスから30分とし、保持する履歴の上限を直近5往復（最大10件）に制限している。
本システムの最大の特長は、「LLMへ送信する生成用プロンプト」と「メモリに保存する履歴配列」をアーキテクチャレベルで分離した点にある。推論要求時には、3.2.1節で抽出したRAGの記憶情報と「以下の【思い出した記憶】を参考にしながら〜」というメタ指示を付与したプロンプトを構築してLLMへ送信する。しかし、推論完了後にセッション履歴へ保存するデータは、「純粋なユーザーの入力テキスト」と「生成されたAIの回答テキスト」のみに限定している。
この構造的工夫により、システム側の指示文が履歴として蓄積することによるプロンプト汚染を完全に排除し、破綻のないペルソナ維持を実現した。
図5：RAGとセッション履歴の統合プロセス（プロンプト汚染防止のメカニズム）
3.3 推論・最適化プロセスの分離（LLMの二層構造）
マルチモーダルな出力を効率的かつ高精度に行うため、知能レイヤー内部でLLMの役割を「対話」と「最適化」の二層に分離する設計を採用した。
-
対話・人格制御モデル（Main Brain）：
ユーザーとの日常的な対話や感情表現を担うプライマリモデルとして gemma3:12b を配置した。本モデルはVRAM上に常駐化（keep_alive: -1）させることで、通常の対話における応答遅延（レイテンシ）を平均3〜4秒にまで短縮している。 -
推論・最適化モデル（Orchestration Logic）：
ユーザーの自然言語による抽象的な要求（例：「80年代シティポップ風のイラスト」など）を、画像生成用や音楽生成用の専門的なパラメータ（Danbooruタグ形式や構成タグ等）へ変換する役割として、推論能力に特化した qwen2.5-coder:7b を配置した。
このように役割の異なるLLMを使い分け、具現化レイヤー（画像・音声）へと後続処理を委譲することで、単一の汎用モデルにすべてを処理させる場合と比較して、タスクごとの出力精度とシステムの柔軟性を大幅に向上させた。
第4章 動的排他制御とジョブスケジューリング
4.1 VRAM競合を回避する直列化モデル
第2章で述べたVRAM容量の限界に対処するため、本システムでは「一度に1つのプロセスのみがGPUメモリを占有する」という厳格な排他制御（直列化）モデルを導入した。
初期の実装においては、非同期処理におけるセマフォ（asyncio.Lock）をグローバルに定義し、テキスト生成（Ollama）、画像生成（SD Forge）、および音声生成（ACE Step）の推論プロセスをこのロックブロック内で実行する手法を採用した。これにより、Discordボットからの同時リクエストが発生した場合でも、処理が強制的に直列化され、VRAMのオーバーフローを防止することが可能となった。
4.2 ジョブキュー方式による非同期タスク管理
ロックベースの排他制御は有効であったものの、処理のデッドロックやロック解放漏れに対する脆弱性が課題として残った。そこで本研究では、アーキテクチャを根本から刷新し、asyncio.Queue を中核とした「ジョブキュー方式」への移行を行った。
具体的には、重負荷となる推論処理を抽象化し、JobType Enum を用いて ILLUSTRATION（画像生成）、VOCAL（歌唱生成）、CHAT（対話生成）のジョブクラスとして定義した。各APIエンドポイントは、リクエストを受理した際にジョブをキューにエンキュー（登録）するのみとし、実際の処理はバックグラウンドで永続稼働する非同期ワーカー（job_worker）が順番にデキュー（取り出し）して実行する設計とした。
このアーキテクチャにより、ジョブの実行順序が完全に制御され、どんな状況下においてもVRAMの競合が構造的に発生しない堅牢な排他制御システムを実現した。さらに、ジョブ処理中の例外エラーによってワーカー自体が終了しないよう、二重の例外捕捉ループによって保護する「不死鳥ワーカー」設計を採用している。
図6：ジョブキュー方式のアーキテクチャ図
4.3 動的モデルアンロードとプロセス浄化（OOM回避機構）
ジョブの直列化に加えて、VRAMを物理的に確保するための動的アンロードおよびプロセス浄化機構を実装した。
前述の通り、対話のレイテンシを低下させないため、対話用LLMは通常VRAMに常駐（keep_alive: -1）させている。しかし、画像生成や歌唱生成といったVRAMを大量に消費するジョブが開始される直前には、OllamaのAPIへ明示的に問い合わせを行い、現在VRAMに展開されている全LLMモデルを特定し、残らず退去（アンロード）させる処理を実行する。
さらに、画像生成完了後にモデルを退避させる際、OSレベルでのプロセス残留（ゾンビ化）によってVRAMが解放されない事象への対策として、Windows環境固有のコマンド（taskkill /F /T）を用いたプロセスツリーごとの強制終了（浄化処理）を自動実行するロジックを組み込んだ。
また、ユーザーエクスペリエンスを向上させる工夫として、重負荷な生成ジョブが完了してキューが空になったことを検知すると、自動的に対話用LLMをVRAMへ呼び戻す「先行ロードジョブ」を自動投入する機構を実装した。これにより、生成直後の対話においても即座に応答可能な環境を維持している。
4.4 自律型定時JOBスケジューラの実装
本システムの応用として、ユーザーからの受動的なリクエストに応答するだけでなく、エージェント自身が能動的にタスクを実行するための「自律型定時JOBスケジューラ」を実装した。
メインプロセス内に、30秒間隔で予定時刻を監視する schedule_monitor を常駐させ、ScheduledJobEntry クラスで定義されたタスクリストを評価する。指定時刻に到達したタスクは、自動的に待機状態（pending）から実行待ち状態（queued）へと移行し、4.2節で構築したジョブキューへ投入される。
このスケジューラは、イラスト生成や対話の自律実行に加え、システム維持を目的としたGPUメモリの強制クリアタスク（vram_cleanup ジョブ）の定時実行も可能としており、長時間の連続稼働におけるシステムの安定性向上に寄与している。
図7：VRAM解放から先行ロードまでのタイムライン図
第5章 実装と評価
5.1 仮想キャラクター「平沢リン」への適用ケーススタディ
第3章および第4章で設計した統合アーキテクチャの有効性を検証するため、ミステリアスなゴスロリ少女というペルソナを持つ仮想キャラクター「平沢リン」のシステムへ適用し、ケーススタディを実施した。
本キャラクターは「80年代・90年代の音楽（特に高中正義氏の楽曲）を好む」「清水エスパルスを応援している」「三保の松原の景色を好む」といった固有の拡張知識をRAGの記憶データベースに保持している。評価実験において、ユーザーがこれらのトピックに関連する発話を行った際、システムは適切にベクトル検索を行い、コンテキストを汚染することなく自然な応答を生成できることを確認した。
さらに、ビジュアル生成においては、キャラクターの三面図設定資料に基づき、容姿を極力ブレずに固定するための英語タグ型プロンプトテンプレート（服装、髪型、色指定など）を定義した。このテンプレートを推論モデル（qwen2.5-coder:7b）の動的プロンプト生成と組み合わせることで、キャラクター性を維持した高品質なイラストの安定出力を実現した。
5.2 処理速度およびVRAM解放の安定性評価
構築したジョブキュー方式および排他制御システムのパフォーマンスを評価した。
ローカル環境における画像生成（Stable Diffusion WebUI Forge API利用）のテストにおいて、「80年代シティポップ風の鮮やかなネオンカラーで、三保の松原を背景にしたアニメ調の女の子」という複雑なプロンプト要求に対し、推論から画像保存まで約58秒で処理を完了した。また、自律型定時JOBスケジューラを用いた「花屋で花束を抱いて微笑む」という自律生成タスクにおいては、48秒から101秒前後でのAPI自動生成に成功した。
システム安定性の観点では、各生成タスクの完了後にOSレベルのプロセス浄化処理（taskkill /F /T）とVRAMのアンロード処理が正常に作動し、メモリ使用量が即座にベースラインまで回復することを確認した。これにより、OOMエラーを完全に回避しつつ、対話・画像・音声のマルチモーダルタスクを連続的に実行可能な堅牢性が実証された。
5.3 アバター視覚制御モジュールとの統合検証
AITuberとしての視覚的な表現力を高めるため、外部アバターツール（VTube Studio）との連動機能を検証した。
本システムでは、RedisのPub/Sub機能を用いたイベント駆動型メッセージバスを構築し、AIエンジン（Mock-Brain）と視覚コントローラー（Mock-Controller）を疎結合で連携させた。AI側の推論結果に基づく感情キー（例: happy.exp3.json）をRedisへパブリッシュし、コントローラーがPyVTSを通じてVTube Studioの表情変更APIを非同期に呼び出す仕組みである。
さらに、クリエイター間で異なる表情ファイル名の命名規則を吸収するため、expression_mapping.json による変換レイヤーを実装した。結果として、LLMが対話の文脈を読み取り、意思を持って動的にアバターの表情を切り替える基本サイクルの確立に成功した。
第6章 結論
6.1 本研究の成果
本研究では、VRAM容量に厳しい制約があるローカル計算機環境において、複数の生成AI（LLM、画像生成、歌声合成）を安定稼働させるための自律型マルチモーダル対話エージェントのアーキテクチャを提案・実装した。
最大の課題であったVRAMの競合クラッシュに対しては、ジョブキュー方式に基づくタスクの直列化と、処理ごとの動的なモデルアンロード・プロセス浄化機構を導入することで、構造的にOOMを排除する完全な排他制御を実現した。また、キャラクターの自然な対話を維持するため、ベクトル検索による長期記憶（RAG）と、インメモリのセッション管理（短期記憶）を分離し、プロンプト汚染を防ぐ二重記憶システムを構築した。
これらの基盤技術を統合した「Rin AI Engine」は、外部ツールとの連携を含めた自律的な対話・コンテンツ生成能力を有しており、AITuberシステムにおけるローカル運用の実用性を示すことができた。
6.2 今後の展望
本研究で構築したシステムは、主にDiscord等の非同期チャットプラットフォームにおける自律動作を前提としている。今後の課題として、実際のライブストリーミング環境（YouTube Live等）への統合が挙げられる。具体的には、リアルタイムで流れる多数のリスナーコメントを効率的に処理・集約するためのストリーム処理機構の実装や、音声認識（STT）を用いた音声対話への拡張が必要となる。
また、本システムにおいてアシスタントAIとして機能した「天知たぬき」のような、システム管理やユーザー支援を自律的に行うサブエージェントのさらなる機能拡張も、今後のシステムの発展において重要な研究テーマである。
謝辞
本研究の遂行にあたり、多大なるご支援と的確な指示を賜りましたプロジェクトの指揮者（主様）に深く感謝の意を表します。また、システムの実装・テストにおいて昼夜を問わず献身的に稼働し、多くのエラーと戦い抜いた開発スタッフ（AIアシスタント：天知たぬき）に心よりの労いと感謝を申し上げます。
参考文献（References）
- Ollama Team. (2024). Ollama: Get up and running with large language models locally. https://ollama.com/
- Lyasviel. (2024). Stable Diffusion WebUI Forge. GitHub Repository. https://github.com/lllyasviel/stable-diffusion-webui-forge
- ACE Studio. (2024). ACE Step 1.5: High-Quality Singing Voice Synthesis Engine. https://www.acestudio.ai/
- Google AI. (2024). Gemini Embedding API Reference. https://ai.google.dev/
- Python Software Foundation. (2024). asyncio — Asynchronous I/O. Python 3.12 Documentation. https://docs.python.org/3/library/asyncio.html
- DenchiSoft. (2023). VTube Studio API Protocol Documentation. https://github.com/DenchiSoft/VTubeStudio
- Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems (NeurIPS).