社内のマニュアルをAIに読ませてチャットで答えさせる、という仕組みは動かせるようになった。問題はその次で、「どこに置くか」でした。
そのまま外に公開すると、誰でも読める。社員向けの情報がネットに流れる。かといって「非公開」にするとURLさえ知っていれば誰でもアクセスできる、というのがDifyのデフォルト設定の実態です。「公開か非公開か」の2択しかない。契約者だけとか、この部署の人だけとか、そういう細かい絞り込みがそもそも設定できません。
なので、認証を外付けするしかなかった。
公開/非公開の2択
Difyでチャットボットを作ると、公開設定は2択しか出てきません。インターネットに公開する、または非公開にする。非公開はURLを知っている人だけアクセスできる状態なので、URLが漏れれば終わりです。
社員向け・契約者向けに使わせたいなら、アカウント認証を挟む必要があります。特定のアカウントでログインした人だけが画面に到達できる状態にする、ということです。
Difyの設定画面ではこれができません。なので、Difyの手前に認証レイヤーを別途用意することになります。
チャットボットの手前に認証を置く構成
AIにこう頼んで構成を整理しました。
DifyのチャットボットUI全体に会社のアカウント認証をかけたい。特定のアカウントでログインした人だけがDifyにアクセスできるようにする。Dify本体の設定ではできないので、手前に認証の仕組みを挟む形で作ってほしい。Dockerで動いている環境なので、Docker Compose上で構成したい。
やることは、Difyを動かすコンテナ群の設定ファイルに、認証を担当するコンテナを一つ追加することです。ユーザーのブラウザからのアクセスはまずその認証コンテナに届き、ログインが確認できた人だけがDifyの画面に通る、という順番になります。
認証には会社のアカウント管理（Microsoft 365を使っている会社ならそのアカウント）を使いました。これで「会社のアカウントを持っている人だけ」「あるいは特定のグループに入っている人だけ」という絞り方が設定できます。
ブラウザ
↓ まずここに届く
認証コンテナ（会社アカウントでログインを確認）
↓ ログイン済みの場合だけ通す
Difyの画面
実際につまずいた2か所
設定を書き換えてDockerを再起動しようとしたところ、起動しませんでした。エラーメッセージを見ながらAIと一緒に切り分けて、設定ファイルの記述が一か所ずれていたのが原因でした。
直して再起動すると今度は起動した。でも認証後の画面がおかしくなりました。ログインは通るのに、その後のDifyの画面が正常に表示されない。ログを見るとヘッダーのサイズが原因で、Nginxのバッファ設定を足すことで解決しました。
最終的には動いた、という会話の記録です。「認証はきた、が、認証後の画面がこうなった」というメモが残っているので、同じ構成をやろうとする人は認証後の画面崩れも想定しておいてください。
既存のDify環境に足すのは選ばなかった
「今動いているDifyに認証を後付けしてほしい」という相談が来たとき、その前提はリスクが高いと判断して、新規構築のみを受ける条件にしました。
理由はシンプルで、稼働中のDocker Compose設定に手を入れるのは事故が起きやすいからです。バージョンの差異、設定の競合、知らないうちに何かに依存していた設定。既存環境を触るたびに何かが崩れる可能性があります。
新規でDify環境を作って、最初から認証込みで構築する。これなら一から設定を制御できるし、問題が起きても「どこかを変えたから起きた」という追いかけ方ができます。
アクセスを絞るべき場面
「社内マニュアルをAIに答えさせたい」「有料契約者だけに使わせたい」というケースは、まずここに引っかかります。DifyのデフォルトはURLが知られたら誰でもアクセスできる。「まあURLは知らないだろう」で公開するのは、規程上も運用上もグレーです。
特定の部署だけ、特定のグループだけ、という絞り方がしたい場面には、認証を外付けする設計を最初から組んでおくほうがいい。
設置してから「やっぱり認証かけたい」になると、稼働中の環境に手を入れることになります。それが大変なのは前述のとおりで、最初の設計段階で決めておく。そういうことです。