【Dify】Lesson1-5：作ったアプリを公開しよう｜方法と注意点まとめ
Difyは、作ったアプリを公開するまでの導線がとても整っています。
リンクを共有するだけでも配布できますし、自分のWebサイトに埋め込んで「サイトの機能」として見せることも可能です。
この記事では、まずは最短で公開できる方法を押さえ、次にWeb埋め込みの基本について解説します。
公開するときに最低限気をつけたいポイント も一緒に確認しますので、ぜひ最後までお読みください。
Lesson１：Dify入門｜環境構築と最初の生成AIアプリ開発
・Lesson1-1：生成AIアプリ開発の入り口｜Difyとは何かを知ろう
・Lesson1-2：Difyを使う準備｜環境構築とセットアップ
・Lesson1-3：Difyの入り口｜初めてのチャットボットを作ろう
・Lesson1-4：RAG入門｜ナレッジベースを作ろう
・Lesson1-5：作ったアプリを公開しよう｜方法と注意点まとめ ◁今回はここ
Lesson２：まずは体験｜基本的なアプリを作ろう
Lesson３：テキスト処理を行いアプリ開発
Lesson４：ファイル処理を行いアプリ開発
Lesson５：RAGアプリの開発
Lesson６：機能拡張と外部連携
Lesson７：AIエージェントを活用したアプリ開発
Lesson８：実務投入への総仕上げ
<<前のページ
Difyの記事一覧
次のページ>>
Difyの公開方法の全体像｜URL共有とWeb埋め込み
Difyで作ったアプリを「公開する」と言っても、やり方は1つではありません。目的に合わせて、主に2つの出し方を選べます。
どちらもDify側で用意されている機能を使うので、難しいサーバー構築などは不要です。
公開方法の選択肢は、次の2つが中心です。
- URL共有：リンクを渡すだけで、相手がすぐ使える
- Web埋め込み：自分のサイトの一部として、チャット画面を表示できる
どちらを選んでも、「作ったDifyアプリを他の人が操作できる状態にする」という意味では同じです。
違いは、どこで使ってもらうか（体験の場所）にあります。
URL共有で公開する手順（いちばん簡単）
最短で「他の人に使ってもらえる状態」を作るURL共有の手順を紹介します。
やること自体はシンプルで、基本は「公開（Publish）して、URLをコピーして渡す」だけです。
とはいえ、公開の意味やチェックポイントを知らないまま進めると「設定を変えたのに反映されない」「想定外の返答をする」などでつまずきやすいので、ポイントを押さえながら進めていきましょう。
まず全体の流れは次の通りです。
- Difyで対象アプリを作る
- 公開する
- WebアプリのURLをコピーする
- 共有相手にURLを渡す（必要なら利用方法も一言添える）
公開して共有用URLを取得する
実際の操作は難しくありません。アプリの編集画面から公開（Publish）へ進み、表示されるWebアプリのURLをコピーします。
（アプリの実行画面の上にある「https://～」の部分です。）
複数アプリを作っている場合は、URLをコピーする前に「今開いているのが目的のアプリか」を一度だけ確認しておくのがおすすめです。
意外とここで別アプリを共有してしまう事故が起きます。
非常に簡単だけど、このやり方は全然関係ない人でもURLさえ知っていれば利用できてしまう。
APIの利用は有料なので、それは避けたいね。
記事後半の注意事項をしっかりと確認しておこう。
ただしクラウド版Difyではあまり有効な対策が無いことも知っておいてね。
よくあるつまずき（反映されない・動かないとき）
URL共有でありがちな “あるある” をまとめておきます。
もし同じ状況になっても慌てずに対処できます。
- 変更が反映されない：Publishし忘れの可能性が高いです。公開を更新してから再確認しましょう。
- 自分は動くのに、相手が使えない：公開範囲やアクセス制限の設定が影響している場合があります（次章以降で扱う「公開範囲と注意点」につながります）。
- 期待と違う回答をする：RAGの知識が不足している、質問の言い回しで参照が変わっているなどが原因になりがちです。共有後の質問ログが改善のヒントになります。
次の章では、URL共有より一歩進めて、あなたのWebサイトに「アプリを埋め込む」方法を見ていきます。
サイトの中で使ってもらえる形にすると、デモとしての説得力がぐっと上がりますよ。
Web埋め込みの基本
URL共有は「リンクを渡せば終わり」でとても手軽でした。
一方で、もう一歩進めて “自分のWebサイト上で使ってもらう” 形にしたいなら、Web埋め込みが活躍します。
たとえば、サービス紹介ページに設置して問い合わせ対応に使ったり、ポートフォリオとして「その場で触れるデモ」を用意したりできます。
埋め込みと聞くと難しそうに感じるかもしれませんが、Difyではコードをコピーして貼り付けるだけで動かせる方法が用意されています。
「サイトに埋め込む」を選択すると、埋め込む方法が選択できます。
適切な方法を選択し、表示されるHTMLコードをサイトに貼り付ければ、完了です。
サイト埋め込みの詳細については、のちの章でもう少し細かく学習します。
公開時の注意事項1：アクセス制限の基本
Difyでアプリを「公開」すると、基本的にはURLを知っている人が使えてしまいます。
社内向けのツールや検証用アプリでも、うっかりURLが広まると想定外の人が触れてしまうので、最初に「誰が使えるか」を決めておくのが大切です。
ここでは、初心者でもすぐできる現実的な方法だけに絞って紹介します。
方法1：Dify Enterpriseのアクセス権で「ログイン必須」にする
Dify EnterpriseはDifyの企業向けプランです。
これを使っているなら、Dify側の機能だけで「ログインした人だけが使える」状態にできます。
Webアプリにアクセスするとログイン画面が出る仕組みなので、URLが漏れても無関係な人は入りにくくなります。
やることはシンプルで、流れは次の通りです。
- Studioで対象アプリを開く
- 公開画面、または「Web App Access（アクセス権）」の設定を開く
- 「認証が必要（ログイン必須）」に相当する権限を選び、利用者の範囲（社内ユーザー／外部ユーザーなど）を指定する
- 保存して、発行されたURLを共有する
ポイントは、「誰でもアクセス可能」のままURLだけ配るのではなく、必ずアクセス権の設定を先に済ませることです。
方法2：Dify Community（オンプレミス版）の場合は「手前に鍵」を付ける
Dify Communityでは、Webアプリが「URLを知っていれば使える」形になりやすいので、Difyの前にログインやパスワードの壁を置くのが安全です。
難しそうに見えますが、初心者でも「既製品の機能」を使えばそこまで大変ではありません。
おすすめは、次のどれかです。
- Cloudflare Accessなどの“ゼロトラスト”機能で、メールアドレスやGoogleログインを要求する
- AWSのALB（Application Load Balancer）の認証機能で、ログインしないと開けないようにする
- いちばん簡単に済ませたいなら、ベーシック認証（ID/パスワード）を付ける
「サーバーやAWSはまだ不安…」という場合は、まずはベーシック認証が最短ルートです。
パスワードさえ知らなければ、URLが漏れても突破されにくくなります。
方法3：埋め込みは「会員だけ見られるページ」に設置し、公開URLは配らない
Web埋め込みは、設置する場所の工夫だけでも安全性が上がります。
Difyの公開URLを直接配るのではなく、ログインが必要なページ（会員サイト、社内ポータル、パスワード付きページなど）にだけ埋め込むのがおすすめです。
例えばこんな運用にすると安心です。
- Difyの公開URLは自分（運営側）だけが管理し、外には出さない
- 実際の利用者には「ログインが必要な自社ページ」のURLだけ渡す
- 退職者や契約終了者が出たら、そのページの権限を外すだけで利用を止められる
Dify側で細かいアクセス制御ができない環境でも、「使わせる入口」を自分の管理下に置けば、事故が起きにくくなります。
このサイトで作る学習用アプリも、できれば誰にも公開しないことをおすすめします。
公開時の注意事項2：コストと負荷の暴走を防ぐ（想定以上に使わせない）
公開した生成AIアプリで意外と多いのが、「気づいたら大量に使われていて、API料金が跳ねた」「連打されて重くなった」という事故です。
特にWeb公開や埋め込みは、使う人が増えるほど “想定外” が起きやすいので、最初から「使われすぎない仕組み」を入れておくのが安全です。
方法1：Difyのレート制限・利用制御を使って “連打” を止める
DifyのWebアプリは、アプリ設定の内容がそのまま公開版に反映されますので、アプリ側でレート制限や利用制御を入れておけば、公開後も一貫して効きます。
ただしこちらもクラウド版では設定できません。
オンプレミス版を使用している場合は、まずは次のような “弱めでも効く” 制限から入れてください。
- 1分あたりのリクエスト数を抑える（例：同じ利用者が短時間に何十回も送れないようにする）
- 同時リクエストを抑える（混雑時に暴走しにくくなる）
「とりあえず公開して様子見」ではなく、公開前に最低限の制限を入れるのが一番ラクで確実です。
方法2：最大トークンを小さくして、1回あたりの料金に上限を付ける
“使われすぎ”は回数だけでなく、1回の返答が長すぎて料金が増えるケースもあります。
そこで初心者でも効果が大きいのが、モデル設定の「最大トークン（Max tokens）」を控えめにすることです。
これは「1回答で出せる文字量の上限」を決めるイメージで、上限を決めるだけでもコストが読みやすくなります（DifyのFAQでも、最大トークンの調整に触れられています）。
おすすめの考え方は次の通りです。
- まずは短めに設定して公開（例：長文レポートを作らないアプリなら小さめでOK）
- 物足りないと言われたら少しずつ増やす（いきなり大きくしない）
「長文が出ない＝不親切」ではなく、初心者向けアプリほど “短く要点だけ” の方が使いやすいことも多いです。
マックストークンはアプリの開発画面上のGPTをクリックすることで設定できます。
公開時の注意事項3：RAGに機密事項を書かない（入れない設計がいちばん安全）
RAG（ナレッジベース）は便利ですが、入れた情報は「アプリが参照できる情報」になります。
つまり、公開したアプリが想定外に使われた場合、機密が “答えとして出る” リスクがゼロではありません。
なので結論としてはシンプルで、機密は最初から入れないのが一番安全です。
そもそも入れてはいけない情報を決める（機密の線引きを作る）
まず最初に「この種類の情報はRAGに入れない」という線引きを作っておくと、判断が迷わなくなります。
1人で作るのが不安なら、上司や関係者に「これだけは入れません」で共有するだけでも効果があります。
例えば、次のような情報は原則として入れない方が安全です。
- 個人情報（氏名、住所、電話番号、メール、社員番号など）
- 認証情報（パスワード、APIキー、トークン、秘密鍵）
- 取引先との契約書や見積、請求、単価などの金額情報
- 未公開の社内情報（新機能、売上、顧客リスト、社内評価など）
- 社外に出したくない社内手順（セキュリティ手順、障害対応の詳細など）
この線引きがあるだけで、「便利だからとりあえず全部入れる」を防げます。
どうしても必要なときは、匿名化と伏字にしてから入れる
「業務マニュアルを入れたいけど、ところどころに顧客名や担当者名がある」みたいなケースはよくあります。
その場合は、アップロード前に“置き換え”をしてから入れるのが現実的です。
やり方は難しくありません。次のように置き換えるだけでもリスクが大きく下がります。
- 実名 → 会社A、顧客B、担当者C
- メールアドレス → user@example.com のようなダミー
- 電話番号 → 000-0000-0000 のようなダミー
- APIキーやトークン →
[API_KEY]のように伏字 - 契約金額 → 「金額は社内規定に従う」のように一般化
ポイントは「文章として意味が通る範囲で、特定できる要素だけ落とす」ことです。
RAGは“知識の形”が残れば十分役に立つので、固有名詞を消しても効果が出やすいです。
公開用と社内用でナレッジベースを分ける（混ぜないのがコツ）
公開する可能性があるアプリと、社内だけで使うアプリが同じナレッジベースを参照していると、あとから管理が大変になります。
初心者ほど「最初から分ける」が安全です。
具体的には、次のように分けるのがおすすめです。
- 公開用ナレッジ：一般公開しても問題ない内容だけ（FAQ、公開マニュアル、一般的な説明）
- 社内用ナレッジ：業務手順など（ただし機密はできるだけ入れない）
- 検証用ナレッジ：ダミーデータだけ（学習・テスト用）
「公開用には公開OKな情報しか入らない」という状態を作っておけば、公開時の不安がかなり減ります。
まとめ
この記事では、Difyで作った生成AIアプリを「他の人に使ってもらえる形」にするために、公開の基本を押さえました。
これであなたのアプリは “作っただけ” から “使われる” 段階に進みました。
次のLesson2では、用途別に基本アプリを作りながら、実務や副業につながる型を増やしていきましょう。
<<前のページ
Difyの記事一覧
次のページ>>