結論：既存のClassic Knowledgeで業務が安定しているなら、Dify 1.18.0に上げてもKnowledgeFSへ急いで移行する必要はありません。 KnowledgeFSは任意のBeta機能で、独立したサービスとデータベースを伴います。Community Editionを自社運用する場合は、公式の対応状況、利用できるイメージ、明示的な有効化条件を確かめてから試してください。
今週の推奨アクション： 現行の知識検索が足りているかを確認し、足りない場合だけ検証環境で必要機能を試します。本番の知識ベースは、復旧と切り戻しが確認できるまで移行しません。
この記事は、Dify Community Editionを運用して1.18.0への更新を検討中の開発者向けです。企業の知識ベースを管理する担当者は、データと権限の境界を確認できます。サーバーを計画するチームは、Dify本体、KnowledgeFS、モデル推論の資源を分けて考えられます。
※ 最終更新：2026年10月26日。Difyの1.18.0リリース情報、Docker構成、KnowledgeFS環境設定例を確認しています。
KnowledgeFSは既存のClassic Knowledgeを置き換える前提ではありません
Dify公式の1.18.0リリース情報では、Agent Knowledge BaseがBetaとして案内されています。KnowledgeFSは既存の知識ベースと同じものを強制的に置き換える機能ではなく、Agent向けの知識空間や検索ノードなど、新しい使い方を検討するための選択肢です。リリースノートでBetaの位置づけと対象機能を確認してください。
既存のClassic Knowledgeを使うチームは、まず現行フローの不足を具体化します。回答品質や検索範囲に問題がなく、Agent向けの新しい知識空間も必要ないなら、移行作業を増やす利点は限られます。旧知識ベースの用途と新機能の目的を分けて評価するのが先です。
一方、Agentごとに知識空間を管理したい、検索処理を新しいワークフローに組み込みたいといった要件があれば、検証候補になります。ただし、検索履歴の追跡や権限の分離が実際の運用要件を満たすかは、構成や権限設定を含めて確認してください。機能名だけで、本番運用に必要な管理機能まで備わると判断するのは避けます。
Community Editionの自社運用は、Compose設定と配布条件を別々に確認します
公式のDocker Compose設定では、KnowledgeFSは既定で有効ではありません。Community Editionのローカル運用では開発用オプションを明示して有効化する条件が示されています。これは「設定を足せば本番サポートも確定する」という意味ではありません。Docker Composeと、KnowledgeFSの環境設定例を、使用するバージョンに合わせて照合します。
また、KnowledgeFSは独立サービスとデータベースを伴う構成です。Dify本体のコンテナだけで完結すると想定すると、起動依存関係、接続設定、永続データの保存先、バックアップ対象を見落とすおそれがあります。公式Docker導入案内を参照し、検証対象のリリースに対応した手順を使ってください。
2026年10月24日付のコミュニティIssueでは、Community Editionのイメージやサポート経路について利用者が質問しています。これはユーザーの疑問を示すもので、公式が未対応と結論した証拠ではありません。イメージの入手可否や対応範囲は、リリース情報と現行の公式案内で個別に確かめます。
注意：mainブランチの設定は更新されることがあります。検証時には、対象バージョンのファイルと配布イメージをそろえ、別の版の手順を混ぜないでください。
チームの状況別に、試用の優先度を見極めます
- 既存のRAGフローが安定している：適合度は低めです。 今すぐKnowledgeFSを有効化する理由がなければ、Classic Knowledgeを継続します。移行作業より、現行データの復旧手順を整えるほうが優先です。
- Agent向けの知識空間を評価したい：適合度は中程度です。 まず隔離環境で、必要な検索動作と権限分離を確認します。現行フローとの差が明確になってから、業務データでの試験を検討します。
- Community Editionを本番運用している：条件付きです。 有効化設定だけで判断せず、公式のサポート範囲、イメージの入手、データ復旧、切り戻しまで確認できる場合に限って評価します。
- EnterpriseまたはCloudを使っている：個別確認が必要です。 Community EditionのCompose設定をそのまま当てはめず、該当するEditionやホスティング形態での提供状況を公式案内で確認します。公式のリリース討議も参考にしつつ、Cloudの利用時期や差異は最新の告知を基準にします。
Dify本体、知識サービス、モデル推論は別の負荷として計画します
サーバー要件を考えるときは、Difyのアプリケーション、KnowledgeFSとそのデータベース、モデル推論を一つの負荷として数えないようにします。外部モデルAPIを使う構成なら、モデル推論を自社サーバーで行うための資源をDify本体の見積もりに加える必要はありません。ただし、文書保存、検索処理、データ転送の経路は別に確認します。
CPU上でモデルを動かす場合は、モデルのパラメーター数と量子化ビット数から重みの容量を概算し、コンテキストに応じたKVキャッシュと実行時の余裕を加えて見積もります。これは容量を考えるための計算で、実際の生成速度や同時処理能力を保証するものではありません。学習や高い同時処理を伴う大規模推論を、CPUサーバーだけで賄えると見込まないでください。
有効化から本番判断までを順番に確認します
次の項目を、上から順にチェックします。途中で対応条件が不明になった場合は、本番への適用を止めて確認を続けます。
- [ ] 必要機能を言語化する。 Agent向け知識空間や新しい検索フローが必要なのか、現行のClassic Knowledgeで不足する点を記録します。
- [ ] 公式の対応状況を確認する。 使用するEdition、リリース、ホスティング形態にKnowledgeFSが含まれるか、最新の公式案内で照合します。
- [ ] サービスとデータベースの依存関係を洗い出す。 対象バージョンのCompose設定と環境設定例を確認し、接続先、永続化先、起動順を整理します。
- [ ] イメージと実行環境を検証する。 入手元、バージョン、サーバーのアーキテクチャとの互換性を確認します。コミュニティの質問だけを、公式の可否判断として扱いません。
- [ ] 復旧と切り戻しを試す。 KnowledgeFSのデータを含むバックアップを取り、別環境での復元と旧フローへの戻し方を実演します。
- [ ] 業務フローで受け入れ確認を行う。 検索結果、アクセス権、障害時の挙動を確認し、問題があれば本番接続を延期します。
補足：Difyの設定ファイルに値を追加できることと、その機能が本番利用でサポートされることは別の確認事項です。動作確認だけでなく、更新後の維持方法と復旧可能性も評価します。
自社運用のサーバーは、負荷が継続する場合に比較します
共有型のVPSやクラウドインスタンスは、小規模な試作や短期間の検証には扱いやすい一方、共有環境のCPU競合、リソースの上限、ストレージ構成の制約が運用上の課題になることがあります。KnowledgeFSを含む複数サービスを長期稼働させる場合は、料金だけでなく、負荷の分離、保存容量、障害時の復旧方法も比較対象です。
専有のAMD物理サーバーは、他の利用者と同じホスト資源を共有しない構成を求め、継続的なサービス運用を計画する場合に候補になります。ただし、専有サーバーを選んでもKnowledgeFSの公式対応や互換性が保証されるわけではありません。先にソフトウェア側の条件を確定し、必要資源を整理してから、NodeKVMのサービス案内と料金・構成情報で現行の提供内容を確認してください。
よくある質問
Community EditionでKnowledgeFSを有効化できますか？
公式設定では、既定のCompose構成でKnowledgeFSは有効にならず、Community Editionのローカル運用では開発用オプションを明示する条件があります。ただし、その設定だけで本番サポートやイメージ提供が確約されるわけではありません。利用する版の公式資料と配布条件を確認してから、検証環境で試します。
Dify Agent Knowledge Baseと従来の知識ベースは同じ機能ですか？
同じ機能の単純な置き換えとして扱わないでください。従来のClassic Knowledgeを使うフローが安定しているなら、引き続き利用できます。Agent向けの知識空間や検索ノードが必要な場合に限り、KnowledgeFSで要件を満たせるか、権限や検索結果も含めて試します。
KnowledgeFSに独立したサービスとデータベースは必要ですか？
公式の1.18.0情報では、KnowledgeFSは任意の独立サービスとデータベースを伴います。Dify本体だけを前提とする構成とは分けて、接続設定、永続化、バックアップ、復旧の対象を整理します。設定例は、検証対象と同じリリースのものを選んでください。
1.18.0に更新したら、既存のDify知識ベースを移行すべきですか？
既存のClassic Knowledgeで検索や業務フローが安定し、Agent向けの新機能も必要ないなら、更新を理由に移行する必要はありません。KnowledgeFSを試す場合は、隔離環境で検索、権限、データ復元、旧フローへの切り戻しを確認します。検証が完了するまでは、本番データを移さない判断が安全です。
KnowledgeFSを有効にするか迷った場合は、まず要件と公式の対応範囲を確定し、その後にサーバー資源を見積もります。共有環境の競合や構成制限が継続運用の妨げになるなら、専有サーバーも比較対象にできます。NodeKVMの現行構成を確認する際も、KnowledgeFSの互換性は別途、利用するリリースと公式資料で照合してください。
よくある質問
-
Q
Dify 1.18.0のKnowledgeFSはCommunity Editionで自社運用できますか？
Community Editionのローカル運用では、KnowledgeFSは既定のCompose設定で有効にならず、開発用オプションを明示して有効化する条件が示されています。ただし、これは本番利用のサポートや配布イメージの継続提供を保証するものではありません。対応するリリース、イメージの入手先、復旧手順を確認してから隔離環境で試してください。
-
Q
Dify Agent Knowledge Baseは従来の知識ベースと何が違いますか？
従来のClassic Knowledgeを使うRAG構成と、Agent向けの知識空間を扱うKnowledgeFSは、同じ機能の新旧版として単純に置き換えられるものではありません。Agentの知識空間や検索ノードが必要かを先に確認し、既存の検索フロー、権限境界、運用手順に影響するかを試用環境で比較してください。
-
Q
KnowledgeFSを有効にすると、別のサービスやデータベースが必要ですか？
公式の1.18.0情報では、KnowledgeFSは任意の独立サービスとデータベースを伴う構成として説明されています。Dify本体だけのコンテナ構成と同一視せず、接続先、永続化先、認証情報、バックアップ対象を個別に洗い出してください。実際の環境変数や依存関係は、利用するリリースに対応した設定例で照合します。
-
Q
既存のDify知識ベースは1.18.0への更新後に移行すべきですか？
既存のClassic KnowledgeとRAGフローが安定しており、新しいAgent向け機能を必要としていないなら、更新を理由にKnowledgeFSへ移す必要はありません。移行を検討する場合は、検索結果、アクセス権、データの復旧、元のフローへの切り戻しを検証します。機能要件とEditionごとの対応状況を確認できるまでは、本番データを移行しない判断が安全です。