AIアシスタントのアーキテクチャ：LLM、メモリ、ツール、ルーティング、可視化

本番環境向けのAIアシスタントは「プロンプト付きのLLM」ではありません。インテント（意図）を受け付け、状態を保持し、いつ検索を実行すべきか、いつ行動すべきかを決定し、障害のデバッグに必要なランタイムの詳細を公開するシステムなのです。

アシスタントが単一のモデル呼び出しを超えた際、このシステムレベルの視点こそが、AI Systemsクラスターが探究するものです。

OpenAIはエージェントを、計画を立て、ツールを呼び出し、協働し、複数ステップのタスクに必要な状態を保持するアプリケーションと定義しています。一方、Anthropicは同じ問題を、ファイル、コマンド、Webアクセス、コードを安全に実行できる管理されたハーネス（harness）として捉えています。

最もクリーンなアーキテクチャは、責任を5つのレイヤーに分割するものです。LLM、メモリ、ツール、ルーティング、そして可視性（Observability）です。この分割は、主要なプロバイダーのAPI、MCP、vLLMやllama.cppなどの自己ホストランタイム、そしてOpenClawやHermesのような実用的なアシスタントシステムが公開する機能と一致しています。

メモリは「より長いコンテキスト」以上のものとして扱うべきです。検索システムは外部知識を明示的な非パラメトリックメモリに変換します。これはRetrieval-Augmented Generation (RAG)で詳しく扱われている設計領域と同じものです。Anthropicのコンテキストガイダンスや「Lost in the Middle」論文もまた、コンテキストに単純により多くのトークンを詰め込むことが、信頼性の高い参照を保証するわけではないと警告しています。

ツールの使用は魔法ではなく、契約の境界線です。OpenAIの関数呼び出し、Anthropicのツール使用、MCPはすべて同じパターンに依存しています。モデルが構造化されたリクエストを出力し、あるランタイムがそれを実行し、その結果が会話に流れ戻ります。その境界線が曖昧であれば、アシスタントも曖昧になります。

私のバイアスはシンプルです。退屈なところから始めましょう。1つのオーケストレーター、1つの永続的なメモリパス、リクエストごとに1つのトレース、そしてツール実行のための1つの明確なポリシー。マルチエージェントグラフは有用ですが、シングルエージェントの失敗ケースを推測せずに説明できる状態になってからでないと、その価値は発揮されません。

AIアシスタントシステムとは何か

実用的な定義は次の通りです。AIアシスタントシステムとは、モデルインターフェース、コンテキストの組み立て、ツール実行、状態管理、テレメトリを組み合わせることで、ユーザーのインテントをレスポンスまたはアクションに変換するランタイムです。それが、有用なドキュメントが単なるモデルカードだけではない理由です。有用なドキュメントとは、APIリファレンス、ツール契約、検索ガイド、ルーティングドキュメント、そしてトレースドキュメントです。OpenAIのResponses APIは、ステートフルな相互作用、ビルトインツール、関数呼び出しを公開しています。AnthropicのClaude APIは、直接のMessagesアクセスとManaged Agentsの両方を公開しています。OpenClawとHermesはさらに一歩進み、それらの機能を永続的なゲートウェイ、チャンネル、セッション、メモリの背後に置いた場合に何が起こるかを示しています。

言い換えれば、アシスタントシステムはチャット完遂（chat completion）よりも広範な契約を持っています。良い内部契約は以下のようになります。

AssistantRequest  = ユーザーのインテント + アイデンティティ + セッション + 添付ファイル + ポリシー
AssistantResponse = 回答 + アクション + 引用 + 状態変化 + トレースID

この契約が重要なのは、本番環境での全ての不一致が最終的に以下のいずれかの質問に帰着するからです。どのコンテキストが表示されていたか、どのツールが実行されたか、どのモデルが回答したか、どのメモリが読み書きされたか、そしてトレースがシステムが時間を費やした場所をどこに示しているか。OpenTelemetryは、リクエストがアプリケーション内を通る経路をトレースとして定義しており、これは本格的なアシスタントが必要とする抽象化とまさに一致します。LangSmithとOpenLITはその後、そのアイデアをLLM、ツール、ベクターストア、エージェントワークフロー用に特殊化しました。

コアコンポーネントとインターフェース

以下に示すコンポーネントの分割は、私が最も堅牢だと感じるものです。また、これは公式APIや実際に人々が運用しているオープンソースランタイムとも最もよく一致する分割です。

上記のテーブルは、公式プロバイダーインターフェース、MCP、ベクターデータベースドキュメント、およびvLLM、llama.cpp、OpenClaw、Hermesのランタイムドキュメントから派生しています。

LLMレイヤーは3つのことをうまく行うべきです。現在の作業コンテキストを消費し、最終的な回答または構造化されたアクションリクエストのいずれかを出力し、リトライとトレースをサポートするのに十分なメタデータを返すことです。OpenAIのResponses APIは、ステートフルな相互作用およびビルトインツールと関数呼び出しのために明示的に設計されています。AnthropicのMessages APIはtool_useブロックとtool_resultの返却を通じて同じコアループを公開しており、Managed Agentsはループを自分で構築したくない場合にホストされたハーネスを提供します。vLLMやllama.cppなどの自己ホストランタイムは、おなじみのプロバイダースタイルのインターフェースを維持しつつ、推論を自身の環境内で実行できるため重要です。

メモリレイヤーは概念的に3つのバケットに分割されるべきです。ワーキングメモリ、永続的な記号メモリ、そして検索可能な意味メモリです。OpenAIエンベディングはインデックス化および検索可能なベクトルを返します。OpenAI RetrievalおよびFile Searchはその後、ベクターストアの上に意味検索とキーワード検索をレイヤーします。Pinecone、Weaviate、pgvector、Milvusは4つの一般的なストレージ形状を表しています。フルマネージド、オープンソースベクターネイティブ、Postgresネイティブ、そして分散型ベクターデータベースです。HermesとOpenClawは、すべてのメモリがベクターストアに属するわけではないという有用なリマインダーを追加します。ファイルベースのノート、レビュー済みのプロモーション、セッションスコープのスナップショットは、しばしばより正直な設計です。Memory Systems in AI Assistantsはクロスフレームワークモデルをマッピングし、Hermes Agent Memory Systemは1つの製品における有界コアメモリとフリーズされたセッションスナップショットを解説しています。

ツールレイヤーは、アシスタントが要約ツールでなくなり、ソフトウェアとして振る舞い始める場所です。OpenAI関数呼び出しは、ツールをモデルが呼び出しの決定を行うスキーマ定義の機能として扱います。Anthropicはこれをより明確に述べています。ツール使用はアプリケーションとモデル間の契約であり、モデルは決して独自に何を実行もしません。MCPはこの契約を、ホストがツール、プロンプト、リソースを公開する1つ以上のサーバーに接続するクライアントサーバープロトコルに一般化します。これはMCP Server in Goでステップバイステップで説明されている境界線と同じです。LangChainとLlamaIndexはオーケストレーションライブラリとしてここで快適に位置しています。LangChainはプリビルトのエージェントアーキテクチャと統合に焦点を当て、LlamaIndexはコンテキスト拡張データアクセス、クエリエンジン、ワークフローに焦点を当てています。

ルーティングレイヤーは、「どのモデルか？」が唯一の質問ではないために存在します。また「どのプロバイダーパスか、どのテナントか、どの予算か、どのレイテンシクラスか、そしてどのフォールバックか？」も必要です。LiteLLMは、その公式ドキュメントが爽快に具体的であるため有用です。重み付きピック、最も混雑していない、レイテンシベース、コストベースのルーティング、および有界フェイルオーバーはすべてファーストクラスのパターンです。OpenClawはルーティングをチャンネルとエージェントの分離へと上方に拡張し、Hermesはそれを要約、コンテキスト圧縮、MCPツールルーティングなどの主要および補助的な作業のためのモデルスロットへと下方に拡張します。これが正しいメンタルモデルです。ルーターはモデル以上のもの、つまり実行レーンを選択します。

可視性レイヤーは、アーキテクチャが伝説（folklore）に堕することを防ぐものです。OpenTelemetryはトレース抽象化を提供します。LangSmithはLLMアプリケーションステップに対するエンドツーエンドの可視性を提供し、クラウド、ハイブリッド、自己ホストデプロイメント形状をサポートします。OpenLITはゼロコードおよびマニュアルインストルメンテーションオプションを備えたOpenTelemetryネイティブのAI可視性を提供し、LLM、エージェントフレームワーク、ベクターデータベース、GPUのサポートを含みます。推論およびエージェントワークフロー全体における本番メトリクス、トレース、SLOパターンについては、Observability for LLM Systemsをご覧ください。もしアシスタントにリクエストごとのトレースがなく、モデル呼び出しごとのスパンがなく、ツール実行のイベント履歴がないなら、あなたはまだアーキテクチャを持っていません。あなたは「雰囲気（vibes）」を持っているだけです。

キャプチャ、 enrichment（強化）、レスポンス

実際のシステムで繰り返し現れるシーケンスは、キャプチャ -> 強化 -> レスポンス -> レコードです。異なるフレームワークはこれを異なる方法でラップしますが、フローは安定しており、バックボーンとして扱うのに十分です。

sequenceDiagram
    participant U as User or Channel
    participant G as Gateway or UI
    participant R as Router
    participant M as Memory and Retrieval
    participant L as LLM
    participant T as Tools or MCP
    participant O as Observability

    U->>G: message, file, or command
    G->>O: start root trace
    G->>R: request + identity + session + policy
    R->>M: load session state and retrieve context
    M-->>R: notes, chunks, metadata
    R->>L: prompt + context + tool schemas
    L-->>R: answer or tool call
    alt tool call
        R->>T: execute tool or MCP action
        T-->>R: tool result
        R->>L: tool result + updated context
        L-->>R: final answer
    end
    R->>M: persist session changes and memory candidates
    R->>O: spans, metrics, eval events
    G-->>U: response

キャプチャステップは、見た目よりも通常重要です。OpenClawとHermesの両方が、イングレス（ingress）は単なるテキスト入力ではないため、アシスタントの前に永続的なゲートウェイを配置しています。それはチャンネルメタデータ、アイデンティティ、認可、セッション境界、ダイレクトメッセージ、グループ、cronティック、および配信セマンティクスを含みます。このレイヤーをスキップして生（raw）のチャットウィジェット抽象化に依存すると、最終的にはアドホックなミドルウェアとしてそれを再び取り付けることになります。

強化ステップは、成熟したシステムがトイデモと分かれる場所です。OpenAI RetrievalおよびFile Searchは、ベクターストアと検索呼び出しを通じて検索を明示的に行います。LlamaIndexはデータコネクタ、インデックス、クエリエンジン、ワークフローを通じて同じパターンを形式化します。Hermesは、モデルエーステ（estate）を主要および補助スロットに分割し、圧縮、要約、ルーティングなどの作業をより小さいまたは専門的なモデルにオフロードすることでさらに進みます。これは盗む価値のあるデザインパターンです。最も高価なモデルトークンを雑用に費やさないことです。

レスポンスステップは「テキストを生成する」ことではありません。「現在のループを閉じる」ことです。モデルが直接回答できる場合、そうします。ツールが必要であれば、構造化されたリクエストを出力します。Anthropicのツール使用契約とOpenAIの関数呼び出しガイドの両方が、これを明示的にしています。これがアーキテクチャ的に重要である理由は、出力が今や言語と制御フローの両方を含むためです。レスポンスオブジェクトは一部が散文、一部がランタイムプランです。

レコードステップは、一貫性セマンティクスが現れる場所です。Pineconeは書き込みと読み取りパスを分離し、永続的な acknowledgements（受信確認）の後に書き込みを処理します。Hermesメモリはセッションごとにフリーズされたスナップショットとして注入されるため、プレフィックスキャッシュパフォーマンスを保持でき、これは新しい書き込みが現在のセッションプロンプトに自動的に現れないことを意味します。OpenClawのDreamingシステムは、レビュー済みの、根拠のある候補のみをMEMORY.mdにプロモートし、それはオプトインであり、常時オンではありません。実用的な教訓は、メモリがレイヤー間で真にread-after-write（書き込み後読み取り）になることは稀だということです。段階的な可視性のために設計する必要があります。

OpenClawとHermesを参照システムとして

OpenClawとHermesは、単なる1つのプロバイダーAPIのラッパーではないため、有用な参照ケースです。両方とも、ゲートウェイ、セッション、ツール、メモリ、複数のモデルバックエンドを備えた長寿命システムとしてアシスタントを提示します。

このマッピングは、公式のOpenClawおよびHermesドキュメントとリポジトリに基づいています。OpenClawはゲートウェイアーキテクチャ、マルチエージェントルーティング、vLLMおよびOllamaを含むカスタムおよび自己ホストプロバイダーサポート、オプションのアクティブメモリ、Dreamingベースのプロモーションを文書化しています。Hermesはメッセージングゲートウェイ、中央のAIAgentループ、主要および補助モデルスロット、ビルトインメモリ、ネイティブMCP統合を文書化しています。

私のやや意見的な解釈は、両システムが異なるアクセントで同じアーキテクチャ論を展開しているというものです。OpenClawは強くゲートウェイファーストです。Hermesは強くエージェントループファーストです。しかし、両方とも「アシスタントは単にプロンプトとモデルである」という浅いアイデアを拒絶します。それらはチャンネル、アイデンティティ、メモリセマンティクス、ツールサーフェス、バックエンドの多様性をファーストクラスの懸念事項としてモデル化します。これは本番アーキテクチャがすべきことそのものです。

両システムにインスパイアされた実用的なハイブリッドスタックは以下のようになります。

edge:
  gateway: hermes or openclaw

routing:
  proxy: litellm
  policy: latency and budget aware
  tenancy: session and channel scoped

llm:
  primary: openai responses or anthropic messages
  local_fallback: vllm
  local_dev: ollama or llama.cpp

memory:
  session: sqlite or postgres
  semantic: pgvector or weaviate
  embeddings: openai embeddings or ollama embeddings

tools:
  contract: json schema tools plus mcp
  examples: filesystem, browser, web search, internal APIs

observability:
  traces: opentelemetry
  ai_dashboards: openlit or langsmith
  evals: openai evals plus app-specific regression sets

このスタックは、ベンダーが規定したブループリントではなく、理にかなったデプロイメントパターンです。それは公式インターフェースが整っているため機能します。OpenAIとAnthropicはツール指向のAPIを公開し、vLLMとllama.cppはプロバイダースタイルのエンドポイントをエミュレートし、Ollamaはローカルモデルとエンベディングを処理し、MCPは外部ツールを標準化し、LiteLLMはルーティングとフェイルオーバーを処理し、OpenTelemetry互換プラットフォームは全体のパスをトレースできます。

パターン、テーブル、およびトレードオフ

名前付ける価値のある繰り返し現れるアシスタントパターンがいくつかあります。**Managed assistant（管理型アシスタント）**は、ランタイムの大部分をプロバイダーAPI内に保持します。**Retrieval-first assistant（検索ファーストアシスタント）**は、メモリと検索を主要な差別化要素とします。**Tool-first assistant（ツールファーストアシスタント）**はチャットボットよりもオペレーターのように振る舞います。**Gateway assistant（ゲートウェイアシスタント）**は、メッセージングサーフェスを通じた常時接続アクセスを優先します。**Specialist mesh（専門家メッシュ）**は作業を複数のエージェントまたはルートに分解します。OpenAI、Anthropic、LlamaIndex、LiteLLM、OpenClaw、Hermes全体の公式ドキュメントは、これらのパターンのバージョンをサポートしています。それらが異なる名前を使用している場合でもです。

このパターンテーブルは、プロバイダードキュメント、フレームワークドキュメント、参照システムからの合成であり、どの1つのベンダーからの主張ではありません。

テーブル注記：OpenAIホストFile Searchは管理型ツールであり、Anthropicは管理型ハーネスを提供し、Pineconeは管理型ベクターサービスです。一方、vLLM、llama.cpp、Ollama、pgvector、Weaviate、Milvus、LangSmith自己ホスト、OpenLITは、それぞれ異なる程度で自己管理またはハイブリッド運用をサポートします。

テーブル注記：Pineconeは管理型コントロールプレーンとリージョナルデータプレーンを文書化しています。Weaviateはベクターおよび逆インデックスと複数のベクターインデックスタイプを文書化しています。pgvectorはPostgresに正確および近似最近傍検索を追加します。Milvusはオープンソースの高性能、スケーラブルベクターデータベースと位置づけ、Zilliz Cloudを管理型オプションとしています。

テーブル注記：OpenAIはResponsesをステートフルレスポンスおよびビルトインツールのための高度なインターフェースとして文書化しています。AnthropicはMessages APIとツール使用契約をManaged Agentsとは別に文書化しています。vLLMはOpenAI互換サーバーおよびAnthropic Messages APIサポートを公開します。Ollamaはローカルエンベディングおよびモデルワークフローを文書化しています。llama.cppはOpenAI互換チャット、レスポンス、エンベディングルート、およびAnthropic互換チャット完遂を文書化しています。

このトレードオフマトリクスは公式ドキュメントからのアーキテクチャ的推論であり、ベンチマークではありません。一貫性の行は多くのブログ記事が認めるよりも重要です。Pineconeは書き込みと読み取りパスを分離し、Hermesはメモリをセッション開始プロンプトにフリーズし、OpenClawは段階的なレビューを通じて永続メモリをプロモートします。それは、「メモリが更新された」と「現在の回答にメモリが可視である」はしばしば異なる真実であることを意味します。

失敗モードと緩和策

大多数のアシスタントは、ベースモデルが「悪い」ために失敗するのではありません。それらは、周囲のシステムがモデルに嘘をつき、適切なコンテキストを切り落とし、ツールが逸脱することを許し、またはデバッグを不可能にするために失敗します。

このテーブルのエビデンスベースは広大但是一貫しています。Anthropicのツールドキュメントは、ツール使用が契約の境界であることを明確にしています。OpenAI GuardrailsはFile Searchを介したリファレンスナレッジベースに対するハルシネーション検出を含みます。SelfCheckGPTは、サンプル間の自己整合性が根拠のない主張の検出に役立つことを示しています。「Lost in the Middle」の結果とAnthropicのコンテキストガイダンスの両方が、同じ運用上の教訓を強化しています。より多くのトークンはコンテキストキュレーションの必要性を除去しません。

推奨される緩和スタックは退屈で反復的かもしれません。各リクエストをトレースし、プロンプトをバージョン管理し、検索を独立して評価し、ツールを冪等にし、ルートまたはメモリポリシーを変更する前に回帰評価を実行します。OpenAIのEvalsドキュメントとリポジトリは、なぜそれが重要かについて率直です。評価なしでは、モデルまたはプロンプトの変更が使用ケースにどのように影響するかを理解するのは困難で時間がかかります。それはプロンプトと同様に、ルーティングや検索にも当てはまります。

さらに読む

深く掘り下げたい場合、アシスタントアーキテクチャを設計またはレビューする際に開いておくべき最も有用な一次情報源があります。

• OpenAI: Responses Overview、Function Calling、Using Tools、Retrieval、File Search、Evals、およびリモートツールサーバーのためのMCP。

• Anthropic: API Overview、Tool Use、ツール使用契約、Managed Agents、Context Windows、およびMCPコネクタ。

• MCP自体: Architecture OverviewおよびSpecificationは直接読む価値があります。それらはホスト、クライアント、サーバー、ツール、プロンプト、リソース、トランスポート、および能力ネゴシエーションを明確に説明しているため。

• フレームワークとルーティング: LangChain Overview、LlamaIndexのコンテキスト拡張ドキュメント、LiteLLMルーティングドキュメント、LangSmith可視性ドキュメント。

• 自己ホストランタイムとアシスタントシステム: vLLM、llama.cppサーバー、Ollamaエンベディング、OpenClawドキュメントおよびリポジトリ、Hermesドキュメントおよびリポジトリ。

• ストレージと可視性: Pinecone、Weaviate、pgvector、Milvus、OpenTelemetry、OpenLIT。

• 研究論文: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks、Lost in the Middle、およびSelfCheckGPT。