スキルプロンプト
スキルプロンプトは、スキルを呼び出すかどうか、およびその使用方法を決定する際にLLMが読む説明です。 適切に記述されたスキルプロンプトにより、信頼性の高い呼び出しと正確なスキル選択が可能になります。
このページでは、効果的なスキルプロンプトを作成するための例を含む完全なテンプレートを提供します。 スキルプロンプトの各部分が何を行い、なぜ重要なのかを理解するため、テンプレートの各セクションを必ず確認してください。
スキルプロンプトテンプレート
すべてのスキルプロンプトで次のテンプレートを使用する必要があります:
目的:[スキルの機能の1行要約]
説明:[スキルの機能、連携するシステム、
および返す内容についての2~3文の説明]
使用する場合:
- [このスキルが適している具体的なシナリオ1]
- [具体的なシナリオ2]
- [必要に応じて具体的なシナリオ3]
使用しない場合:
- [代わりに別のスキルを使用する必要があるシナリオ]
- [このスキルの使用対象外となる制限または制約]
- [スキルを呼び出すべきではないシナリオ]
入力要件:
- [フィールド名]:[入力方法、値の取得元、
形式要件、有効な値]
- [フィールド名]:[各入力フィールドについて繰り返し]
出力要件:
- [スキルが返す内容、およびGenieが
それを使用または提示する方法]
- [ソースURLを引用する必要があるかどうか]
- [出力に関する形式指定]目的
目的は、スキルが行うことを要約する1つの文です。 これは、ユーザーリクエストに対してこのスキルを呼び出すかどうかを評価する際に、LLMが最初に読むものです。 目的行は、LLMがさらに読み進めなくても、このスキルを他のスキルと区別できる程度に具体的である必要があります。 2つのスキルの目的行が似ている場合、LLMはどちらを選ぶべきか判断しにくくなります。
次の形式で記述します: [Action] [object] [in/from system]
推奨 ✅
目的:申請ユーザーに代わってWorkdayに
休暇申請を送信します。目的:Salesforceから未完了の商談、
主要な連絡先、および最近のアクティビティを含む
アカウントサマリーを取得します。目的:指定されたカテゴリーと優先度で、
Jira Service Managementにサポートチケットを
作成します。非推奨 ❌
目的: 休暇関連。目的:このスキルはHRシステムで休暇申請を
処理し、ユーザーが休暇を希望する場合に
送信処理を実行します。目的: Workday API呼び出し。説明
説明では、目的を2~3文で詳しく述べます。 スキルがどのシステムとやり取りするか、そのコンテキストがLLMによる正しい使用に役立つ場合はスキルが内部で何を行うか、そして何を返すかを扱います。 説明は、1つの目的行に収まりきらないコンテキストを記述する場所です。 前提条件が「使用する場合」セクションにまだ含まれていない場合は、ここで前提条件を記載することもできます。 例: this skill should only be called after the user has confirmed the request details
推奨 ✅
説明:Workdayの欠勤管理APIを呼び出して、
認証済みユーザーの休暇申請レコードを作成します。
休暇タイプ、開始日、終了日、および任意の理由を
受け入れます。申請参照番号と送信ステータスを
返します。非推奨 ❌
説明: Workday APIを呼び出します。使用する場合
「使用する場合」は、このスキルをトリガーする具体的なシナリオの一覧です。 これには、実際のユーザーリクエストに対応する具体的かつ明確な条件を含む、スキルの一般的な適用範囲が含まれます。 「使用する場合」の各項目は、一般的な記述ではなく、具体的なトリガー条件として記述します。
推奨 ✅
使用する場合:
- ユーザーが休暇申請を送信する意思を確認し、
すべての必須フィールドが収集済みである
- ユーザーが休暇の予約、申請、または取得を
明示的に依頼し、休暇タイプと日付が
確認済みである
- 休暇申請フローが進行中で、
ユーザーが続行する明示的な確認を提供している非推奨 ❌
使用する場合:
- 休暇リクエスト
- ユーザーが休暇を希望する場合
- HR関連のアクション使用しない場合
「使用しない場合」は、スキルプロンプトで最も十分に活用されていない部分であり、誤った呼び出しを防ぐうえで最も重要です。 これは、このスキルを呼び出さない場合をLLMに伝えます。
このセクションでは、このスキルと他のスキルの境界を定義します。 2つのスキルが関連する目的を果たす場合、他のスキルに言及した明示的な「使用しない場合」句により、LLMが誤って選択することを防げます。
「使用しない場合」句は、次の内容に対して記述します:
- ユーザーのリクエストの言い回しがこのスキルをトリガーするように聞こえるものの、実際には別のスキルを呼び出すべきである、よくある誤ルーティングシナリオ。
- 関連する目的を果たす代替スキル。 スキル間の境界を明確にします。
- 満たされていない前提条件。 早すぎる呼び出しを明示的にブロックします。
- スキルが正しく処理できないシナリオを含む、このスキルの制限。
推奨 ✅
使用しない場合:
- ユーザーが休暇ポリシーまたは資格について
質問している場合:代わりにKnowledge
Baseを使用します
- ユーザーが申請の詳細をまだ確認していない場合:
先に確認を収集します
- 休暇タイプまたは日付がまだ曖昧である、
または提供されていない場合
- ユーザーが既存の休暇申請のステータス確認を
依頼している場合:代わりにGet
Leave Status Skillを使用します
- ユーザーが休暇申請のキャンセルを依頼している場合:
代わりにCancel Leave Request Skillを使用します非推奨 ❌
使用しない場合:
情報がナレッジベースにある場合は、このスキルを呼び出さないでください。入力要件
入力要件は、スキルが受け付けるすべての入力フィールドを対象とします。 入力要件は、ほとんどのスキル失敗を修正する場所です。 誤った値、誤った形式、または誤ったソースからフィールドに入力されている場合、その根本原因はほとんどの場合、フィールドヒントが不十分であることです。
特に次の点に注意してください:
IDフィールド: ユーザーメールやユーザーIDなどのIDフィールドは、必ずスキルプロンプトで指定します。 これは会話からではなく、認証済みのスキルコンテキストから取得する必要があります。 これにより、ユーザーが
do this for my colleagueと言った場合に、Genieが他のユーザーの代理でアクションを実行することを防げます。以前のスキル出力から派生するフィールド: Get Service Desks SkillからのサービスデスクIDや、Get Leave Balance Skillからの休暇タイプIDなど、以前のスキルの出力からフィールドに入力する必要がある場合は、その旨を明示的に記述します。
Use the leave_type_id field from the Get Leave Balance Skill output, not the leave type name the user provided。列挙型フィールド: 有効な値を明示的に一覧表示します。 一般知識に基づいて、どの値が有効かをLLMが知っていることに依存しないでください。
各フィールドについて次を指定します:
- 値の取得元
- フィールドに形式上の制約がある場合の形式要件
- フィールドが列挙型の場合の有効な値
- フィールドが必須か任意か
- 特別な処理手順
例
入力要件:
- leave_type(必須):申請される休暇のタイプ。
Get Leave Balance Skillによって返された
休暇タイプのいずれか1つと完全に一致する必要があります。
オプションをユーザーに提示し、ユーザーが選択した
正確な値を使用します:言い換えたり省略したりしないでください。
- start_date(必須):休暇期間の初日。
形式:YYYY-MM-DD。
自然言語の日付("次の
月曜日"、"14日")をこの形式に変換してから
スキルに渡します。
- end_date(必須):休暇期間の最終日。
形式:YYYY-MM-DD。start_date以降である
必要があります。
- reason(任意):休暇申請の理由。
選択した休暇タイプで理由が必要な場合にのみ必須です:
Get Leave Balanceの休暇タイプの詳細を確認してください。
必須でない場合は、このフィールドを空のままにします。
- user_email(必須):申請ユーザーのメールアドレス。
スキルトリガーコンテキストの認証済みユーザーのメールを
使用します:会話内で言及されたメールアドレスは
使用しないでください。出力要件
出力要件は、スキルが返す内容とその使用方法をGenieに伝えます。 初回構築時には省略されることが多く、その結果、出力処理に一貫性がなくなります。 出力要件が特に重要なのは、次の場合です:
- スキル出力でステータスフィールドに基づく条件付き処理が必要な場合
- スキル出力に引用またはリンクする必要があるURLが含まれている場合
- ユーザー向けにスキル出力を特定の方法で書式設定する必要がある場合
- スキル出力が後続のスキル呼び出しに渡され、どのフィールドを渡すかをGenieが知る必要がある場合
例
出力要件:
- 申請参照番号(request_idフィールド)と
送信ステータス(statusフィールド)を返します
- 確認として参照番号をユーザーに提示します:"休暇申請が
送信されました。参照番号:[id]"
- statusが"pending_approval"の場合は、
申請が確定される前にマネージャーの承認が必要であることを
ユーザーに通知します
- statusが"error"の場合は、
送信に失敗したことをユーザーに通知し、
HRに直接連絡することを提案しますスキルプロンプトの例
次は、テンプレートのすべてのセクションを使用したSubmit Leave Requestスキルの完全なスキルプロンプトです:
目的:申請ユーザーに代わってWorkdayに
休暇申請を送信します。
説明:Workdayの欠勤管理APIを呼び出して、
認証済みユーザーの休暇申請を作成します。休暇タイプ、
開始日、および終了日が必要です。申請参照番号と送信
ステータスを返します。このスキルを呼び出す前に、
ユーザーが申請の詳細を確認する必要があります。
使用する場合:
- ユーザーが休暇申請を送信する意思を確認している
- すべての必須フィールドが収集済みである:
休暇タイプ、開始日、および終了日
- ユーザーが提示された申請サマリーを
明示的に確認している
使用しない場合:
- ユーザーが休暇ポリシーまたは資格について
質問している場合:代わりにKnowledge Baseを
検索します
- ユーザーが申請の詳細をまだ確認していない場合:
確認なしで送信しないでください
- 休暇タイプまたは日付が曖昧である、
または提供されていない場合
- ユーザーが既存の申請の確認を希望している場合:
代わりにGet Leave Statusを使用します
- ユーザーが申請のキャンセルを希望している場合:
代わりにCancel Leave Requestを使用します
入力要件:
- leave_type(必須):Get Leave
Balanceの出力に含まれる休暇タイプのいずれか1つと
完全に一致する必要があります。そのスキルによって返された
正確な値を使用します。
- start_date(必須):休暇の初日。
形式:YYYY-MM-DD。自然言語の日付を
この形式に変換します。
- end_date(必須):休暇の最終日。
形式:YYYY-MM-DD。start_date以降である
必要があります。
- reason(任意):Get Leave
Balanceの出力に基づき、休暇タイプで理由が必要な場合にのみ
必須です。必須でない場合は空のままにします。
- user_email(必須):スキルトリガーコンテキストの
認証済みユーザーのメールを使用します。
会話内のメールは絶対に使用しないでください。
出力要件:
- request_idを参照番号としてユーザーに返します
- statusが"pending_approval"の場合:
確定前に承認が必要であることをユーザーに通知します
- statusが"error"の場合:送信に失敗したことを
ユーザーに通知し、HRに直接連絡することを提案します最終更新日: