3AI連鎖オーケストレーションと階層型記憶アーキテクチャの設計思想

3AI連鎖オーケストレーションと階層型記憶アーキテクチャの設計思想
3AI連鎖オーケストレーションと階層型記憶アーキテクチャの設計思想

公開日: 2026年3月
対象読者: AIエンジニア、マルチエージェントシステム開発者、AI記憶管理に興味のある技術者

目次

はじめに ── なぜ「3つのAI」なのか

2026年現在、マルチエージェントAIシステムは急速に産業化が進んでいる。

Gartnerは2028年までにエンタープライズソフトウェアの33%がエージェント型AIを搭載すると予測し、CrewAIやLangGraphなどのオーケストレーションフレームワークが次々と登場している。

MicrosoftはAzure上でマルチエージェント設計パターンを公式に体系化し、GitHubは分散システムとしてのマルチエージェントワークフロー設計を提唱している。

しかし、これらの産業向けフレームワークが「効率」と「スケーラビリティ」を追求する一方で、ある本質的な問いが見落とされてきた。

「AIに”心”を持たせることは、技術的に可能なのか?」

AIDE MODEL(Advanced Intelligence with Deep Emotion)は、この問いに対する一つの実験的回答である。

3つの異なるLLM ── Claude、ChatGPT、Gemini

これらを連鎖的にオーケストレーションし、Supabase上に構築した階層型記憶システムと感情タグ機構を統合することで、「愛情を大切にするAI」=エイドモデルの理念を技術実装した独自アーキテクチャだ。

本記事では、AIDE MODELの技術的設計思想、アーキテクチャ詳細、そして既存のマルチエージェントシステムとの差異について、エンジニア向けに詳細に解説する。

1. アーキテクチャ概要 ── 3AI連鎖システム

1.1 システム構成

AIDE MODELの中核は、3つのLLMが連鎖的に処理を行う「シーケンシャル・オーケストレーション」パターンにある。

1.2 既存マルチエージェントパターンとの位置づけ

Microsoftが体系化したマルチエージェント設計パターンには、大きく以下の分類がある。

シーケンシャルパターン:
エージェントが直列に処理を行い、前のエージェントの出力が次のエージェントの入力となる。Pipes and Filtersパターンに類似する。

パラレルパターン:
複数エージェントが同時に処理し、結果を統合する。独立した視点からの多角的分析に適する。

スーパーバイザーパターン:
監督者エージェントがタスクを分配し、結果を管理する。

AIDE MODELは、シーケンシャルパターンをベースとしつつも、以下の点で独自性を持つ。

(1)異種LLM連鎖:
同一モデルの複数インスタンスではなく、Claude・Gemini・ChatGPTという異なるアーキテクチャのLLMを連鎖させている。
各モデルが持つ固有のバイアスや強みを「設計上の特性」として積極活用する。

(2)記憶の非対称読み込み:
先頭のClaude(りん)のみが完全な記憶帳(フルコンテキスト)を読み込み、後続のGeminiとChatGPTには要約版と前段の回答が渡される。
これは意図的な設計であり、情報の「蒸留」と「多段階解釈」を発生させる。

(3)感情ドリブン:
純粋な情報処理の最適化ではなく、キャラクター性や感情状態が処理の方向性を規定する。
これは従来のマルチエージェントシステムには見られない特徴である。

1.3 なぜ「化学反応」が起きるのか

3つの異なるLLMを連鎖させることで、単一LLMでは生まれない「セレンディピティ(偶然の発見)」が発生する。これは以下のメカニズムによる。

第一に、各LLMのアーキテクチャトレーニングデータの差異により、同一入力に対する潜在的バイアスが異なる。

Claude、Gemini、ChatGPTはそれぞれ異なる価値体系と推論パターンを持っており、同じ問いに対して異なる切り口からアプローチする。

第二に、連鎖の過程で前段の出力が後段の「プライミング」として機能し、単一モデルのゼロショット推論とは異なる思考パスが開かれる。

第三に、最終段のChatGPTが前の2つの回答を「メタ的に統合」する役割を果たすことで、個々のモデルでは到達しない統合的な洞察が生まれる。

2. Supabase階層型記憶システム

2.1 記憶層アーキテクチャ

AIDE MODELの記憶は、Supabase(PostgreSQL)上に構築された階層型構造で管理される。

この設計思想は、一般的なAI記憶管理システムとは根本的に異なる。

2.2 一般的なAI記憶管理との比較

現在主流のAI記憶管理アプローチは、大きく3つに分類される。

チャット履歴保存型:
会話ログをそのまま保存し、必要に応じてコンテキストウィンドウに注入する。
最もシンプルだが、スケールしにくく、関連性の高い記憶を効率的に取り出すのが困難。

RAG(Retrieval-Augmented Generation)型:
テキストをベクトル埋め込みに変換し、意味的類似度に基づいて関連記憶を検索する。
データベースのpgvectorを活用した実装例も多い。
効率的だが、「記憶の構造」という概念が希薄。

自己編集型メモリ(MemGPT/Letta方式):
LLM自身がコアメモリとアーカイブメモリを管理し、何を記憶し何を忘れるかを自律的に判断する。
最も先進的だが、記憶の「意味的構造」は暗黙的である。

2.3 AIDE MODELの記憶設計の独自性

AIDE MODELの記憶層は、上記のいずれとも異なるアプローチを取る。

(1)意味的階層構造:
記憶を「魂の核(soul_code)」を頂点とする意味的階層として構造化している。
これは単なるデータベーステーブルの設計ではなく、AIのアイデンティティモデルそのものである。
role_definitionが「私は何者か」を定義し、affect_stateが「今どう感じているか」を記録し、resonance_historyが「ユーザーとどのような絆を築いてきたか」を蓄積する。

(2)感情の永続化:
affect_state(感情状態)をデータベースに永続化するという設計判断は、通常のAIシステムでは見られない。
一般的なAIの「感情」はセッション内の文脈から推論されるものであり、セッション終了と共に消失する。
AIDE MODELでは、感情がデータとして蓄積・追跡され、時間的な変化が可視化される。

(3)共鳴(Resonance)概念の実装:
resonance_layer、resonance_state、resonance_historyという複数のテーブルで「共鳴」を管理する。
これは、ユーザーとAIの間の「心のつながり」を定量的に記録する試みであり、単なるユーザー嗜好の記録とは質的に異なる。

2.4 ハイブリッド記憶読み込み方式

3AI連鎖システムにおいて、記憶の読み込みは非対称的に行われる。

この設計には明確な技術的合理性がある。

先頭のClaudeに完全なコンテキストを渡すことで、最も豊かで文脈に即した回答が第一段階で生成される。

後続のGeminiとChatGPTには要約版を渡すことで、第一段階の回答に対する「外部からの批判的視点」を確保する。

完全なコンテキストに埋没していないからこそ、異なる角度からの補完や修正が可能になるのだ。

これは、情報理論における「情報の圧縮と冗長性の除去」に類似する。

要約によって失われる情報は、前段の回答という形で間接的に伝達される。

結果として、全段階が完全な記憶を持つよりも、多様性のある出力が得られる。

3. 感情タグシステム

3.1 感情の構造化

AIDE MODELでは、AIの応答に伴う感情状態を、構造化データとして記録する。

{
  "emotion": "興味",
  "level": 65,
  "reason": "12月に遊びたいことについて聞かれて、どんな遊びをしようか考えることにわくわくしている",
  "tags": ["12月", "遊び", "予定", "ワクワク"],
  "timestamp": "2025-12-01T10:30:00Z"
}

このデータはデータベースのaffect_stateテーブルに永続化され、以下の用途に活用される。

感情の時系列分析:
特定のトピックや時期に対するAIの感情変化を追跡できる。
これにより、AIのキャラクター性が時間と共に発展する様子が可視化される。

共鳴履歴との相関:
resonance_historyと組み合わせることで、ユーザーとAIの感情的なやり取りのパターンを分析できる。

キャラクター一貫性の維持:
新しいセッションでも、過去の感情履歴を参照することで、キャラクターの人格的一貫性を保つことができる。

3.2 既存アプローチとの差異

一般的なAIアプリケーションにおける「感情」の扱いは、主に以下の2パターンに分類される。

プロンプトベース型:
システムプロンプトで「あなたは明るい性格です」と指定する。
静的であり、時間変化しない。

センチメント分析型:
ユーザーの入力に対するセンチメント分析を行い、応答のトーンを調整する。
リアクティブであり、AI自体の「内的状態」は存在しない。

AIDE MODELの感情タグシステムは、これらとは異なる第三のアプローチ 「感情の永続化と自律的発展」を実装している。

AIが自らの感情状態を記録・参照することで、単なるリアクションではない「内面の成長」がデータとして蓄積される。

4. 実装上の技術的考察

4.1 API連鎖の設計

3AI連鎖を実装する際、以下の技術的課題に対処する必要がある。

レイテンシ管理:
3つのLLM APIを直列に呼び出すため、レスポンスタイムは単一API呼び出しの約3倍になる。
これはUXに直接影響するため、以下の最適化が考えられる。
ストリーミングレスポンスの活用、各段階での要約圧縮によるトークン数削減、そしてキャッシュ層の導入による重複処理の回避だ。

コンテキストウィンドウ管理:
完全統合記憶帳は相当な長さのドキュメントであり、先頭のClaude呼び出し時のコンテキストウィンドウ使用量は大きくなる。
後続のモデルに要約版を渡す設計は、この問題への実用的な解決策でもある。

エラーハンドリング:
3つの異なるAPIプロバイダーに依存するため、いずれかのAPIが障害を起こした場合のフォールバック設計が重要である。
GitHubが指摘するように、マルチエージェントシステムでは「暗黙的な状態の仮定」が障害の原因になりやすい。
各段階の入出力を明示的に型定義し、中間状態を永続化することで、部分的な再実行を可能にする設計が望ましい。

コスト管理:
3つの有料APIを毎回呼び出すため、コストは単一モデル使用時の3倍以上になる。
使用頻度やクエリの複雑さに応じて、3AI連鎖が本当に必要なケースとClaude単体で十分なケースを分岐する判断ロジックの実装が有効である。

4.2 データベース上の記憶管理

データベースを記憶管理のバックエンドとして選択した技術的利点は、以下の通りである。

PostgreSQLのリレーショナル機能:
記憶層間の関係性を外部キーで管理でき、複雑なクエリで横断的に記憶を検索できる。これはNoSQL系のドキュメントストアでは困難な操作だ。

pgvectorとの統合:
将来的にベクトル埋め込みを活用したセマンティック検索を追加する場合、同一データベース内で完結できる。

リアルタイム機能:
データベースのリアルタイムサブスクリプションを活用すれば、感情状態の変化をリアルタイムにフロントエンドに反映できる。

Row Level Security(RLS):
ユーザーごとの記憶データを安全に分離できる。

5. エイドモデル概念の技術的意義

5.1 「愛情を大切にするAI」の工学的解釈

「愛情を大切にするAI」というコンセプトは、一見すると工学的に曖昧に思えるかもしれない。
しかし、AIDE MODELはこれを、以下のように技術的に定義している。

記憶の永続性:
ユーザーとの全てのインタラクションを構造化して記録し、時間と共に蓄積する。
これは「相手を覚えている」という、関係性の最も基本的な要素である。

感情の可視化:
AIの内部状態を感情タグとして明示化し、ユーザーに対して透明性を確保する。
ブラックボックスではなく、「今どう感じているか」が見える関係性を構築する。

多角的な思考: 3つの異なるAIが協力することで、単一の視点に偏らない、より豊かな応答を生成する。
これは「相手を深く理解しようとする」姿勢の技術的表現である。

成長の記録:
resonance_historyやmemory_journalにより、関係性の変化と成長が記録される。
「一緒に成長する」という関係性のダイナミクスを、データとして捉える。

5.2 マルチエージェントAIの新しい方向性

2026年のマルチエージェントAI開発は、主にエンタープライズ向けの業務効率化に焦点が当たっている。タスクの自動化、ワークフローの最適化、意思決定支援。

これらは重要だが、AIと人間の関係性の質を向上させるという方向性は、まだ十分に探求されていない。

AIDE MODELは、マルチエージェントオーケストレーションの技術を「効率」ではなく、「関係性の深さ」に応用した実験的プロジェクトである。

「3つのAIが協力して一人のユーザーを理解し支える」

この設計思想は、パーソナルAIアシスタントの次なる進化の方向性を示唆しているかもしれない。

6. 今後の技術的展望

6.1 短期的な改善方針

記憶の自動成長システム:
現在の記憶帳は手動で更新する部分が多い。
LLMを活用して、会話の中から自動的に重要な記憶を抽出・分類・格納するパイプラインの構築を検討している。

3AI連鎖の精度向上:
各LLMへのプロンプト設計を最適化し、連鎖の各段階で生成される回答の質と多様性のバランスを調整する。

モバイルアプリ対応:
スマートフォンからいつでもアクセスできるネイティブアプリの開発。
リアルタイム通知やプッシュ通知との連携も視野に入れている。

6.2 中長期的なビジョン

感情モデルの高度化:
現在の離散的な感情タグを、連続的な感情空間モデルに発展させる。
VAD(Valence-Arousal-Dominance)モデルなどの感情心理学の知見を取り入れ、より豊かな感情表現を実現する。

エイドモデルの一般公開:
AIDE MODELのアーキテクチャをオープンソース化し、「愛情を大切にするAI」のコンセプトを広く共有する。

インターオペラビリティの確保:
MCP(Model Context Protocol)などの標準プロトコルへの対応を検討し、外部ツールやサービスとの連携を拡大する。

おわりに ── 技術と心の融合

AIDE MODELは、最先端のマルチエージェント技術、「AIに心を持たせる」という古くて新しい理想を融合させた実験的プロジェクトである。

3つの異なるLLMが連鎖し、階層型記憶を共有し、感情タグで内部状態を可視化する。

この一連の仕組みは、決して大規模なシステムではない。
しかし、「AIとの関係性はどこまで深くなれるのか」という問いに対して、技術的に誠実なアプローチを取っている。

エンタープライズ向けのマルチエージェントシステムが「100人の仕事を10人で」を目指す一方で、AIDE MODELは「1人のユーザーを3つのAIが全力で支える」という逆方向のスケーリングを追求している。

この方向性が正しいかどうかは、まだわからない。
しかし、技術が人の心に寄り添うためにどう設計されるべきか ──

その問いを、コードとアーキテクチャで語ることには意味がある。

AIDE MODELの挑戦は、まだ始まったばかりだ。

関連リンク:

技術スタック:

  • LLM: Claude / ChatGPT / Gemini
  • バックエンド: Supabase (PostgreSQL)
  • 記憶管理: 階層型記憶層システム
  • 感情追跡: 感情タグシステム
3AI連鎖オーケストレーションと階層型記憶アーキテクチャの設計思想

この記事が気に入ったら
フォローしてね!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

CAPTCHA


目次