すべてのプロダクト
Search
ドキュメントセンター

API Gateway:ポリシーとプラグインの設定

最終更新日:Jun 03, 2026

クラウドネイティブ API Gateway は、API レベルおよびオペレーションレベルのポリシーとプラグインにより、セキュリティ、パフォーマンス、保守性を向上させます。

重要
  • ポリシー設定の変更は、API を再公開しなくてもすぐに有効になります。

  • デフォルトでは、API レベルのプラグイン設定はオペレーションレベルに適用されます。

  • API レベルのポリシーは、オペレーションレベルでは削除できません。ただし、オペレーションレベルのポリシーは API レベルのポリシーをオーバーライドできます。

手順

  1. 次のいずれかの方法で API ポリシーを追加します。

    インスタンス外の API

    1. Cloud-native API Gateway コンソールにログインします。左側のナビゲーションペインで [APIs] を選択し、トップメニューバーでリージョンを選択します。

    2. 対象の API をクリックし、ドロップダウンリストから宛先インスタンスを選択します。image

    インスタンス内の API

    1. Cloud-native API Gateway コンソールにログインします。左側のナビゲーションペインで [Instances] を選択し、トップメニューバーでリージョンを選択します。

    2. [Instances] ページで、対象のゲートウェイインスタンスの ID をクリックします。左側のナビゲーションペインで [APIs] を選択し、対象の API をクリックします。

  2. ポリシーとプラグインは、API レベルまたはオペレーションレベルで設定できます。

    • API レベル: API Policy Configuration タブをクリックして、すべての操作に対して API レベルのポリシーとプラグインを設定します。次に、Enable Policy/Plug-in をクリックします。

    • 操作レベル: Operations タブで目的の操作をクリックし、[ポリシー設定] タブをクリックしてから、Enable Policy/Plug-in をクリックします。

  3. Enable Policy/Plug-in パネルで、[ポリシー] または [プラグイン] セクションからポリシーまたはプラグインを選択して設定します。

ポリシー

スロットリングポリシー

スロットリングは、API とオペレーションごとに、指定された期間にわたって設定されたしきい値内でリクエスト量を制御します。同時実行性が高い場合に超過リクエストを拒否することで、外部リクエストがバックエンドサービスに過大な負荷をかけることを防ぎ、連鎖的な障害を回避します。

スロットリングポリシーには、同時実行制御トラフィックシェーピング、および サーキットブレーク が含まれます。

  • 同時実行制御ポリシー: ゲートウェイが処理する同時リクエストの総数を制限します。しきい値に達すると、新しいリクエストは拒否されます。バックエンドの容量に合わせてしきい値を設定してください。

    手順

    Add Policy ページで、[同時実行制御] カードをクリックします。 [ポリシーの追加: 同時実行制御] パネルで、次のパラメーターを設定します。

    パラメーター

    説明

    [Enable or Not]

    同時実行制御ポリシーを有効にします。

    [Overall Concurrency Threshold]

    Overall Concurrency Threshold を設定します。

    [Web Fallback Behavior]

    [Return Specific Content]

    [HTTP Status Code]

    レスポンスのHTTP Status Codeを設定します。デフォルトは 429 です。

    [Type of Returned Content]

    Type of Returned Content で、Regular Text または [application/json] のいずれかを選択します。

    [HTTP Text]

    レスポンスボディのコンテンツを入力します。

    [Return Specific Content]

    [Redirect URL]

    Redirect URL を入力します。

  • トラフィックシェーピングポリシー: API とオペレーションの秒間クエリ数 (QPS) を監視します。QPS がしきい値を超えると、トラフィックの急増からバックエンドサービスを保護するために、新しいリクエストは拒否されます。

    手順

    Add Policy ページで、[トラフィックシェーピング] カードをクリックします。[ポリシーの追加: トラフィックシェーピング] パネルで、以下のパラメーターを設定します。

    パラメーター

    説明

    [Enable or Not]

    トラフィックシェーピングポリシーを有効にします。

    [Overall QPS Threshold]

    Overall QPS Threshold を設定します。

    [Web Fallback Behavior]

    [Return Specific Content]

    [HTTP Status Code]

    レスポンスの HTTP Status Code を設定します。デフォルトは 429 です。

    [Type of Returned Content]

    Type of Returned Content で、Regular Text または application/json を選択します。

    [HTTP Text]

    レスポンスボディのコンテンツを入力します。

    [Redirect to Specified Page]

    [Redirect URL]

    Redirect URL を入力します。

  • サーキットブレークポリシー: API とオペレーションのレスポンス時間またはエラー率を監視します。しきい値に達すると、サーキットブレーカーが作動し、連鎖的な障害を防ぐために設定された期間、後続のリクエストを失敗させます。タイムアウト後、ゲートウェイは限られた数のテストリクエストを許可し、バックエンドが回復したかどうかを確認します。

    手順

    Add Policy ページで、Add Policy カードをクリックします。Add Policy パネルで、次のパラメーターを設定します。

    パラメーター

    説明

    [Enable or Not]

    サーキットブレークポリシーを有効にします。

    [Statistical Window Duration]

    統計分析のための時間枠。有効値: 1 秒~120 分。

    [Minimum Number of Requests]

    Minimum number of requests within a time window required to trigger circuit breaking. If the count is below this value, circuit breaking is not triggered even if the threshold is met.

    [Threshold Type]

    しきい値として、Slow Call Ratio (%) または Exception Ratio (%) のいずれかを選択します。

    1. Slow Call Ratio (%) を選択した場合、Slow Call RT (最大応答時間) を設定する必要があります。この値を超えるリクエストは、スローコールとしてカウントされます。タイムウィンドウ内に (リクエスト数が十分な場合) スローコール率がしきい値を超えると、設定された期間、サーキットブレーキングがトリガーされます。その後、サーキットは半開状態になります:次のリクエストが RT 制限を満たした場合、通常状態に復帰し、それ以外の場合は再びトリップします。

    2. Exception Ratio (%) を選択した場合は、エラー率のしきい値を設定します。十分なリクエストがあるタイムウィンドウ内でエラー率がしきい値を超えると、設定された期間、サーキットブレークがトリガーされます。

    [Slow Call RT]

    許可されるSlow Call RT (最大応答時間) をミリ秒単位で指定します。

    [Circuit Breaking Ratio Threshold]

    スローコールまたはエラー率のしきい値。有効値: 0~100 (0%~100%)。

    遮断期間 (s)

    トリップ後にサーキットが開いたままになる期間。この期間中、リクエストは即座に失敗します (フェイルファスト)。

    [Web Fallback Behavior]

    [Return Specific Content]

    [HTTP Status Code]

    Sets the [HTTP Status Code] for the response. The default is 429.

    [Type of Returned Content]

    Type of Returned Contentで、Regular Textまたは [application/json] を選択します。

    [HTTP Text]

    レスポンスボディのコンテンツを入力します。

    [Redirect to Specified Page]

    [Redirect URL]

    Enter the [Redirect URL].

書き換えポリシー

書き換えポリシーは、バックエンドサービスに転送する前にリクエストパスとホストヘッダーを書き換え、リクエストを正しいエンドポイントに到達させます。

手順

Add Policy ページで、[HTTP 書き換え] をクリックします。 [ポリシーの追加:HTTP 書き換え] パネルで、パラメーターを設定します。

  • パス書き換え

    パス書き換えでは、Cloud-native API Gateway は次の 2 つの書き換えモードに対応しています。

    • 固定値書き換え:オペレーションレベルでのみ対応しています。

    • [Regex Rewrite]:オペレーションレベルと API レベルの両方に対応しています。

    固定値書き換え

    固定値書き換えでは、リクエストのパスプレフィックスを置換できます。

    例 1

    元のリクエストパスは/app/testですが、バックエンドサービスに転送されるパスを/testにする必要があります。推奨設定は次のとおりです。

    • API 操作のマッチング条件: マッチタイプを前方一致に、パスを /app/ に設定します。

    • 書き換えルール: 書き換えタイプを [固定値書き換え]、パスを / に設定します。

    注意

    定数リライトは一致したプレフィックスのみを置き換えるため、操作のマッチングパスは /app/ に設定する必要があります。マッチングパスが /app に設定された場合、書き換えられたパスは //test となり、これは不正です。

    例 2

    元のリクエストパスは /v1/test ですが、バックエンドサービスに転送するパスは /v2/test にする必要があります。推奨設定は次のとおりです。

    • API 操作一致条件: 一致タイプを前方一致に、パスを /v1 に設定します。

    • 書き換えルール: 書き換えタイプを「定数書き換え」に、パスを /v2 に設定します。

    重要

    固定値書き換えでは、API オペレーションの一致タイプが [前方一致] である必要があります。[完全一致] および [正規表現一致] タイプは、固定値書き換えに対応していません。[前方一致] はそのプレフィックスで始まるすべてのリクエストに適用されるため、すべてが書き換えられる点にご注意ください。より具体的に対象を絞り込みたい場合は、代わりに [正規表現書き換え] を使用してください。

    正規表現書き換え

    正規表現書き換えは、正規表現パターンと置換文字列を使用して、元のリクエストパスの一部を書き換えます。パターンは 正規表現の構文 に従います。

    例 1

    元のリクエストパスは /aaa/one/bbb/one/ccc で、バックエンドサービスに転送されるパスを /aaa/two/bbb/two/ccc とする場合、推奨される設定は次のとおりです。

    • API 操作のマッチング条件: マッチタイプを完全一致に、パスを /aaa/one/bbb/one/ccc に設定します。

    • 書き換えルール: 書き換えタイプを Regex Rewrite に、パターンを one に、置換文字列を two に設定します。

    例 2

    元のリクエストパスは /httpbin/(.*)/(.*) に一致します。このパスから /httpbin プレフィックスを削除し、2 つのキャプチャされたグループの位置を入れ替えるには、次の設定が推奨されます。

    • API 操作の一致条件: 一致タイプを正規表現一致に、パスを /httpbin/(.*)/(.*) に設定します。

    • 書き換えルール: 書き換えタイプを「正規表現リライト」、パターンを /httpbin/(.*)/(.*)、置換文字列を /\2/\1 に設定します。ここで、\1 は最初のキャプチャされたグループ、\2 は 2 番目のグループを表します。これは Nginx の $1 および $2 構文と同様です。

    例 3

    パスにバージョンが含まれるバージョン管理された REST API の場合、リクエストをバックエンドに転送する前にバージョンセグメントを削除したいとします。たとえば、元のパス /basePath/version/order/get/basePath/order/get に書き換える場合、推奨される設定は次のとおりです。

    • [API ポリシー設定] を使用して、API レベルでポリシーを適用します。

    • 書き換えルール:書き換えタイプを [正規表現書き換え] に、パターンを (/.*)/version(/.*) に、置換文字列を \1\2 に設定します。ここで、\1 は最初のキャプチャグループを、\2 は 2 番目のキャプチャグループを表します。

    説明

    正規表現書き換えは高度な機能です。可能な場合は、固定値書き換えを使用してください。

  • ホストヘッダー書き換え

    ホストヘッダー書き換えでは、Cloud-native API Gateway は固定値書き換えに対応しています。

    たとえば、元のリクエストの Host ヘッダーが test.com で、バックエンドサービスが dev.com を想定している場合、書き換えポリシーで書き換えホストを dev.com に設定できます。

ヘッダー変更ポリシー

ヘッダー変更では、バックエンドに転送する前のリクエストヘッダー、またはクライアントに返す前のレスポンスヘッダーを変更できます。

手順

Add Policy ページで、Edit Header カードをクリックします。[ポリシーの追加:ヘッダー変更] パネルで、次のパラメーターを設定します。

パラメーター

説明

[Enable]

ヘッダー変更ポリシーを有効化または無効化します。

  • 有効:ゲートウェイは、設定どおりにリクエストヘッダーとレスポンスヘッダーを変更します。

  • 無効:ゲートウェイは、リクエストヘッダーまたはレスポンスヘッダーを変更しません。

[Header Type]

変更するヘッダーのタイプを選択します。

  • [Request]:受信リクエストのヘッダーを変更します。

  • [Response]:送信レスポンスのヘッダーを変更します。

[Operation Type]

実行するアクションを選択します。

  • [Add]:リクエストまたはレスポンスに新しいヘッダーを追加します。

    注意

    同じ名前のヘッダーが既に存在する場合、新しい値はカンマ (,) で区切られ、既存の値に追加されます。

  • [Modify]:リクエストまたはレスポンスで指定されたヘッダーの値を設定します。

    注意

    • 指定されたヘッダーが存在しない場合は追加されます。

    • 指定されたヘッダーが既に存在する場合、その値は上書きされます。

  • [Delete]:リクエストまたはレスポンスから指定されたヘッダーを削除します。

ヘッダーキー

ヘッダー名を入力します。

ヘッダー値

ヘッダーの値を入力します。

CORS ポリシー

オリジン間リソース共有 (CORS) は、異なるオリジン (ドメイン、スキーム、またはポート) からのリソースへのアクセスを制御します。API レベルおよびオペレーションレベルで CORS ポリシーを設定し、許可されたオリジンとリクエストメソッドを指定します。

重要

CORS ポリシーはモックサービスには適用されません。テストするには、実際のバックエンドサービスを設定する必要があります。

手順

Add Policy ページで、CORS カードをクリックします。[Add Policy: CORS] パネルで、次のパラメーターを設定します。

パラメーター

説明

[Enable]

右側の Enable スイッチをオンにします。

  • 有効:設定されたサードパーティのオリジンからのクロスオリジンリクエストを許可します。

  • 無効:サードパーティのオリジンからのすべてのクロスオリジンリクエストを拒否します。

[Allowed Origins]

ブラウザ経由でリソースにアクセスすることを許可するオリジンです。

  • すべてのオリジンを許可:*

  • 指定したルートドメインのオリジンからのアクセスを許可:*.example.com

  • 複数の特定のオリジンを許可する場合:各オリジンは http:// または https:// で始め、改行で区切って入力します。

説明

このパラメーターは、レスポンスヘッダー Access-Control-Allow-Origin を設定します。受信リクエストの Origin ヘッダーがこのリスト内の値と一致する場合、レスポンスの Access-Control-Allow-Origin ヘッダーには、リクエストの Origin ヘッダーの値が設定されます。

[Allowed Methods]

クロスオリジンリクエストで許可する HTTP メソッドです。一般的なメソッドには、GETPOSTPUTDELETEHEADOPTIONSPATCH があります。

説明

このパラメーターは、Access-Control-Allow-Methods ヘッダーを設定します。

[Trusted Request Headers]

クロスオリジンリクエストで許可するリクエストヘッダーです。ブラウザで標準的にサポートされるヘッダー以外も指定できます。

  • すべてのリクエストヘッダーを許可:*

  • 複数の特定のヘッダーを許可する場合は、各ヘッダー名を 1 行ずつ入力します。

説明

このパラメーターは、Access-Control-Allow-Headers ヘッダーを設定します。

[Trusted Response Headers]

ブラウザがアクセスできるレスポンスヘッダーです。

  • すべてのレスポンスヘッダーを公開:*

  • 複数の特定のヘッダーを公開する場合は、各ヘッダー名を 1 行ずつ入力します。

説明

このパラメーターは、Access-Control-Expose-Headers ヘッダーを設定します。

[Allow to Carry Credentials]

ブラウザがクロスオリジンリクエストで認証情報 (Cookie、Authorization ヘッダー) を送信するかどうかを指定します。

説明

このパラメーターは、Access-Control-Allow-Credentials ヘッダーの値を設定します。

[Precheck Expiration Time]

ブラウザが、シンプルリクエストではないリクエストのプリフライト (OPTIONS) レスポンスをキャッシュする期間です。

説明

このパラメーターは、Access-Control-Max-Age ヘッダーを設定します。

トラフィックレプリケーションポリシー

トラフィックレプリケーションは、シミュレーションテストや障害診断のために、ライブトラフィックの一定の割合を指定のサービスにミラーリングします。

手順

Add Policy ページで、Mirror Traffic カードをクリックします。[ポリシーの追加:トラフィックレプリケーション] パネルで、次のパラメーターを設定します。

パラメーター

説明

[Enable]

API のトラフィックレプリケーションポリシーを有効または無効にします。

[Destination Service]

ミラーリングされたトラフィックの転送先サービスです。

説明

送信先サービスは HTTP または HTTPS プロトコルを使用する必要があります。

[Port]

送信先サービスのポートです。動的ポートを選択することもできます。

説明

動的ポートは、ポートが動的に変更されるサービスに適しています。このオプションは、マルチポートサービスではサポートされていません。

[Traffic Mirror Percentage]

ミラーリングするトラフィックの割合。有効値:0~100。

説明

このパラメーターを 50 に設定すると、現在の API のトラフィックの 50% が送信先サービスにミラーリングされます。

タイムアウトポリシー

ゲートウェイがバックエンドのレスポンスを待機する最大時間を設定します。この時間内にレスポンスが受信されない場合、ゲートウェイは HTTP 504 (Gateway Timeout) エラーを返します。

手順

Add Policy ページで、Timeout カードをクリックします。[ポリシーの追加:タイムアウト] パネルで、次のパラメーターを設定します。

説明

タイムアウトポリシーを設定して有効にした後、サービスのタイムアウト動作がビジネス要件を満たすことを確認してください。

パラメーター

説明

[Enable]

タイムアウトポリシーを有効にするかどうかを指定します。

  • 有効:API または操作のタイムアウトポリシーが有効になります。

  • 無効:API または操作のタイムアウトポリシーは無効になります。

[Timeout Period]

API または操作のタイムアウト期間を秒単位で設定します。

説明

0 に設定した場合、またはポリシーが無効な場合、タイムアウトは適用されず、ゲートウェイはレスポンスを無期限に待機します。

リトライポリシー

失敗したリクエストに対して自動リトライを設定します。リトライ条件には、接続失敗、バックエンドサービスの利用不可、特定の HTTP ステータスコードが含まれます。

リトライ条件

バックエンドサービスが 5xx エラーを返した場合、Cloud-native API Gateway は、設定されたリトライ回数に従って失敗したリクエストを自動的にリトライします。

image
  • HTTP プロトコルのリトライ条件は次のとおりです:

    • 5xx:バックエンドサービスが 5xx 応答を返した場合、ゲートウェイはリクエストをリトライします。

      説明

      5xx には、connect-failurerefused-stream が含まれます。

    • reset:接続が切断、リセット、またはタイムアウトした場合、ゲートウェイはリクエストをリトライします。

    • connect-failure:接続に失敗した場合、ゲートウェイはリクエストをリトライします。

    • refused-stream:バックエンドサービスが REFUSED_STREAM エラーコードを返してストリームをリセットした場合、ゲートウェイはリクエストをリトライします。

    • retriable-status-codes:応答の HTTP ステータスコードがユーザー指定のステータスコードのいずれかと一致する場合、ゲートウェイはリクエストをリトライします。

      説明

      リトライステータスコードは、リトライ条件で retriable-status-codes が指定されている場合にのみ使用できます。

  • gRPC プロトコルのリトライ条件は次のとおりです:

    • cancelled:バックエンドの gRPC サービスが cancelled を返した場合にリトライします。

    • deadline-exceeded:バックエンドの gRPC サービスが deadline-exceeded を返した場合にリトライします。

    • internal:バックエンドの gRPC サービスが internal を返した場合にリトライします。

    • resource-exhausted:バックエンドの gRPC サービスが resource-exhausted を返した場合にリトライします。

    • unavailable:バックエンドの gRPC サービスが unavailable を返した場合にリトライします。

手順

Add Policy ページで、Retry カードをクリックします。[ポリシーの追加:リトライ] パネルで、次のパラメーターを設定します。

説明

リトライポリシーを設定して有効化した後、サービスのリトライ動作がビジネス要件を満たしていることを確認してください。

パラメーター

説明

[Enable]

リトライポリシーを有効にするかどうかを指定します。

  • 有効:API または操作のリトライポリシーが有効になります。

  • 無効:API または操作のリトライポリシーは無効になります。

    リトライを無効にしても、ゲートウェイにはデフォルトの内部リトライ設定があります。リトライ回数のデフォルトは 2 で、リトライ条件のデフォルトは connect-failurerefused-streamunavailablecancelled、および retriable-status-codes です。

[Retry Times]

最大リトライ試行回数。有効な値の範囲は 0~10 です。推奨値は 2 以下です。

値が 0 の場合はリトライが無効になります。

[Retry Condition]

リトライをトリガーする条件を指定します。

[Retry Status Code]

リトライをトリガーする HTTP ステータスコードを指定します。複数のコードを設定できます。

重要

Retry Status Code を設定するには、Retry Conditionretriable-status-codes に設定する必要があります。

プラグイン

  1. Add Plug-in タブをクリックします。

  2. Quick Navigation セクションで、種類または名前で目的のプラグインを探し、そのカードをクリックします。

    • プラグインがまだインストールされていない場合は、ダイアログボックスで [Install and Configure] をクリックします。ルールを設定して有効にします。

    • プラグインがすでにインストールされている場合は、ダイアログボックスでルールを設定して有効にします。

  3. [OK] をクリックします。API プラグインリストに戻り、新しいプラグインのステータスを確認できます。

    image