(57)【要約】【課題】加工処理を追加した際に、過去に蓄積されたデータに対しても手動で加工処理を実行することなく、常に信頼度の高い加工処理結果のデータを提供する。【解決手段】本発明の一実施形態の情報処理システムは、データ蓄積サーバ１０２と、ＥＴＬ管理サーバ１０１とを含む。データ蓄積サーバ１０２は、ネットワークを介して収集した複数のネットワークデバイスのデータ及びＥＴＬ実行済みデータを記憶し、ＥＴＬ実行済みデータを、分析を行う分析システムに提供する。ＥＴＬ管理サーバ１０１は、ＥＴＬの実行及びＥＴＬのルールを管理する。ＥＴＬ管理サーバ１０１は、ルール管理部３０２で管理されている第１のルールに関連する第２のルールが追加された場合に、第１及び第２のルールのそれぞれに従う加工を行う。さらに、第２のルールが追加される前に、第１のルールに従い加工が行われた入力データに対しても、第２のルールに従う加工を行う。【選択図】図１
2016091429.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して収集した複数のネットワークデバイスのデータを記憶する第１記憶手段と、
前記第１記憶手段で記憶されたデータに対して、分析に適したデータとするための加工を行う際の複数のルールを管理する管理手段と、
前記第１記憶手段で記憶されたデータに対して、前記管理されたルールに従う加工を行う加工手段と、
加工済みのデータを記憶する第２の記憶手段と、
前記第２の記憶手段に記憶された加工済みのデータを、分析を行う分析システムに提供する提供手段と、を有し、
前記加工手段は、前記管理手段で管理されている第１のルールに関連する第２のルールが追加された場合に、前記第１のルール及び第２のルールのそれぞれに従う加工を行い、
さらに、前記第２のルールが追加される前に前記第１のルールに従い加工が行われた前記第１記憶手段で記憶されたデータに対しても、前記第２のルールに従う加工を行うことを特徴とする情報処理システム。
【請求項２】
前記加工手段が前記管理されたルールに従う加工を行うために使用するサーバの台数を設定する設定手段をさらに備えることを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記設定手段は、前記管理されたルールに従う加工が終了する期限および該加工を行うデータのデータ量に基づき、前記サーバの台数を算出することを特徴とする請求項２に記載の情報処理システム。
【請求項４】
前記設定手段は、前記管理されたルールに従う加工を行うために使用するサーバの台数または、該加工が終了する期限を設定するための画面を表示することを特徴とする請求項３に記載の情報処理システム。
【請求項５】
前記管理手段は、管理するルール毎に該ルールに従う加工を行うスケジュールを管理し、
前記加工手段は、前記スケジュールに基づいて前記ルールに従う加工を行う、ことを特徴とする請求項１ないし４のいずれか１項に記載の情報処理システム。
【請求項６】
前記管理手段は、前記管理されたルールの変更、または新たに管理するルールの追加を行うための画面を表示することを特徴とする請求項１ないし５のいずれか１項に記載の情報処理システム。
【請求項７】
前記管理手段は、前記管理手段が表示する画面での操作に従って前記変更または追加を行う前に、前記管理されたルールに従う加工が行われたデータに対しても、前記変更または追加を行ったルールに従う処理を行うか否かを設定することを特徴とする請求項６に記載の情報処理システム。
【請求項８】
前記管理手段が表示する画面において、前記管理されたルールに従う加工が行われたデータに対して、前記変更または追加を行ったルールに従う処理を行わないことを設定した場合には、前記管理されたルールに従う加工が行われたデータを、所定の時間が経過した後に削除する削除手段を備えることを特徴とする請求項７に記載の情報処理システム。
【請求項９】
ネットワークを介して収集した複数のネットワークデバイスのデータを記憶する第１記憶工程と、
前記第１記憶工程において記憶されたデータに対して、分析に適したデータとするための加工を行う際の複数のルールを管理する管理工程と、
前記第１記憶工程において記憶されたデータに対して、前記管理されたルールに従う加工を行う加工工程と、
加工済みのデータを記憶する第２の記憶工程と、
前記第２の記憶工程において記憶された加工済みのデータを、分析を行う分析システムに提供する提供工程と、を有し、
前記加工工程において、前記管理工程で管理されている第１のルールに関連する第２のルールが追加された場合に、前記第１のルール及び第２のルールのそれぞれに従う加工を行い、
さらに、前記第２のルールが追加される前に前記第１のルールに従い加工が行われた前記第１記憶工程において記憶されたデータに対しても、前記第２のルールに従う加工を行うことを特徴とするシステムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システムおよび制御方法に関する。
【背景技術】
【０００２】
現在、サーバ上で稼働するアプリケーションのログや、市場で稼働する大量のデバイスの情報をサーバ上に収集、蓄積することが行われている。蓄積したデータは、アプリケーションやデバイスの品質向上、ユーザビリティの向上、または故障予測などに用いられ、集計や分析が行われる。サーバ上で稼働するアプリケーションとは、顧客に対して提供するＷｅｂサービスや、自社ユーザの業務を支援する企業向け社内システムのことである。また、デバイスとは、ＭＦＰ（ＭｕｌｔｉＦｕｎｃｔｉｏｎ  Ｐｅｒｉｐｈｅｒａｌ）や、プリンタ、携帯電話、スマートフォン、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）など多岐にわたる。また、デバイスから収集したデータだけでなく、例えばデバイスの修理などのサポートのためのサービスマンの出動履歴データや、コールセンターへのクレーム情報なども分析対象となっている。このように、分析対象のデータのサイズや種別はますます多様化、大規模化している。
【０００３】
データを効率的に分析するために、蓄積したデータに対して加工処理が行われる。加工処理とは、データに含まれる不正なデータの除去、文字コード補正、符号の付与、正規化、及びフォーマットの統一などのことである。このような加工処理は、一般的にはＥＴＬ（Ｅｘｔｒａｃｔ  Ｔｒａｎｓｆｏｒｍ  Ｌｏａｄ）と呼ばれている。ＥＴＬは、データを利用するユーザやシステムの要件にしたがって柔軟に追加や更新が行われる必要があり、１つの入力データに対して複数の出力データを管理することが求められる。
特許文献１は、基幹データベースから目的別データベースを抽出していく構成を採るデータベースシステムを開示している。特許文献１では、新たに生成した目的別データベースと前回の抽出時点の目的別データベースとの差分を管理し、再生要求があると、差分に従って過去のある時点で収集した目的別データベースを再生する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平５−２５７７６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１では、データの利用時に所望のデータを再生するため、再生処理をしている間はユーザまたはシステムが待ち状態になることが考えられる。また、加工処理の変更時には、管理者が差分データ及び最新データに対して加工処理を手動で適用する必要がある。
【０００６】
本発明は、加工処理を追加した際に、過去に蓄積されたデータに対しても手動で加工処理を実行することなく、常に信頼度の高い加工処理結果のデータを提供する情報処理システムの提供を目的とする。
【課題を解決するための手段】
【０００７】
本発明の一実施形態の情報処理システムは、ネットワークを介して収集した複数のネットワークデバイスのデータを記憶する第１記憶手段と、第１記憶手段で記憶されたデータに対して、分析に適したデータとするための加工を行う際の複数のルールを管理する管理手段と、第１記憶手段で記憶されたデータに対して、管理されたルールに従う加工を行う加工手段と、加工済みのデータを記憶する第２の記憶手段と、第２の記憶手段に記憶された加工済みのデータを、分析を行う分析システムに提供する提供手段と、有する。加工手段は、管理手段で管理されている第１のルールに関連する第２のルールが追加された場合に、第１及び第２のルールのそれぞれに従う加工を行う。さらに、第２のルールが追加される前に、第１のルールに従い加工が行われた第１記憶手段で記憶されたデータに対しても、第２のルールに従う加工を行う。
【発明の効果】
【０００８】
本発明の情報処理システムによれば、加工処理を追加した際に、過去に蓄積されたデータに対しても手動で加工処理を実行することなく、常に信頼度の高い加工処理結果のデータを提供する情報処理システムの提供が可能となる。
【図面の簡単な説明】
【０００９】
【図１】本発明の第１実施形態に係る情報処理システムの構成を示す図である。
【図２】第１実施形態におけるサーバのハードウェア構成を示す図である。
【図３】ＥＴＬ管理サーバのソフトウェアブロック図である。
【図４】データ蓄積サーバのソフトウェアブロック図である。
【図５】データ収集サーバのソフトウェアブロック図である。
【図６】ＥＴＬ管理サーバが管理端末に表示させる一覧画面を示す図である。
【図７】ＥＴＬ管理サーバが管理端末に表示させる新規追加画面を示す図である。
【図８】ＥＴＬ管理サーバのＥＴＬの実行を説明するフローチャートである。
【図９】ルールが追加された際の処理を説明するフローチャートである。
【図１０】非プライマリデータを削除する処理を説明するフローチャートである。
【図１１】本発明の第２実施形態に係る情報処理システムの構成を示す図である。
【図１２】第２実施形態におけるサーバ数指定画面を示す図である。
【図１３】本発明の第３実施形態におけるＥＴＬ期限指定画面を示す図である。
【図１４】ＥＴＬ実行に必要なサーバ数の算出処理を説明するフローチャートである。
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための形態について図面などを参照して説明する。
（第１実施形態）
図１は、本発明の第１実施形態に係る情報処理システムの構成を示す図である。
図１において、インターネット１００は、インターネットを表わしている。以下に説明する各サーバ１０１〜１０４、及び１０６や、管理端末１０５、分析端末１０７は、インターネットを介して相互に接続されている。なお、インターネット１００は、インターネットに限定されず、企業内ネットワーク（イントラネット）であってもよい。
【００１１】
ＥＴＬ管理サーバ１０１は、ＥＴＬの実行とＥＴＬのルールを管理するサーバである。データを利用する前に、利用し易い形にデータを加工することが一般的である。具体的には、データに含まれる不正なデータの除去、文字コード補正、符号の付与、正規化、及びフォーマットの統一などの加工処理がある。本実施形態においては、このような加工処理のことをＥＴＬと呼ぶ。ＥＴＬ管理サーバ１０１は、データ収集サーバ１０３の定期的なデータの収集のたびに、新たに収集されデータ蓄積サーバ１０２に蓄積されたデータに対してＥＴＬを実行する。また、ＥＴＬ実行済のデータをデータ蓄積サーバ１０２に蓄積する。さらに、管理端末１０５からのルールの変更を受け付け、必要であればデータ蓄積サーバ１０２に蓄積された過去のデータに対しても自動的にＥＴＬを実行する。ルール変更に基づいて自動的にＥＴＬを実行することで、管理者がルール変更のたびに手動で過去のデータにＥＴＬを実行して蓄積するという手間を削減することができる。
【００１２】
データ蓄積サーバ１０２は、データ収集サーバ１０３が収集したデータや、ＥＴＬ管理サーバがＥＴＬを行った結果の出力データを蓄積する。また、分析端末１０７や、データ利用サーバ群１０６からの要求に従ってＥＴＬ実行済のデータを提供する。データ蓄積サーバ１０２は、ＦＴＰ、ＨＴＴＰ、ＳＭＢ、またはデータベース接続などの一般的なプロトコルでデータの入出力を受け付けることができるが、データの入出力が可能なプロトコルであればこれに限定されない。
【００１３】
データ収集サーバ１０３は、業務サーバ群１０４等のネットワークデバイスから、データ分析に必要なデータを収集する。このとき、データ収集サーバ１０３は、業務サーバ群１０４の各サーバからＦＴＰ、ＨＴＴＰ、またはＳＭＢなどのデータ転送プロトコルや、データベース接続によってデータを収集する。データの収集に用いるプロトコルは、業務サーバ群１０４の各サーバの提供するプロトコルに従う。本実施形態においては、そのプロトコルは限定しない。また、業務サーバ群１０４は、稼働中にデータの追加、及び更新が行われていくため、データ収集サーバ１０３は、定期的に業務サーバ群１０４からデータの収集を行う。これは、例えばＬｉｎｕｘ（登録商標）のｃｒｏｎｔａｂや、Ｗｉｎｄｏｗｓ（登録商標）タスクスケジューラなどのＯＳの標準機能を利用して行ってもよいし、スケジュール管理機能を有するソフトウェアを利用してもよい。
【００１４】
業務サーバ群１０４は、データ分析とは別の目的で稼働するサーバマシンの集合である。例えば、インターネットを介して顧客に対してＷｅｂサービスを提供するサーバや、自社ユーザの業務を支援する企業向け社内システムが稼働するサーバである。また、近年はユーザ環境で動作するモバイル端末や、プリンタなどの業務機器もインターネットに接続できるようになっている。このようなデバイスから接続され、その管理を行うサーバであってもよい。また、業務サーバ群１０４は、物理的なサーバマシンであってもよいし、仮想環境に構築されたサーバマシンであってもよい。これらのサーバは、それぞれの業務目的のために構築されたサーバであるため、データ分析機能を有していない。そのため、前述のデータ収集サーバ１０３によってこれらのデータを統合的に収集することで初めてデータ分析が可能となる。
【００１５】
管理端末１０５は、管理者が利用する端末である。管理者は、管理端末１０５を利用してＥＴＬ管理サーバ１０１に対して、ルールの変更を指示する。ここで、管理端末１０５は、Ｗｅｂブラウザなどを介してＥＴＬ管理サーバ１０１に接続することが可能であるが、ルールの変更の指示ができればこれに限定されない。
【００１６】
データ利用サーバ群１０６は、データ蓄積サーバ１０２に蓄積されたＥＴＬ実行済のデータを利用するためのサーバ群である。例えば、データ利用サーバ群１０６において、顧客に提供する業務システムのエラーの集計、及び監視を行うことで、業務システムの品質向上のためのデータ分析を行うことができる。また、他の例では、データ利用サーバ群１０６において、多数の端末が送信した使用状況のログからメンテナンスが必要な端末を特定することで、顧客に警告を行う、または顧客先に出向いてメンテナンスを実施するという活用が可能である。
【００１７】
分析端末１０７は、分析者が直接的にデータ蓄積サーバ１０２に蓄積されたデータを参照することで、データ分析を行うための端末である。データ利用サーバ群１０６は、いくつかの特定の目的のためにデータ分析を行うサーバであるのに対し、分析端末１０７では、分析者がさまざまなツールやノウハウを用いてデータ分析を行う。データの活用は、まずはデータを検証することから開始することが定石である。そのため、分析端末１０７で得られたデータの知見をもとに、データ利用サーバ群１０６を設計、構築することで効果的にデータの活用が可能となる。
なお、図１では、各サーバ１０１〜１０４、及び１０６は、物理的に別々のサーバとして記載しているが、同一の物理サーバ内に各サーバを仮想サーバ機能として配置してもよい。
【００１８】
図２は、本実施形態に係るＥＴＬ管理サーバ１０１、データ蓄積サーバ１０２、データ収集サーバ１０３、業務サーバ群１０４、及びデータ利用サーバ群１０６のハードウェア構成を示す図である。
図２において、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）２０２は、装置全体の制御を行う。ＣＰＵ２０２は、ハードディスク（ＨＤＤ）２０５に格納されているアプリケーションプログラム、及びＯＳ等を実行し、Ｒａｎｄａｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ＲＡＭ）２０３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（ＲＯＭ）２０４は、記憶手段であり、内部には、基本Ｉ／Ｏプログラム等の各種データを記憶する。ＲＡＭ２０３は、一時記憶手段であり、ＣＰＵ２０２の主メモリ、ワークエリア等として機能する。ＨＤＤ２０５は、外部記憶手段の一つであり、大容量メモリとして機能し、Ｗｅｂブラウザ等のアプリケーションプログラム、サービス群のプログラム、ＯＳ、及び関連プログラム等を格納している。ディスプレイ２０６は、表示手段であり、キーボード２０７から入力したコマンド等を表示するものである。インターフェース２０８は、外部装置Ｉ／Ｆであり、プリンタ、ＵＳＢ機器、または周辺機器等を接続する。キーボード２０７は、指示入力手段である。システムバス２０１は、装置内におけるデータの流れを司るものである。ネットワークインターフェースカード（ＮＩＣ）２０９は、該インターフェース２０９、インターネット１００を介して外部装置とのデータのやり取りを行う。
なお、上記コンピュータの構成は一例であり、図２の構成例に限定されるものではない。例えば、データやプログラムの格納先は、その特徴に応じてＲＯＭ２０４、ＲＡＭ２０３、またはＨＤＤ２０５などに変更することも可能である。
【００１９】
図３は、ＥＴＬ管理サーバ１０１の提供する機能モジュールを説明するためのソフトウェアブロック図である。
制御部３０１は、以下に説明する機能モジュールを呼び出してＥＴＬを実行するメイン実行部である。ルール管理部３０２は、ＥＴＬの実行を制御するためのルールを管理する。ルール管理部３０２は、データベースまたはＸＭＬなどのテキストファイルとしてルールを保持する。
【表１】
2016091429.tif 000003
【００２０】
ここで、ルール管理部３０２で管理するルールについて表Ａを用いて説明する。
スケジュール列は、定期的にＥＴＬを実行するためのルール毎のスケジュールを表している。例えば、表Ａにおいて、Ｐｅｒ  Ｄａｙと示されているものは、毎日ＥＴＬを実行するスケジュールである。また、Ｐｅｒ  ３ｈｏｕｒと示されているものは３時間ごとにＥＴＬを実行するスケジュールである。分析者ができるだけリアルタイムなデータを分析できるように、データ収集サーバ１０３によるデータの収集頻度に応じてスケジュール設定を行うことが好ましい。
【００２１】
入力パスルール列は、入力データのファイルパスのルールを示している。例えば、表Ａの１行目のルールにおいては、／ｄａｔａ／ｄｅｖｉｃｅ／ＤＥＶＩＣＥ＿ＡＬＡＲＭ＿＊．ｃｓｖに該当するファイルがＥＴＬ対象になる。ここで、＊とは任意の文字列を表わしている。表Ａにおいては、入力パスルール、／ｄａｔａ／ｄｅｖｉｃｅ／ＤＥＶＩＣＥ＿ＡＬＡＲＭ＿＊．ｃｓｖに該当するＥＴＬは１〜３行目であるため、ＥＴＬ管理サーバ１０１は、３つのＥＴＬを実行する。
【００２２】
出力パスルール列は、出力データのファイルパスのルールを示している。ＥＴＬ管理サーバ１０１は、ＥＴＬ実行ファイルによる実行結果のデータを、出力パスルール列で定義されたパスに保存する。ここで、表Ａの５行目の入力パスルールは、４行目の出力パスルールと一致していることがわかる。これは、／ｄａｔａ／ｄｅｖｉｃｅ／ＤＥＶＩＣＥ＿ＥＮＶＩＲＯＮＭＥＮＴ＿＊．ｃｓｖに関しては、４行目のＥＴＬを実行した後、さらに５行目のＥＴＬが実行されることを示している。
【００２３】
ＥＴＬ実行ファイルパス列は、ＥＴＬを実行するための実行モジュールのファイルパスを示している。ＥＴＬ管理サーバ１０１は、ＥＴＬ実行ファイルパスで示される実行ファイルを実行することで、入力ファイルに対してＥＴＬを適用することができる。
プライマリ列は、過去に蓄積され、既にルール管理部３０２が管理するルールに従うＥＴＬが行われた入力データに対しても、チェックが入ったルールに従うＥＴＬを実行するか否かを表している。なお、プライマリ列にチェックがあった場合の処理については、図９のフローチャートで詳述する。
データ読込部３０３は、ＥＴＬ対象のデータをデータ蓄積サーバ１０２から読み込む機能を提供する。データ蓄積サーバ１０２は、ＨＴＴＰ、ＦＴＰ、または一般的なデータベース接続方式などの１つ以上のデータ公開方式を有している。データ読込部３０３は、データ蓄積サーバ１０２の公開方式に合わせてデータを読み込み、一時的に中間データ管理部３０５に保存する。
【００２４】
データ保存部３０４は、ＥＴＬ実行済の出力データをデータ蓄積サーバ１０２に保存するための機能を有する。データ読込部３０３と同様に、データ蓄積サーバ１０２の公開方式に合わせてＥＴＬ実行済のデータを保存する。
中間データ管理部３０５は、ＥＴＬの実行途中のデータを保存するための記憶領域である。
実行ファイル格納部３０６は、ＥＴＬ実行ファイルを格納するための記憶領域である。ＥＴＬ実行ファイルは、例えばスクリプトや実行ファイル（ｅｘｅ、ｊａｒ）などのファイル形式であるがこれに限定しない。
【００２５】
ＥＴＬ実行部３０７は、実行ファイル格納部３０６に格納されたＥＴＬ実行ファイルを起動してＥＴＬを実行する。ＥＴＬとは、例えば文字コード変換、改行コード削除、全角／半角変換、ｎｕｌｌ値挿入、桁揃え、及び簡単な集計などの処理であるが、これらに限定しない。また、これらの処理を複数組み合わせたものであってもよい。
ルール受付部３０８は、管理端末１０５からの要求に従って、ルールの追加を受け付ける。ここで、ルール受付部３０８が管理端末１０５からルールの追加を受け付けるための管理画面について図６及び７を用いて説明する。
【００２６】
図６は、ＥＴＬ管理サーバのルール管理部３０２が、管理しているルールを管理端末１０５に表示する一覧画面を示す図である。
ルール一覧６０１では、ルール管理部３０２が管理するルールを一覧表示させることができる。ユーザが反映ボタン６０３を押下（操作）すると、ルール受付部３０８は、プライマリ列にチェックが入っていたルールに関して、過去にデータ蓄積サーバ１０２に蓄積された入力データに対してもＥＴＬを実行する。上記処理については、図９のフローチャートを用いて詳述する。
【００２７】
本明細書において、プライマリとは、データ蓄積サーバ１０２に格納されたデータの中で、データの活用のためにもっとも相応しいデータであることを示す真偽値である。プライマリとして設定されたデータをプライマリデータと呼ぶこととする。プライマリデータは、多くのデータ利用サーバ群１０６や分析端末１０７に利用されるため、過去に蓄積されたデータに関しても常に取得できることが望ましい。従来は、過去に蓄積されたデータに関しては手動ですべてＥＴＬを実行することが必要であったが、本実施形態のようにプライマリとして指定された場合に、ＥＴＬ管理サーバ１０１が自動的にＥＴＬを実行することで、手動による労力を削減することができる。
【００２８】
また、プライマリデータは、永続的に取得できる必要のあるデータであるが、プライマリデータでないデータに関しては、一時的に取得できればよい。ここで、プライマリデータでないデータに関してもＥＴＬを実行し続ける理由は、すでにデータ利用サーバ群１０６がシステム結合されていた場合にも、データ利用サーバ群１０６を継続的に利用できるようにするためである。ただし、プライマリデータでないデータは、常に過去にわたって全て蓄積しておく必要はない。そのため、定期的に削除が必要となる。プライマリデータでないデータの削除については、図１０のフローチャートを用いて後述する。
【００２９】
ユーザが新規追加ボタン６０２を押下すると、ルール受付部３０８は、図７に示す新規追加画面７００を表示する。
図７のルール入力欄７０１では、ユーザが新規ルールの追加に必要な情報を入力することができる。チェックボックス７０２は、ＥＴＬを実行した結果データをプライマリデータとして登録するか否かを指定するためのチェックボックスである。ユーザがＯＫボタン７０３を押下することで、ルールがルール管理部３０２に登録される。
ここで、チェックボックス７０２にチェックが入っていた場合は、図６の一覧画面６００でプライマリ列にチェックが入っていた場合と同様に、過去にデータ蓄積サーバ１０２に蓄積された入力データに対してもＥＴＬを実行する。このときの処理に関しても、図９に示すフローチャートと同様である。
【００３０】
図４は、データ蓄積サーバ１０２の提供する機能モジュールを説明するためのソフトウェアブロック図である。
データ格納部５０１は、ＥＴＬ実行前の入力データを記憶する第１記憶手段、及びＥＴＬ実行後の加工済みデータを記憶する第２記憶手段として機能する記憶領域である。データ格納部５０１は、一般的には物理的な記憶媒体であるＨＤＤやデータベースであるが、例えば仮想化されたオブジェクトストレージであってもよい。以下、表Ｂ〜表Ｅを用いてデータ格納部５０１に格納される入力データ及び出力データの一例を示す。
【表２】
2016091429.tif 000004
【００３１】
表Ｂは、データ収集サーバ１０３が業務サーバ群１０４から収集したアラーム履歴データの例である。アラーム履歴とは、業務サーバ群１０４と接続された多数のデバイスに何らかの問題が発生した際に業務サーバ群１０４に通知するアラームの履歴のことである。本実施形態においては、表Ｂで表わされるデータは、データ蓄積サーバ１０２の、／ｄａｔａ／ｄｅｖｉｃｅ／ＤＥＶＩＣＥ＿ＡＬＡＲＭ＿＊．ｃｓｖで示されるパスに保存される。
【００３２】
国コード列は、業務サーバ群１０４と接続されているデバイスが稼働している国を表わすコードである。発生日時分列は、アラームが発生した日時分のことである。解除日時分列は、アラームがユーザ、またはサービスマンに解除された日時分のことである。データ送信日時分列は、デバイスがアラーム履歴を業務サーバ群１０４に送信した日時分のことである。機種列は、デバイスの機種を識別するためのコードである。機番列は、デバイスのＩＤ（識別子）である。アラームコード列は、アラームの発生区分コードである。アラームレベル列は、アラームの深刻さを表わす数値である。
【００３３】
上記のアラーム履歴データにおいて、国コード列、機種列の２行目及び５行目に＜LF＞という改行コードが含まれている。また、５行目にはさらに＜ＣＲ＞という改行コードが含まれている。これは、不正な改行コードが含まれている一例である。ＥＴＬ管理サーバ１０１は、この不正な改行コードを取り除くというＥＴＬを実行する。本実施形態において、表Ａの１行目が表Ｂのデータに対して上述したＥＴＬを実行するためのルールである。ＥＴＬ実行ファイルパスは、／ｖａｒ／ｅｔｌ／ｔｒａｎｓｆｏｒｍ＿ｒｃｄ．ｊａｒになっているが、このＥＴＬ実行ファイルを表Ｂのデータに対して実行した結果が表Ｃのデータである。
【表３】
2016091429.tif 000005
【００３４】
表Ｃでは、表Ｂと比較して、２行目及び５行目から、＜ＬＦ＞という不正な改行コードが取り除かれていることがわかる。このような不正な改行コードの混入は、デバイス内でデータを生成する際のソフトウェアバグや、デバイスとデータ収集サーバ１０３とのＯＳの不一致などにより発生する。不正な改行コードが混入した場合に、例えば分析端末１０７やデータ利用サーバ群１０６でデータを分析しようとした際に、データを正しく読み込めない事象が発生する。ＥＴＬ管理サーバ１０１によってこのような不正な改行コードを取り除くことで、分析端末１０７やデータ利用サーバ群１０６でデータを正しく読み込むことが可能となる。
【００３５】
ここで、表Ｃの５行目には、＜ＣＲ＞という改行コードが取り除かれていないことが分かる。これは、ＥＴＬ実行ファイルである／ｖａｒ／ｅｔｌ／ｔｒａｎｓｆｏｒｍ＿ｒｃｄ．ｊａｒの実装時には、＜ＣＲ＞という改行コードがデータに含まれるという想定がなかったために、上述したＥＴＬでは取り除かれずに残ってしまった改行コードである。このような場合には、ＥＴＬ実行ファイルを新規に実装し、ルールを追加する必要がある。表Ａの３行目が追加されたルールを表している。３行目のルールのＥＴＬ実行ファイル／ｖａｒ／ｅｔｌ／ｔｒａｎｓｆｏｒｍ＿ｒｃｄ２．ｊａｒによるＥＴＬ処理では、＜ＣＲ＞という改行コードについても削除することが可能である。ここで、ＥＴＬ管理サーバ１０１でのプライマリデータは、３行目のルールによってＥＴＬを実行したデータとすればよい。
【表４】
2016091429.tif 000006
【００３６】
表Ｄは、データ収集サーバ１０３が業務サーバ群１０４から収集したデバイス内環境データの例である。本実施形態においては、表Ｄで表わされるデータは、データ蓄積サーバ１０２に、／ｄａｔａ／ｄｅｖｉｃｅ／ＤＥＶＩＣＥ＿ＥＮＶＩＲＯＮＭＥＮＴ＿＊．ｃｓｖで示されるパスに保存される。
【００３７】
国コード列は、業務サーバ群１０４と接続されているデバイスが稼働している国を表わすコードである。データ生成日時分列は、機内温度、機内湿度、及び定着ローラ表面温度を測定し、記録した日時分のことである。データ送信日時分列は、デバイスがデバイス内環境データを業務サーバ群１０４に送信した日時分のことである。機種列は、デバイスの機種を識別するためのコードである。機番列は、デバイスのＩＤ（識別子）である。機内温度列は、デバイスの内部の温度である。機内湿度列は、デバイスの内部の湿度である。定着ローラ表面温度列は、デバイス内の定着ローラの表面温度のことである。
【００３８】
上記のデバイス内環境データにおいて、２行目及び６行目の定着ローラ表面温度列の値が異常に高温となっている。これは、デバイス内の温度計測機器が故障しており、サービスマンにパーツ交換が施されていないために不正なデータとなっている一例である。ＥＴＬ管理サーバ１０１は、この不正なデータをすべてｎｕｌｌ値に変換するというＥＴＬを実行する。
【表５】
2016091429.tif 000007
【００３９】
表Ｅは、ＥＴＬ管理サーバ１０１がＥＴＬを実行した結果のデバイス内環境データの例である。表Ｅでは、表Ｄと比較して、２行目及び７行目の機内温度、機内湿度、及び定着ローラ表面温度の各列のデータがｎｕｌｌ値となっていることがわかる。表Ｄのような異常な値がデータに混入している場合に、データ利用サーバ群１０６及び分析端末１０７での分析の際に正しい分析結果を得ることができない。例えば、統計分析による外れ値検出を行うことができない。そのため、ＥＴＬ管理サーバ１０１によるＥＴＬによってあらかじめｎｕｌｌ値としておくことによって、データ利用サーバ群１０６及び分析端末１０７での分析対象から除外することができ、分析結果の精度向上が期待できる。
以上が、図５に示すデータ格納部５０１に格納されるデータの例である。
【００４０】
図４のデータ蓄積サーバ１０２の説明に戻る。データ転送部５０２は、ＥＴＬ管理サーバ１０１からのデータの入出力要求、及びデータ収集サーバ１０３からのデータ入力要求に応じて、データ格納部５０１に格納されたデータを転送する。また、データ利用サーバ群１０６及び分析端末１０７等の分析を行う分析システムからのデータ出力要求に応じて、データ格納部５０１に格納されたデータを提供する。データ転送のプロトコルは、例えばＨＴＴＰやＦＴＰ、データベース接続などであるが、これに限定されない。
【００４１】
図５は、データ収集サーバ１０３の提供する機能モジュールを説明するためのソフトウェアブロック図である。
制御部４０１は、定期的に収集ルール管理部４０４を確認し、収集すべきデータが存在するか否かを確認する。収集すべきデータが存在していた場合には、業務サーバ群１０４からデータを収集し、データ蓄積サーバ１０２に格納する。
【００４２】
データ収集部４０２は、業務サーバ群１０４からデータを取得する。データの取得に用いるプロトコルは、業務サーバ群１０４の提供するプロトコルに従う。データ格納部４０３は、データ収集部４０２によって取得したデータを、データ蓄積サーバ１０２に格納する。データ格納部４０３がデータを格納するためのプロトコルは、データ蓄積サーバ１０２に従う。収集ルール管理部４０４は、業務サーバ群１０４からデータを収集するための収集ルールを管理するデータベースである。ここで、表Ｆを用いて収集ルールについて説明する。
【表６】
2016091429.tif 000008
【００４３】
スケジュール列は、データ収集を実行するスケジュールを表している。例えば、表Ｆにおいて、Ｐｅｒ  Ｄａｙと示されているものは、毎日データを収集するスケジュールである。また、Ｐｅｒ  ３ｈｏｕｒと示されているものは、３時間ごとにデータを収集するスケジュールである。業務サーバ群１０４がデータを提供する頻度、スケジュールに応じてデータを収集することが望ましい。
取得先列は、データ取得先の業務サーバ群１０４のエンドポイントを示している。１行目は、ＨＴＴＰによる取得先を例示し、２行目は、ＦＴＰによる取得先を例示している。
【００４４】
蓄積パスルール列は、データ蓄積サーバ１０２への格納先のパスを示している。データの格納時は、＊で示される箇所には取得時の日時を文字列として挿入することが望ましい。例えば、１行目に示される収集ルールにより、２０１４年９月３０日に取得したデータは、／ｄａｔａ／ｄｅｖｉｃｅ／ＤＥＶＩＣＥ＿ＡＬＡＲＭ＿２０１４０９３０．ｃｓｖというパスに保存される。
プロトコル列は、データ収集部４０２が業務サーバ群１０４からのデータを収集する際に用いるプロトコルを示している。このように、プロトコルを切り替えることによって、多様な業務サーバ群１０４からデータを取得することができる。
【００４５】
次に、ＥＴＬ管理サーバ１０１によるＥＴＬの実行について、図８のフローチャート図を用いて説明する。
ＥＴＬ管理サーバ１０１の制御部３０１は、定期的にステップＳ８０１〜ステップＳ８０６までの処理を呼び出す。その周期は限定しないが、本実施形態では数分程度である。
【００４６】
ステップＳ８０１で、ＥＴＬ管理サーバ１０１の制御部３０１は、ルール管理部３０２に問い合わせてルールを参照する。
ステップＳ８０２で、ＥＴＬ管理サーバ１０１の制御部３０１は、スケジュールに合致するルールについて、ステップＳ８０３〜ステップＳ８０５の処理を適用する。例えば、表Ａにおいて、スケジュール列にＰｅｒ  Ｄａｙと記載されているルールであれば、前回のＥＴＬ実行時から１日以上経過していた場合にスケジュールに合致するものとする。スケジュールの合致の判定は、独自の機能として実装してもよいし、Ｌｉｎｕｘ（登録商標）でのＣｒｏｎｔａｂ機能や、Ｗｉｎｄｏｗｓ（登録商標）でのタスクスケジューラ機能を利用してもよい。
【００４７】
ステップＳ８０３で、ＥＴＬ管理サーバ１０１の制御部３０１は、データ蓄積サーバ１０２に問い合わせて、ＥＴＬ実行前の入力データを取得する。
ステップＳ８０４で、ＥＴＬ管理サーバ１０１の制御部３０１は、ＥＴＬ実行部３０７を呼び出す。ＥＴＬ実行部３０７は、実行ファイル格納部３０６に格納されているＥＴＬ実行ファイルを取得し、入力データに対してＥＴＬを実行する。ここで、ＥＴＬ実行ファイルは、実行ファイル格納部３０６上で、表ＡのＥＴＬ実行ファイルパス列に記載のパスに格納されている。
【００４８】
ステップＳ８０５で、ＥＴＬ管理サーバ１０１の制御部３０１は、ＥＴＬを実行した出力データを、データ蓄積サーバ１０２に転送する。データ蓄積サーバ１０２は、出力データを受け取り、データ格納部５０１に保存する。このとき、データ格納部５０１内での保存先は、表Ａの出力パスルール列に従う。
【００４９】
以上説明したように、ＥＴＬ管理サーバ１０１は、ルール管理部３０２に保存されたルールに従って定期的にＥＴＬを実行することで、継続的にデータ収集サーバ１０３が取得するデータに対してＥＴＬを実行することができる。
【００５０】
次に、管理端末１０５のユーザが、ＥＴＬ管理サーバ１０１のルール管理部３０２が提供する一覧画面６００で反映ボタン６０３を押下した際の処理について、図９のフローチャートを用いて説明する。なお、新規追加画面７００におけるＯＫボタン７０３を押下した際も同様の処理が適用される。
【００５１】
ステップＳ９０１で、ＥＴＬ管理サーバ１０１の制御部３０１は、ルール管理部３０２に新規登録、または変更されたルールを登録する。
ステップＳ９０２で、ＥＴＬ管理サーバ１０１のルール管理部３０２は、新規登録、または変更されたルールがプライマリ指定されているか否かを判定する。プライマリ指定されていた場合は、ステップＳ９０３へ処理を分岐する。プライマリ指定されていなかった場合は、本フローチャートの処理を終了する。
ステップＳ９０３で、ＥＴＬ管理サーバ１０１の制御部３０１は、過去にデータ蓄積サーバ１０２に蓄積された入力データのうち、表Ａの入力パスルールに合致するすべてのデータを取得する。そして、ＥＴＬ管理サーバ１０１の制御部３０１は、ＥＴＬ実行部３０７を呼び出す。ＥＴＬ実行部３０７は、ステップＳ９０３で取得したすべての入力データに対して、実行ファイル格納部３０６から取得したＥＴＬ実行ファイルを実行する。
ステップＳ９０４で、ＥＴＬ管理サーバ１０１の制御部３０１は、ステップＳ９０３でＥＴＬを実行したすべての出力データを、データ蓄積サーバ１０２に転送する。データ蓄積サーバ１０２は、出力データを受け取り、データ格納部５０１に保存する。このとき、保存先は表Ａの出力パスルールに従う。
【００５２】
なお、新規登録、または変更されたルールがプライマリ指定されていた場合に、ステップＳ９０３において取得する入力データが、その他のルールを実行した結果であった場合には、その関連するルールについてもステップＳ９０３〜Ｓ９０４を実行してもよい。例えば、表Ａにおいて、５行目のルールがプライマリ指定されており、５行目の入力パスルールは４行目の出力パスルールと一致している。このような場合に、４行目のルールがプライマリ指定されていなくても、過去に蓄積されたデータに対して４行目のルールを実行するようにしてもよい。
【００５３】
以上説明したように、図９の処理により、ユーザが管理端末１０５を介してルールを追加する際に、追加するルールがプライマリ指定したルールであった場合には、過去に蓄積されたすべてのデータに対して自動的にＥＴＬを実行することができる。例えば、既にルール管理部３０２に管理されている第１のルールに関連する第２のルールを新たに追加した場合に、第２のルールが追加される前に、第１のルールに従って加工が行われた入力データに対しても、第２のルールに従う加工を行うことができる。これにより、２つの関連するルールを同一の期間の入力データに対して実行することができるため、常に信頼度の高い、有用なデータを提供すること可能となる。従来の技術では、手動でＥＴＬを実行し、その結果データを管理する必要があったが、本実施形態によりその管理の手間を削減することができる。
【００５４】
次に、プライマリ指定されなかった出力データ（非プライマリデータ）に関して、一定期間経過後に削除する処理について、図１０のフローチャートを用いて説明する。
ＥＴＬ管理サーバ１０１の制御部３０１は、定期的にステップＳ１００１〜ステップＳ１００６までの処理を呼び出す。その周期は限定しないが、本実施形態では数分程度である。
【００５５】
ステップＳ１００１で、ＥＴＬ管理サーバ１０１の制御部３０１は、データ蓄積サーバ１０２に蓄積されたＥＴＬを実行した結果の出力データすべてに対してステップＳ１００２〜ステップＳ１００５の処理を繰り返す。
ステップＳ１００２で、ＥＴＬ管理サーバ１０１の制御部３０１は、出力データの生成日時を参照する。出力データの生成日時は、出力データのファイルのプロパティを参照することで取得できる。
ステップＳ１００３で、ＥＴＬ管理サーバ１０１の制御部３０１は、出力データを生成するためのルールを、ルール管理部３０２に問い合わせてルールを参照することで取得する。例えば、出力データが出力パスルール／ｄａｔａ／ｄｅｖｉｃｅ／ｅｔｌ／ＤＥＶＩＣＥ＿ＡＬＡＲＭ＿ＥＴＬ＿ＴＲＡＮＳＦＯＲＭ＿ＲＣＤ＿２＿＊．ｃｓｖに合致する場合には、表Ａの３行目のルールによって生成された出力データであることがわかる。
ステップＳ１００４で、ＥＴＬ管理サーバ１０１の制御部３０１は、出力データが削除対象であるか否かを判定する。削除対象となるのは、ステップＳ１００２で取得した生成日時が一定期間以上過去であり、ステップＳ１００３で取得したルールで、プライマリ指定されていないものである。ここで、一定期間以上過去であるとは、例えば１か月程度の期間を想定しているがこれに限定されず、所定の時間に設定すればよい。削除対象となる期間は、データを利用する分析端末１０７や、データ利用サーバ群１０６の取得頻度に応じてあらかじめ設定されることが望ましい。削除対象であった場合にはステップＳ１００５へ処理は進み、削除対象でなかった場合にはステップＳ１００６へ処理を分岐させる。
ステップＳ１００６で、ＥＴＬ管理サーバ１０１の制御部３０１は、削除対象となった出力データのファイルを削除する。
【００５６】
以上説明したように、図１０の処理により、プライマリ指定されていないデータに関しては、ＥＴＬ管理サーバ１０１が一定期間経過後に自動的に削除する。分析端末１０７や、データ利用サーバ群１０６のユーザは、プライマリ指定されていないデータも引き続き利用する必要があるが、プライマリデータではないので永続的に保持する必要がないためである。上記により、プライマリデータは、常に取得できるようにしつつ、既存のユーザやシステムに影響を与えずに、かつデータ蓄積容量を削減することが可能である。
【００５７】
以上のように、本実施形態によれば、ＥＴＬを実行するためのルール追加時に、管理者が手動でＥＴＬを実行する必要がなく、常に信頼度の高いＥＴＬ実行結果の出力データを提供することができる。
【００５８】
（第２実施形態）
次に、本発明の第２実施形態に係る情報処理システムについて説明する。第１実施形態では、ＥＴＬのルール追加時に、自動的に過去に蓄積されたデータに対してＥＴＬを実行することが可能である。本実施形態では、第１実施形態で実行される処理を管理者の所望の台数のサーバにおいて実行する方法について説明する。なお、第１実施形態と同一の構成のものには同一の符号を付し、説明を省略する。
【００５９】
図１１は、本実施形態に係るシステム構成を示す図である。
ＥＴＬ実行サーバ群１０８は、ＥＴＬを実行するためのサーバ群である。ＥＴＬ管理サーバ１０１は、ルール追加時に実行される過去にデータ蓄積サーバ１０２に蓄積された入力データに対するＥＴＬを、ＥＴＬ実行サーバ群１０８に指示することにより短時間で実行することが可能となる。過去に蓄積されたアプリケーションログや、デバイスのデータは、非常に大規模になるため、このように過去に蓄積されたデータに対するＥＴＬは複数のサーバで実行することが望ましい。
【００６０】
図１２は、管理者がＥＴＬを実行するサーバ数を設定するサーバ数指定画面１２００を示す図である。
サーバ数指定画面１２００は、ＥＴＬ管理サーバ１０１のルール管理部３０２が提供する一覧画面６００で管理者が反映ボタン６０３を押下した際、または、新規追加画面７００でＯＫボタン７０３を押下した際に表示される。
【００６１】
サーバ数入力欄１２０１は、管理者がＥＴＬを実行するための所望のサーバ数を指定するための入力欄である。管理者は、追加したＥＴＬのルールに基づいて出力されるデータを利用する開始期限と、サーバを複数台起動するコストとを勘案してサーバ数を指定する。
ＯＫボタン１２０２は、過去に蓄積されたデータに対してＥＴＬを開始するためのボタンである。管理者がＯＫボタン１２０２を押下すると、図９のフローチャートで示したＥＴＬが開始される。
【００６２】
以上のように、本実施形態によれば、管理者の指定したサーバ数で過去に蓄積されたデータに対するＥＴＬを実行することが可能となり、短時間でＥＴＬの実行を完了させることができる。
【００６３】
次に、本発明の第３実施形態に係るシステムについて説明する。第２実施形態では、管理者の所望の台数のサーバにおいて、過去に蓄積されたデータに対するＥＴＬを実行することが可能である。これに対して、本実施形態では、過去に蓄積されたデータに対してＥＴＬを実行する際に、管理者がＥＴＬを完了させるまでの期限を入力することで、自動的にＥＴＬ実行サーバ数を算出し、ＥＴＬを実行する方法について説明する。なお、第１及び第２実施形態と同一の構成のものには同一の符号を付し、説明を省略する。
【００６４】
図１３は、管理者がＥＴＬを終了させるまでの期限を設定するＥＴＬ期限指定画面１３００を示す図である。
ＥＴＬ期限指定画面１３００は、ＥＴＬ管理サーバ１０１のルール管理部３０２が提供する一覧画面６００で管理者が反映ボタン６０３を押下した際、または、新規追加画面７００でＯＫボタン７０３を押下した際に表示される。
期限入力欄１３０１は、管理者がＥＴＬの実行を終了させるまでの期限を指定するための入力欄である。管理者は、追加したＥＴＬのルールに基づいて出力されるデータを利用する開始期限に応じて期限を入力することができる。
算出結果１３０２は、管理者が期限入力欄１３０１で指定した期限までにＥＴＬを完了させるために必要なサーバ数を表示する画面である。
ＯＫボタン１３０３は、過去に蓄積されたデータに対してＥＴＬを開始するためのボタンである。管理者がＯＫボタン１３０３を押下すると、図９のフローチャートで示したＥＴＬを、算出したサーバ数で開始する。
ＥＴＬ実行に要する時間は、ＥＴＬ実行ファイルの処理内容によって異なる。従って、ＥＴＬを完了させるために必要なサーバ数も、ＥＴＬ実行ファイルの処理内容によって異なる。ここで、サーバ数の算出方法について以下で説明する。
【００６５】
図１４は、指定された期限までにＥＴＬの実行を完了させるために必要なサーバ数を算出する処理を説明するフローチャートである。
ステップＳ１４０１で、ＥＴＬ管理サーバ１０１のルール管理部３０２は、追加されるルールを参照する。
ステップＳ１４０２で、ＥＴＬ管理サーバ１０１のルール管理部３０２は、ステップＳ１４０１で参照したルールの、入力パスルールをもとに試行データを取得する。試行データとは、ＥＴＬの実行に要するサーバ数を算出するために、ＥＴＬ実行時間を計測するための入力データである。入力パスルールに指定されているデータであれば、任意のデータを試行データとして取得できる。
ステップＳ１４０３で、ＥＴＬ管理サーバ１０１のルール管理部３０２は、ＥＴＬ実行部３０７を呼び出して試行データに対してＥＴＬを実行する。
ステップＳ１４０４で、ＥＴＬ管理サーバ１０１のルール管理部３０２は、ステップＳ１４０３におけるＥＴＬ実行に要した時間と、試行データのデータ量から、１ＭＢあたりのＥＴＬ実行時間を算出する。
ステップＳ１４０５で、ＥＴＬ管理サーバ１０１のルール管理部３０２は、データ読込部３０３を呼び出して、データ蓄積サーバ１０２に過去に蓄積されたＥＴＬ対象のデータのデータ量を取得する。
ステップＳ１４０６で、ステップＳ１４０４において算出した１ＭＢあたりのＥＴＬ実行時間と、ステップＳ１４０５で取得したＥＴＬ対象のデータのデータ量をもとに、ＥＴＬ実行に必要なサーバ数を算出する。ＥＴＬは、各行のＥＴＬを単純に別々のサーバで処理すればよいので、必要なサーバ数は、１ＭＢあたりのＥＴＬ実行時間から容易に算出できる。例えば、１ＭＢあたりのＥＴＬ実行時間が０．２秒で、ＥＴＬ対象のデータのデータ量が１００ＧＢであった場合には、１台で実行した場合の実行時間は、０．２＊１００，０００＝１０，０００秒である。ユーザが１時間（３６００秒）以内にＥＴＬを完了させたい場合には、１０，０００／３６００＝２．７８となるので、サーバ数は３台となる。
【００６６】
以上のように、本実施形態によれば、試行データに対するＥＴＬ実行時間を算出することにより、管理者が指定した期限までにＥＴＬを完了させ、取得することができる。
【００６７】
（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００６８】
以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。
【図１】
2016091429.tif 000009
【図２】
2016091429.tif 000010
【図３】
2016091429.tif 000011
【図４】
2016091429.tif 000012
【図５】
2016091429.tif 000013
【図６】
2016091429.tif 000014
【図７】
2016091429.tif 000015
【図８】
2016091429.tif 000016
【図９】
2016091429.tif 000017
【図１０】
2016091429.tif 000018
【図１１】
2016091429.tif 000019
【図１２】
2016091429.tif 000020
【図１３】
2016091429.tif 000021
【図１４】
2016091429.tif 000022