このドキュメントは AI によって自動翻訳されています。不正確な部分がある場合は、英語版 を参照してください。
ほとんどのアプリエンドポイントは user フィールドを受け取ります。呼び出しがどのエンドユーザーの代理かを示す、自前の識別子です。Dify はこれを認証しません。アカウント ID など、1 人につき 1 つの安定した値を選び、常に同じ値を送ってください。
新しい user は初めて登場した時点で Dify が追跡を始め、1 つのアプリキーで任意の数のエンドユーザーに対応できます。
user が制御する範囲
user は、各呼び出しが何を参照でき、何を実行できるかを決めます。
-
会話：一覧、履歴、名前の変更、削除はいずれも、そのユーザーの会話だけを対象とします。
-
ファイル：アップロードしたファイルはアップロードしたユーザーに属し、別の
user で参照すると失敗します。
-
生成の停止：チャット系の停止エンドポイントは、
user が返信を開始したユーザーと一致する場合にのみ機能します。一致しない場合は黙って無視されます。呼び出し自体はどちらでも成功するため、レスポンスからは判別できません。
ワークフローの「ワークフロータスクを停止」は user を確認しません。
-
実行の再開：
user が実行の作成者と一致しない場合、ワークフローイベントをストリーム は 404 を返します。
1 つのフローのすべての呼び出しで、1 人につき同じ user を使い続けてください。アップロード、送信、停止、再開のすべてがこの値を確認します。
API ユーザーと WebApp ユーザーの分離
API 経由のトラフィックと Dify がホストする WebApp では、ユーザーの識別が別々に管理されます。API ユーザーが作成した会話は WebApp に表示されず、WebApp の会話も API からは取得できません。
エンドユーザー ID の解決
一部のレスポンスは、詳細情報の代わりにエンドユーザー ID を含みます。「ファイルをアップロード」のレスポンスにある created_by などです。エンドユーザー取得 でこの ID を解決できます。Last modified on July 9, 2026
