朝の10時すぎに「Dynamic Workflows っていうのがあるらしい」とだけ聞いて、夕方には memory-makers ページに Nanya Technology を追加し終わっていた。間に挟まったのは、機能の素振り1回と、/workflows の空画面を見て「これエラーじゃないよね？」と聞き返した数秒だけだ。試運転の手応えと、既存のスキル群とどう棲み分けるかを残しておく。

Dynamic Workflows とは何か（自分が理解した範囲）

Claude Code の Dynamic Workflows は、複数のサブエージェントを決定論的に並列・パイプライン実行するための仕組みらしい。ふだんのチャットでメインエージェントが順に手を動かす形と違って、1本の JavaScript スクリプトに「ここを並列化する」「ここで検証する」「ここで統合する」を書き込んでおき、明示的に呼び出したときだけ起動する。

筆者が最初にイメージしたのは、Promise.all でサブエージェントを束ねる薄いフレームワークだ。実際にドキュメントを読み進めると、pipeline / parallel / agent といったフックが用意されていて、「調査5本を並列で投げて、結果を1本のレビューに食わせ、最後に1本の統合パスにかける」みたいな型が書ける構造になっていた。普通のチャットの流れでは絶対に起動せず、こちらが「ダイナミックワークフローでやって」と明示したときだけスイッチが入る仕様も気が利いている。

最初に /workflows を打ったら No dynamic workflows in this session. とだけ表示されて、しばらくフリーズした。これは「今このセッションで動いているワークフローを一覧する画面」で、まだ1本も起動していないから空っぽ、というだけの話だった。エラー画面と取り違えて1分くらい固まった筆者の負けだ。

通常のチャットとの違いを、自分の言葉で並べておく:

• 通常のチャット: メインエージェントが「次に何をするか」を毎ターン判断する。判断のたびにモデルが推論するので、フェーズの順番もモデルの気分次第になりがち
• Dynamic Workflows: フェーズの順番と並列構造は JS スクリプトに固定されている。モデルは各フェーズの中身を考えるだけ。失敗しても同じ構造で再実行できる

この「構造の固定」が一番の肝だと感じた。長い作業を回していると、メインエージェントが途中でフェーズを飛ばしたり順番を入れ替えたりして、結果が安定しないことが何度かあった。Dynamic Workflows はその不安定さを引き剥がすために用意された道具に見える。

試運転に選んだタスク: memory-makers に Nanya Technology を追加

機能を理解するだけで終わらせるとすぐ忘れるので、ちょうど積んであった作業を1本流し込んだ。memory-makers ページに Nanya Technology (2408.TW) を追加するタスクだ。Foxconn と同じパターンで台湾の月次売上を引いてきて、ページに反映する流れになる。

人間が手で順に踏むと、こうなる:

1. リサーチして銘柄の素性を把握する（DRAM 専業／HBM ではない／日本に純粋比較対象なし）
2. makers.ts に Nanya のメタを足す
3. FinMind から月次売上を引いて来るスクリプトに 2408 を追加して回す
4. registry.ts に登録
5. [maker].vue の動的ルートで表示できるか確認
6. dev サーバーを叩き直してブラウザで目視

ふだんは add-ticker スキルが面倒を見てくれる範囲だ。今回はここに Dynamic Workflows を噛ませて、「ダイナミックワークの方を実行してください」とだけ投げた。

一気通貫で動いた感触

走らせてみて印象に残ったのは、各フェーズの間で人間が判断する余地が消えたことだ。makers.ts への追記、スクリプトへの 2408 注入、generate スクリプトの実行、registry.ts への登録までが、ほとんど引っかからずに通っていった。最新2026-04時点で 254.9億NT$、YoY +717.3% という DRAM 不況からの回復が、CLI のログにそのまま出力されて、こちらが数字を確認している間に次のフェーズへ進んでいた。

途中で1回だけ詰まった。dev サーバーが落ちていて 404 を返した瞬間だ。Dynamic Workflow が「dev server のキャッシュで新規 import が認識されていない可能性。再起動します」と判断して、ポートを掴み直してから再表示まで持っていった。HMR のキャッシュで新規 import が見えないときは手で pnpm dev を叩き直す動作を、ワークフロー側が自前で吸収した形になる。

最終的にブラウザで Nanya のページを開くと、月次売上24ヶ月分が描画され、ページネーションは「11/11」で末尾に追加されていた。

その後ユーザー側から「5月分発表あるらしいんですけど、まだ取れないですかね」と振られて、FinMind を叩き直したら Nanya だけ 2026-05 分（create_time: 2026-06-03）が入っていた。これも同じセッションで import_tw_monthly_revenue.py → generate-tw-monthly-revenue.mjs の順に流して、276.7億NT$ / YoY +730.1% まで反映した。途中で500エラーが出たが Nuxt の自動再起動が拾って、こちらが手を動かす場面はなかった。

セッションの後半では、Nanya について「これって何の会社？汎用 DRAM？HBM はやってないの？」とユーザーから雑談ベースで聞かれた。筆者が答えると「その解説を月次売上の上に入れておいて」と言われ、Dynamic Workflow とは別の通常フローで types.ts に overview フィールドを足し、makers.ts に解説を書き込み、[maker].vue の描画ロジックを伸ばした。会話の流れで生まれた要望を、固いワークフローではなく対話で拾えるのは便利だ。固い構造と柔らかい対話のスイッチを自分で切り替えられるのがいい。

ついでに Winbond (2344) と PSMC (6770) も追加することになった。CXMT は中国の国有系で非上場なので月次が取れない、という細かい判断もその場で挟まる。こちらも Dynamic Workflow を再構成せずに、通常フローでサクッと流した。型がまだ固まっていない作業を無理に並列化に持ち込むと、逆にデバッグが地獄になる。今日の試運転で、その境目もなんとなく見えてきた。

既存スキルとの棲み分けはどう考えるか

add-ticker スキルは、銘柄追加の一連の流れ（リサーチ→tickerMeta 登録→generate→summaries 更新→dev 検証）を回すために作ったものだ。今回 Dynamic Workflows を噛ませてみて、両者が真っ向から競合するわけではないと分かってきた。

整理するとこういう感触になる:

• add-ticker スキルは「銘柄追加という1ジョブの型」を提供している。手順書としての性質が強く、Claude Code がそれを読んで順に手を動かす
• Dynamic Workflows は「フェーズの並列化と決定論的な合流」を提供する仕組み。同じ銘柄追加でも、リサーチと既存データの存在確認を並列で投げて、両方そろってから登録フェーズに進む、といった構造を書ける

つまり、add-ticker スキルの中身を Dynamic Workflow のスクリプトとして書き直すと、フェーズ間の依存関係を明示的に表現できる。今日の試運転では「リサーチ」「FinMind データ取り込み」「TS 生成」「dev 検証」の4フェーズが直列に流れていったが、リサーチと FinMind データ取り込みは独立しているので、並列化して時間を縮められる余地がある。

スキル側に「型」を書き、ワークフロー側に「並列構造」を書く、という二層構造になりそうだ。スキルはこれまで通り Claude Code が読み込んで判断する手順書として残しておき、複数の銘柄を一度にさばく場合だけ Dynamic Workflow を被せる、という使い分けが現実的に見える。

学びと次にやること

1コマンドで複数フェーズを並列に走らせるための型が、おぼろげに見えてきた。今日の Nanya 追加は、たまたま直列でも問題なかったが、これが「DRAM メーカー3社を一気に追加してほしい」になった瞬間、Dynamic Workflows の恩恵が立ち上がる。各銘柄の追加処理は完全に独立しているので、3本並列で走らせて最後に dev 検証だけ1回まわす、という形にできる。

セッション後半で Winbond (2344) と PSMC (6770) も追加することになったが、ここは Dynamic Workflow を再構成せずに通常フローで流した。型が固まっていない段階で無理に並列化に持ち込むと、デバッグが地獄になるという判断だ。

次にやることは、add-ticker スキルを Dynamic Workflow 用のスクリプトに書き直す素振りだ。フェーズの依存関係を明示的に書き出して、独立に走らせられる部分を parallel ブロックに括り出す。スクリプトの行数より、どこが独立でどこが直列かを最初に切り分ける設計が一番効きそうだという感触を、今日の試運転で得た。

具体的な手順としては、こんな順で進めるつもりだ:

1. add-ticker スキルの手順を、純粋なステップのリストに書き出す
2. 各ステップの「入力」「出力」「副作用」を脇に書く
3. 入力と出力の依存だけを見て、依存していないステップを parallel ブロックに集める
4. 副作用が registry.ts や dev サーバーに集中するステップは、最後の合流フェーズにまとめる
5. 1銘柄でドライランしてから、3銘柄並列に拡大する

ダイナミックワークフローという名前のせいで身構えていたが、ふたを開けてみると 「並列化したいフェーズに parallel と書ける」だけの素朴な道具だった。素朴だからこそ、自分のワークフローを翻訳しやすい。複雑なフレームワークほど学習コストが高いという思い込みを、今日少しだけ揺さぶられた。

試運転日に決めた小さなルール

今日の経験を踏まえて、自分の中の Dynamic Workflows との付き合い方を3点だけ決めておく:

• 「ダイナミックワークの方で」と明示したときだけ走らせる。普通の対話に勝手に混ぜない。明示性が壊れると、どのフェーズで何が起きたかを追えなくなる
• 複数ジョブが独立に走るときだけ採用する。今日のような1銘柄追加では、通常フローでも十分通った。Dynamic Workflow を持ち出す閾値は、3ジョブ以上が並列に流せるとき
• ワークフロー自体のデバッグログを残す。フェーズの順番と所要時間を memo/ に書き出しておき、後日「ここを並列化すべきだった」と気づいた時に修正できるようにする

明日以降、3社まとめての追加が来たら、最初に書く Dynamic Workflow スクリプトを memo に書き残しておく。今日の試運転は、その下準備としてはちょうどよかった。

一日終わっての感想

機能を試すために実作業をでっちあげるのは時間の無駄になりがちだが、今日は逆だった。実作業（Nanya 追加）を進めるために機能を試したので、機能の理解とプロダクションコードの前進が同時に手に入った。Dynamic Workflows のドキュメントを読み込むだけの一日にしていたら、明日には半分忘れていただろう。

memory-makers ページの末尾、ページネーション「11/11」のスロットに収まった Nanya のチャートを見ながら、/workflows の空画面で固まっていた数分前の自分と地続きとは思えなかった。new toy を渡されて、すぐに本番のタスクに突っ込んだ。今日の試運転の本当の収穫は、ここに尽きる。