はじめに
Claude Code を日常的に使い始めると、最初は「どのモデルが賢いか」ばかり見ていました。
ただ、しばらく触っていると、検証用の雑な試行と、本番作業の横で使う補助を同じ経路に流すのが少し怖くなりました。失敗してよい試作と、migration 手順や障害メモを確認する場面では、見たいログも、許容できるコストの膨らみ方も違うためです。
この記事では、Claude Code の用途を 検証, 日常作業, 本番補助 に分けて、モデル名だけではなく API key、base URL、上限、ログ確認まで含めて分ける設計を整理します。Flatkey AI は、その確認場所として使っています。宣伝っぽくなりすぎると自分でも読みづらいので、あくまで運用メモとして書きます。
3行まとめ
- Claude Code の用途を
検証,日常作業,本番補助に分けると、コストと事故時の追跡が少し楽になります。 -
ANTHROPIC_BASE_URLは送信先を変える設定で、モデルそのものの選択は/model,--model,ANTHROPIC_MODELなどと分けて考えるのがよさそうです。 - Flatkey AI 側では key、model access、usage、quota、routing logs を同じ dashboard で見られるので、経路ごとの差分を確認しやすくなります。
前提
私が前提にしたのは、次のようなローカル開発環境です。
| 項目 | 内容 |
|---|---|
| ツール | Claude Code |
| OS | macOS または Linux 想定 |
| Gateway | Flatkey AI |
| Claude Code 向け base URL | https://router.flatkey.ai |
| 認証 | Flatkey AI で作った用途別 API key |
2026-06-24 時点で Flatkey AI の Claude Code 向けページには、Claude Code を https://router.flatkey.ai と Flatkey API key で設定する説明があります。また、公開 pricing API では anthropic endpoint の path が /v1/messages として返っていました。
Claude Code 側の公式 docs では、LLM gateway は usage tracking、cost controls、audit logging、model routing のような役割を持つと説明されています。さらに model configuration docs では、ANTHROPIC_BASE_URL はリクエストの送信先を変えるもので、どのモデルが答えるかは別に設定すると明記されています。
この2つを分けて読むのが、今回いちばん大事だったかもしれません。
まず用途を3つに分ける
私は最初に、Claude Code の用途をざっくり次の3つに分けました。
| 用途 | 失敗許容度 | 例 | 分けたいもの |
|---|---|---|---|
| 検証 | 高い | 新しい agent prompt、雑な refactor 案、設定の試行錯誤 | 低めの quota、安めの group、短いログ確認 |
| 日常作業 | 中 | issue 調査、テスト追加、軽いレビュー補助 | 普段使いの上限、安定した route、週次の usage 確認 |
| 本番補助 | 低い | migration 手順確認、障害メモ、release note の確認 | 明示的な切り替え、強めの quota、必ず追えるログ |
ここで「検証は安いモデル、本番補助は賢いモデル」という単純な話にしないようにしました。もちろんモデルの能力差もありますが、業務で怖いのは、あとから「どの key で、どの route を通って、どれだけ使ったか」を追えないことだと思います。
特に Claude Code は自然に長い会話になります。途中でファイルを読んだり、テストを直したり、別の観点で再調査したりするので、1回の呼び出しだけ見ても感覚がつかみにくいです。だから、用途名を先に決めておき、経路名とログ名もそれに合わせるほうがよさそうでした。
モデル名ではなく経路として見る
最初に少し混乱したのは、Claude Code の model 設定と gateway 側の routing を同じものとして見てしまったことです。
Claude Code では /model や claude --model, ANTHROPIC_MODEL でモデルを選べます。一方で、ANTHROPIC_BASE_URL はどこにリクエストを送るかの設定です。さらに gateway 側では、そのリクエストをどの upstream や group に通すかを管理します。
私の理解では、分ける単位は次のようになります。
| レイヤー | 例 | 見る場所 |
|---|---|---|
| Claude Code のモデル選択 |
sonnet, opus, haiku, full model name |
Claude Code の /model や env |
| Claude Code の送信先 | ANTHROPIC_BASE_URL=https://router.flatkey.ai |
ローカル env や settings |
| 認証と用途 | 検証用 key、本番補助用 key | Flatkey AI の key 管理 |
| route / group / quota |
Claude Economy, Claude Official など |
Flatkey AI dashboard |
| 実際の使用量 | tokens、cost、session 単位の傾向 | Flatkey AI usage / logs |
Flatkey AI の公開 pricing API を 2026-06-24 に確認したところ、データ行は 632 件で、group として Claude Economy, Claude Official, Economy, Seedance2.0 Official, Standard が返っていました。Claude 系の available model には claude-sonnet-4-6, claude-opus-4-7, claude-haiku-4-5-20251001 などが含まれていました。
ただし、このへんは変わる前提で扱ったほうがよさそうです。記事や README に固定値を書いて放置すると、半年後の自分が困る気がします。
最小の環境変数ファイルを分ける
まずは小さく、用途ごとに env file を分ける形にしました。
# .env.claude.verify
export ANTHROPIC_BASE_URL="https://router.flatkey.ai"
export ANTHROPIC_AUTH_TOKEN="${FLATKEY_CLAUDE_VERIFY_KEY}"
export ANTHROPIC_MODEL="haiku"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="claude-haiku-4-5-20251001"
export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1
# .env.claude.daily
export ANTHROPIC_BASE_URL="https://router.flatkey.ai"
export ANTHROPIC_AUTH_TOKEN="${FLATKEY_CLAUDE_DAILY_KEY}"
export ANTHROPIC_MODEL="sonnet"
export ANTHROPIC_DEFAULT_SONNET_MODEL="claude-sonnet-4-6"
export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1
# .env.claude.prod-assist
export ANTHROPIC_BASE_URL="https://router.flatkey.ai"
export ANTHROPIC_AUTH_TOKEN="${FLATKEY_CLAUDE_PROD_ASSIST_KEY}"
export ANTHROPIC_MODEL="sonnet"
export ANTHROPIC_DEFAULT_SONNET_MODEL="claude-sonnet-4-6"
export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1
ここで大事なのは、env file に実 token を書かないことです。FLATKEY_CLAUDE_VERIFY_KEY などは、ローカルの secret manager や shell profile から読む想定にしています。
CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1 は、gateway の /v1/models から Claude 系モデルを picker に出したい場合の設定です。公式 docs によると、これは v2.1.129 以降で、ANTHROPIC_BASE_URL が Anthropic Messages format の gateway を指している場合に使われます。gateway が /v1/models を実装していなければ、cached list か built-in list に戻るので、必須というより確認用の設定として見ています。
起動 wrapper に profile を出す
次に、起動時にどの profile を使ったかをログへ残す wrapper を置きました。
#!/usr/bin/env bash
set -euo pipefail
profile="${1:?usage: ./claude-route.sh verify|daily|prod-assist}"
env_file=".env.claude.${profile}"
if [ ! -f "${env_file}" ]; then
echo "env file not found: ${env_file}" >&2
exit 1
fi
set -a
source "${env_file}"
set +a
printf '[claude-code-route] profile=%s base_url=%s model=%s started_at=%s\n' \
"${profile}" "${ANTHROPIC_BASE_URL}" "${ANTHROPIC_MODEL}" "$(date -Is)"
exec claude
使うときはこうです。
./claude-route.sh verify
./claude-route.sh daily
./claude-route.sh prod-assist
これだけでも、terminal scrollback や shell history に「今日は本番補助 profile で起動した」という痕跡が残ります。もちろん本気で監査するなら shell history では足りません。ただ、自分の作業ミスを減らすには、この程度の表示でもかなり効くと思います。
最初は prod という名前にしようとしたのですが、これはやめました。Claude Code に本番操作を直接やらせる意図に読めてしまうからです。私は prod-assist にして、人間が本番作業をする横で確認する用途だと分かる名前にしました。
Flatkey AI dashboard で見る項目
env を分けただけでは、実際に分かれたかどうかは確認できません。ここで gateway 側の dashboard を見ます。
私が確認する項目は次の5つです。
| 見る項目 | 検証用 | 日常作業 | 本番補助 |
|---|---|---|---|
| Key | 検証用 key だけを使う | 普段使い key | 明示的に切り替える key |
| Model access | 試しやすい group に寄せる | 通常利用の group | 許可 model を絞る |
| Usage / cost | 低めの上限で膨らみを早く見る | 週次で見る | 作業ごとに見る |
| Quota | 小さくする | 標準 | 強く管理する |
| Routing logs | fallback や upstream を見る | ざっくり傾向を見る | 何が起きたか説明できる粒度で見る |
Flatkey AI の pricing API では、Claude Code 向けに Claude Economy は cost-effective resource、Claude Official は official key resource という説明が返っていました。私はこの名前だけで判断せず、実際には dashboard 側の model access と usage を見て、チームの用途に合っているか確認するつもりです。
検証 は失敗してよいので、quota を低めにして早く気づけるほうがありがたいです。逆に 本番補助 は、安さよりも「あとから説明できること」を優先したいです。ここを同じ key にしてしまうと、後から usage を見たときに混ざってしまいます。
ハマりそうだったところ
ANTHROPIC_BASE_URL と model を混同する
一番ありがちなミスは、base URL を変えたら model routing も全部期待通りになると思うことだと思います。
Claude Code 側では、base URL は送信先です。どの model を選ぶかは、/model, --model, ANTHROPIC_MODEL, settings の model などで決まります。さらに gateway 側で、key や group、routing policy が関わります。
このため、私は profile 名を model 名にしないようにしました。haiku や sonnet ではなく、verify や prod-assist にしています。model は後で変えられるけれど、用途名は運用ルールとして残したいからです。
provider native token と gateway token を混ぜる
もう1つ怖いのは、Anthropic の token と gateway の token を混ぜることです。
この記事の例では ANTHROPIC_AUTH_TOKEN に Flatkey AI の用途別 key を入れる想定です。provider native token を別の terminal に残したまま使うと、どこを通っているのか分からなくなります。
私は env | grep ANTHROPIC を起動前に見る癖をつけるほうがよさそうだと思いました。泥臭いですが、こういう確認で事故が減ることも多いです。
env | grep '^ANTHROPIC_' | sort
もちろん、この出力をそのまま issue や Slack に貼るのは危ないです。token が含まれる可能性があるので、共有するなら必ず mask します。
本番補助を便利にしすぎる
本番補助 profile は、便利にしすぎると危ないと思いました。
例えば、自動で prod-assist を選ぶ alias を作ると、いつの間にか本番補助 profile で雑な検証をしてしまうかもしれません。私はあえて毎回 ./claude-route.sh prod-assist と打つ形にしています。
数秒の手間ですが、「いまは本番補助として使う」という確認になります。こういう面倒さは、少し残しておくほうがよい場合もあると思います。
今回やらなかったこと
この記事では、Claude Code の具体的な会話ログや dashboard screenshot は載せていません。token や社内 repository 名が混ざりやすいからです。
また、コスト削減率も書いていません。Flatkey AI のページには安く使える訴求がありますが、私の実測として比較したわけではないので、Qiita 記事では書かないほうが誠実だと思いました。
今回やったのは、あくまで経路分離の設計です。
- 用途名を決める
- 用途ごとに key を分ける
- Claude Code の base URL と model 設定を分けて理解する
- 起動 wrapper で profile を表示する
- dashboard で usage、cost、quota、routing logs を見る
これだけでも、全部同じ key で流していたときよりは、かなり見通しがよくなりました。
まとめ
Claude Code のモデル選択は、単に「賢いモデルを選ぶ」話ではないと思いました。
検証、日常作業、本番補助では、失敗してよい範囲も、追跡したいログも、許容できるコストの膨らみ方も違います。だから私は、model name だけではなく、API key、base URL、quota、dashboard の見方まで含めて 経路 として分けることにしました。
Flatkey AI を使うと、key、model access、usage、cost、quota、routing logs を同じ場所で見られるので、Claude Code の運用を分ける実験には向いていると思います。ただし、model group や pricing API の内容は変わるので、固定値として信じすぎず、公開前や運用変更前に必ず確認したほうがよさそうです。
参考
- Flatkey AI Claude Code use case: https://flatkey.ai/use-case/claude-code
- Flatkey AI pricing API: https://router.flatkey.ai/api/pricing
- Claude Code LLM gateway configuration: https://code.claude.com/docs/en/llm-gateway
- Claude Code model configuration: https://code.claude.com/docs/en/model-config
間違いあったらコメントください。よろしくお願いします。