Skip to main content
Dynamic Workflowsは、すべてのDevinセッションで利用できます。作業内容を説明し、ワークフローとして実行するようDevinに依頼するだけです。

Dynamic Workflows とは?

Dynamic Workflow は、Devin エージェントのチームをオーケストレーションする決定論的な Python スクリプトです。Devin がこのスクリプトを作成・実行し、どの エージェントをどの順序で実行するか、各 エージェントに何を指示するかを決定します。また、先行する エージェントの構造化された結果を利用して、後続の エージェントへのプロンプトを組み立てます。 すべての エージェント呼び出しは記録されるため、ワークフローの run は実行中に監視でき、中断された場合も再開できます。完了済みの エージェントは記録された結果を即座に再利用し、未完了の作業のみが再実行されます。 これは、調整役のセッションが 子セッションを手動で spawn して管理する managed Devins の一歩先を行く仕組みです。ワークフローでは、オーケストレーション自体がコードになります。

ワークフローを利用するタイミング

作業に明確な構造がある場合は、ワークフローを利用してください。
  • 広範な並列作業と統合ステップ — それぞれに判断や検証を要する、ファイル、モジュール、エンドポイント、チケットなどの独立した作業単位が概ね5つ以上あり、その結果を集約する場合。
  • 段階的な パイプライン — 後続の段階で前段階の構造化出力を利用する場合。たとえば、監査 → 対処 → 検証
次の場合は、通常のセッション (または複数のmanaged Devins) を利用してください。
  • 変更が機械的な場合 — codemod、linter の自動修正、またはジェネレーターのほうが エージェントよりも速く、確実に処理できます。
  • データの受け渡しがなく、必要な独立したセッションが1つまたは2つだけの場合。
  • 作業が共有状態を介して密結合している場合、または小規模で順次進められる場合。

プロンプトの例

タスクを説明してワークフローを依頼すると、Devin がスクリプトを作成します。 移行 — 各ユニットごとに専用ブランチでエージェントを 1 つずつ並列に実行し、その後結果を集約します。
調査 — 証拠を並行して収集し、統合する:
コードレビュー — ファイルごとにレビュアーを1人割り当て、その後マージする:
コードベース全体の監査監査 → 修正 → 検証の段階的なパイプライン:
ループ — チェックに合格するか、進行が停滞するまで繰り返します:

実行の流れ

  1. Devin がスクリプトをファイルに書き込み、実行を開始します。Settings → Preferences → Auto-approve workflows で自動承認を有効にしている場合を除き、まず承認が必要です。
  2. **スクリプトは Devin’s machine で実行されます。**ワークフローのプリミティブは自動的に組み込まれるため、インストールやインポートは必要ありません。
  3. エージェント呼び出しごとにエージェントが起動され、その構造化出力が返されるのを待ちます。デフォルトでは、そのエージェントは専用の VM 上で動作する独立した Devin セッションです。
  4. **進行状況はセッションにストリーミングされます。**ワークフローパネルには各フェーズ、エージェント、ライブステータスが表示され、そこから任意のエージェントのセッションを開けます。
  5. **結果は実行 ID に紐づけて記録されます。**これにより実行を再開できます。
実行はバックグラウンドで行われるため、セッションは応答可能なままです。実行中も Devin との会話を続けたり、進行状況の要約を求めたり、実行の停止を依頼したりできます。停止するとスクリプトはキャンセルされ、残りの子セッションはスリープ状態になります。すでに記録された内容はすべて再開可能なままです。

オーサリングモデル

スクリプトは通常のPythonです。Devinが作成しますが、レビューする際はその構成を把握しておくと役立ちます。 agent()呼び出しはJSON Schemaを受け取り、それに従ったdictを返します。これにより、あるステージの検出結果を次のステージのプロンプトに渡せます。スキーマは小さく、フラットに保ってください。

3つのモジュールにまたがる、監査してから修正するパイプライン:

エージェントの実行場所

各エージェントはデフォルトで専用の VM 上で実行されますが、オーケストレーション元のセッションのマシンに固定することもできます。

専用 VM(デフォルト)

専用のマシン、リポジトリのクローン、環境を備えた完全な子 Devin セッションです。オーケストレーション元のセッションのファイルにはアクセスできないため、コードの受け渡しは git ブランチを介して行われます。各エージェントはブランチをプッシュしてその名前を報告し、後続のステージは構造化出力からその名前を読み取ります。

共有 VM

エージェントはオーケストレーション元のセッションのマシン上で実行され、未コミットの変更を含む作業ツリーを共有します。git による受け渡しは不要です。エージェントが現在の作業ツリーを読み取りまたは編集する必要がある場合や、リポジトリがそのマシン上にしか存在しない場合に利用します。
共有 VM のエージェントはセッションと CPU、メモリ、ディスクを共有するためリソースを奪い合い、同時実行数の上限も低くなります。分離されていない単一の作業ツリーを共有するため、並列で書き込むエージェントには、重複しないファイルまたはディレクトリを厳密に割り当てる必要があります。 エージェントは特定の Devin モードに固定することもできます。たとえば、大規模なファンアウトで項目ごとの分類を行う場合は、より低コストな Devin Lite を利用できます。

決定性と再開

ワークフロースクリプトは、run を再開すると先頭から再実行されます。各 エージェント呼び出しは、プロンプト、スキーマ、実行設定の hash によって識別されます。すでに完了した処理は記録された結果を再利用し、残りは新しいセッションで実行されます。 これは、スクリプトが毎回同じ呼び出しを行う場合にのみ機能します。ワークフローのロジックと プロンプトは、現在の時刻や日付、乱数、生成された ID、環境変数、ファイルシステムの状態、ネットワーク応答に依存してはなりません。外部の状態を確認する必要がある処理は、agent() 呼び出し内で行う必要があります。その記録済み出力を、スクリプトの残りの部分で利用します。 知っておくべき点は2つあります。
  • プロンプトを編集すると、その エージェントとそれ以降のすべてが再実行されます。変更していない前段の エージェントは引き続き記録済みの結果を再利用します。
  • タイムアウトまたは中断した run は、run ID を指定して再開すると中断した箇所から続行されます。run のデフォルトおよび最大予算は7日間です。
エージェントが失敗した場合 (セッションが終了した、または有効な構造化出力を生成しなかった場合) 、その後の動作はスクリプトで決定します。項目をスキップする、default を代入する、再試行する、または run を失敗させる、のいずれかです。再開した run では、失敗した エージェントが新しいセッションで再試行されます。

コスト

ワークフロー内の各エージェントはDevinセッションであるため、1回の実行で、同じタスクを単一のセッションで実行するよりもはるかに多くのACUを消費する可能性があります。ワークフローをリポジトリ全体に適用する前に、1つのディレクトリ、3つのモジュール、より限定的な質問など、一部の範囲で実行し、ワークフローパネルでエージェントのACU使用量を確認してください。アイテムごとの分類など、大量処理を行うステージでは、より安価なモードを選択することでも、大規模なファンアウトのコストを抑えられます。

再利用するワークフローの保存

ワークフローが動作したら、使用するタイミングを記述したSKILL.mdとともにworkflow.pyスキルとしてリポジトリにコミットできます。Devinは以後のタスクで新しいスクリプトを作成する代わりに、このスキルを検出して再実行します。Devinにワークフローの保存を依頼すると、必要なファイルが作成されます。
  • Advanced Capabilities — 管理対象のDevinを直接オーケストレーション
  • Skills — ワークフローを含む再利用可能な手順をリポジトリに保存
  • Devin MCP — プログラムからセッションを作成・監視