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

目次

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

量子化されたモデルをダウンロードし、Ollama や他のランタイムで起動して、プロンプトを入力します。実験的な用途であれば、これだけで十分です。しかし、好奇心を越えて、メモリ、取得の質、ルーティングの判断、コストへの意識が重要になってくると、その単純さが限界を示し始めます。

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

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

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

AI システムとは何ですか？

AI システムは単なるモデルではありません。推論、取得、メモリ、実行を結びつけ、一貫したアシスタントとして振る舞うオーケストレーション層です。

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

以下のガイドをすでに見ているなら、推論がスタックの単一の層に過ぎないことはご存知でしょう。

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

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

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

実用的なレベルでは、OpenClaw は以下のことを行います。

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

これは単なるモデルのラッパーではありません。推論、取得、メモリ、実行を結びつけ、一貫したアシスタントとして振る舞うオーケストレーション層です。

開始とアーキテクチャ:

OpenClaw の拡張と設定:

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

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

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

実用的なレベルでは、Hermes は以下を望む際に役立ちます。

  • メッセージングアプリにもブリッジできるターミルファーストのアシスタント
  • OpenAI 互換エンドポイントとモデル切り替えによるプロバイダーの柔軟性
  • ローカルとサンドボックス化されたバックエンドを通じたツール実行の境界線
  • 診断、ログ、設定の衛生管理を備えた 2 日目（Day-two）の運用

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

AI システムを異なる点にする要素

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

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

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

それにより、以下の質問が生まれます。

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

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

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

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

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

それらは以下を認識します。

  • チャンクサイズは想起とコストに影響する
  • ハイブリッド検索（BM25 + ベクトル）は純粋な高密度取得よりも優れている可能性がある
  • リランキングは遅延のコストに関わらず関連性を向上させる
  • インデックス戦略はメモリ消費に影響する

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

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

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

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

AI システムは永続的なメモリ層を導入します。それは直ちに設計上の質問を提起します。

  • 長期的に何を保存すべきか？
  • 文脈を要約すべきなのはいつか？
  • トークン爆発を防ぐにはどうするか？
  • メモリを効率的にインデックス化するにはどうするか？

これらの質問は、データインフラストラクチャガイド のデータ層の考慮事項と直接交差します。

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

観測性は省略不可能

ほとんどのローカル 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 課金が必要になった理由を明確にします。

関連リソース

AI アシスタントガイド:

インフラストラクチャ層: