claude-switch-models-setup について
Claude Code CLI のモデル別プロファイルを管理するスキルです。認証情報とセッション状態を分離しながら、共有設定や動作設定を同期できます。
主な機能
- 01プロファイルごとの認証情報と状態の分離
- 02スキル、プロジェクト、フック、プラグイン状態の共有
- 03設定と動作設定の同期
- 04プロバイダ設定ファイルによるモデル振り分け
活用シーン
- 01別々のターミナルで異なるモデルを利用
- 02プロファイル間でフックや権限を統一
- 03プロファイル間の設定差分を確認
MCP 対応
README は、事前読み込みされる MCP ツールスキーマによる起動時コンテキストの削減に触れていますが、このスキルが MCP サービスを提供するとは説明していません。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ daymade/ claude-code-skills --skill claude-switch-models-setupインストール後、Claude Code で/claude-switch-models-setupを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
assets/templates/anthropic.jsoncodex-active-skills.jsondeepseek.jsonglm.jsonkimi-highspeed.jsonkimi.jsonminimax-cn.jsonminimax-m2-7-cn.jsonminimax-m2-7.jsonminimax.jsonstepfun.jsonevals/trigger-evals.jsonreferences/context-window-config.mdcredential-storage.mdlocal-source-sync-architecture.mdmcp-startup-context.mdstudent-setup-guide.mdtroubleshooting.mdscripts/claude-plugins-sync.pyclaude-plugins-sync.test.pyclaude-profiles.shprune-source-sync-backups.pyseed-codex-active-skills.pysetup.shskill-install-audit.pysync-daemon-recorder.shsync-daemon-recorder.test.shsync-local-skill-sources-daemon.shsync-local-skill-sources.pysync-profile-settings.py詳細
翻訳後に原文が更新されています。最新の内容は原文をご確認ください。
Claude Code プロファイルとローカルスキルの有効化
概要
このスキルでは、Claude Code CLI 用の分離しつつ共有可能なプロファイルシステムを構築します。各プロファイルは専用の .claude.json 状態ファイル(プロバイダーの認証情報とセッション履歴)を持ちながら、スキル、プロジェクト、フックスクリプト、エージェント、インストール済みプラグインの状態をすべてのプロファイル間で共有します。また、各プロファイルの settings.json(フックの登録、マーケットプレイス、環境変数の機能フラグ、権限、設定)に加えて、デフォルトプロファイルの .claude.json の動作に関する部分(例:workflowSizeGuideline)も同期するため、プロファイル間で意図的に異なるのはモデル/プロバイダーだけです。
その結果、あるターミナルでは Kimi、別のターミナルでは DeepSeek、さらに別のターミナルでは Anthropic を、それぞれ設定が混在しない完全に独立した Claude Code プロセスとして実行できます。
仕組み
CLAUDE_CONFIG_DIRは、Claude Code CLI に対して設定ルートとして使用するディレクトリを指定します。- 各プロファイルは
~/.claude-profiles/<name>/に、分離された.claude.jsonとともに配置されます。 - コンテンツディレクトリ(
skills/、projects/、hooks/、agents/、settings/)はメインの~/.claude/ディレクトリにシンボリックリンクで戻されるため、コピーは 1 つだけ維持すれば済みます。これはフックのスクリプトを共有するものであり、フックの登録を共有するものではないことに注意してください。登録は各プロファイル自身のsettings.jsonにあります(次の箇条書きを参照)。 - 設定レイヤー —
settings.json: 各プロファイルは自身のsettings.jsonを持ちます(Claude Code はこれを設定ディレクトリローカルとして扱います)。そのため、そこに保存されているものすべて — フック登録、extraKnownMarketplaces、enabledPlugins、envの機能フラグ、permissions、動作設定 — は、デフォルトプロファイル側で変更された瞬間に黙ってずれていきます(2026-07-18 計測: 実在する 9/9 プロファイルでフック登録がゼロ)。sync-profile-settings.pyはその収束役です。SessionStart フックとして登録され、デフォルトプロファイルのsettings.jsonのすべてのキーをすべてのプロファイルのsettings.jsonにコピーします。ただし ID キー(トップレベルのmodelとadvisorModel— 後者は Anthropic モデルのルーティングであり、サードパーティのエンドポイントでは提供できません。およびプロバイダールーティングや Anthropic ネイティブの分離を担う環境変数 —ANTHROPIC_*、CLAUDE_CODE_SUBAGENT_MODEL、ENABLE_TOOL_SEARCH、DISABLE_GROWTHBOOK/TELEMETRY/AUTOUPDATER— これらはプロバイダー設定ファイルが意図的に異なる値を設定しています)は除外されます。env内では、非 ID キーについての収束は双方向です。メインのキーはプロファイルのものを上書きし、メインが持たなくなった非 ID キーはプロファイルから削除され、報告されます(ID キーは対象外です — メインはそれらを決して持たないため、その不在は削除の証拠にはなりません)。プロファイル固有のトップレベルキーは保持されます。メインも持つキー内のネストされたコレクション(例:permissions.allow、enabledPlugins)はメインの値へ丸ごと収束し、そのようにして失われたプロファイル固有のネストエントリは一覧表示されます(書き込み時に件数、詳細は--check時)— これにより損失が黙って起きるのではなく可視化されます。これが「モデル以外のすべてがすべてのプロファイルで動作する」を実際に成り立たせています。- 対象範囲は、あらゆる呼び出しにおいてすべてのプロファイルです。 引数なし、
--all、--checkのいずれの実行もサブセットを対象にすることはありません。毎回、~/.claude-profiles/*のすべてに加えて$CLAUDE_CONFIG_DIRが対象です。実行は実際に変更したプロファイルごとに 1 行を出力し、ずれがなければ何も出力しません — したがって、ずれは隠れることなくセッション開始時の出力に現れ、セッション開始時に何も出力されなければ収束済みであることを意味します。$CLAUDE_CONFIG_DIRが未設定、空、またはプロファイルディレクトリでない場合はスキップされ、決して作成されません。 - 終了コード: 引数なしの実行は無条件に終了コード 0 で終わります — これはセッション開始フックであり、メインファイルが破損している場合でもセッションを決してブロックしません(警告し、何も収束せず、終了コード 0 で終わります。破損したメインは空として読まれ、空に向けて収束するとすべてのプロファイルからフックが剥ぎ取られてしまうためです)。
--checkはずれがある場合に終了コード 1、メインファイルの破損または読み取れなかったプロファイルがある場合に終了コード 2 で終わります。--allは書き込みを行い、同じ 2 つの失敗で終了コード 2 を返します — 両者の違いは--checkが何も書き込まないことであり、どの失敗が 2 を返すかではありません。--check --allは--checkと同じ監査です。読み取れないプロファイルが 1 つあっても報告されてスキップされます — 他のプロファイルの収束を決してキャンセルしません。
- 対象範囲は、あらゆる呼び出しにおいてすべてのプロファイルです。 引数なし、
- 状態レイヤー —
.claude.jsonの動作キー:settings.jsonはプロファイルごとの唯一の設定ファイルではありません。Claude Code はプロファイルごとの状態ファイルも保持しており(メインプロファイルのものは~/.claude.json、サードパーティプロファイルのものは<profile>/.claude.json— 非対称なパスで、ディスク上で確認済み)、いくつかの動作設定はそこにのみ存在します(workflowSizeGuideline、通知/UI の設定)。2026-08-17 時点でworkflowSizeGuideline: smallはメインプロファイルにのみ存在し、11 個中 10 個のサードパーティプロファイルにはコピーがありませんでした — Kimi のセッションが 1 つの Dynamic Workflow を 30 以上のエージェントに展開し、そのシステムプロンプトにはサイズの指針がありませんでした。そのため同じ収束役は、動作キーの許可リストを各プロファイルの.claude.jsonにも同期します。安全機構は、手作業で維持するキー一覧ではなく、スクリプト内の三者分類器です。許可リストにある動作キーは同期されます。状態/キャッシュ/カウンター/マイグレーション/資格情報のキー(名前パターンで一致)は決して触れられません。未知で異なるものは報告されます — 人間が分類するまで、実行ごとにずれたキー 1 つにつき 1 行(次に現れる動作キーをその日のうちに浮かび上がらせるトリップワイヤーです)。書き込みはバックアップ + アトミック置換です。ファイルを書き換える動作中のハーネスに対して安全であることを計測済みです(マーカーキーがアクティブセッションの 30 分以上を生き延びました)。適用は次のセッションからです — ハーネスは起動時にこのファイルを読み取ります。 - 例外 —
plugins/: マーケットプレイスのコンテンツとインストール状態は共有されますが、各プロファイルは自身のknown_marketplaces.jsonを保持します。Claude はマーケットプレイスのinstallLocationをpath.resolve()で検証します(これはシンボリックリンクを解決しません)。そのため単一の共有ファイルでは、書き込みを行っていないすべてのプロファイルが「corrupted installLocation」を報告することになります。claude-plugins-sync.pyがこのプロファイルごとの構造を構築し、維持します。 claude-plugins-sync.pyはまた、デフォルトの~/.claude/settings.jsonから各プロファイルのsettings.jsonへenabledPluginsをミラーします(キャッシュファイルの共有だけでは不十分です。Claude Code は「有効」状態を設定ディレクトリローカルとして扱います)。これはプロファイル起動時とリアクティブに実行されます — 次の箇条書きの LaunchAgent が、デフォルトプロファイルのsettings.jsonへの書き込みのたびにこれを再実行するため、claude plugin enable/disable --scope userは通常、再起動なしで数秒以内にすべてのプロファイルへ伝播します(2026-08-22 検証済み)。このミラーはまず取り込みます: 一部のプロファイルの settings.json にのみ存在する enabledPlugins キー(claude plugin installが書き込む形)は、ミラーする前にデフォルトプロファイルへ書き戻されます — 値が一致するもののみです。プロファイル間の競合は、黙って上書きされるのではなく、継続的な警告の背後でプロファイルごとに留まります。上記の SessionStart 収束役は、設定全体の同期の一部として同じキーをカバーします。claude-plugins-sync.pyはプロファイルごとのknown_marketplaces.json構造のオーナーのままです。skill-install-audit.pyは、レジストリ / インストール済み / 有効 / Codex マニフェスト /~/.agents/skillsの各レイヤーを読み取り専用で突き合わせ、さらにデーモンの固定されたランタイムバージョン、およびそれがすべてを判定する基準としたチェックアウト自体が遅れていないかも確認します。prune-source-sync-backups.pyは、git が再現できる.source-sync-backups/バケットのみを削除します。どのリポジトリにも存在しないブロブを 1 つでも含むバケットは報告され、そのまま残されます。- ローカルソース同期は、承認されたソースに基づくルートを各ホストに対して整合させ続けます。 エントリを選択または修復する前に、 ホスト固有のアクティベーション契約をお読みください。 これがマニフェストのフィールド、マーケットプレイスの展開、Claude プラグイン/直接リンクの区別、 未解決名の処理、衝突安全性、レガシー互換性を担います。 ソース登録だけではアクティベーションポリシーは決まりません。リンクを手作業で作成したり、 サードパーティのインベントリを管理するためにマニフェストを転用したりしないでください。
- 同期スクリプトは共有のプロセス間ロックを使用します。これは、ユーザーが tmux や複数のターミナルから複数のプロバイダーウィンドウを一度に開くことが多いために必要です。同時起動は、すべてのプロファイルを起動できるようにしつつ、マーケットプレイス/キャッシュの書き換えを直列化しなければなりません。
- ローカルソースのアーキテクチャ全体については、これらのスクリプトを変更する前に
references/local-source-sync-architecture.mdをお読みください。 - 承認された独立した Fleet クローンでの Skill 作成には、 リースされた作成のオーナー手順を使用してください。
- プロバイダールーティングは
~/.claude/settings/<name>.jsonを介して行われ、そのウィンドウに対してANTHROPIC_MODEL、ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKENを設定します。このファイルは env ファイルではなく完全な settings ファイルであり、収束役が決して触れない唯一のレイヤーです —claude-profileはclaude --settings ~/.claude/settings/<name>.jsonで起動しますが、収束役が書き込むのは常に<profile>/settings.jsonだけです。したがって、プロファイルごとである必要があり、かつすべてのセッション開始を生き延びる必要があるものはここに置きます。プロファイル自身のsettings.jsonに置くと、次の収束で取り戻されてしまいます。これには、WebSearchやWebFetchを拒否するなど、プロファイルごとのpermissions.denyも含まれます。 - プロファイルごとの思考努力量もそのプロバイダーファイルに存在します。 デフォルトプロファイルは
~/.claude/settings.jsonのmodelSettingsを介して Anthropic モデルごとに努力量を設定します。異なる努力量を必要とするサードパーティプロファイルは、代わりに~/.claude/settings/<name>.jsonの env でCLAUDE_CODE_EFFORT_LEVEL(例:"max")を固定します。プロバイダーファイルはその固定を保持できる唯一のレイヤーです。プロファイル自身のsettings.jsonの env に置くと、収束役が次のセッション開始時にそれを削除します(デフォルトプロファイルが持たない非 ID env キーは削除が伝播されるためです)。デフォルトプロファイルの env に置くと、そこに適用されかつすべてのサードパーティプロファイルのsettings.jsonに収束します — これは通常誤りです。なぜなら、弱いサードパーティモデルは、デフォルトのフラッグシップがもはや必要としないまさにそのときに、強制最大努力量の恩恵を受けるからです(2026-10-06 にエンドツーエンドで検証済み:claude-profile経由で起動したセッションは、自身の環境から固定値を読み戻します)。 - 資格情報も同じファイルに乗っているため、プロファイルをスクリプト化するものは
--settingsも渡さなければなりません。CLAUDE_CONFIG_DIR=<profile> claude -p ...を単独で実行するとNot logged in · Please run /loginと応答します。トークンはプロバイダーファイルにあり、他には何もそれを読み込まないためです。メッセージはログインを名指ししますが、原因はフラグの欠落です。 - 収束役には単一プロファイルモードがありません。あらゆる呼び出しが
~/.claude-profiles/*のすべてに加えて$CLAUDE_CONFIG_DIRを対象とし、それを狭めるフラグはありません。1 つのプロファイルをオンデマンドで収束させるには、CLAUDE_PROFILES_ROOTをそれだけを保持するディレクトリに向けるか、--checkを実行してプロファイルごとの行を読んでください。デフォルトプロファイル自身のファイルがソースであり、決して書き込まれません。
⚠️ 合成 main に対して converger を絶対に実行しないでください
スコープはすべてのプロファイル — ~/.claude-profiles/* のすべてに加えて $CLAUDE_CONFIG_DIR — であり、信頼できる唯一の情報源は CLAUDE_MAIN_CONFIG_DIR です。CLAUDE_PROFILES_ROOT または $CLAUDE_CONFIG_DIR が依然として実際のプロファイルに到達している状態で、それを使い捨てディレクトリに向けると、実行はその実際のプロファイルを合成 main へと収束させます。その hooks オブジェクト全体が偽の main が保持する内容に置き換えられ、その env は偽の main のキーを獲得します。**そのプロファイルに登録されたすべてのガードが発火しなくなります。**出力には、同期したキーの中に hooks が確かに記載され、上書きによってプロファイル固有のエントリが削除された場合はその数が報告されます — しかし、ガードが発火しなくなったことはどこにも書かれていないため、converger が正常に動作しているように読めてしまいます。合成 main が安全なのは、プロファイルルートと $CLAUDE_CONFIG_DIR も合成かつ使い捨てである場合だけです。
手動で実行する前に、スコープの両方を確認してください:
echo "MAIN=$CLAUDE_MAIN_CONFIG_DIR ROOT=$CLAUDE_PROFILES_ROOT ACTIVE=$CLAUDE_CONFIG_DIR"
CLAUDE_PROFILES_ROOT が未設定であることは安全信号ではありません — 実際の ~/.claude-profiles がデフォルトになるため、すべての実際のプロファイルが収束します。CLAUDE_PROFILES_ROOT と $CLAUDE_CONFIG_DIR の両方が合成かつ使い捨てでない限り、中止してください。テストフィクスチャは、ライブの環境を継承するのではなく、クリーンなベースからサブプロセスの環境を構築しなければなりません — シェルプロファイルがこれらの変数を設定しており、スクリプト内の unset は子プロセスに確実には届きません:
env -u CLAUDE_CONFIG_DIR -u CLAUDE_MAIN_CONFIG_DIR -u CLAUDE_PROFILES_ROOT …
実行が何かを書き込んだかどうかは、目視ではなく機械的に判断してください。実行前にターゲットプロファイルの settings.json のサイズを記録し、実行後に比較します。.sync-backup は shutil.copy2 で書き込まれ、これはソースの mtime を保持するため、古いバックアップのタイムスタンプは何も書き込まれなかったことの証明にはなりません — サイズとバイト数を比較してください。
実際のプロファイルが書き込まれた場合は、そのプロファイル自身のバックアップから復元し、バイト単位で検証してください:
cp -p <profile>/settings.json.sync-backup <profile>/settings.json
サイズ、JSON の妥当性、トップレベルキーの数、hooks の長さ、予期しない env キー、および /bin/true のようなサンドボックスシグネチャを確認します。次に、他のプロファイルをスキャンします。スコープはそれらすべてであるため、1 回の実行で複数に影響を与える可能性があります。
ワンクリックセットアップワークフロー
ユーザーが「Claude Code プロファイルをセットアップして」または「Kimi と DeepSeek を別々のウィンドウで使いたい」のようなことを言った場合:
-
前提条件を確認する
claudeCLI がインストールされている:which claude- シェルが zsh または bash である:
$SHELLで検出 python3が利用可能である
-
プロファイルマネージャースクリプトをインストールする — コピーせず、シンボリックリンクを作成する
このリポジトリをチェックアウトしているマシン(メンテナーの場合)では、バンドルされたインストーラーを実行します:
<absolute-path-to-this-repo>/daymade-claude-code/claude-switch-models-setup/scripts/setup.shscripts/setup.shは正確なデプロイセットの唯一の情報源です。これは各ヘルパーを~/.config/claude-switch-models-setup/にリンクし、アクティベーションマニフェストがまだ存在しない場合にのみそれをシードします。ここで別のヘルパーリストを維持しないでください。chmodの手順は不要です。デプロイはシンボリックリンクによるものであり、ソースファイルはコミットされたモードを保持します。レコーダーファイルは、オプションのラッパーを有効にせずにデプロイされます。既存の通常のレコーダーコピーは、セットアップがそれらをリンクに置き換える前に比較および保存する必要があります。固定されたデプロイは「ピンを進める」手順に従います。
なぜ
cpではなくシンボリックリンクなのか: 実際に実行されるのは~/.config/…です — LaunchAgent とclaude-profileはそのパスでスクリプトを呼び出します — 一方、このリポジトリはそのソースを保持します。コピーはドリフトし、デプロイされたコピーはそのソースと見分けがつきません。リンクは、独立した編集とソースの更新が黙って分岐するのを防ぎます、それがリンクであり続ける限り — アトミック保存エディター、rsync、またはうっかりしたcpは、何も言わずにそれを実際のファイルに戻してしまいます。だからこそ、これは解決済みと宣言するのではなく、再確認する価値があるのです。また、sync-local-skill-sources.pyが推測にフォールバックするのではなく、自身のパスを解決して自身のソースリポジトリを特定できるようにします。どのように再確認する価値があるのでしょうか?定期的なチェックなら何でも機能します。このスキルにはバンドルされていません。そのようなものを保管している場所で実行する 1 行です:
for f in ~/.config/claude-switch-models-setup/*.py ~/.config/claude-switch-models-setup/*.sh; do [ -L "$f" ] && [ -e "$f" ] || echo "not a live link: $f" done実ファイルになっているものがある場合は、再リンクする前に別の場所へ移動してください。ほかには存在しない編集が含まれている可能性があり、これこそがここで説明している問題です。
mv "$f" "$f.local-edits" && ln -sf <source> "$f"を実行してから、差分を確認してください。リポジトリがないマシンでは、代わりにこのスキルのバンドルから、インストーラーに記載されているスクリプトをコピーしてください。ただし、再度コピーするまではリポジトリへの修正が反映されないことを了承してもらってください。
LaunchAgent が固定されたプラグインのコピーを実行しているマシン(メンテナー向けの構成についてはlocal-source-sync-architecture.mdを参照)では、これらのリンクはチェックアウトではなく、
.../plugins/cache/...配下にあるそのコピーのバージョンディレクトリを指します。また、固定バージョンを進めたときにのみ移動します(troubleshooting.mdの「advance the pin」を参照)。インストーラーは、このようなマシンをチェックアウトへ再リンクすることを拒否します(CSMS_SETUP_RELINK_TO_CHECKOUT=1で上書きできます)。再リンクすると、デーモンとclaude-profileがチェックアウト先のブランチに追従するためです。前述のライブリンクの確認は、どちらの構成にも適用されます。 -
シェル統合を追加する
- プロファイルマネージャーを
~/.zshrcまたは~/.bashrcで読み込む - エイリアス
csk、csd、csgを追加する - 必要に応じて、アカウント別・プラン別の追加エイリアスを手動で設定する。スクリプトのヘルプテキストには上記の基本例のみが記載されています。
cssplan/csspなどのバリエーションは自動生成されず、手動で追加します source ~/.zshrcを実行するか、新しいターミナルを開くようユーザーに伝える
- プロファイルマネージャーを
-
プロバイダー設定ファイルを生成する
- ユーザーが使用する各プロバイダーについて、
~/.claude/settings/<provider>.jsonを作成する assets/templates/のテンプレートをたたき台として使う- APIキーとベースURLをユーザーに確認する。デフォルト値をハードコードしないでください
- このプロバイダーに適したコンテキストウィンドウを設定する。[1m]サフィックスを使うか、
CLAUDE_CODE_MAX_CONTEXT_TOKENS/CLAUDE_CODE_AUTO_COMPACT_WINDOWを明示的に指定します。下記の「コンテキストウィンドウサイズの設定」を参照してください。新しいプロファイルごとに必ず明示的に設定してください。最も近いテンプレートに設定がないからといって、このプロファイルにも不要だとは限りません。 - 必須の分離フラグを含める:
CLAUDE_CODE_SUBAGENT_MODEL(ANTHROPIC_MODELと同じ値)ENABLE_TOOL_SEARCH: "false"DISABLE_GROWTHBOOK: "1"DISABLE_TELEMETRY: "1"DISABLE_AUTOUPDATER: "1"
- このプロバイダーのモデルが、デフォルトプロファイルとは異なる思考レベルを強制すると効果を発揮する場合は、任意で
CLAUDE_CODE_EFFORT_LEVEL(例:"max")を固定できます。この設定はプロバイダーファイルに記述してください。プロファイルのsettings.jsonのenvには記述しないでください。そこに記述すると、コンバージャーによって削除されます(「仕組み」の「プロファイルごとの思考レベル」を参照)。
- ユーザーが使用する各プロバイダーについて、
-
プロファイルディレクトリを初期化する
claude-profiles-initを実行する- これにより、分離された
.claude.jsonとシンボリックリンクを含む~/.claude-profiles/<provider>/が作成されます - メンテナーのマシンでは、プラグインのメタデータを同期する前に、ローカルソースのシンボリックリンクも修復されます
ステータスラインの設定:
claude-profiles-initは、~/.claude/settings.jsonまたは~/.claude/statusline.shからステータスラインスクリプトを自動検出し、新しい各プロファイルに設定します。どちらも存在しない場合、プロファイルは動作しますが、ステータスバーは表示されません。ユーザーにステータスラインが必要かどうかを判断し、適切であればstatusline-generatorスキルをインストールして、そのインストーラーを実行するのはAIの役割です。プロファイル設定スクリプトに依存関係のインストールをハードコードしないでください。 -
設定収束スクリプトを登録する
~/.claude/settings.jsonのhooks.SessionStartリストにあるデフォルトプロファイルのセッション開始フックとして、'/absolute/path/to/python3' '/absolute/path/to/sync-profile-settings.py'のような絶対パス指定の直接実行コマンドで収束スクリプトを追加します。.py ファイルをシバン経由やパッケージマネージャー経由で登録しないでください。このフックはすべてのプロファイルを修復するためのものであり、共有環境やキャッシュのロック待ちが発生してはなりません。引数なしで登録してください。引数なしの呼び出しはセッション開始モードであり、すべてのプロファイルを収束させ、セッションをブロックしません。フックコマンドに--allを追加しないでください。--allは手動実行用モードであり、破損したメインファイルや読み取れないプロファイルがあると終了コード 2 を返し、セッション開始をブロックします。- 初回の同期を実行します:
python3 ~/.config/claude-switch-models-setup/sync-profile-settings.py --all - 以降は、誰がセッションを開始しても、各セッションの開始時にすべてのプロファイルの
settings.jsonと.claude.jsonの動作に関する部分がデフォルトプロファイルと同期されます(変更は次のセッションから適用されます)。デフォルトプロファイル自身のファイルは SSOT であり、書き換えられることはありません。書き込みを行わずに監査するには、--check(または同じ監査を行う--check --all)を実行します。
-
分離状態を確認する
claude-profiles-doctorを実行します- 各プロファイルのディレクトリに
.claude.jsonがあり、有効なシンボリックリンクが設定されていることを確認します
-
Codex と Claude で使用するローカルソースのスキルを選択する
- 通常の学生や、スキルのソースリポジトリを編集しないユーザーは、この手順を省略してください
- ホスト固有の有効化に関する仕様を読み、要求されたホストに合わせてマシンの有効化マニフェストを編集します。互換性ルールは、レガシーパスを引き続き使用するコンシューマーにのみ適用してください。
python3 ~/.config/claude-switch-models-setup/sync-local-skill-sources.pyでプレビューし、影響を受けるすべてのパスを確認してから、python3 ~/.config/claude-switch-models-setup/sync-local-skill-sources.py --applyで適用します。- メンテナーの macOS マシンでは、
~/.config/claude-switch-models-setup/sync-local-skill-sources-daemon.sh --installを実行します - これは有効化マニフェスト、デフォルトの Claude インストール状態、ローカルのマーケットプレイスマニフェストを監視し、選択、インストール/アンインストール、プラグイン構成の変更後に派生状態を修復します
-
起動方法をユーザーに案内する
-
csk→ Kimi ウィンドウ -
csd→ DeepSeek ウィンドウ -
csg→ GLM ウィンドウ -
claude(エイリアスなし)→ デフォルトの Anthropic プロファイル -
任意:アカウントやプランごとのエイリアスは、自分で追加します —
claude-profiles.shがこれらを生成することはありません。実行例として StepFun があります。サブスクリプションプランは専用のプラン用ベース URL(https://api.stepfun.com/step_plan、単一モデル)でのみ応答します。一方、従量課金ではプロバイダーの標準エンドポイント、またはその前段にあるゲートウェイを使用します。同じプロバイダーでも課金方式は 2 種類あるため、2 つのエイリアスを持つ 2 つのプロファイルとして設定します(ベース URL は必ず正確なものを確認してください):alias cssplan='claude-profile step-plan --dangerously-skip-permissions' alias cssp='claude-profile step-pay --dangerously-skip-permissions'
-
コマンド
セットアップ後、ユーザーは次のコマンドを実行できます:
claude-profiles-init # Re-scan settings/*.json, create missing profiles;
# reports symlink drift (real dirs that should be symlinks).
# Add --repair to archive drift and replace with symlinks.
claude-profile <name> # Launch a specific profile
claude-profiles-ls # List profiles
claude-profiles-doctor # Check symlink health
claude-profile-rm <name> # Remove a profile's isolation directory
python3 ~/.config/claude-switch-models-setup/claude-plugins-sync.py
# Repair per-profile plugin structure and enabledPlugins
python3 ~/.config/claude-switch-models-setup/sync-profile-settings.py --all
# Converge every profile from the default profile:
# settings.json (hooks, marketplaces, env flags,
# permissions, preferences) + .claude.json behavior
# keys (workflowSizeGuideline etc.). Session start
# already does this for all profiles; run --all to
# apply a manual settings edit immediately.
# --check audits the same scope without writing
python3 ~/.config/claude-switch-models-setup/sync-local-skill-sources.py
# Maintainers: preview host selections and affected paths
python3 ~/.config/claude-switch-models-setup/sync-local-skill-sources.py --apply
# Apply the inspected Codex, Claude, and explicit
# legacy compatibility changes
~/.config/claude-switch-models-setup/sync-local-skill-sources-daemon.sh --install
# Maintainers: install automatic macOS watcher
これらは日常的に使うコマンドではありません。有効化された正規ソースへの変更は、シンボリックリンクを通じてすぐに反映されます。単発コマンドは、修復や初期セットアップ、または LaunchAgent の監視機能がない macOS 以外の環境で使用します。
プロバイダーテンプレート
assets/templates/ のプロバイダーテンプレートを使用してください。選択したファイルを読み、モデル、エンドポイント、コンテキスト設定、思考の動作を確認してください。これらの値を、手動で管理しているテンプレートの概要から推測しないでください。
すべてのテンプレートで <API_KEY> プレースホルダーを使用します。設定可能なゲートウェイ向けのテンプレートでは <BASE_URL> も使用します。MiniMax テンプレートでは、ドキュメントに記載されたリージョン別エンドポイントが指定されています。実際のプレースホルダー値はすべてユーザーに尋ねてください。ユーザーが明示的に提供しない限り、推測したり、現在のマシンにある値を再利用したりしないでください。
MiniMax-M3 は適応型または無効の思考をサポートします。ANTHROPIC_REASONING_MODEL は同じモデルに設定してください。MiniMax-M2.7 では思考が常に有効です。テンプレートレベルで無効にする方法があるとは説明しないでください。モデルとコンテキストの値は、選択したテンプレートから読み取ってください。
コンテキストウィンドウサイズの設定
すべてのプロバイダーテンプレートでは、次の2つの方法のいずれかでモデルのコンテキストウィンドウを設定します。これを間違えると、Claude Code はモデルが実際に保持できるコンテキスト量を把握できません。設定値が小さすぎると、プロバイダーが実際に必要とするよりはるかに早い段階でコンパクション(要約して古い詳細を削除する処理)が発生します。大きすぎると、実際の上限を超えてからでないとコンパクションが発生しません。
[1m] マーカーのクライアント側の仕組み全体、つまりモデルフィールドから何が削除され、anthropic-beta ヘッダーに何が追加されるのか、また [1m] がないからといってプロバイダーが大きなプロンプトを保持できないわけではない理由については、references/context-window-config.md に記載されています。コンテキストの数値がおかしいと感じたときに参照してください。テンプレートを作成する際に参照するものではありません。
判断基準
新しいプロバイダー用の settings/<name>.json を作成するときは、モデルの宣伝上の名称や、最も近いテンプレートの設定をそのままコピーするのではなく、プロバイダーの実際の検証済みコンテキストウィンドウに基づいて選択してください。
| プロバイダーの実際のコンテキストウィンドウ | 設定する値 | テンプレートの例 |
|---|---|---|
| 約1Mトークンであることが明示的に確認されている(モデルの階層や名称から推測したものではない) | すべての ANTHROPIC_MODEL / ANTHROPIC_DEFAULT_*_MODEL / CLAUDE_CODE_SUBAGENT_MODEL の値に [1m] サフィックスを付けます。必ず正確に4文字の [1m] を使用してください。Claude Code が照合するのはこの文字列であり、[1million] や [max] のような独自のマーカーではありません。 | kimi.json |
| 既知の、より小さいサイズ(例:200K) | 実際の数値を CLAUDE_CODE_MAX_CONTEXT_TOKENS および/または CLAUDE_CODE_AUTO_COMPACT_WINDOW に明示的に設定します。[1m] は付けません。 | kimi-highspeed.json |
| 不明、または未検証 | 推測したり、テンプレートに何らかの値が必要だからといって、別のプロバイダーの数値をコピーしたりしないでください。まずプロバイダー独自のドキュメントやコンソールを確認するようユーザーに依頼してください。未検証の [1m] や大きな CLAUDE_CODE_AUTO_COMPACT_WINDOW を設定すると、「コンパクションが早すぎる」という問題が「実際の上限を大幅に超えてからでないとコンパクションされない」という問題に変わります。リクエストが実際に失敗するまで表面化しないため、さらに悪い結果になります。 |
テンプレートにコンテキストマーカーと明示的な上限の両方がある場合は、優先順位が検証されていない限り、両方を維持してください。ここでモデルの概要を管理するのではなく、選択したテンプレートから実際の値を読み取ってください。
プロバイダーのモデルの識別や、環境変数が実際に送信されるリクエストを変更するかどうかを確認するには、references/context-window-config.md を参照してください。
重要: 正確なエンドポイントは、ユーザーがプロバイダーに直接接続するか、互換ゲートウェイ(例:OpenRouter)を経由するかによって異なります。必ず確認してください。
共有と分離
| データ | 場所 | 共有 |
|---|---|---|
| セッション履歴 | ~/.claude-profiles/<name>/.claude.json | プロファイルごとに分離 |
| 認証トークン/キャッシュ | ~/.claude-profiles/<name>/.claude.json | プロファイルごとに分離 |
| アカウント+MCP OAuth トークン | macOS Keychain、設定ディレクトリ名から付けられたエントリー | デフォルトでは分離。CLAUDE_SECURESTORAGE_CONFIG_DIR="" を設定すると、すべてのプロファイルで1つのエントリーを共有するため、一度認証したMCPサーバーがすべてのプロファイルで接続されます。詳しくは credential-storage.md を参照してください |
| スキル | ~/.claude/skills/ | シンボリックリンクで共有 |
| プラグインのコンテンツ | ~/.claude/plugins/marketplaces、cache、data、... | シンボリックリンクで共有 |
| プラグインのインストールレジストリ | ~/.claude/plugins/installed_plugins.json | シンボリックリンクで共有 |
| 有効なプラグインのマップ | ~/.claude/settings.json -> <profile>/settings.json | sync-profile-settings.py によって統合されます(claude-plugins-sync.py によってもミラーされます) |
| プラグインマーケットプレイスのインデックス | <profile>/plugins/known_marketplaces.json | プロファイルごと(installLocation は設定ディレクトリ固有であり、共有できません) |
| プロジェクト/メモリ | ~/.claude/projects/、~/.claude/memory/ | シンボリックリンクで共有 |
| フックスクリプト | ~/.claude/hooks/、~/.claude/commands/ | シンボリックリンクで共有(スクリプトのみ — 登録は共有されません) |
settings.json の設定:フック登録、マーケットプレイス、環境変数フラグ、権限、環境設定 | <profile>/settings.json | セッション開始時に sync-profile-settings.py がデフォルトプロファイルからすべてのプロファイルへ統合します(model などの識別キーや、プロバイダーのルーティング/分離に関する環境変数は同期されません) |
.claude.json の動作キー(workflowSizeGuideline、通知/UI の環境設定) | ~/.claude.json → <profile>/.claude.json | 同じスクリプトによって動作の許可リストが統合されます。状態/キャッシュ/カウンター/移行/認証情報のキー(projects、oauthAccount、userID など)は同期されません。変更された未知のキーは、人による分類のために報告されます |
MCP サーバーのレジストリ(mcpServers) | ~/.claude.json → <profile>/.claude.json | 和集合として統合されます。main のエントリーは伝播し、1つのプロファイルだけで定義されたサーバーは保持され、名前が重複する場合は main が優先されます。これは動作キーであり、認証情報ではありません。必要な OAuth トークンは Keychain に保存され、上の行の設定に従います。そのため、認証情報ストアを共有しない場合、レジストリエントリーごとにプロファイルで1回ずつ認証が必要です |
| プロバイダーの設定 | ~/.claude/settings/<name>.json | 共有元からプロファイルごとに読み込まれます |
トラブルシューティング
プロファイルディレクトリが存在するのに、claude-profiles-doctor が「孤立したプロファイル」と報告する
症状:claude-profiles-doctor が次のように報告します。
WARN: orphan profile — no settings/<name>.json; claude-profile <name> fails. Run: claude-profile-rm <name>。
原因:プロファイルの分離ディレクトリは ~/.claude-profiles/ に存在しますが、対応するプロバイダー設定ファイル ~/.claude/settings/<name>.json がありません。claude-profiles-init は settings/*.json だけをスキャンするため、孤立したプロファイルのシンボリックリンクは作成も維持もされず、claude-profile <name> は「Error: Settings file not found.」というエラーで起動に失敗します。プロファイルディレクトリには、プロファイルごとの有用なデータ(history.jsonl、プロバイダーの認証情報を含む .claude.json、settings.json、スキルのワークスペース)が残っている場合があります。
対処方法:
- プロファイルが不要な場合:
claude-profile-rm <name>を実行します — 予期しないファイルがないか最初に確認してから、分離ディレクトリを安全に削除します。 - プロファイルを復元する場合:
~/.claude/settings/<name>.jsonに設定ファイルを再作成し(assets/templates/のプロバイダーテンプレートを使用)、その後claude-profiles-initを実行します。
共有ディレクトリ(skills/projects/hooks/agents/...)がシンボリックリンクではなく、実ディレクトリとして表示される
症状:claude-profiles-doctor が次のように報告します。
<name> is a real directory (expected symlink to ~/.claude/<name>) — drift; run: claude-profiles-init --repair.
原因:シンボリックリンク収束の設計が導入される前にプロファイルが作成された(または手動で作成された)ため、共有コンテンツのディレクトリがシンボリックリンクではなく、プロファイルごとの実ディレクトリになっています。そのプロファイルのコピーは、メインの ~/.claude/ のコピーとは気付かないうちに異なる内容になっています。そのプロファイルの skills/projects/hooks/agents は、ほかのすべてのプロファイルのものと同じではありません。実ディレクトリはリンク切れではありませんが、claude-profiles-doctor のディレクトリ種別チェックでこの不整合を検出できます。
修正(元に戻せます — データはアーカイブされ、削除されることはありません):
claude-profiles-init --repair
不整合のある各ディレクトリについて、プロファイルディレクトリ内の <name>.pre-symlink-bak-<timestamp> に実ディレクトリをアーカイブしてから、本来あるべきシンボリックリンクを作成します。claude-profiles-doctor を再度実行して、問題が解消されたことを確認してください。アーカイブに必要なデータが入っていた場合も、すぐそこに残っているため、何も失われていません。
共有される内容について:修正後、そのディレクトリはメインの ~/.claude/<name> のコピーを参照するため、プロファイルからはデフォルトのプロファイルと同じ skills/projects などが見えるようになります。これこそが共有シンボリックリンク設計の目的です。分離しておく必要があるプロファイルごとの状態(.claude.json、settings.json の model/プロバイダー環境変数などの ID キー、plugins/known_marketplaces.json)は、これらのシンボリックリンクディレクトリには含まれないため、修正によって変更されることはありません。プロファイルに必要なセッション/履歴データが含まれていた場合は、破棄する前にアーカイブを確認してください。これらのデータは修正後、共有コピーを参照するようになります。
Marketplace に「corrupted installLocation」と表示される
症状:/plugin または claude plugin marketplace update で、
corrupted installLocation ... expected a path inside <config-dir>/plugins/marketplaces
と報告されます。
原因:known_marketplaces.json がプロファイル間で共有されている(または手動で編集された)状態になっています。Claude は path.resolve() を使って検証するため(シンボリックリンクは解決されません)、installLocation は config-dir ごとに異なる必要があります。そのため、共有コピーひとつで複数のプロファイルの要件を満たすことはできません。
修正:claude-plugins-sync.py は、各プロファイル固有のコピーと共有コンテンツのシンボリックリンクを再構築します。これは claude-profile の初期化/起動時に自動実行されます。手動で実行するには:
python3 ~/.config/claude-switch-models-setup/claude-plugins-sync.py
デフォルトの Claude にはスキルがあるのに、Kimi/GLM/DeepSeek には表示されない
症状:デフォルトの Anthropic プロファイルではスキルが表示されますが、サードパーティのプロファイルでは表示されません。
原因:Claude Code は enabledPlugins を各設定ディレクトリの settings.json に保存します。plugins/cache を共有するとファイルは利用可能になりますが、プラグインは有効になりません。
修正:
python3 ~/.config/claude-switch-models-setup/claude-plugins-sync.py
影響を受ける Claude Code ウィンドウを再起動してください。
ローカルのソース編集が Claude Code または Codex に反映されない
ソース変更とピン更新の手順をお読みください。ソースに紐付いた経路とピン留めされたランタイムコピー、インベントリレポートと同期の成功、そして新しいホストでの検出の違いについて説明しています。
ソース同期では、派生キャッシュのアーティファクトも管理します。
- バージョンエイリアスのシンボリックリンク。 各キャッシュリンクにはマーケットプレイスの現在のバージョン名が付けられます。同期処理では、同じソースを参照する兄弟リンクを削除します。実ディレクトリには触れません。Claude Code がそれらをインストールするため、アクティブなセッションが
.in_useを介して引き続き使用している可能性があるからです。 installed_plugins.jsonのバックアップ。 JSON に変更があった実行では、毎回バックアップが作成されます。スクリプト内のKEEP_JSON_BACKUPS定数で保持する数を制限します。ファイル名はYYYYMMDD-HHMMSSのタイムスタンプで終わるため、辞書順で時系列に並びます。
どちらも、--apply によって変更が加えられる前に、ドライランで確認できます。
プロファイルにフック、マーケットプレイス、環境変数フラグ、その他のデフォルトプロファイル設定が反映されない
症状:デフォルトプロファイルにはフックガード、マーケットプレイス、または機能フラグが設定されているのに、サードパーティプロファイルではそれらが存在しないかのように動作します(PreToolUse ガードが実行されない、claude plugin marketplace list の結果が空、デフォルトプロファイルで有効な機能がオフになっている)。
関連する別の症状、異なるレイヤー: デフォルトプロファイルに設定した動作上の設定(たとえば、ワークフローのサイズに関するガイドライン)が、サードパーティプロファイルに反映されません。このキーはプロファイルごとの .claude.json に保存されますが、シンボリックリンクと settings.json の同期ではどちらも反映されません。references/troubleshooting.md の「Default-profile behavior settings don't reach third-party profiles」を参照してください。
原因:これらの設定は各プロファイル固有の settings.json に保存されており、設定ディレクトリ内でのみ有効です。ディレクトリをシンボリックリンクしても設定レイヤーは対象にならず、デフォルトプロファイルを変更した時点でひそかに不整合が生じます。
解決方法:
python3 ~/.config/claude-switch-models-setup/sync-profile-settings.py --all
その後、該当するウィンドウを再起動してください。セットアップ手順 6 でコンバージャーが SessionStart フックとして登録されると、次のセッション開始時に、起動したプロファイルだけでなくすべてのプロファイルが同期されます。そのため、手動で変更した設定をすぐに反映する場合を除き、--all は不要です。
サードパーティプロファイルで Anthropic 固有の機能を使用しようとしている
症状:WebSearch やその他の Anthropic ネイティブツールで 400 エラーが発生します。
解決方法:プロファイルの settings.json に次の設定があることを確認してください。
{
"env": {
"ENABLE_TOOL_SEARCH": "false",
"DISABLE_GROWTHBOOK": "1",
"DISABLE_TELEMETRY": "1",
"DISABLE_AUTOUPDATER": "1"
}
}
サブエージェントの呼び出しで別のモデルにフォールバックする
症状:Kimi ウィンドウ内のサブエージェントが claude-opus-4-7 を呼び出します。
解決方法:プロファイルの settings.json で、CLAUDE_CODE_SUBAGENT_MODEL に ANTHROPIC_MODEL と同じ値を設定してください。
巨大なコンテキストを扱えるプロバイダーで、コンテキストの圧縮や要約が早すぎる。またはステータスラインのコンテキスト数が正しくない
症状:独自ドキュメントで約 1M トークンのコンテキストに対応すると謳うプロバイダーなのに、Claude Code がそれを大幅に下回る量で自動圧縮します。長時間のセッションが、まだ必要ないことが明らかなのに要約されたり、ステータスラインのコンテキスト割合が実際の上限ではなく約 200K のモデルを参照しているかのように変動したりします。
原因:プロファイルの ANTHROPIC_MODEL(および ANTHROPIC_DEFAULT_*_MODEL と CLAUDE_CODE_SUBAGENT_MODEL の関連設定)に [1m] マーカーがありません。プロバイダーの実際のコンテキストサイズを Claude Code に知らせる方法はほかにありません。大きなプロンプトを使ったリクエストが成功しても、それだけでは Claude Code に何も伝わりません。これはクライアントではなく、上流プロバイダーの特性だからです。仕組みの詳細は references/context-window-config.md を参照してください。
解決方法:プロファイルの settings.json で、ANTHROPIC_MODEL、すべての ANTHROPIC_DEFAULT_*_MODEL、および CLAUDE_CODE_SUBAGENT_MODEL に、文字列どおりの [1m] サフィックスを追加してください(kimi.json のパターンに合わせます)。該当するウィンドウを再起動してください。
後から新しいプロバイダーを追加する
- テンプレートを使用して、
~/.claude/settings/<new-provider>.jsonを作成します。 - プロバイダーで実際に確認されたコンテキストウィンドウを調べ、設定してください。[1m] マーカー、または明示的な
CLAUDE_CODE_MAX_CONTEXT_TOKENS/CLAUDE_CODE_AUTO_COMPACT_WINDOWを使います。下記の「Configuring Context Window Size」とreferences/context-window-config.mdを参照してください。コピー元のテンプレートで不要だったからといって、この手順を省略しないでください。 claude-profiles-initを実行します。- 必要に応じて、シェルの rc ファイルにエイリアスを追加します。
プロファイルの監査と廃止
プロファイルは増え続けます。ある実験のために追加したバリアントが、そのまま残り続けます。削除する前に、実際の使用状況を監査してください。信頼性の高い順に、次の3つの指標があります。
- プロンプト履歴(
~/.claude-profiles/<name>/history.jsonl)— 最も信頼性の高い指標です。エントリ数を数え、最初と最後のtimestampの値を確認してください。history.jsonlがまったくないプロファイルは、一度も入力されていません。 - シェル履歴の起動記録 — たとえば、
atuin search --search-mode prefix "<alias> "を使うと、各起動エイリアスが実際に何回使われたかを数えられます。 .claude.jsonの mtime は使用状況の指標にはなりません — 設定のコンバージャーと動作キーの同期処理は、セッションの開始時にこのファイルを書き換えるため、すべてのプロファイルが最近アクティブになったように見えます(2026-10-06 に確認:未使用のプロファイル群で、同期の実行による同じ新しい mtime が記録されていました)。
廃止するときは、完全に削除せず、必ずアーカイブしてください。
- プロファイルディレクトリと
~/.claude/settings/<name>.jsonのプロバイダーファイルを、~/.claude-profiles/の外側にあるアーカイブ先へ移動します。そのルートを--delete付きでミラーする dotfiles バックアップを維持している場合、そうしないと次回の実行時にアーカイブしたプロファイルのバックアップコピーが消去されます。ミラールートの外側にアーカイブすれば、コピーは保持されます。 - あるプロファイルが別のプロファイルの役割を引き継ぐ場合(同じプロバイダーで新しい名前を使う場合)は、役割に対応するプロンプト履歴が引き継がれるよう、古いプロファイルの
history.jsonlを先に後継プロファイルのディレクトリへ移動します。 - 孤立したプロファイル(ディレクトリは存在するが、
settings/<name>.jsonがないもの)については、トラブルシューティングで説明しています。再び有効にする場合も削除する場合も、同じ監査を行ってください。
プロバイダーファイルに新しい env 固定値を追加した場合、ウィンドウを開かずに、ヘッドレスで実際のセッションに反映されることを確認します。
CLAUDE_CONFIG_DIR=~/.claude-profiles/<name> claude --settings ~/.claude/settings/<name>.json \
-p 'run printenv <VAR_NAME> via Bash and reply with only its value'
起動したセッションの Bash は設定の env を継承するため、出力された値によって、設定ディレクトリ、プロバイダーファイル、env の適用という起動経路全体を確認できます。これは、「仕組み」の項で説明した CLAUDE_CODE_EFFORT_LEVEL の固定値を読み戻す方法です。
セキュリティに関する注意事項
- API キーは、Claude Code が
ANTHROPIC_AUTH_TOKENを保存するのと同じ方法で、~/.claude/settings/<provider>.jsonにプレーンテキストで書き込まれます。これは Claude Code 独自のセキュリティモデルに準拠しています。 - このスキルがキーや設定を外部へアップロードすることはありません。
- 公開配布用の同梱スクリプトには、ハードコードされたシークレット、エンドポイント、ユーザー固有のパスは含まれていません。
次のステップ
セットアップ後、ユーザーは2つのターミナルを開き、一方で csk(Kimi K3)、もう一方で csd を実行して、すぐにテストできます。各ウィンドウは独立しています。
セットアップの対象者が、自分で操作するワークショップ参加者であり、あなたが操作を代行する相手ではない場合は、このファイルに沿って案内する代わりに、references/student-setup-guide.md を渡してください。このガイドは、まだ必要のないメンテナンスやトラブルシューティングの内容を省き、最初から最後まで対象者自身が進められるように書かれています。