messages.create を呼んだ瞬間に返ってくる error.type: "not_found_error" と model_not_found のメッセージ。コード上はほとんど変えていないのに、昨日まで動いていたスクリプトが急に止まる。Claude API を業務で使い始めると、ほぼ全員が一度はぶつかる症状ではないでしょうか。
私自身、別プロジェクトの古いコードを再利用して claude-3-5-sonnet-20241022 のまま叩いて、「これ最近触ってないだけだから動くはず」と思い込んで30分溶かした経験があります。原因の9割は権限ではなく、ただの綴り違い・エイリアスの古さ・コンソール側のモデル選択ミスです。落ち着いて切り分ければ、5分で復旧できる類のエラーです。
ここでは2026年4月時点で実在するモデルIDの一覧、ありがちな勘違いパターン、そして「どこが原因か」を一発で特定するための小さな診断スニペットまで、現場で詰まりやすい順に整理していきます。
エラー本体を読み解く — 「存在しない」と「アクセスできない」は別問題です
Anthropic の API が返す model_not_found は、実は2種類の状況をひとつに丸めた文言です。実際のレスポンスは次のような形をしています。
{
"type": "error",
"error": {
"type": "not_found_error",
"message": "model: claude-sonnet-4-5 does not exist or you do not have access to it"
}
}ここで重要なのは does not exist or you do not have access to it という後半の文言です。or で繋がっている通り、Anthropic は「そのモデルが存在しない」場合と「あなたのアカウントからは見えない」場合をまとめて同じエラーで返してきます。つまりエラーメッセージだけでは、原因がスペルミスなのか権限の問題なのか判別できません。
私の体感では、現場で見るこのエラーの内訳は次のような割合です。
- 古いモデルIDをコピーしてきて綴りが違う: 約60%
- 廃止されたモデルを引き続き呼んでいる: 約20%
- アカウントの Tier やリージョンで未許可: 約15%
- コンソール側で組織を切り替え忘れている: 約5%
解決の入り口は、「権限を疑う前にまず綴りを疑う」です。順番を間違えると遠回りになります。
2026年4月時点で実在するモデルIDの一覧
Claude のモデル名はリリースと共に少しずつ変わっています。2026年4月時点で実在し、messages.create の model パラメータに渡せる主要なIDは次の通りです。
claude-opus-4-6: 最新のフラッグシップ。複雑な推論や長文の構造化に強いclaude-sonnet-4-6: バランス型の主力モデル。日常的な業務はこれで十分claude-haiku-4-5-20251001: 高速・低コストモデル。バッチや要約に最適
注意していただきたいのが、ID の表記ルールが世代によって少しずつ違う点です。Haiku 4.5 だけ末尾に日付スタンプ -20251001 が付いており、Opus と Sonnet の最新版にはハイフン区切りの世代番号のみが付きます。これは Anthropic 側のリリース運用の都合で、過去のコードベースから移植する際にここで詰まる人を本当によく見ます。
「claude-sonnet-4-5 で動いていたのに claude-sonnet-4-6 だと弾かれる」というケースもしばしば見ますが、その多くは API キーが旧アカウントのもので、新モデルへのアクセスがまだ付与されていないだけです。後述の Tier 確認のステップで切り分けられます。
なお、1〜2世代前の claude-3-5-sonnet-20241022 などは、本記事執筆時点ではまだ呼べる場合がありますが、Anthropic は段階的に Sunset していく方針を表明しています。古いIDを直接ハードコードする運用は早めに卒業した方が安全です。
Tier・地域・コンソール側の権限を3分で確認する
綴りが正しいことを確認できたら、次に疑うのはアカウント側の権限です。確認すべき箇所は実は3つしかありません。
1. Anthropic Console の組織を確認する
複数の組織に所属している方が一番ハマるのがこれです。Console の左上に表示されている組織名を確認してください。会社用と個人用で API キーを使い分けているのに、コードに環境変数で渡しているキーが個人用、コンソールで見ているのが会社用、というすれ違いがよく起きます。
# 環境変数を確認する
echo $ANTHROPIC_API_KEY | head -c 15
# 出力例: sk-ant-api03-XXキーの先頭15文字程度を Console 側のキー一覧と照合すれば、どの組織のキーを使っているか即特定できます。
2. 該当モデルにアクセス権が付与されているか確認する
Console の Settings → Models で、組織ごとに利用可能なモデル一覧が確認できます。新しい Opus 4.6 などは段階的に解放されることがあり、Free Tier や Build Tier では一時的に見えていない場合もあります。
3. リージョン経由の API（Bedrock / Vertex）を使っていないか確認する
AWS Bedrock や Google Vertex AI 経由で Claude を呼ぶ場合、モデルIDは Anthropic 直の表記とは別物になります。
- Bedrock:
anthropic.claude-sonnet-4-6-v1:0のような形式 - Vertex AI:
claude-sonnet-4-6@20260301のような日付付き形式
社内のコード規約で Bedrock 経由なのに、サンプルコードを Anthropic 公式から持ってきて直のIDを書いてしまう、という事故も実は多いです。認証エラーで詰まった場合は、関連して Claude API の 401 認証エラーが出たときの確認手順 も合わせて確認しておくと安心です。
古いコードを安全に Sonnet 4.6 へ移行する
model_not_found の引き金として最も多いのが、古いプロジェクトを再起動したときの「世代ズレ」です。私が普段使っている、リスクの少ない移行手順をご紹介します。
# anthropic_client.py — モデル名は1箇所に集約する
import os
from anthropic import Anthropic
# モデル名は環境変数で切り替えられるようにしておくと、
# 緊急時に即座にフォールバックできる
DEFAULT_MODEL = os.getenv("CLAUDE_MODEL", "claude-sonnet-4-6")
FALLBACK_MODEL = os.getenv("CLAUDE_FALLBACK_MODEL", "claude-haiku-4-5-20251001")
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
def chat(messages: list[dict], model: str = DEFAULT_MODEL) -> str:
"""model_not_found を捕捉して自動でフォールバックする最小実装"""
try:
response = client.messages.create(
model=model,
max_tokens=1024,
messages=messages,
)
return response.content[0].text
except Exception as e:
# APIError は anthropic._exceptions から import できるが、
# ここでは文字列で型を判定して依存を最小化する
if "not_found_error" in str(e) and model != FALLBACK_MODEL:
print(f"[fallback] {model} not available, retrying with {FALLBACK_MODEL}")
return chat(messages, model=FALLBACK_MODEL)
raise
# 動作確認
if __name__ == "__main__":
result = chat([{"role": "user", "content": "Hello"}])
print(result)
# 期待する出力: "Hello! How can I help you today?" のような短い応答このパターンの肝は、モデル名をコード内に複数箇所書かないことです。grep -r "claude-sonnet" . で1箇所しかヒットしないようにしておけば、移行時の事故は劇的に減ります。
可用性をさらに高めたい場合は、複数モデルでフォールバックを組む実装パターン で紹介している多段フォールバックの考え方も参考になります。
ログから即座に切り分ける診断スニペット
エラーが本番で出たとき、深夜にログを眺めながら「これは綴り？権限？それとも別の何か？」と悩むのを避けるため、私は次のような診断スクリプトを使い回しています。
# diagnose_model.py — model_not_found の原因を3秒で切り分ける
import os
import sys
from anthropic import Anthropic
CANDIDATES = [
"claude-opus-4-6",
"claude-sonnet-4-6",
"claude-haiku-4-5-20251001",
]
def diagnose():
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
print(f"API Key prefix: {os.environ['ANTHROPIC_API_KEY'][:15]}...")
print()
for model in CANDIDATES:
try:
client.messages.create(
model=model,
max_tokens=1,
messages=[{"role": "user", "content": "ping"}],
)
print(f"✅ {model}: accessible")
except Exception as e:
err = str(e)
if "not_found_error" in err:
print(f"❌ {model}: not accessible (権限なしまたは廃止済み)")
elif "authentication_error" in err:
print(f"🔑 {model}: API キーが無効")
sys.exit(1)
else:
print(f"⚠️ {model}: {err[:60]}")
if __name__ == "__main__":
diagnose()
# 期待する出力例:
# API Key prefix: sk-ant-api03-XX...
#
# ✅ claude-opus-4-6: accessible
# ✅ claude-sonnet-4-6: accessible
# ✅ claude-haiku-4-5-20251001: accessibleこれを CI/CD のヘルスチェックに組み込んでおくと、デプロイ前に「実は本番アカウントから Opus が見えていない」といった事故を未然に防げます。各モデルに max_tokens=1 で叩くだけなので、コストは1リクエストあたり1セント未満です。
レート制限や 503 が混じるようなら、Claude API のレート制限と 429 エラーの実用的な扱い方 で紹介している指数バックオフを併用すると、より安定した診断結果が得られます。
Claude 専門書ではありませんが、エラー設計と互換性運用の章は今読んでも色褪せません。
全体を振り返って — 次にこのエラーが出ても、もう詰まりません
model_not_found は派手なエラーに見えますが、原因の切り分け順は決まっています。綴り → エイリアス世代 → 組織・キー → リージョン経由の表記、この順で確認すれば多くの場合5分以内に解決します。
今日できる具体的な一歩は、お使いのプロジェクトで grep -rn "claude-" --include="*.py" --include="*.ts" を一度走らせて、モデル名がコード内に何箇所書かれているかを数えてみることです。2箇所以上ある場合、それは将来のあなたが同じエラーで詰まるための時限装置になっています。今のうちに環境変数 1 箇所に集約しておくと、半年後の自分が必ず感謝します。