Fin Tasksを使うと、Finに実行してほしいタスクのステップバイステップの指示を与えられます。Fin向けの指示を書く際のベストプラクティスと例をいくつかご紹介します。
注意：Fin Tasksは現在、管理された利用可能性のもとで、カスタマイズされた実践的サポートを提供しています。アクセスについてはアカウントマネージャーにご相談ください。
Finタスクのベストプラクティス
明確に書かれた指示は、Finタスクのパフォーマンスに大きな違いをもたらします。
一般的なLLMプロンプトのヒント
Fin Tasksの詳細に入る前に、大規模言語モデル（LLM）を扱う際に一般的に役立つヒントをいくつかご紹介します。
良いプロンプトは必須であり、指示的であるべきです。文は動詞で始め、受動態は避けてください。
あいまいさを残さないこと：詳細な指示は簡潔な指示より優れています。
追加の参考資料については、こちらの導入トピックをご覧ください。
タスクの範囲と構成
Finは前のステップや実行したアクション、保存されたデータを記憶しますが、それでも明確な境界と目的を持ったタスク設計が必要です。
単一のFin Taskを使う場合：
すべてのステップが明確な進行を持つ一貫したプロセスの一部である。
後のステップは論理的な順序で前のステップに依存している。
プロセス全体が同じ意思決定基準と結果を共有している。
複数のFin Tasksを検討する場合：
完全に別のビジネスプロセスの場合
複雑なワークフローで明確なチェックポイントを作成する必要がある場合
異なる利害関係者やチームがプロセスの異なる部分を担当している場合
ワークフローへの異なる入り口を可能にしたい場合
タスク構造
トリガーのタイトルと説明
タイトルは説明的で、単なる内部用でないことを確認してください。
良い例：Damaged orders
悪い例：Test123
Finがこのタスクをトリガーすべき状況を説明するために、3～5文を書いてください。できるだけ具体的にし、以下のいずれかを必ず含めてください。
このタスクをトリガーするのに適切な一般的なシナリオ。
このタスクで回答される顧客の質問の例。
顧客が使う可能性のあるキーフレーズ。
良い例：
配送中に破損した注文（飲み物の漏れ、食べ物のこぼれ、容器の破損など）を顧客が報告した場合にこのタスクを使用してください。遅延配送、欠品、製品の破損に関係ない問題の報告にはこのタスクを使用しないでください。
悪い例：
注文の返金にこのタスクを使用してください。
指示ブロック
指示ブロックは以下のセクションで構成された構造化フォーマットに従います。
1. 指示：
これはFinが従うべき明確で論理的に完結したステップバイステップの計画です。Finがタスクを実行するために必要なすべての意思決定ルールをカバーしてください。
これらを作成する最良かつ最も簡単な方法は、「if + else」ロジックに従うことです。このロジックにより、どの段階でも必ず意思決定ができ、解決に向けて進むか、行き詰まった場合にプロセスから抜け出す方法が得られます。例は以下のようになります。
1. 注文日が判明し、30日以内であれば返金を行う。
2. 注文日が判明したが30日を超えている場合、Company Xのポリシーでは30日以上前の購入に対する返金は認められていないと顧客に伝える。
3. それ以外の場合は、サポートチームの人間メンバーにエスカレーションすると顧客に伝え、エスカレーションを実行する（この例ではエスカレーションロジックがFin Taskに組み込まれていることを前提とする）。
Finがアクセスするロジックや情報があまりにも曖昧な場合は、指示ブロックをより明確で制約のあるロジックを持つ小さなステップに分割できるか検討してください。
タスクを実行するために必要な入力値も特定する必要があります。プロンプトに明確に記載してください。
これらの属性が何であり、何に使われるか、そしてこれらの属性がタスクの広い文脈とどのように関連しているか。
これらの属性が必ず利用可能かどうか（例：指示の前のステップから）
もしそうなら、どこで利用可能か、またはその値は何かをプロンプトに直接挿入する。
もしそうでなければ、どこでまたはどのように収集できるか（例：顧客から）
2. ガイダンス（任意）：
Finがタスク中にどのように相互作用し、応答し、振る舞うかを明確に指示してください。Finに従ってほしい特定の行動を簡潔に説明してください。
タスクの下書き
Finタスクを管理するための重要なベストプラクティスは、下書きとして保存機能を使用することです。これにより、顧客に影響を与えることなくライブタスクの変更を安全に編集・テストできます。
ライブタスクを編集すると、2つのバージョンが作成されます：
ライブバージョン：これは顧客が操作しているアクティブなタスクです。
下書きバージョン：これは未公開の変更セットで、プライベートに作業・テストできます。
これにより、公開前に自動化を完璧にする安全な環境が得られます。タスクエディター内のプレビューとシミュレーション機能を常に使用して下書きバージョンをテストしてください。自信がつき、変更を公開ボタンをクリックすると変更がライブになります。
タスクトリガー
約10件の例示的な質問を含めてください
タスクのマッチング精度を向上させるために、タスクをトリガーすべき質問とすべきでない質問の具体的な例を提供してください。これにより、特に類似タスクが複数ある場合にFinが適切にタスクを理解できます。
肯定的な例（「トリガーする場合...」）と否定的な例（「トリガーしない場合...」）の両方を追加できます。
タスクが正しく認識されるように、まず約10件の非常に関連性の高い例示的な質問から始めてください。必要に応じて20～30件に拡張できますが、複雑さに注意してください。リストが長すぎたり具体的すぎる場合は、説明を簡素化するか、意図ベースのトリガーに移行して明確さと管理性を保つことを検討してください。
誤トリガー時のみ否定的な例を使用してください
「トリガーしない場合...」の例は、誤ったトリガー動作が観察された場合にのみ含めてください。否定的な例はFinが応答すべきでないものを明確にすることで検出を改善しますが、誤作動の問題に対処している場合以外は追加を避けてください。
タスク指示
タスクが複雑な場合のみ指示を分割してください
タスクが単純でおおよそ10ステップ未満の場合は、単一の構造化された指示ブロックを使用してください。複雑なロジックや大きな分岐がある場合、または追従が難しい場合は、明確さと保守性のために複数の指示ブロックに分割するのが最適です。
データコネクターの入力はFinに自動収集させる
データコネクターを実行する前にすべての入力を手動で収集する必要はありません。データコネクターの設定時に必要な入力を指定すると、Finが不足している入力を自動的に顧客に尋ねます。これにより指示の複雑さが軽減され、やり取りが効率的になります。
会話中のタスク切り替えが許可されている
Finは会話の途中でタスクを切り替えたり、コンテキストや顧客の意図が変わった場合に情報回答（サポートコンテンツから）に切り替えたりできます。これにより、1つのタスクを終了して別のタスクをシームレスに開始でき、ユーザーの変化するニーズに基づいたより動的で応答性の高い対話が可能になります。
APIの応答は指示ステップ間で記憶される
Finは同じ指示ブロック内でAPIの応答を自動的に記憶します。後のステップで「先ほど返された残高を使用して」など自然にこれらの結果を参照できます。データを繰り返したり手動で保存する必要はありません。
APIの応答を一時属性に保存する必要はない
APIの応答を明示的に一時属性に保存する必要はありません。Finは内部でデータを管理しており、後続のステップで簡単な自然言語を使って直接参照できます。
指示ステップでタグ付けを活用する
会話にタグを付ける
Finにタスク指示で事前定義されたタグを使って会話にタグ付けするよう指示し、会話の分類、報告、フォローアップアクションのトリガーに役立ててください。
例示指示：
"会話にタグを付ける '請求に関する問い合わせ' と '高優先度'。"
注意：指示で使用するタグはFinワークスペースで設定されているタグと一致していることを確認してください。
Finタスクの例
以下に、Finタスクの形作りに役立つさまざまなユースケースのプロンプトをまとめました。
注文の返金
説明：このタスクの目的は、顧客からの返金リクエストが有効かどうかを判断し、有効であれば処理することです。以下の指示に従うことで、Company Xでの注文に対する顧客の返金リクエストを確認し処理できます。
ステップ1：注文ID @collected_order_id の注文詳細を取得するために @get_order_details を使用します。次に、取得した注文が返金可能かどうかを判断するために以下のロジックに従ってください。
注文日が現在日付より30日以上前の場合、注文が30日以上前に行われたため返金できないことを顧客に伝えてください。@refund_outcome を「denied」に設定し、結果を顧客に通知してください。
注文日が現在日付より30日未満の場合は、ステップ2に進んでください。
それ以外の場合は、注文が返金可能かどうか確認できないことを顧客に伝え、サポートチームの人間メンバーにエスカレーションしてください。@refund_outcome を「escalation」に設定し、この対応を行ったことを顧客に伝えてください。
ステップ2：注文ID @collected_order_id を使って @process_items_refund で返金処理を行います。次に応答を収集し、
返金が成功した場合、返金処理が正常に完了したことを顧客に伝えてください。@refund_outcome を「success」に設定し、結果を顧客に通知してください。
返金が失敗した場合は、返金処理ができなかったことを顧客に伝えてください。@refund_outcome を「escalation」に設定し、この対応を行ったことを顧客に伝えてください。
ガイダンス：返金拒否のネガティブな知らせを伝える際は共感的に対応してください。返金が成功した場合は、返金処理のタイムラインについて温かく明確に伝えてください。
サブスクリプション解約リクエスト
説明：このタスクの目的は、顧客からのサブスクリプション解約リクエストが有効かどうかを判断し、有効であれば処理することです。以下の指示に従うことで、Company Xの顧客のサブスクリプションを確認し解約できます。
ステップ1：サブスクリプションID @collected_subscription_id の詳細を取得するために @get_subscription_details を使用します。次に、取得したサブスクリプションが解約可能かどうかを判断するために以下のロジックに従ってください。
サブスクリプションがまだ最低契約期間中（12か月の期間が経過していない）場合：
サブスクリプションが契約期間内のため、現時点で解約できないことを顧客に伝えてください。
@cancellation_outcome を「denied」に設定してください。
サブスクリプションが解約可能な場合（月単位のプランか契約期間が終了している場合）：
ステップ2に進んでください。
それ以外の場合、サブスクリプションの詳細からキャンセル可能か判断できない場合：
サブスクリプションのキャンセル適格性を確認できないことをお客様に伝え、サポートチームの担当者にエスカレーションしてください。
@cancellation_outcome を「escalation」に設定します。
ステップ2：サブスクリプションID @collected_subscription_id を使って @cancel_subscription でキャンセル処理を行います。その後、応答を収集し、以下に従います。
キャンセルが成功した場合：
サブスクリプションが正常にキャンセルされたことをお客様にお知らせください。
@cancellation_outcome を「success」に設定します。
キャンセルが失敗した場合：
サブスクリプションをキャンセルできなかったことをお客様に伝え、問題をエスカレーションしたことをお知らせください。
@cancellation_outcome を「escalation」に設定します。
ガイダンス：契約期間について説明する際は、事実を伝えつつ共感を示してください。成功した場合は、今後の請求について明確に確認してください。
住所変更リクエスト
説明：このタスクの目的は、お客様からの配送先住所変更のリクエストが有効かどうかを判断し、有効であれば処理することです。以下の指示に従い、Company Xのシステムで配送先住所を確認・更新します。
ステップ1：ID @collected_customer_id を使って @get_customer_profile でお客様の現在のアカウント状況を取得します。その後、以下のロジックに従います。
お客様のアカウントがロックされているかフラグが立っている場合（account_status が「suspected fraud」または「unpaid balance」）：
アカウント制限のため住所変更を進められないことをお客様に伝えてください。
@address_change_outcome を「denied」に設定します。
お客様のアカウントがアクティブで更新可能な場合：
ステップ2に進んでください。
それ以外に、システムがアカウント状況を判断できないか情報が不十分な場合：
住所変更が可能か確認できないことをお客様に伝え、人間のサポート担当者にエスカレーションしてください。
@address_change_outcome を「escalation」に設定します。
ステップ2：@collected_new_address を使って @validate_address で住所の正当性と配達可能性を確認します。その後、以下のロジックに従います。
新しい住所が認識されないか、Company Xのサービス対象地域外の場合（住所の値は「United States」、「European Union」、「Canada」のみで、他の地域はサポートされません）：
住所がサービス対象外または無効であることをお客様に伝えてください。
@address_change_outcome を「denied」に設定します。
住所が認識され、配達可能な場合：
ステップ3に進んでください。
住所検証結果が不確定またはシステムで判断できない場合：
住所を確認できないため、リクエストをエスカレーションしたことをお客様に伝えてください。
@address_change_outcome を「escalation」に設定します。
ステップ3：@collected_customer_id と @collected_new_address の両方を使って @update_customer_address で住所更新を完了します。その後、以下のロジックに従います。
住所更新が成功した場合：
住所が正常に更新されたことをお客様にお知らせください。
@address_change_outcome を「success」に設定します。
住所更新が何らかの理由で失敗した場合（システムエラーや記録の競合など）：
問題を人間のサポート担当者にエスカレーションしたことをお客様に伝えてください。
@address_change_outcome を「escalation」に設定します。
ガイダンス：サポートされる地域を明確にしてください。住所変更が成功した場合、今後のすべての発送に影響することをお客様に伝えてください。
ロイヤルティポイント調整
説明：このタスクの目的は、お客様のロイヤルティポイント調整リクエストが有効かどうかを判断し、有効であれば調整を実行することです。以下の指示に従い、お客様のロイヤルティアカウント状況を確認し、リクエストを検証し、Company Xのシステムでポイントを調整します。
ステップ1：ID @collected_loyalty_member_id を使って @get_loyalty_profile でメンバーのアカウント状況を取得します。その後、以下のロジックに従います。
ロイヤルティアカウントが非アクティブ、停止中、または不審な活動でフラグが立っている場合：
現在、ポイント調整の対象外であることをお客様に伝えてください。
@points_adjustment_outcome を「denied」に設定します。
アカウントが良好な状態の場合：
ステップ2に進んでください。
それ以外に、システムがアカウント状況を判断できない場合：
お客様のアカウントを確認できないため、サポート担当者にエスカレーションすることをお知らせください。
@points_adjustment_outcome を「escalation」に設定します。
ステップ2： @collected_loyalty_member_id と @collected_points_adjustment_request を提供して @audit_loyalty_activity を使用し、最近のロイヤルティ取引を確認してリクエストが正当かどうかを判断します。その後：
リクエストされた調整が請求期間外の取引に関する場合（請求日が90日以上前の場合）：
プログラムのポリシーによりリクエストを承認できないことを顧客に通知します。
@points_adjustment_outcome を「denied」に設定します。
リクエストが有効な場合（例：最近の対象購入からポイントが漏れていた場合）：
ステップ3に進みます。
監査結果が不確定の場合（該当する取引が見つからない、または部分的なデータのみの場合）：
さらなる調査が必要であり、人間の担当者にエスカレーションしていることを顧客に通知します。
@points_adjustment_outcome を「escalation」に設定します。
ステップ3： @collected_loyalty_member_id と @collected_points_adjustment_request の金額を提供して @adjust_loyalty_points を使用し、ポイント調整を完了します。その後：
ポイント調整が正常に処理された場合：
顧客にロイヤルティ残高が更新されたことを通知します。
@points_adjustment_outcome を「success」に設定します。
システムエラーや記録の競合により調整が失敗した場合：
リクエストを完了できなかったことを顧客に通知し、手動での確認のためにエスカレーションしたことを伝えます。
@points_adjustment_outcome を「escalation」に設定します。
ガイダンス： ポイント調整が成功した場合は、ポイントを生成した特定の取引を参照してください。リクエストを拒否する際はプログラムのポリシーについて詳しく説明してください。