Claude Codeのアカウント切り替え——CLAUDE_CONFIG_DIRだけでは個人用とクライアント用が完全に分離しない話
Claude Codeで個人用アカウントとクライアント案件用アカウントを切り替える方法を整理した。公式の/login切り替えとCLAUDE_CONFIG_DIRの違い、CLAUDE_CONFIG_DIRが「未公式かつ不完全」な理由をGitHub Issueベースで検証し、フリーランスが本当に分離すべき理由まで解説する。
エンジニアのゆとです。
フリーランスで複数案件を掛け持ちしていると、Claude Codeのアカウントを個人用とクライアント用で分けたくなる瞬間が必ず来る。無料枠を使い切った、クライアントのTeamプランを使う必要がある、契約上クライアントのコードを個人アカウントに触れさせたくない、理由は色々あるはずだ。
この記事では、Claude Codeのアカウント切り替え方法を整理したうえで、よく紹介される CLAUDE_CONFIG_DIR という環境変数が「実は公式ドキュメントに載っていない」「実際に分離しきれていない」という点をGitHub Issueベースで検証する。ついでに、なぜフリーランスにとってはこの「分離しきれない」が地味に危ないのかも書いておく。
一番シンプルな切り替え方: /login のやり直し
Claude Codeで一番手軽なのは、/login で再ログインする方法だ。
claude
> /logout
> /loginX（旧Twitter）上でもエンジニアの和田卓人氏が「切り替えるにはClaude Code側で一度 /logout して別アカウントで認証し直せばOK」と紹介している通り、これが最も確実な公式の切り替え手順になる。
Claude.ai（Web版）側にも同じ仕組みがあって、同じメールアドレスに個人用アカウントとTeam/Enterpriseアカウントが紐づいている場合は、左下のアイコンをクリックして切り替えられる。ただしこれはあくまで「今アクティブなアカウントを差し替える」操作で、2つのアカウントを同時並行で使い分けるものではない。1日に何度もクライアントA・クライアントBを行き来する働き方には向かない。
もう1つ、環境変数で認証情報を直接渡す方法もある。公式ドキュメントに明記されているのは以下の3系統だ。
ANTHROPIC_API_KEY— APIキーをヘッダーとして送信。サブスクリプションの代わりに使うANTHROPIC_AUTH_TOKEN— カスタムトークンを送信ANTHROPIC_PROFILE—claude auth loginで作成したプロフィール名を指定。/loginの認証情報よりも優先される
複数のAPIキーやプロフィールをコマンドの前に環境変数として付けて起動すれば、その場限りでアカウントを切り替えられる。ただしこれもセッションをまたいだ「同時使用」を保証する仕組みではない。
CLAUDE_CONFIG_DIRで分離できるという話、実は半分正しい
個人用・仕事用でディレクトリごと分けたいときによく紹介されるのが CLAUDE_CONFIG_DIR という環境変数だ。
# 個人用
CLAUDE_CONFIG_DIR=~/.claude-personal claude
# クライアントA用
CLAUDE_CONFIG_DIR=~/.claude-client-a claudeシェルのエイリアスに登録しておけば、コマンド一発でアカウントを切り替えられる、という触れ込みだ。実際、日本語コミュニティにもこのやり方を紹介する記事がいくつかある。
ただし、これを実際にやってみると「完全には分離しない」という報告が出ている。理由を確認するために公式ドキュメントとGitHub Issueを見てみた。
まず、CLAUDE_CONFIG_DIR はClaude Codeの環境変数リファレンス（code.claude.com/docs/en/env-vars）に記載がない。公式にサポートされている設定ファイルの場所として明記されているのは次の3つだけだ。
~/.claude/settings.json（ユーザー全体）.claude/settings.json（プロジェクト共有）.claude/settings.local.json（ユーザーのプロジェクト限定）
CLAUDE_CONFIG_DIR はこのリストに出てこない。つまり非公式（もしくは未ドキュメント化）の挙動に依存していることになる。
さらに、Anthropicのリポジトリには実際にこの問題を報告したIssueがある（anthropics/claude-code Issue #3833）。報告内容は、CLAUDE_CONFIG_DIR を設定してもグローバル設定（$CLAUDE_CONFIG_DIR/.claude/）とは別に、作業ディレクトリ側にもローカル設定（.claude/settings.local.json）が作成されてしまうというもの。「完全集約」「グローバルとワークスペース固有のハイブリッド」「別目的の変数」のどれが意図された挙動か不明、という指摘とともに報告されたこのIssueは、コメントがつかないまま「Closed as not planned」（対応予定なしでクローズ）になっている。
実務でこれがどう効いてくるかというと、Qiitaに投稿されている実体験の報告がわかりやすい。個人用・仕事用でディレクトリを分けて運用していたエンジニアが調査したところ、ルールファイルが2つの異なるラベルで2回注入されていたという。原因は、デフォルトの ~/.claude/ がフォールバックとしてスキャンされ続けていたことだった。結果として、毎ターン100KB以上のコンテキストが無駄に消費されていたそうだ。内訳は、ルールファイルの重複注入、使わない言語向けのルール群、有効化されたままのプラグインのスキル説明文、肥大化したプロジェクトCLAUDE.md、各種フックの注入テキストだったという。
この報告の教訓は明快で、「環境変数だけじゃ足りない」。CLAUDE_CONFIG_DIR を設定しただけでは、デフォルトの ~/.claude/ が生きている限りそこも読みにいく可能性がある。完全に分離したいなら、デフォルトディレクトリそのものを物理的にリネームするか退避する必要がある。
# デフォルトディレクトリを退避して、フォールバック読み込みを断つ
mv ~/.claude ~/.claude.bakこれをやってはじめて、CLAUDE_CONFIG_DIR で指定した各ディレクトリだけが参照される状態になる。フックのパスやプラグインレジストリのパスがディレクトリごとに絶対パス指定されている場合は、それぞれのディレクトリ用に個別修正が必要になる点も忘れずに。
それでも完全に分離しきりたいなら: 物理分離という選択肢
CLAUDE_CONFIG_DIR ＋ デフォルトディレクトリの退避で、実用上はかなりのところまで分離できる。ただし同一ホストOS上で動いている以上、Bashツール経由でホームディレクトリの外に出るような操作をされた場合の隔離は保証されない。
クライアントの契約でセキュリティ要件が厳しい場合や、「クライアントAのコードが誤ってクライアントBのセッションから見える」ことを構造的にゼロにしたい場合は、Dev ContainerやDockerのボリューム分離まで踏み込む選択肢もある。プロジェクトごとにコンテナを分ければ、ファイルシステムレベルで隔離されるので、環境変数の設定漏れに起因する事故は起きなくなる。この場合の代償は、コンテナの起動・管理という運用コストだ。
もう少し軽い代替として、そもそもClaude Code自体をサンドボックス化して権限を絞る設定もある。ファイルアクセス範囲やネットワークアクセスを制限しておけば、アカウントの分離とは別軸で「意図しない範囲に手を出さない」ための保険になる。サンドボックス設定の詳細は別記事にまとめてある。
まとめると、分離の強度は次の順で強くなる。
| 方法 | 分離の強度 | 運用コスト | 向いているケース |
|---|---|---|---|
/login の都度切り替え | 弱い（同時使用不可） | ほぼゼロ | 単発の作業、たまにしか切り替えない |
ANTHROPIC_PROFILE / APIキー環境変数 | 弱〜中（認証のみ分離） | 低 | CI/自動化スクリプトでの一時的な切り替え |
CLAUDE_CONFIG_DIR + デフォルト退避 | 中（同一ホスト内では実用十分） | 中 | 複数クライアントを日常的に往復する個人開発者 |
| Dev Container / Docker分離 | 強い（ファイルシステムレベル） | 高 | セキュリティ要件が厳しい案件、契約上の隔離義務がある案件 |
フリーランス視点: なぜ「分離しきれない」が地味に効くか
自分がこの話を掘り下げた理由は、複数クライアントの案件を並行して回しているとき、CLAUDE.mdやhooksの設定がクライアントをまたいで漏れることに実務上のリスクがあるからだ。
たとえば、クライアントAのプロジェクト固有のルール（社内ライブラリ名、内部API仕様、命名規則）がクライアントBのセッションに紛れ込んだ場合、それ自体は動作エラーにはならない。むしろ厄介なのは「気づかないまま」情報が混ざることで、契約上のNDA（秘密保持義務）に抵触するリスクが生まれる点だ。トークン消費が増えるという実害以上に、この「見えない漏洩」のほうが重い。
もう1つ、フリーランスならではの実務的な理由として、案件ごとのコスト管理がある。個人アカウントと案件用アカウントを分けておけば、「今月どの案件にどれだけAPIコストがかかったか」を後から集計しやすい。トークン消費量の確認方法や案件別のコスト分離については別記事で詳しく書いているので、アカウント分離とあわせて読むと運用がしやすくなるはずだ。
ログイン関連のエラーで詰まった場合は、こちらのトラブルシューティング記事も参考にしてほしい。アカウント切り替えの過程で認証エラーが出るケースは実はそこそこある。
まとめ
- Claude Codeのアカウント切り替えの公式手順は
/loginの再認証、またはANTHROPIC_PROFILE/ APIキーの環境変数指定 CLAUDE_CONFIG_DIRはよく紹介される分離方法だが、公式ドキュメントに記載がなく、GitHub Issue #3833で「デフォルトディレクトリが依然としてフォールバックされる」という不具合が報告されている（対応予定なしでクローズ済み）- 実際に運用したエンジニアの報告では、ルールファイルの二重注入で毎ターン100KB超のコンテキストが無駄になっていた
- 本当に分離したいなら、
CLAUDE_CONFIG_DIRの指定に加えてデフォルトの~/.claude/を物理的に退避する必要がある - セキュリティ要件が厳しい案件では、Dev ContainerやDockerでのボリューム分離まで検討する価値がある
- フリーランスにとっては、コンテキスト消費の無駄より「気づかない情報混入によるNDA抵触リスク」のほうが重い問題
「アカウントを分ける」という一見単純な作業の裏に、こういう落とし穴があることを知っているかどうかで、複数案件を安全に回せるかが変わってくる。
