アクセスいただきありがとうございます。こちらのページは現在英語のみのご用意となっております。順次日本語化を進めてまいりますので、ご理解のほどよろしくお願いいたします。

Understand Name-free Interactions

Name-free interaction enables customers to interact with Alexa without invoking a specific skill by name, which helps facilitate greater interaction with Alexa because customers do not always know which skill is appropriate.

When Alexa receives a request from a customer without a skill name, such as "Alexa, play relaxing sounds with crickets," Alexa looks for skills that might fulfill the request. Alexa determines the best choice among eligible skills and hands the request to the skill.

To make your skill more discoverable for name-free interaction, you can implement the the CanFulfillIntentRequest interface in your skill. See Implement CanFulfillIntentRequest for Name-free Interaction.

High-Level overview of how name-free interaction works

  1. The customer speaks to Alexa with a requested action, a question, or a statement that does not include a skill name. In some cases, Alexa processes the utterance, recognizes that no skill name has been specified, selects top candidate skills to fulfill the request, and then queries these skills with CanFulfillIntentRequest to determine if skill can fulfill the intent that the customer wanted.
  2. If a skill has implemented canFulfillIntent according to the interface specification, the skill should be aware that the skill is not yet being asked to take action on behalf of the customer, and should not modify any state outside its scope, or have any observable interaction with its own calling functions or the outside world besides returning a value. Thus, the skill should not, at this point, perform any actions such as playing sound, turning lights on or off, providing feedback to the customer, committing a transaction, or making a state change.
  3. Alexa collects the responses from the original list of candidate skills and considers them along with other factors to select the best way to fulfill the customer's request. Alexa will then call this skill back with IntentRequest.
  4. When Alexa calls back the selected skill with an IntentRequest, the skill must fulfill this IntentRequest and answer the customer, just as for a skill request where the customer has invoked the skill by name.

CanFulfillIntentRequest for a skill which is not enabled by the user

If your skill supports the CanFulfillIntentRequest interface, then your skill may be chosen and auto-enabled to fulfill a query for users who have not enabled your skill yet. If your skill is selected when such a user sends an utterance to Alexa, your skill will be issued CanFulfillIntentRequest, and your skill can then determine whether it can fulfill this request. In this scenario, CanFulfillIntentRequest will not have a userId associated with the request. A skill developer must ensure that their skill can handle this scenario. You can use ASK CLI to test your skill, or use the manual JSON option in the Test area of the developer console to validate this scenario. Note that your skill may fail certification if it cannot gracefully handle this scenario.

Implement canFulfillIntent

The CanFulfillIntentRequest interface is backward-compatible with existing Alexa skills, so you can add an implementation to fulfill CanFulfillIntentRequest without affecting how your skill works.

A CanFulfillIntentRequest request is made to a skill to query whether the skill can understand and fulfill the intent request with detected slots, before actually asking the skill to take action. The canFulfillIntent response that the skill provides should indicate whether or not the skill can fulfill the request, but the skill must not cause any observable interactions or make any changes in state outside of its scope except to return a value indicating whether the skill can fulfill the request. For example, the skill should not play sound, turn lights on or off, give the customer any feedback, or commit a transaction or a charge.

Suppose the request that the customer makes is "Alexa, play relaxing sounds with crickets." A CanFulfillIntentRequest would then take the following form. The request parameters in this response are the same as for other request types. In this example, Alexa recognizes the PlaySound intent, and the "crickets" value for the Sound slot.

{
  "request": {
    "type": "CanFulfillIntentRequest",
    "requestId": "…",
    "intent": {
      "name": "PlaySound",
      "slots": {
        "Sound": {
          "name": "Sound",
          "value": "crickets"
        }
      },
    },
    "locale": "en-US",
    "timestamp": "…"
  },
  "context": {
    "System": {
      "application": {
        "applicationId": "amzn1.ask.skill.<skill-id-value>"
      },
      "user": {
        "userId": "<user-id-value>"
      },
      "device": {
        "supportedInterfaces": {}
      }
    }
  },
  "version": "1.0"
}

Response to CanFulfillIntentRequest

When your skill receives a CanFulfillIntentRequest, it is expected to respond with a canFulfillIntent object that contains the mandatory field canFulfill for the intent, and two optional fields per slot–canUnderstand and canFulfill.

Guidelines for canFulfillIntent

Here are guidelines for which option to choose in response to various scenarios. These are suggestions, rather than strict rules, and are meant to ensure your skill gets those requests that it can handle.

  • Set canFulfill = "YES" if your skill understands all slots, can fulfill all slots, and can fulfill the request in its entirety.
  • Set canFulfill = NO if your skill cannot understand the intent, and/or cannot understand any of the slots, and/or cannot fulfill any of the slots.
  • Set canFulfill = MAYBE if your skill can understand the intent, can partially or fully understand the slots, and can partially or fully fulfill the slots. The only cases where your skill should respond with MAYBE is when your skill can potentially complete the request if your skill get more data through a multi-turn conversation with the user. For example, if the skill understands the intent, such as orderCabIntent, but needs the customer to link their account before being able to fulfill the request. Another example is travelBookingIntent, where the skill understands a subset of all identified slots and needs more information before it can determine whether it can fulfill the intent for each slot value.

Guidelines for slot response values

For each slot, a skill is optionally expected to return values for the canUnderstand and canFulfill fields. While skills are expected to have proprietary logic to determine response for each field, general guidelines are provided below.

canUnderstand management

canUnderstand – Indicates whether your skill understands the slot value. Your skill logic needs to determine whether there is a match and the quality of the match. For example, the skill might look up values from a list that you maintain.

  • Set canUnderstand = "YES" if your skill has a perfect match or a high-confidence match, for example a synonym.

  • Set canUnderstand = "MAYBE" if your skill has a partial match, for example if the exact slot value does not exist but a variation or a fuzzy match exists.

  • Set canUnderstand = "NO" if your skill cannot resolve the slot value.

Default values using the entity resolution implementation from the Alexa Skills Kit

The Alexa Skills Kit provides entity resolution. If your skill uses the entity resolution data to understand slot values, the default value for canUnderstand is as follows.

  • Set canUnderstand = "YES" if entity resolution successfully resolves slot value.

  • Set canUnderstand = "NO" if entity resolution does not resolve slot value.

If you want, you can overwrite the default.

Values for canUnderstand if your skill does not use lists and do not use the entity resolution implementation

If your skill does not maintain a list of slot values and does not use the entity resolution data, your skill needs some other way of determining how to respond to canUnderstand. Choose the logic while considering your skill and the scenarios that it handles.

The following examples show how a skill might respond to canUnderstand.

Example: [Slot value: canUnderstand]

For catalogued slot values = {New York, Paris, London, Munich}

[New York : YES | Newark : NO | Paris : YES | München : YES | Munich : YES | Landon : MAYBE]

In this example, the skill sets canUnderstand = "YES" for the slot values "New York", "Paris", and "Munich" because they are exact matches with the catalog, "YES" to "München" because it recognizes the local term for "Munich", and "MAYBE" to "Landon" because it determines the skill user might have meant "London", but would want to confirm with the user before proceeding.

Example: For catalogued slot value = {hyenas}

[hyenas : YES] | pack of hyenas : YES | aardwolf : MAYBE | aardvarks : NO]

Example: For catalogued slot values = {IBM, HP}

[International Business Machines : YES] | IBM : YES | Business Machines : MAYBE | ITBM : NO | Hewlett Packard : YES | HP : YES | Hewitt Packages : NO]

Example: For catalogued slot values = {US ARMY, US NAVY, US AIR FORCE}

[The US Army : YES] | US Army : YES | Army : MAYBE | The US Navy : YES | Marines : NO]

Example: For the catalogued slot value = {3457 Hillsborough Road Durham NC Ph: (919 333-4444)}

[Hillsborough Road Starbucks Durham : YES] | [3457 Hillsborough Road Durham NC : YES| Bucks Hillsborough Road Durham : MAYBE]

Example: For catalogued slot value = {iPad 2 16GB White}

[iPad two 16GB White : YES] | iPad 2nd generation 16GB White : YES | I Pad 2 16GB White : MAYBE | iPhone 16GB White : NO]

canFulfill management

canFulfill – This field indicates whether your skill can fulfill the relevant action for the slot that has been partially or fully identified. The definition of fulfilling the slot is dependent on your skill, and your skill service is required to have logic in place to determine whether a slot value can be fulfilled in the context of your skill or not.

  • Set canFulfill = "YES" if your skill can certainly fulfill the relevant action for this slot value.

  • Set canFulfill = "NO" if your skill cannot fulfill the relevant action for this slot value.

These examples listed below should clarify how to respond to canFulfill.

Example: A skill that provides animal sounds in response to the name of animal as stated by an Alexa customer

If the skill recognizes the name of animal provided in utterance (that is, canUnderstand = YES), but is unable to play back the sound of the recognized animal because the audio file is not available at the moment, it should return canFulfill = "NO".

Example: A skill that delivers food

If the skill recognizes both the type of food ordered and delivery address, but if the food delivery service backing the skill is unable to deliver food in expected time window, it should return canFulfill = "NO".

Example: A travel booking skill responding to a multi-stop trip query

If the skill recognizes both slot values provided (destinations), but can only provide booking options for the first destination, and not for the second, the skill should return canFulfill = "YES" for the first slot and canFulfill = "NO" for the second slot.

Sample intent response

{
    "version":"1.0",
    "response":{
        "canFulfillIntent": {
            "canFulfill": "YES",
            "slots":{
                "slotName1": {
                    "canUnderstand": "YES",
                    "canFulfill": "YES"
                },
               "slotName2": {
                    "canUnderstand": "YES",
                    "canFulfill": "YES"
                }
            }
        }
    }
}