OpenBiliClaw レビュー：ローカル SQLite に心理画像を貯める自己進化型コンテンツ発見 Agent

OpenBiliClaw が解こうとしている「中間業者」問題

README は推薦システムを「中間商」と表現し、その構造的な問題をこう説明する。現代の推薦はクリック率だけでなく、完播率、いいね・投げ銭確率、滞在時間、ユーザー継続率、クリエイター生態系の健全性、広告収入など十数の目的を重み付けして 1 つのスコアに圧縮している。だがその重みはプラットフォームが決め、最適化目標はあくまでプラットフォーム側にある、と README は主張する。ユーザー満足度は継続と収益化の手段として扱われる、というのが著者の見立てだ。

2 つ目の問題は島の分断である。README は「B 站で 3 年メカニカルキーボードを見ていても小紅書はそれを知らない」という例を挙げ、興味が各社データベースに切り分けられたまま誰も接続しないと書く。OpenBiliClaw はこの 2 点を、ローカルで動き、あなた個人を先に理解し、その理解を携えて複数プラットフォームへ能動的に探しに行く Agent として解こうとする。名前は Bilibili の Bili と爪の Claw に由来し、v0.3.0 以降で汎用クロスプラットフォームに拡張された経緯が README に記されている。対象読者は、推薦の主導権を手元に戻したい個人と、その仕組みを自分で改造したいエンジニアである。

心理画像をローカル SQLite に閉じ込めるデータフロー

README が示す流れは、行動シグナルがローカルバックエンドに入り、画像（プロファイル）が生成され、推薦理由が説明され、フィードバックで学習が続く、というループである。ヒーロー画像の alt テキストにも同じ説明が置かれている。中心にあるのは「先にあなたを理解し、それからコンテンツを探す」という順序で、動画からタグへ照合するのではなく、あなたから出発すると README は書く。

データの保存先はデフォルトで本機の SQLite だと明記されている。興味の表現は心理画像として蓄積され、跨平台の利用、フィードバック、会話から継続的に深められる。学習の入口として README が挙げるのは 3 つ、喜欢、不感兴趣、そしてチャットでのフィードバックである。これらが後続の推薦を変える。

取得側の構造は 2 系統に分かれる。Linux.do、Bangumi、V2EX、微博、GitHub は公開情報として発見でき、GitHub はバックエンドが公式 REST API から公開 repository を匿名で読む。アカウント状態が必要な来源はインストール済みのブラウザ拡張を再利用する。つまり拡張がログイン済みセッションの橋渡しを担い、バックエンドは本機で推論と蓄積を行う。クラウドに興味データを預けない設計が、この 2 系統の分離によって成立している。

導入手順：拡張、バックエンド、来源接続、UI の 4 段

README の「快速开始」は 4 ステップで構成される。第 1 に Chrome 应用商店から拡張を入れるか、Latest Release の zip を手動インストールする。README は商店版が最新機能より数日遅れる可能性があると明記しており、新機能を先に試したい場合は zip 側を選ぶことになる。

第 2 にバックエンドを入れる。同じ Latest Release から macOS の `.dmg` と Windows の `.exe` を取得する。各プラットフォームに 2 種類あり、精简版は初回起動時にベクトルモデル bge-m3 を自動ダウンロードし、`-with-embedding` 完整版は bge-m3 約 1.1GB を同梱してオフラインで即時動作する。回線が細い、あるいはオフライン前提なら完整版、それ以外は精简版、というのが README の案内である。ソースから改造したい場合は、README に記載された指示文を Claude Code、Codex CLI、Cursor などのコーディング助手に貼る方法が用意されている。その文面には、agent-install.md を WebFetch ではなく Bash の curl で取得するよう指定がある点に注意したい。

第 3 に来源を接続する。拡張を入れたブラウザで B站 にログインすると、これがデフォルトの初期化来源になる。小紅書、抖音、YouTube、X、知乎、Reddit、Linux.do、V2EX、微博、GitHub へ切り替えられる。GitHub は公開ユーザー名で starred repositories を初期シグナルに使え、PAT は任意のレート引き上げと本人確認の手段だと README は説明する。

第 4 に UI を開く。ブラウザで `http://127.0.0.1:8420/web`、スマートフォンは拡張の QR コードから `http://<电脑局域网 IP>:8420/m/` を開き、ホーム画面に保存すればアプリのように使える。ネイティブアプリが欲しい場合は別リポジトリの Flutter クライアントを入れ、設定でバックエンドのアドレスを指定すれば同じバックエンドに接続する。

アプリ内 Tailnet：外から使うときの設定と、その範囲の限定

同一 LAN 外から使う場合、README は Tailnet 経由の経路を説明する。`OpenBiliClaw-mobile` の Android / iOS ネイティブアプリは `tsnet` を内蔵しており、PC 側も OpenBiliClaw 自身を同じ tailnet に参加させられる。ただし Web、Linux、macOS、Windows の Flutter クライアントはこの能力の対象外だと明記されている。ここは見落としやすい境界である。

デスクトップ版には helper が同梱される。本機でデスクトップ Web かブラウザ拡張の「设置 → 通用 → 应用内 Tailnet 远程访问」を開き、有効化したうえで、空欄のまま Web ログインを使うか、`tskey-auth-…` の Auth Key を入れるか、認可デバイスタグ付きの `tskey-client-…` OAuth Client Secret を入れる。その後アプリを完全に再起動する。憑証は次の起動まで本機に私的に一時保管され、`config.toml`、API の応答、ログには入らないと README は述べている。

ソースから入れた場合やワンライン導入の場合は、先に `openbiliclaw tailnet build-helper`（Go 1.26.6 が必要）を実行し、次に `openbiliclaw tailnet enable` を実行して再起動する。PC にシステム Tailscale をインストールしたり全体で有効化したりする必要はない。入口はデフォルトで無効、tailnet の私網からのみ見え、Funnel/Serve は使わない。加えて本機 Web 設定でアプリパスワードを有効にすることを README は勧めており、ソース導入では `openbiliclaw set-password` を実行できる。

DeepSeek Harness プラグインという拡張面

README 冒頭の重要更新として、DSH クライアントプラグインが追加されたことが挙げられている。DeepSeek Harness に OpenBiliClaw を組み込むと、DSH の画面に第 4 のカラムとして推薦、内容庫、対話、画像、設定が常駐し、22 個の Agent Bridge ツールが登録される。DSH 内の Agent が推薦を読み、探査に答え、閉ループ学習を回せる、という説明である。プラグイン本体は別リポジトリ `whiteguo233/dsh-openbiliclaw` に置かれている。

この構成の意味は、推薦を単独アプリとして開くのではなく、作業中のツールの中に常駐させる点にある。ただし README が示すのは機能の一覧とツール数までで、22 個のツール名や入出力のスキーマは本記事で参照できる資料には含まれていない。実際に Agent から呼ぶ予定なら、別リポジトリ側のドキュメントでツール定義を確認する必要がある。ここは README だけでは判断できない領域として明示しておく。

向かない場面：マルチユーザー基盤とクラウド学習

この設計は「あなた 1 人」を前提にしている。README 自身が「只为你一个人构建」と書き、心理画像は本機の SQLite に貯まる。したがって、複数人の興味を 1 つのモデルに集約して全員へ配信する用途や、サーバ側で学習を回してアプリ更新だけで全ユーザーに反映させる形には向かない。学習の入力が本機の行動とフィードバックに閉じているため、ユーザーが使わなければ画像は育たない。

もう 1 つの制約は、アカウント状態が必要な来源をブラウザ拡張に依存している点である。B站 や小紅書などを扱うには、拡張を入れたブラウザでその都度ログインしておく必要がある。ヘッドレスなサーバ運用や、ブラウザを持たない環境で完結させたい場合、この経路は成立しない。公開発見に対応する Linux.do、Bangumi、V2EX、微博、GitHub だけを使う構成なら拡張なしでも成立するが、その場合は対象が限定される。

加えて、README は推薦の精度や速度について数値を一切示していない。本記事もそれを検証していない。導入判断は、対応プラットフォームの一覧とローカル保存という設計方針に対して行うべきで、推薦品質の比較に対して行うべきではない。

代替手段との違い：クラウド型推薦サービスと RSS リーダー

比較対象として分かりやすいのは、クラウド側で興味を学習してアプリに配信するタイプの推薦サービスである。違いは学習の場所と、誰の目的関数を最適化するかにある。クラウド型は複数ユーザーの行動を集約できるため新規ユーザーでも初日からそれなりの推薦が出るが、興味データは事業者の管理下に置かれ、最適化目標には事業者側の指標が混ざる。OpenBiliClaw は逆で、初日はほぼ何も知らない状態から始まり、本機の行動とフィードバックで画像を育てる。立ち上がりの遅さと引き換えに、データの所在と最適化目標を自分側に置く。

もう 1 つの比較軸は RSS リーダーである。RSS は購読したフィードを時系列で並べるだけで、あなたの興味を推定しない。OpenBiliClaw は興味の推定そのものが主機能で、推荐、内容庫、対話、画像、設定という画面構成もそのために組まれている。逆に、購読先を自分で管理したいだけなら RSS のほうが軽く、bge-m3 の取得もローカル推論も不要である。どちらが上という話ではなく、興味の推定を機械に任せるか、購読リストを人間が持つかの違いである。

保守コストとライセンスの確認点

ライセンスは MIT で、リポジトリは archived ではない。MIT は商用利用や改変、再配布を許す寛容な条件だが、本記事は法的助言を行わない。実際に再配布や製品組み込みを検討する場合は、同梱される bge-m3 など依存コンポーネント側のライセンスを別途確認する必要がある。ここは README からは判断できない。

更新の頻度は資料から読み取れる。v0.3.220 として openbiliclaw、extension、desktop の 3 つのタグが同日にリリースされており、バックエンド、拡張、デスクトップが別々にバージョン付けされながら同時に更新される運用だと分かる。これは追従コストに直結する。README が「商店版は最新機能より数日遅れる」と書いている以上、拡張とバックエンドのバージョンがずれる期間が常態的に発生する。不具合を切り分けるときは、まず 3 つのバージョンが揃っているかを確認することになる。

もう 1 つのコストは初回のモデル取得である。精简版は初回起動時に bge-m3 を自動ダウンロードするため、その間はネットワークに依存する。完整版は約 1.1GB を同梱する分だけインストーラが大きい。どちらを選ぶかは、配布する環境の帯域とストレージの方針で決まる。手動で更新する場合は、バックエンドと拡張を同じタイミングで入れ替えるのが安全である。

編集部の結論

自分専用の推薦経路を持ちたいが、興味データを外部サービスに預けたくない個人ユーザーには向く。逆に、複数人で共有する推薦基盤や、クラウド側で学習を回して全ユーザーに配信する形を求めるチームには向かない。導入前に確認すべきは、Chrome 拡張とバックエンドのバージョン差（README は商店版が数日遅れると明記している）、bge-m3 を初回に自動取得するか約 1.1GB 同梱版を選ぶか、そして Tailnet 経由で外から触る場合に `openbiliclaw set-password` でアプリ側パスワードを設定したか、の 3 点である。

公式情報源

1. License: MIT
2. Project website
3. README
4. Releases
5. whiteguo233/OpenBiliClaw on GitHub