AI が、
「組織の指揮官」になった日。

SWE-Bench Pro × GDPval-AA × コンピュータ操作

Opus 4.8 は 「コーディング × 知識労働 × エージェント性能」 という実務 3 領域で同時に最高水準を更新した。特に GDPval-AA で GPT-5.5 を +121pt 上回った点は、AI の「実世界での生産性」という最も重要な指標で優位を確立したことを意味する。

• SWE-Bench Pro 69.2% — GitHub Issue を解決する実務的コーディング能力。Opus 4.7（64.3%）から +4.9pt。バグ修正と機能追加の両方で改善。
• GDPval-AA 1890 — 専門家が評価する実世界の知識労働スコア。Opus 4.7（1753）から +137pt、GPT-5.5（1769）を上回る。
• コンピュータ操作 83.4% — 画面操作・ツール使用を含むエージェント性能。Dynamic Workflows と組み合わせて真価を発揮。
• 価格据え置き — 性能向上にもかかわらず料金は 4.7 と同水準。Anthropic の競争戦略は「価格 × 性能」両軸で攻めている。

「黙って間違える」が、構造的に消える

従来モデルの最大の問題は、「自信ありげに間違える」こと。短時間タスクなら人間がレビューできるが、数日にわたる自律作業では誤った前提が雪だるま式に拡大する。Opus 4.8 はこの根本問題に「メタ認知の獲得」という形で解を与えた。これが Dynamic Workflows の長時間実行を実用化した真の決定要因だ。

• 欠陥検出 — 自身のコードのバグ見落としが従来比 1/4。自己レビューループの精度が一段階上がった。
• メタ認知 — 確証が持てない場合に自らフラグを立てて報告。人間レビュアーが「どこを集中して見るべきか」を判断しやすい。
• 長時間作業の手戻り削減 — 数日にわたる自律実行で、誤った前提が雪だるま式に拡大するリスクが大幅に低下。
• Dynamic Workflows との相乗効果 — 並列サブエージェントの一つが「自分は不確実」と表明することで、Adversarial Verifier の検証対象を絞れる。

動的スクリプト生成 × 並列サブエージェント × 外部状態管理

従来のシングルエージェント体制とは異なり、Claude 自身が JavaScript オーケストレーションスクリプトを動的に書く点が革新的だ。スクリプトは「最適な実行順序」と「検証プロセス」を含み、役割分化したサブエージェント艦隊を指揮する。中間結果がコンテキストウィンドウではなくスクリプト変数として外部保持される設計が、数日にわたる長時間実行を可能にした。

1. 動的スクリプト生成 — Claude がタスクを分析し、最適な実行順序や検証プロセスを記述した JavaScript オーケストレーションスクリプトをその場で生成。
2. サブエージェントの展開 — スクリプトに基づき、数十から最大 1,000 のサブエージェントをバックグラウンドで起動。
3. 役割分化と協調 — Finder（情報収集）／ Adversarial Verifier（敵対的検証）／ Synthesizer（統合）の三役で品質を担保。
4. 外部管理 — 中間結果はコンテキストではなくスクリプト内変数として保持。数日にわたる長時間実行や中断からの再開が可能。

ファイルからコードベース全体へ

この事例の本質は「速さ」ではなく「単位」の変化にある。これまで AI が扱える単位は「ファイル」「関数」だったが、Dynamic Workflows はコードベース全体を 1 つのタスクとして扱えるようになった。これは AI 開発における「産業革命」に匹敵する質的転換だ。

• 期間 — 初コミットからマージまで11 日間。従来の数ヶ月〜年単位から劇的に短縮。
• 品質 — 既存テストスイートの 99.8% をパス。「速いが壊れる」ではなく「速くて正確」を実証。
• 自律性 — ライフタイム管理、ファイル単位の並列移植、ビルド・テストの修正ループまでをワークフローが完結。
• 含意 — レガシーコード移植・大規模リファクタリング・言語移行という「巨大プロジェクトの経済性」が根本的に変わる。

xhigh / high / medium / low の判断基準

推論努力（Effort）の設定は、「コストと品質のトレードオフ」を握る最重要パラメータ。タスクの性質に応じて厳格な使い分けが求められる。コーディングエージェントには xhigh、簡単な定型処理には low を選ぶことで、月額コストを桁違いに最適化できる。

• xhigh — コーディングエージェントや高度な分析に推奨。Dynamic Workflows と組み合わせる場合の標準設定。
• high — 知能を要するタスクの最低ライン。実用品質を保つ下限。
• medium / low — コスト・レイテンシ重視。厳密に指示されたことだけを実行させたい場合に適す。Fast mode と組み合わせて経済性を最大化。

スコープ × ツール使用 × デザイン指定の 3 原則

Opus 4.8 の「文字通り実行する」傾向は、曖昧な指示を曖昧なまま受け取る。「いい感じに」「適当に」は禁物。範囲と制約を明示的に記述することで、AI の力を 100% 引き出せる。デザイン指示も明確化が必要——デフォルトではクリーム色背景やセリフ書体を好む美学があるためだ。

• スコープの明示 — 「すべてを確認して」「余計な補完をしないで」など、範囲と制約を明確に記述。
• ツール使用の誘導 — Opus 4.8 は推論優先でツール使用を控える傾向。「ツールを使うべきタイミング」を明文化。
• デザイン指示 — デフォルト美学が出るため、企業向け UI などは具体的な配色・フォント指定が必須。

トークン × 速度 × 研究プレビュー

Dynamic Workflows の真の運用コストは、「並列度 × 反復回数 × 時間」の三次関数的に膨らむ。Bun の 11 日 75 万行の事例も、相応のトークン投資があってこその成果だ。導入時は「小規模 PoC → 中規模実証 → 本格運用」と段階的に進め、コスト挙動を実測しながらスケールさせるのが鉄則だ。

• トークン消費 — 並列エージェントが反復動作するため、短時間で数百ドル規模のコストが発生する可能性。事前に上限設定を。
• 速度の低下 — 通常モードは推論が深い分、出力が低速。日常作業は Fast mode や /effort high への調整が推奨。
• 研究プレビューの安定性 — Dynamic Workflows は現在研究プレビュー段階。挙動が変更される可能性があり、本番依存は慎重に。
• 導入アプローチ — 小規模 PoC → 中規模実証 → 本格運用と段階的にスケール。コスト挙動を実測しながら判断。