API とは

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

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

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

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

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

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

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

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

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

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

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

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

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

取次業者のパートナーが、店頭にある本を探すのに役立つアプリケーションを開発したとします。エクスペリエンスが改善されたことで、書店 (取次業者の顧客) の顧客が増え、既存の収益チャネルが拡大します。

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

特定のパートナーまたはすべての人々と API を共有すると、プラスの効果を得られます。パートナーシップを通じて、自社のマーケティング活動だけでは得られない範囲まで、ブランドの認知度が広がります。パブリック API のように、テクノロジーを広く公開すれば、API を中心としたアプリケーション・エコシステムの構築を促すことができます。テクノロジーを使う人が増えれば、それだけ顧客も増えます。

テクノロジーを公開することで、これまでにない新たな成果や予期しない成果が得られる可能性があります。これらの成果は、時には業界全体を変革することがあります。書籍の取次業者の例では、新しい事業 (書籍のレンタルサービスなど) によってビジネスの手法が根本的に変化する可能性があります。パートナー API やパブリック API により、社内の開発者チームよりも広範なコミュニティの創意工夫や成果を活用することができます。新しいアイデアはどこからでも生まれるものであり、企業は市場の変化を常に把握し、それに即座に対応できる態勢を整えておく必要があります。API がその役に立ちます。

API は、パーソナルコンピュータが登場するはるか以前、コンピュータ技術の黎明期に登場しました。当時の API は、オペレーティングシステムのライブラリとしての利用が中心でした。API はほとんどの場合、API が動作するシステム内 (ローカル) で使用されましたが、メインフレーム間でメッセージをやり取りする目的で使われることもありました。それから約 30 年を経て、API はローカル環境の枠から飛び出しました。そして 2000 年代初頭には、データのリモート統合において不可欠なテクノロジーへと変化していきました。

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

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

Web API の普及に伴い、情報交換の標準化に役立つプロトコル仕様が開発されました。それが、Simple Object Access Protocol、通称 SOAP です。SOAP で設計された API は、メッセージ形式に XML を使用し、HTTP または SMTP を介して要求を受信します。SOAP により、異なる環境で実行されている、あるいは異なる言語で記述されているアプリケーション間であっても、情報を共有しやすくなります。

もう 1 つの仕様は Representational State Transfer (REST) です。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 クライアントは、リソースにアクセスした後、ハイパーリンクを介して現在利用可能な他のすべてのアクションを検出できる必要があります。

このような制約は多いと感じるかもしれませんが、規定されたプロトコルよりもはるかに単純です。このため、RESTful API は SOAP よりも普及が進んでいます。

最近では、REST API を定義する共通規格として OpenAPI 仕様が登場しました。OpenAPI を使用すると、開発者は言語に依存せずに REST API インタフェースを構築できるので、ユーザーは当て推量に頼らずに理解できるようになります。

もう 1 つの API 標準として登場したのが GraphQL です。これはクエリ言語かつサーバーサイドランタイムで、REST の代わりとなるものです。GraphQL では、クライアントが要求するデータのみを正確に提供することが優先されています。GraphQL は REST の代わりとなるものであり、開発者は、1 回の API 呼び出しで複数のデータソースからデータをプルする要求を作成できます。

SOAP と REST の詳細はこちら

リモート API を最も多用するアーキテクチャアプローチは、サービス指向アーキテクチャ (SOA) とマイクロサービス・アーキテクチャの 2 つです。2 つのアプローチのうち古い方の SOA は、モノリシック・アプリケーションを改善する目的で生まれました。モノリシック・アプリケーションは単体であらゆることを実行しますが、一部の機能は、エンタープライズサービスバス (ESB) などの統合パターンを通じて疎結合された、別のアプリケーションから提供できます。

SOA は多くの点でモノリシックなアーキテクチャよりも単純ですが、コンポーネントの相互作用が明確に理解されていない場合、環境全体に連鎖的な変化が生じるリスクがあります。このように複雑化が進むと、SOA が解決しようとしていた問題の一部が再び生じることになります。

マイクロサービス・アーキテクチャは、特殊な疎結合サービスを使用するという点で SOA パターンに似ています。しかし、従来のアーキテクチャを分解する点で、一歩先を行くものです。マイクロサービス・アーキテクチャ内のサービスは、RESTful API などの共通のメッセージング・フレームワークを使用します。これらのサービスは RESTful API を使うことで、複雑なデータ変換処理や追加の統合レイヤーを必要とせずに、相互に通信を行います。RESTful API を使用すると、新機能やアップデートの迅速な提供が可能になり、さらにはそれが促進されます。各サービスは独立しており、あるサービスを置き換えたり、機能強化したり、廃止したりしても、アーキテクチャ内の他のサービスには影響を与えません。このような軽量のアーキテクチャによって、分散型またはクラウドのリソースを最適化し、個々のサービスの動的なスケーラビリティを確保できます。

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 の詳細はこちら