Risuai を採用する前に読む、LLM ロールプレイ用クライアントの実装と制約

Risuai が埋めるのは「モデルは選べるが UI は選べない」という隙間

LLM を対話相手として使うとき、多くの人はベンダー公式のチャット画面か、自前で組んだ簡単なスクリプトのどちらかに落ち着く。前者はモデルの切り替えができず、後者はキャラクター設定や画像表示を毎回作り直すことになる。Risuai はこの中間を狙ったデスクトップ兼ウェブのアプリケーションで、README では「cross platform AI chatting software / web application」と説明されている。想定読者は、API キーを自分で用意して複数のモデルを試したい個人、あるいはキャラクター設定を配布・共有したい作り手だ。対応 API として OpenAI、Claude、Gemini、DeepInfra、Ooba、OpenRouter が列挙されており、単一のモデルに固定されない前提で設計されている。

Svelte 5 + Tauri 2.5 という構成が意味するもの

リポジトリのバッジによれば、UI は Svelte 5、ビルドは Vite 8、スタイルは Tailwind CSS 4、デスクトップ殻は Tauri 2.5、言語は TypeScript 5.9 で書かれている。Tauri を選んでいる点は実用上大きい。Electron ではなく OS の WebView を使うため、配布物に Chromium を同梱せずに済む。ただしその代償として、動作は各 OS の WebView 実装に依存する。README はこの点に触れていないので、古い WebView を積んだ環境での挙動は実際に試すまで分からない。ウェブ版とデスクトップ版が同じコードベースから出ている構成なので、まずウェブ版で挙動を確認し、あとから Tauri ビルドを試す順序が現実的だ。

キャラクターの表現を支える Emotion Images と追加アセット

Risuai の機能一覧で目を引くのは Emotion Images だ。現在のキャラクターの表情に応じて画像を切り替える仕組みで、単にテキストを並べるチャットとは体験が異なる。これと対になるのが Additional Assets で、画像・音声・動画をボットに埋め込み、チャット本文中や背景として表示できると README は説明している。つまりキャラクターはテキスト定義だけでなく、複数のメディアファイルの集合として扱われる。配布物を他人と共有する場合、このアセット群をどう運ぶかが実務上の論点になる。README はアセットの保存形式やエクスポート方法までは述べていないので、共有を前提にするなら実際に書き出しを試して確認する必要がある。

Regex Script とプロンプト順序の制御という二段構え

モデル出力を正規表現で書き換える Regex Script は、この種のツールでは珍しくない。Risuai の場合、README がその用途として「custom GUI and others」を挙げている点が特徴で、表示の整形だけでなく UI の一部を出力側から組み立てる使い方を想定している。もう一段が Powerful Prompting で、プロンプトの順序を変更し、条件や変数を使い、プロンプト内で Impersonate できるとされている。ここは設計上のトレードオフがはっきり出る部分だ。順序と条件を自由にすると、同じキャラクターカードでもモデルごとに結果が変わりやすくなる。再現性を重視するなら、条件分岐を増やさず素直な順序で運用するほうが扱いやすい。

Lorebook と記憶圧縮は長期対話のコストと隣り合わせ

Lorebook は world infos や memory book とも呼ばれ、キャラクターに追加の設定を覚えさせる仕組みだと README は説明する。さらに長期記憶として HypaMemoryV2/V3 による記憶圧縮と、SupaMemory によるコンテキスト管理が挙げられている。圧縮という言葉が示すとおり、これは会話履歴をそのまま送るのではなく要約や選別を挟む設計だ。利点はコンテキスト長の節約だが、圧縮の過程で落ちた情報は後の会話で復元できない。重要な設定を Lorebook 側に固定し、圧縮の対象になりにくくしておくのが安全な使い方になる。README には圧縮アルゴリズムの詳細も、どの情報が優先的に残るかの記述もない。長期の対話ログを業務用途で使うなら、この不透明さは無視できない。

Docker で起動する場合の実際の手順

導入経路は三つ示されている。推奨は公式サイト risuai.net、次に GitHub Releases、そして Docker だ。Docker はウェブホスティング向けと明記されており、手順は次の一行に集約されている。curl -L https://raw.githubusercontent.com/kwaroran/Risuai/refs/heads/main/docker-compose.yml | docker compose -f - up -d 。起動後は http://localhost:6001 にアクセスする。開発に参加する場合は Node.js 20.19 以上または 22.12 以上と pnpm が必要と README に書かれている。ここで注意したいのは、リモートの docker-compose.yml をそのままパイプで流し込む手順だ。中身を確認せずに実行することになるので、閉じたネットワークや監査が必要な環境では、先にファイルを取得して内容を読んでから起動するほうがよい。ポート 6001 も固定なので、既存のサービスと衝突しないか事前に確認しておく。

プラグインで拡張できる代わりに、拡張の品質は自分で見るしかない

Plugins は機能とプロバイダを追加し、そのまま共有できると README は述べている。対応 API の一覧にないサービスを使いたい場合、この経路で追加することになる。ただし README にはプラグインの API 仕様も、配布時の検証方法も書かれていない。プラグインはアプリと同じ権限で動く以上、第三者が配布したものを入れる場合はコードを読む前提で臨むべきだ。公式の Wiki は Work in Progress と明記されており、詳細な仕様がそこに揃っているとも限らない。拡張性は高いが、その分だけ利用者側の確認コストが上がる構造だと言える。

Risuai を選ぶべきでない場面と、代わりに検討するもの

向かない用途ははっきりしている。複数ユーザーが同時にログインするサービスを自前で立てたい場合、Docker 手順はあくまで単一インスタンスを localhost:6001 で動かす話であり、認証やユーザー分離には触れていない。この用途では、サーバー側で会話状態とユーザー管理を持つ設計のフレームワークのほうが素直だ。たとえば LibreChat は複数プロバイダ対応とユーザー認証を備えたサーバーアプリケーションとして作られており、Risuai がクライアント側でキャラクター表現とプロンプト制御に寄せているのとは力点が違う。逆に、自分の手元でキャラクターを育て、Regex Script や Lorebook を試行錯誤したいだけなら、Risuai の機能群はその作業に直接効く。ライセンスは GPL-3.0 なので、改変して配布する場合は同じライセンスでソースを公開する条件が関わってくる。社内ツールとして改変するだけなら話は別だが、判断は法的助言ではなく、自組織の利用形態を整理したうえで行う必要がある。

編集部の結論

採用を検討すべきなのは、特定ベンダーのチャット UI に縛られず、キャラクター設定やプロンプトを手元で管理したい個人利用者だ。逆に、複数ユーザー向けのサービスとして組み込みたい場合や、SaaS として再配布したい場合は GPL-3.0 の条件とサーバー側の認証設計を先に確認する必要がある。最初に見るべきは docker-compose.yml の中身と、利用予定の API がプラグイン側で提供されているかどうかだ。

公式情報源

1. kwaroran/Risuai on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases