JP6705947B2 - 運用支援システム及び方法 - Google Patents

Description

本発明は、概して、計算機システム、アプリケーション、及びサービスといった対象の運用を支援するための技術に関する。

運用対象として、例えば、計算機システムがある。計算機システムの運用では、レスポンスタイムなどの性能値や、ダウンタイムなどの条件を事前に定義しておき、この条件を満たす様に運用を行うことが多い。

そのため、異常状態に迅速に対処することが必要となるが、異常状態となるタイミングを予期することは困難である。また、サーバなどの大量のシステムリソースの状態を個別に常に監視することは現実的ではない。そのため、性能値がしきい値を下回ったタイミングや、エラーがログに出力されたタイミングなど、計算機システムが特定の状態となることをトリガーとして、イベントを発行することが行われている。運用管理者は、イベントを監視することで計算機システムの状態を把握することができ、異常を迅速に検知することが可能となる。

一方で、異常の内容や、異常が発生した箇所に応じて適切な対応を行うためには、情報技術の知識と、運用対象の計算機システムに関する知識が必要であり、高度なスキルセットが必要となる。このような高度なスキルセットを持つ人材は希少であり、イベントを監視し、計算機システムを安全に運用するために十分な人数を確保することが難しい。

そのため、一般に、高度なスキルセットを持つ人材（以降、運用管理者と記す）が、どのような内容のイベントが、どのような条件で発生した場合に、どのような対応をすべきかを記した手順書を用意し、手順書を元に、スキルセットが十分でない人材（以降、オペレータと記す）が、計算機システムを監視する体制が採用される。この体制は、運用対象の計算機システムが、厳密に設計されその上で開発されたシステムであり、システムの規模拡大が遅いために、採用可能である。

しかしながら、近年、クラウドコンピューティングにより、物理的なシステムリソースを柔軟且つ迅速に調達することが可能となり、計算機システムの規模拡大が高速化している。一方で、仮想サーバやアプリケーションといった論理的なシステムリソースの運用は、データの秘匿などの問題もあり、一般にはクラウドコンピューティングの提供者に委託することができない。上記の運用体制では、計算機システムの運用が手順書とオペレータに依っているため、計算機システムの規模拡大に対して運用がボトルネックとなっている。

そこで、運用負荷の削減が望まれる。運用負荷の削減のために、特許文献１に開示の技術を利用することが考えられる。特許文献１は、フロー編集技術を開示する。フロー編集技術とは、フローチャートの形式で論理表現を入力する技術である。特許文献１によれば、フローチャートのテンプレートを元に、フローチャートを記述する際の記述量を削減することが可能となる。

US7,277,875

一般に、手順書には、大量の手順が蓄積されている。上述の特許文献１では、手順毎に、フローチャートのテンプレート化、又は、適用するテンプレートを探し出し、その後に、値を入力する必要がある。従って、手順をフローチャートに変換する負担を実質削減することができない。

手順をフローチャートに変換するためには、手順の記載内容を理解している必要があり、手順書を用意する者は、上述したように、通常、運用管理者である。故に、運用管理者以外の者が、手順をフローチャートに変換することは困難である。しかし、運用管理者は、運用対象である計算機システムの規模に対して概して少数であり、故に、運用管理者に運用負荷が集中している。このため、手順毎に手順をフローチャートに変換するといった大きな工数を運用管理者から捻出することは困難である。

なお、手順書は、自然言語を用いて書かれている。手順書それ自体を機械が読み込める（理解できる）形式に変換し易いように編集することで、手順をフローチャートに自動変換することが期待できる。しかし、手順書は、運用のノウハウに関する手順を含むことがあり、故に、手順書それ自体を編集することは避けることが望ましい。

上述の課題は、運用対象が、計算機システム以外の対象である場合にもあり得る。また、自然言語で表現された手順の変換後の構造体が、フローチャート以外の構造体である場合にもあり得る。

運用支援システムは、運用対象の運用に関する複数の手順を含んだ手順書のうちの第１手順の選択を受ける。運用支援システムは、第１手順に対応した第１抽象手順に包含される第２抽象手順が構造化されたものである抽象構造体と、選択された第１手順とに基づき、第１手順の少なくとも一部を構造化したものである推定構造体を表示する。

本発明によれば、手順書を機械が読み込める形式に変換するための入力作業負担を軽減することが可能となる。

図１は、実施例の概要を示す。 図２は、実施例に係るシステム全体構成を示す。 図３は、実施例に係る管理サーバのハードウェア構成を示す。 図４は、実施例に係る手順書の一例を示す。 図５は、実施例に係る手順テーブルの一例を示す。 図６は、実施例に係る変換順序テーブルの一例を示す。 図７は、実施例に係るイベント情報の一例を示す。 図８は、実施例に係る条件種類テーブルの一例を示す。 図９は、実施例に係る動作テーブルの一例を示す。 図１０は、実施例に係る抽象手順テーブルの一例を示す。 図１１は、実施例に係る抽象手順関係テーブルの一例を示す。 図１２は、実施例に係る抽象手順パタンテーブルの一例を示す。 図１３は、実施例に係る抽象手順同一部テーブルの一例を示す。 図１４は、実施例に係るフローテーブルの一例を示す。 図１５は、実施例に係る手順フロー対応テーブルの一例を示す。 図１６は、樹形図の一例を示す。 図１７は、実施例に係る手順分析処理を示す。 図１８は、実施例に係る手順一般化処理を示す。 図１９は、実施例に係る類似関係抽出処理を示す。 図２０は、実施例に係る包含関係推定処理を示す。 図２１は、実施例に係る包含関係チェック処理を示す。 図２２は、実施例に係る同一部特定処理を示す。 図２３は、実施例に係る手順変換順序決定処理を示す。 図２４は、実施例に係る手順フローチャート変換の全体シーケンスを示す。 図２５は、実施例に係るフロー記憶処理を示す。 図２６は、実施例に係るフロー分解処理を示す。 図２７は、実施例に係るフロー推定処理を示す。 図２８は、実施例における一具体例の前提を示す。 図２９は、実施例におけるフローエディタ画面の遷移例の第１部分を示す。 図３０は、実施例におけるフローエディタ画面の遷移例の第２部分を示す。 図３１は、実施例におけるフローエディタ画面の遷移例の第３部分を示す。 図３２は、実施例におけるフローエディタ画面の遷移例の第４部分を示す。

一実施例について、図面を参照して説明する。なお、以降に説明する実施例は請求の範囲にかかる発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

なお、以降の説明においては、「ａａａテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ａａａテーブル」を「ａａａ情報」と呼ぶことができる。

また、以降の説明においては、「インターフェース部」は、１以上のインターフェースデバイス、具体的には、ユーザインターフェース部と、通信インターフェース部とのうちの少なくとも１つを含んでよい。ユーザインターフェース部は、１以上のＩ／Ｏデバイス（例えば入力デバイス（例えばキーボード及びポインティングデバイス）と出力デバイス（例えば表示デバイス））と表示用計算機とのうちの少なくとも１つのＩ／Ｏデバイスを含んでよい。通信インターフェース部は、１以上の通信インターフェースデバイスを含んでよい。１以上の通信インターフェースデバイスは、１以上の同種の通信インターフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以降の説明においては、「記憶部」は、１以上のメモリを含む。記憶部に関して少なくとも１つのメモリは、揮発性メモリでよい。記憶部は、主に、プロセッサ部による処理の際に使用される。

また、以降の説明においては、「プロセッサ部」は、１以上のプロセッサを含む。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサである。１以上のプロセッサの各々は、シングルコアでもよいしマルチコアでもよい。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。プロセッサ部は、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））を含んでもよい。

また、以降の説明においては、「管理システム」は、運用支援システムの一例であり、一以上の計算機で構成されてよい。具体的には、例えば、管理計算機が表示デバイスを有していて管理計算機が自分の表示デバイスに情報を表示する場合、管理計算機が管理システムでよい。また、例えば、管理計算機（例えばサーバ）が表示用情報を遠隔の表示用計算機（例えばクライアント）に送信し表示用計算機がその情報を表示する場合（管理計算機が表示用計算機に情報を表示する場合）、管理計算機と表示用計算機とのうちの少なくとも管理計算機を含んだシステムが管理システムでよい。管理システムは、インターフェース部、記憶部、及びそれらが接続されたプロセッサ部を有してよい。管理システムにおける計算機が「表示用情報を表示する」ことは、計算機が有する表示デバイスに表示用情報を表示することであってもよいし、計算機が表示用計算機に表示用情報を送信することであってもよい（後者の場合は表示用計算機によって表示用情報が表示される）。

また、以降の説明においては、「ｋｋｋ部」（インターフェース部、記憶部及びプロセッサ部を除く）の表現にて機能を説明することがあるが、機能は、１以上のコンピュータプログラムがプロセッサ部によって実行されることで実現されてもよいし、１以上のハードウェア回路（例えばＦＰＧＡ又はＡＳＩＣ）によって実現されてもよい。プログラムがプロセッサ部によって実行されることで機能が実現される場合、定められた処理が、適宜に記憶部及び／又はインターフェース部を用いながら行われるため、機能はプロセッサ部の少なくとも一部とされてもよい。機能を主語として説明された処理は、プロセッサ部あるいはそのプロセッサ部を有する装置が行う処理としてもよい。プログラムは、プログラムソースからインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機又は計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。各機能の説明は一例であり、複数の機能が１つの機能にまとめられたり、１つの機能が複数の機能に分割されたりしてもよい。

また、以降の説明においては、「手順」は、１以上の手順文で構成されており、システム異常に対する対策内容（例えば、オペレータが運用管理者にエスカレーションを行う）と、その対策内容を実施すると判断するための条件（例えば、イベントを発行したホスト名や、イベントが発行された時間帯）とを含む。「手順文」は、手順における自然文である。「手順書」は、複数の手順を記載したドキュメントである。手順書は、例えば電子ファイルの形式で保存されていてもよい。

また、以降の説明においては、「フローチャート」は、手順の変換後の構造体に関し、機械が読み込める（理解できる）形式である代表的な論理表現例として、説明を簡略化するために用いる。本発明においては、手順の変換後の構造体の形式は、人間が記述でき、かつ、論理構造を表現できる形式であればよく、フローチャート以外の表現形式（木構造表現や、論理式表現、表構造表現や、If Thenのルール表現など）であってもよい。

また、以降の説明においては、運用対象は、対象システム（計算機システム）であるが、本発明においては、計算機システム以外の対象、例えば、アプリケーション、サービス又は装置であってよい。

（１−１）本実施例の概要

図１は、本実施例の概要を示す。

管理システムは、管理サーバ１００と、管理クライアント２００を含むシステムである。

管理サーバ１００は、ルール管理部１２０を含む。ルール管理部１２０は、フローテーブル１５０８を参照することができる。フローテーブル１５０８は、フローチャートに関する情報を保持する。

管理クライアント２００は、コンピュータプログラム（例えばアプリケーションプログラム）の一例であるフローエディタ２２０を実行する。フローエディタ２２０は、フローエディタ画面６０を表示する。フローエディタ画面６０は、管理サーバ１００におけるフローエディタ（図示せず）により管理クライアント２００に表示された画面である。フローエディタ画面６０は、本実施例ではＧＵＩ（Graphical User Interface）であるが、ＧＵＩに限らないでもよい。

図１を用いて、本実施例の概要を説明する。

まず、管理サーバ１００において、ルール管理部１２０は、手順分析処理１２０１を実行する。手順分析処理１２０１は、手順書１５０１を読み込む処理、及び、その手順書１５０１における手順間の関係性を特定する処理を含む。手順書１５０１は、運用対象の運用に関する複数の手順を含む。手順間の関係性を特定する処理は、類似の表現を持つ手順のグルーピングである類似関係抽出処理、及び、他の手順の構成要素として利用される手順を特定する処理である包含関係推定処理を含む。ルール管理部１２０は、手順分析処理１２０１により得られた手順間関係の情報を保持する。

その後、運用管理者は、例えば管理クライアント２００上のフローエディタ２２０に、手順に対応するフローチャートを記述（入力）する。本実施例においては、フローエディタ画面６０が、手順一覧２２１、手順表示２２２、及びフロー入力２２３といった表示領域を有する。手順一覧２２１には、手順の一覧が表示される。運用管理者は、手順一覧２２１から手順を選択してフローチャートの入力を開始する。手順一覧２２１における手順の順序は、例えば、運用管理者が行うフローチャート入力作業の負担を最小とすることができる順序、具体的には、抽象手順が含む単語の少ない順序である。「抽象手順」とは、手順書１５０１における手順が抽象化されたものを意味する。抽象手順内の「単語」は、抽象手順の構成要素であり、例えば、抽象手順における後述の条件節又は対策内容の表現である。

運用管理者が手順一覧２２１から手順を選択すると、選択した手順の内容（詳細）が手順表示２２２に表示される。運用管理者は、その内容に対応するフローチャートをフロー入力２２３に入力する。なお、選択された手順が、入力済みのフローチャートに対応する手順に類似している場合（例えば後述の類似度がしきい値以上の場合）、ルール管理部１２０は、その入力済みのフローチャート（又は、当該フローチャートにおけるパラメータに、選択された手順から特定されたパラメータ値が代入されたフローチャート）を、推定フローチャートとしてフローエディタ２２０に提供し、フローエディタ２２０が、その推定フローチャートをフロー入力２２３に表示する。

従って、過去に入力したフローチャートが無い場合、ルール管理部１２０は、フローチャートを推定するために必要な情報が無いため、推定フローチャートを表示できない。そのため、運用管理者は、選択した手順を元に、フローエディタ２２０に対して、フローチャートを入力し、保存指示を出す。フローエディタ２２０は、保存指示を受けると、手順（又は手順ＩＤ）とフローチャートを管理サーバ１００に送信する。管理サーバ１００のルール管理部１２０が、そのフローチャートと手順を受信し、その手順を関連付けたフローチャートに関する情報をフローテーブル１５０８に登録する。ルール管理部１２０は、手順間の関係性の情報を元に、受信した手順と類似する手順（例えば、受信した手順それ自体を構成要素として利用する手順）に関して、その類似する手順に対応するフローチャートの一部または全部を、受信したフローチャートを元に推定する。

次に、運用管理者が、フローエディタ画面６０にて、先に選択した手順（以降、この段落において第１の手順）に類似する別の手順（以降、この段落において第２の手順）を選択したとする。この場合、既に、先に保存したフローチャート（第１の手順に対応したフローチャート）を元に、第２の手順に対応したフローチャートの一部または全部が推定されている可能性がある。もしも、その推定されたフローチャートがある場合には、その推定フローチャートが、フローエディタ２２０及びルール管理部１２０により、その推定フローチャートに対応する第２の手順の全部又は一部と対応付けて表示される（例えば、第２の手順の全部又は一部である手順文が運用管理者により選択されると、その手順文に対応する推定フローチャートが強調表示される）。運用管理者は、推定フローチャートの編集（例えば、論理表現の修正又は追記）を行うことで、フローエディタ２２０に対して、第２の手順に対応するフローチャートを入力し（完成させ）、保存指示を出す。

上記を繰り返すことで（すなわち、手順の選択の受け付けとフローチャートの入力（編集）の受け付けとのセットを繰り返すことで）、管理サーバ１００（ルール管理部１２０）は、手順とフローチャートの対応を学習し、フローチャートの推定精度を向上させることができる。

後述するが、ルール管理部１２０は、次の処理を行うことができる。例えば、ルール管理部１２０は、手順書１５０１を構成する複数の手順について、それらの手順に含まれる条件節や対策内容について、同種の条件種類や対策内容（動作種類）毎に、パラメータ（パラメータ項目）に置き換えた上で、複数の抽象手順を得る。各抽象手順は、類似関係にある１以上の手順から抽出された共通パタンである。ルール管理部１２０は、複数の抽象手順について、階層的クラスタリングを実施し、抽象手順間の類似関係を特定する。そして、ルール管理部１２０は、特定した類似関係と、各抽象手順に含まれる条件節の種類（条件種類）の包含関係に基づき、抽象手順間の包含関係を推定する。任意の手順に対応する論理表現が与えられた場合（例えば運用管理者から入力された場合）、ルール管理部１２０は、手順と抽象手順の関係、抽象手順間の包含関係に基づき、与えられた手順に関係する他の手順に対応する論理表現を推定する。また、ルール管理部１２０は、他の手順のうち、推定済みの部分と、それ以外の部分とを区別して表示する。

以下、本実施例を詳細に説明する。

（１−２）システム全体構成

図２は、実施例に係るシステム全体構成を示す。

管理サーバ１００、管理クライアント２００、及び対象システム３００が、例えばＬＡＮ（Local Area Network）のようなネットワーク４００に接続されている。

管理サーバ１００は、手順書１５０１とフローチャート１２１を管理するルール管理部１２０と、対象システム３００の構成を管理する構成管理部１３０と、対象システム３００を監視するシステム監視部１４０とを含む。なお、ルール管理部１２０、構成管理部１３０、システム監視部１４０はそれぞれ独立の計算機に配置されていてもよく、構成を限定するものではない。

構成管理部１３０は、設定ファイル１３１や、構成情報１７０を管理する。設定ファイル１３１は、例えばアプリケーションやサービスのコンフィグレーションファイルであってもよいし、管理サーバ１００の構成やアプリケーションのコンフィグレーションファイルを自動的に生成するサーバ自動構成ツールの定義ファイルであってもよいし、ＶＭ（Virtual Machine）やコンテナの構成を定義する定義ファイルであってもよい。また、構成情報１７０は、例えば、管理サーバ１００の構成を示すサーバ構成情報を含む。

システム監視部１４０は、対象システム３００を監視し（例えば、対象システム３００から種々の情報を収集し）、監視結果に関する情報を含む監視情報１６０を更新する。監視情報１６０は、例えば、対象システム３００が発行したイベントを含んだイベント情報、対象システム３００の各要素に関する性能を示す情報を含んだ性能情報、及び、対象システム３００に関するログを含んだログ情報を含む。

管理クライアント２００は、インターフェース部、記憶部及びプロセッサ部を含んだ計算機であり、例えば、ディスプレイ、キーボード及びポインタデバイスを有し、フローエディタ２２０のようなアプリケーションを実行する。なお、フローエディタ２２０が、管理クライアント２００に代えて管理サーバ１００で実行され、管理クライアント２００のＷｅｂブラウザが、フローエディタ２２０からのフローエディタ画面６０を表示してもよい。なお、管理クライアント２００は複数台存在してもよい。また、管理クライアント２００は、管理サーバ１００と一体として形成してもよい（例えば、管理サーバ１００及び管理クライアント２００の両方を含んだスタンドアロンマシンが管理システムの一例であってもよい）。

対象システム３００は、運用対象の一例であって、運用管理者やオペレータの監視対象システム（運用管理対象としての計算機システム）である。例えば、対象システム３００は、サーバ、ストレージ及びネットワークといった物理システムリソース、及び、ＶＭ、コンテナ、アプリケーション及びサービスといった論理システムリソースを含む。

図３は、管理サーバ１００のハードウェア構成を示す。

管理サーバ１００は、メモリ１１０と、記憶装置１５０と、プロセッサ１８０と、Ｉ／Ｆ（通信インターフェースデバイス）１９０とを含む。Ｉ／Ｆ１９０は、ネットワーク４００に接続される。プロセッサ１８０が、Ｉ／Ｆ１９０、メモリ１１０及び記憶装置１５０に接続される。Ｉ／Ｆ１９０が、インターフェース部の一例である。メモリ１１０及び記憶装置１５０のうちの少なくともメモリ１１０が、記憶部の一例である。記憶装置１５０に格納されている情報のうちの少なくとも一部が、記憶装置１５０に代えて又は加えて、管理サーバ１００と通信可能に接続された外部の記憶装置（図示せず）に格納されてもよい。記憶装置１５０それ自体が、その外部の記憶装置であってもよい。プロセッサ１８０が、プロセッサ部の一例である。

メモリ１１０には、プロセッサ１８０で実行され、種々の処理を行うプログラムが配置される。具体的には、例えば、メモリ１１０には、監視表示部１１０２、ルール管理部１２０、構成管理部１３０及びシステム監視部１４０が配置される。ルール管理部１２０は、手順分析処理１２０１、フロー記憶処理１２０２、及び、フロー推定処理１２０３を実行する。ルール管理部１２０は、フローエディタ画面６０を表示し、フローエディタ画面６０経由で、フローチャートの表示、及び、フローチャートの編集を行う。構成管理部１３０は、構成収集処理１３０１を実行する。システム監視部１４０は、監視収集処理１４０１及びアラート処理１４０２を実行する。

監視表示部１１０２は、システム監視部１４０で収集した種々の情報を管理クライアント２００に表示する。

構成収集処理１３０１は、対象システム３００を構成する各システムリソースから当該システムリソースの構成情報を収集する処理である。

監視収集処理１４０１は、対象システム３００を構成する各システムリソースからイベント情報、各種のログ、及び性能情報を収集する処理である。

アラート処理１４０２は、事前に設定されたしきい値や、異常ログ情報（例えば、異常ログに該当する条件を示す情報）を元に、各種のログや性能情報からイベント情報を生成する処理である。例えば、アラート処理１４０２は、或るログが異常ログ情報が示す条件に該当すれば、当該或るログに関してイベント情報を生成する処理を含む。また、例えば、アラート処理１４０２は、性能情報が示す性能値（メトリック値）がしきい値を超えている場合、当該性能値に関わるリソースについてイベント情報を生成する処理を含む。このように、イベント情報は、システム監視部１４０に生成されてもよいし、対象システム３００から受信されてもよい。

記憶装置１５０は、例えば、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）のような補助記憶装置であってもよいし、ＮＡＳ（Network Attached Storage）のような外部記憶装置であってもよい。記憶装置１５０は、種々の情報を記憶する。具体的には、例えば、記憶装置１５０は、手順書１５０１、手順テーブル１５０２、変換順序テーブル１５０３、抽象手順テーブル１５０４、抽象手順関係テーブル１５０５、抽象手順パタンテーブル１５０６、抽象手順同一部テーブル１５０７、フローテーブル１５０８、手順フロー対応テーブル１５０９、条件種類テーブル１５１０、動作テーブル１５１１、監視情報１６０及び構成情報１７０を記憶する。監視情報１６０は、例えば、イベント毎のイベント情報を格納するイベントテーブル１６０１を含む。構成情報１７０は、例えば、物理サーバ名、及び、仮想マシンと物理サーバとの対応関係などを示す情報を格納するサーバ構成テーブル１７０１を含む。

（１−３）各種テーブルの内容

図４は、手順書１５０１を示す。

手順書１５０１は、複数の手順を記述したドキュメントである。手順書１５０１は、手順毎にエントリを有するテーブルである（手順書１５０１のデータ形式は、テーブル以外のデータ形式でもよい）。各エントリは、手順１５０１１及び手順ＩＤ１５０１０といった情報を格納する。以降、１つの手順を例に取る（図４の説明において「対象手順」と呼ぶ）。

手順ＩＤ１５０１０は、対象手順のＩＤを示す。手順１５０１１は、対象手順それ自体であり、例えば「ホストAAAで、12:00〜12:30の間に、xxxのメッセージのイベントが発生した場合は、エスカレーションを行わない」という自然文である。手順１５０１１は、対策内容と条件とを含む。対策内容は、例えば「エスカレーションを行う」「エスカレーションを行わない」である。条件は、例えば、サーバ名（例えば物理サーバ名）、時間帯（例えば、開始時刻及び終了時刻）、メッセージの内容といった条件である。

図５は、手順テーブル１５０２を示す。

手順テーブル１５０２は、手順書１５０１を構成する各手順の詳細に関する情報を格納する。具体的には、例えば、手順テーブル１５０２は、手順における単語毎にエントリを有する。各エントリは、手順ＩＤ１５０２０、手順文ＩＤ１５０２１、単語１５０２２、条件種類ＩＤ１５０２３、動作ＩＤ１５０２４、抽象手順ＩＤ１５０２５及び抽象手順文ＩＤ１５０２６といった情報を格納する。以降、手順における１つの単語を例に取る（図５の説明において「対象単語」と呼ぶ）。なお、手順における「単語」は、手順の構成要素であり、１以上の文字の集合である文字列（例えば、単語、句、節）である。

手順ＩＤ１５０２０は、対象単語を含む手順のＩＤを示す。手順文ＩＤ１５０２１は、対象単語を含む手順文のＩＤを示す。単語１５０２２は、対象単語を示す。条件種類ＩＤ１５０２３は、対象単語が条件節に該当する場合、その条件の種類のＩＤを示す。動作ＩＤ１５０２４は、対象単語が対策内容に該当する場合、その対策内容（動作）のＩＤを示す。抽象手順ＩＤ１５０２５は、対象単語を含む手順を抽象化したものである抽象手順のＩＤを示す。抽象手順文ＩＤ１５０２６は、対象単語を含む手順文を抽象化したものである抽象手順文のＩＤを示す。

対象単語が条件に該当する場合には、ルール管理部１２０は、条件種類ＩＤ１５０２３として有効な値を格納し、動作ＩＤ１５０２４として無効な値（例えば“−”）を格納する。対象単語が対策内容に該当する場合には、ルール管理部１２０は、動作ＩＤ１５１１０として有効な値を格納し、条件種類ＩＤ１５０２３として無効な値を格納する。対象単語が条件及び対策内容のどちらでもない場合には、ルール管理部１２０は、条件種類ＩＤ１５０２３及び動作ＩＤ１５０２４としてそれぞれ無効な値を格納する。

ルール管理部１２０は、同一クラスタ内の複数の手順における単語（例えば文字列）の共通パタンを抽出し、その複数の手順の各々について、抽出した共通パタンを含んだ抽象手順を格納する。対象単語が前述の共通パタンに含まれる場合には、ルール管理部１２０は、その共通パタンを含んだ抽象手順のＩＤを抽象手順ＩＤ１５０２５として格納し、その共通パタンを含んだ抽象手順文のＩＤを抽象手順文ＩＤ１５０２６として格納する。対象単語が共通パタンに含まれない場合は、ルール管理部１２０は、抽象手順ＩＤ１５０２５及び抽象手順文ＩＤ１５０２６としてそれぞれ無効な値（例えば“−”）を格納する。

図６は、変換順序テーブル１５０３を示す。

変換順序テーブル１５０３は、フローエディタ画面６０の手続一覧２２１での手順の順序、すなわち、ユーザに提示する適切な手順変換順序を管理するテーブルである。変換順序テーブル１５０３０は、例えば、手順分析処理１２０１において生成又は修正される。

変換順序テーブル１５０３は、手順毎にエントリを有する。各エントリは、変換順番１５０３０及び手順ＩＤ１５０３１といった情報を格納する。以降、１つの手順を例に取る（図６の説明において「対象手順」と呼ぶ）。

手順ＩＤ１５０３１は、対象手順のＩＤを示す。変換順番１５０３０は、対象手順をフローチャートに変換する順番を示す。

なお、２以上の手順の変換順番１５０３０が、同じであることもあり得る。フローエディタ画面６０の手続一覧２２１において、変換順番１５０３０が同じ２以上の手順にそれぞれ対応した２以上の行が連続して並んでもよい。変換順番１５０３０が同じ２以上の手順の表示形式として、他の形式が採用されてもよい。

図７は、イベントテーブル１６０１を示す。

イベントテーブル１６０１は、例えば、イベント毎にエントリを有する。各エントリは、イベントＩＤ１６０１０（イベントのＩＤ）、イベント情報とを格納する。イベント情報が、イベントＩＤ１６０１０を含んでもよい。イベント情報は、サーバ名１６０１１（イベントを発行したサーバの名称）、時刻１６０１２（イベントが発生した時刻）、重要度１６０１３（例えば、「エラー」や「通知」といったイベント重要度）、及び、メッセージ１６０１４といった情報を含む。

図８は、条件種類テーブル１５１０を示す。

条件種類テーブル１５１０は、条件種類に関する情報を保持するテーブルである。具体的には、例えば、条件種類テーブル１５１０は、条件種類毎にエントリを有する。各エントリは、条件種類ＩＤ１５１００、条件種類１５１０１、条件値１５１０２、取得元テーブル１５１０３、取得元カラム１５１０４、推定フラグ１５１０５及びフローＩＤ１５１０６といった情報を格納する。以降、１つの条件種類を例に取る（図８の説明において「対象条件種類」と呼ぶ）。

条件種類ＩＤ１５１００は、対象条件種類のＩＤを示す。条件種類１５１０１は、対象条件種類を識別する固定文字列を示す。条件値１５１０２は、対象条件種類に該当する条件（例えば条件節）の表現例を示す。取得元テーブル１５１０３は、対象条件種類に対応した条件値表現が格納されているテーブルの名称を示す。取得元カラム１５１０４は、対象条件種類に対応した条件値１５１０２としての表現が格納されているカラム（又は情報要素）の名称を示す。推定フラグ１５１０５は、対象条件種類に対応した条件値１５１０２が推定値か否かを示す。推定フラグ１５１０５“Ｙｅｓ”は、条件値１５１０２が推定値であることを意味する。フローＩＤ１５１０６は、対象条件種類に対応した条件値１５１０２としての表現に対応する論理表現を含んだフローチャートのＩＤである。

ルール管理部１２０は、取得元テーブル１５１０３及び取得元カラム１５１０４として有効な値が格納されている場合、条件値１５１０２として、値が格納されていないことを示す無効な値（例えば“−”）を格納してもよい。

また、ルール管理１２０は、構成情報１７０及び監視情報１６０から、対象条件種類に関し、類似の表現をもつ情報を条件値として特定し、その特定された条件値を、推定値としてもよい。その場合には、ルール管理部１２０は、対象条件種類に対応した推定フラグ１５１０５を“Ｙｅｓ”とする。

図９は、動作テーブル１５１１を示す。

動作テーブル１５１１は、手順に含まれる具体的な対策内容の表現例を動作種類と対応付けて管理するテーブルである。具体的には、例えば、動作テーブル１５１１は、動作毎にエントリを有する。各エントリが、動作ＩＤ１５１１０、動作種類１５１１１、動作表現１５１１２及びフローＩＤ１５１１３といった情報を保持する。以降、１つの動作を例に取る（図９の説明において「対象動作」と呼ぶ）。

動作ＩＤ１５１１０は、対象動作（対策内容）のＩＤを示す。動作種類１５１１１は、対象動作（対策内容）を識別する固定文字列を示す。動作表現１５１１２は、対象動作（対策内容）の表現例を示す。フローＩＤ１５１１３は、対象動作（対策内容）に対応した動作表現１５１１２に対応する論理表現を含んだフローチャートのＩＤを示す。

図１０は、抽象手順テーブル１５０４を示す。

抽象手順テーブル１５０４は、抽象手順に関する情報を保持するテーブルである。具体的には、例えば、抽象手順テーブル１５０４は、抽象手順における単語毎にエントリを有する。各エントリは、抽象手順ＩＤ１５０４０、抽象手順文ＩＤ１５０４１、単語１５０４２、条件種類ＩＤ１５０４３及び動作ＩＤ１５０４４といった情報を格納する。以降、抽象手順における１つの単語を例に取る（図１０の説明において「対象単語」と呼ぶ）。

抽象手順ＩＤ１５０４０は、対象単語を含む抽象手順のＩＤを示す。抽象手順文ＩＤ１５０４１は、対象単語を含む抽象手順文のＩＤを示す。単語１５０４２は、対象単語を示す。条件種類ＩＤ１５０４３は、対象単語が条件節に該当する場合、その条件の種類のＩＤを示す。動作ＩＤ１５０４４は、対象単語が対策内容に該当する場合、その対策内容（動作）のＩＤを示す。

対象単語が条件に該当する場合には、ルール管理部１２０は、条件種類ＩＤ１５０４３として有効な値を格納し、動作ＩＤ１５０４４として無効な値（例えば“−”）を格納する。対象単語が対策内容に該当する場合には、ルール管理部１２０は、動作ＩＤ１５０４４として有効な値を格納し、条件種類ＩＤ１５０４３として無効な値を格納する。対象単語が条件及び対策内容のどちらでもない場合には、ルール管理部１２０は、条件種類ＩＤ１５０４３及び動作ＩＤ１５０４４としてそれぞれ無効な値を格納する。

図１１は、抽象手順関係テーブル１５０５を示す。

抽出手順関係テーブル１５０５は、抽象手順間の包含関係を示す情報を保持するテーブルである。具体的には、例えば、抽出手順関係テーブル１５０５は、抽出手順毎にエントリを有する。各エントリは、抽象手順ＩＤ１５０５０、子抽象手順ＩＤ１５０５１及び親抽象手順ＩＤ１５０５２といった情報を格納する。以降、１つの抽象手順を例に取る（図１１の説明において「対象抽象手順」と呼ぶ）。

抽象手順ＩＤ１５０５０は、対象抽象手順のＩＤを示す。

子抽象手順ＩＤ１５０５１は、対象抽象手順の子抽象手順のＩＤ、すなわち、対象抽象手順を包含するより大きい抽象手順（典型的には、対象抽象手順が有する全ての条件節を含んだ抽象手順）のＩＤを示す。なお、対象抽象手順の子抽象手順を包含する更なる子抽象手順が１つ以上存在することもあり得る。以降、対象抽象手順を包含する全ての抽象手順の各々を「下位抽象手順」と呼び、対象抽象手順に直帰の下位抽象手順を特に「子抽象手順」と呼ぶことがある。

親抽象手順ＩＤ１５０５２は、対象抽象手順の親抽象手順のＩＤ、すなわち、対象抽象手順に包含されるより小さい抽象手順（典型的には、対象抽象手順が有する全ての条件節の一部の条件節を全ての条件節として含んだ抽象手順）のＩＤを示す。なお、対象抽象手順の親抽象手順に包含される更なる親抽象手順が１つ以上存在することもあり得る。以降、対象抽象手順に包含される全ての抽象手順の各々を「上位抽象手順」と呼び、対象抽象手順に直帰の上位抽象手順を特に「親抽象手順」と呼ぶことがある。

図１２は、抽象手順パタンテーブル１５０６を示す。

抽象手順パタンテーブル１５０６は、包含関係にある抽象手順間で共通する部分であるフレーズを保持するテーブルである。具体的には、例えば、抽象手順パタンテーブル１５０６は、フレーズ毎にエントリを有する。各エントリが、フレーズＩＤ１５０６０及びフレーズ１５０６１といった情報を格納する。以降、１つのフレーズを例に取る（図１２の説明において「対象フレーズ」と呼ぶ）。

フレーズＩＤ１５０６０は、対象フレーズのＩＤを示す。フレーズ１５０６１は、対象フレーズ（文字列パタン）それ自体を示す。

図１３は、抽象手順同一部テーブル１５０７を示す。

抽象手順同一部テーブル１５０７は、フレーズが出現する箇所を示す情報を保持するテーブルである。具体的には、例えば、抽象手順同一部テーブル１５０７は、フレーズ毎に、エントリを有する。各エントリは、抽象手順ＩＤ１５０７０、抽象手順文ＩＤ１５０７１、開始位置１５０７２、終了位置１５０７３及びフレーズＩＤ１５０７４といった情報を格納する。以降、１つのフレーズを例に取る（図１３の説明において「対象フレーズ」と呼ぶ）。

抽象手順ＩＤ１５０７０は、対象フレーズを含んだ抽象手順のＩＤを示す。抽象手順文ＩＤ１５０７１は、対象フレーズを含んだ抽象手順文のＩＤを示す。開始位置１５０７２は、対象フレーズの開始位置（例えば、対象フレーズの先頭文字と対象フレーズを含んだ抽象手順の先頭文字との間に存在する文字の数）を示す。終了位置１５０７３は、対象フレーズの終了位置（例えば、対象フレーズの末尾文字と対象フレーズを含んだ抽象手順の先頭文字との間に存在する文字の数）を示す。フレーズＩＤ１５０７４は、対象フレーズのＩＤを示す。

図１４は、フローテーブル１５０８を示す。

フローテーブル１５０８は、手順に対応する論理表現（本実施例ではフローチャート）を保持するテーブルである。論理表現の一部は、推定された論理表現でもよい。具体的には、例えば、フローテーブル１５０８は、フローチャート毎にエントリを有する。各エントリは、フローＩＤ１５０８０及び論理表現１５０８１といった情報を保持する。以降、１つのフローチャートを例に取る（図１４の説明において「対象フローチャート」と呼ぶ）。

フローＩＤ１５０８０は、対象フローチャートのＩＤを示す。論理表現１５０８１は、対象フローチャートとしての論理表現を示す。

論理表現１５０８１は、例えば、図１４に例示のように「ＳＥＲＶＥＲ＿ＮＡＭＥ＿ＣＯＮＤ＿１ ＝＝ ＡＡＡ and [フローＩＤ ＝ 2]」のようなプログラム表現であってもよいし、フローチャート形式でもよい。上記の例では、“ＳＥＲＶＥＲ＿ＮＡＭＥ＿ＣＯＮＤ＿１”は条件種類１５１０１であり、“ＡＡＡ”は、条件値１５１０２である。

また、“[フローＩＤ ＝ 2]”は、フローＩＤ１５０８０“２”である論理表現に置き換えることを意味する。このように、論理表現１５０８１は、入れ子構造であってもよい。これによって、複数のフローチャートを単一のフローチャートとして管理することができる。

図１５は、手順フロー対応テーブル１５０９を示す。

手順フロー対応テーブル１５０９は、手順、抽象手順、フレーズ及びフローチャートの対応関係を示す情報を保持するテーブルである。具体的には、例えば、手順フロー対応テーブル１５０９は、フレーズ毎にエントリを有する。各エントリは、手順ＩＤ１５０９０、手順文ＩＤ１５０９１、抽象手順ＩＤ１５０９２、抽象手順文ＩＤ１５０９３、開始位置１５０９４、終了位置１５０９５、フレーズＩＤ１５０９６、フローＩＤ１５０９７及び代表フラグ１５０９８といった情報を格納する。以降、１つのフレーズを例に取る（図１５の説明において「対象フレーズ」と呼ぶ）。なお、本実施例では、フレーズが、最小単位でよく、フレーズは、１つの単語であってもよい。

手順ＩＤ１５０９０は、対象フレーズを含む対象手順にてのＩＤを示す。手順文ＩＤ１５０９１は、対象フレーズを含む手順文のＩＤを示す。抽象手順ＩＤ１５０９２は、対象フレーズを含む抽象手順のＩＤを示す。抽象手順文ＩＤ１５０９３は、対象フレーズを含む抽象手順文のＩＤを示す。開始位置１５０９４は、手順における対象フレーズの開始位置を示す。終了位置１５０９５は、手順における対象フレーズの終了位置を示す。フレーズＩＤ１５０９６は、対象フレーズのＩＤである。フローＩＤ１５０９７は、対象フレーズに対応したフローチャート部分を含むフローチャートのＩＤである。代表フラグ１５０９８は、そのフローチャートが代表フローチャートであるか否かを示す。

手順フロー対応テーブル１５０９は、以下のタイミング、例えば、フローエディタ２２０を通して運用管理者がフローチャートを保存したタイミング、及び、フロー記憶処理１２０２及びフロー推定処理１２０３の少なくとも１つにおいてフローチャートが推定されたタイミングで更新される。

代表フラグ１５０９８は、ある抽象手順に対応するフローチャートが複数パタン存在する場合に、抽象手順に対応するフローチャートを一意に特定するためのフラグである。これは、抽象手順が、文面が類似している手順集合から抽出されており、この手順集合には異なる意図の手順が含まれている可能性があることに起因する。例えば、「ＳｅｒｖｅｒＡとＳｅｒｖｅｒＢでＸＸＸが発生した場合」と「ＳｅｒｖｅｒＡかＳｅｒｖｅｒＢでＸＸＸが発生した場合」の手順は「ＳｅｒｖｅｒＡ」と「ＳｅｒｖｅｒＢ」を条件節として含むが、それらの手順の論理的な構造はａｎｄ、ｏｒと全く異なる。しかしながら、自然言語としての類似性は高く同一の手順集合にまとめられる可能性があり、このとき、各手順に対応して入力されるフローチャートには、ばらつきが発生する可能性がある。

これに対し、本実施例においては、手順集合内の各手順に対応するフローチャートの内、多数のフローチャートに含まれる論理構造であるフローチャートを代表フローチャートとする例を示す（フロー分解処理Ｓ８０００）。すなわち、複数の候補がある場合には、代表フローチャートが推定フローチャートとして表示されることになる。

なお、上記は代表フローチャートを求める方法を限定するものではない。また、仮に抽象手順に対応するフローチャートが複数パタン発生している場合には、その検出を契機としてフローチャートのパタン毎に手順集合を分割し、抽象手順や、抽象手順間の類似関係を再計算するなどをしてもよい。

手順フロー対応テーブル１５０９について複数の更新タイミングがある。例えば、以下（１）〜（６）のように値が格納され得る。以降に示すように、本実施例では、「フローチャート」は、手順全体又は抽象手順について存在することもあれば、手順又は抽象手順の一部分（例えば、手順文又は抽象手順文の全部又は一部（例えば、フレーズ））について存在することもある。以降の説明では、フローチャートの構成要素を「ノード」と呼ぶことがある。ノードが、フローチャートそれ自体であることもある。つまり、ノードは、フローチャートの全部又は一部である。
（１）指定された手順ＩＤ１５０９０に対応する手順全体のフローチャートを指すフローＩＤ１５０９７が格納される。
（２）指定された手順ＩＤ１５０９０及び手順文ＩＤ１５０９１に対応する手順文のフローチャートを指すフローＩＤ１５０９７が格納される。
（３）指定された手順ＩＤ１５０９０、手順文ＩＤ１５０９１、開始位置１５０９４及び終了位置に対応する手順文部分のフローチャートを指すフローＩＤ１５０９７が格納される。
（４）指定された抽象手順ＩＤ１５０９２に対応する抽象手順全体のフローチャートを指すフローＩＤ１５０９７が格納される。
（５）指定された抽象手順ＩＤ１５０９２及び抽象手順文ＩＤ１５０９３に対応する抽象手順文のフローチャートを指すフローＩＤ１５０９７が格納される。
（６）指定された抽象手順ＩＤ１５０９２、抽象手順文ＩＤ１５０９３、開始位置１５０９４、終了位置１５０９５及びフレーズＩＤ１５０９６に対応する抽象手順文部分（フレーズ）に対応するフローチャートを指すフローＩＤ１５０９７が格納される。

（１−４）本実施例で行われる処理の詳細

図１７は、手順分析処理１２０１を示す。手順分析処理１２０１は、各手順をフローチャートに変換する前の事前処理として実行される。ルール管理部１２０が、手順分析処理において、手順書１５０１に含まれる手順の関係性を特定する。

まず、ルール管理部１２０は、入力として受信した手順書を読み込む（例えばメモリ１１０に格納する）（Ｓ１０００）。

次に、ルール管理部１２０は、その手順書に含まれる手順を抽出し、各手順に対して形態素解析を施す（Ｓ１０１０）。結果として、各手順が、単語に分解される。例えば、ルール管理部１２０は、各手順から、特定の品詞（例えば、名詞又は動詞）に該当する単語のみを抽出してもよいし、１以上の手順の少なくとも１つについて、複数の単語を意味のある単位にまとめて一つの単語とみなしてもよい。Ｓ１０２０以降のステップにおいては、Ｓ１０１０で抽出された各手順について、Ｓ１０１０で得られた単語列（１以上の単語）が、「手順」として扱われる。

次に、ルール管理部１２０は、Ｓ１０２０で手順一般化処理（図１８）を実施する（Ｓ１０２０）。ルール管理部１２０は、手順一般化処理において、手順に含まれる条件節の条件表現や、対策内容の動作を示す単語列を特定する。Ｓ１０３０以降のステップでは、Ｓ１０２０で特定した単語を、対応する条件種類１５１０１や動作種類１５１１１に置き換えた単語を、「手順」として扱う。なお、以降の説明においては、条件種類１５１０１や動作種類１５１１１と、Ｓ１０１０で切り出した単語を区別せずに、「単語」と言及する。

次に、ルール管理部１２０は、類似関係抽出処理（図１９）を実施する（Ｓ１０３０）。ルール管理部１２０は、類似関係抽出処理において、類似である手順集合を特定し、手順集合に共通の単語列パタンを抽象手順として記憶する。従って、抽象手順は、手順集合に属する１以上の手順に共通である。また、抽象手順は、単語列パタンであるため、抽象手順文は、抽象手順としての単語列パタンの一部又は全部である。

次に、ルール管理部１２０は、包含関係推定処理（図２０）を実施する（Ｓ１０４０）。ルール管理部１２０は、類似関係抽出処理において、Ｓ１０３０で生成した抽象手順間の包含関係を推定する。

最後に、ルール管理部１２０は、手順変換順序決定処理（図２３）を実施する（Ｓ１０５０）。ルール管理部１２０は、手順変換順序決定処理において、手順間の類似関係、包含関係を元に手順の順序付けをする。

図１８は、手順一般化処理（Ｓ１０２０）を示す。

ルール管理部１２０は、各手順における各単語（例えば、条件節に該当する単語、及び、対策内容に該当する単語）について、Ｓ２０２０〜Ｓ２０９０を行う。以降、１つの手順における１つの単語を例に取る（Ｓ２０２０〜Ｓ２０９０の説明において、「対象手順」及び「対象単語」と呼ぶ）。なお、「対象単語」は、最小単語（最小単位としての単語）であってもよいし、最小単語の組合せ（２以上の最小単語の集合）であってもよい。具体的には、例えば、「対象単語」は、Ｎ−Ｇｒａｍ（Ｎは１以上の整数）でよい。

ルール管理部１２０は、対象単語が対策内容に該当する単語であれば、対象単語に類似する動作表現１５１１２があるか否かを判断する（Ｓ２０２０）。対象単語のような文字列の類似度（類似性）は、例えば、文字列のレーベンシュタイン距離を計算するなどの方法により特定することができる。対象単語との類似度が一定値以上の動作表現１５１１２が少なくとも１つあれば、Ｓ２０２０の判断結果は真となる。

Ｓ２０２０の判断結果が真の場合には（Ｓ２０２０：Ｙｅｓ）、ルール管理部１２０は、類似する動作表現１５１１２（例えば、最も類似度が高い動作表現１５１１２）を選択し、選択した動作表現１５１１２に対応した動作ＩＤ１５１１０を、動作ＩＤ１５０２４として、手順テーブル１５０２の該当エントリ（対象単語を示す単語１５０２２が登録されるエントリ）に登録する（Ｓ２０３０）。Ｓ２０３０で、該当エントリに、対象手順の手順ＩＤ１５０２０、対象単語を含む手順文の手順文ＩＤ１５０２１、及び、対象単語を示す単語１５０２３も登録されてよい。

Ｓ２０２０の判断結果が偽の場合には（Ｓ２０２０：Ｎｏ）、ルール管理部１２０は、対象単語が条件節に該当する単語であれば、対象単語に類似する条件値１５１０２があるか否かを判断する（Ｓ２０４０）。

Ｓ２０４０の判断結果が偽の場合には（Ｓ２０４０：Ｎｏ）、ルール管理部１２０は、格子柄情報１７０又は監視情報１６０（具体的には、取得元テーブル１５１０３及び取得元カラム１５１０４が指す情報）から、対象単語に類似する値（表現）があるか否かを判断する（Ｓ２０５０）。

Ｓ２０４０又はＳ２０５０の判断結果が真の場合には（Ｓ２０４０：Ｙｅｓ、又は、Ｓ２０５０：Ｙｅｓ）、ルール管理部１２０は、対象単語に類似する値（例えば、条件値１５１０２又は表現）に対応する条件種類の条件種類ＩＤを、条件種類ＩＤ１５０２３として、手順テーブル１５０２の該当エントリに登録する（Ｓ２０６０）。Ｓ２０６０で、該当エントリに、対象手順の手順ＩＤ１５０２０、対象単語を含む手順文の手順文ＩＤ１５０２１、及び、対象単語を示す単語１５０２３も登録されてよい。

Ｓ２０５０の判断結果が偽の場合には（Ｓ２０５０：Ｎｏ）、対象単語が該当する条件節の条件種類が、未知の条件種類（条件種類テーブル１５１０に無い条件種類）である可能性がある。そこで、ルール管理部１２０は、対象単語に類似する値（表現）が構成情報１７０又は監視情報１６０にあるか否かを判断する（Ｓ２０７０）。

Ｓ２０７０の判断結果が真の場合には（Ｓ２０７０：Ｙｅｓ）、ルール管理部１２０は、その類似する値に対応する条件種類と、その条件種類の条件種類ＩＤとを生成し、生成した条件種類を示す条件種類１５１０１、生成した条件種類ＩＤを示す条件種類ＩＤ１５１００、当該類似する値を示す条件値１５１０２、当該値の取得元を示す取得元テーブル１５１０３及び取得元カラム１５１０４、及び、推定フラグ１５０１５“Ｙｅｓ”を、条件種類テーブル１５１０に登録する（Ｓ２０８０）。また、ルール管理部１２０は、登録した条件種類ＩＤ１５１００を、条件種類ＩＤ１５０２３として手順テーブル１５０２の該当エントリに登録する（Ｓ２０９０）。Ｓ２０９０で、該当エントリに、対象手順の手順ＩＤ１５０２０、対象単語を含む手順文の手順文ＩＤ１５０２１、及び、対象単語を示す単語１５０２３も登録されてよい。

図１９は、類似関係抽出処理（Ｓ１０３０）を示す。ルール管理部１２０は、類似関係抽出処理において、クラスタリングなどの方法で類似の手順をまとめ、その類似の関係にある１以上の手順である手順集合から、共通する単語列パタンを抽象手順として抽出する。

ルール管理部１２０は、各手順について、Ｓ３０１０〜Ｓ３０３０を行う。以降、１つの手順を例に取る（Ｓ３０１０〜Ｓ３０３０の説明において、「対象手順」と呼ぶ）。

ルール管理部１２０は、対象手順に対応した１以上の単語１５０２２がそれぞれ示す１以上の単語で構成された単語列を生成する（Ｓ３０１０）。このとき、ルール管理部１２０は、その単語列を構成する１以上の単語の各々について、その単語に対応する条件種類ＩＤ１５０２３又は動作ＩＤ１５０２４として有効な値がある場合には、その単語を、そのＩＤに対応する条件種類１５１０１又は動作種類１５１１１が示す情報（単語）で置き換える（Ｓ３０２０）。その上で、ルール管理部１２０は、単語列をベクトル化する（Ｓ３０３０）。ベクトル化の方法としては、例えば、ＴＦ−ＩＤＦといった公知の方法を用いることができる。

以上、Ｓ３０１０〜Ｓ３０３０によって、条件値１５１０２が異なる手順を同一の手順として扱うことができる。具体的には、例えば、同一の内容である手順であったとしても、構成が異なる（例えばサーバ名などが異なる）と、異なる表現の手順となるが、Ｓ３０１０〜Ｓ３０３０によれば、そのような構成の異なる手順を同一の手順として認識することが可能となる。

次に、ルール管理部１２０は、各手順（単語列）をクラスタリングする。クラスタリングの方法としては、公知の方法（例えば、ｋ平均法、又は、凝集型のクラスタリング）を用いることができる。

次に、ルール管理部１２０は、各クラスタについて、Ｓ３０６０〜Ｓ３１００を行う。結果として、複数の手順の共通パタンである抽象手順が求められる。以降、１つのクラスタを例に取る（Ｓ３０６０〜Ｓ３１００の説明において、「対象クラスタ」と呼ぶ）。

ルール管理部１２０は、対象クラスタに所属する全ての手順である手順集合を取得する（Ｓ３０６０）。

ルール管理部１２０は、その取得した手順集合から、共通した単語列パタンを抽出する（Ｓ３０７０）。具体的には、例えば、ルール管理部１２０は、その手順集合について、１以上の手順ペアを生成する。そして、ルール管理部１２０は、その１以上の手順ペアの各々について、単語の単位でレーベンシュタイン距離を求め、レーベンシュタイン距離が任意のしきい値以上である単語で構成された単語列パタンを抽出する。なお、単語列パタンは、１全手順ペアについて、任意の頻度以上で見られる単語を含んでもよい。また、単語列パタンは、例えば任意の０個以上の単語が手順集合から取り除かれたものであってもよい。Ｓ３０７０で抽出された単語列パタンが、抽象手順である。

ルール管理部１２０は、Ｓ３０７０で抽出した抽象手順（単語列パタン）に関する情報を、抽象手順テーブル１５０４に登録する（Ｓ３０８０）。具体的には、例えば、ルール管理部１２０は、抽象手順ＩＤ１５０４０と抽象手順文ＩＤ１５０４１を重複の無いように生成し、その抽象手順ＩＤ１５０４０と抽象手順文ＩＤ１５０４１を、抽象手順テーブル１５０４に登録する。また、ルール管理部１２０は、抽象手順に含まれる単語がいずれかの条件種類１５１０１を含む場合には、その条件種類１５１０１に対応する条件種類ＩＤ１５１００を、抽象手順テーブル１５０４に条件種類ＩＤ１５０４３として登録する。同様に、ルール管理部１２０は、抽象手順に含まれる単語がいずれかの動作種類１５１１１を含む場合には、当その動作種類１５１１１に対応する動作ＩＤ１５１１０を、抽象手順テーブル１５０４に動作ＩＤ１５０４４として登録する。Ｓ３０８０では、抽象手順に含まれる単語が単語１５０４２として登録されてよい。

その後、ルール管理部１２０は、Ｓ３０６０で取得した手順集合を構成する手順毎に、Ｓ３１００を行う。以降、１つの手順を例に取る（Ｓ３１００の説明において、「対象手順」と呼ぶ）。

ルール管理部１２０は、対象手順に対応する抽象手順に関する情報を手順テーブル１５０２に登録する（Ｓ３１００）。具体的には、例えば、ルール管理部１２０は、Ｓ３０７０で抽出した抽象手順（単語列パタン）内の単語に対応する単語を対象クラスタから特定する。これには、例えば正規表現のパターンマッチなどの方法を用いることができる。そして、ルール管理部１２０は、手順テーブル１５０２における該当エントリ（特定した単語を示す単語１５０２２を含んだエントリ）に、その抽象手順のＩＤを示す抽象手順ＩＤ１５０２５と、特定した単語に対応する単語を含む抽象手順文のＩＤを示す抽象手順文１５０２６とを登録する。

図２０は、包含関係推定処理（Ｓ１０４０）を示す。

ルール管理部１２０は、抽象手順テーブル１５０４から全ての抽象手順（単語列パタン）を取得する（Ｓ４０００）。このとき、ルール管理部１２０は、それらの抽象手順を構成する１以上の単語の各々について、その単語に対応する条件種類ＩＤ１５０４３又は動作ＩＤ１５０４４として有効な値がある場合には、その単語を、そのＩＤに対応した条件種類１５１０１又は動作種類１５１１１が示す情報（単語）で置き換える。

ルール管理部１２０は、Ｓ４０００で取得した抽象手順（単語列パタン）を、Ｓ３０３０と同様にベクトル表現に変換し、凝集型のクラスタリングを実施する（Ｓ４０１０）。凝集型クラスタリングを実施すると、類似性の高い抽象手順から、順次、クラスタにまとめられていく。これにより、最終的には生成されたクラスタは、樹形図と呼ばれる２分木として表現することができる。

図１６は、樹形図の一例、具体的には、抽象手順Ａ〜Ｅを凝集型クラスタリングによってまとめた例を示す。クラスタ１は、抽象手順ＡとＢをまとめたクラスタである。クラスタ２は、対象手順ＣとＤをまとめたクラスタである。クラスタ３は、クラスタ２とクラスタ１をまとめたクラスタである。クラスタ４は、クラスタ３と抽象手順Ｅをまとめたクラスタである。

樹形図では、クラスタの構成要素がどの程度類似しているかを「類似度」と呼ぶ。類似度は、０以上１以下である。樹形図は、リーフの位置を類似度“１”、ルートの位置を類似度“０”として描画する。そして、樹形図は、クラスタの構成要素の類似度に相当する高さで、ノードの結合点を描画する。今後、説明を簡略化するために、結合点の左右の部分木を、クラスタの左右の木と呼ぶ。また、結合点の高さで示される左右のノードの類似度を、その部分木が示すクラスタの類似度と呼ぶ。

図１６に示すように、凝集型クラスタリングでは、複数のクラスタが階層的に構成されることとなるが、より小さいクラスタに所属する抽象手順同士では単語列の過不足がより少なく、より類似である可能性が高くなる。

この特徴を利用し、ルール管理部１２０は、Ｓ４０１０で生成したクラスタリングについて、類似度が高い順にクラスタを選択し、クラスタに含まれる抽象手順同士を比較して順次包含関係を推定していく。ルール管理部１２０は、各クラスタについて、Ｓ４０３０〜Ｓ４０９０を行う。以降、１つのクラスタを例に取る（Ｓ４０３０〜Ｓ４０９０の説明において、「対象クラスタ」と呼ぶ）。

ルール管理部１２０は、対象クラスタにおける左右の木から、それぞれ１つの抽象手順を選択し、選択した抽象手順のペアである抽象手順ペアを生成する（Ｓ４０３０）。対象クラスタに関し、抽象手順ペア毎に、Ｓ４０５０〜Ｓ４０９０が行われる。以降、１つの抽象手順ペアを例に取る（Ｓ４０５０〜Ｓ４０９０の説明において、「対象抽象手順ペア」と呼ぶ）。なお、クラスタの類似度が任意のしきい値以下の場合は、クラスタにおける左右の木に含まれる抽象手順が類似していない可能性が高いため、ループを終了させるなどの処理が採用されてもよい。

ルール管理部１２０は、対象抽象手順ペアについて、包含関係チェック処理を実施する（Ｓ４０５０）。包含関係チェック処理では、対象抽象手順ペアが包含の関係であるか否かがチェック（推定）される。

もしも、チェック結果が偽である場合には（Ｓ４０６０：Ｎｏ）、ルール管理部１２０は、Ｓ４０７０以降の処理をせずに次の抽象手順ペアを選択する。

一方、チェック結果が真である場合には（Ｓ４０６０：Ｙｅｓ）、ルール管理部１２０は、対象抽象手順ペアについて、Ｓ４０７０〜Ｓ４０９０を行う。

すなわち、ルール管理部１２０は、対象抽象手順ペアに関する情報が抽象手順関係テーブル１５０５に未登録か否かを判断する（Ｓ４０７０）。

Ｓ４０７０の判断結果が真の場合（Ｓ４０７０：Ｙｅｓ）、ルール管理部１２０は、対象抽象手順ペアに関する情報を抽象手順関係テーブル１５０５に登録する（Ｓ４０８０）。

具体的には、ルール管理部１２０は、包含関係チェック処理の結果より、対象抽象手順ペアの親子関係を特定する。対象手順ペア内の親の抽象手順について、ルール管理部１２０は、当該親の抽象手順のＩＤを抽象手順ＩＤ１５０５０として含むエントリがあれば、そのエントリに、対象抽象手順ペア内の子の抽象手順のＩＤを子抽象手順ＩＤ１５０５１として登録する。また、対象抽象手順ペア内の子の抽象手順について、ルール管理部１２０は、当該子の抽象手順のＩＤを抽象手順ＩＤ１５０５０として含むエントリがあれば、そのエントリに、対象抽象手順ペア内の親の抽象手順ＩＤを親抽象手順ＩＤ１５０５２として登録する。なお、もしも、対応するエントリがない場合には、ルール管理部１２０は、新規にエントリを抽象手順関係テーブル１５０５に生成する。なお、Ｓ４０８０において、ルール管理部１２０は、対象抽象手順ペア内の子抽象手順のＩＤが、いずれかの既存の抽象手順を含む子抽象手順の子抽象手順ＩＤ１５０５１として登録済であれば、対象抽象手順ペア内の子抽象手順のＩＤを子抽象手順ＩＤ１５０５１として登録しないでよい。同様に、ルール管理部１２０は、対象抽象手順ペア内の親抽象手順のＩＤが、いずれかの既存の抽象手順に含まれる親抽象手順の親抽象手順ＩＤ１５０５２として登録済であれば、対象抽象手順ペア内の親抽象手順のＩＤを親抽象手順ＩＤ１５０５２として登録しないでよい。

ルール管理部１２０は、対象抽象手順ペアについて、同一部特定処理を実施する（Ｓ４０９０）。

図２１は、包含関係チェック処理（Ｓ４０５０）を示す。包含関係チェック処理は、入力である対象抽象手順ペアを構成する２つの抽象手順が包含関係であるか否かを判断する処理である。

ルール管理部１２０は、対象抽象手順ペアを構成する抽象手順毎に、その抽象手順に含まれる条件種類の数を集計する（Ｓ５０００）。対象抽象手順ペアを構成する抽象手順の関係が、包含関係にあるならば、それらの対象手順間の類似度が高く、含まれている条件種類と条件種類の数とが包含関係にあると考えられる。そこで、ルール管理部１２０では、Ｓ５０００で各抽象手順について集計した条件種類及びそれの数を基に、対象抽象手順ペアが包含関係を有するか否か（対象抽象手順ペアを構成する２つの抽象手順が包含関係にあるか否か）を判断する（Ｓ５０１０）。例えば、第１の抽象手順が、第２の抽象手順が含む条件種類の全てを含んでいれば、対象抽象手順ペアは包含関係を有する。一方、第１の抽象手順が、第２の抽象手順含む少なくとも１つの条件種類を含んでいなければ、対象抽象手順ペアは包含関係を有しない。ルール管理部１２０は、Ｓ５０１０の判断結果（真（Ｙｅｓ）又は偽（Ｎｏ））を、チェック結果とし、そのチェック結果を戻り値として返却する。

図２２は、同一部特定処理（Ｓ４０９０）を示す。同一部特定処理は、包含関係にあると推定された対象抽象手順ペアから共通の単語列パタンを特定する処理である。

ルール管理部１２０は、対象抽象手順ペアに関して、抽象手順文の対応関係を特定する（Ｓ６０００）。具体的には、例えば、ルール管理部１２０は、レーベンシュタイン距離や、ＴＦ−ＩＤＦといった方法で、抽象手順文をベクトル表現に置き換え、ベクトルの距離が一定のしきい値以下の抽象手順文ペアを求めてもよいし、抽象手順文の出現順番が一致するように制限を加えてもよい。

その後、ルール管理部１２０は、抽象手順文の数が少ない方の抽象手順を選択する（Ｓ６０１０）。そして、ルール管理部１２０は、選択した抽象手順内の抽象手順文毎に、Ｓ６０３０〜Ｓ６０５０を行う。以降、１つの抽象手順文を例に取る（Ｓ６０３０〜Ｓ６０５０の説明において、「対象抽象手順文」と呼ぶ）。

ルール管理部１２０は、対象抽象手順文に対応する抽象手順文が、Ｓ６０００で特定されているか否かを判断する（Ｓ６０３０）。

もしも、Ｓ６０３０の判断結果が真の場合には（Ｓ６０３０：Ｎｏ）、ルール管理部１２０は、対象抽象手順文と、対象抽象手順文に対応する抽象手順文とを比較し、それらの抽象手順文に共通する部分（フレーズ）があるか否かを判断する（Ｓ６０４０）。ここでは、例えば、ルール管理部１２０は、片方の抽象手順文に含まれる単語列について、Ｎ−Ｇｒａｍで単語列を切り出し、もう片方の抽象手順分に含まれるか否かを判断してよい。また、例えば、フレーズは、単純一致の部分でもよいし、両抽象手順に含まれるような正規表現としての部分でもよい。

もしも、Ｓ６０４０の判断結果が真の場合には（Ｓ６０４０：Ｙｅｓ）、ルール管理部１２０は、抽出手順パタンテーブル１５０６及び抽象手順同一部テーブル１５０７を更新する（Ｓ６０５０）。具体的には、例えば、ルール管理部１２０は、フレーズＩＤ１５０６０を重複ないように生成し、そのフレーズＩＤ１５０６０と、フレーズ１５０６１とを抽出手順パタンテーブル１５０６に登録する。また、ルール管理部１２０は、対象抽象手順文について、Ｓ６０４０で抽出したフレーズが出現する位置（開始位置１５０７２及び終了位置１５０７３）と、そのフレーズのフレーズＩＤ１５０７４（生成したフレーズＩＤ１５０６０と同じＩＤ）を、抽象手順同一部テーブル１５０７に登録する。

図２３は、手順変換順序決定処理（Ｓ１０５０）を示す。手順変換順序決定処理は、類似関係抽出処理と包含関係推定処理で抽出した手順間の関係を元に、手順をフローチャートに変換する推奨順序を決定する処理である。

ルール管理部１２０は、抽象手順関係テーブル１５０６を参照し、包含関係にあり未選択の抽象手順のうち、最も先祖にあたる抽象手順（例えば、最も単語（条件節）の少ない抽象手順）を選択する（Ｓ７０００）。

ルール管理部１２０は、Ｓ７０００で選択した抽象手順の上位抽象手順のうち未選択の上位抽象順があるか否かを判断する（Ｓ７０１０）。もしも、Ｓ７０１０の判断結果が真の場合には（Ｓ７０１０：Ｙｅｓ）、ルール管理部１２０は、未選択の上位抽象手順のうち、１つの上位抽象手順を選択し（Ｓ７０２０）、Ｓ７０１０の判断を行う。

もしも、Ｓ７０１０の判断結果が偽の場合には（Ｓ７０１０：Ｎｏ）、ルール管理部１２０は、当該の抽象手順（Ｓ７０００で選択した抽象手順）を選択する（Ｓ７０３０）。

次に、ルール管理部１２０は、Ｓ７０３０で選択した抽象手順の抽象手順ＩＤ１５０２５に対応した全ての手順を、手順テーブル１５０２から選択する（Ｓ７０４０）。

その後、ルール管理部１２０は、Ｓ７０３０で選択した抽象手順に対応する各手順の変換順番１５０３０が、Ｓ７０３０で選択した抽象手順の親抽象手順に対応する各手順の変換順番の連番（次の順番）になるように、変換順番１５０３０を生成し、その変換順番１５０３０と、Ｓ７０４０で選択した手順の手順ＩＤ１５０３１とを手順変換順序テーブル１５０３に登録する（Ｓ７０５０）。

以上、Ｓ７０００〜Ｓ７０５０が、全ての抽象手順に対して繰り返される（Ｓ７０６０）。結果として、同一の包含関係に属する各抽象手順について、その抽象手順に対応する各手順の変換順番が、その抽象手順の親抽象手順に対応する各手順の変換順番の次の順番とされる。具体的には、例えば、第１の抽象手順が第２の抽象手順の親抽象手順であり、第１の抽象手順に対応する各手順の変換順番がＸ（Ｘは自然数）の場合、第２の抽象手順に対応する各手順の変換順番はＸ＋１である。

図２４は、手順フローチャート変換の全体シーケンスを示す。

管理クライアント２００のフローエディタ２２０が、運用管理者からの手順フローチャート変換操作を受け、その操作に従う手順一覧要求を管理サーバ１００に送信する。管理サーバ１００のルール管理部１２０が、その手順一覧要求を受信する。ルール管理部１２０が、その要求に応答して、変換順番１５０３０と手順１５０１１との組（更に手順ＩＤ１５０１０を含んでもよい）の一覧を、管理クライアント２００に送信する。管理クライアント２００のフローエディタ２２０は、変換順番１５０３０通りに並んだ手順の一覧をフローエディタ画面６０の手順一覧２２１に表示する。

フローエディタ２２０は、運用管理者から、手順一覧２２１からの手順の選択を受け、選択された手順の手順ＩＤ（手順ＩＤに代えて又は加えて手順それ自体でもよい）を管理サーバ１００に送信する。管理サーバ１００のルール管理部１２０は、選択された手順の手順ＩＤを受信することを含むフロー推定処理１２０３を実施し、選択された手順の全部又は一部の推定フローチャートと、選択された手順のうち推定された箇所（手順文又はフレーズ）とのうちの少なくとも１つを管理クライアント２００に送信する。管理クライアント２００のフローエディタ２２０は、受信した情報を元に、手順表示２２２とフロー入力２２３に、手順と推定フローチャートを表示する。なお、フローエディタ２２０は、手順文、フレーズ又は単語といった手順箇所を、マウスなどの入力デバイスによって指定された場合、指定された手順箇所に対応する推定フローチャート箇所（例えば、ノード全体、又は、ノード内の文字列における該当箇所）を、ルール管理部１２０に問合せて特定することにより（或いは、手順フロー対応テーブル１５０９を参照することにより）、強調表示することもできる。

フローエディタ２２０が、運用管理者から、手順表示２２２に対して、手順全体、手順文又はフレーズの選択と、選択箇所に対応するフローチャートの入力とを受ける。このとき、前述のとおり、フローエディタ２２０は、選択箇所に対応する推定フロー箇所を強調表示させてから、当該フローチャートの修正を受けてもよい。フローエディタ２２０は、入力されたフローチャートと、手順対応関係（手順全体、手順文及びフレーズのうちの少なくとも２つの関係）とを保持する。フローエディタ２２０は、運用管理者からフローチャートの保存指示を受けると、入力されたフローチャート、及び、保持した手順対応関係を、管理サーバ１００に送信する。管理サーバ１００のルール管理部１２０は、そのフローチャート及び対応関係を保存するためのフロー記憶処理１２０２を実施し、完了通知を、フローエディタ２２０に通知する。

なお、手順一覧２２１には、手順以外が表示されてもよい。例えば、推定フローが表示されてもよいし、手順のうち推定されている箇所の割合（カバレッジ）などが表示されてもよい。また、保存指示は、運用管理者が明示的に行う必要は必ずしもない。例えば、フローチャートの入力と同時に明示の保存指示無しにフロー記憶処理１２０２が実施されてもよい。このとき、上記の通りに手順一覧２２１の表示が更新されてもよい。

図２５は、フロー記憶処理１２０２を示す。フロー記憶処理１２０２は、受信したフローチャートを記憶する処理である。

フローテーブル１５０８では、図１４に示す通り、論理表現１５０８１から別のフローＩＤ１５０８０を参照することがあり得る。例えば、手順文に対応するフローチャートから、フレーズに対応するフローチャートを参照することがあり得る。そのため、ルール管理部１２０は、まず、フロー分解処理を実施する（Ｓ８０００）。それにより、受信した手順箇所をより細粒度の単位である抽象手順やフレーズなどに分解し、それらの単位に対応するフローチャートを得ることができる。フローチャート毎に、Ｓ８０１０〜Ｓ８０５０が行われる。以降、１つのフローチャートを例に取る（Ｓ８０１０〜Ｓ８０５０の説明で「対象フローチャート」と呼ぶ）。

ルール管理部１２０は、対象フローチャートに関する情報が手順フロー対応テーブル１５０９に登録済みか否かを判断する（Ｓ８０１０）。具体的には、例えば、ルール管理部１２０は、対象フローチャートに対応するＩＤ（例えば、手順ＩＤ、手順文、抽象手順ＩＤ、抽象手順文ＩＤ、開始位置及び終了位置の部分集合）が手順フロー対応テーブル１５０９に登録済みか否かを判断する。

もしも、Ｓ８０１０の判断結果が偽の場合には（Ｓ８０１０：Ｎｏ）、ルール管理部１２０は、対象フローチャートに対応するＩＤを手順フロー対応テーブル１５０９に登録する（Ｓ８０２０）。この時、そのＩＤに対応付けられる代表フラグ１５０９８は“Ｙｅｓ”とされる。

一方で、もしも、Ｓ８０１０の判断結果が真の場合には（Ｓ８０１０：Ｙｅｓ）、ルール管理部１２０は、対象フローチャートと既存のＩＤに対応したフローチャートとの差分を無くしたフローチャートを代表フローチャートとして生成する。具体的には、ルール管理部１２０は、Ｓ８０３０〜Ｓ８０５０を行う。

すなわち、ルール管理部１２０は、手順フロー対応テーブル１５０９から、対象フローチャートに対応するＩＤに合致し、かつ代表フラグ１５０９８“Ｎｏ”であるフローチャート群（１以上のフローチャート）を取得する（Ｓ８０３０）。

そして、ルール管理部１２０は、Ｓ８０３０で取得したフローチャート群と、対象フローチャートとを比較し、代表フローチャートを生成する（Ｓ８０４０）。具体的には、例えば、ルール管理部１２０は、フローチャート群のうちの過半数（所定割合の一例）のフローチャートに存在する条件種類や動作種類を選択する。そして、ルール管理部１２０は、選択した条件種類や動作種類を示すノード間の論理的な接続関係が、上記過半数のフローチャートに存在する場合に、その論理的な接続関係で、対象フローチャート内の条件種類や動作種類を示すノードをつなぐ。結果として、複数のグラフの形として代表フローチャートが生成される。

その後、ルール管理部１２０は、Ｓ８０４０で生成した代表フローチャートに関する情報を、手順フロー対応テーブル１５０９に登録する（Ｓ８０５０）。この時、そのフローチャートについて、代表フラグ１５０９８は“Ｙｅｓ”とされる。

ルール管理部１２０は、Ｓ８０００〜Ｓ８０５０の後（受信したフローチャートを登録した後）、手順一般化処理（Ｓ１０２０）で推定した条件節について、受信したフローチャートを元に確定させる。

具体的には、まず、ルール管理部１２０は、受信したフローチャートから、条件表現を記載した条件節のノードを抽出する（Ｓ８０６０）。

そして、ルール管理部１２０は、抽出したノードに含まれる条件種類に対応したエントリ（条件種類テーブル１５１０のエントリ、例えば、条件値１５１０２や、取得元テーブル１５１０３及び取得元カラム１５１０４が指すテーブル部分に含まれる条件値表現の情報）を元に、Ｓ８０６０で抽出したノードに対応した条件節に対応する手順箇所を特定する（Ｓ８０７０）。例えば、ルール管理部１２０は、上記の条件表現に類似する単語を手順から探索すればよい。なお、Ｓ８０６０で抽出したノードに対応した条件節に関する情報を含んだエントリが、条件種類テーブル１５１０に無い場合には、ルール管理部１２０は、そのようなエントリを条件種類テーブル１５１０に追加する。

もしも、Ｓ８０７０で特定したエントリ（条件種類テーブル１５１０のエントリ）における推定フラグ１５１０５が“Ｙｅｓ”の場合には、ルール管理部１２０は、その推定フラグ１５１０５を“Ｎｏ”に変更し、条件値１５１０２として、Ｓ８０７０で特定した手順箇所の表現を登録する（Ｓ８０８０）。

図２６は、フロー分解処理（Ｓ８０００）を示す。

ルール管理部１２０は、フローチャートと手順対応関係とを受信する（Ｓ１５００）。ルール管理部１２０は、手順対応関係が手順文を含むか否かを判断する（Ｓ１５１０）。Ｓ１５１０の判断結果が偽の場合には（Ｓ１５１０：Ｎｏ）、ルール管理部１２０は、手順テーブル１５１１を参照し、手順に含まれる全手順文のＩＤを抽出する（Ｓ１５２０）。

手順対応関係から特定される手順文毎に、Ｓ１５３０〜Ｓ１５６０が行われる。以降、１つの手順文を例に取る（Ｓ１５３０〜Ｓ１５６０の説明で「対象手順文」と呼ぶ）。

ルール管理部１２０は、手順テーブル１５１１を参照し、対象手順文に対応する抽象手順文を特定する（Ｓ１５３０）。そして、ルール管理部１２０は、受信したフローチャートのうちの、特定した抽象手順文に含まれる条件種類や動作種類に対応したフローチャート部分（フローチャート中のノード）を、特定する（Ｓ１５４０）。その際、ルール管理部１２０は、特定された抽象手順文に対応しない条件節や動作のノードを、受信したフローチャートから除去する。これにより、部分的なフローチャートが作成される。

次に、ルール管理部１２０は、抽象手順パタンテーブル１５０６と抽象手順同一部テーブル１５０７を参照し、抽象手順文に含まれる全フレーズを特定する（Ｓ１５５０）。特定されたフレーズ毎に、Ｓ１５６０が行われる。以降、１つのフレーズを例に取る（Ｓ１５６０の説明で「対象フレーズ」と呼ぶ）。

ルール管理部１２０は、Ｓ１５４０と同様に、受信したフローチャートから、対象フレーズに対応するフローチャートを特定する（Ｓ１５６０）。

Ｓ１５３０〜Ｓ１５６０を実施後、ルール管理部１２０は、Ｓ１５４０と同様に、受信したフローチャートから、抽象手順全体に対応するフローチャートを特定する（Ｓ１５７０）。

ルール管理部１２０は、手順、手順文、抽象手順、抽象手順文、フレーズの対応関係に相当するように、特定したフローチャートの対応関係を特定し、フローチャートの重複を除去する（Ｓ１５８０）。そして、ルール管理部１２０は、特定したフローチャート、フローチャートと手順箇所との対応関係、及び、フローチャート間の重複排除結果を返却する。

図２７は、フロー推定処理１２０３を示す。

ルール管理部１２０は、選択された手順の手順ＩＤを受信し（Ｓ９０００）、まず、手順フロー対応テーブル１５０９を参照し、受信した手順ＩＤに対応するフローＩＤ１５０９７を特定する（Ｓ９０１０）。その後、ルール管理部１２０は、フローテーブル１５０８を参照し、特定したフローＩＤ１５０９７に対応する論理表現１５０８１（図２７の説明において、以降、代表例であるフローチャートと記載）を特定する（Ｓ９０２０）。

次に、ルール管理部１２０は、特定したフローチャートにフローＩＤが含まれているか否かを判断する（Ｓ９０３０）。

もしも、Ｓ９０３０の判断結果が真の場合には（Ｓ９０３０：Ｙｅｓ）、ルール管理部１２０は、含まれているフローＩＤに対応するフローチャートをフローテーブル１５０８から抽出し（Ｓ９０４０）、抽出したフローチャートをＳ９０２０で特定したフローチャートにマージすることで１つのフローチャートを生成する（Ｓ９０５０）。

一方で、もしも、Ｓ９０３０の判断結果が偽の場合には（Ｓ９０３０：Ｎｏ）、ルール管理部１２０は、当該フローチャート（Ｓ９０５０で生成されたフローチャート、又は、Ｓ９０２０で特定されたフローチャート）を返却する。

以降、図２８〜図３２を参照して、フローエディタ画面６０の遷移の一例を説明する。なお、以降の説明では、手順ＩＤ“Ｍ”（Ｍは自然数）の手順を、「手順Ｍ」と呼ぶ。抽象手順ＩＤ“Ｎ”（Ｎは自然数）の抽象手順を、「抽象手順Ｎ」と呼ぶ。フローＩＤ“Ｐ”（Ｐは自然数）のフローチャートを「フローチャートＰ」と呼ぶ。また、フローエディタ画面６０の表示制御は、フローエディタ２２０とルール管理部１２０とのうちの少なくとも１つにより行われる（具体的には、例えば、フローエディタ２２０からの要求に応答してルール管理部１２０から受けた情報を基にフローエディタ２２０により行われる）。以下、説明を簡単にするために、フローエディタ画面６０の表示制御は、ルール管理部１２０によりフローエディタ２２０を通じて行われるとする。なお、当該表示制御は、フローエディタ２２０が、管理サーバ１００が管理する各種テーブルを参照することにより行ってもよい。

図２８に例示の手順１及び２があるとする。ルール管理部１２０が、手順１及び２について、Ｓ１０１０〜Ｓ１０３０を経て、抽象手順１及び２を得る。具体的には、例えば、下記の通りである。
・手順１における「ＨｏｓｔＡ」が、抽象手順１において条件種類“ＳＥＲＶＥＲ＿ＮＡＭＥ＿ＣＯＮＤ＿１”に抽象化されている。「ＨｏｓｔＡ」が、サーバ名に該当する（取得元カラム１５１０４“サーバ名”にある）と判断され、故に、条件種類１５１０１“ＳＥＲＶＥＲ＿ＮＡＭＥ＿ＣＯＮＤ＿１”が推定されたためである。
・手順１における「「ＸＸＸがエラーです」の」が、抽象手順１において条件種類“ＭＳＧ＿ＣＯＮＤ＿１”に抽象化されている。手順１における「「ＸＸＸがエラーです」の」が、メッセージに該当する（取得元カラム１５１０４“メッセージ”にある）と判断され、得湯に、条件種類１５１０１“ＭＳＧ＿ＣＯＮＤ＿１”が推定されたためである。
・手順１における「エスカレーションしない」が、抽象手順１において動作種類“ＮＯ＿ＥＳＣＡＬＡＴＩＯＮ”に抽象化されている。手順１における「エスカレーションしない」が、動作表現１５１１２“エスカレーションしない”に該当したためである。

また、図２８に示すように、ルール管理部１２０が、抽象手順１及び２について、Ｓ１０１０〜Ｓ１０３０を経て、抽象手順１及び２が包含関係にあることを特定する。具体的には、抽象手順２が、抽象手順１の親抽象手順である。抽象手順２の方が抽象手順１よりも条件（条件ノード）が少ないためである。

また、図２８に示すように、条件種類１５１０１“ＳＥＲＶＥＲ＿ＮＡＭＥ＿ＣＯＮＤ＿１”にフローチャート２が関連付けられており、条件種類１５１０１“ＭＳＧ＿ＣＯＮＤ＿１”にフローチャート１が関連付けられている。フローチャート２及び１のいずれも、条件節の論理表現である。

図２８の例によれば、図２９に示すように、手順一覧２２１には、手順２の変換順番が、手順１の変換順番よりも先である。具体的には、手順２の順番（変換順番）は“１”であり、手順１の順番は“２”である。抽象手順２は、抽象手順１の親抽象手順であるためである。

まず、図２９に示すように、運用管理者が順番“１”の手順２を選択したとする。この場合、図２９及び図３０に示すように、ルール管理部１２０が、手順２を手順表示２２２に表示し、選択された手順２に対応した推定されたフローチャート１及びフローチャート４をフロー入力２２３に表示する（なお、図３０に例示のフローチャート４の論理表現は、後述の手動追加後の論理表現である）。フローチャート１の表示を例に取ると、次の通りである。すなわち、ルール管理部１２０が、選択された手順２に対応した抽象手順２を特定する。ルール管理部１２０が、抽象手順テーブル１５０４から、抽象手順２に対応した条件種類ＩＤ１５０４３を特定する。ルール管理部１２０が、条件管理テーブル１５１０から、特定した条件種類ＩＤ１５０４３に対応したフローＩＤ１５１０６を特定する。ルール管理部１２０が、フローテーブル１５０８から、特定したフローＩＤ１５１０６に対応した論理表現１５０８１を特定し、特定した論理表現１５０８１を表すフローチャート１（ノード）をフロー入力２２３に表示する。その際、ルール管理部１２０は、論理表現１５０８１における[variable]（パラメータ）に、手順２から特定されたパラメータ値“ＹＹＹでアラート”を代入する。これにより、「ＭＥＳＳＡＧＥ＝ＹＹＹでアラート」という表現をもったノード（フローチャート）がフロー入力２２３に表示される。

その後、図３０に示すように、運用管理者が、手順２における非抽象化部分“１７：００−１８：００の間”を抽象化した表現“１７：００＜＝ＴＩＭＥ ａｎｄ ＴＩＭＥ＜＝１８：００”をフロー入力２２３に入力し、保存指示を出した（例えば「保存」ボタン１０をクリックした）とする。その表現に対応した条件種類が条件種類テーブル１５１０に無いため、ルール管理部１２０が、その表現に対応した条件種類１５１０１“ＴＩＭＥ＿ＣＯＮＤ＿１”及び条件値を含んだエントリを条件種類テーブル１５１０に追加する。また、ルール管理部１２０が、その表現に対応したフローチャート３（論理表現）をフローテーブル１５０８に追加する。また、ルール管理部１２０が、動作種類に対応したフローチャート４（論理表現）を更新する。また、ルール管理部１２０は、類似関係抽出処理、包含関係推定処理及び手順変換順序決定処理を行って、フローエディタ画面上の手順一覧（手順の並び順）を更新してもよい。

次に、図３１に示すように、運用管理者が順番“２”の手順１を選択したとする。この場合、図３１に示すように、ルール管理部１２０が、手順１を手順表示２２２に表示し、抽象手順１の親抽象手順２に対応した推定されたフローチャート１、３及び４をフロー入力２２３に表示する。その際、ルール管理部１２０は、フローチャート１における[variable]に、手順１から特定されたパラメータ値“ＸＸＸがエラーです” （フローチャート１に対応した条件種類に対応するパラメータ値）を代入する。また、ルール管理部１２０は、フローチャート３における[variable]に、手順１から特定されたパラメータ値“１２：００”及び“１２：３０”（フローチャート３に対応した条件種類に対応するパラメータ値）を代入する。

更に、図３２に示すように、ルール管理部１２０が、抽象手順１に対応した条件種類のうち抽象手順２に包含されていない条件種類“ＳＥＲＶＥＲ＿ＮＡＭＥ＿ＣＯＮＤ＿１”に対応するフローチャート２をフロー入力２２３に表示する。その際、ルール管理部１２０は、フローチャート２（論理表現）における[variable]に、手順１から特定されたパラメータ値“ＨｏｓｔＡ”（条件種類“ＳＥＲＶＥＲ＿ＮＡＭＥ＿ＣＯＮＤ＿１”に対応したパラメータ値）を代入する。

図３２に示すように、運用管理者は、手動でノード間を接続する（例えばノード間を矢印で結ぶ）ことにより、手順１に対応したフローチャートを完成させる。

図３１及び図３２によれば、運用管理者は、抽象手順２の子抽象手順１に対応した手順１について（登録済みフローチャートに対応した手順２の次の順番とされている手順１について）、実質的に、手動でフローチャートを追加又は編集する必要が無い。運用管理者は、手順１についてのフローチャートが推定されたフローチャート（図３２に示すフローチャート）で正しいと判断した場合に、保存指示を出す。この場合、ルール管理部１２０が、動作種類に対応した新たなフローチャート５（フローＩＤ“２”を含んだ新たな論理表現）をフローテーブル１５０８に追加する。

以上、一実施例を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。

例えば、形態素解析に代えてディープラーニングのような他の手法が採用されてもよい。

また、例えば、ルール管理部１２０は、対象システム３００の構成を示す構成情報１７０内の値と、第１抽象手順（第１手順に対応した抽象手順）及び第２抽象手順（第２手順に対応した抽象手順）のうちの少なくとも１つに含まれる単語が類似の場合には、構成情報１７０内の当該値を元に、その単語についての条件種類を推定してもよい。

また、例えば、ルール管理部１２０は、対象システム３００の監視結果を示す監視情報１６０内の値と、第１抽象手順（第１手順に対応した抽象手順）及び第２抽象手順（第２手順に対応した抽象手順）のうちの少なくとも１つに含まれる単語が類似の場合には、監視情報１６０内の当該値を元に、その単語についての条件種類を推定してもよい。

また、例えば、フローエディタ２２０（又はルール管理部１２０）は、手順一覧２２１において、第１抽象手順に包含される第２抽象手順に対応した第２手順の順番が、第１抽象手順に対応した第１手順の順番よりも先としてよい。更に、例えば、フローエディタ２２０（又はルール管理部１２０）は、手順書１５０１（複数の手順）のうちの第３手順に対応した第３抽象手順にも第２抽象手順が包含されており、且つ、第１抽象手順及び第３抽象手順が包含関係にない場合、手順一覧２２１において、第１手順及び第３手順のうち、第１抽象手順及び第３抽象手順のうち条件種類の数が少ない方の抽象手順に対応した手順の方の順番を先としてよい。このような順番に沿って手順をフローチャートに変換していくと、運用管理者による入力作業負担が軽減されることが期待される。

１００…管理サーバ、２００…管理クライアント、３００…対象システム

Claims (13)

1. １以上のインターフェースデバイスを含むインターフェース部と、
   １以上のメモリを含む記憶部と、
   前記インターフェース部及び前記記憶部に接続された１以上のプロセッサであるプロセッサ部と
   を有し、
   前記プロセッサ部が、
   運用対象の運用に関する複数の手順を含んだ手順書のうちの第１手順の選択を受け、
   前記第１手順に対応した第１抽象手順に包含される第２抽象手順が構造化されたものである抽象構造体と、前記第１手順とに基づき、前記第１手順の少なくとも一部を構造化したものである推定構造体を表示する、
   運用支援システム。
2. 前記複数の手順の各々は、１以上の自然文を含み、
   前記第１抽象手順は、前記第１手順を含み類似関係にある１以上の手順である第１手順集合のうちの共通のパタンであり、
   前記第２抽象手順は、第２手順を含み類似関係にある１以上の手順である第２手順集合のうちの共通のパタンである、
   請求項１記載の運用支援システム。
3. 前記プロセッサ部が、
   前記第１手順集合から抽出した共通のパタンである前記第１抽象手順を生成し、
   前記第２手順集合から抽出した共通のパタンである前記第２抽象手順を生成し、
   前記第１抽象手順と前記第２抽象手順が包含関係にあるか否かを判断し、
   前記第２抽象手順が前記第１抽象手順に包含されると判断した場合、前記第２抽象手順と前記第１抽象手順とのうちの共通部分を構造化したものである前記抽象構造体を生成する、
   請求項２記載の運用支援システム。
4. 前記抽象構造体は、パラメータを含んだ論理表現であり、
   前記推定構造体は、前記抽象構造体のパラメータに対して、前記第１手順におけるパラメータ値が代入された論理表現である、
   請求項２記載の運用支援システム。
5. 前記プロセッサ部が、前記第１抽象手順のうち前記第２抽象手順と共通しない部分があって、その共通しない部分についての論理表現を特定した場合、前記第２抽象手順と前記第１抽象手順とのうちの共通部分の論理表現に前記第１手順におけるパラメータ値が代入された論理表現である推定共通論理表現と、前記共通しない部分の論理表現に前記第１手順におけるパラメータ値が代入された論理表現である推定差分論理表現とを表示する、
   請求項４記載の運用支援システム。
6. 前記第１抽象手順と前記第２抽象手順が包含関係にあるか否かの判断は、前記第１抽象手順と前記第２抽象手順とが互いに類似している場合に行われる判断であって、前記第１抽象手順における条件表現の条件種類及びそれの数と、前記第２抽象手順における条件表現の条件種類及びそれの数とに従う、
   請求項３記載の運用支援システム。
7. 前記プロセッサ部は、前記運用対象の構成を示す構成情報内の値と、前記第１抽象手順及び第２抽象手順のうちの少なくとも１つに含まれる単語が類似の場合には、前記構成情報内の前記値を元に、その単語についての条件種類を推定する、
   請求項６記載の運用支援システム。
8. 前記プロセッサ部は、前記運用対象の監視結果に関する監視情報内の値と、前記第１抽象手順及び第２抽象手順のうちの少なくとも１つに含まれる単語が類似の場合には、前記監視情報内の前記値を元に、その単語についての条件種類を推定する、
   請求項６記載の運用支援システム。
9. 前記プロセッサ部が、前記第１抽象手順のうち前記第２抽象手順と共通しない部分があって、その共通しない部分についての論理表現が見つからない場合、
   前記第２抽象手順と前記第１抽象手順とのうちの共通部分の論理表現に前記第１手順におけるパラメータ値が代入された論理表現である推定共通論理表現に追加される論理表現として、前記共通しない部分の論理表現に前記第１手順におけるパラメータ値が代入された論理表現である差分論理表現を受けて、
   前記差分論理表現から代入されたパラメータ値をパラメータに差し替えた抽象差分論理表現を登録する、
   請求項４記載の運用支援システム。
10. 前記プロセッサ部は、手順一覧を表示し、
    前記手順一覧において、前記第１抽象手順に包含される前記第２抽象手順に対応した第２手順の順番が、前記第１手順の順番よりも先である、
    請求項１記載の運用支援システム。
11. 前記複数の手順のうちの第３手順に対応した第３抽象手順にも前記第２抽象手順が包含されており、且つ、前記第１抽象手順及び前記第３抽象手順が包含関係にない場合、前記手順一覧において、前記第１手順及び前記第３手順のうち、前記第１抽象手順及び前記第３抽象手順のうち条件種類の数が少ない方の抽象手順に対応した手順の方が、順番が先である、
    請求項１０記載の運用支援システム。
12. １以上のインターフェースデバイスを含むインターフェース部と、１以上のメモリを含む記憶部と、前記インターフェース部及び前記記憶部に接続された１以上のプロセッサであるプロセッサ部とを有する運用支援システムによる運用支援方法であって、
    前記プロセッサ部が、
    運用対象の運用に関する複数の手順を含んだ手順書のうちの第１手順の選択を受け、
    前記第１手順に対応した第１抽象手順に包含される第２抽象手順が構造化されたものである抽象構造体と、前記第１手順とに基づき、前記第１手順の少なくとも一部を構造化したものである推定構造体を表示する、
    運用支援方法。
13. 運用対象の運用に関する複数の手順を含んだ手順書のうちの第１手順の選択を受け、
    前記第１手順に対応した第１抽象手順に包含される第２抽象手順が構造化されたものである抽象構造体と、前記第１手順とに基づき、前記第１手順の少なくとも一部を構造化したものである推定構造体を表示する、
    ことを１以上の計算機に実行させるコンピュータプログラム。