Rakazo を自前で運用する: モデルとサンドボックスを選べる常駐 AI チームメイトの実像
Open-source Grok Bot alternative. Choose your own model and sandbox.
ひと目でわかる
- これは何？
- Rakazo は常駐型の AI ボットを自分のモデル資格情報と計算基盤で動かすための Apache-2.0 の TypeScript プラットフォームである。公開 Docker イメージによる導入経路と、ソースからの開発経路という性格の異なる 2 つの入口を持つ点が実務上の分岐になる。
- 誰に向いている？
- 常駐ボットを自前のサーバーで動かし、モデル資格情報とサンドボックスの両方を自分で選びたいチームに向く。逆に、マネージド SaaS の可用性やサポート契約を前提にしたい場合、あるいは Node.js のバージョン管理を避けたいだけの用途には向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Rakazo が置き換えようとしているものは何か
一般的なチャットボットは、会話が終われば状態も消える。Rakazo が対象にしているのはその逆で、README は「persistent AI teammates」という表現を使い、ボットが独自の会話、メモリ、ルーチン、履歴を保持すると説明している。つまり単発のプロンプト応答ではなく、ブラウザ、ターミナル、ファイル、グラフィカルデスクトップにアクセスできる常駐プロセスとしてボットを扱う。
対象読者は 2 種類に分かれる。1 つは自分のモデル API キーと計算基盤を持ち込み、ボットを自分のサーバー上で動かし続けたい開発者。もう 1 つは Web、Electron デスクトップ、Expo モバイルという複数のクライアントから同じ Rakazo API に接続し、チーム内で共有する用途である。README の Features には Shared Team Computers と isolated Private computers という区別があり、共有の計算資源と個人用の隔離環境を意図的に分けていることが読み取れる。
ボット、サンドボックス、モデル資格情報の三層構造
スタックの記述から見える構成は素直である。TypeScript と React 19、Vite、Tailwind CSS で UI を作り、Hono と oRPC で API を公開し、PostgreSQL と Prisma で状態を保持し、Better Auth で認証し、Graphile Worker で非同期ジョブを回す。Electron と Expo のアプリは独立した実装ではなく、Web アプリと同じ Rakazo API のクライアントだと README が明言している。
モデル側は Pi を通じた bring-your-own 資格情報で、OpenRouter のキーを .env に置くか、オンボーディング中に対応プロバイダへ接続する。実行環境側は Docker、E2B、Daytona、Box、そして trusted local-computer が並ぶ。ボット同士が委譲し合える点、短命な subagent を起動できる点も Features に挙がっている。ここで重要なのは、モデルの抽象化と計算環境の抽象化が別レイヤーとして設計されていることだ。片方だけ差し替えるという運用が成立しやすい。
公開イメージでの導入手順と、その前提条件
クローンも Node のインストールも不要な経路が用意されている。必要なのは Docker Engine、Compose プラグイン、curl、OpenSSL である。README が示すコマンドは次のとおり。
mkdir -p rakazo && cd rakazo && curl -fsSLO https://raw.githubusercontent.com/elie222/rakazo/main/infra/compose/install-images.sh && bash install-images.sh
このスクリプトは Compose ファイルを取得し、ランダムなシークレットを含む .env を生成して Rakazo を起動する。既存の .env は再実行時に保持される。起動後は http://127.0.0.1:5173 を開いてアカウントを作成し、モデルを接続する。既定のイメージタグは edge で、linux/amd64 と linux/arm64 の両方を対象にした main ビルドである。
制限されたネットワーク向けに、インストーラのダウンロード元を RAKAZO_DOWNLOAD_BASE で上書きする、既存の Compose ファイルをスキップする（--local または RAKAZO_DOWNLOAD_SKIP_EXISTING）、といった逃げ道も文書化されている。エージェント支援によるインストールを想定した SETUP_PROMPT.md も同梱されている。
サーバー運用に切り替えるときの .env の書き換え
ローカルの Docker サンドボックスは既定で有効だが、ボットを常時稼働させたいならバックエンドをサーバーに置く必要がある。README の手順は 2 段階である。まず bash install-images.sh --prepare-only を実行し、次に .env を編集する。ここで書き換えるキーは SANDBOX_PROVIDER を box、e2b、daytona のいずれかにし、対応する API キーを設定、RAKAZO_HOST を自分のドメインにすること。その後、再度 bash install-images.sh を実行する。
ポート 5173 の前段に HTTPS を置く必要があり、docs/self-host.md に Caddy の設定とホストの堅牢化が記載されている。デスクトップアプリからは Existing instance を選び、https:// のアドレスを入力する。公開サーバーは HTTPS 必須で、HTTP が許されるのはループバックとプライベート LAN アドレスのみ、リンクローカルは対象外と明記されている。アプリは保存前に Rakazo のヘルスエンドポイントを検証する。
ソースから開発する場合は前提が厳しい。Node.js 22.22.2 以上（22.x 系）、Node.js 24.x、または 26 以上が必要で、23.x と 25.x はサポート外と明記されている。pnpm 9 と Docker も要る。.env.example をコピーしたうえで、POSTGRES_PASSWORD、DATABASE_URL、BETTER_AUTH_SECRET、ENCRYPTION_KEY、SCREEN_PROXY_SECRET、そして Docker サンドボックス用の SANDBOX_SUPERVISOR_TOKEN をそれぞれ独立した長いランダム値にする。Postgres は既定の Compose ファイルではネットワーク内部に留まり、ホスト側の pnpm や DB ツールから触りたいときだけ postgres-host オーバーレイが 127.0.0.1:5433 を公開する。
接続カタログと Treg の利用条件
アプリ連携は Composio か Pipedream Connect のマネージドカタログを使うか、ユーザーが Integrations から HTTPS の MCP サーバー、Treg エンドポイント、OpenAPI JSON ドキュメントを直接追加する。マネージド側を有効にするには COMPOSIO_API_KEY、または PIPEDREAM_CLIENT_ID、PIPEDREAM_CLIENT_SECRET、PIPEDREAM_PROJECT_ID の 3 点セットが必要になる。コネクタの資格情報はサーバー上で暗号化され、API から返されることはないと README は述べている。
ここで見落としやすいのが Treg の課金体系である。README は Treg が usage-metered であり、セルフホスターは自分の Treg トークンを用意する必要があるとし、ホスト型製品に Treg を組み込む運用者は Treg の integration terms を確認すべきだと書いている。その条件には hosted resale に書面による合意が必要だと記載されているという。Apache-2.0 は Rakazo 自体のライセンスであって、外部サービスである Treg の利用条件を緩めるものではない。ここは法務判断の領域なので、導入前に原典を直接読むべき箇所である。
ベータ段階であることと、向かないケース
README は Rakazo が beta であると明記している。リリース履歴も v0.1.4、v0.1.5、v0.1.6 が 2026 年 9 月 7 日から 8 日にかけて並んでおり、バージョン番号も間隔も初期段階のそれを示す。互換性の保証や長期サポートを前提にした導入は現実的でない。
より具体的な失敗モードはサンドボックスにある。既定はローカル Docker で、これは単一マシン上での動作を想定している。サーバー運用に移す際は SANDBOX_PROVIDER を box、e2b、daytona のいずれかに切り替え、それぞれの API キーを用意する必要がある。つまり外部プロバイダへの依存とその課金を受け入れるか、単一ホストに留まるかの選択になる。ボットにブラウザやグラフィカルデスクトップへのアクセスを与える設計上、信頼できないコードを走らせる用途では隔離の強度がそのまま安全性になる。ここを軽視したまま公開サーバーに置くのは適切でない。
もう 1 つの制約はデータベースの扱いだ。既存の pgdata ボリュームは初回初期化時のユーザー、パスワード、データベースを保持し続けるため、値を変えるなら .env を維持するか ALTER ROLE でその場で変更する必要がある。docker compose down -v は Postgres の状態をすべて削除する。バックアップなしで実行すべきではない。
比較対象としての LibreChat と、抽象化の置き場所の違い
同じ「自前でホストする LLM フロントエンド」という括りで比較されるのが LibreChat である。両者の違いは抽象化をどこに置くかにある。LibreChat は複数のモデルプロバイダを 1 つのチャット UI に束ねることを主眼にし、利用者は会話とプロンプトを中心に据える。Rakazo はボットという常駐主体を中心に据え、会話はその属性の 1 つとして扱われる。README の表現を借りれば、ボットは独自の conversations、memory、routines、history を持ち、peer のボットや短命な subagent へ委譲できる。
この違いは運用に直結する。LibreChat 的な構成では、モデルを差し替えてもユーザー体験の中心はチャット画面のまま変わらない。Rakazo では、サンドボックスプロバイダを Docker から E2B や Daytona に変えると、ボットが何を実行できるかという能力そのものが変わる。どちらが優れているという話ではなく、モデルの抽象化だけを求めているなら Rakazo の計算環境レイヤーは余分な複雑さになる。逆に、ボットに実際の計算資源を渡したいなら LibreChat の設計では届かない。
Electron アプリのローカルスタックと、その停止方法
デスクトップアプリは初回起動時に、このコンピュータで Rakazo を動かすか、既存のサーバーへ接続するかを尋ねる。前者を選ぶと、アプリのデータディレクトリ配下で infra/compose/install-images.sh と同じ公開イメージを Docker Compose 経由で導入・起動する。Docker Desktop、OrbStack、Docker Engine のいずれかが必要で、未導入ならアプリが案内する。パッケージ済みビルドはイメージタグを自身のバージョンに固定し、未パッケージのビルドは edge を取得する。
ここに開発者向けの落とし穴がある。pnpm dev で動かしている開発者は、このコンピュータではなく Existing instance を選び、http://127.0.0.1:5173 を指定する必要がある。スタックはアプリを終了しても動き続け、アプリケーションメニューの Stop Local Stack で止める。この挙動は、デスクトップアプリが単なるビューアではなくスタックのライフサイクル管理も担っていることを意味する。バックグラウンドでイメージが動き続けることを把握していないと、ディスクとポートを意図せず占有したままになる。
編集部の結論
常駐ボットを自前のサーバーで動かし、モデル資格情報とサンドボックスの両方を自分で選びたいチームに向く。逆に、マネージド SaaS の可用性やサポート契約を前提にしたい場合、あるいは Node.js のバージョン管理を避けたいだけの用途には向かない。導入前に確認すべきは、infra/compose/install-images.sh が生成する .env の中身、とくに SANDBOX_PROVIDER と RAKAZO_HOST の 2 つである。ここを決めずに起動すると、既定のローカル Docker サンドボックスのままサーバー公開を試みることになる。
コミュニティノート