WO2022259557A1 - 判定装置、判定方法および判定プログラム - Google Patents

判定装置、判定方法および判定プログラム Download PDF

Info

Publication number
WO2022259557A1
WO2022259557A1 PCT/JP2021/022416 JP2021022416W WO2022259557A1 WO 2022259557 A1 WO2022259557 A1 WO 2022259557A1 JP 2021022416 W JP2021022416 W JP 2021022416W WO 2022259557 A1 WO2022259557 A1 WO 2022259557A1
Authority
WO
WIPO (PCT)
Prior art keywords
log
determination
event
necessary
unnecessary
Prior art date
Application number
PCT/JP2021/022416
Other languages
English (en)
French (fr)
Inventor
史拓 横瀬
公雄 土川
佐也香 八木
有記 卜部
泰輔 若杉
晴夫 大石
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to JP2023526835A priority Critical patent/JPWO2022259557A1/ja
Priority to US18/568,383 priority patent/US20240281353A1/en
Priority to PCT/JP2021/022416 priority patent/WO2022259557A1/ja
Publication of WO2022259557A1 publication Critical patent/WO2022259557A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design

Definitions

  • the present invention relates to a determination device, a determination method, and a determination program.
  • Logs used for process mining must meet the requirements of "only the information to be analyzed”, “divided into items", and “events can be identified”. be.
  • operation logs that record operations on a PC often do not meet the log requirements for process mining. Therefore, when performing process mining, for example, it is necessary to process the operation log to meet this requirement by three pre-processes: "removal of unnecessary operation events", “judgment of the same operation event", and "dividing by project”. .
  • the "unnecessary operation event removal” process is a process of removing unnecessary information contained in the operation log.
  • the operation log may include unnecessary operation events as information unrelated to the work to be analyzed.
  • humans had to visually check the operation log and delete unnecessary events one by one to eliminate unnecessary operation events. This process is done manually.
  • the systems targeted for process mining analysis have different internal structures, so it is not possible to automatically determine targets to be removed using fixed rules and algorithms. In addition, it is also possible to manually customize the rules and algorithms according to the internal construction and work of the above system. It is difficult for general users because they have to understand
  • a determination device includes a reception unit that receives a log event;
  • the present invention is characterized by comprising an estimating unit that estimates a criterion for determining necessity, and a determining unit that determines whether a log event to be processed is necessary or unnecessary based on the criterion.
  • a determination method is a determination method executed by a determination device, comprising: a step of receiving a log event; and determining whether the log event to be processed is necessary or unnecessary based on the criterion.
  • the determination program includes the steps of: receiving a log event; and estimating a determination criterion for determining whether the log event is necessary or unnecessary based on the attribute value of the log included in the log event. and determining whether the log event to be processed is necessary or unnecessary based on the determination criteria.
  • FIG. 1 is a block diagram showing a configuration example of a determination device according to the first embodiment.
  • FIG. 2 is a diagram illustrating logs stored in a storage unit according to the first embodiment;
  • FIG. 3 is a diagram illustrating an example of reception processing by selecting an operation event according to the first embodiment.
  • FIG. 4 is a diagram showing an example of rule types for each attribute element according to the first embodiment.
  • FIG. 5 is a diagram illustrating an example of determination criterion estimation processing according to the first embodiment.
  • FIG. 6 is a diagram illustrating an example of operation event determination processing according to the first embodiment.
  • FIG. 7 is a flow chart showing an example of the overall flow of processing according to the first embodiment.
  • FIG. 8 is a diagram explaining process mining.
  • FIG. 9 is a diagram illustrating preprocessing for process mining.
  • FIG. 10 is a diagram for explaining conventional problems.
  • FIG. 11 is a diagram showing a computer executing a program.
  • the process mining method for business analysis described above is widely used in the market.
  • preprocessing may be required for process mining of operation logs.
  • the operation log is recorded as it is, events other than those targeted for process mining will also be included, so it is necessary to remove unnecessary events. It is also possible to manually remove unnecessary events one by one, but if the amount of logs is large, it is difficult to manually remove all of them.
  • the systems targeted for process mining analysis have different internal structures, so it is not possible to automatically determine targets to be removed using fixed rules and algorithms. In addition, it is also possible to manually customize the rules and algorithms according to the internal construction and work of the above system. must be understood.
  • FIG. 1 is a block diagram showing a configuration example of a determination device according to this embodiment.
  • the determination device 10 has an input unit 11 , an output unit 12 , a communication unit 13 , a storage unit 14 and a control unit 15 .
  • the input unit 11 is in charge of inputting various information to the determination device 10.
  • the input unit 11 is implemented by a mouse, a keyboard, or the like, and receives input such as setting information to the determination device 10 .
  • the output unit 12 controls output of various information from the determination device 10 .
  • the output unit 12 is implemented by a display or the like, and outputs setting information or the like stored in the determination device 10 .
  • the communication unit 13 manages data communication with other devices. For example, the communication unit 13 performs data communication with each communication device. Further, the communication unit 13 can perform data communication with an operator's terminal (not shown).
  • the storage unit 14 stores various information referred to when the control unit 15 operates and various information acquired when the control unit 15 operates.
  • the storage unit 14 can be realized by, for example, a RAM (Random Access Memory), a semiconductor memory device such as a flash memory, or a storage device such as a hard disk or an optical disk.
  • a RAM Random Access Memory
  • the storage unit 14 is installed inside the determination device 10 in the example of FIG. 1, it may be installed outside the determination device 10, and a plurality of storage units may be installed.
  • the storage unit 14 stores operation logs to be processed.
  • the storage unit 14 stores, as an operation log, "occurrence time” of the operation, "specific information of the operated GUI component", and the like.
  • information of one operation event is expressed as a collection of multiple attribute values (columns, items).
  • FIG. 2 is a diagram illustrating logs stored in a storage unit according to the first embodiment.
  • an operation log in which only operations on the browser are recorded is assumed for the sake of simplicity. Therefore, only browser-related values are shown in the log attribute values.
  • the operation log may also record inputs from some input device or command inputs on the CUI (Character-based User Interface). If you want to record those other kinds of operations, you need to increase the log entries as needed.
  • CUI Consumer-based User Interface
  • the storage unit 14 stores “date and time”, “operation type”, “URL”, “title”, “tagName”, “type”, “id”, “value”, “name”, “className”, “left”, “top”, “width”, and “height” are stored.
  • the operation log to be stored in the storage unit 14 is not limited to the one described above, and may also store, for example, an image captured at the time of operation.
  • the storage unit 14 stores a "null" value indicating that the value is not set. Note that the attribute elements included in the operation log do not have to be the directly obtained information itself. You can have it. In addition, the storage unit 14 stores operation logs in chronological order of events so that the order of events occurring during work can be known.
  • the control unit 15 controls the overall determination device 10 .
  • the control unit 15 has a reception unit 15a, an estimation unit 15b, and a determination unit 15c.
  • the control unit 15 is, for example, an electronic circuit such as a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), or an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array).
  • the reception unit 15a receives an operation event as a log event.
  • the receiving unit 15a receives an image of an operation event selected by the user from among a plurality of images of operation events. That is, the accepting unit 15a accepts a plurality of captured images selected by the user as necessary or unnecessary from among the captured images of the plurality of operation events displayed in chronological order.
  • the log event is an event including a log having a similar structure other than the operation event (for example, history of incoming and outgoing calls).
  • the reception unit 15a selects multiple captured images visually displayed in chronological order on the screen of the user's terminal as “necessary selection", that is, operation events to be retained, by the user's click operation.
  • the operation log of the operation event associated with the selected captured image is accepted as the "required operation log”.
  • the accepting unit 15a selects a plurality of operation events to be removed.
  • the operation log of the operation event associated with the image is accepted as "unnecessary operation log". Note that the reception processing described above will also be described in detail in [Details of each processing] (1. Exemplary reception processing by selection of an operation event) described later.
  • the reception unit 15a also refers to the operation logs stored in the storage unit 14 and acquires the selected operation log. On the other hand, the reception unit 15a outputs the set of selected operation logs to the estimation unit 15b. Note that the reception unit 15 a may store the set of selected operation logs in the storage unit 14 .
  • the estimation unit 15b estimates a determination criterion (rule) for determining whether an operation event is necessary or unnecessary based on the attribute values of the operation log included in the operation event as the log event. For example, the estimation unit 15b estimates a criterion for determining whether an operation event is necessary or not by extracting common attribute values of operation logs. That is, the estimating unit 15b extracts a character string or a numerical range commonly included in the attribute elements according to a condition (rule type) set for each attribute element (attribute element), thereby determining whether the operation event is necessary. Alternatively, a judgment criterion for judging unnecessary is estimated.
  • the estimation unit 15b selects the attribute element “title” (rule type B: character column) contains the common character string "route search" as an attribute value of the operation event that you want to keep. Guess as a criterion. Note that the above estimation processing will also be described in detail in [Details of Each Processing] (4. Estimation Processing of Rules for Each Attribute Value), which will be described later.
  • the estimating unit 15b acquires the set of operation logs output by the receiving unit 15a and the rule types of the attribute values stored in the storage unit 14, and uses the commonly included character strings or numerical ranges as the determination criteria. Extract as On the other hand, the estimation unit 15b outputs the extracted determination criteria to the determination unit 15c. Note that the estimation unit 15b may store the extracted criterion in the storage unit 14. FIG.
  • the determination unit 15c determines whether the operation event to be processed is necessary or unnecessary as the log event to be processed, based on the determination criteria. For example, the determination unit 15c uses the extracted attribute value to determine whether the operation event to be processed is necessary or unnecessary. That is, the determination unit 15c matches the operation event including the character string commonly included in the attribute elements or the operation event satisfying the numerical range commonly included in the attribute elements, thereby determining the operation event to be processed. determine whether it is necessary or unnecessary.
  • the determination unit 15c selects the operation event not selected by the user. is searched for the attribute element "title” that includes the character string "route search”, and the searched operation event is output as the determination result. On the other hand, if there is no determination criterion other than the above, the determining unit 15c outputs an operation event that is not one of the desired operation events to be retained as an operation event to be removed. Note that the determination process described above will also be described in detail in [Details of each process] (5. Operation event determination process) described later.
  • the determination unit 15 c transmits the output determination result to the output unit 12 .
  • the determination unit 15 c may store the output determination result in the storage unit 14 .
  • the determination unit 15c presents the user with the determination result of whether or not it is necessary, and outputs the determination result approved by the user, thereby determining whether or not the operation event to be processed is necessary or unnecessary.
  • the determining unit 15c when the determining unit 15c outputs a plurality of visual images as an operation event that includes the character string "route search" in the attribute element "title”, the visual image is displayed by the user's click operation. is selected again as a determined determination result. Note that the above estimation processing will also be described in detail in [Details of each processing] (6. Determination processing based on interaction with the user) described later.
  • FIG. 3 is a diagram illustrating an example of reception processing by selecting an operation event according to the first embodiment.
  • FIG. 3 it is preferable to visually display operation events in chronological order and allow the user to make a selection.
  • one operation event is displayed as one node, and the captured image recorded at the same time as the operation event is displayed on the node, and the operation position is displayed with a thick frame on the image. .
  • the user can recognize specifically which operation each operation event is without understanding the contents recorded in the operation log.
  • the determination device 10 receives the operation event selected by the user (broken line frame in the lower part of FIG. 3) as an example of the user.
  • FIG. 3 illustrates examples of operation events that are desired to be retained, ie, necessary operation events, but it is also possible to select operation events that are desired to be removed, ie, unnecessary operation events.
  • FIG. 4 is a diagram showing an example of rule types for each attribute value according to the first embodiment.
  • the determination device 10 applies the following four types of rules also shown in FIG. 4 according to the nature of each attribute value of the operation event.
  • the first rule is “determine a character string by exact match” (rule type A)
  • the second rule is “determine a character string by partial match” (rule type B)
  • the third rule is “determine a character string by partial match” (rule type B).
  • the second rule is “judgment by numerical value range” (rule type C)
  • the fourth rule is "not used for judgment” (rule type D).
  • rule type A is applied to attribute elements of "operation type", “tagName”, “type”, “id” and “name”, and to attribute elements of "URL” and “title”
  • rule type B applies rule type C to attribute elements of "width” and “height”
  • rule type C applies rule type C to attribute elements of "date and time”
  • value is applied to attribute elements of "className”, “left”, and “top”
  • Rule type D is applied. Note that the user may not use some of the above four types of rules, or may add other types of rules.
  • the determination device 10 rejects this rule for the corresponding attribute element.
  • the determination device 10 uses, as parameters of this rule, character strings in which all of the attribute values in the illustrated plurality of operation events completely match. Also, if it is not necessary to distinguish between uppercase and lowercase letters, the parameters are converted to uppercase letters or lowercase letters for uniformity. Note that even if all the attribute values are "null" in a plurality of exemplified operation events, this rule is adopted for the corresponding attribute element.
  • Rule matching process If the corresponding attribute value of the operation event to be inspected completely matches the character string found in the above-described rule estimation process, the determination device 10 determines that this rule matches (matches). In addition, when the determination device 10 does not need to distinguish between uppercase and lowercase letters, the attribute value is converted into uppercase letters or lowercase letters in the same manner as the parameter, and then compared.
  • rule estimation process In a plurality of illustrated operation events, if the corresponding attribute value includes "null", the determination device 10 rejects this rule for the corresponding attribute element. On the other hand, the determination device 10 finds a common partial character string in a plurality of exemplified operation events. At this time, in the simplest mechanism, the determination device 10 finds the longest common substring that is commonly included in all events, and uses this as a parameter of this rule.
  • the determination device 10 rejects this rule when the number of characters in the common substring is equal to or less than the threshold number of characters.
  • This threshold can be set arbitrarily, but for example, since the leading "http://" and "https://" parts are always common in the case of URLs, 8 characters or less to exceed this will not be adopted. You should do it like this.
  • the determination device 10 determines whether “the corresponding attribute value includes null”, “the corresponding attribute value includes a value that cannot be treated as a numerical value”, or “the corresponding attribute If the value includes any other abnormal value (eg, a negative value for the width), this rule is not adopted for the corresponding attribute element.
  • the determination device 10 calculates the average ⁇ and the standard deviation ⁇ in a plurality of exemplified operation events, and uses them as parameters of this rule. At this time, the determination device 10 may reject this rule when the standard deviation ⁇ is equal to or greater than a certain threshold, or when a sufficient number is not exemplified (only one is exemplified). For example, if the threshold is set to 30, and if the threshold is 30 or more, it is considered that the variation is large and there is almost no commonality, and it is rejected.
  • FIG. 5 is a diagram illustrating an example of determination criterion estimation processing according to the first embodiment.
  • the determination device 10 estimates a rule for each attribute element with respect to the operation log data of a plurality of illustrated operation events, as follows. In FIG. 5, operation logs of four exemplary operation events are shown.
  • the determination device 10 determines "adopted” or “rejected” for each attribute element according to the rule type set in advance for each attribute element. Next, the determination device 10 extracts parameters from the attribute values of the attribute elements determined to be "adopted”. Then, the determination device 10 estimates the extracted parameter as a rule corresponding to the attribute element.
  • the determination device 10 sets the common character string "http://www.sample.jp/ transit/” is included, the attribute element is determined to be “adopted”, and the inclusion of “http://www.sample.jp/transit/” as a character string is extracted as a parameter.
  • the common character string "route search” is included as an attribute value of the attribute element "title” (rule type B: character string is judged by partial match)
  • the determination device 10 determines that the attribute element "Adopt” is determined, and the inclusion of "route search” as a character string is extracted as a parameter.
  • FIG. 6 is a diagram illustrating an example of operation event determination processing according to the first embodiment.
  • the determination device 10 uses the estimated rules to check the rules for operation events other than the exemplified operation events, and determines operation events to be left/removed as follows. In FIG. 6, operation events that do not correspond to the inferred rules are removed.
  • the determination device 10 adds the character string "http:// www.sample.jp/transit/" and the character string "route search” is included in the attribute element "title"), "the group outside the operation events to be left (the operation event group to be removed)” (See (2) in FIG. 6) and "group automatically determined as operation event to be left” (see (3) in FIG. 6).
  • the determination device 10 may not be able to correctly determine which operation events to leave/remove, such as when the number of example operation events is small or when the variety of example operation events is insufficient. Therefore, the determination device 10 does not immediately determine the determination result, but temporarily indicates the determined operation event to the user, and confirms the determination result of the operation event to be retained/removed after obtaining confirmation from the user. can also That is, if the user determines that the presented determination result is inappropriate, the determination device 10 can once cancel the provisional determination result and prompt the user to increase the number of examples.
  • FIG. 7 is a flow chart showing an example of the overall flow of processing according to the first embodiment. Below, while showing the flow of the whole determination processing, the outline of each processing is demonstrated.
  • the reception unit 15a of the determination device 10 executes operation event selection reception processing (step S101).
  • the estimation unit 15b of the determination device 10 executes determination rule estimation processing (step S102).
  • the determination unit 15c of the estimation device 10 executes operation event determination processing (step S103), and ends the processing. Note that steps S101 to S103 below can be performed in a different order. Also, some of steps S101 to S103 below may be omitted.
  • operation event selection reception processing by the reception unit 15a First, operation event selection reception processing by the reception unit 15a will be described.
  • the user selects a plurality of operation events to be retained or removed as an example, and the operation logs of the selected operation events are accepted.
  • the user can recognize which operation each operation event is specifically without understanding the contents recorded in the operation log. be able to.
  • the determination rule estimation processing by the estimation unit 15b will be described.
  • “adopted” or “rejected” is determined for each attribute element according to the rule type set in advance for each attribute element of the operation event for which the selection is received, and "adopted” is determined.
  • a parameter is extracted from the attribute value of the attribute element, and the extracted parameter is estimated as a rule corresponding to the attribute element.
  • the determination rule of the selected operation event can be effectively estimated.
  • the determination rule estimation processing by the determination unit 15c will be described.
  • the rule is checked for operation events other than the illustrated operation event, and the operation event to be left/removed is determined.
  • the determined operation event is provisionally presented to the user, and the determination result of the operation event to be retained/removed is determined after obtaining confirmation from the user.
  • the user can be urged to gradually increase the number of examples through such interaction, and the operation event to leave/remove can be determined easily and effectively.
  • FIG. 8 is a diagram explaining process mining.
  • FIG. 9 is a diagram illustrating preprocessing for process mining.
  • FIG. 10 is a diagram for explaining conventional problems.
  • attribute values recorded in operation logs require specialized knowledge to interpret.
  • knowledge of HTML (Hyper Text Markup Language) and DOM is required to interpret the meaning of an operation log that records operations on a browser.
  • URLs and the like may not be exactly the same even for the same page. Further, for example, if a session ID is included, a part of the URL changes each time a user logs in, so it is necessary to guess a URL generation rule in order to determine the identity of the URL.
  • an image of an operation event selected by the user from among a plurality of images of operation events is received, and common attribute values of operation logs are extracted to determine whether the operation event is necessary or not.
  • a criterion for determining necessity is estimated, and the extracted attribute value is used to determine whether the operation event to be processed is necessary or unnecessary. Therefore, in this process, unnecessary operation events can be easily removed by using the standard of common attribute values of the operation logs based on the selection operation of the image in the pre-processing of process mining.
  • the user is presented with the determination result of determining whether or not it is necessary, and by outputting the determination result approved by the user, it is possible to determine whether the operation event to be processed is necessary or unnecessary. judge. Therefore, in this process, unnecessary operation events can be easily and effectively removed in the pre-processing of process mining.
  • each component of each device shown in the drawings according to the above embodiment is functionally conceptual, and does not necessarily need to be physically configured as shown in the drawing.
  • the specific form of distribution and integration of each device is not limited to the one shown in the figure, and all or part of them can be functionally or physically distributed and integrated in arbitrary units according to various loads and usage conditions. Can be integrated and configured.
  • each processing function performed by each device may be implemented in whole or in part by a CPU and a program analyzed and executed by the CPU, or implemented as hardware based on wired logic.
  • ⁇ program ⁇ It is also possible to create a program in which the processing executed by the determination device 10 described in the above embodiment is described in a computer-executable language. In this case, the same effects as those of the above embodiments can be obtained by having the computer execute the program. Further, such a program may be recorded in a computer-readable recording medium, and the program recorded in this recording medium may be read by a computer and executed to realize processing similar to that of the above embodiments.
  • FIG. 11 is a diagram showing a computer that executes a program.
  • computer 1000 includes, for example, memory 1010, CPU 1020, hard disk drive interface 1030, disk drive interface 1040, serial port interface 1050, video adapter 1060, and network interface 1070. , and these units are connected by a bus 1080 .
  • the memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012, as illustrated in FIG.
  • the ROM 1011 stores a boot program such as BIOS (Basic Input Output System).
  • Hard disk drive interface 1030 is connected to hard disk drive 1090 as illustrated in FIG.
  • Disk drive interface 1040 is connected to disk drive 1100 as illustrated in FIG.
  • a removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100 .
  • the serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120, as illustrated in FIG.
  • Video adapter 1060 is connected to display 1130, for example, as illustrated in FIG.
  • the hard disk drive 1090 stores an OS 1091, application programs 1092, program modules 1093, and program data 1094, for example. That is, the above program is stored in, for example, the hard disk drive 1090 as a program module in which instructions to be executed by the computer 1000 are written.
  • the various data described in the above embodiments are stored as program data in the memory 1010 or the hard disk drive 1090, for example. Then, the CPU 1020 reads the program modules 1093 and program data 1094 stored in the memory 1010 and the hard disk drive 1090 to the RAM 1012 as necessary, and executes various processing procedures.
  • program module 1093 and program data 1094 related to the program are not limited to being stored in the hard disk drive 1090. For example, they may be stored in a removable storage medium and read by the CPU 1020 via a disk drive or the like. . Alternatively, the program module 1093 and program data 1094 related to the program are stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.), and via the network interface 1070 It may be read by CPU 1020 .
  • LAN Local Area Network
  • WAN Wide Area Network

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Software Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

判定装置（１０）は、操作イベントを受け付ける受付部（１５ａ）と、操作イベントに含まれる操作ログの属性値に基づいて、操作イベントの必要または不要を判定するための判定基準を推定する推定部（１５ｂ）と、判定基準に基づいて、処理対象の操作イベントに対して必要または不要を判定する判定部（１５ｃ）と、を備える。

Description

判定装置、判定方法および判定プログラム
　本発明は、判定装置、判定方法および判定プログラムに関する。
　従来、業務の改善点等を見つけるため、業務で行われる作業の流れを分析して可視化するプロセスマイニングの手法が知られている。このようなプロセスマイニングの手法において分析や可視化に使われる情報は、分析対象のイベントが記録されたログである。例えば、分析対象となるイベントは、業務の種類や分析したい粒度にもよって様々なものがあるが、例えば「ボタンのクリック」や「テキストボックスへの入力」などのＧＵＩ（Graphical　User　Interface）操作を対象とすることがある。
　プロセスマイニングに使われるログは、例えば、「分析対象の情報のみに絞られている」「案件ごとに分割されている」「イベントが識別できる状態になっている」の要件を満たしている必要がある。例えば、ＰＣ（Personal　Computer）上の操作を記録した操作ログでは、プロセスマイニングに使われるログの要件を満たしていない場合が多い。そのため、プロセスマイニングを行う際には、例えば、３つの事前処理「不要操作イベントの除去」「同一操作イベントの判定」「案件単位の分割」によってこの要件を満たすよう操作ログを加工する必要がある。
　ここで、「不要操作イベントの除去」処理とは、操作ログに含まれる不要な情報を除去する処理である。つまり、操作ログには、分析対象の作業に関係しない情報として不要な操作イベントも含まれてしまう場合がある。従来では、業務の改善点を見つけるためのＰＣ上の操作の分析・可視化においては、人間が目視で操作ログを確認し不要なイベントを１つずつ削除するなどして、不要な操作イベントを除去する処理を手作業で行っている。
横瀬、卜部、八木、他：DX推進に貢献する業務可視化技術、　2020年、ＮＴＴ技術ジャーナル、2020　vol.32　No.2,　p.72-75、[online]、［2021年4月23日検索］、インターネット＜https://journal.ntt.co.jp/article/880＞
　しかしながら、上述した従来技術では、プロセスマイニングの事前処理において、不要な操作イベントを容易に除去することができない。なぜならば、上述した従来技術には、以下のような課題があるためである。
　まず、不要なイベントを手作業で１つずつ除去することもできるが、ログの量が多い場合は全てを手作業で除去するのは困難である。
　一方、プロセスマイニングの分析対象のシステムは内部的な作りが違うため、固定的なルール・アルゴリズムでは自動的に除去する対象を判定することができない。また、上記システムの内部的な作りや作業に合わせてルール・アルゴリズムを手動でカスタマイズすることにより対応することもできるが、それには上記システムの内部的な作りや操作ログに含まれる属性値の意味を理解しなくてはいけないため、一般的なユーザには困難である。
　上述した課題を解決し、目的を達成するために、本発明に係る判定装置は、ログイベントを受け付ける受付部と、前記ログイベントに含まれるログの属性値に基づいて、前記ログイベントの必要または不要を判定するための判定基準を推定する推定部と、前記判定基準に基づいて、処理対象のログイベントに対して必要または不要を判定する判定部と、を備えることを特徴とする。
　また、本発明に係る判定方法は、判定装置によって実行される判定方法であって、ログイベントを受け付ける工程と、前記ログイベントに含まれるログの属性値に基づいて、前記ログイベントの必要または不要を判定するための判定基準を推定する工程と、前記判定基準に基づいて、処理対象のログイベントに対して必要または不要を判定する工程と、を含むことを特徴とする。
　また、本発明に係る判定プログラムは、ログイベントを受け付けるステップと、前記ログイベントに含まれるログの属性値に基づいて、前記ログイベントの必要または不要を判定するための判定基準を推定するステップと、前記判定基準に基づいて、処理対象のログイベントに対して必要または不要を判定するステップと、をコンピュータに実行させることを特徴とする。
　本発明では、プロセスマイニングの事前処理において、不要な操作イベントを容易に除去することができる。
図１は、第１の実施形態に係る判定装置の構成例を示すブロック図である。 図２は、第１の実施形態に係る記憶部に記憶されたログを示す図である。 図３は、第１の実施形態に係る操作イベントの選択による例示の受付処理の一例を示す図である。 図４は、第１の実施形態に係る属性要素ごとのルール種別の一例を示す図である。 図５は、第１の実施形態に係る判定基準の推定処理の一例を示す図である。 図６は、第１の実施形態に係る操作イベント判定処理の一例を示す図である。 図７は、第１の実施形態に係る処理全体の流れの一例を示すフローチャートである。 図８は、プロセスマイニングについて説明する図である。 図９は、プロセスマイニングの事前処理について説明する図である。 図１０は、従来の課題について説明する図である。 図１１は、プログラムを実行するコンピュータを示す図である。
　以下に、本発明に係る判定装置、判定方法および判定プログラムの実施形態を図面に基づいて詳細に説明する。なお、本発明は、以下に説明する実施形態により限定されるものではない。
〔第１の実施形態〕
　以下に、第１の実施形態（適宜、本実施形態）に係る判定システムの処理、判定装置１０の構成、各処理の詳細、各処理の流れを順に説明し、最後に本実施形態の効果を説明する。
［判定システムの処理］
　以下に、本実施形態に係る判定システム（適宜、本システム）の処理を説明する。本システムは、ＰＣ上の操作を記録した操作ログの処理に関して利用され、特に、ユーザの例示による不要操作イベントの自動判定処理を実行する。以下では、本システムの処理を従来の技術と比較しながら説明する。
　上述した、業務分析のためのプロセスマイニングの手法は市中で広く使われている。また、ＰＣ上の操作をログ（操作ログ）として記録する仕組みも存在する。このとき、操作ログをプロセスマイニングするには事前処理が必要になる場合がある。すなわち、操作ログをありのまま記録すると、プロセスマイニング対象以外のイベントも含まれてしまうため、不要なイベントを除去する必要がある。また、不要なイベントを手作業で１つずつ除去することもできるが、ログの量が多い場合は全てを手作業で除去するのは困難である。
　一方、プロセスマイニングの分析対象のシステムは内部的な作りが違うため、固定的なルール・アルゴリズムでは自動的に除去する対象を判定することができない。また、上記システムの内部的な作りや作業に合わせてルール・アルゴリズムを手動でカスタマイズすることにより対応することもできるが、それには上記システムの内部的な作りや操作ログに含まれる属性値の意味を理解しなくてはいけない。
　そこで、本システムでは、以下のような処理を実行する。第１に、ユーザに残したい／除去したい操作イベントを複数個例示させる。第２に、例示された操作イベント間の属性値の関係性から、残したい／除去したい操作イベントを判定するためのルールを推定する。第３に、推定されたルールを使って残したい／除去したい操作イベントを自動的に判定する。以上の処理により、分析対象のシステム内部の作りや操作ログの属性値の深い理解がなくても、ユーザの例示により、不要操作の除去が自動的にできるようになる。
［判定装置１０の構成］
　図１を用いて、本実施形態に係る判定装置１０の構成を詳細に説明する。図１は、本実施形態に係る判定装置の構成例を示すブロック図である。判定装置１０は、入力部１１、出力部１２、通信部１３、記憶部１４および制御部１５を有する。
　入力部１１は、当該判定装置１０への各種情報の入力を司る。例えば、入力部１１は、マウスやキーボード等で実現され、当該判定装置１０への設定情報等の入力を受け付ける。また、出力部１２は、当該判定装置１０からの各種情報の出力を司る。例えば、出力部１２は、ディスプレイ等で実現され、当該判定装置１０に記憶された設定情報等を出力する。
　通信部１３は、他の装置との間でのデータ通信を司る。例えば、通信部１３は、各通信装置との間でデータ通信を行う。また、通信部１３は、図示しないオペレータの端末との間でデータ通信を行うことができる。
　記憶部１４は、制御部１５が動作する際に参照する各種情報や、制御部１５が動作した際に取得した各種情報を記憶する。ここで、記憶部１４は、例えば、ＲＡＭ（Random　Access　Memory）、フラッシュメモリ等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置等で実現され得る。なお、図１の例では、記憶部１４は、判定装置１０の内部に設置されているが、判定装置１０の外部に設置されてもよいし、複数の記憶部が設置されていてもよい。
　記憶部１４は、処理対象の操作ログを記憶する。例えば、記憶部１４は、操作ログとして、操作の「発生時刻」「操作されたＧＵＩ部品の固有情報」等を記憶する。また、操作ログは、１つの操作イベントの情報は複数の属性値（列、項目）の集まりとして表現される。
　ここで図２を用いて、記憶部１４に記憶された操作ログについて説明する。図２は、第１の実施形態に係る記憶部に記憶されたログを示す図である。図２の例では、例を簡潔にするためブラウザ上の操作のみを記録した操作ログを想定している。そのため、ログの属性値にはブラウザに関連するもののみを示している。
　なお、操作ログには、ＰＣ上のＧＵＩ操作に加えて、何らかの入力装置による入力を記録したり、ＣＵＩ（Character-based　User　Interface）上のコマンド入力を記録したりしてもよい。それらの別種の操作を記録する場合は、必要に応じてログの項目を増やす必要がある。
　図２に例示するように、記憶部１４は、「日時」、「操作種別」、「ＵＲＬ」、「タイトル」、「ｔａｇＮａｍｅ」、「ｔｙｐｅ」、「ｉｄ」、「ｖａｌｕｅ」、「ｎａｍｅ」、「ｃｌａｓｓＮａｍｅ」、「ｌｅｆｔ」、「ｔｏｐ」、「ｗｉｄｔｈ」、「ｈｅｉｇｈｔ」を記憶する。なお、記憶部１４は、記憶する操作ログとして上述したものに限定されるものではなく、例えば、操作時の画像キャプチャ等も記憶してもよい。
　図２の例では、記憶部１４は、その項目が設定されていない場合や取得できない場合は、その値が設定されていないことを示す「ｎｕｌｌ」値が記憶される。なお、操作ログに含まれる属性要素は直接取得した情報そのものである必要はなく、加工されていたり、複数の情報を組み合わせていたり、最終的に操作ログに含まれない情報を利用して加工されていたりしてもよい。また、記憶部１４は、作業の中で発生したイベントの順番が分かるように、イベントの時系列順に操作ログを記憶する。
　制御部１５は、当該判定装置１０全体の制御を司る。制御部１５は、受付部１５ａ、推定部１５ｂおよび判定部１５ｃを有する。ここで、制御部１５は、例えば、ＣＰＵ（Central　Processing　Unit）やＭＰＵ（Micro　Processing　Unit）等の電子回路やＡＳＩＣ（Application　Specific　Integrated　Circuit）やＦＰＧＡ（Field　Programmable　Gate　Array）等の集積回路である。
（受付部１５ａ）
　受付部１５ａは、ログイベントとして、操作イベントを受け付ける。例えば、受付部１５ａは、複数の操作イベントの画像のうち、ユーザによって選択された操作イベントの画像を受け付ける。すなわち、受付部１５ａは、時系列順に表示された複数の操作イベントのキャプチャ画像のうち、ユーザによって必要選択または不要選択された複数のキャプチャ画像を受け付ける。ここで、ログイベントとは、操作イベントの他、同様の構造を持つログを含むイベント（例えば、電話の受信発信履歴等）である。
　具体例を用いて説明すると、受付部１５ａは、ユーザの端末の画面に時系列でビジュアル表示されたキャプチャ画像をユーザのクリック操作によって、「必要選択」すなわち、残したい操作イベントとして複数選択された場合、選択されたキャプチャ画像と紐づけされた操作イベントの操作ログを「必要な操作ログ」として受け付ける。一方、受付部１５ａは、ユーザの端末の画面に時系列でビジュアル表示されたキャプチャ画像をユーザのクリック操作によって、「不要選択」すなわち、除去したい操作イベントとして複数選択された場合、選択されたキャプチャ画像と紐づけされた操作イベントの操作ログを「不要な操作ログ」として受け付ける。なお、上記の受付処理については、後述する［各処理の詳細］（１．操作イベントの選択による例示の受付処理）においても詳細に説明する。
　また、受付部１５ａは、記憶部１４に記憶された操作ログを参照し、選択された操作ログを取得する。一方、受付部１５ａは、選択された操作ログの集合を推定部１５ｂに出力する。なお、受付部１５ａは、選択された操作ログの集合を記憶部１４に格納してもよい。
（推定部１５ｂ）
　推定部１５ｂは、ログイベントとして、操作イベントに含まれる操作ログの属性値に基づいて、操作イベントの必要または不要を判定するための判定基準（ルール）を推定する。例えば、推定部１５ｂは、操作ログの共通する属性値を抽出することによって、操作イベントの必要または不要を判定するための判定基準を推定する。すなわち、推定部１５ｂは、属性の要素（属性要素）ごとに設定された条件（ルール種別）にしたがって属性の要素に共通して含まれる文字列または数値範囲を抽出することによって、操作イベントの必要または不要を判定するための判定基準を推定する。
　具体例を用いて説明すると、推定部１５ｂは、受付部１５ａによって「必要選択」である操作イベントして受け付けられた複数の操作ログにおいて、属性要素「タイトル」（ルール種別Ｂ：部分一致で文字列を判定する）の属性値として、全てに共通する文字列「経路検索」が含まれている場合、属性要素「タイトル」に文字列「経路検索」を含む操作イベントを、残したい操作イベントの判定基準として推測する。なお、上記の推定処理については、後述する［各処理の詳細］（４．各属性値のルールの推定処理）においても詳細に説明する。
　また、推定部１５ｂは、受付部１５ａによって出力された操作ログの集合と、記憶部１４に記憶された属性値のルール種別とを取得し、共通して含まれる文字列または数値範囲を判定基準として抽出する。一方、推定部１５ｂは、抽出した判定基準を判定部１５ｃに出力する。なお、推定部１５ｂは、抽出した判定基準を記憶部１４に格納してもよい。
（判定部１５ｃ）
　判定部１５ｃは、判定基準に基づいて、処理対象のログイベントとして、処理対象の操作イベントに対して必要または不要を判定する。例えば、判定部１５ｃは、抽出された属性値を用いて、処理対象の操作イベントに対して必要または不要を判定する。すなわち、判定部１５ｃは、属性の要素に共通して含まれる文字列を含む操作イベント、または属性の要素に共通して含まれる数値範囲を満たす操作イベントをマッチングすることによって、処理対象の操作イベントに対して必要または不要を判定する。
　具体例を用いて説明すると、判定部１５ｃは、属性要素「タイトル」に文字列「経路検索」を含むことが残したい操作イベントの判定基準として推定された場合、ユーザによって選択されなかった操作イベントから属性要素「タイトル」に文字列「経路検索」が含まれるものを検索し、検索された操作イベントを判定結果として出力する。一方、判定部１５ｃは、上記以外の判定基準が存在しない場合、残したい操作イベントから外れた操作イベントを除去したい操作イベントとして出力する。なお、上記の判定処理については、後述する［各処理の詳細］（５．操作イベントの判定処理）においても詳細に説明する。
　また、判定部１５ｃは、出力した判定結果を出力部１２に送信する。なお、判定部１５ｃは、出力した判定結果を記憶部１４に格納してもよい。
　加えて、判定部１５ｃは、必要または不要を判定した判定結果をユーザに提示し、ユーザによって承認された判定結果を出力することによって、処理対象の操作イベントに対して必要または不要を判定する。
　具体例を用いて説明すると、判定部１５ｃは、属性要素「タイトル」に文字列「経路検索」を含むものを残したい操作イベントとして複数のビジュアル画像で出力した場合、ユーザのクリック操作によってビジュアル画像を選択された操作イベントを、確定した判定結果として再度出力する。なお、上記の推定処理については、後述する［各処理の詳細］（６．ユーザとの対話による判定処理）においても詳細に説明する。
［各処理の詳細］
　図３～図６や数式等を用いて、本実施形態に係る各処理の詳細を説明する。以下では、操作イベントの選択による例示の受付処理、各属性値のルール種別、ルールの詳細およびルールの推定処理、操作イベントの判定処理について詳細に説明する。
（１．操作イベントの選択による例示の受付処理）
　図３を用いて、操作イベントの選択による例示を受け付ける処理について説明する。図３は、第１の実施形態に係る操作イベントの選択による例示の受付処理の一例を示す図である。
　まず、ユーザに、残したい操作イベントまたは除去したい操作イベントを例示として複数選択させる。例えば、図３のように操作イベントを時系列でビジュアルに表示し、ユーザに選択させるとよい。図３では、１つの操作イベントが１つのノードとして表示されていて、そのノードには操作イベントの記録と同時に記録したキャプチャ画像を表示し、その画像上に操作位置を太枠で表示している。このように表示することで、ユーザは操作ログに記録された内容を理解しなくても、各操作イベントが具体的にどの操作かを認識することができる。
　そして、判定装置１０は、ユーザが選択した操作イベント（図３下段の破線枠）を、ユーザの例示として受け付ける。なお、図３では残したい、すなわち必要な操作イベントの例を説明しているが、除去したい、すなわち不要な操作イベントを選択することもできる。
（２．各属性値のルール種別）
　図４を用いて、各属性値のルール種別について説明する。図４は、第１の実施形態に係る各属性値のルール種別の一例を示す図である。
　判定装置１０は、操作イベントの各属性値の性質に合わせて、図４にも示す下記の４種のルールを適用する。第１のルールは、「完全一致で文字列を判定する」（ルール種別Ａ）であり、第２のルールは、「部分一致で文字列を判定する」（ルール種別Ｂ）であり、第３のルールは、「数値の範囲で判定する」（ルール種別Ｃ）であり、第４のルールは、「判定に利用しない」（ルール種別Ｄ）である。
　ユーザは、図４のように、属性要素と利用するルール種別を事前に結び付けておく。例えば、図４では、「操作種別」、「ｔａｇＮａｍｅ」、「ｔｙｐｅ」、「ｉｄ」、「ｎａｍｅ」の属性要素にはルール種別Ａを適用し、「ＵＲＬ」、「タイトル」の属性要素にはルール種別Ｂを適用し、「ｗｉｄｔｈ」、「ｈｅｉｇｈｔ」の属性要素にはルール種別Ｃを適用し、「日時」、「ｖａｌｕｅ」、「ｃｌａｓｓＮａｍｅ」、「ｌｅｆｔ」、「ｔｏｐ」の属性要素にはルール種別Ｄを適用している。なお、ユーザは、上記の４種のルールの一部を使わなかったり、他の種類のルールを追加したりしてもよい。
（３．各属性値のルールの詳細）
　ルールの推定処理に先立って、上記の各属性値のルールの詳細を説明する。以下では、完全一致で判定する文字列（ルールの詳細１）、部分一致で判定する文字列（ルールの詳細２）、数値の範囲で判定する項目（ルールの詳細３）の順に説明する。
（ルールの詳細１：完全一致で判定する文字列）
　第１に、完全一致で文字列を判定するルール（ルール種別Ａ）の詳細について説明する。以下では、ルール種別Ａを適用したルールの推定処理、ルールのマッチング処理の順について説明する。
（ルールの推定処理）
　判定装置１０は、例示された複数の操作イベントにおいて、全ての属性値が完全一致しない場合は、該当の属性要素について本ルールを不採用とする。一方、判定装置１０は、例示された複数の操作イベントにおいて、全ての属性値で完全一致している文字列を本ルールのパラメータとする。また、大文字／小文字を区別しなくてよい場合は、パラメータを大文字または小文字に変換し統一しておく。なお、例示された複数の操作イベントにおいて、全ての属性値が「ｎｕｌｌ」である場合も、該当の属性要素について本ルールを採用する。
（ルールのマッチング処理）
　判定装置１０は、検査対象の操作イベントの該当の属性値が、上記のルールの推定処理で見つけた文字列と完全一致する場合は、本ルールがマッチ（一致した）とする。また、判定装置１０は、大文字／小文字を区別しなくてよい場合は、パラメータと同様に該当の属性値を大文字または小文字に変換した値で比較を行う。
（ルールの詳細２：部分一致で判定する文字列）
　第２に、部分一致で文字列を判定するルール（ルール種別Ｂ）の詳細について説明する。以下では、ルール種別Ｂを適用したルールの推定処理、ルールのマッチング処理の順について説明する。
（ルールの推定処理）
　判定装置１０は、例示された複数の操作イベントにおいて、該当の属性値に「ｎｕｌｌ」が含まれている場合は、該当の属性要素について本ルールを不採用とする。一方、判定装置１０は、例示された複数の操作イベントにおいて、共通する部分文字列を見つける。このとき、判定装置１０は、最も単純な仕組みでは、全てのイベントに共通して含まれる最長の共通部分文字列を見つけ、これを本ルールのパラメータとする。
　また、判定装置１０は、共通部分文字列が閾値文字数以下の場合は、本ルールを不採用とする。この閾値は任意に設定できるが、例えばＵＲＬであれば先頭の「ｈｔｔｐ：／／」や「ｈｔｔｐｓ：／／」の部分が必ず共通するため、これを超えるように８文字以下では不採用とするようにすればよい。なお、より高度にするには、「前方一致」「後方一致」「部分一致」「完全一致」の真偽についての情報も考慮したり、共通部分を複数考慮するようにしたり、文字列長を考慮するようにしてもよい。
（ルールのマッチング処理）
　判定装置１０は、検査対象の操作イベントの該当の属性値が、上記のルールの推定処理で見つけた共通部分文字列を含む場合は、本ルールがマッチ（一致した）とする。
（ルールの詳細３：数値の範囲で判定する項目）
　第３に、数値の範囲で判定するルール（ルール種別Ｃ）の詳細について説明する。以下では、ルール種別Ｃを適用したルールの推定処理、ルールのマッチング処理の順について説明する。
（ルールの推定処理）
　判定装置１０は、例示された複数の操作イベントにおいて、「該当の属性値にｎｕｌｌが含まれている場合」「該当の属性値に数値として取り扱えない値が含まれている場合」「該当の属性値にその他の異常な値が含まれている場合（例：横幅（ｗｉｄｔｈ）がマイナスの値）」は、該当の属性要素について本ルールを不採用とする。
　また、判定装置１０は、例示された複数の操作イベントにおいて、平均μと標準偏差σを算出し、これを本ルールのパラメータとする。このとき、判定装置１０は、標準偏差σが一定の閾値以上の場合や、十分な数が例示されない場合（１つだけしか例示されない）は、本ルールを不採用としてよい。例えば、閾値を３０として、３０以上の場合はばらつきが大きく共通性がほとんどないとみなして不採用とする。
（ルールのマッチング処理）
　判定装置１０は、検査対象の操作イベントの該当の属性値が、μ－ｋσ≦属性値≦μ＋ｋσの範囲にある場合は、本ルールがマッチ（一致した）とする。ここで、ｋは定数であり、任意に決定する。また、値のばらつきが正規分布に従うと仮定する場合は、一般的にｋ＝３（９９．７％の範囲）とするとよい。
（４．各属性値のルールの推定処理）
　図５を用いて、各属性値のルールを推定する処理の詳細について説明する。図５は、第１の実施形態に係る判定基準の推定処理の一例を示す図である。判定装置１０は、以下のように、例示された複数の操作イベントの操作ログデータに対して、属性要素ごとにルールの推定を行う。図５では、例示された４つの操作イベントの操作ログが示されている。
　まず、判定装置１０は、属性要素ごとに事前に設定されたルール種別にしたがい、各属性要素に対して「採用」または「不採用」を決定する。次に、判定装置１０は、「採用」と決定された属性要素の属性値からパラメータを抽出する。そして、判定装置１０は、抽出したパラメータを当該属性要素に対応するルールとして推定する。
　図５の例では、判定装置１０は、属性要素「ＵＲＬ」（ルール種別Ｂ：部分一致で文字列を判定する）の属性値として、共通する文字列「http://www.sample.jp/transit/」が含まれているので、当該属性要素を「採用」と決定し、「http://www.sample.jp/transit/」を文字列として含むことをパラメータとして抽出する。また、判定装置１０は、属性要素「タイトル」（ルール種別Ｂ：部分一致で文字列を判定する）の属性値として、共通する文字列「経路検索」が含まれているので、当該属性要素を「採用」と決定し、「経路検索」を文字列として含むことをパラメータとして抽出する。
（５．操作イベントの判定処理）
　図６を用いて、推定されたルールから操作イベントを判定する処理の詳細について説明する。図６は、第１の実施形態に係る操作イベント判定処理の一例を示す図である。判定装置１０は、以下のように、推定されたルールを用いて、例示された操作イベント以外の操作イベントに対して、ルールのチェックを行い、残す／除去する操作イベントを判定する。図６では、推定されたルールに該当しない操作イベントを除去している。
　図６の例では、判定装置１０は、「残す操作イベントとして例示された群」（図６（１）参照）から推定されたルール（例：属性要素「ＵＲＬ」に文字列「http://www.sample.jp/transit/」が含まれる、属性要素「タイトル」に文字列「経路検索」が含まれる）を用いて、「残す操作イベントから外れた群（除去される操作イベント群）」（図６（２）参照）、「残す操作イベントとして自動判定された群」（図６（３）参照）を判定する。
（６．ユーザとの対話による判定処理）
　以下では、ユーザとの対話による操作イベントを判定する処理の詳細について説明する。判定装置１０は、上述した例示された操作イベントの数が少なかったり、例示された操作イベントの多様性が不十分であったりする場合等、残す／除去する操作イベントを正しく判定できない場合がある。そのため、判定装置１０は、判定結果を即座に確定するのではなく、判定された操作イベントをユーザに仮で示し、ユーザに確認を取ってから残す／除去する操作イベントの判定結果を確定させることもできる。すなわち、判定装置１０は、提示した判定結果がユーザによって不適切と判断された場合は、いったん仮の判定結果を取り消し、例示を増やすようにユーザに促すこともできる。
　このような対話的なやり取りによって、徐々に例示数を増やすようにすることで、より効率的にユーザに例示させることができる。さらに、設定されている各種閾値や、推定により採用されたルールのＯＮ／ＯＦＦを許すようなＵＩ（User　Interface）を提供することで、より高度なユーザの要求に応えることもできる。
［各処理の流れ］
　図７を用いて、本実施形態に係る各処理の流れを詳細に説明する。図７は、第１の実施形態に係る処理全体の流れの一例を示すフローチャートである。以下では、判定処理全体の流れを示すとともに、各処理の概要を説明する。
（処理全体の流れ）
　まず、判定装置１０の受付部１５ａは、操作イベント選択受付処理を実行する（ステップＳ１０１）。次に、判定装置１０の推定部１５ｂは、判定ルール推定処理を実行する（ステップＳ１０２）。そして、推定装置１０の判定部１５ｃは、操作イベント判定処理を実行し（ステップＳ１０３）、処理を終了する。なお、下記のステップＳ１０１～Ｓ１０３は、異なる順序で実行することもできる。また、下記のステップＳ１０１～Ｓ１０３のうち、省略される処理があってもよい。
（各処理の流れ）
　第１に、受付部１５ａによる操作イベント選択受付処理について説明する。この処理では、ユーザに、残したい操作イベントまたは除去したい操作イベントを例示として複数選択させ、選択された操作イベントの操作ログを受け付ける。このとき、操作イベントを時系列でビジュアルに表示し、ユーザに選択させることにより、ユーザは操作ログに記録された内容を理解しなくても、各操作イベントが具体的にどの操作かを認識することができる。
　第２に、推定部１５ｂによる判定ルール推定処理について説明する。この処理では、選択を受け付けた操作イベントの属性要素ごとに事前に設定されたルール種別にしたがい、各属性要素に対して「採用」または「不採用」を決定し、「採用」と決定された属性要素の属性値からパラメータを抽出し、抽出したパラメータを当該属性要素に対応するルールとして推定する。このとき、属性要素と利用するルール種別を事前に結び付けておくことで、選択した操作イベントの判定ルールを効果的に推定することができる。
　第３に、判定部１５ｃによる判定ルール推定処理について説明する。この処理では、推定された判定ルールを用いて、例示された操作イベント以外の操作イベントに対して、ルールのチェックを行い、残す／除去する操作イベントを判定する。このとき、判定結果を即座に確定するのではなく、判定された操作イベントをユーザに仮で示し、ユーザに確認を取ってから残す／除去する操作イベントの判定結果を確定させることで、対話的なやり取りによって徐々に例示数を増やすようにユーザに促すことができ、容易かつ効果的に残す／除去する操作イベントを判定することができる。
［第１の実施形態の効果］
　まず、上述した本実施形態に係る判定処理では、操作イベントを受け付け、操作イベントに含まれる操作ログの属性値に基づいて、操作イベントの必要または不要を判定するための判定基準を推定し、推定した判定基準に基づいて、処理対象の操作イベントに対して必要または不要を判定する。このため、本処理では、プロセスマイニングの事前処理において、不要な操作イベントを容易に除去することができる。
　ここで、プロセスマイニングについて説明する。プロセスマイニングでは、図８に例示するように、イベントの順番や関係性を可視化することで、業務で行われる作業の流れを分析することができる。図８は、プロセスマイニングについて説明する図である。
　このようなプロセスマイニングでは、図９に示すように、プロセスマイニングを行う際には、例えば、事前処理として、「不要操作イベントの除去」「同一操作イベントの判定」「案件単位の分割」を必要がある。図９は、プロセスマイニングの事前処理について説明する図である。
　従来では、このような事前処理を手動で行う。例えば、このような事前処理を手動で行う際に、図１０に示すように、現場のユーザは画面キャプチャから直感的に例示可能だが、操作ログを処理するのは容易ではない場合がある。図１０は、従来の課題について説明する図である。例えば、操作ログで記録されている属性値は、解釈に専門的な知識が必要である。例えば、ブラウザ上の操作を記録した操作ログの意味を解釈するには、ＨＴＭＬ（Hyper　Text　Markup　Language）やＤＯＭの知識が必要となる。また、ＵＲＬ等は、同一のページであっても完全に同一にならない場合がある。また、例えば、セッションＩＤを含む場合には、ログインするたびにＵＲＬの一部が変化してしまうため、ＵＲＬの同一性を判断するにはＵＲＬの生成ルールを推測する必要がある。
　このように、画面内の見た目と内部的な作り（ＩＤの付与方法など）に関連性はないため、一般的なユーザでも判断できるような見た目が類似性からでは内部の作りを推測することはできない。画面内の内部的な作りは様々であるため、一定のアルゴリズムでは常に最良の判断を行うことはできない。専門的な知識を持つユーザが操作ログの傾向からルールを推定して、アルゴリズムを組むことで様々な画面の作りに対応可能であるが、一般的なユーザには困難である。
　このため、操作ログの案件単位の分割を手作業で行う場合、作業者にシステム内部の作りや操作ログの属性値の意味の理解を要し、さらに大量のログを扱うには大きな稼働を要し、また、固定的なルール・アルゴリズムでは、システムは内部的な作りが違うため、案件単位になるように自動的に操作ログを分割することは難しいという課題があった。これに対して、本実施形態に係る判定処理では、プロセスマイニングの事前処理において、不要な操作イベントを容易に除去することができる。また、以下では、さらに、本実施形態に係る判定処理で実現可能な効果について説明する。
　上述した本実施形態に係る判定処理では、複数の操作イベントの画像のうち、ユーザによって選択された操作イベントの画像を受け付け、操作ログの共通する属性値を抽出することによって、操作イベントの必要または不要を判定するための判定基準を推定し、抽出された属性値を用いて、処理対象の操作イベントに対して必要または不要を判定する。このため、本処理では、プロセスマイニングの事前処理において、画像の選択操作をもとに操作ログの共通する属性値の基準を利用することによって、不要な操作イベントを容易に除去することができる。
　上述した本実施形態に係る判定処理では、時系列順に表示された複数の操作イベントのキャプチャ画像のうち、ユーザによって必要選択または不要選択された複数のキャプチャ画像を受け付け、属性の要素ごとに設定された条件にしたがって属性の要素に共通して含まれる文字列または数値範囲を抽出することによって、判定基準を推定し、当該文字列を含む操作イベント、または当該数値範囲を満たす操作イベントをマッチングすることによって、処理対象の操作イベントに対して必要または不要を判定する。このため、本処理では、プロセスマイニングの事前処理において、属性の要素ごとに設定された条件にしたがい、画像の操作をもとに操作ログの共通する属性値を利用することによって、不要な操作イベントを容易に除去することができる。
　上述した本実施形態に係る判定処理では、必要または不要を判定した判定結果をユーザに提示し、ユーザによって承認された判定結果を出力することによって、処理対象の操作イベントに対して必要または不要を判定する。このため、本処理では、プロセスマイニングの事前処理において、不要な操作イベントを容易に、より効果的に除去することができる。
〔システム構成等〕
　上記実施形態に係る図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示のごとく構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
　また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
〔プログラム〕
　また、上記実施形態において説明した判定装置１０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。この場合、コンピュータがプログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。
　図１１は、プログラムを実行するコンピュータを示す図である。図１１に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。
　メモリ１０１０は、図１１に例示するように、ＲＯＭ（Read　Only　Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図１１に例示するように、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、図１１に例示するように、ディスクドライブ１１００に接続される。例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、図１１に例示するように、例えば、マウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、図１１に例示するように、例えばディスプレイ１１３０に接続される。
　ここで、図１１に例示するように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記のプログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えば、ハードディスクドライブ１０９０に記憶される。
　また、上記実施形態で説明した各種データは、プログラムデータとして、例えば、メモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、各種処理手順を実行する。
　なお、プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local　Area　Network）、ＷＡＮ（Wide　Area　Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
　上記の実施形態やその変形は、本願が開示する技術に含まれると同様に、請求の範囲に記載された発明とその均等の範囲に含まれるものである。
　１０　判定装置
　１１　入力部
　１２　出力部
　１３　通信部
　１４　記憶部
　１５　制御部
　１５ａ　受付部
　１５ｂ　推定部
　１５ｃ　判定部

Claims (6)

  1. 　ログイベントを受け付ける受付部と、
    　前記ログイベントに含まれるログの属性値に基づいて、前記ログイベントの必要または不要を判定するための判定基準を推定する推定部と、
    　前記判定基準に基づいて、処理対象のログイベントに対して必要または不要を判定する判定部と、
    　を備えることを特徴とする判定装置。
  2. 　前記受付部は、前記ログイベントとして、複数の操作イベントの画像のうち、ユーザによって選択された操作イベントの画像を受け付け、
    　前記推定部は、前記ログとして操作ログの共通する前記属性値を抽出することによって、前記判定基準を推定し、
    　前記判定部は、抽出された前記属性値を用いて、前記処理対象の操作イベントに対して必要または不要を判定する、
    　ことを特徴とする請求項１に記載の判定装置。
  3. 　前記受付部は、時系列順に表示された複数の操作イベントのキャプチャ画像のうち、前記ユーザによって必要選択または不要選択された複数の前記キャプチャ画像を受け付け、
    　前記推定部は、属性の要素ごとに設定された条件にしたがって前記属性の要素に共通して含まれる文字列または数値範囲を抽出することによって、前記判定基準を推定し、
    　前記判定部は、前記文字列を含む操作イベント、または前記数値範囲を満たす操作イベントをマッチングすることによって、前記処理対象の操作イベントに対して必要または不要を判定する、
    　ことを特徴とする請求項２に記載の判定装置。
  4. 　前記判定部は、必要または不要を判定した判定結果を前記ユーザに提示し、前記ユーザによって承認された前記判定結果を出力することによって、前記処理対象の操作イベントに対して必要または不要を判定する、
    　ことを特徴とする請求項３に記載の判定装置。
  5. 　判定装置によって実行される判定方法であって、
    　ログイベントを受け付ける工程と、
    　前記ログイベントに含まれるログの属性値に基づいて、前記ログイベントの必要または不要を判定するための判定基準を推定する工程と、
    　前記判定基準に基づいて、処理対象のログイベントに対して必要または不要を判定する工程と、
    　を含むことを特徴とする判定方法。
  6. 　ログイベントを受け付けるステップと、
    　前記ログイベントに含まれるログの属性値に基づいて、前記ログイベントの必要または不要を判定するための判定基準を推定するステップと、
    　前記判定基準に基づいて、処理対象のログイベントに対して必要または不要を判定するステップと、
    　をコンピュータに実行させることを特徴とする判定プログラム。
PCT/JP2021/022416 2021-06-11 2021-06-11 判定装置、判定方法および判定プログラム WO2022259557A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2023526835A JPWO2022259557A1 (ja) 2021-06-11 2021-06-11
US18/568,383 US20240281353A1 (en) 2021-06-11 2021-06-11 Determination device, determination method, and determination program
PCT/JP2021/022416 WO2022259557A1 (ja) 2021-06-11 2021-06-11 判定装置、判定方法および判定プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/022416 WO2022259557A1 (ja) 2021-06-11 2021-06-11 判定装置、判定方法および判定プログラム

Publications (1)

Publication Number Publication Date
WO2022259557A1 true WO2022259557A1 (ja) 2022-12-15

Family

ID=84424534

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/022416 WO2022259557A1 (ja) 2021-06-11 2021-06-11 判定装置、判定方法および判定プログラム

Country Status (3)

Country Link
US (1) US20240281353A1 (ja)
JP (1) JPWO2022259557A1 (ja)
WO (1) WO2022259557A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007317130A (ja) * 2006-05-29 2007-12-06 Nippon Telegr & Teleph Corp <Ntt> 情報処理装置及びプログラム
WO2020235085A1 (ja) * 2019-05-23 2020-11-26 日本電信電話株式会社 操作ログ可視化装置、操作ログ可視化方法および操作ログ可視化プログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007317130A (ja) * 2006-05-29 2007-12-06 Nippon Telegr & Teleph Corp <Ntt> 情報処理装置及びプログラム
WO2020235085A1 (ja) * 2019-05-23 2020-11-26 日本電信電話株式会社 操作ログ可視化装置、操作ログ可視化方法および操作ログ可視化プログラム

Also Published As

Publication number Publication date
US20240281353A1 (en) 2024-08-22
JPWO2022259557A1 (ja) 2022-12-15

Similar Documents

Publication Publication Date Title
JP4772378B2 (ja) Ｗｅｂページから時系列データを生成する方法及び装置
US10789366B2 (en) Security information management system and security information management method
US9009850B2 (en) Database management by analyzing usage of database fields
WO2020155750A1 (zh) 基于人工智能的语料收集方法、装置、设备及存储介质
CN106415507A (zh) 日志分析装置、攻击检测装置、攻击检测方法以及程序
US8930447B2 (en) Method, apparatus, and program for usability analysis of web applications
US20120150825A1 (en) Cleansing a Database System to Improve Data Quality
US9542474B2 (en) Forensic system, forensic method, and forensic program
CN110750707A (zh) 关键词推荐方法、装置和电子设备
CN107357794A (zh) 优化键值数据库的数据存储结构的方法和装置
CN112508432B (zh) 广告潜在风险检测方法及装置、电子设备、介质和产品
JP6684970B1 (ja) 分析プログラム、分析方法および分析装置
KR20110035001A (ko) 키워드 시각화 장치 및 그 방법
CN112231696B (zh) 恶意样本的识别方法、装置、计算设备以及介质
EP3564833B1 (en) Method and device for identifying main picture in web page
WO2022259557A1 (ja) 判定装置、判定方法および判定プログラム
WO2022259558A1 (ja) 判定装置、判定方法および判定プログラム
WO2022259559A1 (ja) 判定装置、判定方法および判定プログラム
JP2017167829A (ja) 検出装置、検出方法及び検出プログラム
US20160162639A1 (en) Digital image analysis and classification
US10438695B1 (en) Semi-automated clustered case resolution system
US20170322970A1 (en) Data organizing and display for dynamic collaboration
CN113221035A (zh) 用于确定异常网页的方法、装置、设备、介质和程序产品
JP5839437B2 (ja) 時系列データ分析装置、時系列データ分析方法、及びプログラム
CN111291186A (zh) 一种基于聚类算法的上下文挖掘方法、装置和电子设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21945226

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023526835

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 18568383

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21945226

Country of ref document: EP

Kind code of ref document: A1