「claudecode」タグの記事が2件件あります

こんにちは。開発二部の箕浦です。

2026年5月28日、Anthropicが Claude Opus 4.8 と同時に、Claude Codeの新機能 「Dynamic Workflows(ダイナミックワークフロー)」 を発表しました(公式ブログ)。
ひとことで言うと、 「Claude自身がオーケストレーションスクリプトを書いて、多数のサブエージェントを走らせ、結果を自己検証してから1つの答えにまとめてくれる」 という機能です。

これまでこのブログでは、Claude Code導入ガイドや仕様駆動開発(SDD)入門、Skillsでエージェントを強化するといったテーマを扱ってきましたが、Dynamic WorkflowsはまさにそれらのAIエージェント路線の最新形です。発表されたばかりで日本語の情報もまだ少ないので、現時点(2026年6月)で分かっていることを整理してみます。

なぜ「ワークフロー」が必要なのか​

Claude Codeは賢くなりましたが、それでも 「1人のエージェントが1パスで処理する」には大きすぎるタスク があります。

• サービス全体・リポジトリ全体にまたがる バグ探索 や セキュリティ監査
• 数百〜数千ファイルに触れる 大規模なマイグレーション(フレームワーク移行、API廃止対応、言語ポート)
• コミット前に あらゆる角度からストレステストしておきたい 設計や変更

こうした作業は、人間がやれば「四半期単位」の計画になることもあります。
従来のサブエージェント機能でも並列化はできましたが、 「どう分割し、どう検証し、どう統合するか」を毎回人間が組み立てる 必要がありました。Dynamic Workflowsは、その オーケストレーション(指揮)そのものをClaudeに任せてしまおう という発想です。

Dynamic Workflowsとは何か​

公式の「How it works」を要約すると、こういう流れです。

1. プロンプトを受け取ると、Claudeが 動的に計画を立て、タスクをサブタスクに分解する
2. サブタスクを 並列で動くサブエージェント群 にファンアウト(分散)する
3. 各エージェントが 独立した角度から問題に取り組み、別のエージェントがその結果を 反証(refute) しようとする
4. 答えが 収束(converge)するまで反復 する
5. 結果は統合前に検証され、利用者には 1つの整理された答え だけが返る

ポイントは、Claudeが裏側で JavaScriptのオーケストレーションスクリプトを生成 し、ランタイムがそれを実行するという仕組みです。
調整(コーディネーション)が会話の外側で行われるため、タスクがどれだけ大きくなっても 計画が脱線しにくい という特徴があります。

なお、エージェントの規模には公式ドキュメントで上限が決められています。
同時に走るのは最大16エージェント(CPUコアが少ないマシンではさらに少なくなります)で、 1回の実行で生成できるエージェントは累計最大1,000 までです。後者は暴走ループを防ぐためのストッパーという位置づけです。

さらに、 途中経過が保存される ので、停止しても完了済みのエージェントはキャッシュ結果を返し、残りだけを実行する レジューム(再開) が可能です。
ただし再開できるのは 同一のClaude Codeセッション内に限られ、Claude Codeを一度終了するとワークフローは次回最初からやり直しになる点には注意が必要です。数時間〜数日に及ぶ長時間タスクを想定した設計です。

従来の「サブエージェント」や「Skills」との違い​

過去記事を読んでくださった方向けに、立ち位置を整理します。

CyberAgentのエンジニアの方も公式ブログで 「単一サブエージェントを撃つことと、本格的なエージェントチームを組むことの“あいだ”を埋めてくれる」 とコメントしていて、この表現が立ち位置をうまく言い当てていると思います。

使い方​

対象プランと提供形態​

現時点では リサーチプレビュー として、Claude Code CLI・デスクトップアプリ・IDE拡張・非対話モード(claude -p)・Agent SDKで利用できます。
利用には Claude Code v2.1.154 以降 が必要です。

• 全有料プランで利用可能。ただし Proプランはデフォルト無効 で、/config の「Dynamic workflows」行から自分でオンにします
• 組織(Enterprise等) では管理者がマネージド設定で組織全体のオン/オフを制御できます
• Claude API / Amazon Bedrock / Google Cloud Vertex AI / Microsoft Foundry でも利用可能

起動方法​

公式は auto modeをオンにした状態での利用を推奨 しています。その上で、起動方法は2通りです。

1. Claudeに直接ワークフローを作るよう頼む(例: 「Create a workflow」「ワークフローを作って」)
2. ultracode という新設定をオンにする ─ effort(努力度)メニューからアクセスでき、effortレベルを xhigh に設定しつつ、 ワークフローを使うかどうかはClaudeが自動判断 してくれます

初めてワークフローがトリガーされるときは、Claudeが 「これから何を実行するか」を提示して確認を求めてくれます。いきなり大量のエージェントが暴走することはありません。

ワークフローが起動中は、/workflows コマンドを実行すると
以下のように起動中のエージェントがいくつ立ち上がって、それぞれのエージェントが何をしているかが確認可能です。

ユースケース​

公式やアーリーアクセスのユーザーが挙げている使いどころです。

• コードベース全体のバグ探索 / 最適化監査 / セキュリティ監査
  並列で探索した上で、 個々の発見を独立に再検証 するため、レポートに上がるのは“本物の問題”だけになります。認証チェック・入力バリデーション・危険なパターンの洗い出しといったハードニング作業にも同じ形が使えます。
• 大規模なマイグレーション / モダナイゼーション
  フレームワーク移行、API廃止対応、言語ポートなど、数千ファイルにまたがる作業をエンドツーエンドで。
• 二重チェックが必要なクリティカルな作業
  間違いのコストが高い場面で、Claudeに 独立した複数の試行 をさせ、 敵対的(adversarial)なエージェント に結果を壊しにかからせてから人間が確認できます。

実際、Klarnaのエンジニアリングマネージャーは 「デッドコードの特定や、静的解析では見つからなかったクリーンアップ箇所の洗い出しに効いた」 とコメントしています。

圧巻の実例: Bunを Zig → Rust に移植​

インパクトが大きい事例として、ランタイム Bun の言語移植が紹介されています。

Jarred Sumner氏がDynamic Workflowsを使って、BunをZigからRustへ移植したというものです。

• 既存テストスイートの 99.8% がパス
• 約75万行のRustコード
• 最初のコミットからマージまで わずか11日

流れもエージェント的で、

1. あるワークフローがZigコードの全構造体フィールドに対して 正しいRustのライフタイムをマッピング
2. 次のワークフローが各 .zig を 挙動が同一な .rs に移植(数百のエージェントが並列で動き、各ファイルにレビュアーが2人)
3. ビルドとテストが通るまで回し続ける fixループ
4. 移植後、 夜間のワークフロー が不要なデータコピーを直し、それぞれPRを起票

…という、まさに「四半期仕事が数日で終わる」を体現した事例になっています(※本番投入はこれからとのこと)。

試すときの注意点​

実際に使ってみる前に、押さえておきたい点です。

1. トークン消費が桁違いに増える
   公式が繰り返し警告しているとおり、Dynamic Workflowsは 通常のClaude Codeセッションよりも大幅にトークンを消費 します。いきなり巨大タスクで回すのではなく、 スコープを絞った小さなタスク で使用感を確かめるのが推奨です。
2. リサーチプレビュー段階である
   仕様や挙動は今後変わる可能性があります。社内の標準フローに組み込むのは、もう少し成熟を待ってからが安全でしょう。
3. Enterpriseはデフォルト無効
   組織で使う場合は管理者による有効化が必要です。逆に、管理設定でワークフローを 明示的に無効化 することもできます。

まとめ​

Dynamic Workflowsは、AIコーディングの主役を 「AIにコードを書いてもらう」から「AIエージェント群の指揮系統ごとAIに任せる」 へと一段押し進める機能だと感じます。
前回のSDDの記事で引用したKarpathyの "The programmer is increasingly not just a code writer, but an orchestrator of agents." という言葉が、いよいよ製品機能として降りてきた、という印象です。

とはいえ現状はリサーチプレビューで、トークンコストも相応にかかります。
まずは ultracode をオンにして、コードベースのちょっとしたバグ探索や監査 あたりの“小さく試せるタスク”から触ってみるのが良さそうです。
弊社でも実案件で回してみて、また知見がたまったら続報をお届けしようと思います。

こんにちは。開発二部の箕浦です。

2025年は「vibe coding(雰囲気でAIに書かせる)」が流行語のように使われた1年でした。
ところが2026年に入ってからは、その揺り戻しのように 「仕様駆動開発(Spec-Driven Development、以下SDD)」 という言葉を頻繁に見るようになっています。

GitHub・AWS・Anthropic・Cursorなど大手プレイヤーが揃って「仕様を先に書く」流儀のツールを出してきており、社内でも一度整理しておく価値があると思ったので、代表的な3ツールを比較してみます。

そもそも「仕様駆動開発」とは​

実は「Spec-Driven Development」という言葉自体は新しくありません。
2010年代にはAPI開発の文脈で、OpenAPI/Swaggerを先に書いてからコードを生成する Design-First / Contract-First のことを指していました。

ところが2025年以降の使われ方はこれと少し違います。
AIコーディングの文脈では、SDDは

自然言語で書いた 「要件 → 設計 → タスク」という仕様 をsource of truthとして扱い、コードはそこから派生的に生成・検証されるもの

として再定義されています。

GitHubのSpec Kit公式ドキュメント(spec-driven.md)の表現はかなりドラスティックで、

Spec-Driven Development (SDD) inverts this power structure. Specifications don't serve code—code serves specifications.

と書かれています。「コードが正、仕様は付属物」だった関係を逆転させようというわけです。

背景にあるのはやはりvibe codingの限界です。
LLMに「いい感じに作って」と頼むと、小さなプロトタイプは秒で動くのに、いざ本番投入しようとするとコンテキスト不足で破綻したり、後から要件を聞かれて困ったり、という経験はみなさんもあるはずです。
そこで 「仕様を先に明文化し、AIにはその仕様に従って書かせる」 というスタイルが見直されている、というのが大筋の流れです。

代表ツール3本を比較する​

1. GitHub Spec Kit ─ OSSの“型”を提供するツールキット​

2025年9月にGitHubがOSSとして公開したのが github/spec-kit です。
CLI(Specify)とテンプレート群からなり、Claude Code / Cursor CLI / Gemini CLI / Codex CLI など30以上のAIコーディングエージェントから利用できます。

ワークフローはスラッシュコマンドで段階的に進める形式で、現行版は概ね次の流れになっています。

/speckit.constitution  ← プロジェクト憲法(非交渉な原則)
   ↓
/speckit.specify       ← 要件(What/Whyのみ。技術スタックは書かない)
   ↓
/speckit.clarify       ← 曖昧点を質問形式で洗い出し
   ↓
/speckit.plan          ← 設計・データモデル・契約・research を一括生成
   ↓
/speckit.tasks         ← ユーザーストーリー単位のタスク分解
   ↓
/speckit.analyze       ← 整合性チェック
   ↓
/speckit.implement     ← 実装

「何でも乗せるFW」ではなく、 仕様ドキュメントの構造とフローだけ規定して、AIエージェントは自由に選ばせる のがSpec Kitの設計思想です。手元のClaude Code等にそのまま被せて使える点で導入コストが低いのが強みです。

2. AWS Kiro ─ SDDをコア体験に据えたIDE​

Kiro はAWSが2025年7月にpreview公開、2025年11月17日にGA した agentic IDE です。VS Code(Code-OSS)ベースで、バックエンドはAmazon Bedrock経由でClaude Sonnet系などを利用しています。

機能を1コマンドで立ち上げると、Kiroは以下3ファイルを自動生成します。

• requirements.md ─ ユーザーストーリー + 受け入れ条件を EARS記法 で記述
• design.md ─ アーキテクチャ、シーケンス図、データフロー
• tasks.md ─ 連番付きの実装タスクチェックリスト

公式トップの一文がコンセプトをよく表しています。

Bring engineering rigor to agentic development.

vibe codingとの対比も明確で、Introducing Kiroブログには

Kiro is great at 'vibe coding' but goes way beyond that—Kiro's strength is getting those prototypes into production systems with features such as specs and hooks.

とあります。「vibe codingの楽しさは残しつつ、specs と hooks で本番投入できる強度を持たせる」という立て付けです。
半面、クレジット課金($20/月のProプランで1,000クレジット〜)なので、長時間の試行錯誤にはコスト感の見極めが必要になります。

3. Claude Code(Plan Mode + Skills)─ いま手元にあるもので“軽量SDD”​

専用ツールを入れなくても、Claude Codeの Plan Mode だけでSDD的な使い方は始められます。

Shift + Tab を2回押すか /plan を打つと、Claudeはファイル変更や実行を行わない read-only モードに入り、コードベースを読み込んだ上で構造化された計画を出力します。
これを人間がレビュー・修正してから実装フェーズに移れる、というシンプルな仕掛けです。

さらに2025年10月に登場した Skills (SKILL.md を持つ再利用可能な手順書) を組み合わせれば、「ブレストする」「仕様を書く」「実装する」といった工程をスキルとして固定化できます。
実際このブログ記事も、brainstorming スキルで要件整理 → 3つの調査エージェントを並列で走らせる、というSDD的な流れで書きました。

Spec KitとClaude Codeは併用も普通にできるので、 「まずはClaude CodeのPlan Modeで肌感をつかみ、本格運用ではSpec KitかKiroを選ぶ」 という入り方が現実的だと思います。

実務で取り入れるときの勘所​

1. すべての変更にSDDを被せない ─ ちょっとした修正にまでconstitution→specify→…をやると、HackerNewsで議論された「Waterfallの逆襲」になります。粒度の大きい新機能や、後で他人が読む必要のある変更にだけ適用するのが現実的です。
2. 仕様の解像度を上げるのは人間の仕事 ─ SDDツールは仕様を「書いてくれる」ように見えますが、本質は エンジニア側が要件を言語化する補助 です。ぼんやりした要件を投げると、出てくる仕様もぼんやりします。
3. ツール選定を急がない ─ Spec Kitは無料で軽量、KiroはIDE体験まで揃った代わりに課金、Claude Codeは既存の延長線。プロジェクト規模とチーム構成で選び分ければOKです。

まとめ​

AIコーディングの主役は、いつのまにか「AIにコードを書いてもらう」から 「AIエージェント群に何をさせるかを人間が仕様で指示する」 へと変わりつつあります。
Andrej Karpathyが2026年のSequoia Ascent talkで語った "The programmer is increasingly not just a code writer, but an orchestrator of agents." という表現が、今のリアルな手触りに近いと感じます。

すべてをSDDに振り切る必要はありませんが、 「コードの前に仕様を書く」 という基本動作は、これから数年のスタンダードになっていきそうです。
まずはお使いのClaude CodeのPlan Modeから、軽く試してみてはいかがでしょうか。