ホームAIサーバーはどのようにして各ユーザーのコンテキストを分離しているのですか？

ホームAIサーバーは同じモデルを共有しながら各ユーザーのコンテキストを分離できますが、その分離はモデル自体から生じるものではありません。チャット、メモリー記録、取得したドキュメント、キャッシュエントリ、ツール呼び出しのすべてを認証済みユーザーに紐付けてから、その情報がプロンプトに届くようにすることから生まれます。

二人が別々にサインインできるのに、一方のユーザーの質問が他方のメモを取得してしまう場合、その失敗は通常モデルの周辺のアプリケーションにあります。重要なテストは、アイデンティティがリクエストの全経路で保持されているかどうかです。この記事はその経路をたどり、どこで分離を強制すべきか、どこでよく破られるか、そしていつより強い境界が必要かを示します。

モデルは共有できても、個人のコンテキストは共有できません

モデルの重みは共通の推論エンジンです。モデルが通常の推論リクエストを処理している場合、家族や同僚ごとに別々のコピーを用意する必要はありません。分けておくべきは、その重みの周りに特定のリクエストのために組み立てられた情報です。

その情報には、現在のチャット、保存された会話履歴、ユーザーの設定、取得したファイルの抜粋、ベクター検索の結果、ツールの出力、一時キャッシュ、認証情報が含まれます。これらの層が組み合わさって個人のコンテキストを形成します。同じモデルプロセスを通しても、異なるユーザーには異なるコンテキストパッケージが提供されるべきです。

この区別により、アーキテクチャは実用的になります。ホームサーバーは複数の同一モデルのコピーを読み込むことを避けつつ、各アシスタントを個別化するデータの分離を維持できます。分離の境界は、アイデンティティ、ストレージ、検索、セッション、ツールアクセスにあり、単にモデルにプライバシーを尊重するよう指示するプロンプトにはありません。

アイデンティティはリクエストの全過程にわたって追跡されなければなりません

別々のログイン画面は最初のステップに過ぎません。認証はリクエストを行う人物を確定し、認可はその人物がアクセスできるチャット、ファイル、メモリー、アクションを決定します。効果的な分離には、ユーザーがインターフェースを開くときだけでなく、すべてのデータ境界で認証後の認可が必要です。

サーバーは、検証済みのセッションまたはアクセストークンから安定したユーザーIDを導き出すべきです。フォームフィールド、URLパラメーター、チャットメッセージで送信されたユーザーIDを信用してはいけません。そうしないと、クライアントが制御する値を一つ変更するだけで、他人の記録を要求できてしまう可能性があります。

そのサーバー由来のIDはすべてのルックアップの一部となります。会話クエリ、ベクター検索、ファイルパス、キャッシュキー、ツールの認証情報はすべて同じ信頼されたユーザースコープを必要とします。下流のサービスの1つがこれを失うと、フロントエンドは別々のアカウントを表示していても、システムは静かに共有コンテキストに戻ってしまいます。

耐久メモリにはストレージレベルの境界が必要です

長期メモリは通常、リレーショナルデータベース、ドキュメントストア、またはディスク上のファイルに保存されます。各レコードには所有者またはテナント識別子が必要で、すべての読み取り、更新、削除はそのIDに制限されなければなりません。広範なクエリでデータが返された後にフィルタリングするのは遅すぎます。

データベースポリシーは、アプリケーションコードの下に第2の強制ポイントを提供できます。データベースがレコードを返す前に現在のユーザーを評価すると、1つのアプリケーションルートでフィルターが漏れてもクロスユーザーの情報漏洩になる可能性が低くなります。

ファイルベースのメモリも同じ規律が必要です。各ユーザーに専用のディレクトリを割り当て、所有権とアクセス制御ルールを維持し、アプリケーションが認証済みのIDからパスを解決するようにします。ブラウザから提供されたフォルダ名は認可の境界ではなく、無制限のファイルシステムアクセスを持つ共有サービスアカウントは慎重に設定されたディレクトリを回避できます。

プロンプトが構築される前に取得は範囲を限定する必要があります

RAGは最も重要な分離ポイントの一つを作り出します。なぜなら、取得されたパッセージが直接モデルの作業コンテキストに挿入されるからです。別のユーザーのドキュメントがプロンプトに入った場合、それをモデルに開示しないように頼むのは信頼できる対処法ではありません。まず取得レイヤーで除外しなければなりません。

権限認識型RAGレイヤーは、ドキュメントアクセス権による検索結果のフィルタリングを、パッセージがプロンプトに入る前に行うことができます。認可の判断は、質問で提供されたIDではなく、検証済みのセッションを使用しなければなりません。

ベクターデータベースは、ユーザーごとに1つの名前空間またはコレクションでレコードを分離するか、共有インデックス内で必須のメタデータフィルターを使用して分離できます。分離のための名前空間またはコレクションは、書き込み、検索、削除の範囲を簡単にし、メタデータフィルタリングは、家庭やチームで共通のドキュメントがある場合の制御された共有をサポートできます。

アプリケーションは検証済みセッションから名前空間を選択すべきであり、プロンプトから受け入れるべきではありません。同じルールはプライベートドキュメントに対してセマンティック検索を行う場合にも適用されます。識別フィルタリングは類似度ランキングの前のクエリパスに属し、結果返却後のクリーンアップステップではありません。

共有ドキュメントにも明示的なモデルが必要です。レコードは1人のユーザー、世帯グループ、またはワークスペースに属することがありますが、そのスコープは権限データとして保存され、一貫して評価されるべきです。ドキュメントを複数の個人インデックスにコピーするのは小規模なシステムでは簡単かもしれませんが、ユーザーや共有フォルダが増えるにつれてグループベースの権限の方が管理しやすくなります。

セッションとキャッシュは誤ってデータを再接続することがあります

データベースは完全にフィルタリングできても、キャッシュがコンテキストを漏らすことがあります。チャット履歴が`conversation_id`だけでキャッシュされている場合、衝突や予測可能な識別子を持つ2人のユーザーが同じエントリにアクセスする可能性があります。より安全なキーは信頼されたユーザーIDと会話IDの両方を含みます。

同じ境界はプロンプトキャッシュ、取得チャンクキャッシュ、一時アップロードディレクトリ、メモリ内セッションオブジェクトにも適用されます。テナント認識キャッシュキーは、信頼されたユーザーIDをキャッシュの読み書き両方に渡すことでユーザー間の露出を減らします。

ログアウトは適切な状態を削除または無効化しなければなりません。ブラウザのクッキーをクリアしてもサーバー側のセッション、一時ファイル、またはキャッシュされたプロンプトが残っていると、共有コンピューター上で前のユーザーのコンテキストが露出する可能性があります。期限切れ、削除、アカウント削除は個人データを保持するすべてのストアに伝播すべきです。

ツール呼び出しには同じユーザー境界が必要です

アシスタントはカレンダーの読み取り、メール検索、NASフォルダの開放、または自動化のトリガーを行うことがあります。これらのツールはチャットデータベース以上の情報を明らかにする可能性があるため、各呼び出しはAIサービスが保持する単一の管理者資格情報ではなく、要求したユーザーの権限を使用しなければなりません。

ローカルファイルの場合、ツールはユーザーのファイルシステムアクセス権を継承または強制すべきです。接続されたアプリケーションでは、統合が対応している場合にユーザースコープのトークンを使用してください。グローバルトークンはテスト時には便利ですが、アシスタントが元のサービスからユーザーが期待する権限を回避する経路になってしまいます。

ツールの出力もコンテキストになります。リクエストと同じユーザーおよびセッションスコープで保存し、通常のチャット履歴に秘密情報を置かず、ログから機密フィールドを編集してください。安全な検索レイヤーは、ツールが他のユーザーのデータを直接返すことを補うものではありません。

どの分離パターンが家庭用AIサーバーに適しているか？

適切な境界は、機密性、ユーザー数、およびサーバー所有者が維持できる管理量によって異なります。この表は、共有されるものとミスが最も起こりやすい場所で一般的な設計を比較しています。

ほとんどの家庭では、行レベルのルール、ユーザースコープのベクトル検索、分離されたファイルパス、ユーザー固有のツール権限が実用的な中間地点を提供します。ユーザー同士が信頼できない場合、ツールが任意のコードを実行する場合、またはミスの影響が非常に大きい場合には、コンテナや別のマシンが有用になります。

なぜ別々のアカウントでもコンテキストが漏れるのか

1つ目の失敗は、権限をインターフェース上でのみ適用することです。サイドバーで他のユーザーの会話を隠しても、APIが異なるIDでそれらを返す場合は意味がありません。すべてのサーバーエンドポイントで認可の判断を繰り返す必要があります。

2つ目の失敗は、チャット履歴のフィルタリングは行うが、検索時には行わないことです。アシスタントは正しい会話を表示しますが、ユーザーフィルターなしで共有ベクトルインデックスを検索します。そのため、回答には表示されていないプライベートな詳細が含まれてしまいます。

3つ目の失敗は共有される運用データです。デバッグログ、トレース、プロンプトキャッシュ、一時アップロード、分析には最終回答と同じ機密コンテキストが含まれる可能性があります。ランタイムコンテキストは、ベースモデルがそれに基づいて訓練されていなくても機密情報を露出させる可能性があります。

最後の失敗は、モデルをアクセス制御レイヤーとして信頼することです。システムプロンプトはプライバシーの期待を説明できますが、決して取得されるべきでなかったコンテキストを確実に取り消すことはできません。セキュリティコントロールはモデルに届くものを決定すべきであり、モデルがユーザーが取得を許可されたものを決めるべきではありません。

ユーザー分離が本当に機能しているかをテストする方法

意図的に異なるテストデータを持つ2つの通常アカウントを作成します。ユーザーAにはユニークで無害なフレーズを含むドキュメントを、ユーザーBには異なるフレーズを与えます。どちらのフレーズもテストコーパスの他の場所には存在しないようにします。

ユーザーBから、直接的な質問、あいまいな意味検索、推測された会話ID、共有リンク、名前変更されたファイル、アシスタントにルールを無視するよう依頼するリクエストを試みます。目的は通常のインターフェースをテストするだけでなく、すべてのルートがユーザーBのスコープ外のデータを返さないことを検証することです。

ログアウト、サービス再起動、キャッシュのウォームアップ、ドキュメントの再インデックス、バックアップの復元、アカウント削除後にテストを繰り返します。これらの遷移は通常のチャットとは異なるコードパスを使うことが多く、主要なクエリパスが正しく処理する古いコンテキストを再導入する可能性があります。

同じ2つのIDでサーバーログを確認します。各取得、ファイル読み取り、メモリ書き込み、ツール呼び出しは、プライベートなプロンプト内容を不必要に記録することなく、期待されるユーザースコープを持つべきです。管理者は、なぜすべてのコンテキスト項目が最終プロンプトに入ったのか説明できる必要があります。

家庭用に実用的な分離設計

まずはモデルの実行とデータをローカルに保持することから始め、その後、サーバーがセッションから導出する1つのIDサービスと1つの信頼できるユーザーIDを使用します。そのIDをチャットサービス、メモリーストア、ベクター検索、ファイルゲートウェイ、ツールレイヤーに渡します。IDや権限スコープが欠けている場合は、共有のデフォルトにフォールバックするのではなくリクエストを拒否してください。

特定の脅威が別々のランタイムを必要としない限り、モデルは共有のままにしてください。ストレージ、取得、推論、インターフェース、権限の周辺スタックこそが、ローカルファイルをローカルデータに基づくプライベートアシスタントに変えます。モデルの重みを複製しても、スコープが設定されていないデータベースクエリは修復されません。

耐久性のある記録にはユーザーまたは作業スペースの識別子を使用し、可能な限りアプリケーションの下層で行アクセスを強制し、ベクターデータはユーザースコープの名前空間または必須のフィルタリングされたパーティションに置いてください。一時ファイルやキャッシュにも同じスコープを与え、各レイヤーに対して有効期限と削除ルールを設定します。

個人の知識と共有の知識は意図的に分けてください。家庭用マニュアルは共通の作業スペースに属し、税務記録はプライベートに保ちます。マルチロールAIサーバーでは、グループメンバーシップがそのリクエストに対してユーザーの個人コンテキストにどの共有作業スペースが結合されるかを決定します。

脅威が変わったらより強力な境界を選択してください。ユーザーがコードを実行したり、プラグインをインストールしたり、任意のフォルダーをマウントしたり、強力なツールに接続できる場合、アプリケーションのフィルターだけでは不十分なことがあります。別々のコンテナ、仮想マシン、認証情報、ストレージが、侵害されたサービスがアクセスできる範囲を制限できます。

よくある質問

各ユーザーにAIモデルの別々のコピーが必要ですか？

いいえ。複数のユーザーが一つの推論モデルを共有できます。なぜなら個人のコンテキストは各リクエストごとに別々に組み立てられるからです。別々のモデルプロセスは、信頼できないユーザー、カスタムアダプター、厳しいリソース制限、またはより強い運用境界を必要とするワークロードに対して依然として有用です。

個人のコンテキストを保護するために別のチャット履歴だけで十分ですか？

いいえ。チャット履歴はコンテキストの一つのソースに過ぎません。取得されたドキュメント、ベクターインデックス、アップロードされたファイル、キャッシュ、ツールの認証情報、ログ、一時データも同じアイデンティティ境界に従う必要があります。スコープが設定されていないレイヤーが一つでもあると、表示されている会話リストが正しくても情報が漏れる可能性があります。

家族間で意図的に一部のコンテキストを共有できますか？

はい。共有ドキュメントや記憶は明示的な家庭や作業スペースのスコープに置き、それを必要とするユーザーにメンバーシップを付与してください。個人の記録は個別の所有権の下に保ちます。プロンプトビルダーは、現在のユーザーのプライベートスコープと認可された共有スコープを組み合わせることができますが、どちらも全員に公開しません。

実用的なルールはシンプルです：モデルを共有し、コンテキストパスは共有しないこと。アイデンティティは、データが読み取られ、取得され、キャッシュされ、ツールに渡される前に制約をかけなければなりません。すべてのレイヤーがどのユーザーがアイテムを認可したかを答えられれば、ホームAIサーバーは計算資源を共有しながらも個人用のままでいられます。