Sonnet 4 と Opus 4 が引退した日

2026 年 6 月 15 日午前 9 時 (太平洋時間)、Anthropic は Claude API の公式 Deprecations ページ で claude-sonnet-4-20250514 と claude-opus-4-20250514 のステータスを Retired に更新した。4 月 14 日に告知された引退通知の 60 日後、グレース期間なしの完全停止。

私達は 6 月 5 日の #51「Claude Agent SDK サブスクリプション分離」 で、Agent SDK クレジットプール分離 ($20 Pro / $100 Max 5x / $200 Max 20x、ロールオーバーなし) と Sonnet 4 + Opus 4 引退が 同じ日に発火する ことを 10 日先行して報じていた。本稿はその 第 2 half ── Sonnet 4 + Opus 4 引退 retrospective hub である。

同時に起きた 2 events の片方 (Agent SDK 分離) を 10 日前に先取りできた事実は、本ブログ Anthropic 2026 タイムラインハブ で継続してきた追跡体制の editorial responsiveness の proof と言える。本稿ではその「6 月 15 日ダブルヒット」を起点に、Anthropic モデルラインの 構造的変化 を 6 つの角度で分析する。

1. 「6 月 15 日ダブルヒット」の構造

Anthropic は 6 月 15 日に 2 つの構造変化を同時に発火 させた。これは偶然ではない。

2 つのイベントは 異なるユーザーベース に影響する。Agent SDK 分離は 月額サブスク契約者 (Claude Code を IDE/CLI で使う個人 + チーム)、Sonnet 4 + Opus 4 引退は API 直接呼び出し開発者 (production コードに claude-opus-4-20250514 を埋め込んでいる企業エンジニアリングチーム)。両者を分離して議論できるが、「6 月 15 日のモデルライン構造変化」 としては単一の事象である。

私達が 6 月 5 日に Agent SDK 分離を先行報道した時点で、Anthropic の「モデルライン分離」路線は不可避だったと読める。 #51 で指摘した通り、Anthropic は 2026 年に入ってから 月額契約と API 課金を分離 することで、SaaS 収益 (Claude Code) と API 収益 (Enterprise) の 財務的可視性 を高めようとしている。Sonnet 4 + Opus 4 引退は、その構造変化の API 側発火点 である。

「10 日リード」の事後検証

6/5 時点で Sonnet 4 + Opus 4 移行先を具体的に示せなかった理由は、Anthropic 公式の Deprecations ページが 4 月 14 日告知 → 6 月 15 日発火 の「公式 60 日ルール」で運用されており、移行先モデル ID (4-6 / 4-8) は 公式ページに明示されるまで確定扱いできない ため。本稿時点で公式ページに記載されている移行先を明示する。

2. 公式 Deprecations ページの構造

Anthropic の 公式モデル Deprecations ページ は、引退済みモデルの「Retired」ステータスを Retired YYYY-MM-DD 形式で履歴管理している。

6 月 15 日時点の現役 + 引退役モデル全体像

注目すべきは 3 点。

① 「Active Not sooner than YYYY-MM-DD」表記 ── Opus 4.8 (2027/5/28)、Sonnet 4.6 (2027/2/17) など現役モデルにも「最低保証引退日」が設定されている。最低 11 ヶ月前から告知する という Anthropic の 60 日ルールを厳格適用した形。

② claude-mythos-preview が 6 月 30 日に引退 ── Project Glasswing 初回アップデート で言及した Mythos Preview は 6/30 で引退、移行先は claude-mythos-5 (Glasswing 限定アクセス)。これは #60 Fable 5 / Mythos 5 リリース で解説した「Mythos-class 統合」の最終仕上げ。

③ claude-opus-4-1 が 8 月 5 日に引退予定 ── 6/5 告知 (ちょうど Agent SDK 分離と同じ日)、8/5 発火。次の Deprecation wave は 2026 年 8 月 5 日午前 9 時 (太平洋時間) で確定済み。

パートナー提供プラットフォームでの日付差異

Deprecations ページは明示している:

Dates apply to Anthropic-operated platforms: Claude API, Claude Platform on AWS, Microsoft Foundry. Partner-operated platforms (Amazon Bedrock and Vertex AI) set their own retirement schedules, so lifecycle status and dates may differ.

つまり AWS Bedrock と GCP Vertex AI は Anthropic 公式スケジュールと異なる引退日 を設定する可能性がある。Bedrock の場合は通常 1-2 ヶ月遅れで退役するが、6 月 13 日の AWS Bedrock Fable 5 データ保持強制 を経験した日本企業にとっては、AWS Bedrock 側で claude-sonnet-4-20250514 がまだ動いている ことに依存する設計は危険。両プラットフォームの日付差異を必ず確認すること。

3. 移行先の 5-tier 全体像

Sonnet 4 + Opus 4 が引退したことで、Anthropic モデルラインは 5-tier 構造 に確定した。

#60 Fable 5 リリース記事 で解説した「Mythos-class 統合」が完了し、Sonnet 4 + Opus 4 のリタイアは claude-opus-4 / claude-sonnet-4 系統の完全終了 を意味する。残った現役 Opus 系統 (4-5 / 4-6 / 4-7 / 4-8) と Sonnet 系統 (4-5 / 4-6) を含めて 5 つの現役モデル が production 選択肢となる。

移行先選定マトリクス

MindStudio の migration guide は claude-opus-4-7 をエージェント重視の選択肢として推奨しているが、6 月 5 日時点で claude-opus-4-8 が最新のため、本稿では 4-8 をデフォルト推奨 とする。MindStudio 推奨の 4-7 は 「現時点で成熟している」 ことが選択理由であり、新規採用では 4-8 一択。

4. 移行コード 3 種 (Python / TypeScript / bash)

引退モデルの API ID を新しいモデル ID に置換するだけでなく、3 つの breaking API change を同時に反映する必要がある。

4-1. Adaptive Thinking (Opus 4 → Opus 4.6+)

budget_tokens パラメータは 廃止、thinking: {type: "adaptive"} がデフォルトになった。

# ❌ 旧コード (claude-opus-4-20250514) ── 6/15 以降 404
response = client.messages.create(
    model="claude-opus-4-20250514",
    thinking={"type": "enabled", "budget_tokens": 8192},
    max_tokens=4096,
    messages=[{"role": "user", "content": "このコードを解析して"}]
)

# ✅ 新コード (claude-opus-4-8) ── adaptive thinking
response = client.messages.create(
    model="claude-opus-4-8",
    thinking={"type": "adaptive"},  # ← budget_tokens から変更
    max_tokens=4096,
    messages=[{"role": "user", "content": "このコードを解析して"}]
)

# ✅ 思考深度を制御したい場合 ── effort パラメータを追加
response = client.messages.create(
    model="claude-opus-4-8",
    thinking={"type": "adaptive"},
    effort="high",  # low / medium / high / max の 4 段階
    max_tokens=4096,
    messages=[{"role": "user", "content": "このコードを解析して"}]
)

effort パラメータはベータヘッダー不要で GA。ほとんどのユースケースでは "high" (デフォルト) で十分な精度 が得られる。"max" は Claude Opus 4.8 Dynamic Workflows の並列サブエージェント実行時のみ推奨。

4-2. 1M コンテキスト + 構造化出力 (Sonnet 4 → Sonnet 4.6)

Sonnet 4 で必要だった 1M コンテキストのベータヘッダー が、Sonnet 4.6 では不要になった。さらに output_format → output_config.format への移動も同時に必要。

# ❌ 旧コード (claude-sonnet-4-20250514) ── ベータヘッダー必須
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=4096,
    extra_headers={"anthropic-beta": "context-1m-2025-08-07"},  # 廃止予定
    messages=[{"role": "user", "content": "大規模コードを解析"}]
)

# ✅ 新コード (claude-sonnet-4-6) ── ベータヘッダー不要、1M 自動
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=64000,  # 出力上限引き上げ (旧 32K → 新 64K)
    messages=[{"role": "user", "content": "大規模コードを解析"}]
)

# ✅ 構造化出力 (JSON Schema) ── output_config に移動
import json
my_schema = {
    "type": "object",
    "properties": {
        "summary": {"type": "string"},
        "issues": {"type": "array", "items": {"type": "string"}}
    },
    "required": ["summary", "issues"]
}

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    output_config={"format": {"type": "json", "schema": my_schema}},  # ← output_format から移動
    messages=[{"role": "user", "content": "JSON で出力して"}]
)

4-3. Bash + grep 監査コマンド

production コードベース内に残っている旧モデル ID を一括検出する。

# 全リポジトリから旧モデル ID を検索
grep -rn "claude-opus-4-20250514\|claude-sonnet-4-20250514" \
  --include="*.py" --include="*.ts" --include="*.js" \
  --include="*.yaml" --include="*.yml" --include="*.json" \
  --include="*.env*" --include="*.toml" .

# 旧モデル ID の短縮形も検索 (claude-opus-4 単体の表記)
grep -rn "\"claude-opus-4\"\|'claude-opus-4'\|\"claude-sonnet-4\"\|'claude-sonnet-4'" \
  --include="*.py" --include="*.ts" --include="*.yaml" .

# AWS Bedrock モデル ID の検索
grep -rn "anthropic.claude-opus-4-20250514\|anthropic.claude-sonnet-4-20250514" .

# 環境変数・CI/CD シークレットの検索 (重要!)
grep -rn "CLAUDE_MODEL\|ANTHROPIC_MODEL" . --include="*.env*" --include="*.sh"

監査結果は inventory リスト としてチームに共有し、各ファイル所有者に対応責任を割り当てる。1 ファイルでも漏らすと 6/15 以降 production で 404 エラー が発生する。

5. 4 ステップ実装プレイブック (日本企業向け)

Step 1: Audit (Week 1 ── 6/15 発火済み、即時実施)

旧モデル ID の完全棚卸し。

# 監査スクリプトの例 (Python)
import os
import subprocess
from pathlib import Path

DEPRECATED_IDS = [
    "claude-opus-4-20250514",
    "claude-sonnet-4-20250514",
]

def audit_repo(root_path: str) -> dict:
    """旧モデル ID の使用箇所を検出"""
    results = {"found": [], "total_files_scanned": 0}
    
    for path in Path(root_path).rglob("*"):
        if path.is_file() and path.suffix in {".py", ".ts", ".js", ".yaml", ".yml", ".json"}:
            try:
                content = path.read_text(encoding="utf-8")
                results["total_files_scanned"] += 1
                for model_id in DEPRECATED_IDS:
                    if model_id in content:
                        results["found"].append({
                            "file": str(path),
                            "model_id": model_id,
                            "line": next(
                                (i+1 for i, line in enumerate(content.split("\n")) if model_id in line),
                                0
                            )
                        })
            except (UnicodeDecodeError, PermissionError):
                continue
    
    return results

# 実行
report = audit_repo("./")
print(f"検出ファイル数: {len(report['found'])}")
print(f"スキャン対象: {report['total_files_scanned']} ファイル")
for item in report["found"]:
    print(f"  {item['file']}:{item['line']} ── {item['model_id']}")

Step 2: Migrate (Week 2 ── 6/22 までに完了)

claude-opus-4-20250514 → claude-opus-4-8、claude-sonnet-4-20250514 → claude-sonnet-4-6 の一括置換。sed よりも IDE の一括置換 + 手動レビュー を推奨 (thinking パラメータの構造変更を同時に反映するため)。

config 一元管理パターン ── 将来のマイグレーションを 1 ファイル変更で完結させる:

# config/models.py ── 全モデル ID の中央管理
CLAUDE_MODELS = {
    "opus": "claude-opus-4-8",
    "sonnet": "claude-sonnet-4-6",
    "haiku": "claude-haiku-4-5",
    # 将来的なフラッグシップ Opus 移行時
    # "opus": "claude-opus-4-9",  # ← この 1 行だけ変更
}

// src/lib/claude.ts ── TypeScript 環境
export const CLAUDE_MODELS = {
  opus: "claude-opus-4-8",
  sonnet: "claude-sonnet-4-6",
  haiku: "claude-haiku-4-5",
} as const;

// 使用例
import Anthropic from "@anthropic-ai/sdk";
import { CLAUDE_MODELS } from "./lib/claude";

const client = new Anthropic();

async function summarize(text: string) {
  const message = await client.messages.create({
    model: CLAUDE_MODELS.sonnet,  // ← モデル ID を直接書かない
    max_tokens: 1024,
    messages: [{ role: "user", content: `要約: ${text}` }],
  });
  return message.content[0].text;
}

Step 3: Re-test (Week 3 ── 6/29 までに完了)

エージェント系タスク (Claude Code、Codex CLI 連携) では Opus 4.8 vs 旧 Opus 4 で出力品質に有意な差 が出る。

特に SWE-bench Pro 系タスク では #31 Claude Opus 4.8 でも解説した通り、Opus 4.8 は 4.7 比で +9pt の SWE-bench Pro 改善が報告されている。production の評価スイートを必ず再実行すること。

Step 4: Production cutover (Week 4 ── 7/13 までに完了)

旧モデル ID をコメントアウトではなく 完全削除 し、新モデル ID で production 切替。AWS Bedrock 側のスケジュール を必ず確認 (前述の Deprecations ページ注記参照)。

# production cutover チェックリスト
echo "=== Pre-cutover verification ==="
echo "1. grep で旧 ID が 0 件であることを確認"
grep -rn "claude-opus-4-20250514\|claude-sonnet-4-20250514" . || echo "✅ 旧 ID なし"

echo "2. config ファイルの新 ID 確認"
grep -rn "claude-opus-4-8\|claude-sonnet-4-6" config/ src/ | head -5

echo "3. 環境変数の確認"
echo "ANTHROPIC_DEFAULT_MODEL=$ANTHROPIC_DEFAULT_MODEL"

echo "4. CI/CD パイプラインの新 ID 通過確認"
grep -rn "claude-opus-4\|claude-sonnet-4" .github/workflows/

echo "=== Cutover ==="
git add -A
git commit -m "migrate: claude-{opus,sonnet}-4-20250514 → claude-{opus-4-8,sonnet-4-6}"
git push origin main

6. Anthropic モデルライン構造変化のナラティブ

「5 月 29 日 ── 6 月 17 日」の 20 日間タイムライン

Sonnet 4 + Opus 4 引退を 1 つの事象として見ず、過去 20 日間の Anthropic モデルライン構造変化の中で位置付ける。

この 20 日間で起きた構造変化をまとめると:

① モデルラインの世代交代 ── Sonnet 4 + Opus 4 (2025/5 世代) → Opus 4.8 + Sonnet 4.6 (2026/2-5 世代) → Fable 5 + Mythos 5 (2026/6 Mythos-class 統合) へと 3 段階の世代交代 が完了。

② Mythos-class 統合 ── 「Claude 3 系統 (Opus/Sonnet/Haiku)」の 3-tier 構造 が終焉し、「Mythos-class + Opus + Sonnet + Haiku」4-tier 構造 が標準化。さらに Open-Weight Frontier Japan Hub で詳述した通り、Mythos 5 は Glasswing 申請制に限定することで 「closed frontier ↔ open-weight」二項対立 が鮮明化。

③ 収益モデルの分離 ── 6/15 の Agent SDK 分離は 「月額契約収益 (Claude Code)」 vs 「API/Enterprise 収益」 の財務的可視性を分離する構造変化。S-1 提出 #43 を控えて、IPO 投資家に対して 2 つの独立した revenue stream を提示する狙い。

④ 政治的ガバナンス対応 ── #69 Trump-Sanders で詳述した「cross-aisle populist convergence」 (政府による AI 企業持株論) に対し、Anthropic は #73 Claude Corps で「自主的 AI 税」という制度的回答を提示。モデルライン構造変化は、こうした 政治的・制度的変化と並走する Anthropic の戦略的ポジショニングの一環。

6 月 15 日 = 構造的ブレークポイント

2026 年 6 月 15 日は、Anthropic モデルラインの 「旧世代完全終了」と「新世代 5-tier 確立」 が同時に成立する 構造的ブレークポイント。この日を境に、Anthropic を利用するすべてのエンジニア・企業・投資家は:

• 旧世代 ID の即時マイグレーション (API 利用者)
• 新世代 5-tier の使い分け戦略 (本番運用)
• Glasswing 申請 or Open-Weight 移行の判断 (規制業界)

の 3 軸同時判断 を迫られる。本稿が、その判断材料の retrospective hub として機能することを意図している。

7. 関連シリーズ・記事

Anthropic 2026 ドキュメント arc (24 記事)

関連: Open-Weight Frontier シリーズ (6 モデル)

コスト・経済学シリーズ

8. 日本企業 4 セクターへの影響

Sonnet 4 + Opus 4 引退は、AWS Bedrock ユーザー企業 にとって特に重要。Bedrock 側の引退日は Anthropic 公式より遅れる可能性があるが、#65 AWS Bedrock Fable 5 データ保持 で詳述した provider_data_share opt-in と組み合わせて考えると、AWS Bedrock ユーザーは Sonnet 4 + Opus 4 を「最後の ZDR 保証モデル」として温存 してきた可能性がある。

4 セクター別影響度

特に 汎用 SaaS 事業者 は 6/15 を過ぎても旧モデル ID を production で動かしている場合、ユーザーへの API リクエストが 404 エラー となり、SLA 違反 + 信頼失墜 のリスクがある。Step 1 (Audit) → Step 2 (Migrate) → Step 4 (Production cutover) を 7 月 13 日までに完了 することを強く推奨する。

まとめ

2026 年 6 月 15 日は、Anthropic モデルラインの 「旧世代完全終了」と「新世代 5-tier 確立」 が同時に成立する構造的ブレークポイントであった。

過去 24 記事の Anthropic ドキュメント + 6 モデルの Open-Weight Frontier シリーズ + Cost Reckoning シリーズと接続することで、本稿が 「Anthropic モデルライン構造変化」の retrospective hub として機能する。Sonnet 4 + Opus 4 引退を 1 つの技術イベントとして処理するのではなく、20 日間にわたる Anthropic の戦略的構造変化の中の一局面 として捉えることが、本稿の主張である。

次の #76 Cost Reckoning Part 9 (Bochinski HN「AI coding at home without going broke」) と #77 G7 Summit「Trusted Partners」 は、6 月 15 日以降の世界 (モデルライン 5-tier 確立後) で何が起きるかを 経済学 + 外交政策 の両側から分析する。

この記事はAIによって生成され、人間の編集を経て公開されています。 Appwright AI は AI によるコンテンツ制作の可能性を探求する実験的プロジェクトです。