# 00-概要とスコープ

## 改訂履歴

| 日付 | バージョン | 変更タイプ | 変更概要 | 修正者/出典 |
| --- | --- | --- | --- | --- |
| 2026-07-20 | v0.1 | 重大要件変更 | KASIKA 顧客同期情報ポップアップを削除；同期タスク統計はタスク結果ポップアップに引き継ぎ、顧客単位の結果は同期ログのバッチ顧客リストで一括確認する。 | AI（要件変更に伴う修正） |

## 1. ドキュメントの位置付け

本文書は KASIKA 第二期要件の概要 MRD であり、本期の事業背景、利用者ロール、業務シナリオ、プロダクト目標、スコープ境界、要件分割、およびリリース前の API 能力確認の結論を統一的に説明する。

後続の `01-11` 文書はすべて本稿に基づいて分割される：

- `00` は、なぜやるのか、誰が使うのか、どのシナリオで使うのか、全体連携がどのように回るのかを説明する。
- `01-11` は、それぞれ設定、タグ、権限、`customer_status` タグ設定境界、顧客画面、同期フロー、ログ、KASIKAエントリ画面、C 端の顧客アクセス権限インターフェース、およびデザイン納品を説明する。

本文書ではプロダクト要件と業務フローのみを記述し、具体的な技術実装は展開しない。KASIKA API 能力、メール変数、フィールド書込、変更検出、ページング、バッチ処理結果などの条件は、引き続き開発実測または KASIKA 公式確認を準拠とする。

## 2. 背景と課題

HOME VISTA と KASIKA は現在、それぞれ異なる業務ロールを担っている：

- KASIKA は顧客獲得、資料請求、来場予約、自動返信メール、シナリオメール、顧客経営を担当する。
- HOME VISTA はプロジェクトコンテンツへのアクセス、資料表示、顧客アクセス URL、アクセスパスワード、コンテンツ権限制御を担当する。

本期の連携で解決したいのは、KASIKA 側で発生した顧客が、どのようにスムーズに HOME VISTA に流入し、かつその後の KASIKA 顧客属性の変化に応じて HOME VISTA のアクセスコンテンツを自動調整できるようにするかである。

現在、以下の課題が存在する：

1. KASIKA 自動返信メールは即時送信されるため、VISTA の後続同期がアクセス URL とパスワードを生成するのを待てない。
2. VISTA 同期後に URL / パスワードを書き戻し、さらに KASIKA の定期メールなどで届けようとすると、初回タッチが最長 1 日遅延する可能性がある；本期は初回バインディング後に KASIKA 自動返信メール API を用いて指定の自動返信 ID をトリガーする方式に変更する。
3. KASIKA 顧客と VISTA 顧客の間には安定したバインディングが必要であり、さもなければ後続のフィールド同期、権限判定、追跡がすべてクローズドループにならない。
4. 顧客の関心間取り、来場予約、顧客ステージ、タグ、カスタムフィールドなどの情報は主に KASIKA 側に存在し、VISTA はこれらの情報を用いて適切な公開コンテンツを判断する必要がある。
5. 顧客マスターデータは KASIKA をソースとし、VISTA 側での新規追加、補完、修正は KASIKA 顧客の作成または上書きのソースとはしない。
6. 同期失敗、マッチング競合、フィールド書込失敗、権限判定失敗などは追跡可能である必要があり、管理者はどの段階で失敗したか、どの顧客に影響したか、次に何をすべきかを把握できる必要がある。

## 3. 本期の目標

本期の目標は、KASIKA の顧客体系を完全に複製することではなく、必要な顧客連携と権限連携の能力を構築することである。

本期で実現すること：

1. B 端管理者は VISTA プロジェクト内で KASIKA 連携をセルフ設定できる。
2. KASIKA 顧客は自動返信メール内の VISTA プロジェクト入口から、初回アクセス時にメールアドレス検証を行い、プロジェクト設定に応じてパスワード設定の要否を決め、VISTA 顧客を作成またはバインディングできる。
3. 顧客が KASIKA 入口画面をクリックしなくても、システムは同期フォールバックによって VISTA URL / 初期パスワードを生成し、KASIKA 自動返信メール API を通じて到達させることができる。
4. KASIKA customer_id と VISTA 顧客の間に安定したバインディングを確立する。
5. VISTA は KASIKA 顧客フィールドを読み取り、KASIKA `customer_id`、メールアドレス、`customer_status` を個別に保存し、`customer_status` フィールドに基づいて同名の VISTA タグを設定できる。
6. VISTA は顧客の現在の VISTA タグがヒットする権限テンプレートの和集合に基づき、顧客のアクセス可能コンテンツを計算できる。
7. KASIKA 顧客属性が変化した後、VISTA はフィールドスナップショットを更新できる；初回バインディング後の `customer_status` 変化時に VISTA タグとアクセス権限の自動更新を継続するかどうかは、KASIKA 連携設定画面の `customer_status` 状態権限自動更新スイッチで制御する。
8. VISTA は初回バインディング成功時にのみ、HOMEVISTA アクセス URL を KASIKA の `VISTAURL` フィールドに書き込む；プロジェクトがアクセスパスワードを有効にしている場合は、さらに初回アクセスパスワードを `VISTAPWD` フィールドに書き込む。VISTA 顧客 ID、バインディング状態、初回アクセス完了時刻、その他の VISTA 顧客マスターデータは KASIKA に一切書き戻さない；双方のバインディング情報は VISTA 内部でのみ保存・追跡する。
9. 同期、バインディング、`customer_status` タグ設定、権限判定、削除、および異常処理はすべてログで追跡可能とする。
10. 顧客詳細画面には KASIKA 連携モジュールを表示し、現在の顧客と KASIKA の関連フィールドおよび関連状態を確認できるようにする；KASIKA バインディング関係はメールアドレス読み取り専用、入口検証、権限タグ補完、ログ追跡にも関与する。本期では詳細画面に手動バインディング解除の入口は提供しない。

最終目標：

> KASIKA の顧客が HOME VISTA のコンテンツアクセス経路にスムーズに流入できるようにする；HOME VISTA が KASIKA 顧客属性に基づいて適切なアクセス権限を自動設定できるようにする；かつ初回バインディング時に HOMEVISTA アクセスリンクと、該当する場合の初回アクセスパスワードを KASIKA に書き戻し、KASIKA メール到達を支える。

## 4. 利用者ロール

| ロール | 利用シーン | 目標 |
| --- | --- | --- |
| B 端管理者 | プロジェクトリリース前の KASIKA 連携設定；リリース後の同期ログ・異常確認 | 連携の有効化、API KEY の保守、VISTA プロジェクト入口 URL のコピー、同期状態と失敗原因の確認 |
| セールスマネージャー | プロジェクト顧客管理、連携状態確認、顧客アクセス権限の適切性確認 | 顧客リスト、タグ、権限状態、ログを通じて顧客経営が正常か判断する |
| セールス担当者 | VISTA 顧客の新規追加・保守、顧客が KASIKA とバインディングされているか確認、顧客タグや権限の調整 | VISTA 顧客データを利用可能に保ち、顧客が適切な VISTA コンテンツを見られるようにする；VISTA 顧客データから KASIKA へ逆上書きは行わない |
| 顧客 | KASIKA 自動返信メールまたは後続メールから VISTA にアクセス | 初回アクセス設定を完了し、自身に適したプロジェクトコンテンツを閲覧する |
| システムタスク | 定期同期による KASIKA 顧客の同期、必要なアクセスフィールドの書戻し、権限計算、ログ記録 | 顧客バインディング、フィールドスナップショット、`customer_status` タグ設定、権限判定、制御された書戻し、異常追跡を自動実行する |

## 5. 業務シナリオ概要

### 5.1 シナリオ A：管理者が KASIKA 連携を有効化する

誰が：B 端管理者。

どのシーンで：プロジェクトに KASIKA と HOME VISTA の連携を導入しようとするとき。

何をするか：

1. KASIKA 連携設定画面に遷移する。
2. PID、4 つの API KEY、顧客一括エクスポート API 用 settingID、顧客一括インポート API 用 settingID を設定する。
3. 「VISTA アクセスパスワード要否」スイッチを確認する（デフォルトオン）。
4. VISTA プロジェクト入口 URL をコピーし、顧客に渡して KASIKA 自動返信メールテンプレートに設定してもらう。
5. その後、同一画面から同期ログに遷移し、同期結果や異常を確認する。

実現したい目標：

- VISTA プロジェクトが KASIKA API 呼出、顧客同期、フィールド読取、アクセスフィールド書戻し、KASIKA 入口画面を支える基礎能力を備える。

設計境界：

- KASIKA 入口画面の独立したスイッチは新設しない；4 つの API KEY がすべて揃い、かつ Host から一意の VISTA プロジェクトを識別できる場合、KASIKA 入口画面をサポートする。
- VISTA プロジェクト入口 URL は現在のプロジェクト固有のサブドメインを用いて VISTA プロジェクトを識別し、コピーされる URL には具体的な `kasikacid` を含まない。
- KASIKA 顧客 ID パラメータ `kasikacid` は、KASIKA メールテンプレートまたは送信メカニズムが実際の送信時に追加／挿入する。

### 5.2 シナリオ B：KASIKA 新規顧客が KASIKA 入口画面経由で VISTA にアクセスする

誰が：顧客。

どのシーンで：顧客が KASIKA 側で資料請求、来場予約、事前登録などを行い、KASIKA 自動返信メールを受信したとき。

何をするか：

1. 顧客がメール内の VISTA プロジェクト入口をクリックする。
2. VISTA がアクセス元 Host からプロジェクトと KASIKA API 設定を特定する。
3. VISTA が入口パラメータ `kasikacid` に基づき KASIKA 顧客情報を取得する。
4. 顧客が C 端初回アクセス画面で登録メールアドレスを入力し、プロジェクト設定に応じて VISTA パスワードを設定するかを決定する。
5. VISTA が顧客を作成またはアクティベートし、KASIKA customer_id をバインディングする。
6. VISTA が KASIKA フィールドスナップショットを保存し、`customer_status` に基づいて同名の VISTA タグを設定し、初期権限判定を実行する。
7. 顧客が VISTA コンテンツ画面に遷移する。

実現したい目標：

- 顧客が同期タスクや定期メールを待たず、最初のタッチ時にできるだけ早く VISTA に入れる。
- 初回入場時に KASIKA 顧客情報に基づき適切な初期コンテンツ権限を割り当てられる。

設計境界：

- C 端では「初回アクセス設定画面」のみを設計し、状態カバレッジのローディング、本人検証、オプションのパスワード設定、完了、異常を単一画面で扱い、複数画面に分割しない。
- ローディング中および汎用エラー状態では、具体的な顧客氏名、KASIKA customer_id、権限判定結果を表示してはならない。
- 本期ではメールアドレス検証のみを固定的に使用し、他の本人検証方式の設定は提供しない。

### 5.3 シナリオ C：顧客が KASIKA 入口画面をクリックしなかった場合の同期フォールバック

誰が：システムタスク、B 端管理者。

どのシーンで：顧客が KASIKA 自動返信メール内の KASIKA 入口画面をクリックしなかった場合、または同期フォールバックによるバインディング完了後に KASIKA メールで引き続きアプローチしたい場合。

何をするか：

1. 4 つの API KEY が揃っている場合、システムが定期同期を実行するか、セールスマネージャーが顧客リスト画面の「全量同期チェック」をクリックする；KASIKA 連携設定および完全な同期ログは B 端管理者のみが操作・閲覧でき、セールス担当者にはこれらの権限はいずれも付与されない。
2. システムが KASIKA から新規顧客または変更顧客を取得する。
3. 未バインディングの KASIKA 顧客に対して、システムが既存 VISTA 顧客と突合する；突合できない場合は VISTA 顧客を作成する。
4. VISTA がアクセス URL と初期パスワードを生成する。
5. VISTA がアクセス URL と初期パスワードを KASIKA 顧客フィールドに書き戻す。
6. 書込成功後、VISTA が KASIKA 自動返信メール API を呼び出し、顧客が事前に設定した自動返信 ID を渡す。
7. KASIKA 側が当該自動返信 ID に対応する自動返信テンプレートに従ってメールを送信し、メールには VISTA URL とパスワードが埋め込まれる。

実現したい目標：

- 顧客が KASIKA 入口画面をクリックしなかった場合でも、KASIKA 自動返信メールを通じて VISTA アクセス手段を取得できる。
- KASIKA 入口画面と同期フォールバックが二つの初回タッチ経路を形成する。

設計境界：

- バインディング通知は KASIKA 自動返信 ID を用いて自動返信メールをトリガーし、追加のトリガー用 KASIKA 顧客タグには依存しない。
- 顧客が既に KASIKA 入口画面経由でパスワードを設定している場合、同期フローはランダムな初期パスワードを生成して上書きしてはならない；当該顧客の初回バインディング時アクセスフィールド書戻しにおいては、顧客の現在有効なパスワードを KASIKA アクセスパスワードフィールドに書き込む。
- 本期では顧客情報同期の制御スイッチは提供しない；4 つの API KEY が揃っていない場合、同期フォールバック経路は実行されず、手動「全量同期チェック」によるフォールバックも提供されない。

### 5.4 シナリオ D：KASIKA 顧客属性同期後の VISTA 権限校正

誰が：システムタスク、セールスマネージャー、セールス担当者。

どのシーンで：KASIKA 顧客の `customer_status` が同期処理される；状態が変化した場合もあれば、VISTA 側で人手によりタグが調整された後に現在の状態に合わせて校正が必要な場合もある。

何をするか：

1. 4 つの API KEY が揃っている場合、VISTA が定期同期または全量同期チェックで最新の KASIKA 顧客フィールドを取得する。
2. システムが KASIKA フィールドスナップショットを保存し、当該顧客の KASIKA `customer_id`、メールアドレス、`customer_status` を個別に更新する。
3. システムが、個別保存された `customer_status` フィールド値と設定画面の `customer_status` 状態権限自動更新スイッチにより、同名の VISTA 顧客タグを校正するかどうかを判断する。
4. スイッチがオンの場合、当該顧客を処理するたびに現在の `customer_status` に基づき同名 VISTA タグを校正する：同名タグが存在すれば顧客が当該タグを保持していることを保証する；同名タグが存在しなければ自動的に作成せず、スキップログのみを記録する。
5. スイッチがオンで、かつ `customer_status` が旧状態から新状態に変化した場合、新状態に対応する同名タグを追加し、前の状態に対応する旧タグを削除する；スイッチがオフの場合、フィールドとログの保存のみを行い、タグや権限の能動的な更新は行わない。
6. タグ権限テンプレートが顧客の現在のタグに基づきアクセス権限を再計算する。
7. 顧客は引き続き元の VISTA アクセスリンクを使用するが、閲覧可能なコンテンツは権限変化に応じて変わり得る。

実現したい目標：

- 顧客のアクセスコンテンツが KASIKA 顧客状態の変化に追従して自動調整される。
- セールス担当者が手動で個別に権限調整するコストを低減する。

設計境界：

- 権限変化によって顧客のアクセス URL がデフォルトで変わることはない。
- 初回バインディング時には必ず一度 `customer_status` 同名タグの初期化と初期権限判定を実行する；初回バインディング以降の状態タグ校正と権限更新は、設定画面のスイッチが制御する。
- 本期では VISTA の権限結果や権限サマリを KASIKA に書き戻さない。
- 本期では VISTA から KASIKA 顧客タグを逆にメンテナンスしない。
- VISTA 側の管理者は、VISTA 本来のタグ体系に則ってタグの新規追加、編集、削除、顧客タグの調整を継続できる；これらの操作は KASIKA に書き戻さない。後続の同期では VISTA 側で現在の `customer_status` に基づく軽微な校正のみを行う。
- 4 つの API KEY が揃っていないか、KASIKA API 呼出に失敗した場合、KASIKA から顧客フィールドスナップショットを取得しないため、KASIKA 顧客状態変化に起因して VISTA タグや権限が更新されることはない。

### 5.5 シナリオ E：HOMEVISTA アクセスフィールドを KASIKA に書戻す

誰が：セールス担当者、システムタスク。

どのシーンで：KASIKA 顧客と VISTA 顧客の初回バインディングが成功し、KASIKA 側のメール／オペレーション経路が HOMEVISTA アクセスリンク、およびプロジェクトでアクセスパスワードが有効な場合の初回アクセスパスワードを取得できるようにする必要がある。

何をするか：

1. 4 つの API KEY が揃っている場合、システムが初回バインディング成功後に KASIKA の `VISTAURL` フィールドに HOMEVISTA アクセスリンクを書き込む；プロジェクトがアクセスパスワードを有効にしている場合は、さらに `VISTAPWD` フィールドに初回アクセスパスワードを書き込む。
2. 初回バインディングが完了し、アクセスフィールドの準備が整った後、KASIKA 自動返信メール API と設定画面に保存された自動返信 ID を用いて顧客通知メールをトリガーする。
3. KASIKA 入口画面経路において、プロジェクトがアクセスパスワードを要求し、かつ顧客がパスワードを自ら設定した場合、顧客の自設定パスワードを KASIKA アクセスパスワードフィールドに書き戻すことを許容する；プロジェクトがアクセスパスワード設定を無効にしている場合は、アクセスパスワードを書き戻さない。
4. VISTA 顧客 ID、バインディング状態、初回アクセス完了時刻は VISTA 内部にのみ保存し、KASIKA へは書き戻さない。初回バインディング完了後、VISTA 側の顧客データやアクセスパスワードに変更があっても、再び KASIKA に書き戻すことはない。
5. VISTA がバインディング済み顧客を削除する場合、KASIKA 側の HOMEVISTA アクセス URL およびアクセスパスワードを削除・クリアしない；VISTA 側では必ず当該顧客の有効な KASIKA バインディング関係をクリアし、削除とバインディング失効状態を記録する。
6. 本期の顧客詳細画面には手動で KASIKA バインディングを解除する手段は提供しない；万一誤ったバインディングの修正が必要な場合は、別途バックエンド処置または管理復旧要件を立てる。

実現したい目標：

- KASIKA メールおよびオペレーション経路が HOMEVISTA アクセスフィールドを利用できるようにする。
- KASIKA メールがアクセス手段を取得できるとともに、VISTA が双方の顧客バインディング関係、バインディング失効状態、アクセスフィールド処理結果を追跡可能に保つ。

設計境界：

- 4 つの API KEY が揃っていない場合、`04` 同期メインフローにおける VISTA ローカル操作は、KASIKA 顧客データの照会、作成、更新、削除またはクリアを一切行わない；KASIKA 入口画面は `08` に従い独立実行される。
- VISTA 側での顧客新規追加、メールアドレスや電話番号の補完、氏名・電話番号・会社名などの基本情報の変更は、いずれも KASIKA への顧客作成または上書きを行わない。
- VISTA による顧客削除は、KASIKA 側の過去のアクセスフィールドをクリアしないが、VISTA 側の有効な KASIKA バインディング関係はクリアし、削除後に誤って再バインディングが行われたり、旧顧客が復活した際の一対多バインディング異常を防ぐ。
- 本期では VISTA 側から KASIKA 顧客を手動で選択してバインディングする入口は提供しない。

### 5.6 シナリオ F：管理者が異常を処理し、ログを追跡する

誰が：B 端管理者、セールスマネージャー。

どのシーンで：同期、バインディング、`customer_status` タグ設定、権限判定、KASIKA 入口画面、または書戻しにおいて、失敗、競合、未処理、部分失敗が発生した場合。

何をするか：

1. 画面上に簡潔な失敗サマリと次に取るべきアクションを表示する。
2. 同期ログに、完全な失敗段階、対象、トリガーソース、結果分類、エラーコードを記録する。
3. 管理者がログに基づきソースデータの修正、バックエンドでの誤バインディング処置、設定補完を行い、またはシステム後続フローによる再チェックを待つ。

実現したい目標：

- 異常が特定可能、説明可能、追跡可能であること。
- 失敗がインターフェースエラーだけで止まらず、業務担当者が理解できるようにする。

設計境界：

- 本期ではフロントエンドからのリトライ入口は提供しない。
- 設定画面の保存成功、保存失敗、新規追加、変更、クリアは同期ログに書き込まない。
- 削除系の失敗は失敗結果と失敗原因のみを記録し、VISTA 削除結果をロールバックしない。

## 6. エンドツーエンドの業務フロー概要

### 6.1 全体連携図

```mermaid
flowchart LR
  A["B端管理者<br/>KASIKA連携設定"] --> B["KASIKA側で顧客発生<br/>資料請求 / 来場予約 / 事前登録"]
  B --> C{"顧客は自動返信メール<br/>入口をクリックしたか"}

  C -->|クリック| D["C端初回アクセス画面<br/>メール検証 + オプションパスワード設定"]
  D --> E["VISTA顧客を作成またはアクティベート<br/>KASIKA customer_id をバインディング"]
  E --> F["KASIKAフィールドスナップショット保存"]
  F --> G["customer_status に基づく同名VISTAタグ設定"]
  G --> H["タグ権限テンプレート<br/>によるアクセス権限計算"]
  H --> I["顧客がVISTAコンテンツに入る"]

  C -->|未クリック| J["定期同期 / 全量同期チェック"]
  J --> K["未バインディングのKASIKA顧客を発見"]
  K --> L["VISTAで顧客を事前作成<br/>URLと初期パスワードを生成"]
  L --> M["KASIKAフィールド書戻し<br/>自動返信IDを呼出"]
  M --> N["KASIKA自動返信メールでフォールバック到達"]
  N --> I

  B --> O["後続のKASIKA顧客属性変化"]
  O --> F

  D -.失敗.-> P["エラー表示 / ログ"]
  J -.失敗または競合.-> P
  M -.部分失敗.-> P
  H -.権限計算失敗.-> P
```

### 6.2 初回タッチの二重経路

| 経路 | トリガータイミング | 主な動作 | 目標 |
| --- | --- | --- | --- |
| KASIKA 入口画面経路 | KASIKA 自動返信メール即時送信後、顧客が入口をクリック | C 端メール検証、オプションパスワード設定、VISTA 顧客作成またはアクティベート、KASIKA customer_id バインディング、初期権限計算 | 顧客をできるだけ早く VISTA に入れる |
| 同期フォールバック経路 | 顧客が KASIKA 入口画面をクリックせず、後続の同期で未バインディング新規顧客を発見し初回バインディング | VISTA が URL / 初期パスワードを生成、初回バインディング時に KASIKA へ書戻し、KASIKA 自動返信 ID で自動返信メールをトリガー | クリックしなかった顧客も確実に到達できるようにする |

### 6.3 権限更新経路

```mermaid
flowchart LR
  A["KASIKA顧客属性変化"] --> B["VISTA同期がフィールド取得"]
  B --> C["サードパーティフィールドスナップショット保存"]
  C --> D["customer_status を読み取り"]
  D --> E["同名VISTAタグを設定"]
  E --> F["タグ権限テンプレート"]
  F --> G["最終アクセス権限を計算"]
  G --> H["顧客のアクセスコンテンツが変化"]
```

## 7. 同期ルール概要

1. 本期では統一された一つの「顧客連携同期フロー」を用い、製品機能ごとに複数の同期モジュールに分割しない。
2. バッチ同期は、KASIKA から増分または全量の顧客を取得し、VISTA 側で突合、作成、バインディング、フィールドスナップショット、`customer_status` タグ設定、権限判定を完了するために用いる。
3. 本期では VISTA 顧客マスターデータから KASIKA への同期は行わない；VISTA での顧客作成、メールアドレスや電話番号の補完、基本情報変更、顧客削除は、いずれも KASIKA 顧客の作成または上書きをトリガーしない。
4. `KASIKA -> VISTA` は顧客マスターデータの同期方向を表す；初回バインディング時のアクセスフィールド書戻しは `VISTAURL` および該当場合の `VISTAPWD` のみを含み、ログは VISTA 内部のバインディング状態と自動返信 ID 呼出結果を記録するが、これらの内部情報を KASIKA に書き込むことはなく、VISTA 顧客マスターデータの同期を意味するものでもない。
5. 本期のフロントエンドで提供する手動同期入口は、顧客リスト画面の「全量同期チェック」ボタンのみとする；このボタンは 4 つの API KEY が揃っている場合のみ利用可能とし；単一顧客の手動同期、チェックボックスによるバッチ同期、詳細画面での手動同期は提供しない。
6. 本期では VISTA 側から KASIKA 顧客を手動で選択してバインディングする入口は提供しない。
7. 自動突合の失敗、突合競合、あるいは過去顧客の事後バインディングが自動で完了できない場合は、未処理またはバインディング異常として扱い、管理者がソースデータを修正するかバックエンド処置フローを経る；本期では手動選択バインディング、再バインディング、バインディング変更の入口は提供しない。

## 8. 権限ルール概要

1. VISTA タグは本期の権限判定の中核オブジェクトである。
2. 本期の権限連携では、KASIKA `customer_status` フィールドのみを用いて同名の VISTA タグを設定する。
3. 各 VISTA タグには一つのタグ権限テンプレートを設定できる。
4. 顧客が権限テンプレートを設定されたタグを複数持つ場合、最終権限はそれらタグ権限テンプレートの和集合として計算される。
5. 単一の顧客には引き続き手動で個人アクセスコンテンツを追加できる；本期では顧客権限画面において、タグ権限テンプレートが既に付与したコンテンツを個別に削除することはできない。
6. 権限の変化は顧客のアクセス URL を変えず、その URL 背後でアクセス可能なコンテンツのみが変化する。
7. C 端の顧客アクセス権限インターフェースは、「タグ権限テンプレート和集合 + 個人権限追加」に基づき、リアルタイムにアクセス可能コンテンツを返さなければならない；顧客の個別権限のみを読み取ったり、タグテンプレート和集合を無視してはならない。
8. 間取り図とモデルルーム、コンテンツとナビゲーションメニューとの間の既存の関連ルールは引き続き有効であり、権限の由来がタグテンプレートか個人追加かによって影響を受けない。
9. `customer_status` に同名タグが存在しない、フィールドが空、設定失敗の場合は、状態タグを新たに追加しない；最終的なアクセスコンテンツは、依然として現在のタグ権限テンプレート和集合と個人権限追加に基づきリアルタイム計算され、結果が空になることもあり得る。
10. 本期では VISTA の権限結果や権限サマリを KASIKA に書き戻さない。

## 9. 画面とモジュールのスコープ

| 画面／モジュール | 本期スコープ |
| --- | --- |
| KASIKA 連携設定 | PID、4 つの API KEY、顧客一括エクスポート API 用 settingID、顧客一括インポート API 用 settingID、バインディング通知自動返信 ID、VISTA アクセスパスワード設定スイッチ、VISTA プロジェクト入口 URL 読み取り専用コピーフィールド、ヘルプ説明、同期ログ入口 |
| サードパーティフィールドマッピング / 権限マッピング | 本期はコメントアウトで保持、開発しない；入口は非表示またはコメントアウトし、B 端管理者には表示しない |
| タグ管理 | VISTA 顧客タグの新規追加、編集、削除、無効化 |
| タグ権限テンプレート | VISTA 顧客タグに対して、アクセス可能なコンテンツ権限を設定 |
| 顧客リスト | 既存リストを踏襲し、タグ表示のみ新たに追加；KASIKA 専用カラムは表示しない；4 つの API KEY が揃っている場合「全量同期チェック」ボタンを表示 |
| 顧客新規追加 | VISTA 顧客の基本情報を入力し、顧客情報モジュール下部で初期タグを選択；新規保存によって KASIKA に顧客を作成・更新しない |
| VISTA 顧客ファイルインポートと結果ポップアップ / 結果パネル | VISTA インポートによる新規追加、更新、タグ書込、失敗の結果を表示；インポート完了後、VISTA 顧客インポートを理由に KASIKA に顧客を作成・更新しない |
| 同期タスク結果ポップアップ / 同期ログ | タスク結果ポップアップはバッチ処理統計を表示；同期ログのバッチ顧客リストでは、氏名、メールアドレス、KASIKA ID、VISTA ID、統合同期結果を表示し、顧客同期詳細ポップアップは提供しない |
| 顧客詳細 / 編集 | 既存の顧客基本情報編集を踏襲；概要タブに KASIKA 連携モジュール、現在のタグ、アクセス統計を表示；KASIKA バインディング済み顧客のメールアドレスは読み取り専用 |
| 顧客権限設定 | 顧客詳細の「権限」／「編集」タブで VISTA タグ、タグ権限テンプレート連動結果、個人権限追加を編集可能；タグテンプレートが付与した権限を個別に削除することはできない；権限タブで KASIKA バインディング関係を編集しない |
| KASIKA 連携管理 - 同期ログ | B 端管理者のみが入室可能；顧客同期、フィールドスナップショット、権限計算、削除に伴うバインディング失効、有効バインディング関係クリア、および失敗明細を確認 |
| kasika入口画面 | KASIKA 入口画面を開いた後の単一画面・複数状態ページ；ローディング、本人検証、オプションパスワード設定、完了、汎用エラーをカバー |

## 10. 要件分割アウトライン

| 文書 | 引き継ぎ内容 |
| --- | --- |
| `01-KASIKA連携設定管理.md` | KASIKA 設定画面、PID/API KEY、settingID、バインディング通知自動返信 ID、VISTA アクセスパスワード設定スイッチ、VISTA プロジェクト入口 URL、クローズルール |
| `02-顧客タグ管理.md` | VISTA 顧客タグの新規追加、編集、無効化、削除、および顧客タグメンテナンス |
| `03-タグ権限テンプレート.md` | タグ権限テンプレート、テンプレート和集合計算、テンプレート影響範囲 |
| `04-統合顧客連携同期フロー.md` | `05` 顧客画面を横断する KASIKA 同期のファクトソース；KASIKA から VISTA への顧客同期、バインディング、突合、VISTA 作成、VISTA 側で追加保存する情報リスト、フィールドスナップショット、制御された書戻し、同期フォールバック、失敗処理を定義 |
| `05A-顧客リスト画面.md` | 顧客リスト、インポート結果、全量同期チェック入口、同期タスクポップアップ |
| `05B-顧客詳細画面.md` | 顧客詳細概要、ローカル編集／削除、KASIKA バインディング顧客メール読み取り専用、タグ・権限サマリ |
| `05C-顧客権限画面.md` | 顧客タグ編集、権限テンプレート合成、個人権限追加、最終権限 |
| `05D-顧客新規追加.md` | 新規 VISTA 顧客追加、初期タグ選択、新規保存境界 |
| `07-同期ログと追跡.md` | 同期ログ、エラーコード、失敗サマリ、次アクション、追跡フィールド |
| `08-KASIKA入口画面とVISTA初回アクセスアカウント開設.md` | KASIKA 自動返信メール内の KASIKA 入口画面、C 端初回アクセス、メール検証、オプションパスワード設定、KASIKA 入口画面フロー |
| `09-C端顧客アクセス権限インターフェース.md` | C 端顧客が HOME VISTA コンテンツにアクセスする際の権限インターフェース、タグテンプレート和集合、個人権限追加、フォールバックルール |
| `bak-04-サードパーティフィールドマッピングと権限判定.md` | バックアップ文書；本期ではサードパーティマッピング画面は開発せず、`customer_status` 同名タグ設定と画面入口コメントアウト境界の説明のみ保持 |

## 11. データオブジェクト概要

| データオブジェクト | 説明 |
| --- | --- |
| KASIKA 連携設定 | PID、API KEY、エクスポート / インポート settingID、バインディング通知自動返信 ID、VISTA アクセスパスワード設定スイッチ、設定保存状態 |
| VISTA プロジェクト入口 URL | VISTA プロジェクトにより生成され、KASIKA 連携設定画面に表示；プロジェクト固有のサブドメインでプロジェクトを識別し、具体的な `kasikacid` を含まず、KASIKA メール側が `kasikacid` を補完する |
| KASIKA customer_id バインディング | VISTA 顧客 ID と KASIKA customer_id のバインディング関係、バインディング状態、異常状態 |
| KASIKA 関連情報 | VISTA 側で各関連顧客向けに保存する KASIKA `customer_id`、メールアドレス、`customer_status`、バインディング状態、更新日時；顧客詳細の KASIKA 連携モジュール表示、入口検証、権限タグ補完、ログ追跡に用いる |
| VISTA 顧客 | HOME VISTA 内部の顧客データ、アクセス URL、アクセスパスワード、アクセス権限 |
| VISTA 顧客タグ | VISTA 汎用タグ、手動メンテナンスまたは `customer_status` 同名タグ設定により生成可能 |
| タグ権限テンプレート | タグに対応するアクセス可能コンテンツ権限、既存の VISTA 顧客権限設定画面がサポートするアクセス可能コンテンツオブジェクトをカバー |
| KASIKA フィールドスナップショット | KASIKA から VISTA へ同期された顧客フィールド値、フィールドソース、同期日時、バッチ |
| KASIKA 同期サマリ | 直近の同期結果、処理段階、失敗原因、次アクション、後続処理状態、ソースバッチ；同期ログ追跡に用い、顧客詳細画面には表示しない |
| `customer_status` タグ設定 | KASIKA `customer_status` フィールド値に基づき VISTA 同名タグをマッチング |
| KASIKA 再バインディング禁止 | バックエンドで誤バインディング処置時に書き込める VISTA 顧客フラグ；後続の同期、全量同期チェック、KASIKA 入口画面は当該顧客を他の KASIKA 顧客アカウントにバインディングしてはならない；本期の顧客詳細画面では書込入口を提供しない |
| KASIKA 書戻し結果 | 初回バインディング時の `VISTAURL` および該当時の `VISTAPWD` を KASIKA に書込んだ処理結果；ログには成功／失敗を記録し、アクセスパスワードの平文は表示しない；VISTA 顧客 ID、バインディング状態、初回アクセス完了時刻は書戻さない |
| 権限判定結果 | VISTA タグとタグ権限テンプレートに基づき計算された顧客の最終アクセス権限 |
| 同期タスク | システム自動トリガーまたは「全量同期チェック」によりトリガーされる同期バッチ |
| 同期ログ | 顧客同期、フィールドスナップショット、権限計算、削除に伴うバインディング失効、有効バインディング関係クリア、失敗原因を記録 |

## 12. 非目標

本期では行わないこと：

1. 内部セキュリティ管理、外部セキュアログイン、デバイス制限。
2. 第一期で完了済みの閲覧履歴／顧客アクセス行動レポート能力の再設計、再開発、再検収。
3. KASIKA 顧客フィールド体系の完全複製。
4. 連携設定画面での、運営担当者による KASIKA カスタムフィールド名の手動メンテナンス。
5. B 端でのプロジェクト単位の `application_id` 設定・編集。
6. KASIKA が HOME VISTA インターフェースを能動的に呼び出す前提。
7. API サポートのないリアルタイム KASIKA 変更プッシュ。
8. VISTA 側から KASIKA 顧客を手動選択してバインディングする入口。
9. 単一顧客の手動同期、チェックボックスによるバッチ同期、詳細画面での手動同期。
10. 長期間有効なパスワード不要アクセスリンク。
11. 入口画面での、システムが生成した平文初期パスワードの直接表示。
12. VISTA 権限結果または権限サマリの KASIKA への書戻し。
13. VISTA からの KASIKA 顧客タグの逆メンテナンス。
14. KASIKA 専用で、将来他サードパーティに再利用できない権限制御方式。
15. VISTA から KASIKA への顧客作成、または KASIKA 顧客基本情報の上書き。
16. VISTA 顧客削除に伴う KASIKA 側 HOMEVISTA アクセス URL およびアクセスパスワードの削除・クリア。
17. 本期ではサードパーティフィールドマッピング／権限マッピング画面を開発せず、入口はコメントアウトのみ保持。
18. VISTA 顧客 ID、バインディング状態、初回アクセス完了時刻の KASIKA への書戻し。

## 13. リリース前 API 能力確認結論

本期の KASIKA 連携が依存する API 能力、メール変数能力、バッチ制限、データ取得範囲、設定前提条件はすべて確認済みである。現在、未確認の API 能力リスクは残っていない。

1. KASIKA 自動返信メールは実際の送信時に KASIKA customer_id を挿入でき、`kasikacid={KASIKA顧客ID}` を形成し、`08` の KASIKA 入口画面識別に用いることができる。
2. KASIKA 自動返信メールは即時送信される；本期では KASIKA 入口画面により即時タッチを解決し、入口をクリックしなかった顧客は同期フォールバックと後続メールでカバーする。
3. `customer_custom_fields` のフィールド定義、書込検証、メール変数使用能力は確認済み；顧客側は事前に合意したとおり KASIKA カスタムフィールドとメールテンプレート設定を完了する必要がある。
4. KASIKA 自動返信メール API と自動返信 ID は初回バインディング後の顧客通知に使用可能；VISTA は指定の自動返信 ID を呼び出すのみで、メール本文や変数設定は KASIKA 側テンプレートに依存する。
5. KASIKA 顧客データ取得範囲、バッチ処理同時実行制限、処理状態返却、およびマスターデータ／フィールド定義リスト API の有無はすべて確認済み；同期実装は `04` および `07` の既定方針に従って処理する。

## 14. 改訂履歴

| 日付 | 改訂内容 |
| --- | --- |
| 2026-07-13 | KASIKA ロール権限を明確化：セールスマネージャーは手動全量同期チェックを担当；B 端管理者は連携設定と完全同期ログを担当；セールス担当者は上記操作を禁止。 |
| 2026-08-04 | 初回バインディング時に KASIKA の `VISTAURL` と該当時の `VISTAPWD` の 2 つの受け取りフィールドにのみ書戻すことを明確化；VISTA 顧客 ID、バインディング状態、初回アクセス完了時刻は VISTA 内のみ保存し、KASIKA へは書戻さない。 |