HN threadでのClaude Opus 4.7は、単なる新model公開としては読まれていない。scoreもcomment数も大きいが、中心にあったのは「どれだけ賢いか」だけではなく、「このproduct behaviorを前提に長いworkflowを組めるのか」という問いだった。

最初に引っかかったのはadaptive thinkingだ。以前のthinking budgetやthinking effortを前提にコードを書いていた開発者は、新しい挙動をAPI側でどう扱えばよいのかを気にしていた。reasoning summaryの見え方に関するdoc変更も話題になった。agentの実行ログを人間が確認し、costを見積もり、なぜその判断に至ったのかを追うチームにとって、これは小さなUI差ではない。

tokenizer変更もすぐに実務の話へ移った。同じ入力でもcontent typeによってtoken数が増える可能性がある、という説明を見たHNユーザーは、性能より先にbillとcontext planningを考えた。強いmodelでも、既存promptが静かに膨らむなら運用は難しくなる。長いagent sessionでは、その差がbudgetやlatencyにそのまま出る。

safety filterへの反応はさらに鋭かった。正当なdefensive securityやbug bountyの文脈でも、modelが過度に慎重だと感じたという声があった。一方で、危険なcyber利用を抑える必要があるのも明らかだ。threadが示していたのはsafetyへの単純な賛否ではなく、合法で説明済みの作業まで不規則に止まる時に生まれる信頼コストだった。

そのため、Codexや他のcoding agentとの比較も自然に混ざった。すでに乗り換えたという声もあれば、その比較が本題を薄めているという反応もあった。Opus 4.7へのHNの初期評価は、benchmark表だけではない。quotaの透明性、token accounting、safety friction、agent traceの一貫性まで含めて、frontier modelを実務systemに置けるかを試している。

#adaptive-thinking

Claude Opus 4.7、HNはbenchmarkよりadaptive thinkingと信頼回復を見た