Anomaly detection device, anomaly detection method, and anomaly detection program

Abstract

To confirm the operation situation of abnormality detection.SOLUTION: An alert definition setting unit sets an alert definition and an alert definition execution unit executes the set alert definition. An execution result generation unit determines an abnormality of an alert target on the basis of the result of executing the alert definition and generates the result of determination by the abnormality determination. An execution history generation unit generates an execution history of the executed alert definition. An output control unit controls output of the generated determination result and the execution history to an output apparatus. A manager such as an inside control manager thus can confirm the operation situation of abnormality detection on the basis of the execution history of the alert definition.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an anomaly detection device, an anomaly detection method, and an anomaly detection program. [Background technology]

[0002] Patent Document 1 (JP 2019-135602 A) discloses an information management system that associates work data before and after correction with work data that has been registered once and determines the legitimacy of the correction.

[0003] This information management system holds data and stores rule information in a storage device, the rule information including 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 the rules. When new data is input, a 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. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2019-135602 Summary of the Invention [Problem to be solved by the invention]

[0005] In recent years, there has been an increasing trend of fraudulent acts against 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 anomalies in business data. Anomaly detection devices automatically determine anomalies, and based on the determination 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 measures.

[0006] Internal control managers and other responsible parties need to check whether such operations are being carried out correctly, but if there is no data that can be used to verify the operational status, it becomes difficult to confirm the operational status of anomaly detection.

[0007] The present invention has been 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. [Means for solving the problem]

[0008] In order to solve the above-mentioned problems and achieve the object, the anomaly detection device according to the present invention includes 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 an 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 output of the generated determination result and execution history to an output device. The output control unit controls the output of a message for an item requiring operational confirmation as a determination result to an output device.

[0009] In order to solve the above problems and achieve the object, the present invention provides Anomaly detection deviceThe anomaly detection method 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 an 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 output of the generated determination result and execution history to an output device. The output control unit controls the output of a message for an item requiring operational confirmation as a determination result to an output device.

[0010] In order to solve the above-mentioned problems and achieve the object, an anomaly detection program according to the present invention includes a computer configured to: 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 an 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 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 for the items that require operational confirmation as a result of the determination. [Effects of the Invention]

[0011] The present invention can confirm the operational status of anomaly detection. [Brief explanation of the drawings]

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

[0013] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An anomaly detection device according to an embodiment of the present invention will be described in detail below with reference to the accompanying drawings. However, the present invention is not limited to the following embodiment.

[0014] (Hardware configuration) As shown in Fig. 1, an anomaly detection device 1 according to an 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.

[0015] The communication interface unit 4 is connected to a network 35, for example, 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 the embodiment performs anomaly detection processing based on a predetermined alert definition, as will be described later, on the business data stored in the accounting server device 36 or on business data acquired from the accounting server device 36 and stored in the memory unit 2.

[0016] A storage device such as a ROM (Read Only Memory), RAM (Random Access Memory), HDD (Hard Disk Drive), or SSD (Solid State Drive) can be used as the storage unit 2. 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.

[0017] 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 an external memory, etc.).

[0018] As shown in FIG. 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.

[0019] The alert definition table 51 is a table that manages the settings of the algorithm used for judgment or the update contents of the judgment result, and is composed of a definition number (definition ID), a definition code (definition CD), a definition name, a result table name, an algorithm used for anomaly detection, such as the approximation curve method or the Hotelling method, and a definition of the algorithm, as shown in Figure 3.

[0020] The alert definition group table 52 is a table for managing groups of alert definitions, and is configured to include a definition group ID and a definition group name as shown in Fig. 4. The alert definition group member table 53 is a table for managing alert definitions belonging to a group of alert definitions, and is configured to include a definition group ID and a definition ID as shown in Fig. 5.

[0021] The alert execution history detail table 12 is a table that manages summary information of the determination of whether or not the executed anomaly detection was completed normally, and the execution information is updated each time an abnormal value determination is executed based on the alert definition. Fig. 6 is a diagram showing the alert execution history detail data stored in the alert execution history detail table 12. As shown in Fig. 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.

[0022] The judgment result table 13 is a table for managing the abnormal value judgment result, the response status, and comments after the abnormality judgment is executed. This judgment result table 13 is configured to include an alert result table 60, a judgment result message data table 63, and a judgment result comment table 64, as shown in FIG.

[0023] The alert result table 60 is a table that manages information on the data used for judgment, the presence or absence of an abnormality, and the response status, and one abnormal value judgment result table is created for one alert definition in the alert result table 60. The example in Fig. 7 is an example in which a production volume forecast alert result table 61, an assumed cost alert result table 62, etc. are created in the alert result table 60.

[0024] The progress forecast alert result table 61 is an abnormal value judgment result table created for the alert definition of the construction progress forecast. As shown in Fig. 8, the progress forecast alert result table 61 includes 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 period progress rate, project name, accounting year and month, etc.

[0025] 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 includes 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, accounting year and month, etc.

[0026] The judgment result message data table 63 is a table for managing messages generated in response to detected abnormalities. As shown in Fig. 10, the judgment result message data table 63 includes an execution history detail ID, a line number, and a message generated in response to a detected abnormality.

[0027] The judgment result comment table 64 is a table for managing comments generated in response to the detection result of an abnormality. As shown in Fig. 11, the judgment result comment table 64 includes a comment ID, an execution history detail ID, a line number, a comment content, a response status, an update date, and the like.

[0028] The definition change history data table 14 is a table for managing the change history of alert definitions and alert security, and includes an alert definition history data table 65 and an alert security history data table 66, as shown in FIG.

[0029] The alert definition history data table 65 is a table that stores history that is updated 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.

[0030] 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 is configured to include a definition generation ID, a definition ID, a sequence number, a status (completed, deleted, etc.), a latest flag indicating whether the alert definition is a definition of the latest generation (TRUE) or an older generation (FALSE), the name of the user who updated the alert definition of that generation (updating user name), the update date and time, etc.

[0031] The alert definition history table 72 is a table that manages alert definitions that manage algorithms, parameters, and abnormal value determination result table names by generation. As shown in Fig. 15, the alert definition history table 72 includes a 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 of the alert definition, and a specific definition.

[0032] The preprocessing definition history table 73 is a table that manages preprocessing definitions, which manage information on preprocessing 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 information on aggregation for data used in judgment, by generation.

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

[0034] Furthermore, the message icon history table 79 is a table that manages message icons that manage icons corresponding to anomaly level ranks by generation. The judgment result table information history table 80 is a table that manages judgment result table information that 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 mappings that manage association information of data used in alert definitions by generation. The definition schedule mapping history table 82 is a table that manages definition schedule mappings that manage association information of schedules used in alert definitions by generation.

[0035] The anomaly detection device 1 of the embodiment is capable of setting handling authority by "user" or "user group" for "each alert definition" or for "each alert definition group" which groups together multiple alert definitions.

[0036] 16, the alert security history data table 66 includes 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.

[0037] That is, the alert definition security generation management table 85 is a table that manages the security change history for the alert definition as a generation. As shown in Fig. 17, the alert definition security generation management table 85 includes a security generation ID, a definition ID, a sequence number, a latest flag indicating whether the security generation is the latest generation (TRUE) or an old generation (FALSE), the user name of the user who updated the security of that generation (updating user name), and the update date and time.

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

[0039] The user-defined relation history table 87 is a table that manages user-defined relations by generation, which manage the alert definition authority for each user. As shown in FIG. 19, the user-defined relation history table 87 is configured to include a security generation ID, user ID, user name, definition ID, output authority flag, and inquiry authority flag. The output authority flag is a flag (information) that indicates whether each user has output authority (TRUE or FALSE) for each alert definition. The inquiry authority flag is a flag (information) that indicates whether each user has inquiry authority (TRUE or FALSE) for each alert definition.

[0040] The user group definition relation history table 88 is a table that manages user group definition relations, which manage the alert definition authorities for user groups, by generation. As shown in FIG. 20(a), the user group definition relation history table 88 is configured to include a security generation ID, user group ID, user group name, definition ID, output authority flag, and inquiry authority flag. The output authority flag is a flag (information) that indicates whether or not each user group has output authority for each alert definition (TRUE or FALSE). The inquiry authority flag is a flag (information) that indicates whether or not each user group has inquiry authority for each alert definition (TRUE or FALSE).

[0041] 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 FIG. 20(b), the user-defined group relation history table 89 is configured to include 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 for each alert definition group (TRUE or FALSE). The inquiry permission flag is a flag (information) that indicates whether each user has inquiry permission for each alert definition group (TRUE or FALSE).

[0042] The user group definition group relation history table 90 is a table that manages, by generation, user group definition group relations that manage the authority of alert definition groups for user groups. As shown in FIG. 20(c), the user group definition group relation history table 90 is configured to include a security generation ID, user group ID, user group name, definition group ID, output authority flag, and inquiry authority flag. The output authority flag is a flag (information) that indicates whether or not each user group has output authority for each alert definition group (TRUE or FALSE). The inquiry authority flag is a flag (information) that indicates whether or not each user group has inquiry authority for each alert definition group (TRUE or FALSE).

[0043] (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.

[0044] 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.

[0045] The definition change history generating 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 shown in FIG. 6, as an example.

[0046] The output control unit controls the output of the generated judgment results and execution history to an output device. As the 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 the 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 the 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 of the execution results of the alert definition, etc. via the output device 7, which is a speaker device.

[0047] The definition change history generation unit 24 generates a definition change history of the alert definition when the alert definition is changed. This "definition change history" is the alert definition generation management table 71 and the 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 together with the judgment result and execution history.

[0048] The authority setting unit 26 sets the handling authority for the alert definition. The "handling authority" is, for example, the "output authority" and / or the "inquiry authority" set by the output authority flag and / or the 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.

[0049] When such handling authority is changed, the authority change history generating unit 27 generates an authority change history of the handling authority. The output control unit controls output of this authority change history to an output device together with the judgment result, the execution history, and the definition change history.

[0050] 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 the alert definition is the latest alert definition, and generates a definition change history for other alert definitions by adding generation information indicating that the alert definitions are of older generations. For example, the latest flag (latest FLG) shown in the alert definition generation management table 71 of FIG. 14 corresponds to this "generation information." In the example of FIG. 14, the "generation information indicating that the alert definition is the latest alert definition" is flag information of "TRUE," and the "generation information indicating that the alert definition is of older generations" is flag information of "FALSE."

[0051] When the 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) illustrated in the alert definition security generation management table 85 of FIG. 17 and the alert definition group security generation management table 86 of FIG. 18 corresponds to this "generation information." In the examples of FIGS. 17 and 18, the "generation information indicating that the handling authority is the latest" is flag information of "TRUE," and the "generation information indicating that the handling authority is an older generation" is flag information of "FALSE."

[0052] (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 abnormality detection program stored in the storage unit 2.

[0053] When setting a desired alert definition, the operator specifies the display of the algorithm setting screen. As a result, the display control unit 25 displays the algorithm setting screen shown in FIG. 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 FIG. 21 is an example in which the algorithm "approximate curve method" is set for the alert definition of "production volume forecast alert."

[0054] Details of the algorithm for this "approximate curve method" are set on an approximate curve setting screen shown in Fig. 21(b), which is displayed by the display control unit 25. In the example of Fig. 21(b), the approximate curve method is set with the X-axis item set to "progress rate of construction period," 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."

[0055] 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 the alert definition is of the latest generation.

[0056] 22(b), the alert definition setting unit 21 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. 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.

[0057] (Alert definition change behavior) Next, when changing the alert definition set in this way, the operator again specifies the display of the algorithm setting screen. As a result, the display control unit 25 displays the algorithm setting screen exemplified 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 approximation curve setting screen shown in FIG. 23(b) displayed by the display control unit 25.

[0058] When this change is input, 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.

[0059] In this way, by generating a new record each time a change is input, records of each generation are stacked as history in the alert definition generation management table 71 and the alert definition history table 72. This allows a responsible person such as an internal control administrator to easily check the transition status of changes to the alert definition.

[0060] 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 recognize the latest alert definition (the alert definition with the latest flag set to "TRUE") among all the alert definitions.

[0061] (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.

[0062] When setting the desired security authority, the operator specifies the display of a security registration screen. As a result, the display control unit 25 displays the security registration screen shown in FIG. 25 via the output device 7. This security registration screen displays check boxes for setting whether output authority is granted for each user and for each user group, and check boxes for setting whether inquiry authority is granted. Using this security registration screen, the operator inputs a check icon into the check box of the user or user group to which output authority is granted, and also inputs a check icon into the check box of the user or user group to which inquiry authority is granted, for each alert definition.

[0063] When the security privileges of each user and each user group are set for each alert definition in this manner, the privilege setting unit 26 inputs the security generation ID of "SV1001" and the like 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 of "SV1001" are the latest generation.

[0064] 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 a user definition 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 a user group definition relation history table 88 for each alert definition.

[0065] In this example, "FALSE" is set for both the output authority and inquiry authority for the production volume forecast alert for user "U0001" as shown in Figure 26(b). Also, as shown in Figure 26(b), "TRUE" is set for the output authority for the production volume forecast alert for user "U0002", and "FALSE" is set for the inquiry authority.

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

[0067] (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 specifies 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 whether or not to grant output privileges and whether or not to grant 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 had not previously been granted either "output privilege" or "inquiry privilege."

[0068] When the security privileges of each user and / or each user group are changed in this way, the control unit 3 functions as the privilege change history generation unit 27 based on the anomaly detection program, and generates a record for a record with a new security generation ID of "SV1002" in the alert definition security generation management table 85 shown in FIG. 28(a). The privilege 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.

[0069] The authority change history generation unit 27 also generates a record for user "U0001" that remains without being deleted due to the current security authority change operation, and a record for user "U0003" to which new security authority has been granted, in the user definition relationship history table 87. The authority change history generation unit 27 then assigns a security generation ID of "SV1002" indicating a new security generation to the records for user "U0001" and user "U0003."

[0070] In addition, the authority change history generation unit 27 sets the output authority flag of the records of each user, "U0001" and "U0003", who have been assigned the security generation ID of "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 of the records of each user to indicate whether or not the user has inquiry authority (TRUE or FALSE).

[0071] The authority change history generation unit 27 also generates records for the user group "UG0002" that remain without being deleted as a result of this security authority change operation in the user group definition relation history table 88. Then, the security generation ID of "SV1002" indicating a new security generation is assigned to the record for the user group "UG0002".

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

[0073] This allows a responsible person such as an internal control manager to easily recognize the latest security authority (output authority flag or inquiry authority flag = "TRUE") of each user and each user group.

[0074] (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).

[0075] 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 to a determination result message data table 63 shown in Fig. 29(b). The execution result generation unit 23 also inputs the determination result, etc., to the alert result table 60 shown in Fig. 29(c) (the example in Fig. 29(c) is an example of a volume forecast alert result table 61) based on the execution result of the alert definition.

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

[0077] A responsible person such as an internal control manager can easily recognize the execution status and abnormality determination results of each alert definition based on the execution history of these tables 12, 63, 60 (61).

[0078] (Confirmation of the judgment result) Next, when the anomaly determination results are generated by executing the alert definition as described above, the task checker checks them and updates the comment. When checking the anomaly determination results and updating the comment, the task checker specifies the 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 that includes a list of alerts, including the detection date, alert definition name, and message, for alert definitions that have detected a high degree of anomaly, as shown in FIG. 30(a).

[0079] The person in charge of checking the operations checks each message in the alert list and specifies whether to create a comment. When the creation of a comment is specified, the display control unit 25 displays the response status and comment input screen shown in Fig. 30(b) on the output device 7. The person in charge of checking the operations inputs a response status, for example, one of "Not yet handled," "In handling," or "Handling completed," as well as a desired comment, for example, "Checking with the person in charge," and operates the registration button.

[0080] When the registration button on this status / comment input screen is operated, the execution result generation unit 23 updates the determination 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 determination 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 determination 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).

[0081] (Visualization of operational status) Next, the response status and comments corresponding to the results of the determination of 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 regularly 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 make corrections. This enables the anomaly detection device 1 to be operated appropriately.

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

[0083] As shown in FIG. 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 to be 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 extracts and displays all existing data as the output target. Furthermore, the display control unit 25 displays the output period of "the past year from the start date" and the definition code of "not specified" in the filter section as the initial display.

[0084] Next, the display control unit 25 displays a message for the item requiring operational confirmation in the message section, as shown in Fig. 34. Further specific examples are shown below.

[0085] 1. Messages regarding execution status For example, the message "An execution error has occurred twice. 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.

[0086] 2. Messages regarding detection status (1) For example, the message "The number of detected cases was 0. Please check the detection status and definition contents." will be displayed if the number of cases determined to be abnormal when abnormal value detection 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 settings are such that the expected judgment results can be obtained.

[0087] 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 detection 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.

[0088] 4. Message regarding response status For example, the message "There are three detections that have not been addressed. Please check the response status." is displayed if there are 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.

[0089] 5. Message about alert definition change history For example, the message "The alert definition has been changed twice. Please check that the changes match what you expected" 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.

[0090] 6. Message about alert security change history For example, if there is a history of changes to alert security, the message "Alert AI security settings have been changed twice. Please check that the changes match what you expected" will be displayed. 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.

[0091] (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.

[0092] (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 a pie chart as shown in Fig. 36.

[0093] Furthermore, the display control unit 25 refers to the alert execution history detail table 12 and tallies the number of alerts by month and by situation, as shown in Fig. 35(b). Then, the display control unit 25 displays a stacked bar graph shown in Fig. 36 based on the tallied results.

[0094] Furthermore, the display control unit 25 refers to the alert execution history detail table 12 and tallies 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). Furthermore, the display control unit 25 refers to the alert execution history detail table 12 and tallies the number of successful completions and the number of error completions of each alert definition, as shown in FIG. 35(d). Then, the display control unit 25 displays the last update date and time, the last update status (error or successful completion), the number of successful completions and the number of error completions of each alert definition, as shown in FIG.

[0095] The person in charge will consider the following based on the execution status confirmation screen shown in FIG.

[0096] <Expected confirmation content> 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 "Confirm definition" button) Check whether an error has 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.

[0097] Figure 36 shows the execution status confirmation screen when anomaly detection is operating normally according to each alert definition. In contrast, Figure 37 shows the execution status confirmation screen when anomaly detection is not operating normally according to 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.

[0098] (Displays the confirmation screen for the detection status) Next, when the display of a confirmation screen for the detection status is designated 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). Furthermore, 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).

[0099] Furthermore, when the display of a confirmation screen for the detection status is specified based on the above-mentioned "3. Message regarding the detection status (2)", the display control unit 25 refers to 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).

[0100] 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).

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

[0102] Next, as shown in FIG. 42(b), the display control unit 25 combines the result of combining the result table name and the 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. Furthermore, the display control unit 25 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 date among the update dates 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. Then, based on these aggregation results, an overall aggregation result as shown in FIG. 43(b) is generated.

[0103] The display control unit 25 displays the execution details (detection result details by definition) shown in Fig. 40 based on this aggregation result. In the execution details in Fig. 40, "normal number" is the number of data items that were determined to be within the normal range among the data items that were subject to abnormal value judgment by definition. "abnormal number" is the number of data items that were determined to be abnormal among the data items that were subject to abnormal value judgment by definition. "abnormal rate" is the rate calculated using the formula "number of detected abnormalities / (number of normals + number of detected abnormalities)". "maximum abnormal rate" is the maximum value by definition of the abnormal rate calculated for each execution. "minimum abnormal rate" is the minimum value by definition of the abnormal rate calculated for each execution.

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

[0105] Based on the detection status confirmation screen shown in FIG. 40, the person in charge makes the following considerations.

[0106] <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) If there is a period when the number of abnormalities has become extremely small, and 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).

[0107] In the detection status confirmation screen shown in Figure 40, the anomaly rate is not too high, and the upper limit of 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. In addition, in the example in Figure 41(c), the anomaly rate is normal, but the maximum anomaly rate is high and the minimum anomaly rate is low. Furthermore, when looking at the graph, the number of abnormal results drops sharply. This indicates that normal operation is not being carried out.

[0108] (Displays the confirmation screen for compatibility status) Next, when a request is made to display a confirmation screen for the response status to the alert based on the above-mentioned "4. Message 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.

[0109] 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).

[0110] In addition, the display control unit 25 detects records whose 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.

[0111] 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 production volume forecast alert result table 61 shown in Figure 8 and the assumed cost alert result table 62 shown in Figure 9, for each status, as shown in Figure 44(e) and Figure 44(f).

[0112] 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 Fig. 44(g). Then, based on the result of this addition, the display control unit 25 displays a graph showing the proportion of response status for each status for alerts determined to be "1: Abnormal", as shown in the "Response Status Graph" in Fig. 46.

[0113] The same applies to the "monthly response status," where the display control unit 25 refers to the alert definition table 51 shown in FIG. 45(a) and acquires the definition code and result table name of each alert definition.

[0114] 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).

[0115] In addition, the display control unit 25 detects records whose 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.

[0116] 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 Figure 8 and the assumed cost alert result table 62 shown in Figure 9, by status and by month, as shown in Figure 45(e) and Figure 45(f).

[0117] 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 Fig. 45(g). Then, based on the result of this addition, the display control unit 25 displays a bar graph showing the monthly response status of each alert determined to be "1: Abnormal", as shown in the bar graph of "Monthly response status" in Fig. 46.

[0118] In Figure 46, past statuses are marked as "Resolved," and the most recent cases (December alerts) have a status of "Responding" or "Not Resolved." Based on the graph in Figure 46, it can be seen that each alert has been properly addressed.

[0119] 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 the number of recent alerts (October to December) has increased, and the number of "addressed" and "unaddressed" alerts has also increased. In such cases, it can be seen that the alerts have not been properly addressed.

[0120] Based on the confirmation screen for the response status to the alert shown in FIG. 47, the person in charge will consider the following:

[0121] <Expected confirmation content> 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" (the graph is displayed for each execution month, so if there are any backlogs, 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.

[0122] (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 name of the user who made the change, the status (change completion or deletion), and the change content of each alert definition, as shown in FIG. 48(b). Note that in the change content data in FIG. 48(b), "New" in "Change Content" corresponds to "1 (first updated)" in the sequence (SEQ), and indicates that this is the oldest alert definition. Furthermore, "Modified" in "Change Content" indicates that the alert definition has been modified.

[0123] Next, the display control unit 25 adds the result table name of each alert definition acquired from the alert definition table 51 shown in FIG. 3 as a “definition name” to the change content data, and generates the combined data shown in FIG. 49(a).

[0124] Next, the display control unit 25 extracts from the combined data, as shown in Figure 49(b), a record 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 volume forecast alert was specified in the filter section of the alert AI operation status confirmation screen, and therefore a record with a definition ID of "D0001" for this volume forecast alert is extracted from the combined data.

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

[0126] 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 Figures 49(c) and 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 Figure 50.

[0127] 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 in this revision was to the "algorithm", and that the significance level was revised 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.

[0128] In contrast, the example in Figure 51 shows that 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.

[0129] Based on the alert definition change history confirmation screens shown in FIGS. 50 and 51, the person in charge will consider the following:

[0130] <Expected confirmation content> 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.

[0131] (Displays the confirmation screen for the Alert AI security definition change history) Next, when the display of the confirmation screen for the change history of the alert AI security definition is specified based on the above-mentioned "6. Message regarding the 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 that has been granted security privileges such as output privileges or inquiry privileges (see Fig. 25) for the specified alert definition are extracted.

[0132] Similarly, the display control unit 25 refers to 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). As a result, records of each user or user group that has been granted security privileges such as output privileges or inquiry privileges for the specified alert definition are extracted.

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

[0134] Next, based on this security generation management data, the display control unit 25 refers to the alert definition generation management table 71 shown in Fig. 14 and extracts the records before and after the correction corresponding to the alert definition extracted as the security generation management data, as shown in Fig. 52(d). Furthermore, based on the extracted records before and after the correction, the user definition relation history table 87 shown in Fig. 53(b) and Fig. 53(c), and the user group definition relation history table 88 shown in Fig. 53(d), the display control unit 25 generates change detail data including the change contents of the alert definition for each user and for each user group and the presence or absence of security authority (output authority and / or inquiry authority) for each user and each user group, as shown in Fig. 53(a).

[0135] Then, the display control unit 25 displays the number of changes to the security settings, the change history of the alert security, and details of the changes, 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).

[0136] In FIG. 54, the display control unit 25 compares the records before and after the correction according to the definition of the details (records) selected in "Alert security change history", and displays the changes in the "Change details" display area.

[0137] In addition, the display method for the "change details" is similar, but the display control unit 25 refers to various tables and various data corresponding to the alert definition or alert definition group selected in the details (record) of the "alert security change history" and displays the "change details."

[0138] 55 shows an example in which the alert definition group "inventory management definition group" is selected in the "alert security change history." In this case, the display control unit 25 generates change detail data and the like based on the alert definition group security generation management table 86, the user definition group relation history table 89, and the user group definition group relation history table 90, and displays "change details" including the changed part, user classification, display name, whether or not the user has output authority, and whether or not the user has inquiry authority, together with the "alert security change history," as shown in FIG.

[0139] 56 shows an example in which "output forecast alert definition" is selected in "alert security change history." In this case, the display control unit 25 generates change detail data and the like based on the alert definition security generation management table 85, the user definition relation history table 87, and the user group definition relation history table 88, and displays "change details" including the changed part, user classification, display name, whether or not the user has output authority, and whether or not the user has inquiry authority, together with the "alert security change history," as shown in FIG.

[0140] Figure 55 also shows an example of an alert security change history, etc., which 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 of the "Inventory Management Definition Group" on "December 21, 2022," and also changed the security settings of 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.

[0141] In contrast, Figure 56 shows an example of an alert security change history that shows an example of unauthorized security changes. In the example in Figure 56, the number of security setting changes is extremely high at "40 times," and security privileges have been set for users who are unlikely to be granted security privileges. This shows that anomaly detection using alert definitions is not operating normally.

[0142] Based on the alert definition change history confirmation screens shown in FIGS. 55 and 56, the person in charge will consider the following:

[0143] <Expected confirmation content> Are the security permissions that allow viewing of the analysis screen for anomaly detection by each alert definition (see Figure 32, etc.) set only for users who should be set? <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.

[0144] (Effects of the embodiment) As is clear from the above description, the anomaly detection device 1 of 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.

[0145] Furthermore, since the operating status of the anomaly detection device 1 can be checked, any abnormalities in operation can be quickly noticed and corrective measures can be taken.

[0146] It also allows for the proper implementation of the PDCA cycle in internal control, 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."

[0147] [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 Goals 8 and 9 of the SDGs.

[0148] Furthermore, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, thereby contributing to the achievement of SDGs Goals 12, 13, and 15.

[0149] Furthermore, this embodiment can contribute to strengthening control and governance, which can contribute to the achievement of Goal 16 of the SDGs.

[0150] [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.

[0151] For example, among 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.

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

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

[0154] For example, all or any part of the processing functions of the anomaly detection device 1, particularly the control unit 3 and the 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 processes described in this embodiment, and is mechanically read by the anomaly detection device 1 as needed. That is, a storage unit such as a ROM or HDD stores a computer program for working with an OS to issue instructions to the CPU and perform various processes. The computer program is executed by being loaded into RAM, and works with the CPU to constitute the control unit 3.

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

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

[0157] Furthermore, a "program" is a data processing method written in any language or description method, and does not matter whether it is in the form of source code or binary code. Note that a "program" is not necessarily limited to a single structure, but also includes a structure that is distributed as multiple modules or libraries, or a structure that achieves its function by cooperating with a separate program, such as an OS. Note that the specific structure and reading procedure for reading a recording medium in the anomaly detection device 1 described in the embodiment, as well as the installation procedure after reading, can use well-known structures and procedures.

[0158] 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 providing websites.

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

[0160] Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the drawings, and all or part of them can be configured by functionally or physically distributing and integrating them in any unit according to various additions or functional loads. In other words, the above-described embodiments can be implemented in any combination, or embodiments can be implemented selectively. [Industrial Applicability]

[0161] The present invention is suitable for application to anomaly detection in accounting and other fields in various industries. [Explanation of symbols]

[0162] 1. Anomaly detection device 2 Storage section 3. Control Unit 4. Communication interface section 5 Input / Output Interface Section 6 Input Devices 7 Output Devices 11 Pre-configured Data Tables 12 Alert Execution History Detail Table 13 Judgment result table 14 Definition change history data table 21 Alert definition setting section 22 Alert definition execution part 23 Execution result generation unit 24 Definition change history generation part 25 Display control unit 26 Permission Setting Section 27 Permission change history generation part 35 Network 36 Accounting server device

Claims

1. 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.

2. The output control unit may, 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 ,

3. 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 ,

4. 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,

5. 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,

6. 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 .

7. 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 a result of the determination; An anomaly detection method for an anomaly detection device, comprising:

8. 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:

Images