Dify をチーム導入するときに最初に迷いやすいのが、誰にどこまで触らせるかという権限設計です。2026年7月2日更新の Dify 公式ドキュメントでは、ロールは Workspace 単位で管理され、Settings > Members から招待・変更・削除を行う前提に整理されています。つまり、単に「開発者には Editor を付ける」と決めるだけでは足りず、モデル設定、ナレッジベース、公開済みアプリ、外部ユーザー導線まで含めて運用ルールを揃える必要があります。
この記事は、Dify の権限設計をこれから整える担当者、PoC から本番運用へ移るチーム、メンバー追加が増えてきた管理者に向けて、2026年8月14日時点で確認できる一次情報を基準に「どのロールを誰に割り当てるべきか」「招待フローで何を見落としやすいか」「業務委譲をどこまで許可するか」を整理するガイドです。画面手順だけでなく、最小権限、承認フロー、部署別の割り当て例まで含めて解説します。
- Owner / Admin / Editor / Normal の4ロールを、Dify Cloud の現行仕様に合わせて整理します。
- 招待リンクの72時間制限、Sandbox / Professional / Team の人数制限など、見落としやすい運用条件をまとめます。
- 手順だけで終わらせず、部門別ロール設計、権限棚卸し、相談導線までつなげます。
Difyのロール管理とは？初心者向けにやさしく解説
そもそもロール管理とは何か
ロール管理とは、ユーザーごとに「何を見られるか」「何を変更できるか」「誰を追加できるか」を決める仕組みです。Dify ではこの考え方がワークスペース運用の中心にあり、AI アプリを作る人、使うだけの人、モデル設定や請求管理まで担う人を同じ権限にしないことが前提です。全員が強い権限を持つ状態は一見便利ですが、プロンプト変更、モデル差し替え、メンバー削除、公開設定の変更が誰でもできるようになり、事故の切り分けが難しくなります。
2026年7月2日更新の Manage Members によると、Dify Cloud の built-in roles は Owner、Admin、Editor、Normal の4つです。Owner はワークスペース全体を完全に管理し、1ワークスペースにつき1名です。Admin はメンバーと model providers を管理でき、Editor ができる作業も行えます。Editor は apps と knowledge bases を作成・編集・削除でき、Normal は公開済みアプリの利用が中心です。以前のブログ記事や解説動画では Member や Viewer といった表現が混在することがありますが、現行ドキュメントでは Normal が基準です。
ここで重要なのは、ロールだけですべての可視範囲が決まるわけではない点です。公式 docs でも、Owner / Admin / Editor が knowledge base を作成できても、既存のナレッジベースを誰が閲覧・利用できるかは個別設定で制御すると説明されています。つまり、ワークスペース権限とリソース権限を分けて考えないと、「Editor だから全部見えるはず」「Normal だから安全なはず」という誤解が起きやすくなります。
なぜ Dify で権限設計が重要なのか
Dify はチャットアプリの試作だけでなく、ワークフロー、RAG、外部 API 連携、モデル切り替えを同じワークスペースで扱えるため、権限設計の失敗がそのまま品質・セキュリティ・コストの失敗につながります。たとえば Admin を安易に増やすと、モデルプロバイダー設定や接続情報の変更が複数人に開放され、原因不明の挙動変化や利用料金の急増が起こっても追跡しづらくなります。
逆に権限を絞りすぎても問題です。Editor が必要な開発担当者に Normal を付けると、毎回 Admin 依頼が必要になり、PoC の速度が落ちます。大事なのは「役職」で決めるのではなく「実際の作業ジョブ」で決めることです。請求・基盤・招待運用を持つ人、アプリを作る人、公開済みアプリを使うだけの人、外部委託先のように期間限定で触る人で、必要な権限は変わります。
- Owner: 請求、方針決定、所有権移譲を持つ最終責任者に限定する。
- Admin: メンバー管理やモデル設定を運用する管理担当に絞る。
- Editor: アプリ・ナレッジを更新する開発/改善担当に付与する。
- Normal: 社内利用者、実証参加者、閲覧中心のメンバーに割り当てる。
Difyでロールを設定する具体的な手順
Settings > Members で招待する流れ
現在の Dify Cloud では、Workspace members は Settings > Members から追加・管理します。Owner または Admin が Add を押し、メールアドレスを入力し、ロールを選び、招待を送信する流れです。招待リンクは72時間で期限切れになるため、週次のまとめ招待をして放置する運用よりも、参加日が近いタイミングで送る方が安全です。期限切れになった場合は、同じ相手に再招待して新しいリンクを発行する必要があります。
プランごとのチーム人数上限も、追加時に必ず確認したいポイントです。公式 docs では Sandbox 1名、Professional 3名、Team 50名と明記されています。PoC のつもりで Sandbox を使っていたチームが、実装担当や業務担当を追加しようとして初めて上限に気づくケースは珍しくありません。ワークスペースを分けるのか、プランを上げるのか、先に決めてから招待設計をすると無駄な作業を減らせます。
役割の割り当ては、肩書きでなく作業単位で決めるのが基本です。たとえば、AI アプリを日々改善する担当は Editor、メンバー招待やモデル接続まで扱う運用担当は Admin、請求やオーナー移譲を持つ責任者だけが Owner です。社内実証の参加者や営業メンバーなど、公開済みアプリの利用が主目的であれば Normal に留める方が安全です。
ロール付与の判断に迷う場合は、一度ワークスペースの運用表を作ってから設定してください。設計と導入をまとめて見直したい場合は HelloCraftAIへ相談 いただければ、Dify の権限設計と活用フローを一緒に整理できます。
変更・削除・所有権移譲の注意点
ロール変更や削除は、Owner と Admin が実行できますが、Owner 自身の変更だけは ownership transfer です。つまり、Owner を外したいからといって通常のロール変更で済むわけではありません。責任者交代がある場合は、引き継ぎ日、請求管理、認証コードの受け取りまで含めて段取りを組む必要があります。
削除されたメンバーは、そのワークスペースへのアクセスを即時に失います。一方で、その人が作成したアプリや knowledge bases が自動で消えるわけではありません。退職・異動・外注終了時には「アカウントを消したので安心」と考えず、誰の名義で何が残っているか、公開設定や API 連携がどうなっているかも合わせて確認した方が安全です。
また、knowledge base やアプリの権限はロール外の個別設定も効くため、メンバーを Normal に下げても、過去に共有済みのリソース範囲がどうなっているかは別途確認が必要です。ロール変更はあくまで入口の制御であり、コンテンツ可視範囲の最終確認までは含まれません。
ありがちな失敗とDifyロール設計の注意点
権限を広げすぎる失敗
最も多い失敗は、PoC 初期の勢いで全員を Admin か Editor にしてしまうことです。短期的には速く見えますが、モデル設定変更、メンバー追加、公開方法の差し替え、ナレッジ編集が誰でもできるため、トラブル時に「誰がどの変更を入れたか」が曖昧になります。AI ワークフローはコードよりも設定変更の影響が見えにくく、後から原因追跡しにくいので、権限の広げすぎは想像以上に危険です。
特に、外部 API キーやモデルプロバイダー設定に関わる作業は Admin 以上に寄せる方が無難です。Editor はアプリと knowledge bases を作れるため、それだけでもかなり強い権限です。通常利用者まで Editor にすると、誤って本番向け知識を消したり、公開中アプリの設定を変えたりするリスクが高まります。
責任の所在が曖昧になる失敗
2つ目の失敗は「誰が招待担当か」「誰がモデル設定を変えてよいか」「誰が公開承認を出すか」が曖昧なまま運用を始めることです。Dify は画面上の操作が簡単なので、ルールがないままでも回ってしまいます。しかし、簡単に変えられるからこそ、変更履歴の説明責任を先に決めておかないと、障害時に現場が止まります。
おすすめは、少なくとも 1) Owner、2) Admin 運用担当、3) Editor の責任者、4) 利用者窓口を分けることです。部門横断チームなら、事業側が Owner、情シスやプロダクト運用が Admin、現場改善担当が Editor、利用社員が Normal という切り分けが実務に合いやすいです。
古い解説をそのまま使う失敗
古い記事や動画では、メンバー上限、ロール名、リソース権限の扱いが現行仕様とズレていることがあります。たとえば 2026年7月2日版 docs では Team size limits が Sandbox 1、Professional 3、Team 50 と明記され、招待リンクの期限も 72時間です。これを知らずに社内マニュアルを作ると、「招待メールが無効」「人数追加できない」といった問い合わせが増えます。
- 失敗を減らすには、月1回だけでも権限表と公式 docs を突き合わせる。
- 招待・削除・所有権移譲の実行者を明文化する。
- 外部利用や機密情報を含む knowledge base は個別共有設定まで確認する。
チームで失敗しない！Difyロール管理のベストプラクティス
部門別に最小権限で配る
ベストプラクティスの出発点は、役割ではなくジョブで権限を配ることです。たとえば、経営企画や事業責任者は Owner を持つ必要があっても、日々のモデル設定や招待業務まで自分で行う必要はありません。運用担当には Admin、改善担当には Editor、利用部門には Normal を割り当て、職務変更が起きたら権限も同時に見直すようにします。
社内ガイドラインとしては、「Owner は1名固定」「Admin は2〜3名まで」「Editor は実装担当だけ」「Normal は利用者全般」という上限を置くと、権限の増殖を防ぎやすくなります。小規模チームでも、最初からこの原則を入れておくと後の拡大が楽です。
承認フローと棚卸しを定例化する
ロール管理は一度設定したら終わりではありません。新しい AI アプリの公開、外部委託先の参加、ナレッジベースの追加、モデル差し替えなどが起きるたびに、適切な権限は変わります。月次または四半期で「誰がどのロールか」「不要な Admin がいないか」「退職者や異動者が残っていないか」を棚卸しすると、事故をかなり減らせます。
特にチーム利用で問い合わせが増えやすいのは、招待期限切れ、人数上限、Ownership transfer、knowledge base の共有範囲です。この4点は FAQ にしておくと運用が楽になります。公開中のアプリが増えたら、アプリ単位の責任者と変更承認者も決めておくと、編集権限の乱立を防げます。
Dify 導入支援とセットで設計する
Dify は作って終わりではなく、部門利用が広がった瞬間に権限設計・監査・教育が必要になります。特に「営業も触る」「情シスも関わる」「ナレッジベースに社内情報を入れる」といった段階では、ロール管理の良し悪しがそのまま運用定着率に出ます。最初に簡単な設計表を作り、運用ルール・命名規則・公開判断を揃えておくと、現場の摩擦を減らせます。
Dify の権限設計、運用ルール、社内展開まで含めて見直したい場合は お問い合わせフォーム からご相談ください。HelloCraftAI では、PoC から本番運用までを見据えた Dify 活用設計を支援しています。
ロールごとの実務割り当て例
実際の割り当て例としては、経営者や事業責任者が Owner、情報システムや AI 運用責任者が Admin、アプリ改善担当やプロンプト設計担当が Editor、営業・CS・バックオフィスなど公開済みアプリの利用者が Normal、という切り分けが最も安定しやすいです。ここで大切なのは、Owner を名誉職のように複数人へ配るのではなく、請求と所有権移譲に責任を持つ人へ絞ることです。Admin も同様で、メンバー管理やモデル設定を実際に回す担当だけに留める方が、監査時に説明しやすくなります。
また、外部パートナーや業務委託先が入るケースでは、いきなり Editor を渡す前に、検証用ワークスペースを別で用意するか、対象アプリと knowledge base を明確に限定したうえで期間付きの運用にする方が安全です。社内の本番ワークスペースへ強い権限を付けたまま放置すると、契約終了後のアクセス整理や資産棚卸しが難しくなります。
導入フェーズ別の考え方
PoC フェーズでは速度を優先したくなりますが、それでも Owner と Admin を同一人物1〜2名に集約し、実装担当だけを Editor にする原則は守った方が後で効きます。本番運用フェーズに入ると、アプリ公開手順、モデル差し替え手順、外部共有の承認手順、退職者の削除手順まで明文化しないと、利用者が増えた瞬間に問い合わせが爆発します。つまり、ロール管理は単独機能ではなく、ワークフロー設計そのものです。
ナレッジベースの更新頻度が高いチームでは、Editor を持つ人の中でも「作成担当」と「公開確認担当」を分けると事故が減ります。Dify 上では作成と共有が近い操作感で行えるため、レビューなしで本番反映される状態にしていると、内容の誤りや未整理メモが利用者へそのまま出ることがあります。
よくある質問
- Q. Owner を2人以上にできますか？ A. 現行 docs では Owner は 1 workspace に 1 人です。責任分界のためにも固定運用が安全です。
- Q. Admin ならすべての knowledge base を見られますか？ A. ワークスペース権限とは別に、既存 knowledge base の可視範囲は個別設定も関わるため、共有状態の確認が必要です。
- Q. 招待メールが届かない場合は？ A. 期限切れ、メールフィルタ、プラン上限、入力ミスを順番に確認し、必要なら再招待します。
- Q. 退職者を削除しただけで十分ですか？ A. 不十分です。所有中アプリ、共有設定、外部連携、運用ドキュメントも引き継ぐ必要があります。
こうした FAQ を社内向けに 1 ページ用意しておくだけでも、情シスや AI 推進担当への問い合わせをかなり減らせます。Dify のロール機能自体はシンプルですが、運用ルールがないと人が増えるほど事故率が上がるため、早い段階で標準化しておく価値があります。
最後に、権限設計はセキュリティだけでなく、現場の使いやすさにも直結します。Normal を基本にしつつ、必要な業務だけ Editor や Admin へ上げる設計にすると、現場は迷わず使え、管理側も説明責任を果たしやすくなります。ロールの付け外しをその場対応で済ませるのではなく、申請・承認・棚卸しの仕組みとして扱うことが、チーム利用では特に重要です。
まとめ
2026年8月14日時点の Dify 公式情報では、ロールは Owner / Admin / Editor / Normal の4種類で、Settings > Members から管理します。Owner は1名、Admin はメンバーと model providers を管理でき、Editor は apps と knowledge bases を作成・編集・削除、Normal は公開済みアプリ利用が中心です。招待リンクは72時間で失効し、Sandbox 1名、Professional 3名、Team 50名という人数上限もあります。
実務では、ロール名を覚えることよりも、誰が何を変更できるかをジョブ単位で明確化することが重要です。さらに、knowledge base の利用可否は個別設定にも依存するため、ワークスペース権限とリソース権限を分けて考える必要があります。手順だけでなく、承認フロー、棚卸し、部署別の割り当てまで含めて設計すると、Dify のチーム運用はかなり安定します。
