(57)【特許請求の範囲】
【請求項１】
ネットワークを経由して所定の処理を提供する第１のAPIと第２のAPIとの差分を吸収するAPI変換テーブルを生成するAPI変換テーブル生成装置であって、
前記第１，第２のAPIのリソースモデルのツリー構造を作成するAPIツリー作成部と、
前記第１，第２のAPIの間で、前記ツリー構造のリソースモデルを突き合わせ、類似度に基づいてデータまたはグループを一対一で対応付けるマッピング部と、
前記マッピング部による対応付けに基づいて、前記API変換テーブルを作成する変換テーブル作成部と、
を備えることを特徴とするAPI変換テーブル生成装置。
【請求項２】
前記マッピング部は、前記ツリー構造の最下層のデータの類似度により対応付けを行う、
ことを特徴とする請求項１に記載のAPI変換テーブル生成装置。
【請求項３】
前記マッピング部は、前記ツリー構造の最下層のデータの名称または／および当該データの説明を比較して類似度を算出する、
ことを特徴とする請求項２に記載のAPI変換テーブル生成装置。
【請求項４】
前記マッピング部は、前記第１のAPIのデータが前記第２のAPIの複数のデータに対応付けされたならば、各データを含むグループを上位ノードに順次拡大して前記第１のAPIと前記第２のAPIとの間でグループ同士を比較し、類似度に基づいて前記グループを一対一で対応付ける、
ことを特徴とする請求項２に記載のAPI変換テーブル生成装置。
【請求項５】
前記変換テーブル作成部は、前記第１のAPIと前記第２のAPIとがグループ単位で一致したならば、当該グループ単位で括って前記API変換テーブルを作成する、
ことを特徴とする請求項１に記載のAPI変換テーブル生成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、API（Application Program Interface）リクエストの変換テーブルを生成するAPI変換テーブル生成装置に関する。
【背景技術】
【０００２】
近年のネットワークの高速化とウェブブラウザの普及により、インターネットを経由して所定の処理を提供するAPIが広く普及している。このAPIは、インターネット経由で或るサーバ上にあるプログラムや管理データなどを、他のサーバや端末などから呼び出して利用するための手順やデータ形式などを定めた規約であり、コンピュータプログラムの機能を呼び出して利用するための規約であるAPIに擬えて呼ばれている。
【０００３】
開発者は、APIを活用することによって、容易にエンドユーザ向けアプリケーションを開発することができる。またAPIの提供者は、このAPIを活用したアプリケーションにより、自社のサービスやコンテンツをエンドユーザ等に訴求することができる。例えば通信キャリアは、ネットワーク機能やオペレーション機能をAPIとしてエンドユーザ向けアプリケーションの開発を促し、自社の通信サービスをエンドユーザ等に訴求することができる。
【０００４】
また近年では、スマートフォン等のデバイスが多様化し、また市場がグローバル化して、ニッチな領域への事業者の新規参入が容易になった。このような中で、APIを収益確保可能な形で提供することが重要である。これらサービスの実現と収益確保のためには、事業者間でAPIの連携（マッシュアップ）が容易であることが望ましい。APIの連携を可能とするには、APIの技術標準を定め、これに準拠した標準APIに統一することが望まれる。
【０００５】
例えば非特許文献１には、この標準APIのモデルについて記載されている。この非特許文献１の発行元であるTM(TeleManagement) FORUMは、相互運用のできる情報通信システムのネットワーク管理を実現するため、業界標準の検討と、それに基づく製品化の促進、業界の活性化を目的に設立された非営利の業界団体であり、複数事業者を跨ったサービスを提供するための標準APIについて検討している。
【０００６】
図１３（ａ）は、ＴＭＦ（TeleManagement FORUM）の標準APIで採用されたREST（REpresentational State Transfer）形式のGETリクエストの例を示し、図１３（ｂ）はレスポンスの例を示している。
このようにREST形式のAPIでは、HTTP（Hypertext Transfer Protocol）のメソッドである「GET」でシステムに処理要求を伝え、HTTPのレスポンスで応答を受け取る。なおREST形式では、HTTPの５つメソッドである「GET」「POST」「PUT」「PATCH」「DELETE」で処理要求を伝えることができる。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】TeleManagement FORUM，“Frameworx Specification Product Ordering API REST Specification”，Release 14.5.0，November 2014
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上記したように、事業者間連携を行う場合は、例えばＴＭＦの標準に準拠した共通的な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と前記第２のAPIとの間でグループ同士を比較し、類似度に基づいて前記グループを一対一で対応付ける、ことを特徴とする請求項２に記載のAPI変換テーブル生成装置とした。
【００１９】
このようにすることで、誤りなく第１，第２のAPIのリソースモデルの対応付けを行うことができる。
【００２０】
請求項５に記載の発明では、前記変換テーブル作成部は、前記第１のAPIと前記第２のAPIとがグループ単位で一致したならば、当該グループ単位で括って前記API変換テーブルを作成する、ことを特徴とする請求項１に記載のAPI変換テーブル生成装置とした。
【００２１】
このようにすることで、API変換テーブルに含まれる対応付けのエントリ数を少なくして、容易かつ高速にAPIを変換することができる。
【発明の効果】
【００２６】
本発明によれば、一のAPIを他のAPI規定に合わせたAPIに変換する変換テーブルを自動生成することが可能となる。
【図面の簡単な説明】
【００２７】
【図１】本実施形態におけるAPI変換装置とAPI変換テーブル生成装置を含むシステム構成図である。
【図２】API変換装置とAPI変換テーブル生成装置の概略のブロック図である。
【図３】API構造比較部の処理を示すフローチャートである。
【図４】UMLモデルをツリー構造で表現した例を示す図である。
【図５】APIツリー作成部の動作を説明する図である。
【図６】マッピング部の動作例（その１）の説明図である。
【図７】マッピング部の動作例（その２）の説明図である。
【図８】マッピング部の動作例（その３）の説明図である。
【図９】マッピング部の動作例（その４）の説明図である。
【図１０】変換テーブル作成部の動作例の説明図である。
【図１１】変換テーブル作成部の他の動作例の説明図である。
【図１２】変換テーブル作成部の他の動作例の説明図である。
【図１３】RESTのGETリクエストとレスポンスの例を示す図である。
【発明を実施するための形態】
【００２８】
次に、本発明を実施するための形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。
図１は、本実施形態における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処理部２２は、独自APIと共通APIとの間の変換情報を格納したAPI変換テーブル２２１、APIを変換するAPI変換部２２２、複数のAPIを連携して新たなAPIとするAPIマッシュアップ部２２３を含んで構成される。このAPI変換装置２は、ＣＰＵ（Central Processing Unit）とＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）などを有するコンピュータであり、不図示の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の仕様情報を保有する。辞書データ保有部１７は、共通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準拠のシステム４１やイネーブラに対してAPIを介した通信が行われる時、API変換テーブル２２１（図２参照）に基づいてAPI変換を行うことで、既存システム３２に手を加えることなく、共通APIにて実装されたシステム４１やイネーブラへのアクセスを可能とする。
【００４３】
以下で説明する動作例では、既存システム３２の独自API、共通APIともにRESTを採用していることが前提である。更に共通APIは、ＴＭＦの標準APIモデルに従い、リソース名やデータ構造が定められており、リソース名やデータ構造はＴＭＦ記載の名称をそのまま用いていることが前提である。
なお、ＴＭＦではモデルを規定しているが、その実装は各事業者に委ねており、ＴＭＦの規定に準拠したAPIであっても、特有の名称が用いられることがある。
【００４４】
図４は、UMLモデルをツリー構造で表現した例を示す図である。
既存システム３２の独自APIと共通APIは同じREST形式のプロトコルを用いており、リソースモデルおよびデータ構造があらかじめ把握できている。図４は、APIツリー作成部１２１が作成した独自APIまたは共通APIのリソースモデルのツリー構造を例示している。各ツリー構造において、長方形はツリー構造のリソース名を示すノードである。角が丸い四角形は、データを示すノードである。
【００４５】
図５は、APIツリー作成部１２１の動作（その１）を説明する図である。この図５は、図３のフローチャートのステップＳ１０の直後の状態を示している。
独自API仕様６２は、ツリー構造の“API10”を含んでいる。共通API仕様６１は、ツリー構造の“API1”，“API2”，“API3”，“API4”，を含んでいる。
APIツリー作成部１２１は、独自API仕様６２と共通API仕様６１の最下層のノード（データ）同士を比較してマッピングする。マッピング不可なノードは、独自データとみなす。なお既存システム３２のデータ項目名は独自である場合があることから、突き合わせには類似度計算が必要であり、これを図６にて説明する。
【００４６】
リソースモデルのツリー構造のうち、上位ノードからマッピングを行うことでマッピング範囲を絞り込むことも可能であるが、この場合には、絞り込みのためマッピングができない場合が有る。
例えば「サービスオーダ」と「ProductOrder」が一致とみなせる場合、探索範囲を絞り込むことが可能であるが、共通API仕様６１にて顧客情報は「Customer」に盛り込まれているため「ProductOrder」の探索だけでは不十分であり、マッピングが行えない。そのため、本実施形態では、共通API仕様６１と独自API仕様６２の最下層のノード（データ）からマッピングを行っている。なお、上位からのマッピングでは、一度探索したうえで、見つからない場合は、他のAPIまで範囲を広げるといった方法もある。
【００４７】
図６は、マッピング部１２２の動作例（その１）の説明図である。
マッピング部１２２は、データ名および「その他情報」を用いて類似度を算出し、 APIデータ名の突き合わせを行う。
マッピング部１２２は、類似度計算にて、例えば、共通API仕様６１のデータ名と独自API仕様６２のデータ名との類似度を算出して第１係数を乗算する。マッピング部１２２は更に、共通API仕様６１の「その他情報」と独自API仕様６２の「その他情報」との類似度を算出して第２係数を乗算し、共通API仕様６１のデータ名と独自API仕様６２の「その他情報」との類似度を算出して第３係数を乗算し、共通API仕様６１の「その他情報」と独自API仕様６２のデータ名との類似度を算出して第４係数を乗算する。最後にマッピング部１２２は、これら４項の乗算結果の総和をとり、これを独自APIと共通APIの当該ノードにおける類似度とする。
既存システム３２の独自API仕様６２のデータ名では、インタフェース仕様にて定められた日本語説明を用いる。共通API仕様６１のデータ名では、データ名の英語の説明に加え、データ名から類義語リストを作成し、データ名の日本語の意味を検索することで、データ名の意味を補強するとよい。またデータ名とその他情報を用いて類似度計算を行うことにより、精度を高めることができる。なお、日本語は分かち書きされないので、日本語で記載された「その他の情報」の部分は、形態素解析などにより単語単位に分解して比較する。
【００４８】
類似度計算では一意にマッピングが決まらない場合もありうる。マッピングが決まらない場合には一旦保留したのち、以降のリソースレベルでマッピングする。また、インタフェース仕様書などに記載された情報を補足情報として用いることで、類似度計算の精度を高めることができる。
【００４９】
図６に示した例では、独自API仕様６２の第１行目のデータと、共通API仕様６１の第１，第２行目のデータとを比較している。独自API仕様６２の第１行目のデータ名と、共通API仕様６１の第１行目の「その他情報」とで“customer”の単語が一致する。更に、独自API仕様６２の第１行目のデータ名の“No”と、共通API仕様６１の第１行目のデータ名の“id”とは、目的が一致する。更に独自API仕様６２の第１行目の「その他情報」に記載の「お客様固有」と、共通API仕様６１の第１行目の「その他情報」に記載の「識別するために用いられる符号」とは、目的が一致する。よって、独自API仕様６２の第１行目のデータと、共通API仕様６１の第１行目のデータとでは類似度が高くなる。
【００５０】
独自API仕様６２の第１行目のデータ名と、共通API仕様６１の第２行目の「その他情報」とで“customer”の単語が一致する。しかし、それ以外の一致はないので、独自API仕様６２の第１行目のデータと、共通API仕様６１の第２行目のデータとでは類似度が比較的低くなる。
【００５１】
類似度計算は、予め与えられた辞書により検索される。辞書は既存のものを活用することに加え、専門用語や専門の略称も含まれると考えられることから、追加で補完する情報を加えるとよい。具体的にいうと追加で補完する情報とは、例えば“SO”といった略称であり、インターネットなどの外部から取得したり、手作業で入力するとよい。
【００５２】
図７は、マッピング部１２２の動作例（その２）の説明図である。この図７は、図３のフローチャートのステップＳ１１の直後の状態を示している。
図７に示すように、独自API仕様６２の“API10”のデータ３２１，３２２は、共通API仕様６１の“API3”のデータ３１１，３１２に一対一でマッピング可能である。
独自API仕様６２の“API10”のデータ３２３は、共通API仕様６１の“API1”のデータ３１３に一対一でマッピング可能である。独自API仕様６２の“API10”のデータ３２４は、共通API仕様６１の“API4”のデータ３１４に一対一でマッピング可能である。
【００５３】
独自API仕様６２の“API10”のデータ３２５は、共通API仕様６１の“API1”のデータ３１７と、“API2”のデータ３１５とに一対多でマッピングされる。独自API仕様６２の“API10”のデータ３２６は、共通API仕様６１の“API1”のデータ３１８と、“API2”のデータ３１６とに一対多でマッピングされる。
なお、破線で示した四角形は、マッピングされなかったノード（データ）を示している。これを独自ノードという。
【００５４】
図８は、マッピング部１２２の動作例（その３）の説明図である。この図８は、図３のフローチャートのステップＳ１３の直後の状態を示している。
マッピング部１２２は、独自ノードを除外した状態にて、最下層から一つ上までのノードを一つのグループと見做してグルーピングを行い。グループを相互に比較する。
ここでマッピング部１２２は、共通API仕様６１の“API3”のデータ３１１，３１２の一つ上までのノードをグルーピングし、グループＧ１ｂとする。共通API仕様６１の“API2”のデータ３１５，３１６の一つ上までのノードをグルーピングし、グループＧ２ｂとする。
【００５５】
更にマッピング部１２２は、共通API仕様６１の“API1”のデータ３１３の一つ上までのノードをグルーピングし、グループＧ３ｂにする。共通API仕様６１の“API1”のデータ３１７，３１８の一つ上までのノードをグルーピングし、グループＧ４ｂとする。次いでマッピング部１２２は、共通API仕様６１の“API4”のデータ３１４の一つ上までのノードをグルーピングし、グループＧ５ｂにする。
【００５６】
図９は、マッピング部１２２の動作例（その４）の説明図である。この図９は、図３のフローチャートのステップＳ１５の直後の状態を示している。
マッピング部１２２は、グループに含まれるノードが互いに一致する場合はグループ単位でマッピングする。例えば、マッピング部１２２は、独自API仕様６２の“API10”のグループＧ１ａと、共通API仕様６１の“API3”のグループＧ１ｂとをマッピングする。更に独自API仕様６２の“API10”のグループＧ２ａと、共通API仕様６１の“API2”のグループＧ２ｂとをマッピングする。ここで共通API仕様６１の“API1”のグループＧ４ｂは、グループを拡大した結果、独自API仕様６２の“API10”のグループＧ２ａとは異なるデータ群であることが判明したため、マッピングしない。
このようにマッピング部１２２は、グループが一対一にマッピングされるまでグループの拡大を繰り返す。つまり、ツリー構造の最上位ノードまで繰り返す。
【００５７】
図１０（ａ），（ｂ）は、変換テーブル作成部１２３の動作例の説明図である。この図１０（ａ），（ｂ）は、図３のフローチャートのステップＳ１６の処理を示している。
図１０（ａ）は、マッピング結果と各ノード名称との対応を示す図である。
グループＧ１ａは、独自API仕様６２の“API10”のノード“A”と、これに属するデータ３２１，３２２を含んでいる。このグループＧ１ａにマッピングされたグループＧ１ｂは、共通API仕様６１の“API3”のノード“API3-a”と、これに属するデータ３２１，３２２を含んでいる。
【００５８】
データ３２３は、独自API仕様６２の“API10”のノード“B”に属するノード“a”に更に属しており、名称は“data1”である。このデータ３２３にマッピングされたデータ３１３は、共通API仕様６１の“API1”のノード“API1-a”に従属するデータであり、名称は“d1”である。
データ３２４は、独自API仕様６２の“API10”のノード“B”に属するノード“a”に更に属しており、名称は“data2”である。このデータ３２４にマッピングされたデータ３１４は、共通API仕様６１の“API4”のノード“API4-a”に従属するデータであり、名称は“d2”である。
【００５９】
グループＧ２ａは、独自API仕様６２の“API10”のノード“B”に属するノード“b”と、データ３２５，３２６を含んでいる。このグループＧ２ａにマッピングされたグループＧ２ｂは、共通API仕様６１の“API2”のノード“API2-b”と、これに属するデータ３１５，３１６を含んでいる。
【００６０】
図１０（ｂ）は、作成したAPI変換テーブル２２１の例を示している。
独自API仕様６２の“/API10/A”は、共通API仕様６１の“/API3/API3-a”に変換される。これは、グループＧ１ａとグループＧ１ｂとのマッピング結果により作成される。このように、グルーピングしたマッピング結果からAPI変換テーブル２２１を作成することで、API変換テーブル２２１のエントリ数を削減することができる。
独自API仕様６２の“/API10/B/b”は、共通API仕様６１の“/API2/API2-b”に変換される。これは、グループＧ２ａとグループＧ２ｂとのマッピング結果により作成される。
【００６１】
独自API仕様６２の“/API10/B/a/data1”は、共通API仕様６１の“/API1/API1-a/d1”に変換される。これは、データ３２３とデータ３１３とのマッピング結果により作成される。
独自API仕様６２の“/API10/B/a/data2”は、共通API仕様６１の“/API4/API4-a/d2”に変換される。これは、データ３２４とデータ３１４とのマッピング結果により作成される。
なお、グルーピングを行わす、データ単位でマッピングしてもよい。これにより、短時間にマッピング結果を得ることができる。
【００６２】
図１１（ａ）〜（ｃ）は、変換テーブル作成部１２３の他の動作例の説明図である。
API変換テーブル２２１の作成は、マッピングのパターンに基づき、以下のように定める。
図１１（ａ）は、グループ単位、または個々のデータが一致するパターンを示している。
このとき変換テーブル作成部１２３は、独自API仕様６２の「顧客情報」のグループ名と、共通API仕様６１の「Customer」のグループ名とで括ってAPI変換テーブル２２１を作成する。「顧客番号」は「id」にマッピングし、「名前」は、「name」にマッピングする。
【００６３】
図１１（ｂ）は、グループ単位、または個々のデータが一致するパターンを示している。
このとき変換テーブル作成部１２３は、独自API仕様６２の「/トラチケ/利用者名」と、共通API仕様６１の「/Customer/name」とのマッピングによりAPI変換テーブル２２１を作成する。なお、ここで記載された「トラチケ」とは、トラブルチケットの略称である。
【００６４】
図１１（ｃ）は、データの粒度が異なり、かつデータを分割可能なパターンを示している。
このとき変換テーブル作成部１２３は、リクエストやレスポンスを束ねるルールや、分割するルールに基づいてマッピングする。例えば独自API仕様６２の「/顧客情報/姓」と「/顧客情報/名」とを束ねると、共通API仕様６１の「/Customer/name」にマッピング可能である。
【００６５】
図１２は、変換テーブル作成部１２３の他の動作例の説明図である。
ここでは、データの粒度が異なり、かつ複数のデータを束ねて初めて意味を成すパターンについて説明する。例えば、独自API仕様６２のデータＡ，Ｂ，Ｃが揃ったときに共通API仕様６１のデータａ，ｂ，ｃ，ｄと同じ意味をなす場合は、一時的にバッファリングを行い、分割したリクエストに対するレスポンスが全て揃った段階で変換する。
このようにデータの粒度が異なるパターンは、APIマッシュアップ部２２３の機能を用いて、分割したリクエストに対する全レスポンスを取得したのちに、変換を行うとよい。また、リクエストまたはレスポンスに不足がある場合は、ダミーデータ（空情報を含む）を返却する、またはエラーコードと共に追加リクエストを要求する、といった手段が可能である。
【００６６】
なお、自動マッピングができないデータ項目は、変換テーブル案提示部１３（図２参照）により、リスト化したうえで、管理者（人間）に通知するとよい。これにより、管理者による適切なAPI変換テーブルの生成を好適に支援することができる。
【００６７】
（変形例）
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ）〜（ｃ）のようなものがある。
（ａ）  APIの変換方向は限定されない。独自APIを共通APIに変換するのみでなく、その逆に共通APIを独自APIに変換してもよい。
（ｂ）  API変換テーブル生成装置１は、API変換装置２とは別に構成してもよく、API変換装置２の内部にAPI変換テーブル生成手段として実装してもよく、限定されない。
（ｃ）  APIの形式はRESTに限定されず、例えばSOAP（SimpleObject Access Protocol）といった他のプロトコル形式であってもよい。
【符号の説明】
【００６８】
１  API変換テーブル生成装置
１１  API構造受付部
１２  API構造比較部
１２１  APIツリー作成部
１２２  マッピング部
１２３  変換テーブル作成部
１６  共通API情報保有部
１７  辞書データ保有部
１８  外部情報取得部
２  API変換装置
２１  API入力部
２２  API処理部
２２１  API変換テーブル
２２２  API変換部
２２３  APIマッシュアップ部
２３  API出力部
３  ネットワーク事業者
３１  新規システム
３２  既存システム
３３  オーケストレータ
４  サービス事業者
４１  システム
５  APIアグリゲーション
【図１】
0006457903.tif 000002
【図２】
0006457903.tif 000003
【図３】
0006457903.tif 000004
【図４】
0006457903.tif 000005
【図５】
0006457903.tif 000006
【図６】
0006457903.tif 000007
【図７】
0006457903.tif 000008
【図８】
0006457903.tif 000009
【図９】
0006457903.tif 000010
【図１０】
0006457903.tif 000011
【図１１】
0006457903.tif 000012
【図１２】
0006457903.tif 000013
【図１３】
0006457903.tif 000014