クロード4.5の衝撃的なコーディングテスト

AIのハイプサイクルは早く動き、Claude Opus 4.5は全速力で登場します。Anthropicは、新しいClaude Opusモデルがコード生成リーダーボードから長文理解テストまでのベンチマークを制覇したと主張し、真剣なソフトウェア作業のための「フロンティア」システムとして位置づけています。チャートはプロダクトローンチブログでは素晴らしく見えますが、商品を出荷するわけではありません。

開発者にとって、実際に重要な指標は1つだけです。それは、このモデルが前のモデルよりも機能のリリースをより早く安全に行えるかどうかです。もしツールが編集回数、ロールバック、そして「なぜこれは本番環境で壊れているのか？」という瞬間を減らすことができないのであれば、ベンチマークスコアは単なる雑学に過ぎません。唯一重要なスコアボードは、gitの履歴とインシデントログの中に存在します。

それを試すには、作られたLeetCodeのパズルやおもちゃのCRUDアプリ以上のものが必要です。実際の製品の中でのリアルなコーディングワークフローが必要です。そこには、混乱したレガシーコード、半分しか文書化されていないコンポーネント、実装の途中で変更されるUX要件が含まれています。そこでこそ、Claude Opus 4.5がその話題に値するのか、それともリーダーボードでの勝利と日常のエンジニアリングの現実とのギャップを明らかにするのかが問われます。

テストベッドはComposaloで、すでに有料ユーザーがいて、決して簡単ではないコードベースを持つ本番のウェブアプリです。設定は、Opus 4.5をCursorと端末ベースのクラウドコードで実行し、すべてを本番環境で維持し、AIが単なるコード自動補完ではなく、優秀なペアプログラマーのように振る舞えるかを確認します。選りすぐりのグリーンフィールドプロジェクトや、 sanitization されたリポジトリは使用しません。

ワークフローは、難易度が上がる3つの具体的なタスクに中心を置いています。まずは、シンプルなUI調整です：ノードツールバーにインタラクションモードボタンを追加し、ユーザーが埋め込まれた画面をダブルクリックしてスクロールできることを理解できるようにします。完全にフロントエンドで、スコープは小さく、Opusが既存のコンポーネントを読み取り、特性を損なうことなく機能を通すことができるかをテストするのに最適です。

次に登場するのは、中程度の難易度を持つ機能です。データベースに基づいた「重複ノード」アクションで、ノードをコピーし、正しいデータを保持し、新しいIDを生成し、プロンプトの履歴や古いバージョンを引きずらないようにします。最後に、複雑なストリーミングUIの動作がモデルをマルチファイルの推論、状態管理、エッジケース処理に押し込むことになります。ベンチマークによれば、Claude Opus 4.5はこれに対応できるとのことですが、現実がそれを決定します。

プランモードは、全体のワークフローを静かに実行します。クロード・オーパスがコードの一行にも触れる前に、モリッツはプランモードに入り、何を望んでいるのかを説明します：機能がどこに存在するか、どのように動作するか、どのコンポーネントに影響を与えるか。その前もっての説明が、モデルを自動補完の強化版から、仕様を受け取るジュニアエンジニアに近いものに変えます。

クロードオーパスは、その後、巧妙に強力なことを行います。それは仕様を検証することです。「どのアイコンを好みますか？」や「ボタンの位置はどこにすべきですか？」といった質問は一見些細に思えますが、再作業の全クラスを排除します。ユーザーインターフェースの決定を幻覚するのではなく、モデルはカーソルポインターアイコンの詳細、プレビューボタンの後ろの配置、あるいは重複ノードがタイトルを調整すべきかどうかを明確にします。

その明確化する質問は、不一致の意図に対するガードレールとして機能します。モリッツは、ボタンが間違ったツールバーに入ったり、重複ロジックが誤ったバージョン履歴をコピーしたりすることを発見するために待ちません。彼は一握りの具体的なプロンプトに答え、その制約をコードベースに触れる前にクロード・オーパスが計画に組み込みます。

簡単なUIの微調整には、クラウドコード内での軽いやり取りで十分です。モリッツはプランモードのままで、ファイルリスト—ノードツールバー、ウェブアプリノード、ボタンスタイリング—を承認し、その後自動的に編集を受け入れます。その結果、動作するインタラクショントグル、正しいカーソルの挙動、外部クリック時の無効化などのエッジケース処理が、すべて初回の実行で実現されます。

複雑な機能はワークフローをより重いギアに切り替えます。データベースの書き込み、Supabaseスキーマ、またはマルチバージョンロジックが関与すると、モリッツはクロード・オーパスに別の計画書を生成するよう依頼します。その文書には合意された動作が記録されます：どのフィールドを複製し、どれをスキップするか（プロンプト履歴、バージョン）、および「ユーザーが現在表示しているバージョンのみを複製する」といったルールが含まれます。

その計画文書は耐久性のある遺物となります。モリッツは：

• 1新しいClaude Opusセッションで再利用してください。
• 2作曲家のようなより高速なモデルに渡してください。
• 3数週間後に再訪して、なぜ特定の実装がそのように動作するのかを理解してください。

壊れやすいチャット履歴に依存するのではなく、ワークフローはコンテキストのリセット、モデルの交換、そして人間の再考を乗り越える安定した実装パスを構築します。

コンテンツとインタラクションするためのシンプルなコントロールを追加することは、現代のコーディングモデルなら誰でも簡単にできるはずです。この最初の機能では、クロード・オーパスがComposaloのノードツールバーに新しいボタンを追加し、ユーザーが隠れたダブルクリックジェスチャーを通じて発見するのではなく、埋め込まれた画面のインタラクションモードを明示的に切り替えられるようにしました。

モリッツは計画モードに入り、変更内容を説明します。それは、プレビュー ボタンの後に配置された `NodeToolbar` のアイコンのみの新しいボタンで、`WebAppNode` iframe のインタラクション モードを切り替えます。オーパスはすぐに2つの主要なコンポーネント、UIのための `NodeToolbar` と iframe の動作のための `WebAppNode` を特定し、これらのファイルに限定された編集を提案します。無駄なリファクタリングや無関係なモジュールへの逸脱はありません。

実装は一度のパスで実行されます。Opusはツールバーボタンを追加し、それを既存のダブルクリックインタラクションロジックに接続し、アクティブ状態を明確に示すようにスタイリングを更新します。「埋め込まれたアプリと対話しています」というメッセージが伝わるようにします。モリッツはローカル開発サーバーを起動し、新しい「コンテンツと対話する」ボタンをクリックすると、iframe上でカーソルが手の形に変わり、スクロールとインタラクションが期待通りに動作するのを確認します。

次に、スクリプトなしの部分が登場します。ユーザーがノードの外をクリックすると、Claude Opusは自動的にインタラクションモードを無効にするロジックを実装します。iframeの外をクリックするとモードがオフになり、カーソルと動作が通常に戻ります。モリッツは、これはSonnetや他のモデルが簡単に見落とす可能性のあるエッジケースの処理だと指摘しています。

その追加の動作により、Opusは「強化版オートコンプリート」の範疇を超え、ユーザーエクスペリエンスの落とし穴を予測するジュニアエンジニアに近い存在になります。単に指示に従うだけでなく、粘着的なインタラクションモードがユーザーを混乱させると推測し、静かにそれを修正します。Anthropicは、Introducing Claude Opus 4.5 - Anthropicにおけるモデルの提案において、このような「先行的推論」に重点を置いており、ここでは非常に実用的で、実用化可能な形でそれが現れています。

エッジケースは通常、スプリントの終わりに現れます。QAテスターが「すべきでない」場所をクリックすると、すべてが崩れてしまいます。ここで、クロード・オーパスはそのケースの一つを前もって静かに処理しました。モリッツが新しい「コンテンツとインタラクトする」モードの外をクリックしたとき、機能は自動的に無効になりました。誰もその動作を求めてはいませんでしたが、モデルはそれを組み込みました。

その小さな詳細が重要です。決してオフにならない粘着性のあるインタラクションモードは、出荷され、ユーザーをイライラさせ、バグレポートやホットフィックスに時間を浪費させる、まさにUXの足枷です。Opusはデフォルトで外をクリックして閉じるパターンを採用することで、モーダル、ドロップダウン、ポップオーバーで使用される馴染みのあるウェブのイディオムと一致しました。

コードよりも興味深いのは、それに組み込まれたプロダクト思考です。モリッツはインタラクションを切り替えるボタンを要求しただけで、フォーカスが他の場所に移ったときに何が起こるべきかは明言しませんでした。オーパスはその機能の妥当なライフサイクルを推測しました：クリックまたはダブルクリックでアクティブにし、カーソルの変化でモードを視覚的に示し、ユーザーが他の場所をクリックしたときにスムーズに終了します。

そのような予測的行動は、Anthropicが最先端モデルにおける改善された推論について語る際に意味するものです。これは単なるReactスニペットのパターンマッチングではなく、ユーザーの意図や失敗モードをモデル化し、それらの仮定を実装に組み込むことです。「シンプルな」UIの調整であっても、Opusは状態、フォーカス、逃げ道について推論したのです。

このような小さなエッジは、実際のコーディングワークフローにおいて、実際の時間節約につながります。見逃したエッジケースは、通常、少なくとも1回の追加ループを必要とします： - バグを発見するための手動テスト - モデルに文脈を再説明する - パッチを再生成し、アプリを再実行する

各機能ごとにそれらのループを2〜3回避することは、開発の一週間で数時間の時間を取り戻すことにつながります。モリッツはツールチップのコピー編集を除いて実装にはほとんど手を付けませんでした; 彼はインタラクションの分解を指定したり、イベントリスナーを追加したり、奇妙なスタック状態を追いかける必要はありませんでした。

数十の機能にわたって拡張されると、その動作は「コードの自動補完」というよりも、エディタに組み込まれたジュニアプロダクトエンジニアのように見え始めます。完璧ではなく、全知でもありませんが、実際のユーザーが画面をどのようにクリックするかについて考える能力が高まっています。

中程度の難易度は、一見単純な要求で訪れました。それはノードの複製ボタンで、React UIとバックエンドのデータベースの両方に関わるものでした。モリッツはこれをノードツールバーのアクションドロップダウンに組み込み、既存のアクションと並んで配置し、キャンバス上に現在のノードのコピーをインラインで生成することを望んでいました。モックデータなし、クライアント側のハックなし—これは本物の永続化レイヤーにアクセスしなければなりませんでした。

彼がClaude Opus 4.5に与えたプロンプトは非常に具体的でした。このモデルはノードデータをクローンし、新しいUUIDを生成し、状態の特定のカテゴリをスキップする必要がありました：プロンプトの履歴なし、古いバージョンなし、古いコンテキストを偶然引きずるような隠れたメタデータなしです。また、ユーザーがサイクルできる別々の「バージョン」として編集が積み重なるComposaloのバージョン管理モデルを尊重する必要がありました。

Opus 4.5は、すべての列を単純にコピーするのではなく、最小の重複セットを推測しました。タイトル、コンテンツ、レイアウト、タイプなどの重要なノードフィールドは保持し、履歴テーブルやバージョンレコードは省略しました。表示されるラベルには、タイトルに「copy」のサフィックスを追加し、「Landing Page v2」は「Landing Page v2 (copy)」のような形になります。これは、密なキャンバス内での混乱を軽減する小さなUXの詳細です。

データベース側では、モデルがオリジナルのIDを再利用したり手動で調整したりするのではなく、新しいUUIDを持つ適切な挿入を行いました。このステップは一見簡単に思えますが、多くのAI生成のパッチが失敗するのはまさにこの部分で、IDが衝突したり、オリジナルの行が変異したり、外部キー関係を忘れたりします。ここで、Opus 4.5は通常のUIを通じて作成された他のノードのように振る舞うクリーンな新しい行を作成しました。

フローは複数の層にわたっていました：ツールバーボタン、クリックハンドラー、API呼び出し、データベース書き込み、そしてUIの更新。Opus 4.5はこれらの要素を一貫して保ち、Reactコンポーネントからバックエンドへ正しいノード識別子を渡し、フロントエンドが元のノードの「すぐ隣に」新しく作成されたノードを配置できるように返しました。孤立した状態も、ゴーストノードも、手動クリーンアップもありませんでした。

この中程度の課題は、ベンチマークがほとんど測定しないものを明らかにしました：スタック全体にわたる状態を持つ推論。Opus 4.5は、単にSQLステートメントやReactコンポーネントを独立して作成するのではなく、それらを調整し、バージョンや履歴に関するアプリ固有のルールを尊重し、実際のユーザーが一日中重複ボタンを連打しても耐えられる機能を提供しました。

Composaloの既存の「編集ノード」フローを改修することで、Claude Opus 4.5の強みと弱点が明らかになりました。モリッツはOpusに、アプリの新しいリアルタイムストリーミングUIを、すでに複雑な編集パイプラインに組み込むよう依頼しました。これは新規コードとしてではなく、ライブティッシュへの手術のようなものでした。

キャッチ: 編集には2種類あります。グローバル編集はノード全体—タイトル、コンテンツ、メタデータ—を書き直すのに対し、セクション編集は特定の部分、例えば段落やブロックのみを対象とします。ストリーミングレイヤーは、その区別を理解し、Reactツリーの残りを破壊することなく、関連する領域だけを再レンダリングしなければなりませんでした。

それは単純に聞こえますが、既存の状態、楽観的な更新、サーバーの応答を考慮に入れるとそうもいきません。アプリにはすでにストリーミングでない編集ロジックがあったため、Opusはストリーミングコールバックを次の通りにスレッド処理する必要がありました： - ノードエディターUI - バックエンドのミューテーションハンドラー - セクションごとのレンダリングコンポーネント

Opus 4.5はそのアーキテクチャを驚くほどうまくマッピングしました。部分的なレスポンスを適切なコンポーネントに流し込むストリーミングハンドラーを導入し、グローバルおよびセクションの編集パスに配線し、トークンが流入する間もノードの他の部分が安定したままでいることを保証しました。

グローバル編集では、更新されたコンテンツが完全ノードビューにストリームされ、古いバージョンが徐々に置き換えられました。セクション編集では、そのサブセクションのみがリアルタイムで更新され、周辺のコンテンツは停止したままでした。全ページのちらつきはなく、全体の状態リセットもなく、デモ中に明らかなレース状態もありませんでした。

実装にはまだ継ぎ目が見受けられました。一部のエッジケース、例えばストリームの途中でセクションを素早く切り替えたり、編集中にキャンセルした場合などには、確実なガードが欠けていました。いくつかの抽象化は統合されるのではなく、取り付けられたように感じられ、ストリーミングロジックが本来は輸送の詳細を知らないべきコンポーネントに流れ込んでいました。

モリッツは、名前の整理や重複したコードの分離、ストリーミングペイロード周りのTypeScriptの型の明確化を行う必要がありました。オーパスはコアの動作を実現しましたが、シニアエンジニアが抽出するような洗練されたライブラリ級のAPIを提供するには至りませんでした。

開発者が類似のパターンを組み立てる際には、Anthropic Python SDK - GitHubのようなツールが、モデルのプロンプトから安定したクライアント抽象に移行する必要があるエルゴノミクスに配慮したストリーミングサポートの重要性を示しています。

十分に良い状態で出荷されましたが、完璧には出荷されませんでした。モリッツがクロードオーパスをリアルタイム編集UIに接続したとき、新しいストリーミング動作は技術的に機能しました：テキストの更新はモデルが生成するにつれて流れ込み、ネットワークコールは正しく行われ、機能は仕様に合致しました。しかし、ストリーミングが始まるたびに、エディタは更新が始まる前に小さくも確実なUIのちらつきを見せました。

その小さな不具合は、現代のAI支援開発の90/10ルールを捉えていました。Claude Opusは大部分の作業を担当しました：既存の「編集ノード」機能を理解し、新しいストリーミングパイプラインに通し、適切なReactコンポーネントやAPIハンドラーに触れること。しかし、最後の10%—ユーザーが実際に感じる部分—は、レンダリングタイミングや状態遷移、そしてReactツリーがストレス下でどのように振る舞うかを理解する人間に依存していました。

内部では、モデルはアプリのロジックを尊重していましたが、レンダーライフサイクルの微妙な点を見逃していました。状態は適切な場所で更新され、ストリーミングコールバックも正しく接続されていましたが、中間の空の状態やダブルレンダーがコンポーネントを一時的にアンマウントして再マウントさせることを予測していませんでした。コンパイラーにはすべてが正常に見えましたが、ユーザーにとっては、エディタがまさに不適切なタイミングで点滅していました。

そのギャップは、現在のフロンティアモデルが実際に最適化しているものを明らかにします。Claude Opusは構造的推論に優れており、データフローのマッピング、タイプの推測、API境界の追跡、文脈を失わずにマルチファイル機能のリファクタリングを行います。しかし、フレームごとのUX品質—レイアウトの揺らぎを避け、ハイドレーションのミスマッチを防ぎ、読み込みスケルトンをスムーズにすること—は、ベンチマークでは測定されない暗黙の知識の領域に存在します。

モリッツは別の計画を必要としていたのではなく、味と経験が必要だった。彼は介入し、点滅がどのようにコンポーネントがストリーミング状態を初期化するかから来ているかを認識し、トークンが到着する間にビューが安定するようにレンダリングパスを調整しなければならなかった。そのモデルは彼を「存在しない機能」から「動作する機能」へ数分で導いたが、「アプリにネイティブに感じる」状態にするにはまだ手動でのデバッグが必要だった。

そのトレードオフは、Claude Opus In Production の現実的な姿です。AIは、機能の土台を強化したり、アプローチを探ったり、ボイラープレートを扱ったりする力の倍加器として機能します。しかし、最終的な仕上げやガードレール、デモと製品を分ける見えない詳細については、依然として人間が責任を負っています。

人間とAIのペアリングは、デモの gimmick のように感じるのではなく、生産習慣のように感じる場合にはじめて機能します。モリッツの Composalo ビルドは、Claude Opus を実際のチームのように見える三段階のループに変えます：設計者、実装者、レビュアー。その結果、リポジトリをスパゲッティにすることなく、一度の作業で複数の機能を出荷することが可能になります。

ステップ1は設計と計画です。人間は明確な言葉で「何」を「なぜ」を定義し、その後、Claude Opusを重要なパートナーとして利用します。Moritzは「計画モード」に入り、関連するコンポーネント（「ノードツールバー」）にタグ付けし、制約（スクロールバーなし、最小アイコン、インタラクションモードの切り替え）を述べ、ファイルに触れる前にモデルに明確化の質問をするよう強制します。

そのプランニングパスは二つのことを行います。UXの決定を早い段階で浮き彫りにし（カーソルのアイコン、ボタンの配置、外をクリックした際の挙動）、別のプランニングドキュメントに存在できる軽量な仕様を作成します。データベース作業については、モリッツが厳格なルールを追加します：まずスキーマを尋ね、その後に変更を提案することで、AIがテーブル名やフィールドの妄想をするのを防ぎます。

ステップ2はAI生成です。計画が合理的に見えると、Claude Opusが退屈な部分を処理します：ボイラープレートのReactコンポーネント、ハンドラーの配線、既存のフックを通じての状態のスレッド処理などです。「コンテンツと対話する」機能では、モデルがツールバーを変更し、iframeコンテナを更新し、一度の操作でアクティベーション/非アクティベーションのロジックを配線しました。

同じパターンが「重複ノード」機能に拡張され、UIとデータベースの両方に影響を与えました。モリッツはオーパスにエンドツーエンドのフローを描かせました：新しいツールバーアクション、サーバーコール、ノード複製ロジック、そして重複ノードを元のノードのすぐ隣に配置すること。このようなストリーミングエディターのような長期的な変更に関しては、モデルは効果的に中堅エンジニアとして機能し、メンタルスタックを失うことなく複数のファイルを接続しました。

ステップ3は人間による洗練と磨き上げです。モリッツはシニアレビュアーとしてコードに戻り、アプリを実行し、境界ケースを調べ、手作業で微調整を迅速に行います。これにより、彼はリアルタイムストリーミングのバグを発見しました。ストリーミングコンテンツが表示される前の初期UIのちらつきです。それによって、状態をよりきれいに保持する第二の反復を強いることになりました。

重要なことに、彼は判断を外部に委託しません。小さなコピーの修正（「ダブルクリックして対話」）、ビジュアルの磨き、データの整合性に対する制作の不安は人間が管理します。AIが最初に動き、人間が何を提供するかを決めます。

ループとして実行—計画、生成、レビュー—このワークフローは、品質を犠牲にすることなくスピードを最大化します。Claude Opusは、80%の雑務を加速し、開発者はUX、アーキテクチャ、および正確性を守ります。単一の誤った仮定がリリースを台無しにすることがあるためです。

ベンチマークとマーケティングコピーは一つの物語を語りますが、モリッツのリアルコーディングワークフローは、コードを出荷する際にアンソロピックの新しいノブが実際に何を意味するのかを示しています。やたらと宣伝されている努力パラメータや、ズームアクションのようなコンピュータ利用のアップグレードは、オーパスがビルドを破壊することなくリアルなコードベースに静かに変更をスレッドするのを見れば抽象的ではなくなります。

日々の開発において、作業量は明確に意図に対応します。退屈な作業には低い労力を使用します：Reactのボイラープレートを生成したり、既存のツールバーにボタンを接続したり、基本的なAPIハンドラーをスケッチしたり、テストスタブをドラフトしたりします。高い労力に切り替えるのは、モデルが複雑な状態やレース条件、ユーザーフローについて推論する必要があるときです。例えば、サーバーの応答、クライアントの状態、既存のUXの期待を調整しなければならなかったストリーミング編集UIなどです。

その分割はほとんどのチームにとって実践的なパターンを示唆しています： - 足場作りや繰り返しのグルーコードには低い労力 - お馴染みのパターン内での機能作業には中程度の労力 - クロスカッティングロジック、データモデリング、および難しい非同期フローには高い労力

モリッツのセッションは、なぜAnthropicが信頼性について何度も言及するのかも示唆しています。複数の機能において、Opusは最小限のツール呼び出しのドラマと重大なビルド失敗なしで編集を生成し、プロダクションスタイルのテストではツールやリンターエラーが50～75%少ないという外部報告とも一致しています。一日に何度も実行されるCIパイプラインにおいて、失敗ノイズを10～15%削減することは、エンジニアリングの注意を数時間取り戻すことができます。

そのように見れば、Claude Opus 4.5は「単なるコードジェネレーター」のようには見えなくなり、システムを意識した共同作業者のように見えてきます。コンポーネントの境界を記憶し、ガイドされるとデータベースの契約を尊重し、既存のアーキテクチャを押しつぶすのではなく、それに沿ってナビゲートします。具体的な数字が気になる方には、Claude Opus 4.5のベンチマーク - Vellum AIが、合格率やトークン効率のデータでその定性的な感覚を裏付けています。

あなたにとっての要点はシンプルです：Opusを実際のスタックに組み込み、努力を予算の調整として扱い、自分の時間をLLMがまだ認識できないシステムの部分—プロダクトのトレードオフ、アーキテクチャの賭け、ユーザーにとっての「十分良い」とは本当に何か—に確保してください。

AIは開発者の役割を消すのではなく、書き換えます。クロード・オパス4.5がモリッツのバックログを処理しているのを見ると、それが明らかになります。このモデルはボイラープレートや配線、リファクタリングを処理し続ける一方で、人間は製品の舵を取り続けます。仕事は「一日中コードを入力する人」から「何が存在すべきか、そしてAIが十分に良いときはいつかを決める人」へと変わります。

Claude Opusが実際に自動化するものは、シニアエンジニアが普段から不満を抱いている部分に疑わしく似ています。UIコンポーネントの足場を組み、既存のツールバーに新しいボタンをはめ込み、フロントエンドとバックエンドでデータ構造を反映させます。モリッツのリアルコーディングワークフローにおいて、Opusは「コンテンツとインタラクトする」ボタンとデータベースに基づく重複ノード機能をほとんど人間の入力なしで処理しました。

モデルが欠陥を抱えるところで、新しい開発者が編集長として登場します。そのストリーミングUIの改修は機能的にはうまくいきましたが、微妙なちらつきを引き起こしました—ベンチマークではそれは捕らえられませんが、製品のセンスを持った人間なら気づきます。開発者の仕事は、UXの継ぎ目を見つけ出し、パフォーマンス予算を遵守し、クリーンなアーキテクチャのためにAI生成コードを取り除くタイミングを決定することに変化していきます。

将来に備えたエンジニアは、アーキテクチャとプロダクト思考に一層力を入れます。あなたは、Opusに1行も書かせる前に、イベントフロー、エラーバウンダリー、データオーナーシップを決定します。制約—レイテンシキャップ、アクセシビリティルール、テストカバレッジ—を定義し、その後AIの実装がそれらを実際に尊重しているかどうかを判断します。

日々、それは繰り返しのループのように見えます。

• 1計画モードで問題を正確な制約を持って設定する
• 2クロード・オパスにデザインとパッチセットを提案させてください。
• 3スタッフエンジニアのようにレビューを行い、コードモンキーのように振る舞わないでください。
• 4UX、セキュリティ、またはパフォーマンスに関連する10～20％を手動で洗練させてください。

この人間とAIの引き継ぎをマスターした開発者は、ジュニアからテックリードに移行するのと同様のレバレッジを得ます。あなたは依然として正確性、保守性、ユーザー体験に対する責任がありますが、退屈することのないシステムに反復的な作業を委任するだけです。仕事内容は縮小するのではなく、より戦略的で、より創造的な何かに拡大し、適応することでより強力なものになります。

Claude Opus 4.5とは何ですか？

Claude Opus 4.5は、Anthropicによる最新のフロンティア推論モデルであり、複雑なソフトウェアエンジニアリングタスク、エージェンティックワークフロー、および向上したコーディングパフォーマンスに特化して最適化されています。

Claude Opus 4.5は、コーディングワークフローをどのように改善しますか？

複雑な要件を理解し、明確化のための質問を投げかけ、境界ケースにプロアクティブに対処し、フロントエンドとバックエンドのコードの両方を生成することで、ワークフローを改善し、初期の開発時間を大幅に短縮します。

Claude Opus 4.5は、他のモデルと比べてコーディングにおいて優れていますか？

「優れている」というのは主観的なものですが、Opus 4.5は長期的なコーディングタスクにおいて顕著な改善を示し、文脈の理解が深まっています。実際のテストでも、作業結果を得るために必要な反復が少なくなることがよくあります。

テストで示された最も難しい課題は何でしたか？

最も困難な作業は、「編集ノード」機能のリアルタイムストリーミングプレビューを実装することでした。モデルはコアロジックを成功裏に実装しましたが、マイナーなUIのバグ（ちらつき）を引き起こし、人間による調整が必要でした。