Octopは家のサーバ1台でエージェントを共有できるか。

家にミニPCが1台転がっているなら、そこにAIエージェントを置いて家族や相棒と分け合う、という選択肢が現実的になってきました。今日はその構成をまるごと引き受けるOSSの話をします。データを外に出さずにどこまでやれるのか、設計を追いかけて確認しました。

家に1台のサーバがあれば、エージェントは足りる

TencentCloudが公開しているOctopは、世帯や小規模チーム向けのセルフホストAIアシスタントです。公開は2026年7月8日で、まだ2ヶ月半ほど。それでGitHubのスターは4,600を超えていました（2026年9月23日時点）。ライセンスはMIT、実装はPythonです。

GitHub - TencentCloud/Octop: A smarter, self-hosted AI assistant — multi-user, multi-agent.

A smarter, self-hosted AI assistant — multi-user, multi-agent. - TencentCloud/Octop

github.com

セルフホストのAIエージェントというと、これまでは「自分1人のために自分のマシンで動かす」前提のものがほとんどでした。セルフホストなのに複数人、というところが引っかかりませんか。

Octopが面白いのはまさにそこで、最初から1台を分け合う想定で作られています。管理者アカウントが1つあって、そこにメンバーをぶら下げ、それぞれに別々のエージェントを割り当てる。家庭のNASみたいな発想を、AIエージェントに持ち込んだ形です。

単一プロセスに全部入り、Octopの構成

ここが僕が一番グッときたところなんですが、Octopはプロセスを1本立てるだけで完結します。Webダッシュボード、CLI、IMチャンネル、cronによる定期実行が、全部その1プロセスの中に同居している。しかも全員が ~/.octop/ にある1つのデータベースを共有します。

中身はこうなっています。

• config.json 実行時の設定
• octop.db SQLite。既定はこれで、PostgreSQLにも切り替えられる
• secrets/ JWTの秘密鍵とチャンネルのトークン
• agents// エージェントごとのワークスペース
• security/tool_guard/ シェルコマンドの許可と拒否のルール
• logs/ 実行ログ

マイクロサービスに切らず、状態を1箇所に寄せている。家に置く1台のサーバで動かすなら、この割り切りは正解だと思います。バックアップの単位がディレクトリ1つで済むので、octop backup create と restore だけで引っ越しが終わるのも効いてきます。

導入は3通り、家のサーバならどれか

インストール手段は3つ用意されています。

インストーラ方式は ~/.octop/venv/ にuv管理のPython環境を自前で作り、~/.octop/bin/octop をPATHのラッパーとして置きます。ホストのPythonを汚さない設計なので、すでに何かが動いているサーバに入れるときも心理的に楽です。

じゃあ家のサーバにはどれを入れるか。落として上げ直すのが面倒な常時起動用途ならDocker Compose、今夜だけ触って気に入らなければ消すつもりならワンラインインストーラが素直です。

入れたあとは octop init で初回セットアップウィザードが走り、SQLiteのDBとJWTの秘密鍵、そして最初の管理者アカウントが作られます。あとは octop run でサーバが上がり、既定では http://127.0.0.1:8088 がダッシュボードです。常時動かすなら octop service start でシステムサービスとして登録できます。

Ollamaに繋いだ先で、データはどこまで外に出るのか

ここが本題です。OctopはLLMの接続先として、OpenAI互換API、Qwen向けのDashScope、そしてOllamaを選べます。しかも接続先はエージェントごとに設定できるので、「家族用のエージェントはローカルモデル、自分の開発用だけクラウド」という混在が組めます。

CLIもローカルモデル前提の顔をしていて、octop models には ollama-list ollama-pull ollama-rm というサブコマンドが生えています。モデルの出し入れをOctopの側から完結させられる、ということです。

では、Ollamaに繋げばデータは1ミリも外に出ないのか。答えは「LLMへの推論リクエストは出ない。ただし外に出る経路は別に3つ残る」です。

1. クラウド側のプロバイダを選んだエージェントがいれば、そのエージェントの会話だけは当然外に出ます
2. IMチャンネル。Feishu、DingTalk、QQ、Telegram、WeComに繋いだ時点で、そのメッセージは各社のサーバを通ります（Discordも個別のドキュメントが用意されています）
3. ブラウザ自動化。ヘッドレスChromiumでスクリーンショットを撮ったりページを読ませたりできるので、使えばアクセス先に痕跡が残ります

逆に言えば、この3つを塞いでOllamaだけに繋いでおけば、会話もドキュメントも認証情報も ~/.octop/ の中で完結します。加えて、ワークスペースから外へ出る前に機微な情報を伏せる仕組みと、危険なシェルコマンドに明示的な承認を挟むガードレールが標準で入っています。

「外に出さない」を本気で狙うなら、まずチャンネル連携を空のままにしておくこと。これが一番効きます。

家族と同僚、共有の単位が違えば設定も違う

マルチユーザーはJWT認証で、利用者ごとにワークスペースが分離されます。octop user のサブコマンドに create list passwd role disable delete が揃っていて、サーバにログインせずローカルDBに対して直接叩けるのが実用的です。

家庭で使うなら、octop run --host 0.0.0.0 --port 8088 でLANに開けて、家族それぞれのアカウントを切ります。同じ1台の中にいるのに、お互いの会話やファイルは見えません。小規模チームで使うなら、ここにSSL関連のフラグ（--ssl --certfile --keyfile）と octop backup auto の自動バックアップを足しておきたいところです。autoは octop run のプロセスの中でスケジュールされるので、外にcronを組む必要はありません。

家族と同僚で何が違うか。家族は「お互いに見えなければ十分」ですが、チームは「消えたときに誰が困るか」が変わります。共有の輪を広げるほど、bindするアドレスとバックアップの頻度を先に決めておくべきです。

MBTIペルソナの正体は、SOUL.mdというシステムメッセージ

Octopの紹介で必ず出てくるのが16種類のMBTIペルソナなんですが、実装を追うとこれは性格診断アプリ的なものではありませんでした。エージェントのレコードに persona_mbti という列があって、そこに入ったコードに対応するプロファイルが、起動時に SOUL.md としてレンダリングされる。この SOUL.md がそのままエージェントのシステムメッセージになります。

ペルソナを指定しなければ、素直で有能なデフォルトのトーンになります。カスタムのシステムプロンプトを書いた場合は、ペルソナを置き換えるのではなく後ろに追記される。つまりペルソナが土台で、個別の指示はその上に乗る構造です。

共有環境でこれが効くのは、性格が面白いからではありません。同じサーバに何体もエージェントがいるとき、役割の違いを毎回プロンプトに書かずテンプレートで固定できるからです。家族それぞれのエージェントを作るなら、この差分が管理コストをそのまま下げてくれます。

1台で足りないものと、今日決める3つ

正直に弱点も書いておきます。全部入りの単一プロセスは、裏返せば単一障害点です。落ちたらダッシュボードもIM連携も定期実行も同時に止まります。リモートデスクトップやブラウザ自動化まで有効にすると、家庭の余り物マシンでは荷が重い場面も出てくるはずです。バージョンもまだベータタグの付いたリリースが流れている段階で、オープンなIssueは200件を超えています。

仕事の基盤に据えるには早い。でも家の1台で回す分には、この若さは許容範囲だと思っています。

試すなら、決めるのは次の3つだけです。

• 導入方式。常時起動させたいならDocker Compose、今夜触るだけならワンラインインストーラ
• LLM接続先。データを外に出したくないならOllama、精度優先ならエージェント単位でクラウドを混ぜる
• 共有範囲。自分だけなら既定の 127.0.0.1 のまま、家族に開けるなら --host 0.0.0.0 とアカウント作成までやる

octop init から octop run までは数分です。先に3つを決めておけば、あとで迷うのはモデル選びだけになります。