吉田真吾 (@yoshidashingo) です。
これだけは覚えて帰ってね💡
- AIワークフローには「事前定義型 (Pre-defined Workflow) 」と「適応型 (Adaptive Workflow) 」の2つのアプローチがある
- 事前定義型はDifyのようなDAGベースのビジュアルビルダーに代表され、確定的な実行パスを持つ
- 適応型はClaude Codeのようなコーディングエージェントに代表され、ワークフロー定義とルールブックで構成されるステアリングファイルと、状態管理で構成される
- どちらが優れているという話ではなく、タスクの性質によって使い分ける
2つのワークフロー型
AIを活用したソフトウェア開発やビジネスプロセスの自動化が広がる中、「AIにどう仕事をさせるか」のアプローチが大きく2つの流派に分かれてきています。
1つは事前定義型ワークフロー (Pre-defined Workflow) 。もう1つは適応型ワークフロー (Adaptive Workflow) です。
この2つは、ソフトウェアの世界ではおなじみの対比構造を持っています。手続き型プログラミングと宣言型プログラミング。ウォーターフォールとアジャイル。バッチ処理とイベント駆動。一方が「手順を明示的に定義する」アプローチなら、他方は「目標と制約を定義し、実行方法はエージェントに委ねる」アプローチです。
事前定義型ワークフロー ― DAGで実現するAIワークフロー
Difyに代表されるビジュアルワークフロー
事前定義型ワークフローの代表例は、Difyのようなローコード/ノーコードのAIワークフロービルダーです。他にもLangFlow、Flowise、AWS Step Functions、n8nなど、同じ思想のツールは数多く存在します。
これらのツールに共通するのは、DAG (Directed Acyclic Graph: 有向非巡回グラフ) としてワークフローを構築するアプローチです。
[入力] → [LLM呼び出し] → [条件分岐] → [ツール実行] → [出力]
↓
[別のLLM呼び出し] → [出力]
ノード (処理単位) とエッジ (ノード間の接続) をビジュアルエディタ上で配置し、データの流れと分岐条件を事前に定義します。GUIで直感的に構築できることが大きな特徴です。
事前定義型の特徴
確定的な実行パス。 ワークフローが起動すると、あらかじめ定義されたパスに沿って処理が進みます。条件分岐はありますが、分岐条件自体は事前に定義されています。入力が同じなら、たどるパスも同じです (LLMの出力のばらつきを除けば) 。
明示的なデータフロー。 ノード間のデータ受け渡しが可視化されています。どのノードの出力がどのノードの入力になるかが、エッジとして明確に定義されています。デバッグ時には、各ノードの入出力を個別に確認できます。
再現性と監査性。 同じ入力に対して同じパスを実行するため、結果の再現性が高いです。各ノードの実行ログも取りやすく、「なぜこの結果になったか」のトレースが容易です。
スケーラビリティの制約。 ワークフローが複雑になるほど、DAGも巨大になります。ノード数が増えると視認性が下がり、メンテナンスコストが上がります。また、想定外の入力やエッジケースへの対応は、事前に分岐を用意しておく必要があります。
事前定義型が向いているケース
- 繰り返しの多い定型業務: カスタマーサポートの分類と回答、定型レポートの生成など
- 品質要件が厳格な処理: 法務文書のレビュー、コンプライアンスチェックなど、決められた手順を漏れなく実行する必要がある場合
- 複数のAPIやツールの連携: 外部サービスとの統合が主目的で、LLMはその中の一ステップとして使われる場合
- 非エンジニアによる構築・運用: ビジュアルエディタで構築できるため、プログラミング経験が少ないチームでも扱える
適応型ワークフロー ― ルールブックで駆動するAIワークフロー
Claude Codeに代表されるコーディングエージェント
適応型ワークフローの代表例は、Claude Codeのようなコーディングエージェントです。他にもCursorのAgent Mode、Cline、Amazon Q Developerのエージェント機能など、同じ思想のツールが急速に普及しています。
これらのツールが実現するAIワークフローの根本的な違いは、実行パスが事前に定義されていないことです。ユーザーの指示 (ゴール) を受け取り、AIが「次に何をすべきか」をステップごとに判断します。
ユーザー: 「認証機能を追加して」
↓
エージェント: コードベースを調査 → 既存の認証パターンを発見 →
要件を整理 → 設計を提案 → 承認を得る →
実装 → テスト → 修正 → 完了
このフローは事前に定義されたものではありません。プロジェクトの状態、ユーザーの反応、途中で見つかった問題に応じて、AIが動的にフローを組み立てています。
しかし、適応型ワークフローは「野放し」ではない
ここで重要な区別があります。適応型ワークフローのAIは、何の制約もなく自由に動くわけではありません。制約と指針のセットによって「操舵 (ステアリング) 」されています。
この操舵の仕組みが、事前定義型との本質的な違いを生み出しています。事前定義型が「手順」を定義するのに対し、適応型は「制約・原則・知識」を定義します。手順はAIが状況に応じて自ら決定します。
適応型ワークフローを構成する要素は、大きく4つに分類できます。
適応型ワークフローを駆動するためのステアリングファイル (Steering Files)
現在、適応型ワークフローを駆動する定義ファイルは呼称がさまざまありますが、おおむねコーディングエージェントが必ず読み込むメモリファイルや専用フォルダにコアとなるワークフロー定義と、詳細ルールを定義し、それらをまとめてステアリングファイルと呼称することが多いです。
ステアリングファイルは、AIの振る舞いを規定するプロジェクト固有の指示ファイル群です。
ステアリングファイルの役割は、プロジェクトのコンテキストをAIに伝えることです。技術スタック、コーディング規約、ディレクトリ構造、テスト方針 ── プロジェクトに参加する新しいメンバーに最初に共有する情報と同じものを、AIに共有します。
ステアリングファイルは「手順」を指示するものではありません。「このプロジェクトではこういうルールで動いてほしい」という制約と文脈をAIに与えるものです。車のハンドル (ステアリング) が車の速度やルートを決めるのではなく、進行方向を制御するのと同じです。
1. ワークフロー定義 (Workflow Definition)
ワークフロー定義は、AIが従うべき開発プロセスの全体像を記述するファイルです。ステアリングファイルが「プロジェクト固有の制約」を与えるのに対し、ワークフロー定義は「開発プロセスの構造」を与えます。
AI-DLCのcore-workflow.mdがその典型です。
# core-workflow.md 冒頭 # PRIORITY: This workflow OVERRIDES all other built-in workflows # When user requests software development, ALWAYS follow this workflow FIRST ## Adaptive Workflow Principle **The workflow adapts to the work, not the other way around.**
AI-DLCのワークフロー定義は、INCEPTION → CONSTRUCTION → OPERATIONSという3フェーズと14のステージを定義していますが、どのステージを実行するかはAIが判断します。これが事前定義型との決定的な違いです。
事前定義型のDifyで同じことを実現しようとすると、14ステージ分のノードとそのすべての組み合わせの分岐条件をDAGに描く必要があります。ステージの順序や組み合わせが動的に変わるため、DAGは爆発的に複雑になります。
適応型では、ワークフロー定義は「メニュー」として機能します。AIがメニューから必要な項目を選び、適切な順序で実行します。レストランのコース料理 (事前定義型) ではなく、アラカルト (適応型) です。
2. ルールブック (Rule Details / Rule Book)
ルールブックは、ワークフロー定義の各ステージを実行する際の詳細なルールと手順を記述するファイル群です。
AI-DLCでは.steering/aws-aidlc-rule-details/ディレクトリに格納されたファイル群がこれにあたります。
aws-aidlc-rule-details/
common/
process-overview.md # プロセス全体図
question-format-guide.md # 質問フォーマットのルール
content-validation.md # コンテンツ検証ルール
overconfidence-prevention.md # 過信防止ルール
...
inception/
workspace-detection.md # ワークスペース検出の詳細手順
requirements-analysis.md # 要件分析の詳細手順
...
construction/
code-generation.md # コード生成の詳細手順
build-and-test.md # ビルド・テストの詳細手順
...
ルールブックの特徴は、必要なときに必要なファイルだけが読み込まれることです。AIがワークフロー定義を参照し、「今はRequirements Analysisステージを実行すべき」と判断したら、その時点でinception/requirements-analysis.mdを読み込みます。
これは事前定義型との重要な違いです。事前定義型ではすべてのルールがDAGに組み込まれ、常にメモリ上に存在します。適応型では、ルールは辞書のように必要なページだけが参照されます。
また、AI-DLCではルールブックの二層構造が採用されています。
aws-aidlc-rule-details/ ← ベースレイヤー (AI-DLC標準、変更不可) ga-aidlc-rule-details/ ← 拡張レイヤー (組織固有のカスタマイズ)
ベースレイヤーはフレームワーク標準のルールを提供し、拡張レイヤーが組織固有の知見やルールで補完します。この構造により、フレームワークの標準を維持しながら、各組織の業務に適応することが可能になります。オブジェクト指向プログラミングにおける継承とオーバーライドに似た仕組みです。
CursorにはCursor Rules (.cursor/rules/) があり、Amazon Q Developerには.amazonq/rules/があります。GitHub Copilotでは.github/copilot-instructions.mdが同様の役割を果たします。
ルール の例: - このプロジェクトはTypeScript + Next.jsで構成されている - テストはVitestを使用する - コミットメッセージはConventional Commitsに従う - 環境変数は.env.localから読み込む
状態 (State)
ワークフロー定義とルールブックで構成されるステアリングファイル以外に、セッションを超えて状態管理するためのファイルが構成されています。
AI-DLCには独自の状態機構があります。
- aidlc-state.md: 現在のフェーズ、完了したステージ、保留中のタスクなどの進捗状態を記録
- audit.md: すべてのユーザー入力とAI応答をタイムスタンプ付きで記録する監査証跡
# aidlc-state.md の例 ## Current Phase: CONSTRUCTION ## Completed Stages: - [x] Workspace Detection - [x] Requirements Analysis - [x] Workflow Planning - [x] Application Design ## Current Stage: Code Generation ## Pending Approvals: None
状態ファイルが果たす役割は、コンテキストウィンドウの限界を超えてAIワークフローの連続性を保つことです。人間の開発者がプロジェクトの議事録やWikiを参照しながら仕事を進めるように、AIも状態ファイルを参照しながら過去の判断や文脈を引き継ぎます。
例外：メモリ (Memory) ※コアなワークフローのみ定義することはできる
AIワークフローのセッション間で知識や状態を保持するメモリは、状態管理と似た仕組みですが、ステアリングファイルとして多用しすぎないようにしましょう。
メモリファイルはコーディングエージェントによって必ず読み込まれるという性質から、ワークフローが簡素な間は良いですが、工程によっては参照する必要がない詳細ルールを定義することは、トークンの肥大化を引き起こすため、避けたほうが良いです。コアのワークフローのみを定義したり、ワークフローを駆動する場合はXXXファイルを読むこと、とワークフローのエントリーポイントを記載しておくのはアリです。
Claude Codeでは複数のメモリ機構があります。
- プロジェクトメモリ:
CLAUDE.mdに蓄積されるプロジェクト固有の知識 - ユーザーメモリ:
~/.claude/CLAUDE.mdに保存されるユーザー固有の好み - オートメモリ:
~/.claude/projects/配下に自動保存される学習内容
2つのアプローチの構造的比較
ここまでの内容を整理します。
| 観点 | 事前定義型 (Dify等) | 適応型 (Claude Code + AI-DLC等) |
|---|---|---|
| 実行パスの決定 | 事前にDAGとして定義 | AIが実行時に決定 |
| 制御の粒度 | ノード単位 (細粒度) | 原則・制約単位 (粗粒度) |
| 変更への対応 | DAGの再設計が必要 | ルールの追記・修正で対応 |
| 構成ファイル | ワークフロー定義JSON/YAML | ステアリングファイル + ワークフロー定義 + ルールブック + メモリ |
| デバッグ | ノード単位でI/Oを確認 | 監査証跡 (audit.md) で判断過程を確認 |
| 再現性 | 高い (同一入力→同一パス) | 限定的 (同一入力でも判断が異なりうる) |
| スケーラビリティ | DAGの複雑化が課題 | ルールブックの肥大化が課題 |
| 学習コスト | 低い (ビジュアルエディタ) | 高い (ルール設計の知識が必要) |
| 適応力 | 低い (想定外に弱い) | 高い (未知の状況にも対応) |
具体例で見る違い
例: 「既存のREST APIにページネーション機能を追加する」
事前定義型の場合
Difyでこのタスクを自動化するなら、以下のようなワークフローを事前に構築します。
[要件入力] → [既存API仕様の読み込み] → [ページネーション設計の生成] → [コード生成] → [テストコード生成] → [レビュー用サマリー出力]
各ノードのプロンプト、入出力の形式、エラー時の分岐をあらかじめ定義しておきます。毎回同じ手順が実行され、出力の形式も一定です。
適応型の場合
Claude Code + AI-DLCでこのタスクに取り組むと、以下のような流れになります。
- Workspace Detection: プロジェクトを調査し、Express.jsのREST APIであること、既にいくつかのエンドポイントにページネーションが実装されていることを発見
- Requirements Analysis: 既存のページネーションパターンとの一貫性を確認し、cursor-basedかoffset-basedかの判断材料を整理
- Workflow Planning: 既存パターンがあるためFunctional Designはスキップ、Code GenerationとBuild and Testを実行すると判断
- Code Generation: 既存パターンに倣ってコードを生成
- Build and Test: 既存テストのパターンに合わせてテストを作成・実行
注目すべきは、ステップ1で「既にページネーションが実装されたエンドポイントがある」ことを発見した点です。この発見により、ステップ3でFunctional Designのスキップが判断されました。事前定義型では、この種の動的な判断を組み込むにはあらかじめ分岐条件を設計しておく必要がありますが、適応型ではAIが文脈から自然に判断します。
どちらを選ぶか ― 判断の指針
2つのアプローチは、対象とするタスクの性質によって使い分けるのが現実的です。
事前定義型が適しているケース
- タスクの手順が確立されており、大きく変わらない
- 入力と出力の形式が明確に定義できる
- 非エンジニアが構築・運用する
- 実行の再現性が厳密に求められる
- 複数のAPIやサービスの「接着剤」として機能する
適応型が適しているケース
- タスクがプロジェクトの状態に依存する (ソフトウェア開発そのものなど)
- 未知の状況への対応が求められる
- タスクの複雑さが事前に予測できない
- 文脈に応じた判断が必要
- 長期的なプロジェクトでセッションを跨いで作業する
まとめ
AIワークフローの2つのアプローチを整理しました。
事前定義型 (Pre-defined Workflow) は、DAGとしてワークフローを構築し、確定的なパスで処理を実行します。Difyに代表されるビジュアルビルダーが典型例です。再現性が高く、構築しやすいが、想定外の状況への適応力に限界があります。
適応型 (Adaptive Workflow) は、AIが状況に応じて実行パスを動的に決定します。Claude Codeのようなコーディングエージェントが典型的なツールであり、ステアリングファイル・ワークフロー定義・ルールブック・メモリの4つの構成要素によって操舵されます。適応力が高いが、設計と運用に深い理解が必要です。
重要なのは、どちらのアプローチを選んでも、「AIに何をさせるか」の設計が不可欠だということです。事前定義型ならDAGの設計が、適応型ならステアリングファイルとルールブックの設計が、最終的な品質を決定します。道具は変わっても、設計という営みの重要性は変わりません。
