# 08-KASIKAエントリーページとVISTA初回アクセス口座開設

バージョン：v0.3

## 改訂履歴

| 日付 | バージョン/番号 | 変更種別 | 変更概要 |
| --- | --- | --- | --- |
| 2026-06-15 | v0.1 | 新規作成 | KASIKAエントリーページとVISTA初回アクセス口座開設の要件を策定。 |
| 2026-08-04 | v0.2 | 重大な要件変更 | 初回バインディング時はKASIKAの`VISTAURL`および該当する場合の`VISTAPWD`のみを書き戻すことを明確化。VISTA顧客ID、バインディング状態、初回アクセス完了時刻はVISTA内のみで保存。 |
| 2026-08-07 | v0.3 | 重大な要件変更 | C側本人確認前の情報表示範囲を補完し、エントリーページのプロトタイプをVISTA Cの顧客側表現に同期。 |

## 1. モジュールの位置付け

本ドキュメントは、KASIKA自動返信メール内のKASIKAエントリーページ、および顧客が初回アクセス時にVISTAが実施するプロジェクト検証、KASIKA顧客検証、VISTA顧客バインディング／作成、メール本人検証、任意のパスワード設定、`customer_status`保存、初回バインディング時のタグ初期化、以降のステータス自動更新制御、ならびにVISTAのビジネスプロセスへの遷移を定義する。

本フローは以下の課題を解決するために使用される：

- KASIKA自動返信メールは即時送信であり、VISTAの後続同期によるアクセスURLとパスワードの生成を待つことができない。
- 顧客がKASIKAメールをクリックした後、今回のアクセス内でVISTA顧客の作成またはバインディングを完了する必要がある。
- VISTAはKASIKAの`customer_status`フィールドを保存する必要がある。初回バインディング時は、このフィールドに基づいて同名のVISTAタグ初期化を必ず1回実行し、顧客が初期アクセス権限を取得できるようにしなければならない。
- エントリーリンク、KASIKA顧客、VISTA顧客、メールの間で整合性を確保し、誤バインディングや越権アクセスを回避する必要がある。

本フローは`04-統一顧客連動同期フロー.md`を代替しない。`04`は引き続きKASIKA -> VISTAの一括同期、同期フォールバック、一括バインディング、ログ追跡を担当する。本ドキュメントは「顧客がKASIKAメールのエントリーをクリックすることでトリガーされるKASIKAエントリーページフロー」のみを定義する。

## 2. ビジネス目標

1. KASIKA自動返信メールは、顧客登録後すぐにVISTAエントリーを提供できる。
2. 顧客がメール内のVISTAエントリーをクリック後、VISTAは当該プロジェクトがKASIKAと連動しているかを確認できる。
3. VISTAは`kasikacid`の正当性を検証し、KASIKA顧客情報を取得できる。
4. VISTAは`kasikacid`とVISTA顧客のバインディングが既に存在するかを判断し、バインディングアカウントのメール整合性を検証できる。
5. 未バインディングだが同一メールのVISTA顧客が存在する場合、システムは競合がなく、かつ当該VISTA顧客がKASIKA再バインディング禁止のマーク付けされていない場合にのみバインディングを完了できる。
6. 未バインディングかつ同一メールのVISTA顧客が存在しない場合、システムは新規バインディングフローを継続する。
7. システムはKASIKA設定ページの「VISTAアクセスパスワードが必要か」のスイッチに基づき、顧客がパスワードを設定する必要があるかを判断する。
8. システムはKASIKAが返却した`customer_status`フィールドを保存し、初回バインディング時に同名のVISTAタグ初期化を必ず1回実行する。以降のステータス変化に応じてタグ／権限を自動更新するかどうかは、設定ページの`customer_status`ステータス権限自動更新スイッチで制御する。
9. 成功後、KASIKA識別Cookieを書き込み、VISTAホームページのログインまたはアクセスフローへ遷移する。

## 3. 前提条件

### 3.1 VISTAプロジェクト側の前提条件

1. VISTAプロジェクトは完全な4つのKASIKA API KEYを保存済みであり、KASIKA顧客関連APIを呼び出す基盤条件を備えている。
2. VISTAプロジェクトは安定かつ一意のアクセスサブドメインをバインディング済みであり、システムはアクセスHostから一意のVISTAプロジェクトを逆引きできる。
3. VISTAプロジェクト設定ページにKASIKAエントリーページURLが提供され、管理者がKASIKA自動返信メールテンプレートにコピーしている。
4. VISTAプロジェクトはタグ権限テンプレートを設定済みである。初回バインディング時に`customer_status`同名タグがヒットした後、タグ権限テンプレートを通じて顧客の初期アクセス権限を取得する。
5. VISTAプロジェクト設定ページには「VISTAアクセスパスワードが必要か」スイッチが存在し、デフォルトはオンである。
6. VISTAプロジェクト設定ページには`customer_status`ステータス権限自動更新スイッチが存在し、デフォルトはオンである。このスイッチは初回バインディング後の以降のステータス変化に応じてタグと権限を自動更新するかどうかのみを制御し、初回バインディング時のタグ初期化には影響しない。

### 3.2 KASIKAメールテンプレート側の前提条件

1. 利用者はVISTAが提供するエントリーURLテンプレートを予めKASIKA自動返信メールテンプレートに記入しておく必要がある。
2. KASIKA自動返信メールはKASIKA顧客ID変数を挿入できなければならない。
3. VISTAの管理画面で表示・コピーされるプロジェクトエントリーURLは、現在のVISTAプロジェクトの一意のサブドメインを使用し、具体的なKASIKA顧客IDを含まない。
4. KASIKA自動返信メールを実際に顧客へ送信する際は、KASIKAメールテンプレートまたはKASIKA送信メカニズムによって`kasikacid`パラメータを追加／挿入する必要がある。
5. 設定済みの旧テンプレートとの互換性のため、システムは移行期間中`cid`パラメータの読み取りを互換的にサポートできる。`kasikacid`と`cid`が同時に存在し、値が一致しない場合はパラメータ競合として処理し、システム404ページへ遷移する。

VISTA管理画面で表示・コピーされるURL形式：

```text
https://{domain}.homevista.jp/kasika-entry
```

顧客が実際に受け取るURLは、KASIKA送信後に以下の形式となる必要がある：

```text
https://{domain}.homevista.jp/kasika-entry?kasikacid={KASIKA顧客ID}
```

## 4. コア判定ロジック

エントリーリクエストは以下の順序で判定する必要がある。前提判定に失敗した場合、後続のステップは実行しない。

| 順序 | 判定項目 | 失敗時の処理 |
| --- | --- | --- |
| 1 | アクセスHostを通じてVISTAプロジェクトがKASIKAと連動済みかを検証 | 連動プロジェクトなし、プロジェクトが識別不能、またはAPI KEYが不完全な場合はシステム404ページへ遷移 |
| 2 | `kasikacid`パラメータが存在し、一意で、形式が正当かを検証 | 不正、欠落、空値、パラメータ競合の場合はシステム404ページへ遷移 |
| 3 | KASIKA顧客照会APIを呼び出して顧客情報を取得し、返却された顧客IDが`kasikacid`と一致することを確認 | 照会失敗、顧客不存在、返却ID不一致の場合はシステム404ページへ遷移 |
| 4 | `kasikacid`がVISTA顧客にバインディング済みかを判断し、バインディングアカウントのメール整合性を検証 | バインディング状態に応じて分岐 |
| 5 | 顧客はメールのみを入力し、システムはメールの形式正当性およびKASIKA顧客メールとの一致を検証 | 不一致または形式不正の場合はページでエラーを表示し、再試行を許可。メール検証段階ではパスワード入力欄を表示しない |
| 6 | メール検証通過後、バインディング可能な同一メールのVISTA顧客が存在するかを判断 | バインディング可能な場合はバインディングを確立し、パスワード入力をスキップ。バインディング不可の場合は競合として処理。存在しない場合は新規VISTA顧客フローへ |
| 7 | 新規VISTA顧客の作成が必要で、かつ「VISTAアクセスパスワードが必要か」スイッチがオンの場合のみパスワード設定を表示 | バインディング可能なVISTA顧客が存在する場合、またはプロジェクトがアクセスパスワードスイッチをオフにしている場合は、パスワード入力をスキップ |
| 8 | VISTAアカウントを作成／バインディング／アクティブ化し、`customer_status`を保存し、初回バインディング時に同名VISTAタグ初期化を必ず1回実行 | 同名タグがない場合はタグを追加せず、口座開設をブロックしない。タグ初期化失敗時はバインディングをロールバックしない |
| 9 | 成功を通知し、KASIKA Cookieを書き込み、VISTAホームページのログインまたはアクセスフローへ遷移 | Cookie書き込み失敗時は遷移をブロックしないが、ログを記録する必要がある |

### 4.1 バインディング状態の分岐

| 状態 | 判定条件 | 処理ルール |
| --- | --- | --- |
| 状態1：バインディング済みかつメール一致 | `kasikacid`がVISTA顧客にバインディング済みで、KASIKAが返却するメールがバインディングされたVISTA顧客メールと一致 | KASIKA Cookieを書き込みまたは確認し、VISTAホームページのログインまたはアクセスフローへ遷移。顧客を重複作成せず、パスワード設定を重複要求せず、KASIKAフィールドスナップショット、`customer_status`タグまたは権限を更新しない |
| 状態2：未バインディングだが同一メールのVISTA顧客が存在 | `kasikacid`未バインディング。VISTAに同一メールの顧客が存在 | 顧客のメール検証通過後、当該VISTA顧客がKASIKA未バインディング、KASIKA再バインディング禁止のマーク付けなし、かつ削除後に復旧されたが管理画面でのガバナンス未実施の履歴顧客に該当しない場合は、バインディングを確立しパスワード入力をスキップ。当該VISTA顧客が他のKASIKA customer_idにバインディング済み、再バインディング禁止のマーク付け済み、または削除復旧リスクがある場合はエラーを表示 |
| 状態3：バインディング済みだがメール不一致 | `kasikacid`がVISTA顧客にバインディング済みだが、KASIKAが返却するメールがバインディングされたVISTA顧客メールと異なる | エラー情報を表示し、続行を許可しない。自動でバインディングを変更しない |
| 状態4：未バインディングかつ同一メールのVISTA顧客が存在しない | `kasikacid`未バインディング。VISTAに同一メールの顧客が存在しない | 新規バインディングフローを継続 |

説明：

1. 状態2において、同一メールのVISTA顧客が複数存在する場合、候補顧客が他のKASIKA customer_idにバインディング済みの場合、または候補顧客がKASIKA再バインディング禁止のマーク付け済みの場合は、いずれも競合として処理し、自動バインディングしない。
2. 状態2において、アクセスパスワードスイッチはバインディング可能な既存VISTA顧客に影響しない。KASIKAエントリーページによる同一メール既存顧客のバインディングを理由に、顧客へのパスワード設定またはリセットを要求してはならない。
3. 状態3では、今回入力されたメールで既存VISTA顧客メールを上書きしたり、他のVISTA顧客への自動バインディング変更を許可したりしてはならない。
4. 状態1は既存バインディング顧客の直接アクセス経路であり、後続の同期責任を負わない。以降の`customer_status`変化、タグ置換、権限更新は`04`で定義される同期フローが一元的に処理する。
5. すべてのエラー通知は顧客向けに汎用文言を使用し、KASIKA顧客ID、VISTA顧客ID、内部バインディング対象またはAPIエラー詳細を表示しない。

## 5. 業務フロー図

```mermaid
flowchart TB
  A["顧客がKASIKAメール内のVISTAエントリーをクリック"] --> B{"VISTAプロジェクトはKASIKAと連動済みか"}
  B -->|いいえ| B1["システム404ページへ遷移"]
  B -->|はい| C{"kasikacidパラメータは正当か"}
  C -->|いいえ| C1["システム404ページへ遷移"]
  C -->|はい| D["KASIKA顧客照会APIを呼び出し"]
  D --> E{"KASIKA顧客を取得でき、IDが一致するか"}
  E -->|いいえ| E1["システム404ページへ遷移"]
  E -->|はい| F{"kasikacidはVISTA顧客にバインディング済みか"}

  F -->|バインディング済み| G{"バインディング顧客メールはKASIKAメールと一致するか"}
  G -->|はい| G1["KASIKA Cookieを書き込み／確認"]
  G1 --> G2["VISTAホームページのログインまたはアクセスフローへ遷移"]
  G -->|いいえ| G3["バインディングメール不一致エラーを表示"]

  F -->|未バインディング| J["顧客はメールのみを入力"]
  J --> K{"メール形式が正当かつKASIKAメールと一致するか"}
  K -->|いいえ| K1["ページでエラーを表示し再試行を許可"]
  K -->|はい| H{"同一メールのVISTA顧客が存在するか"}
  H -->|存在し、KASIKA未バインディング、再バインディング禁止なし、削除復旧リスクなし| H1["kasikacidとVISTA顧客のバインディングを確立<br/>パスワード入力をスキップ"]
  H -->|存在するが他のKASIKA customer_idにバインディング済み<br/>または再バインディング禁止／削除復旧リスクあり| H2["バインディング競合エラーを表示"]
  H -->|存在しない| I["新規VISTA顧客フローへ"]

  I --> L{"プロジェクトはVISTAアクセスパスワードを要求するか"}
  L -->|はい| M["顧客がアクセスパスワードを設定"]
  L -->|いいえ| N["パスワード設定をスキップ"]
  M --> O["VISTA顧客の作成／バインディング処理を完了"]
  N --> O
  H1 --> O
  O --> P["customer_statusフィールドを読み取り保存"]
  P --> R["初回バインディング時のタグ初期化<br/>customer_status同名VISTAタグを設定"]
  R --> S["タグ権限テンプレートに基づき初期権限を取得"]
  S --> T["KASIKA Cookieを書き込み"]
  T --> U["成功を通知しVISTAホームページのログインまたはアクセスフローへ遷移"]
```

## 6. 顧客アカウントとバインディングルール

| 状態 | 意味 | 処理ルール |
| --- | --- | --- |
| 未作成 | VISTAがこのKASIKA顧客のアカウントをまだ作成していない | エントリーをクリックすると新規バインディングフローへ |
| 作成済み未アクティブ化 | VISTAに同一メールのアカウントが既に存在するが、初回アクセスが未完了 | バインディング競合がなければバインディングを確立可能。既存のバインディング可能な顧客として処理し、パスワード設定を表示しない |
| アクティブ化済み | VISTA顧客がアクセス可能 | バインディング済みかつメール一致の場合は直接遷移。未バインディングだが同一メールかつ他のバインディングがない場合はバインディングを確立可能。バインディング確立後はパスワード設定を表示せず、パスワードをリセットしない |
| バインディング異常 | KASIKA customer_idとVISTA顧客のバインディング競合、メール不一致、または保存失敗 | 自動上書きしない。汎用エラーを表示しログを記録 |
| 削除済みまたは再バインディング禁止の履歴 | VISTA顧客が過去に削除されKASIKA有効バインディングが失効した、または管理画面でKASIKA再バインディング禁止のマーク付けが行われた | 元のバインディングを自動復旧せず、現在または他のKASIKA顧客へのバインディングも行わない。汎用エラーを表示しログを記録 |

## 7. メールとパスワードのルール

### 7.1 メール本人検証

1. 顧客はメールを入力する必要がある。
2. VISTAフロントエンドは先にローカルの必須入力と形式検証を行う。メール未入力またはメール形式エラーの場合は、バックエンド検証に送信せず、入力欄の下に赤色のエラー表示と入力欄の赤枠表示を行う。
3. ローカル検証通過後、VISTAは入力メールがKASIKA顧客メールと一致するかを検証する。
4. メールがKASIKA顧客メールと不一致の場合、ページでエラーを表示し再試行を許可する。
5. メール検証通過後にのみ、既存VISTA顧客へのバインディング判断または新規VISTA顧客フローへの遷移が許可される。
6. メール検証段階では新規パスワードと確認パスワードの入力欄を表示しない。パスワード入力は、メール検証通過後、新規VISTA顧客の作成が必要と確認され、かつプロジェクトがアクセスパスワードを要求する場合にのみ表示する。
7. 今期は連続失敗回数の設定を個別に提供しない。異常アクセスと検証失敗はログを記録し、必要な基本の防刷戦略はシステム共通セキュリティポリシーで処理する。

### 7.2 アクセスパスワード設定

1. プロジェクト設定ページの「VISTAアクセスパスワードが必要か」スイッチがオンの場合：
   - メール検証通過後に新規VISTA顧客の作成が必要と確認された場合のみ、新規パスワードと確認パスワードを表示する。
   - システムはVISTA既存のパスワード強度ルールに基づき検証する。
   - パスワード設定成功後、VISTA顧客アカウントを作成する。
   - バインディング可能な同一メールのVISTA顧客が存在する場合、エントリーページは新規パスワードと確認パスワードの入力欄を表示してはならず、既存パスワードの設定またはリセットも行ってはならない。バインディング完了後に後続フローへ進む。
2. プロジェクト設定ページの「VISTAアクセスパスワードが必要か」スイッチがオフの場合：
   - ページは新規パスワードと確認パスワードの入力欄を表示しない。
   - メール検証通過後、バインディング可能なVISTA顧客が存在する場合はバインディングを確立し、同一メールのVISTA顧客が存在しない場合はVISTA顧客アカウントを直接作成する。
   - システムは今回のアカウントが「アクセスパスワード不要」設定のもとで作成またはバインディングされたことをログに記録する必要がある。
3. 今期はエントリーリンクによる長期無検証アクセスを採用しない。アクセスパスワードをオフにしても、プロジェクト、`kasikacid`、KASIKA顧客、メールの検証を必ず完了しなければならない。

## 8. `customer_status`の保存、タグ設定と初期権限

### 8.1 フィールド取得

初回アクセス時、VISTAはKASIKA顧客照会APIを通じて顧客情報を取得する。権限関連フィールドは今期限定で以下とする：

- `customer_id`
- `email`
- `customer_status`

その他のKASIKAフィールドはログまたは後続拡張フィールドとして保存できるが、今期は第三者フィールドマッピングページで権限ルールを設定しない。

VISTA顧客の作成またはバインディング成功後、`customer_id`、`email`、`customer_status`をKASIKA関連情報として個別に保存する必要がある。このうち`customer_status`は今期の権限変化の唯一のKASIKAソースフィールドであり、完全なKASIKAフィールドスナップショットのみに保存してはならない。

設定制約：

1. `customer_status`ステータス権限自動更新スイッチは`01-KASIKA連動設定管理.md`で定義される。
2. 初回バインディング時、このスイッチがオンでもオフでも、エントリーページフローは本章のルールに従って`customer_status`同名VISTAタグ初期化を必ず1回実行し、これに基づいて初期権限を取得しなければならない。
3. このスイッチは初回バインディング後の以降の`customer_status`変化に応じてVISTAタグと権限を自動更新するかどうかのみを制御する。
4. スイッチがオフの場合、以降の同期で新しい`customer_status`を取得しても、状態の保存と表示のみ行い、VISTAタグの自動追加、置換、削除は行わず、権限の再計算も能動的に行わず、顧客の既存タグまたは既存権限を取り消さない。
5. バインディング済みかつメール一致の顧客が再度エントリーページからアクセスする場合、エントリーページはアクセス身份の確認と遷移のみ行い、`customer_status`、タグ、権限を更新しない。

### 8.2 タグ設定ルール

1. システムはKASIKAが返却した`customer_status`フィールド値を読み取り、構造化された関連フィールドとして保存する。
2. 初回バインディング時、フィールド値が空、欠落、または解析不能の場合はVISTAタグを設定せず、口座開設をブロックしないが、「初期ステータスが空／解析不能」のログを記録する必要がある。
3. 初回バインディング時、VISTAプロジェクトに`customer_status`フィールド値と文字が同一のタグが存在する場合は、当該VISTA顧客にそのタグを必ず設定し、顧客の初期アクセス権限を初期化するために使用する。
4. 初回バインディング時、同名タグが存在しない場合、システムはタグを自動作成せず、このステータスタグを追加せず、口座開設をブロックしないが、「初期ステータスに同名タグなし」のログを記録し、設定欠落リスクとする。
5. 初回バインディング完了後、`customer_status`ステータス権限自動更新スイッチがオンの場合、以降の`customer_status`が前回保存値と一致しない場合は、システムは最新ステータスに基づいて顧客タグを更新する：新ステータスに対応する同名タグを追加し、前ステータスに対応する旧タグを削除する。
6. 初回バインディング完了後、`customer_status`ステータス権限自動更新スイッチがオフの場合、以降に取得した新しい`customer_status`は保存と表示のみ行い、VISTAタグの追加、置換、削除は行わず、権限の再計算を能動的にトリガーしない。
7. タグ設定完了後、C側顧客アクセス権限APIは`09-C側顧客アクセス権限API.md`の統一ルールに従ってリアルタイムにアクセス可能なコンテンツを返却する：タグ権限テンプレートの和集合＋個人権限の追加。

### 8.3 初期権限

1. 初回バインディング時、エントリーページフローは今回の`customer_status`タグ初期化結果に基づいて初期アクセス権限を計算する必要があり、`customer_status`ステータス権限自動更新スイッチの影響を受けない。
2. `customer_status`同名タグが権限テンプレートにヒットした場合、システムは顧客の現在タグがヒットした権限テンプレートの和集合に基づいて初期アクセス権限を計算する。
3. タグがヒットしない、またはヒットしたタグに権限テンプレートが設定されていない場合、システムはデフォルトコンテンツを追加で付与しない。最終アクセスコンテンツは引き続き現在のタグ権限テンプレートの和集合と個人権限の追加で計算され、結果は空でもよい。
4. 初回バインディング完了後、スイッチがオフの場合、顧客の最終アクセス可能コンテンツは引き続き現在保有するタグと個人権限の追加で決定される。エントリーページへの以降のアクセスで新しい`customer_status`により権限が能動的に更新されることはない。
5. タグ設定または権限計算の失敗は、通過済みのメール検証とバインディング結果をロールバックしてはならないが、ログを記録する必要がある。

## 9. KASIKA識別Cookie

顧客がKASIKAエントリーページからアクセスする場合、VISTAはKASIKA顧客身份の確認後にKASIKA識別Cookieを書き込みまたは確認し、以降の顧客アクセス行動の報告とKASIKA閲覧履歴の帰属に使用する。

処理ルール：

1. VISTAはアクセスHostが一意のプロジェクトに解決済みで、かつKASIKA顧客検証が成功した場合のみ、KASIKA識別Cookieの書き込みまたは確認を許可する。
2. Cookie値は検証済みのKASIKA customer_id、すなわちエントリーパラメータ`kasikacid`に対応する顧客IDを使用する。
3. ブラウザに他のKASIKA顧客Cookieが既にある場合、エントリーページは現在のエントリーリンク内でKASIKA検証を通過した`kasikacid`を基準とする。
4. エントリーの`kasikacid`が欠落、形式不正、KASIKA顧客照会失敗、または返却されたcustomer_idが`kasikacid`と不一致の場合、システムはブラウザの既存Cookieを上書きしてはならない。
5. ブラウザに顧客AのVISTAログイン状態が存在するが、エントリーリンクの検証成功後に対応するのが顧客Bの場合、システムはAのログイン状態のままBのプライベートアクセスページに直接入ってはならない。VISTAログイン状態をクリアまたは切り替えるか、B顧客にログイン／本人確認フローを案内する必要がある。
6. Cookieの書き込みまたは上書き失敗は、顧客の口座開設、ログイン、アクセスをブロックしないが、アクセス統計識別の失敗またはダウングレード結果として記録する必要がある。

## 10. KASIKAへの書き戻し

顧客がKASIKAエントリーページを通じて初回口座開設と初回バインディングを完了した後、VISTAはKASIKAの2つの受入フィールドのみに書き戻す：

- `VISTAURL`：HOMEVISTAアクセスリンク。
- `VISTAPWD`：プロジェクトがアクセスパスワードの設定を要求し、顧客がパスワードを設定済みの場合、顧客の初回アクセスパスワードを書き戻す。

説明：

1. プロジェクトが「VISTAアクセスパスワードが必要か」をオフにしている場合は、アクセスパスワードフィールドを書き戻さない。
2. KASIKAエントリーページが初回バインディングを完了した後、顧客通知メールをトリガーするかどうかは`04`のKASIKA自動返信メール案に従って実行される。エントリーページフローはトリガー型KASIKA顧客タグを追加せず、シナリオメールのトリガーにも依存しない。
3. 書き戻し失敗はVISTA顧客の作成、バインディング、パスワード設定、`customer_status`保存またはタグ設定結果をロールバックせず、部分失敗として記録する必要がある。
4. VISTA顧客ID、バインディング状態、初回アクセス完了時刻、およびVISTA側の顧客氏名、メール、電話番号、会社名などの情報はKASIKAに書き戻さない。これらの情報はVISTA内のみで保存・追跡される。

## 11. フロントエンドUI

### 11.1 C側顧客向けページ

C側は今期「初回アクセス設定ページ」のみを設計し、単一ページの複数状態で読み込み、本人検証、パスワード設定、完了、異常通知をカバーする。

ページはVISTA C顧客側ページに属する：主要コンテンツを遮らない半透明ガラスで現在の操作を収容する。具体的なログインページの色、レイアウト、状態詳細はまだデザインシステムで定義されておらず、「デザインシステム補充待ち」とマークする。VISTA B管理画面のテーブル、サイドバー、設定ページのスタイルをこのページに持ち込んではならない。

| 状態 | ページ表現 | 情報表示範囲 |
| --- | --- | --- |
| 読み込み／検証中 | 確認中メッセージを表示。検証後、メール検証、ログイン遷移、またはエラー状態へ | 顧客氏名、KASIKA customer_id、権限結果を表示しない |
| 本人検証 | メール入力欄、メインボタン。ローカル検証エラー時は入力欄を赤枠にし、下部に赤色エラー表示 | 先に未入力／形式エラーのフロントエンド検証を実施。通過後にKASIKA顧客メールとの一致を検証 |
| パスワード設定 | 新規パスワード、確認パスワード、メインボタン | メール検証通過後、新規VISTA顧客の作成が必要で、かつプロジェクトがアクセスパスワードを要求する場合のみ表示。メール入力を繰り返し表示しない |
| 設定完了／同期処理中 | 完了または処理中メッセージを表示。成功後VISTAへ遷移 | バインディング完了と初期権限が適用済みであることを表示可能。書き戻し失敗はVISTAへの遷移をブロックしない |
| 汎用エラーメッセージ | 汎用エラータイトル、説明、営業担当への連絡などの推奨アクションを表示。再試行ボタンは提供しない | 確認済みプロジェクト、顧客氏名、KASIKA customer_id、権限結果を表示しない |

読み込み、本人検証、パスワード設定の状態では、ページにプロジェクト名、顧客氏名、`kasikacid`、KASIKA顧客ID、顧客ステータス、権限結果を表示してはならない。設定完了状態では「バインディング完了」と「初期アクセス設定が適用済み」など、身份情報を含まない結果のみを表示できる。

異常は一律で汎用エラーメッセージ状態に移行し、エラー種別ごとに独立ページを分割せず、再検証／再試行ボタンを提供しない。システム404ページは、プロジェクト未連動、`kasikacid`不正、顧客取得不能などのリンクレベル失敗を収容するために使用される。この種のエラーは、顧客が現在のページで繰り返しクリックしても結果は変わらない。

モバイル端末適応要件：

1. エントリーページはスマートフォンからのアクセスに対応する必要があり、最低375px幅で検収する。
2. モバイル端末は単一列構造を使用する：ブランド／プロジェクト状態情報を上に、現在の操作領域を下に配置する。
3. メール、パスワード、確認パスワード、主要ボタンは利用可能な幅を全面使用する必要がある。メールとパスワードを同一状態で同時に表示せず、ボタンと入力欄の高さは44px以上とする。
4. プロジェクト状態、エラーメッセージ、完了進捗は横方向に溢れてはならない。長いプロジェクト名や説明文は改行する必要がある。
5. モバイル端末でも同一ページの複数状態を使用し、モバイル専用の独立ページを追加しない。

### 11.2 B側プロジェクト設定UI

既存のKASIKA設定ページに読み取り専用フィールド`VISTAプロジェクトエントリーURL`とコピーボタンを追加し、「VISTAアクセスパスワードが必要か」スイッチ、および`customer_status`ステータス権限自動更新スイッチを追加する。コピーされるURLは現在のプロジェクトの一意のサブドメインを使用し、具体的な`kasikacid`を含まない。コピー成功後はToastを表示する。

今期は独立設定ページ、独立有効化スイッチ、KASIKAメールテンプレートエディタ、第三者権限マッピングページのエントリー、本人検証方法、または連続失敗制限設定を追加しない。

### 11.3 顧客詳細UI

顧客詳細ページは`05B-顧客詳細ページ.md`に従ってKASIKA連動モジュールを表示する。KASIKAにバインディング済みの顧客は、基本情報領域でメールが読み取り専用となる。タグと権限の調整は`05B-顧客詳細ページ.md`、`05C-顧客権限ページ.md`に従い、KASIKAバインディング関係は権限タブで編集しない。

## 12. ユーザーユースケース

### ユースケース 12.1 バインディング済みかつメール一致

- 前提：`kasikacid`がVISTA顧客にバインディング済みで、KASIKAが返却するメールがバインディングされたVISTA顧客メールと同一。
- 操作：顧客がKASIKAメールのエントリーをクリック。
- 期待結果：
  - システムがプロジェクト、`kasikacid`、KASIKA顧客検証を通過。
  - KASIKA Cookieを書き込みまたは確認。
  - VISTAホームページのログインまたはアクセスフローへ遷移。
  - 顧客を重複作成せず、パスワードを重複設定しない。
  - KASIKAフィールドスナップショット、`customer_status`タグまたは権限を更新しない。

### ユースケース 12.2 未バインディングだが同一メールのVISTA顧客が存在

- 前提：`kasikacid`未バインディング。VISTAに同一メールの顧客が存在。
- 操作：顧客がエントリーをクリックし、メール検証を通過。
- 期待結果：
  - 当該VISTA顧客がKASIKA未バインディングで、KASIKA再バインディング禁止のマーク付けもない場合は、バインディングを確立。
  - 当該VISTA顧客がアクティブ化済みかどうかに関わらず、パスワード設定を表示せず、既存パスワードを設定またはリセットしない。
  - バインディング確立後、`customer_status`同名タグ初期化を必ず1回実行し、その後Cookie書き込みとログインまたはアクセスフローへ進む。
  - 当該VISTA顧客が他のKASIKA customer_idにバインディング済み、KASIKA再バインディング禁止のマーク付け済み、または削除後に復旧されたが管理画面でのガバナンス未実施の履歴顧客に該当する場合は、エラーを表示し、自動バインディング変更またはバインディング復旧を行わない。

### ユースケース 12.2A 未バインディングかつ同一メールの顧客が存在せず、プロジェクトがアクセスパスワードを要求

- 前提：`kasikacid`未バインディング。VISTAに同一メールの顧客が存在しない。プロジェクトが「VISTAアクセスパスワードが必要か」をオンにしている。
- 操作：顧客がエントリーをクリックし、先にメールを入力して検証を通過。
- 期待結果：
  - メール検証段階ではメール入力のみ表示し、パスワード入力を表示しない。
  - 新規VISTA顧客の作成が必要と確認された後、ページがパスワード設定状態へ遷移。
  - 顧客がパスワード設定に成功後、システムがVISTA顧客を作成し`kasikacid`をバインディング。

### ユースケース 12.2B 未バインディングかつ同一メールの顧客が存在せず、プロジェクトがアクセスパスワードを要求しない

- 前提：`kasikacid`未バインディング。VISTAに同一メールの顧客が存在しない。プロジェクトが「VISTAアクセスパスワードが必要か」をオフにしている。
- 操作：顧客がエントリーをクリックし、メールを入力して検証を通過。
- 期待結果：
  - 全フローでパスワード入力を表示しない。
  - メール検証通過後、新規VISTA顧客の作成が必要と確認された場合、システムがVISTA顧客を直接作成し`kasikacid`をバインディング。

### ユースケース 12.3 バインディング済みだがメール不一致

- 前提：`kasikacid`がVISTA顧客にバインディング済みだが、KASIKAが返却するメールがバインディングされたVISTA顧客メールと異なる。
- 操作：顧客がエントリーをクリック。
- 期待結果：
  - ページが汎用エラーを表示。
  - 口座開設またはログインの継続を許可しない。
  - VISTA顧客メールを上書きせず、自動バインディング変更も行わない。

### ユースケース 12.4 未バインディングかつ同一メールの顧客が存在しない

- 前提：`kasikacid`未バインディング。VISTAに同一メールの顧客が存在しない。
- 操作：顧客がエントリーをクリックし、メールを入力。新規VISTA顧客の作成が必要と確認され、かつプロジェクトがアクセスパスワードを要求する場合は、パスワード設定へ進む。
- 期待結果：
  - メール形式が正当かつKASIKA顧客メールと一致した後、システムがVISTA顧客を作成し`kasikacid`をバインディング。
  - システムがKASIKAの`customer_status`を保存。
  - `customer_status`ステータス権限自動更新スイッチがオンでもオフでも、システムは`customer_status`に基づいて同名VISTAタグ初期化を必ず1回実行し、これに基づいて初期権限を取得する必要がある。
  - 成功後、KASIKA Cookieを書き込み、VISTAホームページのログインまたはアクセスフローへ遷移。

### ユースケース 12.5 `customer_status`に同名タグがない

- 前提：KASIKAが`customer_status`フィールド値を返却するが、VISTAプロジェクトに同名タグが存在しない。
- 操作：顧客がメール検証と口座開設を完了。
- 期待結果：
  - 初回バインディング時、`customer_status`ステータス権限自動更新スイッチがオンでもオフでも、システムはタグを自動作成せず、このステータスタグを追加しない。
  - 初回バインディング完了後、以降の`customer_status`が変化し、ステータス権限自動更新スイッチがオンの場合は、以降の更新ルールに従って旧ステータスタグを処理する。スイッチがオフの場合は、状態の保存のみ行い、タグを追加せず、前ステータスタグを削除せず、権限を能動的に更新しない。
  - 口座開設フローはブロックされない。
  - 顧客はこのフィールドにより権限が追加されない。既存の他のタグまたは個人権限の追加がある場合は既存設定に従って計算し、なければアクセスコンテンツの結果は空でもよい。

## 13. 検証基準

- プロジェクトがKASIKAと未連動、プロジェクトが識別不能、またはAPI KEYが不完全な場合、KASIKAエントリーページはシステム404ページへ遷移する。
- `kasikacid`が欠落、空、形式不正、重複競合、または互換パラメータ`cid`の値と競合する場合、システム404ページへ遷移する。
- KASIKA顧客照会失敗、顧客不存在、または返却されたcustomer_idが`kasikacid`と不一致の場合、システム404ページへ遷移する。
- バインディング済みかつメール一致の場合、KASIKA Cookieを書き込み／確認した後、VISTAホームページのログインまたはアクセスフローへ遷移し、KASIKAフィールドスナップショット、`customer_status`タグまたは権限を更新しない。
- 未バインディングだが同一メールのVISTA顧客が存在する場合、当該VISTA顧客がKASIKA未バインディング、再バインディング禁止のマーク付けなし、かつ削除後に復旧されたが管理画面でのガバナンス未実施の履歴顧客に該当しない場合のみ自動バインディングする。バインディング可能なVISTA顧客が存在する場合はパスワード設定を表示せず、既存パスワードを設定またはリセットしない。他のKASIKA customer_idにバインディング済み、再バインディング禁止のマーク付け済み、または削除復旧リスクがある場合はエラーを表示する。
- バインディング済みだがVISTA顧客メールがKASIKA顧客メールと異なる場合はエラーを表示し、自動バインディング変更を行わない。
- バインディング関係が存在せず、VISTAに同一メールの顧客が存在しない場合は、新規バインディングフローを継続する。
- 顧客が入力するメールは、形式が正当かつKASIKA顧客メールと一致することを同時に満たす必要がある。
- 「VISTAアクセスパスワードが必要か」スイッチは、新規VISTA顧客の作成が必要な場合のみ有効となる：オンの場合はメール検証通過後にパスワード設定へ進み、オフの場合はパスワード設定をスキップする。バインディング可能なVISTA顧客が存在する場合は、スイッチの状態に関わらずパスワード設定をスキップする。
- VISTA顧客の作成またはバインディング後、システムは`customer_status`フィールドを保存する。
- 初回バインディング時、システムは`customer_status`フィールドに基づいて同名VISTAタグ初期化を必ず1回実行し初期権限を計算する必要があり、`customer_status`ステータス権限自動更新スイッチの影響を受けない。
- 初回バインディング完了後、`customer_status`ステータス権限自動更新スイッチがオンの場合、システムは以降の`customer_status`変化に応じて同名VISTAタグを更新する。同名タグがない場合はステータスタグを追加しないが、今回がステータス変化であると確認された場合は、前ステータスに対応する旧タグを削除する必要がある。
- 初回バインディング完了後、`customer_status`ステータス権限自動更新スイッチがオフの場合、システムは以降のステータス変化によりVISTAタグを追加、置換、削除せず、権限を能動的に計算せず、既存タグまたは既存権限を取り消さない。
- 初回バインディング完了後、KASIKAの`VISTAURL`と該当する場合の`VISTAPWD`のみに書き戻す。VISTA顧客ID、バインディング状態、初回アクセス完了時刻は書き戻さない。
- 成功後、KASIKA Cookieを書き込み、VISTAホームページのログインまたはアクセスフローへ遷移する。