Aserto Topazとは？商用サービス終了後もOSSで使えるのか【2026年8月時点】

Aserto Topazを調べると、日本語でも英語でも「中央管理プレーンがポリシーをリアルタイム同期する」といった説明が出てきます。しかしその管理プレーンは2025年5月31日に停止しました。Aserto社は商用事業そのものを畳んでいます。一方で、OSSの認可サービスであるTopaz本体は2026年8月時点でも更新が続いており、コンテナイメージもCLIも問題なく入手できます（2026年8月15日にコンテナレジストリでマニフェスト取得を確認）。この記事では「何が止まり、何が動いているのか」を一次情報で切り分け、いまTopazを採用してよいのかまで判断できるようにします。

まとめ

• Aserto社は2025年4月27日に商用撤退を表明し、SaaSの管理プレーン（コントロールプレーン）を2025年5月31日までに停止しました。
• OSSのTopazは生きています。最新版はv0.33.16（2026年8月5日公開）で、mainブランチへのコミットも2026年8月11日付です。ライセンスはApache-2.0です。
• 消えたのはSaaS側の機能です。中央ディレクトリ、イベントファブリック、ポリシーレジストリ、管理コンソール、決定ログ集約、IDプロバイダーの常時同期コネクタが該当します。
• 残ったのは認可エンジン本体、ローカルのZanzibar型ディレクトリ、ローカルファイルへの決定ログ出力、そしてds-load CLIによるIDプロバイダーからのデータ投入です。
• 採用判断はSDKの言語で割れます。GoとNodeは2026年に入っても更新されていますが、Python・Ruby・.NETのSDKは2025年春から更新が止まっています。Javaはその中間で、2025年12月が最終更新です。

以下では撤退の経緯、構成要素、消えた機能と残った機能の対応、起動手順、そして本番採用の判断軸の順に見ていきます。

Asertoの商用撤退とTopazの現状

2025年5月31日に停止した管理プレーン

Aserto社は2025年4月27日付のブログ「The final chapter for Aserto」で、SaaSのコントロールプレーンをサンセットし、2025年5月31日までに停止すると告知しました。同時に、商用エンティティとしてのAserto社自体を畳むことも明言しています。移行先の具体的な指示は示されず、読者はtopaz.shへ誘導されました。

つまり、2024年以前に書かれたAserto Topazの解説記事が前提にしている「Asertoにサインアップして認可を管理する」という導線は、現在は存在しません。日本語記事の多くはこの前提のまま残っています。

更新が続くTopaz本体のリリース状況

撤退したのは会社であって、プロジェクトではありません。GitHubのaserto-dev/topazリポジトリをAPIで確認すると、2026年8月時点で次の状態です。

MAINTAINERS.mdに載っているのはGert Drapers氏とDani Carabas氏の2名です。このファイルは2025年8月14日のコミットで所属欄が書き換えられており、2名とも「Aserto」から「D5S」「self」へ、メールアドレスも会社ドメインから個人のものへ変わっています。会社組織から個人ベースの体制へ移ったことが、リポジトリの差分として残っています。リリース間隔はv0.33.13（2026年4月24日）、v0.33.14（同5月13日）、v0.33.15（同7月11日）、v0.33.16（同8月5日）で、間隔は19日・59日・25日、おおむね1か月に1回のペースです。

配布物も生きています。コンテナレジストリのghcr.io/aserto-dev/topazはlatestタグ・0.33.16タグともマニフェストを取得でき、Homebrewのcask定義もversion 0.33.16を指しています。クイックスタートで使うポリシーイメージghcr.io/aserto-policies/policy-todoもタグ一覧を返します。会社の消滅で配布基盤が道連れになった、という事態は起きていません。

旧サービスを宣伝したままのaserto.com

ここが実務上いちばんの罠です。aserto.comは2026年8月時点でも通常のプロダクトサイトとして応答し、トップページには「Fast ~1ms authorizations」「See a demo」といった訴求と、「The Aserto control plane will sync changes to authorization data with them in real-time」という説明が残っています。停止済みのサービスを、停止したと書かないまま宣伝し続けている状態です。

ドキュメントサイトのdocs.aserto.comも同様に生きており、Topaz CLIのテンプレート一覧が案内するドキュメントURLはいまもこのドメインを指しています。読む価値のある技術情報が残っている一方で、サインアップ導線や商用プランの記述は実態と一致しません。調査時は「aserto.comの記述は2025年5月以前の内容」と割り切り、稼働状況の判断はGitHubのリリースとレジストリのタグで行うのが確実です。なお、よく引用される「約1ミリ秒」という数値もこのマーケティングページ由来で、topaz.shの公式ドキュメントには「very low latency」とあるだけで具体的な数値は書かれていません。

Topazの構成要素とOPA・Zanzibarの役割分担

認可エンジンが公開する3つのAPI

Topazは、決定エンジンにOpen Policy Agent（OPA）を使い、そこにGoogle Zanzibarのデータモデルを実装したディレクトリを同梱した、自己ホスト型の認可サービスです。公式ドキュメントは自らを「OPAのポリシーアズコードと決定ログを、Zanzibarモデルのディレクトリと同じコンテナイメージに収めた唯一の実装」と位置づけています。

認可エンジン（Authorizer）が認可判定のためにアプリケーションへ公開するAPIは3つです。単純な可否判定を返すauthz/is、ポリシーへ任意のクエリを投げるauthz/query、UIの表示制御に使う決定ツリーを返すauthz/decisiontreeで、いずれもPOSTまたはgRPCで呼び出します。リクエストのペイロードは、利用者を示すidentity context、ポリシーを示すpolicy context、対象リソースを示すresource context（省略可）の3つで共通化されています。

ポリシーはRegoで書きます。文法やOPA 1.0での変更点はRegoとOPA 1.0の書き方にまとめてあります。

BoltDB上のZanzibar型ディレクトリ

Zanzibarが担うのはルールではなくデータです。公式ドキュメントは「Zanzibarはルールをハードコードしてデータだけに注力し、OPAはルールを書けるがデータは利用者任せ」と両者の欠けを説明し、Topazはその両方を埋めるものだとしています。

ディレクトリの実体はBoltDBのインスタンスで、オブジェクト型・リレーション型・パーミッションの定義、インスタンスの生成、利用者やグループの投入を担います。ポリシー評価時は、Rego側からOPAビルトイン関数でこのディレクトリを引きます。現行のビルトインはds.object、ds.relation、ds.relations、ds.check、ds.checks、ds.graphの6つです。

ここは古い記事を読むと必ず踏む地雷です。ds.identity、ds.user、ds.check_relation、ds.check_permissionを紹介している解説をよく見かけますが、公式のビルトイン関数リファレンスは4つとも見出しに「OBSOLETE」と付けて非推奨を宣言しています。ds.check_relationとds.check_permissionはds.checkに統合済みで、ds.identityとds.userはマニフェスト導入以前の名残りとして「identityやuserというオブジェクト型の存在をハードコードで前提にしている」と説明されています。厄介なことに、Topaz公式のアーキテクチャ解説ページ自体がこの旧6関数を並べたまま更新されていません。新規に書くRegoでは使わないでください。

重要なのは読み込みのタイミングです。data.jsonのような静的データはポリシーのロード時にdata名前空間へ展開されメモリ上に居座りますが、ディレクトリのオブジェクトは必要になった時点でオンデマンドに読み込まれます。関係データが大きくなるアプリでは、この差がメモリ使用量に効いてきます。

マニフェストによるドメインモデルの定義

ドメインモデルはYAMLのマニフェストで宣言します。現行のモデルバージョンは3で、型・リレーション・パーミッションを次のように書きます。

model:
  version: 3

types:
  user:
    relations:
      manager: user

  group:
    relations:
      member: user | group#member

  folder:
    relations:
      parent: folder
      owner: user | group#member
      editor: user | group#member
      viewer: user | user:* | group#member
    permissions:
      can_delete_folder: owner | parent->can_delete_folder

読み方の勘所は2つです。1つはgroup#memberという記法で、これは「あるグループのmemberリレーションを持つ全員」を主体に取れることを意味します。もう1つはparent->can_delete_folderという再帰定義で、親フォルダで削除権限を持つ人はその配下でも削除できる、という継承をこの1行で表現します。ロールを列挙するRBACや属性で判定するABACでは書きにくい「所有関係の継承」を、関係の定義そのものとして書ける点がZanzibar型の利点です。

SaaS停止で消えた機能とOSSに残った機能

管理プレーンに依存していた機能

docs.aserto.comの「Aserto vs Topaz」ページは、どこまでがOSSでどこからが商用かを明示しています。この線引きがそのまま「2025年6月以降に使えなくなったもの」の一覧になります。

旧来の解説記事が「Aserto Topazの強み」として挙げていた項目の多くが、上半分に集まっている点に注意してください。ポリシーの即時伝播やGitHub/GitLabと連携する自動ビルドは商用側の機能でした。OSSのTopazはOPAのポーリング機構でポリシーイメージを取得します。Topazリポジトリの設定リファレンス（docs/config.md）ではポーリング間隔がmin_delay_seconds 60、max_delay_seconds 120と書かれており、更新は秒単位ではなく分単位で反映されると考えておくのが妥当です。

決定ログも位置づけが変わります。OSS側でも決定ログは出せますが、実装はOPAのプラグインで、aserto_decision_logを有効にしてファイル出力先を指定する形です。集約と配送保証は自前で組む必要があり、実運用ではログファイルをFluent BitなどでSIEMへ送る構成になります。

plugins:
  aserto_decision_log:
    enabled: true

decision_logger:
  type: "file"
  config:
    log_file_path: /tmp/topaz/decisions.log
    max_file_size_mb: 20
    max_file_count: 3

ds-loadプラグインで代替できるIDプロバイダー連携

「コネクタが消えた＝IDプロバイダーと繋げない」ではありません。ここは誤解されやすいので分けて理解してください。消えたのはSaaSが常時走らせていた同期コネクタで、OSS側にはds-load CLIというデータ投入ツールが残っています。公式ドキュメントに載っているプラグインはAuth0、Azure AD、AWS Cognito、Google Workspace、Okta、LDAPの6種で、独自プラグインの書き方も案内されています。

ドキュメントより実装のほうが充実している点も押さえておく価値があります。ds-loadリポジトリのplugins配下には、上記6種に加えてAzure AD B2C、FusionAuth、JumpCloud、Keycloak、OpenAPIを含む11種が置かれています。Keycloak環境でも、ドキュメント未掲載なだけで連携手段は最初からあります。

違いは同期の性質です。SaaSのコネクタが変更を継続的に反映していたのに対し、ds-loadは実行したときに取り込むバッチです。利用者の削除や異動を認可へ即時反映したいなら、ds-loadを定期実行するか、IDプロバイダーのイベントを受けてディレクトリのWriter APIを直接叩く仕組みを自前で用意することになります。ポリシー側が60〜120秒で追随するのに対し、ディレクトリのデータ鮮度はこのcron間隔がそのまま上限になります。この「反映の遅れ」を放置すると、退職者の権限が残る典型的な事故につながります。認可の抜けがどう悪用されるかは認可バイパスの仕組みと対策で整理しています。

ローカル環境でのTopaz起動手順とポート割り当て

CLIとコンテナイメージの入手経路

Topaz CLIはLinux・macOS・Windowsに対応し、GitHubリリースのtarball、Homebrew、WinGet、MSI、go installのいずれでも入ります。Homebrewのcask定義は2026年8月5日にv0.33.16へ追随済みです。

brew install --cask aserto-dev/tap/topaz

winget install Aserto.Topaz

go install github.com/aserto-dev/topaz/cmd/topaz@latest

認可エンジン本体はDockerコンテナとして配布され、topaz installコマンドで最新イメージを取得します。Docker DesktopなどのDockerランタイムが前提です。CLIは開発用の自己署名証明書を生成しますが、そのままではブラウザが内蔵コンソールを開けないため、topaz certs trustでgateway用とgRPC用の2つのCA証明書をOSのトラストストアへ登録します。不要になればtopaz certs trust –removeで外せます。

テンプレートによる最小構成の起動

Topazにはテンプレートが同梱されており、ポリシー・ドメインモデルのマニフェスト・サンプルデータの3点セットを一度に展開できます。用意されているのはpeoplefinder、todo、simple-rbac、gdrive、api-auth、slack、github、multi-tenantの8種で、Slackのワークスペースとチャンネル、GitHubのリポジトリと組織といった実在サービスの権限構造を写した題材が揃っています。業務で近いのは後ろの2つで、テナント境界を含む認可を設計するならmulti-tenant、APIのエンドポイント単位で認可したいならapi-authが出発点になります。

topaz templates list
topaz templates install todo

展開先は設定ディレクトリで、XDG_CONFIG_HOMEを設定していなければ$HOME/.config/topaz/以下です。todoテンプレートが参照するポリシーイメージはGHCR上に公開されたままなので、Asertoのアカウントが無くてもこの手順は最後まで通ります。認可のモデリングを試すだけなら、いまでもこれが最短経路です。

コンテナが待ち受ける8つのポート

公式リポジトリのdocker-compose.yamlには、各ポートの用途がコメントで明記されています。サイドカーとして同居させるときのポート衝突を避けるため、事前に押さえておく値です。

内蔵コンソールはhttps://localhost:8080/ui/directoryで開きます。これはREADMEおよびtopaz consoleコマンドの既定値と同じアドレスです。アプリケーションから常用するのは認可エンジンの8282（gRPC）または8383（HTTP）で、ディレクトリへのデータ投入は9292/9393側です。9494と9696はKubernetesのプローブとPrometheus連携を想定した口なので、外部へ公開しない構成にしてください。

Topazを本番に入れてよいかの判断

言語SDKの更新停止が示す実務リスク

ここは玉虫色にせず言い切ります。Topazの中核は健全ですが、周辺のSDKは言語によって明確に見放されています。aserto-devの各リポジトリの最終push日を並べると分岐が見えます。

Python・Ruby・.NETの3つは、いずれもAsertoが撤退を発表した2025年4月前後で更新が止まっています。1年以上放置されたSDKは、依存ライブラリのセキュリティ更新もgRPCスタブの追随も期待できません。この3言語でTopazを採用するなら、SDKを使わずgRPC/RESTのAPIを直接叩く前提で見積もる必要があります。

ポリシーイメージのビルドに使うpolicy CLIは、aserto-devではなくopcr-io/policyで管理されており、こちらはv0.4.0が2026年6月10日に出ています。ツールチェーン全体が止まったわけではない点は補足しておきます。

採用してよい条件と避けるべき条件

Topazを選んでよいのは、GoまたはNode.jsのアプリケーションで、認可をサイドカーとして同居させ、ポリシーとデータを自分たちで管理する腹が決まっているケースです。Zanzibar型の関係モデルとRegoのルールを1つのコンテナで扱える実装は、公式が自ら唯一と位置づけるとおりほかに見当たらず、Regoの資産がすでにあるなら移行コストも小さくて済みます。

逆に避けるべきなのは、次に当てはまる場合です。第一に、Python・Ruby・.NETが主言語で、公式SDKに依存したい場合。第二に、ベンダーのサポート契約やSLAが調達要件に含まれる場合で、法人としてのAsertoが無い以上、標準的なサポート窓口は存在しません。ただし撤退ブログには「メンテナが必要とする利用者へ商用サポートを提供する可能性がある」と明記されているため、個別契約で要件を満たせるならメンテナへ直接打診する余地は残ります。第三に、複数リージョンの認可データを中央で一元管理したい場合です。それを担っていた管理プレーンが無くなったため、同等の構成を自前で設計・運用することになります。メンテナが2名という体制も、長期の基盤として見るなら正直に織り込むべき数字です。

Topazの代替となる認可基盤の選び方

上の条件に引っかかるなら、同じZanzibar系・ポリシー系の実装を検討することになります。2026年8月時点の状況は次のとおりです。

関係ベースの権限（共有・階層・コラボレーション）が要件の中心なら、OpenFGAかSpiceDBが素直です。特にOpenFGAはCNCFのIncubatingプロジェクトで、商標とIPがCNCFへ移管され、プロジェクトの存続が1社の事業判断だけでは決まらない点がTopazとの最大の差です。開発の主導権はOktaにあり、MAINTAINERS.mdに載る25名のうち22名がOkta所属ですが、それでもTopazの2名とは桁が違います。Asertoのように会社が畳めば管理プレーンごと消える、という形の断絶は起きにくい構造です。属性と条件で判定したいだけならCerbos、既存のRego資産を活かして自分でデータ供給を組めるならOPA単体という切り分けになります。TopazはOPAとZanzibarの両方を1つにまとめた設計なので、移行先を1つに決めきれない場合は「ルールをどこに書くか」から先に決めると迷いません。

よくある質問

Asertoは今も使えますか？

商用サービスとしては使えません。Aserto社は2025年4月27日に事業終了を告知し、SaaSの管理プレーンを2025年5月31日までに停止しました。新規のサインアップも提供されていません。OSSのTopazは別で、2026年8月現在も更新が続いています。

Topazとは何ですか。画像編集ソフトのTopazとは別物ですか？

別物です。この記事のTopazは、Aserto社が2022年10月に公開したクラウドネイティブ向けのOSS認可サービスで、GitHubリポジトリの作成日は2022年10月23日です。写真や動画のアップスケーリングで知られるTopaz Labsの製品とは開発元も用途も無関係で、日本語で「topaz とは」と検索した場合は画像処理ソフト側の情報が優勢になります。

TopazとOPAはどういう関係ですか？

TopazはOPAを決定エンジンとして内蔵しています。「Topaz policy engine」と呼ばれることがありますが、厳密にはTopaz自体がポリシーエンジンなのではなく、OPAというポリシーエンジンにZanzibar型のディレクトリを同梱した認可サービスです。ポリシーはOPAと同じRegoで書き、OPAのビルトイン関数の形でTopazのディレクトリを参照します。OPA単体との違いは、認可判定に必要なデータ（利用者・グループ・リソース・それらの関係）を保持するディレクトリが最初から同梱されている点です。

イベントファブリックによるポリシーの即時反映は使えますか？

使えません。イベントファブリックはAsertoの管理プレーン経由で提供されていた商用機能で、SaaSの停止とともに失われました。OSSのTopazはOPAのポーリングでポリシーイメージを取得する方式です。公式の設定例ではポーリング間隔が60〜120秒に設定されており、変更の反映は分単位と見込んでください。

管理プレーン（コントロールプレーン）とは何ですか？

実際の処理を行うデータプレーンに対して、その設定・配布・監視を担う制御層のことです。Asertoの場合は、各アプリの隣に置かれたローカル認可者（データプレーン）へポリシーと認可データを配り、決定ログを集め、コンソールから一元管理する層が管理プレーンでした。Topaz単体はデータプレーンにあたる部分だけを提供します。

関連記事

• Open Policy Agent（OPA）とは？Policy as Codeを実現する汎用ポリシーエンジンを解説
• Regoとは？OPA 1.0（Rego v1）の書き方とv0コード移行・テストの実装ガイド
• ABACとは？属性ベースアクセス制御の仕組みとRBACとの使い分けを実装視点で解説
• RBACとは？ロールベースアクセス制御の仕組みと導入判断を実装視点で解説
• 認可バイパスとは？IDOR・権限昇格の仕組みとサーバ側で止める実装対策を解説