TAKASHI TOYOFUKU

Claude Codeの複数アカウント運用——設定分離・alias・symlinkと作業の引き継ぎ

Claude Codeの複数アカウント運用——設定分離・alias・symlinkと作業の引き継ぎ

September 7, 2026

CLAUDE_CONFIG_DIRとaliasでアカウントを使い分け、共通スキルはsymlinkで共有する。同じプロジェクトの作業を、文書やセッション履歴から再開する方法もまとめた。

複数アカウントを使うたびに、ログインし直す手間をなくしたい

Claude Codeを複数のアカウントで使っている。切り替えるたびにログアウトして、別のアカウントでログインするのは面倒だ。

今はアカウントごとに設定ディレクトリを分け、起動用のaliasを付けて運用している。たとえば、自分のアカウントは~/.claude-toyofukuxを使い、ターミナルでcctと打って起動する。

一方で、スキルや共通の指示までアカウントごとにコピーすると、更新のたびに同じ修正を繰り返すことになる。そこはsymlinkで共有する。

もう一つ考える必要があるのが、同じプロジェクトを別アカウントで触るときの作業の引き継ぎだ。設定を分けると会話履歴の保存先も分かれるので、作業状況はプロジェクト内の文書に残す。不意に中断したときは、元の設定ディレクトリに残ったセッション履歴を探して経緯を補う。

この記事では、macOSのzshで使っている構成をもとに、この三つを順番に紹介する。仕事用のアカウント名は、説明用にworkとする。

CLAUDE_CONFIG_DIRでアカウントごとの設定先を分ける

Claude Codeのユーザー設定は、通常~/.claudeに保存される。環境変数CLAUDE_CONFIG_DIRを指定すると、この保存先を変更できる。公式の環境変数リファレンスにも、複数アカウントを並行して使う例が載っている。

CLAUDE_CONFIG_DIR="$HOME/.claude-toyofukux" command claude

ここでは、起動するコマンドにだけ環境変数を渡している。シェル全体の設定先を変えずに、起動するたびに使うディレクトリを選べる。

構成は次のようになる。

~/.claude/             共通ファイルの配置先としても使う
~/.claude-toyofukux/   自分のアカウント用
~/.claude-work/        仕事用のアカウント用（説明用の名前）

認証情報はファイルを手でコピーせず、それぞれの設定先を指定してログインする。macOSでは通常Keychainが使われ、CLAUDE_CONFIG_DIRに応じて認証情報の参照先も分かれる。保存方法の詳細は公式の認証情報管理の説明を参照してほしい。

なお、ここで分けるのはユーザー設定の保存先だ。同じプロジェクトのファイルや、プロジェクト内のCLAUDE.mdは引き続き同じものを使う。

設定ディレクトリを作り、それぞれのアカウントでログインする

まず、アカウントごとのディレクトリを作る。

mkdir -p "$HOME/.claude-toyofukux" "$HOME/.claude-work"

続いて、一つずつログインする。ブラウザが開いたら、その設定先で使いたいアカウントを選ぶ。

CLAUDE_CONFIG_DIR="$HOME/.claude-toyofukux" command claude auth login

一つ目のログインを終えたら、仕事用も同じように設定する。

CLAUDE_CONFIG_DIR="$HOME/.claude-work" command claude auth login

ブラウザに残っているログイン状態によっては、両方とも同じアカウントを選んでしまうことがある。設定後は、各ディレクトリを指定してログイン先を確認する。

CLAUDE_CONFIG_DIR="$HOME/.claude-toyofukux" command claude auth status --text
CLAUDE_CONFIG_DIR="$HOME/.claude-work" command claude auth status --text

auth loginとauth statusは公式CLIリファレンスにあるコマンドだ。

aliasを登録して、短いコマンドでアカウントを使い分ける

毎回環境変数を書くのは面倒なので、~/.zshrcにaliasを登録する。以下は、普段のaliasからアカウント切り替えに必要な部分を抜き出した例だ。

alias cct='CLAUDE_CONFIG_DIR="$HOME/.claude-toyofukux" command claude'
alias ccw='CLAUDE_CONFIG_DIR="$HOME/.claude-work" command claude'

cctは実際に使っている名前で、ccwはこの記事の仕事用アカウントに対応する例だ。自分が覚えやすい名前にすればよい。command claudeは、同名のシェル関数などを挟まずにコマンドを呼び出すために使っている。

保存したら、新しいターミナルを開くか、設定を読み直す。

source ~/.zshrc

あとは、作業するプロジェクトへ移動して起動するだけだ。

cd ~/workspace/my-app
cct

仕事用で起動するときは、同じ場所でccwを使う。aliasの後ろには通常の引数も付けられるので、ログイン状態の確認も短く書ける。

cct auth status --text
ccw auth status --text

これで、普段の切り替えは起動コマンドを選ぶだけになる。認証が切れた場合の再ログインも、対象のaliasからcct auth loginのように実行する。

スキルなどの共通ファイルはsymlinkで共有する

共通スキルを~/.agents/skillsにまとめる

設定ディレクトリを分けても、日常的に使うスキルは共通にしたい。実体を一か所に置いて、各アカウントからsymlinkで参照すれば、修正する場所も一か所で済む。

今の環境では、共通スキルの実体を~/.agents/skillsに置いている。~/.claude/skillsには、その実体へのリンクとClaude Code向けのスキルを置き、各アカウントのskillsは~/.claude/skills全体へリンクしている。

~/.agents/skills/
└── my-skill/
    └── SKILL.md


~/.claude/skills/
├── my-skill -> ~/.agents/skills/my-skill
└── claude-only-skill/
    └── SKILL.md


~/.claude-toyofukux/skills -> ~/.claude/skills
~/.claude-work/skills     -> ~/.claude/skills

my-skillなどのスキル名は説明用だ。~/.agents/skillsは、自分が共通ファイルの置き場として選んだパスであり、この記事ではClaude Codeのスキル読み込み先へリンクを張って使う。

スキル単位のsymlinkをたどってSKILL.mdを読む動作は、公式のスキルドキュメントでも説明されている。

各設定ディレクトリからsymlinkを張る

たとえば、すでに~/.agents/skills/my-skill/SKILL.mdがあるなら、まずClaude Codeから参照できる場所にリンクする。

mkdir -p "$HOME/.claude/skills"


if [ -f "$HOME/.agents/skills/my-skill/SKILL.md" ] &&
   [ ! -e "$HOME/.claude/skills/my-skill" ] &&
   [ ! -L "$HOME/.claude/skills/my-skill" ]; then
  ln -s "$HOME/.agents/skills/my-skill" "$HOME/.claude/skills/my-skill"
fi

次に、各アカウントのskillsを共有先へリンクする。

for config_dir in "$HOME/.claude-toyofukux" "$HOME/.claude-work"; do
  if [ -e "$config_dir/skills" ] || [ -L "$config_dir/skills" ]; then
    printf '既存のskillsを確認してから移行: %s\n' "$config_dir/skills"
  else
    ln -s "$HOME/.claude/skills" "$config_dir/skills"
  fi
done

この例では、既存のファイル・ディレクトリ・リンクがあれば作成をスキップする。すでにスキルを置いている場合は、中身を共有先と比較し、必要なものを移してから元のディレクトリを別名で退避する。その後、もう一度リンクを作る。

リンク先は次のコマンドで確認できる。

ls -ld "$HOME/.claude-toyofukux/skills" "$HOME/.claude-work/skills"

これで、~/.agents/skills/my-skill/SKILL.mdを更新すれば、両方のアカウントから同じ内容を参照できる。構成を変えたあとは、各aliasから起動し、使いたいスキルが認識されているかも確認する。

共有するものと、アカウントごとに分けるもの

自分の環境では、skillsのほかにCLAUDE.md、agents、rulesも~/.claude側へリンクしている。どのアカウントでも使いたい指示や道具を、一か所で管理するためだ。

ただし、すべてを共有する必要はない。アカウント固有のスキルがあるなら、skills全体をリンクせず、共通にしたいスキルだけを個別にリンクすればよい。

settings.jsonも共通化できるが、自分の環境でも共有しているものと、別ファイルにしているものがある。権限、hooks、環境変数などが含まれるので、アカウントごとの差が必要なら分けておく。MCP接続も、接続先や認証の違いを確認してから共有範囲を決める。

認証情報やセッション履歴のprojectsは、この構成では共有しない。設定ディレクトリ全体をリンクするのではなく、共通にしたいファイルやディレクトリを選んでいる。

同じプロジェクトを別アカウントで再開する

作業状況と次の一手をプロジェクト内の文書に残す

同じプロジェクトを開けば、コードは同じものを見られる。しかし、前のアカウントとの会話まで自動で引き継がれるわけではない。

Claude Codeは会話をローカルのJSONLファイルに保存する。通常の保存先は~/.claude/projects/で、設定先を分けた環境では、それぞれのディレクトリのprojects/に分かれる。セッションの保存と再開の仕組みは公式ドキュメントにも説明がある。

そのため、この構成でccw --continueを実行しても、cctで進めていた会話をそのまま続けられる前提にはしない。同じファイルを開くことと、同じ会話を再開することは別だ。

作業の区切りで、プロジェクト内に状況を文章で残しておく。すでにworklogやタスクごとの文書があれば、そこへ追記すればよい。新しく置くなら、たとえばdocs/handoff.mdのようなファイルにする。

# 作業の引き継ぎ


- 更新日時: 2026-09-07 14:00 JST
- 目的: 記事一覧に新しい記事を表示する
- 依頼範囲: 記事追加から本番公開まで
- 作業場所: ~/workspace/my-app
- ブランチ: posts/new-article
- 最後に確認したcommit: abc1234（例。実際のSHAに置き換える）
- 完了: 本文とメタデータを追加した
- 変更ファイル: src/posts/2026/09/new-article.md
- 検証: ローカルで記事を表示。production buildは未実施
- 未決事項: なし
- 次の作業: buildを実行し、記事一覧と公開URLを確認する
- 実行中の処理: なし

完了したことだけでなく、未確認のことと次にやることを書く。「ビルドした」と「ビルドが成功した」も分ける。裏で処理が動いているなら、その場所や確認方法も残しておくと、切り替え先で二重に実行せずに済む。

切り替え先のアカウントで文書を読ませる

別アカウントで起動したら、最初に引き継ぎ文書を指定する。たとえば、次のように依頼する。

docs/handoff.mdを読んで、このプロジェクトの作業を再開して。
まず現在のブランチ、git status、差分を文書の記載と照合する。
実行中の処理があれば状態を確認し、未完了の作業から続けて。

長い会話を全部再現しなくても、目的、判断の理由、現在の状態、次の作業がわかれば再開しやすい。文書がプロジェクト内にあれば、どのアカウントからでも同じ場所を読める。

不意に中断したら、元のアカウントのセッション履歴を探す

別の設定ディレクトリから該当セッションを検索させる

文書を残す前に接続が切れたり、ターミナルを閉じてしまったりすることもある。その場合は、元のアカウントの設定ディレクトリに会話履歴が残っていないかを探す。

自分の環境では、次のようにプロジェクトのパスに対応したディレクトリがある。

~/.claude-toyofukux/projects/
└── -Users-macmini-workspace-branding/
    ├── セッションID.jsonl
    └── ...

ディレクトリ名を決め打ちするより、まずファイル一覧からプロジェクト名で絞ると探しやすい。rgはripgrepのコマンドだ。

rg --files --hidden "$HOME/.claude-toyofukux/projects" \
  -g '*.jsonl' | rg -F -- 'branding'

これはファイルのパスを探す例なので、本文にしか手がかりがない場合は見つからない。候補が見つからなければ、プロジェクトの絶対パスや、直前の作業で使った固有の語句を履歴の中から検索する。

rg -l --hidden -F \
  -g '*.jsonl' \
  -- '/Users/macmini/workspace/branding' \
  "$HOME/.claude-toyofukux/projects"

-lを付けると、一致したファイル名だけを出せる。候補を絞ってから、必要な範囲の会話を読む。

自分で探す代わりに、切り替え先のClaude Codeへ次のように頼む方法もある。対象は、切り替え先のアカウントでも扱ってよいプロジェクトの履歴に絞る。

このプロジェクトは、前のアカウントで作業していた。
引き継ぎ文書を残す前に中断したので、次の場所から経緯を探して。


履歴の場所: ~/.claude-toyofukux/projects/
プロジェクト: /Users/macmini/workspace/branding
直前の作業: Claude Codeの複数アカウント運用の記事追加


対象プロジェクトのセッション候補を絞り、直近の会話を確認する。
目的・決定事項・未完了の作業を抽出し、現在のGit差分と照合する。
履歴だけで判断できない部分は、未確認として残して。

履歴を読ませれば元のセッションそのものに戻る、という話ではない。会話を資料として読み、別のセッションで作業に必要な文脈を組み立て直す方法だ。履歴が削除されている場合は使えないので、普段の引き継ぎは文書に残す運用を基本にする。

復元した経緯を実ファイルやGit差分と照合する

履歴に「修正する」と書いてあっても、実際の変更が完了しているとは限らない。逆に、文書を書き直す前にファイルだけ更新されていることもある。

git branch --show-current
git status --short
git diff
git diff --cached
git log -5 --oneline

未追跡ファイルはgit diffに出ないので、git statusで見つけたものは中身も確認する。公開やバッチ処理を再開するときは、会話だけで完了を判断せず、実際のデプロイや実行状態も調べる。

復元できた内容は、その場でプロジェクトの文書へ書き戻す。次回は同じ履歴をもう一度探さずに済む。

日々の運用で確認すること——アカウント・リンク切れ・引き継ぎ文書

日常的に確認するのは、次の三つだ。

  • 意図したアカウントで起動しているか。 aliasの名前だけで判断せず、設定時や切り替えに違和感があるときはauth status --textやセッション内の/statusを見る。APIキーなど別の認証設定がある場合は、認証の優先順位によって、そちらが使われることもある。
  • 共通ファイルのリンクが生きているか。 実体を移動したら、各アカウントのリンクも確認する。ls -ldでリンク先を見て、test -e "$HOME/.claude-toyofukux/skills"で参照先が存在するかを確認できる。
  • 今の作業状況が文書に残っているか。 完了した内容、未確認のこと、次の一手を更新する。アカウントを切り替える前だけでなく、作業の区切りで残す。

また、アカウントを分けても、同じ作業ディレクトリのファイルは共通だ。二つのセッションで同じファイルを同時に変更すると衝突するので、切り替え時には前の処理が動いていないかを確かめる。並行して別の変更を進めるなら、作業ディレクトリも分ける。

設定先とaliasを用意しておけば、起動時の切り替えは短いコマンドで済む。共通スキルは一か所で更新し、作業の経緯はプロジェクト内の文書から読めるようにしておくと、アカウントが変わっても再開しやすくなる。

Loading Tweet Button...
© 2024 Takashi Toyofuku All rights reserved.