API とは

API はアプリケーション・プログラミング・インタフェースの略であり、アプリケーション・ソフトウェアを構築および統合するための一連の定義とプロトコルです。

API を使用すると、製品やサービスが他の製品やサービスの実装状況を把握していなくても通信できるようになります。また、アプリケーション開発が単純化されるので、時間とコストを節約できます。新しいツールや製品を設計する場合でも、既存のものを管理する場合でも、API により柔軟性が得られます。設計、管理、使用が単純化されるほか、イノベーションの機会も創出されます。

API は、当事者間の合意を表す文書による契約に例えられることがあります。つまり、一方が特定の方法で構造化されたリモート要求を送信すると、もう一方のソフトウェアは同じ方法で応答します。

API によって開発者が新しいアプリケーション・コンポーネントを既存のアーキテクチャに統合する方法が単純化されるので、ビジネスチームと IT チームのコラボレーションが容易になります。ビジネスのニーズは、絶えず変化するデジタル市場に応じて急速に変わることが多くあります。こうした市場では、新たな競合他社が新しいアプリケーションを投入することで、業界全体を一変させてしまうことさえあります。競争力を維持するには、革新的なサービスの迅速な開発とデプロイメントをサポートすることが重要です。クラウドネイティブ・アプリケーション開発は、開発速度を向上できる明確な手段であり、マイクロサービス・アプリケーション・アーキテクチャを API 経由で接続することに基づいています。

API は、クラウドネイティブ・アプリケーション開発を通じて自社のインフラストラクチャを接続するための単純化された方法ですが、データを顧客や他の外部ユーザーと共有する手段にもなります。パブリック API には、独自のビジネス価値があります。パートナーとの接続方法を単純化し、拡張できるだけでなく、データを収益化できる可能性を秘めているからです。その代表的な例が Google Maps API です。

たとえば、書籍の取次業者を想像してみてください。取次業者は、書店員が取次業者に書籍の有無を確認できるようにするクラウド・アプリケーションを提供できます。このようなアプリケーションは、開発コストが高く、プラットフォームの制限があり、長期間におよぶ開発と継続的なメンテナンスが必要になる場合があります。

取次業者は、別の手段として、在庫確認用の API を提供することもできます。このアプローチにはいくつかのメリットがあります。

• 顧客が API 経由でデータにアクセスできるようにすることで、在庫に関する情報を 1 カ所に集約することができます。
• API の動作が変わらない限り、取次業者は、顧客に影響を与えることなく内部システムを変更できます。
• 公開されている API を使用して、取次業者、書店、またはサードパーティの開発者は、顧客が求めている書籍を検索するためのアプリケーションを開発できます。その結果、売上やその他のビジネス機会が増加する可能性があります。

つまり、API を使用すると、セキュリティと制御を維持しながら、自社リソースへのアクセスを開放することができるのです。アクセスをどのように、誰に公開するかはあなた次第です。API セキュリティの中心は API 管理であり、それには API ゲートウェイの使用も含まれます。API に接続して、API が公開するデータや機能を使用するアプリケーションを作成するには、分散統合プラットフォームを使用します。このプラットフォームによって、レガシーシステムや IoT (モノのインターネット) を含め、あらゆるものが接続されます。

API をパートナーと共有したり一般公開したりすると、次のことが可能になります。

• 新しい収益チャネルの創出や、既存の収益チャネルの拡張
• ブランドリーチの拡大
• 外部開発とコラボレーションを通じた、オープンなイノベーションや効率化の促進

いずれもすばらしいメリットです。でも、API でこれらのメリットがどのようにして得られるのでしょうか。

書籍の取次業者の例に戻りましょう。

取次業者のパートナーが、店頭にある本を探すのに役立つアプリケーションを開発したとします。この改善された方法により、より多くの買い物客が書店 (つまり書籍の取次業者にとっての顧客) に来るようになり、既存の収益チャネルの拡大につながります。

サードパーティがパブリック API を使用して、書店からではなく取次業者から直接書籍を購入できるようにするアプリケーションを開発することも考えられます。これにより、取次業者に新しい収益チャネルが開かれます。

特定のパートナーとであれ、全世界とであれ、API を共有することはプラスの効果をもたらす可能性があります。この連携により、自社のマーケティング活動を超えたブランド認知が実現します。パブリック API のように、テクノロジーを一般に公開することで、開発者はその API を中心にアプリケーションのエコシステムを構築することができます。あなたのテクノロジーを使用する人が増えれば、それだけ多くの人があなたとビジネスをする可能性も高まるのです。

テクノロジーを公開すると、新たな予期せぬ結果へとつながる場合もあります。これらの結果は、時には全産業を揺り動かします。取次業者の例を考えると、たとえば書籍レンタルサービスなどの新会社は、取次業者がビジネスを行う方法を根本的に変える可能性があります。パートナーおよびパブリック API は、社内の開発者よりもずっと規模の大きい外部コミュニティの創造的な取り組みを支援することができます。新しいアイデアはどこから来るかわかりません。企業は市場の変化を認識し、それに対応して行動する必要があります。そのような流れの中で、API が助けとなります。

API はコンピューティングの初期段階、パーソナルコンピュータが登場するよりずっと前に出現しました。当時の API は、オペレーティングシステム用のライブラリとして使用されていました。ほとんどの場合、API はそれが動作するシステムのローカルにありました。時にはメインフレーム間でメッセージを交換することもありました。ほぼ 30 年後、API はローカル環境から切り離されました。2000 年代初頭までに、API はデータのリモート・インテグレーションのための重要なテクノロジーとなっていました。

リモート API は、通信ネットワークを介して対話するように設計されています。リモートとは、API によって操作されるリソースが、要求を行うコンピュータの外部にあることを意味します。最も広く使用されている通信ネットワークはインターネットであるため、ほとんどの API は Web 標準に基づいて設計されています。すべてのリモート API が Web API というわけではありませんが、Web API はリモートであると考えて差し支えないでしょう。

Web API は通常、要求メッセージに HTTP を使用し、応答メッセージの構造の定義を提供します。これらの応答メッセージの形式は、通常 XML または JSON ファイルです。XML と JSON の両方とも他のアプリケーションが操作しやすい方法でデータを提示するため、好まれるフォーマットです。

Web API の普及に伴い、情報交換の標準化を支援するためのプロトコル仕様が開発されました。それが SOAP (Simple Object Access Protocol) です。SOAP で設計された API は、メッセージ・フォーマットに XML を使用し、HTTP または SMTP を介して要求を受信します。SOAP を使用すると、異なる環境で動作しているアプリケーションや異なる言語で書かれたアプリケーションが情報を共有しやすくなります。

もう 1 つの仕様は REST (Representational State Transfer) です。REST アーキテクチャの制約に準拠する Web API は、RESTful API と呼ばれます。REST は SOAP とは根本的に異なります。SOAP はプロトコルですが、REST はアーキテクチャのスタイルです。つまり、RESTful Web API の公式な標準は存在しません。Roy Fielding 氏の論文「Architectural Styles and the Design of Network-based Software Architectures (アーキテクチャ・スタイルとネットワーク・ベースのソフトウェア・アーキテクチャの設計) 」で定義されているように、RESTful システムの 6 つの指針となる制約に準拠する限り、API は RESTful です。

• クライアント・サーバー・アーキテクチャ：REST アーキテクチャは、クライアント、サーバー、リソースで構成され、HTTP を介して要求を処理します。
• ステートレス性：要求と要求の間で、サーバーにクライアントのコンテンツは保存されません。代わりに、セッション状態に関する情報はクライアントが保持します。
• キャッシュ性：キャッシュは、クライアントとサーバー間のやりとりの一部を不要にします。
• 階層化されたシステム：クライアントとサーバー間のやりとりは、追加のレイヤーによって仲介できます。これらのレイヤーにより、ロードバランシング、共有キャッシュ、またはセキュリティなどの追加機能を提供できます。
• オンデマンドのコード (オプション)：サーバーは、実行可能コードを転送することによってクライアントの機能を拡張できます。
• 統一インタフェース：この制約は RESTful API の設計の中核であり、次の 4 つの側面があります。
  • 要求におけるリソース識別：リソースは要求で識別され、クライアントに返される表現とは別です。
  • 表現によるリソース操作：クライアントはリソースを表現するファイルを受け取ります。これらの表現には、修正や削除を可能にするのに十分な情報が含まれている必要があります。
  • 自己記述的メッセージ：クライアントに返される各メッセージには、クライアントが情報をどのように処理すべきかを記述する十分な情報が含まれています。
  • アプリケーション状態のエンジンとしてのハイパーメディア：REST クライアントは、リソースにアクセスした後、REST クライアントは、現在利用可能な他のすべてのアクションをハイパーリンクを通じて見つけられる必要があります。

これらの制約は多く見えるかもしれませんが、規定のプロトコルよりもはるかに簡単です。このため、RESTful API は SOAP よりも普及しています。

先ごろ、REST API を定義する共通規格として OpenAPI 仕様が登場しました。OpenAPI を使用すると、開発者は言語に依存せずに REST API インタフェースを構築できるので、ユーザーが憶測で解釈する必要性が減少します。

もう 1 つの API 標準は、REST の代替となるクエリ言語およびサーバーサイドランタイムである GraphQL です。GraphQL では、クライアントがリクエストしたデータだけを提供することを優先します。GraphQL は REST の代わりに、データを複数のデータソースから取得するリクエストを 1 つの API 呼び出しで構成できます。

SOAP と REST の違いについての詳細を見る

リモート API を最も多用するアーキテクチャアプローチは、サービス指向アーキテクチャ (SOA) とマイクロサービス・アーキテクチャの 2 つです。2 つのアプローチのうち古い方の SOA は、モノリシックなアプリケーションの改善策として始まりました。単一のモノリシック・アプリケーションはすべてを行うのに対し、SOA の一部の機能は別の複数のアプリケーションによって提供されます。そして、それらのアプリケーションはエンタープライズ・サービス・バス (ESB) のような統合パターンによって疎結合されています。

SOA はモノリシック・アーキテクチャよりもシンプルですが、コンポーネントの相互作用を明確に理解していないと、各種の変更が環境全体に連鎖的に波及してしまうリスクがあります。この複雑さゆえに、SOA が解決しようとしている問題のいくつかを逆に招いてしまうことがあります。

マイクロサービス・アーキテクチャは、特殊化したサービスを疎結合するという点で SOA のパターンとよく似ています。しかし、これまでのアーキテクチャをさらに細かく分解しています。マイクロサービス・アーキテクチャ内のサービスは、RESTful API などの共通のメッセージング・フレームワークを使用します。サービス同士は、難しいデータ変換トランザクションや追加の統合レイヤーを使用せずに、RESTful API を使用して互いに通信します。RESTful API を使用すれば、新しい機能やアップデートを短時間で提供できるようになります。それぞれのサービスは独立しています。1 つのサービスの置き換え、拡張、削除がアーキテクチャ内の他のサービスに影響することはありません。このような軽量のアーキテクチャによって、分散型またはクラウドのリソースを最適化し、個々のサービスの動的なスケーラビリティを確保できます。

SOA とは？の詳細を見る

Webhook は HTTP ベースのコールバック機能で、2 つの API 間の軽量なイベント駆動型の通信を可能にします。Webhook はさまざまな Web アプリケーションで使用され、相互のアプリケーションから少量のデータを受信します。また、GitOps 環境で自動化ワークフローのトリガーにも使用することができます。

Webhook は、リバース API またはプッシュ API と呼ばれることもよくあります。通信の責任をクライアントではなくサーバーに委ねるからです。クライアントが HTTP 要求を送信する、つまりサーバーが応答するまでデータを求めるのではなく、 データが利用できるようになったときにサーバーはクライアントに HTTP POST 要求を 1 回送信します。その呼び名とは異なり、Webhook は API ではありません。API と連携して機能します。Webhook を使用するには、アプリケーションには API が必要です。 

Webhook とは？の詳細を見る

モデルコンテキストプロトコル (MCP) と API はどちらも、別々のシステム間の接続を可能にするデジタルブリッジとして機能します。MCP の機能は API を基盤として構築されています。API がなければ、MCP は存在しません。 

これらのテクノロジーは、機能する方法や目的が異なります。

• MCP は、言語モデルを外部ツールおよびデータに接続し、リアルタイムでその場に合わせて適応するワークフローを強化します。 
• 従来の API ワークフローは、固定された一連のルールに従います。2 つのシステムが接続されると、そのやり取りは開発者がプログラムした特定のアクション群に限定されます。

MCP と API の違いについての詳細を見る