「モデルIDに日付が付いていない。ということは、このIDは黙って中身が入れ替わるのでは」——Claude Opus 5やClaude Sonnet 5のような無日付のモデルIDを見て、そう身構えた開発者は少なくないはずだ。実際、claude-3-5-sonnet-20241022のような日付付きIDに慣れていると、日付が消えた瞬間に「ピン留めの保証が失われた」と読むのは自然な反応だ。
結論から言うと、その読みは半分正しく、半分間違っている。Anthropicの公式ドキュメントは「無日付のモデルIDは自動追従するevergreenなポインタだ」という理解を名指しで「よくある誤解」と否定している。ただし、そのすぐ隣に、見た目がそっくりな別の「無日付ID」が今も現役で存在していて、そちらは本当に中身が差し替わる。両者を混同すると、CIのモデルID検証ルールを書き間違えたまま本番に出てしまう。
この記事では、2026年7月時点の公式ドキュメント（Model deprecations、Models overview、Model IDs and versioning）を実際に開いて確認した内容をもとに、無日付IDの境界線がどこにあるのか、何が本当の落とし穴なのか、そして実装レベルでどう備えるかを整理する。
「日付あり」と「日付なし」、いま何が起きているのか
Anthropicのモデルデプリケーションページによると、Claude 4.6世代より前のモデルIDにはYYYYMMDD形式の日付が入る。claude-3-5-sonnet-20241022、claude-3-7-sonnet-20250219、claude-sonnet-4-20250514、claude-opus-4-20250514、claude-opus-4-1-20250805、claude-opus-4-5-20251101、claude-sonnet-4-5-20250929、claude-haiku-4-5-20251001までがこの形式だ。
一方、Claude 4.6世代以降は日付を含まない形式に切り替わっている。claude-opus-4-6、claude-opus-4-7、claude-opus-4-8、claude-sonnet-4-6、そして最新世代のclaude-opus-5、claude-sonnet-5、claude-fable-5、claude-mythos-5がこれにあたる。公式の「Model IDs and versioning」ページには、この形式をclaude-{name}-{major}[-{minor}]という命名スキームとして明記している。
2026年7月時点でのステータス（Active／Deprecated／Retired）を一部抜粋すると次のようになる。
| モデルID | 世代の形式 | 状態 | 備考 |
|---|---|---|---|
| claude-fable-5 | 5系・無日付 | Active | 暫定リタイア予定日は2027年6月9日以降 |
| claude-opus-5 | 5系・無日付 | Active | 暫定リタイア予定日は2027年7月24日以降 |
| claude-sonnet-5 | 5系・無日付 | Active | イントロ価格は2026年8月31日まで |
| claude-opus-4-6/4-7/4-8 | 4.6世代・無日付 | Active | 4.6世代以降で無日付形式に統一 |
| claude-opus-4-5-20251101 | 4.5・日付あり | Active | 短縮エイリアスclaude-opus-4-5あり |
| claude-sonnet-4-5-20250929 | 4.5・日付あり | Active | 短縮エイリアスclaude-sonnet-4-5あり |
| claude-haiku-4-5-20251001 | 4.5・日付あり | Active | 短縮エイリアスclaude-haiku-4-5あり |
| claude-opus-4-1-20250805 | 4.1・日付あり | Deprecated | 2026年8月5日リタイア予定、移行先はclaude-opus-4-8 |
参照日: 2026年7月27日（Anthropic公式Model deprecationsページに基づく）。
公式が名指しした「よくある誤解」——無日付ID=非固定ではない
「Model IDs and versioning」ページには、次のような記述がある（要約）。「無日付のモデルID（例：claude-sonnet-4-6）は、最新版や最も性能の良いバージョンに自動でルーティングされるevergreenなポインタだと誤解されがちだが、それは事実ではない」。
公式の説明はこうだ。4.6世代以降では、無日付のIDそのものが「そのリリースの正式なモデルID」であり、単一の固定されたモデルスナップショットに対応する。Anthropicは既存のモデルIDに対して重みや設定を更新することはなく、更新版を出す場合は新しいモデルIDとして公開する。つまり、日付という「見た目のピン留めサイン」が消えただけで、ピン留めという「保証」そのものは4.6世代以降も引き続き有効ということになる。
ここまでを整理すると、冒頭の「日付が消えた＝ピン留めが失われた」という直感は誤りだ。ではなぜこの記事を書く価値があるのか。それは、この誤解の裏側に、もう一つの本当に注意すべき仕組みが隠れているからだ。
本当に危ないのは、もう一つの「無日付」——エイリアスの罠
「Model IDs and versioning」ページはもう一つ重要な事実を明記している。「Claude APIでは、これらのモデル（4.6世代より前のモデル）に短縮エイリアス（例：claude-sonnet-4-5）が用意されており、そのマイナーバージョンの最新の日付付きスナップショットを指す」。そして、「このピン留めの保証はモデルIDに対するものであり、Claude APIが受け付ける一部の旧モデル向けの便宜的なエイリアスには適用されない」とも書かれている。
つまりclaude-sonnet-4-5という無日付の文字列は、4.6世代の正式な無日付IDとは似て非なるものだ。これは「エイリアス」であり、内部的には常に「そのマイナーバージョンの中で最新の日付付きスナップショット」を指す便宜的なポインタにすぎない。Anthropicが同じマイナーバージョン内で新しい日付付きスナップショットを出せば、このエイリアスが指す先は変わり得る。一方、claude-sonnet-4-6のような4.6世代以降のIDは、エイリアスではなく、それ自体がスナップショットそのものだ。
| 項目 | 4.6世代より前のエイリアス（例: claude-sonnet-4-5） | 4.6世代以降の正式ID（例: claude-sonnet-4-6） |
|---|---|---|
| 文字列の見た目 | 日付なし | 日付なし |
| 正体 | 便宜的なポインタ（エイリアス） | スナップショットそのもの |
| 固定されるか | されない。新しい日付付きスナップショットが出ると指す先が変わり得る | される。重みも設定も更新されない |
| 対応する日付付きID | claude-sonnet-4-5-20250929（実体はこちら） | 存在しない（このID自体が実体） |
この2つは文字列だけを見ると区別がつかない。「無日付だから新しい」「無日付だから危険」という単純なパターンマッチでは正しく判定できず、そのモデルが4.6世代以降のものか、それより前の世代のエイリアスかを知らなければ判断できない。ここが、この命名規則変更の本当の落とし穴だ。
IDが固定されていても挙動が変わりうる、もう一つの理由
もう一つ、公式ドキュメントが正直に書いている注意点がある。「Model IDs and versioning」ページの「Model weights versus serving infrastructure」という項では、「特定のモデルIDに対して重みは固定されているが、モデルを取り巻くサービング基盤（リクエストルーター、安全性分類器、サンプリングロジックなど）は変わりうる」「インフラの更新によって、モデルIDや重みが変わっていなくても、観測できる挙動にわずかな差異が生じることがある」と明記されている。
つまり「モデルIDが固定されている」ことと「出力の挙動が完全に不変である」ことは、厳密には別の話だ。IDのピン留め自体は信頼してよいが、サービング基盤側の変更による微妙なドリフトは、どの世代のモデルであっても起こりうる前提で運用を組む必要がある。
実装で手当てする——4つの具体的な対策
ここまでの整理を踏まえると、開発者側で手当てすべきことは「日付の有無を気にする」ことではなく、次の4点に集約される。
1. モデルIDを設定に外出しし、一箇所で差し替えられるようにする
# 動作環境: Python 3.11+
# モデルIDをコード中にハードコードせず、環境変数経由で一箇所に集約する
import os
MODEL_CONFIG = {
"primary": os.environ.get("CLAUDE_MODEL_PRIMARY", "claude-opus-5"),
"balanced": os.environ.get("CLAUDE_MODEL_BALANCED", "claude-sonnet-5"),
"fast": os.environ.get("CLAUDE_MODEL_FAST", "claude-haiku-4-5-20251001"),
}
# 呼び出し側は MODEL_CONFIG["balanced"] のようにキー経由で参照する。
# 新しいモデルIDへの切り替えは環境変数1箇所の変更で完結し、
# コードベース全体をgrepして回る必要がなくなる。
これは「無日付だから危険」への対策ではなく、そもそもモデルIDがどの世代であっても効く基本の設計だ。エイリアスから正式な日付付きIDへ、あるいは旧世代から4.6世代以降のIDへ移行する際も、変更箇所が1つで済む。
2. 固定プロンプトセットで回帰を検知する評価を継続的に回す
# 動作環境: Python 3.11+, anthropic>=0.40
# 代表的なタスクの固定プロンプトに対する出力を、モデルID切り替えのたびに比較する
import anthropic
client = anthropic.Anthropic() # ANTHROPIC_API_KEY は環境変数で渡す
EVAL_PROMPTS = [
"この関数のエッジケースを3つ挙げてください: ...",
"次のログからエラー原因を1文で要約してください: ...",
]
def run_eval(model_id: str) -> list[str]:
outputs = []
for prompt in EVAL_PROMPTS:
resp = client.messages.create(
model=model_id,
max_tokens=1024,
messages=[{"role": "user", "content": prompt}],
)
outputs.append(resp.content[0].text)
return outputs
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 実運用では出力をルーブリック採点や既存の正解データとの類似度で自動比較し、
# 閾値を下回ったらCIを失敗させる設計にすると、
# 「IDは同じなのにサービング基盤側の変更で挙動が変わった」ケースも拾える。
前段で触れた「重みは固定でもサービング基盤は変わりうる」というリスクに対しては、ID自体の検証ではなく、こうした継続的な出力の回帰検知が唯一の実効的な対策になる。
3. deprecationsページの監視を運用に組み込む
公式のModel deprecationsページには、Anthropicが「公開済みモデルについては、リタイアの少なくとも60日前までに通知する」「Claude ConsoleのUsageページからAPIキー・モデル別の使用状況をCSVでエクスポートし、非推奨モデルの利用箇所を洗い出せる」と明記されている。このページ自体をウォッチする仕組み（定期的な差分チェックやRSS的な監視）を持たない場合、通知メールを見逃した時点で気づく手段がなくなる。
4. コスト前提を価格改定のタイミングで見直す
Claude Sonnet 5は2026年8月31日までイントロ価格（入力$2／出力$10、100万トークンあたり）が適用され、9月1日以降は通常価格（入力$3／出力$15）に切り替わる。世代が上がっても価格が同一に据え置かれるケースもあれば、期間限定価格が終わるケースもあるため、コスト試算は一度作って終わりにせず、価格改定のタイミングで見直す運用にしておく必要がある。
架空のモデルIDはどうなるか——CIで実在を検証する
もう一つ、命名規則が変わったことで起きやすくなった事故がある。世代ごとにID形式が異なるため、記憶や過去の記事を頼りに「それらしい」IDを書いてしまい、存在しないモデルIDをコードやドキュメントに残してしまうケースだ。存在しないモデルIDをAPIに渡すと、リクエストは失敗する。
AnthropicはGET /v1/modelsというエンドポイントを公式に提供しており、現在利用可能なモデルIDの一覧をdata[].idとして取得できる。これを使えば、設定ファイルやコード内で参照しているモデルIDが実在するかどうかを、デプロイ前にCIで機械的に検証できる。
# 動作環境: Python 3.11+, requests
# CI上で実行し、設定に書かれたモデルIDが /v1/models に実在するかを検証する
import os
import sys
import requests
ANTHROPIC_VERSION = "2023-06-01"
def fetch_valid_model_ids() -> set[str]:
"""/v1/models をページネーションしながら、現在有効なモデルIDの集合を取得する"""
ids: set[str] = set()
after_id = None
while True:
params = {"limit": 100}
if after_id:
params["after_id"] = after_id
resp = requests.get(
"https://api.anthropic.com/v1/models",
headers={
"anthropic-version": ANTHROPIC_VERSION,
"x-api-key": os.environ["ANTHROPIC_API_KEY"],
},
params=params,
timeout=10,
)
resp.raise_for_status()
data = resp.json()
ids.update(m["id"] for m in data["data"])
if not data.get("has_more"):
break
after_id = data.get("last_id")
return ids
def check_configured_models(configured: list[str]) -> None:
valid_ids = fetch_valid_model_ids()
missing = [m for m in configured if m not in valid_ids]
if missing:
print(f"存在しないモデルIDが設定に含まれています: {missing}", file=sys.stderr)
sys.exit(1)
print(f"OK: {len(configured)}件のモデルIDはすべて実在します")
if __name__ == "__main__":
# MODEL_CONFIG は本来、設定ファイルや環境変数から読み込む
configured_models = ["claude-opus-5", "claude-haiku-4-5-20251001"]
check_configured_models(configured_models)
# 注意: 本番のCIパイプラインに組み込む前に、必ずステージング環境で動作確認してください。
# limit・ページネーションの仕様は公式ドキュメント（Models API）を必ず確認してください。
このチェックをデプロイパイプラインの1ステップにしておけば、「日付付きだと思っていたら実は存在しないIDだった」「エイリアスのつもりで書いたIDが4.6世代の別のモデルと衝突していた」といった事故を、本番リクエストが失敗する前に検知できる。
よくある質問
Q. 無日付のClaude API IDはピン留めされていますか？
4.6世代以降（claude-opus-4-6、claude-sonnet-5など）の無日付IDはピン留めされています。公式ドキュメントは、これらのIDが自動で最新版に追従する「evergreenなポインタ」だという理解を「よくある誤解」と明記しており、実体は日付付きIDと同じく固定されたモデルスナップショットです。
Q. では claude-sonnet-4-5 のような無日付表記は何が違うのですか？
claude-sonnet-4-5は4.6世代より前のモデルに用意された「エイリアス」で、同じマイナーバージョン内で最新の日付付きスナップショット（claude-sonnet-4-5-20250929）を指す便宜的なポインタです。公式ドキュメントは、ピン留めの保証はモデルIDに対するものであり、こうした便宜的なエイリアスには及ばないと明記しています。
Q. モデルIDが固定されていれば挙動も完全に変わらないと考えていいですか？
いいえ。公式ドキュメントは、モデルの重みは固定でも、リクエストルーターや安全性分類器などの周辺のサービング基盤は変わりうると明記しており、同じモデルIDのまま挙動がわずかに変化する可能性を認めています。だからこそ、固定プロンプトセットによる回帰検知を継続的に運用する必要があります。
まとめ
Claude 4.6世代以降で日付が消えたことは、「ピン留めが失われた」ことを意味しない。無日付のIDは今も固定されたスナップショットであり、その点では従来と何も変わっていない。本当に注意すべきなのは、同じく無日付に見える旧世代のエイリアス（claude-sonnet-4-5など）が実際には差し替わり得るという、見た目だけでは判別できない境界線の存在だ。あわせて、IDが固定されていてもサービング基盤側の変化で挙動がわずかにドリフトしうる点も、運用上は無視できない。
対策は特別なものではない。モデルIDを設定に外出しする、回帰検知の評価を回す、deprecationsページの通知を見逃さない、価格改定のタイミングでコストを見直す——この4つに加えて、CIでモデルIDの実在をAPI経由で機械的に検証する仕組みを持っておけば、命名規則がこの先また変わったとしても対応できる。
参考・出典
- Model deprecations — Anthropic公式ドキュメント（参照日: 2026-07-27）
- Models overview — Anthropic公式ドキュメント（参照日: 2026-07-27）
- Model IDs and versioning — Anthropic公式ドキュメント（参照日: 2026-07-27）
- Versions（anthropic-versionヘッダ） — Anthropic公式APIリファレンス（参照日: 2026-07-27）
- List Models（Models API） — Anthropic公式APIリファレンス（参照日: 2026-07-27）
この記事を読んで、モデルID管理の見直しポイントが見えてきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
あわせて読みたい:
- モデル消失時代のAIエージェント設計｜モデル非依存・フォールバック構成 — モデルIDの外出し設計をさらに一歩進め、特定モデルが使えなくなった場合のフォールバック構成まで扱った記事
- モデルルーティング設計ガイド2026｜タスク複雑度×コスト判断フロー — タスクの複雑度に応じてどのモデルIDを使い分けるかの判断フロー
- Claude Sonnet 5の位置付け｜Opus 4.8とのルーティング設計 — Claude Sonnet 5のベンチマーク・価格を踏まえたルーティング設計の詳細
- 【2026年最新】AIエージェントツール完全比較12選｜用途・料金・選び方ガイド — モデル・ツール選定の全体像
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人超。100社以上の企業向けAI研修・導入支援。著書累計3万部突破。
ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。
