---
title: "Fine-Grained Authorizationを備えたAPIゲートウェイの活用
"
description: "本記事では、Zuplo、Kong、Apache APISIXという異なるAPIゲートウェイについて、およびそれぞれがFGAを使用するサービスにどのように最適に機能するかを解説します。"
authors:
  - name: "Carla Urrea Stabile"
    url: "https://auth0.com/blog/authors/carla-stabile/"
date: "Dec 9, 2025"
category: "Identity & Security"
tags: ["fga", "api gateway", "api"]
url: "https://auth0.com/blog/jp-using-api-gateway-fine-grained-authorization/"
---

# Fine-Grained Authorizationを備えたAPIゲートウェイの活用


>本記事は2025年12月9日に更新された「Using an API Gateway with Fine-Grained Authorization」を翻訳した記事です。

<style>
  li {padding-bottom: .7em; }
  #disqus_thread {display: none;}
</style>

マイクロサービスを扱う際、外部クライアントとの通信を処理するパターンはいくつかあります。システム全体のアクセス制御を決定し、時間とともに急速に変化するFGAサービスと通信する場合、効率的かつスケーラブルに通信を行う必要があります。本記事では、Zuplo、Kong、Apache APISIXという3つのAPIゲートウェイを紹介し、それぞれがFGAを使用するサービスにどのように最適に機能するかを解説します。

## FGAとは

Fine-Grained Authorization (FGA)は、非常に詳細なレベルで、特定のユーザーに特定のリソースに対する特定の操作の実行を許可する認可システムです。FGAは[関係ベースのアクセス制御（ReBAC）](https://auth0.com/blog/relationship-based-access-control-rebac/)に基づいており、Googleの内部認可システムである[Zanzibar](https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/)から着想を得ています。

FGAを使用すると、「`user:carla`は`viewer`関係を介して`document:planning`に関連付けられているか」といった認可チェックに対して、非常に高いパフォーマンスとスケーラビリティで回答を導き出せます。

>Auth0 FGAの詳細については、[Auth0 FGAドキュメント](https://auth0.com/docs/ja-jp/fine-grained-authorization)を確認ください。

[OpenFGA](https://openfga.dev/)はFGAの実装の一つで、Cloud Native Computing Foundation（CNCF）が管理するオープンソースプロジェクトです。OpenFGAプロジェクトは、ホスト型で可用性とスケーラビリティの高い認可サービスである[Auth0 FGA](https://auth0.com/jp/fine-grained-authorization)の基盤となっています。

## APIゲートウェイとは

マイクロサービスアーキテクチャでは、クライアントがバックエンドサービスと通信する方法が必要です。クライアントが複数の異なるバックエンドサービスと通信する代わりに、一つの集約されたサービスとだけ通信し、そのサービスがどのサービスと通信すべきかを判断して応答を返す仕組みをAPIゲートウェイと呼びます。

APIゲートウェイは、クライアントアプリケーションとバックエンドサービス間の単一の入り口として機能します。認証、認可、ルーティング、レート制限などを一元化できます。

例えば、ユーザーのカートに関する情報をリクエストしつつ、ユーザーが認証されているか、その特定のカートを見る権限があるかを確認する必要があるECサイトのクライアントアプリケーションを想定します。少なくとも3つの異なるリクエストを行う代わりに、APIゲートウェイに対して1つのリクエストを行うだけで済みます。APIゲートウェイが適切なサービスにルーティングし、データを収集して1つのレスポンスを返すため、プロセス全体が簡素化されます。

<picture>
<img src="https://images.ctfassets.net/23aumh6u8s0i/7ljjL4IAuQ1jqtNEq8HG5E/ba22994356ab6d21d6de2b2995f92348/api-gateway_diagram.png" alt="APIゲートウェイを介してクライアントとバックエンドサービスが通信する図" style="width:85%; margin: 1em auto; border: solid black 0px; border-radius: 0px;">
</picture>

## 自作かAPIゲートウェイの利用か

企業の規模、ビジネスニーズ、プロジェクトの複雑さに応じて、既存のオプションを使用する代わりにAPIゲートウェイを自作することを検討する場合があります。時間の経過とともに、ロールベースの権限、テナントレベルのレート制限、リトライ、カナリアデプロイのスケーリング、詳細なロギング、あるいはOpenFGAのような外部サービスを呼び出す必要がある認可サービスなど、新しい要件が発生します。自作アプローチは、より多くの制御を可能にします。環境に合わせて調整したものを作成し、コードを可能な限りシンプルに保ち、外部プロジェクトへの依存を避けられます。要件が限られている場合や、トラフィックパターンが独特な場合、または外部の複雑さを最小限に抑えたい場合に適しています。

一方で、既存のソリューションを使用すると、成熟度と多くの組み込み機能が得られます。これらは、FGAのような高度なユースケース向けの高性能なルーティング、安全な通信、統合を処理するように設計されています。また、強力なコミュニティやベンダーのサポートがあるため、エンジニアリングチームの負担を軽減できます。トレードオフとして、ゲートウェイ独自の作法を学習し、その制約に合わせてアーキテクチャを適応させる必要があります。

どちらの方法を選択するかは、チーム次第です。完全な制御を望み、限られた機能セットのみを必要とするチームは自作を好むかもしれません。実証済みの信頼性、迅速なセットアップ、継続的なサポートを求めるチームは、既存のゲートウェイを選択することが多くあります。すべては技術的なニーズ、ビジネス目標、および投資できるリソースに依存します。

## FGAのためのAPIゲートウェイ評価

FGAを処理するAPIゲートウェイを選択する際には、考慮すべき多くの要因があります。パフォーマンスとスケーラビリティ、拡張性、エコシステムの成熟度、ビジネス上のトレードオフという4つの主要なポイントに焦点を当てます。

### 1.パフォーマンスとスケーラビリティ

ゲートウェイはすべてのリクエストの中間に位置するため、そのパフォーマンスはユーザー体験に直接影響します。理想的なゲートウェイは、遅延を最小限に抑え、大量のトラフィックを処理し、需要に応じてスケールアップまたはスケールダウンできる必要があります。FGAのチェックを迅速に行う必要がある場合、キャッシュ、効率的なリクエスト処理、堅牢なロードバランシングなどの機能が特に重要になります。

### 2.拡張性

FGAでは、単純なトークン検証以上の機能が必要になることが多くあります。優れたゲートウェイは、プラグイン、カスタムロジック、またはポリシー統合によって動作を拡張できる必要があります。この柔軟性により、外部のポリシーエンジンとの接続、ユーザーコンテキストによるリクエストの強化、ビジネスニーズに合わせた認可ルールの適用が可能になります。

### 3.エコシステムの成熟度

健全なエコシステムは、ゲートウェイが進化し続け、安全性を維持することへの信頼につながります。これには、活発なコントリビューター、頻繁なリリース、優れたドキュメント、モニタリングツール、ポリシーエンジン、アイデンティティプロバイダーとの統合が含まれます。エコシステムの成熟度は、FGAを実装する際に活用できる共有知識やベストプラクティスが多いことも意味します。

### 4.ビジネス上のトレードオフ

最後に、すべての技術的な選択にはビジネス上の影響が伴います。オープンソースのゲートウェイを自ら運用すればライセンス費用を抑えられるかもしれませんが、運用上の多大な労力が必要になります。マネージドまたは商用のゲートウェイはメンテナンスの負担を軽減できますが、サブスクリプション費用が発生し、柔軟性が低くなる場合もあります。適切なバランスは、チームの規模、スキル、予算によって決まります。

次に、3つのAPIゲートウェイのオプションを、上記の基準に照らして見ていきます。

## オプション1：Zuplo

[Zuplo](https://zuplo.com/)は、開発者体験に重点を置いて構築された、完全にマネージドなクラウドネイティブAPIゲートウェイです。インストールして運用する従来のゲートウェイとは異なり、ZuploはSaaSプラットフォームとして提供されるため、運用の複雑さの多くが解消されます。構成はコード駆動型であり、迅速なオンボーディング、開発者フレンドリーなワークフロー、最新のアイデンティティツールやオブザーバビリティツールとの統合を重視しています。

### FGAのサポート

Zuploは、ゲートウェイ上で直接実行されるJavaScriptベースのポリシーとミドルウェアを介してFGAを実現します。開発者は慣れ親しんだコードを使用して認可ロジックをカスタマイズしたり、簡単なAPI呼び出しを通じて外部のポリシーエンジンやサービス（[OpenFGA Authorization Policy](https://zuplo.com/docs/policies/openfga-authz-inbound)など）と統合したりできます。マネージドサービスであるため、Zuploはこれらのポリシーのスケーリングとデプロイも自動的に処理し、インフラを維持することなくアクセス制御を適用しやすくします。

### 強み

* **パフォーマンスとスケーラビリティ**: SaaS製品であるため、スケーリングやパフォーマンスチューニングが抽象化されており、社内運用なしでグローバルなインフラを利用できます。
* **拡張性**: JavaScriptによるコード駆動型のカスタマイズをサポートしており、柔軟なポリシーを迅速に記述できます。
* **開発者体験**: 強力なツール、明確なドキュメント、最新のワークフローを備え、親しみやすい設計になっています。
* **運用の単純さ**: ゲートウェイインフラ自体を実行または維持する必要がありません。

### 弱み

* **限定的なエコシステムの成熟度**: 比較的新しいサービスであるため、長年続いているオープンソースプロジェクトと比較すると、コミュニティやエコシステムがまだ小規模です。
* **制御の少なさ**: SaaS専用であるため、インフラレベルの詳細をカスタマイズする柔軟性は低くなります。
* **ビジネス上のトレードオフ**: サブスクリプション費用が発生するため、コストを重視するチームにとっては課題になる場合があります。

### 最適なユースケース

* 運用のオーバーヘッドを最小限に抑え、**完全にマネージドなソリューション**を求めるチーム。
* 慣れ親しんだJavaScriptを使用した**迅速なイテレーションとコード駆動型のポリシー**を重視する開発者。
* プラットフォームエンジニアリングに多額の投資をすることなく、**軽量でモダンなゲートウェイ**を探している組織。

## オプション2：Kong Gateway

[Kong](https://konghq.com/)は、最も広く採用されているオープンソースAPIゲートウェイの一つです。Nginxの上に構築され、パフォーマンスのために最適化されています。スタートアップから大企業まで、本番環境で使用されています。Kongには、オープンソース版と、追加の管理機能やセキュリティ機能を提供する商用版のKong Konnectの2つの形態があります。常にスピード、拡張性、エンタープライズ対応に重点を置いています。

### FGAのサポート

Kongは、豊富なプラグインシステムを通じてFGAをサポートします。組み込みの認証・認可プラグインを使用したり、LuaやGoなどのサポートされている言語でカスタムプラグインを作成して機能を拡張したりできます。Kongは、Open Policy Agent（OPA）やOpenFGAなどのポリシーエンジンと、カスタムプラグインまたは[OpenFGA authorization plugin](https://github.com/dol/kong-authz-openfga)のようなコミュニティプロジェクトを介して良好に統合されます。これにより、ゲートウェイ層で複雑なアクセスルールを適用しつつ、ポリシーロジックを専用のサービスに委任できます。

### 強み

* **パフォーマンスとスケーラビリティ**: 非常に大規模な環境でテストされており、重いトラフィック下でも強力なパフォーマンスを発揮します。
* **拡張性**: 成熟したプラグインエコシステムとカスタムロジックのサポートにより、適応性が非常に高くなっています。
* **エコシステムの成熟度**: 強力なコミュニティサポートと商用バックアップを備えた、最も確立されたオープンソースゲートウェイの一つです。
* **エンタープライズ機能**: Kong Konnectにより、集中管理、分析、エンタープライズグレードのサポートが追加されます。

### 弱み

* **運用の複雑さ**: DBレスモードを使用しない限り、大規模なKongの運用には、構成を保存するためのデータベース（PostgresまたはCassandra）などの追加コンポーネントが必要になる場合があります。
* **学習曲線**: プラグインシステムと構成オプションは強力ですが、新規ユーザーには複雑に感じられる場合があります。
* **商用上のトレードオフ**: 高度な機能（Konnectの管理プレーンなど）には商用ライセンスが必要です。

### 最適なユースケース

* 本番環境で**実績のある高性能なゲートウェイ**を必要とするチーム。
* FGAエンジンを統合するための強力な**プラグインの柔軟性**を求める組織。
* **商用サポートや高度な管理機能**を必要とするエンタープライズ企業。

## オプション3：Apache APISIX

[Apache APISIX](https://apisix.apache.org/)は、Apache Software Foundationの下で開発されている、ダイナミックでクラウドネイティブなAPIゲートウェイです。パフォーマンス、プラグイン駆動のアーキテクチャ、そしてKubernetesやサービスメッシュのようなモダンなデプロイモデルへの重点的な取り組みで注目を集めています。Luaで記述され、Nginxとetcdの上に構築されており、エッジゲートウェイから内部サービスルーティングまで、さまざまな環境に対して高度に構成および適応できるように設計されています。

### FGAのサポート

APISIXは、幅広いプラグインと統合を通じてFGAを提供します。[APISIX plugin for integration with OpenFGA](https://github.com/embesozzi/apisix-authz-openfga)のようなコミュニティプラグインを介してOpenFGAなどの外部ポリシーエンジンをサポートしており、外部サービスを呼び出してアクセス制御の決定を適用できます。

### 強み

* **パフォーマンスとスケーラビリティ**: Nginxとetcdをベースに構築されており、非常に高いスループットと低遅延を実現します。
* **拡張性**: 豊富なプラグインエコシステムがあり、Lua、Python、Go、Javaでカスタムプラグインを記述できます。
* **クラウドネイティブ設計**: Kubernetesのファーストクラスサポート、Custom Resource Definition（CRD）による宣言的な構成、サービスメッシュとのシームレスな統合を備えています。
* **オープンなガバナンス**: Apache Foundationの支援を受けており、オープンソースの中立性と活発なコミュニティ開発が保証されています。

### 弱み

* **エコシステムの知名度**: 急速に成長していますが、古いゲートウェイと比較すると、エコシステムが小さく、エンタープライズでの採用事例も少なくなっています。
* **運用の専門知識**: APISIXを効果的に実行および調整するには、Nginx、etcd、Luaに関する知識が必要です。

### 最適なユースケース

* 強力なKubernetes統合を備えた**高性能なクラウドネイティブゲートウェイ**を求めるチーム。
* 複数の言語で**柔軟なプラグイン開発**を行いたい組織。
* **Apacheガバナンスによるオープンソースプロジェクト**と強力なコミュニティの勢いを好む開発者。

## ビジネスに合わせて成長するゲートウェイを見つける

マイクロサービスシステムがより大きく複雑になるにつれて、FGAはモダンなAPIの重要な要素になりつつあります。APIゲートウェイは、リクエストの処理、認証の適用、コンテキストの追加、認可ポリシーのチェックを行うため、この中心的な役割を担います。

本記事では、ゲートウェイを選択する際に考慮すべき主な事項を提示しました。

* パフォーマンス
* 拡張性
* コミュニティの成熟度
* ビジネス上のトレードオフ

また、Kong、Apache APISIX、Zuploがこれらの領域にどのようにアプローチしているかを探りました。それぞれのツールには、オープンソースプロジェクトの柔軟性からマネージドプラットフォームの単純さまで、異なる選択肢があります。

この概要を参考にさらに調査を進め、システムの成長に合わせてニーズに合うゲートウェイを選択してください。Auth0 FGAの詳細については、[ドキュメント](https://auth0.com/docs/ja-jp/fine-grained-authorization)を確認ください。