(57)【要約】【課題】サービスに係るAPIと同一目的のものを、異なるサービスに係るAPIから短時間で選定可能とする。【解決手段】推薦装置５は、複数の第１APIを説明する文章を含む複数のAPI情報を保有するAPI情報保有部５３と、第２APIを説明する文章を有するAPI文書の入力を受け付ける入力部と、API文書とAPI情報との類似度を算出する類似度算出部５９と、類似度算出部５９が算出した類似度に基づき、第２APIに類似する一または複数の第１APIを推薦するAPI推薦部５４とを備える。【選択図】図２
2017142640.tif 000002
【特許請求の範囲】
【請求項１】
複数の第１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（Application-Program Interface）が広く普及している。このAPIは、インターネット経由で或るサーバ上にあるプログラムや管理データなどを、他のサーバや端末などから呼び出して利用するための手順やデータ形式などを定めた規約であり、コンピュータプログラムの機能を呼び出して利用するための規約であるAPIに擬えて呼ばれている。
【０００３】
開発者は、APIを活用することによって、容易にエンドユーザ向けアプリケーションを開発することができる。またAPIの提供者は、このAPIを活用したアプリケーションにより、自社のサービスやコンテンツをエンドユーザ等に訴求することができる。例えば通信キャリアは、ネットワーク機能やオペレーション機能をAPIとしてエンドユーザ向けアプリケーションの開発を促し、自社の通信サービスをエンドユーザ等に訴求することができる。
【０００４】
また近年では、スマートフォン等のデバイスが多様化し、また市場がグローバル化して、ニッチな領域への事業者の新規参入が容易になった。このような中で、APIを収益確保可能な形で提供することが重要である。これらサービスの実現と収益確保のためには、事業者間でAPIの連携（マッシュアップ）が容易であることが望ましい。APIの連携を可能とするには、APIの技術標準を定め、これに準拠した標準APIに統一することが望まれる。
【０００５】
例えば非特許文献１には、この標準APIのモデルについて記載されている。この非特許文献１の発行元であるTM(TeleManagement) FORUMは、相互運用のできる情報通信システムのネットワーク管理を実現するため、業界標準の検討と、それに基づく製品化の促進、業界の活性化を目的に設立された非営利の業界団体であり、複数事業者を跨ったサービスを提供するための標準APIについて検討している。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】TeleManagement FORUM，“Frameworx Specification Product Ordering API REST Specification”，Release 14.5.0，November 2014
【発明の概要】
【発明が解決しようとする課題】
【０００７】
サービス事業者などによってAPIが提供されているサービスＡについて、サービスＸのAPI_XをサービスＡのAPI_Aに合わせたい場合がある。すなわち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_Xによってネットワーク事業者システム２ａにサービスを提供し、API_Yによってネットワーク事業者システム２ｂにサービスを提供し、API_Zによってクラウド事業者システム２ｃにサービスを提供している。つまり、これらAPI_X、API_Y、API_Zには相互に異なっている。つまりサービス事業者システム１ａと、ネットワーク事業者システム２ａ，２ｂやクラウド事業者システム２ｃとの接続は困難である。
【００３０】
図５（ｂ）は、API共通化後における状態を示す図である。
サービス事業者システム１ａは、API_Aによってネットワーク事業者システム２ａ，２ｂとクラウド事業者システム２ｃにサービスを提供している。更に、他のサービス事業者システム１ｂも、API_Aによってネットワーク事業者システム２ａ，２ｂとクラウド事業者システム２ｃにサービスを提供している。つまり、このシステムは、APIを共通化している。
API共通化により、サービス事業者システム１ａは、サービスの拡大時にネットワーク事業者システム２ａ，２ｂやクラウド事業者システム２ｃとの接続が容易となる。他のサービス事業者システム１ｂなどは、サービスへの新規参入が容易となる。また、各サービス事業者システム１ａ，１ｂは、新規顧客の獲得が容易となる。
更にネットワーク事業者やラウド事業者は、市販品活用によるコスト削減を図ることができる。
しかし、サービス事業者システム１ａやネットワーク事業者システム２ａが、既存の処理部を改修してAPI_XをAPI_Aに共通化するには、多大な移行工数が掛かる。そこで、共通API化のために、メディエータ（後記する図６参照）と呼ばれるAPI変換装置を用いることが多い。
【００３１】
図６は、比較例のメディエータ４による共通API化を示す構成図である。
メディエータ４は、API変換部４５と、API入力部４１，４４と、API出力部４２，４３と、シナリオ入力部４６と、API変換シナリオ４７とを含んで構成される。ユーザは、シナリオ入力部４６を介してAPI変換シナリオ４７を予め登録する。ネットワーク事業者システム２は、既存のサービスＸに係るAPI_X仕様のAPIをリクエストする。サービス事業者システム１は、共通化されたサービスＡに係るAPI_A仕様のAPIを提供する。このメディエータ４は、API変換シナリオ４７に基づいてAPI_XをAPI_Aに変換してサービス事業者システム１に出力すると共に、API_AをAPI_Xに変換してネットワーク事業者システム２に出力する。
【００３２】
ネットワーク事業者システム２は、メディエータ４を介してAPI_X仕様によるコマンドをサービス事業者システム１に送信する。API入力部４４は、ネットワーク事業者システム２から送信されたAPIリクエストを受け付け、API変換部４５は、このAPIリクエストをAPI変換シナリオ４７に基づいてAPI_A仕様に変更する。API出力部４３は、変換されたAPIリクエストをサービス事業者システム１に出力する。
【００３３】
サービス事業者システム１は、APIリクエストに基づく処理を実行したのち、APIレスポンスをネットワーク事業者システム２に送信する。サービス事業者システム１が送信するAPIレスポンスは、メディエータ４を介してネットワーク事業者システム２に送信される。
API入力部４１は、サービス事業者システム１から送信されたAPI_A仕様のAPIレスポンスを受け付け、API変換部４５は、このAPIレスポンスをAPI変換シナリオ４７に基づいてAPI_X仕様に変更する。API出力部４２は、変換されたAPIレスポンスを出力する。
これにより、API_X仕様のネットワーク事業者システム２は、API_A仕様のサービス事業者システム１で動作可能となる。つまり、ネットワーク事業者システム２は、メディエータ４によって共通API化される。
【００３４】
メディエータ４の実装にあたっては、API変換シナリオ４７を予め作成して、シナリオ入力部４６を介して入力しておく必要がある。このとき、メディエータ４のユーザは、既存サービスであるAPI_X仕様を紐解いたうえで、API_A仕様に含まれる各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_X仕様のAPIをリクエストする。サービス事業者システム１は、共通化されたサービスＡに係るAPI_A仕様のAPIを提供する。このメディエータ４は、API_X仕様のAPIリクエストをAPI_A仕様に変換してサービス事業者システム１に出力すると共に、API_A仕様のAPIレスポンスをAPI_X仕様に変換してネットワーク事業者システム２に出力する。
【００３７】
ネットワーク事業者システム２は、メディエータ４を介してAPI_X仕様によるコマンドをサービス事業者システム１に送信する。API入力部４４は、ネットワーク事業者システム２から送信されたAPIリクエストを受け付け、API変換部４５は、このAPIリクエストをAPI変換シナリオ４７に基づいてAPI_A仕様に変更する。API出力部４３は、変換されたAPIリクエストをサービス事業者システム１に出力する。
サービス事業者システム１は、APIリクエストに基づく処理を実行したのち、APIレスポンスをネットワーク事業者システム２に送信する。サービス事業者システム１が送信するAPIレスポンスは、メディエータ４を介してネットワーク事業者システム２に送信される。
【００３８】
API入力部４１は、サービス事業者システム１から送信されたAPI_A仕様のAPIレスポンスを受け付け、API変換部４５は、このAPIレスポンスをAPI変換シナリオ４７に基づいてAPI_X仕様に変更する。API出力部４２は、変換されたAPIレスポンスを出力する。
【００３９】
図２は、推薦装置５の詳細を示す図である。
推薦装置５は、図１に示したAPIドキュメント入力部５１、APIマッチング部５２、API情報保有部５３、API推薦部５４に加えて更に、正誤判定結果部５５、教師データ保有部５６を含んで構成される。APIドキュメント入力部５１は、受付部５７と加工部５８とを含んで構成される。APIマッチング部５２は、類似度算出部５９を含んで構成される。API情報保有部５３は、予め比較先となるサービスＡに係るAPI_A（第１API）の仕様であるAPI情報を保有している。このAPI情報は、複数のAPIを説明する文章を含んでいる。
ユーザが推薦装置５に比較したいAPI文書の文章全体とパラメータ情報の２つを入力することで、推薦装置５は、API文書間の類似度を算出し、同一目的で用いるAPIをユーザに推薦する。
【００４０】
受付部５７は、APIドキュメント入力部５１の一部であり、ユーザが入力したサービスＸに係るAPI_X（第２API）の仕様のうち、１または複数のAPIの仕様が記載されたAPI文書６（API情報）の入力を受け付ける。なお、図２ではAPI文書６のことを、APIドキュメントと記載している。
受付部５７は、API文書６の文章全体と、リクエストパラメータやレスポンスパラメータを有する文章の２種類の受付を許容する。ただしAPI文書６の文章全体の受付は必須とする。API文書６の文章全体が入力された場合は、API推薦までを実施し、パラメータの推薦は行わない。ユーザが受付部５７に入力するAPIは、個々に一つずつ入力してもよいし、あるAPI群をまとめて入力してもよい。なお、受付部５７は、リクエストパラメータ例やレスポンスパラメータ例が含まれるAPI文書６を受け付けることができる。
【００４１】
加工部５８は、APIドキュメント入力部５１の一部であり、API文書６のうち、リクエストパラメータ例やレスポンスパラメータ例が記載された部分を削除することで、同一目的で用いるAPIの選定精度を高めている。リクエストパラメータ例やレスポンスパラメータ例は、API文書６の固有表現であり、既存の文書類似度の算出に対するノイズとなるためである。具体的に加工部５８は、JSON（JavaScript（登録商標） Object Notation）形式やXML（eXtensible Markup Language）形式で記述されている部分と、数字を含む単語の文字列とを判定して削除する。JSON形式やXML形式の判定は、中括弧｛｝や山括弧＜＞で括られる部分を見つけることにより行う。加工部５８の処理により、類似度算出部５９の演算におけるノイズを除去することができる。
【００４２】
類似度算出部５９は、API文書６と、API情報保有部５３が保有する各API情報との類似度を算出する。類似度算出部５９は、教師データ保有部５６に保有した業界特有用語集５６１の類義語セットを用いて単語の置換を行うことで、サービス固有の表現の揺れを吸収してAPI選定の精度を高める。更に類似度算出部５９は、業界特有用語集５６１における単語と業務区分との対応に基づき、その区分に当てはまるAPI群を全て候補として提示する。類似度算出部５９は、ベクトル生成にてAPI文書の内容を正確に表すため、他のドキュメントに現れていない、このドキュメント特有の単語に対して、より大きな重み付けを行う。類似度算出部５９は、文章を単語に分解し、単語ごとの出現数を要素に文章ベクトルを生成し、２つの文章に係るベクトルの大きさや向きの差を、２つの文章の類似度として扱い、類似度上位のAPIを複数個抽出する。なお、類似度算出部５９は、類似度が閾値以上であり、かつAPI名が同一のものは、優先的にマッチング先に選定してもよい。
【００４３】
API推薦部５４は、類似度算出部５９の算出の結果として、マッチング先として推薦するAPI候補群を、ユーザ端末の画面上（表示装置）に提示する。API推薦部５４は更に、API候補ごとに正誤判定結果をユーザに入力してもらい、正誤判定の結果を正誤判定結果部５５に格納する。正誤判定結果部５５に保有される判定結果に基づいて教師データ保有部５６のデータが更にアップデートされることで、類似度算出部５９の精度が向上する。このようにすることで、類似度算出部５９の算出精度は、API推薦を繰り返すほど向上する。
【００４４】
API情報保有部５３（保有部）は、マッチング先となるサービスＡに係るAPI_A（第１API）の仕様情報を保有するデータベースである。API仕様７は、各APIを説明する文章７１と、リクエストパラメータ７２と、レスポンスパラメータ７３の組合せを複数含んで構成される。なおAPI情報保有部５３は、マッチング先となる複数のサービスに係るAPI仕様情報を保有してもよい。API情報保有部５３は、例えばTMF（TeleManagement FORUM）のAPI仕様情報や、AWS（Amazon（登録商標） Web Service）のAPI仕様情報を保有してもよい。
教師データ保有部５６は、業界特有用語集５６１を保有する。具体的には、「所定業務に特有のキーワード」を有する。例えば業務区分を「計画・建設系業務」「保全系業務」「課金系業務」に分類した、分類された各業務ごとの区分に、それぞれ１００個のAPI群が分類されている場合を考える。この場合、業務ごとの区分情報に依らずにAPIを推薦するならば、３００個のAPI群から探索する必要がある。
しかし、例えばAPIの文書中に単語“Alarm”が多く出現する場合に「保全系業務で使うAPI」であると推測すると、マッチング先APIの推薦にあたり、候補を「保全系業務で使うAPI群」の１００個に絞り込むことができる。これにより、より正解のAPIを見つけやすくなる。このような対応関係は、例えばTMFのAPI仕様情報からキーワードを抽出するとよい。教師データ保有部５６の各データは、類似度算出部５９に参照され、類似度の重み付けに活用される。
【００４５】
正誤判定結果部５５は、ユーザによる正誤判定結果を保有する。例えばcloudn（登録商標）の“Template”は、AWSの“Image”と同等であることが分かっているが、機械的に類似度を算出するだけでは同等とみなされない。手作業で判断した結果として“Template”は“Image”と同等であるというルールを生成して保有するとよい。
【００４６】
図３は、API文書６の例を示す図である。
API文書６は、API仕様に関する文書であり、APIの名称を保有するAPI名６１、APIに係る仕様を説明するAPI説明６２、リクエストパラメータ６３、レスポンスパラメータ６４、リクエストパラメータ例６５、レスポンスパラメータ例６６を含んで構成される。リクエストパラメータ例６５には、リクエストパラメータ６３の例が示されている。レスポンスパラメータ例６６には、レスポンスパラメータ６４の例が示されている。
API名６１が保有するAPIの名称は、複合語であるキャメルケースやスネークケースで記載されることが多い。ここでキャメルケースとは、複数の単語間のスペースを詰めて次の語を大文字から始めた文字列である。スネークケースとは、複数の単語間のスペースをアンダースコアに置き換えた文字列である。これは一つの文字列トークンのみがAPIの名称として認められるという実装上の制約による。
例えば“alarm name”をキャメルケースで記載すると“AlarmName”であり、スネークケースで記載すると“alarm_name”となる。よって、文書ベクトルのノイズとなるキャメルケースやスネークケースの文字列を各単語に分解することで、文書ベクトルを構成する単語を増やして類似度計算の精度を向上させることができる。
リクエストパラメータ例６５やレスポンスパラメータ例６６は、JSON形式やXML形式で記載され、または数字を含む文字列または単語によって記載されていることが多い。ここで数字を含む文字列または単語とは、例えば“id=1234”などをいう。ここで“1234”という数字はあくまで例であり、APIの利用目的を知るためには不要な要素である。よって、中括弧｛｝や山括弧＜＞で括られたJSON形式やXML形式を判定して削除し、数字を含む文字列または単語を判定して削除することにより、リクエストパラメータ例６５やレスポンスパラメータ例６６を削除することができる。
【００４７】
図４は、ドキュメント加工処理と類似度算出処理を示すフローチャートであり、適宜図２などを参照して説明する。
ユーザが入力したAPI文書６を受付部５７が受け付けると、図４に示す処理が開始する。受付部５７は、API文書６における文章全体と、これにリクエストパラメータ６３やレスポンスパラメータ６４を有する文章の２種類を受け付けることができる。ユーザは、個々に一つずつのAPIを入力してもよく、或るAPI群をまとめて入力してもよい。
【００４８】
API文書６には、API説明６２とリクエストパラメータ６３とレスポンスパラメータ６４に加え、リクエストパラメータ例６５とレスポンスパラメータ例６６も記載されている。加工部５８は、入力されたAPI文書６のうちリクエストパラメータ例６５とレスポンスパラメータ例６６に係る記載を削除する（ステップＳ１０）。これにより、類似度算出部５９の処理におけるノイズを除去することができる。
類似度算出部５９は、教師データ保有部５６に基づき、API文書６の文章を補正する（ステップＳ１１）。具体的に言うと、類似度算出部５９は、入力されたサービスXのAPIドキュメントと、比較先となるサービスAのAPIドキュメント群の単語の置換により、類義語を正規化する。このように教師データ保有部５６の情報を活用することで、サービス毎に異なる固有の表現の差分を吸収し、API選定の精度を高めることができる。
【００４９】
次いで類似度算出部５９は、API文書６やAPI仕様７の文章を単語に分解し（ステップＳ１２）、このドキュメント特有の単語に対し重み付けを行う（ステップＳ１３）。これにより、APIドキュメントの内容を正確に表すことができる。類似度算出部５９は、単語ごとの出現数を要素に文章ベクトルを生成し（ステップＳ１４）、ベクトルの大きさ・向きの差を類似度として扱う。
【００５０】
類似度算出部５９は、入力されたAPI文書６が複数のAPI群に係るものならば（ステップＳ１５→Ｙｅｓ）、全体の類似度を最大化するマッチングペアを生成して第一候補に位置づけ（ステップＳ１６）、類似度上位のAPI群を第二候補〜第Ｎ候補として（ステップＳ１７）、マッチングペアの候補群を不図示の表示装置などに表示する（ステップＳ１８）。類似度算出部５９は、これら候補群の正誤判定結果の入力を受け付け（ステップＳ１９）、正誤判定結果部５５に格納する（ステップＳ２３）。
【００５１】
類似度算出部５９は、入力されたAPI文書６が単一のAPIに係るものならば（ステップＳ１５→Ｎｏ）、類似度上位のAPIを第一候補〜第Ｎ候補として（ステップＳ２０）、APIの候補群を不図示の表示装置などに表示する（ステップＳ２１）。類似度算出部５９は、これら候補群の正誤判定結果の入力を受け付け（ステップＳ２２）、正誤判定結果部５５に格納する（ステップＳ２３）。この正誤判定結果部５５に格納された結果に基づき、新たな教師データを生成して類似度算出部５９の算出精度を向上させることができる。
本実施形態によれば、API変換シナリオ４７の新規作成工数や、API仕様の更新に伴うAPI変換シナリオ４７のアップデート工数を軽減することができる。更に共通APIに準拠しない新サービスの参入が容易となる。
【００５２】
（変形例）
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ），（ｂ）のようなものがある。
（ａ）  類似度算出部５９の処理は、図４のフローチャートに限定されない。類似度算出部５９は、例えば、共通化したいAPI_Aに係る仕様情報を予め単語に分解してもよく、業界特有用語集５６１によって予め正規化してもよい。
（ｂ）  本発明は、既存サービスを利用しているネットワーク事業者システムのAPIを共通化することに限られない。上記実施形態とは逆に、既存のサービスを提供しているサービス事業者システムのAPIを共通化APIに変換し、共通化APIによるサービスを享受するネットワーク事業者システムに提供してもよい。
【符号の説明】
【００５３】
１，１ａ，１ｂ  サービス事業者システム
２，２ａ，２ｂ  ネットワーク事業者システム
２ｃ  クラウド事業者システム
４  メディエータ
４５  API変換部
４７  API変換シナリオ
５  推薦装置  （類似文書推薦システム）
５１  APIドキュメント入力部  （入力部）
５２  APIマッチング部
５３  API情報保有部  （保有部）
５４  API推薦部  （推薦部）
５５  正誤判定結果部
５６  教師データ保有部
５６１  業界特有用語集
５７  受付部
５８  加工部
５９  類似度算出部
６  API文書
７  API仕様
【図１】
2017142640.tif 000003
【図２】
2017142640.tif 000004
【図３】
2017142640.tif 000005
【図４】
2017142640.tif 000006
【図５】
2017142640.tif 000007
【図６】
2017142640.tif 000008