Autonomous Work

​

Autonomous Work を開く

​

前提条件を確認する

• 実行主体: Waker が有効になっており、正常に応答します。WakerFlow の場合は、少なくとも 1 回の手動実行を成功させ、人間の確認ノードと出力を検証してください。
• モデル: Waker のモデルが利用可能です。再現性が重要な場合は特定のモデルを選択し、Auto を使ってシステム推奨に従うこともできます。
• ワークスペース: Waker が必要なディレクトリまたはプロジェクトにアクセスできます。ローカルディレクトリは、トリガー発動時にデバイス、QoderWake、ディレクトリが引き続き利用可能である必要があります。
• 能力とアクセス: 必要な Skill、コネクタ、ネットワークアクセス、外部アカウントを、まず通常のチャットで検証してください。本番の自動化を初回の認可テストに使用しないでください。
• タスクの境界: 目標の再確認が繰り返し必要な作業はチャットに残してください。複数のステージ、固定の承認、人間の確認ステップがある場合は WakerFlow を優先してください。

​

トリガーを選択する

​

自律タスクを作成する

1. New Automation を選択します。
2. 「オブジェクト + 操作 + 頻度またはソース」の形式で名前を入力します。
3. 1 つ以上のトリガー条件を追加します。1 つのタスクには最大 5 つのトリガーを含められます。
4. 実行方法を選択します:
   • 1 つのロールが担当する安定した作業には Waker。
   • 複数のステージ、並列作業、固定の引き継ぎ、構造化入力には WakerFlow。
5. 実行オブジェクトを選択し、それが有効になっていることを確認します。
6. 応答方法が Waker の場合、Auto または特定のモデルを選択します。そのモデルが利用不可になったり削除されたりした場合は、タスクを編集して再テストしてください。
7. タスク説明を記述します: 反復的な目標、入力の範囲、出力、禁止操作。
8. デフォルトのワークスペース、ローカルディレクトリ、またはプロジェクトを選択します。
9. 詳細設定を開き、最大実行回数と終了日時を設定します。
10. 保存して手動で実行し、本番利用を有効にする前に実際のトリガーをテストします。

目的: 各呼び出しで必ず達成する内容。
入力: 使用を許可するデータ、期間、業務オブジェクト。
処理ルール: 必須の手順、判断、エラー処理。
出力: 応答形式、ファイル名、保存先、または外部アクション。
受け入れ基準: Completed ステータスだけでなく、業務結果を検証する方法。
禁止事項: 変更、削除、公開、送信してはならない内容。

​

スケジュールトリガーを設定する

1. Schedule を選択します。
2. 定期実行または 1 回限りの実行を選び、日付、時刻、繰り返しルールを設定します。
3. 次回実行時刻と業務タイムゾーンを検証します。
4. 最初のテストでは、数分後に実行を予約します。成功後にのみ最終的な実行間隔に切り替えてください。

​

イベントトリガーを設定する

1. Event を選択し、イベントソースを認可します。
2. リポジトリまたはオブジェクトを選択します。
3. イベントタイプと、作成、編集、リポジトリ、ブランチ、ラベル、オブジェクト範囲など、ソース固有のフィルターを選択します。利用可能なフィールドはソースによって異なります。
4. 保存し、ソースシステムで安全なテストイベントを作成します。
5. タスク詳細で Event Activity または実行履歴を確認します。まずイベントが届いたことを確認し、次に予期したタスクがちょうど 1 件開始されたことを確認してください。

​

定期ポーリングを設定する（利用可能な場合）

1. ソースを選択し、認可します。
2. オブジェクト範囲、フィルター、ポーリング間隔を選択します。
3. 初回実行がすべての履歴を誤って処理しないよう、初期時刻またはカーソルを定義します。
4. 重複排除には安定したオブジェクト ID または更新時刻を使用します。
5. 変更の検出 → タスクの作成 → カーソルの進め方という完全な経路を検証します。

​

API トリガーを設定する

​

パーソナルアクセストークンを作成する

1. Qoder Console にサインインし、アバターまたはユーザーメニューを開きます。
2. Personal Settings → Service Integration に移動します。
3. パーソナルアクセストークンを作成します。ticketing-production のように、呼び出し側と環境を識別できる名前を使用してください。
4. トークンをすぐにコピーします。通常、完全な形式で表示されるのは 1 回だけです。呼び出し側の資格情報マネージャーまたは CI シークレットストアに保存してください。
5. テスト環境で統合を検証し、その後、本番用の別のトークンを作成します。ローテーションの際は、古いトークンを失効させる前に新しいトークンを検証してください。

​

タスクを作成しエンドポイントを取得する

1. 自律タスクを作成し、API トリガーを追加します。
2. Waker または WakerFlow を選択し、タスク説明、ワークスペース、実行上限を設定します。
3. タスクを保存します。タスク詳細から、生成された POST エンドポイント、認証方法、リクエスト例をコピーします。
4. 完全なエンドポイントを資格情報同様に保護してください。手動で構築したり、公開ログやスクリーンショットに含めたりしないでください。

​

タスク説明とペイロードを設計する

チケット {{ticket.id}} を処理してください。
重大度: {{ticket.severity}}
問題: {{ticket.summary}}
出力: 原因、推奨対応、人間の承認が必要なリスクを提示してください。

curl -X POST 'https://api.qoder.com/v1/qoderwake/automation/invoke/<GENERATED_INVOKE_KEY>' \
  --header 'Authorization: Bearer <YOUR_PAT>' \
  --header 'Content-Type: application/json' \
  --data '{
    "wakeSessionUniqueId": "ticket-1001",
    "ticket": {
      "id": "1001",
      "severity": "high",
      "summary": "Payment callbacks keep timing out"
    }
  }'

• 最上位フィールドには {{field}}、ネストされたフィールドには {{ticket.id}}、配列要素には {{items[0].name}} を使用します。
• フィールド名は大文字小文字を区別します。パスを解決できない場合、プレースホルダーはタスク説明に残り、不一致が確認できます。
• 文字列は直接挿入されます。オブジェクト、配列、数値、ブール値、null は JSON テキストに変換されます。
• タスク説明にプレースホルダーがない場合、固定の説明はそのまま残り、完全なリクエストボディがその実行の入力として追加されます。

​

一回限りのリクエストと継続セッション

• 同じユーザー、自律タスク、wakeSessionUniqueId からのリクエストは 1 つのセッションを再利用し、順番に実行されます。
• このフィールドを省略するか値を変更すると、新しいセッションが開始されます。
• このフィールドはコンテキストを保持します。べき等性キーではありません。呼び出し側は引き続きリトライと重複排除の挙動を実装する必要があります。
• 異なる顧客、プロジェクト、データ権限、セキュリティスコープにわたっては異なる値を使用し、コンテキストが境界を越えないようにしてください。

​

結果を検証する

1. 小さく機微でないペイロードで最初のリクエストを実行します。
2. HTTP レスポンスを確認します。リクエストが受理されたことは、実行がディスパッチされたことを意味するだけで、業務タスクが完了したことを意味しません。
3. Autonomous Work の実行履歴で、トリガーソースが API であることを確認し、入力、実行主体、ワークスペース、現在のステータスを検査します。
4. 完了を待ち、最終レスポンス、生成されたファイル、外部システム内の実際の結果を検査します。
5. 検証後、保護されたエンドポイントと PAT を本番の呼び出し側に設定します。

​

API トリガーをトラブルシューティングする

​

WakerFlow を実行する

1. すでに手動実行を通過済みの WakerFlow を選択します。
2. フェーズと人間の確認ノードをレビューします。
3. すべてのランタイムパラメーターに対してオーバーライド方法と値を設定します。
4. 必須フィールドと出力の互換性を検証します。

​

ワークスペースを設定する

​

詳細設定

• Maximum runs: 無制限またはカスタム回数。上限に達するとタスクは一時停止します。
• End date: 設定しないか、指定の日時。その日時のあとは新しいトリガーは開始しません。

​

ロールアウト前にテストする

1. Run now を使用して、実行主体、タスク説明、ワークスペース、能力を検証します。
2. 直近のスケジュール、安全なイベント、API リクエストで実際のトリガーをテストします。
3. トリガーソース、入力、現在のステップ、最終結果、成果物を検査します。
4. リスクの高い操作が引き続き承認のために停止することを確認します。
5. テストデータを削除してから、本番トリガーを有効にします。

​

実行記録を検査する

​

編集、一時停止、コピー、削除

• 既存のタスクを編集する際は、応答方法と選択された Waker または WakerFlow はロックされます。実行主体を変更するには、Copy を使い、新しいタスクを検証してから、古いタスクを一時停止または削除してください。
• トリガー、モデル、ワークスペース、権限、コネクタを変更したあとは再テストしてください。
• コピーしても、累積した実行回数や実行履歴はコピーされません。コピー後は、2 つのタスクが同じイベントを処理しないよう、名前、トリガー範囲、プロジェクト、モデル、トークンを確認してください。
• 一時停止は新しい自動トリガーを防ぎますが、すでに進行中の実行は停止しません。
• すべてのイベントトリガー型タスクが Run now に対応しているわけではなく、検証には外部ソースからの安全なイベントを使用します。
• 削除の前に、必要な実行記録を保存し、外部システムがエンドポイントを呼び出さないようにしてください。

​

よくある問題