---
title: "Aserto Topazとは？商用サービス終了後もOSSで使えるのか【v0.33.25・2026年11月】"
url: "https://www.issoh.co.jp/tech/details/4609/"
published: 2024-12-23
updated: 2026-11-03
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# Aserto Topazとは？商用サービス終了後もOSSで使えるのか【v0.33.25・2026年11月】

Aserto Topazを調べると、「中央の管理プレーンがポリシーをリアルタイムに同期する」という説明がいまも出てきます。その管理プレーンは2025年5月31日に止まり、Aserto社は商用事業を畳みました。一方でOSSの認可サービスであるTopaz本体は更新が続いており、2026年10月26日にv0.33.25が出ています。この記事では、何が止まって何が動いているのかを一次情報で切り分け、v0.33.25を手元で起動して確かめた結果も添えて、いまTopazを採用してよいかを判断できるようにします。

## まとめ

- Aserto社は2025年4月27日（米国時間）に商用撤退を告知し、SaaSの管理プレーンを2025年5月31日までに停止しました。新規のサインアップもありません。
- OSSのTopazは存続しています。最新版はv0.33.25（2026年10月26日）で、8月5日のv0.33.16から12週間で9本のリリースが出ました。ライセンスはApache-2.0です。
- 消えたのは中央ディレクトリ、イベントファブリック、管理コンソール、ポリシーレジストリ、決定ログ集約、IDプロバイダーの常時同期です。認可エンジン、ローカルのZanzibar型ディレクトリ、決定ログのファイル出力、ds-loadによるデータ投入は残っています。
- TopazはOpenIDの標準規格Authorization API 1.0（AuthZEN）のエンドポイントを持ちます。ただし応答するのはディレクトリ側の9393番で、Regoのポリシーは通りません（2026年11月3日に実測）。
- 採用判断はSDKの言語で割れます。GoとNodeは2026年も更新がありますが、Python・Ruby・.NETのSDKは2025年春からpushがありません。

## Asertoの商用撤退とTopazの現状

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

Aserto社は2025年4月27日付のブログ[「The final chapter for Aserto」](https://www.aserto.com/blog/the-final-chapter-for-aserto)で、SaaSのコントロールプレーンを2025年5月31日までに停止すると告知し、商用エンティティとしての会社も畳むと明言しました。Topazについては「引き続き支えるメンテナがいる」「メンテナが必要な利用者に商用サポートを提供する可能性もある」と書かれ、読者はtopaz.shへ誘導されています。

2024年以前の解説記事が前提にしている「Asertoにサインアップして認可を管理する」導線は、もう存在しません。日本語の解説はこの前提のまま残っているものが多いので、読むときは公開日を確かめてください。

### v0.33.25まで続くTopaz本体のリリース

撤退したのは会社で、プロジェクトは止まっていません。[GitHubのaserto-dev/topaz](https://github.com/aserto-dev/topaz)をAPIで確認した、2026年11月3日時点の状態は次のとおりです。

| 項目           | 2026年11月3日時点          |
| ------------ | --------------------- |
| 最新リリース       | v0.33.25（2026-10-26）  |
| mainへの最終push | 2026-10-30            |
| 同梱OPA        | v1.21.4（mainはv1.22.0） |
| ライセンス        | Apache-2.0            |
| スター数         | 1,368                 |
| メンテナ         | 2名                    |

リリースは8月20日のv0.33.17から10月26日のv0.33.25まで、ほぼ毎週から隔週の間隔で出ています。中身の多くは依存関係とOPAの追随で、10月30日にはmainのOPAがv1.22.0（10月29日公開）へ上がりました。OPAの新版が出てから1日で取り込む速さは、メンテナンスが形だけでないことを示しています。

MAINTAINERS.mdに載るのはGert Drapers氏とDani Carabas氏の2名で、所属欄はそれぞれ「D5S」「self」です。2025年8月のコミットで所属がAsertoから書き換えられており、会社から個人ベースの体制へ移ったことがリポジトリに残っています。

配布物も生きています。ghcr.io/aserto-dev/topazの0.33.25タグはマニフェストを返し、Homebrewのcask定義とWinGetのマニフェストも0.33.25に追随済みです。v0.33.25ではWinGetへの公開をリリース作業に組み込む変更が入りました。

### 製品説明と撤退告知が併存するaserto.com

実務上の罠はここです。aserto.comは2026年11月時点も通常のプロダクトサイトとして応答し、トップページには「\~1ms」の訴求、「See a demo」のボタン、「The Aserto control plane will sync changes to authorization data with them in real-time」という説明が残っています。同じページに撤退ブログ「The final chapter for Aserto」（Goodbye Aserto, long live Topaz.）へのリンクもありますが、製品説明そのものは停止前のままで、リンクを開かない限り停止は分かりません。

docs.aserto.comも残っており、Topaz CLIのテンプレート一覧が示すドキュメントURLはいまもこのドメインです。技術情報としては読めますが、サインアップや商用プランの記述は実態と合いません。稼働状況はaserto.comではなく、GitHubのリリースとレジストリのタグで判断してください。よく引用される「約1ミリ秒」もこのマーケティングページの数字で、topaz.shのドキュメントには具体的な数値がありません。

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

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

Topazは、決定エンジンに[Open Policy Agent（OPA）](/tech/details/4573/)を使い、Google Zanzibarのデータモデルを実装したディレクトリを同じコンテナに収めた、自己ホスト型の認可サービスです。「Topaz policy engine」と呼ばれることもありますが、ポリシーを評価しているのは内蔵のOPAです。

認可エンジン（Authorizer）がアプリケーションに公開するAPIは3つです。可否を返すauthz/is、ポリシーへ任意のクエリを投げるauthz/query、UIの表示制御に使う決定ツリーを返すauthz/decisiontreeで、HTTPのPOSTかgRPCで呼びます。ペイロードは、利用者を示すidentity context、ポリシーを示すpolicy context、対象を示すresource context（省略可）の3つで共通です。ポリシーはRegoで書き、文法とOPA 1.0での変更点は[Regoの書き方とv0からの移行](/tech/details/7523/)にまとめています。

### BoltDB上のZanzibar型ディレクトリ

Zanzibarが担うのはルールではなくデータです。Topazの説明では「Zanzibarはルールを固定してデータに集中し、OPAはルールを書けるがデータは利用者任せ」とされ、その両方を1つにまとめたのがTopazです。ディレクトリの実体はBoltDBで、オブジェクト型・リレーション・パーミッションの定義と、利用者やグループのデータを持ちます。

Regoからは組み込み関数でディレクトリを引きます。[公式のビルトイン関数リファレンス](https://www.topaz.sh/docs/directory/built-ins)に載る現行の関数は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」と表記されています。check\_relationとcheck\_permissionはds.checkに統合済みで、新しく書くRegoでは使わないでください。

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

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

ドメインモデルは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
```

group#memberは「あるグループのmemberを持つ全員」を主体に取る記法です。parent->can\_delete\_folderは、親フォルダで削除できる人は配下でも削除できる、という継承を1行で書いています。ロールを列挙する[RBAC](/tech/details/6488/)や属性で判定する[ABAC](/tech/details/16407/)では書きにくい所有関係の継承を、関係の定義として書ける点がZanzibar型の利点です。

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

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

[docs.aserto.comの「Aserto vs Topaz」](https://docs.aserto.com/docs/overview/aserto-vs-topaz)は、どこまでがOSSでどこからが商用かを示しています。この線引きがそのまま「2025年6月以降に使えなくなったもの」の一覧になります。

| 機能                | 提供元    | 現在 |
| ----------------- | ------ | -- |
| イベントファブリックによる即時伝播 | 管理プレーン | 停止 |
| 中央ディレクトリ          | 管理プレーン | 停止 |
| Aserto Console    | SaaS   | 停止 |
| ポリシーレジストリ         | SaaS   | 停止 |
| 決定ログの集約           | SaaS   | 停止 |
| IDプロバイダーの常時同期     | SaaS   | 停止 |
| 証明書・認可者の一括管理      | SaaS   | 停止 |
| 認可エンジンとローカルディレクトリ | Topaz  | 稼働 |
| 決定ログのファイル出力       | Topaz  | 稼働 |
| 内蔵コンソール（閲覧UI）     | Topaz  | 稼働 |

旧来の記事が「Aserto Topazの強み」として挙げていた即時伝播やGitHub連携の自動ビルドは、上半分の商用側にありました。OSSのTopazはOPAのポーリングでポリシーイメージを取得します。リポジトリの設定リファレンス（docs/config.md）の例ではmin\_delay\_secondsが60、max\_delay\_secondsが120です。この設定例のままなら、ポリシーの変更が届くまで最大2分ほどかかります。間隔は設定で変えられますが、即時伝播の仕組みはOSSにはありません。

決定ログはOPAのプラグインaserto\_decision\_logで出します。[公式の決定ログ設定](https://www.topaz.sh/docs/decision-logs)では、プラグインの有効化はopaのconfig配下、ファイル出力の指定はトップレベルのdecision\_loggerに書きます。既存の設定ファイルには、opa.configの既存のservicesやbundlesと並べてpluginsを足してください。集約と配送保証は自前で組み、実運用ではログファイルをFluent BitなどでSIEMへ送る構成になります。

```
opa:
  config:
    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が残っています。[ds-loadリポジトリ](https://github.com/aserto-dev/ds-load)のplugins配下には、Auth0、Azure AD、Azure AD B2C、Cognito、FusionAuth、Google、JumpCloud、Keycloak、LDAP、Okta、OpenAPIの11種があります。

違いは同期の性質です。ds-loadはfetch・transform・publishの3段を実行したときに取り込むバッチなので、IDプロバイダー側の変更が届くまでには、定期実行の間隔に処理時間が加わり、実行に失敗すれば次の成功まで反映されません。退職や異動を即時に反映したいなら、IDプロバイダーのイベントを受けてディレクトリのWriter APIを直接呼ぶ仕組みが要ります。この遅れを放置すると、退職者の権限が残る事故につながります。認可の抜けがどう悪用されるかは[認可バイパスの仕組みと対策](/tech/details/16399/)で整理しています。

## Topazをローカルで起動する手順

### CLIとコンテナイメージのインストール

Topaz CLIはLinux・macOS・Windowsに対応し、Homebrew、WinGet、MSI、go install、GitHubリリースのzipで入ります。v0.33.25のzipにはCLIのtopazのほか、サーバー本体のtopazdとバックアップ用のtopaz-backupが入っています。下のHomebrew・WinGet・go installは環境に合うものを1つだけ実行し、最後のtopaz installはどの方法でも共通です。

```
# macOS・Linux（Homebrew）
brew install --cask aserto-dev/tap/topaz
# Windows（WinGet）
winget install Aserto.Topaz
# Go環境があれば
go install github.com/aserto-dev/topaz/topaz@latest

# 共通：コンテナイメージの取得
topaz install
```

topaz installはghcr.ioからコンテナイメージを取得します。v0.33.25のlinux/amd64イメージは147MBでした。Dockerランタイムが前提で、CLIは開発用の自己署名証明書を生成します。ブラウザで内蔵コンソールを開くなら、topaz certs trustでCA証明書をOSに登録してください。

colimaのようにホームディレクトリだけをVMへマウントするDocker環境では、XDG\_CONFIG\_HOMEやXDG\_DATA\_HOMEをホーム外（/tmpなど）に向けるとコンテナが設定を読めず、起動直後に終了します。DOCKER\_HOSTにcolimaのソケットを渡すことも必要です。

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

テンプレートはポリシー、マニフェスト、サンプルデータを一度に展開します。v0.33.25のtopaz templates listが返すのはapi-gateway、simple-rbac、api-auth、slack、peoplefinder、todo、gdrive、github、multi-tenantの9種です。テナント境界を含む認可ならmulti-tenant、エンドポイント単位ならapi-authかapi-gatewayが出発点です。

```
topaz templates list
topaz templates install todo --force --no-console
```

–no-consoleを付けないと、インストールの最後にブラウザでコンソールが開きます。v0.33.25でtodoテンプレートを入れると、オブジェクト20件・リレーション25件がディレクトリに投入されました（2026年11月3日に実行）。参照するポリシーイメージghcr.io/aserto-policies/policy-todo:3.0.0は公開されたままなので、Asertoのアカウントが無くても最後まで通ります。

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

リポジトリのdocs/deployments/docker-compose/docker-compose.yamlに、ポートの用途がコメントで書かれています。サイドカーとして同居させるときの衝突を避けるために押さえておく値です。

| ポート  | 用途          |
| ---- | ----------- |
| 8080 | コンソール HTTP  |
| 8081 | コンソール gRPC  |
| 8282 | 認可エンジン gRPC |
| 8383 | 認可エンジン HTTP |
| 9292 | ディレクトリ gRPC |
| 9393 | ディレクトリ HTTP |
| 9494 | ヘルスチェック     |
| 9696 | メトリクス       |

アプリケーションが常用するのは認可エンジンの8282か8383、データ投入はディレクトリの9292か9393です。9494と9696はKubernetesのプローブとPrometheus向けなので、外部へ公開しないでください。

## AuthZEN（Authorization API 1.0）エンドポイントの実測

### 9393番だけが応答するAuthZEN API

OpenID Foundationは2026年1月12日、アプリケーション（PEP）と認可サービス（PDP）の間の要求と応答を標準化する[Authorization API 1.0をFinal Specificationとして承認](https://openid.net/authorization-api-1-0-final-specification-approved/)しました。作業部会の名前からAuthZENと呼ばれます。Topazのリリースノートでは、2025年2月17日のv0.32.50で「AuthZEN Access service」が入り、2025年12月5日のv0.33.0で実装を「latest draft v0.1.0-05」へ更新しています。Final承認の投票にかけられたのもdraft 05の文書でした。

v0.33.25のtodoテンプレートで確かめると、AuthZENのエンドポイントを返したのはディレクトリの9393番で、認可エンジンの8383番は同じパスに404を返しました。下のcurlの-kは、ローカルの自己署名証明書を検証しないためのオプションです。本番では証明書を正しく配布し、-kを外して呼んでください。

```
curl -sk https://localhost:9393/.well-known/authzen-configuration

curl -sk -X POST https://localhost:9393/access/v1/evaluation \
  -H 'Content-Type: application/json' \
  -d '{"subject":{"type":"user","id":"rick@the-citadel.com"},
       "action":{"name":"can_create_resource"},
       "resource":{"type":"resource-creator","id":"resource-creators"}}'
```

| 呼び出し                   | 結果              |
| ---------------------- | --------------- |
| 9393 .well-known       | エンドポイント5本を返す    |
| 9393 evaluation（rick）  | decision: true  |
| 9393 evaluation（jerry） | decision: false |
| 9393 evaluations（2件一括） | true／false      |
| 9393 search/subject    | 利用者3名を返す        |
| 8383 evaluation        | 404 Not Found   |

### Regoを通らない判定という落とし穴

9393番で応答する理由はソースを読むと分かります。AuthZENのevaluationはディレクトリのCheckへそのまま変換され、actionのnameがリレーションかパーミッションの名前として扱われます。つまりAuthZEN経由の判定はマニフェストの関係定義だけで決まり、Regoのポリシーは評価されません。

この差は設計を左右します。時間帯やIPアドレスなど関係以外の条件をRegoで足しているなら、AuthZEN経由の判定ではその条件が素通りします。APIゲートウェイなど標準規格に対応した製品からTopazを呼ぶ場合でも、条件付きのルールが要るならauthz/isを使うべきです。逆に、純粋な関係チェックだけで足りる用途なら、AuthZENで呼んでおくとPDPを別製品に替えるときの改修が要求と応答の形式の分だけ減ります。ただし、移行先の認証方式、subject・resourceの型名、actionの名前の対応は製品ごとに確認が要ります。

Regoの中から同じ判定を呼ぶ手段もあります。v0.33.0で追加されたaz.evaluationなどのaz系ビルトインで、8383番のauthz/queryで評価するとds.checkと同じ結果（true）を返しました。なお、このaz系の関数は2026年11月時点で公式のビルトイン関数リファレンスに載っていません。ドキュメントより実装が先行しているので、使う前にリポジトリのtopazd/authorizer/builtins/azを確認してください。

## Topazの本番採用を左右するSDK・体制・サポート要件

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

本体と各言語SDKでは、更新の時期に大きな開きがあります。aserto-devの各リポジトリの最終push日です（2026年11月3日に確認）。

| リポジトリ         | 最終push     | 状態        |
| ------------- | ---------- | --------- |
| topaz（本体）     | 2026-10-30 | 毎週〜隔週     |
| go-aserto     | 2026-10-07 | 更新中       |
| aserto-node   | 2026-02-12 | 鈍化        |
| aserto-java   | 2025-12-20 | 鈍化        |
| aserto-dotnet | 2025-04-11 | 以後のpushなし |
| aserto-python | 2025-03-26 | 以後のpushなし |
| aserto-ruby   | 2025-03-17 | 以後のpushなし |

Python・Ruby・.NETは撤退告知の2025年4月前後から1年半pushがありません。保守終了の宣言はありませんが、採用前に、依存ライブラリの既知の脆弱性と、現行のTopazのgRPC定義との互換性を自分で確かめる必要があります。確かめられないなら、SDKを使わずgRPCかHTTPのAPIを直接呼ぶ前提で見積もってください。AuthZENのエンドポイントは素のHTTPとJSONで呼べるので、関係チェックだけならSDK無しでも負担は小さく済みます。

ポリシーイメージのビルドに使うpolicy CLIはopcr-io/policyで管理され、v0.4.4が2026年10月24日に出ています。ツールチェーン全体が止まったわけではありません。

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

Topazを選んでよいのは、GoかNode.jsのアプリで、認可をサイドカーとして同居させ、ポリシーとデータを自分たちで運用する体制があるケースです。Zanzibar型の関係モデルとRegoのルールを1つのコンテナで扱えるのがTopazの構成上の特徴で、Regoの資産があるなら移行コストも小さく済みます。

避けるべきなのは次の場合です。

- Python・Ruby・.NETが主言語で、公式SDKに頼りたい。
- ベンダーのサポート契約やSLAが調達要件にある。Asertoは商用事業を畳んでおり、撤退告知ではメンテナによる商用サポートの「可能性」に触れているだけです。要件を満たす契約を結べるかを事前に確かめてください。
- 複数リージョンの認可データを中央で一元管理したい。それを担っていた管理プレーンは自前で作り直すことになります。

メンテナ2名という体制は、長期の基盤として見るなら織り込むべき数字です。採用するなら、AuthZENかauthz/isの呼び出しを薄い層に閉じ込め、PDPを差し替えられる形にしておくのが現実的な保険になります。

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

上の条件に当てはまるなら、Zanzibar系かポリシー系の別実装を検討します。版番号はGitHubの最新リリース、CNCFの区分は[CNCF Landscape](https://github.com/cncf/landscape)の記載で、いずれも2026年11月3日に確認しました。

| 製品      | 最新版（公開日）             | モデル       | CNCF       |
| ------- | -------------------- | --------- | ---------- |
| OpenFGA | v1.22.1（2026-10-28）  | Zanzibar型 | Incubating |
| SpiceDB | v1.57.0（2026-10-20）  | Zanzibar型 | 掲載のみ       |
| Cerbos  | v0.57.0（2026-10-23）  | ポリシー型     | 掲載のみ       |
| OPA単体   | v1.22.0（2026-10-29）  | ポリシー型     | Graduated  |
| Topaz   | v0.33.25（2026-10-26） | 両方        | 掲載のみ       |

共有・階層・コラボレーションのような関係ベースの権限が中心なら、OpenFGAかSpiceDBが素直です。OpenFGAはCNCFのIncubatingで、存続が1社の事業判断だけで決まらない点がTopazとの最大の差です。属性と条件で判定したいだけならCerbos、Regoの資産を活かしてデータ供給を自分で組めるならOPA単体という切り分けになります。

運用する人手が無く、AWS上で完結するなら、マネージドの[Amazon Verified Permissions](/tech/details/4766/)も候補です。ポリシー言語はRegoではなくCedarなので、Topazからの移行ではポリシーの書き直しが必要になります。どれにするか決めきれないときは、ルールをどこに書くか（関係の定義か、ポリシーのコードか）を先に決めると選択肢が絞れます。

## よくある質問

### Asertoは今も使えますか？

商用サービスとしては使えません。Aserto社は2025年4月27日に事業終了を告知し、SaaSの管理プレーンを同年5月31日までに停止しました。OSSのTopazは別で、2026年10月26日にv0.33.25が出ています。

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

別物です。この記事のTopazは、Aserto社が2022年10月に公開したOSSの認可サービスです。写真や動画の高画質化で知られるTopaz Labsの製品とは開発元も用途も関係がありません。

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

TopazはOPAを決定エンジンとして内蔵しています。v0.33.25に同梱されているのはOPA v1.21.4です。ポリシーはOPAと同じRegoで書き、ビルトイン関数でTopazのディレクトリを参照します。OPA単体との違いは、利用者・グループ・リソースとその関係を持つディレクトリが最初から入っている点です。

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

使えません。イベントファブリックはAsertoの管理プレーンの機能で、SaaSの停止とともに失われました。OSSのTopazはOPAのポーリングでポリシーイメージを取得し、設定例の間隔は60〜120秒です。

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

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

## 関連記事

- [OPAとは？Open Policy Agentの意味・仕組みと使い方【v1.21で実行】](/tech/details/4573/)
- [Regoとは？OPAのポリシー言語の書き方｜Rego v1・rego.v2・v0移行とテスト【OPA 1.22対応】](/tech/details/7523/)
- [Amazon Verified Permissionsとは？Cedarの書き方と料金・API Gateway連携の手順](/tech/details/4766/)
- [RBAC（ロールベースアクセス制御）とは？仕組みと実装手順をSQL・Kubernetesの例で解説](/tech/details/6488/)
- [ABACとは？属性ベースアクセス制御の仕組みとRBACとの使い分けを実装視点で解説](/tech/details/16407/)

---

出典: [Aserto Topazとは？商用サービス終了後もOSSで使えるのか【v0.33.25・2026年11月】](<https://www.issoh.co.jp/tech/details/4609/>)（株式会社一創）