ワークフローコードを可視化資産に変える: AST駆動Cloudflare Workflows運用設計
Cloudflareが示した「TypeScriptワークフローをAST解析してステップ図に変換する」アプローチは、単なる見た目改善ではありません。設計書を人手で追従させる時代から、コードを唯一の真実として可視化を自動生成する時代への移行です。
特にAIエージェントや複雑な非同期処理を扱う現場では、図の自動生成は運用品質そのものを左右します。
なぜ手書きワークフロー図は破綻しやすいのか
ワークフローは変更頻度が高く、仕様が少し変わるだけで分岐・再試行・例外経路が増えます。手書き図は次の理由ですぐ陳腐化します。
- 分岐の更新漏れ
- 例外経路の書き忘れ
- 実際のデプロイ状態とのズレ
AST起点で図を生成すれば、少なくとも「コードと図が一致していない」状態を大幅に減らせます。
ASTを“コンパイラ内部”で終わらせない
ASTは構文木なので、通常はビルド処理の文脈で語られます。しかし運用観点では、次の価値が出ます。
- ステップ依存関係の明示
- 到達しない死経路の検知
- 分岐複雑度の定量化
- デプロイ前ポリシー検査
つまりASTは、可視化の元データであると同時に、統制の入力データでもあります。
SRE観点での実利
自動生成図は、SREの主要局面で効きます。
- PRレビュー: テキスト差分だけでなく構造差分を確認できる
- 障害対応: フォールバック経路と再試行経路を即時追跡できる
- 事後分析: 意図した経路と実行経路のズレを説明しやすい
結果として、理解にかかる時間（MTTC）が減り、MTTR短縮にも直結します。
ガバナンスはコーディング規約より構造制約
ASTベースなら、スタイル規約より強い統制を設計できます。
- ステージごとの最大fan-out数
- 外部API呼び出しへのtimeout/retry必須化
- 高権限処理へ直接到達するノードの禁止
この種の制約は、レビュー文化ではなくシステムとして守るべき領域です。
変更管理: トポロジーもバージョン化する
リリースごとに次を残すと、変更リスク管理が安定します。
- グラフハッシュ
- クリティカルパス所要時間の見積もり
- 影響範囲（接続システム数）の推定
障害発生時、ログ探索より先にトポロジー差分を見ると原因に早く辿り着けるケースが増えます。
エージェント時代に可視化が必須になる理由
AIがワークフローコードを生成・改変する場面では、レビュー対象が急増します。このとき図生成がないと、次の問いに答えられません。
- どの構造が増えたのか
- 再試行の自動増幅ポイントはどこか
- どのステップが機密システムへ新規到達したか
つまり可視化は説明資料ではなく、安全装置です。
実装の現実解
導入パターンはシンプルです。
- ビルド時にソースをAST化
- 正規化グラフJSONを出力
- 静的図 + インタラクティブ図を生成
- グラフに対してポリシー検査を実行
- PRに構造アーティファクトを添付
この流れで、開発・SRE・セキュリティが同じ構造を見て議論できます。
追うべきKPI
導入率ではなく効果を見ます。
- 構造リスク注記付きPR比率
- 分岐漏れ起因インシデント件数
- 高複雑度変更のレビュー時間
- 更新後ロールバック発生率
これが改善しないなら、可視化は飾りに留まっています。
まとめ
AST駆動のワークフロー可視化は、運用の説明責任をコードと一体化する仕組みです。エージェント生成コードが増える2026年以降、図を“自動生成される統制アーティファクト”として扱うチームほど、速く・安全に変更できるようになります。
