前回の「Difyで「思考ログ×セルフ検索アプリ」を作る」の続きです。
何をしようとしているかの経緯は以下の記事を参照してください。
前回は権限の都合上、プラグインを用いてOneDriveやSharePointをナレッジの保管庫として使えず、断念したところで終わりました。
ローカルフォルダを保管庫に持てないか？
次に考えたのが、
ローカルフォルダをナレッジの保管庫とする
という構成です。
ただしDifyはクラウド版。
ローカルフォルダを直接参照することはできません。
そこで考えたのが、次の構成です。
HTTPでローカルAPIを叩ければいけそうです。
ngrokでローカルAPIを公開しようと試みる
ローカルAPIを外部公開するためにngrokを使いました。
ngrokでやったこと
ローカルでは以下のような簡単なFlask APIを用意しました。
from flask import Flask, request
app = Flask(__name__)
@app.route("/save", methods=["POST"])
def save():
data = request.json
# ローカルに保存
return "OK"
app.run(port=5000)
ngrokでHTTPトンネルを作成。
ngrok http 5000
発行されたURL 例：
https://xxxx.ngrok-free.app
DifyのHTTP Request ノードから、このURLを叩く構成です。
発生した問題
ところが、Dify側からリクエストを送ると：
- 接続できない
- もしくは即座にタイムアウト
- 社内プロキシログ上はAnonymizer/トンネル系通信として検知
という状況になりました。
社内環境では、ngrok系の通信は
明示的にブロック対象になっているようでした。
技術的には実装可能であったが
重要なのは、
- 設計としては間違っていない
- PoCではよく使われる構成
- しかし社内セキュリティポリシーとは相容れない
という点です。
技術的に「できる」ことと、
組織内で「許可されている」ことは別。
この時点で、
ngrokを前提とする構成は諦める判断をしました。
cloudflared（Cloudflare Tunnel）を試してみる
「ngrok がダメなら Cloudflare なら通るのでは？」
次に試したのが cloudflared（Cloudflare Tunnel） です。
- Cloudflare製
- 大手CDN
- ngrokより信頼されていそう
という理由で、成功を期待しました。
試したコマンド
Quick Tunnel を使用し、Flask API を公開。
cloudflared tunnel --url http://127.0.0.1:5000
正常に URL は発行されます。
https://xxxx.trycloudflare.com
しかし、外部からアクセスすると1033エラー。
エラー内容（実ログ）
cloudflared のログには、次のようなメッセージが出続けました。
Failed to dial a quic connection
timeout: handshake did not complete in time
QUIC（UDP）通信が怪しかったため、HTTP/2 に切り替えます。
cloudflared tunnel --url http://127.0.0.1:5000 --protocol http2
しかし次は、より決定的なエラーが出ました。
TLS handshake with edge error:
x509: certificate signed by unknown authority
技術的原因の切り分け
ここからは、かなり丁寧に原因を切り分けました。
✅ Cloudflare API への HTTPS 接続
Invoke-WebRequest https://api.cloudflare.com/client/v4/ips
→ 200 OK
✅ Cloudflare Tunnel ポート疎通確認
Test-NetConnection region1.v2.argotunnel.com -Port 7844
→ True
❌ Tunnel 接続のみ TLS エラー
certificate signed by unknown authority
結論：社内のSSL検査が介在している
この状況から分かったことは：
- 社内ネットワークでSSL/TLS検査（MITM）が行われている
- Cloudflare Tunnelのエッジ通信のみが検査対象になっている
- cloudflared（Go/TLS）は社内CAを信頼できず、接続失敗
つまり、
Cloudflare Tunnel自体はブロックされていないが、
TLS検証を突破できない
という、かなり典型的な社内制約パターンでした。
「正攻法」は管理者権限が必要
理論上の解決策はあります。
- 社内CAを信頼ストアに追加
- Cloudflare Tunnel用通信の例外設定
しかし、どちらも管理者権限・IT部門調整が必須。
今回のPoCでは現実的ではありませんでした。
Difyのナレッジに自動で蓄えられないか？
最後の望みとして、
- Difyワークフローから
- 自動でナレッジ（Dataset）に追加
を考えましたが、
- ナレッジ（Dataset）に追加するアクションが見当たらず
ここでも行き止まりです。
このフェーズで得た学び
- HTTPトンネル系はほぼ確実に社内で詰む
- 「大手製品だから許可される」は幻想
- TLS検証レベルで止められると利用者側では解決できない
この時点で、
ローカルを直接公開する発想を完全に捨てる判断をしました。
次回
次回はいよいよ、
すべての制約を受け入れた上で完成させた「現実解」 についてです。