JP7218797B2 - 情報処理装置およびａｐｉ使用履歴表示プログラム - Google Patents

Description

本発明は、情報処理装置およびＡＰＩ使用履歴表示プログラムに関する。

近年、複数のソフトウェアコンポーネントをＡＰＩ（Application Programming Interface）を用いて連携することで構成されたコンピュータサービスが実現されている。そして、多種多様なＡＰＩが提供されている。

図９はＡＰＩを用いて構成されたコンピュータシステムの構成を例示する図である。

この図９に示す例においては、決済システム，通信・ＳＭＳ（Short Message Service）システムおよび地図システムのそれぞれとＡＰＩを介して接続されたコンピュータシステム５００を示している。

コンピュータシステム５００は、例えば、地図システム用のＡＰＩを介して地図システムの地図機能を呼び出し、このＡＰＩを介して地図システムが提供する地図機能を使用することができる。

システム管理者においては、複数のＡＰＩについて、それらの使用状況を把握したいという要求がある。

従来においては、ＡＰＩの使用履歴を個別のログデータを見て、例えば、使用回数や使用日時を管理している。

特開２０１５－１０６２６８号公報 特開２０１７－２２８２５７号公報 特開２０１８－１４７３５０号公報

しかしながら、このような従来のＡＰＩ管理方法では、ＡＰＩがどのように用いられたかや、実際に役に立ったものであるか等を把握することができず利便性が低いという課題がある。

１つの側面では、本発明は、ＡＰＩの使用状況を容易に把握できるようにすることを目的とする。

このため、この情報処理装置は、複数のＡＰＩを用いるコンピュータサービスの利用履歴データから前記ＡＰＩの実行回数を抽出し、前記ＡＰＩの実行回数に応じて、前記ＡＰＩに対する表示形態を決定する表示形態決定部と、前記複数のＡＰＩのそれぞれに対応するノードを表す有向グラフにおいて、決定された前記表示形態で前記ＡＰＩに対応する前記ノードを表示させる表示制御部とを備える。

一実施形態によれば、ＡＰＩの使用状況を容易に把握できる。

実施形態の一例としてのコンピュータシステムの構成を模式的に示す図である。 実施形態の一例としてのコンピュータシステムのハードウェア構成を示す図である。 実施形態の一例としてのコンピュータシステムのログ管理データベースによって管理されるテーブルのレコードを例示する図である。 実施形態の一例としてのコンピュータシステムのログ解析部による解析方法を説明するための図である。 実施形態の一例としてのコンピュータシステムのログ解析部によるＡＰＩ呼び出しパターン毎の発生回数の管理方法を例示する図である。 実施形態の一例としてのコンピュータシステムのログ解析部によるＡＰＩ呼び出しパターン毎の発生回数の管理方法を例示する図である。 実施形態の一例としてのコンピュータシステムにおける出力画面を例示する図である。 実施形態の一例としてのコンピュータシステムにおける処理を説明するためのフローチャートである。 ＡＰＩを用いて構成されたコンピュータシステムの構成を例示する図である。

以下、図面を参照して本情報処理装置およびＡＰＩ使用履歴表示プログラムに係る実施の形態を説明する。ただし、以下に示す実施形態はあくまでも例示に過ぎず、実施形態で明示しない種々の変形例や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。また、各図は、図中に示す構成要素のみを備えるという趣旨ではなく、他の機能等を含むことができる。

（Ａ）構成
図１は実施形態の一例としてのコンピュータシステム１の構成を模式的に示す図、図２はそのハードウェア構成を示す図である。図２においては、主に管理装置１０のハードウェア構成を詳細に示す。

コンピュータシステム１は、図１に示すように、管理装置１０およびコンピュータサービス２０を備える。

コンピュータサービス２０は、サービス利用者（エンドユーザ）に利用されるサービスであって、複数種類のアプリケーションプログラム（以下、単にアプリケーションという）を組み合わせて構成されている。以下、コンピュータサービス２０を単にサービス２０という場合がある。

サービス２０において、アプリケーション毎にＡＰＩが備えられており、アプリケーションに処理（機能）を実行させるためには、このＡＰＩを介してアプリケーションの処理を呼び出す。図１においてはAPI_A，API_BおよびAPI_Cの３つのＡＰＩが図示されている。

また、アプリケーション間の連携もＡＰＩを介して行なわれる。例えば、一のアプリケーションのＡＰＩが他のアプリケーションのＡＰＩを呼び出し、呼び出されたＡＰＩが他のプログラムを実行させる。また、一のアプリケーションから他のアプリケーションへのデータ授受を行なう場合には、これらのＡＰＩを介してデータの授受が行なわれる。

図２に示すように、管理装置１０はネットワーク１８ａを介して、ネットワーク網５０に接続されている。このネットワーク網５０には、１つ以上のサービス提供サーバ５１および１つ以上のユーザ端末５２が接続されている。ユーザ端末５２をＥＵ５２と表す場合がある。

サービス提供サーバ５１は、サーバ機能を有する情報処理装置（コンピュータ）であり、各種機能を実現するアプリケーションと、当該アプリケーションに対応して設けられたＡＰＩとを提供する。また、サービス提供サーバ５１は、自身が提供するアプリケーション以外のアプリケーションに対応するＡＰＩを提供してもよい。サービス提供サーバ５１をＳＰ５１と表す場合がある。サービス２０はサービス提供サーバ５１によって提供される。複数のサービス提供サーバ５１が協働してサービス２０を提供してもよい。

サービス提供サーバ５１は、例えば、クラウドコンピューティングシステムにおいて、ネットワーク網５０上に仮想的に備えられた仮想サーバであってもよい。

サービス提供サーバ５１においては、アプリケーションやＡＰＩの実行に伴なって、ログの収集が行なわれ、サービス利用者によるサービス２０の利用に関する利用履歴データとして記憶される。

利用履歴データには、例えば、ＡＰＩが実行された時刻の情報や、当該ＡＰＩを使用したサービス利用者を特定するための識別情報（サービス利用者ＩＤ）が含まれる。これらのＡＰＩの使用履歴を示す情報は、ＡＰＩの使用履歴ログとしてサービス提供サーバ５１の記憶装置（図示省略）に記憶される。

本コンピュータシステム１においては、後述の如く、管理装置１０のログ解析部１０２によるＡＰＩの使用履歴ログ解析時に、ＡＰＩを使用したサービス利用者を特定する必要があるため、各サービス利用者に対して一意に識別できる識別情報であるサービス利用者ＩＤ（Identification）が予め設定される。

本コンピュータシステム１においては、例えば、サービス２０の利用開始時に、図示しないログイン画面において、サービス利用者にサービス利用者ＩＤの入力を行なわせる。これにより、サービス２０の利用に際して、ＡＰＩを使用したサービス利用者を特定し、後述するログ収集部１０１により使用履歴ログとして収集することができる。

サービス２０を構成する各ＡＰＩは、当該ＡＰＩを使用したサービス利用者のサービス利用者ＩＤおよび使用時刻の情報を、使用履歴ログとして、サービス２０によって管理される所定の記憶領域（図示省略）に記録する機能を備える。使用履歴ログを記録する記憶領域は、上述の如く、サービス２０を提供するサービス提供サーバ５１の記憶装置であってもよい。

ユーザ端末５２は、サービス利用者が使用する情報処理装置（コンピュータ）である。サービス利用者は、このユーザ端末５２を用いてサービス２０を利用する。
管理装置１０は、サービス２０において使用されているＡＰＩを管理する。
管理装置１０は、例えば、サーバ機能を備える情報処理装置（コンピュータ）である。

図２を参照しながら、実施形態の一例としてのコンピュータシステム１の管理装置１０のハードウェア構成について説明する。

管理装置１０は、例えば、プロセッサ１１，メモリ１２，記憶装置１３，グラフィック処理装置１４，入力インタフェース１５，光学ドライブ装置１６，機器接続インタフェース１７およびネットワークインタフェース１８を構成要素として有する。これらの構成要素１１～１８は、バス１９を介して相互に通信可能に構成される。

プロセッサ（処理部）１１は、管理装置１０全体を制御する。プロセッサ１１は、マルチプロセッサであってもよい。プロセッサ１１は、例えばＣＰＵ（Central Processing Unit），ＭＰＵ（Micro Processing Unit），ＤＳＰ（Digital Signal Processor），ＡＳＩＣ（Application Specific Integrated Circuit），ＰＬＤ（Programmable Logic Device），ＦＰＧＡ（Field Programmable Gate Array）のいずれか一つであってもよい。また、プロセッサ１１は、ＣＰＵ，ＭＰＵ，ＤＳＰ，ＡＳＩＣ，ＰＬＤ，ＦＰＧＡのうちの２種類以上の要素の組み合わせであってもよい。

そして、プロセッサ１１がＡＰＩ使用履歴表示プログラム（図示省略）を実行することにより、図１に例示する、ログ収集部１０１，ログ解析部１０２，グラフ作成・表示制御部１０３およびログ管理データベース１０４としての機能が実現される。ログ収集部１０１，ログ解析部１０２，グラフ作成・表示制御部１０３としての機能は、例えば、ＯＳ（Operating System）プログラム上で動作する機能として実装されてもよく、また、ＯＳプログラムの機能として実装されてもよい。

なお、管理装置１０は、例えばコンピュータ読み取り可能な非一時的な記録媒体に記録されたプログラム（ＡＰＩ使用履歴表示プログラムやＯＳプログラム）を実行することにより、ログ収集部１０１，ログ解析部１０２，グラフ作成・表示制御部１０３およびログ管理データベース１０４としての機能を実現する。

管理装置１０に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、管理装置１０に実行させるプログラムを記憶装置１３に格納しておくことができる。プロセッサ１１は、記憶装置１３内のプログラムの少なくとも一部をメモリ（ＲＡＭ）１２にロードし、ロードしたプログラムを実行する。

また、管理装置１０（プロセッサ１１）に実行させるプログラムを、光ディスク１６ａ，メモリ装置１７ａ，メモリカード１７ｃ等の非一時的な可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１１からの制御により、記憶装置１３にインストールされた後、実行可能になる。また、プロセッサ１１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

メモリ１２は、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）を含む記憶メモリである。メモリ１２のＲＡＭは管理装置１０の主記憶装置として使用される。ＲＡＭには、プロセッサ１１に実行させるＯＳプログラムや制御プログラムの少なくとも一部が一時的に格納される。また、メモリ１２には、プロセッサ１１による処理に必要な各種データが格納される。

記憶装置１３は、ハードディスクドライブ（Hard Disk Drive：ＨＤＤ）、ＳＳＤ（Solid State Drive）、ストレージクラスメモリ（Storage Class Memory：ＳＣＭ）等の記憶装置であって、種々のデータを格納するものである。記憶装置１３は、管理装置１０の補助記憶装置として使用される。記憶装置１３には、ＯＳプログラム，制御プログラムおよび各種データが格納される。制御プログラムにはＡＰＩ使用履歴表示プログラムが含まれる。

なお、補助記憶装置としては、ＳＣＭやフラッシュメモリ等の半導体記憶装置を使用することもできる。また、複数の記憶装置１３を用いてＲＡＩＤ（Redundant Arrays of Inexpensive Disks）を構成してもよい。

また、記憶装置１３には、後述するログ管理データベース１０４を構成するデータが格納される。

グラフィック処理装置１４には、モニタ１４ａが接続されている。グラフィック処理装置１４は、プロセッサ１１からの命令に従って、画像をモニタ１４ａの画面に表示させる。モニタ１４ａとしては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置等が挙げられる。後述する出力画面２００（図７参照）はモニタ１４ａに表示（出力）される。

入力インタフェース１５には、キーボード１５ａおよびマウス１５ｂが接続されている。入力インタフェース１５は、キーボード１５ａやマウス１５ｂから送られてくる信号をプロセッサ１１に送信する。なお、マウス１５ｂは、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル，タブレット，タッチパッド，トラックボール等が挙げられる。

光学ドライブ装置１６は、レーザ光等を利用して、光ディスク１６ａに記録されたデータの読み取りを行なう。光ディスク１６ａは、光の反射によって読み取り可能にデータを記録された可搬型の非一時的な記録媒体である。光ディスク１６ａには、ＤＶＤ（Digital Versatile Disc），ＤＶＤ－ＲＡＭ，ＣＤ－ＲＯＭ（Compact Disc Read Only Memory），ＣＤ－Ｒ（Recordable）／ＲＷ（ReWritable）等が挙げられる。

機器接続インタフェース１７は、管理装置１０に周辺機器を接続するための通信インタフェースである。例えば、機器接続インタフェース１７には、メモリ装置１７ａやメモリリーダライタ１７ｂを接続することができる。メモリ装置１７ａは、機器接続インタフェース１７との通信機能を搭載した非一時的な記録媒体、例えばＵＳＢ（Universal Serial Bus）メモリである。メモリリーダライタ１７ｂは、メモリカード１７ｃへのデータの書き込み、またはメモリカード１７ｃからのデータの読み出しを行なう。メモリカード１７ｃは、カード型の非一時的な記録媒体である。

ネットワークインタフェース１８は、ネットワーク１８ａに接続される。ネットワークインタフェース１８は、ネットワーク１８ａを介して、サービス２０（サービス提供サーバ５１）との間でデータの送受信を行なう。ネットワーク１８ａには他の情報処理装置や通信機器等が接続されてもよい。

ネットワーク１８ａにはサービス２０を提供するサービス提供サーバ５１が接続され、管理装置１０は、ネットワークインタフェース１８およびネットワーク１８ａを介して、これらのサービス提供サーバ５１と通信可能に接続される。

管理装置１０はサービス管理者によって操作される。サービス管理者は、後述するグラフ作成・表示制御部１０３に、サービス２０を構成するＡＰＩの情報を入力する。そのため、サービス管理者は、サービス２０を構成する複数のＡＰＩ間の関係の他、各ＡＰＩの開発コストや品質について一定の知識を持つものであることが望ましい。

また、サービス管理者は、グラフ作成・表示制御部１０３において表示される結果を確認し、今後のサービスの改善を検討する。

ログ収集部１０１は、サービス２０を構成する各ＡＰＩからそれぞれ、その使用履歴ログを収集する。ログ収集部１０１は、サービス提供サーバ５１からＡＰＩの使用履歴ログを収集する。ＡＰＩの使用履歴ログの収集は、定期的に行なってもよく、また、随時行なってもよい。ログ収集部１０１は、後述するログ解析部１０２による解析に必要とされる情報を抽出し、ログ管理データベース１０４の対応するテーブルに格納する。

また、ログ収集部１０１は、サービス２０を構成するＡＰＩに関する情報を、後述するグラフ作成・表示制御部１０３から予め取得する。

ログ管理データベース１０４は、ログ収集部１０１が収集、抽出したデータ（使用履歴ログ）を記憶（格納）する。

図３は実施形態の一例としてのコンピュータシステム１のログ管理データベース１０４によって管理されるテーブルのレコードを例示する図である。

図３においては、ログ管理データベース１０４がテーブル形式でデータを管理する例を示しているが、これに限定されるものではなく、種々変形して実施することができる。
例えば、ログ管理データベース１０４は、ＡＰＩ毎にテーブルを備える。

図３に示す例において、符号Ｐ１はAPI_Aに関する使用履歴ログを、符号Ｐ２はAPI_Bに関する使用履歴ログを、符号Ｐ３はAPI_Cに関する使用履歴ログを、それぞれ示す。

図３に例示するログ管理データベース１０４のテーブルは、ＡＰＩを使用したサービス利用者のＩＤと使用した時刻とを対応付けて構成されている。

例えば、図３の符号Ｐ１に示すテーブルの先頭のエントリにおいては、サービス利用者ＩＤが“001”のサービス利用者が2019/02/13の12:00にAPI_Aを使用したことを示す。

ログ収集部１０１は、各ＡＰＩの使用履歴ログから、サービス利用者ＩＤと、サービス利用者がＡＰＩを使用した時刻とを抽出し、これらの情報をログ管理データベース１０４の対応するＡＰＩのテーブルに格納する。

ログ解析部１０２は、ログ管理データベース１０４のテーブルのレコードを用いて、ＡＰＩの使用状況の解析を実施する。

［サービス利用者によるAPI使用回数の解析］
ログ解析部１０２は、サービス利用者がＡＰＩを使用した回数（ＡＰＩ使用回数）をＡＰＩごとに解析する。

ログ解析部１０２は、ログ管理データベース１０４のＡＰＩごとに用意されたテーブルから、それぞれ、レコード数（全サービス利用者によるＡＰＩの累計使用回数）を取得する。

例えば、図３において、符号Ｐ１～Ｐ３で示す各テーブルのレコード数はいずれも４である。ログ解析部１０２は、第１の解析結果として、これらのAPI_A，API_BおよびAPI_Cの各ＡＰＩ使用回数としてそれぞれ“4”を得る。

ログ解析部１０２は、ＡＰＩごとのレコード数の大小、すなわちＡＰＩ使用回数に応じて、後述するグラフ作成・表示制御部１０３がモニタ１４ａに表示させる出力画面２００（図７参照）における、ＡＰＩを表すノード２０１の大きさ（ノードサイズ）を決定する。

ログ解析部１０２は、ＡＰＩ使用回数が多いＡＰＩほど大きいノードサイズを決定し、ＡＰＩ使用回数が小さいＡＰＩほど小さいノードサイズを決定する。

ログ解析部１０２は、決定した各ＡＰＩのノードサイズを示すノードサイズ情報をグラフ作成・表示制御部１０３に出力（通知）する。ログ解析部１０２は、ノードサイズ情報を、当該ノードサイズによって表されるＡＰＩを特定する情報（ＡＰＩ識別情報）とともにグラフ作成・表示制御部１０３に通知する。

ログ解析部１０２は、複数のＡＰＩの使用履歴ログからＡＰＩの実行回数を抽出し、ＡＰＩの実行回数に応じて、出力画面２００の有向グラフにおけるＡＰＩに対応するノード２０１の表示形態（ノードサイズ）を決定する表示形態決定部に相当する。

［サービス利用者によるAPIの使用順序の解析］
また、ログ解析部１０２は、サービス利用者がＡＰＩを使用した順序の解析を行なう。
ＡＰＩを使用した順序は以下の処理１～３に従って行なわれる。

（１）処理１
ログ解析部１０２は、ログ管理データベース１０４のＡＰＩごとに用意されたテーブルに格納されたレコードを、サービス利用者毎にグループ化し、時系列順に整列する。

図４は実施形態の一例としてのコンピュータシステム１のログ解析部１０２による解析方法を説明するための図である。

この図４においては、図３に例示したサービス利用者によるＡＰＩの使用履歴ログを、サービス利用者毎にグループ化し、さらに時系列順に並べてテーブル状に表している。

なお、この図４においては、ＡＰＩ毎の使用履歴ログをテーブル形式で表しているが、これに限定されるものではなく、種々変形して実施することができる。

図４に示す例において、符号Ｐ４はサービス利用者ＩＤが“001”のサービス利用者の使用履歴ログを示す。同様に、符号Ｐ５はサービス利用者ＩＤが“002”のサービス利用者の使用履歴ログを、符号Ｐ６はサービス利用者ＩＤが“003”のサービス利用者の使用履歴ログを、符号Ｐ７はサービス利用者ＩＤが“004”のサービス利用者の使用履歴ログを、それぞれ示す。

図４に例示する使用履歴ログのテーブルは、使用したＡＰＩと使用した時刻とを対応付けて構成されている。

例えば、図４の符号Ｐ４に示す、サービス利用者ＩＤが“001”のサービス利用者に関するテーブルにおいては、API_Aが2019/02/13の12:00に使用されたことを示す。また、このテーブルにおいては、その後、API_Bが2019/02/13の12:05に使用され、API_Cが2019/02/13の12:10に使用され、さらにその後、API_Aが2019/02/13の12:15に使用されたことを示す。

これにより、サービス利用者ＩＤが“001”のサービス利用者が、API_A，API_B，API_C，API_Aの順でＡＰＩを使用したことがわかる。

また、この図４の符号Ｐ４に示すテーブルにおいて、各エントリの使用した時刻は５分間隔で推移していることがわかる。

ログ解析部１０２は、時系列に並べられた複数のエントリにおいて、先のエントリの使用した時刻から後続するエントリの使用した時刻までの経過時間が所定の閾値Ｔ（例えば、Ｔ=30分）以内の場合に、これらのエントリが一連の処理として連続して処理されたものである（連続性がある）と判断する。

これに対して、先のエントリの使用した時刻から後続するエントリの使用した時刻までの経過時間が所定の閾値Ｔ（例えば、Ｔ＝30分）よりも大きい場合には、ログ解析部１０２は、これらのエントリ（ＡＰＩ）が一連の処理として連続して使用されたものでないと判断する。

例えば、図４の符号Ｐ５に示す、サービス利用者ＩＤが“002”のサービス利用者に関するテーブルにおいては、サービス利用者ＩＤが“002”のサービス利用者が、API_C，API_A，API_Bの順でＡＰＩを使用したことがわかる。

ここで、API_Cが2019/02/13の11:30に使用された後に、API_Aが2019/02/13の12:30に使用されている。すなわち、サービス利用者ＩＤが“002”のサービス利用者は、API_Cを使用してから60分後にAPI_Aを使用している。この場合には、先のエントリの使用した時刻から後続するエントリの使用した時刻までの経過時間（60分）が閾値Ｔ（Ｔ＝30分）よりも大きいので、ログ解析部１０２は、これらのＡＰＩの使用は連続して使用されたものではない（連続性がない）と判断する。

また、図４の符号Ｐ６に示す、サービス利用者ＩＤが“003”のサービス利用者に関するテーブルにおいて、API_Bの使用した時刻と、その後に行なわれたAPI_Aの使用した時刻との間には75分が経過している。従って、ログ解析部１０２は、これらのＡＰＩの使用についても、連続して行なわれたものではない（連続性がない）と判断する。

なお、閾値Ｔは30分に限定されるものではなく、適宜変更して設定することができる。閾値Ｔを設定するために、サービス管理者は、サービス利用者の平均サービス滞在時間を推定し、この推定値よりも大きな値を閾値Ｔとしてログ解析部１０２に予め入力することが望ましい。サービス利用者の平均サービス滞在時間の推定は、例えば、過去の実績値を参照する等、既知の手法で実現することができ、その説明は省略する。

（２）処理２
次に、ログ解析部１０２は、上述した処理１でサービス利用者ごとにグループ化したレコード群のそれぞれについて、ＡＰＩの使用順序に基づき、連続性があると認められたＡＰＩの呼び出しパターン（実行順序のパターン）のそれぞれについて、発生回数を求める。なお、ＡＰＩの使用順序はＡＰＩの実行順序と同義であるものとする。

ここで、ＡＰＩの呼び出しパターンは、連続して使用された２つのＡＰＩの組み合わせであって、連続して実行された２つのＡＰＩの実行順序である。ＡＰＩの呼び出しパターンは、使用されたＡＰＩの遷移を表す。ここで、連続して使用された２つのＡＰＩの組み合わせにおいて、先に使用されたＡＰＩを始点といい、後に使用されたＡＰＩを終点という場合がある。ＡＰＩの呼び出しパターンは始点と終点とを備える。

ログ解析部１０２は、時系列順に並べられたサービス利用者毎のＡＰＩの使用履歴ログにおいて、ＡＰＩの使用に連続性があると認められた、連続する２つのＡＰＩの組み合わせ（呼び出しパターン，実行順序パターン）を１つの単位として抽出（分割）し、それぞれの発生回数を計数する。

例えば、図４の符号Ｐ４に示す、サービス利用者ＩＤが“001”のサービス利用者に関するテーブルにおいては、サービス利用者が、API_A，API_B，API_C，API_Aの順でＡＰＩを使用している。このような使用順序は、API_A → API_B，API_B → API_C，API_C → API_Aの３つの呼び出しパターンを備える。これらの呼び出しパターンの発生回数はそれぞれ1である。

図５は実施形態の一例としてのコンピュータシステム１のログ解析部１０２によるＡＰＩ呼び出しパターン毎の発生回数の管理方法を例示する図である。

以下、API_A，API_B，API_Cを、それぞれＡ，Ｂ，Ｃで表す場合がある。

図５に示す例においては、サービス利用者毎に、始点となるＡＰＩ（API_A，API_B，API_C）を列に配置し、終点となるＡＰＩ（API_A，API_B，API_C）を行に配置したマトリクスを示している。そして、ＡＰＩの呼び出しパターンの発生回数が、このマトリクスにおける対応位置に設定されている。

なお、この図５においては、呼び出しパターンを構成するＡＰＩの組み合わせをマトリクス形式で表しているが、これに限定されるものではなく、種々変形して実施することができる。

図５に示す例において、符号Ｐ８はサービス利用者ＩＤが“001”のサービス利用者の使用履歴ログにおけるＡＰＩの呼び出しパターンの発生回数を示す。同様に、符号Ｐ９はサービス利用者ＩＤが“002”のサービス利用者の使用履歴ログにおけるＡＰＩの呼び出しパターンの発生回数を示す。また、符号Ｐ１０はサービス利用者ＩＤが“003”のサービス利用者の使用履歴ログにおけるＡＰＩの呼び出しパターンの発生回数を示し、符号Ｐ１１はサービス利用者ＩＤが“004”のサービス利用者の使用履歴ログにおけるＡＰＩの呼び出しパターンの発生回数を示す。各サービス利用者のマトリクスは互いに同じフォーマットを有する。

上述の如く、図４の符号Ｐ４に示す、サービス利用者ＩＤが“001”のサービス利用者に関するテーブルにおいては、API_A → API_B，API_B → API_C，API_C → API_Aの３つの呼び出しパターンを備える。すなわち、始点Ａ－終点Ｂ，始点Ｂ－終点Ｃおよび始点Ｃ－終点Ａの３つの呼び出しパターンのそれぞれの発生回数が1である。

これにより、図５における符号Ｐ８に示すマトリクスにおいては、始点Ａ－終点Ｂ，始点Ｂ－終点Ｃおよび始点Ｃ－終点Ａのそれぞれの位置に発生回数1が設定されている。

このように、ログ解析部１０２は、ＡＰＩの使用順序のうち連続性があると認められた部分を、連続して実行（使用）された２つのＡＰＩの組み合わせ（呼び出しパターン）を１つの単位として抽出し、それぞれの発生回数を計数する。

また、上述の如く、ログ解析部１０２は、連続性があると認められたＡＰＩの呼び出しパターンのそれぞれについて、発生回数を求める。そのため、先のエントリの使用した時刻から後続するエントリの使用した時刻までの経過時間（60分）が閾値Ｔ（例えば、Ｔ＝30分）よりも大きい場合には、ログ解析部１０２は、これらのＡＰＩの使用は（例外的に）計数に含めない。

図４の符号Ｐ６に示す、サービス利用者ＩＤが“003”のサービス利用者に関するテーブルにおいては、API_B → API_A，API_A → API_C，API_C → API_Cの３つの呼び出しパターンを備える。ただし、API_B → API_Aの呼び出しパターンについては、API_Bの使用した時刻から後続するAPI_Aの使用した時刻までの経過時間（75分）が閾値Ｔ（例えば、Ｔ＝30分）よりも大きいので、ログ解析部１０２は、この呼び出しパターンを計数に含めない。

これにより、図５における符号Ｐ１０に示すマトリクスにおいては、始点Ａ－終点Ｃおよび始点Ｃ－終点Ｃのそれぞれの位置に発生回数1が設定される。

（３）処理３
ログ解析部１０２は、処理２においてサービス利用者ごとに作成したマトリクスを合算する。これにより、ログ解析部１０２は、連続性があると認められたＡＰＩの呼び出しパターンのそれぞれについて、全サービス利用者についての発生回数（呼び出し回数）の総和を求める。

すなわち、ログ解析部１０２は、連続して実行された２つのＡＰＩの当該実行順序で実行された回数を求める。

図６は実施形態の一例としてのコンピュータシステム１のログ解析部１０２によるＡＰＩ呼び出しパターン毎の発生回数の管理方法を例示する図であり、全サービス利用者についての発生回数の合計を示している。

この図６に例示するマトリクスにおいては、始点Ａ－終点Ｂの呼び出しパターン、すなわち、API_Aの次にAPI_Bが呼び出されるパターンの発生回数（呼び出し回数）が最も多いことがわかる。

ログ解析部１０２は、合算されたマトリクスの各要素の大小に応じて、グラフ作成・表示制御部１０３で表示する出力画面２００（図７を用いて後述）において、有向グラフ上の対応するエッジ２０２の表示形態を決定し、グラフ作成・表示制御部１０３に出力する。

ログ解析部１０２は、上述の如く解析された連続性があるＡＰＩ間における呼び出し回数に応じて、エッジ２０２の線種を決定する。例えば、ログ解析部１０２は、呼び出し回数が多い呼び出しパターンほどエッジ２０２の線を太くする。

ログ解析部１０２は、決定したエッジ２０２の線種を示す情報（線種情報）をグラフ作成・表示制御部１０３に出力（通知）する。ログ解析部１０２は、エッジ２０２の線種情報を、当該線種情報によって表されるエッジ２０２を特定する情報（例えば、エッジ２０２の始点および終点となる各ＡＰＩのＡＰＩ識別情報）とともにグラフ作成・表示制御部１０３に通知する。

ログ解析部１０２は、ＡＰＩの使用履歴ログに基づき、複数のＡＰＩのうち連続して実行された２つのＡＰＩの実行順序で実行された回数に応じて、出力画面２００の有向グラフにおける２つのＡＰＩに対応する２つのノード２０１間を接続するエッジ２０２の表示形態（線種）を決定する表示形態決定部に相当する。

グラフ作成・表示制御部１０３は、モニタ１４ａに表示させる表示画面の生成を行なう。

グラフ作成・表示制御部１０３は、サービス管理者に提供する表示画面を生成し、グラフィック処理装置１４を介してモニタ１４ａに表示させる。

グラフ作成・表示制御部１０３が生成する表示画面は、サービス管理者が入力操作を行なうための入力画面と、ログ解析部１０２によるログ解析結果を出力する出力画面とを含んでもよい。

グラフ作成・表示制御部１０３によって生成される入力画面はＧＵＩ（Graphical User Interface）をそなえ、サービス管理者は、このＧＵＩを介して入力操作を行なう。サービス管理者は、例えば、サービス２０を構成するＡＰＩに関する情報を入力する。

サービス管理者は、ＡＰＩに関する情報を、例えば、ノードとエッジ（辺，枝）とを備える有向グラフの形式で入力する。

ＡＰＩに関する情報には、例えば、ＡＰＩの名称，ＡＰＩの品質，ＡＰＩの開発コストおよびＡＰＩ間の関連性の有無を含む。入力されたＡＰＩの情報は、図７に示す出力画面２００の生成に用いられる。

なお、ＡＰＩの品質は、例えば、ＡＰＩにおけるエラー発生数（エラー発生率）によって表してもよい。また、ＡＰＩの開発コストは金額や作業工数で表してもよい。

図７は実施形態の一例としてのコンピュータシステム１における出力画面２００を例示する図である。

この出力画面２００は、サービス２０におけるＡＰＩの使用履歴に関する情報を有向グラフに反映させて表すものであり、主にサービス管理者に対して提供されるものである。出力画面２００はサービス２０に対応して生成される。

この図７に例示する出力画面２００は、複数（図７に示す例では７個）のノード２０１－１～２０１－７と、複数（図７に示す例では１１個）のエッジ２０２－１～２０２－１１とを備える。これらのノード２０１－１～２０１－７とエッジ２０２－１～２０２－１１とは有向グラフを構成している。また、この図７に例示する出力画面２００は、関連性があるノード２０１間を連結する無向エッジ２０３も備える。

ノード２０１－１～２０１－７はＡＰＩを表す。図７に示す例においては７個のノード２０１－１～２０１－７が円形で示されており、これらのノード２０１－１～２０１－７は、サービス２０に備えられた７個のＡＰＩ（API_A，API_B，API_C，API_D，API_E，API_F，API_G）に対応する。

以下、７個のノード２０１－１～２０１－７を特に区別しない場合には、ノード２０１と表記する。ノード２０１内には、当該ノード２０１の名称が示されている。

エッジ２０２－１～２０２－１１は関連性のあるノード２０１どうしを連結する有向線分（矢印）である。以下、１１個のエッジ２０２－１～２０２－１１を特に区別しない場合には、エッジ２０２と表記する。

グラフ作成・表示制御部１０３は、入力画面のＧＵＩから入力されたＡＰＩの名称を、出力画面２００においてノード２０１の名称として表示する。また、ＡＰＩ間の関連性の有無を、出力画面２００におけるノード２０１間のエッジの有無として表現する。

出力画面２００においては、ＡＰＩ間でのデータの受け渡しが発生する等、互いに関連するＡＰＩに対応するノード２０１間を線（無向エッジ２０３，エッジ２０２）で連結することで、ＡＰＩ間の連携を視覚的に表す。

出力画面２００において、ノード２０１間を連結する無向エッジ２０３およびエッジ２０２は、ＡＰＩの呼び出しが繰り返し行なわれたことを示す。そして、エッジ２０２の線の太さが太いほど、ＡＰＩの呼び出しの繰り返し回数が多いことを示す。

また、グラフ作成・表示制御部１０３は、ＡＰＩの呼び出しの繰り返し回数が所定の閾値以下である場合、すなわち、ＡＰＩの呼び出しの繰り返し回数が少ない場合に、例えば、エッジ２０２の線種を破線もしくは点線にする（エッジ２０２－９参照）。

なお、グラフ作成・表示制御部１０３は、ＡＰＩの呼び出しの繰り返し回数が第１の閾値以上、且つ第２の閾値以下である場合、すなわち、ＡＰＩの呼び出しの繰り返し回数が多くも少なくもない場合に、エッジ２０２の図示を抑止してもよい。これにより、出力画面２００に表示させる情報を抑制し、見やすくすることができる。

また、グラフ作成・表示制御部１０３は、入力画面のＧＵＩから入力されたＡＰＩの品質を、出力画面２００における縦軸方向のノード２０１の位置として表現する。例えば、品質が高いＡＰＩほど出力画面２００中における上方位置に配置し、品質が低いＡＰＩほど出力画面２００中における下方位置に配置する。

すなわち、グラフ作成・表示制御部１０３は、出力画面２００の有向グラフにおいて、ノード２０１を、当該ノード２０１に対応するＡＰＩの品質に応じた状態で表示させる。

なお、ログ収集部１０１により各ＡＰＩで検出されたエラーの情報を収集し、ログ解析部１０２によりＡＰＩ毎のエラー発生数（エラー発生率）を求めてもよい。そして、このエラー発生数（エラー発生率）に応じて、グラフ作成・表示制御部１０３は、出力画面２００中におけるノード２０１の位置を適宜移動させてもよい。

さらに、グラフ作成・表示制御部１０３は、入力画面のＧＵＩから入力されたＡＰＩの開発コストを、出力画面２００における横軸方向のノード２０１の位置として表現する。

例えば、開発コストが高いＡＰＩほど出力画面２００中における左方位置に配置し、開発コストが低いＡＰＩほど出力画面２００中における右方位置に配置する。例えば、無償のＯＳＳ（Open Source Software）として提供されるＡＰＩは開発コストがかかっていないので出力画面２００中における右端位置に配置する。また、自前で開発したコア機能のＡＰＩは、開発コストが高いものとして出力画面２００中における左側位置に配置する。有償のプロダクトであるＡＰＩは、例えば、出力画面２００中における左右方向の中央付近位置に配置してもよい。

すなわち、グラフ作成・表示制御部１０３は、出力画面２００の有向グラフにおいて、ノード２０１を、当該ノード２０１に対応するＡＰＩの開発コストに応じた状態で表示させる。

グラフ作成・表示制御部１０３は、上述の如く生成した出力画面２００に対して、ログ解析部１０２から通知されたノードサイズ情報および線種情報を反映させる。

すなわち、グラフ作成・表示制御部１０３は、ログ解析部１０２からＡＰＩ識別情報とともに通知されたノードサイズ情報に基づき、当該ＡＰＩ識別情報によって特定されるＡＰＩのノード２０１をノードサイズ情報によって示されるサイズに変更する。

また、グラフ作成・表示制御部１０３は、ログ解析部１０２からエッジ２０２を特定する情報とともに通知された線種情報に基づき、当該エッジ２０２を特定する情報によって特定されるエッジ２０２を線種情報によって示される線種に変更する。

グラフ作成・表示制御部１０３は、これらのノードサイズ情報や線種情報を反映させた出力画面２００をモニタ１４ａに表示させることでサービス管理者に提供する。

（Ｂ）動作
上述の如く構成された実施形態の一例としてのコンピュータシステム１における処理を、図８に示すフローチャート（ステップＡ１～Ｓ８）に従って説明する。

ステップＳ１において、サービス管理者は、キーボード１５ａやマウス１５ｂを用いて、グラフ作成・表示制御部１０３が提供する入力画面のＧＵＩから、サービス２０を構成するＡＰＩに関する情報を入力する。サービス管理者は、ノード２０１とエッジ２０２とを有する有向グラフの形式で、ＡＰＩに関する情報を入力する。入力された情報は、例えば、記憶装置１３の所定の記憶領域に記憶される。

ステップＳ２において、サービス利用者はサービス２０を利用する。この際、サービス提供サーバ５１においては、サービス２０を構成するＡＰＩが使用され、その使用履歴ログが、例えば、ＡＰＩ提供サーバ５１の図示しないメモリや記憶装置に、サービス２０の利用履歴に含めて記録される。

ステップＳ３において、ログ収集部１０１は、グラフ作成・表示制御部１０３から、ステップＳ１において入力されたＡＰＩに関する情報を取得する。

ステップＳ４において、ログ収集部１０１は、ステップＳ３において取得したＡＰＩに関する情報に基づき、ステップＳ２において記録されたＡＰＩの使用履歴ログをサービス提供サーバ５１から取得する。

ステップＳ５において、ログ収集部１０１は、ステップＳ４で取得したＡＰＩの使用履歴ログから必要なデータ（例えば、サービス利用者ＩＤや使用時刻）を抽出し、ログ管理データベース１０４に格納する。

ステップＳ６において、ログ解析部１０２は、ステップＳ５で格納したデータを、ログ管理データベース１０４にから取得して、解析する。

すなわち、ログ解析部１０２は、サービス利用者がＡＰＩを使用した回数（ＡＰＩ使用回数）をＡＰＩ毎に解析する。

また、ログ解析部１０２は、サービス利用者がＡＰＩを使用した順序の解析を行ない、ＡＰＩの使用順序に基づき、連続性があると認められたＡＰＩの呼び出しパターン（実行順序パターン）のそれぞれについて、全サービス利用者についての発生回数（呼び出し回数）の総和を求める。

ステップＳ７において、ログ解析部１０２は、サービス利用者によるＡＰＩ使用回数に基づいてノードサイズ情報を決定し、当該ノードサイズ情報を、ノードサイズによって表されるＡＰＩを特定する情報（ＡＰＩ識別情報）とともにグラフ作成・表示制御部１０３に出力する。

また、ログ解析部１０２は、連続性があると認められたＡＰＩの呼び出しパターンのそれぞれについて、全サービス利用者についての発生回数（呼び出し回数）の総和を求める。そして、ログ解析部１０２は、連続性があるＡＰＩ間における呼び出し回数に応じて、エッジ２０２の線種（表示形態）を決定する。

ログ解析部１０２は、決定したエッジ２０２の線種情報を、当該線種情報によって表されるエッジ２０２を特定する情報（例えば、エッジ２０２の始点および終点となる各ＡＰＩのＡＰＩ識別情報）とともにグラフ作成・表示制御部１０３に出力する。

ステップＳ８において、グラフ作成・表示制御部１０３は、ログ解析部１０２から出力されたノードサイズ情報および線種情報を出力画面２００の有向グラフに反映させ、モニタ１４ａに出力することでサービス管理者に提示する。その後、処理を終了する。

（Ｃ）効果
このように、本発明の一実施形態としてのコンピュータシステム１によれば、ログ解析部１０２が、サービス利用者がＡＰＩを使用した回数（ＡＰＩ使用回数）をＡＰＩごとに解析し、このＡＰＩ使用回数に応じてＰＩを表すノード２０１の大きさ（ノードサイズ）を決定し、グラフ作成・表示制御部１０３に通知する。

グラフ作成・表示制御部１０３が、出力画面２００の有向グラフにおいて、ログ解析部１０２から通知されたノードサイズでＡＰＩに対応するノード２０１を表示させる。

これにより、出力画面２００において、サービス２０において使用されている複数のＡＰＩの使用状況（使用回数）が可視化され、サービス管理者がＡＰＩの使用状況を容易に把握することができ、利便性が高い。例えば、使用頻度が低いＡＰＩについて、早期に改善策をとることができる。

例えば、図７に例示する出力画面２００において、API_E，API_Gの使用回数が少ないことを容易に把握することができ、早期に改善に取り組むことができる。

ここで、API_Eは開発コストが高いにも関わらず、使用回数が少ないことは問題であると考えられ、施策として、API_Eの品質の改善や、自前で開発することをやめて同じ機能をもつOSSにリプレースする等の対処を早期に施すことができる。

API_GもAPI_Eと同様に使用回数が少ないとはいえ、開発コストがもともと低いため、サービス２０に与える影響は小さいと判断することができる。ここで、しかし、API_Gの使用頻度を高める方針をとるのであれば、同じ機能を有するリッチなプロダクトへのリプレースや、API_Gの開発を自前で行なうといった施策を早期に施すことができる。

また、ログ解析部１０２が、各ＡＰＩの使用順序に基づき、連続性があるＡＰＩの呼び出しパターン（実行順序パターン）のそれぞれについて、全サービス利用者についての発生回数（呼び出し回数）の総和を求める。そして、ログ解析部１０２は、解析された連続性があるＡＰＩ間における呼び出し回数に応じて、エッジ２０２の線種を変更させる線種情報を作成する。

グラフ作成・表示制御部１０３が、出力画面２００の有向グラフにおいて、ログ解析部１０２から通知された線種情報でノード２０１間のエッジ２０２を表示させる。

これにより、出力画面２００において、ＡＰＩ間のエッジ２０２を見ることで、サービス利用者がどのような順序でＡＰＩを使用しているかをサービス管理者がＡＰＩの使用状況を容易に把握することができ、利便性が高い。

例えば、図７に例示する出力画面２００において、API_BとAPI_Eとは連携するＡＰＩであるにもかかわらず、API_B → API_Eという順番でAPIを使用する人が極端に少ないことがわかる。サービス管理者は、ここに何かサービス利用者が使用し辛いボトルネックがあると推測することできる。

一方で、API_Cから他のＡＰＩを続けて使用される回数が多いことから、API_Cがハブのような役割を果たしていることを容易に把握することができる。従って、API_CとAPI_Eとを連携させるようサービス２０を改善することで、API_Eの使用回数の増加が期待される旨の分析を行なうこともできる。

（Ｄ）その他
開示の技術は上述した実施形態に限定されるものではなく、本実施形態の趣旨を逸脱しない範囲で種々変形して実施することができる。本実施形態の各構成および各処理は、必要に応じて取捨選択することができ、あるいは適宜組み合わせてもよい。

例えば、上述した実施形態においては、ログ解析部１０２が、ＡＰＩの使用回数に応じて、出力画面２００の有向グラフにおけるＡＰＩに対応するノード２０１のサイズを変更しているが、これに限定されるものではない。

すなわち、ＡＰＩの使用回数に応じてノード２０１の色や形状，模様等を異ならせて表示してもよく、種々変形して実施することができる。色には彩度や明度を含んでもよい。

また、上述した実施形態においては、ログ解析部１０２が、連続して実行された２つのＡＰＩの当該実行順序で実行された回数に応じて、出力画面２００の有向グラフにおけるＡＰＩに対応するノード２０１間のエッジ２０２の線を太くするよう線種を変更しているが、これに限定されるものではない。

すなわち、連続して実行された２つのＡＰＩの当該実行順序で実行された回数に応じてノード２０１の色や形状，模様等を異ならせて表示してもよく、種々変形して実施することができる。色には彩度や明度を含んでもよい。

グラフ作成・表示制御部１０３が、出力画面２００の有向グラフにおいて、ノード２０１を、当該ノード２０１に対応するＡＰＩの品質や開発コストに応じた位置に表示させているが、これに限定されるものではない。グラフ作成・表示制御部１０３は、ＡＰＩの品質や開発コストに応じてノード２０１の色や形状，模様等を異ならせて表示してもよく、種々変形して実施することができる。

また、上述した開示により本実施形態を当業者によって実施・製造することが可能である。

１ コンピュータシステム
１０ 管理装置
１１ プロセッサ
１２ ＲＡＭ
１３ ＨＤＤ
１４ グラフィック処理装置
１４ａ モニタ
１５ 入力インタフェース
１５ａ キーボード
１５ｂ マウス
１６ 光学ドライブ装置
１６ａ 光ディスク
１７ 機器接続インタフェース
１７ａ メモリ装置
１７ｂ メモリリーダライタ
１７ｃ メモリカード
１８ ネットワークインタフェース
１８ａ ネットワーク
１９ バス
２０ コンピュータサービス
５０ ネットワーク網
５１ サービス提供サーバ
５２ ユーザ端末
１０１ ログ収集部
１０２ ログ解析部
１０３ グラフ作成・表示制御部
１０４ ログ管理データベース
２００ 出力画面２００
２０１－１～２０１－７，２０１ ノード
２０２－１～２０２－１１，２０２ エッジ
２０３ 無向エッジ

Claims (5)

1. 複数のＡＰＩ（Application Programming Interface）を用いるコンピュータサービスの利用履歴データから前記ＡＰＩの実行回数を抽出し、前記ＡＰＩの実行回数に応じて、前記ＡＰＩに対する表示形態を決定する表示形態決定部と、
   前記複数のＡＰＩのそれぞれに対応するノードを表す有向グラフにおいて、決定された前記表示形態で前記ＡＰＩに対応する前記ノードを表示させる表示制御部と
   を備えることを特徴とする、情報処理装置。
2. 前記表示形態決定部が、前記利用履歴データに基づき、前記複数のＡＰＩのうち連続して実行された２つのＡＰＩの当該実行の順序で実行された回数に応じて、前記有向グラフにおける前記２つのＡＰＩに対応する２つのノード間を接続する有向線分の表示形態を決定し、
   前記表示制御部が、前記有向グラフにおいて、決定された前記表示形態で前記有向線分を表示させる
   ことを特徴とする、請求項１記載の情報処理装置。
3. 前記表示制御部が、
   前記有向グラフにおいて、前記ノードを、当該ノードに対応する前記ＡＰＩの品質に応じた状態で表示させる
   ことを特徴とする、請求項１または２記載の情報処理装置。
4. 前記表示制御部が、
   前記有向グラフにおいて、前記ノードを、当該ノードに対応する前記ＡＰＩの開発コストに応じた状態で表示させる
   ことを特徴とする、請求項１～３のいずれか１項に記載の情報処理装置。
5. 複数のＡＰＩ（Application Programming Interface）を用いるコンピュータサービスに接続される情報処理装置のプロセッサに、
   前記コンピュータサービスの利用履歴データから前記ＡＰＩの実行回数を抽出し、前記ＡＰＩの実行回数に応じて、前記ＡＰＩに対する表示形態を決定し、
   前記複数のＡＰＩのそれぞれに対応するノードを表す有向グラフにおいて、決定された前記表示形態で前記ＡＰＩに対応する前記ノードを表示させる
   処理を実行させる、ＡＰＩ使用履歴表示プログラム。
   
   

Images