2つのCursorアカウント。
1つのAgentsRoom。ログアウトはゼロ。
1つのプロジェクトで個人用の cursor-agent login、別のプロジェクトで仕事用のログインを、同じウィンドウで同時に使えます。プロジェクト、フォルダ、エージェントごとに1つのCursorアカウントを固定。設定パネルから直接サインインでき、CURSOR_CONFIG_DIRを手でエクスポートする必要も、追加ツールをインストールする必要もありません。
CURSOR_CONFIG_DIR~/.cursor-work~/.cursorCursorアカウントごとに1つのディレクトリがあり、CURSOR_CONFIG_DIRがそれを指します。両方のアカウントがサインインしたまま、両方が同時に動きます。
複数のCursorアカウントを使う理由
開発者が複数のCursorアカウントを使う実際の理由を、率直に説明します。
仕事と個人をきれいに分離
会社のCursorアカウントは仕事のリポジトリ専用のままです。個人のアカウントは週末のプロジェクト専用のままです。サイドプロジェクトに仕事の認証情報が入り込むことも、会社のアカウントに個人のセッションが記録されることもなく、プロンプトを打つ前に思い出しておくことも何もありません。
クライアントごとに使用量を請求
クライアントから自社のCursorアカウントへのアクセスを渡されたら、そのクライアント向けのセッションはそのアカウントで実行されます。消費されるのは相手のクォータで、あなたのものではありません。各アカウントが独自の履歴を持つため、何が誰のものかは数か月後でも読み取れます。
クォータの衝突を避ける
仕事用アカウントのプランが厳しいなら、個人プロジェクトでエージェントを長く走らせてもそこを削るべきではありません。アカウントが2つあれば、制限も使用履歴も2組になり、いつもぶつかる共有の予算枠が1つだけという状態から抜け出せます。
本番アカウントの隣でテストアカウントを動かす
ノイズの多い実験、使い捨てのエージェント、プロンプトの下書き用に2つ目のCursorアカウントを用意し、メインのアカウントはきれいに保ちます。切り替えはプロジェクト単位でもエージェント単位でも、リストから選ぶだけです。
組織が違えばポリシーも違う
会社のアカウントは、独自のプライバシーモード、ロギング、保持のルールを持つCursorチームに属していることがあります。その隣に個人アカウントを置いておけば、個人のコーディングは自分の条件のまま保たれ、認証情報と設定はディスク上のディレクトリ単位で隔離されます。
2人の開発者、1台のワークステーション
2人の開発者が1台のマシンを共有する場合、それぞれが自分のCursorアカウントでサインインします。AgentsRoomは両方を記憶し、プロジェクトやエージェントに応じて適切な方を起動するので、最後にログインした人が勝つということはありません。
AgentsRoomに直接組み込み
外部スイッチャーなし、シェルのラッパーなし、ログアウトとログインの繰り返しもなし。
プロジェクトごとに1つのCursorアカウント
Cursorアカウントをプロジェクトに固定すると、その中のすべてのエージェントがそのアカウントを継承します。同じウィンドウで仕事用プロジェクトと個人用プロジェクトを開けば、それぞれが裏側で自分のCursorログインで動きます。
エージェントごとに上書き
1つのエージェントだけ別のアカウントにしたいときは、エージェントを編集して別のCursorアカウントを選び、保存するだけです。上書きはそのエージェントにだけ適用され、プロジェクトの残りはプロジェクトのアカウントを使い続けます。
プロジェクトのフォルダごとに1つのアカウント
サイドバーのフォルダにCursorアカウントを固定すると、その下に入れたすべてのプロジェクトがそのアカウントで始まります。サブフォルダも同じです。仕事用フォルダは仕事用アカウント、個人用フォルダは個人用アカウントに。プロジェクト単位でも、エージェント1つだけでも、上書きは今までどおりできます。
グローバルデフォルトのアカウント
1つのCursorアカウントをデフォルトに指定します。もっと具体的な指定がない限り、新しいプロジェクトはすべてそのアカウントで始まります。後からデフォルトを変えれば、何も固定していないプロジェクトは自動的に追従します。
アプリの中でサインイン
アカウントを追加すると、AgentsRoomは適切なCURSOR_CONFIG_DIRをすでに設定した状態でcursor-agent loginを実行する小さな埋め込みターミナルを開きます。ブラウザで手続きを終えたら、あとは確認するだけです。アカウントは使える状態になり、シェルには何も打ち込んでいません。
ディスク上での厳格な分離
各アカウントは自分のディレクトリの中にあります。認証情報とcli-config.jsonです。2つのアカウントがアイデンティティを共有することはなく、AgentsRoomからアカウントを削除しても別のアカウントのデータには触れません。
アカウントごとに1つの色
各Cursorアカウントに専用の色を割り当てます。色はエージェントのアバター、ターミナルのヘッダー、プロジェクトタイルに点として表示されるので、どのアカウントが動いているかを調べに行かずに一目で読み取れます。
利用上限を超えても作業を続ける
エージェントが動いているアカウントがクォータを使い切ると、AgentsRoomはそれをすでにサインイン済みの別のCursorアカウントへ移せます。ただし1点の留保があります。cursor-agent CLIはチャットIDを公開しないため、エージェントは同じ会話を引き継ぐのではなく、別のアカウントであらためて起動し直されます。どのアカウントも、スイッチ1つでその対象から外せます。
すでにあるディレクトリを指定
アカウントとは要するにパスです。AgentsRoomに作成と管理を任せることも、自分で用意した既存のCursor設定ディレクトリのパスを入力することもできます。デフォルトの~/.cursorも指定できます。何も移動されず、書き換えられもしません。
内部の仕組み
Cursor CLI自身がドキュメント化している環境変数の上に構築されています。
CURSOR_CONFIG_DIRがすべてを決める
cursor-agent CLIはローカルの状態を1つのディレクトリから読み込みます。認証情報とcli-config.jsonです。デフォルトは~/.cursorで、CURSOR_CONFIG_DIRでその場所を別の場所に移せます。1つのディレクトリがサインイン済みの1アカウントなので、エージェントをアカウントに結び付けることは、ディレクトリに結び付けることと同じです。
各アカウントは1つのディレクトリ
アカウントを追加すると、AgentsRoomは自分のホームの下にディレクトリを作り、そこでサインインします。パスを入力すれば、すでに手元にあるCursor設定ディレクトリをアカウントとして指定することもできます。CLIから見ればどちらも同じもので、CURSOR_CONFIG_DIRの値にすぎません。
サインインは設定に組み込み済み
AgentsRoomは、新しいディレクトリをCURSOR_CONFIG_DIRに設定した状態でcursor-agent loginを実行する小さなターミナルを起動します。ブラウザでの手順はいつもどおりです。Cursorは認証情報をどこに書き込むかを公表していないため、AgentsRoomはパスを推測しません。ブラウザでの手続きが終わったらあなたが確認します。まだ準備できていないかもしれないアカウントを、準備完了と告げられることはありません。
アカウントは起動時に解決される
エージェントが起動するとき、AgentsRoomは次の順にカスケードをたどります。エージェントの上書き、プロジェクトの固定、アカウントを固定している最も近いフォルダ、グローバルデフォルト、そしてCLI自身のディレクトリです。cursor-agentが起動する前に、対応するCURSOR_CONFIG_DIRがエージェントの環境に設定されます。
AgentsRoom以外の方法
複数のCursorアカウントを扱う他のやり方と、AgentsRoomがそこで何を変えるか。
CURSOR_CONFIG_DIRを手でエクスポートする
いちばん直接的な方法です。cursor-agentを起動する前にexport CURSOR_CONFIG_DIR=/some/pathを実行します。動きはしますが、2つ目のターミナルタブを開いて、そちらがどのアカウントなのか分からなくなった時点で機能しなくなります。AgentsRoomは同じ変数をプロジェクトごと、エージェントごとに代わりに設定し、有効なアカウントを画面上に表示します。
CURSOR_API_KEYを設定する
ほぼ全員がはまる罠です。キーではアカウントは切り替わりません。キーはセッションが有効でないときに使われるフォールバックで、マシンにすでに保存されているセッショントークンが優先されます。cursor-agent loginを一度でも実行した人は、キーで切り替わったと思い込んだまま最初のアカウントで動き続け、警告してくれるエラーも出ません。実際にアカウントを切り替える唯一のレバーはディレクトリで、AgentsRoomが動かしているのはそれです。
毎回ログアウトしてログインし直す
もう一方のアカウントでcursor-agent loginを実行し、戻るときにもう一度実行します。このコマンドはマシン全体でキャッシュされたセッションを置き換えるため、グローバルかつ破壊的です。他のプロジェクトもすべて一緒に切り替わり、実行中のセッションも乱されます。AgentsRoomはすべてのアカウントを同時にサインインしたまま保ち、リストから選ぶだけで切り替えます。
2台のマシン、または2つのOSユーザーセッション
Cursorアカウントごとにマシンを分ける、あるいはOSのユーザーを分けるチームもあります。重くて遅いうえに、それでも仕事用エージェントと個人用エージェントを並行して実行することはできません。AgentsRoomは同じマシンの同じウィンドウで、両方を同時に動かします。
AgentsRoomだけができること
AgentsRoomは複数のCursorアカウントをファーストクラスの概念として扱います。プロジェクトごとの固定、フォルダごとの固定、エージェントごとの上書き、cursor-agent loginを代わりに実行する組み込みのサインイン、そしてアカウントごとの色です。CursorアカウントはClaude、Codex、Grokのアカウントと同じパネルに並ぶので、仕事用のCursorエージェント、個人用のCursorエージェント、Claudeエージェントをすべて並べて実行できます。
よくある質問
AgentsRoomにCursorアカウントはいくつ追加できますか?
はっきりした上限はありません。アカウントはディスク上のディレクトリなので、仕事用、個人用、クライアントごと、テスト用と好きなだけ追加できます。すべて設定パネルに一覧表示され、どれでもプロジェクト、フォルダ、あるいはエージェント1つに対して選べます。
2つのCursorアカウントを使うのに追加のツールが必要ですか?
不要です。AgentsRoomが動かすのは、Cursor CLI自身がドキュメント化しているCURSOR_CONFIG_DIRという変数です。外部のスイッチャーも、シェルのラッパーも、追加の依存関係もありません。サインインの流れは、設定に組み込まれたターミナルで公式のcursor-agent loginコマンドを実行します。
2つのエージェントを2つの異なるCursorアカウントで同時に実行できますか?
できます。それこそが狙いです。各エージェントは独自の環境を持つため、アカウントはエージェント単位で決まります。仕事用アカウントに固定したプロジェクトの中に、個人用アカウントへ上書きしたエージェントを1つ置くことができ、両方が同じウィンドウで並行して動きます。
CURSOR_API_KEYを設定すればCursorアカウントは切り替わりますか?
切り替わりません。ここが意外に思われるところです。APIキーは、セッションが有効でないときのためのフォールバックです。cursor-agent loginでサインインしていれば、保存されたセッションが優先され、キーは黙って無視されます。切り替わらなかったことを知らせるエラーも出ません。確実な方法は設定ディレクトリを分けることだけです。
まだ参照しているエージェントがあるアカウントを削除するとどうなりますか?
何も壊れません。そのエージェントはカスケードの次のアカウントに静かにフォールバックし、ディレクトリ自体は、後で別のアカウントから指定したくなった場合に備えてディスクに残されます。取り残されたエージェントは、好きなときに結び直せます。
Cursorの認証情報はサーバーに送信されますか?
されません。各アカウントのディレクトリはあなたのマシンに残ります。AgentsRoomが認証情報を読み取ったり、コピーしたり、送信したりすることは一切なく、間にAgentsRoomのアカウントが入ることもありません。サインインはローカルで公式のcursor-agent login CLIを実行し、ブラウザでの手順はいつもどおりあなたとAnysphereの間で行われます。
Cursorアカウントをプロジェクトのグループ全体に固定できますか?
できます。サイドバーのフォルダは独自のデフォルト設定を持ち、Cursorアカウントもその1つです。仕事のリポジトリを入れたフォルダに仕事用アカウントを固定すれば、中のすべてのプロジェクトがそのアカウントで始まります。後から追加したプロジェクトも、サブフォルダのプロジェクトも同じです。順序は、エージェントの上書き、プロジェクトの固定、最も近いフォルダ、グローバルデフォルト、そしてCLI自身のディレクトリです。
CursorアカウントをClaude、Codex、Grokのアカウントと混在させられますか?
できます。アカウントはプロバイダーごとに、同じ複数アカウントパネルで管理されます。1つのプロジェクトにCursorアカウントとClaudeアカウントを同時に固定でき、各エージェントは自分が動くプロバイダーのアカウントを使います。プロバイダー間で共有されるものはありません。
Cursorアカウントのディレクトリには具体的に何が入っていますか?
CLIにとって~/.cursorに入っているのと同じものです。ブラウザでのサインインが書き込む認証情報と、そのアカウントの設定が入ったcli-config.jsonです。2つのアカウントとは、このディレクトリが2つあるということで、だからこそ互いに干渉せずに同時にサインインしていられます。
Cursorアカウントの1つがクォータを使い切るとどうなりますか?
AgentsRoomは、ウィンドウがリセットされるまでエージェントを止めたままにする代わりに、すでにサインイン済みの別のCursorアカウントへエージェントを移せます。ただし1点、重要な留保があります。Claude、Codex、Grokとは違い、cursor-agent CLIはチャットIDを公開しないため、引き継げるものがありません。エージェントは同じ会話を続けるのではなく、別のアカウントであらためて起動し直されます。その対象から外しておきたいアカウントは、1つずつ除外できます。詳しい挙動はアカウント自動切り替えのページで説明しています。
こちらもおすすめ:Grok マルチアカウント
複数のCursorアカウントがあれば、1つのアプリで2つのAnysphereログインを使えます。Grok マルチアカウントはgrok CLIに同じことをもたらし、固定の仕組みも分離の仕組みも同じです。どちらも複数アカウントパネルの中、ClaudeとCodexの隣にあります。
Grok マルチアカウント機能を見るエージェントが利用上限に達する。 それでも作業は続く。
エージェントが動いているClaudeまたはCodexのアカウントが上限を使い切ると、AgentsRoomは同じ会話をすでにログイン済みの別アカウントへ引き継ぎ、作業がそのまま続きます。
仕組みを見るさらに詳しく
Claude Codeは一度に1つのログインしか保持しない。複数を並行して動かす方法
同じマシンで仕事用アカウントと個人用アカウントを併用するための実践ガイド: どのログインが有効かを決めるたった1つの環境変数、ターミナルが2つを超えるとshell方式が破綻する理由、そしてプロジェクトごとにアカウントを固定する方法。
Antigravity CLIはマシンごとにGoogleログインを1つしか持てない。代わりに使える方法はこれです。
Antigravity CLIで2つのGoogle AI Proサブスクリプションを交互に使えない理由、ログイン情報が実際に保存されている場所、アカウント切り替えツールがシステムのキーチェーンに対して本当にやっていること、ファミリープランでもクォータが倍にならない理由、そして複数のアカウントを本当に並行して動かせる唯一の方法。
AgentsRoomがGrok Buildに対応
xAIのターミナル向けコーディングエージェントGrok Buildが、AgentsRoomのファーストクラスのプロバイダーになりました。Claude、Codex、Antigravity CLI、OpenCode、Aiderと並べて実行し、会話の途中で切り替えられます。
Cursorからログアウトするのはもうやめましょう。アカウントはリストから選ぶだけです。
仕事用のCursorアカウント、個人用、クライアント用を、今日からAgentsRoomで並べて使いましょう。
コンパニオンアプリ:外出先でもエージェントを確認
Claude、Codex、Antigravity CLI、またはその他の AI プロバイダーを使用します。
バグや要望を公開バックログに直接送信できます。
実際の AgentsRoom の様子。