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

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

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

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  = ユーザー意図 + 識別子 + セッション + 添付ファイル + ポリシー
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は、すべてのメモリがベクトルストアにあるわけではないという有用なリマインダーを追加します。ファイルバックドノート、レビュー済みのプロモーション、およびセッションスコープのスナップショットは、しばしばより正直なデザインです——Hermes Agent Memory System で分解されているパターン——バウンデッドコアメモリおよび凍結されたセッションスナップショットのため。

ツールレイヤー は、アシスタントが要約機からソフトウェアへと変わる場所です。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 を参照してください。アシスタントにリクエストごとのトレースがなければ、モデル呼び出しごとのスパンがなければ、ツール実行のためのイベント履歴がなければ、あなたにはまだアーキテクチャがありません。あなたはバイブスを有しています。

捕捉、豊富化、応答

実際のシステムで繰り返し現れるシーケンスは、捕捉 -> 豊富化 -> 応答 -> 記録です。異なるフレームワークはそれを異なる方法でラップしますが、フローは安定しており、バックボーンとして扱うのに十分です。

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の両方が、イングレスがテキスト入力だけではないため、アシスタントの前に永続ゲートウェイを置きます。それはチャネルメタデータ、識別子、認証、セッション境界、ダイレクトメッセージ、グループ、クロンティック、および配信セマンティクスを含みます。そのレイヤーをスキップして生チャットウィジェット抽象化に依存する場合、結局はアドホックミドルウェアとしてそれを再び取り付けることになります。

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

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

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

参照システムとしての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互換プラットフォームは全体のパスをトレースできます。

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

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

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

テーブル注記: 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。