AIシステム：セルフホスト型アシスタント、RAG、ローカルインフラ

目次

ほとんどのローカルAIセットアップは、モデルとランタイムから始まります。

量子化されたモデルをダウンロードし、Ollamaなどのランタイムで起動して、プロンプトを入力し始めます。実験や検証のためであれば、これで十分でしょう。しかし、好奇心を超えて、メモリ、検索の品質、ルーティングの判断、コスト意識などを重要視し始めると、そのシンプルな構成には限界が見えてきます。

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

この違いは最初は些細に見えるかもしれませんが、ローカルAIに対する考え方を根本から変えます。

AI systems orchestration with local LLMs, RAG, and memory layers

AIシステムとは何か

AIシステムは、モデル以上のものです。推論、検索、メモリ、実行を接続し、一貫性のあるアシスタントのように動作するものを作るためのオーケストレーション層です。

ローカルでモデルを動かすことはインフラ構築作業です。そのモデルを軸にアシスタントを設計することは、システム設計作業です。

次のようなより広範なガイドを探索したことがある場合：

推論はスタックのレイヤーの一部にすぎないことがすでにわかっています。

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

本番環境のアシスタントにおいて、LLM、メモリ、ツール、ルーティング、オブザーバビリティといったレイヤーがどのように組み合わされるのかという横断的なマップについて — OpenClawとHermesを参照システムとして — は、AIアシスタントのアーキテクチャ：LLM、メモリ、ツール、ルーティング、オブザーバビリティ をご覧ください。

アシスタントのアーキテクチャが堅固になったら、次のステップは能動化（プロアクティブ化）です。AIアシスタントにおけるポーリングエージェント：11の実装パターン は、バックグラウンドポーリングワーカー、キューベースの実行、持続的ワークフロー、意味論ベースのLLM評価者が、受動的なアシスタントを監視し、判断し、自ら行動するものに変える方法を解説します。

単一のアシスタントでは不十分で、複数のエージェントが調整が必要な場合、協調パターンの選択がすべてを決定します：レイテンシ、フォールトトレランス、コスト、デバッガビリティ。マルチエージェントオーケストレーションパターン：実用的なガイド は、オーケストレーター-ワーカー、シーケンシャルパイプライン、ファンアウト、階層型、スウォーム、メッシュという6つの標準パターンを、具体的な障害モードと正しいアーキテクチャを選択するための意思決定フレームワークとともに解説します。

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

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

実用的なレベルで、OpenClawは以下のことをします：

  • OllamaやvLLMなどのローカルLLMランタイムを使用
  • 索引付けされたドキュメントからの検索を統合
  • 単一セッションを超えてメモリを維持
  • ツールや自動化タスクを実行
  • 計装（インストルメンテーション）と観測が可能
  • ハードウェア制約の内で動作

モデルまわりのラッパーに過ぎません。推論、検索、メモリ、実行を接続し、一貫性のあるアシスタントのように動作するものを作るためのオーケストレーション層です。

セットアップとアーキテクチャ：

背景と分析：

OpenClawの拡張と設定：

プラグインはOpenClawランタイムを拡張します — メモリバックエンド、モデルプロバイダー、通信チャネル、Webツール、オブザーバビリティを追加します。スキルはエージェントの動作を拡張します — エージェントがそれらの能力をいつ、どのように使用するかを定義します。本番環境設定とは、実際にシステムを使用している人に合わせて、両方を組み合わせることを意味します。

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

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

実用的なレベルで、Hermesが役立つのは、以下を望む場合です：

  • メッセージングアプリへのブリッジも可能なターミナルファーストのアシスタント
  • OpenAI互換エンドポイントとモデルスイッチングによるプロバイダーの柔軟性
  • ローカルおよびサンドボックス化されたバックエンドによるツール実行境界
  • 診断、ログ、設定衛生を備えたDay-2運用

Hermesのプロファイルは完全に分離された環境です — それぞれが独自の設定、シークレット、メモリ、セッション、スキル、状態を備えています — これにより、プロファイルは個々のスキルではなく、本番環境の所有の実際の単位となります。

永続的な知識とメモリ

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

MCP: Model Context Protocolサーバー

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

  • Agent Skills vs MCPサーバー：意思決定フレームワーク — いつスキルを使用し、いつMCPサーバーを構築し、薄いサーバーパターンがどのように両方を組み合わせるかの実践的な意思決定フレームワーク
  • GoでのMCPサーバー — プロトコルアーキテクチャ、JSON-RPCメッセージ構造、能力交渉、公式Go SDK、GoでMCPサーバーを構築するステップバイステップチュートリアル
  • PythonでのMCPサーバーの構築 — Web検索とスクレイピングMCPサーバー、stdioおよびSSEトランスポート、Claude Desktop統合をカバーする実践的な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システムが検索を孤立したデモとして提示するのではなく、生きたアシスタントに埋め込むという点です。Deep Researchはその考えを最も極めます：1回の検索パスではなく、システムが計画し、分岐し、再確認し、証拠が十分になるまで反復します。セルフホストDeep Researchシステム：12ツール比較 は、12のセルフホストシステム — 再帰的な研究ツリー、プランナー+サブエージェント設計、証拠ギャップループを含む — を walkthrough し、各々がどのように検索を適応型研究ループに変えるかを説明します。

メモリとしてのインフラ

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

AIシステムは永続的なメモリレイヤーを導入します。それはすぐに設計上の質問を提起します：

  • 何を長期に保存すべきか？
  • いつコンテキストを要約すべきか？
  • トークン爆発をどのように防ぐか？
  • メモリを効率的に索引付けするには？

これらの質問は、データインフラガイド のデータレイヤーの考慮事項と直接交差します。Hermes Agentにとって特に — 有界な2ファイルメモリ、プレフィックスキャッシュ、外部プラグイン — は、Hermes Agentメモリシステム とフレームワーク横断比較のエージェントメモリプロバイダー比較 から始めてください。自動キャプチャと反省も、モデル自身の推論を将来の「エビデンス」に変えることができます — 障害モードについては AIエージェントにおける自己強化メモリループ を、保守的なローカル実装については Hermes AgentのためのMnemosyne をご覧ください。AIシステムメモリハブ は、関連するCogneeや知識レイヤーガイドをリストしています。

メモリは機能ではなくなり、ストレージの問題になります。

オブザーバビリティはオプションではない

ほとんどのローカルAI実験は「反応する」で止まります。

AIシステムにより、以下を観測することが可能になります：

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

これは、オブザーバビリティガイド で説明された監視原則と自然に結びつきます。

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

使用感とは

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

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

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

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

見えるインタラクションはシンプルのままです。システムの動作は多層的です。

その多層的な動作こそが、システムをデモと区別するものです。

AIシステムがスタック内で占める位置

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

  • LLMホスティング：モデルが実行されるランタイムレイヤー（Ollama、vLLM、llama.cpp）
  • RAG：コンテキストとグラウンディングを提供する検索レイヤー
  • パフォーマンス：レイテンシとスループットを追跡する測定レイヤー
  • オブザーバビリティ：メトリクスとコスト追跡を提供する監視レイヤー
  • データインフラ：メモリと索引付けを処理するストレージレイヤー

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

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

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

関連リソース

A2A: Agent-to-Agent Protocol:

MCPサーバー:

比較:

AIアシスタントガイド:

インフラレイヤー:

購読する

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