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

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

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

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

最もクリーンなアーキテクチャは、責任を5つのレイヤーに分割します：LLM、メモリ、ツール、ルーティング、そして可視性。この分割は、主要なプロバイダーの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はさらに一歩進み、それらの機能を永続的なゲートウェイ、チャネル、セッション、そしてメモリの背後に置いたときに何が起きるかを示しています。

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

AssistantRequest  = user intent + identity + session + attachments + policy
AssistantResponse = answer + actions + citations + state changes + trace 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は、すべてのメモリがベクトルストアにあるわけではないという有用なリマインダーを追加します：ファイル backed ノート、レビュー済みのプロモーション、セッションスコープのスナップショットは、しばしばより正直な設計です。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ツールルーティングのような主要および補助作業のためのモデルスロットへと下方に拡張します。それが正しいメンタルモデルです：ルーターはモデル以上を選びます。それは実行レーンを選びます。

可視性レイヤーは、アーキテクチャが民間伝承に変わるのを防ぐものです。OpenTelemetryはトレース抽象化を提供します。LangSmithはLLMアプリケーションステップ全体のエンドツーエンドの可視性を提供し、クラウド、ハイブリッド、セルフホストデプロイメント形状をサポートします。OpenLITは、LLM、エージェントフレームワーク、ベクトルデータベース、およびGPUのサポートを含む、ゼロコードおよび手動計装オプションを持つOpenTelemetryネイティブAI可視性を提供します。推論およびエージェントワークフロー全体の本番メトリクス、トレース、およびSLOパターンについては、Observability for LLM Systemsをご覧ください。アシスタントにリクエストごとのトレースがなければ、モデル呼び出しごとのスパンがなければ、そしてツール実行のためのイベント履歴がなければ、まだアーキテクチャを持っていません。バイブ（雰囲気）があるだけです。

キャプチャ、エンリッチ、レスポンス

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

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

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

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

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

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

OpenClawとHermesは、単一のプロバイダー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互換プラットフォームは全体をトレースできます。

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

いくつかの名前を付ける価値のある反復可能なアシスタントパターンがあります。マネージドアシスタントは、ランタイムの大部分をプロバイダーAPI内に保持します。リトリバルファーストアシスタントは、メモリと検索を主な差別化要因として扱います。ツールファーストアシスタントは、チャットボットよりもオペレーターのように振る舞います。ゲートウェイアシスタントは、メッセージングサーフェスを通じた常時アクセスを優先します。スペシャリストメッシュは、作業を複数のエージェントまたはルートに分解します。OpenAI、Anthropic、LlamaIndex、LiteLLM、OpenClaw、Hermesの公式ドキュメントは、それらを異なる名前で呼ぶ場合でも、これらのパターンのバージョンをサポートしています。

スペシャリストメッシュパターンは、エージェント数が増加するにつれて、明確な工学 discipline へと成長します。6つの規範的な協調パターン（オーケストレーター-ワーカー、シーケンシャルパイプライン、ファーンアウト、階層、スワーム、メッシュ）、特定の障害モード、および本番環境決定フレームワークについては、Multi-Agent Orchestration Patternsをご覧ください。

このパターンテーブルは、プロバイダードキュメント、フレームワークドキュメント、および参照システムからの合成であり、どの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は段階的なレビューを通じて永続メモリをプロモートします。それは「メモリが更新された」ことと「現在の回答に対してメモリが可視である」ことが、しばしば異なる真実であることを意味します。

障害モードおよび緩和

ほとんどのアシスタントは、ベースモデルが「悪い」ために失敗するわけではありません。それらは、周囲のシステムがモデルに嘘をつき、適切なコンテキストを starvation し、ツールを drift させる、またはデバッグを不可能にするために失敗します。

このテーブルの証拠ベースは広範囲ですが一貫しています。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は直接読む価値があります。なぜならそれらはホスト、クライアント、サーバー、ツール、プロンプト、リソース、トランスポート、および能力ネゴシエーションをクリーンに説明しているからです。MCPとAgent2Agentプロトコルの実用的な比較、およびマルチエージェントシステムが両方のレイヤーを必要とする時期については、A2A vs MCP: Do AI Agents Really Need Both Protocols?をご覧ください。そしてA2A概念自体（エージェントカード、タスクライフサイクル、メッセージ、パーツ、およびアーティファクト）については、What Is the A2A Protocol? Agent Cards and Tasks Explainedをご覧ください。

• バックグラウンドおよびプロアクティブアシスタント: ツールレイヤーはアシスタントが行動する方法の一部に過ぎません。アシスタントが監視し、決定し、独自に行動する方法（スケジューラー、キューベースワーカー、クレームプロトコル、永続ワークフロー、およびセマンティックポーリング）については、Polling Agents in AI Assistants: 11 Implementation Patternsをご覧ください。

• A2Aプロトコルおよび採用: エージェントが独立してデプロイされ、所有境界を超えて協働する必要が生じたとき、A2Aが関連性を持ちます。A2Aが実際に牽引力を持つ場所、それが引き起こすセキュリティ質問、およびそれを採用する時期の決定フレームワークの実用的な2026年の視点については、Google A2A Protocol in 2026: Adoption, Hype, and Realityをご覧ください。それらのエージェントが単一のチャットターンではなく長寿命タスクを交換するとき、A2A Streaming and Async Tasks for Long-Running Agent Workflowsはプロトコル境界でのSSE、プッシュ、およびinput_required設計をカバーします。

• フレームワークおよびルーティング: 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。