動的ワークフローって何?AIが手順を決める仕組み

「手順が決まっていない作業の進め方」の話

動的ワークフローという言葉、最初に聞いたとき「ワークフローって要するに作業手順のことでしょ、動的って何が動くの?」と思った人も多いんじゃないでしょうか。私も正直そうでした。

ざっくり言うと、あらかじめ決められた手順どおりに進むのではなく、状況を見ながらその場で次にやることを決めていく進め方のことです。Claude Codeのようなコーディングエージェントに作業を頼んだとき、裏側で起きているのはまさにこれです。

カーナビと、地元に詳しい人

例え話をひとつ。目的地まで行く方法には、大きく2通りあります。

動的ワークフローは後者です。ゴールは決まっているけれど、そこに至るステップは実行しながら組み立てられていきます。

Claude Codeでの具体的なイメージ

たとえば「ログイン機能のバグを直して」と頼んだとします。このとき、あなたは手順を一切指定していません。それでも実際には、だいたいこんな流れで進みます。

ポイントは、この5ステップがどこかに設定ファイルとして書かれているわけではない、ということ。ファイルを読んだ結果「あ、原因はこっちだった」となれば探索が増えるし、テストが一発で通れば修正のやり直しは発生しません。実行の途中で得た情報が、次のステップを決める材料になるんです。

従来の「静的」な自動化との違い

	静的なワークフロー	動的ワークフロー
手順の決まり方	実行前に全部決まっている	実行しながら決まる
想定外への対応	エラーで止まる、または例外処理を事前に書いておく必要がある	その場で別の手を試せる
結果の再現性	高い。毎回同じ動き	低め。同じ依頼でも経路が変わりうる
向いている作業	定型作業、ビルドやデプロイ	調査、試行錯誤が必要な修正

どちらが偉いという話ではありません。毎朝決まった時刻に同じ処理を流すなら静的なほうが圧倒的に安心です。逆に「原因が分からないバグを追う」ような作業は、そもそも手順を事前に書けないので動的でないと成立しません。

ここでつまずきやすいポイント

動的ということは、裏返せば毎回同じ結果になるとは限らないということです。昨日はうまくいった頼み方が今日は遠回りする、ということが起こりえます。これは不具合ではなく、性質だと思ったほうがいいです。

もうひとつ、「自分で判断してくれる」を「何も伝えなくていい」と取り違えると失敗します。ゴールが曖昧だと、その曖昧なゴールに向かって自由に進んでしまう。動的ワークフローで大事なのは手順の指示ではなく、ゴールと制約をはっきり伝えることです。「バグを直して」より「ログイン時にセッションが切れるバグを、既存のテストを壊さずに直して」のほうが、結果がぶれにくくなります。

使いこなすコツ

途中経過を見せてもらえる場面では、ちゃんと見ておくのがおすすめです。どのファイルを読みに行ったか、どんな仮説で修正したかが分かれば、方向がずれた時点で軌道修正を頼めます。全部終わってから「違うんだよなあ」となるより、はるかに速い。

そして、何度も繰り返す作業で経路が毎回ブレるのが気になるなら、そこだけ手順を明示して静的に寄せてしまうのも手です。全部を動的にする必要はなくて、手順が読めない部分だけ任せるという使い分けが現実的だと思います。