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

目次

ローカルAI環境の構築は、モデルとランタイムから始まります。

量子化モデルをダウンロードし、Ollamaなどのランタイムで起動し、プロンプトを入力するところから始めます。実験段階であれば、これだけで十分です。しかし、好奇心を超え、メモリ管理、検索の質、ルーティングの決定、コスト意識などが重要になってくると、そのシンプルさが限界を露呈し始めます。

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

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

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

AIシステムとは何か

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

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

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

推論がスタックの単なる一層であることがすでに分かっているはずです。

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

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

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

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

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

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

始め方とアーキテクチャ：

文脈と分析：

OpenClawの拡張と設定：

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

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

Hermesエージェントは、永続的な運用に焦点を当てたセルフホスト型でモデルに依存しないアシスタントです。長寿命のプロセスとして実行し、設定可能なバックエンドを介してツールを実行し、メモリと再利用可能なスキルによってワークフローを時間とともに改善できます。

実践的なレベルでは、Hermesは以下のことを望む際に有用です：

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

Hermesプロファイルは完全に隔離された環境です — 各自に固有の設定、シークレット、メモリ、セッション、スキル、状態を持ち、プロファイルこそが本番環境における所有権の真の単位であり、個々のスキルではありません。

AIシステムの違いは何か

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

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

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

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

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

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

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

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

AIシステムは文書検索を統合しますが、単純な「埋め込みと検索」ステップとしてではありません。

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

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

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

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

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

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

AIシステムは永続的なメモリ層を導入します。それによって直ちに設計上の問いが生じます：

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

これらの問いは、データインフラストラクチャガイドからのデータ層の考慮事項と直接交差します。Hermesエージェントがそれらをどのように解決するか — バウンドされた2ファイルメモリ、プレフィックスキャッシング、8つの外部プロバイダオプション — についての具体的な答えについては、Hermesエージェントのメモリシステムを参照してください。

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

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

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

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

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

これは、可観測性ガイドで説明されたモニタリング原則と自然につながります。

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

使うとどう感じるか

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

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

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

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

見える相互作用はシンプルに保たれます。システム動作は層状です。

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

AIシステムがスタックの中でどこに位置するか

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

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

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

OpenClawによる最小限のローカルインストールについては、ローカルのOllamaモデルまたはクラウドベースのClaude設定を使用するDockerベースのセットアップを解説するOpenClawクイックスタートガイドを参照してください。

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

関連リソース

AIアシスタントガイド：

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

購読する

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