Fin Tasksを使用すると、Finに実行してほしいタスクのステップバイステップの指示を与えることができます。Fin向けの指示を書く際のベストプラクティスと例をいくつかご紹介しています。

明確に書かれた指示は、Finタスクのパフォーマンスに大きな違いをもたらします。

Fin Tasksの詳細に入る前に、大規模言語モデル（LLM）を扱う際に一般的に役立つヒントをいくつかご紹介します。

追加の参考資料については、こちらの導入トピックをご覧ください。

Finは前のステップや実行されたアクション、保存されたデータの記憶を保持しますが、明確な境界と焦点を持った目的でタスクを設計する必要があります。

単一のFin Taskを使用する場合：

複数のFin Tasksを検討する場合：

タイトルは説明的で、内部用だけでないことを確認してください。

Finがこのタスクをトリガーすべき状況を説明するために3～5文を書いてください。できるだけ具体的にし、以下のいずれかを必ず含めてください。

良い例：

配送中に破損した注文（飲み物の漏れ、食べ物のこぼれ、容器の破損など）を顧客が報告した場合にこのタスクを使用してください。遅延配送、欠品、製品の破損に関係ない問題の報告にはこのタスクを使用しないでください。

悪い例：

注文の返金にこのタスクを使用してください。

指示ブロックは以下のセクションで構成される構造化フォーマットに従います。

1. 指示：

これはFinが従うべき明確で論理的に完結したステップバイステップの計画です。Finがタスクを実行するために必要なすべての意思決定ルールをカバーしてください。

これらを作成する最良かつ最も簡単な方法は、「if + else」ロジックに従うことです。このロジックにより、どの段階でも必ず意思決定ができ、解決に向けて進むか、行き詰まった場合にプロセスから抜け出す方法が得られます。例としては次のようになります。

1. 注文日が判明し、30日以内であれば返金を行う。

2. 注文日が判明したが30日を超えている場合、Company Xのポリシーでは30日以上前の購入に対する返金は認められていないと顧客に伝える。

3. それ以外の場合は、サポートチームの人間メンバーにエスカレーションすると顧客に伝え、エスカレーションを実行する（この例ではエスカレーションロジックがFin Taskに組み込まれていることを前提とする）。

Finがアクセスするロジックや情報があまりにも曖昧な場合は、指示ブロックをより小さなステップに分け、より明確で制約のあるロジックにすることを検討してください。

タスクを実行するために必要な入力値も特定する必要があります。プロンプトで明確に述べてください。

2. ガイダンス（任意）:

Finがタスク中にどのように対話し、応答し、振る舞うかを明確に指示してください。Finに従ってほしい特定の行動を簡潔に説明してください。

Finタスクを管理するための重要なベストプラクティスは、下書きとして保存機能を使うことです。これにより、顧客に影響を与えずにタスク指示の編集やテストが安全に行えます。

ライブタスクを編集すると、2つのバージョンが作成されます。

これにより、公開前に自動化を完璧に仕上げる安全な環境が得られます。タスクエディター内のプレビューとシミュレーション機能を使って下書きバージョンを必ずテストしてください。自信がつき、変更を公開ボタンをクリックするまで変更はライブになりません。

タスクのマッチング精度を向上させるために、タスクをトリガーすべき質問とすべきでない質問の具体的な例を提供してください。これにより、特に類似タスクが複数ある場合にFinが適切にタスクを使う判断がしやすくなります。

ポジティブ例（「トリガーする場合...」）とネガティブ例（「トリガーしない場合...」）の両方を追加できます。

約10件の非常に関連性の高い例示的な質問や顧客フレーズから始めて、タスクが正しく認識されるようにしてください。必要に応じて20～30件に拡張できますが、複雑さに注意してください。リストが長すぎたり具体的すぎる場合は、説明を簡素化するか、意図ベースのトリガーに切り替えて明確さと管理のしやすさを保つことを検討してください。

「トリガーしない場合...」の例は、誤ったトリガー動作が観察される場合にのみ含めてください。ネガティブ例はFinが反応すべきでないものを明確にして検出を改善しますが、誤作動の問題に対処している場合以外は追加を避けてください。

タスクが単純でおおよそ10ステップ未満の場合は、単一の構造化された指示ブロックを使用してください。複雑なロジックや大きな分岐がある場合、または追従が難しい場合は、明確さと保守性のために複数の指示ブロックに分割するのが最適です。

データコネクターを実行する前にすべての入力を手動で集める必要はありません。データコネクターの設定時に必要な入力を指定すると、Finが不足している入力を自動的に顧客に尋ねます。これにより指示の複雑さが減り、やり取りが効率的になります。

Finは会話の途中でタスクを切り替えたり、文脈や顧客の意図が変わった場合に情報回答（サポートコンテンツから）に切り替えたりできます。これにより、1つのタスクを終了して別のタスクをシームレスに開始でき、ユーザーの変化するニーズに基づいたより動的で応答性の高い対話が可能になります。

Finは同じ指示ブロック内でAPIレスポンスを自動的に記憶します。後のステップで「先ほど返された残高を使って」など自然に結果を参照できます。データを繰り返したり手動で保存する必要はありません。

APIレスポンスを明示的に一時属性に保存する必要はありません。Finは内部でデータを管理しており、後続のステップで自然言語で直接参照できます。

会話にタグを付ける

Finにタスク指示で事前定義されたタグを使って会話にタグ付けするよう指示し、会話の分類を改善します。これによりフィルタリング、レポート作成、フォローアップアクションのトリガーが容易になります。

例示指示:

"会話にタグを付ける '請求に関する問い合わせ' と '高優先度'。"

チームにエスカレーションする

人間の介入が必要な会話をスムーズに引き継ぐため、Finに特定のチームやチームメンバーにエスカレーションするよう指示します。

例示指示:

"エスカレーション先: 請求"

以下に、Finタスクの形作りに役立つさまざまなユースケースのプロンプトをまとめました。

説明: このタスクの目的は、顧客からの返金リクエストが有効かどうかを判断し、有効であれば処理することです。以下の指示に従うことで、Company Xでの注文に対する顧客の返金リクエストを検証し処理できます。

ステップ1: 注文ID @collected_order_id の注文詳細を取得するために @get_order_details を使用します。その後、取得した注文が返金可能かどうかを以下のロジックで判断します。

ステップ2: 注文ID @collected_order_id で @process_items_refund を使用して返金処理を行います。その後、レスポンスを取得し、以下を実行します。

ガイダンス: 返金拒否のネガティブな知らせを伝える際は共感的に対応してください。返金が成功した場合は、返金処理のタイムラインについて温かく明確に伝えてください。

説明: このタスクの目的は、顧客からのサブスクリプション解約リクエストが有効かどうかを判断し、有効であれば処理することです。以下の指示に従うことで、Company Xの顧客のサブスクリプションを検証し解約できます。

ステップ1：ID @collected_subscription_id のサブスクリプションの詳細を取得するために @get_subscription_details を使用します。その後、取得したサブスクリプションがキャンセル可能かどうかを以下のロジックに従って判断します。

ステップ2：ID @collected_subscription_id のサブスクリプションをキャンセルするために @cancel_subscription を使用します。その後、応答を収集し、以下に従います。

ガイダンス：契約期間について説明する際は、事実を淡々と伝えつつも共感を示してください。成功した場合は、今後の請求について明確に確認してください。

説明：このタスクの目的は、お客様からの配送先住所変更のリクエストが有効かどうかを判断し、有効であれば処理することです。以下の指示に従い、Company Xのシステムで配送先住所を確認・更新します。

ステップ1：ID @collected_customer_id を使用して @get_customer_profile からお客様の現在のアカウント状況を取得します。その後、以下のロジックに従います。

ステップ2：@collected_new_address を提供して @validate_address を使用し、その住所の正当性と配達可能性を確認します。その後、以下のロジックに従います。

ステップ3：@collected_customer_id と @collected_new_address の両方を提供して @update_customer_address を使用し、住所の更新を完了します。その後、以下のロジックに従います。

ガイダンス：サポートされている地域を明確に伝えてください。住所変更が成功した場合は、今後のすべての発送に影響することをお客様にお知らせください。

説明：このタスクの目的は、お客様のロイヤルティポイント調整のリクエストが有効かどうかを判断し、有効であれば調整を実行することです。以下の指示に従い、お客様のロイヤルティアカウントの状況を確認し、リクエストを検証し、その後Company Xのシステムでポイントを調整します。

ステップ1：ID @collected_loyalty_member_id を使用して @get_loyalty_profile からメンバーのアカウント状況を取得します。その後、以下のロジックに従います。

ステップ2： @collected_loyalty_member_id と @collected_points_adjustment_request を使用して @audit_loyalty_activity を実行し、最近のロイヤルティ取引を確認してリクエストが正当かどうかを判断します。その後：

ステップ3： @collected_loyalty_member_id と @collected_points_adjustment_request の金額を使用して @adjust_loyalty_points を実行し、ポイント調整を完了します。その後：

ガイダンス： ポイント調整が成功した場合は、ポイントが発生した特定の取引を参照してください。リクエストを拒否する際はプログラムのポリシーについて説明してください。