モデル / データセット
nextlevelbuilder/goclaw avatar
nextlevelbuilder/goclaw

GoClaw: Goで書き直されたマルチテナントAIエージェント基盤の実像

GoClaw - GoClaw is OpenClaw rebuilt in Go — with multi-tenant isolation, 5-layer security, and native concurrency. Deploy AI agent teams at scale without compromising on safety.

スター 3,602フォーク 1,055GoNOASSERTION

ひと目でわかる

これは何?
OpenClawをGoで再実装し、PostgreSQLによるテナント分離と単一バイナリ配布を狙ったプロジェクト。READMEから読み取れる設計と、読み取れない部分を分けて評価する。
誰に向いている?
複数ユーザーにエージェントを配りたいがNode.jsランタイムを抱えたくないチーム、特にPostgreSQLをすでに運用している組織には検討価値がある。逆に、単一ユーザーのローカル用途ならLite版で足り、Standard版のマルチテナント機構は過剰になる。
商用利用できる?
まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
今もメンテナンスされている?
されています。最後のコミットは 1 日前です。
何の言語で書かれている?
主に Go です(GitHub の言語統計による)。

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

オープンソース詳細解説

OpenClawの再実装が解こうとしている問題

READMEはこのプロジェクトを「Multi-Tenant AI Agent Platform」と位置づけ、Goで書かれたマルチエージェント向けのAIゲートウェイだと説明している。狙いは2つに読める。1つは配布形態で、約25MBの静的Goバイナリ、Node.jsランタイム不要、起動1秒未満、5ドルのVPSで動くとREADMEは述べている。もう1つは分離で、マルチテナントPostgreSQL、ユーザーごとのワークスペース、ユーザーごとのコンテキストファイル、AES-256-GCMによるAPIキー暗号化、RBAC、セッション分離が列挙されている。つまり単一のチャットボットではなく、複数の利用者にエージェントを配る場面を想定した作りだ。向き先は、社内の複数チームにボットを配りたい運用担当者、あるいはTelegramやSlackなど複数チャネルを1つのバックエンドに集約したい開発者になる。個人が1つのエージェントと会話したいだけなら、この構成は重い。

8段パイプラインと3層メモリの実際の中身

READMEが挙げる中核は8段のエージェントパイプラインで、context → history → prompt → think → act → observe → memory → summarize の順に並ぶ。各段はプラグイン可能で、常時実行されると説明されている。プロンプト側には4モード(Full / Task / Minimal / None)があり、セクション単位のゲーティング、キャッシュ境界の最適化、セッションごとのモード解決を行うとREADMEは書いている。メモリは3層で、Working(会話)→ Episodic(セッション要約)→ Semantic(知識グラフ)という階層に分かれ、L0/L1/L2の段階的読み込みを伴う。Knowledge Vaultは[[wikilinks]]付きの文書レジストリで、FTSとpgvectorを組み合わせたハイブリッド検索とファイルシステム同期を持つ。ここで注意したいのは、これらの名称と順序はREADMEで確認できるが、各段が具体的にどんなデータをどう変換するかはREADMEには書かれていない点だ。パイプラインの図は画像ファイルとして置かれているだけで、本文に処理内容の説明はない。設計の意図を評価するにはdocs.goclaw.shの該当ページを読む必要がある。

エージェントチームと自己進化という2つの主張

READMEはエージェントチーム機能として、共有タスクボード、エージェント間の委譲(同期・非同期)、3つのオーケストレーションモード(auto / explicit / manual)を挙げる。自己進化については、メトリクス→提案→ガードレール付き自動適応という流れで、エージェントが自分のコミュニケーションスタイルを洗練させると説明している。この2つは他の機能と性質が違う。タスクボードや委譲は状態を持つ仕組みで、PostgreSQL上のテーブル設計とジョブの再試行方針が見えないと挙動を判断できない。自己進化はさらに踏み込んでいて、エージェントが自分の振る舞いを書き換える以上、何をガードレールが止めるのかが導入判断の分かれ目になる。READMEにはガードレールの具体像も、適応がどの設定で無効化できるかも書かれていない。ここは「READMEの記述以上のことは不明」と明記しておく。自動適応をオフにできるかどうかは、本番で使う前に必ず確認したい項目だ。

起動までの手順と、READMEが途中で切れている事実

サーバ版のQuick StartはREADME内で「Prere」まで来て途切れており、起動コマンドそのものは確認できない。確認できるのはデスクトップ版の導線で、macOSはcurl -fsSL https://raw.githubusercontent.com/nextlevelbuilder/goclaw/main/scripts/install-lite.sh | bash、WindowsはPowerShellでirm https://raw.githubusercontent.com/nextlevelbuilder/goclaw/main/scripts/install-lite.ps1 | iex を実行する形になっている。ソースからデスクトップ版をビルドする場合は、前提としてGo 1.26以降、pnpm、Wails CLI(go install github.com/wailsapp/wails/v2/cmd/wails@latest)が必要で、make desktop-build、make desktop-dmg VERSION=0.1.0、make desktop-dev というターゲットが用意されている。デスクトップ版は独立したバージョン管理で、lite-v* タグをpushするとGitHub ActionsがmacOS(.dmgと.tar.gz)とWindows(.zip)をビルドしてReleaseを作る、とREADMEは説明している。サーバ版については、docs.goclaw.shのQuick StartでDocker構成とPostgreSQL 18の接続情報、暗号化キーなどの環境変数を確認するのが先になる。

Lite版とStandard版の境界はエージェント数ではなくDBにある

READMEの比較表で最も実務的なのは、両版の差がエージェント数やチーム数だけでなくデータベースの種類に及ぶ点だ。Lite版はSQLiteで、メモリはFTS5のテキスト検索、チャネル接続なし、知識グラフなし、RBACとマルチテナントなし。Standard版はPostgreSQLで、pgvectorによるセマンティック検索、Telegram・Discord・Slack・Zalo・Feishu・WhatsAppの7チャネル、知識グラフ、RBACが使える。エージェント数はLiteが最大5、チームは最大1(メンバー5人)で、Standardは無制限。ここから読み取れるのは、Lite版は「SQLiteで動く単一ユーザー向けのローカルアプリ」であり、Standard版との差は機能の足し算ではなく保存層の置き換えだということだ。FTS5からpgvectorへの移行は検索方式そのものの変更であり、後からLite版のデータをStandard版へ持ち上げる道が用意されているかはREADMEからは分からない。移行を前提にするなら、そこは先に問い合わせるべき点になる。

向かない場面と、比較対象としてのフレームワーク型

このプロジェクトが向かないのは、エージェントの制御フローを自分で書きたい場合だ。8段パイプラインは順序が固定され、常時実行されるとREADMEは述べており、段の差し替えはできても「この段を飛ばす」設計がどの程度自由かは示されていない。LangGraphのようにグラフを自分で定義して分岐やループを組むフレームワークとは発想が逆で、GoClawは会話・記憶・チャネル接続・テナント分離といった運用側の部品を先に用意し、その上でエージェントを動かす。したがって、研究用途で制御フローを細かく試したい人、あるいはチャネルもマルチテナントも不要で単一のCLIエージェントが欲しいだけの人には、この構成は荷が重い。逆に、認証・レート制限・プロンプトインジェクション検出・SSRF対策・AES-256-GCM暗号化といった5層のセキュリティ機構を自前で書きたくない運用側の人間にとっては、そこが採用理由になる。どちらが上かではなく、運用部品を買うか制御を買うかの違いだ。

ライセンス表記の食い違いとベータ番号の連投

導入前に引っかかる事実が2つある。第一にライセンスで、リポジトリのメタデータはNOASSERTION、READMEのバッジはCC BY-NC 4.0を示している。CC BY-NC 4.0は非商用条項を含む表示で、ソフトウェアのライセンスとして使われることもあるが、この2つの表記が一致していない以上、どちらが実際に適用されるかはリポジトリ内のLICENSEファイルを直接開いて確認するしかない。商用利用を想定しているなら、この確認は最初の作業になる。第二にリリースで、v3.15.0-beta.208、beta.207、beta.206が2026年9月8日から9日にかけて並んでいる。ベータ番号が200を超え、ほぼ毎日のように更新されているという事実は、活発さの証拠にはなるが、安定版タグが存在するかどうかは別の話だ。Releasesページでbetaの付かないタグを探し、それがいつ切られたかを見る必要がある。メジャー番号が3に達していてもベータが続いているなら、破壊的変更を前提にバージョンを固定して運用する覚悟が要る。

どのチームが採用し、何を先に確かめるか

サーバ版を選ぶべきなのは、複数テナントを1つのPostgreSQLに載せ、TelegramやSlackなどのチャネルを束ね、APIキーをアプリ側で暗号化して保持したいチームだ。Go 1.26とPostgreSQL 18という前提が許容でき、運用にDockerを持ち込めることが条件になる。デスクトップ版を選ぶべきなのは、1人か少人数でローカルにエージェントを置きたい場合で、エージェント5体、チーム1つという上限が仕事の範囲に収まるならSQLiteのゼロ設定は魅力だ。判断を保留すべきなのは、自己進化のガードレールの中身と、Lite版からStandard版へのデータ移行手段が確認できるまでの間だ。着手順としては、docs.goclaw.shのQuick Startでサーバ版の起動コマンドと環境変数を確認し、リポジトリのLICENSEファイルでNOASSERTIONとCC BY-NC 4.0のどちらが有効かを読み、Releasesでbeta以外のタグの有無を見る。この3つが揃って初めて、パイプラインの各段を読む作業に進む意味が出てくる。

編集部の結論

複数ユーザーにエージェントを配りたいがNode.jsランタイムを抱えたくないチーム、特にPostgreSQLをすでに運用している組織には検討価値がある。逆に、単一ユーザーのローカル用途ならLite版で足り、Standard版のマルチテナント機構は過剰になる。導入前に確認すべきは3点。第一にライセンスで、GitHubのメタデータはNOASSERTION、READMEのバッジはCC BY-NC 4.0であり、商用利用の可否がこの2つで食い違っている。第二にリリースがv3.15.0-beta.208のようなベータ番号で連日積まれている事実で、安定版タグの有無をReleasesで直接見る必要がある。第三にQuick Startの手順がREADME内で途中で切れているため、docs.goclaw.shのQuick Startページで起動コマンドと必須の環境変数を自分の目で確認してから、docker composeの構成を読むこと。

公式情報源

  1. Issues
  2. nextlevelbuilder/goclaw on GitHub
  3. Project website
  4. README
  5. Releases
コミュニティノート

コミュニティノート