# 12-第2期テスト範囲・トレーサビリティ一覧（日本語版）

## 改訂履歴

| 日付 | バージョン | 変更タイプ | 変更概要 | 備考 |
| --- | --- | --- | --- | --- |
| 2026-08-12 | v0.1 | 新規 | 第2期正式要件に基づき、KASIKA、VISTA B、KASIKA エントリページ、VISTA C を横断するテストケース総リストフレームワークを構築。以降のテスト設計、実行、リグレッション、準出記録の唯一の基盤ディレクトリとする。 | 現時点ではテスト手順概要のみ記載、未実行。 |
| 2026-08-12 | v0.2 | 重大な要件変更 | RENO 実行版テスト手順書にアップグレード：テスト初期状態、RENO 操作、システム自動処理、メール、PASS 基準、南京側の連携境界を項目ごとに追記。 | プロトタイプや単一画面表示を実際の連携判定の代替としない。 |
| 2026-08-12 | v0.3 | 重大な要件変更 | 日本側の非専門テスター向けガイドブックに調整：業務ロジック、データ変化の説明、操作境界、待機/停止判定、異常時の引き継ぎルールを補充。 | テスターは PRD を事前に完全読了する必要なし。 |
| 2026-08-12 | v0.4 | 説明最適化 | 11使用説明書との双方向参照ナビゲーションを確立。test-jp環境情報表、画面入口索引、異常時の振り分けルールを補足し、12が完全なテストの唯一の実行手順書であることを明確化。テスターが理解する必要のない技術用語を業務用語に書き換え。 | 日本語版の元となる改訂。 |
| 2026-08-15 | v0.5 | 実行構造の最適化 | 「KASIKA 顧客を新規作成し、VISTA 初回紐付けを完了、アクセス権限を取得する」をテスト主目標とし、最小成功パスとケースごとの前提条件インデックスを追加。日本語実行版では、統合モジュール単位の説明のみに留めない。 | RENO 等の非専門テスター向けフィードバック。 |
| 2026-08-16 | v0.6 | 並行検証方法の調整 | 重複クリック同期の検証を、権限を持つ2つのアカウントが同時に同一の正常同期を発起する方式に変更。南京側で事前に同期タスクの占有状態を用意する必要はない。 | ドキュメント 13 の T13-12、T13-13 に対応。 |
| 2026-08-16 | v0.7 | 異常テスト境界の調整 | KASIKA メールの一意性を明確化。同一メールの候補競合、同一 customer_id のメール不一致、再紐付け禁止および履歴削除は、RENO が正常なページ経由で構築する必要はなく、南京側が分離環境で一括検証する。 | ドキュメント 13 では、これらの異常に対して RENO 実行カードを保持しない。 |
| 2026-08-16 | v0.8 | 削除テスト境界の調整 | 紐付け済み VISTA 顧客の削除および元エントリからの再訪は、RENO が専用テスト顧客を通常のページ操作で実施。南京側はテスト後のクリーンアップ/復元および必要なログサポートのみ担当。 | 無効リンクなど正常に構築できないエントリエラーは、引き続き南京側が管理された環境で検証。 |
| 2026-08-16 | v0.9 | ログテスト連携境界の整理 | 同期記録、照会、およびログアクセス権限の検証は、RENO が自前のアカウントと実測時間を用いて実施。アカウントまたはログエントリが不足する場合のみ南京側に対応を依頼。 | 失敗シミュレーションおよびエラー辞書は、引き続き南京側が管理された環境で検証。 |
| 2026-08-16 | v0.10 | 通常テスト連携境界の整理 | 定期同期、タグ/テンプレート、エントリ、リスト、詳細、状態変化、通常の書き戻し検証は、RENO が専用テストデータ、管理者アカウント、実レコードを用いて実施。 | 南京側は、管理された異常、安全に復元できないデータクリーンアップ、環境欠落の調査のみ対応。 |
| 2026-08-16 | v0.11 | 実行基準の同期 | 通常タグ、状態、権限、書き戻し、メール、リスト、詳細、および回帰ケースの連携欄を RENO 自主実行に同期。ケース内には、実際に管理された異常、データクリーンアップ、環境調査が必要な南京側連携のみを残す。 | ドキュメント 13 の RENO 実行カードと一致。 |
| 2026-08-16 | v0.12 | テストデータ管理境界の確認 | RENO が test-jp の全 KASIKA 顧客に対する管理権限を有することを確認。全量同期前の顧客範囲確認および未紐付けテスト顧客の処理は、RENO 自身が実施。 | 南京側に通常の全量同期用の顧客分離を要求しない。 |
| 2026-08-16 | v0.13 | 通常ケース連携の整理とメールルール修正 | ドキュメント 12 のタグ、テンプレート、エントリ、スイッチ、ロール、通常紐付けの南京側連携をさらに削除。初回アクセス招待メールのルールを「テンプレートを VISTA エントリのベース URL に配置し、KASIKA が実際の送信時に顧客の kasikacid を自動付与する」に修正。 | 管理された異常、バックエンドデータガバナンス、環境ベースラインには影響なし。 |
| 2026-08-16 | v0.14 | 権限と業務判定境界の確認 | RENO が KASIKA および VISTA の完全な操作権限を有することを確認。ただし、連携設定の業務的意味を自ら理解することは要求しない。自動応答 ID と紐付け完了通知の業務マッピングは南京側が一度説明し、RENO はそれに基づいて設定の確認、実行、判定を行う。 | 南京側が RENO に代わって操作することはない。 |
| 2026-08-16 | v0.15 | テスト開始条件の整備 | test-jp 環境情報表を「業務判定ベースラインと環境情報表」に調整し、南京側が業務標準、環境バージョン、管理対象外例外を一括提供することを明確化。RENO は自身でアカウント、顧客、メール、実際の実行記録を提供する。 | 完全な操作権限を誤って業務ルールの独自理解と記載しないこと。 |
| 2026-08-16 | v0.16 | ドキュメントの役割分担と実行可能性の最適化 | 12 はカバレッジ範囲、業務ルール、トレーサビリティ目録であり、13 こそが RENO のステップバイステップ操作マニュアルであることを明確化。入口と同期が同時に発生するケースを RENO が自然に実行できるシナリオに変更し、南京側の管理対象外例外リストから除外。 | 11 → 12 → 13 の読書順序が一致すること。 |
| 2026-08-16 | v0.17 | 用語とトレーサビリティの最適化 | RENO向けの結果用語を「期待どおり／期待どおりではない／実施または判定不可」に統一し、入口と同期が同時に発生する通常操作の境界も整理。日本語版も同じ内容に更新。 | 実際の実行は文書13に準拠する。 |

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

本チェックリストはKASIKA第2期のテスト作業における管理一覧です。以降のすべてのテストケース、テストデータ、実行記録、欠陥、回帰結果、リリース判断は、本チェックリストの1つ以上のケース番号に対応付けられている必要があります。

本チェックリストは、各テストがカバーすべき業務ルール、前提条件、自動処理、期待結果、南京側の協力境界を説明します。シナリオの漏れを確認し、問題を対応モジュールに対応付けるために使用します。**RENOが一字一句そのまま実行する操作手順書ではありません**。RENOの実際の操作、記録、例外の引き継ぎには、統一して『13-RENOテスト実行手順書（日本語版）』を使用します。

### 1.1 このマニュアルは誰のために使い、どのように使うか

このチェックリストは、HOMEVISTAの内部ルールを理解しておらず、第2期要件も完全には読んでいないRENOテスト担当者にも向けています。テスト時にシステムがどう処理すべきかを推測する必要はありません。以下の順序で読んで実行してください：

1. まず『11-KASIKA×HOMEVISTA連携操作ガイド（日本語版）』の「テスター向け閲覧と実行ナビゲーション」、および第1、4、5、8、9章を読んでください。完全な要件書を読む必要はありません。
2. 次に、このチェックリストの第 2 章「テスト前に必ず理解すべき業務ロジック」と第 6 章「実行前共通管理表」を読み、各テストの種類がなぜ必要なのか、いつ開始できるのかを理解してください。
3. 最後に 13 を開き、その中の T13-01 から T13-29 の順序で実行してください。明確に RENO 向けに書かれた操作のみを行い、「システム自動」または「南京側協力」と記載されたステップは操作しないでください。
4. 完了後、13 の「期待どおりの結果」に従って項目ごとに確認してください。未達、表示されるべきページが表示されない、届くべきメールが届かない、または記載されていない自動動作が発生した場合は、「期待どおりではない」または「実施または判定不可」と記録し、資料を自分で修正しないでください。
5. 13 の実行番号、顧客番号、開始時間、結果、スクリーンショット、メール件名を記録してください。南京側の操作が必要な場合はその項目を一時停止し、南京側の返信を待つことを「期待どおりではない」と記録しないでください。

### 1.2 テストにおける3つの結果

| 結果 | いつ使用するか | RENOの対応 |
| --- | --- | --- |
| 期待どおり | 記載されたすべての期待結果が確認され、予期しない副作用がない場合。 | スクリーンショット/メールの証跡を保存し、完了時間を記録する。 |
| 期待どおりではない | 手順に従ってRENOで可能な操作を完了したが、システムの結果が期待どおりではない場合。 | 繰り返し操作を停止し、時間、顧客番号、ページ/メールのスクリーンショット、実施済みの手順を記録し、南京側に確認を依頼する。 |
| 実施または判定不可 | アカウント、テストデータ、テンプレート/IDの業務説明、test-jpタイムゾーン、または南京側の管理対象バックエンド操作が不足しており、開始または判定ができない場合。 | 推測せず、設定を変更しない。記録に不足項目を明記し、南京側の補充を待つ。 |

### 1.3 最初のテストはどこから始めるか：新規顧客の最小成功パス

第2期の中心は、単独の画面を確認することではなく、**新規に作成したKASIKAテスト顧客**が正しいVISTAアクセス権限を取得できるようにすることです。初回は異常・削除・複雑な権限の組み合わせから始めず、まず次表の最小経路を完了してください。この経路が期待どおりである場合にのみ、T05～T11の変更、異常、復旧の検証に進みます。

| 順序 | RENO の操作 | 満たされている必要がある条件 | システムが自動的に完了すること | RENO が確認する場所 |
| --- | --- | --- | --- | --- |
| M0 | test-jp 環境情報表を開き、専用の新規顧客 A を選択する。 | T00 でバージョン、アカウント、テストメール、入口招待テンプレート、紐付け完了通知テンプレート／ID の業務説明、test-jp タイムゾーンが確認済みであること；T01 の連携設定が保存され、保存時刻が記録されていること；A が VISTA に存在せず、未紐付けであること。 | 顧客・紐付け・メールは発生しない。 | KASIKA 顧客プロフィール、VISTA B 顧客リスト、テストメールのいずれもベースラインスクリーンショットを保存する。 |
| M1 | KASIKA から A へ初回の入口招待メールを送信し、メール内リンクから入口ページを開く。 | メールにプロジェクト入口 URL と A の `kasikacid` が含まれること；プロジェクトで KASIKA 連携が有効になっていること。 | 入口ページがプロジェクトと A を識別し、メール確認を待つ。 | メールの件名、リンク、入口ページのプロジェクト識別結果。 |
| M2 | A が KASIKA に登録したメールアドレスを入力する；プロジェクトでパスワードが有効な場合は、ページ設定に従い初回パスワードを設定する。 | メールアドレスが KASIKA の記録と一致すること；A と同じメールアドレスで直接紐付けできる既存の VISTA 顧客がいないこと。 | VISTA 顧客を新規作成し、初回紐付けを確立する；A の `customer_status` に応じて同名のタグとコンテンツ権限を初期化する。 | VISTA B 顧客、紐付けサマリー、タグ／最終権限；VISTA C のアクセス可能なコンテンツ。 |
| M3 | 入口を再度訪問せず、今回の処理完了を待つ。 | 初回紐付けが成功していること；アクセスリンクが準備済みであること；パスワードが有効な場合は、初回パスワードが使用可能であること。 | KASIKA に `VISTAURL` を書き戻し、該当する場合は `VISTAPWD` を書き戻す；紐付け完了通知メール ID を呼び出して通知を送信する。 | KASIKA カスタムフィールド、テストメールの件名／本文／時刻、VISTA B 同期ログ。 |
| M4 | A でログインするか VISTA C を開き、リストに従って許可されたコンテンツと許可されていないコンテンツを確認する。 | タグテンプレートと共有可能なコンテンツが T02 で準備完了であること。 | 最終権限にのみ従ってコンテンツを表示する；再紐付け・再書き込み・再メール送信は行わない。 | VISTA C のページと VISTA B の最終権限が一致すること。 |

> M0～M4のいずれかの条件が欠落している場合、「実施または判定不可」と記録し、そのステップをスキップして状態変化、削除、並行、または失敗回復のテストケースを実行しないでください。同期フォールバックのメインパスはT04で別の新規顧客Bを使用して繰り返し検証します。Bは入口招待メールを開かないでください。

## 2. テスト前に必ず理解すべきビジネスロジック

### 2.1 四つの端末の分担：誰が何をするか

| 位置 | 非技術的な言葉での理解 |
| --- | --- |
| KASIKA | 顧客情報とメールの提供元。顧客のメールアドレス、顧客番号、現在のステータスはここが基準です。 |
| VISTA B | 管理者が使用するバックエンド。ここで連携設定、顧客の確認、タグとコンテンツのアクセス範囲の設定、同期結果の確認を行います。 |
| KASIKA 入口ページ | 顧客がKASIKAメールから開く確認ページ。まず「これは誰か」を確認し、既存のVISTA顧客を利用するか、新規顧客を作成するかを決定します。 |
| VISTA C | 顧客が実際に目にするプロジェクト内容ページ。その顧客が現在閲覧を許可されているコンテンツのみを表示し、KASIKA内部資料や権限理由は表示しません。 |

### 2.2 顧客データのフロー

連携は「**KASIKAが顧客の事実を提供し、VISTAがVISTA内のアクセス内容を決定する**」と捉えることができます。

| データ | 主なソース/管理元 | 同期後VISTAでの処理 | テスト時に確認すべき点 |
| --- | --- | --- | --- |
| KASIKA顧客番号、メールアドレス、`customer_status` | KASIKA | 識別、紐付け、ステータス保存、同名タグを追加するかどうかの決定に使用。VISTAでの手動編集がKASIKAへ逆に反映されることはありません。 | KASIKAの元の値、VISTAの紐付け/ステータス概要、同期ログ。 |
| VISTA 顧客、VISTA タグ、個人権限 | VISTA | VISTA は KASIKA のステータスに基づいてタグを補完し、タグテンプレートと個人追加権限で内容を決定します。 | B 端タグ／最終権限と C 端表示内容が一致しているか。 |
| `VISTAURL` | VISTA 初回紐付け時に生成 | 初回紐付け成功後に KASIKA へ書き戻し、顧客がメールから VISTA に入りやすくします。以降、毎回の同期で書き直すわけではありません。 | KASIKA カスタムフィールドに正しいリンクがあるか。 |
| `VISTAPWD` | VISTA 初回紐付け時に生成、または顧客が設定 | プロジェクトでアクセスパスワードが有効な場合のみ初回に書き戻します。顧客が後で VISTA でパスワードを変更しても、KASIKA には書き戻しません。 | 適用シーンでのみ出現するか。ログでパスワードの平文を確認できないこと。 |

### 2.3 顧客を初めて VISTA に導く 2 つの経路

| 経路 | 誰が先にアクションを起こすか | システムがその後何をするか | テストで最も誤判定しやすいポイント |
| --- | --- | --- | --- |
| 顧客が自ら入る | KASIKA が先に「初回アクセス招待メール」を送信。顧客が `kasikacid` を含むリンクをクリック。 | 入口ページでメールを確認し、システムは既存の同一メールアドレスの顧客を使用、または VISTA 顧客を新規作成し、初回紐付けを完了します。 | 「初回アクセス招待メール」は紐付け完了通知ではありません。招待メールを受け取っただけでは、まだ紐付けされていません。 |
| システム同期によるフォールバック | 顧客が入口をクリックしない。管理者が手動で全量同期、またはシステムが定期同期のタイミングに到達。 | システムが KASIKA から顧客を取得し、VISTA 顧客をマッチング／新規作成して初回紐付けを行います。 | RENO が同期を実行していないのに自動で発生した場合、必ずしも異常ではありません。トリガー時間とログを確認し、定期同期かどうかを判断する必要があります。 |

### 2.4 初回紐付け後、なぜシステムは2通の異なる性質のメールを書き戻し・送信するのか

| メール/動作 | なぜ発生するのか | 発生すべきでない場合 |
| --- | --- | --- |
| 初回アクセス招待メール | KASIKA の相談・予約・登録などの運用ルールにより、顧客が自主的に入口ページへアクセスするよう招待する。 | これを VISTA の紐付け完了の証拠とみなしてはならない。 |
| `VISTAURL` / 該当する場合は `VISTAPWD` の書き戻し | 初回紐付け完了後、KASIKA の顧客プロフィールに VISTA のアクセス方法を持たせるため。 | 紐付け済み顧客の再アクセス、その後のステータス変更、または通常のプロフィール変更時には繰り返し書き戻すべきではない。 |
| 紐付け完了通知メール | 初回紐付けと必要なアクセス方法の準備が完了した後、VISTA が KASIKA の設定済み自動返信 ID を呼び出して送信する。 | 紐付け未完了時、紐付け済み顧客の再アクセス時、または単なるステータス変更時には繰り返し送信すべきではない。 |

### 2.5 顧客ステータスが表示可能なコンテンツを変える理由

KASIKAの `customer_status` は、今期においてVISTAのコンテンツアクセス範囲に自動的に影響を与える唯一のKASIKAフィールドです。初回紐付け時、システムはVISTA内の同名タグを検索し、見つかった場合はそのタグを顧客に付与します。タグの背後にある「権限テンプレート」が表示可能なコンテンツを決定します。顧客が複数のタグを持つ場合、コンテンツは和集合となり、人為的に追加された個人権限も積み重ねられます。一致するタグやテンプレートがない場合、システムは権限を拡大するよりむしろコンテンツを少なく表示することを選びます。

初回紐付け後のステータス変更が引き続き自動的にタグやコンテンツを調整するかどうかは、VISTA Bの「ステータス権限自動更新」スイッチに依存します。オンにすると最新のステータスに基づいて校正し、オフにすると新しいステータスを保存してログを残すだけで、コンテンツは自動的に変更されません。

### 2.6 自ら処理しない異常

以下の状況はRENO操作のエラーを示すものではありませんが、自ら削除・再紐付け・繰り返し再試行してはいけません：メールアドレスの不一致、1つのメールアドレスが複数の候補に対応する、すでに他のKASIKA顧客に紐付けされている、削除された顧客が再び出現する、KASIKAが元の顧客を見つけられない、書き戻し・メール送信に失敗する。現象を記録して南京側に引き渡してください。システムログは発生したステップを説明する役割を担い、一般のテスターは技術エラーコードを理解する必要はありません。

### 2.7 カバレッジ側と責務

| 端 | 本リストにおけるテストの注目点 |
| --- | --- |
| KASIKA 管理端 | 連携認可情報、顧客情報、受付フィールド、メールテンプレート、自動返信、および一括処理結果。 |
| VISTA B | 連携設定、タグ・権限テンプレート、顧客管理、同期トリガー、異常処理、ログ・ロール権限。 |
| KASIKA 入口ページ | KASIKA メールから `kasikacid` を取得した後のプロジェクト識別、顧客検証、アカウント作成・連携の振り分け、エラー状態。 |
| VISTA C | 顧客のログインまたはアクセス後のコンテンツ権限読み取り、アクセス制限の表示、変更後の実際の適用状況。 |

### 2.8 テスト原則

1. 単一エンドページの検証は、クロスエンドのクローズドループ検証の代わりにはならない：作成、紐付け、状態、権限、または書き戻しに関わるケースでは、最終的にデータとページ表示が一致していることを必ず確認する必要がある。
2. KASIKAは実際の連携対象である。プロトタイプ画面やページ構築の通過は事前確認としてのみ有効であり、そのケースを合格とマークすることはできない。
3. 失敗からの回復、繰り返し操作、または同バッチの顧客で異なる結果が出た場合は毎回、最終的な業務結果を確認し、重複顧客、重複紐付け、誤った権限、またはアクセス方法の書き戻し漏れを見逃さないようにする。
4. ページをリフレッシュした直後にまだ古い結果が表示されている場合、自分でシステムエラーと判断しないこと。ケース内の「リフレッシュ／再ログイン／南京側の確認待ち」操作を行った後に判定する。具体的なリフレッシュ待機時間は、南京側がテスト環境情報表で説明する。

### 2.9 テスト中に表示されるシステム名

以下の名称は、RENOが正しい設定や記録を見つけるための補助であり、システム内部の実装を理解する必要はない。テスト時には「正しく入力されているか、期待どおりの結果が生成されているか」のみを確認すること。

| ページや記録に表示される可能性がある名称 | 本マニュアルでの簡潔な呼称 | RENOが理解する必要があること |
| --- | --- | --- |
| API KEY、Secret Key | KASIKA 連携認証情報 | 管理者が保存する4項目の認証情報です。コピー・スクリーンショット・メールでの平文送信はしないでください。 |
| settingID | KASIKA インポート／エクスポート設定番号 | システムが顧客をどこから読み取り、アクセスリンクをどこに書き込むかを認識させます。番号が管理者から提供されたものかを確認するだけでOKです。 |
| `自動返信ID` | 紐付け完了通知メール番号 | 「紐付け完了通知メール」のテンプレートを指します。初回アクセス招待メールではありません。 |
| Host | プロジェクトアクセスドメイン | 顧客がメールのリンクから開くプロジェクトのアドレスを指します。アドレスが正しくない場合、入口ページはプロジェクトを識別できません。 |
| Cookie | ブラウザ識別記録 | システムが今回メールから入った顧客を識別するのに役立ちます。書き込みに失敗した場合はシステムが記録するため、RENO側での手動対応は不要です。 |
| フィールドスナップショット、process_id | 同期プロセス記録、KASIKA処理番号 | 南京側が同期ログで追跡するためだけのものです。RENOが読み取ったり判断する必要はありません。 |
| 並行処理、タスクロック、冪等性、補償 | 重複操作防止、失敗後の継続処理 | 同じ操作を繰り返しクリックしたり、途中で失敗して復旧する場合でも、システムが顧客を重複作成・紐付け・メール送信しないようにします。 |

### 2.10 業務説明を11で再確認する必要がある場合

| 12 で遭遇した問題 | 11 の章を再確認 | PRD を読み返す必要がない理由 |
| --- | --- | --- |
| KASIKA、VISTA B、入口ページ、VISTA C がそれぞれ何をするのかわからない | 第 1 章 | 運営用語で双方の役割分担と顧客ジャーニーを説明済み。 |
| メール確認後に紐付けが確立される理由がわからない | 第 4 章 | 能動的な紐付け、既存の同一メール顧客、初回紐付け後のシステム動作を説明済み。 |
| ステータスによってコンテンツが増減する理由がわからない | 第 5 章 | 「ステータス → 同名タグ → 権限テンプレート → コンテンツ」の関係とスイッチの差異を説明済み。 |
| 初回招待メールと紐付け完了通知が異なる理由がわからない | 第 2.5、4.3、7.2～7.3 節 | 送信元、トリガータイミング、アクセスリンク/パスワードフィールド、重複送信の境界を説明済み。 |
| 競合、削除、送信失敗が発生した場合の対処方法がわからない | 第 6.4、第 8 章 | 自己での再紐付け/削除をしないこと、記録・引き継ぎが必要な情報を説明済み。 |

## 3. 業務フローモジュール概要

| モジュール | 業務目標 | 関連端末 |
| --- | --- | --- |
| T00 | テスト環境、メール、テストデータの制御可能性 | KASIKA、VISTA B、入口ページ、VISTA C |
| T01 | 連携環境の開通と設定の有効化 | KASIKA、VISTA B |
| T02 | タグ、権限テンプレート、共有可能なコンテンツの管理 | VISTA B、VISTA C |
| T03 | KASIKA メール入口の初回アクセスとアカウント作成紐付け | KASIKA、入口ページ、VISTA B、VISTA C |
| T04 | 入口をクリックしなかった顧客の同期フォールバックと初回紐付け | KASIKA、VISTA B、VISTA C |
| T05 | `customer_status` からタグとアクセス権限への継続的な連動 | KASIKA、VISTA B、VISTA C |
| T06 | VISTA 顧客管理と手動権限調整の境界 | VISTA B、VISTA C |
| T07 | 初回紐付け後のKASIKA書き戻しと自動返信 | KASIKA、VISTA B |
| T08 | VISTA Cのコンテンツアクセスと権限の実際の有効化 | VISTA C、VISTA B |
| T09 | 削除、紐付け異常、および手動データガバナンス | VISTA B、エントリページ、VISTA C |
| T10 | 同期ログ、エラーメッセージ、ロール権限と監査 | VISTA B |
| T11 | 重複操作と失敗復旧後の結果の正確性 | KASIKA、VISTA B、エントリページ、VISTA C |
| T12 | リリース前の全フロー回帰と運用可用性 | 4つの場所 |

### 3.1 各モジュールのビジネスロジックに関するヒント

| モジュール実行前に理解すること | この一連のケースで何を証明するか | 実施後に確認すべきデータ変化 |
| --- | --- | --- |
| T00 テスト制御 | まずテスト環境、自動同期時間、メール、顧客データを予測可能な状態にする。そうしないと、システムが「自ら動作したかどうか」を判断できない。 | テスト記録のみ生成し、顧客の作成・紐付けは行わない。 |
| T01 連携設定 | VISTA は正しい認可とパラメータを取得して初めて、KASIKA の顧客を読み取るか、紐付け完了通知を送信できる。 | 設定の保存自体は、顧客同期ログ・紐付け・メールを生成しない。 |
| T02 タグとテンプレート | タグは「顧客がどの段階・グループに属するか」のマークであり、テンプレートは「そのマークでどのコンテンツを閲覧できるか」のルールである。 | VISTA のアクセスルールのみ変更し、KASIKA の顧客プロフィールは変更しない。 |
| T03 導線初回アクセス | 顧客が KASIKA のメールから自らアクセスする場合、システムはまずメールアドレスを検証し、他人のコンテンツが別の人に開放されることを防ぐ。 | 初回成功時に1対1の紐付けを確立し、適用時にはアクセス方法を書き戻して紐付け完了通知を送信する。 |
| T04 同期フォールバック | 顧客が導線メールをクリックしなくても、システムはその顧客を見逃してはならない。同期により、KASIKA で取得可能な顧客と VISTA を一つずつ照合する。 | 新規顧客は作成・紐付けされる可能性がある。既に紐付け済みで変更のない顧客は、重複作成・書き戻し・メール送信を行わない。 |
| T05 ステータス権限制御 | KASIKA の顧客ステータスにより、VISTA は段階的に異なるコンテンツを開放できるが、同名のタグとテンプレートが存在する場合のみ有効となる。 | 主な変化は VISTA のタグ・最終権限・C 端コンテンツであり、KASIKA のステータスは変更しない。 |
| T06 手動管理の境界 | 運用担当者は VISTA 独自のタグと個人権限を管理できるが、VISTA を使用して KASIKA の顧客情報を上書きしたり、独自に紐付けを変更したりすることはできない。 | VISTA 内のデータとコンテンツ範囲のみ変更する。 |
| T07 書き戻しと通知 | 書き戻しと紐付け完了通知は「初回紐付けの準備が完了した」場合のみ対象で、顧客に導線やパスワードがない事態を防ぐために使用する。 | KASIKA は URL・該当パスワードフィールドのみ更新し、以降の通常更新では重複しない。 |
| T08 C 端アクセス | 顧客が最終的に何を閲覧できるかは、現在のタグ・テンプレートの和集合に個人の追加分を加えたものに依存し、メールを受信したかどうかには依存しない。 | C 端の閲覧可能コンテンツのみ変更・読み取りし、KASIKA の顧客更新は生成しない。 |
| T09 削除と異常 | 誤って紐付けが拡大するのを避けるため、削除・衝突時に KASIKA の元データを自動修復・削除しないこと。追跡可能性は必ず保持すること。 | VISTA の有効な紐付けをクリーンアップし、履歴を残すことは可能。KASIKA に書き込まれた URL・パスワードは空にしない。 |
| T10 ログとロール | ログは「システムが自動で何を行ったか」を説明するために使用されるが、完全なログは管理者のみに開放される。 | 顧客の業務データは変更せず、追跡可能性と権限境界のみを検証する。 |
| T11 重複操作と失敗リカバリ | 同じ顧客またはタスクが重複してトリガーされた場合、システムは最終的に正しい結果を1つだけ保持する。 | 失敗リカバリ後は未完了のステップのみを続行し、顧客作成・紐付け・書き戻し・送信を重複して行わない。 |
| T12 リリース前リグレッション | 実際のメイン経路を使用して、すべての工程が繋がっても正しいことを証明する。特定のページだけを見るのではない。 | KASIKA、VISTA B、エントリーページ、VISTA C、およびメール証跡が相互に説明できること。 |

## 4. テストケース一覧

### T01 連携環境の開通と設定の有効化

| 番号 | テストケース | テスト手順概要 |
| --- | --- | --- |
| T01-01 | 完全連携設定の有効化 | KASIKAで利用可能なプロジェクトと管理者提供の連携認可情報、2つのインポート／エクスポート設定番号、および紐付け完了通知メール番号を準備する；B端管理者が保存後、連携ステータスとプロジェクト入口リンクの利用可能性を確認する。 |
| T01-02 | 不完全または不正な設定のブロック | 主要パラメータがそれぞれ不足、誤入力、または認証失効の場合、顧客照会、同期、入口ページのリアルタイム検証を開始できないことを確認し、理解可能な処理プロンプトを表示する。 |
| T01-03 | 設定編集と保存の失敗 | 既存設定の保存、設定の変更、変更のキャンセル、および保存失敗のシミュレーションを行い、有効な設定が誤って上書きされず、後続業務が最終保存値に従って実行されることを確認する。 |
| T01-04 | 2つの業務スイッチ | 「アクセスパスワード設定」と「ステータス権限自動更新」をそれぞれオン、オフ、再オンにし、二次確認、リスク提示、およびその後の初回紐付け／ステータス更新動作が一貫していることを確認する。 |
| T01-05 | 読み取り専用情報のコピーとメール組み立て | プロジェクト入口URL、`VISTAURL`、`VISTAPWD`などの読み取り専用情報をコピーし、KASIKAメールテンプレートで入口リンクを組み立て、顧客パラメータが正しく渡されることを確認する。 |
| T01-06 | ロール別アクセス設定ページ | 管理者、営業マネージャー、営業担当者としてそれぞれ設定ページに入り、設定提出を試み、権限を持つロールのみが表示・変更できることを確認する。 |

### T02 タグ、権限テンプレート、共有コンテンツのガバナンス

| 番号 | テストケース | テスト手順概要 |
| --- | --- | --- |
| T02-01 | タグの全ライフサイクル | 新規追加、重複名のブロック、編集、無効化、削除を行い、リスト、関連顧客、関連テンプレートの表示が各ルールに従うことを確認する。 |
| T02-02 | タグ権限テンプレートの作成と編集 | タグページからテンプレートに入り、1つ以上のタグにアクセス可能なコンテンツを設定し、保存後にテンプレートとタグの関連関係を確認する。 |
| T02-03 | テンプレート権限の和集合 | 顧客に複数のテンプレート付きタグを設定し、最終的なアクセス可能なコンテンツがテンプレートの和集合で計算され、互いに上書きされないことを確認する。 |
| T02-04 | 共有可能コンテンツの審査制限 | 未審査の共有可能コンテンツをテンプレートに追加しようとし、コンテンツの共有資格が取り消された後にテンプレートと顧客の最終権限を再確認する。 |
| T02-05 | テンプレート保存の即時影響 | 既存テンプレートを変更後、影響を受けるすべての顧客の権限結果とC側で実際に表示されるコンテンツを確認する。 |
| T02-06 | テンプレートなしと空権限の境界 | 権限テンプレートなしのタグ、空テンプレート、タグなしの顧客を使用し、意図しないコンテンツの開放がないことを確認する。 |

### T03 KASIKAメール入口の初回アクセスとアカウント作成紐付け

| 番号 | テストケース | テスト手順概要 |
| --- | --- | --- |
| T03-01 | メール入口からプロジェクト識別 | KASIKA から初回アクセスでメールの入口を開き、プロジェクトのアクセスドメイン、メール内の顧客番号、KASIKA 顧客がすべて識別されることを確認してから後続フローに進む。 |
| T03-02 | 紐付け済みかつメールアドレス一致 | 紐付け済みの顧客で入口にアクセスし、VISTA に入れることを確認し、重複作成、重複パスワード設定要求、初回紐付けデータの重複更新が行われないことを確認する。 |
| T03-03 | 未紐付けだが同一メールの VISTA 顧客が紐付け可能 | 未紐付けの KASIKA 顧客と、同一メールで未紐付けの VISTA 顧客を使用し、メール本人確認完了後に紐付けが確立され、パスワード設定がスキップされることを確認する。 |
| T03-04 | 新規顧客かつアクセスパスワード有効 | 同一メールの VISTA 顧客がいない KASIKA 顧客を使用し、メール検証とパスワード設定を完了し、新規作成、紐付け、初期権限、VISTA への入り口の一連のフローを確認する。 |
| T03-05 | 新規顧客かつアクセスパスワード無効 | プロジェクトのアクセスパスワード設定を無効にして新規顧客の入口フローを進め、パスワードが表示・生成されないが、プロジェクト・顧客・メール検証はスキップ不可であることを確認する。 |
| T03-06 | メール検証失敗 | KASIKA 顧客と一致しない、形式不正、または空のメールを入力し、作成・紐付け・書き戻しが行われず、顧客の機密情報も漏洩しないことを確認する。 |
| T03-07 | 紐付け競合と再紐付け禁止 | 紐付け済みだがメールが異なるケース、同一メールの候補が他者に紐付け済み、複数候補、削除済み復元リスク、再紐付け禁止マークをカバーし、入口が自動で紐付け変更や新規作成を行わないことを確認する。 |
| T03-08 | 入口ページエラー状態 | プロジェクトアドレス無効、KASIKA顧客を一時的に確認できない、顧客が存在しない、ブラウザ識別記録が保存されていないなどのケースをカバーし、ページのプロンプト、継続可能範囲、記録が正しいかを確認する。 |
| T03-09 | 同一顧客の繰り返しアクセス | アカウント作成完了前後に同じメールリンクを複数回開く、または複数のブラウザタブを開く場合、重複アカウント、紐付け、パスワード書き込み、権限記録が発生しないことを確認する。 |

### T04 入口をクリックしていない顧客の同期フォールバックと初回紐付け

| 番号 | テストケース | テスト手順概要 |
| --- | --- | --- |
| T04-01 | 手動全量同期チェック | 権限のあるロールが顧客リストから全量同期をトリガーし、現在のチェック項目に依存せず、追跡可能なバッチ結果が生成されることを確認する。 |
| T04-02 | スケジュール同期トリガー | 完全な構成下で定義されたスケジュールアンカーに従って待機またはトリガー時点への到達をシミュレートし、システムが顧客集合を取得してバッチ記録を形成することを確認する。 |
| T04-03 | 既存VISTA顧客との同期マッチング | 未紐付けのKASIKA顧客が、ユニークで紐付け可能な同一メールアドレスのVISTA顧客とマッチすることを確認し、紐付け、フィールド保存、権限初期化、その後の書き戻しチェーンを確認する。 |
| T04-04 | 同期新規作成 VISTA 顧客 | VISTA に存在しない KASIKA 顧客を使用して同期し、顧客作成、初回紐付け、必要アクセスフィールド準備、権限初期化を確認する。 |
| T04-05 | 自動処理すべきでない VISTA 顧客 | VISTA のみに存在し、KASIKA 対応関係がない顧客を準備し、同期が勝手に削除、書き換え、誤った関係の作成を行わないことを確認する。 |
| T04-06 | 同期変更なし | 完全に同期済みでフィールド変更がない顧客に対して再度チェックを実行し、結果が変更なしに分類され、業務データが重複生成されないことを確認する。 |
| T04-07 | バッチ部分成功 | 同一バッチで成功可能、マッチング競合、外部呼び出し失敗の顧客を同時に準備し、成功項目が保持され、失敗項目が追跡可能で全体ロールバックが発生しないことを確認する。 |
| T04-08 | 権限なしロール同期ブロック | 営業担当者がページエントリの表示、呼び出し、バイパスを試みて同期をトリガーし、ページと実際の機能の両方がブロックされることを確認する。 |

### T05 `customer_status` からタグおよびアクセス権限への継続的連動

| 番号 | テストケース | テストステップ概要 |
| --- | --- | --- |
| T05-01 | 初回紐付け状態初期化 | 初回エントリー紐付けと同期フォールバックの2経路で有効な `customer_status` をそれぞれ提供し、同名タグ、テンプレート権限、およびレコードがすべて初期化されていることを確認する。 |
| T05-02 | 後続状態変更の自動更新 | 自動更新を有効にした後、KASIKA 顧客状態を変更し同期をトリガーし、旧状態タグの調整、新状態タグ、権限計算、および C 端コンテンツが同期更新されることを確認する。 |
| T05-03 | 自動更新オフ | 自動更新をオフにしてから KASIKA 状態を変更し、構造化状態とログは更新されるが、タグや権限は自動変更されないことを確認する。 |
| T05-04 | 同名タグなし | VISTA に同名タグが存在しない状態値を提供し、状態レコードが保持され、追跡可能なスキップ結果が得られ、誤って権限が付与されないことを確認する。 |
| T05-05 | 状態タグ部分更新失敗 | 新タグが追加されたが旧タグが未削除、またはタグ更新が未完了の状況をシミュレートし、復旧後に未完了ステップのみ処理され、最終タグ結果に基づいて権限が再計算されることを確認する。 |
| T05-06 | 状態切り戻しと複数回変更 | 複数回の状態切り替え後にタグ、テンプレート権限、ログ、および C 端コンテンツを確認し、履歴状態の残留による権限超過がないことを確認する。 |

### T06 VISTA 顧客管理と手動権限調整の境界

| 番号 | テストケース | テスト手順概要 |
| --- | --- | --- |
| T06-01 | 顧客リストと連動ステータス表示 | 異なる紐付け状態、タグ、同期結果でリストを確認し、今期許可されている情報のみが表示され、完全なKASIKAスナップショットやログ詳細がリストに露出しないことを確認する。 |
| T06-02 | 顧客詳細のKASIKA情報境界 | 紐付け済み、未紐付け、異常な顧客詳細を開き、表示される連動サマリーが正しいことを確認し、今期許可されていない手動での紐付け解除、変更紐付け、パスワード閲覧が提供されないことを確認する。 |
| T06-03 | 手動タグと個人権限の追加 | 顧客権限ページでVISTAタグを追加/削除し、個人権限を追加し、それらがタグテンプレートとの和集合の関係およびC側効果を確認する。 |
| T06-04 | 個人設定でテンプレート権限を差し引かない | タグテンプレートで付与されたコンテンツを顧客レベルで除外しようとし、個人権限でテンプレート権限を相殺できないルールを確認する。 |
| T06-05 | 顧客プロフィールのローカル編集境界 | VISTAの独自プロフィールを編集し、KASIKAの主要フィールドを変更しようとし、VISTAの手動入力がKASIKAの顧客事実を逆に上書きしないことを確認する。 |

### T07 初回紐付け後のKASIKA書き戻しと自動返信

| 番号 | テストケース | テスト手順概要 |
| --- | --- | --- |
| T07-01 | 初回紐付け時のアクセスフィールド書き戻し | 入口新規作成、入口での既存顧客紐付け、同期新規作成、同期での既存顧客紐付けの適用経路において、`VISTAURL` と該当する場合の `VISTAPWD` のみが書き戻されることを確認する。 |
| T07-02 | 書き戻しフィールドの境界 | KASIKA 側のフィールドとログを確認し、VISTA 顧客 ID、紐付け状態、初回訪問完了時間が書き戻されないこと、またパスワードが平文でログに記録されないことを確認する。 |
| T07-03 | パスワードスイッチと書き戻しの差異 | パスワードスイッチがオンの場合とオフの場合それぞれで初回紐付けを完了し、`VISTAPWD` の生成、書き込み、非書き込みのロジックを確認する。 |
| T07-04 | アクセス方法書き戻し部分失敗後の継続処理 | アクセスリンクまたはパスワードフィールドが単独で失敗した場合、全て失敗した後に復旧した場合をシミュレーションし、失敗したフィールドのみを処理し、成功済みフィールドの重複作成、紐付け、書き換えが行われないことを確認する。 |
| T07-05 | 自動返信送信 | 初回紐付けとアクセスフィールド準備完了後、設定済みの自動返信 ID に基づいて KASIKA メールがトリガーされることを確認し、メールが実際に受け持つフィールドを検査する。 |
| T07-06 | 自動返信欠落または送信失敗 | 自動返信 ID が欠落している場合や送信に失敗した場合、紐付けと権限がロールバックされないこと、失敗が追跡可能であり、以降は送信段階のみが処理されることを確認する。 |

### T08 VISTA C コンテンツアクセスと権限の実際の有効性

| 番号 | テストケース | テスト手順概要 |
| --- | --- | --- |
| T08-01 | 権限ありコンテンツアクセス | 異なるタグテンプレートと個人追加権限を持つ顧客がC側に入り、実際にアクセス可能なコンテンツがB端の最終権限と一致することを確認する。 |
| T08-02 | 権限なし・空権限アクセス | 権限なし、テンプレートが空、または権限が既に回収された顧客が制限されたコンテンツにアクセスし、表示されないか、開くことが許可されないことを確認する。 |
| T08-03 | 権限変更後の再アクセス | B端でテンプレート、タグ、個人追加権限、またはステータスを変更した後、再びC側にアクセスして最終的な効果を確認する。キャッシュが実装されている場合、その実際の有効メカニズムと期限を記録する。 |
| T08-04 | 複数タグと個人権限の組み合わせ | 複数の権限ソースを組み合わせて異なるコンテンツにアクセスし、C側が読み取るのが最終的な合成権限であり、単一のタグではないことを確認する。 |
| T08-05 | 旧セッションと複数タブ | 権限が回収された、顧客が削除された、または紐付け異常が発生した後、ログイン済みセッション、ページ更新、新しいタブを使用して再アクセスし、古いページ状態による越権アクセスが発生しないことを確認する。 |

### T09 削除、紐付け異常、および手動データガバナンス

| 编号 | テストケース | テスト手順概要 |
| --- | --- | --- |
| T09-01 | 未紐付けのVISTA顧客を削除 | 未紐付けの顧客を削除し、通常削除、権限無効化、ログ境界を確認する。 |
| T09-02 | 紐付け済みのVISTA顧客を削除 | 紐付け済みの顧客を削除し、VISTAの有効な紐付け関係のみがクリーンアップされることを確認する。KASIKA顧客および書き込み済みのアクセスフィールドは削除またはクリアされない。 |
| T09-03 | 削除後のエントリ再アクセス | 元のKASIKAメールエントリを使用して削除済み顧客に再アクセスし、元の紐付けが自動的に復元されないこと、他の顧客に紐付けされないこと、および規定の異常処理に入ることを確認する。 |
| T09-04 | KASIKA顧客の疑似削除 | KASIKAで紐付け済み顧客を削除した後、同期またはエントリアクセスをトリガーし、VISTAがローカルデータ、元の関連情報、権限履歴を保持し、疑似削除/紐付け異常レコードが形成されることを確認する。 |
| T09-05 | 誤紐付けのバックエンド処理 | 誤紐付け、メール不一致、紐付け競合などのシナリオに対して、承認済みのバックエンドデータガバナンスを実行し、処理前後の関係、再紐付け禁止マーク、権限再計算、監査がすべて追跡可能であることを確認する。 |
| T09-06 | 削除/処理失敗 | 削除または誤紐付け処理の失敗をシミュレートし、失敗理由のみが記録され、ログページに要件と矛盾する直接再試行や自動復元が提供されないことを確認する。 |

### T10 同期ログ、エラーメッセージ、ロール権限と監査

| 番号 | テストケース | テスト手順概要 |
| --- | --- | --- |
| T10-01 | バッチログと顧客レベル結果 | 手動、定期、部分成功バッチについて、集計、顧客リスト、および3種類のフロント結果（成功、変化なし、失敗）の対応関係を確認する。 |
| T10-02 | エラー辞書の一貫性 | 重要な失敗段階でエラーを発生させ、同期タスク結果、バッチリスト、顧客詳細連動サマリー、ログ詳細が統一されたエラーコード、サマリー、および次のアクションを使用しているかを横断的に確認する。 |
| T10-03 | 失敗段階と後続処理ステータス | クエリ、マッチング、作成、紐付け、フィールド書き込み、スナップショット、ステータスラベル、権限、書き戻し、自動返信、エントリへのアクセス失敗をカバーし、ログが失敗段階と後続処理範囲を特定できることを確認する。 |
| T10-04 | 機密情報の保護 | ページとログを確認し、連動認可情報、完全なシステム通信内容、ブラウザ識別記録、またはHOMEVISTAパスワードの平文が表示されないことを確認する。 |
| T10-05 | ログアクセスロール | 管理者、営業マネージャー、営業担当者として同期ログエントリと実際のデータ読み取り機能にアクセスし、B端管理者のみが完全なログを閲覧できることを確認する。 |
| T10-06 | ログクエリと非対象 | 定義された時間範囲クエリを検証する。今期はログエクスポート、サイト内/メール失敗通知、顧客同期詳細ポップアップなどの除外された機能がないことを確認する。 |

### T11 繰り返し操作と失敗復旧後の結果の正確性

| 番号 | テストケース | テスト手順概要 |
| --- | --- | --- |
| T11-01 | 同一プロジェクトでの同期の再発行 | 同期処理中に異なるロールまたは入口から再度同期を発行し、2回目の処理が作成されず、追跡可能な結果が保持されることを確認する。 |
| T11-02 | KASIKA レート制限と既存タスク処理中 | 呼び出し制限または KASIKA 同種タスク処理中の結果を受信し、盲目的に再提出せず、返された情報に基づいて後続の確認根拠を保持する。 |
| T11-03 | 作成/紐付け未完了後の継続処理 | 作成、紐付け保存、同期記録保存、権限計算などのプロセスで失敗後に復旧し、未完了部分のみを継続し、重複顧客、重複紐付け、重複権限記録を生成しないことを確認する。 |
| T11-04 | アクセス方式の書き戻しと送信未完了後の継続処理 | アクセス方式の書き戻しまたは自動返信の失敗後に復旧し、リンク/パスワードを再生成せず、成功済みフィールドを重複書き込みせず、成功済みメールを再送しないことを確認する。 |
| T11-05 | 入口と同期の競合 | 同一 KASIKA 顧客に対して入口でのアカウント作成とバックグラウンド同期が同時に発生した場合、最終的に追跡可能な VISTA 顧客と有効な紐付け関係が1つだけ形成されることを確認する。 |
| T11-06 | 4箇所の結果照合 | 成功、部分失敗後に復旧済み、変化なしの顧客について、KASIKA 顧客情報、VISTA B タグ/権限/ログ、入口ステータス、VISTA C の実際のアクセス結果を逐一比較する。 |

### T12 リリース前全フロー回帰と運用可用性

| 番号 | テストケース | テスト手順概要 |
| --- | --- | --- |
| T12-01 | 2つの初回タッチメイン経路回帰 | 実在のテスト顧客を使用し、「メール入口からの初回アクセス」と「入口未クリック後のフォールバック同期」をそれぞれ完了し、KASIKA 設定から VISTA C コンテンツアクセスまで全経路を照合する。 |
| T12-02 | ステータス駆動コンテンツ解放回帰 | 同一テスト顧客の KASIKA `customer_status` を変更し、B 端タグと権限、C 端コンテンツ範囲、および監査記録がクローズドループを構成することを確認する。 |
| T12-03 | 運用日常チェックプロセス | 運用担当者の実際のアクションに従い、設定状態、メールリンク、単一顧客連携状態、同期ログ、および異常引き継ぎ情報が日常調査を完了するのに十分か確認する。 |
| T12-04 | 回帰範囲確認 | 設定、同期、入口、タグテンプレート、権限、書き戻し、またはログ問題を修正するたびに、本チェックリストに基づいて影響を受けるモジュールを特定し、関連するメイン経路および異常系テストケースの回帰を完了する。 |

## 5. 今後の詳細化と実行ルール

1. 詳細化の順序としては、まずT01、T02の環境と権限の基盤を完了し、その後T03/T04の2つの初回接触メイン導線を実行し、続いてT05からT11を実行し、最後にT12で準出結論を出す。
2. 各テストケースの詳細化時には、少なくとも以下を補完する：テストデータ、前提条件、操作手順、期待どおりの結果、期待どおりではない結果、エビデンスリンク/スクリーンショット、実行日、欠陥番号、回帰ステータス。
3. 実際のKASIKA環境、設定可能なプロジェクト、各ロールのアカウント、制御可能な顧客ステータス/メール/自動返信データは、T01からT12の実行を開始するための必須条件である；いずれかが欠けている場合、ページ確認のみ可能であり、実際の連携を通じた合格とマークすることはできない。
4. ビジネスルールの競合が発生した場合、`00-総覧と範囲.md`、`04-統一顧客連携同期フロー.md`、`07-同期ログと追跡.md`、`08-KASIKAエントリページとVISTA初回アクセスアカウント作成.md`、`09-C側顧客アクセス権限インターフェース.md` の現在の正式内容を基準とする；これらのルールを変更する必要がある場合、まず要件を更新し、本チェックリストへの影響範囲を評価すること。

## 6. RENO 実行前共通管理表

### 6.1 テストデータとリセットルール

1. 各作成・紐付け・書き戻し・メール送信を行うユースケースは、必ず独立したテスト顧客（例：`REN0-T03-04-01`）を使用すること。同一顧客が入口紐付けと同期補完の初回紐付け検証を同時に担ってはならない。
2. 実行前に、RENO は KASIKA 顧客番号、メールアドレス、`customer_status`、KASIKA 登録時間、VISTA 顧客の存在有無・紐付け有無、タグ、個人権限、KASIKA の `VISTAURL`/`VISTAPWD` フィールド、および現在の受信トレイ状態を記録する。
3. 「未紐付け」または「未作成」状態が必要なユースケースでは、ページデータの削除による自己リセットは認められない。南京側で事前に確認し、管理されたクリーンアップを完了させるか、新しい隔離テスト顧客を提供すること。削除済み紐付け顧客は履歴紐付けや再紐付け禁止などの影響を残すため、新品同様の顧客として再利用できない。
4. メールに関わるユースケースでは、テスト用メールアドレスのみ使用を許可する。RENO は各操作前に受信トレイ内の既存メールを記録し、履歴メールを今回のトリガー結果と誤判定しないようにする。

### 6.2 自動同期とメールの判定ルール

| 項目 | RENO の判定方法 |
| --- | --- |
| 定期同期 | 連携設定を保存した後、システムはその保存時刻を起点として、1時間ごとに自動チェックを行います。RENOは直近の正しい保存時刻とtest-jpタイムゾーンを記録し、少なくとも1つの完全な周期を待ちます。自然な正時や顧客作成時刻で推測しないでください。 |
| 手動同期 | B端管理者または営業マネージャーのみが「顧客リスト → 全量同期チェック」でトリガーします。処理範囲はKASIKAが現在取得可能な全顧客であり、リストで選択した顧客ではありません。 |
| 同期の相互排他 | 同じプロジェクトでは、同時に1つの同期のみ処理されます。処理中は再度クリックしないでください。手動操作時には「kasikaデータを同期中です。しばらくしてからお試しください」と表示されます。 |
| 初回アクセス招待メール | KASIKAの相談、予約、登録などの運用ルールによって送信されます。メールにはプロジェクトの入口URLと該当顧客の`kasikacid`が必ず含まれている必要があります。その目的は顧客に入口ページを開いてもらうことだけで、VISTA紐付け完了後の自動通知ではありません。テンプレート名とトリガールールはRENO/KASIKA側がテスト記録に記入します。 |
| 紐付け完了通知メール | 初回紐付け時のみ、アクセスリンクの準備が完了し、「紐付け完了通知メール番号」が設定されている場合に、システムがKASIKAに通知して送信します。紐付け済みの顧客が再度アクセスした場合、その後のステータス変更、または通常のプロフィール変更では再送信されません。 |
| `7a87c2addf` | 現在の正式な要件では、そのテンプレート名やtest-jp設定の帰属は記録されていません。南京側は、これが「紐付け通知自動返信ID」であるかどうか、対応するテンプレート名、トリガー条件、有効状態、受信者、変数、期待される内容を一度に説明する必要があります。RENOはその後、KASIKA/VISTA設定で照合します。確認が完了するまで、このIDのメール内容を検証するすべてのテストケースは「実施または判定不可」として記録され、「期待どおり」とは判定できません。 |

### 6.3 実行記録フィールド

各実行の後、ケース番号に続けて記録します：テスト顧客、開始/終了時刻、設定保存時刻、同期トリガー方法（入口/手動/定期/失敗後の継続処理）、メールの実際の件名と送信時刻、KASIKAスクリーンショット、VISTA Bスクリーンショット、VISTA Cスクリーンショット、同期ログ番号、結論（期待どおり／期待どおりではない／実施または判定不可）、問題番号、南京担当者、および処理結果。

### 6.4 test-jp 業務判定基準と環境情報表

RENO は完全な操作権限を有するが、連携設定やシステム自動処理の業務意味を自ら推測する必要はない。南京側が一度に業務判定基準を記入する。RENO は自身でアカウント、顧客、保存時間、実績実行記録を記入する。未記入の南京側項目に対応するテストは「実施または判定不可」と記録しなければならない。

| 項目 | 提供元 | RENO の使用方法 |
| --- | --- | --- |
| test-jp バージョン、デプロイ時間、四端 URL | 南京側が一度に説明 | 現在テストしているシステムのバージョンと、四端へのアクセス経路を確認する。 |
| KASIKA/VISTA ロールアカウントと権限 | RENO | 自身の完全権限アカウントとロール境界テストアカウントを使用して実行する。 |
| テスト顧客プールとテストメール | RENO | ケース番号に応じて使用し、前後の状態を記録する。ケース間での初回紐付け顧客の再利用は行わない。 |
| 設定最終保存時刻、使用タイムゾーン | RENO が正しく連携設定を保存するたびに記録 | これのみに基づいて定期同期を待機または判断し、自然な正時で推測しない。 |
| 初回アクセス招待テンプレート名、トリガールール、テストメール | RENO | T03 の能動的な入口経路に使用され、紐付け完了通知として扱わない。 |
| 紐付け完了通知テンプレート名、実際の `自動返信ID`、有効状態、受信者、トリガー条件、期待内容 | 南京側が一度説明し、RENO が設定を照合 | T03/T04/T07 に使用；`7a87c2addf` がその ID であるか、および正しさの判定方法を明確にする必要がある。 |
| 管理対象外異常、バックグラウンドデータガバナンスと担当者 | 南京側が一度説明 | 誰が失敗を注入できるか、誤紐付けの処理、安全に再利用できないデータの復旧を明示する。 |
| 異常提出チャネル、担当者、期待される応答方法 | 南京側が一度説明 | 結果が期待どおりではない、または実施または判定不可の場合に使用し、自ら業務データを変更しない。 |

### 6.5 画面エントリと操作境界のインデックス

| テストモジュール | RENO が操作を開始する場所 | RENO が自ら操作すべきでない事項 |
| --- | --- | --- |
| T00 | 南京側が提供するtest-jpアドレス、アカウント、テスト環境情報表。 | 本番環境設定、テストデータのリセット、バックエンドログ権限の開放。 |
| T01 | VISTA B「プロジェクト設定 → KASIKA連携設定管理」；KASIKAの連携認可、メールテンプレート、受付フィールド設定ページ。 | 実際の本番認可情報を使用するか、未認可時に既存設定の保存・変更を行う。 |
| T02 | VISTA B「タグ管理 → タグ編集／権限編集」。 | 本番コンテンツの共有資格を回収するか、使用中の本番タグを削除する。 |
| T03 | KASIKAテストメール受信トレイのエントリーリンク；VISTA Cエントリーページ。 | 顧客番号を直接連結する、他の顧客のブラウザログイン状態を変更する、または他人に代わってメールを確認する。 |
| T04 | VISTA B「顧客リスト → 全量同期チェック」；または環境情報表に従って定期同期を待つ。 | 一括影響範囲を把握せずに全量同期を実行する、または同時にタスクを繰り返しトリガーする。 |
| T05～T08 | KASIKAテスト顧客ステータス／メールページ；VISTA Bタグ、顧客詳細／権限ページ；VISTA Cコンテンツページ。 | VISTA手動資料でKASIKA資料を上書きする、または個人設定でテンプレートが付与した権限を差し引く。 |
| T09～T11 | VISTA B顧客詳細、プロジェクト設定 → KASIKA連携設定管理 → 同期ログ。 | 紐付け解除／再構築、KASIKA顧客の削除、エラー紐付けの処理、模擬失敗の手配；すべて南京側の授権担当者が実行する。 |
| T12 | T00～T11で確認済みのエントリーとテスト顧客に基づき、エンドツーエンド回帰を実行する。 | バージョン、設定、テンプレート、テストデータを凍結せずにリリース結論を出す。 |

### 6.6 期待どおりではない、実行または判定不能、および業務上の疑問の引き継ぎルール

| RENO が確認した状況 | 記録区分 | RENO が提出すべき内容 | 南京側の後続対応 |
| --- | --- | --- | --- |
| 手順どおり完了したが、結果が「期待どおりの結果」と一致しない | 期待どおりではない | 用例番号、顧客番号、時刻、操作手順、画面/メールのスクリーンショット、同期ログの要約。 | システム障害、設定問題、またはデータ問題を判断し、処理結果を返却する。 |
| テストアカウント、テンプレート/ID、同期時点、テスト顧客、またはバックエンド権限が不足している | 実施または判定不可 | 不足している具体的な項目と、誰が提供する必要があるか。 | 環境情報表を補充するか、権限操作を手配する。 |
| ルール自体が合理的か不明。例：「ステータス変更後に保持すべき内容」 | 業務疑問（期待どおりではないとは判定しない） | シナリオ、顧客ステータス、確認したい内容の範囲。 | プロダクト側がルールを確認する；確認前はテスト内で独自に期待値を設定しない。 |
| メールアドレスの衝突、誤った紐付け、削除後の再出現などの異常 | 期待どおりではない、または実施または判定不可。「期待どおりの結果」に基づき判定 | 顧客番号、メールアドレスの要約、発生時刻、画面とログの要約；繰り返し操作しないこと。 | 管理者/技術サポートがバックエンドデータガバナンスフローに従って処理する。 |

## 7. テスト範囲の明細とトレーサビリティの根拠

以下では、各テスト種別が何をカバーすべきかを説明し、『13-RENOテスト実行手順書（日本語版）』に業務ルールの漏れがないかを照合しやすくします。各列は日方要求の①から⑦をカバーします。RENOは13から離れて本章だけを単独で運用してはなりません。特に断りがない限り、南京側の協力とは、制御された異常・障害シミュレーション、RENOが安全に復旧できないデータクレンジング、環境バージョンと基本設定の確認、およびRENOでは操作できないバックエンド機能を指します。

### T00 テスト環境、メール、テストデータの制御可能性（新規）

| テストケース | 前提状態 | RENO：KASIKA 操作 | RENO：VISTA 操作 | システム自動処理とメール | 期待どおりの結果 | 南京側の協力 |
| --- | --- | --- | --- | --- | --- |
| T00-01 テスト環境ベースライン確認 | test-jp にテスト対象バージョンがデプロイ済み。RENO は自前の KASIKA/VISTA アカウントでログイン可能。 | プロジェクト、テストメールボックス、メールテンプレートが存在するプロジェクトを確認。顧客は作成しない。 | プロジェクトバージョン、KASIKA 設定状態、および4つのエンドポイントのアクセスURLを確認。 | 同期、書き戻し、メールは発生しないこと。 | テスト環境、バージョン、アカウント、プロジェクト、および4つのエンドポイントの URL が記録され、一致している。 | 必須1回：バージョン番号、デプロイ時間、4つのエンドポイントのアドレス、基本連携設定の正確性、test-jp のタイムゾーンを提供。 |
| T00-02 定期同期の可観測性 | KASIKA 設定が完全に保存されている。 | 新規顧客は作成しない。 | RENO は設定の最終保存時刻、現在処理中の同期の有無、同期ログの入り口を記録する。 | システムは保存時刻を起点に、1時間ごとに自動チェックする。自然な正時を仮定しない。 | RENO は保存時刻とタイムゾーンに基づいて観測ウィンドウを計算し、管理者同期記録を通じてトリガーされたかどうかを確認できる。 | なし。ログの入り口が欠落している場合は南京側に提出して処理。 |
| T00-03 2種類のメールと自動返信 ID マッピング | KASIKA に初回アクセス招待テンプレートと紐付け完了通知テンプレートがある。 | RENO は各テンプレート名、トリガールール、変数、有効状態、および `7a87c2addf` の実際の帰属先を記録する。 | B 側に保存されている紐付け通知の自動返信 ID を照合する。 | 招待メールは KASIKA の運用ルールにより送信される。紐付け完了通知は、初回紐付け後に VISTA が ID を呼び出してのみ送信される。 | 2種類のメールは、件名、トリガー者、トリガー時間、変数によって明確に区別できる。ID が未確認の場合は、関連テストをブロックする。 | 必須1回：南京側が `7a87c2addf` の業務用途、テンプレート、トリガー条件、受信者、期待される内容を説明。RENO は自身で設定とテスト受信トレイを確認して検証。 |
| T00-04 テスト顧客プールとリセット検証 | RENO は自身で再利用しない KASIKA/VISTA テスト顧客プールを準備する。 | 各人の KASIKA ID、メールアドレス、状態、フィールド、既存メールを確認。 | 各人が VISTA に存在するか/紐付けされているか、タグ、権限、ログイン状態を確認。 | 自動リセットは行われないこと。削除/紐付け解除の影響は記録しなければならない。 | 各初回紐付け/障害/削除のテストケースに独立したサンプルがあり、リセット後の状態が証明可能である。 | T09-02 の専用削除テストは RENO が正常に実行。それ以外は、ページ上の削除による新規顧客リセットの代替を禁止する。削除履歴や制御された異常サンプルのバックエンドクレンジングは南京側が処理。 |
| T00-05 期待どおりではない/交接演练を実行できない | 安全にトリガーできる誤りまたは情報欠落のシナリオを1件準備済み。 | 手順に従って現象を確認し、繰り返し試行しない。 | 用例番号、時間、顧客番号、ページ、メール件名、実施済み操作を記録し、同期ログの確認範囲に含める。 | システムは失敗または条件欠落を記録可能であること。繰り返し操作により新規紐付け/新規メールが発生してはならない。 | RENOは「期待どおりではない」と「実施または判定不可」を明確に区別し、南京が再現できる十分な情報を提出する。 | 必須：南京の受信経路、担当者、応答方法を確認する。 |

### T01 連携環境の開通と設定反映

#### T01-01 完全な連携設定の開通

- 前提：KASIKA管理者がPID、4項目の連携承認情報、顧客インポート/エクスポート設定番号、利用可能な紐付け完了通知メールテンプレートを提供済み。VISTAのKASIKA機能は開通済みで、設定ページは空または編集中。
- KASIKA操作：RENOはKASIKAで管理者が上記情報とアクセス許可を準備済みであることを確認し、テスト顧客を作成しない。
- VISTA操作：RENOは管理者として全パラメータを入力し、保存して入口URLをコピーする。
- 自動/メール：保存自体は顧客作成、同期、書き戻し、メール送信を行わないこと。保存時間が以降の定期同期アンカーとなる。

- 期待どおりの結果：保存成功、キーはマスキングされ、ステータスは利用可能、入口URL/フィールド名はコピー可能。顧客業務レコードは表示されない。
- 南京コラボレーション：総スイッチ、連携認可、インポート／エクスポート設定が利用可能であることのみ確認。保存時間はRENOが自ら記録し、それに基づいて後続の定時同期を観察する。

#### T01-02 不完全または誤った設定のブロック

- 前提：既知の有効な設定一式と独立したテストプロジェクト/復元可能なドラフトを保持する。
- KASIKA操作：RENOは欠落項目または無効パラメータのテスト値を提供する。本番キーは使用しない。
- VISTA操作：必須項目をそれぞれ欠落させ、無効な値を入力して保存する。その後、入口アクセスと全量同期を試行する。
- 自動/メール：保存検証失敗が後続の自動チェック時間を変更しない。連携認可が利用できない場合、システムは顧客の読み取り、紐付け作成、アクセス方法の書き戻し、またはメール送信を行ってはならない。
- 期待どおりの結果：フィールドエラーまたは利用不可ステータスが識別可能であり、既存の有効な構成が上書きされず、顧客/メールへの副作用がない。

- 南京協力：安全な無効パラメータと設定復旧操作を提供する。

#### T01-03 設定編集と保存失敗

- 前置条件：完全な保存済み設定があること。元の設定保存時刻を記録する。
- KASIKA 操作：なし。
- VISTA 操作：単一項目を編集後、キャンセルする。その後、保存失敗を模擬し、ページを更新して確認する。
- 自動/メール：キャンセル、検証ブロック、または保存失敗によって、定期同期アンカーが更新されず、同期・メールがトリガーされないこと。
- 期待どおりの結果：キャンセル後、元の値に戻る。失敗後も元の設定が有効であり、後続の同期時点が書き換えられないこと。
- 南京協力：安全な「保存失敗」の模擬を手配し、テスト環境を復旧する。

#### T01-04 二つの業務スイッチ

- 前提：完全な設定、未紐付けの新規顧客1名と紐付け済みで状態可変の顧客1名を使用し、いずれもテスト用メールを使用する。
- KASIKA 操作：顧客二名と可変 `customer_status` を準備する。
- VISTA 操作：それぞれアクセスパスワードスイッチ、状態権限自動更新スイッチを無効/有効にし、確認操作を完了して対応するエントリまたは同期をトリガーする。
- 自動/メール：パスワードスイッチは新規初回紐付け時のパスワード生成/書き戻しにのみ影響する。状態スイッチは初回ラベル初期化には影響せず、後続の状態変化にのみ影響する。
- 期待どおりの結果：パスワード無効時は二次確認がある。状態スイッチを無効にした後、状態フィールド/ログは更新されるが、ラベル権限は自動で変わらない。再度有効にした後、次の状態同期で更新可能。
- 南京協力：なし。RENO は顧客二名の状態とスイッチ二つを自ら復元する。保存後の実際の同期結果でスイッチの有効性を判断する。

#### T01-05 読み取り専用情報のコピーとメール組み立て

- 前提：完全な設定と KASIKA テストメールテンプレートの下書き。
- KASIKA 操作：RENO は「初回アクセス招待メール」テンプレートに VISTA エントリの基本 URL を配置する。実際の送信時には KASIKA が自動的に該当顧客の `kasikacid` を付加し、テスト担当者は手動でパラメータを追加しないこと。自動返信 ID には紐付けしない。
- VISTA 操作：エントリ URL、`VISTAURL`、`VISTAPWD` のフィールド名をコピーし、編集不可であることを確認する。
- 自動/メール：テスト招待メール送信後、エントリページにのみ到達すること。クリック前は紐付け、書き戻し、紐付け完了通知の送信を行わないこと。
- 期待どおりの結果：リンクに正しいプロジェクトと顧客パラメータが含まれ、フィールド名が KASIKA のカスタムフィールドと一致すること。コピー自体はログを生成しない。
- 南京協力：なし。RENO がテスト招待メールを送信し、実際のリンクが正しいプロジェクトと顧客のエントリページを開くことを確認する。

#### T01-06 角色アクセス設定ページ

- 前提：管理者、営業マネージャー、営業担当者のアカウントはすべて作成済み。
- KASIKA 操作：なし。
- VISTA 操作：3つのロールがそれぞれ設定を表示、編集、提出する。
- 自動/メール：なし。
- 期待どおりの結果：管理者のみが表示/変更可能。非管理者は既知のページアドレスを開いても提出・保存できない。
- 南京協力：なし。RENO は自社の3種類のアカウントを使用して検証を完了。アカウントまたはページが欠落している場合はブロックとして記録。

### T02 タグ、権限テンプレート、共有可能なコンテンツのガバナンス

#### T02-01 标签の全ライフサイクル

- 前提：管理者アカウント、独立したテストタグ、および未関連付け/関連付け済みのテスト顧客。
- KASIKA 操作：なし。
- VISTA 操作：新規追加、同名追加、編集、無効化、タグ削除、および顧客/テンプレートの関連付け表示。
- 自動/メール：タグ操作はKASIKAに書き戻さず、メールも送信しない。権限に影響する場合は、テンプレートルールに基づいて再計算する。
- 期待どおりの結果：名前ルールが有効で、関連付けの表示が正しく、削除/無効化後の権限とページ表示がルールに適合する。
- 南京連携：なし。RENOは専用テストタグを使用し、完了後はそれを後続の状態タグとして再利用しない。

#### T02-02 テンプレートの作成と編集

- 前提：少なくとも2つの審査済み共有可能コンテンツと1つの共有不可コンテンツが存在し、テストタグが存在すること。
- KASIKA 操作：なし。
- VISTA 操作：タグから権限テンプレートに入り、追加、保存、編集を行う。
- 自動/メール：保存後、影響を受ける顧客の権限が再計算され、KASIKA のアクション/メールはなし。
- 期待どおりの結果：テンプレートが対象タグのみに紐づき、コンテンツ保存後に顧客の最終権限およびC側で読み取り可能であることを検証する。
- 南京協力：なし。RENO は専用のテストコンテンツとテンプレートを使用し、テスト設定を自身で復元する。

#### T02-03 テンプレート権限の和集合

- 前提条件：1名の顧客が、それぞれ異なるコンテンツを含む2つのタグテンプレートを持つ。
- KASIKA操作：なし。
- VISTA操作：同じ顧客に2つのタグを設定し、最終権限の概要とVISTA Cを確認する。
- 自動処理／メール：テンプレートの和集合によりリアルタイムで計算する。メールは送信しない。
- 期待どおりの結果：両方のテンプレートのコンテンツにアクセスでき、相互に上書き・控除されない。
- 南京側の協力：なし。VISTA Bの最終権限とVISTA Cの実際のアクセス結果で併せて確認する。

#### T02-04 可分享内容审定限制

- 前提条件：共有可能なコンテンツ1件と共有不可のコンテンツ1件があり、共有可能なコンテンツはテンプレートに設定済みである。

- KASIKA 操作：なし。
- VISTA 操作：共有不可のコンテンツを選択してみる。その後、選択済みコンテンツの共有資格を撤回する。
- 自動/メール：資格変更後、コンテンツはテンプレートおよび最終権限から除外されるべきであり、メールは送信されない。
- 期待どおりの結果：共有不可のコンテンツは選択できない。撤回後、C側ではアクセスできなくなる。
- 南京協力：なし。RENOは専用テストコンテンツで実行し、共有資格変更を復元する。

#### T02-05 テンプレート保存時の即時影響

- 前提：同じタグを持つ2名のテスト顧客がおり、そのうち1名はC側にログイン済み。
- KASIKA 操作：なし。

- VISTA操作：テンプレート修正後、ログイン済みセッションと新規セッションをそれぞれリフレッシュする。
- 自動/メール：権限は実装されたリアルタイム読み取り/キャッシュポリシーに応じて有効となるものとする。ポリシーと最大時間制限は未定義のため、実際の結果を記録する。
- 期待どおりの結果：リフレッシュ、再オープン、または再ログイン後、2名の顧客の最終権限が一致し、取り消されたコンテンツへのアクセスを継続しないこと。実際に有効となった動作と時間を記録する。
- 南京協力：なし。実際のアクセス結果で判定し、キャッシュや有効化メカニズムを事前に想定しない。

#### T02-06 テンプレートなしと空権限の境界

- 前置条件：テンプレートタグなし、空テンプレートタグ、タグなしの顧客をそれぞれ1名用意する。
- KASIKA操作：なし。
- VISTA操作：それぞれC側にログインし、制限されたコンテンツにアクセスする。

- 自動/メール：デフォルトコンテンツを自動付与せず、メールも送信しない。
- 期待どおりの結果：最終権限が空、または個人追加権限のみ由来であり、制限コンテンツにはアクセス不可。
- 南京協働：なし。

### T03 KASIKA メール入口の初回アクセスとアカウント作成紐付け

#### T03-01 メール入口からプロジェクト識別へ

- 前提：完全な連携設定が済んでいること；KASIKA テスト顧客が未紐付けであること；「初回アクセス招待メール」テンプレートが設定済みであること。
- KASIKA 操作：RENO は通常の業務ルールに従い、VISTA 入口のベース URL を含む招待メールを送信する；KASIKA は実際の送信時に正しい `kasikacid` を自動的に付加する。

- VISTA操作：RENOが未ログインブラウザでメールリンクを開く。
- 自動/メール：VISTAがプロジェクトアクセスドメインとKASIKA顧客を確認後、メールボックスに入って確認する；リンクを開くだけでは紐付け完了通知を送信しないこと。
- 期待どおりの結果：正しいプロジェクトが検証ページに入り、顧客の機密情報を事前に表示しない；プロジェクトアドレスまたは顧客番号が正しくない場合はアカウント作成に進まない。
- 南京連携：なし。招待テンプレートと送信ルールはRENOが自ら準備し、実際の受信メールで確認する。

#### T03-02 既に紐付け済みかつメールアドレス一致

- 前提：KASIKA/VISTAに有効な1対1の紐付けが既に存在し、メールアドレスが一致、現在のVISTAURL/メール数を記録する。
- KASIKA操作：RENOがその顧客に初回アクセス招待メールを送信する。
- VISTA操作：メールから入り口を開き、対応するメールアドレスで必要な確認を完了する。

- 自動/メール：システムは既存の紐付け、書き込み、またはブラウザ認識記録の確認後、VISTAへ移行する。新規作成、パスワード再設定、書き戻し、紐付け完了通知の送信は行わない。
- 期待どおりの結果：紐付け/権限/フィールドおよびメール数は変更されず、該当顧客が持つべき内容にアクセスできる。
- 南京協力：なし。RENOは先行ケースで紐付け済みの専用顧客を使用し、顧客、フィールド、メール、管理者の同期記録により、重複した初回紐付けがないことを確認する。

#### T03-03 未紐付けだが同一メールのVISTA顧客が紐付け可能

- 前提：KASIKA顧客は未紐付け。VISTAに同一メールの顧客が一意に存在し、未紐付けかつ再紐付け禁止のマークがない。
- KASIKA操作：RENOが初回アクセス招待メールを送信する。
- VISTA操作：メールを開き、KASIKAに登録されたメールアドレスを入力して確認を完了する。
- 自動/メール：紐付けを確立し、パスワード入力をスキップする。アクセスフィールドを準備後、設定に従って書き戻し、紐付け完了通知を送信する。

- 期待どおりの結果：未だ2つ目のVISTA顧客を新規作成していない；一意の紐付けを確立し、コールバック/メールはそれぞれ1回のみ発生する。
- 南京コラボレーション：なし。RENOは専用の既存顧客を使用して紐付け完了後に結果を保持し、テスト準備段階で自動返信IDとテンプレートを記録する。

#### T03-04 新規顧客かつアクセスパスワードを有効化

- 前提：KASIKAに顧客が存在し、VISTAに同メールアドレスの顧客が存在しない；パスワードスイッチが有効；状態同名ラベル/テンプレートが準備済み。
- KASIKA操作：RENOが初回アクセス招待メールを送信する。
- VISTA操作：リンクを開き、一致するメールアドレスを入力し、現行のVISTAパスワード規則に適合するパスワードを設定し、アカウント作成を完了してC側に入る。
- 自動/メール：VISTA顧客を作成し、紐付けし、状態/初期ラベル権限を保存し、URLとパスワードをコールバックし、紐付け完了通知をトリガーする。
- 期待どおりの結果：四端のデータが一致し、メールは紐付け完了通知であり招待メールではなく、重複した口座作成/送信がない。

- 南京協力：なし。RENOはページの実際のパスワードルール、専用テスト顧客、テストメールを使用して検証を完了；自動返信IDとテンプレートはテスト準備段階で記録。

#### T03-05 新規顧客かつアクセスパスワード無効

- 前提：T03-04と同様、ただしパスワードスイッチは無効。
- KASIKA操作：初回アクセス招待メールを送信。
- VISTA操作：入口を開き、メール確認を完了。
- 自動/メール：作成と紐付け、ステータス権限、URL書き戻しは引き続き実行；VISTAPWDは表示・生成・書き戻しを行わず、紐付け完了テンプレートはパスワードフィールドに依存しないこと。
- 期待どおりの結果：パスワード不要でもプロジェクト・顧客・メール検証は省略不可；KASIKAはURLのみ取得。
- 南京協力：なし。RENOがスイッチの切り替えと復元を自ら行い、新しい専用顧客を使用して検証を完了し、実際のメールを確認。

#### T03-06 メールアドレス検証失敗

- 前提：KASIKA顧客未連携、VISTAに誤マッチング対象なし。
- KASIKA操作：招待メールを送信する。
- VISTA操作：空、形式エラー、KASIKAと一致しないメールアドレスをそれぞれ入力する。
- 自動/メール：作成しない、連携しない、書き戻さない、連携完了通知をトリガーしない；必要なセキュリティログのみ記録する。
- 期待どおりの結果：失敗通知は氏名/ID/権限を漏らさない。KASIKA/VISTAデータと受信トレイに初回連携結果の新規追加がない。
- 南京協力：なし。ページ、顧客データ、書き戻しフィールド、テスト受信トレイで初回連携が発生していないことを確認する；ログ入口が利用できない場合は記録してブロックとする。

#### T03-07 紐付け競合と再紐付け禁止（南京側分離検証）

- 前提：KASIKA メールは一意であり、RENO は2つの KASIKA 顧客から同じメールを自然に構築することはできない。南京側は分離環境でそれぞれ同一の customer_id でメール不一致、同一メールの候補競合、再紐付け禁止または削除復旧リスクのサンプルを準備する。
- KASIKA 操作：RENO は異常サンプルを作成しない。南京側は分離計画に従ってアクセス可能なサンプルまたは検証記録を提供する。
- VISTA 操作：RENO が入口サンプルを提供された場合、ページ表示を記録できる。南京側は完全な異常検証を実施する。
- 自動/メール：システムは自動紐付け/新規作成を停止し、旧関係を上書きせず、書き戻さず、紐付け完了通知を送信しない。
- 期待どおりの結果：各エラータイプに統一されたサマリーとログがある。既存の紐付け、ラベル、権限は破損しない。
- 南京協力：必須。異常紐付けとバックエンド処理記録を構築/クリーンアップし、検証結果を提供する。

#### T03-08 入口ページのエラー状態

- 前提：プロジェクトアドレスが無効、顧客番号が無効・欠落、一時的にKASIKA顧客を確認できない、顧客が存在しない、ブラウザ識別記録が未保存などの制御可能なシナリオ。
- KASIKA操作：該当するテストリンクを送信または生成する。
- VISTA操作：リンクを順番に開き、ページとその後のアクセスを記録する。
- 自動・メール：プロジェクトまたは顧客が無効な場合はアカウント作成を行わないこと。ブラウザ識別記録が未保存でも、確認済みのアカウント作成を妨げるべきではないが、システムは記録を残すこと。
- 期待どおりの結果：ページの表示、継続可能な範囲、記録結果が要件を満たすこと。エラーの書き込みや発信が発生しないこと。
- 南京協力：これらのシミュレーションシナリオを手配し、ログ確認を提供する。

#### T03-09 同一顧客の繰り返しアクセス

- 前提：未紐付け顧客1名と、独立した2つのブラウザまたはタブを用意する。別途、初回紐付けを完了した顧客も用意する。
- KASIKA操作：初回アクセス招待メールを1回送信する。
- VISTA操作：並行してリンクを開く。アカウント作成後にも、同じリンクを再度開く。
- 自動処理／メール：同時に開いた場合でも、最終的には顧客1名、紐付け1件、アクセス方法の書き戻し1回、紐付け完了通知1回のみとする。完了後は既存の関係に入る。
- 期待どおりの結果：重複した顧客、紐付け、メールがない。ログから今回の重複オープンの処理方法を説明できる。
- 南京側の協力：なし。RENOは管理者同期記録で処理結果を確認し、専用テスト顧客を記録として保持する。

### T04 入口をクリックしていない顧客の同期フォールバックと初回紐付け

#### T04-01 手動全量同期チェック

- 前提：完全な設定；KASIKA には未紐付けのテスト顧客が存在；RENO は一切の招待メールをクリックしないことを確認。
- KASIKA 操作：テスト顧客を作成・保持し、入口メールを送信しない、または開かない。
- VISTA 操作：管理者または営業マネージャーが顧客リストで「全量同期チェック」をクリックし、タスク完了を待つ。
- 自動/メール：システムが KASIKA の現在取得可能な全顧客を処理；初回紐付けサンプルに対し、作成・紐付け・書き戻し後に紐付け完了通知を送信。
- 期待どおりの結果：タスクがチェックされた行のみを処理するわけではない；サンプルが正しいバッチ、紐付け、フィールド、メール、ログを形成する。
- 南京協力：なし。RENO は test-jp の全 KASIKA 顧客に対する管理権を持ち、操作前に実際のバッチ範囲を自ら確認する。

#### T04-02 定时同步触发

- 前提：T04-01と同じ；RENOは最後に正しく保存された設定の時間、test-jpタイムゾーン、および現在同期処理が進行中かどうかを記録済み。
- KASIKA操作：未紐付けの顧客を作成し、VISTA同期ボタンを操作せず、エントリをクリックしない。
- VISTA操作：RENOは顧客リスト、受信トレイ、および表示可能なタスク結果のみを観察し、手動でトリガーしない。
- 自動/メール：最後に正しく保存された設定の時間から、完全な1時間周期が経過した後、システムが自動同期する；初回紐付けサンプルはT04-01に従って自動処理され、同時に紐付け完了通知が送信される。
- 期待どおりの結果：実際のログトリガー時間がスケジュールルールと一致し、RENOが操作しなくても完全なチェーンを説明できる。
- 南京協力：なし。RENOは管理者アカウントで同期記録を確認する；完全な周期を超えてもトリガーされない、またはログエントリが欠落している場合は「ブロック（環境調査待ち）」と記録する。

#### T04-03 既存のVISTA顧客との同期一致

- 前提：KASIKAは未紐付けの顧客；VISTAには同一メールアドレス、紐付け可能な顧客が存在；エントリをクリックしない。

- KASIKA操作：顧客と状態の準備。
- VISTA操作：手動同期または完全な定期同期サイクルを1回待ち、その後顧客詳細/権限/C側を確認。
- 自動/メール：既存顧客とマッチングし、新規作成は行わない；初回紐付け後に書き戻しと紐付け完了通知を送信。
- 期待どおりの結果：1対1の紐付けが成立し、既存のVISTA情報は保持され、重複した顧客や重複したメールは発生しない。
- 南京協力：なし。RENOは専用の既存顧客を使用して紐付け完了後に結果を保持し、テストメールボックスで実際のメール記録を確認する。

#### T04-04 同期によるVISTA顧客の新規作成

- 前提条件：KASIKA顧客がVISTAに同じメールアドレスのオブジェクトが存在しないこと；パスワードスイッチの状態が記録済みであること。
- KASIKA操作：顧客を作成し、エントリーポイントをクリックしない状態を維持する。

- VISTA操作：手動同期を開始するか、定期同期を観察し、新規顧客、権限、C側を確認する。
- 自動/メール：作成、紐付け、状態初期化；URLおよび該当パスワードを書き戻す；紐付け完了通知を送信する。
- 期待どおりの結果：一度だけ作成、書き戻しフィールドがスイッチに適合、メールは一回、C側権限が正しい。
- 南京協力：なし。RENOは専用の新規顧客とテストメールアドレスを使用し、今回の結果を保持し、他の初回紐付けケースには再利用しない。

#### T04-05 自動処理すべきでないVISTA顧客

- 前提：VISTAにはローカルのみに存在し、KASIKAとの対応関係がない顧客がいる。
- KASIKA操作：対応する顧客を作成しない。
- VISTA操作：全量同期を実行し、その顧客の前後の資料・権限を確認する。

- 自動/メール：削除しない、書き換えない、偽の関連付けを作成しない、メールを送信しない。
- 期待どおりの結果：ローカル顧客は変わらず、ログではこれをKASIKA同期対象として扱わない。
- 南京連携：なし。

#### T04-06 同期に変化なし

- 前提：完全に同期され、初回紐付けが完了した顧客が1名おり、既存のフィールド/メール数を記録する。
- KASIKA操作：顧客フィールドを変更しない。
- VISTA操作：手動で全量同期を実行するか、完全な定期同期サイクルを待つ。
- 自動/メール：結果は変化なし；再作成や初回アクセスフィールドの書き戻し、紐付け完了通知の送信は行わない。

- 期待どおりの結果：批次/ログは「変化なし」であり、すべての業務オブジェクトとメール数は変わりません。
- 南京協力：なし。RENO は管理者同期記録を使用してタスクが「変化なし」であることを確認します。

#### T04-07 バッチ部分成功

- 前提：同じバッチ内に、成功可能なもの、メール/紐付け競合、KASIKA 呼び出し失敗、または制御可能な失敗サンプルが少なくとも存在すること。
- KASIKA 操作：3種類の顧客を準備します。
- VISTA 操作：管理者が全量同期を開始し、タスクサマリー、顧客レベルの結果、ログを確認します。
- 自動/メール：成功項目は完了します。失敗項目は成功項目をロールバックせず、メールは初回紐付け条件を満たす成功項目にのみ送信されます。
- 期待どおりの結果：サマリー、3種類のフロント結果、失敗理由、成功済みデータが相互に一致します。

- 南京側の協力：制御可能なKASIKA応答失敗シナリオを手配し、すべての処理明細を照合する。

#### T04-08 権限のないロールによる同期の遮断

- 前提：日本側が営業担当者、管理者、営業マネージャーのアカウントを準備し、必要な設定が完了している。
- KASIKA操作：なし。
- VISTA操作：営業担当者は顧客一覧を表示し、同期ボタンのクリックまたは既知の同期URLの表示を試みる。管理者と営業マネージャーはそれぞれ入口が表示されることを確認する。
- 自動処理／メール：遮断された操作は、処理開始、顧客取得、アクセス方法の書き戻し、メール送信を行ってはならない。
- 期待どおりの結果：営業担当者は画面上でも直接URLでも同期を開始できず、管理者／営業マネージャーの権限は要件どおりである。
- 南京側の協力：なし。

### T05 `customer_status` とラベル・アクセス権限の継続的な連動

| ケース | 前提状態 | RENO：KASIKA 操作 | RENO：VISTA 操作 | システム自動処理とメール | 期待どおりの結果 | 南京側連携 |
| --- | --- | --- | --- | --- | --- |
| T05-01 初回紐付け状態初期化 | RENO は未紐付けの顧客2名を準備し、状態値にはそれぞれ対応する VISTA 同名ラベルとテンプレートがあるものとする；1名は入口経由、1名は同期経由とする。 | 状態を設定し、テスト中は変更しない。 | それぞれ T03 初回紐付け、T04 同期フォールバックを実行；ラベル、権限、C 端を確認する。 | 2つの初回紐付け経路はいずれも状態を保存し、同名ラベルを設定し、初期権限を計算する；状態スイッチがオフでもスキップしない。メールは各メイン経路の紐付け完了通知ルールに従う。 | 2名の顧客のラベル／最終権限／C 端内容はすべて状態テンプレートと一致し、経路の違いによって初期化結果は変わらない。 | なし；テスト顧客、状態、テンプレートは RENO が自ら準備し、結果を保持する。 |
| T05-02 以降の状態変更の自動更新 | 紐付け済み顧客、自動更新スイッチはオン；旧／新状態には同名ラベルがある。 | 状態を A から B に変更する。 | 変更前のラベル／内容を記録し、手動同期後に B／C 端を確認する。 | 新状態を保存し、B ラベルを追加、A ラベルを削除、権限を再計算する；初回 URL／パスワードは書き戻さず、紐付け完了通知を重複送信しない。 | B 端、ログ、C 端はすべて最新状態に対応する権限のみを反映する。 | なし；RENO は手動同期と管理者同期記録を使用して判定を完了する。 |
| T05-03 自動更新オフ | 紐付け済み顧客；RENO はプロジェクト設定でスイッチをオフにできる；旧状態ラベルは存在する。 | 状態を新しい値に変更する。 | スイッチをオフにして保存後、手動同期をトリガーし、フィールド、ラベル、権限、C 端を確認；終了後にスイッチを復元する。 | 構造化状態とログを更新するが、状態ラベルの自動追加・削除や権限の再計算は行わない；メールなし。 | 新状態は追跡可能だが、元のラベル／権限／C 端の表示内容は今回の変更によって自動的に変わらない。 | なし；RENO が自ら状態とスイッチを復元する。 |
| T05-04 同名ラベルなし | 紐付け済み顧客、自動更新オン；KASIKA の新状態には VISTA に同名ラベルがない。 | マッチしない状態に変更する。 | 手動同期をトリガーし、ログ、ラベル、C 端を確認する。 | 状態を保存；初回シナリオではデフォルト権限を付与せず、以降のシナリオではルールに従って旧状態ラベルを削除し、スキップを記録；メールなし。 | ラベルの自動作成や誤認可はなく、ログにマッチなしと記録される。 | なし；RENO が自ら状態名を準備／復元する。 |
| T05-05 状態ラベルの部分失敗 | 紐付け済み顧客、A→B；南京側は「ラベル追加／削除または内容更新失敗」のシミュレーションシナリオを手配できる。 | 状態を B に変更する。 | 同期をトリガーし、南京がシミュレーションシナリオを復旧した後、後続チェックに従って実行する。 | システムは失敗箇所を記録；復旧後は未完了のラベル／権限ステップのみを継続し、紐付け、書き戻し、送信は繰り返さない。 | 最終的に正しいラベルと権限のみが存在し、ログには以前の失敗と復旧後の結果が保持される。 | 必須：失敗シミュレーション、復旧、ログ確認を手配する。 |
| T05-06 ステータス切り戻しと複数回の変更 | 紐付け済み顧客で、少なくともA/B/Cの各ステータスに対応するテンプレートがあること。 | A→B→C→Aの順に変更する。 | 毎回タスク結果ページで完了し、今回の同期記録が出現した後にB/C側の結果を記録する。 | 各ラウンドは現在のステータスに基づきキャリブレーションする；初回フィールドの書き戻しや紐付け完了通知はない。 | 最終的にAの権限のみ保持され、B/Cの残留越権がないこと。 | なし；RENOが自ら同期を発起し、結果を記録してステータスを復元する。 |

### T06 VISTA顧客管理と手動権限調整の境界

| ユースケース | 前提ステータス | RENO：KASIKA操作 | RENO：VISTA操作 | システム自動処理とメール | 期待どおりの結果 | 南京側の連携 |
| --- | --- | --- | --- | --- | --- |
| T06-01 顧客リストと連動ステータス表示 | RENOが未紐付け、紐付け済み、および異なるタグの顧客を準備する；異常サンプルは管理された検証結果を使用し、RENOの構築は不要。 | 顧客を変更しない。 | 権限付きロールでリストを開き、フィルタリングして各行を表示する。 | データの読み取りのみ、同期、書き戻し、メール送信は行わない。 | タグと許可された連動サマリーが表示される；完全なKASIKAスナップショット、パスワード、ログ詳細はない。 | なし；テスト担当者は専用のテスト顧客を使用する。 |
| T06-02 顧客詳細情報の境界 | T06-01と同様。 | 顧客を変更しない。 | 各顧客の詳細を表示し、紐付け解除、再紐付け、パスワード表示の入り口を探す。 | 自動アクションやメールはなし。 | 許可されたサマリーのみ表示；フロントエンドに手動紐付け解除/再紐付け/再試行/パスワード表示は存在しない。 | なし。 |
| T06-03 手動タグと個人権限の追加 | 紐付け済み顧客、共有可能なコンテンツとテンプレートが準備されている。 | ステータスを変更しない。 | 通常のVISTAタグの追加/削除、個人権限の追加を行い、最終権限とC側を表示し、終了後に専用テスト設定を復元する。 | 権限の再計算はVISTA内でのみ発生し、KASIKAへの書き戻しやメールはない。 | C側はテンプレートの和集合に個人追加を加えたものと等しい。 | なし；RENOが自らテストタグ/権限を復元する。 |
| T06-04 個人設定でテンプレート権限を削減できない | 顧客がタグテンプレートを通じてコンテンツXを取得済み。 | なし。 | 顧客レベルの設定でXを除外しようとする。 | システムは相殺を拒否するか、テンプレート付与を引き続き保持する；メールはなし。 | Xはテンプレート権限で引き続きアクセス可能であり、ページで「除外済み」という偽の状態を作り出さないこと。 | なし。 |
| T06-05 ローカル資料編集境界 | 顧客に紐付け済みかつ KASIKA に異なる/識別可能な資料があること。 | RENO は KASIKA の元資料を記録し、本ケースでは変更しない。 | VISTA の氏名、メール、電話などの許可されたローカルフィールドを編集する；KASIKA の主フィールドの変更を試みる。 | KASIKA に書き戻さず、自動再紐付け/送信もしない。 | KASIKA の元資料は変更されない；制限フィールドは編集不可か紐付けに影響しない。 | なし；KASIKA の前後値は RENO が独自に記録を確認する。 |

### T07 初回紐付け後の KASIKA 書き戻しと自動返信

| ケース | 前提状態 | RENO：KASIKA 操作 | RENO：VISTA 操作 | システム自動処理とメール | 期待どおりの結果 | 南京側連携 |
| --- | --- | --- | --- | --- | --- |
| T07-01 初回紐付け時のフィールド書き戻し | RENO が入口新規作成、入口紐付け既存、同期新規作成、同期紐付け既存の4種類の未紐付けサンプルをそれぞれ準備；自動返信設定は記録済み。 | 顧客とカスタムフィールドを準備し、初期フィールドは空値のまま保持する。 | それぞれ対応する T03/T04 のメイン経路を実行する。 | 初回紐付け後に `VISTAURL` と該当する `VISTAPWD` を書き込む。 | 4種類の該当経路すべてで正しい書き戻しが一度だけ発生し、フィールドは KASIKA 顧客資料で確認できる。 | なし；RENO が独立サンプルを使用して完了し、記録を保持する。 |
| T07-02 書き戻しフィールド境界 | T07-01 のサンプルを完了する。 | KASIKA のフィールドとメールを確認する。 | VISTA B と管理者同期記録を確認する。 | VISTA ID、紐付け状態、初回アクセス時刻は書き戻さない；ログのパスワードはマスキング処理する。 | 許可された2種類のフィールドのみ；ページ/ログ/メールにパスワード平文以外の誤った情報境界が漏れない。 | なし；RENO は管理者アカウントで記録を確認する。 |
| T07-03 パスワードスイッチと書き戻し差異 | 2件の新規サンプルで、1件はパスワードスイッチがオン、1件はオフ。 | 同一条件の顧客を準備する。 | それぞれ初回紐付けを完了し、スイッチを復元する。 | オン：生成/設定後に VISTAPWD を書き戻す；オフ：疑似パスワードを生成せず、空パスワードも書き込まない。 | URL はすべて書き戻される；オンサンプルのみ有効なパスワードフィールドと該当メール変数がある。 | なし；RENO が2種類の実際のメール内容を確認する。 |
| T07-04 書き戻し失敗と部分失敗後の継続処理 | 南京側が「アクセスリンクまたはパスワード書き戻し失敗」の新規サンプルを用意可能。 | サンプルを準備；南京側が指定フィールドを一時的に書き込み不可にし、その後復旧する。 | 初回紐付けをトリガーし、初回結果を記録し、南京側の後続確認手配を待つ。 | 紐付けと権限は取り消さない；復旧後、システムは以前失敗したフィールドのみを書き込み、再作成、再紐付け、成功済み部分の再送信はしない。 | 復旧後にフィールドが全て揃い、各項目が一度だけ出現する；ログに失敗と復旧後の記録がある。 | 必須：失敗のシミュレーション手配、後続確認時間の説明、ログの提供。 |
| T07-05 自動返信送信 | RENO が紐付け通知テンプレート名、ID、有効状態、テスト受信トレイの新規サンプルを記録済み。 | テンプレート変数と自動返信 ID を確認し、別途運用招待メールを送信しないこと。 | 初回紐付けを1回完了する。 | URL（および該当する場合はパスワード）準備完了後にその ID を呼び出し、紐付け完了通知を送信する。 | メールの件名/本文/時刻が紐付け完了通知に対応し、フィールド/紐付けが完了していること。 | なし。RENO は設定ページとテスト受信トレイで `7a87c2addf` の実際の帰属と送信結果を確認する。 |
| T07-06 自動返信未設定または送信失敗 | メール番号が未設定のサンプル1組、南京側で送信失敗を仕込めるサンプル1組。 | 南京側の手配の下、テスト項目のメール番号を削除するか、送信失敗を仕込む。 | 初回紐付けを完了し、その後設定を戻すか、南京側でシミュレーションシナリオの復旧を待つ。 | 顧客構築、紐付け、権限、既に成功した書戻しには影響しない。単に「未送信/送信失敗」を記録し、後続は発信のみ処理する。 | 番号未設定時は送信しない。復旧後も紐付け/書戻しを繰り返さず、メールは最大1回の成功送信とする。 | 必須：設定の安全な変更、失敗シミュレーションの手配と復旧。 |

### T08 VISTA C コンテンツアクセスと権限の実際の有効化

| テストケース | 前提状態 | RENO：KASIKA 操作 | RENO：VISTA 操作 | システム自動処理とメール | 期待どおりの結果 | 南京側コラボレーション |
| --- | --- | --- | --- | --- | --- |
| T08-01 権限ありコンテンツアクセス | 紐付け完了済み。ラベルテンプレート/個人追加権限が複数の共有済みコンテンツをカバー。 | 状態を変更しない。 | 顧客が C 端にログインし、許可されたコンテンツを1件ずつ開く。管理者は最終権限を確認する。 | C 端は最終権限を読み込む。同期/メールなし。 | 各許可コンテンツに入場できる。B 端の最終権限と C 端が一致する。 | なし。RENO は専用テストコンテンツリストを使用。 |
| T08-02 権限なし・空権限アクセス | ラベルなし、空テンプレート、または権限を回収された紐付け済み顧客。 | 状態を変更しない。 | C 端にログインし、同じ制限 URL/エントリにアクセスする。 | デフォルト認可なし、メールなし。 | ページが非表示またはアクセス拒否となり、直接 URL で迂回できない。 | なし。 |
| T08-03 権限変更後の再アクセス | ログイン済みセッションと新規セッションを各1つ準備。テンプレート/ラベル/状態/個人権限の変更を1件準備。 | 状態テストの場合は状態を変更する。 | B 端で変更後、旧セッションの更新、再ログイン、新規タブをそれぞれ実行。 | 権限は実際の実装の更新/キャッシュポリシーに基づいて更新される。初回紐付けメールなし。 | 実際の有効動作と時間を記録する。更新、再オープン、再ログイン後、回収されたコンテンツにはアクセス不可となり、追加された権限にはアクセス可能となる。 | なし。実際のアクセス結果で判定し、キャッシュやトークン失効メカニズムは前提としない。 |
| T08-04 複数タグと個人権限の組み合わせ | 1名の顧客が二つのテンプレートタグと一つの個人追加を持ち、コンテンツ集合が記録済みされている。 | なし。 | B 端の最終権限を確認し、C 端で項目ごとに検証する。 | リアルタイムで和集合+追加を計算し、メールは送信しない。 | C 端の集合が記録済みされた集合と厳密に一致し、漏れや追加コンテンツがない。 | なし。 |
| T08-05 旧セッションと複数タブ | 顧客が複数タブでログイン済み；権限の回収、削除、または紐付け異常のいずれかを準備する。 | シナリオに応じて状態を変更するか、KASIKA 顧客を削除する。 | B 端で対応する変更を実行；旧タブ、更新、制限リンクへの再アクセスを行う。 | 新規リクエストは現在の権限に基づいてブロックされる；自動的な紐付け復元やメールはない。 | 旧セッションが継続的に権限を超えない；異常はログで追跡可能。 | 必須：削除/異常データガバナンスを実行し、セッションポリシーを確認する。 |

### T09 削除、紐付け異常、および手動データガバナンス

| テストケース | 前提状態 | RENO：KASIKA 操作 | RENO：VISTA 操作 | システム自動処理とメール | 期待どおりの結果 | 南京側の協力 |
| --- | --- | --- | --- | --- | --- |
| T09-01 未紐付けの VISTA 顧客を削除 | VISTA のみに存在し、未紐付けのテスト顧客。 | なし。 | 権限に基づいて削除し、C 端/ログを確認する。 | ローカル削除および権限無効化；KASIKA を呼び出さず、メールも送信しない。 | 顧客は再アクセス不可、KASIKA に変更なし、ログが境界に適合する。 | テストデータのリセット/復元。 |
| T09-02 紐付け済みの VISTA 顧客を削除 | 専用の有効紐付けを持つテスト顧客で、KASIKA フィールドが記録済み。 | KASIKA 顧客は削除しない。 | RENO 管理者が通常のページ操作で VISTA 顧客を削除し、KASIKA、VISTA/ログを確認する。 | VISTA の有効紐付けをクリーンアップし、履歴を保持；KASIKA 顧客を削除せず、その URL/パスワードをクリアせず、メールも送信しない。 | KASIKA フィールドは残存；VISTA に有効紐付けがなく、ログが完全である。 | テスト後に専用データをクリーンアップ/復元；RENO がログを確認できない場合は証拠を提供する。 |
| T09-03 削除後の入口からの再アクセス | T09-02 が実行済みで、元の招待リンクを保持している。 | RENO が元の顧客入口リンクを開く。 | リンクからメール確認を完了し、ページを記録する。 | 元の紐付けを自動的に復元したり、他人に紐付けしたりしない；異常を停止して記録し、紐付け完了通知はない。 | 新規作成/変更紐付け/書き戻しなし；統一された異常表示と追跡可能なログを表示する。 | RENO がログを確認できない場合は、削除履歴/再紐付け禁止の証拠を提供する。 |
| T09-04 KASIKA 顧客疑似削除 | サンプルに紐付け済みで、後でKASIKAから削除可能。 | KASIKAの該当テスト顧客を削除する。 | 同期をトリガーするか、元のエントリを開いてVISTA B/C/ログを確認する。 | VISTAはローカル情報、元の関係、ステータス、履歴を保持し、疑似削除/紐付け異常とマークする。自動で紐付け解除やメール送信は行わない。 | VISTAデータの誤削除なし、自動再紐付けなし、ログは明確。 | 必須：KASIKAテストデータの削除と復旧計画。 |
| T09-05 誤紐付けのバックエンド処理 | 実データまたは隔離された誤紐付け/メール不一致/競合サンプル。 | 関連する顧客識別情報を提供する。 | RENOは現象とスクリーンショットのみを記録し、南京の承認者がバックエンド処理を実行した後、再確認する。 | 処理結果に応じて有効な関係を更新し、再紐付けの禁止と権限再計算を行う。KASIKAに書き込まれたフィールドはクリアしない。 | フロントエンドでの権限外操作なし。処理前後、操作者、理由、結果はすべて追跡可能。 | 必須：この機能はRENOが単独で実行しない。 |
| T09-06 削除/処理未完了 | 南京側で削除またはバックエンド処理が未完了のサンプルを手配可能。 | なし。 | 削除/処理の実行と送信を行い、失敗ページとログを記録する。 | システムは未完了の理由を記録し、ログページでは直接の再試行や自動復旧は提供しない。 | 元データの状態が確認でき、失敗情報は追跡可能。 | 必須：シナリオのシミュレーションとデータ確認を手配。 |

### T10 同期ログ、エラーメッセージ、ロール権限と監査

| ユースケース | 前提状態 | RENO：KASIKA操作 | RENO：VISTA操作 | システム自動処理とメール | 期待どおりの結果 | 南京側の連携 |
| --- | --- | --- | --- | --- | --- |
| T10-01 バッチログと顧客レベル結果 | RENOが手動、定期、または変更なしバッチを完了し、時刻を記録済み。 | バッチサンプルを準備/保持する。 | 管理者はサマリーとバッチ顧客リストを表示。他のロールは可視範囲を表示。 | 新しい業務アクションはなし。 | サマリーと顧客レベルの成功/変更なし/失敗が一致し、3列の情報が範囲に適合。 | なし。アカウントまたはログエントリ欠落時は南京側に処理を依頼。 |
| T10-02 エラー辞書の一貫性 | 主要な失敗段階の記録を作成済み。 | 失敗シナリオに応じて戻り値を準備する。 | タスク結果、バッチリスト、顧客詳細サマリー、ログ詳細を比較する。 | 同じエラーコード/サマリー/次のアクションは再利用され、メール要求なし。 | 4箇所の意味が一致し、機密情報を公開しない。 | 失敗サンプル/ログを提供する。 |
| T10-03 失敗原因と後続処理の説明 | 「顧客を読み取れない、マッチしない、作成できない、紐付けできない、アクセス方法を書き込めない、内容を更新できない、送信できない、またはエントリを確認できない」などのサンプルを準備する。 | 南京側の手配のもとで項目ごとに条件を準備する。 | 対応するフローをトリガーし、ページとログを記録する。 | システムは失敗がどこで発生したかを記録し、次のステップがシステム待機、追加設定、または手動処理のいずれであるかを示す。 | 各項目に明確な原因、処理対象、次のステップがあり、単に「失敗」とだけ表示されるわけではない。 | 必須：シナリオのシミュレーションを手配し、ログ権限を提供する。 |
| T10-04 機密情報の保護 | 設定およびRENOが自ら実施したテストログがある。 | なし。 | 管理者が設定ページ、ログ、タスク詳細を確認する。 | なし。 | 連携認証情報、システム通信内容の全体、ブラウザ識別記録、パスワードの平文は確認できない。今期はログのエクスポート機能はない。 | なし。管理者アカウントまたはログエントリが欠落している場合は南京側に提出して処理する。 |
| T10-05 ログアクセスロール | RENOが管理者、営業マネージャー、営業担当者のアカウントと既存のログを準備済み。 | なし。 | 3つのロールがそれぞれメニューおよび既知のページアドレスからログにアクセスを試みる。 | なし。 | 管理者のみが完全なログを閲覧可能。他のロールにはエントリがなく、既知のアドレスからも閲覧できない。 | なし。ロールアカウントまたは権限が欠落している場合は南京側に提出して処理する。 |
| T10-06 ログ照会と非対象機能 | RENOが期間をまたいだテスト操作を完了し、開始/終了時刻を記録済み。 | なし。 | 開始/終了時刻で照会。エクスポート、通知、顧客同期詳細のポップアップエントリを試みる。 | なし。 | 時間フィルタは正確。エクスポート、サイト内/メール失敗通知、顧客同期詳細のポップアップは存在しない。 | なし。ログエントリが欠落している場合は南京側に提出して処理する。 |

### T11 重複操作および失敗復旧後の結果の正確性

| テストケース | 前提状態 | RENO：KASIKA操作 | RENO：VISTA操作 | システム自動処理とメール | 期待どおりの結果 | 南京側の協力 |
| --- | --- | --- | --- | --- | --- |
| T11-01 同一プロジェクトの同期クリック繰り返し | 日本側が2つの権限付きアカウント、2つの独立したブラウザ、および今回初めて処理すべき顧客1名を準備する。現在同期タスクはなく、今回の全量同期で事前に処理される他の未紐付け顧客もいない。 | 招待メールを送信せず、その顧客を変更しない。 | 2つの権限付きアカウントが約束したカウントダウン後に同時に「全量同期チェック」をクリックする。 | システムは1回のみ処理を受け付け、タスクロックを取得する。もう一方の側には「しばらくしてから再試行してください」と表示され、2つ目のタスクは作成されない。 | 同期タスク1件と処理結果1件のみが作成され、重複した顧客、重複紐付け、重複書き戻し、重複送信は発生しない。 | 南京協力：なし。 |
| T11-02 KASIKA 一時的に同期を処理できない | 南京側でKASIKAが「後で処理してください」または「処理が既に進行中です」というサンプルを返すよう手配可能。 | 南京側の手配に従って顧客を準備する。 | 同期を開始し、ページとログを確認する；プロンプトに従って待機し、再度確認する。 | システムは繰り返し送信すべきではない；KASIKAの処理番号または制限の説明が保持される。 | 重複処理や虚偽の完了進捗がないこと；いつ再度確認できるかの記録が残る。 | 必須：KASIKAのテスト能力とログ。 |
| T11-03 顧客作成または紐付け未完了後の継続処理 | 新規顧客。南京側で顧客作成、紐付け保存、または権限更新時に一時的に失敗させるよう手配可能。 | 顧客を準備する。 | 同期をトリガーし、南京側がシミュレーションシナリオを復元した後、後続の確認を実行する。 | システムは未完了の部分のみを継続し、完了済みの顧客、紐付け、または権限を重複して処理しない。 | 最終的にVISTA顧客は1件のみ、有効な紐付けは1件、正しいコンテンツ権限が存在する；ログで先に失敗し、後に完了したことが確認できる。 | 必須：シミュレーションシナリオを手配し、データ/ログを照合する。 |
| T11-04 アクセス方法の書き戻しまたは送信未完了後の継続処理 | 新規顧客。南京側でアクセス方法の書き戻しまたは送信を一時的に失敗させるよう手配可能。 | フィールドとメール条件を準備する。 | 初回紐付けをトリガーし、復元後に確認する。 | システムは書き戻されていないアクセス方法または送信されていないメールのみを処理し、リンク/パスワードを再生成したり、成功したメールを重複送信したりしない。 | アクセス方法とメールはそれぞれ1回のみ成功し、顧客と紐付けは重複しない。 | 必須：シミュレーションシナリオの手配とメール送信記録の提供。 |
| T11-05 入口アクセスと同期の同時発生 | 未紐付けの顧客1名。入口メールと同期の両方が開始可能；RENOテスター2名、2つのブラウザ、各自のアカウントを準備済み。 | 1人が招待メールを送信し入口を開く；もう1人は今回の同期のみを準備する。 | 2人は約束したカウントダウン後に同時に入口メール確認と「全量同期チェック」を送信する。 | システムは最終的に顧客1件、有効な紐付け1件、初回アクセス方法の書き戻し1回、通知1回のみを保持する。 | 四つの側面で重複結果がなく、管理者ログで実際の処理順序を確認できる。 | なし；RENOが通常の入口と通常の同期ボタンを使用して自然に実行する。 |
| T11-06 四つの側面での結果照合 | 成功、部分失敗後に復旧、変化なしの各1名を選択。 | 3名のKASIKA顧客のプロフィールとメールを確認する。 | VISTA B顧客のプロフィール/タグ/権限/ログ、入口ステータス、C側コンテンツを照合する。 | 新規アクションなし。 | 各顧客について四つの側面での結果が相互に説明可能であり、重複や矛盾したステータスがない。 | 必須：四つの側面の読み取り専用証拠とログを提供する。 |

### T12 リリース前の全フロー回帰と運用可用性

| テストケース | 前提状態 | RENO：KASIKA操作 | RENO：VISTA操作 | システム自動処理とメール | 期待どおりの結果 | 南京側の協力 |
| --- | --- | --- | --- | --- | --- |
| T12-01 2つの初回タッチ主導線回帰 | 2名の新規、削除可能な顧客；設定、テンプレート、状態/権限はすべて確認済み。 | Aが初回訪問招待を送信しクリック；Bは顧客登録後エントリをクリックしない。 | Aがエントリアカウント作成を完了；Bは手動または確認済み定期同期処理により、両者ともC側にログイン。 | A/Bともに紐付け、権限、適用書き戻し、紐付け完了通知が完了；トリガーソースが異なる。 | 四端クローズドループがすべて正しく、招待メールと紐付け完了通知を明確に区別できる。 | 必須：設定の凍結、同期時間の手配、データのクリーンアップ。 |
| T12-02 状態駆動コンテンツ開放回帰 | 紐付け済み顧客、少なくとも2段階の状態とコンテンツテンプレート。 | 状態を変更し時刻を記録。 | 同期をトリガー/待機し、B/C、ログを確認。 | 状態スイッチがオンの場合、ラベル権限を校正；初回フィールドの書き戻し/メールなし。 | コンテンツ範囲が新状態に応じて変化し、ログ/時刻を追跡可能。 | 同期の制御と状態復元を支援。 |
| T12-03 運用日常チェックプロセス | 既存設定、メール、成功・失敗サンプル。 | 運用パスに従ってテンプレート、顧客、メールを確認。 | 管理者は設定/ログを確認；運用担当者は許可ページを確認し異常を引き継ぐ。 | 新規業務アクションなし。 | ロールが日常チェックを完了できる；異常処理ができない場合、明確な南京/技術サポート引き継ぎ情報がある。 | 実メニュー権限とサポート連絡先を提供。 |
| T12-04 回帰範囲確認 | いずれかの欠陥が修正済みで、影響を受けるモジュールが明確。 | 欠陥の影響に応じて顧客を準備。 | 本リストに従い、影響を受けるケースとその主導線/異常関連項目を実行。 | 実際のアクションで検証；関連しないメールが誤って再送されないこと。 | 欠陥ケースが期待どおりであり、関連線に回帰がなく、証拠が完全。 | バージョン、デプロイ時間、変更範囲、ロールバック戦略を確認。 |

## 8. テスト範囲の補足と実行条件

元の67件の業務ケースは主幹をカバーするものとして保持；新規T00の5件の環境制御ケースを追加し、3つの省略不可なテストシーンを固定化：テストデータのリセットとメールの相互干渉防止、定期/手動同期トリガーの可観測性、クロス端末最終状態の照合。これらは追加機能要件ではなく、各クロス端末ケースが繰り返し実行可能で明確な結果判断ができるための必須条件である。

以下の情報はRENO自身が記録し、南京側が一度ビジネス口径を説明した後でのみ、関連項目に真実の結論を下すことができる：最後に正しく保存された連携設定の時刻とtest-jpタイムゾーン；`7a87c2addf`のテンプレート名、用途、トリガー条件、期待コンテンツ；テスト顧客プールとリセット方法；管理者同期記録。制御された失敗シミュレーションまたはバックグラウンドデータガバナンスが未手配の場合、対応する制御異常ケースのみ「実施または判定不可（環境手配待ち）」として記録し、期待どおりとして記録してはならない。