Dynamic Workflowsは、すべてのDevinセッションで利用できます。作業内容を説明し、ワークフローとして実行するようDevinに依頼するだけです。Enterprise アカウント:Enterprise 管理者がEnterprise Settings > DevinでDynamic workflowsを有効にするまで、この機能は無効です。それまでは、DevinはEnterprise内のどの組織でもワークフローを実行しません。
Dynamic Workflows とは?
Dynamic Workflow は、Devin エージェントのチームをオーケストレーションする決定論的な Python スクリプトです。Devin がこのスクリプトを作成・実行し、どの エージェントをどの順序で実行するか、各 エージェントに何を指示するかを決定します。また、先行する エージェントの構造化された結果を利用して、後続の エージェントへのプロンプトを組み立てます。 すべての エージェント呼び出しは記録されるため、ワークフローの run は実行中に監視でき、中断された場合も再開できます。完了済みの エージェントは記録された結果を即座に再利用し、未完了の作業のみが再実行されます。 これは、調整役のセッションが 子セッションを手動で 起動して管理する 管理対象の Devin の一歩先を行く仕組みです。ワークフローでは、オーケストレーション自体がコードになります。Dynamic Workflows の仕組みと活用場面(12 個のコンポーネントを対象としたアクセシビリティレビューの例)
ワークフローを利用するタイミング
作業に明確な構造がある場合は、ワークフローを利用してください。- 広範な並列作業と統合ステップ — それぞれに判断や検証を要する、ファイル、モジュール、エンドポイント、チケットなどの独立した作業単位が概ね5つ以上あり、その結果を集約する場合。
- 段階的な パイプライン — 後続の段階で前段階の構造化出力を利用する場合。たとえば、監査 → 対処 → 検証。
- 変更が機械的な場合 — codemod、linter の自動修正、またはジェネレーターのほうが エージェントよりも速く、確実に処理できます。
- データの受け渡しがなく、必要な独立したセッションが1つまたは2つだけの場合。
- 作業が共有状態を介して密結合している場合、または小規模で順次進められる場合。
プロンプトの例
タスクを説明してワークフローを依頼すると、Devin がスクリプトを作成します。 移行 — 各ユニットごとに専用ブランチでエージェントを 1 つずつ並列に実行し、その後結果を集約します。runの流れ
- Devin がスクリプトをファイルに書き込み、run を開始します。run はデフォルトで自動承認されます。run ごとに Devin に承認を求めさせたい場合は、Settings → Preferences → Auto-approve workflows をオフにしてください。
- **スクリプトは Devin’s マシン で実行されます。**ワークフローのプリミティブは自動的に組み込まれるため、インストールやインポートは必要ありません。
- エージェント呼び出しごとにエージェントが起動され、その構造化出力が返されるのを待ちます。デフォルトでは、そのエージェントは専用の VM 上で動作する独立した Devin セッションです。
- **進行状況はセッションにストリーミングされます。**ワークフローパネルには各フェーズ、エージェント、ライブステータスが表示され、そこから任意のエージェントのセッションを開けます。
- **結果はrun ID に紐づけて記録されます。**これによりrunを再開できます。
オーサリングモデル
スクリプトは通常のPythonです。Devinが作成しますが、レビューする際はその構成を把握しておくと役立ちます。
各
agent()呼び出しはJSON Schemaを受け取り、それに従ったdictを返します。これにより、あるステージの検出結果を次のステージのプロンプトに渡せます。スキーマは小さく、フラットに保ってください。
例
3つのモジュールにまたがる、監査してから修正するパイプライン:エージェントの実行場所
各エージェントはデフォルトで専用の VM 上で実行されますが、オーケストレーション元のセッションのマシンに固定することもできます。専用 VM(デフォルト)
専用のマシン、リポジトリのクローン、環境を備えた完全な子 Devin セッションです。オーケストレーション元のセッションのファイルにはアクセスできないため、コードの受け渡しは git ブランチを介して行われます。各エージェントはブランチをプッシュしてその名前を報告し、後続のステージは構造化出力からその名前を読み取ります。
共有 VM
エージェントはオーケストレーション元のセッションのマシン上で実行され、未コミットの変更を含む作業ツリーを共有します。git による受け渡しは不要です。エージェントが現在の作業ツリーを読み取りまたは編集する必要がある場合や、リポジトリがそのマシン上にしか存在しない場合に利用します。
決定性と再開
ワークフロースクリプトは、run を再開すると先頭から再実行されます。各 エージェント呼び出しは、プロンプト、スキーマ、実行設定の hash によって識別されます。すでに完了した処理は記録された結果を再利用し、残りは新しいセッションで実行されます。 これは、スクリプトが毎回同じ呼び出しを行う場合にのみ機能します。ワークフローのロジックと プロンプトは、現在の時刻や日付、乱数、生成された ID、環境変数、ファイルシステムの状態、ネットワーク応答に依存してはなりません。外部の状態を確認する必要がある処理は、agent() 呼び出し内で行う必要があります。その記録済み出力を、スクリプトの残りの部分で利用します。
知っておくべき点は2つあります。
- プロンプトを編集すると、その エージェントとそれ以降のすべてが再実行されます。変更していない前段の エージェントは引き続き記録済みの結果を再利用します。
- タイムアウトまたは中断した run は、run ID を指定して再開すると中断した箇所から続行されます。run のデフォルトおよび最大予算は7日間です。
コスト
ワークフロー内の各エージェントはDevinセッションであるため、1回の実行で、同じタスクを単一のセッションで実行するよりもはるかに多くのACUを消費する可能性があります。ワークフローをリポジトリ全体に適用する前に、1つのディレクトリ、3つのモジュール、より限定的な質問など、一部の範囲で実行し、ワークフローパネルでエージェントのACU使用量を確認してください。アイテムごとの分類など、大量処理を行うステージでは、より安価なモードを選択することでも、大規模なファンアウトのコストを抑えられます。再利用するワークフローの保存
ワークフローが動作したら、使用するタイミングを記述したSKILL.mdとともにworkflow.pyをスキルとしてリポジトリにコミットできます。Devinは以後のタスクで新しいスクリプトを作成する代わりに、このスキルを検出して再実行します。Devinにワークフローの保存を依頼すると、必要なファイルが作成されます。
関連項目
- Advanced Capabilities — 管理対象のDevinを直接オーケストレーション
- Skills — ワークフローを含む再利用可能な手順をリポジトリに保存
- Devin MCP — プログラムからセッションを作成・監視

