claraverse-space/ClaraVerse とは何ですか？

ClaraVerseはOllamaやLM Studioを自動検出し、チャット、マルチエージェントのCrew、知識ベースをセルフホストでまとめるTypeScript製のワークスペースだ。Docker Composeのサイドカー構成とAGPL-3.0の扱いを中心に、導入判断に必要な範囲を確認する。

claraverse-space/ClaraVerse は商用利用できますか？

まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。

claraverse-space/ClaraVerse は今もメンテナンスされていますか？

されています。最後のコミットは 43 日前です。

claraverse-space/ClaraVerse はどのプログラミング言語で書かれていますか？

主に TypeScript です（GitHub の言語統計による）。

ClaraVerse v0.3.1 レビュー: セルフホスト型AIワークスペースの構成と制約

ひと目でわかる

これは何？: ClaraVerseはOllamaやLM Studioを自動検出し、チャット、マルチエージェントのCrew、知識ベースをセルフホストでまとめるTypeScript製のワークスペースだ。Docker Composeのサイドカー構成とAGPL-3.0の扱いを中心に、導入判断に必要な範囲を確認する。
誰に向いている？: ローカルLLMをすでに動かしていて、チャットUIだけでなくエージェントのレビュー工程や知識ベースまで同じホストにまとめたい個人や小規模チームに向く。単一コンテナで試したいだけならKnowledgeタブとsearch_knowledgeツールが動かない点を先に受け入れる必要があり、MySQL、MongoDB、Redis、SearXNG、Qdrantを運用したくない場合はOpen WebUIのほうが構成は軽い。
商用利用できる？: まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
今もメンテナンスされている？: されています。最後のコミットは 43 日前です。
何の言語で書かれている？: 主に TypeScript です（GitHub の言語統計による）。

回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · claraverse-space/ClaraVerse

ClaraVerseが置き換えようとしているもの

READMEはClaraVerseを「プライベートAIワークスペース」と位置づけ、ChatGPT、Claude、N8N、ImageGenの代わりに自分のホストしたLLM、自分のキー、自分の計算資源を使う構成を掲げている。対象は、チャットUI、複数エージェントのチーム運用、ビジュアルなワークフロー作成、Telegram連携を別々のSaaSで契約している人だ。これらを1つのアプリにまとめ、OpenAI、Claude、Geminiに加えてOllamaやllama.cppのようなローカルモデルも同じ画面から使えるようにする。チャットは既定で端末上に保存され、複数マシンで共有したい場合のみ暗号化同期を使う。クラウド側に会話を預けたくないが、UIの使い勝手は落としたくない、という層を狙っている。

OllamaとLM Studioを2分ごとに探しに行く検出機構

READMEで最も具体的なのはローカルAIの自動検出だ。ClaraVerseはホスト側で動くプロバイダを定期的に探し、Ollamaは既定でhttp://host.docker.internal:11434、LM Studioはhttp://host.docker.internal:1234を見る。Ollamaはモデルをインポートしてプロバイダを作成し、可視状態まで設定する。LM StudioはOpenAI互換API経由でモデルを取り込む。検出は2分間隔で走り、プロバイダが落ちれば自動で無効化され、復帰すればモデルが再インポートされる。ここで引っかかるのがOllama側の待ち受け設定だ。Ollamaは127.0.0.1で待つためDockerコンテナから到達できず、OLLAMA_HOST=0.0.0.0を設定する必要があるとREADMEは明記している。systemdならsystemctl edit ollamaでEnvironment行を足して再起動する手順が示されている。自動検出という言葉からゼロ設定を想像すると、この1点でつまずく。

単一コンテナではKnowledgeタブが動かない

docker runの単一コンテナ例はポート3000、ボリューム2つ、host.docker.internalへのadd-hostだけで起動する。ただしREADMEは、この構成ではMySQL、MongoDB、Redis、SearXNG、Qdrant、embeddingsサイドカーが欠けるため、Knowledgeタブとsearch_knowledgeツールが「embeddings service unreachable」を出すと書いている。RAGを使うならdocker-compose.production.ymlでのフルスタックが前提になる。つまり「まず単一コンテナで様子を見る」という進め方は、後からCompose構成へ移す前提でのみ成立する。4 GB RAMが最低、8 GB推奨という数字も、サイドカーを含めた構成を想定したものと読める。

メモリはピン留めと想起の2層に分かれる

メモリの設計はREADMEで最も説明が厚い部分だ。事実はバックグラウンドで自動抽出され、現在の会話に関連するときだけ引き戻される。すべての項目はSettingsから見え、編集も削除もできる。ピン留め層に入れた事実は常に注入され、関連度スコアを飛ばし、減衰もしない。アレルギーや硬い制約、呼ばれ方の指定が例として挙がっている。それ以外は想起層に入り、現在の会話に対する埋め込み類似度で選別される。使われない記憶は時間とともに関連度を失い、自動でアーカイブされる。Claraはsearch_memoryとadd_memoryを会話の途中で呼ぶ。他のツールと同じ呼び方だ。保存時はAES-256-GCMで暗号化し、鍵はHKDFでユーザーごとに導出するため、ClaraVerseの管理者でも読めないとされている。ただし埋め込み類似度による選別が動く以上、想起層の検索はembeddingsサイドカーに依存する。単一コンテナ構成ではこの層が機能しない点と表裏になる。

Crewはカードを人間が承認してから進める

Crewはプロジェクトの概要を渡すとエージェントのチームを組み、カードのパイプラインで作業を進める。READMEが繰り返すのは、各カードが送り出される前に必ず自分のレビューへ戻ってくるという点で、「ブラックボックスではない」と表現している。自動で最後まで走り切るエージェントではなく、途中に人間の承認点を挟む設計だ。これは速度より追跡可能性を優先した選択であり、承認を省いて一気に流したい用途には向かない。同じリポジトリにはターミナルで動くClara Agentも含まれ、ファイルの読み書き、編集、コマンド実行を、Webアプリと同じモデルとアカウントで行う。claraverse agent installでビルドしてclaracliをPATHに置き、claracliから/login claraverseで接続する流れが示されている。

導入手順と設定キー

LinuxとmacOS向けの1行インストールはcurl -fsSL https://raw.githubusercontent.com/claraverse-space/ClaraVerse/main/cli/install.sh | bashの後、claraverse initを実行する。Compose構成ならgit cloneの後にdocker compose -f docker-compose.production.yml up -dで、http://localhost:3000を開き、最初に登録したユーザーが管理者になる。設定はdocker-compose.production.ymlの隣に.envを置いて上書きする。CLARAVERSE_PORTは既定3000、OLLAMA_BASE_URLはhttp://host.docker.internal:11434、LMSTUDIO_BASE_URLはhttp://host.docker.internal:1234が既定値として示されている。ログはdocker compose -f docker-compose.production.yml logs -f claraverse、再起動は同ファイルでのrestart、データを消してやり直すならdown -vの後にup -dだ。パイプでシェルに流すインストールは中身を確認せずに実行することになるため、先にinstall.shを読むか、Compose手順を選ぶほうが安全だ。

ライセンス表記とメンテナンス費用の読み方

READMEのバッジはAGPL-3.0を示し、本文も「人が注目した途端に課金を始めないライセンス」と書いている。一方でリポジトリのメタデータ上、LicenseはNOASSERTIONと表示される。GitHubが既知のライセンスとして認識できていない状態であり、READMEの主張とメタデータが一致していない。導入を検討するならLICENSEファイルを直接開き、AGPL-3.0の全文が入っているかを自分の目で確認する必要がある。AGPL-3.0であれば、改変した版をネットワーク経由で提供する場合にソース開示が及ぶ範囲が、MITやApache-2.0とは異なる。ここでは法的助言はできないので、社内利用や再配布の条件は自組織の判断で確認してほしい。更新頻度はリリース情報から見る限り活発で、v0.3.0のKnowledge bases everywhere、v0.3.1のOne-line install RAG-readyが同じ日に並んでいる。RAG周りが短期間で動いているぶん、Compose構成のサイドカー定義や既定ポートが次のリリースで変わる可能性を織り込んでおきたい。

Open WebUIとの違いは同梱物の範囲

README自身がOpen WebUIとの比較節を設けている。両者ともOllamaをバックエンドにしたセルフホストのチャットUIという入口は同じだが、ClaraVerseはCrew、メモリの2層管理、ビジュアルワークフロー、Telegram連携、ターミナルのClara Agentを同じリポジトリに同梱する。Open WebUIはチャットとモデル管理に焦点を絞り、それ以外は外部ツールと組み合わせる前提だと理解すれば、差は機能数ではなく構成要素の数に出る。ClaraVerseはMySQL、MongoDB、Redis、SearXNG、Qdrant、embeddingsサイドカーを抱えるため、バックアップ対象と障害点がその分だけ増える。エージェントのレビュー工程や知識ベースが不要で、単純にローカルモデルと話したいだけなら、同梱物の少ない側を選ぶ理由は明確だ。逆に、これらを別々のSaaSで繋いでいる状態を1つのComposeファイルに畳みたいなら、ClaraVerseの構成はその作業を先に済ませたものと見られる。

編集部の結論

ローカルLLMをすでに動かしていて、チャットUIだけでなくエージェントのレビュー工程や知識ベースまで同じホストにまとめたい個人や小規模チームに向く。単一コンテナで試したいだけならKnowledgeタブとsearch_knowledgeツールが動かない点を先に受け入れる必要があり、MySQL、MongoDB、Redis、SearXNG、Qdrantを運用したくない場合はOpen WebUIのほうが構成は軽い。導入前にdocker-compose.production.ymlの中身とLICENSEファイルを開き、NOASSERTIONと表示されるライセンスの実体がAGPL-3.0の全文なのかを確認してから、docker compose up -dを実行するか決めればよい。

公式情報源

コミュニティノート