デーモンとランタイム

エージェントは Multica のサーバーでは実行されません — あなた自身のマシンで実行されます。

Multica では、エージェントは私たちのサーバーでは実行されません — ローカルにインストールされた AI コーディングツールを呼び出すデーモンという小さなプログラムが駆動し、あなた自身のマシンで実行されます。Multica サーバーは調整役に徹します。イシューを保存し、タスクをキューに入れ、適切なランタイムへ分配します（ランタイム = デーモン × AI コーディングツール 1 つ）。

この構造が Multica と Linear / Jira の最大の違いです。あなたの API キー、ツールチェーン、コードディレクトリはすべてあなたのマシンに残り、Multica サーバーはそのどれも見ることはありません。つまり「自分のエージェントが動かない」はほとんど常にローカルの問題です。デーモンが実行されていない、AI ツールがインストールされていない、キーが期限切れになっている、といったことです。まずローカルを確認してください。案内はトラブルシューティングを参照してください。

デーモンを起動する

デーモンは Multica CLI の一部です。Multica CLI をインストールしたら、あなた自身のマシンで実行してください。

multica daemon start

起動時にデーモンは 4 つのことを行います。

ログイン時に保存された認証情報を読み込みます
PATH にインストールされた AI コーディングツールを検出します（内蔵 16 種: Antigravity、Claude Code、CodeBuddy、Codex、Cursor、Copilot、Hermes、Kimi、Kiro CLI、OpenCode、OpenClaw、Pi、Qoder、Trae CLI、DevEco Code、Grok）
検出した各ツールに対するランタイムとともに、自身をサーバーに登録します
3 秒ごとに取得すべきタスクがないかポーリングし、15 秒ごとにハートビートを送信し続けます

よく使うコマンド:

コマンド	用途
`multica daemon start`	起動（デフォルトはバックグラウンド。フォアグラウンドで実行するには `--foreground` を追加）
`multica daemon stop`	停止
`multica daemon restart`	再起動
`multica daemon status`	ステータス表示
`multica daemon logs`	ログ表示（追従するには `-f` を追加）

完全な CLI リファレンスは CLI コマンドを確認してください。

デスクトップアプリにはデーモンが同梱されています。 デスクトップアプリを使う場合、multica daemon start を手動で実行する必要はありません。起動時にデーモンを自動的に立ち上げます。あなたのワークフローにどの方式が合うかは、デスクトップアプリページを参照してください。

1 つのマシンに複数のランタイムができる理由

ランタイムはサーバーでもコンテナでもありません。「デーモン × AI コーディングツール 1 つ」の組み合わせです。たとえば、Claude Code と Codex の両方がインストールされた MacBook でデーモンを起動し、あなたが 2 つのワークスペースのメンバーだとします。すると Multica は 4 つのランタイムを登録します。

Rendering diagram…

要点:

1 つのデーモンは複数のランタイムにマッピングされ得ます — インストールされたツールと、あなたが所属するワークスペースの組み合わせごとに 1 つできます
同じデーモン、ワークスペース、ツールは、ちょうど 1 つのランタイムを作ります — デーモンを再起動しても重複レコードは生まれません
Multica UI のランタイムページがこれらの行を一覧表示します

カスタムランタイムプロファイル

組み込み provider 検出は一般的なツールを対象にしています。Multica が対応するプロトコルファミリーで動作し、別の起動コマンドが必要な AI CLI には custom runtime profile を定義できます。たとえば、Codex の社内 wrapper、バージョンを固定した実行ファイル、モデル引数を事前設定したチーム CLI などです。

Claude Code、Codex、Kimi などの組み込み provider を通常のコマンドで使うだけなら、カスタムプロファイルは不要です。デーモンが自動的に検出します。

作成前の確認

Multica デーモンが動作する少なくとも 1 台のマシンにカスタムコマンドをインストールし、同じコマンドがそのマシンのターミナルで動くことを確認します。
ツールが UI に表示されるベースプロトコルファミリーのいずれかを実装していることを確認します。ファミリーの選択は Multica に通信方法を伝えるもので、互換性のない CLI を互換にするものではありません。
プロファイルを作成、編集、削除できるのはワークスペースの owner または admin だけです。

Runtimes UI から作成する

Runtimes を開き、コマンドをインストールしたマシンを選択します。
カスタムランタイムを追加を選択します。
コマンドが実装しているベースプロトコルファミリーを選びます。
表示名と、固定引数を含むターミナルで実行するコマンドを入力します。チーム向けに用途の説明も追加できます。
ランタイムを作成を選択します。

プロファイル定義はワークスペース全体に属し、接続済みのすべてのデーモンへ同期されます。各マシンはそのコマンドを解決できる場合にだけ独自のランタイムを登録します。作成を開始したマシンには待機中の 登録中 行が一時的に表示されます。オンラインにならない場合は、そのマシンでコマンドがインストールされ、デーモンから見えることを確認してください。

プロファイルを作成しても CLI のインストール、認証、他のマシンへのコピーは行われません。このランタイムを提供する各マシンで、基盤となるツールを個別にインストールしてログインしてください。

CLI から管理する

同じワークスペースプロファイルを CLI から管理できます。

multica runtime profile list
multica runtime profile create --display-name "Composer" --protocol-family codex --command-name agent
multica runtime profile update <profile-id> --command-name agent
multica runtime profile delete <profile-id>

組み込みランタイムとカスタムランタイムは同じマシン一覧に表示されます。カスタムランタイム行の操作メニューから、プロファイルを編集または削除できます。プロファイルを削除すると、デーモンの同期後に登録済みランタイムインスタンスも削除されます。エージェントがまだ依存している場合、削除はブロックされることがあります。

入力するコマンドは shell 文字列ではなく argv 形式です。Multica は実行ファイル名と固定引数を保存し、デーモンは exec.Command(command_name, fixed_args...) で直接起動します。通常の引数、引用符、バックスラッシュエスケープは使えますが、パイプ、リダイレクト、&&、;、バッククォート、$VAR / $(...) 展開は使えません。shell の動作が必要な場合は wrapper script を使ってください。現在、コマンドと引数の解析は Runtimes UI が担当します。CLI の profile コマンドは profile 行とローカルのパス上書きを管理します。

デスクトップアプリから起動したデーモンが、ターミナルでは動くコマンドを見つけられない場合は、そのマシンで絶対パスを固定できます。

multica runtime profile set-path <profile-id> --path /abs/path/to/agent
multica runtime profile unset-path <profile-id>

profile のコマンドや引数の変更は、デーモンが再登録された後に新しく取得するタスクへ適用されます。実行中のタスクは開始時の引数を使い続けます。混在デプロイでは、先に server をアップグレードしてから daemon を順次更新することを推奨します。fixed_args の入力は server 側の Runtimes UI が担い、failed_profiles 登録レポートも server が表示します。古いコンポーネントは未知のフィールドを明示的に失敗させず無視することがあるため、server を先に更新すると rollout を観測しやすくなります。

クラウドランタイムが近日提供されます。 現在は順番待ちリストの段階です。提供が始まれば、ローカルのデーモンを実行せずに Multica Cloud 上で直接エージェントタスクを実行できるようになります。ダウンロードページでメールアドレスを登録すると通知を受け取れます。

ランタイムがオフラインと表示される時点

Multica はハートビートでランタイムがオンラインかどうかを判断します。3 つの重要な数値があります。

イベント	しきい値
デーモンのハートビート頻度	15 秒ごと
欠落として表示	45 秒間ハートビートなし（3 回欠落）
自動削除	関連するエージェントがない状態で 7 日以上欠落

欠落は永続的ではありません。デーモンが再びハートビートを送った瞬間にオンラインに戻り、ランタイムレコードも保持されます。デーモンを再起動してもランタイムは失われません。

欠落したランタイムで実行中だったタスクは失敗として表示されます（失敗理由 runtime_offline）。リトライ可能なソース（イシュー、チャット）については、Multica が自動的に再度キューに入れます。オートパイロットがトリガーしたタスクは自動的にはリトライされません。タスク → どの失敗が自動リトライされるかを参照してください。

いくつのタスクを並列に実行できるか

Multica は 2 つの層で同時実行数の制限を適用します。

デーモン層: デフォルトで同時タスク 20 個（環境変数 MULTICA_DAEMON_MAX_CONCURRENT_TASKS で調整可能）
エージェント層: デフォルトでエージェントあたり同時タスク 6 個（エージェントごとに設定）

2 つのうち厳しい方が適用されます。デーモンがすでにタスク 20 個を実行中なら、あるエージェントに余裕が残っていても新しいタスクは待機します。

タスクが dispatched に進めず queued で止まっている場合、通常はこの 2 つの制限のいずれかが飽和しています。

デーモンのクラッシュ後、進行中だったタスクはどうなるか

デーモンがクラッシュしたり強制終了されたりすると、デーモンが取得していたタスクは dispatched または running 状態に残ります。次回の起動時、デーモンはサーバーに「これらのタスクはもう私のものではないので、失敗として表示してください」と伝えます。サーバーはそれを理由 runtime_recovery とともに failed に切り替えます。リトライ可能なソースについては、タスクが自動的に再度キューに入ります。

この手順がネットワークの問題で失敗しても、バックアップとして30 秒ごとにサーバー側のスキャンが回ります。45 秒以上ハートビートのないランタイムは欠落として表示され、その上のタスクも一緒に回収されます。

動かないエージェントのトラブルシューティング

「自分のエージェントが動かない」という問題に遭遇したら、まずこの 3 ステップのチェックリストを進めてください。

multica daemon status を実行し、デーモンが実行中でオンラインかを確認します
multica daemon logs -f を実行し、エラーがないかを確認します
Multica UI のランタイムページを開き、ランタイムが「オンライン」と表示されているかを確認します

より多くのシナリオはトラブルシューティングを参照してください。

タスク — デーモンがタスクを取得した後の全ライフサイクル
プロバイダー対照表 — 16 種の AI コーディングツールの機能の違い