検証済みの作業方法を再現可能な実行可能なワークフローに変換し、入力値、Waker、確認、実行履歴、自動トリガーを管理します。
WakerFlow は、検証済みの作業方法を再現可能な実行可能なワークフローに変換します。各実行では構造化された入力値を収集し、ステージごとに割り当てられた Waker を呼び出し、逐次処理、並列処理、分岐、人間の確認を制御し、1 つの定義された結果を返します。実行順序と成果物の形式を実行ごとに安定させたい場合に使用してください。未検証または曖昧なタスクを安定的にするために使用するものではありません。
フローを作成する前に、各参加 Waker を小さなタスクで検証してください。責任範囲、ワークスペース、Skills、Connectors、権限を確認します。ワークフローが確実に再利用できるのは、すでに明確になっている作業方法だけです。
実用的な進め方は、まず Chat で 1 つの Waker を検証し、次に Group で複数役割の作業を検証してから、安定した手順を WakerFlow として形式化することです。1 つの Waker による 1 ステップのタスクで構造化された入力がない場合、通常はワークフローは不要です。
パス: 左ナビゲーション → Capabilities & Resources → WakerFlow。管理ページからフローを作成したり、参加 Waker を確認したり、既存のフローを開いたり、自動トリガーを管理したりします。
既存のフローを編集する前に、その説明、入力値、割り当てられた Waker、最近の実行を確認してください。名前だけが動作を定義するわけではありません。入力フィールド、実行ノード、最終的な return 値が動作を定義します。
生成結果を修正する必要がある場合は、一度に 1 種類の問題だけを変更してください。たとえば、2 つの抽出ノードを並列にする、レビューノードを QA Waker に割り当てる、公開前に確認を追加するなどです。ノード、入力、出力を同時に変更すると、検証が難しくなります。
Canvas は構造を説明しますが、Script が実行可能な定義です。Script を変更した後は、Canvas と実行フォームがそれと一致していることを確認してください。
実行ごとに変化する値のみを入力フィールドとして定義します。各フィールドには、安定した名前、型、説明、必須かどうか、適切な場合は安全なデフォルト値を設定します。
入力フィールドを変更すると、手動実行フォームとフローを呼び出すすべての Autonomous Work アイテムに影響する可能性があります。入力を変更した後は、すべての呼び出し元を確認してください。
複数の Waker が同じディレクトリを共有する場合は、1 人を主な編集者と定義し、他は読み取り専用またはレビュー中心にします。並列に書き込むと同じファイルを上書きする可能性があります。1 つのステージに複数の並列 Waker ノードを含めることはできますが、最終成果物を複数のノードで編集させるのではなく、後のステージで統合してください。
最後の
オブジェクトや配列の入力値には有効な JSON が必要です。フィールドの欠落、不正な JSON、型の不一致があると、送信が妨げられるか検証エラーが発生します。
実行状態に応じて次のアクションを決定してください。
初回の検証では、通常の入力、欠落フィールド、無効な入力、人間の確認パス、1 つの Waker ノードの失敗をカバーすべきです。
Configuration summary は完全な入力ではなく、Business log も完全な出力ではありません。入力には Run configuration、提供には Final result と成果物、ノードレベルのトラブルシューティングには Waker chat を使用してください。
Waiting for input は失敗ではありません。フローは必要な値や人間の判断を待っている可能性があります。調査が必要なのは、ノードが失敗を報告した場合、またはフローが予期せず終了した場合のみです。
Terminate は以降の実行を停止しますが、すでに書き込まれたファイル、送信されたメッセージ、完了した外部アクションを取り消すわけではありません。Terminate する前に、手動でのクリーンアップやロールバックが必要か判断してください。
Retry は同じ実行内ですでに完了したノードを再利用できます。Retry は、入力とスクリプトが変更されていない一過性の失敗後にのみ使用してください。入力、ワークフロースクリプト、ノード設定を変更した場合は、新しい実行を開始して古い結果を引き継がないようにしてください。
最初の異常なノードから調査を始めます。
ワークフロースクリプトはノードエラーをキャッチして続行できます。したがって、全体の状態が Completed になっていても、実行には N-failure バッジが表示されることがあります。これはエンジンが終了したことを意味し、すべての業務ステップが成功したことを意味するわけではありません。全体の状態、失敗数、最終 return 値、実際の成果物を合わせて検証してください。
失敗した Action ノードを開き、その名前、エラーサマリー、エラー詳細、入力パラメータ、利用可能な出力を確認します。Waker ノードやサブフローの失敗もカウントに含まれることがあります。ページに詳細が表示されない場合は、該当する Waker chat またはサブフローの実行を開いてください。
失敗した Action ノードに Improve workflow from this failure が表示される場合、そのノードのエラーと実行コンテキストを編集可能なドラフトに取り込みます。ドラフトを送信したり、ワークフローを自動的に変更したりすることはありません。
意味のある変更のたびに、分かりやすいバージョンを保存し、その説明に理由を記録します。
Run history に切り替えると、選択した実行のステージと Waker ノードの状態が左側に、時系列の実行リストが右側に表示されます。
WakerFlow は Autonomous Work の実行対象になります。スケジュール、イベント、API トリガーでは、Run WakerFlow を選択し、必要なワークフロー入力を固定値またはトリガーフィールドにマッピングします。
このページはワークフロー構造、入出力設計、失敗診断を担当します。トリガーのタイミング、実行制限、API アクセスの設定は Autonomous Work で行います。
まず手動実行を完了させ、その後限定されたテストで実際のトリガーを検証してください。フローに human-confirmation ノードが含まれる場合、自動実行はそのノードで一時停止します。判断を迂回することはありません。
WakerFlow の使用場面
| 作業モード | 向いている用途 | 主な特徴 |
|---|---|---|
| One Waker chat | 頻繁に質問や調整を伴う探索的な作業 | 最も柔軟で、タスクが実行可能かを検証できる |
| Group | Leader が動的に作業を割り当てながら、複数の Waker が 1 つの目標に向けて協働する | オープンエンドな協働と継続的な議論 |
| WakerFlow | ステージ、依存関係、入出力を実行ごとに一貫させたい | 並列処理、分岐、人間のゲートを含む明示的な実行経路 |
| Autonomous Work | スケジュール、イベント、API 呼び出しで安定的なタスクを開始する | 開始タイミングを制御する。対象は Waker または WakerFlow |
WakerFlow を開く
パス: 左ナビゲーション → Capabilities & Resources → WakerFlow。管理ページからフローを作成したり、参加 Waker を確認したり、既存のフローを開いたり、自動トリガーを管理したりします。
フローを作成する
- New WakerFlow を選択して空のキャンバスを開きます。
- Chat パネルで、目的、変化する入力値、ステージ、Waker の割り当て、エラー処理、人間の確認、最終出力を説明します。
- QoderWake がスクリプト、ステージ、Waker ノードを生成するまで待ちます。同じリクエストを繰り返し送信しないでください。
- スコープと除外事項の両方を説明する、明確な名前と説明を付けます。
- キャンバス上でステージの順序、並列関係、各ノードに割り当てられた Waker を確認します。次にスクリプトと実行設定を確認します。
- 自動トリガーを追加する前に、保存して手動テストを実行します。
エディタを理解する
| エリア | 目的 |
|---|---|
| Canvas | ステージ、Waker ノード、並列分岐、依存関係を確認する |
| Script | 実行可能な定義、入力、出力、ロジックを確認・編集する |
| Chat panel | 自然言語でフローを作成・修正し、生成状況を確認する |
| Run configuration | 手動実行に必要なフィールドを確認する |
| Version history | 保存されたワークフローバージョンを比較・復元する |
| Run history | 各実行の入力、ノードの状態、結果を確認する |
生成されたフローを修正する
- ステージまたは Waker ノードを選択し、Chat パネルで正確な変更を説明します。例: 「ステージ 02 のみを変更し、そのレビュー結果をステージ 03 に渡す」。
- 構造的な変更を行う場合は、残すステージ、追加または削除するノード、入出力の互換性を保つ必要があるかどうかを明記します。
- Script を直接編集した後は、まずパーサーエラーを解決し、その後 Canvas、実行設定、最後の
returnを再確認します。 - 検証可能な変更のグループごとにバージョンを保存し、未検証の修正を重ねすぎないようにします。
実行入力値を設定する
実行ごとに変化する値のみを入力フィールドとして定義します。各フィールドには、安定した名前、型、説明、必須かどうか、適切な場合は安全なデフォルト値を設定します。
| 設定 | ガイダンス |
|---|---|
| Field name | 後で自動マッピングが壊れないよう、安定した識別子を使用する |
| Description | 入力内容と想定される形式を説明する |
| Required | その値なしではフローが完了できない場合に有効にする |
| Default | 長期間有効な安全な値のみを使用する |
| Sensitive data | パスワード、トークン、顧客データを通常のデフォルトとして保存しない |
ステージと Waker を設定する
- Stage: 情報収集、分析、レポート生成などの業務ステップ。
- Waker node: 特定のタスクを実行するノード。責任範囲が明確な利用可能な Waker を 1 つ割り当て、ノードの入力、作業内容、成果物を定義する。
- Parallel: 作業項目が独立している場合に使用する。
- Sequential: 後のステップが前の結果に依存する場合に使用する。
- Branch: 構造化された条件からパスを選択し、デフォルト処理とエラー処理を含める。
- Human confirmation: コードのマージ、リリース、削除、外部公開、その他の重要なアクションの前に一時停止する。
| 項目 | 確認内容 |
|---|---|
| Node name | 期待される成果物がすぐに理解できる |
| Task instruction | 必要なワークフロー入力と上流の結果が参照されている |
| Assigned Waker | 責任範囲、実行環境、可用性がタスクに適合している |
| Workspace | 正しいプロジェクトが利用可能で、並列ノードが同じファイルに書き込まない |
| Downstream result | 次のステージが利用できるだけ構造化されている |
出力を定義する
最後の return は、内部の実行ログではなく、ビジネスユーザーが必要とするものを返すべきです。含めるべき内容は次のとおりです。
- ビジネス上の結論または構造化されたフィールド
- 生成された成果物へのアクセス可能なリンクまたは場所
- 検証結果、未解決の問題、必要な人間によるアクション
return がなくても実行は成功と報告されることがありますが、最終結果は null になる可能性があります。提供を意図した内容がビジネスログにのみ存在してはいけません。
手動で実行する
- Run を選択し、すべての必須フィールドを入力します。
- この実行にとってデフォルト値が適切かどうかを確認します。
- 割り当てられた Waker、プロジェクト、モデル、Connectors が利用可能か確認します。
- 実行を開始し、Run history を開いてアクティブなステージとノードを追跡します。
- 確認が求められた場合は、コンテキスト、影響、選択肢を読んでから判断します。
- 完了後、最終結果を確認し、実際の成果物を開きます。
| 状態 | 意味 | 次のアクション |
|---|---|---|
| Queued / Running | 実行が存在し、進行中 | 変化が止まった場合は、アクティブなノードとサービス状態を確認する |
| Waiting for input | 人間の回答または確認が必要 | 実行を開いて回答する。失敗とは扱わない |
| Completed | ワークフロースクリプトが終了した | 最終結果、必須フィールド、実際の成果物を検証する |
| Completed · N failures | ワークフローは終了したが、1 つ以上のノードが失敗したか失敗結果を返した | 失敗したノードを開く。「Completed」だけで実行を承認しない |
| Failed / Terminated | ノードが失敗したか、実行がキャンセルされた | 最初の異常なノードから調査し、原因を修正して再実行する |
設定、ログ、結果を理解する
| 情報 | ソース | 完全性 | 用途 |
|---|---|---|---|
| Run configuration | 送信されたフィールドとデフォルト値 | 完全 | 実行入力を再現する |
| Configuration summary | システム生成の概要 | 要約または切り捨てられる場合がある | 主要な設定を素早く確認する |
| Node state | ワークフローエンジン | 実行状態 | 実行中、待機中、成功、失敗のノードを特定する |
| Business log | 明示的なワークフローまたは Waker の出力 | フローがログに選択した内容のみ | ビジネス上の進捗と主要な判断を追跡する |
| Waker chat | 実際の Waker セッション | ノードレベルのコンテキスト | 入力、ツールアクティビティ、応答を確認する |
| Final result | ワークフローの return 値 | 公式な返却値 | 実行結果を提供する |
待機と失敗への対処
Waiting for input は失敗ではありません。フローは必要な値や人間の判断を待っている可能性があります。調査が必要なのは、ノードが失敗を報告した場合、またはフローが予期せず終了した場合のみです。
Terminate は以降の実行を停止しますが、すでに書き込まれたファイル、送信されたメッセージ、完了した外部アクションを取り消すわけではありません。Terminate する前に、手動でのクリーンアップやロールバックが必要か判断してください。
Retry は同じ実行内ですでに完了したノードを再利用できます。Retry は、入力とスクリプトが変更されていない一過性の失敗後にのみ使用してください。入力、ワークフロースクリプト、ノード設定を変更した場合は、新しい実行を開始して古い結果を引き継がないようにしてください。
最初の異常なノードから調査を始めます。
- ノードが受け取った入力を確認する。
- ノードに割り当てられた Waker が有効であり、デバイスがオンラインか確認する。
- ワークスペース、Skill、Connector、権限を確認する。
- スクリプトの分岐が現在の入力をカバーしているか確認する。
- 問題を修正し、同じテスト入力で再実行する。
「Completed with failures」を正しく理解する
ワークフロースクリプトはノードエラーをキャッチして続行できます。したがって、全体の状態が Completed になっていても、実行には N-failure バッジが表示されることがあります。これはエンジンが終了したことを意味し、すべての業務ステップが成功したことを意味するわけではありません。全体の状態、失敗数、最終 return 値、実際の成果物を合わせて検証してください。
失敗した Action ノードを開き、その名前、エラーサマリー、エラー詳細、入力パラメータ、利用可能な出力を確認します。Waker ノードやサブフローの失敗もカウントに含まれることがあります。ページに詳細が表示されない場合は、該当する Waker chat またはサブフローの実行を開いてください。
失敗したノードから改善する
失敗した Action ノードに Improve workflow from this failure が表示される場合、そのノードのエラーと実行コンテキストを編集可能なドラフトに取り込みます。ドラフトを送信したり、ワークフローを自動的に変更したりすることはありません。
- 参照されているノード、エラー、実行を確認し、含めるべきでない機密性の高い入力を削除する。
- 期待される動作、許可されるステージ、受け入れ基準を追加する。
- リクエストを送信し、提案された変更を確認してから新しいバージョンを保存する。
- 同じ入力で再実行し、失敗したノードと最終成果物を比較する。
バージョン履歴を使用する
意味のある変更のたびに、分かりやすいバージョンを保存し、その説明に理由を記録します。
- 小さな変更後は固定された回帰サンプルを実行する。
- 入力または出力を変更した後は、すべての Autonomous Work アイテムと API 呼び出し元を確認する。
- 復元後は、削除または置換された Waker、プロジェクト、Connector を再接続する。
- Version history は設定を記録し、Run history は実行を記録します。
実行履歴からフローを改善する
Run history に切り替えると、選択した実行のステージと Waker ノードの状態が左側に、時系列の実行リストが右側に表示されます。
- 最新の実行が対象だと決めつけずに、調査したい実行を選択する。
- 最初に失敗した、または予期せず待機している Waker ノードから始め、その結果と Chat を開く。
- Run configuration、Configuration summary、Business log、Final result を比較し、入力、タスク指示、リソース、またはワークフロー構造の問題を特定する。
- 構造的な問題には Improve workflow from this run を使用する。1 つの失敗した Action ノードには、ノードレベルの改善エントリを優先する。どちらも何かを送信する前に編集可能なドラフトを作成する。
- 新しいバージョンを保存し、同じ入力で再実行してノードの状態と最終成果物を比較する。
自動トリガーを設定する
WakerFlow は Autonomous Work の実行対象になります。スケジュール、イベント、API トリガーでは、Run WakerFlow を選択し、必要なワークフロー入力を固定値またはトリガーフィールドにマッピングします。
このページはワークフロー構造、入出力設計、失敗診断を担当します。トリガーのタイミング、実行制限、API アクセスの設定は Autonomous Work で行います。
まず手動実行を完了させ、その後限定されたテストで実際のトリガーを検証してください。フローに human-confirmation ノードが含まれる場合、自動実行はそのノードで一時停止します。判断を迂回することはありません。
ロールアウトと運用チェックリスト
- 名前、説明、入力、出力が新規ユーザーにも理解できる。
- すべての Waker ノードに 1 つの明確な責任範囲と、利用可能な割り当て Waker がある。
- 並列ノードが同じファイルや外部オブジェクトを上書きできない。
- 高リスクなアクションには人間の確認と実行可能なロールバック計画がある。
- 通常、無効、空の入力がテストされている。
- 入力、スクリプト、Waker、Connector、権限を変更した後は再テストする。