Claude Code dynamic workflowsを現役SaaSが触ってみた──Subagentsと何が違うか

Claude CodeでSubagentsを手動で並べて大規模リファクタを回していると、いつも初期プロンプトの組み立てに30分以上溶けていきます。さらにOpus 4.7で長時間タスクを任せると、セッション後半で精度が落ちて、結局自分でレビューに入り直す。そんな現役エンジニアの肌感を持っていた僕にとって、2026年5月28日のリリースは一つの区切りでした。

同日に発表されたClaude Opus 4.8とClaude Code dynamic workflows(research preview)が、この「手動オーケストレーションのオーバーヘッド」と「長時間自律実行の精度低下」の両方に正面から効きます。

本記事は、MAXまたはProプランで毎日Claude Codeを業務利用していて、Subagents・Skills・Hooksは触っているけれど、dynamic workflowsはまだ未体験という現役エンジニアに向けて書きます。読み終えれば、①dynamic workflowsの起動方法と並列subagentの挙動、②Opus 4.8で何が変わったか、③従来のSubagents/Hooks/Skillsとの使い分け表、④僕が現職のOCR×LLM開発で試した結果、までを持ち帰れるはずです。

2026-05-28に何が同時に起きたか──Opus 4.8とdynamic workflows

リリースから数日が経ったので、まずは事実関係を一次情報ベースで整理しておきます。Anthropic公式と各社の告知を並べて読むと、この日は3つの動きが同時に走っていたことが見えてきます。

Opus 4.8の発表

1つ目はモデル本体です。Claude公式アカウントが告知したClaude Opus 4.8は、Opus 4.7に比べてsharper judgment(判断力の鋭さ)、self-honesty about its own progress(自己進捗の正直さ)、そして長時間の独立作業能力が強化されたモデルです。前バージョンより長時間にわたって自律的に作業できる点が強調されていて、Claude公式の告知ツイート(favorite数 66,984)は半日で爆発的に拡散しました。「自己進捗の正直さ」というキーワードがエンジニア界隈で刺さっていたのが印象的でした。

GitHub Copilotへの即日展開

2つ目は配信面です。同日、GitHubがOpus 4.8をGitHub Copilotにgenerally available(一般提供)として展開したことを公式チェンジログとXの両方で告知しました。GitHub Copilotの利用者は追加設定なしでモデル選択肢としてOpus 4.8を選べるようになっています。発表からCopilot反映までが同日というのは、Claude側の配信パイプラインが整ってきた証左でもあります。

dynamic workflowsのresearch preview

3つ目が本記事の主役です。Anthropic直営のClaude DevsアカウントがClaude Codeにdynamic workflows(research preview)を追加したと告知しました。原文は「Claude writes an orchestration script on the fly, then spins up a large fleet of coordinated subagents in parallel to take on your most complex tasks」。要約すれば、プロンプトに「workflow」の意図を含めるとClaudeがその場でオーケストレーションスクリプトを書き、複数のsubagentを並列に立ち上げて検証まで走らせる仕組みです。数百ファイル横断のmigrationが想定ユースケースとして提示されています。favorite数は1万を超え、エンジニア層からの実機検証ツイートが続いています。

この3つが同日に出たことが大きい。長時間自律で精度が落ちにくいOpus 4.8と、並列subagentを自動配置するdynamic workflowsが組み合わさることで、Claude Codeが「長時間×大規模×自律」のレンジに踏み込めるようになった、と捉えるのが今のところの僕の読みです。

「まずClaude Codeにやらせてみよう」が一段抽象化された

ここまでは公式情報の整理だった。次はリリース後の数日で僕が実際に触ったログを置いておく。

2026年の1月から3月にかけて、僕の口癖は「まずClaude Codeにやらせてみたらどうだろう」になっていた。自分で書き始める前にClaude Codeに任せることから始める、という思考の転換が起きた3ヶ月だった。ただ振り返ると、これは「自分でSubagentsを手動配置するための入口」でしかなかったんだなと、dynamic workflowsを触って気付いた。

現職では2025年3月以降、AzureのOCRで請求書から文字情報を読み、その結果をOpenAIのLLMで解析する二段階構成の読取機能をずっと改善している。元々のラベリング型OCRは正解率1割で詰んでいて、LLMを噛ませて大幅に改善した経緯はZennにも書いた。最近では40ファイル前後の改修を一気に通す週もあり、Subagentsで分担を組むだけで毎回30分以上はプロンプト設計に溶けていた。

dynamic workflowsをこのワークフローに入れた最初の感触は、率直に言ってクリック1回ぶんだけ抽象化が進んだ感じだった。プロンプトに「workflow:」と前置きして要件を渡すと、Claude側が並列subagentの粒度を決めて立ち上げてくれる。Opus 4.8の落ち着きと噛み合って、後半で精度が落ちる感覚が確かに薄い。MAXプラン月100ドルを払っている身として、消費トークンの体感はSubagentsを手で並べていたときの1.3倍ぐらいに収まっていた。

実機検証──Subagents / Hooks / Skills / dynamic workflows の使い分け

dynamic workflowsが追加されたことで、Claude Codeの「やらせ方」の選択肢は4つになりました。Subagents、Hooks、Skills、そしてdynamic workflowsです。それぞれの役割が一部重なるため、まずは比較表で全体像を把握するのが早いです。

4手法の比較表

| 観点 | Subagents(/agents) | Hooks | Skills | dynamic workflows | |---|---|---|---|---| | 起動トリガー | /agents スラッシュコマンドまたは手動指定 | 特定イベント(PreToolUseなど)の発火時に自動 | /<skill-name> 起動またはキーワード検出 | プロンプトに workflow: 等の意図を含める | | オーケストレーション主体 | 人間が分担を設計 | 人間がイベントとコマンドを設計 | スキル作成者がプロトコルを定義 | Claudeが自動でスクリプトを書く | | 並列度 | 手動で並べた数だけ | イベントごとに1つ | 1つ(人が連結) | 大規模な並列fleet | | 向くタスク | 小〜中規模で粒度が読める作業 | テスト自動化・lint・ガードレール | 定型タスク・社内手順の標準化 | 数百ファイル横断のmigration・大規模リファクタ | | 消費トークン傾向 | 線形で読みやすい | 軽い(イベントトリガーが安い) | 中程度(呼び出し1回ごと) | 並列度に応じて重め・予測しにくい | | Opus 4.8の恩恵度 | 中(個別agentに反映) | 小(イベント主導のため) | 中 | 大(長時間自律で本領発揮) | | 研究プレビュー段階のリスク | なし(GA) | なし | なし | あり(挙動が変わりうる) |

表の前提として書き足しておくと、Subagents / Hooks / Skills の3つは2026年6月時点で一般提供されていますが、dynamic workflowsだけはresearch preview段階で、UIや挙動が今後変更されうる点に注意が必要です。

dynamic workflowsをすぐ試す3ステップ

僕が現職の改修で実際に踏んだ手順は、次の3つです。

  1. Claude Codeを最新版に更新する。 ターミナルで claude --version を確認し、/install-github-app を再実行するか、npm install -g @anthropic-ai/claude-code で2026-05-28以降のビルドに上げます。dynamic workflowsはこの版以降で有効になります。
  2. CLAUDE.md にworkflow用の方針を1行追加する。 既存の CLAUDE.md の末尾に Use dynamic workflows for migrations touching 5+ files or refactors involving 3+ modules. のような明示ガイドを1行入れます。Claudeが自動でworkflow起動を判断するための補助線になります。
  3. プロンプトに workflow: 接頭辞を付けて投げる。 例として workflow: Migrate all Azure SDK v3 calls in src/ocr/ to v4 while keeping the existing test fixtures green. のように渡します。Claudeがその場でオーケストレーションスクリプトを生成し、並列subagentを立ち上げて差分・テスト・ドキュメント更新まで通します。

使い分けの基準

僕の手元で運用してきた基準を整理すると、次のように分かれます。

  • Hooks は変更ファイルに対する eslint / pytest 等のガード用途に残します。dynamic workflowsとは併存できますし、置き換える理由はありません。
  • Skills は社内ナレッジを呼び出す定型化に向きます。たとえば「DBマイグレーション手順」「Datadogアラート初動対応」のような、人間も再利用したい手順はskill化のまま残すのが得策です。
  • Subagents(/agents) はdynamic workflowsの選択肢が増えたぶん、適用範囲が狭まりました。「分担が完全に頭に入っている」「並列度を自分で握りたい」ケースに絞るのが現実的です。
  • dynamic workflows は粒度を自分で決めかねる大規模リファクタや、数十〜数百ファイルにまたがるmigrationに当てます。Opus 4.8で長時間自律の精度が上がったことで、僕は1回あたり1時間ほどの自律実行を許容できるようになりました。

ここまでが「dynamic workflowsが他の3手法をどこまで侵食したか」の僕の現状回答です。Skills / Hooks は共存、Subagentsは縮小、というのが大まかな構図でした。

課題と限界──research previewであることの重み

ここまで威勢のいい話が続いたので、限界の話も同じ重みで書きます。リリース直後のresearch previewには、現場で踏むべきブレーキが3つあります。

1. 挙動が変わりうる前提を忘れない

dynamic workflowsはresearch previewです。Anthropicの告知文にも明記されている通り、UIや内部実装は今後の修正対象になりえます。本番DBへのmigrationのようなミッションクリティカルな処理を、いきなりdynamic workflowsに丸投げするのはまだ早い。最初は読み取り系のリファクタや、テスト追加・コードコメント整備のような副作用が少ない領域から試すのが、現時点で取れる現実的なリスク制御だと思います。

2. 並列subagentのトークン消費が読みにくい

並列度をClaude側に握られるぶん、MAXプラン契約者でも消費感覚が予測しにくいのが正直なところです。僕の手元では1.3倍程度に収まりましたが、対象規模が大きい指示ほどブレ幅が大きく、想定外の連続呼び出しが起きると思っていた以上にクレジットが減ります。Proプランのcredit加算で試す場合は、まず小規模リファクタ1〜2件で消費感をキャリブレーションしておくのが安全です。

3. 出力の正誤判定スキルが追いつかなくなる

Xでは現役エンジニアから「90%のAI agentチュートリアルはリサイクル」「Claude Code best practicesはまだベストプラクティスが存在しない」といった冷ややかな声が出ています。さらに、らんぶる氏のポストを引用した久保田氏が指摘していたのが「計算機科学の基礎体力がないと、AIの出力の正誤判定ができない」という論点です。dynamic workflowsで自律度が上がるほど、この指摘はクリティカルになります。Claudeが書いた並列スクリプトの中身を読まずに通すと、後で原因切り分けに数倍の時間を取られます。

それでも、Opus 4.8とセットで使えば「人間の確認しろ」を残しつつ低リスクなrefactoringから入る、という導入経路が成立すると考えています。批判一辺倒で寝かせるよりは、まず触って自分の運用感を作っておくほうがリターンが大きい局面です。

まとめ──6月から運用設計をどう書き換えるか

最後に、僕がこの記事を書きながら手元の運用方針をどう書き換えたかを共有します。

  • dynamic workflowsはSubagentsの手動配置を置き換える層であって、Hooks/Skillsとは併存できます。Hooksをガード、Skillsを定型ナレッジ、dynamic workflowsを大規模オーケストレーションと役割分離するのが分かりやすい構図です。
  • Opus 4.8と組み合わせると、長時間自律実行のしんどさが一段下がります。Opus 4.7の頃にあった「後半で精度が落ちて結局自分でレビューに入り直す」感覚が薄れました。
  • ただしresearch preview。本番DBマイグレーションのような不可逆処理は、まだdynamic workflows単独に任せず、人間の最終確認を必ず挟んだほうが安全です。
  • MAX未契約者はProのcredit加算でも試せますが回数は限られるため、小規模なリファクタからキャリブレーションするのが効率的です。
  • 僕の運用設計は、workflow: 接頭辞のガイドをCLAUDE.mdに固定追加、5ファイル以上の改修はdynamic workflowsを既定、Hooks/Skillsは現行どおり残す、の3点に整理しました。

6月以降のClaude Code運用設計は、これまでの「Subagentsをどう並べるか」から「dynamic workflowsをいつ起動するか」へと、判断の主語が変わっていきます。最新版にアップデートしておくだけで、明日から検証は始められます。

参考リンク