リモートサーバーに接続

どのクライアントも、データを所有する cc_server の上で動くレンダラーです。デスクトップは自身の中で cc_server を起動できますが、app.usectrl.dev の Web アプリはできません。ブラウザーのタブはサーバーをホストできないからです。いずれの場合も、このガイドではクライアントを別の場所で動いているサーバー — 小さなマシン、クラウド VM、ビルドサーバー — に向けます。

前提条件

稼働中の cc_server。まだない場合は、ヘッドレスサーバーを実行を参照してください。
サーバーが発行した 3 つのペアリング値 — サーバー URL（ws://…/rpc または wss://…/rpc）、デバイス ID、ペアリングキー — または、ワークスペース管理者からのワンタイムの招待コード。招待を引き換えると、あなたのユーザーがプロビジョニングされ、メンバーシップが記録され、このクライアントの資格情報が発行されるため、デバイス ID やキーを自分で扱う必要はありません。

サーバーに到達できることを確認する

ローカルサーバーには何も必要ありません。ブラウザーはループバックを信頼できるオリジンとして扱うため、ws://localhost:9030/rpc はデスクトップとブラウザーの両方から動作します。

別のマシン上のサーバーは話が別です。app.usectrl.dev は HTTPS で提供されるため、ブラウザーはすでに信頼している証明書を持つ wss:// ソケットしか開きません — そして cc_server はそもそも TLS なしで非ループバックアドレスをバインドすることを拒否します。次のいずれかを用意してください:

--tls-cert と --tls-key を使って証明書を直接渡す
前面に TLS 終端のリバースプロキシを置き、サーバーを --insecure で起動する（プロキシの背後は平文。信頼できるネットワークでのみ）
証明書を提供するトンネルまたは VPN — Tailscale、cloudflared など。設定 → サーバー → 接続とステータスの このサーバーを共有に、組み込みのトンネルのオプトインがあります。

サーバー側には、見落としやすい設定が 2 つあります。プロキシ、NAT、トンネルの背後では、 --public-url にクライアントが実際に接続すべきアドレスを設定してください — 既定ではローカルのバインドになるため、設定しないとクライアントは誤ったホストに接続しようとします。また、Web ビルドを自分でホストする場合は、そのオリジンを --allowed-origins に追加してください。既定では https://app.usectrl.dev のみで、ループバックとネイティブクライアントは常に許可されます。

デスクトップアプリを接続する

新規インストールの場合:

Control Center を起動します。初回起動画面で Control Centerをどのように実行しますか？ と尋ねられます
このアプリで実行ではなく、接続用のフィールドに入力します。サーバー URL と、招待コード、またはデバイス ID とペアリングキーです。
接続をクリックします。Control Center はサーバーに接続し、ワークスペースの受信トレイに移動します。

すでに自身でサーバーを実行しているデスクトップの場合:

設定 → サーバー → 接続とステータスを開きます。
サーバーを追加をクリックします。サーバー URL（wss://host:9030/rpc）と、招待コード、またはデバイス ID とペアリングキーを入力します。URL フィールドの末尾のボタンは、LAN または tailnet 上の cc_server インスタンスを検出します。
接続をクリックし、次に新しいサーバーの行の切り替えをクリックします。

切り替えはライブで行われます。アプリは再起動せず、新しいセッションを中心にその場で再構築されます。接続に失敗した場合は、現在のサーバーにとどまり、エラーが表示されます。接続中のサーバーの行には切り替えの操作はありません。ローカルサーバーは最初の行で、このアプリで実行というラベルが付いています。

切り替えた後は、デスクトップはデータベースを所有しません。すべての画面は WebSocket 経由でリモートサーバーを介して読み書きします。

Web クライアントを接続する

Web ビルドは常にリモートです。

app.usectrl.dev、または自分でホストしている Web ビルドのコピーを開きます。
サーバー URL と、招待コード、またはデバイス ID とペアリングキーを入力します。
クライアントはサーバーに接続し、デスクトップと同じインターフェースを描画します。

URL にペアリング用のディープリンクがある場合、フィールドはあらかじめ入力されています。ペアリングキーは URL のフラグメントに乗ります。ブラウザーはこれをページをホストするサーバーに送信しないため、静的ホストがキーを目にすることはありません。

ブラウザーが行わないこと

Web クライアントはデスクトップと同じサーバーを読み書きしますが、いくつかのサーフェスにはネイティブウィンドウか、そのマシン自身のデバイスが必要です:

OS の通知トースト、通知音、常時表示のバナー列はありません（アプリ内の通知センターは引き続き動作します）
サーバーを追加ダイアログでの LAN または tailnet のサーバー検出はありません
アプリ内の記事リーダーはありません — ニュースフィードの記事は新しいタブで開きます
ミーティング要約の再実行、および処理中の要約のキャンセルはできません

2 つは存在しないのではなく、動作が異なります。ミーティングの録音はブラウザーで動作し、マイクと、音声トラックを含む画面共有を取り込みます。IDE で開くも動作しますが、サーバーに対して_サーバー自身の_ディスプレイでエディターを起動するよう要求するため、エディターがインストールされていないヘッドレスホストに対しては、このボタンは表示されません。

トラブルシューティング

接続がタイムアウトする: サーバーにクライアントから到達できる必要があります。バインド（--bind any）、ポートが開いていること、--public-url がクライアントから実際に接続できるアドレスを指していることを確認してください。オープンなインターネット経由では TLS が必須です — 平文の非ループバックバインドは、プロキシの背後で --insecure を付けてサーバーを起動しない限り、起動時に拒否されます。
ブラウザーは接続を拒否するが、ネイティブクライアントは動作する: ブラウザーのオリジンがサーバーの --allowed-origins リストにありません。既定では https://app.usectrl.dev のみが許可されます（加えてループバック）。
ペアリングキーが拒否される: サーバーで cc_server pair を再実行してそのデバイスのキーをローテーションし、新しいキーを入力してください。失効したデバイスは資格情報が失われていることを検出し、フェイルクローズします。失効は数秒以内にライブセッションを切断します。
ワークスペースが違う: ワークスペースは URL の一部（/workspaces/:workspaceId/…）であり、すべての呼び出しに付随するため、あるクライアントでワークスペースを切り替えても、変わるのは自分自身の表示だけです。到達できるのは自分がメンバーであるワークスペースだけです — それ以外は “Not a member of this workspace” で拒否されます。ワークスペースと分離を参照してください。