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

目次

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

量子化モデルをダウンロードし、Ollamaまたは他のランタイム経由で起動して、プロンプトを入力し始めます。実験的には、これで十分です。しかし、好奇心の域を超え、メモリ、検索の質、ルーティングの決定、またはコスト意識を重視するようになると、そのシンプルさの限界が現れてきます。

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

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

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

AIシステムとは何か

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

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

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

推論がスタックの単一レイヤーに過ぎないことをすでに知っています。

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

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

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

実用的な観点から、OpenClawは以下を行います：

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

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

開始とアーキテクチャ：

文脈と分析：

OpenClawの拡張と構成：

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

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

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

実用的な観点から、Hermesは以下を望む場合に有用です：

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

Hermesプロファイルは完全に隔離された環境です — それぞれに独自の構成、シークレット、メモリ、セッション、スキル、ステートを備えており、プロファイルが個別のスキルではなく、本番環境所有の真の単位となります。

持続的知識とメモリ

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

AIシステムを特徴づけるもの

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

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

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

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

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

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

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

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

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

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

  • チャンクサイズは再現性とコストに影響する
  • ハイブリッド検索（BM25 + ベクトル）は純粋な密集検索を凌駕する可能性がある
  • リランキングはレイテンシのコストをかけて関連性を向上させる
  • インデックス化戦略はメモリ消費に影響する

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

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

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

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

AIシステムは持続的メモリレイヤーを導入します。これにより、すぐに設計上の質問が生じます：

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

これらの質問は、データインフラストラクチャガイドのデータレイヤーの考慮事項と直接交差します。Hermesエージェントに特化して — 有界の2ファイルメモリ、プレフィックスキャッシング、外部プラグイン — Hermesエージェントメモリシステムおよびクロスフレームワーク比較エージェントメモリプロバイダーの比較から始めます。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課金が必要になったかを明確にします。

関連リソース

AIアシスタントガイド：

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

購読する

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