Anthropicが5月28日にリリースしたClaude Opus 4.8、とりあえず公式のrelease notesを頭から読んだ。1M tokenのcontext windowとか128k max outputとかもえぐいんだけど、自分が一番「あ、これPR出せる」となったのはmid-conversation system messageの正式サポートだ。
今まで自分がLLMラッパーを書くときの一番のハマりポイントは、長いセッションでシステムプロンプトを途中で変えたくなる瞬間だった。たとえばユーザーが認証を通過したあとに権限レベルに応じた指示を追加したいとか、会話の途中でツールの使い方の制約を動的に切り替えたいとか。そういうユースケースで今まではconversation historyを全部作り直すか、workaroundとしてuserターンにシステム的な指示を雑に混ぜるかしかなかった。prompt cache hitが吹き飛ぶのもつらかった。
Opus 4.8ではmessages配列の中でuserターンの後にrole: \"system\"を送れるようになった。placement rulesがあるので全部が全部できるわけじゃないけど、少なくともprompt cacheをなるべく壊さずに途中で命令を差し込めるのは素直にありがたい。beta headerも不要。うちのチームで使っているセッション管理のコードは割とシンプルに直せそうだ。
もう一個気になったのがstop_detailsフィールドの公式ドキュメント化だ。refusal responseにcategoryとして cyber か bio か null が返ってくるやつ。今まではモデルが断る理由を自前でパースしようとして微妙な正規表現を書いてたんだけど、これが構造化されて返ってくるなら素直にswitch caseで振り分けられる。こっちも直したい箇所がすぐ浮かんだ。
コスト面でもう一点。prompt cachingのminimum cacheable prompt lengthが1,024 tokenに下がった。Opus 4.7のときは2,048だったはずで、短めのシステムプロンプトでもキャッシュが効くようになる。自分が個人開発で触っているDiscordボットは最初のシステムプロンプトが1,200tokenくらいで、これまでキャッシュの恩恵がほぼなかった。これは地味に助かる変更だ。
adaptive thinkingがOpus 4.8でさらに賢くなったという話もある。同じeffort: highの設定でも、thinking tokensを必要なターンだけ使うようになったらしい。Opus 4.7のときは全ターンでthinkingが走ってコストが予想より膨らむことがあった。自分のProduction環境の請求書を見るとthinking tokenの占める割合がじわじわ上がってきていたので、これが改善されるなら費用感がだいぶ変わりそうだ。
あと、temperature / top_p / top_kをnon-defaultに設定すると400エラーになる制約はOpus 4.7から引き続きある。ここはたまに忘れてハマる人を見るので、チームのAPIラッパーにvalidationを追加しておこうと思う。
Opus 4.6のfast modeは30日後にremovalなので、そっちを使ってる人は早めにOpus 4.7か4.8のfast modeに移行が必要だ。うちは既にOpus 4.7ベースに切り替えてあるので影響はないけど、一応migration guideを読んでおくつもり。
mid-conversation system messageのplacement rulesの細かい仕様をまだちゃんと読めていない。週末にドキュメントを一通り試してから、既存のセッション管理モジュールにPRを出すのが直近のタスクだ。
今まで自分がLLMラッパーを書くときの一番のハマりポイントは、長いセッションでシステムプロンプトを途中で変えたくなる瞬間だった。たとえばユーザーが認証を通過したあとに権限レベルに応じた指示を追加したいとか、会話の途中でツールの使い方の制約を動的に切り替えたいとか。そういうユースケースで今まではconversation historyを全部作り直すか、workaroundとしてuserターンにシステム的な指示を雑に混ぜるかしかなかった。prompt cache hitが吹き飛ぶのもつらかった。
Opus 4.8ではmessages配列の中でuserターンの後にrole: \"system\"を送れるようになった。placement rulesがあるので全部が全部できるわけじゃないけど、少なくともprompt cacheをなるべく壊さずに途中で命令を差し込めるのは素直にありがたい。beta headerも不要。うちのチームで使っているセッション管理のコードは割とシンプルに直せそうだ。
# 構造イメージ (実際はSDKで組む)
curl https://api.anthropic.com/v1/messages \\
-H \"x-api-key: $ANTHROPIC_API_KEY\" \\
-H \"anthropic-version: 2023-06-01\" \\
-d '{
\"model\": \"claude-opus-4-8\",
\"messages\": [
{\"role\": \"system\", \"content\": \"...\"},
{\"role\": \"user\", \"content\": \"...\"},
{\"role\": \"system\", \"content\": \"追加指示\"},
{\"role\": \"user\", \"content\": \"...\"}
]
}'もう一個気になったのがstop_detailsフィールドの公式ドキュメント化だ。refusal responseにcategoryとして cyber か bio か null が返ってくるやつ。今まではモデルが断る理由を自前でパースしようとして微妙な正規表現を書いてたんだけど、これが構造化されて返ってくるなら素直にswitch caseで振り分けられる。こっちも直したい箇所がすぐ浮かんだ。
コスト面でもう一点。prompt cachingのminimum cacheable prompt lengthが1,024 tokenに下がった。Opus 4.7のときは2,048だったはずで、短めのシステムプロンプトでもキャッシュが効くようになる。自分が個人開発で触っているDiscordボットは最初のシステムプロンプトが1,200tokenくらいで、これまでキャッシュの恩恵がほぼなかった。これは地味に助かる変更だ。
adaptive thinkingがOpus 4.8でさらに賢くなったという話もある。同じeffort: highの設定でも、thinking tokensを必要なターンだけ使うようになったらしい。Opus 4.7のときは全ターンでthinkingが走ってコストが予想より膨らむことがあった。自分のProduction環境の請求書を見るとthinking tokenの占める割合がじわじわ上がってきていたので、これが改善されるなら費用感がだいぶ変わりそうだ。
あと、temperature / top_p / top_kをnon-defaultに設定すると400エラーになる制約はOpus 4.7から引き続きある。ここはたまに忘れてハマる人を見るので、チームのAPIラッパーにvalidationを追加しておこうと思う。
Opus 4.6のfast modeは30日後にremovalなので、そっちを使ってる人は早めにOpus 4.7か4.8のfast modeに移行が必要だ。うちは既にOpus 4.7ベースに切り替えてあるので影響はないけど、一応migration guideを読んでおくつもり。
mid-conversation system messageのplacement rulesの細かい仕様をまだちゃんと読めていない。週末にドキュメントを一通り試してから、既存のセッション管理モジュールにPRを出すのが直近のタスクだ。