拓海先生、最近、部下から「APIをうまく選べば開発が早くなる」と言われまして、でもAPIが山ほどあって何を基準に選んだらいいのか見当もつきません。これって要するに誰かに選んでもらう仕組みがあればいいということですか？
素晴らしい着眼点ですね！その通りです。今回の論文は、プロジェクトの“プロフィール”を入れると、そのプロジェクトに合ったWeb API (Web API) — ウェブ上で提供される機能群を呼び出す仕組み — を優先順位付きで返す仕組みを提案していますよ。
なるほど。で、その返し方が普通の検索とどう違うのですか。検索はキーワードで出てくるだけでしょう？
良い質問です。ここの仕組みはPersonalized Ranking (PR) — パーソナライズドランキング — を使って、単なるキーワードの一致ではなく、過去のプロジェクトがどのAPIを実際に使ったかの履歴を学習して、あなたの新しいプロジェクトに合うAPIを順位付けしますよ。
過去の履歴を学ぶというのは現場でもよく聞きますが、具体的にどうやって「このAPIは合っている」と判断するのですか？投資対効果の観点で知りたいのですが。
大丈夫、一緒にやれば必ずできますよ。要点は3つです。第一に、プロジェクトを表す特徴量であるfeature vector (FV) — フィーチャベクトル — を作ります。第二に、APIごとの特徴量も作り、それらを組み合わせて「使われたAPI」と「使われなかったAPI」を比較して学びます。第三に、新規プロジェクトでは学習済みモデルで各APIの関連度スコアを出し、高い順に提示します。
これって要するに、過去の実績データを元に「この案件にはこれが合う」と順位を付けてくれるレコメンドシステムということですか？
その理解で合っていますよ。特に面白いのは、単純な人気順とは違い、各プロジェクトに合わせて順位が変わる点です。これは経営判断で言えば、汎用的に人気なものを採るのではなく、自社案件に最適な候補を優先するという発想に近いんですよ。
導入のコストと効果が気になります。学習には大量のデータが必要でしょうし、それを集めるのも手間です。現場のデータや外部の公開データで間に合いますか。
良い視点です。ここでも要点は3つです。第一に、外部の公開データセット（例えばProgrammableWebのようなAPIカタログ）を初期学習に使えること。第二に、自社の履歴を結び付ければ推薦の精度がさらに上がること。第三に、最初は半自動で候補リストを出し、エンジニアが最終決定する運用にすれば投資対効果を抑えられますよ。
分かりました。では最後にまとめます。要するに、新しいプロジェクトの特徴を入れると、過去の使用実績を学習したモデルがそのプロジェクト向けにAPIを順位付けしてくれて、最初は人間がチェックすればコストを抑えつつ効果を出せる、ということですね。私の理解で合っていますか？
その通りです。素晴らしい整理ですね。大丈夫、一緒にステップを踏めば必ずできますよ。まずは小さなプロジェクト一件で試してみましょう。
分かりました。自分の言葉で言うと、「過去の実績を学んで、自分の案件に最も合うAPIを上位に出してくれる仕組みを、まずは小さく試しに入れて、効果が出れば本格導入する」ということですね。では、お願いできますか。
