セルフホスト型AIアシスタントOSS「Octop」の仕組みと特徴

社内やチームで AI アシスタントを共有したい一方で、会話ログ・作業用ワークスペース・API キーを外部 SaaS に置けないという制約は珍しくありません。情報管理ポリシーの観点から、まずセルフホストできる選択肢を探すところから検討が始まるケースもあります。

ところが、いざセルフホストに寄せると別の負担が出てきます。チャット UI、モデルプロバイダへの接続、ユーザー認証、IM（チャットツール）連携、定期実行のスケジューラ。これらを個別のプロダクトで組み合わせると、プロセスも設定ファイルも増え、「誰が何を管理するのか」が曖昧になりがちです。小規模なチームでは、この構成管理コストが導入の実質的な障壁になります。

Tencent Cloud が公開している Octop は、この領域に対して「全部を 1 つのプロセスで動かす」というアプローチを採っている OSS です。Web ダッシュボード・CLI・IM チャネル・cron（定期実行）が octop run という単一コマンドで同時に立ち上がり、データは実行ホストの ~/.octop/ 配下に閉じる設計になっています。

ただし、公開は 2026 年 7 月で、本記事執筆時点では公開から約 3 か月。スター数も Open WebUI や LibreChat とは桁が違います。初見で「候補に残すべきか」を判断するには、機能の一覧ではなく設計上の差分と現在の成熟度を分けて見る必要があります。

本記事では、Octop の公開ドキュメント（README・docs/ 配下）と GitHub API の取得値（2026 年 10 月 4 日時点）だけを根拠に、次の 3 点を整理します。本記事はドキュメントベースの整理であり、インストール・動作検証は含みません。 実環境での検証は読者側で行う前提でお読みください。

• Octop が何をする OSS で、どの規模・どの制約の組織を想定して設計されているか
• 単一プロセス設計・マルチユーザー分離・エキスパート単位の分離が具体的に何を意味するか
• Open WebUI / LibreChat / OpenClaw といった類似 OSS との棲み分けと、採用前に確認すべき項目

Octopとは｜セルフホスト型AIアシスタントOSSの位置づけ

Octop は、GitHub 上の TencentCloud organization で MIT ライセンスのもとに公開されている、セルフホスト前提の AI アシスタント基盤です。リポジトリの description は「A smarter, self-hosted AI assistant — multi-user, multi-agent.」とされており、セルフホスト・マルチユーザー・マルチエージェントの 3 点が自己定義の軸になっています（出典: TencentCloud/Octop）。

README は想定利用者を個人・家庭（households）・小規模チームと明示しています。つまり、大規模組織向けのエンタープライズ基盤として売り出しているのではなく、「自分やごく小さなチームが日常的に使うアシスタント環境を、自分の管理下に立てる」ことを目的に設計されたプロダクトです。この前提は採用判断の入口として重要で、数百ユーザー規模の全社展開を想定している場合は、そもそも設計意図から外れます。

Octopが解決しようとしている課題

Octop が前面に出しているのは "fully self-hosted" と local-first という考え方です。README の Security & privacy セクションでは、設定・チャット履歴・ワークスペース・資格情報のすべてが実行ホストの ~/.octop/ 配下に置かれると説明されています。加えて、LLM プロバイダ・ストレージバックエンド・IM チャネルを差し替え可能にすることで、特定ベンダーへのロックインを避ける方針も明記されています。

もう一つの軸が「構成の単純さ」です。README は、ダッシュボード・CLI・IM・cron が octop run 一つで立ち上がると説明しています。チャット UI と推論基盤とスケジューラを別々に運用する構成と比べ、監視対象のプロセスと設定の分散を抑えられる点が、小規模チームにとっての主要な訴求になっています。

想定される利用シーン

README の「What can you do with Octop」に挙げられている用途は、おおむね次の 6 系統に整理できます。

この一覧を見て「自分が欲しいのはチャット UI だけ」であれば、後述する比較のとおり Open WebUI のような UI 専業の OSS が適します。逆に「IM からも CLI からも同じエージェントに話しかけたい」「定時実行まで同じ環境で面倒を見たい」という要件があるなら、Octop の設計が噛み合う可能性があります。

Octopの基本情報｜ライセンス・技術スタック・開発状況

採用判断に直結する数値と事実を先に押さえます。以下はいずれも 2026 年 10 月 4 日時点に GitHub API（gh api /repos/TencentCloud/Octop および関連エンドポイント）から取得した値です。

リポジトリの基本指標

ライセンスは MIT で、商用利用・改変・再配布を前提とした採用のハードルは低い部類です。リポジトリはアーカイブされておらず、フォークでもないため、本家として開発が継続している状態です。最終 push は取得日の前日であり、コードベースは動いています。

技術スタックと依存関係

README の Core Technology セクションに記載されている構成です。

Octop 本体は、機能ごとに切り出された関連プロジェクトを束ねる構成になっています。README の Related projects に挙げられている 4 つが土台です。

依存が複数リポジトリに分かれている点は、障害切り分けの際に追う範囲が広がることを意味します。一方で、公式ドキュメントによればビルド済みのダッシュボード SPA が wheel に同梱されるため、インストール自体はフロントエンドのビルド工程を伴いません。

開発状況の読み方

アクティビティに関する取得値は次のとおりです（いずれも 2026 年 10 月 4 日時点）。

この数値の読み方は 3 点に整理できます。

1 点目は公開から約 3 か月という時間軸です。リポジトリ作成が 2026-07-08 なので、長期運用の実績が外部から観測できる段階ではありません。「数年動いている OSS を選びたい」という要件があるなら、この時点で候補から外す判断も合理的です。

2 点目はバージョン付番です。最新リリースは v1.0.2b5 で、1.0 系に到達しているものの beta を示す b サフィックスが継続しています。README のバージョンバッジも同じ 1.0.2b5 表記です。メジャーバージョンの数字だけを安定性の指標として読むと実態を取り違える可能性があります。

3 点目はリリース間隔です。9 月 23 日から 29 日までの 1 週間で 5 本のリリースが出ており、更新頻度は高い状態です。これは活発な開発の証拠として読める一方、短期間でのバージョン追従が必要になる可能性も示しています。後述するアップグレード運用の確認が重要になるのはこのためです。

なお open issue 370 件 / open PR 391 件という数値は取得日時点の事実として提示するもので、件数の多寡だけから品質を断定することはできません。注目度の高いリポジトリでは issue も PR も自然に積み上がります。採用を検討する段階では、件数ではなく自社の用途に関係する issue が放置されていないかを個別に確認するのが実務的です。

単一プロセス設計｜Octopのアーキテクチャと状態復元

Octop の設計上の最大の特徴は、スタック全体を 1 プロセスで完結させている点です。公式ドキュメントの docs/architecture.md は、この方針を次のように明言しています。

The whole stack is one process. There is no separate worker, no external queue, no required external services beyond whatever LLM provider the user configures.

出典: https://github.com/TencentCloud/Octop/blob/main/docs/archit…

別ワーカー・外部キュー・外部必須サービスを持たない（ユーザーが設定する LLM プロバイダを除く）という設計です。この判断の背景は ADR として文書化されており、docs/adr/001-single-process-model.md で単一プロセスモデルの意思決定記録を、docs/adr/002-database-backends.md でデータベースバックエンドの選択理由を確認できます。設計意図を追いたい場合は README よりこの 2 本を先に読むほうが早いでしょう。

レイヤ構成と起動シーケンス

レイヤ構成は公式ドキュメントに次の図として示されています。

┌──────────────────────────────────────────────────────────────────┐
│  Surface          │  Dashboard (React)   CLI (click)   HTTP API │
├──────────────────────────────────────────────────────────────────┤
│  API layer        │  FastAPI routers       WS / SSE / JSON        │
├──────────────────────────────────────────────────────────────────┤
│  Domain layer     │  AgentManager   Gateway   GlobalProcessor     │
│                   │  CronManager    UserManager   SharedServices │
├──────────────────────────────────────────────────────────────────┤
│  Reusable libs    │  octop-harness   octop-gateway            │
├──────────────────────────────────────────────────────────────────┤
│  Storage          │  SQLite or PostgreSQL control plane + file workspaces│
└──────────────────────────────────────────────────────────────────┘

出典: https://github.com/TencentCloud/Octop/blob/main/docs/archit…

Surface 層に Dashboard（React）・CLI・HTTP API が並び、その下の API 層（FastAPI）を経て Domain 層のマネージャ群に到達します。再利用ライブラリとして octop-harness（LangGraph ベースのチャットランタイム）と octop-gateway（IM チャネルパイプライン）が位置し、ストレージはコントロールプレーン DB とファイルワークスペースに分かれます。

起動時の依存順も同じドキュメントに記載があります。

OctopServer.start()
 ├─ PathLayout.from_env()            (root + DB + secrets dirs)
 ├─ load_config(config.json)        (env overrides on top)
 ├─ open_database()                  (SQLite WAL or PostgreSQL via PostgresPool)
 ├─ run_migrations()                 (infra/db/migrations/*.sql, versioned)
 ├─ SharedServices (repos + factories)
 ├─ WizardTokenStore                 (5-min TTL setup tokens)
 ├─ ExpertCatalog  / SubagentCatalog (bundled MD libraries)
 ├─ PluginManager.seed_bundled() then load_installed()  (~/.octop/plugins/*; bundled default off)
 ├─ AgentManager (global registry — one per process)
 │    └─ for each agent row: builds HarnessAgentRuntime on demand
 │       ├─ HarnessAgent (LangGraph)
 │       ├─ GlobalProcessor (slash dispatch + chunk projection)
 │       └─ BackendWorkspace (filesystem or remote storage adapter)
 ├─ Gateway                         (IM channels + WS hub + cron trigger source)
 │    ├─ ChannelManager (one per agent that has a channel row)
 │    └─ WebSocketHub  (dashboard + CLI channel)
 ├─ CronManager (process-wide APScheduler)
 └─ UserManager (auth + per-user lookups)

出典: https://github.com/TencentCloud/Octop/blob/main/docs/archit…

実務上の意味は 2 つあります。1 つは、プロセスを再起動すればコントロールプレーン DB から状態が再構築されることです。README もアーキテクチャセクションで「Restart rebuilds state from the control-plane database」と述べています。エージェント定義・チャネル設定・cron ジョブは DB の行として保持されるため、起動スクリプト側に状態を持たせる必要がありません。もう 1 つは、スケジューラがプロセス全体で 1 つの APScheduler に集約されている点です。cron ジョブを複数ノードに分散させる構成は、公式ドキュメントでは言及されていません。

したがって、「1 台のホストで運用する」前提なら構成管理の手間は小さく、逆に「水平スケールさせたい」要件に対しては公式情報の範囲では設計上の裏付けが確認できません。スケールアウトを前提にするなら、この点を事前に issue や ADR で確認する必要があります。

データの置き場所

ローカルに何が置かれるかは、README の Data directory セクションに具体的なツリーで示されています。

~/.octop/                          ← install & data root
├── config.json                    # process config (optional database section)
├── octop.db                       # SQLite — users, agents, channels, cron, …
├── secrets/                       # JWT secret, channel tokens
├── agents/<agent_id>/             # per-agent workspace (SOUL.md, skills, …)
├── security/tool_guard/           # shell command allow/deny rules
├── logs/                          # runtime logs
├── venv/                          # uv-managed Python (installer layout)
└── bin/octop                      # PATH wrapper → venv/bin/octop

出典: https://github.com/TencentCloud/Octop

JWT シークレットと IM チャネルのトークンが secrets/ に、シェルコマンドの許可・拒否規則が security/tool_guard/ に、エージェントごとのワークスペースが agents/<agent_id>/ に置かれます。バックアップ設計を考えるうえでは、このディレクトリと後述のコントロールプレーン DB の扱いが出発点になります。

SQLiteとPostgreSQLの使い分け

コントロールプレーン（users / agents / providers / channels / cron / sessions / audit / JWT シークレット）の保存先は、既定の SQLite（WAL モード）と、任意で選べる PostgreSQL の 2 択です。マイグレーションは NNN_*.sql（SQLite）と NNN_*.pg.sql（PostgreSQL）としてバージョン管理されており、起動時に適用されます。

PostgreSQL を選んだ場合、エージェントメモリも既定で同一 DSN（エージェントごとのスキーマ）を再利用します。メモリだけはファイルベースのまま維持したい場合の設定は、README に次のスニペットで示されています。

"memory": { "backend": { "type": "sqlite" } }

出典: https://github.com/TencentCloud/Octop

単一ホストで個人利用に近い使い方をするなら SQLite のままで足りますが、定期バックアップ・可用性・外部からの参照といった要件があるなら PostgreSQL を選ぶ判断になります。選択の背景は前述の ADR（002-database-backends.md）に記録されています。

なお会話の経路についても補足すると、公式ドキュメントの会話サーフェス表では、Web UI・CLI・IM チャネル・cron のすべてが同一のエージェントランタイムに接続する構造が示されています。Web UI のストリーミングは WebSocket（/api/agents/{aid}/chat/ws）に移行済みで、旧来の SSE エンドポイントは双方向 WebSocket に置き換えられ、chat/hitl/resume のみ SSE が継続しているとされています。「IM から話しかけたエージェントと Web UI 上のエージェントが別物になる」という構造ではない点が、複数の入口を用意したい用途では効いてきます。

マルチユーザーとマルチエージェント｜エキスパートとAgentTeams

Octop の「multi-user, multi-agent」が具体的に何を分離しているのかを、「何が分かれ、何が共有されるか」の軸で整理します。社内導入を検討する際、ここが最大の確認事項になります。

ユーザーとエージェントの分離単位

公式ドキュメントによれば、すべてのリクエストは JWT で認証されて User 行に解決され、エージェントの所有権は行レベル（agents.user_id と呼び出し元の照合）で強制されます。管理者ロールはこの照合をバイパスできる設計です。また、ユーザーごとに AgentManager を持つ旧構成は廃止され、プロセス全体で 1 つのグローバルレジストリが該当ランタイムにディスパッチする方式に変更済みとされています。

ダッシュボード（React SPA）は常に /api の HTTP / WebSocket 経由でアクセスし、Python モジュールを直接 import したり SQLite ファイルを直接開いたりしない、という境界も明記されています。フロントエンドとバックエンドの責務が分かれているため、リバースプロキシ配下に置く構成の見通しは立てやすいでしょう。

エキスパート（役割を定義したエージェント）単位では、ワークスペース・モデルプロバイダ・IM チャネル・cron ジョブがそれぞれ独立します。つまり「経理用エキスパートは特定の IM チャネルと定時ジョブだけを持ち、開発支援用エキスパートは別のモデルプロバイダを使う」といった分け方が、設定上そのまま表現できます。

ワークスペースのバックエンドは差し替え可能で、README ではローカルディスク・Docker サンドボックス・PostgreSQL・COS / S3 が挙げられています。コントロールプレーン DB とは分離されているため、「メタデータは PostgreSQL、作業ファイルはオブジェクトストレージ」という構成も設計上は想定されています。

エキスパートの再利用と共有

README の Highlights には、エキスパートを再利用するための仕組みが複数挙げられています。

• エキスパートライブラリ: 起動時に agents/experts/library/ をスキャンし、シナリオごとに専門家を切り替えられる
• エキスパートマーケット: エキスパートやスキル・サブエージェントのプールを公開し、デプロイ内で共有する
• MBTI ペルソナ: 16 パターンの人格テンプレートと対話式の診断を備える
• ナレッジベース: 自前ドキュメントに対する RAG をデプロイ内のコーパスとして共有する
• プラグイン: サードパーティプラグインを導入・切り替えできる（同梱プラグインは seed 済みだが既定は無効）
• ポータブルメモリ: Octop Memory により、ワークスペースの移動に合わせて記憶も移動する

チームで使う観点では、「誰かが作ったエキスパート定義を他のメンバーが流用できる」ことが運用コストの削減に直結します。一方、共有範囲がデプロイ内に限られる点は、組織をまたいだ再利用を期待する場合には制約になります。

AgentTeams（Beta）での多段タスク分担

複数のエキスパートに多段のタスクを割り振る機能が AgentTeams です。README は、コーディネーターが複数のエキスパートをスケジュールする構成であると説明し、詳細を docs/expert-teams.md に委ねています。

ここで重要なのは、AgentTeams が Beta として位置づけられていることです。README のロードマップでも「In progress」に分類されています。マルチエージェントの協調動作を本番業務の前提に組み込む設計を考えている場合、Beta 機能への依存度がそのままリスクになります。採用判断の段階では「AgentTeams を使わない構成でも要件を満たせるか」を確認しておくほうが安全です。

なお README のロードマップには「This roadmap may shift as the community grows; treat it as indicative only.」という注記があり、Planned に並ぶ項目（Managed Agents、Project 単位ワークスペース、プラグインマーケット等）は確定事項として扱えません。将来の機能追加を前提にした採用判断は避けるべきです。

セルフホスト前提のセキュリティ機構

README の Security & privacy セクションに挙げられている機構は次の 4 点です。

エージェントにシェルコマンドの実行を許す構成では、許可・拒否規則をファイルとして管理できることが運用上の前提条件になります。Octop はこれをデータディレクトリ内の編集可能なファイルとして持っているため、構成管理ツールでの配布・レビューの対象にしやすい形です。ただし、規則の具体的な記述方法や既定値の厳しさは公式ドキュメントで個別に確認する必要があります。

対応チャネルと拡張の仕組み｜IM連携・Connectors・ACP

対応IMチャネルと必要な資格情報

README の「Supported channels」表に基づく対応チャネルと、必要な資格情報です。

その他（Yuanbao / Xiaoyi / MQTT 等）はゲートウェイ経由で扱われます。

日本の読者にとって実務的な論点は、この対応表が中国圏の IM を中心に構成されていることです。Feishu・DingTalk・WeCom・QQ・WeChat が並び、グローバル系は Telegram と Discord の 2 つです。なお Slack と LINE については README の対応表に記載がありません。これは「公開情報では対応の有無を確認できない」という事実であり、非対応と断定できるものではありません。社内で Slack や LINE WORKS を使っている場合は、ゲートウェイ経由での実現可否を公式リポジトリの issue や docs/ で個別に確認する必要があります。

対応 LLM プロバイダは、OpenAI 互換 API・DashScope（Qwen）・Ollama、およびその他のプリセットです。設定はエージェント単位で、ダッシュボードまたは octop provider から行います。OpenAI 互換 API に対応しているため、互換エンドポイントを提供する多くのサービスやセルフホスト推論基盤を接続先にできる見込みはありますが、個別の組み合わせの動作は公式情報の範囲では保証されていません。

Connectors・プラグイン・ナレッジベースによる拡張

Connectors は OAuth と MCP（Model Context Protocol）ゲートウェイを土台にした外部サービス連携の仕組みで、README では Tencent 系サービス（Docs / Meeting / News 等）が例示されています。自社で使っている SaaS を繋ぎたい場合、MCP サーバを介した接続が現実的な経路になります。

プラグインはサードパーティ製のものを導入・切り替えできますが、同梱プラグインは seed 済みで既定は無効です。有効化は明示操作が必要という設計で、初期状態で不要な機能が動かない点は運用上扱いやすい挙動です。

ナレッジベースは、自前ドキュメントに対する RAG をデプロイ内のコーパスとして共有する機能です。社内文書を参照させたい用途では、この機能の仕様とインデックス更新の運用方法が確認ポイントになります。

このほか、ヘッドレス Chromium による Web 自動化とスクリーンショット取得を担う Browser AI+、ブラウザ上の対話シェルである Terminal AI+、ダッシュボードから Linux / Windows / macOS の画面・入力を操作するリモートデスクトップ機能が README に挙げられています。Windows / macOS / Linux のネイティブデスクトップクライアントと、FnOS（NAS）向けパッケージの提供も記載されています。

ACPによるIDE・コーディングエージェント連携

開発支援の文脈で特徴的なのが、ACP（agent-client-protocol）による双方向連携です。README によれば、octop acp で Octop のエージェントを IDE やターミナル AI に提供できる一方、逆方向として OpenCode / CodeBuddy / Claude Code / Codex といったコーディングエージェントへ権限ゲート付きで委譲することもできます。

つまり Octop を「IDE から呼ぶ側」としても「IDE 側の AI を呼ぶ側」としても構成できる設計です。既存のコーディングエージェントを置き換えずに共存させたい場合に意味を持つ機構で、詳細は docs/acp.md に記載されています。CLI 全体のコマンド体系は docs/cli.md を参照すると把握しやすいでしょう。

主な CLI コマンドは octop init / octop run / octop service start|stop / octop agent / octop channel / octop chats / octop acp / octop cron / octop models / octop skills / octop plugin / octop backup / octop clean / octop memory list|slim / octop update です。ダッシュボードを使わずに CLI だけで一通りの管理ができる構成になっています。

類似OSSとの違い｜Open WebUI・LibreChat・OpenClawとの比較

セルフホスト型の AI 関連 OSS は選択肢が多く、「どれを選ぶか」の判断には目的レイヤの違いを押さえる必要があります。ここでは代表的な 4 件と Octop を比較します。スター数・ライセンス・最終 push はいずれも 2026 年 10 月 4 日時点に gh api /repos/{owner}/{name} で取得した値です。

比較表

最初に明確にしておくべきは、スター数で見れば Octop は比較対象より大幅に小さく、人気を根拠に選ぶ OSS ではないという点です。コミュニティ規模・日本語の情報量・UI の作り込みという観点では、Open WebUI や LibreChat のほうが厚みがあります。採用するとすれば「要件に合致するから」という理由に限られます。

チャットUI中心のOSS（Open WebUI / LibreChat）との違い

Open WebUI は、セルフホストできるチャット UI として広く使われています。モデルフロントエンドとしての完成度が主な価値で、推論基盤（Ollama 等）は別途用意する前提です。LibreChat は ChatGPT 互換の UI を持つマルチモデル対応のチャット基盤で、マルチユーザー認証（SSO 連携の記述あり）の作り込みが強みです。実装は TypeScript で、既定構成では DB を含む複数サービスを併用します。

この 2 つと Octop の差分は、カバーする範囲にあります。「ブラウザから LLM と会話する環境が欲しい」だけであれば、Open WebUI や LibreChat のほうが導入が速く、情報も多く、UI も成熟しています。一方で「IM からも CLI からも同じエージェントに話しかけたい」「エキスパートごとに定期実行ジョブを持たせたい」という要件が出てくると、Open WebUI / LibreChat では別のコンポーネントを組み合わせる必要が生じます。Octop はその範囲を 1 プロセスに畳み込んでいる点が差分です。

実作業エージェント・アプリ開発基盤（OpenClaw / Dify）との違い

OpenClaw は「The AI that really does things. Any OS. Any Platform.」という description のとおり、OS やプラットフォームを横断して実作業を行うエージェント本体が主目的です。Octop も Browser AI+ やリモートデスクトップで実作業の機能を持ちますが、設計の中心は「マルチユーザーのアシスタント基盤」であり、JWT による分離・管理者ロール・エキスパート共有といった基盤側の作り込みに重心があります。目的レイヤが異なります。

Dify はエージェンティックワークフローや RAG パイプラインを構築するアプリ開発プラットフォームです。「作って配る」ための基盤であり、個人やチームが日常的に使うアシスタント環境を立てる Octop とはレイヤが分かれます。両者は競合というより、用途が重なる局面が限定的な関係です。

Octopを選ぶ条件・選ばない条件

ここまでの整理から、判断の軸をまとめます。

候補に入りやすい条件

• Web ダッシュボード・CLI・IM・定期実行を 1 つのプロセスで完結させたい（運用対象プロセスを増やしたくない）
• エキスパート単位でワークスペース・モデルプロバイダ・IM チャネル・cron まで分離したい
• 会話・ワークスペース・資格情報を実行ホスト配下に閉じ込めたい（local-first 要件）
• 使用している IM が Feishu / DingTalk / QQ / WeChat / Telegram / Discord / WeCom のいずれかに該当する
• MIT ライセンスでの商用利用・改変を前提にしたい
• 1 台のホストで個人〜小規模チーム規模の利用を想定している

候補から外したほうがよい条件

• 必要なのはチャット UI だけ（Open WebUI / LibreChat のほうが導入が速く、情報量も多い）
• 数年単位の運用実績があるプロジェクトを選びたい（公開から約 3 か月・beta 付番継続）
• 日本語のドキュメントや国内の導入事例を前提に社内説明をしたい（日本語の解説記事は本記事執筆時点で確認できていません）
• Slack / LINE 系の IM 連携が必須要件（README の対応表に記載がない）
• 水平スケール・複数ノードでの cron 分散を前提にしたい（公式ドキュメントで言及されていない）
• マルチエージェントの協調動作（AgentTeams）を本番の中核機能として使いたい（Beta）

Octop導入前に確認したい判断ポイント

ここまでの内容を踏まえ、採用判断の前に確認すべき項目を整理します。

環境・ポリシー面の確認項目

1. 使用している IM とモデルプロバイダが対応表にあるか。これが最も早く結論が出る確認項目です。Slack / LINE 系が必須なら、ゲートウェイ経由の実現可否を先に確認する必要があります。
2. Beta 機能に本番依存しない構成で要件を満たせるか。AgentTeams を外した構成で足りるかを先に確認しておくと、後戻りを避けられます。
3. インストーラの配布元が自社ネットワークポリシーと整合するか。README のワンライナーは Tencent Cloud の COS ドメイン（*.myqcloud.com）から取得します。許可ドメインを限定している環境では、この配布元の扱いが論点になります。代替経路として PyPI（octop パッケージ）・Docker・ソースビルドが README に記載されています。
4. コントロールプレーンを SQLite のままにするか PostgreSQL にするか。バックアップ頻度・可用性・外部からの参照要件から逆算して決めます。環境変数と config.json の詳細は docs/configuration.md にまとまっています。
5. アップグレード運用を回せるか。README によれば octop update は wheel / バイナリのみを置き換え、~/.octop/ 配下の DB・ワークスペース・シークレット・config.json は保持されます。スキーマは次回起動時に自動マイグレーションされます。ただしクロスバージョンのアップグレード前には octop backup の実行が推奨されています。前述のとおりリリース間隔が数日単位であるため、追従方針を決めておく価値があります。
6. 英語の一次情報を読み続けられるか。本記事執筆時点で日本語の解説記事・導入記事は確認できておらず、README と docs/ 配下が実質的に唯一の情報源です。公式サイトは octop.cloud にありますが、トラブルシューティングは GitHub 上の情報に依存します。

導入手順の確認

README の Quick Start に記載されている手順は次のとおりです。以下はすべて README からの引用です。

macOS / Linux 向けのワンライナーインストーラ:

curl -fsSL https://finnie-1258344699.cos.ap-guangzhou.myqcloud.com/octop/install.sh | bash

出典: https://github.com/TencentCloud/Octop

初期化:

octop init

出典: https://github.com/TencentCloud/Octop

起動:

# Foreground (API + Web dashboard)
octop run

# Custom host / port
octop run --host 0.0.0.0 --port 8088

# Register as a system service (systemd / launchd / Windows service)
octop service start

出典: https://github.com/TencentCloud/Octop

本番向けとして README が推奨しているのは Docker 構成です。

# Build and start
docker compose -f docker/docker-compose.yml up -d

出典: https://github.com/TencentCloud/Octop

既定のアクセス先は http://127.0.0.1:8088 です。API ドキュメントは /api/docs で提供されますが、config.json の "enable_api_docs": true で有効化する必要があり、既定は無効です。パスワードは 8 文字以上・英数字混在が要求され、Docker の初回起動時は OCTOP_DEFAULT_PASSWORD が未設定の場合にランダム生成され /data/.octop/credential.txt に書き出されます。

なお、インストーラは Python の事前インストールを必要とせず、uv を使って ~/.octop/ 配下に隔離された Python 3.12 環境を用意するとされています。既存の Python 環境を汚さない構成は、検証段階では扱いやすい性質です。

本記事の前提と、読者側で検証すべき範囲

本記事の記述は、GitHub API の取得値（2026 年 10 月 4 日時点）と公開ドキュメント（README・docs/ 配下）に基づく整理です。インストールや動作の検証は行っていません。 したがって、以下については読者自身の環境での確認が必要です。

• 上記コマンドが自社環境で期待どおり動作するか
• 使用しているモデルプロバイダ（特に OpenAI 互換エンドポイント）との実際の互換性
• 想定ユーザー数・同時セッション数における挙動とリソース消費
• PII マスキングやツールガードレールが自社の情報管理ポリシーを満たす粒度で設定できるか

また、公式情報で確認できなかったため本記事で扱っていない事項として、商用サポート・有償プラン・SLA の有無、ベンチマークや性能数値、日本語 UI / 日本語ドキュメントの提供状況、Slack / LINE 対応の有無があります。これらが判断に必要な場合は、リポジトリの issue や Discussions で直接確認するのが確実です。公式サイト（octop.cloud）の掲載内容についても、本記事では根拠として扱っていません。

まとめ

本記事では、Tencent Cloud が MIT ライセンスで公開しているセルフホスト型 AI アシスタント OSS の Octop について、公開ドキュメントと GitHub API の取得値（2026 年 10 月 4 日時点）の範囲で設計と現状を整理しました。

設計上の強みは、Web ダッシュボード・CLI・IM・cron を外部キューや別ワーカーなしに 1 プロセスで提供する構成、エキスパート単位でワークスペース・プロバイダ・チャネル・cron まで分離できる粒度、そしてデータを ~/.octop/ 配下に閉じる local-first の方針です。一方の制約は、公開から約 3 か月という時間軸、v1.0.2b5 という beta 付番の継続、AgentTeams が Beta である点、IM 対応表が中国圏中心である点、日本語情報がほぼ存在しない点に集約されます。

候補に入れる価値があるのは、「1 台のホストで、個人から小規模チーム向けに、複数の入口（Web / CLI / IM）と定期実行をまとめて自前運用したい」という要件があり、使用中の IM とモデルプロバイダが対応範囲に収まる場合です。必要なのがチャット UI だけなら Open WebUI や LibreChat のほうが近道であり、運用実績の長さを重視するなら現時点では見送る判断も合理的です。判断材料が揃った段階で、自社のネットワークポリシー・バックアップ要件・IM 環境と照合してください。

関連情報

社内向け AI 基盤の技術選定やセルフホスト環境の構築・運用についてご相談を検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。