あなたの知らない非公式・非公認APIの世界
こんにちは。@maekawawawaさんに続く「Web API Advent Calendar 2021」20日目の話題は「非公式・非公認API」についてです。
書いてる人は波多野です。よろしくお願いします。（てゆうか@maekawawawaさんの次の日になってるの書き出してから気づきました。なんかうれしい。）
さて、今回のテーマ「非公式・非公認API」は、メーカーから公式に公開や利用を許可されていない（もしくはそもそもメーカーが存在を認識していない）APIのことを指しています。（面倒なので以下「非公式」で統一します。）
APIを備えたサービス提供に関わる立場としては、正直非公式APIには「トラブルの種となりうるちょっと危ない存在」というイメージがあります。
しかし「非公式APIがなぜ生まれてしまうのか？」という問いはAPIの本質を考える上の材料として興味深いと思い、調べてみる事にしました。
非公式APIの3つのタイプ
非公式APIについて調べるのは（非公式だけに）なかなかソースが少ないんですが、GitHub上で公開されている非公式APIの一覧をまとめているリポジトリがありましたので、この辺りを参考にします。
これらの非公式APIをざっと眺めてみると、非公式APIの提供目的は大きく3つのタイプに分類できそうなので、以下にそれぞれの性質をご紹介していきます。
1. データソースを提供するタイプ
例：Fortnite-API, PokeAPIなど
このタイプの非公式APIは、ニーズの高いデータを簡単に利用できるようにするためのデータソースを提供する目的で作られるものです。
例えば、PokeAPIは広範囲のポケモンに関するデータを有志の方が高いモチベーションでもって意見を出し合い、作り上げたデータベースを継続的にメンテしAPIとして提供しています。
Fortnite-APIはフォートナイトのゲームファイルから直接データを取得して、ゲーム内アイテムやアセットの情報をGETメソッドしか無い参照系APIとして提供しているようです。
問題点
このタイプの非公式APIの問題は、元となるデータの著作権によるものが主となりそうです。
PokeAPIの場合は有志が（恐らく何らかの方法でポケモンのゲームを観察して）集めてきたデータが元になっており、データそのものに画像等メーカーの著作物が含まれない限り、著作権が問題になる危険性は低いと思われます。
※ただこのようなコンテンツもサービス規約で「ユーザー貢献物」「ファンコンテンツ」として定義されていたりするので、メーカーの規約はしっかり確認した方が良いでしょう。
一方、Fortnite-APIの場合はゲームファイルから直接データを取得してAPI公開を行っており、これをEpic Gamesの著作物の再配布と考えるとPokeAPIより規約上の問題が発生しやすいコンテンツ作成方法と言えます。
メーカーの対応
上記のFortnite-APIが実際どうなのかは置いておくとして、著作権や利用規約的にグレーなものを取り扱う非公式APIは恐らく数多く存在すると思います。
メーカーとしてはこれをどう扱うかは迷うところですが、データソース系APIは本質的にはファンの作った情報サイトと同じコンテンツの一種で、恐らくそれだけでメーカーや利用者に大きな迷惑をかけることは少ないはずです。
APIを作るような人は熱心なファンであることが多く、またAPIはファンコンテンツ作成の手助けになるツールでもあるので、状況をウォッチしながら、もし明らかな問題が出てくれば対処する、としているメーカーが多いのではないかと思われます。
2.APIリファレンスを提供するタイプ
例：Tesla API等
@sugimomotoさんの記事「Tesla API の検証環境（物理）が手に入ったので、改めて Tesla API の使い方を解説してみる」で紹介されていた「Tesla API」は、APIリファレンスの提供を目的としたAPIです。
こちらは@sugimomotoさんも書かれている通り、公式なTeslaアプリからAPIリクエストをキャプチャして、リバースエンジニアリングし、本来は公開されていないAPI仕様を非公式に書き起こしたものとなります。
この手の非公式APIリファレンスには、他にもiOSのnintendo switchアプリを解析したものや、FedexのShip Managerを解析したもの等がありました。
問題点
まず、気になるのはリバースエンジニアリングですが、リバースエンジニアリングを行うこと自体は違法とはされてはいませんので、技術的な興味や研究の目的で非公式のAPI仕様書を作成することは違法行為にあたりません。
しかし、サービスの利用規約にリバースエンジニアリングの禁止が盛り込まれている場合も多いため、この行為が「規約違反」になるケースも多いと考えられます。
また、利用者にとっては、非公式APIに不具合があっても当然ながら公式のサポートは受けられませんし、メーカーの意向によって通達なく突然仕様が変更される・APIが廃止されるというリスクがあります。
※実際、メーカーの意向により非公式APIが廃止された例も、以下の通りたくさん見つけることができます、
メーカーの対応
このタイプの非公式APIは、前述の規約違反などの問題以外にメーカーに次のような問題をもたらします。
通常の操作ではあり得ない頻度・手順でのAPIアクセスが発生する事でサービス負荷が高まる。
想定外の処理で作成されたデータに関する不具合が公式サポートに持ち込まれる等で、問題の原因追究が困難になる。
想定外の処理で作成されたデータに対して、表示層が対応できていないなどのケースで不具合につながる可能性がある。
もちろん、非公式な方法であってもWebから利用できるAPI機能が存在する時点で、メーカーとしてはアクセスされても大丈夫なように対策を行っておくべきです。
しかし負荷の高いリソースに想定外の負荷がかかるといった問題は、単純な対策で解決できるとは限りませんので、直接的に利用者の迷惑につながる状況が発生しうる場合は、対象のAPIへのアクセスを禁止する、という判断になることも致し方ないと思います。
3.公式APIの使い勝手を良くするタイプ
例：jwiki,discode.jsなど
公式のAPIを自分がよく使用する言語で使いやすいようにラッピングしたり、公式のAPIのインターフェースが気に入らないので使いやすくするといった目的で作られます。
jwikiはWikipedia/MediaWikiへのアクセスをJavaで簡単に行えるようにするライブラリです。README見てると標準APIのつらみが伝わってきますねw
discode.jsも、discodeのRESTAPIをラッピングしてnode.jsから呼び出せるようにしたものです。
問題点
公式APIを使う際にも自分達が使いやすくなるように処理をラッピングすることはよくあると思いますので、それをライブラリとして公開する事は他の多くのAPI利用者にとってメリットとなり得ます。
しかし、公式APIを使ってサービスのクローンを作成されてしまうリスク等を考慮して、メーカーがAPIを用いた2次制作物の作成・配布を禁じている場合がありますので、公式APIをラッピングしたライブラリの配布が規約違反となっていないかについては、確認が必要になると思われます。
メーカーの対応
前述のように、公式APIを元にしてサービス「そのもの」のクローンが作成されてしまうのはメーカーとしてはリスクになりますので、何らかの形で規約上の縛りはかけておきたいところです。
しかしそれによって、公式APIを様々な環境で使いやすくするためのツールが生まれなくなってしまうと、ディベロッパーコミュニティの活性化に寄与する大きな要素を排除する事になってしまいますので、これは勿体無いですね。
そのため、規約を適切に整備してメーカーとしてのリスクを抑えながら、善意の開発者が力を発揮できるような仕組みを作っていく事が重要になると思います。
非公式APIはなぜ生まれる？
以上、非公式APIを調べて3つのタイプに分類してみました。
非公式だけに問題になる部分もありますが、いろいろな非公式APIを見て感じたのは、非公式APIが生まれるのは「サービスやサービスの情報を便利に使いたいから」だという事です。
このサービスへの熱量や想い自体はメーカーにとっても嬉しく、予想もつかない利用シーンやサービスの広がりを生み出してくれる種でもあるので、大事にすべきだと思います。
その一方、予想もつかない使い方や操作の広がりは想定外のサービス負荷を生み出し、多くの利用者の迷惑となる可能性もあります。
そのためメーカーは規約などで適切にリスクコントロールを行いながら、状況をウォッチし、必要に応じてアクセスを停止するといった措置を行うことも必要だと感じました。
とまあ、すっきりまとめてみましたが非公式APIを作るのは技術者なんで、実際には「やってみたらできたから公開してみた」とか、シンプルな動機も多いんだろうなとも思いますけどw
それはそれで、なんというか・・・いいですよね。
（規約とかは守らないと、だけど）
ということで、普段あまり触れることのない、WebAPIの奥深さに触れられた楽しい調査でした。