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

目次

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

量子化されたモデルをダウンロードし、Ollama或其他のランタイムを介して起動し、プロンプト入力を開始します。実験段階であれば、これだけで十分です。しかし、好奇心の域を超えて、メモリ、検索品質、ルーティングの判断、コストの認識などを気にし始めると、そのシンプルさには限界が生じ始めます。

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

この区別は最初は微細に思えますが、ローカルAIに対する思考方法を根本から変えます。

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

AIシステムとは何か？

AIシステムは単なるモデルではありません。それは、推論、検索、メモリ、実行を繋ぎ合わせ、一貫性のあるアシスタントのように振る舞う何かになるためのオーケストレーション層です。

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

以下の私たちのより広範なガイドを探索したことがあるなら：

既に推論はスタックの1つの層に過ぎないことを知っています。

AIシステムクラスタは、それらの層の上に位置しています。それらを置き換えるのではなく、それらを組み合わせます。

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

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

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

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

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

実務的なレベルでは、OpenClawは：

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

これは単なるモデルのラッパーではありません。それは、推論、検索、メモリ、実行を繋ぎ合わせ、一貫性のあるアシスタントのように振る舞う何かになるためのオーケストレーション層です。

導入とアーキテクチャ：

コンテキストと分析：

OpenClawの拡張と設定：

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

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

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

実務的なレベルでは、Hermesは以下を望むときに有用です：

  • メッセージングアプリにブリッジすることもできるターミナルファーストのアシスタント
  • OpenAI互換エンドポイントとモデルスイッチングによるプロバイダーの柔軟性
  • ローカルとサンドボックス化されたバックエンドによるツール実行の境界
  • 診断、ログ、設定衛生状態管理によるデイトーオペレーション

Hermesプロファイルは完全に分離された環境です — 各々が独自の設定、シークレット、メモリ、セッション、スキル、状態を持ち、プロファイルが実際のプロダクション所有の単位であり、個別のスキルではないことを意味します。

永続知識とメモリ

いくつかの問題は、単にコンテキストウィンドウを大きくするだけでは解決しません — それらは永続知識（グラフ、インジェストパイプライン）と、HermesやOpenClawのようなアシスタントに組み込まれたエージェントメモリプラグイン（Honcho、Mem0、Hindsight、同様のバックエンド）を必要とします。

MCP：Model Context Protocolサーバー

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

  • エージェントスキル 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システムが検索を孤立したデモとして提示するのではなく、生きているアシスタントに組み込むという点です。

メモリはインフラストラクチャ

ステートレス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ベースのセットアップを歩きます。

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

関連リソース

A2A：Agent-to-Agent Protocol：

MCPサーバー：

AIアシスタントガイド：

インフラ層：

購読する

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