Skip to main content
Waker を使う

WakerFlow ワークフロー

繰り返し実行可能な多段階ワークフローの作成、実行、トラブルシューティング：自然言語からキャンバスとスクリプトの生成、実行入力の設定、ユーザー入力待ちの処理、ビジネスログの理解、自動トリガーの設定まで。

本章の目標： 繰り返し実行可能な多段階ワークフローの作成、実行、トラブルシューティング。既存のワークフローを実行するだけなら、直接実行記録に進みます。ワークフローを調整する必要がある場合は、入力フォーム、Worker、返却構造を確認します。
WakerFlow は、複数の役割、複数の段階、または人間による確認が必要なワークフローのオーケストレーションに使用します。単一の Waker が固定タスクを定期的に繰り返し実行する場合は、「自動タスク」を使用します。

WakerFlow を開くまたは作成する

左側メインナビゲーションの「WakerFlow」をクリックして、WakerFlow 管理ページに入ります。
Figure 5-1
 既存のワークフローを開く際は、まず名前と説明で目標を確認します。実行中のワークフローを変更する前に実行記録を確認します。リストが空またはロードに失敗した場合は、ページを更新してローカルサービスとネットワーク状態を確認します。 新しいワークフローの作成： 現在のバージョンでは、まず下書きを作成し、次に対話を通じてワークフローを生成します。 操作手順：
  1. WakerFlow 一覧ページで「新規 WakerFlow」をクリックします。
  2. 空白のワークスペースに目標を入力し、実行入力、処理ステップ、役割分担、エラー処理、出力形式を明確に記載します。
  3. システムがキャンバスとスクリプトを生成するのを待ちます。「スクリプト」を開き、入力フィールド、対象の Waker、最後の return を確認します。
  4. 上部の名前を編集し、「詳細設定」にワークフローの用途の説明を追加します。
  5. 右上の「実行」をクリックして、手動テスト実行を 1 回完了します。
Figure 5-2
 ワークフローを記述する際は、目標、実行入力、処理ステップ、エラー処理、最終出力の順に記載することを推奨します。人間の判断が必要な場合は、確認ノード、質問内容、タイムアウトやスキップ時の処理方法も記載します。 完了判定：
  • キャンバスに段階とノードが生成され、スクリプトが空でない。
  • 実行フォームに必要なフィールドが含まれ、各 Worker が現在の環境の Waker を指している。
  • スクリプトに明示的な return があり、その内容が納品要件を満たしている。
生成結果が期待通りでない場合： 左側のカスタマイズ対話で、調整したいノード、実行順序、入力、または出力を説明します。一度に 1 種類の問題のみ調整し、変更後にキャンバス、スクリプト、実行フォームを再確認します。

詳細ページの理解

WakerFlow 詳細ページは 3 つのエリアに分かれています：
エリア主な用途
WakerFlowキャンバス、スクリプト、バージョンの表示・調整
実行記録実行状態、ログ、結果、エラーの確認
詳細設定説明、トリガー方式、デフォルトパラメーターの変更
右上の「実行」は現在のワークフローの手動実行用です。「トリガー方式を追加」または「トリガー方式を管理」は自動実行の設定用です。これらは同じ操作ではありません。 キャンバス: キャンバスはスクリプトを段階とノードの関係に解析し、ワークフロー構造をすばやく理解するのに適しています。
Figure 5-3
 一般的なノード：
ノード意味
Phaseビジネス段階
WorkerWaker に割り当てて実行させるタスク
Parallel / Pipeline並行処理またはバッチ多段階処理
Ask User一時停止して人間の入力を待つ
Action / サブワークフローアクションの実行または他のワークフローの呼び出し
キャンバスに表示されない条件、エラー処理、返却構造はスクリプトが基準です。「実行設定」は記入可能なフィールドであり、過去の実行の実際のパラメーターではありません。 スクリプトとバージョンの調整:
  1. 左側のカスタマイズ対話で変更要件を説明するか、「スクリプト」を直接編集します。
  2. 保存後、キャンバス、実行入力、return を確認してから手動テスト実行します。
  3. 復元が必要な場合は、「バージョン履歴」でプレビューしてロールバックします。
実行記録: 実行記録には実行 ID、トリガー方式、ノードの状態が表示されます。ノードをクリックすると、入力、セッション、結果、またはエラーを確認できます。ワークフロー全体のログと最終返却値は実行詳細で確認します。
Figure 5-4

実行入力と最終出力の設定

実行フォームはスクリプト内の meta.inputSchema から生成され、入力値は args を通じて渡されます。最終的な納品物は return によって決まります。
  1. inputSchema でフィールドの型、説明、デフォルト値、必須項目を設定します。
  2. 「実行」をクリックし、フォームのフィールドとデフォルト値が正しいか確認します。
  3. 実行後、「最終返却値」が期待通りか確認します。
オブジェクトや配列は有効な JSON で入力する必要があります。フィールドの欠落、フォーマットエラー、型の不一致がある場合、ページが送信をブロックするか、バリデーション失敗を表示します。

オーケストレーション機能クイックリファレンス

スクリプトを変更する際は、必要に応じて以下の機能を使用します：
機能役割
phase / log段階のマークとビジネスログの記録
workerWaker タスクをディスパッチして結果を待つ
parallel / pipeline並行処理またはバッチ多段階処理
askUserワークフローを一時停止して人間の入力を待つ
workflow別の WakerFlow を呼び出す
action宣言済みの HTTP またはローカルアクションを実行
保存前に、Waker ID、サブワークフロー ID、Action アドレス、ローカルパスが現在の環境に属しているか確認してください。シークレットをスクリプトにハードコードしてはいけません。

手動実行とユーザー入力待ちの処理

手動実行

  1. 詳細ページの右上にある「実行」をクリックします。
  2. 実行パラメーターを入力します。必須項目は空にできません。オブジェクトと配列は有効な JSON を使用する必要があります。
  3. 送信後、「実行記録」でノードの進捗を確認します。
  4. 実行完了後、ステータスと「最終返却値」を確認します。
実行ステータス：
ステータス意味取るべきアクション
キュー中 / 実行中作成済みで進行中動かない場合は現在のノードとサービス状態を確認
入力待ちワークフローが人間の回答を待機中質問を開いて送信またはスキップ
完了スクリプトが終了最終返却値が正しいか確認
失敗 / 終了実行エラーまたはキャンセル失敗したノードを確認し、修正後に再試行
「完了」はスクリプトが正常に終了したことを示すだけで、ビジネス内容が正しいことを自動的に証明するものではありません。最終返却値に期待されるフィールド、数量、根拠が含まれているか確認する必要があります。

ユーザー入力の待機

askUser() はテキストプロンプト、選択肢、または承認カードを生成できます。スクリプトには質問、選択肢、タイムアウト、デフォルトの処理方法を明確に記載します。
Figure 5-5
 ワークフローが「入力待ち」に入った後、実行記録または承認ダッシュボードで回答を送信します。無人運用のワークフローでは、長期間待機状態にとどまることを避けるため、このノードを慎重に使用してください。
「終了」は、既に書き込まれたファイル、送信済みのメッセージ、実行済みの外部アクションを取り消しません。「再試行」は前回完了したノードを再利用する場合があります。入力やスクリプトが変更されている場合は、新しい実行を開始してください。

実行設定、ビジネスログ、結果の正しい理解

これは WakerFlow の実行記録を読む際に最も混同しやすい部分です。

種類の情報の出所

情報ソースと意味ではない
実行設定フォームフィールドと今回の入力値最終出力
ビジネスログスクリプトが log() で記録した進捗やサマリー完全な入力と最終結果
Worker Instruction単一 Worker のタスク指示ワークフロー全体の完全な入力
Worker Result単一 Worker の返却値Worker の完全な実行過程
最終返却値スクリプトの return の内容必ず完全な明細であるとは限らない。内容はスクリプトが決定
原始イベント段階、ディスパッチ、ログ、結果、失敗などのイベントストリームWorker 内部の全量記録
スクリプトが明示的に return しない場合、実行は成功する可能性がありますが、最終返却値は null になります。 ページ上で隣接する 2 つの「ログ」セクションは「入力設定」と「完全な出力」を意味するものではなく、いずれもスクリプトが能動的に書き込んだビジネスサマリーである可能性があります。
Figure 5-6
 スクリーンショットの 3 つのエントリは、以下のような log() 呼び出しから生成されています： 
log(`実行モード：${args.mode} | 実行 ID：${runLabel}`)
log(`競合スキャン：あり | レビュー待ち要件：${pendingCount}件 | 既存機能：${capabilityCount}件`)
log(`コードリポジトリ：${repoPath} | プラン生成：はい | 永続化：はい`)
これらはすべてスクリプトが設計したサマリーであり、完全な入力や出力を表すものではありません。右側の +2分33秒 はワークフロー開始からのイベントの相対時間であり、そのログエントリの所要時間ではありません。

実際の結果を確認する場所

確認したい内容入口
単一 Worker の入力と結果実行記録 → 対象の実行 → Phase → Worker → Instruction / Session / Result / エラー
ワークフロー全体の納品物実行詳細 → 「最終返却値」。失敗またはキャンセル時は対応する理由を確認
全過程の診断実行詳細 → 「原始イベント」。最後の成功イベントと最初の失敗イベントから問題を特定
ログ記述の推奨事項：
  • ログは段階、数量、重要な判断、例外のみ記録し、大きなオブジェクト全体や認証情報を書き込まない。
  • ログレベルは info、warn、error を使用する。
  • 納品する必要のある内容は明示的に return する必要があり、ログへの書き込みだけに頼ってはいけない。

自動実行の設定

1 つの WakerFlow に複数のトリガー方式を追加できます。数量と種類の上限は現在のページの表示に従います。
  1. まず手動テスト実行を完了し、最終返却値が正しいことを確認します。
  2. 右上の「トリガー方式を追加」をクリックするか、「詳細設定」→「トリガー方式を管理」に入ります。
  3. デフォルトパラメーターを設定し、スケジュール、API、GitHub、またはページ提供のイベントトリガー方式を追加します。
  4. 保存して有効化し、実際のトリガーを待つか、ページ提供のテスト入口を使用します。
  5. 「実行記録」に戻り、トリガー方式、実行 ID、ステータス、最終返却値を確認します。
トリガー方式で設定したフィールド値は自動実行のデフォルトパラメーターを上書きし、自動実行のデフォルトパラメーターはスクリプトのデフォルト値を上書きします。同一フィールドには固定値または Payload マッピングのいずれか一方のみを選択します。自動トリガーに異常がある場合は、まずトリガー設定、デフォルトパラメーター、実行記録を確認します。 ローンチ前チェック：
  • 段階とノードの名前を明確に保ち、Schema で下流データを制約する。
  • 外部書き込み、メッセージ送信、公開の前に人間による確認を残す。
  • 重要な変更はバージョンを保存して手動テスト実行を先に行う。再試行は既に発生した外部操作を取り消さない。

Q&A Specialist のデフォルト Q&A ワークフロー

対象範囲：このセクションは「Q&A Specialist」テンプレートから作成した Waker のみに適用されます。通常の WakerFlow ユーザーは読み飛ばせます。
Q&A Specialist を作成すると、メッセージ判定、ナレッジ検索、専門家支援、元のグループへの返信を行うプリセットフローが初期化されます。日常の接続は Waker ホームのクイック設定から行い、ペアリング時に WakerFlow を選択する必要はありません。
Figure 5-7
 ワークフローを確認して保守する：
  1. Q&A Specialist 詳細 >「ワークフロー」を開き、プリセット Q&A ワークフローを選択します。
  2. メッセージ判定、ナレッジ検索、専門家支援、返信ノードを確認します。編集前に動作するバージョンを保存します。
  3. 編集後、テストグループでナレッジ内、ナレッジ外、範囲外、専門家確認済みの 4 種類のメッセージを送信し、Q&A 記録と実行記録を確認します。
確認：ナレッジ内の質問は資料を根拠に回答し、ナレッジ外の質問は不明であることを説明するか専門家に依頼し、範囲外の質問はルールに従って処理し、確認済みの結論だけを保存します。根拠不足時の支援分岐を削除せず、未確認の結果を保存しないでください。
はじめに
Waker を使う
機能
ベストプラクティス
設定
サポート