> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dify.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# エンドユーザーの識別

> user フィールドが何を識別し、どの範囲を制御し、なぜ呼び出し間で一貫させる必要があるか

> このドキュメントは AI によって自動翻訳されています。不正確な部分がある場合は、[英語版](/en/api-reference/guides/end-user-identity) を参照してください。

ほとんどのアプリエンドポイントは `user` フィールドを受け取ります。呼び出しがどのエンドユーザーの代理かを示す、自前の識別子です。Dify はこれを認証しません。アカウント ID など、1 人につき 1 つの安定した値を選び、常に同じ値を送ってください。

新しい `user` は初めて登場した時点で Dify が追跡を始め、1 つのアプリキーで任意の数のエンドユーザーに対応できます。

## `user` が制御する範囲

`user` は、各呼び出しが何を参照でき、何を実行できるかを決めます。

* **会話**：一覧、履歴、名前の変更、削除はいずれも、そのユーザーの会話だけを対象とします。

* **ファイル**：アップロードしたファイルはアップロードしたユーザーに属し、別の `user` で参照すると失敗します。

* **生成の停止**：チャット系の停止エンドポイントは、`user` が返信を開始したユーザーと一致する場合にのみ機能します。一致しない場合は黙って無視されます。呼び出し自体はどちらでも成功するため、レスポンスからは判別できません。

  ワークフローの「ワークフロータスクを停止」は `user` を確認しません。

* **実行の再開**：`user` が実行の作成者と一致しない場合、[ワークフローイベントをストリーム](/ja/api-reference/workflow-runs/stream-workflow-events) は 404 を返します。

1 つのフローのすべての呼び出しで、1 人につき同じ `user` を使い続けてください。アップロード、送信、停止、再開のすべてがこの値を確認します。

## API ユーザーと WebApp ユーザーの分離

API 経由のトラフィックと Dify がホストする WebApp では、ユーザーの識別が別々に管理されます。API ユーザーが作成した会話は WebApp に表示されず、WebApp の会話も API からは取得できません。

## エンドユーザー ID の解決

一部のレスポンスは、詳細情報の代わりにエンドユーザー ID を含みます。「ファイルをアップロード」のレスポンスにある `created_by` などです。[エンドユーザー取得](/ja/api-reference/end-users/get-end-user-info) でこの ID を解決できます。