💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 認可はもう一行の if 文ではない

2026 年の SaaS バックエンドで最も頻繁に聞こえるフレーズが「認可がまた壊れた」だ。キャピタル・ワン事件以降、クラウド IAM の隙間に対する警戒が業界全体に広がり、GDPR-K(韓国 PIPA 強化案)、日本の APPI 2025 改正、EU AI Act のすべてが「誰が何にアクセスしたか」を監査可能な形で残すよう要求している。`if user.role == "admin"` の一行で終わらせていた時代は明確に終わった。

転換点は、2019 年に Google が USENIX ATC で公開した Zanzibar 論文だった。YouTube、Drive、カレンダー、クラウドコンソールがすべて同じ認可バックエンドを使っているという事実自体が衝撃で、さらに衝撃的だったのは、そのバックエンドが「関係(relationship)」というたった一つの抽象で RBAC、ABAC、共有リンク、フォルダ継承、グループ権限のすべてを表現していることだった。それから 7 年経った 2026 年、市場は **Zanzibar スタイル(ReBAC)陣営**と **ポリシー言語陣営(OPA、Cedar、Cerbos)** の二つに分かれている。

この記事はその地図だ。SpiceDB(AuthZed)、OpenFGA(Auth0/Okta)、Permify、Cerbos、AWS Cedar、Casbin、Oso、Ory Keto、Warrant、Aserto、Topaz がそれぞれどこに位置するのか、どんなトレードオフを抱えているのか、そして韓国・日本のエンタープライズが実際にどう導入したかまで扱う。

1. RBAC と ABAC と ReBAC — 認可の三つの時代

認可モデルは大きく三つの系譜に分岐してきた。

| モデル | 判断基準 | 代表的な実装 | 限界 |

| --- | --- | --- | --- |

核心は **ReBAC が RBAC と ABAC を一般化したモデル** だということ。「user は group の member であり、group は folder の viewer であり、folder は document を contain する」という 4 段の関係こそが認可の本質である。RBAC の「role」はグラフの一つのノードに過ぎず、ABAC の「attribute」は ReBAC では条件付き関係(conditional relation)で表現される。

2026 年の SaaS で最も頻繁に出てくる要件が「このボードを社外ゲストとだけ共有、ただしコメントのみ可」だが、これを純粋な RBAC でモデル化しようとするとロールが爆発する。だから市場は ReBAC と条件付き関係(ABAC を吸収)に収束しつつある。

2. Google Zanzibar — すべてを変えた論文

[Zanzibar 論文(USENIX ATC '19)](https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/) は、たった 19 ページの中に以下を詰め込んでいる。

- 単一の抽象: **(object, relation, user)** のタプル。例: (doc:readme, viewer, user:alice)。

- ネームスペース/リレーションのスキーマで権限モデルを宣言的に定義。

- グローバル一貫性: Spanner の上に **外部一貫性(external consistency)** を保証。

- 新しい一貫性トークン **Zookie** — クライアントが「最低でもこの時点以降のデータを見たい」を表現。

- キャッシュフレンドリーな **snapshot read** と、新しく到着したタプルを高速に処理する **Leopard インデックス**。

- p99 < 10ms の Check API、毎秒一千万件処理。

論文が業界に投げかけたメッセージは明確だった。**「認可は実は分散データベースの問題である」** と。深いグラフ(フォルダのフォルダのフォルダの共有グループのメンバー)の上で権限が一貫して評価されなければならず、そのためには通常の DB ができない一貫性モデルが必要だということ。

3. Zanzibar の内部 — Zookie、snapshot read、Leopard

論文で最も頻繁に引用される三つのメカニズム。

**Zookie(一貫性トークン)**。クライアントが「このユーザーは今まさに権限を付与された」という事実を知っている場合、Zookie を受け取って次の Check リクエストに添付する。Zanzibar はその Zookie 以降の状態でのみ評価する。キャッシュ一貫性と新鮮さの間のトレードオフをクライアントが選べるように設計されている。

**Snapshot read**。ほとんどの Check 呼び出しは「強い新鮮さを必要としない」通常の参照だ。Spanner の時点スナップショット読み込みでキャッシュヒット率を最大化する。p99 キャッシュヒット率は 90% 以上と報告されている。

**Leopard インデックス**。Spanner はグラフトラバーサルに最適化されていない。そのため頻繁に評価されるグループメンバーシップ(例: googlers グループの全メンバー)を別途インデックス化し、一種の materialized view として保持する。新メンバーが追加されると Leopard が非同期で更新する。

**Watch API**。タプルが変更されると購読者に通知する。外部キャッシュ(例: Akamai の権限キャッシュ)を無効化するチャネル。

4. Zanzibar の系譜 — 誰が何を作ったか

論文が出てから業界がどう分かれたかを一覧で。

| --- | --- | --- | --- | --- |

ポリシー言語陣営も整理すると:

| --- | --- | --- | --- | --- |

5. SpiceDB (AuthZed) — Zanzibar に最も忠実な実装

[SpiceDB](https://authzed.com/) は Zanzibar 論文の著者周辺のエンジニアが助言に参加した実装で、2026 年現在「Zanzibar スタイル FGA の事実上の標準」となっている。Apache 2.0 と商用 SaaS(Authzed Cloud)のデュアルモデル。

SpiceDB スキーマ例: 文書共有とフォルダ継承

definition user {}

definition organization {

relation member: user

}

definition folder {

relation parent: folder

relation owner: user

relation viewer: user | organization#member

permission view = viewer + owner + parent->view

permission edit = owner + parent->edit

}

definition document {

relation parent: folder

relation owner: user

relation viewer: user | organization#member

permission view = viewer + owner + parent->view

permission edit = owner + parent->edit

permission delete = owner + parent->edit

}

主要文法: **+** は和集合、**&** は交集合、**-** は差集合、**parent->view** は「親の view 権限を継承する」という意味。この一つのファイルで RBAC、ABAC(条件付き関係拡張時)、フォルダ継承、グループ権限のすべてが表現される。

性能: 単一ノードで p99 < 10ms の Check API、水平スケール時には毎秒数十万 Check。

6. OpenFGA — Auth0/Okta の製品

[OpenFGA](https://openfga.dev/) は Auth0(現 Okta)が 2022 年にオープンソースとして公開した Zanzibar 実装である。2023 年に CNCF Sandbox に入り、2024 年に卒業トラックへ進んだ。JSON ベースのモデル定義と豊富な SDK(Node、Go、Python、Java、.NET、Ruby)が強み。

OpenFGA モデル (DSL 形式、内部的に JSON にコンパイル)

model

schema 1.1

type user

type organization

relations

define member: [user]

type folder

relations

define parent: [folder]

define owner: [user]

define viewer: [user, organization#member]

define view: viewer or owner or view from parent

define edit: owner or edit from parent

type document

relations

define parent: [folder]

define owner: [user]

define viewer: [user, organization#member]

define view: viewer or owner or view from parent

define edit: owner or edit from parent

SpiceDB とほぼ同等の表現力。差異は SDK エコシステムとホスティング(Auth0 FGA がマネージド SaaS)、そして Okta Identity Cloud との統合である。

7. Permify — オープンソースの挑戦者

[Permify](https://permify.co/) はイスタンブール出身のチームが作ったもう一つの Zanzibar 実装。差別化ポイントは **Postgres を一級バックエンドとしてサポート** することと、DSL が SpiceDB / OpenFGA より簡潔なこと。

Permify Check API 呼び出し例

curl -X POST 'http://localhost:3476/v1/tenants/t1/permissions/check' \

-H 'Content-Type: application/json' \

-d '{

"metadata": {

"schema_version": "",

"snap_token": "",

"depth": 20

"entity": {

"type": "document",

"id": "readme"

"permission": "view",

"subject": {

"type": "user",

"id": "alice"

}

応答は `{ "can": "CHECK_RESULT_ALLOWED" }` のような形式。snap_token は SpiceDB の ZedToken / Zanzibar の Zookie に対応する。

8. Cerbos — ポリシー駆動、関係駆動ではない

[Cerbos](https://cerbos.dev/) は Zanzibar 陣営とは色合いが異なる。**関係グラフを保持しない** ステートレスなポリシー決定点(PDP: Policy Decision Point)を標榜する。ポリシーは YAML で記述し、コンテキスト(主体、リソース、環境)は呼び出し側が毎回提供する。

Cerbos ポリシー例: 休暇申請承認

apiVersion: api.cerbos.dev/v1

resourcePolicy:

version: "default"

resource: "leave_request"

rules:

- actions: ['view']

effect: EFFECT_ALLOW

roles:

- employee

condition:

match:

expr: request.principal.id == request.resource.attr.ownerId

- actions: ['approve']

effect: EFFECT_ALLOW

roles:

- manager

condition:

match:

all:

of:

- expr: request.resource.attr.status == "PENDING"

- expr: request.principal.attr.department == request.resource.attr.department

Cerbos はサイドカーとしてデプロイしやすく、ポリシーが GitOps フレンドリーで、決定がステートレスなのでキャッシュしやすい。一方で「user:alice はどのフォルダにアクセスできるか」のような ListObjects 系のクエリは弱い。

9. AWS Cedar — 検証可能なポリシー言語

[Cedar](https://www.cedarpolicy.com/) は AWS が 2023 年 5 月にオープンソースとして公開したポリシー言語である。Amazon Verified Permissions のエンジンとして使われ、AVP(Amazon 検証権限)は AWS コンソールから直接利用できる。Cedar の最大の特徴は **数学的に検証可能なポリシー** であること: Cedar のポリシーは Rust で実装された分析器(symbolic analyzer)で「このポリシーは常に安全か」を証明できる。

// Cedar ポリシー例: 文書編集権限

permit (

principal in Group::"engineering",

action == Action::"editDocument",

resource

)

when {

resource has owner &&

(principal == resource.owner ||

principal in resource.editors)

};

forbid (

principal,

action == Action::"deleteDocument",

resource

)

unless {

principal in Group::"admins"

};

既定のセマンティクスは ABAC だが、principal / resource がグループメンバーシップを通じて階層化されるので ReBAC も表現可能。MIT などとの学術連携を通じて、ポリシー検証の形式意味論まで論文として発表されている。

10. Casbin — 可変モデルの行列アプローチ

[Casbin](https://casbin.org/) は 2017 年から始まったオープンソースプロジェクトで、30 以上の言語 SDK をサポートする最も汎用的な認可ライブラリだ。差別化ポイントは **モデル自体が設定ファイル** であること。RBAC、ABAC、ドメイン付き RBAC、ACL のどんなモデルでも PERM(Policy、Effect、Request、Matchers)の四部モデルで表現する。

Casbin RBAC with domains モデル

[request_definition]

r = sub, dom, obj, act

[policy_definition]

p = sub, dom, obj, act

[role_definition]

g = _, _, _

[policy_effect]

e = some(where (p.eft == allow))

[matchers]

m = g(r.sub, p.sub, r.dom) && r.dom == p.dom && r.obj == p.obj && r.act == p.act

policy.csv 例

p, admin, tenant1, data1, read

p, admin, tenant1, data1, write

g, alice, admin, tenant1

Casbin はライブラリとして組み込まれるモデルが強み(別途サーバー不要)。短所はモデル表現が自由な分、Zanzibar のようなグローバル一貫性保証は自前で実装する必要があること。

11. Oso — Polar で組み込む認可

[Oso](https://www.osohq.com/) は 2020 年に始まった認可スタートアップで、独自のポリシー言語 **Polar**(Prolog 着想)を提供する。2024 年に SaaS の Oso Cloud に転換し、オープンソースの組み込みライブラリも維持している。強みは **ホスト言語(Python、Node、Rust)のオブジェクトと自然に統合される** こと。

Polar のポリシーは一行で自然言語のように読める: `allow(actor, "read", resource) if actor in resource.viewers;`。

Oso Cloud はデータ同期モデル(アプリケーション DB の変更を fact として流す)を通じて Zanzibar スタイルの中央権限ストアの役割も果たす。ライセンスは Apache 2.0 と商用クラウドのデュアル。

12. Ory Keto / Warrant / Aserto / Topaz — 脇役たち

- **[Ory Keto](https://www.ory.sh/keto/)**: Ory エコシステム(Hydra OAuth2、Kratos Identity)の認可コンポーネント。初期は ACL モデルだったが、2021 年に Zanzibar モデルで書き直された。Go で実装。

- **Warrant**: 2022 年 YC W22 出身。Zanzibar 忠実実装、2023 年に Okta が買収し OpenFGA と統合。

- **[Aserto](https://www.aserto.com/)**: Zanzibar ディレクトリと OPA Rego のハイブリッド。セルフホスト + SaaS。

- **[Topaz](https://www.topaz.sh/)**: Aserto が作ったオープンソースコア。サイドカー形式でデプロイし、ディレクトリと政策を組み合わせる。

特に Topaz は興味深く、「関係グラフ(誰が誰のメンバーか)は Zanzibar で、ポリシー決定(このアクションは許可されるか)は Rego で」というハイブリッドモデルを明示的に提案している。

13. OPA (Open Policy Agent) — 汎用ポリシーエンジン

[OPA](https://www.openpolicyagent.org/) は 2016 年に始まった CNCF 卒業プロジェクトで、認可に限定されない **汎用ポリシーエンジン** だ。Kubernetes アドミッションコントロール、Envoy / Istio のポリシー、Terraform ポリシー、CI/CD ゲートなどあらゆる場所で使われる。ポリシー言語は Datalog 着想の **Rego**。

Rego ポリシー例: 文書アクセス

package documents.authz

default allow := false

allow if {

input.action == "view"

input.user.id == input.resource.owner

}

allow if {

input.action == "view"

input.user.id in input.resource.viewers

}

allow if {

input.action in {"view", "edit"}

input.user.role == "admin"

}

allow if {

input.action == "view"

group := input.resource.groups[_]

group in input.user.groups

}

OPA の長所は表現力とエコシステム。短所は関係グラフのストアが一級でないこと(別途データ同期が必要)、そして Rego の学習曲線が急なこと。

14. Check API — FGA の心臓

すべての FGA システムの中核 API は一つだけ: **Check**。「主体 S がリソース R に対してアクション A を実行できるか」を boolean で返す。

// SpiceDB Go SDK の例

client := authzed.NewClient("localhost:50051", grpcOpts...)

resp, err := client.CheckPermission(ctx, &v1.CheckPermissionRequest{

Resource: &v1.ObjectReference{

ObjectType: "document",

ObjectId: "readme",

Permission: "view",

Subject: &v1.SubjectReference{

Object: &v1.ObjectReference{

ObjectType: "user",

ObjectId: "alice",

Consistency: &v1.Consistency{

Requirement: &v1.Consistency_MinimizeLatency{MinimizeLatency: true},

})

if resp.Permissionship == v1.CheckPermissionResponse_PERMISSIONSHIP_HAS_PERMISSION {

// 許可

}

主要なパラメータ:

- **Consistency**: MinimizeLatency(キャッシュ優先)、AtLeastAsFresh(Zookie 以降の時点)、FullyConsistent(常に最新、コスト高)から選択。

- **Resource / Permission / Subject**: 標準の (object, relation, user) タプル。

p99 < 10ms が SpiceDB と OpenFGA が共通で目指す SLO である。

15. ListObjects と ListRelations — 高コストなクエリ

Check は単一の boolean だが、実際の UI はもっと複雑なクエリを要求する。

- **ListObjects(user, permission)**: 「alice が view できるすべての文書」 — ファイル一覧 UI に必須。

- **ListRelations(resource, permission)**: 「この文書に view 権限を持つすべてのユーザー」 — 共有ダイアログに必須。

- **Lookup(user, resource)**: 「alice がこの文書に対して持つすべての権限」 — 権限デバッグに必須。

ListObjects はグラフの逆方向トラバーサルなので、Check よりはるかに高コストだ。SpiceDB は別途 `LookupResources` API を、OpenFGA は `ListObjects` を提供する。両システムとも結果数が多くなるとページネーションが必要になる。

// OpenFGA ListObjects の応答例

{

"objects": [

"document:readme",

"document:design-doc",

"document:budget-2026"

]

}

UI のページネーションと統合するときによく見るアンチパターン: ListObjects ですべてを取得してクライアント側でページ分割 — 権限数が増えると爆発する。正解は DB のページネーションと組み合わせた **filtered list**(例えば SpiceDB のカーソルベースのページネーション)。

16. スキーマ設計 — ネームスペース、リレーション、コンディション

Zanzibar スタイル FGA のスキーマ設計でよく落ちる落とし穴。

1. **リソースタイプを細かく分けすぎるな**。「Document、Image、Video、Audio、PDF」よりも、type 属性を持つ単一の「asset」のほうが ListObjects のコストを下げる。

2. **グループを一級市民にせよ**。Zanzibar の強みはグループメンバーシップのトラバーサルだ。グループを独立したネームスペースにしないとその強みが死ぬ。

3. **条件付き関係は ABAC を吸収する道具**。SpiceDB の [Caveats](https://authzed.com/docs/spicedb/concepts/caveats)、OpenFGA の [Conditions](https://openfga.dev/docs/modeling/conditions) で「月曜日のみ、社内 IP の場合のみ」のような ABAC 条件を表現できる。

4. **権限と関係を区別せよ**。`relation viewer: user` はデータ(誰が viewer か)で、`permission view = viewer + owner` は計算(view は viewer または owner)だ。権限を直接付与せず、関係だけを付与すること。

17. マルチテナント隔離パターン

SaaS で最も頻繁な要件。同じ FGA バックエンドで複数テナントのデータをどう隔離するか。

三つのパターン:

1. **テナント prefix**: object_id の前にテナント接頭辞を付ける。例: `document:tenant1/readme`。単純だがクロステナントクエリに弱い。

2. **テナントネームスペース**: テナントごとに別個に定義。スキーマが同じように複製され管理コストが膨らむ。

3. **テナントオブジェクトをルートに**: `definition tenant { relation member: user }` を作り、すべてのリソースが `relation tenant: tenant` を持つ。すべての権限計算が tenant->member を経由するよう強制する。最も推奨されるパターン。

Permify は明示的に [マルチテナンシーを一級としてサポート](https://docs.permify.co/getting-started/multi-tenancy) する(`/v1/tenants/{tenantId}/...` API)。SpiceDB と OpenFGA はスキーマで表現する。

18. Postgres RLS — フォールバックまたは補完

[Postgres Row-Level Security](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) は DB レイヤで認可を強制するメカニズムだ。FGA を導入する前、単純なマルチテナンシー程度なら RLS だけで十分。

-- Postgres RLS: マルチテナント隔離

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON documents

USING (tenant_id = current_setting('app.current_tenant')::uuid);

CREATE POLICY user_owned ON documents

USING (owner_id = current_setting('app.current_user')::uuid);

-- アプリケーション側

SET app.current_tenant = '550e8400-e29b-41d4-a716-446655440000';

SET app.current_user = '7a8e9c00-1234-5678-9abc-def012345678';

SELECT * FROM documents; -- 自動的にフィルタリング

RLS の長所: アプリケーションにバグがあっても DB が止めてくれる。短所: 深い関係グラフ(グループのグループのフォルダ)には非常に弱い。だから 2026 年の推奨パターンは **FGA を上位決定、RLS をバックストップ** の二段防御だ。Supabase が RLS を中核機能としてマーケティングする理由でもある。

19. 性能 — レイテンシと一貫性のトレードオフ

FGA の性能を決める三つの軸。

1. **グラフの深さ**: リソースからユーザーまでのパスが深いほど Check のコストが増える。Zanzibar は通常 5 段以内に制限。

2. **グラフの広さ(fan-out)**: 一つのグループに 100 万人のメンバーがいると Leopard のような事前インデックスなしでは高コストになる。

3. **一貫性要求**: MinimizeLatency(キャッシュ OK)と FullyConsistent(常に最新)の選択が p99 を支配する。

| --- | --- | --- | --- | --- |

| Permify | `<20ms` | `<150ms` | あり | 中規模 SaaS |

| OPA | `<5ms` | `<15ms` | なし | 一般ポリシー決定 |

Cerbos / OPA は Check 自体は速いが、ListObjects のようなグラフクエリができないことを常に覚えておくこと。

20. エッジ認可 — Cloudflare、Fastly + OPA

2025 年以降に台頭したパターン: **エッジで認可を決定する**。Cloudflare Workers、Fastly Compute@Edge、AWS Lambda@Edge で OPA WASM バンドルや SpiceDB のキャッシュを立て、オリジンに到達する前に権限を拒否する。

長所: グローバル分散 SaaS で p50 < 10ms の認可、オリジン負荷の軽減、DDoS グレードの拒否。

短所: ポリシー変更の伝播遅延、エッジノードごとのキャッシュ一貫性問題。

[OPA WASM](https://www.openpolicyagent.org/docs/latest/wasm/) は Rego ポリシーを WASM モジュールにコンパイルし、あらゆるランタイムに組み込めるようにする。SpiceDB は [Materialize API](https://authzed.com/docs/spicedb/concepts/datastores#materialize-api) を通じて権限グラフの変更を外部キャッシュにストリームする。

21. Zanzibar スタイルと OPA スタイル — どう選ぶか

最も頻繁に受ける質問。決定木:

1. **データは関係グラフか?** 「このフォルダはあのフォルダの子で、あのフォルダは...」のような深さ 3 以上のグラフがあるなら → Zanzibar スタイル(SpiceDB、OpenFGA、Permify)。

2. **データは平坦でポリシーが複雑か?** 「管理者は平日 9-6 の社内 IP からのみ、外注は NDA 署名者のみ...」のような条件が多いなら → OPA / Cedar / Cerbos。

3. **両方必要か?** → Topaz / Aserto のようなハイブリッド、または SpiceDB と OPA の組み合わせ。

4. **組み込みが必要か?** → Casbin / Oso(ライブラリ組み込み)。

5. **AWS のみを使うか?** → Amazon Verified Permissions(Cedar マネージド)。

22. SaaS とセルフホスティング

| --- | --- | --- | --- |

| Auth0 FGA (OpenFGA) | $$ | なし | Okta リージョン |

| Permify Cloud | $$ | なし | EU / US 選択 |

| Amazon Verified Permissions | $ | なし | AWS リージョン |

| Topaz / Aserto サイドカー | $ | 少 | 完全制御 |

データ主権が核心の韓国金融セクター / 公共 / 日本エンタープライズはセルフホスティングがほぼ強制される。グローバル SaaS スタートアップは Authzed Cloud / Auth0 FGA を素早く導入する傾向。

23. RBAC から ReBAC への移行

既存の RBAC システム(ロールテーブルと権限行列)から ReBAC へ移行する 4 段階のパターン。

1. **二重書き込み(dual write)**: 新しい権限付与時に RBAC テーブルと FGA に同時に記録する。読み込みはまだ RBAC。

2. **シャドウ比較(shadow compare)**: すべての RBAC 決定を FGA でも評価して結果の一致率をメトリックとして追跡する。95% を超えたら次の段階。

3. **読み込み切り替え(read flip)**: フィーチャーフラグで一部のトラフィックを FGA 決定に切り替える。段階的に拡大。

4. **レガシー整理(cleanup)**: RBAC テーブルを削除するか、バックアップ用途のみに維持。

SpiceDB チームの [ブログ](https://authzed.com/blog/) と OpenFGA のドキュメントの両方がこのパターンを推奨している。

24. 事例 — Naver、Kakao、AWS 東京、Cybozu

**Naver Cloud IAM (2024)**: Naver は自社の RBAC + ABAC ハイブリッドを運用していたが、コンテンツ権限(ブログ / カフェ / スマートストア共有)に限って SpiceDB のセルフホストクラスタを導入したと発表。マルチリージョン一貫性要件のため Authzed Cloud は採用しなかった。

**Kakao KOLON 認可 (2025)**: Kakao Works / Kakao Talk チャネルの権限モデルが爆発的に増えたことを受け、Kakao は社内 Zanzibar クローン(コードネーム KOLON)を公開。2026 年のオープンソース化を検討中だと if(kakao) で発表。

**AWS 東京 IAM (2025)**: AWS が日本の金融セクター顧客向けに Amazon Verified Permissions の東京リージョンをローンチ。Cedar ポリシーを通じて日本の APPI 2025 改正による「アクセスログ 5 年保存」要件をメタデータ自動記録で満たす。

**Cybozu kintone (2024)**: 日本 SaaS の代表格 kintone が権限モデルを OpenFGA で再構築。既存は PHP ベースの自社権限エンジンだったが権限グラフが深くなり限界に達した。CNCF KubeCon Japan で事例を発表。

このほかにも、Kakao Bank の社内権限システム、LINE のメッセージ ACL、楽天のモバイルアプリ内権限などが ReBAC への移行事例として報告されている。

25. 2026 年の展望 — 次に来るもの

- **AI エージェント認可**: LLM エージェントがユーザーを代理して行動するとき「このエージェントはどの権限を委任されたか」を表現する新しい関係パターンが必要。Cedar と SpiceDB の両方で 2025 年後半から [delegation](https://authzed.com/blog/) というキーワードの使用が急増。

- **ポリシー形式検証の日常化**: Cedar の検証可能性が他のポリシー言語に拡散。Rego も [OPA の形式検証トラック](https://www.openpolicyagent.org/) が進行中。

- **GraphQL / REST 統合標準**: 権限メタデータを API スキーマにインラインで記述する OpenAPI / GraphQL 拡張標準の作業。OpenFGA が [GraphQL Authorization Extension](https://openfga.dev/) のドラフトを公開。

- **オンプレ GenAI 認可**: 社内 RAG システムで「この文書はこの人が検索結果として見られるか」を検索のたびに評価する。SpiceDB とベクトル DB の組み合わせパターンが [リファレンス実装](https://authzed.com/docs) として登場。

- **認可データの標準化**: 複数の FGA の間でデータ移植性のための標準フォーマット作業が IETF レベルで議論されているという噂。

26. References

- Google Zanzibar 論文 (USENIX ATC '19): https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/

- Zanzibar arXiv: https://arxiv.org/abs/1906.10247

- SpiceDB / AuthZed: https://authzed.com/

- SpiceDB ドキュメント: https://authzed.com/docs/spicedb/getting-started/discovering-spicedb

- OpenFGA: https://openfga.dev/

- OpenFGA モデリングガイド: https://openfga.dev/docs/modeling/getting-started

- Permify: https://permify.co/

- Permify ドキュメント: https://docs.permify.co/

- Cerbos: https://cerbos.dev/

- Cerbos ポリシードキュメント: https://docs.cerbos.dev/cerbos/latest/policies/

- AWS Cedar: https://www.cedarpolicy.com/

- Amazon Verified Permissions: https://aws.amazon.com/verified-permissions/

- Casbin: https://casbin.org/

- Oso: https://www.osohq.com/

- Ory Keto: https://www.ory.sh/keto/

- Aserto: https://www.aserto.com/

- Topaz: https://www.topaz.sh/

- Open Policy Agent (OPA): https://www.openpolicyagent.org/

- OPA Rego 言語: https://www.openpolicyagent.org/docs/latest/policy-language/

- Postgres Row-Level Security: https://www.postgresql.org/docs/current/ddl-rowsecurity.html

- CNCF OpenFGA ページ: https://www.cncf.io/projects/openfga/

- AWS Cedar Language Specification: https://docs.cedarpolicy.com/policies/syntax-grammar.html