Claude Codeは一度に1つのログインしか保持しない。複数を並行して動かす方法

同じマシンで仕事用アカウントと個人用アカウントを併用するための実践ガイド: どのログインが有効かを決めるたった1つの環境変数、ターミナルが2つを超えるとshell方式が破綻する理由、そしてプロジェクトごとにアカウントを固定する方法。

Claude Codeを仕事でも自分のプロジェクトでも使っている人の多くが、一度は経験する場面があります。仕事のセッションを終えてサイドプロジェクトに切り替え、エージェントがまだ勤務先の支払うアカウントにログインしたままだと気づく。そこでログアウトし、自分のアカウントで入り直し、30分後には逆の作業をする羽目になります。

このループは機能が足りていないという話ではありません。Claude Codeがログイン情報をどこに置いているかの帰結であり、その場所さえ分かってしまえば、複数アカウントの併用はワークフローの問題ではなく、設定の細部になります。

1つの環境変数が、どのアカウントを有効にするかを決める

Claude Codeは、認証情報をデータベースや、プロファイル単位のキーチェーンエントリに保存しているわけではありません。必要なものはすべて1つのディレクトリから読み込みます: 認証情報、セッションのメタデータ、そしてプロジェクトごとの履歴です。

そのディレクトリはCLAUDE_CONFIG_DIRが指す場所です。一度も設定していなければ~/.claudeになります。

Claude Codeがアカウントを解決する仕組みの図: CLAUDE_CONFIG_DIR環境変数が、credentials.json、セッションのメタデータ、プロジェクトごとの履歴を含む1つのディレクトリを指しており、変数が未設定の場合は~/.claudeにフォールバックする。

これが仕組みのすべてで、ここには便利な性質があります: アカウントがグローバル設定ではなくディレクトリである以上、アカウントを2つ持つことはディレクトリを2つ持つことと同じです。両者の間で共有されるものは何もありません。どちらも無期限にログインしたままで、互いの存在を知りません。

だから、素朴なやり方でもちゃんと動きます:

# 個人用
CLAUDE_CONFIG_DIR=~/.claude claude

# 仕事用
CLAUDE_CONFIG_DIR=~/.claude-work claude

2つ目の中で一度/loginを実行すれば、1台のマシンで2つのアカウントが同時に生きている状態になります。

shell方式がつらくなるのはどこか

上の2行は、ターミナルを一度に1つしか開かず、きちんと自制できるなら本当に十分です。それが十分でなくなる理由は3つあり、しかも積み重なります。

この変数はマシン単位ではなくプロセス単位です。 新しいターミナル、新しいペイン、エディタに統合されたshellは、どれもプロファイルのデフォルトから始まります。.zshrcでexportすれば、問題が移動するだけです: 今度はもう一方のアカウントを忘れ続けることになります。

どのアカウントが有効かを教えてくれるものが何もありません。 Claude Codeはプロンプトにアカウントを表示しません。ターミナルが2つ開いていて、片方が仕事用アカウントで動いていても、見た目は同じです。気づくのはたいてい、請求を確認したときです。

並列実行に耐えられません。 面白い使い方はどれも、複数のプロジェクトで複数のエージェントを同時に走らせるものです。同時セッションが2つを超えた時点で、どのペインをどの変数で起動したかを覚えておくのは自制の問題ではなく、設計の問題です。

比較図: 左側は、各ターミナルでCLAUDE_CONFIG_DIRをexportしてClaude Codeのアカウントを選ぶ方式で、3つ目のターミナルではどのアカウントが有効なのか見た目では分からない。右側は、エージェント単位のオーバーライドを備えたうえでアカウントをプロジェクトに紐づける方式で、エージェントの起動時に自動で解決される。

解決策はshellを増やすことではありません。起動時に判断するのをやめ、実際にアカウントを決めているもの、つまりプロジェクトにアカウントを紐づけることです。

アカウントはターミナルではなくプロジェクトに紐づける

たいていの場合に欲しいのはコマンドではなく、ルールです。たとえば「このクライアントのリポジトリは常にこのクライアントのアカウントで動く」といったものです。そのルールさえ存在すれば、誰も何も覚えておく必要がなくなります。

これをきちんとやるには、決められた順序でアカウントを解決する必要があります。ルールには例外が必要だからです。プロジェクト全体のデフォルトはほとんどの場合正しいのですが、特定のエージェントだけ別の場所で動かしたいことがあります: テスト用アカウントでの使い捨ての実験や、より大きなクォータを持つシート上で動かすレビュー用エージェントなどです。

アカウント解決の4段階の順序を示す図: エージェント単位のオーバーライドがプロジェクトへの固定に優先し、それがアプリケーションのデフォルトに優先し、最終的にシステムのデフォルトディレクトリ~/.claudeにフォールバックする。

上から読んで、最初に一致したルールが勝ちます。エージェントのオーバーライドはプロジェクトへの固定に勝ちます。プロジェクトへの固定は、全体のデフォルトとして設定したものに勝ちます。どこにも何も設定されていなければ~/.claudeに行き着きます。これは新規インストール直後の状態そのものです。この最後のフォールバックは重要です: つまり、既存の環境にこれを導入しても、明示的に何かを固定するまでは何も変わらないということです。

これがAgentsRoomが実装しているモデルです。各アカウントは管理されたディレクトリで、サインインはshellではなくアプリの中で行われ、上記の解決処理はエージェントの起動時に走って、そのプロセスにだけCLAUDE_CONFIG_DIRを設定します。CCSのようなサードパーティの切り替えツールをすでに使っているなら、ログインし直す代わりに、既存のプロファイルディレクトリをアカウントとして指定できます。

同じ問題はCodexにもあり、変数だけが違う

複数のプロバイダーを使っているなら、この問題には2回ぶつかります。形は同じで変数は違うため、片方向けに作られた切り替えツールはもう片方をカバーしません。Codex側はCodexのマルチアカウントで別途ドキュメント化しており、サインインの流れの違いもそこに書いてあります。

一般論として一度言っておく価値があります: アカウントの分離はプロバイダーごとの仕組みです。これをグローバルに扱えると謳うツールは、各プロバイダーを個別にラップしているか、1つしかサポートしていないかのどちらかです。

実際にトークンを消費しているアカウントを把握する

アカウントを分ける理由の半分は分離ですが、もう半分は、特にクライアントが支払っている場合に、消費がどこに計上されるのかを把握することです。

ここがshell方式で静かに壊れる部分です。~/.claudeしか見ない使用量リーダーは、エージェントが別の場所で動いた瞬間に過少報告を始めます。しかも数字はもっともらしく見えるので、何週間も誰も気づきません。アカウントを認識できるリーダーは、デフォルトのディレクトリだけでなく、設定されたすべてのディレクトリを走査する必要があります。

アカウントごと、セッションごとの数値が必要なら、計測側はClaude Codeのトークン使用量を確認する方法で扱っています。リアルタイムの表示はトークン使用量のページにあります。

これは何のためのものではないか

1点だけはっきりさせておきます。よく出る質問であり、黙っているよりまっすぐ答えるに値するからです。

ここまでの内容はすべて、すでに正当に存在しているアカウントを分離するための話です。勤務先が費用を負担しているシートと、自分で支払っている個人サブスクリプションは2つの異なる商取引関係であり、それらを混ざり合わせずに1台のマシンに共存させることは、実在するごく普通のニーズです。クライアントのトークンをそのクライアントに請求することも、実験用アカウントを本番用から遠ざけておくことも同じです。

契約しているプランの利用上限を回避するために追加のアカウントを作ることは、それとはまったく別の話であり、利用ポリシーが狙いを定めているのはまさにそこです。ここで説明した仕組みはそれを許容できるものにはしませんし、それを自動化するツールは、あなたが署名した合意に違反する手助けをしていることになります。2つ目のアカウントが、別の誰かが支払っているから存在するのであれば問題ありません。レート制限をリセットするために存在するのであれば問題です。判断の基準はAnthropicの利用ポリシーであって、この記事ではありません。

実際によく聞かれる質問

同じPCでClaude Codeのアカウントを2つ使えますか?

はい。Claude Codeは、認証情報、セッションのメタデータ、プロジェクトごとの履歴を、CLAUDE_CONFIG_DIRが指すディレクトリから読み込みます。デフォルトは~/.claudeです。この変数を2つ目のディレクトリに向けてそこでログインすれば、同じマシン上に独立した2つのアカウントが存在することになります。2つのディレクトリの間では何も共有されないため、どちらもログインしたままの状態を保てます。

ログアウトせずにClaude Codeのアカウントを切り替えるには?

そもそもログアウトする必要はありません。ログアウトして入り直しても同じディレクトリを使い回すため、2つ目のセッションを得る代わりに1つ目を失うことになります。そうではなく、アカウントごとに専用の設定ディレクトリを用意し、CLIを起動するときにCLAUDE_CONFIG_DIRを設定して選びます。どちらの認証情報もディスク上で有効なまま残るので、切り替えのコストはゼロです。

Claude Codeはログイン情報をどこに保存していますか?

CLAUDE_CONFIG_DIRが指すディレクトリです。変更していなければ~/.claudeになります。認証情報そのものは、そのディレクトリ内の.credentials.jsonというファイルに置かれ、その隣にセッションのメタデータとプロジェクトごとの履歴が並びます。このディレクトリ1つがアカウントのすべてであり、だからこそ差し替えが小手先のハックではなく、きれいな切り替えになります。

2つのエージェントを別々のClaudeアカウントで同時に動かせますか?

はい。各エージェントのプロセスが自分専用のCLAUDE_CONFIG_DIRを環境変数として受け取っていれば可能です。この変数はグローバルにではなく起動時にプロセス単位で読み込まれるため、異なる値で起動した2つのエージェントは並行して別々のアカウント上で動きます。仕事用のプロジェクトと個人のプロジェクトを同じウィンドウで扱えるのは、この仕組みのおかげです。

Claudeのアカウントを複数持つことはAnthropicの規約違反ですか?

目的の異なるアカウントを別々に持つこと自体はごく普通のことです。勤務先が費用を負担しているシートと、自分で支払っている個人サブスクリプションは、2つの異なる商取引関係です。利用ポリシーが狙いを定めているのは、契約しているプランの利用上限を回避するためにアカウントを作ることです。2つ目のアカウントが、別の誰かが支払っているから存在するのであれば問題ありません。レート制限をリセットするために存在するのであれば問題です。判断の基準はAnthropicの利用ポリシーです。

要点だけ

Claude Codeはアカウントをディレクトリとして保存し、どれが有効かはCLAUDE_CONFIG_DIRが決めます。ディレクトリが2つあればアカウントも2つあり、どちらもログインしたままで、両者の間で共有されるものは何もありません。

このshell版は、ターミナルを2つ以上開くまでは問題なく動きます。その先で欲しくなるのは、アカウントがプロジェクトの属性であり、例外にはエージェント単位のオーバーライドがあって、起動時に正しい認証情報が自動で紐づけられ、誰も何も覚えなくていい状態です。

AgentsRoomをダウンロード

あなたのAIエージェント(Claude、Codex、Antigravity CLI、OpenCode、Aider、Grok Build、Mistral Vibe、Kimi Code)を単一のウィンドウから実行します。

無料AgentsRoomをダウンロード

コンパニオンアプリ:外出先でもエージェントを確認

Claude、Codex、Antigravity CLI、またはその他の AI プロバイダーを使用します。

拡張機能を入手
Chrome Web Store

バグや要望を公開バックログに直接送信できます。

実際の AgentsRoom の様子。

マルチプロジェクト
マルチプロバイダー
マルチエージェント
ライブステータス
ファイル差分
モバイルアプリ
ライブプレビュー
エージェントチーム
ブラウザテスト
バックログ駆動開発
プロンプトライブラリ
スキルライブラリ
すべての機能を見る

続きを読む