ワークフロー
ワークフローは、繰り返し使える仕事の単位です。エージェントスキルと、あらかじめ設計されたタスクの一覧 — タスクテンプレート — を組み合わせたものです。テンプレートは実行の前に決まっているので、ワークフローを実行すると、毎回同じ手順を設計し直すことなく、すぐに作業が始まります。
管理サイドバーの Workflows を開くと管理できます。
ワークフローを何もないところから作る方法はありません。スキルから生成することが、ワークフローの生まれ方です。
ステータス
| ステータス | 意味 | 実行できる人 |
|---|---|---|
generating | 背景の設計実行がまだタスクテンプレートを書いています。 | なし |
draft | 設計はあるが、一度も公開されていないか、公開を解除された状態です。 | Developer と Super Admin(公開前のテスト用) |
failed | 設計実行がテンプレートを作らずに終わりました。理由は詳細ページと設計チャットに出ます。 | なし |
published | 設計が凍結され、実行できる状態です。 | requester 以上のロールを持つ全員 |
modified | 一度公開したあとに編集された状態です。実行には公開済みの版が使われます。 | published と同じ |
modified というステータスが見えるのは Developer、Reviewer、Super Admin だけです。それ以外の人にはこのワークフローは published として見え、名前・説明・タスクテンプレートはすべて最後に公開したときのものが表示されます。未公開の編集はその人たちが見るべきものではありませんし、見えている設計こそが実際にその人の実行で動く設計です。
画面
| 画面 | たどり方 | できること |
|---|---|---|
| Workflows 一覧 | 管理サイドバー → Workflows | 一覧、タグでの絞り込み、Run による実行 |
| ワークフローの詳細 | ワークフロー名をクリック | 項目の編集、Discard changes、Open design session(Developer);Publish、Deactivate(Reviewer) |
| Task Templates | 詳細ページの Task Templates へのリンク | 手作業でのステップの追加・編集・並べ替え(Table と Graph の 2 表示) |
| 設計セッション | 詳細ページの Open design session | 設計エージェントと会話しながらステップを詰める |
ワークフローのレコードは、Name、分類に使うタグ、従う Agent Skill、ステータス、Description、そして 2 つのプロンプトフィールドを持ちます。
ワークフローを生成する
Generate workflow は 2 か所から開けます。どちらもページを離れずに同じダイアログを開きます。エージェントスキル一覧の行の操作と、スキル詳細ページのヘッダーにある Generate Workflow のアイコンボタンです。どちらも、そのスキルがリビジョンを公開するまでは押せません。
- Workflow Name(スキル名が入っています)と、やってほしいことを書く Prompt を入力します。必要なら Knowledge Bases でナレッジベースも選べます。選んだものは新しいワークフローにすぐ紐付くので、最初の設計から設計エージェントが参照できます。生成すると画面が移るので、詳細ページから開いた場合は未保存の編集を先に保存するか尋ねられます。断るとページはそのままで、生成も行われません。
- ワークフローは
generatingとしてすぐ登録され、その詳細ページに移ります。詳細ページは処理の間、自分で表示を更新し続けます。 - 背景では、入力した Prompt がそのワークフローの設計セッションの最初のメッセージとして送られます。設計エージェントはスキルに従って依頼をステップに分解し、タスクテンプレートとして登録します。テンプレートは依存関係のグラフで、各ステップは自分より先に終わっているべきステップと、必要な MCP ツールを宣言します。
- 実行が終わると設計の会話が要約されて Generated prompt に入り、ワークフローを実行する人向けの短い Description もあわせて書かれ、ステータスが
draftになり、通知からワークフローへ直接戻れます。
実行が失敗した場合 — あるいはテンプレートを 1 つも登録せずに終わった場合 — ワークフローは理由つきで failed になり、通知でそれが伝わります。設計チャットはそのまま使えます。そこから、あるいは Task Templates の管理ページからタスクテンプレートを書けば、ワークフローは draft に戻り、失敗の記録も消えます。
Generate Workflow ダイアログに入力した Prompt 自体はワークフローには保存されません。設計の会話の最初のメッセージとして残り、生成された要約が意図を引き継ぎます。
説明とプロンプト
ワークフローは 2 種類の文章を持ちます。実行に影響するのはそのうち片方だけです。
| フィールド | 中身 | 書く人 | 編集できる人 | 見える人 |
|---|---|---|---|---|
| Description | ワークフローが何のためのものかを説明する文章。実行からは一切読まれません | 生成時に AI、その後は人 | Developer なら誰でも | ワークフローを開ける人全員 |
| Prompt | 生成プロンプトの上書き | 人。多くは AI の要約を手で直したもの | Developer なら誰でも | Admin、Developer、Reviewer |
| Generated prompt | AI が設計の会話を要約したもの | AI | Super Admin だけ | Admin、Developer、Reviewer |
有効なほうのプロンプトが、実行のたびに実行エージェントへ文脈として渡されます。Prompt が空でなければそちらが、空なら Generated prompt が使われます。上書きは要約の写しから始まることが多いので、Prompt には Show diff from the generated prompt の操作があり、2 つの単語単位の差分をダイアログで表示します。フォームの現在の値を読むので、未保存の編集も差分に出ます。
ワークフロー一覧に出るのは Description です。Run Workflow ダイアログでも確認文の下に表示されるので、実行する人は選んだワークフローが正しいか確かめられます。プロンプトのフィールドは、それ以外のロールには見えません。詳細ページ、一覧の任意列 Prompt、実行の詳細ページのいずれでも隠されます。
プロンプトを作り直す
タスクテンプレートを調整していくと AI の要約は古びるので、Generated prompt には Generate from the design conversation の操作があります。設計の会話をその場で要約し直し、結果をそのまま保存します。公開時の自動要約はありません。作り直すかどうか、いつ作り直すかは利用者が決めます。
同じ操作は設計セッションのチャット入力の「+」メニューからも使えます。こちらは保存の前に、詳細ページと同じ差分ダイアログで変更を確認できます。会話を離れずに作り直したいときに便利です。タスクテンプレートの生成中は、このメニューは出ません。
どちらも Developer の操作です。published のワークフローで要約を書き直すと modified になります。Prompt が空の実行は要約のほうを使うので、そのままだと公開済みの版と食い違ってしまうためです。
タスクテンプレートを調整する
下書きのタスクテンプレートは 2 通りの方法で詰められます。混ぜて使っても構いません。
チャットで。ワークフロー詳細ページの Open design session を押すと設計チャットが開きます。実行時と同じチャット画面で、左端にテンプレートの一覧が並び、設計エージェントがテンプレートを直接編集します。設計エージェントは何も実行しません。このセッションはテナントの Developer 全員(に加えて Super Admin とそのワークフローの作成者)で共有されるので、チームで設計を詰められます。共有チャットとしての挙動はワークフローセッションと同じで、メッセージごとの送信者アバターも付きます。Reviewer も同じチャットを開いて、公開するかどうかを決める前に履歴を読めますが、発言欄は表示されません。レビューは操作することではないからです。
手作業で。Task Templates のページには Table と Graph の 2 つの表示、新規作成フォーム、そして Depends on と MCP Tools のピッカーを持つテンプレートごとの詳細ページがあります。Graph 表示はテンプレートを依存順に縦 1 列に積み、それぞれが右へ、ツールを借りている MCP サーバー、さらに個々のツールへと枝分かれします。
テンプレートの構造は実行時のタスクと同じで、タイトル、説明、依存の辺、ツールの割り当てを持ちます。ただしステータスは持ちません。ライフサイクルは設計ではなく実行のものだからです。依存先は同じワークフローのテンプレートでなければならず、循環を作る辺は拒否されます。
公開する
ワークフロー詳細ページの Publish が、ワークフローを実行できる状態にする操作です。これは Reviewer の操作です。Developer はワークフローを作って編集しますが、もう公開はしません。設計を書いた人と、それを世に出す人を分けるためです。テンプレートが 1 つ以上あり、生成が走っていないことが条件です。
公開は設計を凍結します。ワークフローの名前、説明、有効なプロンプト、テンプレートの一覧(依存の辺とツールの割り当てを含む)が新しい公開済みの版(v1、v2、…)として取り込まれます。それより前の版は版の履歴に残ります。ここで AI は動きません。要約の作り直しは別の操作です。調整と再公開は何度でもできます。各実行はタスクの写しを持っているので、すでに始まっている実行は影響を受けません。
公開済みのワークフローを編集する
公開後の編集が、実行される内容を黙って変えることはありません。詳細フォームの保存、AI のプロンプトの作り直し、タスクテンプレートの追加・編集・削除 — 設計エージェントがチャットで加えた変更も含みます — はいずれもワークフローを modified にします。
modified の間 | |
|---|---|
| 実行が使うもの | 最後に公開した版の名前・有効なプロンプト・テンプレート。ただし Developer が編集内容を選んだ場合はその限りではありません(編集内容を試す) |
| 実行できる人 | published のときと同じです。Run ボタンの条件は変わりません |
| 編集内容が見える人 | Developer、Reviewer、Super Admin だけです |
| Publish(Reviewer) | 編集内容を以後の実行に反映し、他の人にも見えるようにします |
| Discard changes(Developer) | 編集を捨てます。テンプレートは公開済みの版から書き直され、名前と説明は元に戻り、公開済みの版のプロンプトが書き戻され、ワークフローは published に戻ります |
Discard changes は詳細ページのステータスバーの、Publish の隣にある取り消しアイコンです。未公開の変更がないワークフローで押しても、その旨が返るだけで何も起きません。
Developer と Reviewer のどちらのロールも持たない人には、この間ずっと公開済みの版が返ります。一覧と詳細ページの名前・説明も、Task Templates の画面も、さらには一覧で名前を検索したときにヒットする対象も公開済みの版です。ステータスは published と表示され、最後の公開より後に追加されたタスクテンプレートはそもそも存在しません。ですから作りかけの設計変更が、ワークフローを実行するだけの人を混乱させることはありませんし、その人に見えているものは常に実行される内容と一致します。
版の履歴とロールバック
公開した版はすべて残ります。ワークフロー詳細ページのヘッダーにある時計アイコン Version history を開くと、新しい順に、版の番号・名前・説明と、いつ誰が公開したかが並びます。見られるのは Admin、Developer、Reviewer、Super Admin だけです。Requester や Approver には時計アイコン自体が表示されません。
以前の設計に戻すには(Developer):
- Version history を開き、戻したい版の Restore を押します。
- 確認します。その版のテンプレート・名前・説明・プロンプトが今の設計を置き換え、ワークフローの画面に戻ります。
- 結果を確かめます。復元は公開しません。Reviewer が Publish を押すまで実行は今の公開済みの版を使い続け、押すと復元した設計が新しい版として記録されます。
| 復元前のステータス | 復元後のステータス |
|---|---|
published か modified | modified。ただし最新の版を復元した場合は、未公開のものが残らないので published |
draft | draft |
公開する前に気が変わったら、Discard changes で今の公開済みの版に戻せます。その後に削除された MCP サーバーのツールを割り当てている版は復元できず、エラーで拒否されます。
内部メモ
ワークフロー詳細ページの Internal notes には、ロールバックした理由など、ワークフローを運用するメンバーに伝えたいことを書いておけます。
| 見られる人 | Admin・Developer・Reviewer。それ以外の人には表示されません。 |
| 編集できる人 | 同じ 3 つのロール。欄に入力して、欄の保存アイコンを押します。 |
| ワークフローへの影響 | ありません。保存してもステータスは変わらず、実行がメモを読むこともありません。 |
| 版 | 版の管理対象ではありません。公開しても、版を復元しても、Discard changes をしても、メモはそのまま残ります。 |
公開を解除する
Deactivate は、ワークフローが published か modified のときに Publish の隣に現れる電源アイコンで、Publish と同じ Reviewer ロールが押せます。押すとワークフローは draft に戻ります。これで requester ロールの実行権限がなくなり、一度も公開していないワークフローと同じ状態になります。Developer と Super Admin はテストのために実行を続けられます。タスクテンプレート、2 つの説明フィールド、公開済みのスナップショットはそのまま残るので、もう一度公開すればすぐ元に戻ります。
ワークフローを実行する
ワークフロー一覧の Run を押すと、ワークフロー実行が作られます。実行はその時点のワークフローのスナップショットを持つ、独立したレコードです。
テスト実行では、実行ダイアログの Mock tools に、このワークフローのいずれかのタスクが使うツールのツールモックと、ビルトインツールのモックが並びます。チェックするとそのツールがこの実行の間だけ差し替えられるので、ツールの副作用なしに公開前のテストを何度でも繰り返せます。テスト実行とは、draft のワークフローか、modified のワークフローの未公開の編集内容(下記)を実行する場合です。それ以外ではモックは出ませんし、指定しても拒否されます。本物に見えて何もしなかった実行が返るくらいなら、実行しないほうがましだからです。
編集内容を試す
modified の間、ワークフローは 2 つの設計を抱えています。そのため実行ダイアログは Developer にどちらを実行するかを尋ねます。
| 選択肢 | 実行される内容 | 記録のされ方 |
|---|---|---|
| Published version | 最後に公開したときの設計。他の全員に見えているもの | 本番の申請として |
| Unpublished edits | いま編集中の設計そのもの | テスト実行として。ツールをモックでき、運用メトリクスからは除外されます |
初期選択は公開済みの版です。ここで本番の申請といえばそれを指すからです。編集内容を選ぶのは、設計変更を確定させる前に最後まで通しでリハーサルするためで、Developer の操作です。そもそも他の人にはその編集内容が見えません。draft や published のワークフローではこの選択肢は出ません。実行できる設計が 1 つしかないからです。
実行に必要なものは、開始時にすべて実行側へコピーされます。あとからの編集が実行に入り込むことはありません。
| 実行にコピーされるもの | どこから |
|---|---|
| 名前と有効なプロンプト | 最後に公開した版。 |
ただし draft のまま実行した場合、および Developer が未公開の編集内容を選んだ場合は編集中の内容 | |
タスクテンプレート。依存とツールの割り当てを持つ pending のタスクとして | 同じ設計 |
| 実行が固定されるエージェントスキルのリビジョン | スキルの公開済みリビジョン |
| 選んだツールモック。値として | その時点のモックの内容 |
そのあとワークフローセッション — 実行が進むチャット — に移ります。決まった開始メッセージが自動で送られ、エージェントはすぐに作業を始めます。タスクは公開によって承認済みなので、改めて確認するものがないからです。ここから先は普通のチャットと同じで、描画される対話的な画面やその中のボタンも使えます。この画面についてはワークフロー実行で説明します。
エージェントがタスクを進める仕組み
実行エージェントは実行のタスクを一覧し、次に着手できるもの — 依存がすべて完了している pending のタスク — を選び、in_progress にし、スキルの指示どおりに作業して、completed、failed、skipped のいずれかにします。すべてのタスクが終端の状態になると、実行の完了が通知されます。
ステータスが変わっていく様子は、実行の読み取り専用の Workflow Tasks 表示(Table と Graph)で追えます。実行のタスク一覧は固定です — ワークフローを公開したときに凍結されたものです — ので、エージェントは各タスクのステータスを進めるだけで、タスクを追加したり削除したりはしません。
時刻を待つ必要があるタスク。 実行時刻の要件はタスクの説明にそのまま書きます。たとえば「明日の 9:00 以降に実行」「月初より前には実行しない」のように書きます。指定の時刻より前にそのタスクの番が来ると、エージェントはタスクを pending のまま残し、いつ再開するかをチャットで伝えて止まります。それまでセッションは Scheduled と表示され、時刻になると A2Flow が自動で再開します。チャットを開いておく必要はありません。タイムゾーンを書いていない時刻は、デプロイの現地タイムゾーンとして解釈されます。待っている間も、別のセッションが担当するブランチは進みます。待機中のセッションにメッセージを送ると、すぐに再開します。
タスクが使う MCP ツール
タスクは MCP サーバーに登録されたサーバーのツールを使えます。ツールは設計時に割り当てられ、実行時に検査されます。
設計中、エージェントは、あなたが見られるサーバーが公開しているツール(あなたに見えないサーバーは、アクセス制御タグによって一覧から外れます)を一覧し、必要なものをステップに与えられます。この割り当てはテンプレートに保存され、実行開始時にその実行のタスクへコピーされます。
実行時は、サーバーに届く前にすべての呼び出しが検査されます。その (サーバー, ツール) の組が、現在進行中のタスクに割り当てられていなければなりません。割り当てのないツールへの呼び出しは、使えるツールを列挙したメッセージとともに拒否されます。ワークフロー間で共有されるエージェントでも、そのタスクに与えられていないツールには手が届きません。承認が紐づいているタスクは、それによっても止められます。
手作業でツールを割り当てる。テンプレートのフォームにある MCP Tools のピッカーは 2 段階です。まずページ送りのあるダイアログでサーバーを選び、次にそのサーバーのツールをドロップダウンから追加します。追加したツールは削除できるチップになります。問い合わせるのは選んだサーバーだけなので、フォームを開くだけで登録済みの全サーバーに接続しにいくことはありません。到達できないサーバーはツール一覧の代わりにその旨を表示しますが、すでに割り当て済みのツールのチップはそのまま残ります。割り当てたツールは、Task Templates と Workflow Tasks の一覧の Tools 列にチップとして出ます。
入力の承認が要らないツール。Selected Tools に並ぶ各ツールのチップには、削除ボタンの隣に小さな盾のボタンが付いています。これを押すと、そのツールを呼ぶときの値は、このステップを覆う承認で人が同意する対象から外れます。承認そのものは変わらず必要で、ステップは承認が下りるまで待ちます。ボタンのアイコンと色はツールの現在の状態に応じて変わり、マウスを乗せると今の状態と押した場合の動作が表示されます。
押してよいのは、読むだけのツールです。一覧、参照、状態の確認などが該当します。理由は 2 つあり、どちらも読み取り専用の作業に固有のものです。
| 判断する材料がない | 何も変えない問い合わせの引数に、同意を求める意味がない |
| 値が事前に決まらない | 次に何をするか決めるために調べるステップは、何を尋ねるか前もって書けない |
書き込む、消す、費用が発生する、送信する — こうしたツールは既定の状態のままにします。既定は「承認が必要」なので、追加しただけのツールは入力が縛られた状態のままです。「承認が不要」に切り替えたツールは、実行時の承認で Any input と表示されます。どのツールが縛られていないかを、承認する人が推測せずに済むようにするためです。
申請者に質問するツール。ツールの中には、呼び出しの途中で止まり、ワークフローを動かしている人に質問するものがあります。たとえば Azure MCP Server は、シークレットに対する操作のたびに同意を求めます。どのタスクのツールがそうなのかを、ワークフロー生成時のプロンプトかデザインセッションでデザインエージェントに伝えると、エージェントがそのツールに「質問する」印を付けます。そうしたツールを持つステップは、始まる前に申請者の再開を待つので、申請者はチャットで答えられます(MCP サーバーからの確認)。印のないツールは質問できません。管理画面のフォームにこの印を操作する項目はなく、デザインエージェントが付けた印をそのまま保ちます。実行のタスクタイムラインでは、Bound tools ダイアログにそうしたツールが Asks the initiator mid-call と表示されます。
タスクのタイトル。この 2 つの一覧はページ送りをせず全件を表示します。おかげで Depends on 列が相互参照として働きます。依存はタイトルで示され、そのチップにマウスを乗せると、指している行が強調されます。設計エージェントには簡潔な命令形のタイトル — 2〜4 語、50 文字 — が課されていて、チップとして読みやすく収まります。長すぎるタイトルは、詳細は説明のほうに書くよう促すメッセージとともに拒否されます。この制限がかかるのはエージェントだけです。管理フォームから編集するタイトルは 200 文字まで使えます。チップからあふれたタイトルは省略され、マウスを乗せると全体が出ます。
ナレッジベース
ワークフローの詳細ページの Knowledge Bases でナレッジベースを選んで Save を押すと、設計エージェントと実行エージェントが作業中にそこを調べるようになります。詳しくはナレッジベースを参照してください。この選択は公開済みの設計には含まれないので、変えてもワークフローが modified になることはありません。
ワークフローを削除する
ワークフローを削除すると、そのタスクテンプレート、公開済みの版、設計セッションも一緒に消えます。すでにあるワークフロー実行は残ります。実行はそれぞれ自分のスナップショットを持っているので、元のワークフローがなくなっても実行の履歴は読めます。