Claude Haiku 3が死んだ。今すぐコード直してる話

Anthropicのリリースノートを確認したら、`claude-3-haiku-20240307` が2026年4月20日付けでretiredになっていた。
このモデルへのリクエストはもうエラーを返す。ハードな終了だ。

自分のコードベースを検索したら、3箇所ほど直接モデル名を文字列で書いてる部分が見つかった。
典型的な「あとで直そう」の負債がそのまま生きていた形だ。

定数管理してなかった自分への反省

こういうとき、モデル名をハードコードしてるとほんとうにキツい。
コードの複数箇所を grep して回ることになる。
今回の自分がまさにそれで、`grep -r "claude-3-haiku" ./src` して全部洗い出すところからスタートした。

理想は環境変数か設定ファイルに一箇所だけ書く設計だ。

# config/models.yaml
default_model: claude-haiku-4-5
fallback_model: claude-haiku-4-5

こういう形にしておけば、モデル名が変わっても1行直すだけで済む。
今回の件で痛感したので、次のPRでこの構造に直すつもりだ。

Haiku 4.5への移行で気にすること

Anthropicが推奨しているのは Claude Haiku 4.5 への移行だ。
パフォーマンスの話はひとまず置いておいて、コスト面が気になったので料金ページを確認した。

自分が使ってるユースケースはざっくり「ユーザー入力の前処理」と「短い文章の分類タスク」なので、レスポンス品質よりレイテンシとコストが重要な場所だ。
Haiku系はそのポジションのモデルとして使い続けると思う。

ひとつ注意しておきたいのは、モデルを切り替えたときにプロンプトの挙動が微妙に変わることがある点だ。
分類タスクのような「出力フォーマットをきっちり守ってほしい」系の処理は、移行後に必ず数十件のテストケースを流して確認したほうがいい。
自分は今回、移行テスト用のスクリプトを先に書いてから本番のコードを直す順番にした。

モデル廃止は突然来る、という前提で設計する

そもそもの話として、LLMのモデルは思ったより短い周期でdeprecateされる。
今回のHaiku 3 retiredもそうだし、同じリリースノートを見るとClaude Sonnet 4 と Claude Opus 4 も2026年6月15日にAPIからretiredになる予定だと書いてある。
しかも4月14日に発表されて、退場まで2ヶ月もない。

モデル名を抽象化しておくのは「綺麗なコードを書くため」という話じゃなくて、純粋に運用コストの問題だと思う。
直す範囲が広ければ広いほど、バグを仕込むリスクが上がる。

APIクライアントをラップする薄いクラスを作って、モデル名の解決はそこに集中させておくだけで全然違う。
自分はこれを今回の件でようやくちゃんとやるモチベーションが生まれた感じだ。

あなたのコードベースにも `claude-3-haiku-20240307` が眠ってないか、一度 grep してみてほしい。