Google Zanzibar: 次世代分散型認可システムに関する包括的技術レポート

エグゼクティブサマリー

本レポートは、Googleが開発したグローバル規模の認可システム「Zanzibar」に関する、シニア技術リーダー向けの包括的な技術分析を提供する。Zanzibarは単なる技術ではなく、認可のパラダイムシフトを象徴するものである。従来、各アプリケーション内に散在していた認可ロジックを、一貫性を持ち、グローバルに利用可能な中央集権型サービスへと移行させた。このアーキテクチャは、今日の複雑な分散システムにおける認可の課題に対する、先進的な解決策を提示している。

本レポートの主要な結論は以下の通りである。

• 設計思想と動機: Zanzibarの設計は、ハイパースケール環境における分散型認可の失敗、特に一貫性の欠如とエンジニアリングの重複という課題への直接的な対応である。その設計は、一貫性、柔軟性、そしてパフォーマンスを最優先事項としている 。  
• 中核的イノベーション: Zanzibarの核心的なイノベーションは、リレーションシップベースアクセスコントロール（ReBAC）モデルと、グローバルに一貫性を持つデータストア（Spanner）、そして「ズーキー（Zookies）」と呼ばれるスナップショット読み取りメカニズムの組み合わせにある。これにより、低レイテンシを犠牲にすることなく、認可判断の正確性が保証される 。  
• エコシステムの形成: 2019年に公開されたZanzibarの論文は、新たなオープンソース認可データベースのエコシステムを触発した。その中でも特に著名なのがAuthzed SpiceDBとOry Ketoであり、それぞれが実装と統合に関して異なる哲学を提示している 。  
• 戦略的課題: Zanzibarスタイルのシステムを導入する上での最大の戦略的課題は、「中央集権化のトレードオフ」である。これは、認可に関連する全てのデータをシステムに移行する必要があることを意味し、大規模なエンジニアリング投資を必要とする 。  
• 将来展望: Zanzibarモデルの柔軟性とスケーラビリティは、複雑なエンタープライズ環境におけるAIエージェントの権限管理など、新たな技術的課題に対して特に有効である 。  

本レポートは、Zanzibarの技術的詳細、アーキテクチャ、実用上の考慮事項、そしてオープンソース実装の比較分析を通じて、次世代認可システムの導入を検討する技術リーダーに戦略的な洞察を提供することを目的とする。

Google Zanzibarの起源と哲学

この章では、Zanzibarが「なぜ」そして「何を」解決するために生まれたのかという根源的な問いを探求し、Googleの規模で直面した特定の問題クラスに対する解決策として位置づける。

Zanzibar以前の問題領域: スケールと一貫性の危機

Zanzibarが登場する以前のGoogleにおける認可システムは、断片化された状況にあった。各アプリケーションが独自のアクセスコントロールメカニズムを個別に実装・運用しており、これは深刻な問題を引き起こしていた 。この分散型アプローチは、一貫性のないユーザーエクスペリエンス、エンジニアリングリソースの重複、そしてサービス間での信頼性の高い認可チェックの不能といった課題を生み出した 。  

具体的な例として、Gmailでメールを作成する際に、リンクされたGoogle Driveドキュメントへのアクセス権が受信者にない場合に警告を発するという機能がある。サイロ化された権限システムでは、このようなサービス横断的なチェックは困難で、非常に脆弱なものとなっていた 。  

このシステムは、Google+のサークル、カレンダー、Drive、マップ、フォト、YouTubeといった、数十億のオブジェクトとユーザーを管理するプロダクトをサポートする必要性から生まれた 。これらの要求に応えるため、Zanzibarは5つの厳格な設計原則を掲げた。  

1. 正確性 (Correctness): 認可判断は、ACLの変更とコンテンツの変更の因果的順序を尊重しなければならない。
2. 柔軟性 (Flexibility): 多様なアクセスコントロールポリシーを表現できる必要がある。
3. 低レイテンシ (Low Latency): 95パーセンタイルで10ミリ秒未満の応答時間を目標とする。
4. 高可用性 (High Availability): 99.999%以上の可用性を維持する。
5. 大規模スケール (Large Scale): 数兆のACLと毎秒数百万のクエリ（QPS）を処理できること 。  

コアデータモデル: 関係タプルと名前空間

Zanzibarのデータモデルの根幹をなすのは、「関係タプル（relation tuple）」と呼ばれる基本的なデータプリミティブである。これは認可データの原子単位であり、object#relation@subjectという形式で表現される 。  

このタプルの各構成要素は以下の通りである。

• Object: 保護対象のリソース。型と一意のIDで識別される（例: document:quarterly-report） 。  
• Relation: オブジェクトとサブジェクト間の関係性を定義する（例: owner, editor, viewer） 。  
• Subject: アクセスを要求するエンティティ。ユーザーID（例: user:alice）だけでなく、別のオブジェクトとリレーションのペア、すなわち「ユーザーセット（userset）」を指定することもできる（例: group:marketing#member） 。このユーザーセットのネスト機能は、グループの階層構造や権限移譲をモデリングする上で極めて重要である。  

このデータモデルの柔軟性は、ユーザーと他のエンティティとの間の区別をなくし、すべてを「オブジェクト」として統一的に扱うことから生まれる。関係タプルのサブジェクトは、user:aliceのような具体的なユーザーでも、group:marketing#memberのような別のオブジェクトとリレーションのペアでもあり得る 。これは、グループが単なるオブジェクトであり、メンバーシップがリレーションであることを意味する。同様に、フォルダもオブジェクトであり、その親子関係もリレーションで表現される。この統一的な表現方法により、RBACのような単純なモデルでは限界があった、グループ内グループやフォルダ内フォルダといった任意かつ深い階層構造を、特別な処理なしでモデリングすることが可能になる 。SpiceDBのような実装では、この考え方をさらに推し進め、「ユーザー」という特別な概念を完全に取り払い、APIキーのような非人間エンティティも第一級のサブジェクトとして扱えるようにしている 。これは、モデルの強力さがその抽象的かつ統一的な性質に由来することを示している。  

また、「名前空間（Namespaces）」は、オブジェクトの型とその型が持ちうるリレーションを定義するスキーマとして機能する。Googleの実装ではProtocol Buffersを用いて定義される 。名前空間は、  

Docs:secret_projectとCalendar:secret_projectのように、異なるサービス間での名前の衝突を防ぎ、データモデルを構造化する役割を果たす 。  

さらに、「ユーザーセットリライト（Userset Rewrites）」は、単純なリレーションを集合演算（和集合、積集合、差集合）を用いて組み合わせることで、複雑な関係性を定義するメカニズムである。例えば、「viewer（閲覧者）」は、「editor（編集者）」であるか、または直接の「viewer」である、と定義できる 。これが権限継承の基礎を形成する。  

指導哲学: 文脈の中のリレーションシップベースアクセスコントロール（ReBAC）

Zanzibarの指導哲学は、**リレーションシップベースアクセスコントロール（Relationship-Based Access Control, ReBAC）**である。このモデルでは、アクセス権はサブジェクトとオブジェクト間の関係性の有向グラフを走査することによって決定される 。「  

user:aliceはdocument:reportを閲覧できるか？」というチェックは、「document:report#viewからuser:aliceへのパスがグラフ上に存在するか？」というグラフ走査問題に変換される 。  

Zanzibarの論文はReBACの概念を広く普及させたが、この概念自体はそれ以前から存在していた 。Zanzibarの強みを理解するために、他の主要なアクセスコントロールモデルとの比較を行うことが不可欠である。  

• RBAC (ロールベースアクセスコントロール): 静的な「ロール」に権限を割り当てる。単純だが柔軟性に欠け、複雑なシナリオでは「ロール爆発」と呼ばれる問題に直面する 。Zanzibarは、ロールをグループとして扱う（例:   role:admin#member@user:bob）ことで、RBACをモデリングすることが可能である 。  
• ABAC (属性ベースアクセスコントロール): ユーザー、リソース、環境の動的な「属性」を使用する。非常に柔軟だが、管理や監査が複雑になる可能性がある 。Zanzibarのコアモデルは属性ベースではないが、SpiceDBのような実装では「caveat」という機能を追加してこのギャップを埋めている 。  
• ReBACの得意領域: フォルダとファイル、組織とチームのような自然な階層構造や、権限が継承・委譲されるソーシャルグラフのモデリングに非常に優れている 。  

以下の表は、これらのアクセスコントロールモデルを多角的に比較したものである。

表1: アクセスコントロールモデルの比較分析 (RBAC vs. ABAC vs. ReBAC)

一貫性の要請: 「ズーキー」と「新しい敵問題」

Zanzibarの設計における最も重要な側面の一つは、一貫性の保証である。この文脈で登場するのが「新しい敵問題（New Enemy Problem）」である。これは、分散システムにおいて権限の変更とコンテンツの変更が因果的に順序付けられていない場合に発生する競合状態の一種であり、不正なアクセス判断につながる可能性がある 。  

• 例A: アリスがフォルダのACLからボブを削除した後、新しいドキュメントをそのフォルダに追加する。もし新しいドキュメントに対するACLチェックが、古い（ボブがまだ含まれている）フォルダの権限を読み込んでしまうと、ボブは不正にアクセスできてしまう可能性がある 。  
• 例B: アリスがドキュメントのACLからボブを削除した後、そのドキュメントに新しいコンテンツを追加する。もしコンテンツのチェックが古いACL（ボブが削除される前）で評価されると、ボブは新しいコンテンツを閲覧できてしまう可能性がある 。  

Zanzibarの設計は、単に権限を保存するだけでなく、本質的に権限の因果的順序を保証するシステムである。ReBACモデルが「何を」保存するかを定義するのに対し、ズーキープロトコルは「どのように」それを大規模かつ正確に機能させるかを定義する。多くのシステムは関係性を保存できるが、グローバルな分散環境で高スループットを維持しながら正確性を保証できるシステムは稀である。したがって、真のイノベーションはデータモデルそのものよりも、分散システムにおける一貫性という、はるかに困難な問題を解決するための実用的なエンジニアリングソリューション（ズーキーとSpannerのTrueTime）にある。

Zanzibarの解決策は「ズーキー（Zookies）」である。ズーキーとは、書き込み操作時にZanzibarから返される、タイムスタンプ付きの不透明なスナップショットトークンである 。これは、その時点での権限データのスナップショットを表現する。  

このメカニズムを支えるのは、クライアント側のプロトコルである。

1. クライアントアプリケーションは、権限の書き込み（例: ACLの変更）後にZanzibarからズーキーを受け取る。
2. クライアントは、受け取ったズーキーを、自身のコンテンツの更新とアトミックに（不可分な操作として）自身のストレージに保存する。
3. 後続の認可チェックを行う際、クライアントはこの保存したズーキーをZanzibarに送信し、「このズーキーのタイムスタンプと少なくとも同じくらい新しいデータで」チェックを行うよう要求する 。  

このプロトコルは、認可チェックがイベントの因果的順序を尊重することを保証し、それによって**外部整合性（external consistency）と線形化可能性（linearizability）**を提供する。「新しい敵問題」は、このメカニズムによって効果的に解決される 。さらに重要なのは、この設計により、Zanzibarはほとんどのリクエストを（潜在的に古い）ローカルキャッシュから高速に処理しつつ、要求に応じて強力な一貫性保証を提供できるという、パフォーマンスと正確性の間の重要なトレードオフを実現している点である 。  

アーキテクチャの深層分析: Zanzibarエンジンの解体

この章では、Zanzibarがその極めて高いパフォーマンスと可用性の目標を達成するために用いている内部機構を詳細に分析する。

Spanner基盤: グローバルな一貫性の礎

Zanzibarは、Googleの内部で開発された、グローバルに分散された外部整合性を持つSQLデータベース「Spanner」の上に構築されている 。  

Spannerの重要な機能は、そのTrueTime APIである。TrueTimeは、グローバルに同期された高精度のタイムスタンプを提供する。これにより、Zanzibarは意味のあるズーキーを生成し、分散された全フリートにわたって一貫したスナップショット読み取りを実行することが可能になる 。TrueTimeまたはそれに相当するメカニズムがなければ、Zanzibarの一貫性保証を達成することは格段に複雑になるだろう。  

Zanzibarは、一貫性を確保するために、すべての関係タプルを正規化された形式でSpannerに保存する 。データはオブジェクトIDによってシャーディングされており、読み取りが中心のワークロードに最適化されている 。  

APIサーフェス: 認可グラフとの対話

Zanzibarは、一連のコアRPC（Remote Procedure Call）メソッドを通じてその機能を提供する 。このAPIは、クライアントサービス（DriveやYouTubeなど）と中央認可システムとの間の契約として機能する。以下の表は、Zanzibarの5つのコアAPIメソッドをまとめたものである。  

表2: Google Zanzibar コアAPIメソッド

ハイパースケールでのパフォーマンス: キャッシング、インデキシング、最適化

Zanzibarの低レイテンシは偶然の産物ではない。それは、リクエストのたびにSpannerにアクセスすることを避けるために設計された、多層的な最適化戦略の結晶である。このアーキテクチャは、単一の特効薬に頼るのではなく、レイテンシに対する「多層防御」戦略を採用している。各層（Leopard、分散キャッシュ、リクエストヘッジング、Spanner）は、リクエスト分布の異なる部分を処理するように設計されており、可能な限り多くのリクエストが最もコストの高い層、すなわちSpannerデータベースに対する完全な非キャッシュ評価に到達するのを防ぐことを目的としている。

• 分散キャッシング (Distributed Caching): 各Zanzibarサーバーは、最終的および中間的なCheck/Expandの結果を保存するためのインメモリキャッシュ（例: LRUキャッシュ）を保持している 。コンシステントハッシングを用いて、同じオブジェクトに対するリクエストを常に同じサーバーにルーティングすることで、キャッシュのヒット率を最大化する 。  
• Leopardインデキシングシステム (Leopard Indexing System): ネストされていない浅い関係性を含むチェックの大部分を処理するために設計された、独立した特殊なインデキシングシステム。これは「ホット」なデータに対する最外層の高速キャッシュとして機能する 。  
• ホットスポット対策 (Hotspot Mitigation): 「ホット」なオブジェクト（例: バイラルになったYouTube動画や公開フォルダ）が受け取る不均衡に多いチェックリクエストを処理するための特別な技術。これには、同時リクエストを重複排除するための分散ロックテーブルや、既知のホットオブジェクトに対するプリフェッチなどが含まれる 。  
• リクエストヘッジング (Request Hedging): Google検索のようなレイテンシに敏感なクライアントのために、最初のZanzibarサーバーが短時間内に応答しない場合、別のサーバーに重複したリクエストを発行することができる。これにより、テールレイテンシが劇的に削減される 。  
• タイムスタンプ量子化 (Timestamp Quantization): ズーキーのタイムスタンプを意図的に少し古い値に丸めることがある。これにより、キャッシュヒットの可能性を高め、最小限の鮮度を犠牲にしてパフォーマンスを向上させる 。  

分散グラフエンジン: 認可チェックの並列化

複雑なCheckリクエストは、単一の操作ではない。Zanzibarのエンジンは、リクエストをサブ問題のツリーに分解する 。  

例えば、group:Aがgroup:Bとgroup:Cを含み、ユーザーXがネストされたグループgroup:Aのメンバーであるかをチェックする場合、このリクエストはgroup:B#member@user:Xとgroup:C#member@user:Xの並列チェックにファンアウトされる。

このファンアウトは、Zanzibarの数千台のサーバーからなるグローバルなフリート全体で発生し、各サブ問題は、その結果がキャッシュされている可能性が最も高いサーバーにディスパッチされる 。そして、それらの結果が再結合されて最終的な答えが生成される。この分散された並列グラフ走査こそが、そのパフォーマンスの鍵となっている。  

このアーキテクチャは、「サービスとしての整合性（consistency as a service）」の優れた実践例と言える。デフォルトの状態は高速でわずかに古いデータを返し、強力な整合性はズーキーという明示的なプロトコルを介してオンデマンドで利用可能になる。リクエストにズーキーが含まれていない場合は、高速だが潜在的に古いキャッシュからの応答が得られる。一方、ズーキー付きのリクエストは、システムにズーキーのタイムスタンプ以上の鮮度を持つスナップショット読み取りを強制し、これにはリージョン間の通信やレプリケーションの待機が必要になる場合がある。この「ユーザー指定可能な整合性モデル」により、アプリケーションのコンテキストを持つクライアントが、リクエストごとにレイテンシと鮮度のトレードオフを決定できる。これは、単純な「結果整合性」か「強整合性」かの二者択一よりもはるかに洗練されたアプローチである。  

Zanzibarエコシステム: オープンソース実装とイノベーション

2019年の論文公開後、Zanzibarの思想を具現化するサービス群が登場した。この章では、その中でも特に著名な2つのオープンソース実装を分析する。これらは、Zanzibarを一般の組織に提供する上で、異なる哲学的アプローチを代表している。

Authzed SpiceDB: 忠実かつ拡張された実装

• コア哲学: SpiceDBは、Zanzibar論文のアーキテクチャに忠実でありながら、Google固有の要素を排除（de-Googling）し、より広範な適用性を目指す、機能的に完全なオープンソース実装であることを目標としている 。開発元であるAuthzedは、認可に100%特化した企業である 。  
• アーキテクチャ決定とデータストア抽象化:
  • Zanzibarとの重要な違いは、プラグ可能なストレージバックエンドである。ZanzibarがSpannerに密結合しているのに対し、SpiceDBはGoogle Cloud Spannerに加えて、PostgreSQL、CockroachDB、MySQL、そして開発用のインメモリストアをサポートしている 。これにより、セルフホスティングの参入障壁が大幅に低下する。  
  • コンシステントハッシングによる分散キャッシングや並列グラフ評価（「ディスパッチ」）など、Zanzibarの中核的なスケーリングコンセプトを実装している 。  
• 論文を超えたイノベーション:
  • SpiceDBスキーマ言語: Googleが使用するProtobuf形式にコンパイルされる、より直感的で人間が読みやすいスキーマ言語を提供し、開発者体験を向上させている 。  
  • ABACのためのCaveat: SpiceDBは「Caveat」を導入した。これは、関係性に付加できる短いコードスニペット（GoogleのCELを使用）であり、属性ベースの条件を追加できる。これにより、「ユーザーがeditorsグループに属し、かつrequest.ip == resource.ipである場合にアクセスを許可する」といった、ReBACとABACのハイブリッドポリシーをモデリングできる 。この機能はNetflixの支援によって開発された 。  
  • 柔軟なユーザーモデル: SpiceDBは、GoogleのGAIAのような中央IDシステムに紐づいた特別な「ユーザー」型の概念を排除している。ユーザーは他のオブジェクト型と同様に扱われ、複数のIDプロバイダーや非人間エージェント（APIキー）のような複雑なアイデンティティシナリオのモデリングを可能にする 。  
  • 開発者向けツール: CLI（zed）、Kubernetesオペレーター、スキーマ開発用のWebベースPlayground、CI/CD連携など、豊富なツールエコシステムを提供する 。  
  • リバースインデックス: 「このユーザーがアクセスできるリソースは何か？」というクエリに対し、フラットな結果リストを提供することで、ZanzibarのExpand APIを改善している。これはUIを構築するアプリケーション開発者にとってより実用的である 。  

Ory Keto: 広範なアイデンティティエコシステム内の構成要素

• コア哲学: Ory Ketoは、最小限でステートレス、かつ構成可能な認可サーバーとして設計されている。これは、Kratos（ID管理）、Hydra（OAuth2/OIDC）、Oathkeeper（IDプロキシ）を含む、より広範なOryエコシステムの一コンポーネントである 。その哲学は「最小限の依存関係」と「どこでも実行可能」である 。  
• アーキテクチャ決定:
  • Ketoは、永続化のために標準的なRDBMS（PostgreSQLやMySQLなど）に依存するステートレスなGoバイナリである。ロードバランサーの背後でインスタンスを追加実行するだけで水平にスケールするように設計されている 。  
  • 有界の陳腐性（bounded staleness）を実現するためのズーキーのような、より複雑なZanzibarの機能の一部は実装しておらず、代わりにシンプルさと自社スタック内での統合を重視している 。  
  • OpenAIのユースケースに見られるように、マルチリージョンでの耐障害性を実現するためにCockroachDBと共にデプロイされることが多い 。  
• Ory Permission Language (OPL):
  • Ketoは独自の構成言語OPLを使用しており、これはTypeScriptのサブセットである 。これはWeb開発者にとって馴染みやすく、カスタムDSLよりも威圧感が少ないように設計されている。  
  • この言語は、他のZanzibar実装と同様に、名前空間と関係性の定義を可能にする 。  

比較分析: SpiceDB vs. Ory Keto

Zanzibarのオープンソースエコシステムは、2つの異なる哲学、すなわち「権威ある認可データベース」（SpiceDB）と「構成可能なアイデンティティコンポーネント」（Ory Keto）に分岐している。どちらを選択するかは、技術的な優劣よりも、企業のIAM（Identity and Access Management）に関するアーキテクチャ戦略に大きく依存する。SpiceDBは、認可のための単一の真実の源として機能することに重点を置いており、認証方法には依存しない。一方、Ory Ketoは、Oryが提供するより大きなIAMパズルの一部を解決するコンポーネントとして位置づけられている。したがって、異種環境に強力な専用認可サービスを導入したいチームはSpiceDBを、新しいプラットフォームをゼロから構築し、事前に統合されたフルスタックのIAMソリューションを求めるチームはOryエコシステムを選択する可能性が高い。

また、オープンソース実装の進化は、ZanzibarのReBACモデルを拡張してABACを取り込むという市場主導のニーズを示している。これは、ReBAC単独では多くの現実世界のエンタープライズユースケースに対応するには不十分であることを示唆している。SpiceDBがNetflixの支援を受けて「Caveat」を追加したことは、これが学術的な探求ではなく、実際の生産ニーズへの対応であったことを証明している 。先進的な認可の未来は、ReBACかABACかではなく、両方のパラダイムの長所を組み合わせたハイブリッドモデルにある。最も成功するZanzibar実装は、この2つのパラダイムをエレガントに融合させるものとなるだろう。  

以下の表は、SpiceDBとOry Ketoの機能とアーキテクチャを直接比較したものである。

表3: オープンソース実装の機能・アーキテクチャ比較 (Authzed SpiceDB vs. Ory Keto)

実践的応用と戦略的実装

この章では、Zanzibarスタイルのシステムの導入を検討しているアーキテクト向けに、具体的なユースケースと重要な運用上のトレードオフに焦点を当てた実践的なガイダンスを提供する。

標準的なユースケース: 現実世界のモデリング

Zanzibarモデルが、複雑で現実的な問題をどのように解決するかを具体的な例で示す。

• Google Drive: 階層的なフォルダ/ファイル権限のモデリング。親フォルダに対するユーザーの権限は、子ファイル/フォルダに継承されるが、下位レベルで上書きすることも可能である 。これは、継承を定義するためにユーザーセットリライトを使用する（例: ファイルの   viewerは、そのparentのviewerである） 。  
• YouTube: コンテンツの公開設定（公開、非公開、限定公開）、チャンネル権限の管理、そしてバイラル動画の「ホットスポット」への対応 。  
• Google Cloud IAM: 数十の異なるサービス（Compute, Storage, BigQueryなど）にわたる統一された権限モデルの提供。プロジェクトにおけるユーザーのロールは、そのプロジェクト内のすべてのリソースに対する権限を付与し、サービス間の相互運用性を示している 。  

中央集権化のトレードオフ: Zanzibarはあなたの組織に適しているか？

これは最も重要な戦略的考慮事項である。Zanzibarモデルは、認可判断に関連する全てのデータをZanzibarシステム自体に中央集権化することを要求する 。これには、ロールや権限だけでなく、組織図、フォルダ階層、プロジェクトの所有権、リソースの属性（例: リポジトリの「公開」ステータス）といったアプリケーションデータも含まれる 。  

この「中央集権化のトレードオフ」は、Zanzibar導入における最大の障壁であり、アプリケーションデータと認可データの相互作用方法を再設計するという、根本的なアーキテクチャ上の結合を意味する。多くの「認可データ」（例: 誰がユーザーの上司か、どのファイルがどのフォルダにあるか）は、同時に中核的な「アプリケーションデータ」でもある。このため、チームは困難な選択を迫られる。それは、データの二重管理と同期の複雑さを受け入れるか、あるいは、以前はローカルデータだったものを認可システムに問い合わせるようにアプリケーションを根本的に変更するかである。Googleでさえ、この移行に「トップダウンの指令」と「数年」を要したという事実は 、これが単純なライブラリの統合ではなく、大規模で侵襲的なアーキテクチャ変更であることを証明している。したがって、Zanzibarを評価するチームは、このデータ移行と同期の労力を、後付けではなく主要なプロジェクトコストとして予算計上しなければならない。  

この要求は、「データ同期のジレンマ」という大きなアーキテクチャ上の課題を生み出す。チームは、どちらも理想的とは言えない2つの選択肢に直面する 。  

1. 二重書き込み / 同期: アプリケーションは、まずプライマリデータベースに書き込み、次に別のステップで、関連する認可データをZanzibarに書き込む。これは複雑さを増大させ、データ不整合のリスクを生み、堅牢なエラーハンドリングと監査を必要とする。
2. Zanzibarをプライマリストアとして使用: このデータをZanzibarを真実の源として扱い、アプリケーションロジックで必要な場合はAPIを介して取得する。しかし、Zanzibarは汎用データベースではないため、パフォーマンス上の問題から、これは多くの場合、現実的な選択肢ではない。

このトレードオフは非常に大きく、Google社内でもサービスをZanzibarに移行するには、数年がかりのトップダウンの指令が必要だった 。そのような規模や権限を持たないほとんどの企業にとって、これは導入の大きな障壁となる。  

実装への道筋と運用負荷

• 移行戦略: 既存のアプリケーションをZanzibarスタイルのシステムに移行するためのパターンを議論する。通常、関係データの初期一括ロードを行うための「オフラインパイプライン」と、システム間の同期を保つためのリアルタイムのイベント駆動型更新が含まれる 。  
• セルフホスティング vs. マネージドサービス: 運用オーバーヘッドの分析。CockroachDBと組み合わせたSpiceDBのような分散型一貫性データベースをセルフホストするには、分散システム、監視、データベース管理に関する高度な専門知識が必要となる 。Authzed CloudやOry Networkのようなマネージドサービスは、コストと引き換えにこの複雑さを抽象化する 。  
• パフォーマンスチューニング: 現実世界の実装では、特に深くネストされた関係性や競合の激しいリソースに対して、パフォーマンスのホットスポットを回避するための手動チューニングが必要になることが多い 。これは「一度設定すれば終わり」のシステムではない。  

認可の未来: AIと複雑なデジタルエコシステムにおけるZanzibarの役割

Zanzibarモデルが特に強力な、新たなユースケースを探る。論文が発表された当時には存在しなかった、AIエージェントやRAG（Retrieval-Augmented Generation）システムの台頭は、Zanzibarのような認可システムにとっての「キラーアプリケーション」を生み出している。これらの新しいユースケースは、膨大な数の関係性を管理し、低レイテンシのチェックを提供するというZanzibarの強みと完全に一致している。

• AIエージェント: 企業が何千ものAIエージェントを展開するにつれて、これらのエージェントがアクセスできるデータやAPIを制御するための、スケーラブルで細粒度の認可システムが不可欠になる。Zanzibarはこれらの権限を大規模に管理し、エージェントがユーザーレベルの権限を継承できるようにし、侵害されたエージェントの影響範囲を限定するための境界を強制し、完全な監査証跡を提供することができる 。  
• 検索拡張生成 (RAG): RAGパイプラインにおいて、Zanzibarは、ドキュメントがLLMに渡されて埋め込みや生成が行われる前に、ユーザーの権限に基づいてドキュメントを事前フィルタリングするために使用できる。これにより、AIがユーザーに閲覧が許可されているデータのみを基に推論することが保証される 。  

これは、以前は大規模な人間向けアプリケーションに限定されていたZanzibarのビジネスケースが、劇的に拡大していることを意味する。AIとデータの相互作用を安全に統制する必要性は、今後10年で企業におけるZanzibar導入の主要な推進力になる可能性がある。

結論: Zanzibarの影響と将来の軌跡の統合

Google Zanzibarは、柔軟なReBACモデルに基づく、中央集権化されたグローバルに一貫性のある認可システムとして、現代の分散アーキテクチャにおける根本的な課題に対する一つの答えを提示した。

その中核的な貢献は、極端なスケールで認可を正確かつ高性能に解決するための青写真を提供したことにある。特に、「新しい敵問題」とその解決策であるズーキープロトコルは、分散システムにおける因果整合性を保証する上での画期的な成果である。

Zanzibarの永続的な遺産は、2019年の論文がハイパースケーラーの知識を民主化したことにある。これにより、オープンソースおよび商用の製品からなる活発なエコシステムが生まれ、これらの高度な能力がFAANG企業以外でも利用可能になった。

最後に戦略的な観点から見ると、実装上の課題、特に中央集権化のトレードオフは大きいものの、Zanzibarが先駆けたアーキテクチャパターンは、複雑で分散化され、ますますAIによって駆動されるデジタルエコシステムの認可の未来を代表している。このモデルを採用することは、アプリケーションのセキュリティ体制の正確性、スケーラビリティ、そして将来性への戦略的投資であると言えるだろう。