WO2022259497A1

WO2022259497A1 - Scenario setting device, scenario setting method, and scenario setting program

Info

Publication number: WO2022259497A1
Application number: PCT/JP2021/022222
Authority: WO
Inventors: 真実小宮山; 明片岡; 英毅小矢
Original assignee: 日本電信電話株式会社
Priority date: 2021-06-10
Filing date: 2021-06-10
Publication date: 2022-12-15

Abstract

A setting unit (131) receives scenario settings for the behavior of a chatbot, for hierarchical states. A scenario generation unit (133) generates a scenario for each state, on the basis of information received by the setting unit (131).

Description

Scenario setting device, scenario setting method and scenario setting program

The present invention relates to a scenario setting device, a scenario setting method, and a scenario setting program.

Recently, business use of chatbots is increasing. There is a demand for a chatbot that not only responds to inquiries such as FAQs, but also supports user operations such as proxy operations for business systems.

For example, there is a known technology that uses peripheral information acquired by a chatbot to operate business systems on behalf of others (see Patent Document 1, for example).

In the execution of support for user operations by chatbots, it is necessary to specify (narrow down) the status of the user to be supported, and rule-based chatbots are sometimes used.

A rule-based chatbot operates based on a predefined response flow (scenario) for user input. In addition, at that time, the contents of the dialogue including the bot utterance and the user utterance can be set in the flow (Reference: Repl-AI (https://repl-ai.jp/)).

There is also a known technique for generating a dialogue scenario by creating a state transition diagram on a GUI when setting the dialogue scenario (see Non-Patent Documents 1 and 2, for example).

WO2021/070292

However, conventional technologies have the problem of complicating chatbot operation scenarios.

For example, in the chatbot described in Patent Document 1, in addition to conversation information (text) with the user, the state of the user (whether the target application is running or whether necessary data has been input) can be determined from the acquired peripheral information. The operation scenario is transitioned under conditions such as whether or not there is

At that time, when chatbots provide support according to various tasks and states, transitions such as interruptions occur frequently, complicating scenarios (state transitions). In particular, when interrupt processing is represented by a state transition diagram, the number of transitions (edges) increases and becomes complicated.

For example, if you want to define a scenario (state transition) in which "Work A has started, is interrupted, and then starts Work B," it is necessary to set transitions corresponding to interrupts.

As a result, the operating scenarios become more complicated, making it difficult to efficiently configure chatbot scenarios.

In Non-Patent Documents 1 and 2, nodes are grouped as composite states to reduce the number of apparent edges, but it is not possible to omit the actual edge settings.

In order to solve the above-described problems and achieve the object, a scenario setting device includes a setting unit that receives scenario settings regarding chatbot operations for a hierarchical state, and based on information received by the setting unit. and a scenario generator that generates a scenario for each state.

According to the present invention, it is possible to prevent chatbot operation scenarios from becoming more complicated.

FIG. 1 is a diagram showing a configuration example of a scenario setting device according to the first embodiment. FIG. 2 is a diagram showing an image of hierarchization of transition states. FIG. 3 is a diagram showing an example of a state transition diagram screen. FIG. 4 is a diagram showing an example of a state transition diagram screen. FIG. 5 is a diagram showing an example of a property screen. FIG. 6 is a diagram showing an example of a transition condition setting screen. FIG. 7 is a diagram showing an example of a state transition diagram screen. FIG. 8 is a diagram for explaining the orientation of edges. FIG. 9 is a diagram for explaining the orientation of edges. FIG. 10 is a diagram showing an example of the property screen. FIG. 11 is a diagram showing an example of an operation setting screen. FIG. 12 is a diagram for explaining how to open the operation setting screen. FIG. 13 is a diagram showing an image of scenario setting. FIG. 14 is a flow chart showing the processing flow of the scenario setting device according to the first embodiment. FIG. 15 is a diagram illustrating an example of a computer that executes a scenario setting program;

Embodiments of the scenario setting device, scenario setting method, and scenario setting program according to the present application will be described below in detail based on the drawings. In addition, this invention is not limited by embodiment described below.

[Configuration of the first embodiment]
First, the configuration of the scenario setting device according to the first embodiment will be described using FIG. FIG. 1 is a diagram showing an example of the configuration of a scenario setting device according to the first embodiment.

The scenario setting device 10 provides a GUI (Graphical User Interface) to the user, and sets a chatbot scenario through the user's operation via the GUI. For example, chatbots can assist users in their work.

As shown in FIG. 1, the scenario setting device 10 has an input unit 11, an output unit 12, a control unit 13 and a storage unit 14.

The input unit 11 is an interface for inputting data. The input unit 11 may be an input device such as a mouse or a keyboard.

The output unit 12 is an interface for outputting data. The output unit 12 is, for example, a display. Moreover, the input unit 11 and the output unit 12 may constitute a touch panel display.

The storage unit 14 is a storage device such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), an optical disc, or the like. The storage unit 14 may be a rewritable semiconductor memory such as RAM (Random Access Memory), flash memory, NVSRAM (Non Volatile Static Random Access Memory).

The storage unit 14 stores an OS (Operating System) and various programs executed by the scenario setting device 10 . The storage unit 14 stores GUI configuration information 141 and scenario information 142, for example.

The GUI configuration information 141 is information for the scenario setting device 10 to provide the user with a GUI. For example, the GUI configuration information 141 is program data defining GUI parts and processing for each part.

The scenario information 142 is a scenario generated by the scenario setting device 10 saved in a predetermined format (for example, Json format).

The control unit 13 controls the scenario setting device 10 as a whole. The control unit 13 includes, for example, electronic circuits such as CPU (Central Processing Unit), MPU (Micro Processing Unit), GPU (Graphics Processing Unit), ASIC (Application Specific Integrated Circuit), FPGA (Field Programmable Gate Array), etc. It is an integrated circuit. The control unit 13 also has an internal memory for storing programs defining various processing procedures and control data, and executes each processing using the internal memory.

The control unit 13 functions as various processing units by running various programs. For example, the control unit 13 has a setting unit 131 , a GUI display control unit 132 and a scenario generation unit 133 .

The setting unit 131, the GUI display control unit 132, and the scenario generation unit 133 perform processing related to scenario setting.

Here, in this embodiment, states are defined for each layer, taking each state related to work as an example. Hierarchization of states will be described with reference to FIG. FIG. 2 is a diagram showing an image of hierarchization of transition states.

As shown in Figure 2, the hierarchy can be divided according to the granularity of tasks and user statuses, for example. In the example of FIG. 2, there are three hierarchies.

In the example of FIG. 2, the first layer, which has the coarsest granularity, includes the physical state of the user who performs the task. The physical state is, for example, "Working on PC", "Away from desk", or the like. In addition, the second level of granularity includes the status of the work in progress. In addition, the third layer, which has the finest granularity, includes the state of work being performed. It should be noted that work is an element that constitutes work.

In this embodiment, the transition state is managed for each layer. For example, when a transition occurs in the parent layer, the transition state in the child layer is reset.

In addition, in the example of FIG. 2, the parent hierarchy corresponds to a hierarchy that is coarser in granularity than the child hierarchy. For example, the first hierarchy is the parent hierarchy of the second and third hierarchies. Also, the third hierarchy is a child hierarchy of the first hierarchy and the second hierarchy.

Also, in this embodiment, transition conditions can be set between states in one hierarchy, making it easier to understand the flow of state transitions.

In addition, in this embodiment, since the state granularity is the same in the same layer, it becomes easier to express interrupt processing and the like. That is, in this embodiment, there is no need to set transitions (transition destinations+transition conditions) for states with different granularities.

In other words, in this embodiment, it is sufficient to set transitions between nodes in the same hierarchy, and there is no need to set transitions between nodes in different hierarchies.

In addition, in this embodiment, it is possible to set the utterance content of the chatbot and the support content to be executed for each state.

Furthermore, in this embodiment, it is possible to select a GUI (setting mode, which will be described later) that is easy to set for each layer, depending on "what kind of granular state you want to determine" and "the purpose of setting that layer".

Even if the contents that can be set as state transition conditions and the data values that can be handled are common to all hierarchies and states, the rules that are actually set (transition conditions between states) depend on the granularity of state management. ) and easy setting methods are considered to be different.

Here, the processing of each part of the scenario setting device 10 will be described while showing examples of displayed screens (GUI).

The setting unit 131 accepts scenario settings related to the behavior of the chatbot for the hierarchized state.

The GUI display control unit 132 displays a GUI regarding each state for each layer. Also, the setting unit 131 can receive settings via the GUI.

The scenario generation unit 133 generates a scenario for each state based on the information received by the setting unit 131.

The scenario setting device 10 displays a screen according to the specified setting mode. The setting mode includes flow definition, state setting, and operation setting.

(Setting mode: flow definition)
Each screen when the setting mode is flow definition will be explained. FIG. 3 is a diagram showing an example of a state transition diagram screen. The example of FIG. 3 indicates that the setting mode is "flow definition".

In the example of FIG. 3, the GUI display control unit 132 displays the state transition diagram list 211 and the node type list 212 on the state transition diagram screen 21. FIG. Also, the GUI display control unit 132 displays the state transition diagram of the selected layer.

Here, the setting unit 131 receives scenario settings for each layer. For example, the setting unit 131 receives the setting of the scenario of the layer on which the state transition diagram is displayed.

In the example of FIG. 3 where selectable hierarchies are displayed in the state transition diagram list 211, "Work A" is selected and the state transition diagram of "Work A" is displayed.

In the state transition diagram, nodes corresponding to states are represented by circles, and edges between nodes are represented by lines. Edge arrows indicate the direction of state transitions.

"ROOT -> Work A" is displayed on the selected canvas. This means that the state transition diagram of the hierarchy under the node "task A" defined on the state transition diagram of "ROOT" is displayed on the main screen.

The user can add a node to the state transition diagram by dragging and dropping any node displayed in the node type list 212 on the state transition diagram screen 21 . In addition, users can connect edges between nodes by drag and drop.

When the node is double-clicked, the GUI display control unit 132 opens a transition condition setting screen. Also, when a node is right-clicked, the GUI display control unit 132 displays a right-click menu 213. FIG.

When "property setting" in the right-click menu 213 is selected, the GUI display control unit 132 opens the property screen of the target node.

Also, when "upper node setting" and "lower node setting" of the right-click menu 213 are selected, the GUI display control unit 132 opens the state transition diagram screen 21 of the upper node and lower node of the target node, respectively. That is, the GUI display control unit 132 switches the canvas during selection.

It should be noted that the upper and lower relationships are the same as the parent and child relationships described above. For example, a higher node means a node existing in a parent hierarchy (higher hierarchy), and a lower node means a node existing in a child hierarchy (lower hierarchy).

When "operation setting" of the right-click menu 213 is selected, the GUI display control unit 132 opens the operation setting screen of the target node.

FIG. 4 is a diagram showing an example of the state transition diagram screen. FIG. 4 shows the state transition diagram screen 21 when "ROOT" is selected.

Task A, task B, task C, and task D are nodes immediately below the node "ROOT" in the highest hierarchy.

For example, when "work A" is double-clicked or "lower node setting" is selected from the right-click menu of "work A", the GUI display control unit 132 switches the canvas and displays the screen of FIG. .

It should be noted that the GUI display control unit 132 may change the color and shape of nodes that have child hierarchies, or display the names of lower nodes corresponding to the state transition diagram list 211 .

Fig. 5 shows an example of the property screen in flow definition mode. FIG. 5 is a diagram showing an example of a property screen.

As shown in FIG. 5, in the case of the flow definition mode, the setting unit 131 accepts the setting of the node name for each node, chatbot utterance content, and transition conditions on the property screen 22 .

The setting item "utterance content" is the content to be spoken by the chatbot, and may be null. With this setting item, the setting unit 131 receives setting of the utterance content of the chatbot corresponding to the node included in the state transition diagram.

Any of the nodes displayed in the state transition diagram can be selected as the transition destination of the transition condition. Further, when the setting button is pressed, the GUI display control unit 132 opens a transition condition setting screen corresponding to the transition destination node.

Based on the settings accepted by the setting unit 131 on the property screen 22, the scenario generation unit 133 generates a scenario in which the utterance content is linked to the nodes included in the state transition diagram.

In the example of FIG. 5, the scenario generation unit 133 generates, for example, the following basic node information as a scenario, based on the setting of the utterance content "Work A has started."

{
“id”:”node0000”,
“name”:”node 1”,
“botTalk”:”You have started task A.”,
“conditionList”:[
{“(node 2 id)”, “(transition condition id)”},
{“(node 3 id)”, “(transition condition id)”},
…
]
“parent”:”(parent node id)”,
“child”:”(child node id)”,
…
“action”:”(action setting id)”,
…
}

In the above basic information, "botTalk" corresponds to the utterance content. Also, "parent" and "child" are set when there are nodes in the parent hierarchy and child hierarchy, respectively. Transition conditions and operation contents will be described later.

The transition condition setting screen will be explained using the case where the setting button corresponding to the transition destination "node 2" is pressed on the property screen in FIG. 5 as an example. FIG. 6 is a diagram showing an example of a transition condition setting screen.

Note that the transition condition setting screen is opened not only when the setting button on the property screen is pressed, but also when an edge of the state transition diagram is double-clicked.

As shown in FIG. 6, on the transition condition setting screen 23, the setting unit 131 receives setting of conditions for each context. For example, context includes user utterances, URLs, and the like.

For example, the scenario generation unit 133 generates the following transition conditions from the setting contents of the transition condition setting screen 23 .

{
“transition condition id”:”condition1-1”,
“Transition condition name”: “Open ○○ system and start task A”
“Transition condition”: User utterance = “Start work A” OR URL = Open page “xxx”
}

This transition condition corresponds to the transition destination "node 2" on the property screen 22 in FIG. Therefore, the transition condition means "transition from node 1 to node 2 when the user utters 'Start task A' or when a page with URL 'xxx' is opened". do.

(Setting mode: state definition)
Each screen when the setting mode is state definition will be described. FIG. 7 is a diagram showing an example of a state transition diagram screen. The example of FIG. 7 indicates that the setting mode is "state definition".

Even if the setting mode is state definition, the functions that can be called by double-clicking, right-clicking, etc. from the state transition diagram screen 21 are the same.

However, in the flow definition mode, the direction of the edge was considered to be outward with respect to the target node, whereas in the state definition mode, the direction of the edge was considered to be inward. Also, in the state definition mode, edges do not have to be displayed on the GUI on the premise that edges are connected between all nodes (full mesh).

In other words, while the flow definition mode is a mode for setting transition conditions from the target node to the transition destination, the state definition mode is a mode for setting transition conditions from the transition source to the target node. .

In the example of FIG. 7, when "business A" is the target node, settings are made for edges from "business B", "business C", and "business D" to "business A".

　FIGS. 8 and 9 are diagrams for explaining the orientation of the edge. For example, the higher the hierarchy, the setting is made such that the edge direction is inward as shown in FIG. 8, and the lower hierarchy is the setting such that the edge direction is outward as shown in FIG.

For example, if a state transition occurs in a higher layer while a state transition is being performed in a lower layer, the state transition in the lower layer is reset. Then, the state transition is re-evaluated at the node below the transition destination node in the higher hierarchy.

Also, when the state transitions to the completion node in the lower hierarchy, the transition conditions in the state transition diagram are re-evaluated in the upper hierarchy, or the state transition diagram in the upper hierarchy returns to the start.

The property screen in the state definition mode will be explained using FIG. FIG. 10 is a diagram showing an example of the property screen.

As shown in FIG. 10, the state definition mode property screen 22 differs from the flow definition mode in that transition conditions are set for transition source nodes.

Also, on the property screen 22 in the state definition mode, it is possible to collectively set "other than the above" as the transition source node. In the example of FIG. 10, "other than the above" means "nodes in the same hierarchy other than node 2".

(Setting mode: Operation setting)
Each screen when the setting mode is the operation setting will be described. In both the flow definition mode and the state definition mode, when "operation setting" is selected in the right-click menu of a node, the setting mode becomes operation setting.

In the operation setting mode, it is possible to set the content of support implementation and scenarios related to support implementation (such as asking the user if it is okay to perform support).

For example, as shown in FIG. 11, on the operation setting screen 24 in the operation setting mode, processing logic can be set by combining blocks using visual programming. FIG. 11 is a diagram showing an example of an operation setting screen.

On the operation setting screen 24, the setting unit 131 accepts settings for support content to be executed by the chatbot corresponding to the node included in the state transition diagram. Then, the scenario generation unit 133 generates a scenario in which the support contents are linked to the nodes included in the state transition diagram.

For example, the scenario generation unit 133 generates the following operation settings from the setting contents of the operation setting screen 24 .

{
“actions”:[
{
“id”:“(action setting id)”,
“action”: ”(Action settings)“
},
…
}

For example, the operation settings include the script language itself such as JavaScript (registered trademark), the execution file (example: exe) for executing the RPA (Robotic Process Automation) application, the path of the scenario to be read, and the agent included in the chatbot. It is a dedicated instruction set or the like for operating the operation execution system.

The setting modes described so far (flow definition mode, state definition mode, operation setting mode) may be switched according to the user's GUI operation (for example, setting mode pull-down list).

Also, the setting mode may be selected by the user at the time of initial setting for each hierarchy (upper or lower). Furthermore, the initial setting mode may be determined according to the past usage frequency, the nature of the canvas to be set, and the like (for example, state definition mode for upper nodes and flow definition mode for lower nodes).

In this way, the GUI display control unit 132 switches the GUI to be displayed according to the hierarchy for which the setting unit 131 has accepted the setting of the scenario. Regardless of the switching method, the scenario setting device 10 of this embodiment can provide a GUI for scenario setting in a setting mode corresponding to the hierarchy.

The GUI display control unit 132 provides a GUI according to the setting mode based on the GUI configuration information 141. Therefore, by changing the GUI configuration information 141, the GUI in each setting mode can be changed. Furthermore, information may be added to the GUI configuration information 141 to provide a new setting mode.

As shown in FIG. 12, when a node without a child hierarchy is selected in the state transition diagram by double-clicking or the like, the setting mode may be switched to the operation setting mode and the operation setting screen 24 may be opened. FIG. 12 is a diagram for explaining how to open the operation setting screen.

FIG. 13 is a diagram showing an image of scenario setting. As shown in FIG. 13, it is assumed that layers L11 and L12 exist below layer L1, and layer 121 exists below them.

At level L1, the status is determined with coarse granularity, and for example, the work in progress is defined. The scenario setting device 10 provides a state transition diagram screen for layer L1.

At levels L11 and L12, the status is determined with medium granularity, and for example, the work included in the business is defined. The scenario setting device 10 provides state transition diagram screens for the layers L11 and L12.

However, since task D of layer L1 does not have a lower layer, the scenario setting device 10 provides an operation setting screen for task D.

Similarly, the scenario setting device 10 provides a state transition diagram screen for the layer L121 that is lower than the layer L12, and provides an operation setting screen 24 for nodes that do not have a layer lower than the layer L121.

The scenario setting device 10 of this embodiment finally generates the following data as the scenario information 142 . For example, the scenario information 142 is in Json format.

{
“node”:[
{
“id”:”(node id)”,
“name”:”(node name)”,
“botTalk”:”(utterance content)”,
“conditionList”:[
{“(id of transition destination node)”, “(id of transition condition)”},
…
],
“parent”:”(parent node id)”,
“child”:”(child node id)”,
…
“action”:”(action setting id)”,
],
“conditions”:[
{
“id”:”(id of transition condition)”,
“name”:“(condition name)”
“condition”:“(transition condition)”
},
…
],
“actions”:[
{
“id”:“(action setting id)”,
“action”: ”(Action settings)“
},
…
}

　The data in the above "node" corresponds to one scenario in which it is stored in one file.

"id", "name", "botTalk", and "conditionList" are the basic information of the node.

"parent" and "child" are information representing hierarchical relationships. “action” is information that associates action settings.

"conditions" is information about transition conditions, and the details of the conditions corresponding to the id of the transition conditions in the "conditionList" of the basic information are described.

"actions" is information about action settings, and details of the action corresponding to the action setting id in "action" of the basic information are described.

[Processing of the first embodiment]
FIG. 14 is a flow chart showing the processing flow of the scenario setting device according to the first embodiment.

First, the scenario setting device 10 displays a list of nodes for each layer (step S101). The scenario setting device 10 also displays the state transition diagram of the selected node (step S102).

At this time, the scenario setting device 10 displays the state transition diagram in either the flow definition mode or the state definition mode according to the hierarchy of the selected node.

The scenario setting device 10 adds nodes and edges to the state transition diagram (step S103). Then, the scenario setting device 10 sets properties and operations for each node (step S104).

For example, the function of the property screen for setting properties differs depending on whether you are in flow definition mode or state definition mode.

[Effects of the first embodiment]
As described so far, the setting unit 131 receives setting of a scenario relating to the operation of the chatbot for the hierarchized state. Scenario generation unit 133 generates a scenario for each state based on the information received by setting unit 131 .

By hierarchizing the states in this way, it is possible to prevent the operational scenario of the chatbot from becoming complicated. For example, by limiting transitions within the same hierarchy, it is not necessary to consider transitions between hierarchies.

The GUI display control unit 132 displays a GUI regarding each state for each layer. The setting unit 131 receives settings via the GUI.

The setting unit 131 receives scenario settings for each layer. The GUI display control unit 132 switches the GUI to be displayed according to the hierarchy for which the setting unit 131 has accepted the setting of the scenario.

For example, depending on the hierarchy, it changes whether it is better to set transition conditions to the transition destination or to set transition conditions from the transition source. Therefore, by providing a GUI according to the hierarchy, the scenario setting can be made more efficient.

The GUI display control unit 132 displays a state transition diagram with each state of a specific hierarchy as a node. The setting unit 131 receives setting of the utterance content of the chatbot corresponding to the node included in the state transition diagram. The scenario generation unit 133 generates a scenario in which utterance contents are linked to nodes included in the state transition diagram.

As a result, it is possible to set the content of the chatbot's utterances according to the user's situation (state).

The GUI display control unit 132 displays a state transition diagram with each state of a specific hierarchy as a node. The setting unit 131 receives settings for the support content to be executed by the chatbot corresponding to the node included in the state transition diagram. The scenario generation unit 133 generates a scenario in which support contents are linked to nodes included in the state transition diagram.

As a result, it is possible to set the content of support to be provided by the chatbot according to the user's situation (state).

[System configuration, etc.]
Also, each component of each device illustrated is functionally conceptual, and does not necessarily need to be physically configured as illustrated. In other words, the specific form of distribution and integration of each device is not limited to the illustrated one, and all or part of them can be functionally or physically distributed or Can be integrated and configured. Furthermore, all or any part of each processing function performed by each device is realized by a CPU (Central Processing Unit) and a program analyzed and executed by the CPU, or hardware by wired logic can be realized as Note that the program may be executed not only by the CPU but also by other processors such as a GPU.

Further, among the processes described in the present embodiment, all or part of the processes described as being automatically performed can be performed manually, or the processes described as being performed manually can be performed manually. All or part of this can also be done automatically by known methods. In addition, information including processing procedures, control procedures, specific names, various data and parameters shown in the above documents and drawings can be arbitrarily changed unless otherwise specified.

[program]
As one embodiment, the scenario setting device 10 can be implemented by installing a scenario setting program for executing the above scenario setting process as package software or online software on a desired computer. For example, the information processing device can function as the scenario setting device 10 by causing the information processing device to execute the above scenario setting program. The information processing apparatus referred to here includes a desktop or notebook personal computer. In addition, information processing devices include mobile communication terminals such as smartphones, mobile phones and PHS (Personal Handyphone Systems), and slate terminals such as PDAs (Personal Digital Assistants).

The scenario setting device 10 can also be implemented as a scenario setting server device that uses a terminal device used by a user as a client and provides the client with a service related to the above scenario setting process. For example, the scenario setting server device is implemented as a server device that provides a scenario setting service in which a hierarchical state of work is input and scenario information is output. In this case, the scenario setting server device may be implemented as a web server, or may be implemented as a cloud that provides services related to the scenario setting process by outsourcing.

FIG. 15 is a diagram showing an example of a computer that executes a scenario setting program. The computer 1000 has a memory 1010 and a CPU 1020, for example. Computer 1000 also has hard disk drive interface 1030 , disk drive interface 1040 , serial port interface 1050 , video adapter 1060 and network interface 1070 . These units are connected by a bus 1080 .

The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM (Random Access Memory) 1012 . The ROM 1011 stores a boot program such as BIOS (Basic Input Output System). Hard disk drive interface 1030 is connected to hard disk drive 1031 . Disk drive interface 1040 is connected to disk drive 1041 . For example, a removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1041 . The serial port interface 1050 is connected to a mouse 1051 and a keyboard 1052, for example. Video adapter 1060 is connected to display 1061, for example.

The hard disk drive 1031 stores, for example, an OS 1091, application programs 1092, program modules 1093, and program data 1094. That is, the program that defines each process of the scenario setting device 10 is implemented as a program module 1093 in which computer-executable code is described. Program modules 1093 are stored, for example, in hard disk drive 1031 . For example, the hard disk drive 1031 stores a program module 1093 for executing processing similar to the functional configuration of the scenario setting device 10 . The hard disk drive 1031 may be replaced by an SSD (Solid State Drive).

Also, the setting data used in the processing of the above-described embodiment is stored as program data 1094 in the memory 1010 or the hard disk drive 1031, for example. Then, the CPU 1020 reads out the program modules 1093 and program data 1094 stored in the memory 1010 and the hard disk drive 1031 to the RAM 1012 as necessary, and executes the processes of the above-described embodiments.

The program modules 1093 and program data 1094 are not limited to being stored in the hard disk drive 1031, but may be stored in a removable storage medium, for example, and read by the CPU 1020 via the disk drive 1041 or the like. Alternatively, the program modules 1093 and program data 1094 may be stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.). Program modules 1093 and program data 1094 may then be read by CPU 1020 through network interface 1070 from other computers.

10 scenario setting device 11 input unit 12 output unit 13 control unit 14 storage unit 21 state transition diagram screen 22 property screen 23 transition condition setting screen 24 operation setting screen 131 setting unit 132 GUI display control unit 133 scenario generation unit 141 GUI configuration information 142 Scenario information 211 State transition diagram list 212 Node type list 213 Right-click menu

Claims

a setting unit that receives scenario settings related to the behavior of the chatbot for the hierarchized state;
a scenario generation unit that generates a scenario for each state based on the information received by the setting unit;
A scenario setting device characterized by comprising:
further comprising a GUI display control unit that displays a GUI for each state of each layer;
2. The scenario setting device according to claim 1, wherein said setting unit receives settings via said GUI.
The setting unit receives scenario settings for each of the layers,
3. The scenario setting device according to claim 2, wherein the GUI display control unit switches the GUI to be displayed according to the hierarchy for which the setting unit receives the scenario setting.
The GUI display control unit displays a state transition diagram with each state of a specific hierarchy as a node,
The setting unit receives setting of utterance content of the chatbot corresponding to a node included in the state transition diagram,
4. The scenario setting device according to claim 2, wherein the scenario generation unit generates a scenario in which the contents of the utterance are linked to nodes included in the state transition diagram.
The GUI display control unit displays a state transition diagram with each state of a specific hierarchy as a node,
The setting unit receives settings for support content to be executed by the chatbot corresponding to nodes included in the state transition diagram,
4. The scenario setting device according to claim 2, wherein the scenario generation unit generates a scenario in which the content of support is linked to a node included in the state transition diagram.
A scenario setting method executed by a scenario setting device, comprising:
a setting step of receiving scenario settings related to the operation of the chatbot for the hierarchized state;
a scenario generation step of generating a scenario for each state based on the information received by the setting step;
A scenario setting method comprising:
A scenario setting program for causing a computer to function as the scenario setting device according to any one of claims 1 to 5.