エージェントオーケストレーション ​

エージェントオーケストレーションは大規模アクションモデルの主要機能であり、Genieがレシピ内で複数ステップのビジネスプロセスを自律的に計画および実行できるようにします。 レシピは、ユーザー入力なしでタスクをGenieに割り当てます。 レシピジョブが一時停止している間に、Genieがタスクを処理し、その後レスポンスとメタデータをレシピに返します。 レシピは返されたデータで再開します。

エージェントオーケストレーションワークフローは、Conversationsページで追跡できます。 Genieに割り当てられた各タスクは、新しい会話として表示されます。

エージェントオーケストレーションは、Assign task to genieアクションを使用します。 入力と出力のフィールドレベルの説明については、Genieにタスクを割り当てアクションリファレンスを参照してください。

Assign task to genieアクションを使用すると、タスクをGenieに割り当てることができます。 Genieがタスクの処理方法を理解できるように、明確なタスク説明を提供する必要があります。

仕組み ​

Assign task to genieアクションは、標準のアクションステップとして任意のレシピで使用できます。 アクションを設定するには、次のフィールドが必要です:

• Genie: タスクを処理するGenie。
• Task instructions: これは、Genieが人の支援なしで割り当てられたタスクを処理するために受け取るプロンプトです。 Genieがタスクを完了するために必要な情報は、すべてタスク指示に含める必要があります。 詳細については、効果的なタスク指示を記述するを参照してください。
• Metadata: タスク指示とともにGenieに渡される任意の構造化データ。 メタデータフィールドは、タスク処理中にGenieが呼び出す任意のスキルのスキルトリガーで定義されます。 スキルがレシピコンテキストから特定の値にアクセスする必要がある場合は、請求書ID、商談ID、ユーザーメールなどの値を、タスク指示テキストに埋め込むのではなくメタデータフィールドとして渡します。 メタデータ値は、スキル内でStart workflowトリガーからのデータピルとしてアクセスできます。
• Conversation ID: 識別された会話のコンテキストと会話履歴を使用してGenieがタスクを処理できるようにする任意のフィールド。 このフィールドを空白のままにすると、Genieは会話コンテキストと履歴なしでタスクを処理します。 分類、要約、評価などのユースケースでは、このフィールドを空白のままにできます。 相互に積み重ねていく複数のAssign task to genie呼び出しを連鎖させる場合など、継続性が必要なユースケースでは、チェーン全体でコンテキストを維持するために、最初の呼び出しの出力から後続の呼び出しへConversation IDを渡す必要があります。
• Configure genie output for use in this recipe: カスタム出力フィールドを定義できる任意の設定。 Genieは、自由形式のテキストではなく、定義されたスキーマに一致する構造化形式でレスポンスを返します。 構造化出力フィールドは、下流のレシピステップで使用可能なデータピルになります。

レシピがAssign task to genieアクションステップに到達すると、次のプロセスが開始します:

• レシピが一時停止し、タスクがGenieに送信される
• Genieがジョブ説明、利用可能なスキル、ナレッジベースを使用してタスクを処理する
  • Genieの処理中、レシピジョブは一時停止され、待機中にレシピランタイムを消費しません。 処理時間は、タスクの複雑さと、Genieがスキルを呼び出す必要があるか、ナレッジベースを検索する必要があるかによって異なります。 単純な推論タスクは数秒で完了します。 複数のスキル呼び出しを必要とするタスクは、時間がかかる場合があります。
• Genieがレスポンスを返す
• Genieのレスポンスがデータピルとして使用可能な状態でレシピが再開する

複数のGenie呼び出しを連鎖する ​

同じレシピで複数のAssign task to genie呼び出しを使用できます。たとえば、検証Genie、続いて要約Genie、続いてルーティングGenieを使用できます。 これらを正しく連鎖するには、コンテキストの継続性とエラー処理に注意する必要があります。

呼び出し間でコンテキストを渡す ​

各Assign task to genie呼び出しは個別です。 明示的に渡さない限り、2番目のGenie呼び出しは最初のGenieのコンテキストに自動的にアクセスできません。

Genie間でコンテキストを渡す方法には、次の2つのアプローチがあります:

• Conversation IDを渡す: 最初のAssign task to genie出力のConversation IDを、2番目の呼び出しのConversation ID入力として使用します。 これにより、2番目のGenieは最初の呼び出しの会話履歴にアクセスできます。 2番目のタスクが最初のGenieの発言を参照する必要がある場合は、このアプローチを使用します。

• 構造化出力をタスクコンテキストとして渡す: 最初のAssign task to genie呼び出しのカスタム出力フィールドを、2番目の呼び出しのタスク指示内のラベル付きコンテキストとして使用します。 これにより、構造化データのためのクリーンで信頼性の高い会話履歴が提供され、2番目のGenieは解析が必要な完全な会話スレッドではなく、特定のフィールド値を受け取れるようになります。

例:

タスク: 次のチケット解決の詳細に基づいて
顧客通知を作成します。

前のステップの解決の詳細:
- チケットキー: [ticket_keyデータピル]
- カテゴリ: [ステップ3のcategoryデータピル]
- 解決の概要: [resolutionデータピル
  from Step 3]
- 解決までの時間: [durationデータピル]

連鎖呼び出しのエラー処理 ​

Assign task to genie呼び出しのチェーンは、Genieがタイムアウトした場合、スキルがエラーを返した場合、または出力が期待される形式と一致せず、下流の呼び出しが不正または欠落した入力を受け取る場合に失敗することがあります。

チェーン内の各Assign task to genieステップの後にエラー処理を追加する必要があります:

• 出力フィールドを確認する: 値を次のステップに渡す前に、出力フィールドに値が設定され、期待される形式である必要があります。
• 信頼度の低い出力を処理する: Genieが信頼度の低い出力を返した場合は、自動化チェーンを続行するのではなく、人によるレビューステップにルーティングします。
• 問題を診断するのに十分なコンテキストで失敗をログに記録する: タスク指示、Genieの生レスポンス、レシピジョブIDを含めます。

Genie間でサブタスクを委任する ​

Assign task to genieアクションは、プライマリGenieが専門Genieにサブタスクを委任するマルチエージェントアーキテクチャをサポートします。 これにより、ユーザーはプライマリGenieと対話でき、プライマリGenieはAssign task to genieアクションを通じて専門Genieをヘッドレスに呼び出し、タスクを完了します。

プライマリGenieで使用可能なスキルには、Assign task to genieアクションを呼び出すスキルを含める必要があります。 これにより、Assign task to genieアクションは実質的に呼び出し可能なスキルになります。 作業を委任する必要がある場合、プライマリGenieはこのスキルを呼び出します。

Assign task to genieアクション ​

Assign task to genieアクションを使用して、タスクをGenieに割り当てることができます。 これにより、Genieは自律的にレシピをトリガーし、割り当てられたタスクを実行してレスポンスを返せます。

Assign task to genieアクションを設定するには、次の手順を実行します:

顧客オンボーディングフォームを確認し、次を抽出します:
- 会社名と規模
- 業界カテゴリ
- 必要な連携

会社規模が500人を超える場合は、Salesforceからエンタープライズコンプライアンス要件も取得します。すべてのデータを次のフィールドを含むJSON形式で返します: company_name, company_size, industry, integrations (array), enterprise_requirements (object or null).

<instructions>
次のタスクデータに対して次の手順を実行します
- [Step 1]
- [Step 2]

エラーが発生した場合、または確認が必要な場合
- [Error handling instructions]
</instructions>

次のコンテキストを使用してタスクを処理します
<data>
[Map any datapills or provide the task data so your genie can handle it]
</data>

効果的なタスク指示を記述する ​

Assign task to genieアクションのタスク指示には、会話型のGenieプロンプトとは異なる要件があります。 Genieは会話をするのではなく、定義されたタスクを完了して結果を返します。

目標を具体的にする ​

最初の文でタスクの目標を明示します。 Genieは、何を生成するよう求められているかをすぐに把握できる必要があります。 タスク指示が、構造化された分類ではなく会話型レスポンスを生成するような内容になっています。

必要なコンテキストを指示またはメタデータで渡す ​

Genieは不足している情報をユーザーに尋ねることはできません。 チケットの説明、アカウント名、要約するドキュメントなどの必要なデータを、タスク指示またはメタデータフィールドに追加する必要があります。 構造化された値はメタデータとして渡します。 ドキュメントテキスト、トランスクリプト内容、説明フィールドなどの非構造化コンテンツは、ラベル付きフィールドとしてタスク指示に直接渡します。

例:

チケット詳細:
- Subject: [Subject datapill]
- Description: [Description datapill]
- Priority: [Priority datapill]
- Submitter: [Submitter Email datapill]
- Category (current): [Category datapill]

出力形式を指定する ​

Genieがレスポンスで使用する正確な形式を指定します。 カスタム出力フィールドが設定されているタスクの場合、Genieは自動的にスキーマに従います。 カスタム出力フィールド設定がないタスクの場合は、指示で形式を指定する必要があります。 レシピがGenieのレスポンスを解析して使用する必要があるタスクでは、明示的な出力形式の指示が不可欠です。 I think this should be categorized as Hardware with P2 priority because...を返すGenieでは、regex解析が必要です。 クリーンなJSONオブジェクトを返すGenieでは、解析は不要です。

例:

次のフィールドのみを含むJSONオブジェクトとして
レスポンスを返してください:
{
  "category": "次のいずれか: Hardware, Software,
               Access, Network, Other",
  "priority": "次のいずれか: P1, P2, P3, P4",
  "reasoning": "1文の説明",
  "confidence": "次のいずれか: high, medium, low"
}

JSONオブジェクトの外にテキストを含めないで
ください。上記に記載されていないフィールドを
追加しないでください。

判断タスクの評価基準を提供する ​

分類、スコアリング、評価など、Genieが判断を行う必要があるタスクには、明示的な基準を提供します。 あいまいな基準では実行ごとに結果が不一致になり、基準点を持つ基準では一貫性のある信頼性の高い出力が生成されます。

例:

分類基準:

Hardware: 物理デバイス、周辺機器、
またはハードウェア障害に関する問題

Software: アプリケーションエラー、
ソフトウェアのインストール、またはソフトウェアアクセスに関する問題

Access: ログイン失敗、
パスワードリセット、または権限リクエストに関する問題

Network: 接続、VPN、
またはネットワークパフォーマンスに関する問題

優先度基準:
P1: ビジネスクリティカルなシステムが停止し、
    複数のユーザーに影響があり、回避策がない
P2: 重大な影響があり、回避策は利用可能
    だが不便
P3: 中程度の影響があり、妥当な回避策を
    利用可能
P4: 軽微な問題で、ビジネスへの影響が最小限

提供したデータのみを使用するようGenieに指示する ​

この指示がない場合、Genieは提供されたデータを独自の推論や一般知識で補足する可能性があります。 精度と一貫性が重要な分類および評価タスクでは、Genieは提供された内容のみに基づいて出力する必要があります。

例:

上記で提供されたチケット詳細のみに基づいて
分類してください。一般的なチケットパターンに
関する仮定や一般知識を使用しないでください。
提供された情報が信頼度の高い分類を行うには
不十分な場合は、confidenceを"low"に設定し、
reasoningフィールドで理由を説明してください。

次の例は、サポートチケット分類タスクの完全なタスク指示セットを示しています:

次のサポートチケットを分類し、
構造化された分類結果を返してください。

チケット詳細:
- 件名: [Subjectデータピル]
- 説明: [Descriptionデータピル]
- 現在の優先度: [Priorityデータピル]
- 送信者: [Submitter Emailデータピル]

分類基準:

カテゴリ:
- Hardware: 物理デバイス、周辺機器、
  ハードウェア障害
- Software: アプリケーションエラー、インストール、
  ソフトウェアアクセス
- Access: ログイン失敗、パスワードリセット、
  権限リクエスト
- Network: 接続、VPN、ネットワークパフォーマンス
- Other: 上記のカテゴリに該当しない
優先度:
- P1: ビジネスクリティカルなシステム停止、
  複数のユーザーに影響、回避策なし
- P2: 重大な影響、回避策は
  利用可能だが不便
- P3: 中程度の影響、妥当な
  回避策を利用可能
- P4: 軽微な問題、ビジネスへの影響が最小限

レスポンスをJSONオブジェクトとして返してください:
{
  "category": "Hardware|Software|Access|
               Network|Other",
  "recommended_priority": "P1|P2|P3|P4",
  "priority_change_needed": true|false,
  "reasoning": "1文",
  "confidence": "high|medium|low"
}

上記のチケット詳細のみに基づいて分類してください。
信頼度の高い分類を行うための情報が
不十分な場合は、confidenceを"low"に
設定してください。

エージェントオーケストレーションのユースケース例 ​

エージェントオーケストレーションにより、Genieはレシピ内で複数ステップのタスクを自律的に実行できます。 これにより、意思決定、データ収集、またはドキュメント処理を必要とするワークフローを、ユーザー入力なしで実行できます。 エージェントオーケストレーションをワークフローに適用する方法を判断するには、次のユースケース例を参照してください:

• 自律タスク処理: レシピジョブが一時停止している間に、Genieが完全なタスクを実行します。 例:
  • 請求書照合: 請求書とPOを比較し、一致点と相違点のJSONサマリーを返します。
  • 契約書要約: 契約書から、終了、更新、支払いなどの重要条項を抽出します。
  • サポートトリアージ: チケットを分類し、優先度レベルまたは担当者を提案します。
• ナレッジベースの意思決定: Genieは内部ナレッジベースを使用して、決定論的なワークフローを導きます。 例:
  • ポリシーQ&A: Genieは内部SOPまたはWikiを使用して、レシピ内で質問に回答します。
  • ドキュメント検索: サポートGenieが関連する製品ドキュメントとURLを取得します。
• ファイルおよびデータ処理: Genieは構造化データおよび非構造化データを解析、検証、またはエンリッチします。 例:
  • ドキュメント分類: ドキュメントの種類とメタデータを識別します。
  • データ抽出: スプレッドシートまたはCSVを解析し、API操作を通じてデータをエンリッチします。
  • 証拠のアップロード: 監査ファイルを収集し、Google DriveまたはSharePointにアップロードします。
• テストと評価: Genieはワークフローまたは他のGenieを自律的にテストします。 例:
  • レスポンステスト: Genieの出力を期待される回答と比較します。
• チャネル内のGenie: GenieはSlackまたはTeams向けWorkbotと組み合わせて会話コンテキストを維持しながら、バックグラウンドタスクを処理します。 例:
  • 永続的なConversation ID: 同じConversation IDを使用して、複数ターンの会話を維持します。
• クロスエージェントコラボレーション: GenieはAssign task to genieアクションを使用して相互にサブタスクを委任し、マルチエージェントワークフローを形成します。 例:
  • コンプライアンス監査: Audit Genieは結果をまとめるために、証拠収集を別のGenieに委任します。
  • 調達: Finance Genieが予算を検証し、その後Procurement Genieがオンボーディングを進めます。
  • プロジェクト更新: Product Manager GenieがJira課題を要約し、その後Communications Genieが更新内容を下書きします。

定義済みタスクメタデータのユースケース例 ​

次のユースケース例では、Assign task to genieアクションでメタデータを定義して使用する方法の概要を示します:

請求書処理 ​

請求書が会計システムで自動的に作成され、Finance Genieが承認のために自律的に処理します。 スケジュール済みトリガーが実行され、新しい保留中の請求書を検出します。 トリガーは会計システムから請求書の詳細を取得し、invoice_idメタデータを定義した状態でタスクをFinance Genieに割り当てます。 この方法は安定しており、Genieがメタデータを直接処理せずにリクエストを処理できるため、ハルシネーションの可能性を排除できます。

Finance Genieは、請求書の承認、追加ドキュメントの要求、レビュー対象としてのフラグ付けなど、適切なアクションを自律的に判断し、検証済みのinvoice_idメタデータを使用して会計システムで請求書承認を実行し、リクエストがなりすまされないようにします。

ワークフローの概要

• スケジュール済みトリガー: レシピはスケジュールに従って実行され、会計システム内の新しい保留中の請求書を確認します。
• 請求書コンテキストの取得: レシピは請求書の詳細を取得し、会計システムから請求書IDを抽出します。 Assign task to genie: レシピはAssign task to genieアクションを使用して、invoice_idメタデータ（例: INV-2026-001234）とともに請求書処理タスクをFinance Genieに送信し、レシピジョブを一時停止します。
• 自律タスク処理: Finance Genieはタスク指示と利用可能なスキルを参照し、請求書の承認、追加ドキュメントの要求、レビュー対象としてのフラグ付けなど、適切なアクションを判断します。
• アクションの実行: Genieは請求書承認スキルを使用して、invoice_idメタデータで指定された請求書を会計システムで承認します。
• ワークフローの完了: Genieは請求書承認が成功したことを確認し、完了ステータスを元のレシピに返します。

次の図は、このワークフローを示しています。

パスワードリセット ​

ユーザーがSlackでパスワードリセットをリクエストし、ITSM Genieがそのリクエストを自律的に処理します。 WorkbotトリガーがSlackスレッド内の新しいメッセージを検出して実行されます。 ユーザーのメールアドレスを取得し、user_emailメタデータとともにタスクをITSM Genieに割り当てます。 この方法は安定しており、Genieがメタデータを直接処理せずにリクエストを処理できるため、ハルシネーションの可能性を排除できます。

ITSM Genieは、パスワードのリセット、ポリシーへのリンク、アカウントのロック解除など、適切なアクションを自律的に判断し、検証済みのuser_emailメタデータを使用してOktaでパスワードリセットを実行し、リクエストがなりすまされないようにします。

ワークフローの概要

• Workbotコネクタートリガー: Workbotは、パスワードリセットをリクエストするSlackスレッド内の新しいメッセージを検出します。
• ユーザーコンテキストの取得: レシピはSlack IDを使用して、Slackからユーザーのメールアドレスを取得します。
• Assign task to genie: レシピはAssign task to genieアクションを使用して、user_emailメタデータ（例: [email protected]）とともにパスワードリセットタスクをITSM Genieに送信し、レシピジョブを一時停止します。
• 自律タスク処理: ITSM Genieはタスク指示と利用可能なスキルを参照し、パスワードのリセット、アカウントのロック解除、ポリシーへのリンクなど、適切なアクションを判断します。
• アクションの実行: Genieはパスワードリセットスキルを使用して、user_emailメタデータで指定されたユーザーのパスワードをOktaでリセットします。
• ワークフローの完了: Genieはパスワードリセットが成功したことを確認し、完了ステータスを元のレシピに返します。

コンプライアンス監査のユースケース例 ​

コンプライアンス監査がスケジュールに従ってトリガーされ、Audit Genieが証拠収集を自律的に開始します。 Audit GenieはAPIエンドポイントスキルを使用して、証拠収集タスクをEvidence Collection Genieに割り当てるレシピを呼び出します。

Evidence Collection Genieは、複数のシステムから必要なコンプライアンスドキュメントを自律的に収集し、ファイルをGoogle DriveにアップロードしてファイルURLをAudit Genieに返します。その後、Audit Genieは証拠をガバナンス、リスク、コンプライアンスツールにアップロードします。

ワークフローの概要

• トリガー: スケジュール済みレシピがAudit Genieをトリガーし、コンプライアンス証拠収集を開始します。

• API呼び出し: Audit Genieはスキルを使用して、APIエンドポイントレシピを呼び出します。

• Assign task to genie: APIエンドポイントレシピはAssign task to genieアクションを使用して、証拠収集タスクをEvidence Collection Genieに送信し、レシピジョブを一時停止します。

• 自律タスク処理: Genieはタスク指示を参照して、タスクの処理方法を理解します。

• レスポンスの送信: タスクが完了すると、Genieはレスポンスとメタデータをレシピに送り返します。

• レシピの再開: APIエンドポイントレシピが再開し、GenieのレスポンスをAudit Genieに返します。

• ワークフローの完了: Audit GenieはGoogle Drive URLを使用してファイルにアクセスし、別のスキルを使用してファイルをガバナンス、リスク、コンプライアンスツールにアップロードします。

App EventsとAssign task to genieの比較 ​

このセクションでは、ユースケースに適したツールがApp EventsかAssign task to genieアクションかを判断します。

次の点を確認してください: ユーザーがメッセージを受信し、場合によってはアクションを実行する必要がありますか。

• はい: App Eventsを使用
• いいえ: Assign task to genieアクションを使用

App Eventsにはユーザーが必要です。 Genieはチャットインターフェイスを通じて、特定の識別済みユーザーに連絡します。 ユーザーはメッセージを受信して応答し、会話が続行されます。

Assign task to genieにはユーザーは必要ありません。 Genieは推論し、スキルを呼び出し、構造化された結果をレシピに返すことで、バックグラウンドでタスクを処理します。 会話スレッドは作成されません。

App Eventsを使用する場合 ​

App Eventsは次の場合に使用します:

• ユーザーに通知する必要があり、ユーザーがアクションを実行する必要がある場合があります。 たとえば、そのユーザーが作成したチケットが更新された場合や、更新商談の期限が近づいている場合です。
• プロセスの途中でユーザーの判断が必要です。 Genieはコンテキストとオプションを提示し、ユーザーが判断します。
• ダウンストリームのスキルにVerified User Accessが必要です。 Verified User Accessにはアクティブなユーザーセッションが必要です。
• フローにBusiness Approvalsが含まれています。 承認通知はユーザーのチャットインターフェイスに表示され、ユーザー操作が必要です。
• Genieがプロアクティブに会話を開始する必要があります。 たとえば、スケジュールされたリマインダーやイベントトリガー型アラートです。

App Eventsは構造化された値をレシピに返すことはできません。 レシピはイベントの送信後、Genieの完了を待たずにすぐに続行されます。

Assign task to genieを使用する場合 ​

Assign task to genieアクションは次の場合に使用します:

• 処理が自動化され、結果がレシピにフィードバックされます。 たとえば、チケットの分類、ドキュメントの要約、請求書データの抽出です。
• ユーザーが存在しない、または必要ありません。 たとえば、バックグラウンドジョブやシステム間連携です。
• Genieの出力は、ユーザーへのメッセージではなく構造化データです。
• 複数のGenieがパイプライン内で連携する必要があります。 オーケストレーションを行うレシピは、専門のGenieに順番にタスクを割り当て、それぞれから構造化出力を収集できます。

Assign task to genieアクションは次とは併用できません:

• Verified User Access。ヘッドレス呼び出しにはユーザーコンテキストがないためです。
• Business Approvals。承認通知はユーザーのチャットインターフェイスを通じて配信されるためです。
• 権限認識型ナレッジベース。ユーザースコープの権限で取り込まれたナレッジベースは、ユーザーコンテキストがないとそれらの権限を適用しないためです。

これらはプラットフォームの制約であり、設定上の選択肢ではありません。

App EventsとAssign task to genieの比較 ​

使用する機能を判断するには、次の比較を参照してください:

両方の機能の組み合わせ ​

最も強力なアーキテクチャでは、両方の機能を順番に組み合わせます。

レシピは、チケットの分類やエスカレーション基準の評価などの自動推論にAssign task to genieを使用します。 構造化された結果により、レシピはApp Eventsを使用して関連ユーザーに通知し、会話を開始できます。 推論は自動化され、判断はユーザーによって決定されます。

一般的なミス ​

• Assign task to genieを使用すべき場面でApp Eventsを使用する: ビルダーは受信サポートチケットを自動的に分類する必要があります。 ビルダーはApp Eventsを使用して各チケットをエージェントに送信し、分類応答を待ちます。 これにより、チケットごとに会話スレッドが作成され、エージェントのチャットインターフェイスがGenieメッセージで埋まります。 この場合は、ユーザーの関与を必要としないAssign task to genieアクションを使用する必要があります。

• App Eventsを使用すべき場面でAssign task to genieを使用する: ビルダーは更新商談が近づいたときに営業担当者に通知する必要があります。 ビルダーはAssign task to genieアクションを使用して更新イベントを処理し、要約をデータピルとして返します。 営業担当者は通知を受信しません。これは、Assign task to genieアクションがApp Eventsのようにチャットインターフェイスで会話を開始しないためです。

ユースケースの推奨事項 ​

ワークフローに適した機能を選択するには、次のユースケースの推奨事項を参照してください: