Langflow 1.12.3、ナレッジベースのユーザー間分離の不備を修正　既存データの移行には手動確認が必要

Langflowは9月22日に1.12.3をリリースし、OpenSearchとChroma Cloudのナレッジベースの保存領域を所有者ごとに分離するよう変更した。PyPIでも同バージョンのパッケージが公開されている。この修正は、複数ユーザーで共有するRAG環境と、アップグレード後も既存の文書を検索できるかどうかに直接影響する。[リリース告知](https://github.com/langflow-ai/langflow/releases/tag/v1.12.3)、[PyPIのリリース履歴](https://pypi.org/project/langflow/1.12.3/)

問題の原因は、2つの層で命名規則が一致していなかったことにある。アプリケーションでは異なるユーザーが同名のナレッジベースを作成できる一方、リモートストレージではナレッジベース名だけが使われる場合があった。2人がそれぞれ「docs」を作成し、同じOpenSearchクラスター、または同じChroma Cloudのテナントとデータベースに接続すると、検索結果に互いの文書の断片が混入したり、削除操作が相手のデータに影響したりする可能性がある。メンテナーは2ユーザーによる再現記録を公開しているが、それを根拠にすべての導入環境で情報漏えいが起きたとは判断できない。[修正の説明](https://github.com/langflow-ai/langflow/pull/15148)

新版では、所有者IDとナレッジベース名からハッシュ化したストレージ名を生成し、一般ユーザーによる物理インデックスやコレクションの指定を制限する。移行時には、単一の所有者に帰属すると判断できる旧名称については既存の紐付けを維持する。複数ユーザーが共有する名称については警告を記録し、それぞれの空の保存領域に接続先を切り替えるが、元のデータは削除しない。移行処理ではリモート側のアカウントを確認しないため、実際にはデータが混在していない同名のナレッジベースでも、手動での復旧が必要になる可能性がある。[移行ルール](https://github.com/langflow-ai/langflow/pull/15148)

同バージョンの告知には、ナレッジベースの接続先に対するSSRF対策の検証処理や、凍結したノードの結果キャッシュを実行者ごとに分離する修正も記載されている。これらはそれぞれ、外部接続とキャッシュの境界に対処する変更だ。ストレージ名が分離されたことを確認するだけでは、ワークフロー全体の権限制御の動作を検証したことにはならない。[変更一覧](https://github.com/langflow-ai/langflow/releases/tag/v1.12.3)

公式ドキュメントに記載されている「Test Connection」は、バックエンドに到達できるかを確認するための機能だ。今回の問題からは、管理者は接続の成功だけでなく、ナレッジベースが最終的に使用する物理コレクションと、認証情報がアクセスを許可する範囲も追跡・確認すべきだと考えられる。画面上で別々に表示されるリソースでも、基盤となるストレージで必ず分離されているとは限らない。[ナレッジベースのドキュメント](https://docs.langflow.org/knowledge)

エンジニアリングチームによるアップグレードの受け入れ検証には、2つのアカウントで同名のナレッジベースを作成した後の検索、件数の確認、削除を含めるべきだ。また、旧インデックスとの対応表と元の文書も保持しておく必要がある。新版で既存の内容が見えなくなった場合は、まず移行時の警告とデータの帰属を確認し、そのうえで再インポートするか、管理者が紐付けを復元するかを判断する。運用上の要点は、インストール結果と既存データの移行をそれぞれ検証することにある。公開された再現記録は、各環境での受け入れ検証の代わりにはならない。