Difyのアプリを非公開にする方法｜Webアプリの公開停止・アクセス制限・権限設定

DifyのWebアプリは、初期状態では「URLを知っていれば誰でも使える」公開状態です。非公開にしたいときは、アプリの「アクセスポイント」タブにあるWeb Appのスイッチを切って公開を止めます。特定のメンバーだけに使わせる権限設定は、Dify Enterpriseの機能です。

「DifyのアプリはPrivateが初期設定」という説明を見かけることがありますが、2026年10月15日時点の公式ドキュメントとは違います。この記事では、クラウド版・セルフホスト版（Community版）・Enterprise版のそれぞれで、Difyのアプリへのアクセスを絞る方法を、公式ドキュメントとGitHubで公開されているソースコード（v1.17.1）で確かめた内容に沿って説明します。

前提：DifyのWebアプリは初期状態で公開されている

Difyで作ったアプリは、公開（Publish）すると自動でWebアプリになります。公式ドキュメントのWebアプリ設定のページには、次のように書かれています（Web App Settings、2026年10月15日確認）。

Webアプリは既定で公開（public）であり、URLを知っている人なら誰でも開ける
共有する前に、URLを渡してよい相手かどうかを確認すること

つまり、ワークスペースのメンバーを招待しても、それだけでWebアプリが「メンバー限定」になるわけではありません。メンバー管理は「アプリを作る・編集する側」の権限で、Webアプリを「使う側」の制限とは別の仕組みです。

エディションごとにできること

やりたいこと	クラウド版（dify.ai）	セルフホスト（Community版）	Enterprise版
Webアプリの公開を止める	できる（スイッチ）	できる（スイッチ）	できる
公開URLを作り直す	できる（再生成）	できる（再生成）	できる
特定のメンバーやグループだけに使わせる	標準の画面にはない	標準の画面にはない	できる（アクセス権限）
サーバーの手前に認証をかける	できない	できる（リバースプロキシなど）	SSOなどで対応
自社システムからAPIで呼ぶ	できる（APIキー）	できる（APIキー）	できる（APIキー）

アクセス権限の画面は、ソースコード上ではシステムのwebapp_auth機能が有効なときだけ表示される作りになっており、その機能はEnterprise版のドキュメントで説明されています。

Webアプリの公開を止める（非公開にする）

いちばん確実な非公開の方法は、Webアプリそのものを止めることです。Dify v1.17.1の画面では、アプリを開いて「アクセスポイント（Access Point）」タブを選ぶと、Web App、API、MCPサーバー、トリガーなど、アプリへの入り口がカードで並んでいます（Publish Overview）。

アプリを開き、「アクセスポイント」タブを選ぶ
「Web App」カードのスイッチをオフにする（状態が「無効」になる）
Web AppのURLを開き、使えなくなっていることを確かめる

このスイッチはアプリのenable_siteという設定を切り替えるもので、GitHubのソースコード（web-app-card.tsx）で確認できます。Webアプリを止めても、アプリの編集画面での動作確認（プレビュー）や、APIキーを使った呼び出しは別の設定です。APIも止めたい場合は、同じタブのAPIのカードも確認してください。

URLが漏れたときは「再生成」

Web Appカードには「再生成」の操作もあります。日本語の画面では「公開 URL を再生成しますか？現在の URL は直ちに使用できなくなります。」と確認が出ます（日本語の表示文言）。共有してはいけない相手にURLが渡ってしまったときは、再生成で古いURLを無効にし、新しいURLを必要な人にだけ渡し直します。

ただし、新しいURLもまた「知っていれば誰でも使える」点は変わりません。継続的に人を限定したい場合は、次の方法と組み合わせます。

メンバーと権限（ロール）の設定

アプリを作る・編集する人を絞るのは、ワークスペースのメンバー管理です。「設定」→「メンバー」で招待し、ロールを選びます（Manage Members、2026年10月15日確認）。

ロール	できること
Owner（オーナー）	ワークスペースのすべて。1つのワークスペースに1人
Admin（管理者）	メンバーとモデルプロバイダーの管理、Editorができることすべて
Editor（編集者）	アプリとナレッジベースの作成・編集・削除
Normal（一般）	公開されたアプリを使うだけ

公式ドキュメントに書かれている運用上のポイントは次のとおりです。

招待リンクの有効期限は72時間。期限が切れたら招待し直す
ロールの変更は、そのメンバーの次の操作から反映される（ログイン中でも）
メンバーを削除すると、ワークスペースへのアクセスはすぐに取り消される。作ったアプリやナレッジベースはワークスペースに残る
クラウド版のメンバー数の上限は、Sandboxが1人、Professionalが3人、Teamが50人

退職者や異動者が出たら、メンバーの削除と、必要に応じてWebアプリのURLの再生成をセットで行うと、知っているURLから使い続けられる状態を防げます。

特定のメンバーだけに使わせる：Enterprise版のアクセス権限

Dify Enterpriseには、Webアプリごとに「誰が使えるか」を決めるアクセス権限（Web App Access Control）があります（Access Control – Dify Enterprise Docs、2026年10月15日確認）。選べるのは次の4つです。

設定（日本語の画面表示）	使える人
プラットフォーム内の全メンバー	Enterpriseのプラットフォームにログインできる全員
特定のプラットフォーム内メンバー	選んだグループと個人だけ。新しいアプリの既定値
認証済みの外部ユーザー	SSOで認証した社外のユーザー
リンクを知っているすべてのユーザー	認証なしで誰でも

公式ドキュメントの注意点もあわせて押さえておきましょう。

「特定のメンバー」でグループもメンバーも選ばないと、作成者本人も含めて誰も使えない
Owner・Admin・Editorはアプリを編集できても、Webアプリを使うにはアクセス権限の一覧に入っている必要がある
権限の変更に再公開は不要で、すぐ反映される。ただし、ログイン中の利用者にはセッションが切れるまで反映されないことがある
Webアプリの権限はAPIには影響しない。APIはAPIキーで別に管理する

Enterprise版の契約については、Difyの料金ページから問い合わせる形になります。

セルフホスト版でアクセスを絞る

管理画面へのログインを招待制のままにする

セルフホスト版の管理画面（コンソール）は、初期設定でメールアドレスとパスワードでのログインです。環境変数のALLOW_REGISTERは既定でfalseで、この場合は自分でアカウントを作れず、ワークスペースへの招待でのみ参加できます（Environment Variables）。社内向けに立てるなら、この既定値を変えないのが基本です。

ただし、これはあくまで管理画面のログインの話で、公開したWebアプリの利用者を制限するものではありません。

サーバーの手前に認証をかける

Community版でWebアプリの利用者を絞りたい場合は、Difyの手前に置くリバースプロキシや、クラウドのロードバランサーの認証機能で、サーバーごと社内の人しか届かないようにする方法があります。例としては、nginxのBasic認証（ngx_http_auth_basic_module）、社内ネットワークやVPNからだけ接続できるようにする方法、ID認証付きのプロキシなどです。

設定するときの注意点が2つあります。

Difyの公式のDocker構成に含まれるnginxの設定テンプレートには、冒頭に「このファイルを直接編集せず、.envの変数で変更すること」と書かれています（default.conf.template）。直接書き換えると更新時に失われやすいため、Difyの外側に別のプロキシを置くほうが管理しやすくなります。
Webアプリの画面は/chat/などのパスですが、画面から呼ばれるデータのやり取りは/apiのパスを通ります。画面のURLだけに認証をかけても、API側が開いたままになるおそれがあります。かけるならホスト全体にかけるのが確実です。

自社のシステムからAPIで呼ぶ

社内ポータルなど、すでにログインの仕組みがあるシステムがあるなら、DifyのWebアプリは止めておき、そのシステムからDifyのAPIを呼ぶ構成もあります。公式ドキュメントでも、APIで組み込む場合は「画面、ユーザー認証、データの扱いを自分で管理できる」と説明されています（Publish Overview）。APIキーはサーバー側だけに置き、ブラウザに渡さないようにします。