【2026年最新】Claude Codeモデル切替フック実装ガイド

モデル切替を統制するときの判断軸は、モデル名そのものではなく「誰が、どの経路で、どの状態から何へ切り替えたか」です。ここを曖昧にしたまま「Opusは禁止」「高いモデルは確認」とだけ決めると、対話セッションでは動いても、SDK、Remote Control、自動フォールバック、再開セッションで挙動が分かれます。

Anthropic公式のClaude Code changelogでは、v2.1.251にPreModelSwitchとPostModelSwitchが追加されたと説明されています。2026年8月29日にnpmの公式パッケージメタデータを確認した時点でも、@anthropic-ai/claude-codeのlatestは2.1.251でした。本稿はこの時点の公式仕様を基準にしています。機能は更新されるため、実装前に必ず公式ドキュメントとchangelogを再確認してください。

事例区分：実装パターン解説。この記事は特定企業の定量成果を示す実在事例ではありません。公式入力スキーマに沿ったリファレンス実装と、チーム導入時の設計判断を解説します。

2つのモデル切替フックが埋める運用上の空白

従来の設定は「開始時のモデル」を決めるのが中心だった

Claude Codeには、model設定、/modelコマンド、モデルピッカー、opusplan、自動フォールバックなど、モデルを選ぶ複数の仕組みがあります。ところが、チーム運用で必要なのは初期値だけではありません。セッション途中の切替を許可する条件、切替直後に渡す注意事項、変更履歴の記録まで含めた制御が必要です。

たとえば、プロジェクト設定で推奨モデルを決めても、利用者が/modelで別モデルへ移ることはあります。Agent SDKホストがset_modelを送る場合もあります。さらに、自動フォールバックやセッション再開では、利用者の明示操作がなくてもセッションのモデルが変わります。開始時設定だけでは、これらを同じ境界で扱えません。

モデルの既定値と組織設定の設計は、既存のClaude Code全社ガバナンス｜利用モデルとスキル統制で整理しています。本稿では、そのポリシーを「切替イベント」に接続します。

PreModelSwitchは「要求された変更」の前に動く

PreModelSwitchは、利用者またはクライアントが要求したモデル切替の前に実行されます。公式ドキュメントが列挙する対象は、/model、モデルピッカー、/configのModel設定、モデル変更を伴うfast mode、Agent SDKやRemote Controlからのset_modelなどです。

一方、Claude Code自身が行う自動フォールバックや、セッション再開時の復元には実行されません。つまり、PreModelSwitchは「すべてのモデル変更を事前に止める万能ゲート」ではありません。この境界を誤解すると、監査ログに穴ができます。

PostModelSwitchは「実際に変わった後」を観測する

PostModelSwitchは、要求された変更に加え、自動フォールバック、opusplanのplan mode出入り、セッション再開時のモデル復元でも動きます。切替後なのでブロックはできませんが、次のモデルリクエストへモデル別の指示を追加できます。

ただし、フォールバックチェーンの別モデルが1ターンだけ応答し、セッションのモデル自体が変わらない場合は発火しません。ここも重要です。すべての「実際に応答したモデル」を監査したいなら、モデル切替フックだけで完結させず、APIゲートウェイやOpenTelemetryのログと組み合わせます。自動フォールバックの設計は、fallbackModel設定でAPI障害に備える実装も参照してください。

入力スキーマを先に固定する

判定に使う9項目を役割別に分ける

公式仕様では、共通フィールドに加えて次の項目がモデル切替フックへ渡されます。運用設計では、これらを3群に分けると実装しやすくなります。

役割	主なフィールド	用途
切替対象	from_model、to_model、requested_model	現在値、解決後のモデルID、利用者が指定したaliasを区別する
要求経路	source	command、picker、sdk、auto、resumeを区別する
キャッシュ影響	context_tokens、prompt_cache_warm、cache_ttl、estimated_cache_write_usd、pricing	切替時の再送量と推定キャッシュ書き込み費用を表示・記録する

requested_modelとto_modelは同じではありません。利用者がopusというaliasを指定しても、matcherは解決後のcanonical nameと比較されます。LLM gatewayだけが知る独自モデルIDではcanonical nameを決められず、すべてのPreModelSwitch hookが走る場合があります。したがって、遮断処理はmatcherだけに依存せず、stdinのto_modelをスクリプト内でも検査してください。

キャッシュ費用は「推定値」として扱う

estimated_cache_write_usdは、次のモデルに会話コンテキストを書き込む推定費用です。公式ドキュメントは、サーバーが全コンテキストを再キャッシュしない場合もあるため、推定値として扱うよう明記しています。ここから請求額を断定してはいけません。

画面に出す文言は「切替費用は1.2ドルです」ではなく、「次のモデルへのキャッシュ書き込み推定は約1.2ドルです。実際の処理・請求と一致しない場合があります」のようにします。閾値も固定の正解ではありません。組織の料金契約、gatewayの設定、セッション長、開発者の役割で決めます。

Claude Codeの支出可視化を全社設計へ広げる場合は、Claude Code全社導入のコスト可視化・上限設計ガイドと合わせると、イベント単位と組織単位の責務を分けやすくなります。

sourceは認可ではなく補助情報として使う

sourceは要求経路を示しますが、利用者の本人性や職務権限を証明するフィールドではありません。「pickerなら人間だから許可」「sdkなら危険だから拒否」と単純化するのは避けます。最終的な認可は、managed settings、ID基盤、gatewayポリシー、リポジトリ権限と組み合わせてください。

ただし、対話確認の可否を決める材料にはなります。公式仕様では、askの確認画面を表示できるのは対話セッションの/modelだけです。非対話-p、/config、set_modelではaskが拒否として扱われます。本番ポリシーでは、この違いをテストケースに入れます。

最小構成を4ファイルで実装する

ディレクトリ構成と責務を分ける

最初から1本の巨大なシェルへ詰め込まず、設定、事前判定、事後ガイダンス、テストを分離します。次の構成なら、レビュー対象と実行対象が明確です。

.claude/
├── settings.json
└── hooks/
    ├── pre-model-switch.sh
    └── post-model-switch.sh
tests/
└── model-switch-hooks.sh

.claude/settings.jsonは共有設定に置く前提です。組織全体で強制する必要がある項目はmanaged settingsへ移し、プロジェクト側で上書きできないようにします。個人の~/.claude/settings.jsonだけに置くと、各端末で差分が生まれます。

settings.jsonで2イベントを登録する

以下は、すべての切替先をスクリプト内で判定する最小設定です。matcherを.*にし、canonical nameが不明なケースもstdinのto_modelで処理します。

{
  "hooks": {
    "PreModelSwitch": [
      {
        "matcher": ".*",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/pre-model-switch.sh",
            "timeout": 10
          }
        ]
      }
    ],
    "PostModelSwitch": [
      {
        "matcher": ".*",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/post-model-switch.sh",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

PreModelSwitchの公式既定timeoutは30秒ですが、社内スクリプトは外部APIを呼ばず、ローカルのポリシーファイルだけで高速に判定する方が安全です。公式仕様では、このフックがtimeoutすると切替はブロックされます。これはPreToolUseのtimeout時挙動と異なるため、運用監視では区別してください。

事前フックで禁止モデルをdenyする

次のシェルはstdinからJSONを読み、解決後のto_modelを検査します。例示した禁止リストはサンプルです。実際のモデル名や許可方針は、公式のmodel configurationと所属組織の契約を確認して変更してください。

#!/usr/bin/env bash
set -euo pipefail

input="$(cat)"
to_model="$(jq -r '.to_model // ""' <<<"$input")"
source_name="$(jq -r '.source // "unknown"' <<<"$input")"
cache_warm="$(jq -r '.prompt_cache_warm // false' <<<"$input")"
estimated_cost="$(jq -r '.estimated_cache_write_usd // 0' <<<"$input")"

case "$to_model" in
  *opus-4-6*)
    jq -n \
      --arg reason "このプロジェクトでは対象モデルを許可していません。管理済みモデルを選択してください。" \
      '{hookSpecificOutput:{hookEventName:"PreModelSwitch",permissionDecision:"deny",permissionDecisionReason:$reason}}'
    exit 0
    ;;
esac

if [[ "$cache_warm" == "true" ]] && awk "BEGIN {exit !($estimated_cost >= 1.0)}"; then
  jq -n \
    --arg msg "モデル切替により、プロンプトキャッシュ再書き込みの推定費用が発生する可能性があります。値は推定であり請求額ではありません。" \
    '{systemMessage:$msg,hookSpecificOutput:{hookEventName:"PreModelSwitch",permissionDecision:"allow"}}'
  exit 0
fi

jq -n '{hookSpecificOutput:{hookEventName:"PreModelSwitch",permissionDecision:"allow"}}'

この例は高い推定値でも自動拒否せず、注意を表示して許可します。理由は、キャッシュ費用が推定であり、正当な長文セッションの切替を一律に止めると開発を阻害するためです。厳格な上限が必要なら、金額だけでなく、リポジトリ、環境、利用者ロール、sourceを組み合わせたポリシーにします。

事後フックで次のモデルへガイダンスを渡す

PostModelSwitchは切替を取り消せません。その代わり、次のリクエストへadditionalContextを渡せます。ここには秘密情報や長大な手順を入れず、モデルに依存する短い運用ルールだけを入れます。

#!/usr/bin/env bash
set -euo pipefail

input="$(cat)"
to_model="$(jq -r '.to_model // ""' <<<"$input")"
source_name="$(jq -r '.source // "unknown"' <<<"$input")"

case "$to_model" in
  *haiku*)
    guidance="このモデルでは、仕様変更や破壊的操作を提案する前に、影響範囲と未確認事項を列挙してください。"
    ;;
  *opus*)
    guidance="このモデルでも、リポジトリのテストとレビューを省略しないでください。モデル切替元はフック入力に記録されています。"
    ;;
  *)
    guidance="モデル切替後です。既存のCLAUDE.md、権限設定、テスト要件を引き続き守ってください。"
    ;;
esac

jq -n \
  --arg text "$guidance" \
  '{hookSpecificOutput:{hookEventName:"PostModelSwitch",additionalContext:$text}}'

公式仕様では、次のprompt送信から5秒以内にフックが終わらなければ、その出力は次々回へ回る場合があります。事後フックでネットワーク照会や重い処理を行うと、意図したターンにガイダンスが入らない可能性があります。ローカル判定と短い出力に絞るのが実務的です。

allow・deny・askを運用面で選ぶ

allowは「無条件許可」ではなく確認を省く決定

allowは切替を進め、キャッシュがwarmな場合にClaude Codeが出す確認を省略します。したがって、単に「問題がなければallow」と返す実装でも、標準UIの確認を消す副作用があります。キャッシュ影響を利用者に見せたいなら、何も決定を返さず通常フローへ委ねる、またはsystemMessageだけ返す設計も比較してください。

本番でallowを使うなら、ポリシー評価済みであること、推定費用をどこで表示するか、ログに何を残すかをセットで決めます。

denyは理由を利用者が修正できる形で返す

denyのpermissionDecisionReasonは、対話画面やset_modelのエラーとして返ります。「禁止です」だけでは復旧できません。許可モデルのalias、申請先、例外条件、設定ファイルの場所など、次の一手を含めます。

{
  "hookSpecificOutput": {
    "hookEventName": "PreModelSwitch",
    "permissionDecision": "deny",
    "permissionDecisionReason": "このリポジトリでは当該モデルを許可していません。/model sonnet を選ぶか、managed settingsの変更手続きを確認してください。"
  }
}

複数のPreModelSwitch hookが異なる判断を返した場合、公式仕様の優先順位はdeny > ask > allowです。コストhookがallowし、セキュリティhookがdenyした場合はdenyになります。この優先順位を前提に、責務別のhookを分離できます。

askは対話面を限定して使う

askは、対話セッションの/modelでのみ確認画面を出せます。それ以外の面では拒否として扱われます。CI、SDK、Remote Controlで同じ設定を共有するなら、「確認待ちになる」と期待してはいけません。

対話専用のプロジェクトで、長いセッションの切替を人に再確認させる場合は有効です。たとえば、context_tokensと推定キャッシュ書き込み費用を理由文へ入れられます。ただし、値は推定であることを明記し、機密情報をreasonへ含めません。

{
  "hookSpecificOutput": {
    "hookEventName": "PreModelSwitch",
    "permissionDecision": "ask",
    "permissionDecisionReason": "現在の会話コンテキストを新しいモデルへ再送します。推定キャッシュ影響を確認して続行しますか？"
  }
}

単体テストで境界条件を固定する

Claude Code本体を起動する前にstdin/stdoutを検証する

command hookはstdinでJSONを受け、stdoutのJSONと終了コードで判断されます。まずスクリプト単体で入出力を固定すれば、設定ファイルの問題と判定ロジックの問題を分離できます。

#!/usr/bin/env bash
set -euo pipefail

HOOK=".claude/hooks/pre-model-switch.sh"

run_case() {
  local name="$1"
  local payload="$2"
  local expected="$3"
  actual="$(printf '%s' "$payload" | "$HOOK" | jq -r '.hookSpecificOutput.permissionDecision')"
  if [[ "$actual" != "$expected" ]]; then
    echo "FAIL: $name expected=$expected actual=$actual" >&2
    exit 1
  fi
  echo "PASS: $name"
}

run_case \
  "retired model is denied" \
  '{"to_model":"claude-opus-4-6","source":"command","prompt_cache_warm":false,"estimated_cache_write_usd":0}' \
  "deny"

run_case \
  "approved model is allowed" \
  '{"to_model":"claude-sonnet-5","source":"picker","prompt_cache_warm":false,"estimated_cache_write_usd":0}' \
  "allow"

ここでは実在の請求値やベンチマークを使わず、ポリシー分岐のダミー入力だけをテストします。金額閾値をテストするときも、テストデータであることを明示してください。

最低8ケースをテーブル化する

ケース	入力の焦点	期待結果
許可モデル	既知のto_model	allowまたは通常フロー
禁止モデル	禁止リストに一致	denyと復旧理由
独自gatewayモデル	未知のcanonical name	matcher任せにせず再検査
対話切替	source=commandまたはpicker	設計に応じた確認
SDK切替	source=sdk	askを確認待ちと誤解しない
warm cache	prompt_cache_warm=true	推定値の注意表示
自動フォールバック	source=auto	Postのみを想定
セッション再開	source=resume	Postでガイダンス再注入

さらに、JSON欠損、null、巨大な文字列、フックtimeout、jq不在も試します。セキュリティ制御は成功系より失敗系で差が出ます。

実機確認は4つの操作面を分ける

1. 対話/model：deny理由とask確認が表示されるか。
2. モデルピッカー：canonical nameのmatcherが期待通りか。
3. Agent SDKまたはRemote Control：askが拒否になる仕様をクライアント側で処理できるか。
4. 再開・自動切替：PostModelSwitchのsource=resumeまたはautoをログで識別できるか。

なお、この記事のシェル例はローカルのstdin/stdoutテストを前提にしています。実際のClaude Code接続、組織契約、gateway、モデルaliasは環境ごとに異なるため、ステージング環境で公式仕様と照合してください。

監査ログは最小化して別系統へ送る

保存するのは判断に必要なメタデータだけ

モデル切替ログに会話本文やプロンプト全文を入れる必要はありません。セッションIDも組織の規程に従って取り扱い、保存期間と閲覧権限を決めます。最小セットの例は、時刻、イベント名、from/to、requested model、source、decision、pricing種別、推定値です。

{
  "timestamp": "RFC3339 timestamp",
  "event": "PreModelSwitch",
  "from_model": "canonical model id",
  "to_model": "canonical model id",
  "requested_model": "alias or full id",
  "source": "command|picker|sdk|auto|resume",
  "decision": "allow|deny|ask|observed",
  "pricing": "configured|catalog|default",
  "estimated_cache_write_usd": "estimate"
}

推定費用を保存する場合は、実請求として集計しません。実際の利用量・支出は、組織のusage、gateway、OpenTelemetryなど正本となるデータソースで確認します。

PostModelSwitchをブロック用途に使わない

切替後に「禁止モデルだった」と判定しても、PostModelSwitchは変更を取り消せません。ここでプロセスを強制終了する設計は、編集途中の状態やバックグラウンド処理へ別の障害を作り得ます。Postは、監査、通知、追加コンテキストに限定し、事前に止められる経路はPreまたは上位のgatewayポリシーで止めます。

Hooks全体の基本、設定場所、整形・通知の例は、Claude Code Hooks実践ガイドで確認できます。推論時のDLPと組み合わせる場合は、Claude Code推論フック実装ガイド｜DLP対応を参照してください。

秘密情報をログ・systemMessage・reasonへ入れない

フック入力にはtranscript pathやcwdなどの共通情報も含まれます。それらを丸ごと外部ログへ転送すると、プロジェクト名、ユーザー名、ディレクトリ構成が漏れる可能性があります。許可リスト方式で必要項目だけ抽出し、認証情報、環境変数、会話本文、コード断片を記録しない設計にします。

HTTP hookやMCP tool hookを使う場合も同じです。送信先の認証、TLS、再試行、timeout、障害時の既定動作を設計し、外部サービスが落ちたときに全開発者のモデル切替が止まる影響を評価します。

Claude Codeにレビューさせる5つの入力例

1. ポリシーの矛盾を列挙する

このリポジトリの .claude/settings.json と model switch hook を読んでください。
PreModelSwitch と PostModelSwitch の責務が重複している箇所、
対話・SDK・自動フォールバックで挙動が矛盾する箇所を表にしてください。
不足している情報があれば、最初に質問してから作業を開始してください。

2. 入力スキーマの欠損耐性を確認する

pre-model-switch.sh が、to_model、source、estimated_cache_write_usd の
欠損・null・型違いを安全に処理できるかレビューしてください。
仮定した点は必ず「仮定」と明記し、修正案にはテストケースを添えてください。

3. askの非対話挙動をテストへ追加する

PreModelSwitch の permissionDecision="ask" は、対話 /model 以外では
拒否として扱われるという前提で、テスト計画を作ってください。
command、picker、sdk、auto、resumeを混同しないでください。
公式仕様で確認できない点は断定せず、確認URLを示してください。

4. ログ最小化をレビューする

model switch監査ログのJSONスキーマをレビューしてください。
会話本文、コード、認証情報、個人情報を保存せずに、
変更経路・判断・復旧に必要な最小フィールドだけ残してください。
数字と固有名詞には根拠または「設定例」のラベルを付けてください。

5. ロールバック手順を生成する

このmodel switch hookを段階導入するため、
observe-only → warn → deny の3段階とロールバック手順を作ってください。
各段階での成功条件、失敗条件、監視項目を分けてください。
不足している情報があれば、最初に質問してから作業を開始してください。

これらはコード生成を丸投げするためではなく、設定とテストのレビュー観点を増やすための入力例です。生成された修正は人が差分を確認し、ステージングで実行してください。

ロールアウトはobserve-onlyから始める

段階1：判断せず観測する

最初は切替を止めず、from_model、to_model、source、キャッシュ状態だけをローカルまたは承認済み監査基盤へ記録します。どの経路が実際に使われているかを把握しないままdenyを入れると、SDKや再開セッションが想定外に止まります。

段階2：systemMessageで注意する

次に、禁止候補や高い推定キャッシュ影響を検出したとき、ブロックせず注意を表示します。表示内容が多すぎないか、開発者が復旧方法を理解できるか、推定値を実請求と誤解しないかを確認します。

段階3：限定条件だけdenyする

最後に、廃止済みモデル、契約外モデル、規程で禁止されたgateway経路など、客観的に判定できる条件だけdenyへ移します。例外申請が必要なら、そのフローをreasonに含めます。複雑な業務判断を1本のシェルへ埋め込まず、ポリシー正本を別ファイルで管理します。

ロールバックは設定削除だけで終わらせない

障害時は、hook登録を外す、observe-onlyへ戻す、直前バージョンへ戻す、関連ログを保全する、影響セッションを確認する、という順序を用意します。PreModelSwitchはtimeoutで切替をブロックするため、スクリプト不具合が開発者全体へ広がる可能性があります。設定変更の配布方法と戻し方を同じリポジトリで管理してください。

よくある失敗と修正方法

失敗1：matcherだけで禁止判定する

❌ matcherが一致しなければ安全だと考える。

⭕ 公式仕様どおり、canonical nameを決められないモデルでは全hookが走る可能性を考慮し、stdinのto_modelを再検査します。gateway独自IDを使う環境では特に重要です。

失敗2：askをCIの承認待ちに使う

❌ 非対話実行でも確認プロンプトが出ると考える。

⭕ 対話/model以外ではaskが拒否として扱われる仕様を前提にします。CIやSDKでは、allow/denyを明示し、必要な承認は外部ワークフローで完了させます。

失敗3：PostModelSwitchで切替を止めようとする

❌ 切替後hookでプロセスを終了し、禁止モデル利用を防ごうとする。

⭕ Postは追加コンテキストと観測に限定します。要求された切替はPre、Claude Code自身の自動変更はgateway・契約・上位監視も含めて制御します。

失敗4：推定キャッシュ費用を請求額として報告する

❌ estimated_cache_write_usdを月次請求へそのまま加算する。

⭕ 公式説明どおり推定値として表示し、実利用量はusageやgatewayなどの正本で照合します。pricingがconfigured、catalog、defaultのどれかも一緒に記録します。

失敗5：フック入力を丸ごと外部送信する

❌ デバッグのためstdin全体とtranscript pathを外部ログへ保存する。

⭕ 許可したフィールドだけを新しいJSONへ詰め直します。所属組織の規程・コンプライアンス・保存期間に従い、秘密情報や個人情報を含めません。

FAQ

PreModelSwitchは自動フォールバックも止められますか？

止められません。公式仕様では、Claude Code自身が行う自動フォールバックやセッション再開時の復元にPreModelSwitchは実行されません。これらはPostModelSwitchで観測し、必要に応じてgatewayや組織設定と組み合わせてください。

permissionDecisionのaskはどこでも確認画面を出しますか？

いいえ。公式仕様では、対話セッションの/modelだけがaskの確認を表示できます。非対話-p、/config、SDKのset_modelなどでは拒否として扱われます。

PostModelSwitchのadditionalContextはいつClaudeへ届きますか？

切替後の次のモデルリクエストへ渡されます。ただし、次のpromptから5秒以内にhookが完了しない場合、出力が次々回へ回る可能性があります。短時間で終わるローカル処理にしてください。

推定キャッシュ書き込み費用を上限管理に使えますか？

注意喚起や参考判断には使えますが、実請求額として断定できません。公式ドキュメントも推定値として扱うよう説明しています。実支出は組織のusage、gateway、請求データなどの正本で確認してください。

モデル切替フックだけで全社ガバナンスは完結しますか？

完結しません。managed settings、権限、認証、gateway、監査ログ、データ取り扱い、例外申請、ロールバックを組み合わせます。フックは「切替イベント」を扱う1つの制御点です。

参考・一次情報

• Anthropic Claude Code CHANGELOG — v2.1.251の追加機能を確認（参照日：2026-08-29）
• Hooks reference – Claude Code Docs — 入力スキーマ、decision、timeout、各surfaceの差を確認（参照日：2026-08-29）
• Automate actions with hooks – Claude Code Docs — hook設定と実行方式を確認（参照日：2026-08-29）
• Configure models – Claude Code Docs — alias、opusplan、automatic fallbackを確認（参照日：2026-08-29）
• Prompt caching – Claude Code Docs — モデル切替時のcache挙動を確認（参照日：2026-08-29）
• npm registry: @anthropic-ai/claude-code latest — latestバージョンを確認（参照日：2026-08-29）

結論と次の一歩

モデル切替フックの価値は、モデル選択を固定することではありません。変更の前後に明確な境界を置き、要求経路、キャッシュ影響、判断理由、切替後のガイダンスを同じ設計で扱えることです。

1. 今日：公式hooks referenceとv2.1.251 changelogを読み、利用中バージョンと切替経路を一覧にします。
2. 今週：observe-onlyのPre/Post hookを1リポジトリへ入れ、8つの境界テストを実行します。
3. 今月：注意表示から限定denyへ段階移行し、managed settings、gateway、監査ログ、ロールバックを接続します。

あわせて読みたい：コスト可視化・上限設計、推論フックとDLP対応、利用モデルとスキル統制。

あわせて読みたい

• ▸ 【2026年9月】Claude Code研修・講師の依頼先6社比較と選び方
• ▸ 【2026年最新】Claude Code /compact｜長時間開発の5手順
• ▸ 【2026年最新】Claude Code /diff活用｜差分レビュー5手順
• ▸ 【2026年最新】Claude Code管理MCP配布｜7手順
• ▸ 【2026年最新】Claude Code外部読取制御｜設定5手順