AIシステム：セルフホスト型アシスタント、RAG、およびローカルインフラストラクチャ

目次

地元のAIセットアップの多くは、モデルとランタイムから始まります。

量子化されたモデルをダウンロードし、Ollamaや他のランタイムを通じて起動し、プロンプトを入力し始めます。実験段階では、これだけで十分です。しかし、好奇心の段階を超え、メモリ、取得の質、ルーティングの決定、またはコスト意識を重視し始めると、そのシンプルさが限界を示し始めます。

このクラスターは異なるアプローチを探求します。AIアシスタントを単一のモデル呼び出しではなく、協調されたシステムとして扱うことです。

この区別は最初は微妙に思えるかもしれませんが、ローカルAIの考え方を根本から変えます。

ローカルLLM、RAG、メモリレイヤーによるAIシステムのオーケストレーション

AIシステムとは何か

AIシステムは単なるモデル以上のものです。推論、取得、メモリ、実行を接続し、一貫したアシスタントのように振る舞うものへと統合するオーケストレーションレイヤーです。

モデルをローカルで実行することはインフラストラクチャ作業です。そのモデルを中心にアシスタントを設計することはシステム作業です。

以下の包括的なガイドを探索したことがあるなら：

推論はスタックの単一レイヤーに過ぎないことをすでにご存知でしょう。

AIシステムクラスターはこれらのレイヤーの上に構築されます。それらを置き換えるのではなく、組み合わせます。

プロダクションアシスタントにおいて、LLM、メモリ、ツール、ルーティング、可観測性がどのように連携するかの横断的なマップについては、OpenClawとHermesを参考システムとしてAIアシスタントアーキテクチャ：LLM、メモリ、ツール、ルーティング、可観測性をご覧ください。

アシスタントのアーキテクチャが確立されたら、次のステップはそれを能動的にすることです。AIアシスタントにおけるポーリングエージェント：11の実装パターンは、バックグラウンドポーリングワーカー、キューベースの実行、永続ワークフロー、およびセマンティックLLM評価器が、反応的なアシスタントを監視し、決定し、自律的に行動するものへとどのように変えるかを説明しています。

単一のアシスタントでは不十分で、複数のエージェントが調整を必要とする場合、調整パターンの選択がすべてを決定します：レイテンシ、フォールトトレランス、コスト、およびデバッグ可能性。マルチエージェントオーケストレーションパターン：実用ガイドは、オーケストレーター-ワーカー、シーケンシャルパイプライン、ファノアウ、階層型、スウォーム、メッシュという6つの標準的なパターン、特定の失敗モード、および適切なアーキテクチャを選択するための意思決定フレームワークをカバーしています。

OpenClaw：セルフホスト型AIアシスタントシステム

OpenClawは、オープンソースでセルフホストされたAIアシスタントであり、ローカルインフラストラクチャ上で実行されながらメッセージングプラットフォーム全体で動作するように設計されています。

実践的なレベルでは、以下を行います：

  • OllamaやvLLMなどのローカルLLMランタイムを使用します
  • インデックス付きドキュメント上の取得を統合します
  • セッションを超えてメモリを維持します
  • ツールと自動化タスクを実行します
  • 計装および監視可能です
  • ハードウェア制約内で動作します

これは単なるモデルのラッパーではありません。推論、取得、メモリ、実行を接続し、一貫したアシスタントのように振る舞うものへと統合するオーケストレーションレイヤーです。

開始とアーキテクチャ：

文脈と分析：

OpenClawの拡張と構成：

プラグインはOpenClawランタイムを拡張し、メモリバックエンド、モデルプロバイダ、コミュニケーションチャネル、Webツール、および可観測性を追加します。スキルはエージェントの振る舞いを拡張し、エージェントがそれらの機能を使用する方法とタイミングを定義します。プロダクション構成は、実際にシステムを使用している人に合わせて形成された両方を組み合わせることを意味します。

Hermes：スキルとツールサンドボックスを備えた永続的エージェント

Hermes Agentは、永続的な動作に焦点を当てたセルフホスト型でモデル非依存のアシスタントです：長寿命のプロセスとして実行し、構成可能なバックエンドを通じてツールを実行し、メモリと再利用可能なスキルを通じてワークフローを時間とともに改善できます。

実践的なレベルでは、Hermesは以下を望む場合に有用です：

  • メッセージングアプリにも橋渡しできるターミナルファーストのアシスタント
  • OpenAI互換エンドポイントとモデル切り替えによるプロバイダ柔軟性
  • ローカルおよびサンドボックス化されたバックエンドによるツール実行境界
  • 診断、ログ、および構成衛生を備えたデー2運用

Hermesプロファイルは完全に隔離された環境です — 各々に独自の構成、シークレット、メモリ、セッション、スキル、および状態を備え、プロファイルが個々のスキルではなく実際のプロダクション所有の単位となります。

永続的知識とメモリ

一部の課題は、より大きなコンテキストウィンドウだけでは解決されません — それらは永続的知識（グラフ、インジェストパイプライン）と、HermesやOpenClawなどのアシスタントに接続されたエージェントメモリプラグイン（Honcho、Mem0、Hindsight、および同様のバックエンド）を必要とします。

MCP：Model Context Protocolサーバー

Model Context Protocol（MCP）は、Anthropicによって導入されたオープン標準であり、AI言語モデルを外部データソース、ツール、およびシステムに接続するためのものです。それはN×M統合問題を普遍的なインターフェースによって解決します — AIアプリケーションのためのUSB-Cポートと考えることができます。MCPサーバーを構築することで、ファイル、データベース、API、および呼び出し可能なツールのためのカスタム統合を、stdioまたはHTTP上のシンプルなJSON-RPCベースのプロトコルを使用してAIアシスタントに拡張できます。

  • GoにおけるMCPサーバー — プロトコルアーキテクチャ、JSON-RPCメッセージ構造、能力ネゴシエーション、公式Go SDK、およびGoでMCPサーバーを構築するためのステップバイステップチュートリアル
  • PythonにおけるMCPサーバーの構築 — Web検索およびスクレイピングMCPサーバー、stdioおよびSSEトランスポート、およびClaudeデスクトップ統合をカバーする実践的なPython実装ガイド

A2A：Agent-to-Agent Protocol

Agent2Agent Protocol（A2A）は、独立してデプロイされたAIエージェントシステム間の通信のためのオープン標準です。MCPがエージェントをツールに接続するのに対し、A2Aはエージェントを他のエージェントに接続し、Agent Cardsを介して互いを発見し、タスクとメッセージを交換し、進捗をストリーミングし、型付きアーティファクトを返すことを可能にします。A2Aは、エージェントが異なるチームによって所有され、異なるフレームワークで構築され、または相互運用を必要とする個別のサービスとしてデプロイされるシステムのために設計されています。

AIシステムを特別にするもの

AIシステムをより詳しく検討する価値のあるいくつかの特性があります。

モデルルーティングを設計選択として

大多数のローカルセットアップはデフォルトで1つのモデルを使用します。AIシステムはモデルを意図的に選択することをサポートします。

これにより以下の問いが生じます：

  • 小さなリクエストはより小さなモデルを使用すべきか？
  • 推論がより大きなコンテキストウィンドンを正当化するのはいつか？
  • 1,000トークンあたりのコスト差は何ですか？

これらの問いは、LLMパフォーマンスガイドで議論されたパフォーマンストレードオフおよびLLMホスティングガイドに概説されたインフラストラクチャ決定に直接関連します。

AIシステムはそれらの決定を隠すのではなく、表面化します。

取得は進化するコンポーネントとして扱われる

AIシステムはドキュメント取得を統合しますが、シンプルな「埋め込みと検索」ステップとしてではありません。

それらは以下を認めます：

  • チャンクサイズは再現性とコストに影響します
  • ハイブリッド検索（BM25 + ベクトル）は純粋な密集取得を超回る可能性があります
  • リランキングはレイテンシのコストで関連性を向上させます
  • インデックス戦略はメモリ消費に影響します

これらのテーマは、RAGチュートリアルで議論された深いアーキテクチャ的考慮事項と一致します。

違いは、AIシステムが取得を孤立したデモとして提示するのではなく、生きているアシスタントに埋め込むことです。

メモリとしてのインフラストラクチャ

ステートレスなLLMはセッション間ですべてを忘れます。

AIシステムは永続的メモリレイヤーを導入します。これによりすぐに設計上の問いが生じます：

  • 何を長期的に保存すべきか？
  • コンテキストを要約すべきはいつか？
  • トークン爆発を防ぐ方法は？
  • メモリを効率的にインデックスする方法は？

これらの問いは、データインフラストラクチャガイドからのデータレイヤーの考慮事項と直接交差します。Hermes Agentについては特に — 境界付き2ファイルメモリ、プリフィックスキャッシング、外部プラグイン — Hermes Agentメモリシステムおよびクロスフレームワーク比較エージェントメモリプロバイダの比較から始めます。AIシステムメモリハブは関連するCogneeおよび知識レイヤーガイドをリストします。

メモリは機能からストレージ問題へと変化します。

可観測性はオプションではない

大多数のローカルAI実験は「応答する」で止まります。

AIシステムは以下を観察可能にします：

  • トークン使用量
  • レイテンシ
  • ハードウェア利用
  • スループットパターン

これは、可観測性ガイドで説明された監視原則と自然に接続します。

AIがハードウェア上で実行されるなら、他のワークロードと同様に測定可能であるべきです。

使用感

外側から、AIシステムはまだチャットインターフェースのように見えるかもしれません。

表面の下では、より多くのことが起こります。

ローカルに保存された技術レポートの要約を依頼した場合：

  1. 関連するドキュメントセグメントを取得します。
  2. 適切なモデルを選択します。
  3. 応答を生成します。
  4. トークン使用量とレイテンシを記録します。
  5. 必要に応じて永続的メモリを更新します。

見える相互作用はシンプルです。システム振る舞いは層状です。

この層状振る舞いが、システムとデモを区別します。

スタックにおけるAIシステムの位置

AIシステムクラスターは、いくつかのインフラストラクチャレイヤーの交差点に位置します：

  • LLMホスティング：モデルが実行されるランタイムレイヤー（Ollama、vLLM、llama.cpp）
  • RAG：コンテキストとグラウンディングを提供する取得レイヤー
  • パフォーマンス：レイテンシとスループットを追跡する測定レイヤー
  • 可観測性：メトリクスとコスト追跡を提供する監視レイヤー
  • データインフラストラクチャ：メモリとインデックスを処理するストレージレイヤー

この区別を理解することは有用です。それ自体を実行することで、違いがより明確になります。

OpenClawのための最小限のローカルインストールについては、OpenClawクイックスタートガイドをご覧ください。これは、ローカルのOllamaモデルまたはクラウドベースのClaude設定のいずれかを使用したDockerベースのセットアップを案内します。

セットアップがClaudeに依存する場合、エージェントツールのためのこのポリシー変更は、なぜサードパーティOpenClawワークフローのためにAPI課金が必要になったかを明確にします。

関連リソース

A2A：Agent-to-Agent Protocol：

MCPサーバー：

AIアシスタントガイド：

インフラストラクチャレイヤー：

購読する

システム、インフラ、AIエンジニアリングの新記事をお届けします。