これらの値を処理する前にユーザー入力を検証することは、ボットの効率とユーザー体験の向上に大きく貢献します。エンティティタイプはいくつかの基本的な制約を課しており、これらは必ずしも十分というわけではなく、特定のビジネス要件を満たしません。エンティティルールは、追加的処理のヒントおよび検証に使用可能です。
エンティティルールは、対応するエンティティのインスタンスプロパティにおけるエンティティルールセクションから追加できます。提供されているJSONエディターにおいてルールを追加します。 方法についてはこちらをご覧ください。
これらのルールは、エンティティのスクリプトに設定することもできますが、その場合、ルールはダイアログフローのエンティティプロンプトの前に設定しなければなりません。ダイアログの最初または当該エンティティノードの直前に、以下のスクリプトを含むスクリプトノードを追加します。
context.entityRules.<entityName> = { "ruleName": "value" }
サブエンティティルールは、複合エンティティルールの一部である場合もあります。
context.entityRules.<compositeEntityName> = { <subentityName> : { "ruleName": "value" } }
以下は、必要なエンティティをJSONエディターで入力したり、上記のスクリプトに ruleName
として含めることができるエンティティルールです。このリストは継続的に改善、更新しています。ご意見やご要望がございましたら、 コミュニティフォーラム にご投稿ください。できれば、開発者が対応いたします。
一般的なルール
ruleName | 値 | 説明 |
---|---|---|
processLatestSentence | true/false | チェック対象を現在のボレーの文のみに限定。 |
例
{ "processLatestSentence": <true/false> } |
||
patternsOnly | true/false | エンティティパターンのみで一致を制限。デフォルトで、指定のエンティティパターンがエンティティ値の抽出の結果に結びつかない場合、プラットフォームはユーザー発話から値を見つけようとします。このルールをtrueに設定すると、そのデフォルトの処理が無効になります。 |
例
{ "patternsOnly": <true/false> } |
||
allowConfirmation | true/false | 抽出されたエンティティ値は、入力のたびにユーザーに提示され、ユーザーが確認した後にフローが続行されます。現在、このルールはLoVの列挙されたエンティティタイプにのみ適用されます。 |
例
{ "allowConfirmation": <true/false> } |
||
confirmYesSynonyms | <concept names> | エンティティ値を確認するために使用される追加の単語/フレーズ。前述のallowConfirmationルールと合わせて使用されます。 |
例
{ "confirmYesSynonyms": ["~concept1", "~concept2"] } where concept1: ok; concept2: affirmative |
||
confirmNoSynonyms | <concept names> | 確認エンティティをキャンセルする際に使用する追加の単語/フレーズ。前述のallowConfirmationルールと合わせて使用します。 |
例
{ "confirmNoSynonyms": ["~concept2", "~concept3"] } where concept1: nope; concept2: wrong |
文字列型のエンティティ
説明エンティティタイプ
ruleName | 値 | 説明 |
---|---|---|
stripLeading | <concept name> | 抽出された文字列の先頭から、概念で与えられた単語を削除。概念は、単一の概念名、またはスペースで区切られた概念のリスト、あるいは概念名の配列である場合もあります。 |
例 | ||
JSON
{ "stripLeading": [ "~stringConcept" ] } |
stringConcept: city エンティティパターン: 私は*が好きですユーザー発話 「私はニューヨーク市が好きです」抽出された値 ニューヨーク | |
stripTrailing | <concept name> | 抽出された文字列の最後から、概念に含まれる単語を削除。概念は、単一の概念名、またはスペースで区切られた概念のリスト、あるいは概念名の配列である場合もあります。 |
例 | ||
JSON
{ "stripTrailing": "~stringConcept ~stringConcept1" } |
stringConcept: city; stringConcept1: airport エンティティパターン: 私は*が好きですユーザー発話 「私はニューヨーク市が好きです」または「私はニューヨーク空港が好きです」抽出された値ニューヨーク | |
avoidSingleWord | <concept name> | 概念のメンバーであるいかなる値も、それが入力全体でない限り無視すること。概念は、単一の概念名、またはスペースで区切られた概念のリスト、あるいは概念名の配列である場合もあります。 |
例 | ||
JSON
{ "avoidSingleWord": "~stringConcept" } |
stringConcept: チェス、クリケットエンティティパターン: *トーナメントを観るのが好きですユーザー発話 「私はチェスのトーナメントを観るのが好きです」抽出された値 エンティティ値のプロンプトユーザー発話「私はゴルフのトーナメントを観るのが好きです」抽出された値ゴルフユーザー発話 「クリケット」抽出された値クリケット、入力全体という理由で | |
avoidSingleVerb | true | trueに設定すると、入力全体でない限り、動詞だけの値は無視されます。 |
例 | ||
JSON
{ "avoidSingleVerb": true } |
エンティティパターン: 私は*ミュージックが好きですユーザー発話 「私は演奏ミュージックが好きです」 抽出された値 エンティティ値のプロンプトユーザー発話 「私はラップミュージックが好きです」 抽出された値 ラップユーザー発話 「演奏」 抽出された値演奏、入力全体から | |
extractOnlyNumbers | true | trueの場合、文字列に含まれる数字のみを抽出し、それをエンティティの値として設定します。 |
例 | ||
JSON
{ "extractOnlyNumbers": true } |
番号型エンティティ
ruleName | 値 | 説明 |
---|---|---|
asString | true | 先頭のゼロを残して数字を文字列としてキャプチャ |
例 | ||
JSON
{ "asString": true } |
エンティティパターン – デフォルトでは数字エントリユーザー発話「OTPは009944」抽出された値「009944」 ルールがなかったら、「9944」だったでしょう |
通貨型エンティティ
ruleName | 値 | 説明 |
---|---|---|
defaultCode | <currency code> or <country code> | ユーザー入力にコードが記載されていない場合は、この値がコードとして選択されます。値は、3文字の通貨コードまたは2文字の国別アルファ-2コードである必要があります。 |
例 | ||
JSON
{ "defaultCode": "NZD" } |
エンティティパターン*を払うユーザー発話「30を払う」抽出された値「NZD30」ユーザー発話「USD30を払う」抽出された値「USD30」 | |
maxDigits | <number> | 金額の長さを制限金額の長さが値を超えた場合は破棄されます。 |
例 | ||
JSON
{ "maxDigits":[ "3" ] } |
エンティティパターン*を払うユーザー発話「 USD30を払う」抽出された値「USD30」ユーザー発話「USD3000を払う」抽出された値値のプロンプト | |
currencyCodes | [<currency code>,<currency code>] or [<country code>,<country code>] | 通貨コードを制限ユーザー入力のコードが所定のリストにない場合、その値は破棄されます。 |
例 | ||
JSON
{ "currencyCodes": [ "USD", "INR", "NZD" ] } |
エンティティパターン*を払うユーザー発話「 USD30を払う」抽出された値「USD30」ユーザー発話「AUD30を払う」抽出された値値のプロンプト |
PersonName タイプエンティティ
ruleName | 値 | 説明 |
---|---|---|
disablePatterns | 無視する人名パターンの配列 – 現在は"possessive" のみをサポートしています。 | 特定のシナリオで適用されない場合に、人名を抽出するパターンを無効化。 |
例 | ||
JSON
{ "disablePatterns": [ "possessive" ] } |
エンティティパターン– デフォルトでは大文字の単語ユーザー発話「Bobのreviewを午前9時に予定」抽出された値「Bob」 | |
ignoreWords | <concept name> | 概念に含まれる単語は、大文字であっても名前とはみなされません。概念名には、スペースで区切られた概念のリスト、または概念の配列を指定できます。 |
例 | ||
JSON
{ "ignoreWords": [ "review", "~prepositionList" ] } |
エンティティパターン – 定義では大文字の単語ユーザー発話「BobのReviewのための会議」抽出された値「Bob」 ルールがなければ「Bob Review」になっていたでしょう | |
negativePatterns | array of patterns | 人名は一般的な大文字の単語であったり、人としての意味を持たない意味での名前が使われたりします。 |
例 | ||
JSON
{ "negativePatterns": [ "about *" ] } |
エンティティパターン – 定義では大文字の単語ユーザー発話「PhilipとFredとの会議を予定」抽出された値「Fred」ルールがなければ「Philip」になっていたでしょう |
会社タイプのエンティティ
ruleName | 値 | 説明 |
---|---|---|
ignoreWords | <concept name> | 概念に含まれる単語は、大文字であっても会社とはみなされません。概念名には、スペースで区切られた概念のリスト、または概念の配列を指定できます。 |
例 | ||
JSON
{ "ignoreWords": [ "atm" ] } |
エンティティパターン – 定義では大文字の単語ユーザー発話「ATMを探す」抽出された値ルールがなかったら、「ATM」(イタリアの会社)ではなかったでしょう。 | |
negativePatterns | 除外する会社名パターンの配列 | 特定のシナリオに適用されない場合に、人名を抽出するパターンを無効化。 |
日付型エンティティ
ruleName | 値 | 説明 |
---|---|---|
range | { “from” : <from-date>, “to” : <to-date> } | 指定した範囲の日付のみを抽出。どちらのエンドポイントもオプションです。値には、YYYY-MM-DDの日付や、今日、明日、昨日といったキーワードを使用できます。日付は包括的なものです。 |
例 | ||
JSON
{ "range": { "from": "2020-01-01", "to": "today" } } |
エンティティパターン– デフォルトでは日付パターンユーザー発話「2019-02-03の予定を表示」 抽出された値値のプロンプトユーザー発話「明日の予定を表示」抽出された値 値のプロンプトユーザー発話「2019-02-03の予定を表示」抽出された値「2020-02-03」 | |
referenceDate | <date> | 条件日を<date>に設定すると、現在の日付のエンティティ値を設定するための日付計算は、その日付に基づいて行われます。値には、YYYY-MM-DDの日付や、今日、明日、昨日といったキーワードを使用できます。 |
例 | ||
JSON
{ "referenceDate": "2020-07-09" } |
エンティティパターン– デフォルトでは日付パターンユーザー発話「2日後の予定」抽出された値 「2020-07-11」は、基準日がなければ、現在の日付から2日後の日付になっていたでしょう | |
preferredDateFormat | "yyyy-mm-dd" | 日付が曖昧な場合は、優先する日付形式を使用して曖昧さを解消します。値は以下が可能:
|
例 | ||
JSON
{ "preferredDateFormat": "mm-dd-yyyy" } |
ユーザー発話「03-04-2021」抽出された値「2021-03-04」 メモ:このルールは、ユーザーの発話に曖昧さがある場合にのみ登場します。ユーザーの好みが以前の会話の一部として既に設定されている場合、ユーザーが選択した形式が定義されたルールよりも優先されます。例として、先のユースケースでは、ユーザーが以前の会話で好みの形式として「dd-mm-yyy」を選択していた場合、日付は「2021-04-03」として扱われます。 | |
returnOnlyMonthYear | <true/false> | trueに設定した場合、プラットフォームはユーザー入力から月と年だけをキャプチャして、それに合わせてコンテキストオブジェクトを更新します。たとえユーザーがすべて(2019年10月20日など)を入力したとしても、システムはその入力から2019年10月だけを受け取るだけです。記入されていない場合でも、ユーザーは日付の入力を指示されません。 |
例 | ||
JSON
{ "returnOnlyMonthYear": true } |
ユーザー発話「03-04-2021」抽出された値 「04-2021」ユーザー発話「Apr 2021」抽出された値「04-2021」 |
日付の期間型のエンティティ
ruleName | 値 | 説明 |
---|---|---|
range | { “from” : <from-date>, “to” : <to-date> } | 指定した範囲の日付のみを抽出。どちらのエンドポイントもオプションです。値には、YYYY-MM-DDの日付や、今日、明日、昨日といったキーワードを使用できます。日付は包括的なものです。 |
例 | ||
JSON
{ "range": { "from": "2020-01-01", "to": "today" } } |
エンティティパターン– デフォルトでは日付パターンユーザー発話「2019-02-03の予定を表示」抽出された値値のプロンプトユーザー発話「明日の予定を表示」抽出された値値のプロンプトユーザー発話「2020-02-03の予定を表示」抽出された値「2020-02-03」 | |
referenceDate | <date> | 条件日を<date>に設定すると、現在の日付のエンティティ値を設定するための日付計算は、その日付に基づいて行われます。値には、YYYY-MM-DDの日付や、今日、明日、昨日といったキーワードを使用できます。 |
例 | ||
JSON
{ "referenceDate": "2020-07-09" } |
エンティティパターン– デフォルトでは日付パターンユーザー発話「2日後の予定」抽出された値「2020-07-11」 | |
tense | past/future | ユーザー発話に年が存在しない場合に、時制に基づいて日付の期間を調整。このルールがない場合、月/日が現在の日付から90日以内に収まる場合、年は現在の年として設定され、そうでない場合は前年に設定されます。このルールでは、年を強制的に現在または過去にすることができます。 |
例 | ||
JSON
{ "tense": "past" } |
エンティティパターン– デフォルトでは日付パターンユーザー発話「1月の明細書を取得」抽出された値「2020-01-01」 現在の日付が 「2020-15-12」の場合、ルールがなければ 「2021-01-01」になっていたでしょう。 | |
preferredDateFormat | "yyyy-mm-dd" | 日付が曖昧な場合は、優先する日付形式を使用して曖昧さを解消します。値は以下が可能:
|
例 | ||
JSON
{ "preferredDateFormat": "mm-dd-yyyy" } |
ユーザー発話「03-04-2021」抽出された値 「2021-03-04」 メモ:このルールは、ユーザーの発話に曖昧さがある場合にのみ登場します。ユーザーの好みが以前の会話の一部として既に設定されている場合、ユーザーが選択した形式が定義されたルールよりも優先されます。例として、先のユースケースでは、ユーザーが以前の会話で好みの形式として「dd-mm-yyy」を選択していた場合、日付は「2021-04-03」として扱われます。 |
日付時間型のエンティティ
ruleName | 値 | 説明 |
---|---|---|
range | { “from” : <from-datetime>, “to” : <to-datetime> } | 指定した範囲の日付時間のみを抽出。どちらのエンドポイントもオプションです。値は、YYYY-MM-DDの日付、またはYYYY-MM-DDTHH:MM:SSの日付時間(指定がない場合はユーザーのタイムゾーンが想定されます)、またはキーワード(今日、明日、昨日、今)のいずれかです。日付は包括的なものです。 |
例 | ||
JSON
{ "range": { "from": "2020-01-01T00:00:00+05:30", "to": "2020-10-01T00:00:00+05:30" } } |
エンティティパターン – デフォルトでは日付時間パターンユーザー発話「2019-02-03T10:00:00にアラームをセット」抽出された値値のプロンプトユーザー発話「2021-12-20T10:00:00の予定を表示」抽出された値値のプロンプトユーザー発話「2020-02-03 T10:00:00の予定を表示」抽出された値 「2020-02-03T10:00:00」 | |
preferredTimes | { “from” : <from-time>, “to” : <to-time> } | 時間が曖昧な場合に、時間を解釈するのに使用する優先時間を設定。これらの時間は、すべての曜日に適用されます。例として、「3」は、優先時間が午前9時から午後6時の場合、「3pm」になります。時間が範囲内に収まらない場合は、最も近いものに基づいてam/pmを選択します。2つの可能性がある場合、または距離が等しい場合は、「日中/標準的に起きている状態」の時間を使用します。時刻は、ISO 8601形式のTHH:MMを使用してください。 |
{ “from” : [], “to” : [] } | このオプションは、曜日ごとに異なる優先時間を設定するためのものです。「from」と「to 」のキーは、日曜日から土曜日までの各曜日の時間を表す7メンバーの配列にすることができます。それぞれの値は、Thh:MM形式か、設定がないことを示す空の文字列でなければなりません。 | |
{ “favor” : <keyword> } | 「favor」キーワードを使用して、「未来」、「過去」、「午前」、「午後」のいずれかで優先順位を設定することができます。 | |
例 | ||
JSON
"preferredTimes": { "from": "T12:00:00", "to": "T18:00:00" } |
エンティティパターン– デフォルトでは日付パターンユーザー発話「3時にリマインドしてください」抽出された値「T15:00:00」 | |
JSON
"preferredTimes": { "from": [ "", "T09:00", "T09:00", "T21:00", "T21:00", "T07:00", "" ], "to": [ "", "T18:00", "T18:00", "T06:00", "T06:00", "T16:00", "" ] } |
エンティティパターン– デフォルトは日付パターンユーザー発話 「3時にリマインドしてください」抽出された値 現在の日が月/火/金の場合は「15:00:00」、 現在の日が水/木の場合は 「T03:00:00」 | |
JSON
"preferredTimes": { "favor": "pm" } |
エンティティパターン– デフォルトでは日付パターンユーザー発話「3時にリマインドしてください」抽出された値 「T15:00:00」 | |
timeRangePossible | true/false | trueの場合、ダイアログはユーザー入力において時間範囲を探します。「10から4」の解釈の方法に影響します。デフォルトでは「3:50」となりますが、範囲指定の可能性がある場合は、「10:00 」と「16:00」の2回に分けてデコードされます。 |
例 | ||
JSON
{ "timeRangePossible": "true" } |
||
preferredDateFormat | "yyyy-mm-dd" | 日付が曖昧な場合は、優先する日付形式を使用して曖昧さを解消します。値は以下が可能:
|
例 | ||
JSON
{ "preferredDateFormat": "mm-dd-yyyy" } |
ユーザー発話「03-04-2021」抽出された値 「2021-03-04」 メモ:このルールは、ユーザーの発話に曖昧さがある場合にのみ登場します。ユーザーの好みが以前の会話の一部として既に設定されている場合、ユーザーが選択した形式が定義されたルールよりも優先されます。例として、先のユースケースでは、ユーザーが以前の会話で好みの形式として「dd-mm-yyy」を選択していた場合、日付は「2021-04-03」として扱われます。 |
時間型のエンティティ
ruleName | 値 | 説明 |
---|---|---|
preferredTimes | { “from” : <from-time>, “to” : <to-time> } | 時間が曖昧な場合に、時間を解釈するのに使用する優先時間を設定。これらの時間は、すべての曜日に適用されます。例として、「3」は、優先時間が午前9時から午後6時の場合、「3pm」になります。時間が範囲内に収まらない場合は、最も近いものに基づいてam/pmを選択します。2つの可能性がある場合、または距離が等しい場合は、「日中/標準的に起きている状態」の時間を使用します。時刻は、ISO 8601形式のTHH:MMを使用してください。 |
{ “from” : [], “to” : [] } | このオプションは、曜日ごとに異なる優先時間を設定するためのものです。「from」と「to 」のキーは、日曜日から土曜日までの各曜日の時間を表す7メンバーの配列にすることができます。それぞれの値は、Thh:MM形式か、設定がないことを示す空の文字列でなければなりません。 | |
{ “favor” : <keyword> } | 「favor」キーワードを使用して、「未来」、「過去」、「午前」、「午後」のいずれかで優先順位を設定することができます。 | |
例 | ||
JSON
"preferredTimes": { "from": "T12:00:00", "to": "T18:00:00" } |
エンティティパターン– デフォルトでは日付パターンユーザー発話「3時にリマインドしてください」抽出された値「T15:00:00」 | |
JSON
"preferredTimes": { "from": [ "", "T09:00", "T09:00", "T21:00", "T21:00", "T07:00", "" ], "to": [ "", "T18:00", "T18:00", "T06:00", "T06:00", "T16:00", "" ] } |
エンティティパターン– デフォルトは日付パターンユーザー発話 「3時にリマインドしてください」抽出された値 現在の日が月/火/金の場合は「15:00:00」、 現在の日が水/木の場合は 「T03:00:00」 | |
JSON
"preferredTimes": { "favor": "pm" } |
エンティティパターン– デフォルトでは日付パターンユーザー発話「3時にリマインドしてください」抽出された値「T15:00:00」 | |
timeRangePossible | true/false | trueの場合、ダイアログはユーザー入力において時間範囲を探します。 |
例 | ||
JSON { "timeRangePossible": "true" } | 「10から4」のような発話の解釈の方法に影響します。デフォルトでは「3:50」となりますが、範囲指定の可能性がある場合は、「10:00 」と「16:00」の2回に分けてデコードされます。 | |
range | { “from” : now, } or { “to” : now } | 指定した範囲の日付時間のみを抽出。どちらのエンドポイントもオプションです。現在は「now」という値だけに対応しています。 |
例 | ||
JSON
{ "range": { "from": now } } |
アドレス型エンティティ
ruleName | 値 | 説明 |
---|---|---|
geocode | true/false | 完全にフォーマット化されたアドレスの場合。trueに設定すると、Googleなどのジオコードサービスを利用して、アドレスを個々のパーツに分割して表示します。 |
例 | ||
JSON
{ "geocode" : true } |
抽出された値のJSONオブジェクト
{ "text" : "", "geocode" : [] } 「text」プロパティには、geocodeではないフォームを使用した場合のアドレスが含まれます。「geocode」プロパティには、サービス(デフォルトではGoogle)からの修正されていない結果が含まれています。結果の中から自分に合った好きな要素を抽出することができます。 |
都市型エンティティ
ruleName | 値 | 説明 |
---|---|---|
ignoreWords | <concept name> | 概念の中の言葉が、都市とみなされないために。概念名には、スペースで区切られた概念のリスト、または概念の配列を指定できます。 |
例 | ||
JSON
{ "ignoreWords": "Send" } |
エンティティパターン– デフォルトでは大文字の単語 ユーザー発話「私のメールアドレスに目的地を送信してください」抽出された値エンティティ値のプロンプト、ルールがなければ都市名なので「送信」になっていたでしょう |
郵便番号型エンティティ
ruleName | 値 | 説明 |
---|---|---|
preferredCountries | [<“country1”>,<“country2”>,..] | ユーザーの所在地の国と、入力から集めた国に加えて、与えられた好ましい国のセットから郵便番号を制限。<"country1">, <"country2">,…の代わりに、2文字の国別アルファ2コードを追加する必要があります。 |
例 | ||
JSON
{ "preferredCountries": [ "GB" ] } |
エンティティパターン– デフォルトでは郵便番号パターン ユーザー発話「PO16 7GZへの納品をチェック」抽出された値 「PO16 7GZ」、ルールがなければ、ユーザーが英国の地域にいない場合、これは除外されたかもしれません。 |
所在地型エンティティ
ruleName | 値 | 説明 |
---|---|---|
preferredCountries | [<“country1”>,<“country2”>,..] | ユーザーの所在地の国と、入力から集めた国に加えて、与えられた好ましい国のセットから所在地を制限。<"country1">, <"country2">,…の代わりに、2文字の国別アルファ2コードを追加する必要があります。 |
例 | ||
JSON
{ "preferredCountries": [ "GB" ] } |
アイテムのリスト(enum)型エンティティ
ruleName | 値 | 説明 |
---|---|---|
所有権 | 含める/除外する | 潜在的な選択肢をエンティティの値に含めるべきか、除外すべきかを判断するために、「is mine」などの潜在的な「所有権」の表現を探索。所有権を表すフレーズの例としては、「is mine」「belongs to me」などがあります。 |
例 | ||
JSON
{ "ownership": "include" } |
入力オプション – アイテムを選択します。"pen", "watch", "bottle", "book", "cap」 ユーザー発話 "first two are mine」 抽出された値 ["pen", "watch"]. | |
JSON
{ "ownership": "exclude" } |
入力オプション – アイテムを選択します。"pen", "watch", "bottle", "book", "cap」 ユーザー発話 "first two are mine」 抽出された値 ["bottle", "book", "cap"], なぜなら、ルールが所有権の値を除外しているからです。 | |
includeWords | <概念名>または単語の配列 | 所有権のフレーズを補足する言葉のリスト。値は、文字列の配列または概念です。 所有権:除外ルールとともに使用 |
例 | ||
JSON
{ "ownership": "include", "includeWords": "great" } |
入力オプション – アイテムを選択します。「pen」、「watch」、「bottle」、「book」、「cap」ユーザー発話「first two are mine」 抽出された値 [「pen」、「watch」] ユーザー発話 「first two are great」 抽出された値 [「pen」、「watch」] | |
excludeWords | <概念名>または単語の配列 | 非所有者用のフレーズとして使用できる単語のリストです。値は、文字列の配列または概念です。所有権:除外ルールとともに使用 |
例 | ||
JSON
{ "ownership": "exclude", "excludeWords": "~lovConcept" } |
入力オプション – アイテムを選択します。「pen」、「watch」、「bottle」、「book」、「cap」lovConcept –dubiousUser発話 「First two are dubious」抽出された値 [「bottle」、「book」、「cap」] | |
noIndexMatch | true | アルファベットと数字のインデックス一致を無効にすると、ユーザーがインデックスを使用して項目を選択できなくなります。 |
例 | ||
JSON
{ "noIndexMatch": "true" } |
入力オプション – アイテムを選択します。「Pen」、「watch」、「bottle」、「book」、「cap」ユーザー発話ユーザー発話 抽出された値 入力のためのプロンプト、ルールがなければ[「pen」]になっていたでしょう。 |