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

目次

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

量子化モデルをダウンロードし、Ollamaなどのランタイムを通じて起動してプロンプトを打ち出します。実験目的であれば、これで十分なことが多いでしょう。しかし、好奇心を超えて、メモリ、検索品質、ルーティング判断、コスト意識を気にし始めると、そのシンプルさが限界を示し始めます。

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

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

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

AIシステムとは何か

AIシステムは、単なるモデルよりも多くの要素から成り立っています。推論、検索、メモリ、実行を接続するオーケストレーションレイヤーであり、一貫したアシスタントのように動作するものです。

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

以下のより幅広いガイドを閲覧された場合:

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

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

本番のアシスタントにおいて、LLM、メモリ、ツール、ルーティング、可観測性がどのように組み合わされるかの包括的なマップについては — OpenClawとHermesを参照システムとして紹介 — AIアシスタントアーキテクチャ: LLM、メモリ、ツール、ルーティング、可観測性 をご覧ください。

アシスタントのアーキテクチャが確立した後、次のステップはそれを能動的なものにすることです。AIアシスタントにおけるポーリングエージェント: 11の実装パターン は、バックグラウンドポーリングワーカー、キューベースの実行、永続ワークフロー、セマンティックなLLM評価子が、リアクティブなアシスタントを、監視し、判断し、自ら行動するものにどう変化させるかを扱います。

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

より多くの自律性を付与する前に、エージェントがそもそもどのような判断を許可されるべきかを確認する価値があります。意思決定LLM: モデルが判断すべき時と、そうでない時 は、モデルの判断とシステムの権限を分離します: 5つの意思決定役割、各判断を最も適した最小のティアにルーティング、そしてモデルの呼び出しを事後に監査可能にする意思決定ストア、不変条件、ブラスグローブゲートです。

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

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

実用的なレベルでは、OpenClawは:

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

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

導入とアーキテクチャ:

コンテキストと分析:

OpenClaw の拡張と設定:

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

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

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

実用的なレベルでは、Hermesは以下を望む場合に有用です:

  • メッセージングアプリへのブリッジも可能なターミナルファーストのアシスタント
  • OpenAI互換エンドポイントとモデル切り替えによるプロバイダの柔軟性
  • ローカルおよびサンドボックス化されたバックエンドによるツール実行境界
  • 診断、ログ、設定衛生を含むDay-2運用

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はエージェントを他のエージェントに接続します — エージェントカードを通じて互いを見つけ出し、タスクとメッセージを交換し、進捗をストリーミングし、型付き成果物を返すことを可能にします。A2Aは、エージェントが異なるチームによって所有され、異なるフレームワークで構築され、または互操作性を必要とする個別サービスとしてデプロイされるシステムのために設計されています。

AIシステムを特別なものにしているもの

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

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

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

これは以下の問いを導入します:

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

これらの問いは、LLMパフォーマンスガイド で議論されるパフォーマンスのトレードオフと、LLMホスティングガイド に示されるインフラストラクチャ決定と直接的につながります。

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

検索を進化するコンポーネントとして扱う

AIシステムは文書検索を統合しますが、シンプルな「埋め込みと検索」ステップとしてではなく。

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

  • チャンクサイズがリコールとコストに影響する
  • ハイブリッド検索 (BM25 + ベクトル) は純粋な密検索を上回る可能性がある
  • リランキングは関連性を改善するが、レイテンシの代償がある
  • インデックス戦略がメモリ消費量に影響する

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

違いは、AIシステムが検索を孤立したデモとして提示するのではなく、生きているアシスタントに埋め込むことです。Deep Researchはその考えを最も遠くまで推し進めます: 単一の検索パスではなく、システムは計画し、分岐し、再確認し、証拠が十分になるまで反復します。セルフホストDeep Researchシステム: 12ツールの比較 は、12のセルフホストシステム — 再帰的研究ツリー、プランナープラスサブエージェント設計、証拠ギャップループを含む — およびそれぞれがどのように検索を適応的研究ループに変えるかを歩みます。

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

ステートレスな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ワークフローでは désormais API課金が必要となったかを明確にしています。

関連リソース

A2A: Agent-to-Agent Protocol:

MCPサーバー:

比較:

AIアシスタントガイド:

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

購読する

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