規制業種の企業に適したDust AIの代替製品（コンプライアンスとオンプレミス）

要約

• DustはSOC 2 Type II、GDPR、HIPAA対応を可能にする位置づけを掲げていますが、ISO 27001、ISO 42001、FedRAMPの認証はなく、クラウド専用です。
• 候補の絞り込みは4つの基準で決まります。コンプライアンス認証、導入形態の主権、権限の再現精度、そして価格と価値実現までの時間です。
• Onyxは45以上のコネクタにわたるユーザー単位のACL同期で先行しています。Difyは完全に自社管理できる導入形態を提供しますが、監査の負担は顧客側に移ります。
• 決定論的でオンプレミスのワークフローを、トークンコストを15〜60分の1に抑えて実行したい規制業種の企業には、Jinba Flowがそのコンプライアンス要件に合わせて設計されています。

コンプライアンス要件に合う代替製品はどれか

• Jinbaは、監査対応が可能な自動化のためにオンプレミスかつ決定論的なワークフローを必要とする規制業種の企業（銀行、保険、法務、医療）に適しています。
• Onyxは、SharePointやGoogle Driveといった連携元システムからユーザー単位の権限を同期することが最大の障壁になっている企業に適しています。
• Difyは、独自のAIアプリを開発し、コンプライアンス証明を自社で担える体制のあるエンジニア主導のチームに適しています。

企業はエージェント構築のワークフローを目当てにDustを導入し、調達段階で同じ壁に突き当たります。セキュリティレビューでISO 27001、ISO 42001、FedRAMPを求められるものの、Dustのセキュリティページにはそのいずれも記載されていません。Dustのコンプライアンス範囲は、SOC 2 Type II、GDPR、そしてビジネスアソシエイト契約（BAA）によるHIPAA対応を可能にする位置づけまでで、これは正式なHIPAA認証と同じものではありません。同じレビューでは次に、データを自社ネットワークの内側にとどめられるかが問われますが、答えは「いいえ」です。Dustはクラウド専用であり、EUまたは米国のリージョンホスティングか、専用のシングルテナントインスタンスとして提供されます。自己ホスト、VPC、オンプレミス、外部遮断環境の選択肢はありません。購入を承認するのがコラボレーション部門ではなくコンプライアンス部門である銀行、保険会社、医療機関にとって、この差は代替製品を検討するきっかけになります。より広いAIコンプライアンスツールの分野の中での位置づけも、あわせてご覧ください。

候補を絞り込む基準は4つあり、以下の各製品の評価にも一貫して適用します。

• コンプライアンス認証と監査体制は、ベンダー側の書類だけでセキュリティレビューを初日に通過できるのか、それとも企業側が監査の負担を引き継ぐことになるのかを決めます。ここで防げる誤りは、「SOC 2」という記載があれば規制対象の業務でもそのまま監査に対応できると思い込むことです。
• 導入形態の主権は、データが物理的に企業のネットワークの外に出るかどうかを決めます。ここで防げる誤りは、「準拠済み」とうたうクラウド製品を選んだ後、契約から数か月経った調達の途中で外部遮断環境の要件が判明することです。
• 権限モデルとアクセス同期は、AIエージェントが文書本来のアクセス権一覧に実際に従うのか、それともプラットフォーム側の粗い近似に従うだけなのかを決めます。ここで防げる誤りは、ロールベースのアクセス制御（RBAC）の設定画面が連携元システムと同じ粒度を再現していると思い込むことです。
• 価格と価値実現までの時間は、そのプラットフォームがどれだけ早く費用を回収できるか、また、どのような利用パターンになると個別見積のエンタープライズプランへの移行が避けられなくなるかを決めます。ここで防げる誤りは、そのプラットフォームによって不要になる開発期間やトークン費用を勘定に入れずに、表示価格だけを比べることです。

Jinba：規制業種の企業向けの決定論的なワークフロー

Jinbaは、Y Combinatorの出資を受け、SOC 2に準拠したワークフロービルダーです。銀行、保険会社、法律事務所、医療機関、製薬企業といった、従業員2万人以上の規模の規制業種の大企業に的を絞って設計されています。Dustや類似のツールが呼び出しのたびに確率的な言語モデルで回答を生成するのに対し、Jinbaのワークフローは80%がルールベースで決定論的です。同じ入力からは同じ出力が安定して得られます。KYC処理や融資審査のようなワークフローについて事後に説明責任を果たす必要があるとき、コンプライアンス部門や内部監査部門が求めるのは、まさにこの性質です。この決定論的な仕組みは、外部遮断環境にも対応するオンプレミス導入と組み合わされており、さらに監査ログ、RBAC、シングルサインオン（SSO）、Active Directory連携が、後付けではなくプラットフォームに標準で組み込まれています。

決定論的なアーキテクチャは、AIが実証実験から本番運用へ移る段階で規制業種の企業が直面するコストの問題にも対応します。確率的なエージェントは実行のたびにトークンを消費しますが、Jinbaのルールベースの実行はその一部の費用で動きます。具体的には、同等の確率的エージェントの費用と比べて15〜60分の1であり、これは契約更新を承認するCFOにとって直接意味のある差です。ワークフローはチャットまたはビジュアルエディタで作成し、API、バッチジョブ、MCPサーバーとして導入できます。構築にかかる期間は、コンサルタント主導の自動化プロジェクトで一般的な数か月ではなく、数日単位です。

メリット：

• 決定論的な実行と、オンプレミスおよび外部遮断環境への導入は、規制業種のコンプライアンスレビューで最初に問われる2点に対応している。Dustではいずれも利用できない。
• ワークフロー、エージェント、コネクタを個人ごとに作るのではなく、RBACのもとでチーム全体で共有できる。Claude Coworkのような個人利用が前提の確率的なツールが規制業種の業務チームに残す空白を埋められる。

デメリット：

• 公開されている認証の範囲は、一部の代替製品より狭い。SOC 2への準拠は明示されているが、ISO 27001、ISO 42001、FedRAMPについての記載はない。
• 導入実績と事例の蓄積が最も厚いのは日本市場（MUFG（三菱UFJ銀行）を含む）で、米国での展開はクレジットユニオンと日系銀行の米国支店が中心にとどまる。

適している企業：決定論的でオンプレミスのワークフロー自動化を必要とし、個人向けの生産性ツールではなく、停滞したPower AutomateやUiPathの導入を置き換えようとしている規制業種の企業。

Onyx：権限を正確に反映する企業内検索

Onyxは、GitHubのスター数がおよそ20,000あるオープンソースの企業内検索・アシスタント基盤で、SOC 2 Type IIの認証を取得しています。また、現在FedRAMP、ITAR、CMMC、FERPA、GDPRの規制下にある環境で稼働していると説明しています。この表現には注意が必要です。示されているのはOnyxが稼働している環境であって、Onyx自身が取得したFedRAMPの認可ではありません。調達部門はコンプライアンスレビューの際に、この2つを混同すべきではありません。

Onyxが本記事の他のどの選択肢よりも優れているのは、権限の再現精度です。Onyxは接続されたすべてのソースから、ユーザー単位・文書単位のアクセス制御リストを同期します。対象はSharePoint、Confluence、Google Drive、Slackなど合計45を超えるコネクタにおよび、アクセス権の変更は数分以内に反映されます。プロビジョニングはSCIM、またはOktaやAzure ADといったIDプロバイダー経由で行われます。これはDustのモデルより明確に踏み込んだ内容です。Dustではエージェントが接続先データソースの権限をエージェント単位で引き継ぎ、ユーザー単位のACLを直接同期する方式ではありません。権限モデルの違いが最も大きく表れるのは、銀行が現在検討しているエージェント型AIツールにおいても同じ点です。AIアシスタントが本来閲覧権限のない相手に文書を提示してしまうことがコンプライアンス上のリスクである企業にとって、購入を決めるのはこの基準です。

導入形態も同様に柔軟です。自社管理型は4通り（AWS、Azure、GCP上のVPC、オンプレミスのデータセンター、インターネット接続を一切必要としない外部遮断環境、そしてベアメタル）あり、いずれもデータが顧客のネットワークの外に出ることはありません。加えて、ローカルのオープンウェイトモデルや任意のプロバイダーを利用するマネージドクラウドの選択肢もあります。

メリット：

• 権限同期について、本記事の比較の中で最も詳しく裏づけが示されている。45以上のコネクタを対象に、数分単位での反映とSCIM／IDプロバイダーによるプロビジョニングに対応。
• 外部遮断環境とベアメタルを含む4通りの自社管理型の導入形態を備え、導入の柔軟性ではDifyと同等以上。

デメリット：

• 「FedRAMP／ITAR／CMMC／FERPA環境で稼働している」という表現が示すのはOnyxの稼働場所であり、Onyx自身が保有する認可ではない。調達部門は認証として受け取らず、この違いを確認する必要がある。
• Onyxの位置づけは企業内検索とアシスタントの用途であり、JinbaやDifyのようなワークフロー構築とオーケストレーションが中心ではない。求めているのが検索ではなく、決定論的で複数段階の業務プロセスを構築することである場合、この違いは重要になる。

適している企業：コンプライアンス上の障壁が、多数かつ多様な連携先システムにわたる権限の再現精度そのものである企業。

Dify：自社ホスト型のAIアプリ基盤

Dify Enterpriseは、自社で管理するインフラ上に独自のAIアプリケーションやエージェントを構築したいチームに向けて作られています。提供されるのは、Helm／KubernetesとTerraformモジュールによるVPC、オンプレミス、外部遮断環境への導入、SAMLまたはOIDCによるSSO、ワークフロー単位のRBAC、SCIMによるプロビジョニング、そしてSIEMへ転送できる改ざん検知付きの監査ログです。持ち込み鍵（BYOK）による暗号化によって、データは顧客自身のVPC、リージョン、セキュリティ境界の内側にとどまり、モデルの学習に流出することはありません。マルチテナント分離により、テナントごとに利用量の上限とアクセスポリシーが適用されます。

トレードオフは認証にあります。Difyのエンタープライズ向けページには、自社で取得したSOC 2やISOの認証は掲載されていません。これは、自社ホスト型の導入では認証と監査の負担がベンダー側ではなく、顧客自身の環境と証明手続きに大きく移ることを端的に示しています。この点はDustのモデルとは逆です。Dust自身の監査についてVantaが伝えるところによれば、Dustは最小限のエンジニアリング工数で3週間のうちにSOC 2 Type IIの監査対応を整え、コンプライアンス業務の負荷を半減させました。SaaSベンダーが認証取得を一元的に引き受けるためです。自社ホストで得られるのはインフラの管理権であって、認証済みの環境ではありません。Difyを選ぶ企業は、その差を埋めるだけの監査体制の成熟度を自ら備えている必要があります。

価値実現までの時間について、Difyは、AIアプリケーション1件あたりの立ち上げ期間を、自社開発でおよそ4か月かかっていたところから約2週間に短縮したと報告しており、導入事例としてA.P. Møller-Maerskを挙げています。

メリット：

• 導入形態の主権を完全に確保でき（VPC、オンプレミス、外部遮断環境）、BYOK暗号化とテナント単位の分離にも対応。インフラの管理権では本記事で最も強い選択肢と同水準。
• 独自のAIアプリケーションをゼロから開発するチームについて、立ち上げ期間の短縮が示されている（自社開発で約4か月に対し、約2週間）。

デメリット：

• 自社で保有するSOC 2やISOの認証がないため、本来SaaSベンダーが一元的に担うコンプライアンス証明の作業が、顧客自身のセキュリティ部門に回ってくる。
• ワークフロー単位のRBACとSCIMは十分な水準だが、連携元システムから直接取得するOnyxのユーザー単位・文書単位のACL同期には及ばない。

適している企業：社内にセキュリティと監査の体制を持ち、既製のワークフロー層を採用するのではなく、独自のAIアプリケーションを自ら構築して保有したいエンジニアリング組織。

比較表：エンタープライズのコンプライアンスから見たDust AIの代替製品

よくある質問

Dust自体は自社ホストできるのか、それともクラウド専用なのか。

Dustはクラウド専用です。公開されている導入形態はEUまたは米国でのリージョンホスティングと、専用のシングルテナントインスタンスであり、顧客が自ら管理する自己ホスト、仮想プライベートクラウド（VPC）、オンプレミス、外部遮断環境の構成は提供されていません。EU／米国のリージョンホスティングでは満たせない厳格な外部遮断やデータ所在地の要件がある企業は、自社ホストできる代替製品（OnyxまたはDify）か、Jinbaのオンプレミス導入を選ぶ必要があります。

EU AI法はこれらのプラットフォームの評価方法を変えるのか。

EU AI法における高リスクAIの義務は、第9条から第17条を対象として2026年8月2日から適用されます。人事、採用、安全といった領域の意思決定にエージェントが関わる企業にとって、これらの義務に対するベンダーの姿勢は、将来の課題ではなく現時点の調達上の論点になります。本記事で比較した製品を含め、どのベンダーに対しても契約前に確認しておく価値があります。

「SOC 2 Type II認証を取得している」と「FedRAMP環境で稼働している」は実務上どう違うのか。

SOC 2 Type IIの認証は、独立した監査人がベンダー自身の統制を一定期間にわたって検証したことを意味します。一方、Onyxが自社の稼働状況について述べている「FedRAMP規制下の環境で稼働している」とは、その認可を受けた顧客側の環境の中でプラットフォームが動いているという意味です。Onyx自身がFedRAMPの認可を受けたことを意味するものではありません。この観点でベンダーを評価する調達部門は、そのベンダーが保有している認証と、顧客がたまたま運用している規制環境とを分けて、直接確認すべきです。

自社ホスト型の導入とSaaSでは、コンプライアンスの作業負荷を誰が引き受けるのか。

DustのようなSaaSプラットフォームでは、ベンダーが認証を一度取得し、その成果をすべての顧客が引き継ぎます。Dust自身がSOC 2 Type IIの取得過程について述べているところでは、3週間で監査対応が整い、コンプライアンス業務の負荷が50%削減されました。一方、Difyのような自社ホスト型のプラットフォームでは、同じ形の一元化は成り立ちません。監査の対象になるのは顧客自身の環境であり、Difyのエンタープライズ向けページにも自社で取得したSOC 2やISOの認証は記載されていません。インフラの主権と、認証が一元化されていることの安心感は、実務上どちらかを選ぶ関係にあります。どちらを取るべきかは通常、その企業自身の監査体制の成熟度で決まります。