JP7367783B2 - サービス設計装置、サービス設計方法およびサービス設計プログラム - Google Patents

Description

本発明は、サービス設計装置、サービス設計方法およびサービス設計プログラムに関する。

従来、クラウドやオンプレミスの様々なアプリケーションを組み合わせて、業務システムを構築するクラウドサービスがある。また、複数のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を組み合わせて、新たなＡＰＩを作成する場合がある。

先行技術としては、１つのサービスのエラーにより生じる他のサービスの処理コストと、エラーの発生確率とを用いて正規化される正規化コストを、サービスの各々について算出し、算出した正規化コストに従って、サービスの実行順序を決定するものがある。また、デバイスとのユーザ対話を容易にし、ローカルサービスおよび／またはリモートサービスを使用しやすくするためのアシスタントシステムがある。

また、複数のサービスの現在の順序列を更新するための条件が満足される場合、ユーザ端末の表示装置上に表示される複数のサービスの更新される順序列を決定する技術がある。また、プラント制御機能を提供するクラウドサービスの動作状態を検証し、検証された動作状態に基づき、クラウドサービスを選択し、選択されたクラウドサービスと利用装置との間でサービス情報を伝達する技術がある。

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

しかしながら、従来技術では、複数のＡＰＩを組み合わせて新たなＡＰＩを作成するにあたり、複数のＡＰＩの適切な実行順序を判断するのに時間や手間がかかるという問題がある。

一つの側面では、本発明は、複数のＡＰＩを用いたサービスの設計を容易にすることを目的とする。

一つの実施態様では、複数のＡＰＩの選択を受け付ける受付部と、選択された前記複数のＡＰＩの各々のＡＰＩの仕様および使用履歴の少なくともいずれかの情報に基づいて、前記複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定する特定部と、前記特定部によって特定された前記ＡＰＩ間の呼び出しの順序関係に基づいて、前記複数のＡＰＩの実行順序を決定する決定部と、を有するサービス設計装置が提供される。

本発明の一側面によれば、複数のＡＰＩを用いたサービスの設計を容易にすることができるという効果を奏する。

図１は、実施の形態にかかるサービス設計方法の一実施例を示す説明図である。 図２は、情報処理システム２００のシステム構成例を示す説明図である。 図３は、サービス設計装置１０１のハードウェア構成例を示すブロック図である。 図４は、利用者端末２０１のハードウェア構成例を示すブロック図である。 図５は、ＡＰＩリポジトリ２２０の記憶内容の一例を示す説明図である。 図６は、サービス設計装置１０１の機能的構成例を示すブロック図である。 図７は、複数のＡＰＩの実行順序の第１の決定例を示す説明図（その１）である。 図８は、複数のＡＰＩの実行順序の第１の決定例を示す説明図（その２）である。 図９は、複数のＡＰＩの実行順序の第２の決定例を示す説明図（その１）である。 図１０は、複数のＡＰＩの実行順序の第２の決定例を示す説明図（その２）である。 図１１は、複数のＡＰＩの実行順序の出力例を示す説明図である。 図１２は、実行履歴テーブル１２００の記憶内容の一例を示す説明図である。 図１３は、推奨結果情報の具体例を示す説明図である。 図１４は、サービス設計装置１０１のサービス設計処理手順の一例を示すフローチャート（その１）である。 図１５は、サービス設計装置１０１のサービス設計処理手順の一例を示すフローチャート（その２）である。

以下に図面を参照して、本発明にかかるサービス設計装置、サービス設計方法およびサービス設計プログラムの実施の形態を詳細に説明する。

（実施の形態）
図１は、実施の形態にかかるサービス設計方法の一実施例を示す説明図である。図１において、サービス設計装置１０１は、複数のＡＰＩの実行順序を決定するコンピュータである。ＡＰＩは、ソフトウェア同士をつなげるインターフェースであり、例えば、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やアプリケーションが、他のアプリケーションに対して、機能の一部を利用可能に提供する。

ＡＰＩとしては、例えば、Ｗｅｂ ＡＰＩが挙げられる。Ｗｅｂ ＡＰＩは、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルを用いて、ネットワークを介して呼び出すソフトウェア間のインターフェースである。ＡＰＩは、例えば、一連の手続きや関数の集まりなどにより実現される。

ここで、複数のＡＰＩを組み合わせて、新たなＡＰＩを作成する場合がある。例えば、投稿サービスに投稿された記事から特定のキーワードを含む記事を検索し、検索した記事を、あるサービスで分析したり、加工したりして、その結果を別のサービスに送信する機能を提供するとする。この場合、各サービスで提供されているＡＰＩを組み合わせて新たなＡＰＩを作成し、その機能を提供するアプリケーションやサービスを設計することになる。

しかし、単純にＡＰＩを直列に実行させると、実行時間やコストの増大を招いてしまう。例えば、アプリケーションの実行時間が増大すると、ユーザの待ち時間が増えるとともに、アプリケーションを動作させるインフラのコストが増える。そもそもどの順番で直列に実行すればよいのかを利用者が判断できない場合もある。

一方、実行時間やコストを削減するために、複数のＡＰＩの並列処理や順序関係を利用者にモデリングさせると、作業が複雑になり、ＩＴに詳しくないビジネスユーザが使うことが難しくなる。また、ＩＴスキルの高いユーザであっても、アプリケーションの実行時間が最短となるような設計を行うには時間や手間がかかり、生産性の低下につながるおそれがある。

そこで、本実施の形態では、ユーザが組み合わせたい複数のＡＰＩを選択するだけで、複数のＡＰＩの適切な実行順序を特定して、高品質なＡＰＩサービスの設計を支援するサービス設計方法について説明する。以下、サービス設計装置１０１の処理例について説明する。

（１）サービス設計装置１０１は、複数のＡＰＩの選択を受け付ける。具体的には、例えば、サービス設計装置１０１は、ユーザの操作入力により、ＡＰＩリストから、任意のＡＰＩの選択を受け付けることにより、複数のＡＰＩの選択を受け付ける。ＡＰＩリストは、選択可能なＡＰＩをリスト化したものである。

図１の例では、ユーザが組み合わせたい複数のＡＰＩとして、ＡＰＩ１，ＡＰＩ２，ＡＰＩ３，ＡＰＩ４，ＡＰＩ５が選択された場合を想定する。

（２）サービス設計装置１０１は、記憶部１１０を参照して、選択された複数のＡＰＩの各々のＡＰＩの仕様および使用履歴の少なくともいずれかの情報に基づいて、複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定する。ここで、記憶部１１０は、ＡＰＩの仕様および使用履歴の情報を記憶する。

ＡＰＩの仕様は、例えば、ＡＰＩの名称、機能、目的、リクエストおよびレスポンスのフォーマットなどを表す情報である。また、ＡＰＩの使用履歴は、ＡＰＩが実行された際の履歴を表す情報であり、例えば、当該ＡＰＩと組み合わせて実行された他のＡＰＩや、そのときのＡＰＩの実行順序などを表す。

例えば、ＡＰＩ１のリクエスト項目とレスポンス項目のフォーマットを「［Ｉｎ：＊，Ｏｕｔ：画像］」とする。「Ｉｎ：＊」は、リクエスト項目として任意のデータを入力することを示す。「Ｏｕｔ：画像」は、レスポンス項目として画像を出力することを示す。また、ＡＰＩ５のリクエスト項目とレスポンス項目のフォーマットを「［Ｉｎ：画像，Ｏｕｔ：＊］」とする。「Ｉｎ：画像」は、リクエスト項目として画像を入力することを示す。「Ｏｕｔ：＊」は、レスポンス項目として任意のデータを出力することを示す。

この場合、ＡＰＩ１のレスポンス項目のフォーマット「画像」と、ＡＰＩ５のリクエスト項目のフォーマット「画像」とが一致し、ＡＰＩ１からのレスポンスが、ＡＰＩ５のリクエストとして入力されるという入出力関係が存在し得る。このため、サービス設計装置１０１は、例えば、ＡＰＩ１の仕様とＡＰＩ５の仕様に基づいて、ＡＰＩ１，ＡＰＩ５間の呼び出しの順序関係として、「ＡＰＩ１→ＡＰＩ５」を特定する。

また、過去にＡＰＩ２とＡＰＩ４とが組み合わせて使用されており、ＡＰＩ２の後にＡＰＩ４が実行された回数が最も多いとする。この場合、サービス設計装置１０１は、例えば、ＡＰＩ２とＡＰＩ４の使用履歴に基づいて、ＡＰＩ２，ＡＰＩ４間の呼び出しの順序関係として、「ＡＰＩ２→ＡＰＩ４」を特定する。

図１の例では、選択されたＡＰＩ１～ＡＰＩ５に含まれるＡＰＩ１，ＡＰＩ５間の呼び出しの順序関係として、「ＡＰＩ１→ＡＰＩ５」が特定された場合を想定する。また、ＡＰＩ３，ＡＰＩ５間の呼び出しの順序関係として、「ＡＰＩ３→ＡＰＩ５」が特定された場合を想定する。また、ＡＰＩ２，ＡＰＩ４間の呼び出しの順序関係として、「ＡＰＩ２→ＡＰＩ４」が特定された場合を想定する。

（３）サービス設計装置１０１は、特定したＡＰＩ間の呼び出しの順序関係に基づいて、複数のＡＰＩの実行順序を決定する。具体的には、例えば、サービス設計装置１０１は、呼び出しの順序関係があるＡＰＩ同士を、その関係に従って実行する順序に決定する。また、サービス設計装置１０１は、呼び出しの順序関係がないＡＰＩ同士を、並列に実行する順序に決定する。

図１の例では、選択されたＡＰＩ１～ＡＰＩ５のうち、ＡＰＩ１，ＡＰＩ５は、呼び出しの順序関係「ＡＰＩ１→ＡＰＩ５」があるため、その関係に従って実行する順序に決定される。また、ＡＰＩ３，ＡＰＩ５は、呼び出しの順序関係「ＡＰＩ３→ＡＰＩ５」があるため、その関係に従って実行する順序に決定される。また、ＡＰＩ２，ＡＰＩ４は、呼び出しの順序関係「ＡＰＩ２→ＡＰＩ４」があるため、その関係に従って実行する順序に決定される。

また、ＡＰＩ１，ＡＰＩ２，ＡＰＩ３は、呼び出しの順序関係がないため、並列に実行する順序に決定される。なお、ＡＰＩ１は、ＡＰＩ４とも並列に実行可能である。しかし、ＡＰＩ４は、ＡＰＩ１と並列に実行するＡＰＩ２との間で呼び出しの順序関係がある。このため、この例では、ＡＰＩ１とＡＰＩ４は並列に実行しない順序とする。また、ＡＰＩ４，ＡＰＩ５は、呼び出しの順序関係がないため、並列に実行する順序に決定される。

なお、２以上のＡＰＩを並列に実行する順序に決定するとは、例えば、それらＡＰＩを並列に実行可能なＡＰＩとして設定することに相当する。図１の例では、ＡＰＩ１～ＡＰＩ５を組み合わせた新たなＡＰＩを実行する際には、ＡＰＩ１～ＡＰＩ３を並列に実行を開始した後、ＡＰＩ１～ＡＰＩ３の実行状況によっては、ＡＰＩ４がＡＰＩ５よりも先に実行されることにしてもよい。

このように、サービス設計装置１０１によれば、ユーザが組み合わせたい複数のＡＰＩを選択するだけで、ＡＰＩ間の呼び出しの順序関係や並列性を考慮したＡＰＩの実行順序を導出することができる。これにより、複数のＡＰＩを組み合わせて新たなＡＰＩを作成するにあたり、複数のＡＰＩの適切な実行順序を特定可能となり、容易に高品質なＡＰＩサービスを設計することができる。

図１の例では、ＡＰＩ１，ＡＰＩ２，ＡＰＩ３を並列に実行した後、ＡＰＩ４，ＡＰＩ５を並列に実行する実行順序が決定される。なお、２以上のＡＰＩ（例えば、ＡＰＩ４，ＡＰＩ５）を並列に実行する順序に決定するとは、それらＡＰＩを並列に実行可能なＡＰＩとして設定することに相当する。例えば、ＡＰＩ１～ＡＰＩ５を組み合わせた新たなＡＰＩを実行する際には、ＡＰＩ１～ＡＰＩ３を並列に実行を開始した後、ＡＰＩ１～ＡＰＩ３の実行状況によっては、ＡＰＩ４がＡＰＩ５よりも先に実行されてもよい。

（情報処理システム２００のシステム構成例）
つぎに、図１に示したサービス設計装置１０１を含む情報処理システム２００のシステム構成例について説明する。情報処理システム２００は、例えば、ＡＰＩの実行環境を提供するコンピュータシステムに適用される。

図２は、情報処理システム２００のシステム構成例を示す説明図である。図２において、情報処理システム２００は、サービス設計装置１０１と、利用者端末２０１とを含む。情報処理システム２００において、サービス設計装置１０１および利用者端末２０１は、有線または無線のネットワーク２１０を介して接続される。ネットワーク２１０は、例えば、インターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などである。

ここで、サービス設計装置１０１は、ＡＰＩリポジトリ２２０を有する。ＡＰＩリポジトリ２２０は、ＡＰＩの仕様および使用履歴の情報を記憶する。図１に示した記憶部１１０は、例えば、ＡＰＩリポジトリ２２０に相当する。ＡＰＩリポジトリ２２０の記憶内容については、図５を用いて後述する。サービス設計装置１０１は、例えば、クラウドコンピューティングのサーバである。

利用者端末２０１は、情報処理システム２００のユーザが使用するコンピュータである。ユーザは、例えば、複数のＡＰＩを組み合わせて新たなＡＰＩを作成する者や、新たなＡＰＩを利用する者である。利用者端末２０１は、例えば、ＰＣ、タブレット型ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）などである。

なお、図２の例では、サービス設計装置１０１と利用者端末２０１とを別体に設けることにしたが、これに限らない。例えば、サービス設計装置１０１は、利用者端末２０１により実現されることにしてもよい。

（サービス設計装置１０１のハードウェア構成例）
図３は、サービス設計装置１０１のハードウェア構成例を示すブロック図である。図３において、サービス設計装置１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、メモリ３０２と、ディスクドライブ３０３と、ディスク３０４と、通信Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０５と、可搬型記録媒体Ｉ／Ｆ３０６と、可搬型記録媒体３０７と、を有する。また、各構成部は、バス３００によってそれぞれ接続される。

ここで、ＣＰＵ３０１は、サービス設計装置１０１の全体の制御を司る。ＣＰＵ３０１は、複数のコアを有していてもよい。メモリ３０２は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭがＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）のプログラムを記憶し、ＲＯＭがアプリケーションプログラムを記憶し、ＲＡＭがＣＰＵ３０１のワークエリアとして使用される。メモリ３０２に記憶されるプログラムは、ＣＰＵ３０１にロードされることで、コーディングされている処理をＣＰＵ３０１に実行させる。

ディスクドライブ３０３は、ＣＰＵ３０１の制御に従ってディスク３０４に対するデータのリード／ライトを制御する。ディスク３０４は、ディスクドライブ３０３の制御で書き込まれたデータを記憶する。ディスク３０４としては、例えば、磁気ディスク、光ディスクなどが挙げられる。

通信Ｉ／Ｆ３０５は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して外部のコンピュータ（例えば、図２に示した利用者端末２０１）に接続される。そして、通信Ｉ／Ｆ３０５は、ネットワーク２１０と装置内部とのインターフェースを司り、外部のコンピュータからのデータの入出力を制御する。通信Ｉ／Ｆ３０５には、例えば、モデムやＬＡＮアダプタなどを採用することができる。

可搬型記録媒体Ｉ／Ｆ３０６は、ＣＰＵ３０１の制御に従って可搬型記録媒体３０７に対するデータのリード／ライトを制御する。可搬型記録媒体３０７は、可搬型記録媒体Ｉ／Ｆ３０６の制御で書き込まれたデータを記憶する。可搬型記録媒体３０７としては、例えば、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）－ＲＯＭ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリなどが挙げられる。

なお、サービス設計装置１０１は、上述した構成部のほかに、例えば、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、入力装置、ディスプレイ等を有することにしてもよい。また、サービス設計装置１０１は、上述した構成部のうち、例えば、ディスクドライブ３０３、ディスク３０４、可搬型記録媒体Ｉ／Ｆ３０６、可搬型記録媒体３０７を有していなくてもよい。

（利用者端末２０１のハードウェア構成例）
図４は、利用者端末２０１のハードウェア構成例を示すブロック図である。図４において、利用者端末２０１は、ＣＰＵ４０１と、メモリ４０２と、ディスクドライブ４０３と、ディスク４０４と、通信Ｉ／Ｆ４０５と、ディスプレイ４０６と、入力装置４０７と、可搬型記録媒体Ｉ／Ｆ４０８と、可搬型記録媒体４０９と、を有する。また、各構成部はバス４００によってそれぞれ接続される。

ここで、ＣＰＵ４０１は、利用者端末２０１の全体の制御を司る。ＣＰＵ４０１は、複数のコアを有していてもよい。メモリ４０２は、例えば、ＲＯＭ、ＲＡＭおよびフラッシュＲＯＭなどを有する記憶部である。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ４０１のワークエリアとして使用される。メモリ４０２に記憶されるプログラムは、ＣＰＵ４０１にロードされることで、コーディングされている処理をＣＰＵ４０１に実行させる。

ディスクドライブ４０３は、ＣＰＵ４０１の制御に従ってディスク４０４に対するデータのリード／ライトを制御する。ディスク４０４は、ディスクドライブ４０３の制御で書き込まれたデータを記憶する。

通信Ｉ／Ｆ４０５は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他のコンピュータ（例えば、サービス設計装置１０１）に接続される。そして、通信Ｉ／Ｆ４０５は、ネットワーク２１０と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。

ディスプレイ４０６は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する表示装置である。ディスプレイ４０６としては、例えば、液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイなどを採用することができる。

入力装置４０７は、文字、数字、各種指示などの入力のためのキーを有し、データの入力を行う。入力装置４０７は、キーボードやマウスなどであってもよく、また、タッチパネル式の入力パッドやテンキーなどであってもよい。

可搬型記録媒体Ｉ／Ｆ４０８は、ＣＰＵ４０１の制御に従って可搬型記録媒体４０９に対するデータのリード／ライトを制御する。可搬型記録媒体４０９は、可搬型記録媒体Ｉ／Ｆ４０８の制御で書き込まれたデータを記憶する。

なお、利用者端末２０１は、上述した構成部のうち、例えば、ディスクドライブ４０３、ディスク４０４、可搬型記録媒体Ｉ／Ｆ４０８、可搬型記録媒体４０９などを有さないことにしてもよい。

（ＡＰＩリポジトリ２２０の記憶内容）
つぎに、図５を用いて、サービス設計装置１０１が有するＡＰＩリポジトリ２２０の記憶内容について説明する。ＡＰＩリポジトリ２２０は、例えば、図３に示したメモリ３０２、ディスク３０４などの記憶装置により実現される。

図５は、ＡＰＩリポジトリ２２０の記憶内容の一例を示す説明図である。図５において、ＡＰＩリポジトリ２２０は、ＩＤ、名称、機能、操作対象、リクエスト仕様、レスポンス仕様、エラー率、レイテンシ、優先度および組み合わせ履歴のフィールドを有する。各フィールドに情報を設定することで、ＡＰＩ管理情報（例えば、ＡＰＩ管理情報５００－１～５００－３）がレコードとして記憶される。

ここで、ＩＤは、ＡＰＩを一意に識別する識別子である。名称は、ＡＰＩの名称である。機能は、ＡＰＩにより実現される機能である。操作対象は、ＡＰＩの操作対象である。リクエスト仕様は、ＡＰＩのリクエストの仕様であり、例えば、リクエスト項目のフォーマット（項目名、型など）を示す。

レスポンス仕様は、ＡＰＩのレスポンスの仕様であり、例えば、レスポンス項目のフォーマット（項目名、型など）を示す。エラー率は、ＡＰＩを実行した際にエラーが発生する割合を示す（単位：％）。レイテンシは、ＡＰＩを実行した際の実行時間を示す（単位：ｍｓ）。優先度は、ＡＰＩの実行優先度を示す。優先度が高いＡＰＩほど、優先して実行すべきＡＰＩであることを示す。組み合わせ履歴は、過去に組み合わせて使用された複数のＡＰＩを示す。

ＡＰＩリポジトリ２２０内のフィールドのうち、例えば、ＩＤ、名称、機能、操作対象、リクエスト仕様、レスポンス仕様および優先度は、ＡＰＩの仕様を表している。また、エラー率、レイテンシおよび組み合わせ履歴は、ＡＰＩの使用履歴を表している。

例えば、ＡＰＩ管理情報５００－１は、ＩＤ「１」のＡＰＩの名称「ＡＰＩ１」、機能「分析」、操作対象「テキスト」、リクエスト仕様「ｘｘｘ項目、ａａ型、…」、レスポンス仕様「ｙｙｙ項目、ｂｂ型、…」を示す。また、エラー率「０．２［％］」、レイテンシ「８０［ｍｓ］」、優先度「２」および組み合わせ履歴「履歴１：［ＡＰＩ１，ＡＰＩ３，ＡＰＩ４］、履歴２：［ＡＰＩ４，ＡＰＩ１，ＡＰＩ５］、履歴３：［ＡＰＩ１０，ＡＰＩ９，ＡＰＩ５，ＡＰＩ１］」を示す。例えば、履歴１：［ＡＰＩ１，ＡＰＩ３，ＡＰＩ４］は、「ＡＰＩ１→ＡＰＩ３→ＡＰＩ４」の順序で使用されたことを示す。

なお、ＡＰＩリポジトリ２２０には、ＡＰＩの目的を示す目的項目が含まれていてもよい。目的項目としては、例えば、「画像の解析」、「画像の取得」などが設定される。ただし、ＡＰＩの目的項目は、ＡＰＩの機能や操作対象などから特定されてもよい。また、ＡＰＩリポジトリ２２０には、ＡＰＩの認証方式、提供者情報、呼び出し履歴、レイテンシ履歴などが含まれていてもよい。呼び出し履歴は、エラー率の算出元となる情報（例えば、ＡＰＩの実行結果の成否、呼び出し時のリクエスト情報、レスポンス情報など）である。レイテンシ履歴は、レイテンシの算出元となる情報である。

（サービス設計装置１０１の機能的構成例）
図６は、サービス設計装置１０１の機能的構成例を示すブロック図である。図６において、サービス設計装置１０１は、受付部６０１と、特定部６０２と、決定部６０３と、出力部６０４と、実行部６０５と、を含む。具体的には、例えば、受付部６０１～実行部６０５は、図３に示したメモリ３０２、ディスク３０４、可搬型記録媒体３０７などの記憶装置に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、通信Ｉ／Ｆ３０５により、その機能を実現する。各機能部の処理結果は、例えば、メモリ３０２、ディスク３０４などの記憶装置に記憶される。

受付部６０１は、複数のＡＰＩの選択を受け付ける。選択対象となるＡＰＩは、複数のＡＰＩを組み合わせて新たなＡＰＩを作成するためのＡＰＩであり、例えば、Ｗｅｂ ＡＰＩである。ＡＰＩの選択は、例えば、図２に示した利用者端末２０１のディスプレイ４０６（図４参照）に表示される、不図示のＡＰＩ選択画面において行われる。ＡＰＩ選択画面は、例えば、選択可能なＡＰＩのリストから、ユーザが組み合わせたい複数のＡＰＩを選択する操作画面である。

より詳細に説明すると、例えば、利用者端末２０１は、ＡＰＩ選択画面において、入力装置４０７（図４参照）を用いたユーザの操作入力により、複数のＡＰＩの選択を受け付ける。そして、利用者端末２０１は、サービス設計装置１０１にＡＰＩの選択結果を送信する。この場合、受付部６０１は、利用者端末２０１からＡＰＩの選択結果を受信することにより、複数のＡＰＩの選択を受け付ける。

また、受付部６０１は、自装置の入力装置（不図示）を用いたユーザの操作入力により、複数のＡＰＩの選択を受け付けることにしてもよい。また、受付部６０１は、自装置の入力装置（不図示）を用いたユーザの操作入力により、ＡＰＩの名称の入力を受け付けることにより、複数のＡＰＩの選択を受け付けることにしてもよい。

また、受付部６０１は、複数のＡＰＩの選択を受け付けるとともに、複数のＡＰＩにより実現する機能の指定を受け付けることにしてもよい。機能の指定は、例えば、利用者端末２０１に表示されるＡＰＩ選択画面において行われる。機能の指定は、例えば、機能名の選択または入力によって行われてもよく、また、機能の内容を表す文章の選択または入力によって行われてもよい。

より詳細に説明すると、例えば、利用者端末２０１は、ＡＰＩ選択画面において、ユーザの操作入力により、複数のＡＰＩにより実現する機能の指定を受け付ける。そして、利用者端末２０１は、指定された機能を特定する情報を含む、ＡＰＩの選択結果をサービス設計装置１０１に送信する。この場合、受付部６０１は、利用者端末２０１からＡＰＩの選択結果を受信することにより、複数のＡＰＩの選択を受け付けるとともに、複数のＡＰＩにより実現する機能の指定を受け付ける。

特定部６０２は、選択された複数のＡＰＩの各々のＡＰＩの仕様および使用履歴の少なくともいずれかの情報に基づいて、複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定する。ＡＰＩの仕様は、例えば、ＡＰＩの名称、機能、目的、リクエストやレスポンスのフォーマット、実行優先度などを表す情報である。

また、ＡＰＩの使用履歴は、例えば、ＡＰＩの組み合わせ履歴、エラー率、レイテンシなどを表す情報である。ＡＰＩの組み合わせ履歴は、過去に組み合わせて使用された複数のＡＰＩと、複数のＡＰＩの実行順序とを示す。エラー率は、ＡＰＩを実行した際にエラーが発生する割合を示す。レイテンシは、ＡＰＩを実行した際の実行時間を示す。

ＡＰＩの仕様および使用履歴は、例えば、図５に示したＡＰＩリポジトリ２２０から特定される。具体的には、例えば、特定部６０２は、ＡＰＩリポジトリ２２０を参照して、選択された複数のＡＰＩのうち、第１のＡＰＩのレスポンス項目のフォーマットと、第２のＡＰＩのリクエスト項目のフォーマットとが一致するか否かを判断する。ここで、第１のＡＰＩのレスポンス項目のフォーマットと、第２のＡＰＩのリクエスト項目のフォーマットとが一致する場合、特定部６０２は、第１のＡＰＩから第２のＡＰＩへの呼び出しの順序関係を特定する。

また、特定部６０２は、ＡＰＩリポジトリ２２０を参照して、第１のＡＰＩの目的項目と第２のＡＰＩの目的項目とを比較する。そして、特定部６０２は、比較した結果から第１のＡＰＩと第２のＡＰＩとに依存関係が存在すると判断した場合に、第１のＡＰＩと第２のＡＰＩとの呼び出しの順序関係を特定する。一例として、第１のＡＰＩの目的項目を「画像またはテキストの解析」とし、第２のＡＰＩの目的項目を「画像またはテキストの取得」とする。この場合、第２のＡＰＩで取得した画像またはテキストを、第１のＡＰＩで解析するという依存関係が存在するため、特定部６０２は、第２のＡＰＩから第１のＡＰＩへの呼び出しの順序関係を特定する。

また、特定部６０２は、ＡＰＩリポジトリ２２０を参照して、第１のＡＰＩと第２のＡＰＩとの組み合わせ履歴を特定する。そして、特定部６０２は、特定した第１のＡＰＩと第２のＡＰＩとの組み合わせ履歴に基づいて、第１のＡＰＩと第２のＡＰＩとの呼び出しの順序関係を特定する。一例として、第１のＡＰＩと第２のＡＰＩとが組み合わせて使用された履歴があり、第１のＡＰＩの直後に第２のＡＰＩが実行された回数を「１００」とし、第２のＡＰＩの直後に第１のＡＰＩが実行された回数を「５０」とする。この場合、特定部６０２は、使用頻度が高い第１のＡＰＩから第２のＡＰＩへの呼び出しの順序関係を特定する。

また、ＡＰＩ間の呼び出しの順序関係は、ＡＰＩの提供者またはユーザによって指定されてもよい。この場合、特定部６０２は、ＡＰＩの提供者またはユーザによって指定されたＡＰＩ間の呼び出しの順序関係を特定する。

また、各々のＡＰＩには、仕様として、あらかじめ実行優先度が設定されていてもよい。実行優先度は、優先度が高いＡＰＩほど、優先して実行すべきＡＰＩであることを示す。実行優先度は、例えば、ＡＰＩリポジトリ２２０内の全てのＡＰＩにおいて、統一的な価値基準をもとに設定される。この場合、特定部６０２は、選択された複数のＡＰＩのうち、第１のＡＰＩの実行優先度が、第２のＡＰＩの実行優先度よりも高い場合、第１のＡＰＩから第２のＡＰＩへの呼び出しの順序関係を特定することにしてもよい。

決定部６０３は、特定されたＡＰＩ間の呼び出しの順序関係に基づいて、選択された複数のＡＰＩの実行順序を決定する。具体的には、例えば、決定部６０３は、呼び出しの順序関係が特定されたＡＰＩ同士を、その関係に従って実行する順序に決定する。また、決定部６０３は、呼び出しの順序関係が特定されなかったＡＰＩ同士を、並列に実行する順序に決定する。

また、決定部６０３は、さらに、最大多重度に基づいて、複数のＡＰＩの実行順序を決定することにしてもよい。ここで、最大多重度は、並列実行可能なＡＰＩの上限数である。最大多重度は、例えば、あらかじめ設定されてメモリ３０２、ディスク３０４などの記憶装置に記憶されている。

具体的には、例えば、決定部６０３は、呼び出しの順序関係が特定されなかったＡＰＩ同士を、最大多重度を超えないように並列に実行する順序を決定する。なお、最大多重度は、例えば、ＡＰＩのプロトコルや、設計対象のサービス（複数のＡＰＩを組み合わせて作成される新たなＡＰＩ）を実行するコンピュータ（例えば、サービス設計装置１０１）のハードウェアリソースに応じて設定される。

また、決定部６０３は、さらに、各々のＡＰＩを実行した際のエラー率に基づいて、複数のＡＰＩの実行順序を決定することにしてもよい。具体的には、例えば、複数のＡＰＩのうち、エラー率の高いＡＰＩほど順序を先に決定してもよい。これにより、早い段階でエラーが発生しやすくなって、エラー発生時の無駄な時間やコストを抑えることができる。

より詳細に説明すると、例えば、決定部６０３は、特定されたＡＰＩ間の呼び出しの順序関係に基づいて、複数のＡＰＩを複数のグループに分類する。この際、決定部６０３は、呼び出しの順序関係が特定されたＡＰＩ同士を異なるグループに分類しつつ、呼び出しの順序関係が特定されなかったＡＰＩ同士を同一グループに分類する。また、決定部６０３は、ＡＰＩ間の呼び出しの順序関係に従って、グループ間の順序関係を設定する。

以下の説明では、複数のＡＰＩを分類した複数のグループを「グループＧ１～Ｇｎ」と表記する場合がある（ｎ：２以上の自然数）。また、グループＧ１～Ｇｎのうちの任意のグループを「グループＧｉ」と表記する場合がある（ｉ＝１，２，…，ｎ）。

つぎに、決定部６０３は、分類したグループＧ１～ＧｎのいずれかのグループＧｉ内のＡＰＩ数が最大多重度を超える場合、グループＧｉ内の各々のＡＰＩのエラー率に基づいて、グループＧｉ内のＡＰＩを複数のサブグループに分類する。ただし、決定部６０３は、各サブグループ内のＡＰＩ数が最大多重度を超えないように分類する。

また、決定部６０３は、分類したグループＧ１～ＧｎのいずれかのグループＧｉ内のＡＰＩ数が最大多重度を超える場合、グループＧｉ内の各々のＡＰＩのエラー率およびレイテンシに基づいて、グループＧｉ内のＡＰＩを複数のサブグループに分類してもよい。この際、決定部６０３は、サブグループ間の順序関係を設定する。

以下の説明では、グループＧｉ内の複数のサブグループを「サブグループｓ１～ｓｍ」と表記する場合がある（ｍ：２以上の自然数）。また、サブグループｓ１～ｓｍのうちの任意のサブグループを「サブグループｓｊ」と表記する場合がある（ｊ＝１，２，…，ｍ）。

そして、決定部６０３は、グループＧ１～ＧｎとグループＧｉ内のサブグループｓ１～ｓｍとに基づいて、複数のＡＰＩの実行順序を決定する。例えば、決定部６０３は、同一グループ内のＡＰＩを並列に実行しつつ、グループ間の順序関係に従って異なるグループ内のＡＰＩを直列に実行する順序を決定する。また、決定部６０３は、同一サブグループ内のＡＰＩを並列に実行しつつ、サブグループ間の順序関係に従って異なるサブグループ内のＡＰＩを直列に実行する順序を決定する。

なお、複数のＡＰＩの実行順序の決定例については、図７～図１０を用いて後述する。

出力部６０４は、決定された複数のＡＰＩの実行順序を出力する。出力部６０４の出力形式としては、例えば、メモリ３０２、ディスク３０４などの記憶装置への記憶、通信Ｉ／Ｆ３０５による他のコンピュータ（例えば、利用者端末２０１）への送信、不図示のディスプレイへの表示、不図示のプリンタへの印刷出力などがある。

なお、複数のＡＰＩの実行順序の出力例については、図１１を用いて後述する。

実行部６０５は、決定された複数のＡＰＩの実行順序に従って、複数のＡＰＩを実行する。すなわち、実行部６０５は、決定された複数のＡＰＩの実行順序に基づいて、複数のＡＰＩを組み合わせて作成される新たなＡＰＩを実行する。

具体的には、例えば、実行部６０５は、同一グループ内のＡＰＩを並列に実行しつつ、グループ間の順序関係に従って異なるグループ内のＡＰＩを直列に実行する。また、グループＧｉ内にサブグループｓ１～ｓｍが存在する場合、実行部６０５は、同一サブグループ内のＡＰＩを並列に実行しつつ、サブグループ間の順序関係に従って異なるサブグループ内のＡＰＩを直列に実行する。

なお、各ＡＰＩの実行時に用いられる各種パラメータの値は、例えば、ユーザの操作入力により指定される。各ＡＰＩの実行処理では、例えば、ＡＰＩリクエストが作成され、作成されたＡＰＩリクエストが、各ＡＰＩを提供するウェブサーバに送信される。ＡＰＩリクエストは、ＡＰＩの実行を依頼するものであり、例えば、各種パラメータの値を含む。この結果、ウェブサーバにおいて、各種パラメータの値に基づきＡＰＩが実行され、ＡＰＩレスポンスがサービス設計装置１０１に送信される。

また、出力部６０４は、実行された複数のＡＰＩの実行結果を出力することにしてもよい。ここで、複数のＡＰＩの実行結果は、複数のＡＰＩを組み合わせて作成される新たなＡＰＩの実行結果であり、例えば、新たなＡＰＩにより要求された情報や、新たなＡＰＩの実行結果の成否などである。

また、出力部６０４は、選択された複数のＡＰＩにより実現される機能と対応付けて、決定された複数のＡＰＩの実行順序を出力することにしてもよい。これにより、機能と対応付けて、その機能を実現する複数のＡＰＩと、複数のＡＰＩの実行順序を記録することができる。

例えば、サービス設計装置１０１は、機能の指定を受け付けたことに応じて、指定された機能に対応する複数のＡＰＩの実行順序を特定する情報を出力することができる。これにより、ユーザは、ある機能を実現するにあたり、どのＡＰＩを組み合わせて、どのような順番で実行すればよいのかを判断することができる。

また、出力部６０４は、選択された複数のＡＰＩにより実現される機能と対応付けて、決定された複数のＡＰＩの実行順序と、当該実行順序に従って複数のＡＰＩを実行した場合の実行時間および実行結果の成否を出力することにしてもよい。実行時間は、複数のＡＰＩ（複数のＡＰＩを組み合わせて作成される新たなＡＰＩ）の実行を開始してから、複数のＡＰＩの実行が終了するまでに要する時間である。

実行結果の成否は、複数のＡＰＩの実行が成功したか否かを示す。具体的には、例えば、出力部６０４は、複数のＡＰＩにより実現される機能と対応付けて、複数のＡＰＩの実行順序、実行時間および実行結果の成否を、後述の図１２に示すような実行履歴テーブル１２００に記録する。

これにより、機能と対応付けて、その機能を実現する複数のＡＰＩと、複数のＡＰＩの実行順序と、その実行順序で複数のＡＰＩを実行した場合の実行時間および実行結果の成否を記録することができる。なお、複数のＡＰＩにより実現される機能は、例えば、キーワードによって表現されてもよく、また、文章によって表現されてもよい。

例えば、サービス設計装置１０１は、機能の指定を受け付けたことに応じて、指定された機能に対応する複数のＡＰＩの実行順序と、当該実行順序に従って複数のＡＰＩを実行した場合の実行時間および実行結果の成否を特定する情報を出力することができる。これにより、ユーザは、ある機能を実現するにあたり、どのＡＰＩを組み合わせて、どのような順番で実行すればよいのかを判断することができる。

なお、上述したサービス設計装置１０１の機能部のうち、実行部６０５は、サービス設計装置１０１とは異なる他のコンピュータにより実現されることにしてもよい。この場合、他のコンピュータにおいて、サービス設計装置１０１で決定された複数のＡＰＩの実行順序に従って、複数のＡＰＩを実行する。また、上述したサービス設計装置１０１の各機能部は、利用者端末２０１により実現されることにしてもよい。

（複数のＡＰＩの実行順序の決定例）
つぎに、図７～図１０を用いて、複数のＡＰＩの実行順序の決定例について説明する。まず、図７および図８を用いて、複数のＡＰＩの実行順序の第１の決定例について説明する。

図７および図８は、複数のＡＰＩの実行順序の第１の決定例を示す説明図である。図７において、まず、受付部６０１は、複数のＡＰＩの選択を受け付ける。ここでは、複数のＡＰＩとして、ＡＰＩ１，ＡＰＩ２，ＡＰＩ３，ＡＰＩ４，ＡＰＩ１０，ＡＰＩ１１，ＡＰＩ１２，ＡＰＩ１００，ＡＰＩ１０１が選択されている。

つぎに、特定部６０２は、ＡＰＩリポジトリ２２０を参照して、各々のＡＰＩの仕様および使用履歴に基づいて、複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定する。ここでは、ＡＰＩ１，ＡＰＩ１０間の呼び出しの順序関係として、「ＡＰＩ１→ＡＰＩ１０」が特定されている。ＡＰＩ２，ＡＰＩ１０間の呼び出しの順序関係として、「ＡＰＩ２→ＡＰＩ１０」が特定されている。

また、ＡＰＩ３，ＡＰＩ１１間の呼び出しの順序関係として、「ＡＰＩ３→ＡＰＩ１１」が特定されている。ＡＰＩ４，ＡＰＩ１２間の呼び出しの順序関係として、「ＡＰＩ４→ＡＰＩ１２」が特定されている。ＡＰＩ１０，ＡＰＩ１００間の呼び出しの順序関係として、「ＡＰＩ１０→ＡＰＩ１００」が特定されている。ＡＰＩ１１，ＡＰＩ１０１間の呼び出しの順序関係として、「ＡＰＩ１１→ＡＰＩ１０１」が特定されている。

図８において、決定部６０３は、特定されたＡＰＩ間の呼び出しの順序関係に基づいて、複数のＡＰＩをグループＧ１～Ｇｎに分類する。具体的には、例えば、決定部６０３は、呼び出しの順序関係が特定されたＡＰＩ同士を異なるグループに分類しつつ、呼び出しの順序関係が特定されなかったＡＰＩ同士を同一グループに分類する。

この際、決定部６０３は、例えば、グループ内のＡＰＩ数ができるだけ多くなるように、複数のＡＰＩを複数のグループに分類してもよい。また、決定部６０３は、グループ数ができるだけ少なくなるように、複数のＡＰＩを複数のグループに分類してもよい。

例えば、ＡＰＩ１とＡＰＩ１０は、呼び出しの順序関係があるため、異なるグループに分類される。また、ＡＰＩ１０とＡＰＩ１００は、呼び出しの順序関係があるため、異なるグループに分類される。また、ＡＰＩ１とＡＰＩ２は、呼び出しの順序関係がないため、同一グループに分類される。

ここでは、ＡＰＩ１とＡＰＩ２とＡＰＩ３とＡＰＩ４がグループＧ１に分類され、ＡＰＩ１０とＡＰＩ１１とＡＰＩ１２がグループＧ２に分類され、ＡＰＩ１００とＡＰＩ１０１がグループＧ３に分類されている。また、グループＧ１～Ｇ３には、「グループＧ１→グループＧ２→グループＧ３」という順序関係が設定されている。

なお、各グループＧ１～Ｇ３内のＡＰＩ数は最大多重度を超えていないものとする。

そして、決定部６０３は、グループＧ１～Ｇ３のグループ間の順序関係に従って、同一グループ内のＡＰＩを並列に実行しつつ、異なるグループ内のＡＰＩを直列に実行する順序を決定する。ここでは、グループＧ１内のＡＰＩ１，ＡＰＩ２，ＡＰＩ３，ＡＰＩ４を並列に実行した後、グループＧ２内のＡＰＩ１０，ＡＰＩ１１，ＡＰＩ１２を並列に実行し、その後、グループＧ３内のＡＰＩ１００，ＡＰＩ１０１を並列に実行する実行順序が決定される。

これにより、ユーザが選択した複数のＡＰＩ（ＡＰＩ１～ＡＰＩ４，ＡＰＩ１０～ＡＰＩ１２，ＡＰＩ１００，ＡＰＩ１０１）について、ＡＰＩ間の呼び出しの順序関係や並列性を考慮したＡＰＩの実行順序を導出することができる。

つぎに、図９および図１０を用いて、複数のＡＰＩの実行順序の第２の決定例について説明する。ここでは、複数のＡＰＩを分類したグループＧ１～ＧｎのうちのグループＧｉ内のＡＰＩ数が最大多重度を超えていた場合について説明する。

図９および図１０は、複数のＡＰＩの実行順序の第２の決定例を示す説明図である。図９において、ＡＰＩ１～ＡＰＩ８を含むグループＧ１が示されている。ここで、最大多重度を「３」とすると、グループＧ１内のＡＰＩ数「８」が最大多重度を超える。

この場合、決定部６０３は、グループＧ１内のＡＰＩを、各サブグループ内のＡＰＩ数が最大多重度を超えないように、サブグループｓ１～ｓｍに分類する。より詳細に説明すると、例えば、決定部６０３は、各サブグループ内のＡＰＩ数が、最大多重度を超えず、かつ、できるだけ多くなるように、グループＧ１内のＡＰＩをサブグループｓ１～ｓｍに分類する。

ここでは、ＡＰＩ１とＡＰＩ２とＡＰＩ３がサブグループｓ１に分類され、ＡＰＩ４とＡＰＩ５とＡＰＩ６がサブグループｓ２に分類され、ＡＰＩ７とＡＰＩ８がサブグループｓ３に分類されている。また、サブグループｓ１～ｓ３には、「サブグループｓ１→サブグループｓ２→サブグループｓ３」という順序関係が設定されている。

図１０において、決定部６０３は、グループＧ１内の各々のＡＰＩのエラー率に基づいて、各サブグループｓ１～ｓ３に属するＡＰＩを更新する。具体的には、例えば、決定部６０３は、グループＧ１内のＡＰＩ１～ＡＰＩ８のうち、エラー率が高いＡＰＩほど順序が先となるように、各サブグループｓ１～ｓ３に属するＡＰＩを更新する。

ここでは、エラー率が高いＡＰＩ２とＡＰＩ６とＡＰＩ８がサブグループｓ１に分類されている。また、エラー率がＡＰＩ２，ＡＰＩ６，ＡＰＩ８よりも低い、ＡＰＩ１とＡＰＩ３とＡＰＩ４がサブグループｓ２に分類されている。また、エラー率がＡＰＩ２，ＡＰＩ６，ＡＰＩ８よりも低い、ＡＰＩ５とＡＰＩ７がサブグループｓ３に分類されている。

なお、サブグループｓ１（先頭のサブグループ）には、エラー率があらかじめ設定された閾値以上となるＡＰＩのみ属するようにしてもよい。

つぎに、決定部６０３は、サブグループｓ１以外のサブグループｓ２，ｓ３内の各々のＡＰＩのレイテンシに基づいて、各サブグループｓ２，ｓ３に属するＡＰＩを更新する。具体的には、例えば、決定部６０３は、サブグループｓ２のレイテンシとサブグループｓ３のレイテンシとを足した合計レイテンシが最短となるように、各サブグループｓ２，ｓ３に属するＡＰＩを更新する。この際、決定部６０３は、サブグループｓ３よりもサブグループｓ２のレイテンシが長くなるように、各サブグループｓ２，ｓ３に属するＡＰＩを更新してもよい。

各サブグループｓ２，ｓ３のレイテンシは、各サブグループｓ２，ｓ３に属する各々のＡＰＩのレイテンシのうちの最長のレイテンシによって決まる。例えば、サブグループｓ２に属するＡＰＩ１，ＡＰＩ３，ＡＰＩ４のうちＡＰＩ１のレイテンシが最も長い場合、サブグループｓ２のレイテンシは、ＡＰＩ１のレイテンシによって決まる。

ここでは、サブグループｓ２とサブグループｓ３の合計レイテンシが最短となるように、ＡＰＩ３とＡＰＩ５とＡＰＩ７がサブグループｓ２に分類され、ＡＰＩ１とＡＰＩ４がサブグループｓ３に分類されている。また、サブグループｓ２のレイテンシ（遅）は、サブグループｓ３のレイテンシ（速）よりも長くなっている。

そして、決定部６０３は、グループＧ１について、サブグループｓ１～ｓ３のサブグループ間の順序関係に従って、同一サブグループ内のＡＰＩを並列に実行しつつ、異なるサブグループ内のＡＰＩを直列に実行する順序を決定する。ここでは、グループＧ１について、サブグループｓ１内のＡＰＩ２，ＡＰＩ６，ＡＰＩ８を並列に実行した後、サブグループｓ２内のＡＰＩ３，ＡＰＩ５，ＡＰＩ７を並列に実行し、その後、サブグループｓ３内のＡＰＩ１，ＡＰＩ４を並列に実行する実行順序が決定される。

これにより、グループＧ１内のＡＰＩ数が最大多重度を超えている場合に、グループＧ１内の各々のＡＰＩのエラー率およびレイテンシを考慮して、新たなＡＰＩを効率的に実行可能な実行順序を決定することができる。

例えば、グループＧ１内でエラー率が高いＡＰＩほど順序を先にすることで、エラー発生時の無駄な時間やコストを抑えることができる。また、サブグループｓ２とサブグループｓ３の合計レイテンシが最短となるように、各サブグループｓ１，ｓ２に属するＡＰＩを調整することで、実行時間の短縮化を図ることができる。また、サブグループｓ３よりもサブグループｓ２のレイテンシが遅くなるように調整することで、エラー発生時の無駄な時間やコストを抑えることができる。

（複数のＡＰＩの実行順序の出力例）
つぎに、図１１を用いて、複数のＡＰＩの実行順序の出力例について説明する。ここでは、利用者端末２０１のディスプレイ４０６に表示される設計支援画面を例に挙げて、複数のＡＰＩの実行順序の出力例について説明する。

図１１は、複数のＡＰＩの実行順序の出力例を示す説明図である。図１１において、設計支援画面１１００は、ユーザによって選択された複数のＡＰＩ（ＡＰＩ１～ＡＰＩ８，ＡＰＩ１１～ＡＰＩ１７，ＡＰＩ１０１～ＡＰＩ１０６）の実行順序を示す操作画面の一例である。各ＡＰＩは、各ＡＰＩを模したブロック（例えば、ブロック１１０１）によって表現されている。

設計支援画面１１００には、ユーザによって選択された複数のＡＰＩを分類したグループＧ１～Ｇ３が表示されている。また、グループＧ１内のＡＰＩ１～ＡＰＩ８を分類したサブグループｓ１～ｓ３が表示されている。また、グループＧ２内のＡＰＩ１１～ＡＰＩ１７を分類したサブグループｓ４～ｓ６が表示されている。また、グループＧ３内のＡＰＩ１０１～ＡＰＩ１０６を分類したサブグループｓ７，ｓ８が表示されている。

設計支援画面１１００によれば、ユーザは、複数のＡＰＩ（ＡＰＩ１～ＡＰＩ８，ＡＰＩ１１～ＡＰＩ１７，ＡＰＩ１０１～ＡＰＩ１０６）をどのような順序で実行すれば、時間やコストを抑えて効率的に実行できるのかを判断することができる。なお、図１１の例では、図示を省略したが、ＡＰＩ間の呼び出しの順序関係を表示することにしてもよい。

例えば、設計支援画面１１００において、図４に示した入力装置４０７を用いたユーザの操作入力により、ボタンＢ１を選択すると、ＡＰＩ間の呼び出しの順序関係を示す記号（例えば、矢印）が表示される。これにより、ユーザは、どのＡＰＩとどのＡＰＩとが呼び出しの順序関係があるのかを把握することができる。

また、ユーザは、各グループ内のサブグループ間でのエラー率やレイテンシの大小関係が表示されるため、エラー率やレイテンシを考慮して順序が決められていることを把握することができる。ただし、エラー率やレイテンシの大小関係を表す表示は行わないことにしてもよい。また、各グループ内のサブグループを表す表示についても行わないことにしてもよい。

また、設計支援画面１１００において、ユーザの操作入力により、ＡＰＩの実行順序を変更可能であってもよい。例えば、ドラッグアンドドロップ等により、ＡＰＩ７を表すブロック１１０１をサブグループｓ２からサブグループｓ３に移動させることで、ＡＰＩ７の実行順序を変更することができる。

（実行履歴テーブル１２００の記憶内容）
つぎに、図１２を用いて、サービス設計装置１０１が有する実行履歴テーブル１２００の記憶内容について説明する。実行履歴テーブル１２００は、例えば、メモリ３０２、ディスク３０４などの記憶装置により実現される。

図１２は、実行履歴テーブル１２００の記憶内容の一例を示す説明図である。図１２において、実行履歴テーブル１２００は、機能、ＡＰＩの組み合わせ、実行時間および実行結果の成否のフィールドを有し、各フィールドに情報を設定することで、実行履歴情報１２００－１～１２００－７をレコードとして記憶する。

ここで、機能は、複数のＡＰＩにより実現される機能を示す。機能は、例えば、キーワードや文章によって表現される。ＡＰＩの組み合わせは、機能を実現するためのＡＰＩの組み合わせおよび実行順序を示す。図１２中、大文字のアルファベット（Ａ，Ｂなど）は、ＡＰＩを示す。実行時間は、複数のＡＰＩの実行を開始してから、複数のＡＰＩの実行が終了するまでに要する時間である（単位：秒）。なお、複数のＡＰＩが複数回実行された場合は、実行時間の統計値（例えば、平均実行時間）が設定される。

実行結果の成否は、複数のＡＰＩの実行が成功したか否かを示す。実行結果の成否「ＯＫ」は、実行に成功したことを示す。実行結果の成否「ＮＧ」は、実行に失敗したことを示す。なお、複数のＡＰＩが複数回実行された場合は、実行結果の成否の統計値（例えば、ＯＫまたはＮＧの多いほう）が設定される。

例えば、実行履歴情報１２００－１は、機能αを実現するためのＡＰＩの組み合わせの実行順序「Ｐ→Ｑ」、実行時間「２［秒］」および実行結果「ＮＧ」を示す。

例えば、サービス設計装置１０１は、機能の指定を受け付けたことに応じて、実行履歴テーブル１２００を参照して、指定された機能を実現する複数のＡＰＩの推奨結果情報を出力する。

ここで、図１３を用いて、推奨結果情報の具体例について説明する。ここでは、サービス設計装置１０１が、利用者端末２０１から機能の指定を受け付けた場合を想定する。この場合、サービス設計装置１０１から出力された推奨結果情報は、例えば、利用者端末２０１のディスプレイ４０６に表示される。

図１３は、推奨結果情報の具体例を示す説明図である。図１３において、推奨結果情報１３００は、機能βを実現する複数のＡＰＩの推奨結果１３０１を示す。推奨結果１３０１では、機能βを実現する複数種類のＡＰＩの組み合わせのうち、実行時間が短く、実行結果の成否が「ＯＫ」のものが上位に表示されている。

推奨結果情報１３００によれば、機能βを実現するにあたり、どのＡＰＩを組み合わせて、どのような順番で実行すればよいのかを推薦することができる。例えば、ユーザは、機能βを実現するにあたり、複数のＡＰＩ「Ａ，Ｂ，Ｃ」を「Ａ→Ｂ→Ｃ」の順序で実行すれば、最も短い時間で実行に成功する可能性が高いと判断することができる。

これにより、ＡＰＩを使い慣れていないビジネスユーザであっても、ある機能を実現するために、どのようなＡＰＩを組み合わせて、どのような順序で実行すればよいのかを容易に判断することが可能となる。

（サービス設計装置１０１のサービス設計処理手順）
つぎに、図１４および図１５を用いて、サービス設計装置１０１のサービス設計処理手順について説明する。

図１４および図１５は、サービス設計装置１０１のサービス設計処理手順の一例を示すフローチャートである。図１４のフローチャートにおいて、まず、サービス設計装置１０１は、複数のＡＰＩの選択を受け付けたか否かを判断する（ステップＳ１４０１）。

ここで、サービス設計装置１０１は複数のＡＰＩの選択を受け付けるのを待つ（ステップＳ１４０１：Ｎｏ）。そして、サービス設計装置１０１は、複数のＡＰＩの選択を受け付けた場合（ステップＳ１４０１：Ｙｅｓ）、選択された複数のＡＰＩについて、ＡＰＩの全ペア（順列）を作成する（ステップＳ１４０２）。

なお、各ペアは、順序関係を有する２つのＡＰＩである。例えば、「ＡＰＩ１→ＡＰＩ２」と「ＡＰＩ２→ＡＰＩ１」は異なるペアとして作成される。

つぎに、サービス設計装置１０１は、作成した全ペアのうち選択されていない未選択のペアを選択する（ステップＳ１４０３）。そして、サービス設計装置１０１は、選択したペアについて、ユーザによって指定された呼び出しの順序関係があるか否かを判断する（ステップＳ１４０４）。

ここで、呼び出しの順序関係がある場合（ステップＳ１４０４：Ｙｅｓ）、サービス設計装置１０１は、ステップＳ１４０７に移行する。一方、呼び出しの順序関係がない場合（ステップＳ１４０４：Ｎｏ）、サービス設計装置１０１は、ＡＰＩリポジトリ２２０を参照して、選択したペアについて、ＡＰＩの関係性分析を行う（ステップＳ１４０５）。

なお、ＡＰＩの関係性分析とは、ＡＰＩの仕様および使用履歴の少なくともいずれかの情報に基づいて、ＡＰＩ間の呼び出しの順序関係を特定する処理である。例えば、サービス設計装置１０１は、選択したペア（第１のＡＰＩ→第２のＡＰＩ）について、第１のＡＰＩのレスポンス項目のフォーマットと、第２のＡＰＩのリクエスト項目のフォーマットとが一致する場合、呼び出しの順序関係があると判断する。

つぎに、サービス設計装置１０１は、選択したペアについて、ユーザによって指定された呼び出しの順序関係が特定されたか否かを判断する（ステップＳ１４０６）。ここで、呼び出しの順序関係が特定されなかった場合（ステップＳ１４０６：Ｎｏ）、サービス設計装置１０１は、ステップＳ１４０８に移行する。

一方、呼び出しの順序関係が特定された場合（ステップＳ１４０６：Ｙｅｓ）、サービス設計装置１０１は、選択したペアを関係あり集合に登録する（ステップＳ１４０７）。そして、サービス設計装置１０１は、作成した全ペアのうち選択されていない未選択のペアがあるか否かを判断する（ステップＳ１４０８）。

ここで、未選択のペアがある場合（ステップＳ１４０８：Ｙｅｓ）、サービス設計装置１０１は、ステップＳ１４０３に戻る。一方、未選択のペアがない場合には（ステップＳ１４０８：Ｎｏ）、サービス設計装置１０１は、図１５に示すステップＳ１５０１に移行する。

図１５のフローチャートにおいて、まず、サービス設計装置１０１は、関係あり集合に登録されたペアに基づいて、選択された複数のＡＰＩをグループＧ１～Ｇｎに分類する（ステップＳ１５０１）。例えば、サービス設計装置１０１は、呼び出しの順序関係があるＡＰＩ同士を異なるグループに分類しつつ、呼び出しの順序関係がないＡＰＩ同士を同一グループに分類する。

つぎに、サービス設計装置１０１は、グループＧｉの「ｉ」を「ｉ＝１」として（ステップＳ１５０２）、グループＧｉを選択する（ステップＳ１５０３）。そして、サービス設計装置１０１は、選択したグループＧｉ内のＡＰＩ数が最大多重度を超えるか否かを判断する（ステップＳ１５０４）。

ここで、最大多重度を超えない場合（ステップＳ１５０４：Ｎｏ）、サービス設計装置１０１は、ステップＳ１５０８に移行する。一方、最大多重度を超える場合（ステップＳ１５０４：Ｙｅｓ）、サービス設計装置１０１は、グループＧｉ内のＡＰＩ数と最大多重度とに基づいて、サブグループの個数を決定する（ステップＳ１５０５）。

なお、サブグループの個数は、例えば、グループＧｉ内のＡＰＩ数を最大多重度で割った値（ただし、小数点切り上げ）とする。一例として、グループＧｉ内のＡＰＩ数を「１０」とし、最大多重度を「３」とすると、サブグループの個数は「４」となる。

つぎに、サービス設計装置１０１は、ＡＰＩリポジトリ２２０を参照して、グループＧｉ内のＡＰＩのうち、エラー率の高いＡＰＩを、決定した個数分のサブグループの先頭のサブグループに入れる（ステップＳ１５０６）。この際、サービス設計装置１０１は、エラー率が閾値以上のＡＰＩを先頭のサブグループに入れることにしてもよい。

そして、サービス設計装置１０１は、ＡＰＩリポジトリ２２０を参照して、グループＧｉ内の残余のＡＰＩについて、レイテンシの遅いＡＰＩから順々に次のサブグループに入れる（ステップＳ１５０７）。この結果、グループＧｉ内のＡＰＩが、サブグループｓ１～ｓｍに分類される。

つぎに、サービス設計装置１０１は、グループＧｉの「ｉ」をインクリメントして（ステップＳ１５０８）、「ｉ」が「ｎ」よりも大きくなったか否かを判断する（ステップＳ１５０９）。ここで、「ｉ」が「ｎ」以下の場合（ステップＳ１５０９：Ｎｏ）、サービス設計装置１０１は、ステップＳ１５０３に戻る。

一方、「ｉ」が「ｎ」より大きくなった場合（ステップＳ１５０９：Ｙｅｓ）、サービス設計装置１０１は、グループＧ１～ＧｎとグループＧｉ内のサブグループｓ１～ｓｍとに基づいて、複数のＡＰＩの実行順序を決定する（ステップＳ１５１０）。そして、サービス設計装置１０１は、決定した複数のＡＰＩの実行順序結果を出力して（ステップＳ１５１１）、本フローチャートによる一連の処理を終了する。

これにより、複数のＡＰＩを組み合わせて新たなサービス（新たなＡＰＩ）を設計するにあたり、複数のＡＰＩをどのような順序で実行すれば、時間やコストを抑えて効率的に実行できるのかを判断可能な情報をユーザに提供することができる。

なお、選択された複数のＡＰＩのうち、いずれのＡＰＩとも呼び出しの順序関係がないＡＰＩが存在する場合がある。この場合、サービス設計装置１０１は、例えば、ステップＳ１５０１の処理に先立って、いずれのＡＰＩとも呼び出しの順序関係がないＡＰＩについて、他のＡＰＩとの呼び出しの順序関係を、ユーザに問い合わせることにしてもよい。

また、サービス設計装置１０１は、いずれのＡＰＩとも呼び出しの順序関係がないＡＰＩについて、グループＧ１～Ｇｎよりも前（つまり、先頭）、あるいは、グループＧ１～Ｇｎよりも後（つまり、末尾）に実行する順序に決定してもよい。また、いずれのＡＰＩとも呼び出しの順序関係がないＡＰＩが複数存在する場合は、サービス設計装置１０１は、あらかじめ設定された実行優先度に基づいて、それらＡＰＩの実行順序を決定することにしてもよい。

また、ステップＳ１４０４において、サービス設計装置１０１は、選択したペアについて、ＡＰＩの提供者によって指定された呼び出しの順序関係があるか否かを判断することにしてもよい。

以上説明したように、実施の形態にかかるサービス設計装置１０１によれば、複数のＡＰＩの選択を受け付け、選択された複数のＡＰＩの各々のＡＰＩの仕様および使用履歴の少なくともいずれかの情報に基づいて、複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定することができる。ＡＰＩは、例えば、Ｗｅｂ ＡＰＩである。そして、サービス設計装置１０１によれば、特定したＡＰＩ間の呼び出しの順序関係に基づいて、複数のＡＰＩの実行順序を決定し、決定した複数のＡＰＩの実行順序を出力することができる。

これにより、複数のＡＰＩを組み合わせて新たなＡＰＩを作成するにあたり、ＡＰＩ間の呼び出しの順序関係や並列性を考慮したＡＰＩの実行順序を導出することができる。そのため、複数のＡＰＩの適切な実行順序を容易に特定でき、サービスの設計作業にかかる作業時間や作業負荷を削減して、生産性の向上につなげることができる。

また、サービス設計装置１０１によれば、さらに、並列実行可能なＡＰＩの上限数である最大多重度に基づいて、複数のＡＰＩの実行順序を決定することができる。

これにより、ＡＰＩのプロトコルやハードウェアリソースによって並列度に制限がある場合に、呼び出しの順序関係がないＡＰＩ同士を、並列実行可能なＡＰＩの上限数を超えないように並列に実行する順序を決定することができる。

また、サービス設計装置１０１によれば、さらに、各々のＡＰＩのエラー率に基づいて、複数のＡＰＩの実行順序を決定することができる。

これにより、例えば、エラー率の高いＡＰＩほど順序を先にして、エラー発生時の無駄な時間やコストを抑えることが可能な実行順序を導出することができる。

また、サービス設計装置１０１によれば、複数のＡＰＩにより実現される機能と対応付けて、決定した複数のＡＰＩの実行順序を出力することができる。また、サービス設計装置１０１によれば、機能の指定を受け付けたことに応じて、指定された機能に対応する複数のＡＰＩの実行順序を特定する情報を出力することができる。

これにより、機能と対応付けて、その機能を実現する複数のＡＰＩと、複数のＡＰＩの実行順序を記録することができる。また、ユーザからの機能の指定に応じて、その機能を実現するにあたり、どのＡＰＩを組み合わせて、どのような順番で実行すればよいのかを判断可能な情報を提供することができる。

また、サービス設計装置１０１によれば、複数のＡＰＩにより実現される機能と対応付けて、決定した複数のＡＰＩの実行順序と、当該実行順序に従って複数のＡＰＩを実行した場合の実行時間および実行結果の成否を出力することができる。また、サービス設計装置１０１によれば、機能の指定を受け付けたことに応じて、指定された機能に対応する複数のＡＰＩの実行順序と、当該実行順序に従って複数のＡＰＩを実行した場合の実行時間および実行結果の成否を特定する情報を出力することができる。

これにより、機能と対応付けて、その機能を実現する複数のＡＰＩと、複数のＡＰＩの実行順序と、その実行順序で複数のＡＰＩを実行した場合の実行時間および実行結果の成否を記録することができる。また、ユーザからの機能の指定に応じて、その機能を実現するにあたり、どのＡＰＩを組み合わせて、どのような順番で実行すれば、時間やコストを抑えることができるのかを判断可能な情報を提供することができる。

また、サービス設計装置１０１によれば、各々のＡＰＩのリクエスト項目およびレスポンス項目のフォーマットに基づいて、複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定することができる。

これにより、ＡＰＩのリクエストとレスポンスの仕様から導出される関係性から、ＡＰＩ間の呼び出しの順序関係を特定することができる。

また、サービス設計装置１０１によれば、各々のＡＰＩの目的項目に基づいて、複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定することができる。

これにより、ＡＰＩの目的から判断されるＡＰＩ同士の依存関係をもとに、ＡＰＩ間の呼び出しの順序関係を特定することができる。

また、サービス設計装置１０１によれば、複数のＡＰＩのうち第１のＡＰＩと第２のＡＰＩとが組み合わせて使用された際の実行順序に基づいて、第１のＡＰＩと第２のＡＰＩとの呼び出しの順序関係を特定することができる。

これにより、既存のサービスやアプリケーションなどで使用されているＡＰＩの実行順序をもとに、ＡＰＩ間の呼び出しの順序関係を特定することができる。

また、サービス設計装置１０１によれば、特定したＡＰＩ間の呼び出しの順序関係に基づいて、複数のＡＰＩをグループＧ１～Ｇｎに分類することができる。また、サービス設計装置１０１によれば、分類したグループＧ１～ＧｎのいずれかのグループＧｉ内のＡＰＩ数が最大多重度を超える場合、グループＧｉ内の各々のＡＰＩのエラー率に基づいて、グループＧｉ内のＡＰＩを、各サブグループ内のＡＰＩ数が最大多重度を超えないように、サブグループｓ１～ｓｍに分類することができる。そして、サービス設計装置１０１によれば、分類したグループＧ１～ＧｎとグループＧｉ内のサブグループｓ１～ｓｍとに基づいて、複数のＡＰＩの実行順序を決定することができる。

これにより、グループＧｉ内のＡＰＩ数が最大多重度を超えている場合に、グループＧｉ内の各々のＡＰＩのエラー率を考慮して、新たなＡＰＩを効率的に実行可能な実行順序を決定することができる。

また、サービス設計装置１０１によれば、グループＧｉ内のＡＰＩ数が最大多重度を超える場合、グループＧｉ内の各々のＡＰＩのエラー率およびレイテンシに基づいて、前記いずれかのグループ内のＡＰＩを、各サブグループ内のＡＰＩ数が最大多重度を超えないように、サブグループｓ１～ｓｍに分類することができる。

これにより、グループＧｉ内のＡＰＩ数が最大多重度を超えている場合に、グループＧｉ内の各々のＡＰＩのエラー率およびレイテンシを考慮して、サービス（新たなＡＰＩ）を効率的に実行可能な実行順序を決定することができる。

これらのことから、サービス設計装置１０１によれば、ユーザが組み合わせたい複数のＡＰＩを選択するだけで、複数のＡＰＩの適切な実行順序を特定可能となり、容易に高品質なＡＰＩサービスを設計することができる。

なお、本実施の形態で説明したサービス設計方法は、あらかじめ用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本サービス設計プログラムは、ハードディスク、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ、ＵＳＢメモリ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本サービス設計プログラムは、インターネット等のネットワークを介して配布してもよい。

また、本実施の形態で説明したサービス設計装置１０１は、スタンダードセルやストラクチャードＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などの特定用途向けＩＣやＦＰＧＡなどのＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）によっても実現することができる。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）複数のＡＰＩの選択を受け付ける受付部と、
選択された前記複数のＡＰＩの各々のＡＰＩの仕様および使用履歴の少なくともいずれかの情報に基づいて、前記複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定する特定部と、
前記特定部によって特定された前記ＡＰＩ間の呼び出しの順序関係に基づいて、前記複数のＡＰＩの実行順序を決定する決定部と、
を有することを特徴とするサービス設計装置。

（付記２）前記決定部は、
さらに、並列実行可能なＡＰＩの上限数である最大多重度に基づいて、前記複数のＡＰＩの実行順序を決定する、ことを特徴とする付記１に記載のサービス設計装置。

（付記３）前記決定部は、
さらに、前記各々のＡＰＩを実行した際のエラー率に基づいて、前記複数のＡＰＩの実行順序を決定する、ことを特徴とする付記１に記載のサービス設計装置。

（付記４）前記決定部によって決定された前記複数のＡＰＩの実行順序を出力する出力部をさらに有することを特徴とする付記１に記載のサービス設計装置。

（付記５）前記出力部は、
前記複数のＡＰＩにより実現される機能と対応付けて、決定された前記複数のＡＰＩの実行順序を出力する、ことを特徴とする付記４に記載のサービス設計装置。

（付記６）前記出力部は、
前記複数のＡＰＩにより実現される機能と対応付けて、決定された前記複数のＡＰＩの実行順序と、当該実行順序に従って前記複数のＡＰＩを実行した場合の実行時間および実行結果の成否を出力する、ことを特徴とする付記４に記載のサービス設計装置。

（付記７）前記ＡＰＩは、Ｗｅｂ ＡＰＩである、ことを特徴とする付記１に記載のサービス設計装置。

（付記８）前記特定部は、
前記各々のＡＰＩのリクエスト項目およびレスポンス項目のフォーマットに基づいて、前記複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定する、ことを特徴とする付記１に記載のサービス設計装置。

（付記９）前記特定部は、
前記各々のＡＰＩの目的項目に基づいて、前記複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定する、ことを特徴とする付記１に記載のサービス設計装置。

（付記１０）前記特定部は、
前記複数のＡＰＩのうち第１のＡＰＩと第２のＡＰＩとが組み合わせて使用された際の実行順序に基づいて、前記第１のＡＰＩと前記第２のＡＰＩとの呼び出しの順序関係を特定する、ことを特徴とする付記１に記載のサービス設計装置。

（付記１１）前記決定部は、
特定された前記ＡＰＩ間の呼び出しの順序関係に基づいて、前記複数のＡＰＩを複数のグループに分類し、
分類した前記複数のグループのいずれかのグループ内のＡＰＩ数が、並列実行可能なＡＰＩの上限数である最大多重度を超える場合、前記いずれかのグループ内の各々のＡＰＩのエラー率に基づいて、前記いずれかのグループ内のＡＰＩを、各サブグループ内のＡＰＩ数が前記最大多重度を超えないように複数のサブグループに分類し、
前記複数のグループと、前記複数のサブグループとに基づいて、前記複数のＡＰＩの実行順序を決定する、ことを特徴とする付記１に記載のサービス設計装置。

（付記１２）前記決定部は、
分類した前記複数のグループのいずれかのグループ内のＡＰＩ数が前記最大多重度を超える場合、前記いずれかのグループ内の各々のＡＰＩのエラー率およびレイテンシに基づいて、前記いずれかのグループ内のＡＰＩを、各サブグループ内のＡＰＩ数が前記最大多重度を超えないように複数のサブグループに分類する、ことを特徴とする付記１１に記載のサービス設計装置。

（付記１３）複数のＡＰＩの選択を受け付け、
選択された前記複数のＡＰＩの各々のＡＰＩの仕様および使用履歴の少なくともいずれかの情報に基づいて、前記複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定し、
特定された前記ＡＰＩ間の呼び出しの順序関係に基づいて、前記複数のＡＰＩの実行順序を決定する、
処理をコンピュータが実行することを特徴とするサービス設計方法。

（付記１４）複数のＡＰＩの選択を受け付け、
選択された前記複数のＡＰＩの各々のＡＰＩの仕様および使用履歴の少なくともいずれかの情報に基づいて、前記複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定し、
特定された前記ＡＰＩ間の呼び出しの順序関係に基づいて、前記複数のＡＰＩの実行順序を決定する、
処理をコンピュータに実行させることを特徴とするサービス設計プログラム。

１０１ サービス設計装置
１１０ 記憶部
２００ 情報処理システム
２０１ 利用者端末
２１０ ネットワーク
２２０ ＡＰＩリポジトリ
３００，４００ バス
３０１，４０１ ＣＰＵ
３０２，４０２ メモリ
３０３，４０３ ディスクドライブ
３０４，４０４ ディスク
３０５，４０５ 通信Ｉ／Ｆ
３０６，４０８ 可搬型記録媒体Ｉ／Ｆ
３０７，４０９ 可搬型記録媒体
４０６ ディスプレイ
４０７ 入力装置
６０１ 受付部
６０２ 特定部
６０３ 決定部
６０４ 出力部
６０５ 実行部
１１００ 設計支援画面
１２００ 実行履歴テーブル
１３００ 推奨結果情報

Claims (6)

1. 複数のＡＰＩの選択を受け付ける受付部と、
   選択された前記複数のＡＰＩの各々のＡＰＩの仕様および使用履歴の少なくともいずれかの情報に基づいて、前記複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定する特定部と、
   前記特定部によって特定された前記ＡＰＩ間の呼び出しの順序関係に基づいて、前記複数のＡＰＩの実行順序を決定する決定部と、
   を有し、
   前記決定部は、
   前記特定部によって特定された前記ＡＰＩ間の呼び出しの順序関係に基づいて、呼び出しの順序関係が特定されたＡＰＩ同士を異なるグループに分類しつつ、呼び出しの順序関係が特定されなかったＡＰＩ同士を同一グループに分類することにより、前記複数のＡＰＩを複数のグループに分類するとともに、グループ間の順序関係を設定し、
   分類した前記複数のグループのいずれかのグループ内のＡＰＩ数が、並列実行可能なＡＰＩの上限数である最大多重度を超える場合、前記いずれかのグループ内のＡＰＩを、各サブグループ内のＡＰＩ数が前記最大多重度を超えないように複数のサブグループに分類するとともに、サブグループ間の順序関係を設定し、
   前記いずれかのグループ内の各々のＡＰＩのエラー率に基づいて、当該エラー率が高いＡＰＩほど順序が先となるように、前記複数のサブグループの各サブグループに属するＡＰＩを更新し、
   前記複数のサブグループのうちの先頭のサブグループ以外の他のサブグループ内の各々のＡＰＩのレイテンシに基づいて、前記他のサブグループに属する各々のＡＰＩのうちの最長のレイテンシによって決まる前記他のサブグループそれぞれのレイテンシを足した合計レイテンシが最短となるように、前記他のサブグループに属するＡＰＩを更新し、
   前記複数のグループと前記複数のサブグループとに基づいて、同一グループ内のＡＰＩを並列に実行しつつ、前記複数のグループのグループ間の順序関係に従って異なるグループ内のＡＰＩを直列に実行し、同一サブグループ内のＡＰＩを並列に実行しつつ、前記複数のサブグループのサブグループ間の順序関係に従って異なるサブグループ内のＡＰＩを直列に実行する順序を決定する、
   ことを特徴とするサービス設計装置。
2. 前記決定部によって決定された前記複数のＡＰＩの実行順序を出力する出力部をさらに有することを特徴とする請求項１に記載のサービス設計装置。
3. 前記出力部は、
   前記複数のＡＰＩにより実現される機能と対応付けて、決定された前記複数のＡＰＩの実行順序を出力する、ことを特徴とする請求項２に記載のサービス設計装置。
4. 前記出力部は、
   前記複数のＡＰＩにより実現される機能と対応付けて、決定された前記複数のＡＰＩの実行順序と、当該実行順序に従って前記複数のＡＰＩを実行した場合の実行時間および実行結果の成否を出力する、ことを特徴とする請求項２に記載のサービス設計装置。
5. 複数のＡＰＩの選択を受け付け、
   選択された前記複数のＡＰＩの各々のＡＰＩの仕様および使用履歴の少なくともいずれかの情報に基づいて、前記複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定し、
   特定された前記ＡＰＩ間の呼び出しの順序関係に基づいて、呼び出しの順序関係が特定されたＡＰＩ同士を異なるグループに分類しつつ、呼び出しの順序関係が特定されなかったＡＰＩ同士を同一グループに分類することにより、前記複数のＡＰＩを複数のグループに分類するとともに、グループ間の順序関係を設定し、
   分類した前記複数のグループのいずれかのグループ内のＡＰＩ数が、並列実行可能なＡＰＩの上限数である最大多重度を超える場合、前記いずれかのグループ内のＡＰＩを、各サブグループ内のＡＰＩ数が前記最大多重度を超えないように複数のサブグループに分類するとともに、サブグループ間の順序関係を設定し、
   前記いずれかのグループ内の各々のＡＰＩのエラー率に基づいて、当該エラー率が高いＡＰＩほど順序が先となるように、前記複数のサブグループの各サブグループに属するＡＰＩを更新し、
   前記複数のサブグループのうちの先頭のサブグループ以外の他のサブグループ内の各々のＡＰＩのレイテンシに基づいて、前記他のサブグループに属する各々のＡＰＩのうちの最長のレイテンシによって決まる前記他のサブグループそれぞれのレイテンシを足した合計レイテンシが最短となるように、前記他のサブグループに属するＡＰＩを更新し、
   前記複数のグループと前記複数のサブグループとに基づいて、同一グループ内のＡＰＩを並列に実行しつつ、前記複数のグループのグループ間の順序関係に従って異なるグループ内のＡＰＩを直列に実行し、同一サブグループ内のＡＰＩを並列に実行しつつ、前記複数のサブグループのサブグループ間の順序関係に従って異なるサブグループ内のＡＰＩを直列に実行する順序を決定することにより、前記複数のＡＰＩの実行順序を決定する、
   処理をコンピュータが実行することを特徴とするサービス設計方法。
6. 複数のＡＰＩの選択を受け付け、
   選択された前記複数のＡＰＩの各々のＡＰＩの仕様および使用履歴の少なくともいずれかの情報に基づいて、前記複数のＡＰＩに含まれるＡＰＩ間の呼び出しの順序関係を特定し、
   特定された前記ＡＰＩ間の呼び出しの順序関係に基づいて、呼び出しの順序関係が特定されたＡＰＩ同士を異なるグループに分類しつつ、呼び出しの順序関係が特定されなかったＡＰＩ同士を同一グループに分類することにより、前記複数のＡＰＩを複数のグループに分類するとともに、グループ間の順序関係を設定し、
   分類した前記複数のグループのいずれかのグループ内のＡＰＩ数が、並列実行可能なＡＰＩの上限数である最大多重度を超える場合、前記いずれかのグループ内のＡＰＩを、各サブグループ内のＡＰＩ数が前記最大多重度を超えないように複数のサブグループに分類するとともに、サブグループ間の順序関係を設定し、
   前記いずれかのグループ内の各々のＡＰＩのエラー率に基づいて、当該エラー率が高いＡＰＩほど順序が先となるように、前記複数のサブグループの各サブグループに属するＡＰＩを更新し、
   前記複数のサブグループのうちの先頭のサブグループ以外の他のサブグループ内の各々のＡＰＩのレイテンシに基づいて、前記他のサブグループに属する各々のＡＰＩのうちの最長のレイテンシによって決まる前記他のサブグループそれぞれのレイテンシを足した合計レイテンシが最短となるように、前記他のサブグループに属するＡＰＩを更新し、
   前記複数のグループと前記複数のサブグループとに基づいて、同一グループ内のＡＰＩを並列に実行しつつ、前記複数のグループのグループ間の順序関係に従って異なるグループ内のＡＰＩを直列に実行し、同一サブグループ内のＡＰＩを並列に実行しつつ、前記複数のサブグループのサブグループ間の順序関係に従って異なるサブグループ内のＡＰＩを直列に実行する順序を決定することにより、前記複数のＡＰＩの実行順序を決定する、
   処理をコンピュータに実行させることを特徴とするサービス設計プログラム。

Images