Kong連載第2回　Kong API GatewayのAPIルーティングの基本「Service」と「Route」

こんにちは。SCSKの石田です。

今回はKongの連載記事第2回です。
前回の記事では、APIトラフィックの急増やAI活用が進む現代において、なぜ「APIマネジメント」が必要なのか、そしてその解決策としての「Kong API Gateway」の概要についてお伝えしました。

KongにおけるAPIルーティングの基本
なぜ「Service」と「Route」を分けるのか？（分離のメリット）
1. 1. バックエンド改修時の影響を最小化できる
2. 2. プラグイン（ポリシー）の適用範囲を柔軟にコントロールできる
1つのServiceに複数のRouteを設定するユースケース
1. ユースケース1：内部向けと外部向けでセキュリティレベルを変える
2. ユースケース2：段階的なAPIバージョンの移行
やってみた：KongでAPIのルーティングを設定してみる
まとめ

KongにおけるAPIルーティングの基本

第2回となる今回は、Kong API Gatewayを触り始める際に誰もが最初に通る道であり、最も重要な基本概念である「Service（サービス）」と「Route（ルート）」について解説します。

Kong API Gatewayの最大の役割は、「クライアントからのAPIリクエストを受け取り、適切なバックエンドシステム（APIサーバーやマイクロサービスなど）へ安全に受け渡すこと」です。この「交通整理（ルーティング）」を行うために、Kongでは設定を以下の2つの論理エンティティに分けて管理します。

Service（サービス）：「どこへ送るか」の定義。Kongから見たバックエンドの接続先（ホスト名、ポート番号、パス、プロトコルなど）の実体を指します。
Route（ルート）：「どうやって受け取るか」の定義。クライアントがKongに対して送ってくるリクエストの条件（URLパス、ドメイン、HTTPメソッドなど）を指します。

Kongは、クライアントからのリクエストが「Route」の条件に合致すると、それに紐づく「Service」へとトラフィックを転送（プロキシ）する仕組みになっています。

なぜ「Service」と「Route」を分けるのか？（分離のメリット）

一般的なリバースプロキシやシンプルなAPIゲートウェイの中には、入り口（URL）と出口（転送先）を1つの設定ファイルにまとめて記述するものもあります。しかし、Kongはあえてこれらを分離しています。エンタープライズの複雑なシステム環境において、この「疎結合化」は非常に大きなメリットをもたらします。

1. バックエンド改修時の影響を最小化できる

システムを運用していると、「オンプレミスのサーバーからAWS上のコンテナ（ECS Fargateなど）へバックエンドを移行する」といったインフラの変更が必ず発生します。
ServiceとRouteが分離されていれば、バックエンドのIPアドレスやホスト名が変わった際、Kong管理者は「Service」の向き先（URL）を1箇所書き換えるだけで移行が完了します。クライアントがアクセスするURL（Route）は一切変わらないため、API利用者にソースコードの修正を強いることがありません。

2. プラグイン（ポリシー）の適用範囲を柔軟にコントロールできる

Kongの強力な機能である「プラグイン（認証、レート制限、ログ出力など）」は、ServiceにもRouteにも適用できます。

Serviceに適用した場合： そのバックエンドへ向かう「すべての経路」に対して共通のルール（例：必ずバックエンド側で必要な共通ヘッダーを付与するなど）を強制できます。
Routeに適用した場合： 「特定の入り口」から入ってきたリクエストにのみ個別のルール（例：特定のパスのみIP制限をかけるなど）を適用できます。

このように、入り口と出口を分けることで、ポリシー管理の粒度を自由自在に設計できるようになります。

1つのServiceに複数のRouteを設定するユースケース

ServiceとRouteは「1対1」である必要はありません。「1つのServiceに対して、複数のRoute（N）を紐づける」という構成をとることで、1つのバックエンドAPIを様々な用途で安全に使い回すことが可能になります。具体的なユースケースを2つ紹介します。

ユースケース1：内部向けと外部向けでセキュリティレベルを変える

同じ「顧客データ取得API（Service）」に対して、2つの入り口を用意します。

Route A（社内システム用）： パスを /internal/customers とし、社内ネットワークからの通信のため認証プラグインはかけず、高速に処理させる。
Route B（外部パートナー用）： パスを /external/customers とし、外部公開用として厳格なOIDC認証プラグインやレート制限（1分間に100回まで）プラグインを適用してシステムを保護する。

このように、バックエンドの実装は1つのままで、Kongのルーティング設定だけで利用者に合わせたセキュリティを提供できます。

ユースケース2：段階的なAPIバージョンの移行

将来的にAPIの仕様変更を予定している場合、クライアントには /v1/api（Route A）と /v2/api（Route B）という2つのパスを公開しておきます。現状はどちらのRouteも「現行のAPIサーバー（Service）」へ転送しておき、準備が整った段階で /v2/api の裏側だけを「新しいAPIサーバー（新しいService）」へ切り替える、といった運用も容易になります。

やってみた：KongでAPIのルーティングを設定してみる

それでは、実際にKongの「Admin API（管理用API）」を使って、ServiceとRouteの作成からAPIリクエストの転送までをやってみましょう。

今回は、AWS上に構築したKongから、バックエンドとして用意した「AWS Lambda（Function URL）」へルーティングする構成を構築します。Kong自体の構築は、また別途ご紹介します。

事前準備：モック用バックエンド（AWS Lambda）の用意

バックエンドとして、簡易的なJSONを返すLambda関数を作成し、「関数URL（Function URL）」を有効化しておきます。
今回はすぐに消す環境のため、セキュリティ対策として、特定のリクエストヘッダー（x-techharmony-secret: {任意の文字列}）が含まれていないと 401 Unauthorized で弾く簡易的な自衛コードを仕込んでおきます。
なお、この方法をご自身の環境で再現する場合は、URLがパブリックに公開されてしまうため、Lambdaの同時実行数を制限するなどの対策を行ったうえで、動作確認の時だけ有効化し、確認できたらすぐにURLを削除してください。


import json

def lambda_handler(event, context):
    # ヘッダーとパスを取得
    headers = event.get('headers', {})
    path = event.get('rawPath', '/')
    
    # 1. 簡易認証
    if headers.get('x-techharmony-secret') != '{任意の文字列}':
        return {
            'statusCode': 401,
            'body': json.dumps('Unauthorized: Invalid Secret')
        }
    
    # 2. APIパス（Route）をチェックし、'/mock' ではない場合、404 (Not Found) を返す
    if not path.startswith('/mock'):
        return {
            'statusCode': 404,
            'body': json.dumps(f'No Route Found for path: {path}')
        }
    
    # 3. 成功時のレスポンス
    return {
        'statusCode': 200,
        'body': json.dumps({
            'message': 'Hello Kong from Lambda Mock Backend!'
        })
    }

ステップ1：Service（接続先）の作成

まずはKongに「どこへ転送するか」を教えます。先ほど作成したLambdaの関数URLを lambda-service という名前で登録します。（URLなど{}の部分はご自身の環境に読み替えてください。ControlPlaneというものを指定していますが、これについては次回ご説明します。）

curl -i -X POST https://us.api.konghq.com/v2/control-planes/{ControlPlaneのID}/core-entities/services \
  -H "Authorization: Bearer {Kongのアクセストークン}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "lambda-service",
    "url": "{ご自身のLambdaのURL}"
  }'

成功するとHTTP 201が返り、KongにServiceの設定が完了し、バックエンドの場所を認知します。

ステップ2：Route（入り口）の作成

次に、今作成した lambda-service に対して、クライアントからの入り口を作ります。今回は /mock というパスでアクセスが来た場合に転送するよう設定します。

curl -i -X POST https://us.api.konghq.com/v2/control-planes/{{ControlPlaneのID}/core-entities/services/{先ほど作成したServiceのID}/routes \
  -H "Authorization: Bearer {Kongのアクセストークン}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "lambda-route",
    "paths": ["/mock"],
    "strip_path": false
  }'

これで、「{KongのURL}/mock にアクセスが来たらLambdaに転送する」というルーティングの完成です。

ステップ3：実際にAPIへリクエストを送ってみる

設定が正しく機能しているか、Kongの経由でAPIを叩いてみます。Lambda側で要求しているシークレットヘッダー（-H "x-techharmony-secret: {任意の文字列}"）を付与してリクエストを送ります。

curl -i -H "x-techharmony-secret: {任意の文字列}" https://{KongのURL}/mock

【実行結果】

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 51
Connection: keep-alive
Date: Fri, 01 May 2026 09:19:41 GMT
x-amzn-RequestId: e27d062a-9e8c-4135-a3d2-b095bcfdf262
X-Amzn-Trace-Id: Root=1-69f607fc-55f9ec0b2ba8a2ef06e07e21;Parent=0765acf9818f1642;Sampled=0;Lineage=1:2545ac3c:0
Server: kong/3.10.0.9-enterprise-edition
X-Kong-Upstream-Latency: 436
X-Kong-Proxy-Latency: 4
Via: 1.1 kong/3.10.0.9-enterprise-edition
X-Kong-Request-Id: 9c8ed83e804fdc713d84fd1a3533ac66

{"message": "Hello Kong from Lambda Mock Backend!"}

無事にKongを経由して、バックエンドのLambdaからレスポンスが返ってきました！
レスポンスヘッダを見ると、X-Kong-Proxy-Latency（Kongの処理時間）や Via: kong といった、情報が付与されていることが分かります。

まとめ

今回はKong API Gatewayのルーティングの基本について解説しました。

Serviceは「バックエンドの接続先」、Routeは「クライアントへの公開ルール」
2つを分離することで、インフラ変更に強く、柔軟なAPI運用が可能になる
1つのバックエンドに複数の入り口（Route）を作り、それぞれでセキュリティ制御を変えることができる

今回は curl コマンドを使って直接KongのAdmin APIを叩きました。簡単に設定できることがご理解頂けたかと思います。実はdecKというツールもあるので、そちらも別途ご紹介します。

次回は、これらの設定をGUIで行えるだけでなく、複数環境の設定を統合管理したりできるKongのSaaS型プラットフォーム「Kong Konnect」についてご紹介する予定です。

Kongについては当社のホームページでも情報を記載しています。

Kongの導入検討や、API管理基盤のモダナイゼーションについてご相談があれば、ぜひSCSK（kong-sales@scsk.jp）までお問い合わせください。

次回もどうぞお楽しみに！