ホスト型とセルフホストのパーソナルエージェントのどちらを選ぶかは、「手軽さ」と「プライバシー」のどちらを取るかという話ではありません。システムのそれぞれの部分を誰が運用するのか、データがどこへ移動するのか、どの障害が自分の責任になるのかを選ぶことです。
この違いは、単純なチャットアプリよりもパーソナルエージェントにとって大きな意味を持ちます。エージェントは進行中の Task を抱え、モデルを呼び出し、ウェブを検索し、ほかのサービスにつながり、コンピューター環境で作業し、あとで結果を持って戻ってくることがあります。アプリケーションを自分のマシンに移せば、そうした境界の一部は変わります。しかし、すべての依存関係が自動的に一緒に移るわけではありません。
Comma はどちらの道も用意しています。Comma が運用するホスト型のサービスと、Docker Compose で動かせる オープンソースのデプロイ です。どちらの形でも製品としては同じものだとわかりますが、運用のモデルと一部の機能は同じではありません。このガイドでは、セルフホストを勲章のように扱うことも、ホスト型のソフトウェアを誰もが避けるべき妥協のように扱うこともせずに、そのトレードオフを説明します。
短い答え
エージェントを使いたいけれど、そのインフラの運用者にはなりたくないなら、ホスト型の Comma を選びましょう。Comma がサービスを動かし、ホスト型ワークスペースのデータを保存し、更新とバックアップを担い、ワークスペース用のクラウドコンピューターを提供します。ホスト型の製品には、Comma が紹介している会議録音の機能も含まれます。その管理されたサービスと引き換えに、アカウント、プラン、データの扱い、可用性に関するサービスの境界を受け入れることになります。
アプリケーションスタック、データベース、モデルの設定、デプロイ環境を自分で管理することが運用の手間に見合うなら、セルフホストの Comma を選びましょう。インスタンスは自分が管理するマシンで動き、アプリケーションのデータは自分が運用するデータベースとオブジェクトストレージに置かれます。アップグレード、バックアップ、公開ネットワークの設定、容量、監視、障害からの復旧も自分の担当です。モデルの呼び出しや任意の連携は、それでもデータを外部の提供元に送ることがあります。
どちらを選んでも、権限と接続したサービスを理解しておく必要はなくなりません。役に立つ問いは、単に Comma はどこにインストールされているか？ ではありません。それぞれのコンポーネントを誰が動かしていて、この Task が実行されるとき情報はどこへ行くのか？ です。
比べるのはスローガンではなく、誰が担うか
公式のセルフホストガイド は、この分担を具体的に示しています。
これは機能の採点表ではありません。ある人にとっては、5 つの永続ボリュームとリバースプロキシを管理するのは余計な手間です。別の人にとっては、アプリケーションとその記録を自分が管理するインフラに置くことこそが、この製品を使う一番の理由です。より良い選択肢とは、その責任を実際に担い続けられるほうです。
データの経路をたどる
「セルフホスト」が表すのは、Comma のスタックがどこで動くかです。すべてのデータがそのマシンにとどまるという意味ではありません。
初期設定のセルフホストスタックでは、Task、チャット、ファイルは自分が運用するサービスに保存されます。Compose のデプロイには、Comma のサーバーとクライアントに加えて、PostgreSQL、Redis、ClickHouse、MinIO、設定ボリュームが含まれます。Comma のガイドによれば、このスタックは分析データやトレースを Comma に送りません。これは役に立つ境界ですが、データの流れの分析はここで終わりではありません。
エージェントがモデルを呼び出すと、リクエストはそのインスタンスに設定したモデルの提供元に送られます。ウェブ検索やページの読み取りのために Exa のキーを追加すれば、関係するリクエストは Exa に送られます。インスタンスを公開するなら、ログインコードのために実際のメールサーバーが必要です。接続したアプリやエージェントが使うウェブサイトは、それぞれ独自のデータの扱いを持つ別のサービスのままです。リバースプロキシ、DNS の提供元、ホスティング会社、バックアップの保存先も、自分で設計する運用の経路の一部になるかもしれません。
ホスト型の Comma は、経路が異なります。Comma がアプリケーションを運用してホスト型ワークスペースのデータを保存し、モデルや連携の経路はホスト型の設定と自分が選ぶサービスによって決まります。ホスト型ならサーバーの管理は要りませんが、何を接続するか、Task がどの情報を使うべきかを決める必要はなくなりません。
どちらのデプロイでも、プライバシーについて大まかな結論を出す前に、現実的なワークフローをひとつ書き出してみてください。Task が外部のモデルを使って Drive のドキュメントを要約するなら、次のように問います。
Task とドキュメントへの参照はどこに保存されるか？
どのサービスが元の資料を取りに行くか？
モデルへのリクエストにはどんな内容が含まれるか？
どの提供元がそのリクエストを受け取るか？
結果、ログ、バックアップはどこに保持されるか？
接続を取り消したり、保存された状態を削除したりできるのは誰か？
この作業からは、デプロイについたラベルよりも多くのことがわかります。セルフホストなら重要な保存先と設定を直接管理できますが、経路の全体像は、自分が組み立てたワークフローそのものの性質です。
自分のモデルを使うことは、経路を決めること
Comma のセルフホストの設定では、モデルの提供元のエンドポイント、プロトコル、モデル ID、API キー、コンテキストの上限、出力の上限を設定できます。提供元への呼び出しは自分の提供元アカウントを使うので、課金と利用規約は Comma のクレジットではなく、その提供元との関係に属します。
この柔軟さによって、いくつかの構成が可能になります。自分のアカウントで商用モデルの API を使うこともできますし、互換性のあるプライベートなエンドポイントを指定することも、自分で運用するモデルを設定することもできます。これらの選択肢を「ローカル AI」とひとまとめにすべきではありません。プロンプトをクラウドのモデルに送るセルフホストの Comma インスタンスには、やはり外部へのモデルのデータ経路があります。プライベートなモデルを動かせばその経路は変えられますが、それは設定したエンドポイントと周辺のインフラが、実際に意図した境界の内側にある場合に限られます。
認証情報にも同じ注意が必要です。スタックを運用するということは、モデルのキー、生成されたシークレット、メールの認証情報、連携が使うトークンを守るということです。設定を管理できることに価値があるのは、まさに設定が責任を伴うからです。
セルフホストとは、システムを運用すること
公開リポジトリには、シングルノードの Docker Compose の出発点がひととおりそろっています。ウェブクライアント、管理クライアント、サーバーをビルドし、それを支えるデータサービスを起動します。最初の起動はローカルで行えます。ポートは初期設定ではループバックにだけバインドされ、Mailpit がログインコード用のローカルの受信箱を提供します。
ローカルで動いたからといって、本番環境の準備ができた証明にはなりません。公開するデプロイには、リバースプロキシの背後での HTTPS、ウェブアプリ、管理アプリ、製品 API それぞれに別のオリジン、そして実際の SMTP サービスが必要です。公開での登録は初期設定ではオフです。誰がインスタンスにアクセスできるか、証明書と DNS をどう管理するか、シークレットをどう保存するか、セキュリティ更新をどう適用するかを決める必要があります。
バックアップも、データベースをひとつコピーすることではなく、システム全体の性質です。Comma のガイドは、スタックを停止して 5 つの名前付きボリュームをまとめてバックアップするよう求めています。config、postgres、objects、clickhouse、redis です。設定ボリュームには暗号化キーと認証のシークレットが入っています。ほかのボリュームを残してこれを失うと、意味のある形では復元できないデータが手元に残るだけになりかねません。バックアップの計画は、復元を一度テストするまでは完成していません。
アップグレードには、さらに別の責任が伴います。メンテナンスの時間帯、ビルドに足りるディスク容量、サービスの障害を検知する手段、そして用途に見合ったロールバックや復旧の計画が必要です。エージェントが日々の仕事の一部になれば、マシンの可用性、ストレージの健全性、ネットワークの設定は、ホスト型のサービスなら代わりに引き受けてくれるはずの製品上の問題になります。
オープンソースによって、検証して変更できる範囲は変わりますが、この運用の手間がなくなるわけではありません。Comma の独自のコードは AGPL-3.0-only でライセンスされており、リポジトリでは、変更したバージョンをサービスとして提供する場合のソースコード公開の義務も説明されています。これは意味のある管理権限ですが、セキュリティ監査やサポート契約とは別物であり、特定のデプロイが正しく設定されていることを保証するものでもありません。
クラウドコンピューターは、2 つの道で同じ機能ではない
ホスト型の製品は、ワークスペース用のクラウドコンピューターを提供します。これによってエージェントは、ユーザーに別途環境を用意してもらわなくても、1 回のモデル呼び出しでは済まないファイル、ツール、ブラウザーのような実行が必要な仕事をするための環境を持てます。
2026 年 10 月 26 日時点で、公開のセルフホストスタックにおけるグループのクラウドコンピューターは初期設定ではオフで、Cloudflare の設定が必要です。コアのサービスが動いているからといって、リポジトリがその機能を自動的に使えるローカルのサンドボックスにしてくれるわけではありません。クラウドコンピューターでの作業が Task の中心にあるなら、アプリケーションサーバーだけでなく、そのランタイム、設定、コスト、隔離、保守も判断に含めてください。
これによって、実際の答えが変わることがあります。持続する Task、接続したモデルの呼び出し、保存されたアプリケーションデータの管理が主に必要な人なら、追加の設定を受け入れられるかもしれません。すぐに使える実行用のコンピューターがエージェントの体験の一部であることを期待する人は、Docker を動かせるとしても、ホスト型の Comma のほうを好むかもしれません。
会議録音には別のランタイムの境界がある
同じ注意は会議にも当てはまります。2026 年 10 月 26 日時点で、Comma のホスト型の体験には会議録音が含まれていますが、公開のセルフホストリポジトリによれば、会議と Agent VMM ホストには、リポジトリに含まれていないランタイムが必要です。
ですから、コアのアプリケーションをセルフホストしても、ホスト型の会議の経路がそのまま再現されるわけではありません。追加のインフラを自分で構築したり統合したりすることはできますが、その際は自分の状況に関係する権限、録音に関する法律、ストレージの設計、文字起こしの提供元を考慮する必要があります。それは自分で運用するシステムであって、標準の Compose スタックに含まれるスイッチではありません。
これは明確な製品上の境界として扱ってください。通話の録音と処理が決め手になる用途なら、現時点でホスト型とセルフホストの Comma は置き換え可能ではありません。
選ぶ前に、責任のテストを
セルフホストについていちばん役に立つ問いは、「Docker を動かせるか？」ではありません。「最初の起動に成功したあとも、このサービスを担い続けたいか？」です。
長く使えるマシンやサーバーがあり、その状態を守ってバックアップでき、自分が設定する外部の提供元を理解していて、直接の管理をデプロイの保守に見合うほど重視しているなら、セルフホストはよく合います。独自のネットワーク境界、モデルのエンドポイント、保持のプロセス、ソースレベルのカスタマイズが必要なときには、特に意味を持ちます。
サーバーよりも成果が大事なとき、管理されたクラウドコンピューターや会議の経路が必要なとき、あるいはパーソナルエージェントの可用性を自分の保守の習慣に左右されたくないときは、ホスト型の Comma がよく合います。ホスト型を選んでも、権限を慎重に設定したり、接続するものを絞ったりできなくなるわけではありません。インフラの運用を Comma に任せるというだけです。
決める前に、次の問いへの答えを書き出してみてください。
どのデータを、自分が運用するインフラに保存しなければならないか？
どのモデルの提供元が Task の内容を受け取るのか、どのアカウントで？
主なワークフローに、クラウドコンピューターや会議録音は必要か？
HTTPS、メールの配信、シークレット、更新、アクセス制御を管理できるか？
バックアップの対象は何で、復元をテストしたことはあるか？
自分がいない間に障害が起きたら、誰が気づいて直すのか？
セルフホストを選ぶのは具体的な境界のためか、それとも言葉の響きが安全そうだからにすぎないのか？
答えがばらばらの方向を指すなら、いちばん大事なワークフローを支えられるデプロイから始めましょう。抽象的な機能比較よりも、範囲の決まった Task をひとつ選び、その実際のデータの経路を見るほうが多くのことがわかります。
ホスト型とセルフホストのパーソナルエージェントについての質問
セルフホストの Comma なら、自動的にプライバシーが高まりますか？
いいえ。アプリケーションスタックとデータベースは自分の管理下に置かれ、標準のスタックは分析データやトレースを Comma に送りません。それでも、モデルの提供元、検索、メール、接続したアプリ、ネットワークのサービス、バックアップがデータを受け取ったり保存したりすることはあります。プライバシーは、設定とワークフローの全体によって決まります。
セルフホストの Comma には、Comma のアカウントやサブスクリプションが必要ですか？
公開の Docker Compose スタックには、Comma のアカウントも、Stripe も、Comma のクレジットも必要ありません。マシンは自分で用意し、モデルの提供元のアカウントかプライベートなモデルを設定します。それぞれの選択には、独自のインフラや利用量のコストがかかることがあります。
自分のモデルの提供元を使えますか？
はい。セルフホストのスタックには、提供元のエンドポイント、プロトコル、モデル、認証情報の設定があります。必要なインターフェースに対応していれば、自分で運用する提供元も使えます。ただし、Comma をセルフホストするだけで、サードパーティのモデルがローカルになるわけではありません。
セルフホスト版にはクラウドコンピューターが含まれますか？
すぐに使える初期設定としては含まれません。Comma の公式ガイドによれば、グループのクラウドコンピューターには Cloudflare の設定が必要です。ワークフローがコンピューターでの実行に依存するなら、その別の設定と運用の境界を計画に含めてください。
セルフホスト版には会議録音が含まれますか？
いいえ。公開リポジトリによれば、会議用のランタイムは含まれていません。そのため、この用途ではホスト型のサービスと標準のセルフホストスタックは異なります。
何をバックアップすべきですか？
スタックを停止した状態で、5 つの名前付きボリューム、つまり設定、PostgreSQL、オブジェクト、ClickHouse、Redis をひとまとまりとしてバックアップしてください。設定ボリュームには暗号化と認証のシークレットが入っているので、必ず残してください。アップグレードや復元の前には、最新の セルフホストガイド に従ってください。
オープンソースなら安全ということですか？
いいえ。ソースコードが公開されていれば、検証、変更、独立した運用が可能になります。安全性は、今もコード、その依存関係、自分の設定、ネットワークへの公開範囲、認証情報、更新の習慣、運用での対応に左右されます。
維持できる境界を選ぶ
ホスト型のパーソナルエージェントでは、サービスの運用者を信頼し、評価することが求められます。セルフホストのパーソナルエージェントでは、自分が運用者になることが求められます。Comma がその両方に対応しているのは、管理と手軽さのどちらを好むかが人によって違い、ふさわしい境界が任せようとする仕事によって変わるからです。
管理されたサービスを使いたいなら、ホスト型の Comma から始めてください。スタックを自分で運用したいなら、セルフホストガイド を最後まで読み、公式リポジトリ を確認し、大事な Task を載せる前に、モデル、ネットワーク、バックアップ、クラウドコンピューター、会議の境界を計画してください。
