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

目次

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

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

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

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

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

AIシステムとは何か

AIシステムとは、単なるモデル以上のものです。推論、検索、メモリ、実行を結びつけ、一貫したアシスタントのように振る舞う何かを生み出すオーケストレーションレイヤーです。

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

以下の広範なガイドを探索してきたなら：

推論がスタックの単一のレイヤーに過ぎないことをすでに理解しているはずです。

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

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

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

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

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

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

それは単なるモデルのラッパーではありません。推論、検索、メモリ、実行を結びつけ、一貫したアシスタントのように振る舞う何かを生み出すオーケストレーションレイヤーです。

開始方法とアーキテクチャ：

文脈と分析：

OpenClawの拡張と構成：

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

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

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

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

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

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

永続的知識とメモリ

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

MCP：モデルコンテキストプロトコルサーバー

モデルコンテキストプロトコル（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 Desktop統合をカバーする実用的なPython実装ガイド

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課金が現在必要とされる理由を明確にします。

関連リソース

MCPサーバー：

AIアシスタントガイド：

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

購読する

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