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

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

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

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

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

仕組み ​

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

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

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

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

複数のジーニー呼び出しの連鎖 ​

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

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

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

ジーニー間でコンテキストを渡す方法には 2 つのアプローチがあります。

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

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

例：

Task: Draft a customer notification based 
on the following ticket resolution details.

Resolution details from previous step:
- Ticket key: [ticket_key data pill]
- Category: [category data pill from Step 3]
- Resolution summary: [resolution data pill 
  from Step 3]
- Time to resolve: [duration data pill]

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

Assign task to genie 呼び出しのチェーンは、ジーニーがタイムアウトした場合、スキルがエラーを返した場合、または出力が期待される形式と一致しない場合に失敗する可能性があり、下流の呼び出しが不正または不足した入力を受け取る原因となります。

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

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

ジーニー間でサブタスクを委任する ​

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

プライマリジーニーが利用できるスキルには、Assign task to genie アクションを呼び出すスキルが含まれている必要があります。これにより、実質的に Assign task to genie アクションが呼び出し可能なスキルとなります。プライマリジーニーは作業を委任する必要があるときにこのスキルを呼び出します。

Assign task to genie アクション ​

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

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

Review the customer onboarding form and extract the following:
- Company name and size
- Industry category
- Required integrations

Also retrieve their enterprise compliance requirements from Salesforce if the company size is over 500 employees. Return all data in JSON format with fields: company_name, company_size, industry, integrations (array), enterprise_requirements (object or null).

<instructions>
Perform the following steps for the following task data
- [Step 1]
- [Step 2]

If you hit errors or need clarification
- [Error handling instructions]
</instructions>

Use the following context to handle the task
<data>
[Map any datapills or provide the task data so your genie can handle it]
</data>

効果的なタスク指示の書き方 ​

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

目標を具体的に記述する ​

最初の文でタスクの目標を述べます。ジーニーは、何を生成するよう求められているかをすぐに理解する必要があります。曖昧なタスク指示は、構造化された分類ではなく会話型の応答を生成します。

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

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

例：

Ticket details:
- Subject: [Subject datapill]
- Description: [Description datapill]
- Priority: [Priority datapill]
- Submitter: [Submitter Email datapill]
- Category (current): [Category datapill]

出力形式を指定する ​

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

例：

Return your response as a JSON object with 
the following fields only:
{
  "category": "one of: Hardware, Software, 
               Access, Network, Other",
  "priority": "one of: P1, P2, P3, P4",
  "reasoning": "one sentence explanation",
  "confidence": "one of: high, medium, low"
}

Do not include any text outside the JSON 
object. Do not add fields not listed above.

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

分類、スコアリング、評価など、ジーニーが判断を行う必要があるタスクには明示的な基準を提供します。曖昧な基準は実行ごとに一貫性のない結果をもたらしますが、明確に定義された基準は一貫性のある信頼できる出力を生成します。

例：

Classification criteria:

Hardware: issues involving physical devices, 
peripherals, or hardware failures

Software: issues involving application errors, 
software installation, or software access

Access: issues involving login failures, 
password resets, or permission requests

Network: issues involving connectivity, VPN, 
or network performance

Priority criteria:
P1: business-critical system down, affecting 
    multiple users, no workaround available
P2: significant impact, workaround available 
    but inconvenient
P3: moderate impact, reasonable workaround 
    available
P4: minor issue, minimal business impact

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

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

例：

Base your classification only on the ticket 
details provided above. Do not use assumptions 
or general knowledge about typical ticket 
patterns. If the provided information is 
insufficient to make a confident classification, 
set confidence to "low" and explain why in 
the reasoning field.

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

Classify the following support ticket and 
return a structured classification result.

Ticket details:
- Subject: [Subject datapill]
- Description: [Description datapill]
- Current priority: [Priority datapill]
- Submitter: [Submitter Email datapill]

Classification criteria:

Category:
- Hardware: physical devices, peripherals, 
  hardware failures
- Software: application errors, installation, 
  software access
- Access: login failures, password resets, 
  permission requests
- Network: connectivity, VPN, network performance
- Other: does not fit the above categories
Priority:
- P1: business-critical system down, 
  multiple users affected, no workaround
- P2: significant impact, workaround 
  available but inconvenient
- P3: moderate impact, reasonable 
  workaround available
- P4: minor issue, minimal business impact

Return your response as a JSON object:
{
  "category": "Hardware|Software|Access|
               Network|Other",
  "recommended_priority": "P1|P2|P3|P4",
  "priority_change_needed": true|false,
  "reasoning": "one sentence",
  "confidence": "high|medium|low"
}

Base your classification only on the ticket 
details above. Set confidence to "low" if 
the information is insufficient for a 
confident classification.

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

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

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

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

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

請求書処理 ​

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

財務ジーニーは、請求書承認、追加ドキュメントのリクエスト、レビュー対象としてのフラグ付けなどの適切なアクションを自律的に決定し、検証された invoice_id メタデータを使用して会計システムで請求書承認を実行することで、リクエストが偽装されないようにします。

ワークフローの概要

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

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

パスワードリセット ​

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

ITSM ジーニーは、パスワードリセット、ポリシーへのリンク、アカウントのロック解除などの適切なアクションを自律的に決定し、検証された user_email メタデータを使用して Okta でパスワードリセットを実行することで、リクエストが偽装されないようにします。

ワークフローの概要

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

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

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

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

ワークフローの概要

• トリガー: スケジュールされたレシピが監査ジーニーをトリガーして、コンプライアンス証拠の収集を開始します。

• API 呼び出し: 監査ジーニーはスキルを使用して API エンドポイントレシピを呼び出します。

• タスクをジーニーに割り当て: API エンドポイントレシピは Assign task to genie アクションを使用して、証拠収集タスクを証拠収集ジーニーに送信し、レシピジョブを中断します。

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

• 応答の送信: タスクが完了すると、ジーニーはレシピに応答とメタデータを返します。

• レシピの再開: API エンドポイントレシピが再開し、ジーニーの応答を監査ジーニーに返します。

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

App Events と Assign task to genie の比較 ​

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

次の質問を検討してください: ユーザーがメッセージを受信し、アクションを実行する必要がありますか？

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

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

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

App Events を使用する場合 ​

次の場合に App Events を使用します。

• ユーザーに通知が必要で、アクションが必要になる可能性がある場合。例: 作成したチケットが更新された、または更新の機会が近づいている場合。
• プロセス中にユーザーの判断が必要な場合。ジーニーがコンテキストとオプションを提示し、ユーザーが決定します。
• ダウンストリームのスキルが 認証済みユーザーアクセス を必要とする場合。認証済みユーザーアクセスにはアクティブなユーザーセッションが必要です。
• フローに ビジネス承認 が含まれる場合。承認通知はユーザーのチャットインターフェースに表示され、ユーザーの操作が必要です。
• ジーニーが会話をプロアクティブに開始する必要がある場合。例: スケジュールされたリマインダーやイベントトリガーアラート。

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

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

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

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

Assign task to genie アクションは次の機能と一緒に使用できません。

• 認証済みユーザーアクセス: ヘッドレス呼び出しではユーザーコンテキストが存在しないため。
• ビジネス承認: 承認通知はユーザーのチャットインターフェースを通じて配信されるため。
• 権限対応のナレッジベース: ユーザースコープの権限で取り込まれたナレッジベースは、ユーザーコンテキストなしではそれらの権限を適用しないため。

これらは設定の選択肢ではなく、プラットフォームの制約です。

App Events と Assign task to genie の比較 ​

次の比較表を使用して、どちらの機能を使用するかを判断してください。

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

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

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

よくある間違い ​

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

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

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

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