ZluriとToriiの比較：2026年、SaaSスタックに必要なのはアイデンティティセキュリティか、AIガバナンスか

著者: Camellia · 更新日: 2026年9月9日

あなたは従業員250人から2,000人規模の企業でIT DirectorまたはHead of Identityを務めており、ZluriとToriiの両方が候補に挙がっています。これは偶然ではありません。Zluri自身の想定規模はこの範囲の大きいほうに、Toriiは小さいほうに偏っているため、従業員数がその中間にある場合は、どちらのベンダーも喜んで商談に応じる領域のど真ん中にいることになります。ただし、どちらも商談に入る前に費用を教えてくれず、いくら掘り下げても料金表は見つかりません。両社の料金ページは、あなたを担当者へ誘導するためだけに存在しており、しかも両社とも、この1年で実際に販売しているものを静かに変えています。

詳細に入る前に結論を述べます。Zluriはより深いアイデンティティおよびガバナンスのスタックであり、その分だけ運用は重くなります。Toriiは立ち上げが速いツールで、マルチシグナルの検出と、エンジニアなしで自社チームが運用できるワークフロービルダーを軸に作られており、現在はアイデンティティセキュリティよりもAIガバナンスに照準を合わせています。両者の選択は、機能リストを選ぶことではなく、今後2年間の製品の方向性を選ぶことです。どちらの会社も「SaaS管理」の意味を自ら積極的に作り直しているからです。SaaS管理プラットフォームのまとめで、この2社がカテゴリの他社に対してどこに位置するかはすでに整理しているため、このページでは2社だけに絞ります。具体的には、それぞれが今何のために作られているのか、どうやってアプリを見つけるのか、ガバナンスはどこまで深いのか、どんなアーキテクチャを買い込むことになるのか、そして推測に頼らず公正に比較できる見積もりをどう取るのか、という点です。

TL;DR

上の表は意思決定の全体像であって、すべてではありません。Zluriのモジュールを3つ購入する企業と、Toriiの3製品すべてを購入する企業のどちらが多く支払うことになるのかは、この表からは分かりません。どちらのベンダーも、その計算を公開の場に示していないからです。それが、このページの残りでセクションごとに掘り下げていく内容です。

重要なポイント

• 組織は平均でSaaSライセンスの36%を未使用のまま放置しており、従業員1人あたりのSaaS支出の中央値は$9,455です。これはZyloの2026 SaaS Management Indexによるものです。
• SaaSの価格上昇率は2026年6月に16.4%に達し、当時の米国のCPI（4.2%）の約4倍でした。これはVertice SaaS Inflation Indexによるものです。VerticeはSaaSの価格交渉サービスを販売しているため、中立的な調査ではなくベンダーの指標として読んでください。
• Toriiは自社ホームページで「named a Leader in the July 2026 Gartner Magic Quadrant for SaaS Management Platforms」と述べ、顧客が「cut costs by 25%」できたと主張しています。出典はToriiです。この順位はレポート自体と照合して検証していないため、独立して確認された事実ではなくToriiの主張として扱ってください。また、同じレポートで他のベンダーがどこに位置したかについても、何も推測しないでください。
• Zluriは自社ホームページで、ISPMの修復向けに「1,500+ automated actions」を謳っています。出典はZluriで、単純なデプロビジョニングを超えてガバナンス自動化がどこまで及ぶかを示す1つのデータポイントです。

それぞれのプラットフォームは何のために作られているのか

両社とも同じ場所から出発しました。会社が実際に使っているSaaSアプリの棚卸しです。その後どちらもそれをはるかに超えて構築を進めており、その先に何を作ったかが本当の物語です。

Zluriの料金ページには6つが掲載されています。IVIP（Identity Visibility and Intelligence）は検出と棚卸しのレイヤーで、「どのアプリとアイデンティティが存在するのか」に答える部分です。IGAは1つの名前の下に4つの異なる機能をまとめています。Access Management（誰が何を持っているか）、Access Requests（新しいアクセスがどう付与されるか）、Access Reviews（既存アクセスの定期的な再認証）、Segregation of Duties（単一のアイデンティティが利益相反を生む権限の組み合わせを持たないようにすること）です。ISPM（Identity Security Posture Management）は修復と堅牢化のレイヤーで、「1,500+ automated actions」の主張を担う部分です。おそらく、過剰な権限の取り消し、古いアカウントの閉鎖、監査人に見つかる前の誤設定アクセスの検知といったことを指すのでしょう。SMPは元のSaaS Management Platformで、かつては製品の全体だったモジュールが、いまでは5つのうちの1行になっています。IRIS（Identity Risk Intelligence System）は他のレイヤーの上に乗るリスクレイヤーとして名前が挙がっていますが、Zluri自身の料金ページは名前以上の仕組みを説明していないため、これ以上は推測しません。Universal Identity Connectorが5つすべてを1つのデータモデルに結び付けます。SaaS管理は、いまや主役ではなく、支える側のモジュールです。

Toriiの料金ページには3つが掲載されています。IGAは比較的新しい追加で、Toriiのページは、Zluriのように下位の機能へ分解していないため、職務分掌まで含むのか、アクセス申請とレビューだけなのかを確信を持って言うことはできません。SMPは引き続きApp Discovery、Savings and Renewalsと説明されており、ここは立ち止まる価値があります。この表現は、支出管理の仕事（節約と更新）を検出と同じモジュールに折り込んでおり、これはZluriの5つのモジュールのどこにも名前が出てこないものです。3つ目は、4つの名前付き機能を軸に作られた独立のAI Management製品です。AIアプリとプロジェクトの検出（どのAIツールとプロジェクトが存在するかを見つけること）、トークン消費量の追跡（各モデルの利用がどれだけ、誰によって消費されているか）、部門別のAI利用と支出（そのコストをコストセンターに帰属させること）、そして導入率とROIのレポーティング（AI支出が測定可能な利用を実際に生んでいるか）です。

製品の方向性：アイデンティティセキュリティかAIガバナンスか

どちらの会社もSaaS管理プラットフォームにとどまることに満足しておらず、その拡張の方向も同じではありません。

Zluriのホームページは「Identity Security for Autonomous Enterprises」を前面に出しており、この枠組みは人間と非人間の両方のアイデンティティを明示的に対象としています。出典はZluriです。サービスアカウント、APIキー、マシンアイデンティティが人と並んで名前が挙がっていることは、今後数年のエンジニアリング投資がどこへ向かうと同社が見ているかを示しています。どのアプリが存在するかだけでなく、誰が、何が、システムにアクセスできるのかというところへ、さらに深く入っていくのです。

Toriiの最新の賭けは異なります。そのAI Management製品は、AIアプリとAIプロジェクトの検出、トークン消費量の追跡、部門別のAI利用と支出、導入率、ROIのレポーティングを軸に作られています。これもガバナンスの課題ですが、Zluri流のアイデンティティセキュリティではなく、急成長するツールカテゴリに対する支出と利用のガバナンスです。

2つの方向性は、異なる予算と、契約に署名する異なる人物も指しています。調達が絡んでくると、この点は思った以上に重要になります。

どちらのプラットフォームを今購入しても、現在の機能リストだけでなく、その方向性を買い込むことになります。SaaS管理プラットフォームのままであってほしいと考える購入者は、どちらのベンダーも、その言葉の意味を、異なる方向に向けて静かに再定義していることに気づくでしょう。どちらの再定義も間違いではなく、中立的なマーケティングでもありません。アイデンティティセキュリティもAIガバナンスも、いま実際に成長している予算項目であり、各社は自社の今後数年の成長を支えてくれると考える側へ、自らを位置付け直しています。購入者にとってはこれは有益な背景情報です。つまり、今は必要のないモジュール、Zluri側ならIRIS、Torii側ならAI Managementは、時間をかけて各社がまさに最も売り込みたいモジュールだということだからです。

検出：それぞれがどうやってアプリを見つけるのか

Zluriの有名な検出に関する数字、つまり古い比較記事の多くが今も繰り返している連携数やアプリライブラリの規模は、現在Zluriのサイトでは公開されておらず、Zluri自身のブログ記事同士も数値が食い違っています。不安定な数字を繰り返すより、情報源が変わっても変わらない、検出方法で2つを比較するほうが有益です。

両社とも本質的に同じ方法のリストをカバーしており、つまり方法のリスト自体は決め手になりません。また、各方法は実際のアプリ全体のうち異なる一部を捕捉するため、「検出」が単一のものを意味すると思い込む前に、これを知っておく価値があります。

2つのプラットフォームが実際に分かれるのは検出の後です。そのシグナルは、アイデンティティガバナンスのワークフロー（Zluri）に流れ込むのか、それとも節約、更新、AI支出のワークフロー（Torii）に流れ込むのか。どちらの製品もIDプロバイダー自体を置き換えるものではなく、どちらもその上に載っています。その基盤レイヤーをまだ選んでいる最中であれば、JumpCloudの代替ツールのガイドがその判断を別途扱っています。

ガバナンス、アクセスレビュー、オフボーディング

検出は、何が存在するかを教えてくれます。ガバナンスは、誰がそれにまだ触れてよいのか、そしてその答えが変わった瞬間に何が起きるのかを教えてくれます。これは、このカテゴリ全体の中で、より難しく、より重大な後半部分です。ここでは、2つのプラットフォームがモジュール名だけでなく、深さにおいて本当に分かれます。

ZluriのIGAとISPMのモジュールは合わせて、アクセス申請、アクセスレビュー、職務分掌のチェック、自動修復をカバーしており、同社は自社ホームページでISPMの修復向けに「1,500+ automated actions」を謳っています。出典はZluriです。これは本格的なガバナンスプログラムであり、四半期に一度確認するダッシュボードではなく、アイデンティティまたはセキュリティのチームが継続的に運用するものです。

Toriiの強みは1つ上の層にあり、ポリシーの深さではなく、使いやすさにあります。そのワークフロービルダーは明確にノーコードのツールで、エンジニアではなくIT運用の担当者が、HRが従業員を退職者としてマークしたときに何が起きるかを設定できるようにすることを目指しています。指定したアプリ全体でのアクセスの取り消し、ファイルの再割り当て、アプリ担当者への通知、そのすべての記録です。ToriiのIGAモジュールは新しいため、Zluriのアイデンティティスタックのように何年もかけて成熟する時間がありませんでした。

同じ出来事、つまり従業員の退職を順にたどって、各プラットフォームが実際にどこで動くのかを見ると分かりやすくなります。

Zluri側のその表に何が欠けているかに注目してください。ファイルとデータの扱いという名前付きのステップです。これはZluriがファイルを扱えないという意味ではなく、アクセスレビューや職務分掌のようには、料金ページがそれを独立した機能として名前を挙げていないというだけのことです。退職する従業員のファイルやドキュメントを自動で再割り当てすることが特定の要件であるなら、どちらのプラットフォームのマーケティング文書でもカバーされていると思い込まず、直接尋ねてください。

連携とアーキテクチャ

各製品の背後にあるアーキテクチャの選択は、モジュールのリストと同じくらい重要です。

Zluriは料金ページでUniversal Identity Connectorを挙げています。これはIVIP、IGA、ISPM、SMP、IRISを横断する、1つの統合レイヤーを明示的に目指したものです。対照的に、Toriiの料金ページは、IGA、SMP、AI Managementを3つの名前付き製品として販売しており、それらを横断する1つの接続レイヤーを謳っているわけではありません。

Zluriのような単一コネクタのアーキテクチャは、5つのモジュールの内側にとどまっている限りは便利ですが、アクセスに関するロジックの多くが1つのベンダーのコネクタ層の中に置かれることも意味します。Toriiの別々に販売される3つの製品は、1つずつ段階的に導入しやすい反面、統合作業が、1つの宣伝された共通レイヤーではなく、3つの製品のデータモデルに分散します。どちらの形が客観的に優れているということはなく、統合リスク（1つのベンダーがあなたのアイデンティティグラフをより多く保持すること）と、統合のオーバーヘッド（3つの購入を自分で組み合わせること）の間のトレードオフです。

このトレードオフは、各ベンダー自身の接続が時間とともにどう振る舞うかにも表れます。ユニバーサルコネクタのモデルは、同じベンダーから購入するモジュールが増えるほど充実する傾向があります。新しいモジュールごとに、他のモジュールがすでに収集したアイデンティティの文脈を再利用できるからです。製品ごとのモジュール型モデルは、モジュール単位では考えやすいままですが、1つの宣伝されたレイヤーがその役割を果たしてくれるのではなく、IGA、SMP、AI Managementの間にあるTorii自身の内部連携に頼ることになります。各ベンダーに、モジュール同士がどのようにデータを共有しているかを直接尋ねてください。これは妥当なデューデリジェンスの質問であり、どちらの料金ページもそれに答えていません。

必要なのがアイデンティティレイヤーではなく、ハードウェア、ソフトウェア、担当者、更新を1つにまとめた台帳なら、どちらもそのためのツールではありません。その別のカテゴリについては、IT資産管理ソフトウェアのガイドで扱っています。

料金：なぜどちらも公開しないのか、そして比較可能な見積もりの取り方

zluri.com/pricingには「Schedule a personalized discovery session」しかありません。ページにはプランも、料金も、トライアル期間もありません。toriihq.com/pricingも同じ形で、3つの製品の名前は載せていますが、金額、トライアル期間、課金条件は公開していません。どちらのベンダーも、数字の前に会話を求めており、これはアイデンティティやガバナンス系のソフトウェア全般でよくあることです。価格は、調べられる席単位の定額ではなく、リスクの範囲やポリシーの複雑さに連動する傾向があるからです。

ZluriもToriiも、その会話がどう見積もりになるのかを説明していませんが、同じカテゴリの近いライバルは説明しています。BetterCloud自身の料金ページは、価格が「reflects your license count, connected apps, chosen modules, and any add-ons」であると明言しています。出典はBetterCloudです。BetterCloudはこのページのベンダーではありませんが、カテゴリ全体の価格の付け方を示す妥当な目安になります。事前に調べられる席単価ではなく、ライセンス数、接続されたアプリ、モジュールの選択が価格を左右するのです。

2つの仮想の企業で、これを具体的に考えてみましょう。1社目は従業員1,800人、2人のアイデンティティチーム、すでに四半期ごとのアクセスレビューが必須のコンプライアンスカレンダーを持っています。この企業がZluriとの通話に臨むときのモジュール候補は、アクセスレビューと修復がすでに明確な要件であって、あれば良いというものではないため、おそらく最低でもIVIPとIGAとISPMになるでしょう。2社目は従業員380人で、専任のアイデンティティ担当はおらず、IT運用のリーダーが主に心配しているのは、3つの異なるチームが誰にも告げずに登録したAIツールです。この企業にとってのToriiとの通話は、実質的にアプリ検出のSMPと、AI支出の可視化のためのAI Managementが中心で、IGAは通話の理由ではなく二次的な問いです。どちらの企業も、相手のベンダーとの通話に同じモジュールリストを持って臨むべきではありません。価格が会話に入る前から、候補リスト自体がすでに違って見えるはずです。

どちらの通話にも、次の情報を用意して臨んでください。

どちらのベンダーも自社の一覧表を公開していないため、一般的な言い方になりますが、金額を上下させる要因は次のとおりです。

モジュールのリストに加えて、通話の場で投げかける短い質問の一覧が、使える見積もりと宣伝用の数字とを分ける傾向があります。

モジュールのリストが決まったら、通話の最中ではなく通話の前に、依頼内容を明細化してください。見積もりのみで購入するあらゆる案件に自社のチームが使う手順と同じものを、ベンダーデューデリジェンスのチェックリストのように各ベンダーに適用し、比較そのものはSaaSのRFPの進め方のように構成してください。そうすれば、「Zluriのほうが高かった」「Toriiのほうが安かった」が、異なる範囲を比べているだけの話にならず、意味を持つようになります。

導入と変更管理

どちらのプラットフォームでも、導入は概ね同じ段階を踏みます。検出ソースを接続し、フラグが立ったものをレビューし、それに対処するポリシーやワークフローを設計し、自動化を有効にし、その後モニタリングする、という流れです。2つが違うのは、「自動化を有効にする」段階に到達するまでにかかる時間です。Zluriの5つのモジュールは、自動修復を安全に有効化できるようになる前に順序立てるべきアイデンティティの種類とポリシーが多いことを意味します。IGAのアクセスレビューが少なくとも一度実行される前に、ISPMにアクセスを自動で取り消させたくはありません。そのため、モジュールには自然な、そしてより遅い作業順序があります。Toriiのワークフロービルダーは、特にオフボーディングの用途では、その段階により速く到達できます。完全なアイデンティティスタックではなく、より用途の絞られた専用ツールだからです。ただし、新しいIGAとAI Managementの追加には、元の検出製品が蓄積してきたのと同じ導入ノウハウが、まだ年月をかけて積み上がってはいません。

トレーニングの負荷も同じパターンをたどります。Zluriの導入では通常、アイデンティティまたはセキュリティの専門家を、IGAのポリシー設計とISPMの修復ルールについて訓練する必要があり、これはアクセスガバナンスの概念にある程度慣れていることを前提とした作業です。Toriiの導入では通常、IT運用の担当者全般を、ワークフロービルダーのルールロジックについて訓練します。これは設計上、学習曲線がより浅く、加えて、財務またはITの誰かがAI Managementのレポートを使うことになる場合は、別途小さな立ち上げ期間が必要です。

リスク、ガバナンス、ベンダーの継続性

どちらのベンダーも見積もりのみであるため、更新時にそれぞれがどう価格を設定するのか、あるいは関係が終了したときにデータがどうなるのかも見えません。これはこのカテゴリでは仮定の話ではありません。同じSaaS管理領域で資金力のある名前だったProductivは、2026年8月2日に顧客に対し、8月6日に事業を終了し、アクセスが終了した後にアカウントデータを削除すると通知しました。これは1Passwordが公開した移行ガイダンスによるものです。何年分もの利用履歴を保持するプラットフォームに対し、通知期間はわずか4日でした。ZluriもToriiもProductivではありませんが、この教訓は一般化できます。データの移行可能性と通知期間については署名の後ではなく前に尋ね、見積もりのみのベンダーが更新条件について黙っていることは、思い込みで済ませるのではなく、通話の場で提起すべき問いとして扱ってください。

この2社に特有の、もう一つの目立たないリスクがあります。どちらのプラットフォームも、アイデンティティのワークフローに深く組み込まれるほど、誰が何にアクセスできるかを示す記録システムになっていきます。これはまさに購入の目的ですが、同時に、後でベンダーを乗り換えることが、検出ツールを入れ替えるようにはいかないことも意味します。アクセスレビューの履歴、職務分掌のルール、そして（特にZluriの場合は）非人間アイデンティティの棚卸しを、新しいプラットフォームに移し替えることになるからです。その履歴のエクスポートが実際にどのような形になるのか、そして自社のプラットフォームの外でも使えるのか、それとも事実上そこに縛られるのかを、各ベンダーに平易な言葉で尋ねてください。

どちらのベンダーの主張も、引用に値するものはありますが、帰属を明示した場合に限ります。どちらも独立して検証されていないためです。

Zluriが適切な選択となる場合

• 2つの製品をつなぎ合わせるのではなく、アイデンティティガバナンスとSaaS検出を1つのアーキテクチャの下で実現したい。そして、これを単なるSaaS管理ではなく、アイデンティティセキュリティの購入と呼ぶことに抵抗がない。
• 非人間アイデンティティ、つまりサービスアカウント、APIキー、エージェントが、すでに将来の問題ではなく、現在進行形のガバナンス課題になっている。Zluriは自社ホームページで、これを人間のアイデンティティと並ぶ第一級の対象として明示しています。
• IGAのポリシー設計、アクセスレビュー、職務分掌のルールを担えるアイデンティティまたはセキュリティのチームがすでにいるか、積極的に構築している。これは四半期に一度眺めるダッシュボードではなく、継続的な運用作業だからです。
• アプリ数の純粋な検出よりも、自動修復のほうが重要である。ZluriがISPMで1,500以上の自動アクションを謳っていることは、エンジニアリング投資がどこへ向けられてきたかを示しており、軽量な検出ツールが張り合おうとしない深さです。
• 従業員数が250人から2,000人の範囲の大きいほう、あるいはそれ以上にある。Zluriの想定規模は大きな組織寄りで、5つのモジュールからなるスタックは、運用上のオーバーヘッドを正当化できる規模があるほど意味を持ちやすくなります。
• 同じアイデンティティデータの一部ずつを担う3つか4つの個別ツールを運用するより、アイデンティティの可視化、ガバナンス、ポスチャ管理を1つのコネクタの下に集約したい。Universal Identity Connectorは、まさにその集約に向けたZluriの提案です。

アイデンティティの深さが今の自分には過剰である場合、あるいは見積もりのみのプロセスが購買サイクルに合わない場合は、Zluriの代替ツールのガイドが、検出とガバナンスの領域の残りをカバーしています。

Toriiが適切な選択となる場合

• セキュリティの専門家でもエンジニアでもなく、IT運用の担当者が、他のチームにチケットを起票することなく、オフボーディングのワークフローを構築し維持できるようにしたい。
• 最も差し迫った死角が、特にAIツールの乱立である。どのAIアプリやプロジェクトが存在し、どれだけのトークンを消費しており、どの部門が支払っているのか。これは検出に後付けされた副次的な機能ではなく、今ではToriiの専用製品です。
• 少なくとも自社内のビジネスケースでの論点として、独立したアナリストの評価を示せるプラットフォームがほしい。Toriiは2026年7月のGartner Magic Quadrant for SaaS Management Platformsでリーダーに選ばれたと述べていますが、ここでは当社が独立して確認したものではなく、Torii自身の主張として扱っています。
• 従業員数が100人から2,000人の範囲の小さいほうから中程度にある。Toriiの想定規模はZluriより小さく、より軽量で、モジュールごとに導入していく道筋のほうが、より小規模なIT運用チームには合う傾向があります。
• 初日から完全なアイデンティティセキュリティのロードマップにコミットするのではなく、まずSaaS管理を購入し、ガバナンスは後から重ねたい。特に、セキュリティ部門がまだそれを運用できる体制になっていない場合に当てはまります。
• 別々の検出プラットフォームの上に別の支出管理プラットフォームを購入するのではなく、アプリを検出するのと同じツールの中に、節約と更新の作業を折り込みたい。ToriiのSMPモジュールは、その2つの仕事をまとめて名前に挙げています。

検出に軽量なワークフロービルダーを加えただけでは足りない場合、あるいは先に市場全体をもっと比較したい場合は、Toriiの代替ツールのガイドが、検出を第一に置いたプラットフォームの、より広い選択肢をカバーしています。

意思決定フレームワーク

これらの行のどれも、通話そのものの代わりにはなりません。どちらの営業チームにも議題を決めさせるのではなく、自社の状況にとってどの質問が重要かをあらかじめ分かったうえで臨むための手段です。複数の行が当てはまるのは普通のことで、フレームワークが壊れている印ではありません。多くの場合、正直な答えは両方を候補に入れ、料金のセクションにある同じ聞き取りの質問を両社に投げ、モジュールのリストだけでなく2つの見積もり（そして更新やデータ移行可能性の質問への各ベンダーの答え方）に最終判断を委ねることだ、という意味です。

次のステップ

どちらの通話を受ける前にも、実際に購入するのは2つの製品のどちらなのかを書き出してください。たまたまSaaS検出を含んでいるアイデンティティセキュリティプラットフォームなのか、それとも、AIガバナンスを含み始めたSaaS検出プラットフォームなのか。事前に決めたこの一文が、あなたの問いに答える代わりにベンダーのロードマップをそれとなく売り込むデモを避ける助けになります。そのうえで、製品名ではなくモジュールごとに明細化した見積もりを依頼し、更新とデータ移行可能性の質問を含め、上の料金のセクションにある同じ聞き取りのリストを両ベンダーに当ててください。

具体的な手順は短くまとめるとこうです。まず、現在どのガバナンス課題に最も時間を取られているかに基づいて、モジュールの候補リストを書き出します。記憶が新しいうちに比較できるよう、数週間空けず、同じ週に両社との通話を予約します。両ベンダーに、同じ言葉で同じ更新とデータエクスポートの質問をし、記憶に頼らず答えを書き留めます。そして、その後で初めて、1つにまとめた数字同士ではなく、モジュールごとに2つの見積もりを並べて比較します。

本当に必要なのが、アイデンティティやアプリのガバナンスではなくデバイス管理だと分かった場合、それはまったく別の比較になります。その判断については、JamfとIntuneの比較が単独で扱っています。