JP7795502B2 - Anomaly detection device, anomaly detection method, and anomaly detection program - Google Patents

Description

The present invention relates to an anomaly detection device, an anomaly detection method, and an anomaly detection program.

Patent Document 1 (JP 2019-135602 A) discloses an information management system that associates work data before and after a correction and determines the legitimacy of corrections to work data that has already been registered.

This information management system stores data and holds rule information in a storage device, which includes multiple pairs of rules that apply to the data and first indices that indicate the validity of the difference between two pieces of data that conform to these rules. When new data is input, the processor identifies, from the rules included in the rule information, rules that conform to the new data and data stored in the storage device, and sums the first indices corresponding to the identified rules. The processor then determines the validity of the difference between the two pieces of data based on the sum of the first indices, and outputs the result of the validity determination and the basis for the validity determination.

Japanese Patent Application Laid-Open No. 2019-135602

In recent years, there has been an increasing trend of fraudulent activity in business data, such as accounting or subsidiary ledgers. To address this, there is a need for the development of an anomaly detection device that can automatically detect abnormalities in business data. Anomaly detection devices automatically determine anomalies, and based on the results, a responsible person, such as a business checker, determines whether the anomaly is due to a worsening business situation or intentional fraud, and takes the necessary action.

Internal control managers and other responsible parties need to check whether these operations are being carried out correctly, but if there is no data available to verify the operational status, it becomes difficult to confirm the operational status of anomaly detection.

The present invention was made in consideration of the above-mentioned problems, and aims to provide an anomaly detection device, an anomaly detection method, and an anomaly detection program that enable the operational status of anomaly detection to be confirmed.

In order to solve the above-mentioned problems and achieve the object, the anomaly detection device of the present invention has an alert definition setting unit that sets an alert definition, an alert definition execution unit that executes the set alert definition, an execution result generation unit that performs an anomaly determination for the alert target based on the execution result of the alert definition and generates a determination result based on the anomaly determination, an execution history generation unit that generates an execution history of the executed alert definition, and an output control unit that controls the output of the generated determination results and execution history to an output device, and the output control unit controls the output of a message for items that require operational confirmation as the determination result to the output device.

Furthermore, in order to solve the above-mentioned problems and achieve the object, the anomaly detection method for an anomaly detection device according to the present invention includes an alert definition setting step in which an alert definition setting unit sets an alert definition; an alert definition execution step in which an alert definition execution unit executes the set alert definition; an execution result generation step in which an execution result generation unit performs an anomaly determination for the alert target based on the execution result of the alert definition and generates a determination result based on the anomaly determination; an execution history generation step in which an execution history generation unit generates an execution history of the executed alert definition; and an output control step in which an output control unit controls the output of the generated determination result and execution history to an output device, and the output control unit controls the output of a message for items that require operational confirmation as the determination result to the output device.

Furthermore, in order to solve the above-mentioned problems and achieve the object, the anomaly detection program of the present invention causes a computer to function as an alert definition setting unit that sets an alert definition, an alert definition execution unit that executes the set alert definition, an execution result generation unit that performs an anomaly determination for the alert target based on the execution result of the alert definition and generates a determination result based on the anomaly determination, an execution history generation unit that generates an execution history of the executed alert definition, and an output control unit that controls the output of the generated determination results and execution history to an output device , and the output control unit controls the output of a message for items that require operational confirmation to the output device as the determination result.

This invention allows you to check the operational status of anomaly detection.

FIG. 1 is a block diagram showing a hardware configuration of an anomaly detection device according to an embodiment. FIG. 2 is a diagram illustrating an example of the preset data table. FIG. 3 is a diagram illustrating an example of an alert definition table. FIG. 4 is a diagram illustrating an example of an alert definition group table. FIG. 5 is a diagram illustrating an example of an alert definition group member table. FIG. 6 is a diagram illustrating an example of an alert execution history detail table. FIG. 7 is a diagram illustrating an example of the determination result table. FIG. 8 is a diagram illustrating an example of a production volume forecast alert result table. FIG. 9 is a diagram showing an example of an assumed cost alert result table. FIG. 10 is a diagram showing an example of the determination result message data. FIG. 11 is a diagram showing an example of a judgment result comment table. FIG. 12 is a diagram illustrating an example of a definition change history data table. FIG. 13 is a diagram illustrating an example of an alert definition history data table. FIG. 14 is a diagram illustrating an example of an alert definition generation management table. FIG. 15 is a diagram illustrating an example of an alert definition history table. FIG. 16 is a diagram illustrating an example of the alert security history data table. FIG. 17 is a diagram illustrating an example of an alert definition security generation management table. FIG. 18 is a diagram illustrating an example of an alert definition group security generation management table. FIG. 19 is a diagram illustrating an example of a user-defined relation history table. FIG. 20 is a diagram showing an example of a user group definition relation history table, a user-defined group relation history table, and a user group definition group relation history table. FIG. 21 is a diagram showing an example of the algorithm setting screen. FIG. 22 is a diagram illustrating an example of settings of an alert definition generation management table and an alert definition history table. FIG. 23 is a diagram showing an example of inputting changes to an alert definition based on the algorithm setting screen. FIG. 24 is a diagram for explaining the process of updating the alert definition generation management table and the alert definition history table when a change to the alert definition is input. FIG. 25 is a diagram showing an example of the security registration screen. FIG. 26 is a diagram illustrating an example of an alert definition security generation management table, a user definition relation history table, and a user group definition relation history table. FIG. 27 is a diagram showing an example of inputting security changes based on the security registration screen. FIG. 28 is a diagram for explaining the update process of the alert definition security generation management table, the user definition relation history table, and the user group definition relation history table when security changes are input. FIG. 29 is a diagram for explaining the abnormality determination operation. FIG. 30 is a diagram showing an example of displaying the abnormality determination result. FIG. 31 shows an example of an abnormal value determination result table to which input is made based on the abnormality determination result, and a determination result comment table to which comments on the abnormality determination result are input. FIG. 32 is a diagram showing an example of an alert AI operation status confirmation screen. FIG. 33 is a diagram for explaining details of the filter section of the alert AI operation status confirmation screen. FIG. 34 is a diagram for explaining details of the message section of the alert AI operation status confirmation screen. FIG. 35 is a diagram showing data of various tables acquired when displaying the execution status of the alert definition on the alert AI operation status confirmation screen. FIG. 36 shows the display format of various graphs indicating that the alert definition is being executed normally. FIG. 37 is a diagram showing the display form of the graph when the alert definition is not executed normally. FIG. 38 shows the data of various tables acquired when displaying the abnormality detection status on the alert AI operation status confirmation screen. FIG. 39 is a diagram showing data of another table acquired when displaying the abnormality detection status on the alert AI operation status confirmation screen. FIG. 40 is a diagram showing the display form of the graph when anomaly detection is being performed normally. FIG. 41 is a diagram showing the display form of the graph when abnormality detection is not performed normally. FIG. 42 shows the data of various tables acquired when displaying details of the abnormality detection status on the alert AI operation status confirmation screen. FIG. 43 shows data of other tables acquired when displaying details of abnormality detection status on the alert AI operation status confirmation screen. FIG. 44 shows the data of various tables acquired when displaying the monthly response status of abnormalities on the alert AI operation status confirmation screen. FIG. 45 shows other data in various tables acquired when displaying the monthly response status of anomalies on the alert AI operation status confirmation screen. FIG. 46 is a graph showing a case where a detected abnormality is dealt with normally. FIG. 47 is a graph showing a case where a detected abnormality is not properly dealt with. FIG. 48 is a diagram showing data of various tables acquired when generating an alert definition change history. FIG. 49 is a diagram showing data of various other tables acquired when generating an alert definition change history. FIG. 50 is a diagram showing an example of an alert definition change history etc. when an alert definition has been changed normally. FIG. 51 is a diagram showing an example of an alert definition change history etc. when an alert definition has not been changed normally. FIG. 52 is a diagram for explaining the generation of security generation management data. FIG. 53 is a diagram for explaining the generation of the change detail data. FIG. 54 is a diagram showing an example of the alert security change history, etc. FIG. 55 is a diagram showing an example of an alert security change history showing a normal security change example. FIG. 56 is a diagram showing an example of an alert security change history showing an example of an unauthorized change in security.

Below, an anomaly detection device according to an embodiment of the present invention will be described in detail with reference to the drawings. Note that the present invention is not limited to the following embodiment.

(Hardware configuration)
1, the anomaly detection device 1 of the embodiment includes a storage unit 2, a control unit 3, a communication interface unit 4, and an input/output interface unit 5. An input device 6 and an output device 7 are connected to the input/output interface unit 5. The output device 7 corresponds to a display unit of a monitor device (including a home television), a printing device, a speaker device, or the like. The input device 6 may be a keyboard device, a mouse device, a microphone device, or a monitor device that cooperates with a mouse device to realize a pointing device function.

The communication interface unit 4 is connected to a network 35, which may be a wide area network such as the Internet or a private network such as a local area network (LAN). An accounting server device 36, which stores business data such as accounting or subsidiary ledgers, is connected to the network 35. The anomaly detection device 1 of this embodiment performs anomaly detection processing based on a predetermined alert definition, as described below, on business data stored in the accounting server device 36 or business data acquired from the accounting server device 36 and stored in the memory unit 2.

The storage unit 2 can be, for example, a storage device such as a ROM (Read Only Memory), RAM (Random Access Memory), HDD (Hard Disk Drive), or SSD (Solid State Drive). The storage unit 2 stores an anomaly detection program that detects anomalies in business data such as accounting or subsidiary ledgers, and generates data that can be used to check the operational status of this anomaly detection, making it possible to check the operational status of the anomaly detection.

The storage unit 2 also stores a preset data table 11, an alert execution history detail table 12, a judgment result table 13, and a definition change history data table 14, which will be described later. Note that the "tables" refer to the respective storage areas provided within the storage unit 2 (or may be in external memory, etc.).

As shown in Figure 2, the pre-configured data table 11 includes an alert definition table 51, an alert definition group table 52, an alert definition group member table 53, an alert definition generation management table 54, and an alert definition history table 55.

The alert definition table 51 is a table that manages the settings of the algorithm used for judgment or updates to the judgment results, and as shown in Figure 3, it is composed of a definition number (definition ID), definition code (definition CD), definition name, result table name, algorithm used for anomaly detection, such as the approximation curve method or Hotelling's method, and algorithm definition.

The alert definition group table 52 is a table that manages alert definition groups, and is configured to include a definition group ID and a definition group name as shown in Figure 4. The alert definition group member table 53 is a table that manages alert definitions that belong to an alert definition group, and is configured to include a definition group ID and a definition ID as shown in Figure 5.

The alert execution history detail table 12 is a table that manages summary information on whether or not an abnormality detection that has been performed has been completed successfully. The execution information is updated each time an abnormal value determination is performed based on the alert definition. Figure 6 is a diagram showing the alert execution history detail data stored in the alert execution history detail table 12. As shown in Figure 6, the alert execution history detail table 12 stores alert execution history detail data such as the execution history detail ID, definition code, alert definition name, status (successful completion or error), number of data items, number of abnormal items, number of normal items, and update date.

The judgment result table 13 is a table that manages the abnormal value judgment results, response status, and comments after an abnormality judgment is performed. As shown in Figure 7, this judgment result table 13 is composed of an alert result table 60, a judgment result message data table 63, and a judgment result comment table 64.

The alert result table 60 is a table that manages information about the data used in the judgment, the presence or absence of abnormalities, and the response status. Within the alert result table 60, one abnormal value judgment result table is created for each alert definition. The example in Figure 7 is an example in which a production volume forecast alert result table 61 and an assumed cost alert result table 62 are created within the alert result table 60.

The progress forecast alert result table 61 is an abnormal value judgment result table created for the construction progress forecast alert definition. As shown in Figure 8, the progress forecast alert result table 61 is composed of the execution history detail ID, line number, judgment result (abnormal or normal), judgment result status (not yet addressed, in progress, no action required, addressed), construction progress rate, project name, and fiscal year and month, etc.

The estimated cost alert result table 62 is an abnormal value judgment result table created for the alert definition of the estimated cost of construction work. As shown in Figure 9, the estimated cost alert result table 62 is composed of the execution history detail ID, line number, judgment result (abnormal or normal), judgment result status (not yet addressed, in progress, no action required, addressed), cost amount, and accounting year and month, etc.

The judgment result message data table 63 is a table that manages messages generated in response to detected abnormalities. As shown in FIG. 10, the judgment result message data table 63 is composed of information such as an execution history detail ID, a line number, and a message generated in response to a detected abnormality.

The judgment result comment table 64 is a table that manages comments generated in response to the results of anomaly detection. As shown in FIG. 11, the judgment result comment table 64 includes a comment ID, execution history detail ID, line number, comment content, response status, update date, etc.

The definition change history data table 14 is a table that manages the change history of alert definitions and alert security, and as shown in FIG. 12, it includes an alert definition history data table 65 and an alert security history data table 66.

The alert definition history data table 65 is a table that stores history updates when an alert definition is created, changed, or deleted. As shown in FIG. 13, this alert definition history data table 65 includes an alert definition generation management table 71, an alert definition history table 72, a preprocessing definition history table 73, a preprocessing result item history table 74, and an aggregation condition history table 75. The alert definition history data table 65 also includes an aggregation result item history table 76, an extraction condition history table 77, a result message template history table 78, a message icon history table 79, a judgment result table information history table 80, a definition data mapping history table 81, and a definition schedule mapping history table 82.

The alert definition generation management table 71 is a table that manages the change history of alert definitions as generations. As shown in FIG. 14, the alert definition generation management table 71 contains the definition generation ID, definition ID, sequence number, status (completed, deleted, etc.), a latest flag indicating whether the alert definition is the latest generation definition (TRUE) or an older generation definition (FALSE), the name of the user who updated the alert definition of that generation (updating user name), and the update date and time.

The alert definition history table 72 is a table that manages alert definitions by generation, which manage algorithms, parameters, and abnormal value determination result table names. As shown in FIG. 15, the alert definition history table 72 is composed of the definition generation ID, definition ID, definition code, definition name, result table name in which the determination results created by executing the alert definition are stored, the algorithm for the alert definition, and specific definitions.

The preprocessing definition history table 73 is a table that manages preprocessing definitions, which manage preprocessing information for data used in judgment, by generation. The preprocessing result item history table 74 is a table that manages preprocessing result item information, which manages information on columns newly created when preprocessing is performed, by generation. The aggregation condition history table 75 is a table that manages aggregation conditions, which manage aggregation information for data used in judgment, by generation.

The aggregation result item history table 76 is a table that manages aggregation result item information by generation, which manages information on columns newly created when aggregation is performed. The extraction condition history table 77 is a table that manages extraction conditions by generation, which manage information on thresholds used for judgment. The result message template history table 78 is a table that manages result message templates by generation, which manage message templates that form the basis of judgment results.

The message icon history table 79 is a table that manages message icons, which manage icons corresponding to anomaly ranks, by generation. The judgment result table information history table 80 is a table that manages judgment result table information, which manages column information in the judgment result table 13, by generation. The definition data mapping history table 81 is a table that manages definition data mapping, which manages association information for data used in alert definitions, by generation. The definition schedule mapping history table 82 is a table that manages definition schedule mapping, which manages association information for schedules used in alert definitions, by generation.

The anomaly detection device 1 of this embodiment allows for the setting of handling permissions by "user" or "user group" for each "alert definition" or for each "alert definition group" which groups together multiple alert definitions.

For this reason, as shown in FIG. 16, the alert security history data table 66 is composed of an alert definition security generation management table 85, an alert definition group security generation management table 86, a user definition relation history table 87, a user group definition relation history table 88, a user definition group relation history table 89, and a user group definition group relation history table 90. This alert security history data table 66 stores history that is updated when security settings for an alert definition are newly set, changed, or deleted.

In other words, the alert definition security generation management table 85 is a table that manages the security change history for alert definitions as generations. As shown in FIG. 17, the alert definition security generation management table 85 is composed of a security generation ID, definition ID, sequence number, a latest flag indicating whether the security generation is the latest generation (TRUE) or an older generation (FALSE), the username of the user who updated the security of that generation (updating username), and the update date and time.

The alert definition group security generation management table 86 is a table that manages the security change history for alert definition groups as generations. As shown in FIG. 18, the alert definition group security generation management table 86 contains the security generation ID, definition group ID, sequence number, latest flag indicating whether the group security is the latest generation group security (TRUE) or an older generation group security (FALSE), the username of the user who updated the group security of that generation (updating username), and the update date and time.

The user-defined relation history table 87 is a table that manages user-defined relations by generation, which manage the alert definition permissions for users. As shown in FIG. 19, the user-defined relation history table 87 is composed of a security generation ID, user ID, user name, definition ID, output permission flag, and inquiry permission flag, etc. The output permission flag is a flag (information) that indicates whether each user has output permission (TRUE or FALSE) for each alert definition. The inquiry permission flag is a flag (information) that indicates whether each user has inquiry permission (TRUE or FALSE) for each alert definition.

The user group definition relation history table 88 is a table that manages user group definition relations, which manage alert definition permissions for user groups, by generation. As shown in FIG. 20(a), the user group definition relation history table 88 is composed of a security generation ID, user group ID, user group name, definition ID, output permission flag, and inquiry permission flag, etc. The output permission flag is a flag (information) that indicates whether each user group has output permission (TRUE or FALSE) for each alert definition. The inquiry permission flag is a flag (information) that indicates whether each user group has inquiry permission (TRUE or FALSE) for each alert definition.

The user-defined group relation history table 89 is a table that manages user-defined group relations by generation, which manage the permissions of alert definition groups for users. As shown in Figure 20 (b), the user-defined group relation history table 89 is composed of fields such as a security generation ID, user ID, user name, definition group ID, output permission flag, and inquiry permission flag. The output permission flag is a flag (information) that indicates whether each user has output permission (TRUE or FALSE) for each alert definition group. The inquiry permission flag is a flag (information) that indicates whether each user has inquiry permission (TRUE or FALSE) for each alert definition group.

The user group definition group relation history table 90 is a table that manages user group definition group relations, which manage the permissions of alert definition groups for user groups, by generation. As shown in FIG. 20(c), the user group definition group relation history table 90 is composed of fields such as a security generation ID, user group ID, user group name, definition group ID, output permission flag, and inquiry permission flag. The output permission flag is a flag (information) that indicates whether each user group has output permission (TRUE or FALSE) for each alert definition group. The inquiry permission flag is a flag (information) that indicates whether each user group has inquiry permission (TRUE or FALSE) for each alert definition group.

(Functional configuration of anomaly detection device)
Next, the control unit 3 executes the anomaly detection program stored in the memory unit 2, and thereby functions as an alert definition setting unit 21, an alert definition execution unit 22, an execution result generation unit 23, a definition change history generation unit 24, a display control unit 25, an authority setting unit 26, and an authority change history generation unit 27, as shown in FIG. 1 .

The alert definition setting unit 21 sets an alert definition for anomaly detection. The alert definition execution unit 22 executes the set alert definition. The execution result generation unit 23 performs an anomaly determination for the alert target (business data, as an example) based on the execution result of the alert definition, and generates a determination result based on the anomaly determination.

The definition change history generation unit 24 generates an execution history of executed alert definitions. This "execution history" is various data stored in the alert execution history detail table 12, an example of which is shown in Figure 6.

The output control unit controls the output of the generated judgment results and execution history to an output device. As an output control unit, the display control unit 25 can be provided with a print control unit, an audio output control unit, etc. When the display control unit 25 is provided as the output control unit, the display control unit 25 displays a predetermined screen and the execution results of the alert definition, etc. via the output device 7, which is a display unit. When a print control unit is provided as the output control unit, the print control unit prints out a predetermined screen and the execution results of the alert definition, etc. via the output device 7, which is a printer. When an audio output control unit is provided as the output control unit, the audio output control unit controls the output of a predetermined screen and the audio results of the execution of the alert definition, etc. via the output device 7, which is a speaker device.

The definition change history generation unit 24 generates a definition change history for an alert definition when the alert definition is changed. This "definition change history" is the alert definition generation management table 71 and alert definition history table 72 shown in FIG. 14. The output control unit controls the output of this definition change history to an output device, along with the judgment results and execution history.

The authority setting unit 26 sets the handling authority for the alert definition. The "handling authority" is, for example, the "output authority" and/or "inquiry authority" set by the output authority flag and/or inquiry authority flag in the user-defined relationship history table 87 shown in FIG. 19 or the user group-defined relationship history table 88 shown in FIG. 20.

When such handling permissions are changed, the permission change history generation unit 27 generates a permission change history for the handling permissions. The output control unit controls the output of this permission change history to an output device, along with the judgment results, execution history, and definition change history.

When an alert definition is changed, the definition change history generation unit 24 generates a definition change history for the changed alert definition by adding generation information indicating that it is the latest alert definition, and for other alert definitions, generates a definition change history by adding generation information indicating that they are older generations of alert definitions. For example, the latest flag (latest FLG) shown in the alert definition generation management table 71 in Figure 14 corresponds to this "generation information." In the example of Figure 14, the "generation information indicating that this is the latest alert definition" is flag information of "TRUE," and the "generation information indicating that this is an older generation of alert definition" is flag information of "FALSE."

When handling authority is changed, the authority change history generation unit 27 generates an authority change history in which generation information indicating that the changed handling authority is the latest handling authority is added to the handling authority after the change, and generates an authority change history in which generation information indicating that the other handling authorities are older generations of handling authority is added to the handling authority. For example, the latest flag (latest FLG) shown in the alert definition security generation management table 85 in FIG. 17 and the alert definition group security generation management table 86 in FIG. 18 corresponds to this "generation information." In the examples of FIGS. 17 and 18, the "generation information indicating the latest handling authority" is flag information of "TRUE," and the "generation information indicating the older generation of handling authority" is flag information of "FALSE."

(Alert definition setting behavior)
Next, the operation of setting an alert definition will be described. The setting of the alert definition is performed by the control unit 3 functioning mainly as the display control unit 25 and the alert definition setting unit 21 based on the anomaly detection program stored in the storage unit 2.

When setting a desired alert definition, the operator specifies the display of the algorithm setting screen. This causes the display control unit 25 to display the algorithm setting screen shown in Figure 21 (a) via the output device 7. The operator inputs the definition code of the desired alert definition and the desired algorithm via this algorithm setting screen. The example in Figure 21 is an example in which the "approximate curve method" algorithm is set for the alert definition of a "production volume forecast alert."

Details of the algorithm for this "approximate curve method" are set on the approximate curve setting screen shown in Figure 21(b), which is displayed by the display control unit 25. In the example of Figure 21(b), the approximate curve method is set with the X-axis item set to "Period progress rate," the Y-axis item set to "Cumulative progress rate," the approximate function candidate set to "Not specified," and the significance level set to "0.025."

When such an alert definition algorithm is input, the alert definition setting unit 21 sets the definition generation ID, definition ID, sequence number, status, and latest flag corresponding to the set alert definition in the alert definition generation management table 71, as shown in FIG. 22(a). In this example, since the first alert definition has been set, the latest flag information is "TRUE," indicating that this is the latest generation alert definition.

The alert definition setting unit 21 also sets the definition generation ID, definition ID, definition code, definition name, result table name, algorithm, definition, etc. corresponding to the set alert definition in the alert definition history table 72, as shown in FIG. 22 (b). This example shows that the set alert definition is an alert definition for a production volume forecast alert, and that the storage destination for the abnormality determination result based on this alert definition is the production volume forecast alert result table 61. This example also shows that the approximation curve method is used as the algorithm, the definition does not specify an approximation function candidate, and the significance level is set to 0.025.

(Alert definition change behavior)
Next, when changing the alert definition set in this manner, the operator again specifies the display of the algorithm setting screen. As a result, the display control unit 25 displays the algorithm setting screen illustrated in FIG. 23( a) via the output device 7. The example in FIG. 23( a) is an example of changing the alert definition of the above-mentioned production volume forecast alert. For example, when changing the significance level of the alert definition of the production volume forecast alert, the operator changes the significance level from the above-mentioned "0.025" to, for example, "0.05" on the approximate curve setting screen shown in FIG. 23( b) displayed by the display control unit 25.

When this change is entered, the control unit 3 functions as the definition change history generation unit 24 based on the anomaly detection program, and generates new records corresponding to this change in the alert definition generation management table 71 and the alert definition history table 72, as shown in Figures 24(a) and 24(b). That is, in the example of Figure 24(a), the record in the first row is a record of the alert definition that was initially set, and the record in the second row is a record of the alert definition that corresponds to the change. Similarly, in the example of Figure 24(b), the record in the first row is a record of the alert definition that was initially set, and the record in the second row is a record of the alert definition that corresponds to the change.

In this way, by generating a new record each time a change is entered, records for each generation are stacked as history in the alert definition generation management table 71 and the alert definition history table 72. This allows responsible parties such as internal control managers to easily check the transition status of changes to alert definitions.

Furthermore, the definition change history generation unit 24 sets the latest flag of the record of the new generation corresponding to the change input to "TRUE" among the latest flags in the alert definition generation management table 71 shown in FIG. 24(a), and updates the latest flag of the record of the generation that has become old due to the change input to "FALSE." This allows a responsible person such as an internal control administrator to easily identify the latest alert definition (= the alert definition with the latest flag set to "TRUE") among each alert definition.

(Security permission setting behavior)
Next, we will explain how to set security permissions, which are the permissions to output and query alert definitions for each user and each user group. The security permissions are set by the control unit 3 functioning mainly as the display control unit 25 and the permission setting unit 26 based on the anomaly detection program stored in the storage unit 2.

When setting the desired security permissions, the operator specifies the display of the security registration screen. This causes the display control unit 25 to display the security registration screen shown in FIG. 25 via the output device 7. This security registration screen displays check boxes for setting output permissions and check boxes for setting inquiry permissions for each user and user group. Using this security registration screen, the operator inputs a check icon into the check box for the user or user group to whom output permissions are to be granted, and also inputs a check icon into the check box for the user or user group to whom inquiry permissions are to be granted, for each alert definition.

Once security privileges for each user and user group are set for each alert definition in this way, the privilege setting unit 26 inputs the security generation ID "SV1001" and other information into the alert definition security generation management table 85 for each alert definition shown in FIG. 26(a), and sets the latest flag to "TRUE" to indicate that the security privileges for the security generation ID "SV1001" are the latest generation.

Furthermore, as shown in FIG. 26(b), the authority setting unit 26 sets the output authority and inquiry authority of each user set via the security registration screen shown in FIG. 25 for the user-defined relation history table 87 for each alert definition. Similarly, as shown in FIG. 26(c), the authority setting unit 26 sets the output authority and inquiry authority of each user group set via the security registration screen shown in FIG. 25 for the user-group-defined relation history table 88 for each alert definition.

In this example, as shown in Figure 26(b), "FALSE" has been set for both the output authority and inquiry authority for production volume forecast alerts for user "U0001." Also, as shown in Figure 26(b), "TRUE" has been set for the output authority for production volume forecast alerts for user "U0002," and "FALSE" has been set for the inquiry authority.

In addition, as shown in Figure 26(c), this example is an example in which "FALSE" is set as the output authority for production volume forecast alerts and "TRUE" is set as the inquiry authority for user group "UG0001." In addition, as shown in Figure 26(c), this is an example in which "TRUE" is set as both the output authority and the inquiry authority for user group "UG0002."

(Security permission change behavior)
Next, we will explain how to change the security privileges, which are the output and inquiry privileges for alert definitions for each user and each user group. To change the desired security privileges, the operator again selects the display of the security registration screen. This causes the display control unit 25 to display the security registration screen shown in FIG. 27 via the output device 7. The operator changes the security privileges by checking or deleting checkboxes that set the output and inquiry privileges on this security registration screen. The example in FIG. 27 shows how the security privileges granted to "User 2" and "User Group 1" are revoked by deleting the records for "User 2" and "User Group 1," and how the security privilege of "output privilege" is newly granted to "User 3." The example in FIG. 27 also shows how the security privilege of "inquiry privilege" is granted to "User 1," who previously had neither the "output privilege" nor the "inquiry privilege."

When the security permissions of each user and/or each user group are changed in this way, the control unit 3 functions as the permission change history generation unit 27 based on the anomaly detection program, and generates a record for a new security generation ID of "SV1002" in the alert definition security generation management table 85 shown in FIG. 28(a). The permission change history generation unit 27 then sets the latest flag of the record for the old security generation of "SV1001" to "FALSE" and the latest flag of the record for the new security generation of "SV1002" to "TRUE." This makes it possible to indicate that the record for the security generation of "SV1002" is the record for the latest security generation.

The authority change history generation unit 27 also generates in the user-defined relationship history table 87 a record for user "U0001" that will remain undeleted due to the current security authority change operation, and a record for user "U0003" to which new security authority has been granted. Then, the security generation ID "SV1002" indicating a new security generation is assigned to the records for user "U0001" and user "U0003."

In addition, the authority change history generation unit 27 sets the output authority flag for the records of each user, "U0001" and "U0003," who have been assigned the security generation ID "SV1002," to indicate whether or not the user has output authority (TRUE or FALSE), as set on the security registration screen, and sets the inquiry authority flag for each user's record to indicate whether or not the user has inquiry authority (TRUE or FALSE).

The authority change history generation unit 27 also generates records for the user group "UG0002" in the user group definition relation history table 88 that have not been deleted due to the current security authority change operation. It then assigns a security generation ID of "SV1002" to the records for the user group "UG0002," indicating that this is a new security generation.

In addition, the authority change history generation unit 27 sets the output authority flag for the record of the user group "UG0002" assigned the security generation ID "SV1002" to indicate whether or not the user has output authority set on the security registration screen (TRUE or FALSE), and sets the inquiry authority flag for each user's record to indicate whether or not the user has inquiry authority (TRUE or FALSE).

This allows internal control managers and other responsible parties to easily recognize the latest security permissions (output permission flag or inquiry permission flag set to "TRUE") for each user and each user group.

(Abnormality judgment operation)
Next, an abnormality determination operation based on the alert definition set as described above will be described. When the date and time set in the alert definition arrives or when an abnormality determination is specified by the operator, the control unit 3 functions as the alert definition execution unit 22 based on the abnormality detection program and performs an abnormality determination for the business data shown in Fig. 1 based on the alert definition. When the alert definition is executed, the alert definition execution unit 22 inputs an execution history detail ID that is automatically assigned for each execution, the definition ID of the executed alert definition, the execution status (execution completed, error, etc.), the number of data items, the number of abnormal items, and the number of normal items into the alert execution history detail table 12, as shown in Fig. 29(a).

The control unit 3 also functions as the execution result generation unit 23 based on the anomaly detection program, and inputs a message corresponding to the execution result of the alert definition into the judgment result message data table 63 shown in Figure 29(b). The execution result generation unit 23 also inputs the judgment results, etc., into the alert result table 60 shown in Figure 29(c) (the example in Figure 29(c) is an example of a production volume forecast alert result table 61) based on the execution result of the alert definition.

As a result, the alert execution history detail table 12 shown in Figure 29(a) stores stacked records containing the definition ID, status, number of data items, number of abnormal items, and number of normal items for each execution of the alert definition as history. Also, the judgment result message data table 63 shown in Figure 29(b) stores stacked records of messages of the judgment results of business data based on the alert definition as history. Furthermore, the alert result table 60 shown in Figure 29(c) (the example in Figure 29(c) is an example of a production volume forecast alert result table 61) stores stacked records of abnormality judgment results and the like based on the alert definition as history.

Responsible parties such as internal control managers can easily recognize the execution status and anomaly determination results for each alert definition based on the execution history of these tables 12, 63, 60 (61).

(Confirmation of the judgment result)
Next, when the anomaly determination results are generated by executing the alert definition as described above, the operation checker confirms them and updates the comment. When confirming the anomaly determination results and updating the comment, the operation checker specifies display of the analysis job screen via the input device 6. When this specification is made, the display control unit 25 refers to the determination result message data table 63 shown in FIG. 29( b) and displays, via the output device 7, an analysis job screen including a list of alerts, including the detection date, alert definition name, and message, for alert definitions for which a high degree of anomaly has been detected, as shown in FIG. 30( a).

The person in charge of checking the operations checks each message in the alert list and specifies whether to create a comment. When the person in charge of checking whether to create a comment is specified, the display control unit 25 displays the response status/comment input screen shown in Figure 30 (b) on the output device 7. The person in charge of checking the operations inputs a response status, such as "Not yet addressed," "In progress," or "Addressed," as well as a desired comment, such as "Currently checking with the person in charge," and operates the registration button.

When the registration button on this status/comment input screen is operated, the execution result generation unit 23 updates the judgment result status in the production volume forecast alert result table 61 to, for example, "in progress" based on the response status entered on the status/comment input screen, as shown in FIG. 31(a). The execution result generation unit 23 also updates the response status in the judgment result comment table 64 to, for example, "in progress" based on the response status entered on the status/comment input screen, as shown in FIG. 31(b). The execution result generation unit 23 also updates the response status in the judgment result comment table 64 to, for example, "checking with the person in charge" based on the comment entered on the status/comment input screen, as shown in FIG. 31(b).

(Visualization of operational status)
Next, the response status and comments corresponding to the results of determining an anomaly in business data by executing such an alert definition are displayed on the alert AI operation status confirmation screen described below. This alert AI operation status confirmation screen clearly visualizes data related to the operation status. By periodically checking this alert AI operation status confirmation screen, a responsible person such as an internal control manager can grasp the operation status of the anomaly detection alert definition. This alert AI operation status confirmation screen is configured to make it easy to notice any problems with the operation status of the alert definition, and if there is a problem, a responsible person such as an internal control manager can check the situation with the person in charge and correct the problem. This enables the anomaly detection device 1 to be operated appropriately.

That is, Figure 32 is a diagram showing an example of the alert AI operation status confirmation screen. The display control unit 25 displays this alert AI operation status confirmation screen via the output device 7 based on the anomaly detection program at a timing specified by a person in charge, etc. As shown in Figure 32, the alert AI operation status confirmation screen has display areas for a filter section, a message section, and a details display section.

As shown in Figure 33, the filter section includes an input field for the output period, an input field for the definition code, and a display button. By selecting the output period and the definition code for the output target, it is possible to narrow down the data displayed in the message section and the detailed display section. If the output period and definition code are not specified, the display control unit 25 will extract and display all existing data as the output target. The display control unit 25 will also initially display the output period of "the past year from the start date" and the definition code of "no specification" in the filter section.

Next, the display control unit 25 displays a message in the message section for items that require operational confirmation, as shown in Figure 34. Further specific examples are provided below.

1. Messages related to the execution status For example, a message such as "Two execution errors have occurred. Please check the execution status" is displayed if an error occurs during abnormal value determination.
Since there is a possibility that abnormality determination that should have been performed has not been performed, the person in charge checks the execution status graph to see what kind of error has occurred in which definition.

2. Messages regarding detection status (1)
For example, the message "The number of detected items was 0. Please check the detection status and definition contents." is displayed if the number of items determined to be abnormal when abnormal value determination is performed is 0.
Although a certain amount of anomaly detection is expected, if none are detected at all, the judgment may be inappropriate. Therefore, check the alert definition to ensure that the expected judgment result is obtained.

3. Messages regarding detection status (2)
For example, the message "The number of detected cases exceeds 30% of the total. Please check the detection status and definition contents" is displayed if the number of cases determined to be abnormal when abnormal value determination is performed exceeds 30% of the total.
There is a possibility that the number of detections has become too great to handle, or that unnecessary detections are being made, so the person in charge looks at the detection status graph to see how many cases have been detected by which alert definition.

4. Messages regarding response status For example, a message such as "There are three detections that have not been addressed. Please check the response status" will be displayed if there are any cases in which the response status to the abnormal value detection results detected after the abnormal value detection was performed has not been changed.
There is concern that abnormalities have been detected but left unaddressed for a long period of time, so the person in charge looks at the response status graph and checks for alert definitions whose response status has not been updated.

5. Messages regarding the alert definition change history For example, a message such as "The alert definition has been changed twice. Please check that the changes match your expectations" will be displayed if there is a history of changes to the alert definition.
There is concern that unexpected changes have been made to the alert definition, making it impossible to make correct judgments, so the person in charge looks at the table of alert definition change history to confirm the changes and the user who made them.

6. Messages regarding alert security change history For example, a message such as "Alert AI security settings have been changed twice. Please check that the changes match your expectations" will be displayed if there is a history of alert security changes.
Since unexpected changes have been made to the alert definition and security privileges may have been granted to a user who does not have security privileges to view data, the person in charge checks the alert security change history table to confirm the changes or the user who changed the alert definition.

(Check the status according to the message)
Next, the person in charge who sees such a message displays the confirmation screen specified in the message and checks the execution status of the alert definition, etc. The display control unit 25 displays the specified confirmation screen in the details display section of the alert AI operation status confirmation screen.

(Displays the execution status confirmation screen)
First, when the display of the execution status confirmation screen is designated based on the above-mentioned "1. Messages related to execution status," the display control unit 25 refers to the alert execution history detail table 12 and tallies the number (number of times) by status (successful completion and error) as shown in Fig. 35(a). Then, based on the tallied results, the display control unit 25 displays the pie chart shown in Fig. 36.

The display control unit 25 also refers to the alert execution history detail table 12 and tallies the number of alerts by month and by status, as shown in FIG. 35(b). Then, the display control unit 25 displays the stacked bar graph shown in FIG. 36 based on the tallied results.

Furthermore, the display control unit 25 refers to the alert execution history detail table 12 and tally up the last update date and time and the last update status (error or successful completion) of each alert definition, as shown in FIG. 35(c). The display control unit 25 also refers to the alert execution history detail table 12 and tally up the number of successful completions and the number of error completions for each alert definition, as shown in FIG. 35(d). The display control unit 25 then displays the last update date and time, last update status (error or successful completion), the number of successful completions, and the number of error completions for each alert definition, as shown in FIG. 36.

Based on the execution status confirmation screen shown in Figure 36, the person in charge should consider the following:

<Expected confirmation contents>
Is the abnormal value detection being carried out normally as scheduled?
<Possible situations>
Abnormal value detection is not performed, and the target cannot be detected.
<Confirmation image>
Are the alert definitions executed periodically? If there are periods when they are not executed, it is possible that they are not executed at the expected time.
Is the latest update date correct? (If it has not been executed, it will be earlier than expected.) If it has not been executed, check the alert definition (you can go to the setting screen by clicking the button to check the definition).
Check whether any errors have occurred (the number of error terminations is increasing) → If an error has occurred, identify the type of error from the log viewer and take action.

Figure 36 shows the execution status confirmation screen when anomaly detection is operating normally using each alert definition. In contrast, Figure 37 shows the execution status confirmation screen when anomaly detection is not operating normally using each alert definition. The example in Figure 37(a) is an example where many errors have occurred, and Figure 37(b) is an example where there is a period where anomaly detection is not being performed.

(Displays the detection status confirmation screen)
Next, when the display of a confirmation screen for the detection status is specified based on the above-mentioned "2. Message (1) Regarding the Detection Status," the display control unit 25 refers to the alert execution history detail table 12 and tallies the abnormality rates of the last updated records by alert definition, as shown in Figures 38(a) and 38(c). In addition, the display control unit 25 refers to the alert execution history detail table 12 and tallies the abnormality rates by alert definition and execution, as shown in Figure 38(b).

Furthermore, when the display of the detection status confirmation screen is specified based on the above-mentioned "3. Message Regarding Detection Status (2)," the display control unit 25 references the alert definition table 51 shown in FIG. 3 and acquires the definition code of each alert definition and the "result table name" of each alert definition, as shown in FIG. 42(a).

In addition, as shown in Figure 42 (b), the display control unit 25 obtains the execution history detail ID corresponding to the update date from the alert execution history detail table 12 and combines it with, for example, the production volume forecast alert result table 61 shown in Figure 42 (c) and/or the assumed cost alert result table 62 shown in Figure 42 (d).

Next, the display control unit 25 acquires the execution history detail ID, line number, and judgment result status of the record for which the judgment result is "1: Abnormal" from the acquired result table name, for example, the output forecast alert result table 61 shown in FIG. 8 and the assumed cost alert result table 62 shown in FIG. 9 (FIGS. 42(c) and 42(d)).

Next, as shown in FIG. 42(b), the display control unit 25 combines the result of combining the result table name and execution history detail ID, the judgment result message data table 63 shown in FIG. 42(e), and the judgment result comment table 64 shown in FIG. 43(a) using the execution history detail ID and row number. The display control unit 25 also acquires messages from the judgment result message data table 63, and if a "row" exists in the judgment result comment table 64, acquires the most recent update date for each execution history detail ID and row number as the last update date. If a "row" does not exist in the judgment result comment table 64, acquires the update date of the alert execution history detail table 12 as the last update date. Based on these aggregation results, the display control unit 25 generates the overall aggregation result shown in FIG. 43(b).

The display control unit 25 displays the execution details (detection result details by definition) shown in Figure 40 based on the aggregation results. In the execution details in Figure 40, "Number of normals" is the number of data items that were determined to be within the normal range out of the data items that were subject to abnormal value judgment by definition. "Number of abnormalities" is the number of data items that were determined to be abnormal out of the data items that were subject to abnormal value judgment by definition. "Abnormality rate" is the rate calculated using the formula "Number of abnormalities detected / (Number of normals + Number of abnormalities detected)". "Maximum abnormality rate" is the maximum value of the abnormality rate by definition calculated for each execution. "Minimum abnormality rate" is the minimum value of the abnormality rate by definition calculated for each execution.

The display control unit 25 also extracts the alert definition data selected in the execution details of FIG. 42 (assuming the assumed cost alert was selected) from the alert execution history details table 12, as shown in FIG. 39, from the data corresponding to the output period shown in FIG. 33. Then, based on the results of this extraction, a stacked bar graph of the number of data items determined to be normal and the number of data items determined to be abnormal for each execution date of anomaly detection is displayed, as shown in FIG. 40 (result status by execution date).

Based on the detection status confirmation screen shown in Figure 40, the person in charge will consider the following:

<Expected confirmation content>
Is the data that should be detected being detected correctly?
<Possible situations>
The outlier detection is over-detecting, meaning unnecessary things are being detected, reducing the effectiveness of the system.
The outlier detection is not detecting anything at all, i.e., things that should be detected are not being detected, reducing the effectiveness of the system.
<Confirmation image>
Is the overall number of abnormalities too high? → If so, check the response status described below (4. Messages regarding response status)
Is there a period when the number of anomalies has become extremely small? If they suddenly become undetectable, check the alert definition change history (described below) to see if the alert definition has been changed (5. Messages related to the alert definition change history)

The detection status confirmation screen shown in Figure 40 shows that the anomaly rate is not too high and the upper limit on the number of anomalies per anomaly detection run is low. This indicates that normal operation is being carried out. In contrast, Figures 41(a) to 41(c) are examples of abnormal operation. That is, the examples in Figures 41(a) and 41(b) have a high anomaly rate, and the abnormality rate is always high in the details. This indicates that normal operation is not being carried out. Furthermore, the example in Figure 41(c) has a normal anomaly rate, but the maximum anomaly rate is high and the minimum anomaly rate is low. Looking at the graph, we can see that the number of abnormal results drops sharply. This indicates that normal operation is not being carried out.

(Display of confirmation screen for response status)
Next, when a request to display a confirmation screen for the response status to an alert is made based on the above-mentioned "4. Messages regarding the response status," the display control unit 25 refers to the alert definition table 51 shown in FIG. 44( a) and acquires the definition code and result table name of each alert definition.

In addition, as shown in Figure 44(b), the display control unit 25 obtains the execution history detail ID corresponding to the update date from the alert execution history detail table 12 and combines it with, for example, the production volume forecast alert result table 61 shown in Figure 44(c) and/or the assumed cost alert result table 62 shown in Figure 44(d).

The display control unit 25 also detects records for which the judgment result is "1: Abnormal," as shown in Figures 44(c) and 44(d), for example, from the production volume forecast alert result table 61 shown in Figure 8 and the assumed cost alert result table 62 shown in Figure 9.

In addition, the display control unit 25 counts the number of statuses (not yet addressed, being addressed, and addressed) indicating the response status corresponding to the judgment result of "1: Abnormal" in the output forecast alert result table 61 shown in FIG. 8 and the assumed cost alert result table 62 shown in FIG. 9, for each status, as shown in FIG. 44(e) and FIG. 44(f).

After tallying up each status in this way, the display control unit 25 adds up the numbers for each status in each alert result table 61, 62, as shown in Figure 44 (g). Then, based on the result of this addition, the display control unit 25 displays a graph showing the proportion of response statuses for each status for alerts determined to be "1: Abnormal," as shown in the "Response Status Graph" in Figure 46.

The same applies to the "Monthly Response Status" display; the display control unit 25 references the alert definition table 51 shown in FIG. 45(a) and obtains the definition code and result table name for each alert definition.

In addition, as shown in Figure 45(b), the display control unit 25 obtains the execution history detail ID corresponding to the update date from the alert execution history detail table 12 and combines it with, for example, the production volume forecast alert result table 61 shown in Figure 45(c) and/or the assumed cost alert result table 62 shown in Figure 45(d).

The display control unit 25 also detects records for which the judgment result is "1: Abnormal," as shown in Figures 45(c) and 45(d), for example, from the production volume forecast alert result table 61 shown in Figure 8 and the assumed cost alert result table 62 shown in Figure 9.

In addition, the display control unit 25 tally up the number of statuses (not yet addressed, being addressed, and addressed) indicating the response status corresponding to the judgment result of "1: Abnormal" in the output forecast alert result table 61 shown in FIG. 8 and the assumed cost alert result table 62 shown in FIG. 9, by status and month, as shown in FIG. 45(e) and FIG. 45(f).

After tallying up each status for each month in this way, the display control unit 25 adds up the number of each status for each month in each alert result table 61, 62, as shown in Figure 45 (g). Then, based on the result of this addition, the display control unit 25 displays a bar graph showing the monthly response status for each alert determined to be "1: Abnormal," as shown in the "Monthly Response Status" bar graph in Figure 46.

In Figure 46, past statuses are marked as "resolved," and the most recent cases (December alerts) have a status of "in progress" or "not resolved." Based on the graph in Figure 46, this shows that each alert has been properly addressed.

In contrast, the graph in Figure 47(a) shows that there are "unaddressed" alerts from the past (April). Furthermore, the graph in Figure 47(b) shows that there are a large number of recent alerts (October to December), and that the number of "addressed" and "unaddressed" alerts is also increasing. In such cases, it can be seen that the alerts are not being properly addressed.

Based on the alert response status confirmation screen shown in Figure 47, the person in charge will consider the following:

<Expected confirmation contents>
Are corrective actions being taken in response to detected issues?
<Possible situations>
The judgment information is left unaddressed → The abnormal situation is forgotten and not addressed, or it is not addressed intentionally. Or, there are too many detections and it is not possible to address them in time.
<Confirmation image>
Check the monthly response status to see if any past cases have a status other than "resolved" (because the graph is displayed for each execution month, if there are any cases that are backlogged, the legend for past months will show "Not resolved" or "In progress"). If past cases remain in the graph as "Not resolved" or "In progress," click on the graph for the "Not resolved" section to narrow down the details, open this analysis screen, and check the comments. Then, identify the person in charge and check the details of the response status.

(Displays the alert definition change history confirmation screen)
Next, when the display of a confirmation screen for the change history of alert definitions is specified based on the above-mentioned "5. Messages Regarding Alert Definition Change History," the display control unit 25 references the alert definition generation management table 71 shown in FIG. 48(a) and generates change content data indicating the change user name, status (change completion or deletion), and change content of each alert definition, as shown in FIG. 48(b). In the change content data in FIG. 48(b), "New" in "Change Content" corresponds to "1 (first updated)" in the sequence (SEQ) and indicates the oldest alert definition. In addition, "Modified" in "Change Content" indicates that the alert definition has been modified.

Next, the display control unit 25 adds the result table name of each alert definition obtained from the alert definition table 51 shown in Figure 3 as a "definition name" to the change content data, and generates the combined data shown in Figure 49 (a).

Next, the display control unit 25 extracts from the combined data, as shown in Figure 49(b), records corresponding to the definition code of the alert definition specified in the filter section of the alert AI operation status confirmation screen shown in Figure 32. In the example of Figure 49(b), an alert definition for a production volume forecast alert was specified in the filter section of the alert AI operation status confirmation screen, so a record with a definition ID of "D0001" for this production volume forecast alert is extracted from the combined data.

The example in Figure 49 (b) also shows that the alert definition for the production volume forecast alert was newly set on "October 10, 2022" and then revised on "December 15, 2022." Therefore, the alert definition for the production volume forecast alert set on "October 10, 2022" is an older generation definition (FALSE), while the alert definition for the production volume forecast alert revised on "December 15, 2022" is the latest generation definition (TRUE). The number of changes is also "1 time."

The display control unit 25 also references the alert definition history table 72 shown in FIG. 15, compares the alert definition of the production volume forecast alert before and after the correction, and detects the changed parts, column names, algorithms, definitions, etc. in the alert definition of the production volume forecast alert before and after the correction, as shown in FIG. 49(c) and FIG. 49(d). Then, the display control unit 25 displays the number of changes to the alert definition, the change history, and change details, as shown in FIG. 50.

The example in Figure 50 shows that the number of changes was "1", and that the alert definition was revised on "December 15, 2022". The example in Figure 50 also shows that the change made to the "algorithm" was to change the significance level from "0.025" to "0.05". In the example in Figure 50, the number of changes to the alert definition was only "1". The change to the significance level was also within the normal range. This shows that anomaly detection using the alert definition is operating normally.

In contrast, in the example in Figure 51, the alert definition has been changed an extremely large number of times, at 30 times, and the value of the algorithm's significance level after the change has been deleted (set to 0). This is an act that makes it difficult to detect fraud, and shows that anomaly detection using alert definitions is not working properly.

The person in charge will consider the following based on the alert definition change history confirmation screens shown in Figures 50 and 51.

<Expected confirmation contents>
Have any unauthorized changes been made to the abnormal value determination definition?
<Possible situations>
The alert definition has been illegally changed -> The administrator of the alert definition has made a mistake in the settings, or the definition has been intentionally changed to make it difficult to detect something that should have been detected.
<Confirmation image>
Check the change history to see if the changes were within the expected range. → Important changes have been made at a time when operations should not have changed. Or, unexpected changes or changes that appear to be fraudulent have been made. In this case, check the situation with the administrator.

(Display of confirmation screen for Alert AI security definition change history)
Next, when the display of a confirmation screen for the change history of the alert AI security definition is specified based on the above-mentioned "6. Message Regarding Alert Security Change History," the display control unit 25 refers to the alert definition security generation management table 85 shown in Fig. 17 and extracts records corresponding to the alert definition specified in the filter section of the alert AI operation status confirmation screen shown in Fig. 32, as shown in Fig. 52(a). As a result, records of each user or user group to which security privileges such as output privileges or inquiry privileges (see Fig. 25) for the specified alert definition are extracted.

Similarly, the display control unit 25 references the alert definition group security generation management table 86 shown in FIG. 18 and extracts records corresponding to the alert definition specified in the filter section of the alert AI operation status confirmation screen, as shown in FIG. 52 (b). This extracts records for each user or user group that has been granted security privileges, such as output privileges or inquiry privileges, for the specified alert definition.

Next, the display control unit 25 combines the extracted records for each user and each user group to generate the security generation management data shown in Figure 52 (c). This security generation management data may be displayed.

Next, based on this security generation management data, the display control unit 25 references the alert definition generation management table 71 shown in FIG. 14 and extracts the pre- and post-correction records corresponding to the alert definition extracted as security generation management data, as shown in FIG. 52(d). Furthermore, based on the extracted pre- and post-correction records, the user definition relationship history table 87 shown in FIGS. 53(b) and 53(c), and the user group definition relationship history table 88 shown in FIG. 53(d), the display control unit 25 generates change detail data, as shown in FIG. 53(a), that includes the changes to the alert definition for each user and each user group, and the presence or absence of security permissions (output permission and/or inquiry permission) for each user and each user group.

Then, the display control unit 25 displays the number of security setting changes, alert security change history, and change details as shown in FIG. 54 based on the security generation management data shown in FIG. 52(c), the records before and after the correction corresponding to the alert definition in FIG. 52(d), and the change detail data shown in FIG. 53(a).

In this Figure 54, the display control unit 25 compares the records before and after the modification according to the definition of the detail (record) selected in "Alert Security Change History," and displays the changes in the "Change Details" display area.

The "Change Details" are displayed in the same way, but the display control unit 25 references the various tables and data corresponding to the alert definition or alert definition group selected in the "Alert Security Change History" details (record) to display the "Change Details."

That is, Figure 55 shows an example in which the alert definition group "Inventory Management Definition Group" has been selected in the "Alert Security Change History." In this case, the display control unit 25 generates change detail data, etc. based on the alert definition group security generation management table 86, user-defined group relation history table 89, and user group-defined group relation history table 90, and displays "change details" including the change location, user classification, display name, whether or not the user has output authority, and whether or not the user has inquiry authority, along with the "Alert Security Change History," as shown in Figure 55.

Figure 56 also shows an example in which "Output volume forecast alert definition" has been selected in "Alert security change history." In this case, the display control unit 25 generates change detail data, etc. based on the alert definition security generation management table 85, user definition relationship history table 87, and user group definition relationship history table 88, and displays "change details" including the change location, user classification, display name, whether or not the user has output authority, and whether or not the user has inquiry authority, along with the "Alert security change history," as shown in Figure 56.

Figure 55 also shows an example of an alert security change history, etc., that shows an example of a normal security change. In the example of Figure 55, the number of security setting changes was "twice," and "User A" changed the security settings for the "Inventory Management Definition Group" on "December 21, 2022," and also changed the security settings for the "Output Volume Forecast Alert" on "December 15, 2022." In the example of Figure 55, the number of security setting changes was only "twice." Furthermore, security permissions were set within the expected range. This shows that anomaly detection using the alert definition group is operating normally.

In contrast, Figure 56 shows an example of an alert security change history, which indicates an example of unauthorized security changes. In the example of Figure 56, the number of security setting changes is extremely high at 40 times, and security privileges have been granted to users who are unlikely to be granted security privileges. This shows that anomaly detection using alert definitions is not working properly.

The person in charge should consider the following based on the alert definition change history confirmation screens shown in Figures 55 and 56.

<Expected confirmation content>
Is the security authority that allows viewing of the analysis screen for anomaly detection by each alert definition (see FIG. 32, etc.) set only for users who should be set it?
<Possible situations>
The data is now viewable by users who should not have been allowed to view it, which suggests some kind of manipulation was used to conceal the fraud.
<Confirmation image>
Check whether there are any unexpected changes in the change history. If there are any unexpected changes or changes that appear to be fraudulent, check with the administrator about the situation.

(Effects of the embodiment)
As is clear from the above description, the anomaly detection device 1 according to the embodiment can accumulate data such as system execution history, judgment result information, and definition change history, which are necessary for operational confirmation. Furthermore, the data can be visualized (including display, printing, and audio output) to make it easier to check the operational status. Therefore, a responsible person, such as an internal control manager, can easily check the operational status of the anomaly detection device 1.

In addition, because the operational status of the anomaly detection device 1 can be checked, any abnormalities in operation can be quickly noticed and corrective measures can be taken.

In addition, the PDCA cycle for internal control can be properly implemented, improving the level of control. The PDCA cycle is a method for continuously improving and streamlining business operations by repeating the steps of "Plan → Do → Check → Act."

[Contribution to the United Nations-led Sustainable Development Goals (SDGs)]
This embodiment can contribute to improving business efficiency and promoting appropriate management decisions by companies, thereby contributing to the achievement of SDGs Goals 8 and 9.

Furthermore, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, thereby contributing to SDGs Goals 12, 13, and 15.

Furthermore, this embodiment can contribute to strengthening control and governance, thereby contributing to Goal 16 of the SDGs.

Other Embodiments
The present invention may be implemented in various different embodiments other than those described above within the scope of the technical concept set forth in the claims.

For example, of the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using known methods.

In addition, the processing procedures, control procedures, specific names, registered data for each process, information including parameters such as search conditions, screen examples, and database configurations shown in this specification and drawings may be changed as desired unless otherwise specified.

Furthermore, with regard to the anomaly detection device 1, the components shown in the figure are functional concepts and do not necessarily have to be physically configured as shown.

For example, all or any part of the processing functions of the anomaly detection device 1, particularly the control unit 3 and the various processing functions performed by the control unit 3, may be implemented by a CPU (Central Processing Unit) and a program interpreted and executed by the CPU, or may be implemented as hardware using wired logic. The program is recorded on a non-transitory computer-readable recording medium containing programmed instructions for causing the information processing device to execute the processing described in this embodiment, and is mechanically read by the anomaly detection device 1 as needed. That is, a computer program is recorded in a storage unit such as a ROM or HDD for working with the OS to issue instructions to the CPU and perform various processes. This computer program is executed by being loaded into RAM, and works with the CPU to form the control unit 3.

In addition, the anomaly detection program for this anomaly detection device 1 may be stored on another server device connected to the anomaly detection device 1 via any network, and all or part of it may be downloaded as needed.

The anomaly detection program for executing the processing described in this embodiment may be stored on a non-transitory computer-readable recording medium or configured as a program product. Here, "recording medium" includes any "portable physical medium" such as a memory card, USB (Universal Serial Bus) memory, SD (Secure Digital) card, flexible disk, magneto-optical disk, ROM, EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable and Programmable Read-Only Memory), CD-ROM (Compact Disk Read-Only Memory), MO (Magneto-Optical Disk), DVD (Digital Versatile Disk), and Blu-ray (registered trademark) Disc.

A "program" is a data processing method written in any language or description method, and may be in any format, such as source code or binary code. It should be noted that a "program" is not necessarily limited to a single structure, but also includes a distributed structure consisting of multiple modules or libraries, or a structure that achieves its function by working in conjunction with a separate program, such as an OS. The specific structure and reading procedure for reading a recording medium in the anomaly detection device 1 shown in the embodiment, as well as the installation procedure after reading, can use well-known structures and procedures.

The memory unit 2 is a storage means such as a memory device such as RAM or ROM, a fixed disk device such as a hard disk, a flexible disk, or an optical disk, and stores various programs, tables, databases, and web page files used for various processes and website provision.

The anomaly detection device 1 may also be configured as an information processing device such as a known personal computer or workstation, or may be configured as an information processing device to which any peripheral device is connected. The information processing device may also be implemented by installing software (including programs, data, etc.) that realizes the processing described in this embodiment.

Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the figures, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various additions or functional loads. In other words, the above-mentioned embodiments may be implemented in any combination, or embodiments may be implemented selectively.

This invention is suitable for use in detecting anomalies in accounting and other processes in a variety of industries.

REFERENCE SIGNS LIST 1 Anomaly detection device 2 Storage unit 3 Control unit 4 Communication interface unit 5 Input/output interface unit 6 Input device 7 Output device 11 Pre-set data table 12 Alert execution history detail table 13 Judgment result table 14 Definition change history data table 21 Alert definition setting unit 22 Alert definition execution unit 23 Execution result generation unit 24 Definition change history generation unit 25 Display control unit 26 Authority setting unit 27 Authority change history generation unit 35 Network 36 Accounting server device

Claims (8)

An alert definition setting section for setting an alert definition;
an alert definition execution unit that executes the set alert definition;
an execution result generation unit that performs an abnormality determination for an alert target based on an execution result of the alert definition and generates a determination result based on the abnormality determination;
an execution history generation unit that generates an execution history of the executed alert definition;
an output control unit that controls output of the generated determination result and the execution history to an output device ,
the output control unit controls the output device to output a message regarding an item requiring operational confirmation as a result of the determination;
An anomaly detection device characterized by the above. The output control unit may output the following as a message for an item requiring operational confirmation:
A message prompting you to check the execution status,
Message prompting you to check the detection status or definition details
A message prompting you to take action regarding the judgment result
A message prompting you to confirm the changes to the alert definition
Among the messages that prompt you to confirm the changes to security settings,
Output control of any one or more of them;
The anomaly detection device according to claim 1 , a definition change history generation unit that generates a definition change history of the alert definition when the alert definition is changed,
the output control unit controls output of the definition change history together with the determination result and the execution history to the output device;
The anomaly detection device according to claim 2 , an authority setting unit that sets handling authority for the alert definition;
an authority change history generating unit that generates an authority change history of the handling authority when the handling authority is changed,
the output control unit controls to output the authority change history to the output device together with the determination result, the execution history, and the definition change history;
The anomaly detection device according to claim 3 , the definition change history generation unit, when the alert definition is changed, generates the definition change history by adding generation information indicating that the changed alert definition is the latest alert definition, and generates the definition change history by adding generation information indicating that the other alert definitions are of older generations;
The anomaly detection device according to claim 4 , the authority change history generation unit, when the handling authority is changed, generates the authority change history by adding generation information indicating that the changed handling authority is the latest handling authority to the handling authority after the change, and generates the authority change history by adding generation information indicating that the other handling authorities are handling authorities of older generations to the handling authority after the change;
The anomaly detection device according to claim 5 . The alert definition setting unit includes an alert definition setting step for setting an alert definition;
an alert definition execution step in which an alert definition execution unit executes the set alert definition;
an execution result generation step in which an execution result generation unit performs an abnormality determination for an alert target based on an execution result of the alert definition, and generates a determination result based on the abnormality determination;
an execution history generating step in which an execution history generating unit generates an execution history of the executed alert definition;
an output control step in which an output control unit controls output of the generated determination result and the execution history to an output device;
the output control unit controls the output device to output a message regarding an item requiring operational confirmation as the determination result;
An anomaly detection method for an anomaly detection device, comprising : Computer,
An alert definition setting section for setting an alert definition;
an alert definition execution unit that executes the set alert definition;
an execution result generation unit that performs an abnormality determination for an alert target based on an execution result of the alert definition and generates a determination result based on the abnormality determination;
an execution history generation unit that generates an execution history of the executed alert definition;
functioning as an output control unit that controls the output of the generated determination result and execution history to an output device;
the output control unit controls the output device to output a message regarding an item requiring operational confirmation as a result of the determination;
An anomaly detection program characterized by: