AnthropicはClaude Opus 4.8モデルの発表と同時に、同社のプログラミングツール「Claude Code」に「動的ワークフロー（Dynamic Workflows）」と呼ばれる大型機能を導入した。この技術により、AIは大規模なタスクを自律的に分解し、並行処理することが可能になる。Bunの創業者、ジャレッド・サムナー（Jarred Sumner）氏による実証テストでは、ZigからRustへの75万行に及ぶコード移行をわずか11日間で完了。しかし、この抜本的な基盤プロトコルのアップグレードは、Claudeの代わりに中国の国産大規模言語モデル（LLM）を使用していた多数のユーザーにAPIの400エラーを引き起こすという予期せぬ事態を招き、一部のAPI中継サービス業者が中国国産モデルに「皮をかぶせていた」という内幕を暴く結果となった。
四半期計画が週末作業に：動的ワークフローが見せた驚異的な効率性
Anthropicの公式ブログによると、動的ワークフローの中核的能力は、Claudeが動的にオーケストレーションスクリプトを作成できる点にある。一つのセッション内で、AIは数十から数百の並列サブエージェントを同時に実行し、結果がユーザーに届く前に自律的に作業品質をチェックできる。これは、コードベース全体のバグ探索、パフォーマンス最適化監査、セキュリティ監査といった、従来は人間の集中的な調整を必要とした大規模タスクを、AIがエンドツーエンドで自律的に完了できることを意味する。
Anthropicは、高性能JavaScriptランタイム「Bun」の創業者であるジャレッド・サムナー氏の実践事例を公開した。サムナー氏は動的ワークフローを用いて、プロジェクト全体をZig言語からRust言語へ移植した。11日間でClaude Codeは約75万行のRustコードを生成し、既存のテストスイートにおける合格率は99.8%に達したという。あるワークフローでは、各構造体のRustのライフタイムをマッピングするために数百のエージェントが並行稼働し、各ファイルに2名のレビュアーが配置された。
この背景には、新たなエンジニアリング哲学が垣間見える。大規模プロジェクトを移行する際、もはや人間がコードの意味を一行ずつ理解する必要はなく、AIがタスクを独立して実行可能なサブタスクに分解し、並行処理して最終的に集約するのだ。ワークフローが開始されると、Claudeはプロンプトに基づいて動的に計画を立案し、サブタスクを分解して並列サブエージェントに分散実行させ、結果を集約する前にチェックし、回答が収束するまで反復を繰り返す。注目すべきは、進捗がリアルタイムで保存されるため、中断されたジョブも中断点から再開でき、最初からやり直す必要がない点だ。
現在、動的ワークフローはClaude CodeのCLI、Desktop、VS Code拡張機能において研究プレビュー版として提供されており、Max、Team、Enterpriseプランで利用可能だ。また、Claude API、Amazon Bedrock、Vertex AI、Microsoft Foundryを通じても提供されている。
プロトコルの密かな変更が引き起こした「惨事」：中国国産モデルが一斉に機能停止
業界が11日間で75万行のコード移行を達成した効率性に驚嘆する一方で、中国の開発者コミュニティは悲鳴に包まれた。『電子工程専輯』の報道によると、Claude Opus 4.8とClaude Code v2.1.154が同時にリリースされると、「Claude Code + 中国国産LLM」の組み合わせを設定していた多数のユーザーの端末に、ターミナル起動直後から「APIError: 400」という目立つ赤いエラーメッセージが表示されるようになった。
技術分析によると、エラーの根本原因は、Anthropicが自社プロトコル内でメッセージロール（role）の定義を密かに変更したことにある。旧プロトコルでは、systemフィールドはリクエストの最外層にのみ配置でき、会話全体を通じて不変だった。しかし、動的ワークフローに対応するため、新プロトコルではsystemをmessages配列の途中に直接挿入し、userやassistantの通常の会話と混在させることが可能になった。Anthropicはこの途中で挿入されるsystemブロックを「mid-conversation-system」と命名した。
Claude Code v2.1.154へのアップグレード後、デフォルトでこの新しいフォーマットでモデルにリクエストが送信されるようになった。このリクエストがDeepSeekなどの中国国産LLMに転送されると、問題が発生する。中国国産モデルは旧標準に従い、messages配列内のroleはuserかassistantのみを認識する。そこに突然role: systemが現れると、直接400エラーを返すのだ。
より深層にある理由は、Anthropicによるプロンプトキャッシュ（prompt cache）メカニズムの最適化にある。プロンプトキャッシュは、Anthropicが開発者向けに提供するコスト削減機能で、会話内で変更されない内容をサーバー側でキャッシュし、ヒットすれば価格が10分の1に低下する。しかし、このキャッシュには「最上位のsystemを一度変更すると、全キャッシュがクリアされる」という鉄則がある。動的ワークフローでは、エージェントが実行中に頻繁に新しい命令を挿入する必要がある。旧プロトコルのまま最上位のsystemを毎回変更していては、キャッシュが繰り返し消去されてしまう。そこでAnthropicは、messagesの末尾に直接systemメッセージを追加する新方式を選択した。これにより、新たな命令を有効にしつつ、キャッシュを保持できる。残念ながら、この新プロトコルは「世界中が自分と同じ標準を使っている」という前提に立って構築されており、サードパーティモデルの互換性が瞬時に失効した。
中継サービス業者の「皮かぶせ」が露見：あなたが購入したClaudeは偽物かもしれない
今回のプロトコルアップグレードが引き起こした連鎖反応は、LLM中継サービス業界の隠された慣行を偶然にも暴き出した。報道によれば、一部のユーザーは、自身が購入した「Claudeモデル」と称する中継サービスでも、同様のsystem roleエラーが発生したことに気づいたという。
「もし利用中の中継サービスのClaudeモデルでもこのエラーが発生したら、注意が必要だ」と報道は率直に指摘する。これは、ユーザーが料金を支払って購入した中継サービスが、実は「皮かぶせ品」であることを示している。中継事業者が中国国産LLMにClaudeの皮をかぶせており、実際に動作しているのは本物のClaudeモデルではないのだ。Anthropicによる今回のプロトコルアップグレードは、この偽装を直接引き剥がした。
この現象の根源は、Claude Codeのオープン性にある。Claude Codeは本質的に単なるクライアントツールであり、Anthropicのプロトコルフォーマットに従ってリクエストをパッケージ化し送信する。ANTHROPIC_BASE_URL環境変数を設定することで、ユーザーはリクエストを任意のサーバーに転送できる。過去1年間、DeepSeekをはじめとする中国国産LLMは、自らを流暢な「Anthropic訛り」に訓練することでこのプロトコルへの適応に成功し、ユーザーはシームレスにモデルをClaudeから中国国産モデルに切り替えることができた。しかし、今回Anthropicが一方的にプロトコルを変更したことで、このエコシステムは瞬時に時代遅れとなった。
二つの緊急修正策
現在の厄介な状況に対し、開発者コミュニティは迅速に二つの有効な解決策を提示した。
一つ目の解決策は、最も単純で直接的なバージョンダウン操作だ。Claude Codeをv2.1.153に戻せば、このバージョンはまだ新プロトコルを導入しておらず、DeepSeekへの接続は以前と変わらず機能する。ダウングレード後は、～/.claude/settings.jsonで自動更新を無効にし、再び密かにアップグレードされるのを防ぐ必要がある。代償として、Opus 4.8の動的ワークフローなどの新機能は利用できなくなるが、既にサードパーティモデルを選択しているユーザーにとって、これらの新機能は元々完全には利用できないものだった。
二つ目の解決策は、バージョンを下げたくないユーザー向けだ。settings.jsonのenvセクションに特定の変数を追加する。この変数は、Anthropicがv2.1.25およびv2.1.27の公式変更履歴で「ゲートウェイユーザー」（つまりサードパーティモデルに接続するユーザー）向けに繰り返し推奨している方式であり、信頼性は極めて高い。副作用として、一部の試験的機能は無効になるが、日常的なコーディングにはほとんど影響がない。
報道では、おそらく遠からずして中国の国産LLMベンダーが最新のAnthropicプロトコルへの適応を完了し、その時点でこの騒動は自然沈静化するだろうと予測している。しかし、今回の事件が露呈させたサードパーティエコシステムの脆弱性の問題は、オープンソースプロトコルの互換性に依存する全ての開発者にとって、警鐘を鳴らすものとなった。