Claude Sonnet 5.5のCode Arena結果、高モードが4位に

Claude Sonnet 5.5は、高い推論負荷のCode Arena: WebDevで1,699点を獲得し、Arenaの9月29日時点のスナップショットで4位に入った。同じ推論負荷設定におけるClaude Sonnet 5.5のCode Arena結果は、Sonnet 5を159点上回った。これは世代間で意味のある向上だが、この順位は恒久的な評価ではなく、変動するベンチマーク上の結果にとどまる。

より示唆的な変化は、総合スコアの下位項目に現れた。日付付きの結果によると、SonnetはReference-Based Design、Simulations、Gamingで30位圏外から4位へ上昇した。これらのカテゴリは、特定の視覚的・挙動上の要件を、動作するWeb体験へと変換できるかを試す。

Arenaはまた、Sonnet 5.5を、そのすぐ上に位置するモデルより低コストな選択肢として位置付けた。ここに本質的な緊張関係がある。Anthropicの中価格帯モデルはリーダーボードを制したわけではないが、多くの開発チームがすべてのフロントエンド作業に最上位モデルを必要とするのかを問うほど、首位グループに近づいた。

Claude Sonnet 5.5のCode Arenaでの伸長は、単なる新たな順位以上の意味を持つ

見出しは4位だが、重要なのは前世代のSonnetから159点向上したことだ。

Code Arena: WebDevは、Web開発タスクと人間の選好を通じてモデルを比較する。ライブのWebDevボードでは、複数段階の推論とツール利用を要するエージェント型ワークフローを含む、フロントエンド作業を評価対象としていると説明されている。

Arenaは、高い推論負荷のClaude Sonnet 5.5に1,699点を報告した。高い推論負荷のSonnet 5は1,540点だった。この差をコーディング能力の単純な割合改善に換算することはできない。リーダーボードのレーティングは比較評価だからだ。それでも、同一モデルファミリー内で159点動いたことは、購入者がルーティングシステムでSonnetをどう位置付けるかを変えるほど大きい。

Highというラベルは重要だ。推論負荷の設定は、モデルが応答前にどの程度長く考え、作業を確認するかを制御する。高い推論負荷は難しい出力を改善し得る一方、レイテンシーとトークン消費を増やす可能性もある。High同士を比較することで、異なる設定を比較するよりも世代間の結果は有用になる。

4位という順位にもタイムスタンプが必要だ。Arenaのリーダーボードは、モデルへの投票が増え、新たなシステムが参加し、信頼区間が狭まるにつれて変化する。Arenaの公開ページ自体も、固定された認定ではなくライブシグナルとして提示されている。

この違いが、リーダーボードのスコアはテストの指針にはなっても、それに取って代わるものではない理由を説明している。あるスナップショットで首位のモデルでも、投票量の増加に伴って順位を動かす可能性がある。また、企業独自のリポジトリ、デザインシステム、対象ブラウザ、デプロイ環境では異なる性能を示すこともある。

それでもこの結果は、チームがSonnetを再テストする十分に信頼できる理由になる。Sonnet 5をプレミアムモデルから大きく引き離された位置に置いた過去の評価は、もはや現在の選択肢を正しく表していないかもしれない。その古い差に基づくモデル方針は、現在では時間や処理能力を無駄にしている可能性がある。

Anthropic自身のモデル発表も、WebDevスコアを独自に検証するものではないものの、Arenaでの動きの方向性を裏付けている。同社によれば、Sonnet 5.5はSonnet 5に比べ、コーディング、視覚的理解、長時間にわたる作業、ツール効率を改善している。

Anthropicはまた、このモデルが前世代より30%以上速く出力を生成するとしている。開発者がページを承認するまでに数十回の小さな修正を依頼することもある反復的なWeb開発では、この主張は重要だ。

より速い応答に価値があるのは、品質が維持される場合に限られる。Arenaが報告した向上は、Anthropicが明確な選好出力の低下を受け入れて速度を得たわけではないことを示唆する。ただし、公開結果だけからは、推論時間、トークン使用量、再試行、最終コード品質の正確なバランスは分からない。

最も安全な読み方は限定的だが重要である。高い推論負荷では、Sonnet 5.5はArenaのWeb開発環境において大幅に競争力を高めた。どのシステムが本番環境で最も機能するかという広範な問いに決着がつく前でも、モデル選定の判断を見直すには十分だ。

3つの弱かったカテゴリが最も強い証拠へと変わった

Reference-Based Design、Simulations、GamingにおけるSonnet 5.5の上昇は、意図をインタラクティブな挙動に変換する能力が幅広く向上したことを示唆している。

Reference-Based Designは、視覚的な目標や既存デザインに導かれた作業を評価する。成功には有効なHTMLとCSSを生成する以上のことが求められる。モデルは、提供された参照からレイアウト、余白、階層、色、コンポーネント、レスポンシブな挙動を解釈しなければならない。

このカテゴリでの高スコアは、すでにFigmaファイル、スクリーンショット、確立済みのインターフェースを持つプロダクトチームにとって重要になり得る。彼らの課題は、「Webサイトを作る」ことではほとんどない。むしろ「この正確なパターンを、比率、状態、視覚的なリズムを損なわずに実装する」ことに近い。

高い推論負荷のSonnet 5は、このカテゴリで30位圏外にいたと報告されている。Sonnet 5.5は4位に到達した。この変化は、視覚的なグラウンディング、実装の選択、あるいはその両方の向上を示す。公開投稿には、どの能力がこの伸びを生んだのかを切り分けるだけの詳細はない。

Simulationsは別種の難しさを持ち込む。シミュレーションは時間の経過に伴うルールを表現し、入力に応答し、一貫した内部状態を維持しなければならない。誤った動き、壊れたコントロール、不安定な挙動を、魅力的なスタイリングで補うことはできない。

軌道の可視化、粒子システム、経済サンドボックスを構築するモデルは、インターフェース要素と基礎となるモデルを結び付ける必要がある。また、静的なスクリーンショットには現れないエッジケースも扱わなければならない。このため、シミュレーションは、生成されたコードが初回レンダリング後も首尾一貫して動作するかを測る有用なテストとなる。

Gamingには関連する要求があるが、応答性とインタラクションへの圧力はさらに高まる。小規模なブラウザゲームであっても、入力処理、衝突ロジック、スコアリング、アニメーション、音声状態、再スタート動作を組み合わせることがある。説得力のある最初のフレームだけでは、体験が遊び続けられるものかはほとんど分からない。

したがって、3つの領域すべてで30位台から4位に移動したことは、1つの視覚カテゴリだけで順位を上げるよりも多くを示している。デザイン解釈、動的状態、インタラクティブな実行にまたがる改善を示唆するからだ。

Arenaは、カテゴリの方法論が、より広範なWebDev評価プロセスをフィルタリングされたプロンプト領域に適用していると説明している。実際のプロジェクトでは複数の意図が組み合わさることが多いため、プロンプトには複数のカテゴリが付与されることがある。たとえばダッシュボードには、マーケティング要素やインタラクティブなシミュレーションも含まれ得る。

この重なりによりカテゴリ結果は有用になる一方、明確な因果関係の結論は妨げられる。強いGaming結果は、視覚デザインや指示追従の向上を部分的に反映している可能性がある。Reference-Based Designの向上は、フロントエンドアーキテクチャの改善ではなく、画像理解の改善に依存しているかもしれない。

それでも結果はAnthropicの位置付けと整合する。同社はSonnet 5.5について、デザインを見る目がより鋭くなったと説明し、洗練されたドキュメント、スライド、Web出力を作成できる能力を強調している。これらは企業側の主張だが、Arenaのカテゴリ上の動きは同じ方向を示す外部シグナルとなる。

Anthropicが引用する実アプリのテストも、もう一つの手掛かりを加える。Base44は118件のアプリ構築でモデルを評価し、より少ない反復でOpus 5と同じ品質水準に達したと報告した。Base44は早期テスターとして参加していたため、この証拠は中立的な監査と同等ではない。しかし、主張される能力が実際の生成ワークフローでどのように現れるかは示している。

Unityは、モデルの作業の大半がランタイムチェックを通過し、同社の社内マルチステップベンチマークのタスクを90%完了したと報告した。このテストはブラウザ開発ではなくUnityに焦点を当てているが、生成された成果物が正しく実行されるかを評価する重要性を補強している。

開発者にとって、これらのカテゴリは身近なタスクに対応する。プロダクトエンジニアは、スクリーンショットから承認済みインターフェースを再現する必要があるかもしれない。データチームは、インタラクティブなシナリオエクスプローラーを求めるかもしれない。ゲームスタジオは、アート、コントロール、状態を結び付けるプロトタイプを必要とするかもしれない。

カテゴリでの飛躍は、Sonnet 5.5がすべての参照を正確に再現したり、本番対応のゲームを作成したりすることを意味しない。これは、これらの領域に分類されたプロンプトで、モデルが大幅に強い選好を得たことを意味する。チームはこれを自動的なデプロイ判断ではなく、テストの優先事項として扱うべきだ。

フロンティアに近いモデルがコストパフォーマンスの問いを変える

Claude Sonnet 5.5は、WebDevスコアでプレミアムモデルに近づきつつ、日常的で大量の作業向けに位置付けられることで、プレミアムモデルに圧力をかけている。

従来のモデルルーティングにおける前提は単純だ。品質が重要なときには最も能力の高いモデルを使い、簡単または反復的な作業には小型モデルを使う。Claude Sonnet 5.5のCode Arena結果は、この区分をより居心地の悪いものにする。

Arenaの比較では、Sonnet 5.5はスコアで首位グループを下回った一方、混合利用コストでは2位と3位のシステムを大きく下回った。正確な運用費は、入力長、出力長、キャッシュ、再試行、推論負荷設定に依然として左右される。見出しレベルの比較では、特定のアプリケーションにおける最終的な請求額を予測できない。

圧力を生むのは方向性だ。チームが4位と2位の性能差を許容できるなら、より安価なモデルは有力なデフォルト候補になる。その場合、プレミアムモデルは信頼性、難しいエッジケース、あるいは人間による修正の少なさを通じて、その位置を正当化する必要がある。

フロントエンド開発では作業が一連の修正として到来するため、これは特に重要だ。開発者は初期ページを生成し、確認し、レイアウト変更を依頼し、レスポンシブな挙動を修正し、イベント処理を修復するかもしれない。1ターンあたりの差が小さくても、このループ全体で積み重なる。

レイテンシーも同様に積み重なる。Anthropicによれば、Sonnet 5.5はSonnet 5より30%以上速く出力を生成する。モデルが最初の試行でタスクを完全に終えられない場合でも、より速い反復はアイデアから目に見える結果までの時間を短縮し得る。

競争相手は他社ベンダーだけではない。Claude Opus 5.5も判断の一部だ。Anthropicは、Opusを持続的な判断を要するオープンエンドな作業により強い選択肢と説明する一方、Sonnetは明確に範囲が定められた日常タスクと高速な反復を対象としている。

これにより自然な社内ルーティング戦略が生まれる。Opusはアーキテクチャを定め、曖昧な要件を解決し、難しい障害を調査できる。Sonnetは定義済みのコンポーネントを実装し、修正を適用し、通常の開発作業のより大きな量を処理できる。

ある早期テスターは、まさにこの役割分担を説明した。クリエイティブコーダーのKevin Ngoは、Opus 5.5がアーキテクチャと全体的なフレームワークを確立した後なら、ゲーム実装をSonnet 5.5に任せると述べた。このコメントはAnthropicの発表資料に掲載されているため、独立した証明ではなく顧客の証言として読むべきだ。

しかし多くのチームにとって、アーキテクチャと実装は明確に分離されていない。一見限定的なコンポーネント作業でも、状態管理の問題やアクセシビリティ上の制約が表面化する可能性がある。モデルルーターには、タスクが日常的な実行からより深い判断へ移行した時点を検出する方法が必要だ。

自動エスカレーションが役立つ場合がある。システムは通常のインターフェース変更をSonnetに任せ、テストの失敗が繰り返された場合や大規模なアーキテクチャ差分が出た場合に、プレミアムモデルへ作業を移すことができる。セキュリティに関わるコードや顧客向けリリースでは、人によるレビューが引き続き必要だ。

同じ考え方は個々の開発者にも当てはまる。迅速に応答する低コストモデルは、使用頻度の低い高順位モデルより、探索に適していることがある。開発者は複数の実装を比較し、それぞれを実行して、最も優れたアプローチを残せる。

このワークフローでは成果物も増える。プロンプト、スクリーンショット、要件、生成されたパッチ、レビューノートは、すぐに追跡しにくくなる。検索可能なエンジニアリング・ナレッジベースは、これらの資料を、それらが支えた意思決定と結び付けて維持できる。

したがって、購入者の問いは変化している。もはや単純に、どのモデルが最高のWebDevスコアを保持しているかではない。チームの実際のワークロード全体で、許容できるコード、予測可能なレビュー負荷、迅速な反復を生み出すモデルの組み合わせはどれか、という問いだ。

Sonnet 5.5は、この計算を変えるためにすべてのベンチマークで勝つ必要はない。プレミアムルーティングが大部分のタスクにおける標準ではなくなるほど十分に優秀になればよい。大幅な世代間の向上を伴う4位という結果は、その閾値を改めて測定する価値を示している。

1,699というスコアが示さないこと

Arenaの結果は有益なシグナルだが、本番環境での信頼性、厳密なデザイン再現性、あるいはモデル支出に対する普遍的なリターンを証明するものではない。

Code Arenaは比較による選好を利用しており、特定の問いに答える。すなわち、ベンチマークの条件下で評価者がどの出力を好むかという問いだ。これは、変更が成熟したコードベースへ安全にマージできるかを問うこととは異なる。

生成されたサイトは、保守性の問題を抱えながら見た目だけ優れていることがある。スタイルの重複、コンポーネント境界の弱体化、依存関係の誤用、アクセシビリティ状態の欠落、未テストのブラウザでの不具合が起きる可能性がある。人間の選好では、隠れた欠陥をすべて見つけられない場合がある。

この特定の結果について、公開投稿は完全なテストセットの内訳も開示していない。読者は発表だけから1,699というスコアを再構成できない。Sonnet 5.5が何件の比較に関与したか、カテゴリごとに不確実性がどのように変動したか、どのプロンプト種別が伸びを牽引したかも確認できない。

評価設計は重要な文脈を提供する。Arenaは、従来のフロントエンド・リーダーボードを超え、実際の開発ワークフローをより適切に表現するため、新しいWebDevシステムを開発した。それでも、公開ベンチマークがすべての非公開リポジトリ、デザインシステム、フレームワーク、デプロイルールを再現することはできない。

順位も相対的なものだ。より強い競合モデルが参入したり、他のスコアへの投票が増えたりするだけで、モデルの根本的な挙動が変わらなくても順位は変わり得る。Arenaのリーダーボード履歴は、2026年を通じて頻繁な追加と手法の更新を示している。

したがって、報告された4位という位置付けは9月29日時点のものとして扱うべきだ。それはその時点の競争環境と利用可能な投票を表している。後日、日付を付けずに順位を繰り返せば、ベンチマークが裏付ける以上の恒久性を示唆することになる。

努力設定も別の不確実性を生む。High effortはより多くの推論を可能にするが、本番システムでは応答時間を制御するためにMediumやLowを使うことがある。チームは、Sonnet 5.5がすべての設定で同じ相対的優位性を保つと想定すべきではない。

混合コストの比較にも同様の注意が必要だ。入力トークンと出力トークンの一般的な組み合わせでは、大規模なキャッシュ済みリポジトリ、短いパッチ、画像入力、反復的なツール呼び出しが中心のワークロードを説明できない。重要なのは、失敗と人間のレビューを含めた、受理されたタスクあたりのコストだ。

Anthropic自身のローンチ資料もベンチマークの限界を認めている。同社は、Sonnetが複数の評価でOpusに近づいたにもかかわらず、複雑でオープンエンドな作業ではOpus 5.5が依然として優位だとしている。この留保は重要である。リーダーボード上の差は、曖昧なプロジェクトでの実務上の差より小さく見えることがあるからだ。

初期の顧客事例にも選択効果が伴う。Anthropicはローンチページに掲載する企業と引用文を選んでいる。テストは厳格かもしれないが、公開された要約には完全なデータセット、失敗事例、独立して再現された結果は含まれていない。

開発チームは、ローカル評価によってこの検証ギャップの一部を埋められる。テストセットには、自社リポジトリで完了したタスクを含め、必要に応じて機密データを除去すべきだ。各モデルには同一の指示、ツール、時間制限を与える必要がある。

レビュー担当者は、見た目の魅力だけでなく測定すべきだ。有用な確認項目には、テスト合格率、ビルド成功率、アクセシビリティ違反、修正ターン数、不必要な変更の規模、レビュー担当者が出力を受理するまでの時間が含まれる。

Reference-Based Designでは、画面サイズをまたいだ画像比較と手動検査が必要になる。シミュレーションには、状態と入力挙動に対する決定論的なチェックが必要だ。ゲームでは、オープニングシーンを超えたランタイムテストが必要になる。

チームはモデルの失敗とエージェントの失敗も分けるべきだ。弱い結果は、ツールの不足、不十分なリポジトリ索引、適切でないブラウザハーネス、重要な制約を省いた指示に起因する可能性がある。周辺システムを修正せずにモデルだけを変えると、誤解を招く結論につながり得る。

セキュリティも別の境界となる。生成されたフロントエンドコードは、認証情報を露出させたり、安全でないレンダリングを導入したり、未検証データを信頼したりする可能性がある。高い選好スコアは、静的解析、依存関係チェック、認証や決済フローのレビューの代わりにはならない。

これらの留保は向上を打ち消すものではない。それらは、結果が実際に裏付ける内容を定義する。Claude Sonnet 5.5は、特にインタラクティブかつ視覚的制約のある作業において、Web開発評価のより強力な候補になった。本番環境への適合性は、コードが実行される環境内でなお実証されなければならない。

Sonnetの台頭はプレミアムと低価格の競合双方に圧力をかける

このモデルは中間層から競争しており、品質ではプレミアムシステムに十分近く、能力では低コストシステムに挑んでいる。

Sonnet 5.5を上回るモデルが最も明確な圧力に直面する。より高いスコアは依然として魅力的だが、購入者は追加の差がプレミアムルーティングを正当化するほど十分な結果の違いを生むか問えるようになった。ベンダーは、総合順位の改善だけでなく、難しいタスクでより強い成果を示す必要がある。

その圧力は、要件がすでに明確な場合に最も大きい。デザイナーが参照を提供し、プロダクトマネージャーが期待状態を定義し、テストが挙動を記述しているなら、生のオープンエンドな判断の重要性は下がる。効率的な実装が中心的な仕事となる。

Sonnetのカテゴリ別の伸びは、Anthropicがまさにワークフローのこの部分を改善したことを示唆している。このモデルは、限定された目標をインタラクティブな結果へ変換する能力が高まったように見える。目標自体が不明確な場合にOpusが依然として強いとしても、これは価値ある位置付けだ。

低コストの競合は異なる課題に直面する。開発者がより多くの再試行、より詳細なプロンプト、より多くの手動修正を必要とするなら、その優位性は弱まる。使用料金が高いモデルでも、望む結果に素早く到達できれば、受理されたタスクあたりのコストは低くなり得る。

これが、スコアあたりのトークン数を示すグラフが出発点にすぎない理由だ。購入者には成果レベルの測定が必要である。関連する分母は、受理されたプルリクエスト、公開済みランディングページ、またはユーザーテストに合格したプロトタイプかもしれない。

オープンモデルは、制御、デプロイの柔軟性、インフラをカスタマイズする選択肢を提供するため、依然として重要だ。これらの利点は選好リーダーボードには十分に現れない。規制対象のチームは、わずかな順位差よりもデータの所在やモデルの所有権を重視する場合がある。

大規模なプロプライエタリモデルにも独自の利点がある。多くの場合、マネージドツール、長文コンテキストのサポート、エンタープライズ制御、統合コーディングエージェントとともに提供される。モデルスコアとその周囲の製品は、異なる形で成果に影響する可能性がある。

したがって、競争環境は多次元的だ。ArenaはWeb開発パフォーマンスの有用な一部を切り出す一方、チームはガバナンス、可用性、速度、コンテキスト処理、統合品質を加味しなければならない。

Claude Sonnet 5.5は、Anthropicに対してもモデルラインアップを明確に差別化し続ける圧力を強める。Sonnetが日常的なコーディングでOpusに近づきすぎれば、顧客はより少ないリクエストにのみOpusを使うようになる。Anthropicは、アーキテクチャ、判断、長期的な信頼性におけるプレミアムモデルの優位性を可視化しなければならない。

それは必ずしも同社にとって問題ではない。明確な2モデルのワークフローは、標準の選択肢をより速く、正当化しやすくすることで、利用を拡大できる。Opusは、ミスが高くつくタスクのエスカレーション経路として残せる。

開発者は、この結果を単一ベンダーへの指令に変えるべきではない。モデル性能は急速に変化し、Arenaのボードには新規参入者が定期的に加わる。出力を比較し、プロバイダーを切り替えられるルーティング層は、すべてのワークフローを1つのモデルに深く結び付けるより安全だ。

競合他社からの最も強力な対応は、別の孤立したベンチマーク主張ではない。同等のツールとレビュー基準の下で、各社のシステムがより多くの受理済み作業を提供するという再現可能な証拠だ。

購入者にとって、当面の機会は証拠に基づく交渉にある。測定済みの社内ワークロードを持つチームは、自分たちの条件でモデルを比較できる。標準モデルを選び、エスカレーションルールを定義し、大規模リリースが最前線を変えた際に判断を見直せる。

Claude Sonnet 5.5のCode Arena結果が重要なのは、その再テストを行う価値が生まれたからだ。SonnetはもはやAnthropicファミリーの単なる経済的なメンバーではない。High effortでは、最前線に近い信頼できるWeb開発の選択肢となった。

4位の意味を示す3つのシグナル

次の検証点は、Sonnet 5.5が順位を維持し、ベンチマーク上の向上を受理されるコードへ転換し、より低い努力設定でも優位性を保てるかどうかだ。

第一に、比較がさらに蓄積するにつれてライブのArenaスコアを注視するべきだ。1,699付近で評価が安定すれば、この上昇が初期サンプルではなく一貫した選好を反映しているという根拠が強まる。急落や大幅に広い不確実性は、その根拠を弱める。

カテゴリ順位も同じく注目に値する。Reference-Based Design、Simulations、Gamingで4位近辺を維持できれば、Anthropicがインタラクティブな視覚開発を改善したという主張を支えられる。以前のモデルの順位へ後退すれば、初期のカテゴリ変動は持続性が低かったことを示すだろう。

第二に、独立した本番評価を注視するべきだ。最も有用な報告は、タスク数、リポジトリ種別、ツール構成、失敗基準、人間によるレビュー手順を開示する。コーディングが良くなったという曖昧な主張が加える情報は少ない。

受理された変更の割合が主な成果指標となるべきだ。ビルド成功と視覚的な類似性は重要だが、チームが最終的に必要とするのは保守・出荷できるコードである。修正ターン、レビュー担当者の時間、不必要な編集は、モデルの速度が運用上の価値へ変換されるかを明らかにする。

第三に、同一タスクで努力設定を比較するべきだ。報告されたArenaの結果はHighで得られたものだが、多くのチームは日常作業ではより高速な設定を好むだろう。Mediumが改善の大半を維持できれば、Sonnetの価値提案は大幅に強まる。

向上がHigh未満で消える場合でも、チームは要求の厳しいフロントエンドタスクにこのモデルを使える。その結果は、より限定的な導入パターンを示すにすぎない。向上が維持されるなら、Sonnetは大量実装におけるより強力な標準モデルとなる。

同じ評価には、少なくとも1つのプレミアムモデルと1つの低コスト競合モデルを含めるべきだ。こうした対照がなければ、チームはSonnet 5からの改善を測定できても、Sonnet 5.5が現在最良の選択肢かどうかは判断できない。

読者は、リーダーボードの順位が変動することも想定すべきだ。Arenaでは2026年を通じて頻繁にモデルが追加されており、4位というスナップショットもすぐに古くなり得る。重要なのは正確な順位ではない。世代的な性能向上の規模と、その到達位置だ。

開発者にとって次の実践的なステップは、焦点を絞ったトライアルである。結果が既知の最近のビジュアル、シミュレーション、インタラクティブなタスクを選定する。一貫した条件下で実行し、すべての修正を記録したうえで、最初のスクリーンショットではなく最終コードを比較する。

技術リーダーにとって、この判断はブランドの好みではなく、ルーティング方針へと変えるべきだ。どのタスクをSonnetにデフォルトで任せるのか、どの失敗をエスカレーションの契機とするのか、そしてどの変更には常に人間のレビューを求めるのか。

Claude Sonnet 5.5のCode Arenaスコアは、その実験を行うに足る信頼できる理由となる。ただし、すべてのチームに対する答えを与えるものではない。開発者が実際に出荷する業務でモデルを試し、受け入れられた成果によって、4位が1位にどれだけ近ければ十分なのかを判断するとよい。