Cursor アカウントの管理

Cursor アカウントは、エディタのすべてのクラウド機能への鍵です。サインイン、サブスクリプションティア、使用量制限、そしてマシン間の設定同期などです。このガイドでは、サインイン方法の選択から、メールの変更、重複の統合、デバイス間で同期されるものの理解、そしてアカウントのきれいな削除まで、日常的に実際に触れる部分を扱います。

サインイン方法

Cursor は 3 つのサインインパスを提供しています。それらはすべてバックエンド上の同じアカウントレコードに解決されますが、復旧とセキュリティの特性は後に重要になる形で異なります。

メールマジックリンク

メールアドレスを入力すると、Cursor がワンタイムリンクを送信します。リンクをクリックするとサインインされます。パスワードは関与しません。

• 信頼できるマシンでは高速です
• サードパーティの ID プロバイダーに依存しません
• 復旧は、そのメールボックスへの継続的なアクセスに完全に依存します

Google

Google アカウントで OAuth を通じてサインインします。Cursor の ID は Google アカウントの識別子に結びつけられます。

• Google の 2FA が有効な場合はデフォルトで強力なセキュリティです
• すでに Google Workspace の中で生活している場合は便利です
• 後で別の Google アカウントに移行するのは容易ではありません

GitHub

GitHub OAuth を通じてサインインします。これは開発者にとって最も一般的なパスです。

• 広く使われており、GitHub のセキュリティ設定から簡単に取り消せます
• コーディングの ID がすでに GitHub 上にある場合に適しています
• Cursor のセッションを GitHub の 2FA の状況に結びつけます

方法	長所	短所
メールマジックリンク	パスワード不要。どのメールボックスでも機能する	メールボックスへのアクセスに完全に依存する。リンク自体が認証情報である
Google	強力な 2FA、馴染みのあるフロー	後で移行するのが難しい
GitHub	開発者に優しく、取り消しが簡単	GitHub が持つ 2FA の強度をそのまま継承する

サインインプロバイダーの切り替え

アプリ内でプロバイダーを切り替えることはできません。GitHub から Google へ、またはマジックリンクから GitHub への移行は、サブスクリプションと履歴を所有する ID を変更するため、サポート支援による移行です。メール変更とまったく同じように扱ってください。チケットを起票し、両方の方法の所有権を証明し、その後は新規サインインを想定します。

アカウントを移行せずに 1 つの方法の使用をやめたいだけの場合は、残したい方法でサインインするだけです。新しいプロバイダーで新規登録しないでください。既存のアカウントを移行するのではなく重複アカウントを作成し、サブスクリプションは古いレコードに取り残されるからです。

すでに強化しているプロバイダーを選ぶ

GitHub アカウントがすでに 2FA を強制している場合、GitHub でサインインすると Cursor はその保護を無料で継承します。クリックが少し速いものではなく、実際に維持している最も強力なセキュリティ態勢を持つプロバイダーを選んでください。

どの方法を選んでも、最初のサインインでアカウントレコードが作成されます。後続のサインインは同じ方法を使う必要があり、そうしないと無言で 2 つ目のアカウントを作成してしまい、これが「サブスクリプションが消えた」という報告のほとんどすべての根源です。

サブスクリプションと使用量の確認場所

重要な 2 つのサーフェスがあります。Web ダッシュボードとアプリ内のアカウント設定です。これらは重複しますが同一ではない情報を表示します。

Web ダッシュボード

ブラウザで https://cursor.com/dashboard を開きます。ダッシュボードは請求関連のあらゆるものについての正式なビューです。

• サブスクリプション：現在のティア（Free、Pro、Pro+、Business、Enterprise）と更新日
• 使用量：現在のサイクルで消費されたリクエスト。モデル別に分類されます
• 請求：請求書、支払い方法、チームの座席数

使用量ビューは、制限にどれだけ近いかを見る場所です。プレミアムモデルのリクエストを、より安価または含まれるモデルと分離するため、どのモデルクラスがクォータを消費しているかを推測ではなく把握できます。

アプリ内の設定 > アカウント

Cursor 内で Ctrl/Cmd + , で設定を開き、アカウントを選択します。このパネルはほぼ読み取り専用です。

• サインアウトコントロール
• 現在のセッションのプランインジケーター
• 請求管理へのディープリンク（ブラウザのダッシュボードを開きます）
• 設定同期のトグル

プランの変更と支払い方法は、意図的に Web ダッシュボードにあります。エディタに支払い UI を埋め込むにはクライアントでカードデータを扱う必要があるため、Cursor はそれをブラウザに保っています。

使用量タブの正しい読み方

カウンターは、カレンダーの月の 1 日ではなく、更新のアンカー日に月次でリセットされます。制限がおかしいように見える場合は、チケットを起票する前にアンカー日を確認してください。

使用量は請求サイクルでリセットされる

17 日に更新される Pro プランは、17 日に使用量をリセットします。カウンターはカレンダーの月ではなく、その日付と比較してください。リセット日に関する期待の食い違いが、偽の「使用量バグ」報告の大部分を引き起こします。

既存アカウントのメールの変更

セルフサービスのメール変更はありません。設定を開いてアドレスを編集し、サブスクリプション、使用履歴、同期設定が追従することを期待することはできません。ID はサインインしたプロバイダーに結びつけられており、その結びつきはユーザーが編集できません。

信頼できる道は、Cursor サポートに連絡し、旧アドレスと新アドレスの両方を制御している証明を添えて、手動のメール変更またはアカウント移行を依頼することです。

アカウント ID の見つけ方

サポートはアカウント ID を求めます。2 つの場所で見つけられます。

• アプリ内の 設定 > アカウント パネルは、サインアウトコントロールの近くにアカウント識別子を表示します
• Web ダッシュボードのページソースまたはアカウントセクションは、同じ識別子を公開します

見つからない場合、それはメールアドレスではないことに注意してください。サポートが正確なレコードを特定するために使用する不透明な識別子です。

所有権の証明

メール変更は事実上 ID の移転であるため、サポートは両方のアドレスを所有している証拠を必要とします。最も明確な証明は、依頼時に各メールボックスから検証メッセージを送信できることです。

サポートチケットのテンプレート

次のテンプレートをコピーして適合させてください。構造化しておくと最初の応答が速くなります。

To: support (via the in-app Contact Support form or [email protected])
Subject: Request to change account email from [email protected] to [email protected]

Account ID: <paste from Settings > Account>
Current email: [email protected]
Requested email: [email protected]
Sign-in method: Email magic link | Google | GitHub

Reason for change:
  Migrating from a personal domain to a company domain.

Proof of ownership:
  - I can send a verification email from [email protected] on request
  - I can also send one from [email protected] on request

Subscription details (if active):
  Tier: Pro (annual)
  Invoice reference: <paste from dashboard>

Impact to preserve:
  - Usage history
  - Settings Sync state

Additional notes:
  <anything else support should know>

パスワードやセッショントークンを決して送らない

サポートはパスワード、マジックリンク URL、またはセッショントークンを求めません。サポートを名乗るメッセージがそれらを要求する場合、それはフィッシングです。共有するのはアカウント ID と所有権証明の手順のみにしてください。

変更には数営業日かかり、その後は新規サインインが必要になると想定してください。デバイスがサインアウトされる短い期間に備えて計画してください。

重複アカウントの統合

重複アカウントは誤って作成しやすいものです。よくあるパターンは、素早い試用のために Google で一度登録し、有料プランを決めたときに GitHub で再び登録するというものです。Cursor はアカウントを自動的に統合せず、アプリ内に統合ボタンもありません。

できることは、サポートを通じて統合を依頼することです。

• ダッシュボードから両方のアカウント ID を特定する
• 有効なサブスクリプションを保持しているレコードを確認する。通常はそれが保持すべきレコードです
• 両方のサインイン方法の所有権証明を提供する
• セカンダリアカウントの使用履歴が統合されるのではなく破棄される可能性があることを明示的に述べる

実際には、使用履歴とチャット履歴は引き継がれません。統合は主に請求を統合し、放棄された ID を解放して、後に有効なアカウントと誤認されないようにするために存在します。

重複は起こる前に防ぐ

有料プランを開始するときは、無料ティアで使ったのと同じサインイン方法を使い続けてください。プロバイダーを切り替える必要がある場合は、新規登録ではなく、サポートを通じた変更として行ってください。新規登録は古いものを移行するのではなく新しいアカウントを作成します。

デバイス間で移行されるもの

設定同期は、サインインしているマシン間で構成のサブセットを引き継ぐ機能です。何が移動し、何が移動しないかを正確に知ることで、2 台目のノート PC をセットアップする際の多くの混乱を防げます。

同期されるもの

• エディタ設定、つまり settings.json
• キーバインド、つまり keybindings.json
• インストール済み拡張機能の一覧
• ユーザースニペット
• アクティブなテーマやレイアウト設定などの UI 状態

同期されないもの

• チャット履歴：各マシンにローカルに保存され、クラウドには保存されません
• Rules ファイル：.cursor/rules はプロジェクトごとで、リポジトリとともに移動します
• MCP 構成：プロジェクトごとまたはマシンごとの mcp.json
• コードベースインデックス：埋め込みは各マシンでローカルに再構築されます

この分割は意図的です。個人的な編集の感覚を定義するものはあなたとともに移動し、プロジェクトを定義するものはプロジェクトに残り、チームメイトが単一の信頼できる情報源を共有します。

設定同期の有効化

設定 > 一般 > 設定同期 で切り替えるか、直接設定します。

// settings.json excerpt
{
  "settingsSync.enabled": true,
  "settingsSync.keybindingsPerPlatform": false
}

keybindingsPerPlatform が false の場合、Cursor はプラットフォームごとに 1 つを維持するのではなく、オペレーティングシステム間で単一のキーバインドセットを同期します。macOS と Windows の間を行き来する場合は便利ですが、プラットフォーム固有のデフォルトを平坦化することがあります。

Rules をコミットし、エディタ設定を同期する

.cursor/rules と mcp.json はプロジェクトリポジトリ内に保ち、コードとともに移動してチームメイト間で一貫するようにします。設定同期にはエディタレベルの設定のみを処理させてください。2 つの信頼できる情報源を分離することで、誰かの個人同期が上書きしてルールが無言で変わるという漂流を防げます。

デバイス制限とサインイン済みマシンの管理

単一のアカウントは複数のマシンで使用でき、各サインインはセッションとして追跡されます。これにより、デバイスを紛失したり共有したときにアクセスを確認して取り消すことができます。

アクティブなセッションの確認

• ダッシュボードを開き、セッションまたはデバイスの領域を見つけます
• 各エントリにはデバイスラベルと最終確認のタイムスタンプが表示されます
• 不明なラベルや予期しない場所は取り消しの合図です

他のデバイスの認証解除

2 つの同等のパスがあります。

• もう使用しないマシンで Cursor 内からサインアウトする
• ダッシュボードからセッションを取り消す。これによりそのデバイスは次のアクションで再認証を強いられます

ダッシュボードからの取り消しは、デバイスがまだ到達可能であることに依存しないため、より強力なオプションです。

すべての場所からサインアウト

マシンを紛失、売却、または共有した場合は、そのセッションを取り消し、サインイン方法の背後にある認証情報をローテーションします。

• Google または GitHub アカウントのパスワードを変更するか、そのプロバイダーの設定で Cursor の OAuth 許可を取り消します
• マジックリンクでサインインした場合はメールボックスのパスワードを変更します

プロバイダーの認証情報をローテーションするとアカウント全体でトークンが無効になり、これがグローバルサインアウトに最も近いものです。

アカウントの削除

削除は永続的で、2 つの異なるスコープがあります。Cursor がクラウドで所有するものと、ディスク上にあるものです。

データはどうなるか

• クラウド：アカウントレコード、サブスクリプションの紐づけ、使用履歴、同期設定が削除されます
• ローカル：ディスク上のファイルは影響を受けません。Cursor がそれらを所有したことはないためです
• バックアップ：削除は遅延スケジュールでバックアップを通じて伝播するため、短時間の復元ウィンドウが存在する場合があります

削除する前にエクスポートする

削除は元に戻せないため、これを最初に行ってください。

• 気にかかるチャット履歴を各マシンのローカルストレージからコピーします
• settings.json、keybindings.json、およびすべての .cursor/rules ファイルを保存します
• 自分の記録用にダッシュボードから請求書をダウンロードします
• サブスクリプションを明示的に解約します。そうしないと、もうサインインできないレコードに対して請求が続く場合があります

削除する前に請求を解約する

有効なサブスクリプションが紐づいた状態でアカウントを削除すると、ダッシュボードからそのサブスクリプションを管理する機能を失う可能性があります。まずプランを解約し、解約メールを確認してから、削除を進めてください。

仕事用と個人用アカウントの分離

ID を混ぜることは、仕事のコンテキストを個人の使用に漏らす、あるいはクライアントのデモ中に個人の拡張機能が有効になっているのを見つける最速の方法です。2 つの世界を物理的に分離してください。

• ローカルのアプリケーションデータが決して重ならないよう、OS ユーザーアカウントを分ける
• 2 つの Cursor インスタンスが共存できるよう、別々のディレクトリにインストールする
• 異なるプロバイダーでサインインする。仕事は Google Workspace SSO 経由、個人は GitHub 経由
• 拡張機能一覧とキーバインドが混ざらないよう、別々の設定プロファイルを使う

コマンドラインフラグで 2 つ目の隔離されたインスタンスを実行できます。

# Launch a second instance with its own data and extensions directories
cursor --user-data-dir="$HOME/.cursor-work" --extensions-dir="$HOME/.cursor-work/extensions"

隔離されたインスタンスは独自のチャット履歴、独自のインデックス済みコードベース、独自のアカウントを保持し、複数のクライアントにまたがってコンサルティングや請負を行うときにまさに望ましいものです。

よくあるアカウント問題のトラブルシューティング

いくつかのアカウント問題がサポートチャネル全体で繰り返し発生します。素早く解決する方法は次のとおりです。

サインインしているのにすべてがロックされているように見える

サブスクリプションが有効であるにもかかわらず Cursor がプランを Free と表示する場合、ほぼ確実に、別のプロバイダーで作成された 2 つ目の重複アカウントにサインインしています。アプリに表示されるアカウント ID をダッシュボードのレコードと比較してください。異なる場合は、2 つ目のプランを購入するのではなく、上記の統合パスを使用してください。

マジックリンクが届かない

• スパムフォルダとプロモーションフォルダを確認してください。マジックリンクのメールは頻繁にフィルタリングされます
• エイリアスではなく、実際に登録したアドレスを入力したことを確認してください
• 別のリンクを要求する前に 1 分待ってください。新しいものを要求すると前のリンクが無効になることがあります
• メールボックスがカスタムドメインにある場合、その DNS とスパムフィルタリングがメッセージを無言で破棄していないことを確認してください

設定同期が適用されない

• 設定 > 一般 > 設定同期 で同期が有効であることを確認する
• 更新されていないマシンでサインアウトして再サインインする
• チャット履歴、rules、MCP 構成は決して同期されないため、それらの欠如はバグではなく想定内であることを覚えておく

サブスクリプションが誤った座席数を示す

チームプランの場合、座席の管理はダッシュボードの請求の下で行います。メンバーを削除すると、即時ではなく次のサイクルで座席が解放されるため、サイクル途中の数は実際には正しいのに止まって見えることがあります。

デバイス間でのアカウント ID の不一致

すべてのデバイスは同じアカウント ID を報告すべきです。2 台のマシンが食い違う場合、それらは異なるアカウントにサインインしています。サブスクリプションを保持するアカウントに落ち着き、他をサインアウトし、正しいプロバイダーで再サインインしてください。

まずアカウント ID を確認する

「プランが消えた」「同期が壊れた」というほぼすべての報告は、重複アカウントに行き着きます。デバイス間でアカウント ID を比較することは、チケットを開く前に実行できる最速の単一の診断です。

セキュリティのベストプラクティス

ほとんどのアカウントリスクをカバーする短いチェックリストです。

• 2FA を強制するプロバイダーでサインインする。GitHub や Google がすでにそうしているなら、その保護は Cursor にも引き継がれます。
• パスワードベースのオプションが存在する場合は、常に一意のパスワードを使用する。
• アクティブなセッションを定期的に確認し、心当たりのないものは取り消す。
• マジックリンクのメールを有効な認証情報として扱う。リンクを開く人は、それが期限切れになるまであなたのセッションを取得します。
• 共有または借用したマシンでは、終わったらサインアウトし、不明な場合はすべての場所からサインアウトする。
• セッショントークン、マジックリンク、またはパスワードを、チャット、チケット、またはアカウントを「修正」すると称するサードパーティサイトに決して貼り付けない。

四半期ごとのアカウントレビュー

四半期に一度、次のことに 5 分費やしてください。これでほとんどの問題が深刻化する前に捕捉できます。

• 使用するすべてのデバイスでアカウント ID を比較し、不一致を解消する
• 心当たりのないセッションを取り消す
• 請求のアンカー日がまだ期待と一致することを確認する
• サインインプロバイダーがまだ 2FA を強制していることを検証する
• settings.json、keybindings.json、および .cursor/rules ファイルをバックアップする

アカウントは、請求、データ、デバイスアクセスがすべて出会う層です。正しいサインイン方法を選ぶのに数分費やし、セッションを定期的に確認することで、後に何時間もの復旧を節約できます。