APIとは
API（Application Programming Interface）は、外部から所定の手順で呼び出せるようにしたシステムの窓口です。広い意味ではソフトウェアの内部で機能同士を呼び出す口もAPIと呼びます。ビジネスの場で話題になるのは多くがインターネット経由で呼び出すAPIで、これをWeb APIと呼びます。
飲食店でたとえると客が厨房に入らず、所定の注文票で料理を注文する仕組みに近いです。注文票の書き方さえ守れば厨房の中がどうなっているかを知らなくても料理が届きます。
経理システムによる銀行の入出金明細の自動取り込み、EC（Electronic Commerce）サイトから配送会社への出荷依頼、自社サイトへの地図の表示などが代表例です。こうした連携の多くはAPIを通じて行われています。
なぜ必要か
APIがなければシステムの外へデータを取り出す方法は2つしかありません。人が画面を見て転記するか、CSV（Comma-Separated Values）などのファイルに書き出して別のシステムに取り込むかです。画面の表示をプログラムで読み取る方法もありますが、画面の見た目が変更されるたびに動作しなくなります。
銀行と家計簿アプリの連携がよい例です。以前は利用者が銀行のログインIDとパスワードをアプリ事業者に預け、事業者はその情報で銀行の画面にログインして明細を読み取っていました。利用者は認証情報を他社へ渡すことになり、事業者は銀行の画面が変更されるたびに改修が必要でした。2017年に成立し2018年に施行された改正銀行法により、銀行には外部の事業者がAPIを通じて接続できる体制を整える努力義務が課されました。その後はIDとパスワードを預けずに必要なデータだけをAPIで受け渡す方式への移行が進みました。
効果
- 手入力や画面からの転記が不要になり、転記ミスと作業時間が減少する
- 実装によっては数分以内にデータが反映され、在庫や入金の確認待ちが減少する
- 自社で開発しなくても、決済・地図・認証・生成AIなどの機能を外部から借りて利用できる
- 自社のデータや機能をAPIで提供すると、取引先や他社サービスがそれを組み込める
コストとリスク
- 連携ごとに開発費がかかる。相手のAPIで取得できる項目と自社が必要とする項目が一致しないと、項目を変換する処理の開発が増える。受注データは取得できても配送指定の備考欄は取得できない、といった不一致は珍しくない
- 相手側の仕様変更や旧バージョンのAPIの提供終了に合わせた改修が導入後も続く
- 相手のAPIには呼び出し回数の上限や従量課金がある。件数が増えると同期が遅延したり、費用を予測しにくくなったりする
- APIを呼び出すためのキーやトークンの管理に不備があると、連携先のデータが外部に漏洩する
- 連携の停止を検知する監視と、復旧できる担当者が必要になる
- 事業の中核を外部のAPIに依存すると、料金改定や提供条件の変更を自社では阻止できない。2023年には旧Twitter、現在のXが無料で使えたデータ取得のAPIを月額課金制に切り替え、無料で読み取っていたサービスは有料プランへの移行か連携の中止かの選択を迫られた
- 自社がAPIを提供する側になると、仕様書の整備・問合せ対応・互換性の維持という運用が新たに発生する
よくある誤解
APIがあればすぐにつながる
APIは窓口があるという意味にすぎません。つなぐには項目の対応づけ・認証・エラー時の処理を実装する開発が必要です。
一度つないでしまえばあとは放っておける
相手の仕様変更や障害で連携は停止します。停止を検知する仕組みを用意し、保守の担当を決めておく必要があります。
APIを公開すれば他社が使ってくれる
利用してもらうには、仕様書・試用環境・問合せ窓口・変更の事前告知まで含めた運用が必要です。公開しただけでは利用されません。
