インターネット上のサービスについて調べていると、「API」という言葉によく出会います。
「APIを使って情報を取得する」「外部サービスとAPI連携する」「この機能はAPIで提供されている」といった具合です。何かと何かをつなぐものらしい、ということまでは分かっても、実際に何が起きているのかは、なかなか想像しにくい言葉です。
APIは「Application Programming Interface」の略です。日本語にしても、「アプリケーション・プログラミング・インターフェース」となるだけで、あまり分かりやすくはなりません。
よく使われるのは、「ソフトウェア同士をつなぐ窓口」という説明です。これは間違いではありません。ただ、「ソフトウェア同士がつながる」とは、そもそもどういうことなのでしょうか。
天気予報アプリは、自分で天気を観測しているのか
スマートフォンの天気予報アプリを開くと、現在の気温や明日の天気、降水確率などが表示されます。
では、そのアプリを作った会社は、自ら全国に観測機器を置いて、気温や風速を測っているのでしょうか。必ずしもそうではありません。天気に関するデータを持っている別の会社や機関から情報を受け取り、利用者に見やすい画面を作っていることがあります。
人間同士なら、電話をかけて尋ねることもできます。
「明日の東京の天気を教えてください」「午前は曇り、午後は雨です。最高気温は25度です」
しかし、天気予報アプリは、利用者が画面を開くたびに誰かへ電話をしているわけではありません。アプリというプログラムが、天気データを持つ別のプログラムへ、自動的に問い合わせています。
その際には、たとえば次のような情報を送ります。
- 調べたい場所：東京都
- 調べたい日：明日
- 欲しい情報：天気、最高気温、降水確率
すると、相手から次のような結果が返ってきます。
- 天気：雨
- 最高気温：25度
- 降水確率：70％
天気予報アプリは、返ってきた情報を受け取り、天気のマークを付けたり、文字の大きさを整えたりして、私たちが見る画面に表示します。
このときに必要になるのが、「どこに問い合わせるのか」「どんな項目を送るのか」「結果はどのような形で返ってくるのか」という取り決めです。この取り決めに従って、プログラムが別のプログラムへ仕事を頼むための接点がAPIです。
APIには「依頼」「返事」「ルール」がある
APIのイメージをつかむには、三つの要素に分けて考えると分かりやすくなります。
一つ目は、依頼です。「この地域の天気を教えてほしい」「この住所の地図を表示したい」「この荷物が今どこにあるか知りたい」といった、相手にしてほしい仕事を伝えます。コンピューターの世界では、この依頼を「リクエスト」と呼びます。
二つ目は、返事です。依頼を受けた側は、天気や地図、配送状況などの結果を返します。こちらは「レスポンス」と呼ばれます。
三つ目は、依頼と返事のルールです。場所の名前をどう書くのか、日付をどの順番で書くのか、結果をどのような形で返すのかが、あらかじめ決められています。
人間なら、「あした」「明日」「翌日」という表現を、前後の文脈から同じ意味だと理解できます。しかし、プログラム同士のやり取りでは、曖昧な表現は困ります。「日付は西暦、月、日の順で書く」「地域は決められた番号で指定する」といった約束が必要です。
APIは、よく「窓口」に例えられます。ただし、何を頼んでも受付の人が気を利かせてくれる窓口ではありません。決められた申込書に、決められた書き方で記入すると、決められた形式で結果を渡してくれる窓口です。
私たちが見る画面と、APIは別の入口
天気情報を調べたい人は、通常、天気予報のWebサイトやアプリを開きます。場所を入力し、ボタンを押せば、結果が読みやすい画面で表示されます。これは、人間が利用するための入口です。
一方、別のアプリが天気情報を必要とするとき、人間向けの画面を開いて文字を読んだり、表示された数字を書き写したりするのは不便です。そこで、プログラムが直接利用できる入口としてAPIが用意されます。
同じ情報を提供するサービスに、二つの入口があると考えることができます。
- Webサイトやアプリの画面：人間のための入口
- API：プログラムのための入口
人間向けの入口では、色、文字、ボタン、画像などの見やすさが大切です。プログラム向けの入口では、情報が毎回同じ規則で並び、機械が間違えずに読み取れることが大切です。
API自体は、通常、私たちが直接目にする画面ではありません。だからこそ、普段インターネットを使っていても、その存在を意識しにくいのです。
APIを使えば地図を一から作らなくてもよい
飲食店のWebサイトを開くと、店の所在地が地図で表示されることがあります。
その店が、道路や建物の情報を集め、世界中の地図を自分で作ったわけではありません。地図を提供するサービスのAPIを利用し、「この住所を中心にした地図を表示してください」と依頼している場合があります。
店のサイトを作る人が用意するのは、住所や地図を置く場所です。道路の情報、地図の拡大や縮小、表示する範囲の計算などは、地図を専門に扱うサービスが担当します。
APIがなければ、地図を表示したい会社は、自分で地図を作るか、地図サービスの画面へ利用者を移動させる必要があります。APIがあれば、地図の機能を自分のサイトの一部として組み込めます。
このようにAPIは、別のサービスが持つ情報や機能を、自分のサービスの中で利用するためにも使われています。
買い物の裏側でも、複数のサービスが動いている
オンラインショップで商品を注文する場面も考えてみましょう。
私たちから見ると、一つのサイトの中で買い物が完了しているように見えます。しかし、その裏側では、いくつもの異なる仕組みが関わっていることがあります。
クレジットカードで支払うとき、オンラインショップは決済を扱う会社の仕組みに必要な情報を送り、支払いが認められたかどうかを受け取ります。商品が発送された後は、配送会社の仕組みに荷物の番号を送り、現在の配送状況を受け取ります。在庫管理を別の会社のサービスで行っていれば、注文が入ったことをそのサービスへ伝える必要もあります。
利用者には一つの注文に見えても、裏側では次のような依頼と返事が交わされています。
- 決済サービスに、支払いを処理できるか確認する
- 在庫管理サービスに、商品が売れたことを伝える
- 配送サービスに、荷物の発送を依頼する
- 配送サービスから、荷物の現在地を受け取る
これらの仕組みがAPIによってつながっていれば、担当者がそれぞれのサービスへ同じ情報を手で入力し直さなくても、処理を自動的に進められます。
「API連携」とは、多くの場合、このように、あるサービスで起きたことを別のサービスへ伝えたり、別のサービスが持つ情報や機能を呼び出したりできるようにすることです。
「別のアカウントでログイン」にもAPIが関わる
初めて訪れたサービスで、「Googleでログイン」「Appleでサインイン」といったボタンを見たことがある人も多いでしょう。
この場合、新しいサービスにGoogleやAppleのパスワードを直接渡しているわけではありません。GoogleやAppleの側で本人確認を行い、「この人は本人として確認できました」という結果や、許可された範囲の情報を、新しいサービスへ伝えます。
ここでも、サービス同士が決められた方法で情報を受け渡しています。
重要なのは、APIでつながったからといって、相手が持つ情報を何でも自由に見られるわけではない、ということです。どの機能を使えるか、どの情報を受け取れるかは、APIの提供側が決めます。利用者に「氏名の提供を許可しますか」などと確認が表示されるのも、渡す情報の範囲を管理するためです。
APIは、コンセントや差し込み口に少し似ている
「インターフェース」という言葉には、異なるものが接する境界、という意味があります。
身近な例では、コンセントが一種のインターフェースです。私たちは発電所や送電設備の内部を知らなくても、決められた形のプラグをコンセントに差せば、電気を利用できます。ただし、形や電圧が合わなければ使えません。
USBの差し込み口も似ています。機器の内部構造が違っていても、共通の規格に対応していれば接続できます。
APIも、ソフトウェアの内部をすべて知らなくても、決められた接続方法に従えば機能を利用できるようにします。天気予報の計算方法や、地図データの保存方法、決済会社の内部処理を知らなくても、用意されたAPIのルールを守れば結果を受け取れます。
ただし、APIは物理的な穴や端子ではありません。プログラム同士が情報を送受信するための、目に見えない接続方法です。
APIを使うには「説明書」が必要になる
新しい家電を使うときに説明書を読むように、APIを利用するプログラムを作るときにも説明書が必要です。一般に「APIドキュメント」と呼ばれます。
そこには、たとえば次のようなことが書かれています。
- どこへ依頼を送るのか
- どのような仕事を頼めるのか
- 必要な情報は何か
- 情報をどの形式で書くのか
- どのような結果が返ってくるのか
- 依頼に失敗したとき、どのような知らせが返るのか
- 何回まで利用できるのか
- 利用料金はいくらか
APIを使う開発者は、この説明書を読んで、決められたとおりに依頼を送るプログラムを作ります。
技術者が「このサービスはAPIが使いやすい」と言うときは、単に機能が優れているだけでなく、説明書が分かりやすい、依頼や返事の形式が一貫している、失敗した理由を確認しやすい、といった点を含んでいることがあります。
APIキーは、窓口を利用する人の識別票
誰でも、好きなだけAPIを利用できるとは限りません。多くのAPIでは、「APIキー」と呼ばれる文字列が発行されます。
APIキーは、その依頼が誰から送られてきたのかを見分けるための識別票のようなものです。提供会社はAPIキーをもとに、利用回数を数えたり、料金を計算したり、認められていない利用を止めたりします。
映画館の入場券に少し似ています。入口がどこにあるかを知っていても、入場券を持っていなければ中には入れません。また、一般席の券で特別席には入れないように、契約内容によって利用できる機能が異なることもあります。
APIキーが他人に知られると、自分になりすましてAPIを使われ、料金が発生する可能性があります。そのため、パスワードと同じように、他人へ公開してはいけません。
なお、一般の利用者がWebサイトやアプリを使うだけなら、APIキーを自分で用意することは通常ありません。サービスを作る会社や開発者が、裏側で管理しています。
APIにも混雑や故障がある
APIは、呼び出せば必ず即座に答えが返ってくる魔法の仕組みではありません。
短い時間に大量の依頼が集中すれば、返事が遅れたり、一時的に利用できなくなったりします。依頼の書き方が間違っていれば、「必要な項目がありません」「指定された場所が見つかりません」といったエラーが返ります。利用回数の上限を超えれば、それ以上の依頼を断られることもあります。
また、利用しているAPIの内容が変更されたり、提供そのものが終了したりすれば、それを組み込んだサービスも修正を迫られます。地図のAPIで障害が起きた結果、さまざまなWebサイトで一斉に地図が表示されなくなる、といったことも起こり得ます。
外部のAPIを利用することは、便利な機能を一から作らなくてよい反面、その提供元にも頼るということです。料金の変更、利用条件の変更、障害、サービス終了などの影響を受けます。
なぜ自分たちですべて作らずにAPIを使うのか
それでも多くのサービスがAPIを利用するのは、一つの会社がすべてを作るより、それぞれの得意分野を組み合わせたほうが合理的だからです。
オンラインショップを作りたい会社が、世界中の地図を整備し、決済網を築き、配送網まで持つ必要はありません。地図は地図の専門家、決済は決済の専門家、配送は配送の専門家が担当し、必要な機能をAPIとして提供します。
APIを利用する側は、すでに存在する機能を組み合わせながら、自分たちにしか作れない部分へ力を注げます。提供する側も、自社の機能をさまざまなサービスで使ってもらえます。
現在のデジタルサービスは、巨大な一枚岩というより、多くの会社が提供する部品を組み合わせてできていることがあります。APIは、その部品同士を接続するための共通の約束です。
APIとは、異なるものの間にある約束である
APIという言葉が分かりにくいのは、それ自体が目に見える製品ではないからかもしれません。地図のように眺めることも、アプリのようにアイコンを押して開くこともできません。多くの場合、私たちが画面を操作した後、その裏側で働いています。
一言で表すなら、APIとは「あるプログラムが、別のプログラムに仕事を頼むための約束事と、その受付口」です。
何を頼めるのか。どこへ依頼するのか。どのような形で情報を渡すのか。結果はどのような形で返ってくるのか。利用できる回数や権限はどうなっているのか。こうしたことがあらかじめ決められているから、別々の会社が作ったプログラムでも一緒に働けます。
天気を表示する。地図を埋め込む。支払いを処理する。荷物を追跡する。別のアカウントでログインする。私たちが一つの画面の中で自然に使っている機能も、その裏側では複数のサービスがAPIを通じて役割を分担しているかもしれません。
次にAPIという言葉を見かけたら、片方が決められた注文票を送り、もう片方が決められた形式で返事をする様子を思い浮かべてみると良いのではないでしょうか。