インストール

Control Center の使い方は 2 通りあります。ダウンロード不要の Web アプリとして app.usectrl.dev で使うか、インストールする デスクトップアプリとして使うかです。どちらも同じ機能を持つ同じアプリケーションで、違うのはサーバーをどこで実行するかだけです — そして Web アプリは、あなたの代わりにサーバーを実行することはできません。

ブラウザーで使う

app.usectrl.dev は、このアプリケーションをブラウザー向けにコンパイルしたものです。インストールも更新も不要です。開いて接続するだけです。

ブラウザーのタブにできないのは、サーバーそのものに_なる_ことです。すべてのクライアント — デスクトップ、Web、スマートフォン — は、データベースを所有して実際の処理を行うヘッドレスの cc_server の上で描画する薄いレンダラーにすぎないため、Web アプリは常に、自分で実行しているサーバーと通信します。サーバーを用意する方法は 2 つあります:

自分のマシン上のサーバー。 cc_server をローカルで起動し、Web アプリの接続先を ws://localhost:9030 にします。ブラウザーは localhost を信頼できるものとして扱うため、証明書もトンネルも不要です。Web アプリを試す最短の方法であり、データがマシンの外に出ることはありません。

別のマシン上のサーバー。 app.usectrl.dev は HTTPS で配信されるため、ローカル以外のサーバーには、ブラウザーがすでに信頼している証明書を伴う wss:// で到達できる必要があります。cc_server は TLS なしで非ループバックアドレスをバインドすることを拒否するため、次のいずれかを選びます:

--tls-cert と --tls-key で証明書を直接渡す
TLS 終端のリバースプロキシの背後に置き、--insecure を付けて起動する
証明書を提供するトンネルか VPN 経由で公開する — Tailscale、cloudflared などです。設定 → サーバー → 接続とステータスには、このサーバーを共有の下に組み込みのトンネルのオプトインがあります。

サーバーがプロキシ、NAT、トンネルの背後にある場合は常に、クライアントが実際に接続すべきアドレスを --public-url に設定します。既定ではローカルのバインドから導出されるため、これを設定しないとクライアントは誤ったホストに接続しようとします。

ネイティブウィンドウやマシン自身のオーディオデバイスを必要とするため、デスクトップ専用のままの機能がいくつかあります: フローティングのフォーカスモードのピル、OS の通知トースト（アプリ内の通知センターはどこでも動作します）、カレンダーイベントからの「録音を開始してリンク」、ミーティングの要約の再実行です。それ以外 — スペース、エージェント、プルリクエストのレビュー、パイプライン、チケット、メモリ、そしてミーティングの録音そのもの — はすべて同じように動作します。

Web アプリをサーバーに接続するには、リモートサーバーに接続に従ってください。サーバーを自分でホストするには、ヘッドレスサーバーを実行に従ってください。

デスクトップ版のシステム要件

要件	macOS	Windows	Linux
OS のバージョン	macOS 13+（Ventura）	Windows 10+	Ubuntu 22.04+、または glibc 2.35+ と GTK 3 を備えた別のディストリビューション
アーキテクチャ	Apple Silicon (arm64)	x64, ARM64	x86_64
Git	必須	必須	必須
ディスク容量	アプリ用に約 200 MB、加えてサーバーのデータディレクトリ	約 200 MB	約 200 MB

Intel Mac 向けのビルド済みダウンロードはありません。代わりにソースからビルドしてください。

サーバーのデータディレクトリは、アプリ本体よりも大きくなります。初回起動時に cc_server はオンデバイスのモデル — テキスト埋め込み（約 90 MB）、話者分離（約 35 MB）、選択した音声モデル（既定では Parakeet TDT v3、約 600 MB。Whisper の各バリアントは 198–626 MB） — と、埋め込みの code-server ビルドを強制的にインストールします。さらに、エージェントの会話ごとに、作業対象のリポジトリのコピーオンライトのワークツリーが作られます（Windows では通常の git worktree）。音声は任意ではありません: ASR モデルがないと、ミーティングとディクテーションの操作は提供されません。音声モデルの初回ダウンロードでは、録音が使えるようになるまでに再起動が 1 回必要です。

デスクトップは、サーバーのデータを OS のユーザーごとのアプリケーションサポートディレクトリに置きます。--data-dir を付けずに手動で起動した cc_server は、既定で <application data>/control-center を使います — macOS では ~/Library/Application Support/control-center、Windows では %APPDATA%\control-center、Linux では $XDG_DATA_HOME/control-center（または ~/.local/share/control-center）です。

ダウンロード

以下のすべての成果物は GitHub Releases から入手できます。

macOS (Apple Silicon)

Control-Center-<version>-arm64.dmg をダウンロードして開き、Control Center を Applications にドラッグします。このビルドは Developer ID で署名され、Apple による公証を受けているため、そのまま開けます。

Windows (x64, ARM64)

Control-Center-<version>-x64-setup.exe: ユーザーごとのインストーラー。
Control-Center-<version>-windows-x64.zip: ポータブルな zip。
Control-Center-<version>-arm64-setup.exe: ユーザーごとのインストーラー。
Control-Center-<version>-windows-arm64.zip: ポータブルな zip。

Windows ではスペースのチェックアウトに git worktree を使います（コピーオンライトはありません）。

Linux (x86_64)

Control-Center-<version>-x86_64.AppImage
Control-Center-<version>-linux-x64.tar.gz

AppImage は更新情報を内包しているため、AppImageUpdate や appimaged を使って、変更された分だけをダウンロードしながらその場で最新リリースに更新できます。

どちらも Ubuntu 22.04 でビルドされ、それ以降のもの（Debian 12、Fedora 36 以降）で動作します。glibc 2.35 と GCC 12 の libstdc++ にリンクし、GTK 3 はシステムのものを利用します。標準的なデスクトップに欠けていることがある少数のライブラリは同梱されているため、ほかにインストールするものはありません。音声 — ミーティングの再生、サウンドスケープ、リグの音声、通知チャイム — はシステムの libmpv で再生されます（Ubuntu 22.04 では libmpv1、新しい Ubuntu と Debian では libmpv2、Fedora では mpv-libs）。これがないと、アプリはそれらのコントロールを非表示にして起動します。

スタンドアロンサーバー

各リリースには、ヘッドレスサーバー単体も収められています — cc_server-<version>-macos-arm64.tar.gz、cc_server-<version>-linux-x64.tar.gz、cc_server-<version>-windows-x64.zip、cc_server-<version>-windows-arm64.zip — さらに GHCR 上の cc-server、cc-webapp、cc-remote イメージもあります。詳しくはヘッドレスサーバーを実行を参照してください。

Linux アーカイブは Ubuntu 22.04 でビルドされ、同梱のネイティブライブラリは glibc 2.35 と GCC 12 の libstdc++ にリンクしているため、少なくともそれと同じか新しいホスト（Ubuntu 22.04、Debian 12、Fedora 36 以降）が必要です。古いディストリビューションでは、代わりに cc-server イメージを実行してください — コンテナは独自のユーザーランドを持ち込むため、カーネルだけがホストのものであれば済みます。

エージェントバックエンド

Control Center はアダプターを通じてエージェントをディスパッチします。アダプターは 2 つだけで、この一覧は固定であり、自動的に検出されます — 別のものを登録する方法はありません。

Control Center (built-in) アダプターは外部 CLI を必要としません。エージェントループがサーバー内で実行され、モデルプロバイダーとは HTTP で通信するため、常に利用できます。プロバイダーは設定 → サーバー → モデルプロバイダーで接続します。OpenAI、Codex、Cursor、Kimi Code はブラウザーでのサインインに対応し、Anthropic、OpenRouter、Google Gemini、DeepSeek、Mistral、xAI、z.ai、Moonshot は API キーを使います。Codex と Cursor は、別個の CLI ではなく、このランナー上のプロバイダーです。z.ai が 2 つ表示されるのは意図的です: z.ai は従量課金のオープンプラットフォームで、アカウントの残高に対して課金され、z.ai GLM Coding Plan はサブスクリプションです。アカウントキーは同じですが、z.ai はこのプランを別のホストから提供します — コーディングプランのキーを素の z.ai のタイルに貼り付けると、すべてのリクエストが 429 … "Insufficient balance or no resource package" を返します。そのプランには消費できる残高がないためです。Claude Pro/Max のサブスクリプションは Anthropic API のログインではありません。そのプランを使うには、代わりに Claude Code アダプターを経由してください。そのページで追加_できる_のはカスタムプロバイダーです — OpenAI または Anthropic 互換の任意のエンドポイント（Ollama、LM Studio、vLLM、プライベートデプロイメント）を、カスタムプロバイダー → プロバイダーを追加から追加できます。

もう一方のアダプターは外部 CLI をラップします:

Claude Code (claude): npm install -g @anthropic-ai/claude-code

検出は cc_server を実行しているマシンの PATH を調べます — デスクトップが独自のサーバーを実行している場合は同じマシン、それ以外の場合はリモートホストです。Claude Code CLI はクライアントではなくそこにインストールしてください。そのページの更新ボタンで、検出をやり直せます。

モデル一覧は、接続された各プロバイダーからライブで提供されます。models.dev は料金とコンテキストウィンドウのメタデータを補うだけです。詳しくはアダプターとモデルを管理を参照してください。

GitHub の認証

GitHub の資格情報はあなたのものであり、サーバー上に存在し、あなたのユーザー id をキーとして管理されます — クライアント OS のキーチェーンには保存されません。サインインするどのデバイスも同じものを使い、他のメンバーが読み取ることはできません。

サーバーに GitHub App が登録されている場合（GitHub App を作成）、設定 → ワークスペース → プロフィールと識別情報 → コードホスティングに GitHubでサインインが表示されます（サーバーが実行するデバイスフローです）。それ以外の場合は、個人アクセストークンを貼り付けます:

クラシック: repo と read:org
きめ細かい: Contents と Pull requests（読み取りと書き込み）、Checks と Actions（読み取り）

トークンは GitHub → Settings → Developer settings → Personal access tokens で作成します。サーバーは保存時にトークンを検証してアカウント名を取得するため、行には「…としてサインインしています」と表示されます。検証に失敗してもトークンは保存され、誤字や不足したスコープは後になって失敗したリクエストとして現れます。

オンボーディングの最初のステップがこの接続です。その後も、同じカードで置き換えたり解除したりします。GitLab と Bitbucket も同じカードを使います。詳しくはコードホストを接続を参照してください。

サーバーをどこで実行するかを選ぶ

Control Center は、データベースを所有してすべての処理を行うヘッドレスの cc_server プロセスの上で動くシンクライアントです。この分離がデスクトップ、Web、スマートフォンにとって何を意味するかは、デプロイメントとクライアントで説明しています。

初回起動時に、デスクトップ版は 「Control Centerをどのように実行しますか？」 と尋ねます:

このアプリで実行: デスクトップがこのマシン上で cc_server を起動して監視し、ループバック経由で通信します。ほかに設定するものはありません。クイックスタートが前提としている構成です。
リモートインスタンスに接続: 別の場所で動いている cc_server を、その WebSocket URL、デバイス id、そしてペアリングキーまたは 1 回限りの招待コードで指定します。データを所有するのはそのサーバーで、このデスクトップはそれを描画するだけです。

サーバーの追加や切り替えは、後から設定 → サーバー → 接続とステータスで行えます。切り替えはその場で再接続され、再起動は不要です。ブラウザーはサーバーを実行できないため、Web クライアントは常にリモートです。詳しくはリモートサーバーに接続を参照してください。

サーバーを自分でホストするには、ヘッドレスサーバーを実行に従ってください。バイナリのビルド、初回起動前のペアリングキーの発行、--data-dir / --port / --bind フラグを扱っています。

セットアップを確認する

設定 → サーバー → モデルプロバイダーに両方のアダプターが一覧されます。「Control Center (built-in)」はバージョン built-in で検出済みと表示され、Claude Code は CLI がサーバーホストの PATH にあれば検出済みと表示されます。見つからない場合は更新を押します。
設定 → ワークスペース → リポジトリにこのワークスペースのリポジトリが一覧され、リポジトリを追加でサーバーホストのフォルダーを参照できます。
設定 → ワークスペース → エージェントに、最初のワークスペースがシードした 5 体のエージェントが一覧されます。実行するには、それぞれにアダプターとモデルを設定する必要があります。
設定 → サーバー → 診断とプライバシーは、このホストが提供するサンドボックスバックエンド、埋め込みモデルの状態、ログを表示します。

ソースからビルド

ネイティブライブラリは必須で、縮退モードはありません。1 つでも欠けると起動が失敗し、遅くなるだけでは済みません。何よりも先にそれらをステージングしてください。Flutter と Dart のコマンドはすべて fvm を経由します。SDK のバージョンはリポジトリで固定されているためです。

git clone https://github.com/SamuelAlev/control-center.git
cd control-center
scripts/natives/build_natives.sh
fvm flutter pub get
fvm flutter pub run build_runner build --delete-conflicting-outputs
fvm flutter gen-l10n
fvm flutter run -d macos  # or -d windows, -d linux

macOS では、セキュアストレージ（GitHub、Linear、Google のサインイン）を使うために、Apple チームによるアプリの署名が必要です — 無料の Apple ID で十分で、local development signing に書かれている 1 回限りの設定です。これがなくてもアプリは起動しますが、セキュアストレージだけが利用できません。Windows と Linux では署名は不要です。

ヘッドレスサーバーのバイナリをビルドするには、まず同じようにネイティブライブラリをステージングしてから、次を実行します:

cd apps/cc_server
fvm dart build cli

ビルドフックは、その時点で build/natives/ にあるものをそのままバンドルへコピーするため、ステージングの前にビルドすると、ネイティブを含まないバンドルができ、サーバーは起動を拒否します。

Web クライアントには scripts/build_web.sh を使います（スマートフォン PWA には --target remote）。これは CI が実行するものと同じです。素の flutter build web では、ビルド ID のスタンプ、Web Worker の再生成、デプロイマニフェスト、アセット予算のチェックが省略されます。