API戦略のベスト・プラクティス

アプリケーション・プログラミング・インターフェース（API）は、アプリケーション、システム、データベースの接続と統合、ワークフロー、ワークフローのオーケストレーション、新しいアプリやサービスの開発と配布の迅速化、レガシーシステム用のモダナイズされたインターフェースの作成などに使用され、現代の組織にとって必要不可欠なものです。平均的な企業では、613以上のAPIエンドポイントが本番稼働しています。

しかし、アドホックな方法によるAPIの作成、デプロイ、組み込みが行われると、組織はその価値を放置したり、サイバーセキュリティーのリスクに対して脆弱なままになってしまう危険があります。しっかりとしたAPI戦略があれば、組織はAPIを有効に使い、共通のビジネス目標の達成に役立てることができます。

API戦略は、組織がビジネス目標を達成するためにAPIをどのように使用するかを概説する大まかな計画です。この戦略では、APIの設計、開発とデプロイメント、API管理、セキュリティーなどのガイドラインとポリシーを確立します。API戦略は、組織のAPIが孤立して存在するのではなく、より大きなビジネスニーズと目標に合わせて円滑に連携できるようにするのに役立ちます。

API戦略は、組織の技術、セキュリティー、コンプライアンスのニーズを考慮すると同時に、将来的に新しいAPIを実装するための持続可能で予測可能な集中システムを促進するのに役立ちます。

つまり、API戦略は、組織がより効率的で価値のある安全なAPIを設計および管理するのに役立ちます。API機能は非常に広範で多様で、急速に進化しているため、APIプロジェクトの一貫性、効率性、有効性を維持するために利害関係者は具体的なAPI戦略を策定する必要があります。

APIにはさまざまな種類があり、その使用方法はさらに増えています。APIは現代の企業において不可欠な役割を果たしているため、組織はデジタルエコシステムの秩序を維持し、リソースの無駄やセキュリティリスクを回避するための明確で包括的なAPI戦略を立て、APIが可能な限り多くのビジネス価値をもたらすようにする必要があります。

堅牢なAPI戦略は、開発者に優れたエクスペリエンスを提供し、互換性と拡張性を向上させ、組織のAPIの収益化を支援します。API戦略は、デジタル・トランスフォーメーションなどの全体的な目標を達成するためにも重要な要素です。

デジタル・トランスフォーメーションは、組織全体にテクノロジーを組み込むことを目的としたストラテジーです。これは、プロセス、製品、オペレーション、テクノロジースタックの完全な見直しであり、継続的かつ迅速な顧客主導のイノベーションを可能にします。特定のプロセス置き換えや、サービスの更新にとどまらず、テクノロジーを組織の中心に据えた完全なビジネス・トランスフォーメーションを実践します。

AP、および適切に策定されたAPI戦略は、このトランスフォーメーションを推進する上で非常に大きな役割を果たします。テクノロジーを中心に、企業全体のテクノロジーをつなぎ、ユーザーを企業のアプリケーション、システム、サービスに結び付けるためによく使用されるのがAPIです。

APIにより、組織はより多くのサービスを多数のユーザーに提供したり（新しい収益源を開く）、これらのサービスを高速化して全体的なユーザーエクスペリエンスを向上させったり、内部システム、データベース、アプリケーション間のデータ交換を促進したり、クラウド・プロバイダーでホストされているリソースを接続したり、レガシーITインフラストラクチャをモダナイズしたりすることが可能になります。

強力な企業API戦略には、組織のAPIがどのように構築され、使用されているかを明確に説明する徹底したAPIドキュメンテーション（APIを組織がいかに検出するかについての詳細を読む）が含まれます。開発者ポータルは、フロントエンドとバックエンドの両方のAPIを利用可能にし、整理し、開発者が見つけやすくする貴重なツールとなり得ます。優れたAPI戦略がなければ、開発者は必要なツールを見つけるのに苦労し、開発と実装が遅れ、APIの冗長性やリソースの無駄につながる可能性があります。

新しいソフトウェアやソフトウェアの更新に対応するには、APIを監視して更新する必要があります。通常、適切に開発されたAPI戦略には、APIライフサイクル全体（アイデアの立案、API設計、テスト、実装、保守、必要に応じて廃止など）の計画が含まれます。このようなプロセスにより、最新のソフトウェア・バージョンとのAPI互換性の一貫性が促進され、互換性関連のクラッシュや予測不可能な動作のリスクが軽減されます。

テクノロジーの猛烈な進化は、ほぼすべての組織が何らかのレガシー・サービス、ソフトウェア、またはデータベースに依存していることを意味します。これらのリソースを更新する作業には、多くの場合、コストと時間がかかります。

モダナイゼーションの取り組みが進む一方で、組織はAPIを使用してこれらのシステムやデータベースへのインターフェースをモダナイズすることができます。これにより、組織はシステム全体の更新を待つことなく、レガシーのリソースを統合し、その中の貴重なデータを活用できるようになります。

たとえば、膨大な顧客アカウントの記録が、社内の他の部署では使用されなくなったデータベースに保管されている場合があります。すべてのデータを苦労して新しいシステムに移行する代わりに（または移行の進行中に）、APIを使用して、システムの他の部分がデータベースと通信し、情報を要求できるようにすることができます。

API戦略とは、定められた目標に向かってビジネスを方向付け、より広範なビジネス戦略に適合するような方法でAPIを設計、デプロイ、文書化することです。API戦略は、API開発と配布のロードマップの作成、および、より一貫性のある合理化されたビジネスモデルとAPIの価値を高める計画の策定に役立ちます。

APIは攻撃ベクトルとしてよく使用され、対処しなければならないセキュリティー・リスクをもたらします。組織のセキュリティー基準、そして組織がAPIの悪用を防ぐ方法を詳細に説明したAPI戦略を持つことにより、このリスクを軽減できます。そのために、API Gatewayなどのツールや、認証やレート制限などのテクニックがよく使用されます。

レート制限は、ブルートフォース攻撃や分散型サービス妨害（DDoS攻撃）のリスクを軽減するために使用されます。レート制限は、ボリュームリスクのあるリクエストをブロックまたは破棄し、システムにリクエストが殺到するのを防ぎます。さらに精密な自動化機能もあります。たとえば、組織は、不審なものとしてフラグが立てられた、リクエスト・アクティビティーが多い特定のIPアドレスにレート制限を設定できます。

APIセキュリティー戦略には認証技術も組み込まれており、安全で承認されたリクエストのみが確実に実行されるようにします。OAuth（オープン認証）は、トークンを使用するプロトコルで、ユーザーはログインしなくても以前に承認されたデータやサービスにアクセスできます。APIキーは、クライアントとサーバーだけが知る一意の文字列で、APIの安全を確保するために組織がよく使うツールの一つです。

組織は、システムのセキュリティを継続的にチェックする自動テストプラットフォームを使用して、手動によるチェックとテストを補完および改善できます。

マイクロサービス・アーキテクチャでは、アプリケーションは、疎結合で独立してデプロイ可能な多数の小さなコンポーネントまたはサービスで構成されます。これらのコンポーネントは、多くの場合、APIを介して通信します。

マイクロサービスは柔軟性と汎用性を向上させますが、互換性の問題や、ネットワーク接続数の増加やデータロギングの増加によるレイテンシーの問題など、複雑な問題が生じる可能性もあります。実質的に、マイクロサービスのアーキテクチャは自由度を高める一方で、複雑さの増加も伴います。

企業API戦略は、高速かつ効率的なマイクロサービス・アプリケーションに必要なAPIの一貫性と見つけやすさを確立するのに役立ちます。

APIファーストの戦略では、ビジネス資産としてAPIを最優先します。この考え方では、APIはソフトウェア開発後に追加される機能ではなく、開発者がコードを書くための基盤となります。これは、エンタープライズ・システム、データベース、アプリケーション間の統合と通信に重点を置いているため、デジタル・ファースト戦略でよく使われるアプローチです。

APIファースト戦略にはいくつかのメリットがあります。

• APIの冗長性のリスクを軽減する
  
  
• APIの再利用を促進する
  
  
• API を一元化された場所で発見可能にし、簡単に検索・導入できるようにする
  
  
• APIエコシステムをより効率化する
  
  
• 開発者がコードのデバッグに費やす時間が短縮される
  
  
• より優れた拡張性を実現する
  
  
• APIの保守と更新が容易になる
  
  
• ますますAPIが普及していく世界でビジネス上の優位性を実現する
  
  
• 開発チームが複数のAPIを同時に並行して作業し、リアルタイムで共同作業できるようにします。

API戦略は、個々の組織のビジネス目標やニーズに応じて大きく異なります。しかし、強力なAPI戦略を実現するより大きな概念とコンポーネントがいくつかあり、多くのAPI戦略は次の手順を使用して構築されます。

戦略の開発は、「組織がAPIで何を達成しようとしているのか」という単純な質問から始まります。

これらの目標は、デジタル・トランスフォーメーションの実施、開発者のワークフロー最適化、メトリクス（ユーザーベース、顧客体験、収益化）の向上、組織の業務効率の向上など、組織が設定した他の目標と連動させる必要があります。

潜在的なユースケースを徹底的にカタログ化することで、効果的なAPI戦略の方向性が得られます。

組織は内部チーム間で簡単にデータを共有したいのでしょうか？開発者がソフトウェアを迅速に作成・改善できるようにしたいのでしょうか？顧客やユーザーをデータとサービスに結び付けたいのでしょうか？戦略は組織のニーズに応じて変化するため、APIはどのように使用されるのかという単純な質問から始めることは理にかなっています。

APIガバナンスとは、組織がAPIを開発、デプロイ、使用する方法を指示する包括的な基準、ポリシー、プラクティスのセットを指します。

理想的には、組織は最初にガバナンスの概要を説明し、その後、それらのルールに従ってAPIを設計します。その逆の手順は避けるべきです。このガバナンスを作成する際に、チームは組織の目標、既存のテクノロジー、組織が将来取り入れる可能性のあるテクノロジーなどの要素を考慮します。

ガバナンス・フレームワークでは、さまざまなユースケースでどのような種類のAPIが使用されているかについても概説する場合があります。API プロトコル、アーキテクチャスタイル、言語はいくつかあり、それぞれに長所と短所があります。例えば、¹が含まれます。

リモートプロシージャコール (RPC) は、プログラムがローカルでサービスを要求する場合と本質的に同じコードを使用して、別のコンピューター上の別のプログラムからサービスを要求できるようにするプロトコルです。

RPCは、オペレーティングシステムで使用される高レベルの通信パラダイムを提供します。これは、通信プログラム間でメッセージデータを伝送するための、伝送制御プロトコル/インターネット・プロトコル (TCP/IP) やユーザー・データグラム・プロトコル (UDP) などの低レベル転送プロトコルの存在を前提としています。

RPC は、ネットワークアプリケーションのサポート専用に設計された論理的なクライアント/サーバー通信システムを実装しています。²

RPCプロトコルの種類には、XML-RPC、JSON-RPC、gRPCなどがあります。

Representational State Transfer（REST）は、Web APIアーキテクチャの原則のセットです。REST API（RESTful APIとも呼ばれる）は、特定のRESTアーキテクチャの制約を遵守するAPIです。REST APIは、GET、PUT、HEAD、DELETEといったHTTPリクエストを使ってリソースとやりとりします。RESTはデータをリソースとして利用できるようにし、各リソースは一意のURIで表されます。クライアントはリソースのURIを指定してリクエストします。

REST API はステートレスであり、リクエスト間でクライアント データを保存しません。 SOAP プロトコルを使用して RESTful API を構築することは可能ですが、実務者は通常、2 つの標準を競合する仕様と見なしています。

GraphQLは、オープンソースのクエリ言語およびサーバー側のランタイムであり、クライアントが必要なリソースを正確にターゲットにすることができます。通常、複数のエンドポイントを使用してデータを取得し、ネットワーク操作を実行するRESTとは異なり、GraphQL APIは単一のGraphQLエンドポイントを使用して、単一のリクエストから1回の往復で正確で包括的なデータ応答をクライアントに提供するため、オーバーフェッチやアンダーフェッチの問題がなくなります。³

ただし、GraphQLは、単純なアプリケーションに必要以上の複雑さをもたらす可能性があります。

シンプル・オブジェクト・アクセス・プロトコル（SOAP）は、軽量のXMLベースのメッセージング・プロトコル仕様で、エンドポイントがSMTP（簡易メール転送プロトコル）やHTTP（ハイパーテキスト転送プロトコル）などのさまざまな通信プロトコルを通じてデータを送受信できるようにします。SOAPは独立しているため、SOAP APIは異なる環境で動作するアプリケーションやソフトウェア・コンポーネント間、あるいは異なる言語で書かれたアプリやソフトウェア・コンポーネント間で情報を共有することができます。

API管理プラットフォームは、APIにアクセスし、APIを管理・配布・分析する作業を一元化された場所で実行するために特別に設計されたツールです。API管理プラットフォームは、企業がチーム間でドキュメンテーションやツールを共有することを可能にし、データ・セキュリティーを強化し、コンプライアンスやガバナンスの基準を満たし、デジタル・トランスフォーメーション・イニシアチブを支えます。

API管理プラットフォームには、多くの場合、開発者がAPIドキュメンテーションを閲覧、アクセス、共有するためのワンストップショップとして機能する開発者ポータルが含まれています。このソリューションでは、APIやソフトウェア開発における複数のリポジトリ、廃止されたライブラリ、不明な所有権の認証情報の問題を回避できます。これらをすべて1つの場所で管理できます。

APIプラットフォームには、貴重な分析ツールも含まれています。この一元化されたプラットフォームは、APIの使用状況、応答時間、および全体的な性能を監視し、APIの脆弱性を検知するのに役立ちます。

最後に、API管理プラットフォームを使用することで、完全なAPIライフサイクル管理が可能になります。APIライフサイクルには、作成、開発、テスト、公開、保守、廃止などのさまざまな段階が含まれます。APIプラットフォームでは、これらすべての段階を1か所にまとめられるため、組織は大規模で複雑なAPI環境を可視化できます。

APIは、内部クライアントかサードパーティクライアントかを問わず、データやサービスへのアクセスを提供するため、API戦略開発のあらゆる段階においてセキュリティを主要な考慮事項とする必要があります。APIセキュリティーに欠陥があると、サイバー攻撃、データ侵害、その他の不正アクセスにつながる可能性があります。API戦略では、認証、暗号化、検証、監視、定期的な更新などに対するアプローチの詳細を定め、APIが安全でコンプライアンスに準拠していることをどのように確認するのかを明確にする必要があります。

完全な API戦略には、APIが作成された後に何が行われるか、つまりAPIをどのように監視、保守、分析、テスト、更新するかについての計画が含まれます。

APIの使用状況を監視することは、次のいくつかの理由から欠かせません。

• APIが適切に動作し、バグがないことを確認する
  
  
• トラフィック・パターンを分析して、異常な動作や潜在的に危険な動作をチェックする
  
  
• すべてのAPIが最新であることを確認する
  
  
• 潜在的な重複に注意する
  
  
• 非機能または置き換えられたAPIを削除する

API戦略では、組織がAPI環境全体の可視性をどのように促進するか、分析やユーザーからのフィードバックで得た洞察をどのように取り入れてAPIの性能を向上させるか、更新をどのように実装し文書化するか、必要に応じてAPIを廃止する方法について詳しく説明する必要があります。