アプリケーションプログラミングインタフェース （API 英 :application programming interface ）[ 注釈 1] ソフトウェアコンポーネント 同士が情報をやりとりするインタフェース の仕様である。
APIには、サブルーチン 、データ構造 、オブジェクトクラス 、変数などの仕様が含まれる。APIには様々な形態があり、POSIX のような国際標準規格、マイクロソフト のWindows API のようなベンダーによる文書、プログラミング言語 の標準ライブラリ （例えば、C++ のStandard Template Library やJava API （英語版 ）
商業的に使われる狭義では、各種システムやサービス（ハードウェア、OS 、ミドルウェア およびWebサービス等）を利用するアプリケーションソフトウェア (Application) を開発・プログラミング (Programming) するためのインタフェース (Interface) である[ 1] [ 2] [ 3] [ 4] [ 5]
APIはアプリケーションバイナリインタフェース (ABI) とは異なる。APIはソースコード ベースだが、ABIはバイナリインタフェースである。例えば、POSIXはAPIだが、Linux Standard Base (LSB) はABIである[ 6]
広義のAPIでは単なるライブラリのインタフェースを含むかどうかにばらつきがあるなど定義が曖昧であるため、ここでは狭義のAPIについて説明する。
前述のとおりAPIは各種システム／サービスがそのシステム／サービスを利用するアプリケーションに対して公開するインタフェースである。APIの重要な役割は、システム／サービス提供者が公式に仕様（外部仕様 ）を定義し、管理している各種機能を利用するための操作方法（インタフェース）を提供することである。APIは多くの場合、アプリケーションを構築する言語と同じ言語のライブラリ、あるいは通信プロトコル形式[ 注釈 2]
アプリケーションがシステム／サービスを利用するには、APIを無視してシステム／サービスの現在の実装 および内部仕様 に依存した方法がある。人と同じ操作をアプリケーションにさせたり、たまたま設定が書き込まれていたファイルをアプリケーションで読み取るなどである。この手法を非API[ 7] [ 8] [ 9] [ 10] 互換性 を維持してくれるため、アプリケーション側の変更は必要ない(ただし頻繁ではないが提供者により互換性がなくなる場合もある)。アプリケーションがシステム／サービスを操作するにあたり、APIにだけ依存することでこのような互換性の問題を避けることができる。
ただし、APIを使う場合、APIの提供者から使用回数などに制限を掛けられる場合があり[ 8]
#（参考情報）ライブラリ形式の非API 、#（参考情報）ライブラリとAPI も参照
APIはソフトウェアライブラリ と対応しているのが一般的である。APIは「期待される挙動」を規定し説明するが、ライブラリはその規則群の「実際の実装」である。1つのAPIが複数の実装を持つこともあるし、実装のない抽象的APIもありうる。
広義のAPIはソフトウェアフレームワーク と対応する場合もある。フレームワークはいくつかのライブラリを備え、いくつかのAPIを実装することもあるが、通常のAPIとは使い方が異なり、「フレームワークに組み込まれた」挙動への「アクセス」としてフレームワーク自身に新たなクラスをプラグインすることでその内容を拡張するという手段をとる。さらに言えば、呼び出し側はプログラムの動作を制御できず、制御の反転 や他の類似の機構によってフレームワーク側が流れを制御する[ 11]
APIはプロトコル の実装となっていることもある。
プロトコル は、共通の転送手段に基づいた要求と応答の標準的交換方法を定義している。一方プロトコルを実装していないAPIは、ライブラリとして実装され、直接使われるのが一般的である。したがってAPIには「転送手段」が関与することはなく（遠隔のマシンとの物理的情報転送を行わない）、「関数呼び出し」によって単純に情報交換し、データは特定の言語で表現された形式で交換される[ 12]
APIがプロトコルの実装である場合、下層にある通信プロトコルを使ってリモート呼び出しを行うためのプロキシ 的手段となっている。その場合のAPIの役目は、プロトコルの詳細を隠蔽することである。例えばJava RMI は、JRMP （英語版 ） RMI-IIOP としてのIIOP を実装している。
プロトコルは一般に異なるテクノロジー（特定OS内の特定プログラミング言語に基づくシステム）間をつなぎ、それらの間での情報交換を可能にしている。一方APIは特定のテクノロジーに固有であり、何らかの変換手段を用いない限り、ある言語用のAPIを別の言語では使用できない。
オブジェクトAPIは具体的なオブジェクト交換フォーマットを規定し、オブジェクト交換プロトコルはメッセージ内の同種の情報をリモートシステムに転送する方法を定義する。
2つの異なるプラットフォーム間で、両者にあるオブジェクトを使ってプロトコル経由でメッセージを交換する場合、あるプログラミング言語内のオブジェクトは相手の異なる言語でのオブジェクトに変換される。例えばJava で書かれたプログラムがC# で書かれたサービスをSOAP やIIOP 経由で呼び出す場合、どちらのプログラムもリモート呼び出し用API（API自体はローカルに存在する）を使って情報交換し、ローカルなメモリ内でオブジェクトの変換を行う。
一方、同一マシン上でAPI経由のオブジェクト交換を行う場合、メモリ内で効率的に（オブジェクトまたはオブジェクトへの参照の）交換が行われる。例えば、1つのプロセスに割り当てられたメモリということもあるし、共有メモリ を使って複数プロセス間で行うこともあるし、タプルスペース のような共有技法を使うこともある。
ウェブAPIはHTTP 要求メッセージ定義とJSON 形式等の応答メッセージ定義で構成される。Web 2.0 ではSOAP ベースからREST ベースへと変化している[ 13] マッシュアップ により複数のサービスを組み合わせて新たなアプリケーションとすることを可能にする[ 14]
APIを公表する慣習により、ウェブコミュニティにはコミュニティ間やアプリケーション間でコンテンツとデータを共有するオープンアーキテクチャが発展していった。そのため、ある場所で作成されたコンテンツはウェブ上の様々な場所で盛んにポストされ更新される。
写真はFlickr やPhotobucket といったサイトからFacebook やMyspace といったソーシャルネットワークサイトに共有される。 コンテンツは埋め込むこともできる。例えば、SlideShare にあるプレゼン資料をLinkedIn のプロファイル情報に埋め込むことができる。 Twitter のつぶやきをFacebook の投稿にも同時に反映させるAPIもある。動画コンテンツも別のホスト上のサイトに埋め込むことができる。 ウェブコミュニティにおけるユーザー情報を外部アプリケーションと共有させることができ、アプリケーションの更新をウェブ側から働きかけるなどの機能もオープンなAPIで実現されている。好例としてFacebookプラットフォーム （英語版 ） OpenSocial プラットフォームがある。 WebAPIは様々なスタイルで表現される。例えばリソースの表現は以下の様式がありうる。
URLパス名:https://API.internal./japan/tokyo/sinjuku URLクエリ文字列:https://API.internal./?country=japan&prefecture=tokyo&city=sinjuku リクエストボディ:POST https://API.internal. Body{country: japan, prefecture: tokyo, city: sinjuku} パスは厳密な階層構造をもつリソースの表現に適している。クエリ文字列およびリクエストボディは自由な表現が可能なため任意のリソースに利用できる。
広く知られるWebAPIスタイルの例として以下が挙げられる。
REST ful API: 操作をHTTPメソッド、リソースをURLパス名で表現GraphQL : 操作およびリソースをリクエストボディ内にDSL (GraphQL query language) で表現SOAP POSIX 標準は、様々な一般的コンピューティング機能を各種システム上で実装できるよう考慮したAPIを定義している。例えば、macOS やBSD 系システムで実装されている。ただし、ABIや実行ファイル形式は標準化されていないため、POSIX準拠のプログラムを別のPOSIX準拠のプラットフォームで実行するには、再コンパイルが必要である。
一方、APIおよびABIに互換性があるシステムならば、どこでも同じバイナリをそのまま実行可能である。これはアプリケーションソフトウェアベンダーにもユーザーにも有益であり、ベンダーは互換API/ABIが実装されていれば新システムが登場してもアプリケーション製品を修正・リビルドせずに済むし、ユーザーも古いソフトウェアを後方互換性のある新システムにインストールして利用できる。ただし、それには一般に各種ライブラリが必要なAPI群を実装している必要がある。
WindowsはAPI/ABIに後方互換性があり、例えばVisual C++ とWindows SDK を使用して開発されたアプリケーションは、ビルド時にWindows APIヘッダーをインクルードする前にWINVERおよび_WIN32_WINNTなどのシンボル[ 15] [ 注釈 3] WINVERおよび_WIN32_WINNTをそのバージョンに合わせて定義するか、LoadLibrary関数を使用して動的ロードする。
なおWindows XP 以降では、特定のバージョンのWindowsの実装や内部仕様に依存するなど、誤った実装や後方互換性を無視した実装により正常に動作しなくなってしまったアプリケーション向けに、「互換モード 」が用意されている。これはシステム側が返す情報を特定バージョンのWindowsのものに偽装することで、アプリケーションをだますことにより動作させる救済措置であり[ 16] [ 17] [ 18]
Unix系 OSでは、相互に関連はあるが非互換なOS群が同一ハードウェア上で動作している。ソフトウェア業者が同一バイナリで各種OSに対応できるようAPIとABIを共通化する試みがなされてきたが、いずれも失敗に終わっている。そのような試みとしてLinux ではLinux Standard Base がある。BSD系OSも各種あるが、互換性のレベルは様々である。
Androidには「APIレベル」という概念が存在し、Android OSのバージョン ごとにAPIレベルの番号が割り振られている。例えばAndroid 10はAPIレベル29に相当する。特定のAPIレベルで追加された機能（クラス、メソッド、フィールド）を利用するには、アプリケーションのビルド時に "AndroidManifest.xml"[ 19] [ 20] targetSdkVersionの値をそのAPIレベル番号以降に設定し、また指定されたバージョン以降のAndroid SDKを使ってビルドする必要がある。また、minSdkVersionの値によって、アプリケーションのインストールおよび実行に必要な最小システムバージョンを指定することができる。minSdkVersion以下の機能は（廃止されたものでない限り）無条件で使用できるが、minSdkVersionを超えるバージョンで追加された機能を使用する場合は、android.os.Build.VERSION クラスのSDK_INTフィールドの値に基づいて動的分岐する処理を実装する必要がある。
ウィキメディア・エンタープライズ API - 米国時間2025年11月10日に、Wikipediaを運営する非営利団体ウィキメディア財団は、AIを扱う企業へAIモデルのトレーニングを目的としたWikipedia等のデータ収集（スクレイピング） をする際に無断で行うのを止めて、ウィキメディア財団の提供する有料APIを利用し、Wikipedia等を出典としたことを示すクレジット表示と財政的支援を求める声明を発表した[ 21] [ 22] [ 23] APIの公開に関しては2つの一般的な方針がある。
自社のAPIを厳重に秘匿する。例えばソニー はライセンス をもった開発者にしかPlayStation の公開APIを利用できないようにしている。なぜならPlayStationのゲームを開発できる人の数を制限したほうが、より多くの利益をあげられるからである。これはAPIの実装を売ることで利益を上げるわけではない会社の典型的な例である。（ソニーの場合は、ゲーム開発時のAPIのライセンス料によって利益を上げようとしたがうまくいかず、PlayStation用コンソール の販売を中止している。） [要出典 自社のAPIを広く普及させる。例えばマイクロソフト は計画的にAPIに関する情報を公開している。誰でも簡単にWindows プラットフォーム 用のソフトウェアを作成することができる。これはAPIの実装を販売して利益をあげる会社の例である。 [要出典 OSなどのAPIは、いくつかのコードに分割され、ライブラリ として実装されており、OSと一緒に配布される。また直接アプリケーションの中に統合される必要があるAPIもある。 この2つの方針の中間もある。
アメリカ国内 2010年 、米オラクル はGoogle がJava の新たな実装をAndroid の一部として配布したとして、Googleを訴えた[ 24] OpenJDK プロジェクトやIBM J9 などの実装には与えられていたが、一方AndroidのDalvik仮想マシン の実装はOpenJDK などに基づいてはおらず、またGoogleはJava APIを複製する許可をとっていなかった。これに対して、地方裁判所はAPIは著作権法の対象外であるとする判断を下したものの、控訴裁では保護対象であるとされ、最終的に2015年 、最高裁 によりアメリカ合衆国内ではAPIにも著作権があるとの判断が確定した[ 25] [ 26] [ 27] 2021年 には著作権があってもフェアユース の下に利用可能であるとの判断が下されている[ 28]
日本国内 日本 においては、著作権法 第10条第3項において、プログラムのインタフェースやプロトコルが著作物とみなされないことが明確に示されている[ 29]
他 互換性のためのAPIを作成するためにそのAPIの実装を解析することは一般的に合法 である。この手法は相互運用性のためのリバースエンジニアリング と呼ばれる。
DDI (Device Driver Interface) -デバイスドライバ を開発するためのソフトウェアインタフェース。WindowsおよびLinuxの用語。 SPI (System Programming Interface) - アプリケーション構築用ではなくシステム制御や拡張用のインターフェース[ 30] [ 31] [ 32] ファームウェアインタフェース -ファームウェア を開発するためのソフトウェアインタフェース。UEFI [ 33] ASPI SCSI 装置を制御するためのソフトウェアインタフェース特にDDIやファームウェアインタフェースを使う場合は、ソフトウェアがアプリケーションと異なる環境で動作しAPIに依存するライブラリを使用できない場合があるため、開発者は自分が何を使っているか意識する必要がある。
複数の高水準言語 での使用を意図したAPIは、文法的・意味的に各言語に適したインタフェースをAPIに自動的にマッピングする機能を提供している。これを言語束縛 と呼び、それ自体もAPIである。その目的は、そのAPIに要求される機能のほとんどをカプセル化 するため、各言語に薄い層を設けることである。
以下に挙げたものは、コンパイル時に言語とAPIの束縛を行うインタフェースジェネレータである。
SWIG - オープンソースの多言語間のインタフェースジェネレータ（通常はC/C++からスクリプト言語へのインタフェースを生成）F2PY:[ 34] Fortran からPython へのインタフェースジェネレータ Microsoft Windows 、macOS 、iOS 、Android などのOSには、API以外に、俗に「隠しAPI」や「プライベートAPI」「非公開API」などと呼ばれるライブラリ形式の非APIが存在する。これらの非APIは特定の共通処理をアプリケーション側ではなくシステム内部でのみ再利用することを想定して実装されており[ 7] DLL にエクスポートされていることから、LoadLibrary 関数を使用して呼び出すことができる。Java や.NET Framework の場合は、カプセル化 を破壊することになるが、隠蔽されたメソッド であってもリフレクション を使用して呼び出すことができる。しかし、これらはシステム／サービス提供者が公式に提供している機能ではなくAPIではない。このためこれらの隠し機能を使ったアプリケーションの動作は保証されないし、互換性も将来に渡って保証されることはない。不具合修正があれば容易に変更あるいは破棄される。例えばWindows API において、timeBeginPeriod() ,timeEndPeriod() はアプリケーション開発者向けに正式公開・ドキュメント化されているAPI関数だが、これらは内部でNtSetTimerResolution()を呼び出している[ 35] NtSetTimerResolution()は、Windows NT系 のシステムDLLのひとつ、"ntdll.dll"にエクスポートされているが、アプリケーション開発者向けのドキュメントには記載されていない非API関数であり[ 36] [ 37] [ 38]
APIは関数 、プロシージャ 、変数 やデータ構造 といったライブラリによって実装されることが多いが、狭義のAPIではライブラリとAPIは同一ではない。ライブラリ形式ではなくプロトコル形式で提供される場合もあるという理由もあるが、ライブラリ形式である場合も同一視せず区別する必要があるという理由がある。
例えばAPIが関数であればサービスにより提供される関数はAPI関数と呼ぶが、API関数を利用して構築された関数はAPIではないためライブラリ関数と呼ぶ。ライブラリ関数は直接サービスと関係ないか、APIを使って構築されておりサービスを利用する上で必須ではない。逆にAPI関数の存在はサービスを利用する上で必須である。例えばC言語 の標準ライブラリ関数であるfwrite は、Windows上ではAPI関数であるWriteFile を使って実装されている。WriteFileはOSの機能に直接アクセスできることからfwriteよりも高機能であり、別OSへの移植性を考えなければfwriteの代わりにWriteFileを直接利用してアプリケーションを記述することもできる。同様に、Linuxではwrite システムコール を利用して実装されている。
APIはサービスを利用するうえで必須になるが、APIを直接使用することは外部サービスに対する依存性を高め移植性を妨げる。例えば前述のWriteFileを使うプログラムは基本的にWindows用にしかコンパイル できないが、fwriteを使うプログラムはフリースタンディング環境 以外ならどの環境でもコンパイルできる。このため移植性を考えるのであればAPIの直接使用は避け、APIを抽象化したライブラリを使用することが望ましい。さらに、後述するように移植性を意識する言語ではライブラリとAPIを厳密に区別している場合が多い。特に後述のSmalltalkはクロスプラットフォーム が一つの長所となっているためAPIの直接使用を避けることは重要となる。
C++ の規格書では、API関数とライブラリ関数は一貫して区別されており、API関数は標準のライブラリ関数から呼び出されるもの、あるいは標準ライブラリの関数が同等の機能を模倣する対象として書かれている[ 39] C の規格書においてはAPIという言葉は無く、相当する関数がライブラリ関数以外の関数として書かれている[ 40] Smalltalk でもAPIとライブラリは区別されており、例えばSmalltalk環境の一種であるPharo はAPIと対応しているパッケージをライブラリとは別にAPIとして区分している[1] 。
なお、標準ライブラリはOSやファームウェア などアプリケーション以外からも使われる。
^ 「インターフェイス」「インターフェース」と表記されることもあるが、本記事では「インタフェース」で統一する。 ^ ローレベルなTCP あるいはUDP のパケット形式であったり、REST やSOAP に代表されるようなHTTP やXML などを組み合わせた上位プロトコルであったりする。 ^ 新しいバージョンのコンパイラおよびWindows SDKでは、ある程度古いバージョンのWindowsのサポートが打ち切られることもある。 ^ https://www.ibm.com/support/knowledgecenter/ja/SS4SVW_2.0.0/com.ibm.zosconnect.doc/backmatter/glossary.html#glossary__api ^ https://developer.mozilla.org/ja/docs/Glossary/API ^ https://web.archive.org/web/20090821010346/http://www.ocn.ne.jp/support/words/abc/API.html ^ https://www.synergy-marketing.co.jp/glossary/api/ ^ Smalltalk環境の提供元Cincomによる見積サービスの説明 APIの解説がある。^ Stoughton, Nick (2005年4月). “Update on Standards ” (PDF). USENIX . 2009年6月4日閲覧。 ^a b “Eclipse プラットフォーム API - 使用規則 ”. www.ibm.com . 2023年5月24日閲覧。 ^a b Liran (2020年7月16日). “8 Best One Product Shopify Store Examples That Will Inspire You ” (英語). Debutify . 2023年5月24日閲覧。 ^ georgiostrantzas (2023年2月28日). “Prerequisites and limitations - Power Automate ” (英語). learn.microsoft.com . 2023年5月24日閲覧。 ^ Geva, Nahar (2023年5月16日). “KalDrop Guide ” (英語). ZIK Analytics . 2023年5月24日閲覧。 ^ Fowler, Martin. “Inversion Of Control ”. 2012年10月18日閲覧。 ^ “API vs Protocol ”. 2012年10月18日閲覧。 ^ Benslimane, Djamal; Schahram Dustdar, and Amit Sheth (2008年). “Services Mashups: The New Generation of Web Applications ”. IEEE Internet Computing, vol. 12, no. 5 . Institute of Electrical and Electronics Engineers. pp. 13–15. 2012年10月18日閲覧。 ^ Niccolai, James (2008-04-23), “So What Is an Enterprise Mashup, Anyway?” , PC World , http://www.pcworld.com/businesscenter/article/145039/so_what_is_an_enterprise_mashup_anyway.html ^ WINVER および _WIN32_WINNT の変更 | Microsoft Docs ^ 121ware.com > サービス＆サポート > Q&A > 情報番号 003142 ^ Windows 7の互換機能を使いこなす（互換モード編） | 日経 xTECH（クロステック） ^ Windows 8.1ミニTips(100) 「プログラム互換性アシスタント」を制御する●つの方法 | マイナビニュース ^ <uses-sdk> | Android Developers ^ ビルドを設定する | Android Developers ^ “AIの「タダ乗り」許さず--Wikipedia、AI企業に無断利用の停止と支払いを要求 ”. CNET Japan (2025年11月11日). 2025年11月11日閲覧。 ^ “Wikipedia運営元、AI企業にAPIを介したデータ使用料支払いを要求 ”. ITmedia NEWS . 2025年11月11日閲覧。 ^ “WikipediaがAI開発者に有料APIの利用を促す - GIGAZINE ”. gigazine.net (2025年11月11日). 2025年11月12日閲覧。 ^ “Oracle and the End of Programming As We Know It ”. DrDobbs (2012年5月1日). 2012年5月2日時点のオリジナル よりアーカイブ。2012年5月9日閲覧。 ^ Josh Lowensohn (2012年5月23日). “Jury clears Google of infringing on Oracle's patents ”. ZDNet . 2012年5月25日閲覧。 ^ Joe Mullin (2012年5月31日). “Google wins crucial API ruling, Oracle’s case decimated ”. Ars Technica . 2012年6月1日閲覧。 ^ “米最高裁がGoogleの訴えを却下、OracleとのJava著作権訴訟で ”. ITPro (2015年6月30日). 2015年7月1日閲覧。 ^ “［速報］10年にわたる著作権訴訟でGoogleがオラクルに勝訴、米連邦最高裁判所で判決。Java SEのコードのコピーはフェアユースの範囲 ”. Publickey (2021年4月6日). 2021年4月7日閲覧。 ^ 松下正. “知的財産権（特許・商標・著作権）の基礎講座 ”. 知的財産権（特許・商標・著作権）の基礎講座. 2015年7月1日閲覧。 ^ “Programming Interface (System Interface Guide) ”. docs.oracle.com . 2024年12月13日閲覧。 ^ “Introduction to system programming commands ” (英語). www.ibm.com . 2024年12月13日閲覧。 ^ “Job scheduler System Programming Interfaces (SPI) ” (英語). www.ibm.com . 2024年12月13日閲覧。 ^ UEFI firmware requirements | Microsoft Docs ^ “F2PY.org ”. F2PY.org. 2011年12月18日閲覧。 ^ Sysinternals Freeware - Inside Windows NT High Resolution Timers ^ NTAPI Undocumented Functions ^ “API エラーおよび警告に関する設定 ”. www.ibm.com . 2023年5月24日閲覧。 ^ “Apple rejects Unity games on the App Store ” (英語). Engadget . 2023年5月24日閲覧。 ^ C++14の規格書の最終草案 ^ C11の規格書の最終草案 
