オープンAPI（Open API）
1. 概要
A. 定義
オープンAPI(Open API) は、外部の開発者・サービスがアクセス・利用できるように公開された標準インターフェースであり、組織が保有するデータ・機能を開放してサービス連携・拡張とエコシステム(プラットフォーム) を促進する。
オープンAPIの本質は技術というより「契約」 にある。内部実装がどう変わろうと、外部に公開されたインターフェース(要求形式・応答スキーマ・認証方式)さえ守ればよいという約束を通じて、互いに知らない組織同士が事前協議なしにシステムを結合できる。この「標準化された契約」こそがオープンAPIを個別のPoint-to-Point連携と区別する核心である。
B. 登場背景および必要性
過去のシステムは閉鎖的であったため、外部とデータをやり取りするには毎回個別連携(Point-to-Point)を開発せねばならなかった。連携対象がn個なら最悪の場合n×(n−1)個の接続を管理せねばならない組合せ爆発が起き、一つのシステムが変わると接続されたすべての連携を併せて修正せねばならない保守負担が大きかった。この方式は参加者が増えるほど急激に非効率になる。
デジタル経済では、一つのサービスが複数のサービスと結合(マッシュアップ、Mashup) するとき価値が大きくなる。地図の上に配達・不動産情報を載せたり、決済・認証・地図を組み合わせて新たなサービスを作る類である。オープンAPIはこの結合を標準契約にし、誰もが定められた規格に従って機能を呼び出せるようにする。すなわち統合コストを下げ、革新の速度を高めることがオープンAPIの根本的な必要性である。
特に金融業界のオープンバンキング・マイデータは法・制度でAPI開放を強制し、オープンAPIが単なる技術選択を超え産業インフラとなった代表事例である。かつて銀行ごとに閉ざされていた口座・取引情報が標準APIで開放されることで、フィンテック企業が複数の金融社のデータを一つのアプリで統合提供するサービスが可能になった。これはオープンAPIが市場構造そのものを変えた事例である。
C. 特徴
オープンAPIの特徴はすなわちその価値であり管理負担でもある。開放・標準・再利用性がエコシステムを育てる一方、誰でも呼び出せるため認証・課金・トラフィック統制が必ず伴う。すなわち「開くが、統制する」という二重の命題がオープンAPI運営の本質であり、これをバランスよく達成する地点がまさにAPIゲートウェイである。
| 特徴 | 内容 | 伴う管理課題 |
|---|---|---|
| 開放性 | 認証された外部主体に機能・データを公開 | アクセス統制・権限管理 |
| 標準性 | HTTP・REST・OpenAPI(Swagger)など標準を遵守 | 仕様・バージョン管理 |
| 再利用性 | マッシュアップ・プラットフォームのエコシステム拡張 | 開発者ポータル・文書化 |
| 統制の必要 | 認証・課金・トラフィック制御 | APIゲートウェイ運営 |
特に標準性はオープンAPIが拡散した決定的要因である。HTTP・JSON・OpenAPI仕様という共通言語があるからこそ、異なる言語・プラットフォームで作られたシステムも別途のアダプタなしに結合できる。標準がなければ連携のたびに形式を協議せねばならないため、エコシステムの拡張自体が不可能である。すなわち標準性は再利用性と開放性を支える土台である。
2. オープンAPIアーキテクチャと構成要素
オープンAPIはクライアントがAPIサーバの資源を直接呼び出す単純な構造に見えるが、実際の運用環境ではAPIゲートウェイが中央関門の役割を担い、認証・ルーティング・トラフィック制御・ログを一括担当する。以下の構造図は、要求がゲートウェイを通過して処理される過程を示す。
flowchart LR
C["クライアント(アプリ・サービス)"] -->|HTTPS要求| G["APIゲートウェイ"]
G -->|認証・認可| A["認証サーバ(OAuth)"]
G -->|レート制限・ルーティング| S["APIサーバ(資源)"]
S -->|照会・処理| D[(データストア)]
S -->|JSON応答| G
G -->|応答・ログ| C
G -.監視・統計.-> M["管理・分析ポータル"]
ゲートウェイを置く理由は横断的関心事(Cross-cutting Concern)の一元化である。認証・トラフィック制限・バージョン・ログを個別のAPIごとに実装すると重複と不一致が生じるため、これをゲートウェイ一か所に集めて方針を一貫して適用する。開発者ポータルはこれらのAPIをカタログ化し、外部開発者が仕様を読みキーの発行を受けてすぐに使えるようにするセルフサービスの窓口の役割を果たす。
核心構成要素は資源(URIで識別)、行為(HTTPメソッド)、表現(主にJSON)、認証トークン(OAuth・JWT)、そしてそれらを包むゲートウェイ・ポータルである。これらが結合して「誰が、何を、どう呼び出し、どんな形式で応答を受けるか」という契約を完成させる。
認証・認可はオープンAPI運営の関門である。代表標準であるOAuth 2.0は、利用者の資格証明(パスワード)を第三者アプリに直接渡さず、権限を委任されたアクセストークンだけで資源にアクセスさせる委任認証方式である。以下の流れはクライアントがトークンの発行を受けてAPIを呼び出す過程を示す。
sequenceDiagram
participant C as クライアント
participant Auth as 認証サーバ
participant API as 資源サーバ(API)
C->>Auth: 認証・権限要求(scope)
Auth->>C: アクセストークン発行
C->>API: トークンと共に資源要求
API->>API: トークン検証・権限確認
API->>C: JSON応答
この方式の核心的な利点は最小権限と失効の容易さである。トークンにはアクセス範囲(scope)と有効期限が入り、奪取されても被害範囲と期間が制限される。またトークンさえ回収すれば権限を即座に撤回でき、パスワード共有方式よりはるかに安全である。実務ではここにOIDC(OpenID Connect)を載せ、認証(誰か)まで標準化する。
3. SOAPとRESTの構成要素比較
オープンAPIを実装する二つの方式がSOAPとRESTである。両者の根本的な違いは、SOAPが厳格なXMLプロトコルであり、RESTがHTTPをそのまま活用するアーキテクチャスタイルである点である。この違いが性能・信頼性・開発利便のトレードオフを生む。
SOAPは標準が強く、WS-Security・トランザクション(WS-AtomicTransaction)を備え、銀行間取引のように高い信頼性とセキュリティが必要な所に合う。メッセージがXML Envelopeで重く包まれWSDLでインターフェースを厳格に定義するため契約が明確だが、その分オーバーヘッドが大きく柔軟性に劣る。一方RESTは資源をURIで表現しHTTPメソッド(GET・POST・PUT・DELETE)で扱い、軽量で、無状態(Stateless)ゆえ水平拡張が容易であり、HTTPキャッシングをそのまま活用できる。
こうした違いから、今日の公開APIの大半はREST(またはその代替であるGraphQL)で提供される。Web・モバイル環境では軽量・キャッシング・拡張性が決定的な利点だからである。ただし強いトランザクション保証と標準セキュリティが必要な企業間(B2B)・レガシー連携では依然としてSOAPが使われる。すなわち「RESTが常に正しい」というより、要求事項(信頼性 vs 軽量性)に応じて選択するのが実務的な判断である。
| 区分 | SOAP | REST |
|---|---|---|
| 概念 | XMLベースのプロトコル | HTTPベースのアーキテクチャスタイル |
| 構成要素 | Envelope・Header・Body、WSDL、UDDI | 資源(URI)・HTTPメソッド・表現(JSON)・無状態 |
| メッセージ | XML | 主にJSON |
| セキュリティ・トランザクション | WS-Security・WS-Transaction内蔵 | HTTPS・OAuthなどを別途組合せ |
| 特徴 | 強い標準・トランザクション・信頼性 | 軽量・拡張性・キャッシング・Stateless |
| 適合 | エンタープライズ・高信頼・B2B | Web・モバイル・公開API |
4. 脆弱性および対応方案(OWASP API Security Top 10)
オープンAPIは外部に露出するため、Webアプリケーションとは異なるAPI固有の脅威を受ける。その中で最も多く致命的なのがBOLA(Broken Object Level Authorization、オブジェクトレベル認可の不備) であり、認証は通過したが「他人のデータにアクセスする権限」まで検証せず、URLの識別子だけを変えれば他人の情報が照会される欠陥である。
例えばログインした利用者が/orders/1001を/orders/1002に変えて他人の注文を照会する類である。認証(誰か)は確認したが、認可(この資源にアクセスしてよいか)を資源単位で検証しなかったのが原因である。したがって要求のたびに当該オブジェクトの所有・権限をサーバが再検証せねばならず、クライアントが送ったIDをそのまま信頼してはならない。BOLAがOWASP API Top 10で繰り返し1位を占める理由は、機能は正常に動作するためテストで表れにくく、配備後に悪用されるからである。
BOLA以外にも認証の脆弱(Broken Authentication)、過度なデータ露出、資源枯渇(無制限呼び出しによるDoS)、インジェクション、放置された旧バージョンAPIの露出などが主な脅威である。これらの大半は「サーバがクライアント入力を信頼した」という共通の原因を持つため、対応の核心はすべての入力・要求・権限をサーバが独立して検証することである。
| 脆弱性 | 原理 | 対応 |
|---|---|---|
| オブジェクト認可の不備(BOLA) | オブジェクト所有権の未検証 | OAuth 2.0・JWT + オブジェクトレベルの権限検証 |
| 認証の脆弱 | 弱いトークン・セッション管理 | 標準認証(OAuth・OIDC)、トークン失効・回転 |
| 過度なデータ露出 | 応答に不要フィールドを含む | 応答フィールドの最小化、スキーマ検証 |
| 資源枯渇(DoS) | 無制限呼び出し・大量照会 | レート制限・クォータ、ページネーション |
| インジェクション | 未検証入力がクエリとして実行 | 入力検証、パラメータバインディング |
| 不適切な資産管理 | 放置・旧バージョンAPIの露出 | APIインベントリ・バージョン管理、廃止APIの遮断 |
実際に複数の大型プラットフォームでBOLA・過度なデータ露出により数百万件の個人情報が漏えいした事故が繰り返され、これはAPIセキュリティがネットワークファイアウォールではなくアプリケーションロジック層の問題であることを示す。ファイアウォール・WAFは認証を通過した正常要求の中に含まれた認可の欠陥を判別できないため、APIセキュリティは必ずサービスロジックに内在化されねばならない。
5. API管理(ライフサイクル)
オープンAPIは一度公開して終わりではなく、外部利用者が依存するため設計から廃止まで慎重に管理せねばならない。突然APIを変えると、これを使っていたすべてのサービスが壊れるからである。そのため設計段階でOpenAPI仕様で契約を先に定め(契約優先、Contract First)、ゲートウェイ・ポータルで掲載・運用し、廃止時には十分な猶予とマイグレーション案内を置く。
flowchart LR
P["設計(OpenAPI仕様)"] --> B["掲載(ゲートウェイ・ポータル)"]
B --> O["運用(認証・課金・監視)"]
O --> V["バージョン管理(下位互換)"]
V --> R["廃止(猶予・マイグレーション)"]
O -.フィードバック.-> P
ライフサイクルで最も敏感な地点はバージョン管理である。下位互換を壊す変更(フィールド削除、応答形式の変更)は新バージョン(/v2)に分離し、既存バージョンは廃止予告(Deprecation)ののち猶予期間を置いて利用者がマイグレーションする時間を与える。この原則を守らなければ開放エコシステムの信頼が崩れ、外部開発者がAPIの採用自体を敬遠するようになる。
運用段階では監視とSLA(サービス水準協約) 管理が重要である。外部利用者はAPIの可用性・応答時間に自らのサービスを依存させるため、ゲートウェイが収集した呼び出し量・エラー率・遅延の指標を常時観測し、異常の兆候を早期に検知せねばならない。また利用等級別に呼び出し限度(クォータ)と課金方針を差別適用し、特定利用者の暴走が全体のサービス品質を落とさないよう隔離する。
| 段階 | 活動 |
|---|---|
| 設計 | OpenAPI仕様(契約優先)、標準化 |
| 掲載 | APIゲートウェイ・開発者ポータルへの登録 |
| 運用 | 認証・課金・監視・トラフィック制御 |
| バージョン管理 | 下位互換の維持、新バージョンの分離 |
| 廃止 | 廃止予告・猶予・マイグレーション案内 |
6. 深化:最新動向と標準
オープンAPIのエコシステムはRESTを基盤としつつ、新たな要求に合わせて進化している。技術士の観点では以下の流れを併せて理解せねばならない。
- GraphQL・gRPCの台頭:RESTが資源ごとに固定された応答を返すのと異なり、GraphQLはクライアントが必要なフィールドだけを照会し、過度な/不足したデータ転送(Over/Under-fetching)を解決する。一方、マイクロサービス内部通信では性能が重要なため、HTTP/2ベースの二進プロトコルであるgRPCが拡散する。すなわち公開APIはREST/GraphQL、内部通信はgRPCへと分化する傾向である。
- APIゲートウェイ・API管理(APIM)の高度化:単純なルーティングを超え、認証・方針・課金・分析を統合した商用/オープンソースのAPIM(Kong、Apigeeなど)が標準インフラとなり、サービスメッシュ(Istio)と結合して内部トラフィックまで統制する。
- ゼロトラスト・mTLSの適用:「内部網も信頼しない」というゼロトラスト原則に従い、API区間をmTLS(相互TLS) で相互認証し、すべての呼び出しを検証・ログ化する方向へセキュリティが強化されている。
- 国内の開放政策の拡大:オープンバンキング・マイデータで始まったAPI開放が公共データポータル、行政情報共同利用などへ拡散し、オープンAPIがデータ経済の核心インフラとして定着しつつある。
- API優先(API-First)・文書自動化:サービスを企画する際にAPIを最優先の産出物として設計するAPI-First文化が拡散し、OpenAPI仕様から文書・SDK・テストを自動生成して一貫性と生産性を同時に確保する方式が標準になりつつある。
7. 考慮事項および示唆点
- ゲートウェイ中心の統制:認証・トラフィック制限・バージョン・ログを個別のAPIごとに実装する代わりにAPIゲートウェイで一元化し、セキュリティ・運用を一貫して適用して個別サービスの負担を減らす。
- 契約優先(Contract First):OpenAPI仕様を先に確定すれば文書・モックサーバ(Mock)・クライアントコードを自動生成でき、開発生産性とフロント・バックエンドの並行開発が可能になる。
- セキュリティはアプリケーション層の問題:ファイアウォールだけではBOLAのようなロジック欠陥を防げない。要求のたびにオブジェクトレベルの権限を検証し、ゼロトラスト・mTLSで区間を保護せねばならない。
- ガバナンスとエコシステム戦略:オープンAPIは技術であり同時にビジネス戦略である。どのデータを開放してどのパートナーエコシステムを育てるか、課金・SLAをどう設計するかがすなわちプラットフォーム競争力となる。オープンバンキング・マイデータのように開放が市場構造を変え得ることを考慮せねばならない。
- 標準選択のトレードオフ:REST・GraphQL・gRPC・SOAPはそれぞれ軽量性・柔軟性・性能・信頼性で強みが異なる。「何が最新か」ではなく、対象(公開/内部)、要求(信頼性/性能)、利用者の力量を総合して選択せねばならず、一つのシステムの中でも階層別に異なるプロトコルを混用するのが一般的である。
参考資料
- OWASP API Security Top 10 — https://owasp.org/API-Security/
- OpenAPI Specification (Swagger) — https://spec.openapis.org/oas/latest.html
- 金融決済院 オープンバンキング — https://www.open-platform.or.kr/
一言まとめ: オープンAPIは標準(REST/SOAP・OpenAPI)ベースの「公開された契約」でマッシュアップ・プラットフォームのエコシステムを拡張し、OAuth・オブジェクトレベルの権限検証・ゲートウェイ・レート制限でOWASP APIの脆弱性(特にBOLA)に対応し、契約優先・バージョン・廃止のライフサイクル管理とゼロトラスト・mTLSで運用するオープンバンキング・マイデータの基盤インフラである。