制約の壁に阻まれた前回の続きです。
すべての制約を受け入れた「現実解」
前回までで、次のことがはっきりしました。
- 外部からローカルを叩く構成は無理
- HTTPトリガーもOAuthも管理者権限が必要
- Dify単体で自動蓄積はできない
つまり、
楽して理想は実現できない
という割り切りが必要でした。
最終構成（ナレッジ蓄積）
たどり着いた構成がこちらです。
この構成のポイント
✅ 外部HTTP待受なし
✅ OAuth設定なし
✅ 管理者権限不要
✅ 社内FW回避
「社内で許可されているもの」だけで完結しています。
Difyは「チャットUI」ではなく「API」として使う
ここでの発想転換が重要でした。
Dify＝アプリの裏側にいる要約・整理エンジン
です。
役割分担
- アプリ：入力UI／モード切替
- Dify：
- 雑メモの整理
- Markdown整形
- Knowledge検索（RAG）
思考ログ生成フロー（技術補足）
① アプリ → Dify（思考ログモード）
アプリからは、かなりラフな入力を送ります。
・今日はDifyとPower Automate連携を考えた
・HTTPトリガーが使えなくて困った
・結局PADに寄せたその他の行を表示する
② Dify ワークフローで整形
Dify側では、
- 要約
- 見出し付け
- タグ付与
- Markdown変換
までを ワークフロー内で完結させます。
出力例：
# Dify × Power Automate連携の検討ログ
## 要約
HTTPトリガーが利用できない制約の中で、
Power Automate Desktopを使う構成に切り替えた。
## 結論
ローカル共有フォルダを正とし、
PADで定期同期するのが現実解。
---
tags: dify, power-automate, knowledge
created_at: 20260312
なぜ「ファイル（Markdown）」に落としたのか
ここは意図的です。
- Difyのナレッジに蓄えるにはファイルアップロード前提
- MarkdownはAIに優しい
VDI共有フォルダを「保管庫」にした理由
選定理由はシンプルです。
✅ 社内で正式利用されている
✅ 権限・監査的に安全
✅ OneDriveのように制約がない
Power Automate Desktop の役割（技術補足）
PADは「橋渡し役」に徹しました。
PADでやっていること
- 共有フォルダを走査
- 未投入Markdownを検出
- ブラウザ操作でDify Datasetに投入
- 処理済み印を付ける
👉 HTTP や API は使っていません。
「人が操作できること」を自動化しているだけです。
なぜ PAD を自動実行する必要があったか
毎回手動実行すると確実に運用が破綻します。
そこで、
① PS1 を用意
Start-Process "C:\Program Files\Power Automate Desktop\PAD.Console.Host.exe" `
-ArgumentList "--run-flow thinklog_sync"
② タスクスケジューラで定期実行
- 朝一
- 昼
- 夜
👉 「多少遅れるが、確実に回る」を優先しました。
質問モード（セルフ検索）の実装
思考ログがナレッジに溜まれば、あとは楽です。
フロー
- アプリから質問送信
- Difyで Knowledge 検索
- 検索結果を基に回答生成
- アプリに返却
ポイント
- Knowledge優先
- 無ければ「見つからない」と返す設計
👉 推測で答えないことが重要でした。
この構成で得られたもの
- 過去の判断理由を引ける
- 「同じことで悩む」回数が減る
- 自分専用の思考DBが育つ
一見すると遠回りですが、
制約を把握した上で作った仕組みは壊れにくい
と感じています。
まとめ
以上でほぼ理想どおりの構成が実現できました。
- 管理者権限なし
- 厳しい社内セキュリティ
- クラウド×ローカル混在
という条件下でも、
目的（思考を残し、再利用する）は達成できました。
完成とは、制約の中で納得できる着地点を見つけること
この経験が、同じような環境で試行錯誤している方の
参考になれば嬉しいです。
おわりに
もし時間と権限があれば、
- OneDrive連携
- グループ利用
もやりたかったですが、
それは「次のフェーズ」に取っておきます。