ホスト型エージェント（hosted agent）はプロバイダーのクラウドで動作します。リポジトリのコピーと認証情報を渡すと、そこを起点に作業を進めます。ローカルファーストエージェント（local-first agent）は自分のマシン上で動作し、ランタイム、サブスクリプション、ファイル、鍵はすでに手元にあり、外に出るのは会話内容だけです。
どちらも正当な設計です。コード、アイデンティティ、請求の所在がそれぞれ異なり、エージェントを他者と共有し始めるとその違いはいっそう重要になります。
ホスト型の利点と、その代償
2026年における具体例としては、Claude Code on the web や OpenAI’s Codex cloud tasks が挙げられます。どちらもプロバイダーのサンドボックス内でリポジトリのクローンに対してエージェントを実行し、GitHubのOAuth連携を通じてプロバイダーに発行されたtokenでgitの認証を行います。そのため、エージェントがローカルの認証情報、SSHキー、環境変数にアクセスすることはありません。これは確かなセキュリティ特性です。侵害された開発者ノートPCがエージェントの環境に漏洩することはなく、スコープ設定が不適切なタスクがサンドボックス外のファイルに触れることもありません。
ホスト型エージェントは常に稼働しています。ノートPCを起動し続ける必要はなく、インストールするものもありません。無人で24時間365日動かすフリートにとっては、これが決定的な利点になります。
一方で、その代償は運用で直せるものではなく構造的なものです。
- あらゆるものの2重のコピー。 エージェントが作業できるように、プロバイダーがリポジトリや開発環境を保持します。そのコピーには独自のアクセス制御、保持ポリシー、侵害リスクが伴います。
- 2重の認証情報。 GitHub、クラウド環境、社内APIのtokenがプロバイダーに対して発行されます。ローテーションを行うなら、そちらでも実施する必要があります。
- 2重の請求。 すでに契約しているサブスクリプションに加えて、あるいはそれとは別に、ホスト型ランタイムの費用を支払うことになります。
- プロバイダー都合のモデル選択。 どのモデルが利用可能で、いつ切り替わるかはホスト側が決めます。
ローカルファーストの利点と、その代償
ローカルファーストエージェントは、すでにマシンにあるものをそのまま利用します。契約済みの Claude Code や Codex のサブスクリプション、チェックアウト済みのリポジトリ、キーチェーン内の鍵などです。どこにも何も複製されません。エージェントを共有すると、相手は指示を出すことができますが、実際の作業を行うのはあくまであなたのマシンです。
代償となるのは可用性です。マシンがスリープしていれば、エージェントもスリープします。
これに対する緩和策はアーキテクチャ上の問題ではなく実用面で対処できます。daemonをサービスとして登録してログイン時に起動しクラッシュ後も自動再起動するようにする、就業時間中はマシンをスリープさせないようにする、そしてマシンがオフラインの間も何も失われないようリクエストを受信箱にキューイングする、といった対応です。マシンが復帰した際に、リクエストは順を追って実行されます。
信頼の境界をどこに置くか：プロバイダーのサンドボックスの周りか、それとも外側にルームを備えた自分自身のマシンの周りか。
クラウド層はどこまで薄くできるか
muti はローカルファーストであり、興味深い設計上の問いは「クラウドに何を保持させてよいか」でした。その答えは、「ルームのみであり、ルームがマシンになりすませるようなものは一切持たせない」ということです。
この構成は3つの仕組みによって成立しています。
アウトバウンド通信のみ。 マシン上の daemon は、外向きの接続経由でタスクをポーリングします。開いたポートやトンネル、インバウンドの経路はありません。仮に muti のクラウドが侵害されたとしても、攻撃者ができるのはリクエストをキューに入れることだけであり、それらもパーミッションルールと承認の対象となります。ファイルに到達することはできません。
ファイルではなくイベント。 daemon は何が起きたかを記述したタイムラインイベントを発行します。作業ツリーをアップロードすることはなく、環境変数やキーファイルを読み取って外部に送信することも決してありません。
中央での承認。 マシンがオーナー自身のものであるため、他者からのあらゆるリクエストに対して4つの危険なアクションタイプが発生した際、処理を一時停止してあなたに確認を求めます。あなたの認証情報を持ったホスト型エージェントには、確認を求める相手がいません。
判断基準
なぜ muti はランタイムをホストしないのか
「クラウドで実行する」ボタンを追加すること自体は簡単です。しかし、私たちはそうしていませんし、それは意図して掲げた非目標（non-goal）です。ランタイムを移動させた瞬間、認証情報とリポジトリも移動し、オーナーが承認者ではなくなってしまいます。エージェントが実行前に必ず確認すべき4つのアクションにあるすべての保証は、マシンがオーナーのものであることに依存しています。
muti がホストするのはルームです。エージェントは元の場所にとどまります。
よくある質問
「ローカルファースト」は「オフライン」と同じ意味ですか？ いいえ。エージェントがモデルプロバイダーにアクセスするにはネットワークが必要ですし、muti がメッセージを届けるのにもネットワークが必要です。ローカルファーストとは、作業と秘密情報がどこにあるかを指す言葉であり、マシンが接続されているかどうかを指す言葉ではありません。
muti のクラウド部分をセルフホストできますか？ 1人用のオフライン対応モードとして、ルーム層のセルフホストをロードマップに含めています。daemon とクラウドはすでにプレーンなAPI経由で通信しています。
複数台のマシンを持っている場合はどうなりますか？ それぞれのマシンを接続してください。エージェントはマシンおよび作業ディレクトリに紐づけられており、daemon が報告するアドレスによってマシンを識別できます。
すでに優れたエージェントに課金していて、それを手元に置いたまま活用したいなら、ルームを用意しましょう。
公開日 · 更新日