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

# 顧客メッセージ：ケースでの情報リクエストと回答確認

> Diditのケース管理では、定型メッセージのプレビュー、認証済みの連絡先への情報リクエスト送信、顧客からのレスポンスのレビューができます。

ケースを開き、**顧客にメッセージを送信**を選択します。
認証済みの受信者、言語、目的を選択してから、**プレビュー**を選択します。
プレビューには、実際に使用される送信者、受信者、件名、メール本文がそのまま表示されます。
選択内容を変更するには**編集**を、確定するには**送信**を選択します。
変更されたプレビューや期限切れのプレビューは、送信前に再生成する必要があります。

## メッセージの目的

| 目的 | 顧客のアクション | ケースのステータス |
| - | - | - |
| 本人確認書類 | 本人確認書類の鮮明な写真をアップロードする | ユーザー対応待ち |
| 住所証明 | 氏名と居住地の住所が記載された最近発行された書類をアップロードする | ユーザー対応待ち |
| 企業書類 | 法人登記書類をアップロードする | ユーザー対応待ち |
| 詳細情報の確認 | レビュアーが評価するための氏名と生年月日を送信する | ユーザー対応待ち |
| レビュー中 | アクションは不要。メールにレスポンス用のボタンは含まれません | 変更なし |

書類のアップロードは現在、5 MBまでのJPEG、PNG、WebP画像に対応しています。
ケースの対象者に該当する目的のみが表示されます。
顧客向けのメールテンプレートは現在、英語、スペイン語、ポルトガル語で利用できます。
コンソールでは、セッションの再提出と同じメールフィールドと言語セレクターを使用します。

## 認証済みの受信者と固定テンプレート

受信者は、ケースの対象者およびアプリケーションに属するセッションで、メールアドレス認証を完了している必要があります。
ユーザープロフィールでインポートまたは編集されたメールアドレスは、認証済みとはみなされません。
認証済みの連絡先が存在しない場合は、作成画面にその旨が表示され、送信は無効のままになります。

レビュアーは、任意のメール本文、リンク、送信元アドレス、受信者を指定することはできません。
メールには、既存のDiditまたはホワイトラベルのブランディングが使用されます。
カスタムの送信元を使用するには、設定済みのメールドメインが検証されている必要があります。
すべてのテンプレートで、このメールがパスワード、認証コード、支払いを求めることはないと受信者に伝えます。

セッションの再提出は、認証チェックをやり直すための別のアクションとして引き続き提供されます。
そのプレビューには、実際の再提出メールと選択されたチェックが表示されます。

## 配信とレスポンス

メッセージ履歴では、キュー登録済み、送信中、送信済み、シミュレーション、不明の各配信結果が区別されます。
シミュレーションのメールは送信されません。
不明という結果は、プロバイダーがメールを受け付けた可能性があることを意味します。システムが自動的に再送信することはありません。
確定済みのリクエストを再試行する際は、重複配信を避けるため同じリクエストIDが使用されます。

対応が必要なリクエストには、7日間有効なセキュアなレスポンスリンクが含まれます。
リクエストをキャンセルするかケースを解決すると、そのリンクは無効になります。ケースが再オープンされた後も無効のままです。
顧客向けページでは、非公開のケースの調査結果やその他の元レコードは開示されません。

送信されたレスポンスは、**Customer messages**にレビュー待ちの証拠として表示されます。
ケースはオープンに戻り、既存の保留中の解決については、再度レビューが必要です。
レスポンスによって、以前の提出を置き換えること、元の認証を承認すること、顧客の本人情報を上書きすること、不正の判定結果に寄与することはできません。

元の認証またはケースを削除すると、その顧客リクエストとアップロードされた証拠も削除されます。

## APIワークフロー

コンソールのすべてのエンドポイントは、組織、アプリケーション、ケースの範囲に限定されます。

```text theme={null}
GET  /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/options/
POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/preview/
GET  /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/
POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/
POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/cancel/
POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/remind/
GET  /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/attachment/
```

履歴と添付ファイルの読み取りには`read:cases`が必要です。
作成、プレビュー、確定、キャンセル、リマインドには`write:cases`が必要です。
確定時には、同じ`contact_id`、`purpose`、`language`に加えて、プレビューで返された`request_id`、`expires_at`、`preview_token`を含める必要があります。
確定レシートは15分後に期限切れとなります。これは顧客のレスポンス期限とは関係ありません。

リマインダーは、同じ確認済みの受信者に同じメールを再送信します。送信できるのは、1件のリクエストにつき24時間に1回までです。
それ以外は何も変更されません。リクエストの期限もケースのステータスもそのまま維持されます。
レスポンスでは、リクエスト、`reminded_at`、リマインダー自体の`delivery_status`（`SENT`、`SIMULATED`、`UNKNOWN`のいずれか）、`next_reminder_at`が返されます。
顧客がもう回答する必要のないリクエストの場合は、`code`が`case_request_not_waiting`の`409`と、`reason`（`answered`、`cancelled`、`expired`、`closed`、`not_actionable`、`not_delivered`、`contact_unavailable`のいずれか）が返されます。
24時間以内に2回目のリマインダーを送ると、`code`が`case_request_reminder_too_soon`の`429`、`retry_at`タイムスタンプ、`Retry-After`ヘッダーが返されます。
解決が承認待ちの間は、リマインダーは`400`を返します。

顧客向けのエンドポイントは`GET`または`POST /v3/case-requests/{request_uuid}/`で、リクエスト固有の`X-Case-Request-Token`ヘッダーを使用します。
回答用リンクはこの認証情報をフラグメントに含んでおり、ページを開くとそのフラグメントは削除されます。
このトークンでアクセスできるのは、そのリクエストのみです。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.