(57)【要約】      （修正有）【課題】自動生成したマッシュアップAPIを自動的にアプリ側に反映させる抽象化API自動生成システムおよびその生成方法を提供する。【解決手段】抽象化API自動生成システムＳは、SDKを活用したアプリケーション２から利用されるAPIのリクエスト-レスポンスを監視するAPI管理部１ｄと、監視の結果、抽象化すべきAPIか否か判定するAPI抽象化判定部１ｅと、抽象化すべきAPIと判定された場合に抽象化APIを生成するAPI抽象化部１ｆと、アプリケーションのSDKを抽象化APIに対応したSDKに更新するSDK最新化処理部１ｇ、APL-SDKアップデート処理部１ｈとを備えている。【選択図】図１
2017033424.tif 000002
【特許請求の範囲】
【請求項１】
通信を介して所定の目的を実現するイネーブラが実行されるAPIを用いて、アプリケーションが、所望の情報を取得するためのリクエスト情報を前記イネーブラへ送信し、当該送信されたリクエスト情報を受信した前記イネーブラが前記リクエスト情報に応じたレスポンス情報を、前記APIを介して前記アプリケーションへ返信する通信システムにおいて複数の前記APIによる処理を生成した単数の抽象化APIで提供する抽象化API自動生成システムであって、
SDKを活用したアプリケーションから利用されるAPIのリクエスト-レスポンスを監視するAPI監視部と、
前記API監視部の監視の結果、抽象化すべきAPIか否か判定するAPI抽象化判定部と、
抽象化すべきAPIと判定された場合に前記抽象化APIを生成する抽象化API生成部と、
前記アプリケーションの前記SDKを前記抽象化APIに対応したSDKに更新するSDK更新部とを
備えることを特徴とする抽象化API自動生成システム。
【請求項２】
請求項１に記載の抽象化API自動生成システムにおいて、
前記API抽象化判定部は、２つ以上のAPIが実行されており、閾値の数以上の同じ前記APIの組み合わせが抽出された場合、前記２つ以上のAPIによる処理を抽象化すべきAPIと判定する
ことを特徴とする抽象化API自動生成システム。
【請求項３】
請求項１または請求項２に記載の抽象化API自動生成システムにおいて、
前記SDK更新部がSDKを更新した場合、当該更新したSDKの箇所の履歴を記憶するSDK管理部を
備えることを特徴とする抽象化API自動生成システム。
【請求項４】
請求項１から請求項３の何れか一項に記載の抽象化API自動生成システムにおいて、
前記抽象化API生成部は、
一の前記APIから得られたレスポンス結果を他の前記APIのリクエスト内容に用いている場合、順次実行される前記抽象化APIを生成する
ことを特徴とする抽象化API自動生成システム。
【請求項５】
請求項１から請求項４の何れか一項に記載の抽象化API自動生成システムにおいて、
前記抽象化API生成部は、
一のAPIから得られたレスポンス結果を利用せず、異なるパラメータを用いて他のAPIにリクエスト送信をしている場合、並列で実行される前記抽象化APIを生成する
ことを特徴とする抽象化API自動生成システム。
【請求項６】
請求項４または請求項５に記載の抽象化API自動生成システムにおいて、
前記抽象化APIは、
予め指定したイネーブラのAPIが実行されるか、または、
あるイネーブラのAPIの実行結果をもとに別のイネーブラのAPIが実行される
ことを特徴とする抽象化API自動生成システム。
【請求項７】
通信を介して所定の目的を実現するイネーブラが実行されるAPIを用いて、アプリケーションが、所望の情報を取得するためのリクエスト情報を前記イネーブラへ送信し、当該送信されたリクエスト情報を受信した前記イネーブラが前記リクエスト情報に応じたレスポンス情報を、前記APIを介して前記アプリケーションへ返信する通信システムにおいて複数の前記APIによる処理を単数の抽象化APIで提供する抽象化API自動生成システムの生成方法であって、
前記抽象化API自動生成システムは、API監視部とAPI抽象化判定部と抽象化API生成部とSDK更新部とを備え、
前記API監視部は、SDKを活用したアプリケーションから利用されるAPIのリクエスト-レスポンスを監視し、
前記API抽象化判定部は、前記API監視部の監視の結果、抽象化すべきAPIか否か判定し、
前記抽象化API生成部は、抽象化すべきAPIと判定された場合に前記抽象化APIを生成し、
前記SDK更新部は、前記アプリケーションの前記SDKを前記抽象化APIに対応したSDKに更新する
ことを特徴とする抽象化API自動生成システムの生成方法。
【請求項８】
請求項７に記載の抽象化API自動生成システムの生成方法において、
前記API抽象化判定部は、２つ以上のAPIが実行されており、閾値の数以上の同じ前記APIの組み合わせが抽出された場合、前記２つ以上のAPIによる処理を抽象化すべきAPIと判定する
ことを特徴とする抽象化API自動生成システムの生成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のWebサービスを組み合わせて1つのアプリを作成するマッシュアップAPIの作成技術に係る抽象化API自動生成システムおよびその生成方法に関する。
【背景技術】
【０００２】
従来、SNS（Social Networking Service）などインターネット上のWeb (World Wide Web)サービスでは、提供するサービスへアクセスするAPI（Application Programming Interface）を公開している。
なお、APIとは、プログラムのスクラッチで開発していたような機能、地図描画や認証等の共通機能をもつ情報インターフェイスである。
【０００３】
APIの利用形態の一つとして、複数のWebサービスを組み合わせて1つのアプリ（Application Program）を作成するマッシュアップがある。
例えば、APIを活用したアプリの開発では、複数のAPIをマッシュアップして（組合せて）１つのAPIに見せることで、早く、安く、多様な機能のアプリを開発することができる。
【０００４】
つまり、ソフトウェア開発において、APIを活用したソフトウェア開発により、幾つかのAPIを組合せてシステムテストを含む開発期間の短縮、開発コストの削減を図ることができる。
非特許文献１には、他者がWebサーバを通じて提供するソフトウェア機能を積極的に再利用することによりマッシュアップを行うことが記されている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】「セキュアプログラミング講座−Ｗｅｂアプリケーション編−第８章マッシュアップ」、[online]、2013、ＩＰＡ独立行政法人、情報処理推進機構、［平成２７年１月２６日検索］、インターネット〈URL: https://www.ipa.go.jp/security/awareness/vendor/programmingv2/web.html〉
【非特許文献２】橿渕健一, 金丸翔, “サーバ側マッシュアップのおけるAPIの並列実行に関する一考察” 電子情報通信学会総合大会, 通信講演論文集, p70, 2014
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、従来、APIのマッシュアップの自動化を、リクエスト-レスポンス等を監視および分析した上で実施する検討がなされている。
また、非特許文献２には、API提供機能側がAPIを叩く際の最適な手順を判断するためのシステムが提案されている。しかし、自動生成したマッシュアップAPIを自動的にアプリ側に反映させる方法は検討課題となっている。
【０００７】
自動生成したマッシュアップAPIを自動的にアプリ側に反映させる仕組みが無い場合、アプリケーション開発者によって、アプリの書き換え等しない限り、マッシュアップAPIが利用できず、Webサービスの応答時間の短縮やAPI提供機能によるAPIの実行手順の最適化が図れない。
【０００８】
図１４に、従来のシステム概要図を示す。
従来のシステム１００Ｓは、API統合基盤１０１とアプリ１０２とイネーブラ１０３ａ〜１０３ｃとAPI１０４とを有している。
API統合基盤１０１は、APIのインフラというべきもので、APIの管理、運営を行う。
イネーブラ１０３ａ〜１０３ｃは、ある機能を有効にする装置である。
【０００９】
アプリ１０２は、ユーザ側のシステムのApplication Programである。なお、アプリ１０２はSDK（Software Development Kit）v１を有しており、関連するソフトウェアを開発する場合にSDKを入手する必要がある。
図１５に、従来のマッシュアップAPI生成後のシステム概要図を示す。
API統合基盤１は、マッシュアップAPI１０５を自動生成する。
【００１０】
しかし、図１５に示すように、システム１００ＳにマッシュアップAPI１０５が生成された場合も、アプリ１０２の開発者にてマッシュアップしたAPIを活用したスクリプトに変更しなければ、マッシュアップAPIは活用されない 。つまり、アプリ１０２の開発者にてバージョンアップしたSDKv2に変更しなければ、マッシュアップしたAPIを利用できない。
【００１１】
本発明は上記実状に鑑み創案されたものであり、自動生成したマッシュアップAPIを自動的にアプリ側に反映させる抽象化API自動生成システムおよびその生成方法の提供を目的とする。
【課題を解決するための手段】
【００１２】
前記課題を解決するため、第１の本発明の抽象化API自動生成システムは、通信を介して所定の目的を実現するイネーブラが実行されるＡＰＩを用いて、アプリケーションが、所望の情報を取得するためのリクエスト情報を前記イネーブラへ送信し、当該送信されたリクエスト情報を受信した前記イネーブラが前記リクエスト情報に応じたレスポンス情報を、前記APIを介して前記アプリケーションへ返信する通信システムにおいて複数の前記APIによる処理を生成した単数の抽象化APIで提供する抽象化API自動生成システムであって、SDKを活用したアプリケーションから利用されるAPIのリクエスト-レスポンスを監視するAPI監視部と、前記API監視部の監視の結果、抽象化すべきAPIか否か判定するAPI抽象化判定部と、抽象化すべきAPIと判定された場合に前記抽象化APIを生成する抽象化API生成部と、前記アプリケーションの前記SDKを前記抽象化APIに対応したSDKに更新するSDK更新部とを備えている。
【００１３】
第７の本発明の抽象化API自動生成システムの生成方法は、第１の本発明の抽象化API自動生成システムを実現する方法である。
【００１４】
第１または第７の本発明によれば、抽象化APIを生成した場合、SDK更新部でSDKを更新するので、アプリ開発者は、アプリのソースコード等の書き直しをせずに、応答時間の短縮や、API提供機能によるAPIの実行手順の最適化を図ることができる。
【００１５】
第２の本発明の抽象化API自動生成システムは、第１の本発明において、前記API抽象化判定部は、２つ以上のAPIが実行されており、閾値の数以上の同じ前記APIの組み合わせが抽出された場合、前記２つ以上のAPIによる処理を抽象化すべきAPIと判定している。
第８の本発明の抽象化API自動生成システムの生成方法は、第２の本発明の抽象化API自動生成システムを実現する方法である。
【００１６】
第２または第８の本発明によれば、閾値の数以上の同じ前記APIの組み合わせが抽出された場合、前記２つ以上のAPIによる処理を抽象化すべき単数の抽象化APIと判定するので、通信がbusyになることを未然に防ぐことができる。
【００１７】
第３の本発明の抽象化API自動生成システムは、第１または第２の本発明において、前記SDK更新部がSDKを更新した場合、当該更新したSDKの箇所の履歴を記憶するSDK管理部を備えている。
【００１８】
第３の本発明によれば、SDK管理部でSDKの更新箇所の履歴が記憶されるので、SDKの更新履歴を参照でき、システムの保守、開発に役立てることができる。
【００１９】
第４の本発明の抽象化API自動生成システムは、第１から第３の何れかの本発明において、前記抽象化API生成部は、一の前記APから得られたレスポンス結果を他の前記APIのリクエスト内容に用いている場合、順次実行される前記抽象化APIを生成している。
【００２０】
第４の本発明によれば  抽象化API生成部は、一の前記APから得られたレスポンス結果を他の前記APIのリクエスト内容に用いている場合、順次実行される前記抽象化APIを生成するので、通信回数を削減できる。
【００２１】
第５の本発明の抽象化API自動生成システムは、第１から第４の何れかの本発明において、前記抽象化API生成部は、一のAPIから得られたレスポンス結果を利用せず、異なるパラメータを用いて他のAPIにリクエスト送信をしている場合、並列で実行される前記抽象化APIを生成している。
【００２２】
第５の本発明によれば、リアルタイム性が要求されるアプリに対して可能な限り応答時間を短縮することができる。
【００２３】
第６の本発明の抽象化API自動生成システムは、第４または第５の何れかの本発明において、前記抽象化APIは、予め指定したイネーブラのAPIが実行されるか、または、あるイネーブラのAPIの実行結果をもとに別のイネーブラのAPIが実行されている。
【００２４】
第６の本発明によれば、抽象化APIの実行順を選択できる。そのため、抽象化APIの実行の自由度を高めることができる。
【発明の効果】
【００２５】
本発明によれば、自動生成したマッシュアップAPIを自動的にアプリ側に反映させる抽象化API自動生成システムおよびその生成方法を提供することができる。
【図面の簡単な説明】
【００２６】
【図１】本発明に係る実施形態のAPI自動生成システムの構成概要を示す図。
【図２】APIリクエスト-レスポンス管理部とAPI抽象化判定部との詳細動作のブロック図。
【図３】APIリクエスト-レスポンス管理部とAPI抽象化判定部との詳細動作のブロック図。
【図４】SDK最新化処理部とSDK、APL開発者管理部との詳細動作のブロック図。
【図５】書き換え前のSDKにおけるAPIＢとAPIＣとを実行するスクリプトを示す図。
【図６】書き換え後のSDKにおけるAPIＢとAPIＣとを抽象化したAPIを実行するスクリプトを示す図。
【図７】SDK、APL開発者管理部におけるアプリの管理内容、例えばアプリろの管理内容を示す図。
【図８】APL-SDKアップデート処理部とSDK、APL開発者管理部との詳細動作のブロック図。
【図９】APIの順次実行の静的指定のタイムチャート。
【図１０】APIの並列実行の静的指定のタイムチャート。
【図１１】APIの順次実行の動的指定のタイムチャート。
【図１２】APIの並列実行の動的指定のタイムチャート。
【図１３】実施形態のAPI自動生成システムＳにおいて抽象化APIを自動生成してSDKv1をSDKv2にバージョンアップする構成を示す図。
【図１４】従来のシステム概要図。
【図１５】従来のマッシュアップAPI生成後のシステム概要図。
【発明を実施するための形態】
【００２７】
以下、本発明の実施形態について、適宜図面を参照しながら詳細に説明する。
実施形態の抽象化API自動生成システムＳでは、API提供機能側で用意したSDKを、アプリに配布し、そのSDKを活用したアプリから利用されるAPIのリクエスト-レスポンス等を監視する。なお、アプリとは、ユーザのシステムのアプリケーションプログラムである。
【００２８】
そして、抽象化（マッシュアップ）すべきAPIと判断した場合、API提供機能側で抽象化API（マッシュアップAPI）を生成し、アプリで利用しているSDKのアップデートを実行する。
なお、APIの抽象化とは、複数のAPIによる処理を1つのAPI（マッシュアップAPI）で提供することである。
本発明により、アプリは、コードの書き直しをすることなく、応答時間の短縮や、API提供機能によるAPIの実行手順の最適化を図ることができる。
【００２９】
＜＜実施形態１＞＞
図１に本発明に係る実施形態のAPI自動生成システムの構成概要を示す。
API自動生成システムＳは、API統合基盤１を有している。
API統合基盤１は、APIを管理運営する通信インフラであり、ソフトウェアとハードウェアとで構成される。
【００３０】
API統合基盤１は、アプリ２とイネーブラＡ３ａ、Ｂ３ｂ、Ｃ３ｃ、Ｄ３ｄ、……とに、インターネット等の通信を介して接続されている。なお、アプリ２は、ユーザのシステムのアプリケーションプログラムである。
各々のアプリ２は、クラウド等に存在し、つまり、インターネットのＷＥＢ(World Wide Web)上に存在し、インターネットに接続されている。
例えば、アプリ２は、スマートフォン（スマホ）やパーソナルコンピュータ等の端末機に、インストールされている。
【００３１】
このクライアントのアプリ２が実行されることで、インターネット上のAPI統合基盤１にアクセスされる。API統合基盤１にはプログラムのコードが格納されており、このコードの中にAPI統合基盤１の各機能を実行するソースコードが記述されている。このソースコードが実行されることで、インターネットを介してAPI統合基盤１が稼働し、アプリ２およびイネーブラＡ３ａ、Ｂ３ｂ、Ｃ３ｃ、Ｄ３ｄ、……からのAPI統合基盤１に対するアクセス（入出力）が遂行される。
【００３２】
＜イネーブラＡ３ａ、Ｂ３ｂ、Ｃ３ｃ、Ｄ３ｄ、……＞
アプリ２のAPIへのアクセスが行われることで、API統合基盤１を介して、例えば位置情報取得機能としてのイネーブラＡ３ａから、「位置情報」が取得され、API統合基盤１を介して、スマートフォン（アプリ２）等の端末機に「位置情報」が返される。或いは、天気情報取得機能としてのイネーブラＢ３ｂから、「天気情報」が取得され、API統合基盤１を介して、スマートフォン等の端末機（アプリ２）に天気情報」が返される。
【００３３】
イネーブラＡ３ａ、Ｂ３ｂ、Ｃ３ｃ、Ｄ３ｄ、……は、通信処理機能を備え、位置検索や必要情報等のユーザ側のアプリ２が所望する情報を提供する等、何らかの目的を果たすための機能を有する装置である。換言すれば、イネーブラＡ３ａ、Ｂ３ｂ、Ｃ３ｃ、Ｄ３ｄ、……は、ある機能を有効にする装置である。
例えば、イネーブラＡ３ａはある地点の位置情報（緯度経度情報）取得機能を有しており、イネーブラＢ３ｂは、天気情報取得機能を有している。また、イネーブラＣ３ｃは、レコメンド機能を有している。イネーブラＡ３ａ、Ｂ３ｂ、Ｃ３ｃ、Ｄ３ｄ、……は、単数の機能を有していてもよいし、複数の機能を有していてもよい。
【００３４】
アプリ２は、対応するSDK（Software Development Kit）をもっている。アプリはSDKに連携して実行される。
SDKとは、ソフトウェアを開発するために必要な技術文書やツールなど一式をいう。SDKには、コンパイラやデバッカなどの開発ツール類や、利用者が作成したプログラムに連結して使用するクラスファイルやライブラリファイル、APIの仕様などを記述した文書ファイル、サンプルコードを記述したプログラムファイルなどが含まれる。つまり、アプリ２は適合するSDKによって、アプリ２のプログラムを開発することができる。
【００３５】
＜API統合基盤１＞
API統合基盤１は、開発者ポータル部１ａ、SDK、APL開発者管理部１ｂ、API実行機能部１ｃ、APIリクエスト-レスポンス管理部１ｄ、API抽象化判定部１ｅ、API抽象化部１ｆ、SDK最新化処理部１ｇ、およびAPL-SDKアップデート処理部１ｈを有している。
【００３６】
開発者ポータル部１ａは、APIを利用するための窓口機能を有しており、アプリ開発者のアプリ開発支援（APIドキュメントやAPI利用申請等）機能を有する。
SDK、APL開発者管理部１ｂは、各アプリ２のSDKや開発者を管理する。つまり、SDK、APL開発者管理部１ｂには、各アプリ２のSDK情報や開発者のＩＤ、パスワード等の個人情報が記憶されている。
【００３７】
API実行機能部１ｃは、APIを介して、アプリ２からのイネーブラＡ３ａ、Ｂ３ｂ、Ｃ３ｃ、Ｄ３ｄ、……へのアクセスを実現する。
APIリクエスト-レスポンス管理部１ｄは、アプリ２からのイネーブラＡ３ａ、Ｂ３ｂ、Ｃ３ｃ、Ｄ３ｄ、……へのリクエストと、イネーブラＡ３ａ、Ｂ３ｂ、Ｃ３ｃ、Ｄ３ｄ、……からのレスポンスが管理される。つまり、APIリクエスト-レスポンス管理部１ｄはイネーブラＡ３ａ、Ｂ３ｂ、Ｃ３ｃ、Ｄ３ｄ、……へのリクエストとレスポンスが記憶され、履歴等が管理される。
【００３８】
API抽象化判定部１ｅは、どのAPIを抽象化する（組み合わせる）か否か判定する。
API抽象化部１ｆは、抽象化すべきと判定されたAPIを抽象化する。
SDK最新化処理部１ｇは、SDKを最新に更新する。
APL-SDKアップデート処理部１ｈは、アプリ２やアプリ２に対するSDKの更新処理を行う。
【００３９】
次に、API統合基盤１の動作の概要について説明する。
（１）アプリ２から開発者ポータル部１ａに開発者の登録が行われる。これにより、開発者のＩＤ、パスワード等の固有の識別情報が開発者ポータル部１ａから開発者に付与される。
【００４０】
（２）開発者ポータル部１ａからアプリ２へは、随時、最新のSDKがダウンロードされる。
これにより、開発者ポータル部１ａにて開発者登録をしたアプリ開発者は、開発者ポータルからAPIを活用するためのSDKをダウンロードし、アプリを作成することができる。
【００４１】
（３）開発者ポータル部１ａはSDKのダウンロード情報をSDK、APL開発者管理部１ｂに反映する。
（４）アプリ２は、API実行機能部１ｃを介して、イネーブラＡ３ａ、Ｂ３ｂ、Ｃ３ｃ……等にAPIを実行し、イネーブラＡ３ａから経度、緯度情報を取得したり、イネーブラＢ３ｂから天気情報を取得したりする。
【００４２】
（５）API抽象化判定部１ｅは、定期的または随時、アプリ２毎のAPI利用状況を取得し、分析する。そして、API抽象化判定部１ｅは、抽象化対象のAPIをAPI抽象化部１ｆに通知する。
（６）API抽象化部１ｆは、通知されたAPIを抽象化する。そして、抽象化APIを受け付ける設定（プロキシ設定等）をAPI実行機能部１ｃに反映する。
【００４３】
（７）API抽象化部１ｆは、SDK最新化処理部１ｇに抽象化APIを通知する。
（８）SDK最新化処理部１ｇは、マッシュアップ（抽象化）APIのSDKを作成（更新）し、SDK、APL開発者管理部１ｂに最新のSDKを反映する。
最新のSDKを反映されたSDK、APL開発者管理部１ｂは、随時開発者ポータル部１ａに最新のSDK情報を反映する。
【００４４】
（９）APL-SDKアップデート処理部１ｈは、SDK、APL開発者管理部１ｂに各アプリ２のSDKの利用状況を確認する。
（１０）APL-SDKアップデート処理部１ｈは、SDK、APL開発者管理部１ｂから最新のSDK情報を取得し、アプリ２のSDKのバージョンアップを実施する。
【００４５】
（１１）マッシュアップAPIが作成された場合、アプリ２からAPI実行機能部１ｃを介してイネーブラＡ３ａ、Ｂ３ｂ、Ｃ３ｃ等にマッシュアップAPIが実行される。
以上が、API統合基盤１の動作の概要である。
【００４６】
API自動生成システムＳの動作を、アプリ開発者のオペレーションとともにまとめると、
開発者ポータル部１ａにて開発者登録をしたアプリ開発者は、開発者ポータル部１ａからAPIを活用するためのSDKをダウンロードし、アプリを作成する。
アプリ作成後に、API統合基盤１がアプリ２から利用されたAPIのリクエストとレスポンスを監視し、抽象化候補となるAPIを抽出し、抽象化APIを生成する。同時に、API統合基盤１にて実行するAPIの実行手順も判定する。
抽象化API生成後は、SDK最新化処理部１ｇにて、SDKが抽象化APIを利用する形式に変更し、アプリ側で使用しているSDKをAPI統合基盤１側からアップグレードさせる。
【００４７】
次に、上述のAPI自動生成システムＳの詳細な動作例について説明する。
＜APIリクエスト-レスポンス管理部１ｄとAPI抽象化判定部１ｅ＞
図２に、APIリクエスト-レスポンス管理部とAPI抽象化判定部との詳細動作のブロック図を示す。
【００４８】
APIリクエスト-レスポンス管理部１ｄは、API実行機能部１ｃ を介して、各アプリ２のアプリい２ａ〜アプリほ２ｅのAPI利用状況を管理し、抽象化の対象となるAPIの候補を抽出する。各アプリ２（アプリい２ａ〜アプリほ２ｅ）は、ID（API-Key等）で管理されている。
【００４９】
APIリクエスト-レスポンス管理部１ｄは、表１に示すように、各アプリ２（アプリい２ａ〜アプリほ２ｅ）毎にAPIが実行された順序を管理する。
表１は、APIリクエスト-レスポンス管理部１ｄの管理状況を示す表である。
【００５０】
【表１】
2017033424.tif 000003
【００５１】
アプリい２ａは、ＩＤがaaaaであり、APIＡ、APIＢの順にAPIを利用している。
アプリろ２ｂは、ＩＤがbbbbであり、APIＣ、APIＢ、APIＤの順にAPIを利用している。
アプリは２ｃは、ＩＤがccccであり、APIＣ、APIＢの順にAPIを利用している。
アプリに２ｄは、ＩＤがddddであり、APIＣ、APIＡ、APIＢの順にAPIを利用している。
アプリほ２ｅは、ＩＤがeeeeであり、APIＣ、APIＡ、APIＤの順にAPIを利用している。
【００５２】
そして、API抽象化判定部１ｅは、APIリクエスト-レスポンス管理部１ｄから定期的にまたは随時アプリ（２ａ〜２ｅ）毎のAPI利用状況を取得して分析する。
そして、API抽象化判定部１ｅは、抽象化の候補となるAPIの組み合わせを抽出する。
【００５３】
表２は、APIリクエスト-レスポンス管理部１ｄのアプリ毎のAPI利用状況を取得・分析状況を示す表である。
【表２】
2017033424.tif 000004
【００５４】
アプリい２ａは、APIＡ、APIＢの順にAPIを利用しているので、ＡＢのAPIの組み合わせがある。
アプリろ２ｂは、、APIＣ、APIＢ、APIＤの順にAPIを利用しているので、ＣＢ、ＢＤ、ＣＢＤのAPIの組み合わせがある。
【００５５】
アプリは２ｃは、APIＣ、APIＢの順にAPIを利用しているので、ＣＢのAPIの組み合わせがある。
アプリに２ｄは、APIＣ、APIＡ、APIＢの順にAPIを利用しているので、ＣＡ、ＡＢ、ＣＡＢのAPIの組み合わせがある。
【００５６】
アプリほ２ｅは、APIＣ、APIＡ、APIＤの順にAPIを利用しているので、ＣＡ、ＡＤ、ＣＡＤの各順のAPIの組み合わせがある。
API抽象化判定部１ｅの抽象化すべきAPIの抽出方法は、2つ以上のAPIが実行されている場合、表２に示すように、利用順序に従って抽象化するAPIの組み合わせを抽出する。
【００５７】
例えば、表２より、アプリろ２ｂとアプリは２ｃがＣＢの順にAPIを利用しており、アプリに２ｄとアプリほ２ｅは、ＣＡの順にAPIを利用している。そこで、APIの利用が複数、つまりしきい値の“２”以上重複しているので、APIがＣＢとＣＡとをAPIの抽象化の対象とする。なお、API提供者にて抽象化の対象のAPIが複数利用されているとみなすしきい値は任意に設定可能とする。ここでは、複数のしきい値は“２”である。
利用されているAPIを抽出後、複数のしきい値以上の組み合わせが抽出された場合（ここでは、ＣＢとＣＡ）、下記のように、API抽象化部１ｆにて、APIの抽象化を実施する。
【００５８】
＜API抽象化判定部１ｅとAPI抽象化部１ｆ＞
次に、API抽象化判定部１ｅとAPI抽象化部１ｆの詳細な動作例について説明する。
図３に、APIリクエスト-レスポンス管理部とAPI抽象化判定部との詳細動作のブロック図を示す。
【００５９】
API抽象化判定部１ｅは、抽象化候補となったAPIのリクエストとレスポンス内容を分析する。リクエスト-レスポンスの分析から、API抽象化判定部１ｅは、抽象化するAPIが順時実行型か並列実行型かを判定する。
そして、API抽象化部１ｆは、API抽象化判定部１ｅの判定結果に基づいて、APIの抽象化を行う。
【００６０】
以下その詳細を説明する。
レスポンスとして得られた値を他のAPIのリクエスト値として、そのまま流用している場合は、順時実行型のマッシュアップAPIとして、API抽象化部１ｆで作成（生成）する。
例えば、表３は、アプリろ２ｂのAPIＣ、APIＢの順にAPIを利用している場合のパラメータの内容を示す表である。
【００６１】
【表３】
2017033424.tif 000005
【００６２】
アプリろ２ｂのAPIＣのレスポンスは、“ <lat>N35.000</lat><lon>E139.000</lat> ”であり、APIＢのリクエストは、“ <lat>N35.000</lat><lon>E139.000</lat> ”である。つまり、一のAPI(API C)から得られたレスポンス結果をそのまま他のAPI(API B)のリクエスト内容に流用している。
【００６３】
そこで、API抽象化判定部１ｅは、レスポンスとして得られた値を他のAPIのリクエスト値として、そのまま流用していることから、APIＣとAPIＢとを、順時実行型のマッシュアップ（抽象化）APIとして、API抽象化部１ｆで作成する。
【００６４】
一方、API抽象化部１ｆは、抽象化候補となったAPIのリクエストとレスポンス内容を分析し、レスポンスとして得られた値を他のAPIのリクエスト値として、流用していない場合、並列実行型のマッシュアップAPIとして、API抽象化部１ｆで作成する。
【００６５】
例えば、表４は、アプリろ２ｂのAPIＣ、APIＢの順にAPIを利用している場合の他のパラメータの内容を示す表である。
【表４】
2017033424.tif 000006
【００６６】
アプリは２ｃのAPIＣのレスポンスは、“ <lat>N35.000</lat><lon>E139.000</lat> ”であり、APIＢへのリクエストは、“ <lat>N59.000</lat><lon>E129.000</lat>”である。つまり、一のAPI(APIC)から得られたレスポンス結果をそのまま利用せず、異なるパラメータを用いて他のAPI(APIB)にリクエスト送信をしている。
【００６７】
そこで、API抽象化判定部１ｅは、一のAPI(API C)から得られたレスポンス結果をそのまま利用せず、異なるパラメータを用いて他のAPI(API B)にリクエスト送信をしていることから、APIＣとAPIＢとを、並列実行型のマッシュアップAPIとして、API抽象化部１ｆで作成する。
【００６８】
こうして、API抽象化部１ｆは、順時実行型のマッシュアップAPIまたは並列実行型のマッシュアップAPIを作成する。同時に、API抽象化部１ｆはAPI実行機能部１ｃにマッシュアップAPI生成の情報を通知し、API実行機能部１ｃは生成した抽象化API（マッシュアップAPI）の受付を可能にする設定を実行する。
【００６９】
＜SDK最新化処理部１ｇとSDK、APL開発者管理部１ｂ＞
次に、SDK最新化処理部１ｇとSDK、APL開発者管理部１ｂの詳細な動作例について説明する。
【００７０】
図４に、SDK最新化処理部とSDK、APL開発者管理部との詳細動作のブロック図を示す。
API実行機能部１ｃでの抽象化APIのリクエスト受信の設定が完了後、API実行機能部１ｃはSDK最新化処理部１ｇに抽象化APIを受けつける設定が完了したことを通知する。通知後、SDK最新化処理部１ｇは、スクリプトを書き換える領域をSDK、APL開発者管理部１ｂに問い合わせ、SDKにおける当該抽象化APIを実行する部分のスクリプトを、抽象化APIを活用した記述の仕様に書き換える処理を実施する。
【００７１】
つまり、SDK最新化処理部１ｇは、SDKにおけるAPI-BとAPI-Cを呼び出しているソースコードを抽出し、抽出された部分を抽象化APIを呼び出すコードに書き換える。
図５に、書き換え前のSDKにおけるAPIBとAPICとを実行するスクリプトを示し、図6に書き換え後のトを示す。
【００７２】
例えば、図５に示す書き換え前のSDKにおけるAPIＢとAPIＣとを実行するスクリプトを、図６に示すSDKにおけるAPIＢとAPIＣとを抽象化したAPIに書き換える。
SDK最新化処理部１ｇは、SDKの仕様を抽象化APIを活用した記述に変更した後、SDK、APL開発者管理部１ｂにバージョン情報と共に変更後の記載内容、すなわち変更したスクリプトを通知する。また、SDK最新化処理部１ｇは、SDKの仕様を抽象化APIを活用した記述に変更した旨をSDKアップデート処理部に通知する。
【００７３】
図７に、SDK、APL開発者管理部におけるアプリの管理内容、例えばアプリろの管理内容を示す。
図７に示すように、アプリろのIDは“bbbb”であり、利用SDK配置箇所は ‘/path/bbbb/api-sdk である。
【００７４】
SDKの記述の変更前、図７の上欄に示すように、SDKバージョン１（v1）には、APIＢを呼び出すスクリプトには、“curl#setopt($lanlon#ch, CURLOPT#URL,’https://apiproxyB/v1/...”と記述されており、APIＣを呼び出すスクリプトには、“curl#setopt($Postcode#ch, CURLOPT#URL,‘https://apiproxyC/v1/... ”と記述されている。SDKバージョン１（v1）のダウンロード日時は、“2015/06/08 15:00”である。
【００７５】
SDK、APL開発者管理部１ｂは、変更したスクリプトが通知された後、図７の下欄に示すように、SDKバージョン１．１（v1.1）として、スクリプト変更領域として、図７の上欄の APIＢの記述とAPIＣの記述とを、“curl#setopt($mashup#ch, CURLOPT#URL,'https://apiproxyB-C/v1/…”の抽象化APIを呼び出すコードに変更する。
【００７６】
これにより、SDK、APL開発者管理部１ｂは、SDK更新履歴を管理することができる。また、SDK更新履歴をソフトウェアの保守、開発等に活用できる。
また、SDK最新化処理部１ｇは、APL-SDKアップデート処理部１ｈにアプリ２のSDKが更新されたことを通知する。
【００７７】
＜APL-SDKアップデート処理部１ｈとSDK、APL開発者管理部１ｂ＞
次に、APL-SDKアップデート処理部１ｈとSDK、APL開発者管理部１ｂの動作の詳細について説明する。
図８に、APL-SDKアップデート処理部とSDK、APL開発者管理部との詳細動作のブロック図を示す。
【００７８】
APL-SDKアップデート処理部１ｈは、定期的に、SDK、APL開発者管理部１ｂに、各アプリ２ａ〜２ｅのSDKバージョン情報を参照し、SD最新化処理部１ｇのSDKの更新情報を元に、アプリ２側で導入しているSDKが最新化されているか否かを確認をする。
【００７９】
アプリ２ａ〜２ｅ側で導入しているSDKが最新化されていない場合、つまり最新バージョンへの変更がなされていない場合、利用SDK配置箇所（パソコン、スマホ、サーバ等）の端末機に、API統合基盤１のAPL-SDKアップデート処理部１ｈから、該当するアプリ２のSDKのアップグレードを実行する。利用SDK配置箇所（パソコン、スマホ、サーバ等）の端末機は、アップグレード情報をアプリ開発者に伝え、アプリ開発者からのアップグレード許諾を得た上で、情報を格納する。なお、アプリ開発者からのアップグレード許諾を得ないで、情報を格納する構成としてもよい。
【００８０】
＜APIの実行パターン＞
複数のAPIの実行形式として、「順次実行」と「並列実行」がある。「並列実行」はリアルタイム性が要求されるアプリに対して可能な限り応答時間を短縮したいケースで有効である。つまり、「並列実行」は APIを並列に実行することで、応答時間を短縮する。
これに対して、「順次実行」はAPIを順番に実行するので、応答時間が長くなり、応答時間の長さが問題にならないケースに適合する。
【００８１】
「順次実行」と「並列実行」については、さらに、予め実行するAPIを指定しておく「静的指定」（図９、図１０参照）と、APIの実行結果（可変個）をもとに実行するAPIを動的に指定する「動的指定」（図１１、図１２参照）のパターンに分けられる。
【００８２】
＜順次実行の静的指定＞
図９に、APIの順次実行の静的指定のタイムチャートを示す。なお、図９〜図１２において、実線矢印はリクエストを示し、破線矢印はレスポンスを示す。
順次実行の静的指定では、図９に示すように、APIが実行される。
【００８３】
アプリ２は、APIアグリゲーションに郵便番号に送り、位置情報を問い合わせる（図９のステップＳ１１）。APIアグリゲーションはイネーブラ（１）に郵便番号を送り、位置情報を問い合わせる（ステップＳ１２）。イネーブラ（１）はAPIを実行し（ステップＳ１３）、緯度・経度情報をAPIアグリゲーションに送る（ステップＳ１４）。
【００８４】
続いて、APIアグリゲーションは、郵便番号をイネーブラ（２）に送り、天気を問い合わせる（ステップＳ１５）。イネーブラ（２）はAPIを実行し（ステップＳ１６）、天気情報（晴／曇／雨等）をAPIアグリゲーションに送る（ステップＳ１７）。
【００８５】
APIアグリゲーションは、アプリ２に緯度・経度情報と天気情報（晴／曇／雨等）とを送る（ステップＳ１８）。
上述したように、順次実行の静的指定は、予め指定したイネーブラ（１）、（２）のAPIを、指定した順番（イネーブラ（１）、（２）の順）で実行する。これにより、予め指定したイネーブラの順に、順次実行を遂行することができる。
【００８６】
＜並列実行の静的指定＞
図１０に、APIの並列実行の静的指定のタイムチャートを示す。
並列実行の静的指定では、図１０に示すように、APIが実行される。
アプリ２は、APIアグリゲーションに郵便番号に送り、位置情報、天気情報を問い合わせる（図１０のステップＳ２１）。
【００８７】
APIアグリゲーションは、イネーブラ（１）に郵便番号を送り、位置情報を問い合わせる（ステップＳ２２）とともに、イネーブラ（２）に郵便番号を送り、天気情報を問い合わせる（ステップＳ２３）。
【００８８】
イネーブラ（１）はAPIを実行し（ステップＳ２４）、緯度、経度情報をAPIアグリゲーションに送る（ステップＳ２５）。また、イネーブラ（２）はAPIを実行し（ステップＳ２６）、天気情報（晴／曇／雨等）をAPIアグリゲーションに送る（ステップＳ２７）。
【００８９】
APIアグリゲーションは、緯度・経度情報と天気情報（晴／曇／雨等）とをアプリ２に送る（ステップＳ２８）。
上述したように、並列実行の静的指定は、予め指定したイネーブラ（１）、（２）のAPIを同時に実行する。これにより、予め指定したイネーブラの順に、順次実行を遂行することができる。短い時間で処理を遂行することができる。
【００９０】
＜順次実行の動的指定＞
図１１に、APIの順次実行の動的指定のタイムチャートを示す。
順次実行の動的指定では、図１１に示すように、APIが実行される。
アプリ２は、APIアグリゲーションに検索したい“つぶやき”のキーワードを含むつぶやき情報を送る（図１１のステップＳ３１）。APIアグリゲーションは当該つぶやき情報をイネーブラ（１）に送る（ステップＳ３２）。
【００９１】
イネーブラ（１）はAPIを実行し、該当のキーワードを含むつぶやきを検索した結果、複数件検索（例えば2件ヒット）し、そのキーワードがつぶやかれた場所の第１・第２の緯度・経度情報を取得する。そして、イネーブラ（１）はそのキーワードがつぶやかれた場所の第１・第２の緯度・経度情報（2件分）をAPIアグリゲーションに返却する（ステップＳ３４）。
【００９２】
APIアグリゲーションは、第１の緯度・経度情報をイネーブラ（２）に送る（ステップＳ３５）。イネーブラ（２）は取得した第１の緯度・経度情報をもとに、イネーブラ（２）のAPIを実行する（ステップＳ３６）。イネーブラ（２）は、第１の緯度・経度の地点の気温情報をAPIアグリゲーションに返却する（ステップＳ３７）。
【００９３】
続いて、APIアグリゲーションは、第２の緯度・経度情報をイネーブラ（２）に送る（ステップＳ３８）。イネーブラ（２）は取得した第２の緯度・経度情報をもとに、イネーブラ（２）のAPIを実行する（ステップＳ３９）。イネーブラ（２）は、第２の緯度・経度の地点の気温情報をAPIアグリゲーションに返却 する（ステップＳ４０）。
【００９４】
そして、APIアグリゲーションは、第１、第２の緯度・経度情報とそれぞれの気温情報をアプリ２に送る（ステップＳ４０ａ）。
【００９５】
上述したように、順次実行の動的指定では、取得した緯度・経度情報をもとに、順番にイネーブラ（１）、（２）の各APIを実行する。そして、該当の緯度・経度の地点の気温情報をそれぞれアプリ２に返却する。これにより、APIの実行結果に基づき、順次実行を遂行することができる。
【００９６】
＜並列実行の動的指定＞
図１２に、APIの並列実行の動的指定のタイムチャートを示す。
アプリ２は、APIアグリゲーションに検索したい“つぶやき”のキーワードを含むつぶやき情報を送る（図１２のステップＳ４１）。APIアグリゲーションは当該つぶやき情報をイネーブラ（１）に送る（ステップＳ４２）。
【００９７】
イネーブラ（１）はAPIを実行し（ステップＳ４３）、該当のキーワードを含むつぶやきを検索した結果、複数件検索（例えば2件ヒット）し、そのキーワードがつぶやかれた場所の第１・第２の緯度・経度情報を取得する。イネーブラ（１）は第１・第２の緯度・経度情報をAPIアグリゲーションに送る（ステップＳ４４）。
【００９８】
APIアグリゲーションは、第１の緯度・経度情報をイネーブラ（２）に送る（ステップＳ４５）とともに、第２の緯度・経度情報をイネーブラ（２）に送る（ステップＳ４６）。
イネーブラ（２）は、第１の緯度・経度情報を元に、APIを実行し、第１の緯度・経度情報地点の気温情報を取得する（ステップＳ４７）。同時に、イネーブラ（２）は、第２の緯度・経度情報を元に、APIを実行し、第２の緯度・経度情報地点の気温情報を取得する（ステップＳ４８）。
【００９９】
イネーブラ（２）は、第１の緯度・経度情報地点の気温情報をAPIアグリゲーションに返却する（ステップＳ４９）とともに、第２の緯度・経度情報地点の気温情報をAPIアグリゲーションに返却する（ステップＳ５０）
アグリゲーションは、第１、第２の緯度・経度情報とそれぞれの気温情報をアプリ２に送る（ステップＳ５１）。
【０１００】
上述したように、並列実行の動的指定では、取得した緯度・経度情報をもとに、イネーブラ（２）のAPIを同時に実行する。そして、該当の緯度・経度の地点の気温情報をそれぞれ返却 する。これにより、APIの実行結果に基づき、並列実行を遂行することができる。そのため、短い時間で処理を遂行することができる。
【０１０１】
以上、APIの実行パターンの順次実行の静的指定、並列実行の静的指定、順次実行の動的指定、並列実行の動的指定の各実行概要をまとめると、表５のようになる。
【０１０２】
【表５】
2017033424.tif 000007
【０１０３】
上記構成によれば、API提供機能側で用意したSDKをアプリに配布し、そのSDKを活用したアプリから利用されるAPIのリクエスト-レスポンス等を監視し、マッシュアップすべきAPIと判定した場合、API提供機能側でマッシュアップAPIを作成し、アプリで利用しているSDKのアップデートを実行することができる。
ここで、マッシュアップすべきAPIの判定は、複数の閾値以上の場合に抽象化APIすべきAPIとするので、閾値を定めることで、抽象化APIすべきAPIの基準を任意に定めることができる。
【０１０４】
そのため、図１３に示すように、アプリのSDKのバージョンアップ（SDKv1からSDKv2に更新）をAPI統合基盤１の側から実行し、開発者にてスクリプトの変更をしなくてもマッシュアップAPI５が活用される。 図１３に、実施形態のAPI自動生成システムにおいて抽象化APIを自動生成してSDKv1をSDKv2にバージョンアップする構成を示す。
また、SDKを更新した際、SDK、APL開発者管理部１ｂで履歴を管理するので、後のシステム、ソフトウェアの保守、開発に役立てることができる。
【０１０５】
従って、アプリ開発者は、アプリのソースコード等の書き直しをせずに、応答時間の短縮や、API提供機能によるAPIの実行手順の最適化を図ることができる。
【０１０６】
以上、実施形態を説明したが、本発明は、特許請求の範囲内で様々な具体的形態が可能である。
【符号の説明】
【０１０７】
１      API統合基盤（SDK、APL開発者管理部、API監視部、API抽象化判定部、抽象化API作成部、SDK更新部）
１ｂ    SDK管理部（SDK、APL開発者管理部）
１ｄ    APIリクエスト-レスポンス管理部 （API監視部）
１ｅ    API抽象化判定部
１ｆ    API抽象化部（抽象化API生成部）
１ｇ    SDK最新化処理部（SDK更新部）
１ｈ    APL-SDKアップデート処理部（SDK更新部）
２      アプリケーション
２ａ    アプリい（アプリケーション）
２ｂ    アプリろ（アプリケーション）
２ｃ    アプリは（アプリケーション）
２ｄ    アプリに（アプリケーション）
２ｅ    アプリほ（アプリケーション）
３ａ、３ｂ、３ｃ、３ｄ  イネーブラ
Ｓ      API自動生成システム（抽象化API自動生成システム）
【図１】
2017033424.tif 000008
【図２】
2017033424.tif 000009
【図３】
2017033424.tif 000010
【図４】
2017033424.tif 000011
【図５】
2017033424.tif 000012
【図６】
2017033424.tif 000013
【図７】
2017033424.tif 000014
【図８】
2017033424.tif 000015
【図９】
2017033424.tif 000016
【図１０】
2017033424.tif 000017
【図１１】
2017033424.tif 000018
【図１２】
2017033424.tif 000019
【図１３】
2017033424.tif 000020
【図１４】
2017033424.tif 000021
【図１５】
2017033424.tif 000022