API Management: アーキテクチャと用途

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 10, 2026 · 20 min read

本記事の位置づけ#

参考資料#

1) API管理のランドスケープ#

SAP API Managementは、SAP Integration Suite内の機能の1つです。そのインフラストラクチャは、公式には5つのコンポーネントにマネタイゼーションを加えたものとして説明されています。それぞれの役割を理解しておくことで、後々のスコープに関する議論の大半を防ぐことができます。

これらは代替品ではありません。

2) S/4HANA への接続方法#

                                             SAP Integration Suite (BTP)
                       ┌───────────────────────────────────────────────────────────────┐
   App developer ──────▶│  Developer Hub (API Business Hub Enterprise)                 │
   (registers app,      │            │                                                 │
    gets API key)       │            ▼  app credentials                                │
                        │  ┌───────────────────────────────────────────────────────┐  │
   Client app  ─ HTTPS ─┼─▶│  API Runtime (Gateway)                                │  │
                        │  │  Proxy Endpoint  ──  Policies  ──  Target Endpoint     │  │
                        │  │   (Pre/Post/Cond.   (Sec/Traffic/  (route to backend) │  │
                        │  │    + Fault Rules)    Med/Ext)                          │  │
                        │  └────────┬─────────────────────────────────┬────────────┘  │
                        │           │                                 │               │
                        │           ▼                                 ▼               │
                        │   Cloud Integration iflow            S/4HANA OData / SOAP   │
                        │   (CPI as backend)                   (direct backend)       │
                        └───────────┬─────────────────────────────────┬───────────────┘
                                    │ via Cloud Connector             │
                                    ▼                                 ▼
                            S/4HANA on-premise                 S/4HANA Cloud

API ManagementはS/4HANAへの接続を所有しません。これはCPIまたはODataアダプターの役割です。API Managementは、データを公開するものを前面に配置するプロキシを所有します。2つのパターンが主流です。パターンA：CPI iフローをバックエンドとし、その上にプロキシを配置 — 統合ロジックが複雑な場合。パターンB：S/4HANA ODataサービスを直接バックエンドとし、その上にプロキシを配置 — プロキシがゲートウェイ関連の懸念事項（認証、クォータ、スロットリング、キャッシング）のみを追加する場合。オンプレミスのS/4HANAは、APIプロバイダーとして設定されたSAP Cloud Connectorを介して、どちらのパターンでも到達可能です。

重要ポイント：API管理は境界およびコンシューマーエクスペリエンス層です。統合ランタイムではありません。

3) 成熟度マップ#

4) 要件チェックリスト#

設計上の関心事ごとに1つのサブテーブル。各行は要件段階で決定可能です。

テナントおよび契約の前提条件#

ポリシーデザインのベースライン#

バックエンド統合（ターゲットエンドポイント）#

デベロッパーハブとマネタイゼーション#

運用と分析#

5) 意思決定基準#

最初に問うべき3つの質問#

Q1. ゲートウェイを正当化する測定可能な非効率性はどこにあるのか？

正当化する例：クォータなしで公開されたAPIが悪用されるケース、手動での認証情報配布、外部パートナーが文書化された契約を必要とするケース、財務部門がデータプロダクトを収益化したいケース。正当化しない例：「全員が持っているから」。定量化された課題がなければ、ゲートウェイは擁護者のいないコストとなります。

Q2. APIの背後にあるデータの所有者は誰で、どこに保存される必要がありますか？

プロキシは転送されたペイロードだけでなく、トラフィックメタデータもログに記録します。データ主権ルールにより、メタデータのクロスリージョン転送が除外される場合、API Managementのリージョンは一致している必要があります。これはUATでは妥協できません。

Q3. 予算権限を持つ2年目のスポンサーは誰ですか？

Year-1は簡単な収入源です。Year-2になるとコールボリュームが拡大し、パートナーがDeveloper Hubに参入し、誰かがテナントティアを更新しなければならなくなります。Year-1のみのスポンサーでは、ボリュームの増加に耐えられません。

プロジェクトコンテキストによるドメイン選択#

ライセンスとコスト#

リスト価格は公開されていません。価格は見積もりベースであり、ティア、地域、通話量に依存します。アーキテクチャを確定する前に、調達計画を立ててください。

6) よくある障害#

障害 1: 本番環境におけるAPIキーのみの認証

API Key はプロトタイプメカニズムとして文書化されています。本番環境のプロキシでは、OAuth 2.0（内部/B2C）または相互 TLS（B2B/パートナー）を使用する必要があります。これは最も一般的なセキュリティ上の指摘事項であり、最初のペネトレーションテストで検出されます。

障害 2: ベースラインテンプレートに脅威保護ポリシーがない

JSON Threat Protection、XML Threat Protection、Regular Expression Protection はデフォルトでは有効になりません。これらがない場合、ペイロードの複雑性を悪用した攻撃がバックエンドに到達し、メモリやCPUを枯渇させます。修正はテンプレートレベルで行います。外部向けのプロキシはすべて、これらを含むベースラインから開始する必要があります。

障害 3: デフォルトのエラーレンベロープがコンシューマーに送信される

デフォルトのフォールト応答はSAP APIガイドラインに準拠しておらず、フォールトを発生させたポリシーによって異なります。修正方法は、デフォルトフォールトルールと、標準化されたエンベロープを出力するRaise Fault + Assign Messageテンプレートを組み合わせることです。これがないと、各APIチームが場当たり的に対応することになり、Developer Hubカタログは他人が作ったかのような見た目になってしまいます。

障害 4: 最初のAPIが内部向けであるため、Developer Hubがオプション扱いされる

「Developer Hubは後で設定する」はよくあるスコープカットです。その代償として、最初の外部パートナーからのリクエストが再アーキテクチャとなります。IdP統合は急ごしらえで行われ、承認ワークフローは納期に追われて場当たり的に作られます。Developer Hubは初日からプラットフォームに組み込むべきです。

障害 5: API管理が「CPIの前面にあるもの」として範囲設定されている

このフレーミングにより、JavaScriptやService Calloutを介してロジックがプロキシに紛れ込んだり、「CPIがすでに認証を行っている」という理由でAPI Managementの対象範囲が外れたりします。その結果、クォータ、マネタイゼーション、パブリックDeveloper Hubをiflow URLに後付けできないという問題を見落とします。再フレーミング：API Managementは、背後にCPIがあるかどうかに関わらず、あらゆるAPIのコンシューマーエクスペリエンスレイヤーです。

障害 6: 2年目のAPIコール量予測の欠落

導入によりボリュームが増加し、ティア超過料金は交渉時よりも悪化しています。予算としての初年度ボリュームは、2年目のアウテージを引き起こす危険をはらんでいます。

障害 7: 非推奨化とバージョン管理ポリシーの欠如

書面による非推奨契約（sunset HTTPヘッダー、並行稼働期間、EOL日付）がなければ、コンシューマーは移行を行わず、プラットフォームチームは古いバージョンを無期限に抱えることになります。この契約はプラットフォームレベルで定められ、Developer Hubで公開される必要があります。

FAQ#

Q: SAP API Management はオンプレミスのS/4HANAでも動作しますか、それともクラウドのみですか？

両方です。テナントはSAP BTP Cloud Foundry上で動作しますが、APIプロバイダーはSAP Cloud Connector経由で到達可能なオンプレミスのバックエンドを指すことができます。ゲートウェイはクラウド上にあり、バックエンドはオンプレミスに配置可能です。これは「コントロールプレーンはクラウド、データプレーンは一部オンプレミス」というトレードオフであり、アーキテクチャ上の決定として明示的に記載されるべきです。

Q: SAP API Managementは2026年にどのようにライセンス供与され、顧客はどこで過剰支出をしているのか？

Integration Suite（Standard または Premium）にバンドルされ、主にAPI呼び出し数で課金されます。リスト価格は公開されていないため、アカウントチームとの協議を計画してください。よくある2つの落とし穴として、2年目の呼び出し量がティアの上限を超えること（超過料金は交渉時よりも悪化する）、およびEdge Integration Cellクラスターが調達時に過小サイジングされ、負荷がかかると拡張されることです。対策として、指名されたスポンサーによる2年目の予測と、6か月ごとのサイジングレビューを実施してください。

Q: プロジェクトからSAP API Managementをスコープ外とするのはどのような場合ですか？

以下のいずれかに該当する場合：定量化されたペインがゲートウェイの懸念事項にマッピングされていない、APIが完全に内部向けであり既存のIdPゲートウェイがすでに認証を処理している、ボリュームが低く手動管理の認証情報が2年間のテナント費用よりも低コストである、またはガバナンスのオーナーが指名されていない。「このフェーズでは対象外、<日付>に再評価」は成果物であり、後退ではありません。

Q: API要件を、納品後も生き残る形で文書化するにはどうすればよいですか？

各APIを六つの要素で記述すること：(1) 対象者、(2) 認証パターンと認証情報ライフサイクルの所有者、(3) クォータとスパイクアレストのデフォルト値、(4) 非推奨契約を含むSLA、(5) 分析データの保持期間とオーバーフロー先、(6) 製品ライフサイクルにおける指名されたAPI所有者。この六つが揃わなければ、非推奨契約はビルド中に静かに破棄される。

Q: SAP API Management と Cloud Integration (CPI) — それぞれどのような場合に適用されますか？

CPIは統合ランタイム（オーケストレーション、マッピング、メッセージルーティング）です。API Managementはゲートウェイ（ライフサイクル、セキュリティ、クォータ、Developer Hub、マネタイゼーション）です。「既存のODataサービスをクォータとOAuthで公開する」→ API Management単独。「XML注文をIDocに変換してSAPに転送する」→ CPI単独。「その変換を認証・レート制限付きAPIとしてパートナーに公開する」→ 両方、まずCPI、その上にAPI Managementプロキシ。

Q: SAP API Policy v4/2026 について — API Management の使用方法は変わりますか？

間接的です。このポリシーは、公開されたAPI（SAP Business Accelerator Hubまたは製品ドキュメントに掲載されているもの）のみが利用を許可され、内部/プライベートAPIは対象外であることを強調しています。これにより、Developer Hubの役割が高まります。顧客に公開されるすべてのAPIは、意図的で文書化された製品でなければなりません。サポート対象のバックエンドに対して、アクティブなすべてのプロキシの一括棚卸を実行してください。

Q: オンプレミス版は新規プロジェクトにおいて依然として有効な選択肢ですか？

一般的にはいいえ。SAPの戦略ラインはクラウドです。オンプレミスはサポートされていますが、同じペースで強化されておらず、Neoはサンセット（廃止予定）です。オンプレミスを選択するのは、データレジデンシーやレイテンシーによりデータプレーンを顧客ネットワーク内に置く必要がある場合のみにしてください。その場合でも、まずはハイブリッドパスとしてEdge Integration Cellを優先してください。

概要#

SAP API Managementは2026年時点で、5つのサブコンポーネントとマネタイゼーション機能から構成され、すべてApigee Edge上に構築され、本番環境で利用可能です。この製品は成熟しており、プロジェクトの失敗は設計上の失敗に起因します。例えば、本番環境でのAPIキー使用、ベースラインでの脅威保護の欠如、デフォルトのエラーレスポンス形式、Developer Hubの先送り、2年目のボリューム予測の欠落などです。コンサルタントの価値は、ポリシーベースライン、フォールトルールテンプレート、IdP統合を含むDeveloper Hub計画、そして2年目のスポンサーを中心にスコープを設定することにあります。「ゲートウェイが必要かどうか」という議論ではありません。API Managementを「CPIの前段に置くもの」という枠組みで捉えることを拒否してください。これは、顧客が公開するすべてのAPIに対するコンシューマーエクスペリエンスレイヤーです。

次に読むべきもの#