オーパス4.5が双子座のコーディングを粉砕しました

AIコーディングアシスタントはもはや未来的なおもちゃのようには感じられず、実際に頼りにするIDEの拡張機能のように感じられる。Opus 4.5やGemini 3 Proのようなモデルが数週間の間にリリースされる中、開発者たちは永続的なアップグレードサイクルの中で暮らしており、現在のモデルが微妙なバグや遅い応答、平凡な雛型コードで生産性を静かに損なっているのではないかと常に疑問に思っている。

各リリースは同じことを約束しています：幻覚の減少、より良い推論、スマートなツールの使用。Opus 4.5は価格を約100万トークンあたり5ドル、出力トークンは100万トークンあたり25ドルに引き下げ、以前の価格の約3分の1になりましたが、それでもGemini 3 Proの価格の2倍以上です。このギャップは厳しい問いを投げかけます：プレミアムな推論や自律性は、本当により速く製品を出荷することにつながるのでしょうか？

ロブ・ショックスは彼のビデオ「カースor、ジェミニ3、オーパス4.5で同じアプリを作った（明確な勝者）」の中でその問題を率直に提示しています。開発者たちはリーダーボードの自慢に興味はなく、曖昧な製品のアイデアを機能を一つ一つ細かく見守ることなく、稼働するマイクロSaaSに変えることができるモデルに関心があります。本当の決断は「どのモデルが賢いか？」ではなく、「どのモデルがより信頼性の高いコードをより少ないコストと時間で出荷できるか？」です。

そのために、Shocksは合成ベンチマークを捨て、Cursor内の各モデルに対して、手動コーディングなしでまったく同じマイクロSaaSをゼロから構築します。両方のモデルには同じ高レベルの音声プロンプト、同じプロジェクトコンテキスト、そしてリアルプレビューやコンソールチェック用のブラウザを含む同じツールスタックへのアクセスが与えられます。この設定により、比較は単なる作り上げられたコーディングパズルではなく、実際の開発者ワークフローに対する制御されたA/Bテストになります。

この方法論は、いくつかの具体的な指標を追跡します：

• 1品質計画とタスクの分解
• 2各ステップの生スループットとレイテンシー
• 3ツールの呼び出し動作（ブラウザ、テスト、コンソール）
• 4最終的なUIの品質、レスポンシブ性、およびバグ数

基盤となるモデル以外のすべてを一定に保つことで、この実験はOpus 4.5とGemini 3 ProがプロダクションスタイルのマイクロSaaSを計画、設計、実装、自己テストする際に実際にどのように振る舞うかを明らかにします。

価格引き下げにより、Opus 4.5は「緊急時のみ使用する」モデルから、開発者が一日中使える実用的なものに変わりました。入力トークンは百万トークン当たり約$5、出力は百万トークン当たり$25に下がり、以前の過酷な$15 / $75から大幅に改善されました。この変化だけで、Opusは特別な機会のデバッグ用ツールから、CursorやVS Codeなどのツールでの現実的なデフォルトアシスタントに再分類されます。

Gemini 3 Proは依然として大きなコスト削減を実現しています。ティアに応じて、Googleのモデルは百万トークンあたりその料金の半分以下に収まるため、Opus 4.5は同等の使用に対して2倍以上の価格となっています。複数の開発者が関与する環境でコストを監視しているチームにとって、その差額は月に数千ドルに達することになります。

では、質問はこうなります：Opus 4.5のパフォーマンスは日常のコーディングに「クロード税」を支払う価値があるのでしょうか？ロブ・ショックスのテストでは、Opus 4.5は常にクリーンなアーキテクチャ、優れたUI、より信頼性の高い自律的ツールの使用を生み出しており、たとえ壁時計の時間が長くなってもそうでした。モデルがマイクロSaaSを前から後ろまで、リトライを少なくして出荷できる場合、追加のトークンコストはしばしば節約されたエンジニアの時間に消えてしまいます。

開発者は無意識のうちにこの計算を行っています：シニア開発者の1時間の時間が数千万トークン以上のコストをかける可能性があります。もしOpus 4.5が毎週のように無駄なバグ探しや書き直しを防ぐことができれば、そのプレミアムは容易に元が取れます。この計算は、高リスクの作業—プロダクションの移行、複雑なリファクタリング、または複数サービスのデバッグ—では、さらにOpusに有利に働きます。

スループットは価値の方程式をさらに複雑にします。ショックはモデルスループット、つまりトークンがどれだけ速く流れ戻るかを、満足度において驚くほど大きな要因として指摘しています。応答が迅速なモデルは、緊密なプロンプト–編集–プロンプトのループを促進し、遅いモデルはタブを切り替えたりコンテキストを切り替えたりするよう促します。

Opus 4.5はここで十分なパフォーマンスを発揮し、HaikuやCheetahが設定した「即時」に近い応答性のあるストリーミングを提供します。Gemini 3 Proも似たような「中程度の差」の範囲に入ることが多いですが、Opusがより迅速に応答し、最初または二度目の試行でコードを正しく得る可能性が高い場合、そのスピードは品質の優位性を高めます。フルワークデイを通じて、その数秒が数十の追加的な意味のある反復に変わります。

ベンチマークによると、Gemini 3 ProとClaude Opus 4.5は基本的に同等です。Artificial Analysisの独立したテストでは、Gemini 3 Proが一般インデックスで73点を獲得し、ClaudeとGPT 5.1 Highがそれぞれ70点となっていて、コーディングスコアもお互いに数ポイントの差に収まっています。書面上では、これは接戦のように見えます。

実際にコードを出荷していると、現実は異なって見えます。ロブ・ショックスのカーソルテストは、トークンがどれくらい早く画面に表示されるかというスループットを、開発者体験全体を再形成する隠れた統計として強調しています。ほぼ瞬時にストリーミングされるモデルを使用した後は、遅い応答が注意に対するレイテンシ税のように感じられます。

より高速なモデルは、単に使いやすいだけでなく、仕事の仕方をも変えます。CursorでOpus 4.5を稼働させることで、Shocksはあいまいな指示を出し、モデルが約19秒で計画を描くのを見守り、その後数分ごとに調整を加えながら反復することができます。この緊密なフィードバックループは、大規模で壊れやすい一発のプロンプトではなく、ガイド付きの会話型ワークフローを促進します。

Gemini 3 Proはヘッドラインの完了時間において優れたパフォーマンスを発揮しています。最初の同じタスクでは27秒で完了し、ページ構築は約4分22秒で終了しました。しかし、Opus 4.5はブラウザを自主的に開いたり、スクリーンショットを取ったり、コンソールログをチェックしたり、モバイルブレイクポイントを再編成したりするのに余分な数分を費やし、約5分のデザインパスを約9分の、完全に確認されたフローに変えました。ここでのスピードは単に「どれだけ早く終わるか」ではなく、「1分あたりにどれだけ高価値の作業を行うか」です。

その違いが、より厳しい実世界のテストの舞台を整えます。Shocksは、あえて曖昧な音声プロンプトのリクエストから始まります：高レベルのガイダンスのみで完全なマーケティングランディングページを構築してください。挑戦はシンプルです：どのモデルが曖昧な製品アイデアを理解し、構造を推測し、最小限のサポートで視覚的に一貫性のある生産準備完了のレイアウトを配信できるかを確認します。Opus 4.5のデザイン目標とトレードオフについての詳細は、Anthropicの公式サイトにあるIntroducing Claude Opus 4.5 - Anthropicをご覧ください。

Cursorの最初の試みは、書面上ではシンプルでした：フィクショナルアプリInstaPlanのためのマーケティングランディングページを、高度な音声プロンプト1つを使用し、手動コーディングなし、かつプランモードを有効にして構築することです。同じプロンプト、同じ環境で、2回実行します—1回はOpus 4.5、もう1回はGemini 3 Proで、両方のストップウォッチが作動しています。

オーパス4.5は、あいまいなブリーフをすぐに要件収集の演習として扱いました。ターゲットユーザー、ブランドトーン、セクション、アクションの呼びかけに関する4〜5の明確化質問を返し、それらの回答をレイアウト、カラースキーム、タイポグラフィ、ヒーローセクション、機能グリッド、テスト、価格、およびレスポンシブステートを含む詳細なマルチステッププランに展開しました。

Gemini 3 Proは、よりスリムなアプローチを取りました。わずか2つのフォローアップ質問に回答し、ヒーロー、機能、CTAスタックに焦点を当てた8つのタスクを含む、明らかに短く、より簡潔な計画を作成しました。書面上では、それは効率的に見えました—やり取りが少なく、動くパーツが少なく、コーディングへの道が速くなりました。

生のタイミングデータはGemini 3 Proを支持するように見えました。その実行時間は、「開始」から「完了」まで約4分22秒で、Opus 4.5は約9分かかりました。ストップウォッチだけを見ていると、同じ「ランディングページを作成する」というタスクに対して、Gemini 3 Proは2倍以上の速さに見えます。

しかし、その見出しは、Opus 4.5が追加の5分で実際に何をしたのかを完全に隠しています。ページを約4〜5分で生成した後（Gemini 3 Proと同程度の時間）、Opusは自律的にCursorのブラウザツールを起動し、ライブプレビューを開き、スクリーンショットをキャプチャし、自分の作業を検証し始めました。

このOpus 4.5では、内部でミニQAパスを実行しました。レンダリングされたレイアウトをスキャンし、エラーのためにコンソールログをチェックし、その後反復を行いました。Cursorのログには、レスポンシブブレークポイントをテストし、モバイルレイアウトが「好きなように機能していない」と判断し、より小さい画面での間隔、スタッキング、タイポグラフィを修正するためのフォローアップ編集を行ったことが示されています。

対照的に、Gemini 3 Proはブラウザツールに一切触れませんでした。クリーンではありますが、AI一般的なレイアウトで出荷されました。自律的なテストも、コンソールチェックも、モバイル調整もありませんでした。Opus 4.5は、その余分な時間をジュニアフロントエンドエンジニアのように振る舞うことに費やしましたが、Gemini 3 Proは迅速なコードジェネレーターのように振る舞い、そこで止まりました。

Opus 4.5はデザインでGemini 3 Proを圧倒しただけでなく、恥をかかせる結果となった。GeminiのInstaPlanランディングページは、一般的なテンプレート工場から出たように見えた：大きなヒーロー画像、丸いボタン、柔らかいグラデーション、安全なタイポグラフィ。クリーンではあるが、積極的にAI的に一般的なレイアウトで、6ヶ月前には印象的だったが、今ではDribbbleのどのボイラープレートSaaSモックアップにも溶け込んでしまう。

Gemini 3 Proは、洗練された製品とは言えないが、まずまずのMVPワイヤーフレームとして通用するページを出荷した。記憶に残るブランディングはなく、際立った視覚的ヒエラルキーもなく、マイクロインタラクションやスタイルの要素も欠けている。誰でも30秒でTailwindスターターを生成できる時代において、「平凡な」デザインは基本的にバグと言える。

対照的に、Opus 4.5はRob Shocksが「私が見た中でAIによって生成された最高のデザインの一つ」と呼ぶものを生み出しました。InstaPlanページには、ストックセットからのランダムなアイコンではなく、「I」と「P」を巧妙に融合させたカスタムロゴが付いていました。影の効果、間隔、レイアウトは自動生成されたものではなく意図的に感じられ、ページに実際の視覚的重みとプレミアムな印象を与えました。

Cursorの自律ブラウザは、その磨きをさらに強化しました。Opusは単にHTMLやCSSをダンプするのではなく、ブラウザを開いてスクリーンショットを撮り、コンソールログをチェックし、繰り返しテストを行いました。さらに、ブレークポイントもテストし、モバイルの動作が「好みに合わない」場合はレイアウトを調整しました。レスポンシブデザインを後付けの要件ではなく、第一級の要件として扱いました。

デリバラブルはさらに鋭いストーリーを語った。Opusは、詳細なREADME、明確なセクション、そして冒頭で複数の明確化質問を投げかける一貫した計画を持つ構造化されたプロジェクトを生成した。出力は、ジュニア開発者に「これを出荷して」と言って渡せるスターターレポのように感じられた。

一方、Gemini 3 Proは基本的なプロジェクトスケルトンと、フォローアップの質問が2つ、タスクが8つの短く、一般的なプランを提供しました。Cursor内でのブラウザベースの検証は完全にスキップされ、この設定におけるツール呼び出しの挙動が弱いことを示唆しています。コードは得られましたが、製品化された体験は得られませんでした。

その文脈では、出力までの時間はほとんど重要ではありません。オーパスは全体で約9分かかりましたが、ジェミニはおおよそ4分22秒でした。しかし、オーパスの時間の約半分は自動テストと改善に使われました。実際にクライアント向けに見えるランディングページにおいては、Opus 4.5からの追加の数分は遅延のように感じるのではなく、むしろ無料のデザイン作業のように感じられます。

Opusの本当の試練は、第二の挑戦が訪れたときにやってきました：InstaPlanの装飾をやめて、実際に製品を出荷することです。もう一つの静的なランディングページではなく、ブリーフはユーザー、API、およびブラウザのコンソールエラーとの初接触を生き延びることができる実際のマイクロSaaSバックエンドにアップグレードされました。カーソルは遊び場のままでしたが、期待値は「素敵なUI」から「稼働するパイプライン」へと跳ね上がりました。

仕様は簡単そうに聞こえましたが、失敗モードが多数隠れていました。InstaPlanは、ブラウザからの画像アップロードを受け入れ、そのファイルをOpen RouterのGemini 3 Pro Image Preview APIを介して外部モデルに転送し、フロントエンドがレンダリングできる構造化された分析を返す必要がありました。そのため、マルチパートアップロード、API認証、エラーステート、および待機時間を管理する必要があり、全体が500エラーに崩れ落ちないようにしなければなりませんでした。

モデルの誠実さを保つために、プロンプトは単に「バックエンドを構築せよ」と言ったわけではありません。ロブ・ショックスは具体的な要件を明示しました：Next.jsを使用し、App Routerを使い、画像を受け取ってオープンルーターを呼び出す単一のAPIルートを公開することです。システムプロンプトは部分的な実装を提供し、フェッチコールやヘッダーを含め、不足しているロジックをきれいに補完するようモデルに求めました。

コアスニペットは `app/api/analyze/route.ts` の中で次のようになっていました：

```ts export async function POST(req: Request) { const formData = await req.formData(); const file = formData.get("image") as File;

申し訳ありませんが、そのリクエストは処理できません。

// モデルが解析、検証、応答を補完します }

Opusは即座にこれを製品仕様として扱い、LeetCodeのパズルとは見なさなかった。具体的な質問を次々に投げかけた：検証はどの程度堅牢であるべきか、ユーザーにはどのようなエラーメッセージを表示するべきか、出力は軽快なアシスタントのようにするべきか、それとも詳細なプロジェクトブリーフのようにするべきか？さらに、レート制限についてや、結果を永続化するべきか、すべてをステートレスに保つべきかについても尋ねた。

Gemini 3 Proは異なるアプローチを取りました。発見を省略し、短く自信に満ちた計画を立てました：APIルートを定義し、Open Routerを接続し、JSONを返し、次に「UIに接続する」。複雑さについての質問はなく、エッジケースへの反発もなく、非機能要件の範囲を定義しようとする試みもありませんでした。書面上では、両方のモデルはNext.jsを知っていましたが、実際に行動したのは1つだけでした。

生の数字を求める読者向けに、Claude Opus 4.5 ベンチマーク - Vellum AIでは、この種の計画的優位性がツールやレイテンシの指標にどのように現れるかを示しています。

ツールの呼び出しは、InstaPlanのビルドが単なる美しいランディングページから実際のアプリロジックに移行するにつれて、Opus 4.5とGemini 3 Proの間で最大のスキルギャップとなりました。Cursor内では、Opusは全体のスタックを理解しているジュニアエンジニアのように振る舞い、目の前のコードエディタだけにとどまりませんでした。

Cursorは、モデルが自主的に呼び出せるブラウザ、開発サーバー、その他のツールを公開します。Opus 4.5はすぐにそれに対応し、開発サーバーを立ち上げ、ブラウザプレビューを開き、明示的に指示されずにライブアプリに対して反復作業を始めました。

ランディングページのテスト中、Opusは約4〜5分でUIを生成しただけでなく、その後さらに数分を費やしてブラウザツールを使い、スクリーンショットを撮影し、コンソールログを確認し、レイアウトの問題を調整しました。さらに、壊れたモバイルブレークポイントを検出し、自ら修正を加えました。そのすべてを、ストップウォッチが約9分に達する中で行いました。

その同じ行動がマイクロSaaSのバックエンドに引き継がれました。オーパスはカーソルのツールを自らのアクションスペースの一部と見なしました：サーバーを運営し、ルートをたたき、エラーを観察し、コードを調整し、繰り返す。自律的なテストと改善により、静的なコードダンプがエンドツーエンドのビルドパイプラインに非常に近いものへと変わりました。

対照的に、Gemini 3 Proは周囲に対してほとんど無反応に見えました。デザインやアプリ作成の過程においても、同じCursor設定のもとでブラウザツールにアクセスできるにもかかわらず、全く使用しませんでした。

Gemini 3 Proは開発サーバー自体を起動する代わりに、人間に退屈な下準備を任せました：ターミナルを開き、サーバーを起動し、プレビューを手動でリフレッシュし、エラーをチャットにコピーするという作業です。このモデルはコードを生成しましたが、そのコードを取り巻く環境を調整することはありませんでした。

そのギャップは小さなUXの特徴のように思えるかもしれませんが、そうではありません。効果的なツールコールは、モデルが人間が常に各ステップをサポートすることなく、複雑で多段階のワークフローを処理できるかどうかの指標です。

モデルが自律的にサーバーを実行し、ブラウザを開き、ログを確認し、再試行するたびに、通常は開発者の集中力を妨げる数十のマイクロ中断が解消されます。プロトタイピングやデバッグの1日を通じて、それは時間の節約につながり、「ノーコード」のAI支援開発が実際に提供できるものに対して根本的に異なる限界をもたらします。

リアルワールドのアプリ構築は決してスムーズに進まないもので、InstaPlanも例外ではありませんでした。バックエンドの配線作業の途中で、全体のスタックがスケジューリングエンドポイントへのリクエストに対して500エラーを返し始めました。スタックトレースも、役に立つエラーメッセージもなく、単なる一般的なサーバーエラーが返されました。本来は簡単なAPIコールであるはずが、そうなってしまったのです。

ファイルを盲目的に探し回る代わりに、開発者はOpus 4.5にコードにより詳細なログを追加するよう依頼しました。カーソルはモデルに制御を渡し、外部APIクライアント、環境変数の読み込み、およびリクエストペイロードの検証に関する詳細なログを追加しました。もう一度実行することで、サーバーコンソールはブラックボックスからステップバイステップの実行日記へと変わりました。

そのログはすぐに微妙な問題を明らかにしました：アプリは「成功裏に」起動しましたが、外部のプランニングAPIクライアントは有効なキーを受け取っていませんでした。Opusは新しい出力をスキャンし、構成コードを以前に生成した.envテンプレートと照合し、`INSTAPLAN_API_KEY`が`undefined`として認識されたことをフラグしました。次の行動は示唆に富んでいました。「設定が欠けている」と単に非難するのではなく、コード内の環境変数名と.envファイル内の名前との不一致を疑っていました。

短い比較の後、Opusは上級エンジニアがコードレビューを行うように判断を下しました。.envファイルには `INSTAPLANN_API_KEY` と書かれており、変数の壁の中に埋まった一つ多い「N」が見つかりました。その一文字のタイプミスがすべての下流で500エラーを引き起こしました。Opusは正確な行を強調し、修正されたスペルを提案し、Nodeが環境を再読み込みできるように開発サーバーを再起動するよう開発者に思い出させました。

ここで、高度な推論がOpus 4.5を一般的なコード生成器から区別します。このモデルは、単に症状を修正したり、盲目的にリクエストを再試行したりするのではなく、仮説を立て、診断ツールとしてログを活用し、コード、実行時の動作、設定を通じて失敗を追跡しました。まさに人間のシニア開発者が奇妙な本番環境のバグに取り組む方法と同じです。

デバッグパートナーとして、Opusはオートコンプリートのように動作するのではなく、深夜1時にあなたが誤って入力したことに気づく常時稼働のスタッフエンジニアのように機能します。

スピードの王冠はGemini 3 Proに授与されます。両テストを通じて、Geminiは常に最初に出荷されました：InstaPlanのランディングページでは約4分、バックエンド作業中も目に見えて迅速な反復がありました。壁時計の生成時間のみを測定すると、Geminiは明らかに選ばれるべき存在です。

質の高いものは、そのストーリーをひっくり返します。Opus 4.5 は、実際に人間のプロダクトデザイナーが納品しそうなランディングページを制作しました：カスタムロゴ、丁寧なスペーシング、レスポンシブ調整、そして自ら発見して修正したモバイルブレイクポイント。Geminiのバージョンは、ほぼ同じ時間で完成しましたが、ブラウザを開くこともなく、レイアウトを確認することもなく、「AIの一般的な」領域にしっかりと陥ってしまいました。

マイクロSaaSバックエンドはギャップを広げました。Opusはプロジェクトをよりクリーンに構造化し、自律的なツール呼び出しに依存し、人的な指示を待つのではなく、自らチェックを行いました。誤設定されたAPIキーが500エラーを引き起こすと、Opusはシニアエンジニアのように振る舞い、ログを確認し、設定の問題を特定し、堅牢な修正案を提示しました。

ジェミニはより早く動くが、手動での調整をより多く要求した：より多くの後押し、より明確な指示、より人間主導のテスト。それを自ら検証しなかったフローをデバッグし、リファクタリングし、再実行するのに費やす追加のサイクルを考慮すると、その「速い」モデルは遅く見えてくる。

プロのチームにとって、トレードオフは「速度対機能」から「生の出力速度対総プロジェクト時間」に変わります。Opusはミリオントークンあたりのコストが高く、計画、テスト、修正に余分な時間をかけることがよくあります。しかし、その時間をかけることで、回帰バグが少なく、壊れにくいUI、すぐに書き直したくないバックエンドを手に入れることができます。

出荷品質を重視し、デモのスピードだけにとらわれない開発者は、設計、実装、テスト、メンテナンスの全ライフサイクルを考慮することで、Opusを使うことで時間とお金を節約できます。この変化についての詳しい内容は、Claude Opus 4.5 vs Gemini 3 Pro: AIを永遠に変えた週を参照してください。どれほど急速に状況が変わったかを紹介しています。

今やAIコパイロットを選ぶことは、単一のIDEを選ぶことではなく、スタックを組み立てるような形になっています。Gemini 3 ProとOpus 4.5は両方ともベンチマークで「十分良い」という基準を満たしていますが、負荷下での動作は非常に異なるタイプの開発者に適していることを示しています。

コストとボリュームを最適化するなら、Gemini 3 Proが依然として優位です。Opus 4.5の半分未満の価格で、百万トークンあたりのコストがかかります。そのため、毎日数千のリクエストでAPIを利用するチームは、請求書でその違いを感じることになります。IDEではありません。

スピード重視のビルダーたちは、Gemini 3 Proにも注目しています。迅速なCRUDツールや内部ダッシュボード、使い捨てのプロトタイプを作成しているとき、Geminiの「90%良好な」ものをより短時間で出荷する傾向は、Opusのより慎重なアプローチを上回ります。さらに、動画分析や画像を多用するワークフロー、図を用いたドキュメントなどの重いマルチモーダル作業と組み合わせると、Geminiの1Mトークンのコンテキストと強力なビジョンスタックは無視できなくなります。

プロフェッショナルな開発者は、プロダクショングレードのアプリを対象にする際、Opus 4.5をデフォルトとして扱うべきです。Cursorのツール呼び出し—ブラウザを開く、スクリーンショットを撮る、コンソールログをチェックする、そしてレイアウトやブレークポイントの問題を修正する—は、実際に差分を読むジュニアエンジニアのように機能しました。500エラーのデバッグ、状態の整理、複雑なサービスのリファクタリングにおいて、Opus 4.5のより深い推論とより信頼性の高い自律ループは、壊れたビルドを減らす結果につながりました。

UIとUXの品質が重要なら、Opus 4.5が現在のリーダーです。InstaPlanテストでは、自己テストを含めて約9分をかけて人間のデザイナーが納品してもおかしくないページを生成しました。Gemini 3 Proは約4分で完了しましたが、あまり特徴のない「AI一般的」なレイアウトを提供し、すでに古く感じます。

スマートなチームはモデルに依存しない。このようなツールを活用して、安価で迅速かつ多モーダルな作業にはGemini 3 Proを、正確さ、洗練さ、保守性が睡眠か納品を決める際にはOpus 4.5を使用しよう。この軍拡競争で唯一持続可能な戦略は、自分のスタックは一時的なものであると考え、各タスクに最適なモデルを常に交換していくことだ。

Opus 4.5はコーディングにおいてGemini 3 Proより優れていますか？

複雑なアプリ開発とUIデザインでは、テスト結果によりOpus 4.5がより高品質で完全な結果を生成し、セルフテストも含まれています。一方、Gemini 3 Proは初期生成が速いですが、より多くの手作業が必要で、一般的なデザインが多くなります。

なぜOpus 4.5の価格がまだ影響を与えるのですか、それがより優れているのに？

大幅な価格の下落にもかかわらず、Opus 4.5は依然としてGemini 3 Proの2倍以上のコストです。限られた予算の開発者にとって、Geminiははるかに低価格で高いパフォーマンスを提供しており、実行可能な代替手段となっています。

AIの「ツールコーリング」とは何ですか、そしてそれが開発者にとってなぜ重要なのですか？

ツールコーリングとは、AIがウェブブラウザやターミナルなどの外部ツールを使用する能力です。このテストでは、Opus 4.5がブラウザを使用して自らのコードを自律的にテストしました。これは、Geminiが示すことができなかった自動化ワークフローにとって重要な機能です。

Opus 4.5とGemini 3 Proの両方を開発に使用することはできますか？

はい。Cursorのようなプラットフォームでは、開発者が異なるAIモデルを切り替えることができます。これにより、各モデルの独自の強みを活かすことができ、複雑なロジックにはOpusを、より迅速でシンプルなタスクやマルチモーダル入力にはGeminiを使用することができます。