# 07-同期ログとトレーサビリティ

## 改訂履歴

| 日付 | バージョン | 変更タイプ | 変更概要 | 変更者/ソース |
| --- | --- | --- | --- | --- |
| 2026-07-20 | v0.2 | 重大な要件変更 | フロント側の同期ログを「同期バッチリスト → バッチ顧客リスト → 顧客同期詳細ポップアップ」から2層リストに収束。顧客同期詳細ポップアップを削除し、顧客行には氏名、メールアドレス、双方のID、統合後の同期結果（簡潔な変更サマリーを含む）のみを表示。 | AI（要件に基づき変更） |
| 2026-07-16 | v0.1 | 重大な要件変更 | 同期ログの検索条件を開始時間、終了時間に収束。顧客名、顧客メールアドレス、KASIKA ID、VISTA ID、その他の時間以外の検索条件とヒットハイライト要件を削除。 | AI（要件に基づき変更） |

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

本モジュールは、KASIKA 二期の顧客同期データに関連する同期、フィールドスナップショット、`customer_status` タグ設定、権限判定、削除/誤バインド対応、失敗ステータスのログ記録とトレーサビリティ要件を専門に定義する。

### 製品目標

- すべての同期データの追加・削除・変更がトレーサブルであることを保証する。
- 同期失敗、権限変更、`customer_status` タグ設定の変更、削除/誤バインド対応の結果を特定・説明可能にする。本期ではフロントエンドの再試行エントリは提供しないが、ログには失敗フェーズ、次のアクション、その後の自動チェック基準を明確に記録する必要がある。
- バックエンドの誤バインド対応後の履歴 KASIKA フィールド保持、再バインド禁止マーク、その後ブロックされた自動バインド試行がトレーサブルであることを保証する。
- B 端末管理者が KASIKA 連携管理ページから開始時間と終了時間でログを照会できるようにする。
- 顧客ページ、`customer_status` タグ設定、権限テンプレート、顧客同期タスクに統一されたログ機能を提供する。
- `08-KASIKA入口页与VISTA首次访问开户.md` で発生する KASIKA 入口ページ訪問、KASIKA 顧客検証、メールアドレス検証、パスワード設定、初回口座開設、KASIKA 入口ページバインドのログをカバーする。

### 本モジュールに含まれないもの

- 顧客リストと顧客詳細のページ操作レイアウトは定義しない。
- 三者間フィールドマッピングルールは定義しない。本期では三者間マッピングページのコメントは保留する。
- タグ権限テンプレートの認可計算ルールは定義しない。
- KASIKA 連携設定フォームの保存成功、保存失敗、新規追加、変更、クリアは記録しない。

上記の内容はそれぞれ `05A-顾客列表页.md`、`05B-顾客详情页.md`、`05C-顾客权限页.md`、`bak-04-第三方字段映射与权限判定.md`、`02-顾客标签管理.md` に属する。

## 2. ログ記録範囲

| 項目 | 内容 |
| --- | --- |
| ユースケース名 | KASIKA 連携関連操作ログの記録 |
| トリガーソース | システム、営業担当者、営業マネージャー、B 端末管理者 |
| ページ範囲 | KASIKA 連携管理ページ - 同期ログ |

### 要件詳細

1. すべての同期データの追加・削除・変更はログを記録しなければならない。
2. ログタイプには以下を含む：
   - 初回バインド時の `VISTAURL` および該当する場合の `VISTAPWD` の書き戻し。
   - KASIKA -> VISTA 同期。
   - バックエンドの誤バインド対応。
   - VISTA 顧客の作成、更新、削除、誤バインド対応。
   - KASIKA 側の疑似削除またはバインド異常マーク。
   - 第三者フィールドスナップショットの保存と変更。
   - `customer_status` タグ設定の判定。
   - 権限計算。
   - 履歴フィールドの再判定。
   - タグ権限テンプレート変更後の権限計算。
   - 定期同期バッチ。
   - KASIKA 入口ページ訪問。
   - 初回訪問時のメールアドレス検証とパスワード設定。
   - 初回バインド自動返信メール送信。
   - 失敗ステータスとその後のチェック。
3. KASIKA 連携設定フォームの保存成功、保存失敗、新規追加、変更、クリアは同期ログに書き込まない。設定ページではページの Toast で保存結果のみをフィードバックする。
4. 本期では同期ログの保存期間、アーカイブ戦略、ログクリーンアップルールを個別に設計しない。
5. 同期ログはプロジェクトデータのライフサイクルに従って保持する。プロジェクト有効期間中、削除類、誤バインド対応類、権限変更類のログは個別にクリアできない。
6. プロジェクト満了時にデータをクリアする場合、ログデータはプロジェクトデータとともに一括処理する。
7. ログは手動操作とシステムタスクを区別する必要がある。
8. ログには VISTA アクセスパスワードの平文、API KEY の平文、Secret Key の平文などの機密情報を記録してはならない。アクセスパスワードの同期に関わる場合は、同期成功有無、同期時間、対象顧客、失敗理由のみを記録する。

### 検証基準

- 同期、`customer_status` タグ設定、権限判定、削除/誤バインド対応にすべてログがある。
- KASIKA 連携設定フォームの保存成功、保存失敗、新規追加、変更、クリアは同期ログに書き込まれない。
- 手動操作とシステムタスクを区別できる。
- プロジェクト有効期間中、削除類、誤バインド対応類、権限変更類のログは個別にクリアできない。
- ログ明細に VISTA アクセスパスワードの平文、API KEY の平文、Secret Key の平文は表示されない。

## 3. ログフィールド

| 項目 | 内容 |
| --- | --- |
| ユースケース名 | ログ明細の表示 |
| 操作者 | B 端末管理者 |
| ページ範囲 | KASIKA 連携管理ページ - 同期ログ |

### 要件詳細

1. ログフィールドには少なくとも以下を含む：
   - プロジェクト。
   - ログタイプ。
   - トリガー方式。
   - 操作者またはシステムタスク。
   - 操作時間。
   - VISTA 顧客 ID。
   - KASIKA customer_id。
   - メールアドレス。
   - バインド関係の変化。
   - 操作結果。
   - 結果分類。
   - 処理フェーズ。
   - エラーコード。
   - ページサマリー。
   - 失敗理由。
   - 次のアクション。
   - 後続処理ステータス。
   - 同期バッチ ID。
   - インポートバッチ ID。
   - KASIKA process_id。
   - KASIKA 処理ステータス。
   - 影響顧客数。
   - 自動バインド後の VISTA 顧客 ID と KASIKA customer_id。
   - バックエンドの誤バインド対応または VISTA 顧客削除時に KASIKA 側の HOMEVISTA アクセスフィールドをクリアしなかった場合の処理結果。
   - VISTA がバインド済み顧客を削除した場合の有効な KASIKA バインド関係のクリーンアップ結果、バインド無効ステータス、履歴バインド保持結果。
   - バックエンドの誤バインド対応時のバインド関係変更と権限再計算結果。
   - バックエンドの誤バインド対応時に保持した履歴 KASIKA `customer_id`、メールアドレス、`customer_status` サマリー。
   - バックエンドの誤バインド対応後の KASIKA 再バインド禁止マーク。
   - 後続の同期または KASIKA 入口ページが再バインド禁止マークによりスキップまたはブロックされた処理結果。
   - 初回バインド時の KASIKA 側 HOMEVISTA アクセスフィールド書き込み結果。
   - 初回バインド自動返信メール送信結果、自動返信ID、失敗サマリー。
   - フィールドスナップショット変更サマリー。
   - `customer_status` タグ設定結果サマリー。
   - `customer_status` 状態権限自動更新スイッチの状態。
   - `customer_status` 状態変更前後のフィールド値。
   - 状態タグ調整結果。現在の状態と同名のタグの補完、新タグの追加、旧タグの削除、同名タグなしのスキップ、部分成功結果を含む。
   - 権限変更サマリー。
   - API 呼び出し制限または同時受付制限の理由。
   - KASIKA 入口ページのアクセスソース。
   - メールアドレス検証結果。
   - パスワード設定結果。パスワードの平文は記録しない。
   - 初回訪問の口座開設ステータス。
   - バッチで実際に取得し処理に参加した KASIKA 顧客数。
   - 今回の新規バインド数、更新完了数、失敗/待処理数。3つの定義は同期完了ポップアップと一致しなければならない。
   - 同一プロジェクトの同期タスクロック競合記録。競合時に既存タスクのトリガー方式とトリガー時間を含む。機密パラメータは記録しない。
2. `customer_status` タグ設定と権限判定ログは、使用したフィールドスナップショット、フィールド値、ヒットした同名タグ、同期調整が発生したかどうか、調整前後の顧客タグ結果サマリーをトレースできる必要がある。
3. フィールドスナップショット本体はログに保存しない。ログにはフィールドスナップショットの保存、更新、変化なし、失敗などの処理プロセス、および変更フィールド、変更前後サマリー、同期バッチ、処理結果のみを記録する。
4. 削除、自動バインド、バックエンドの誤バインド対応ログには、操作前後のバインド関係を記録する必要がある。VISTA がバインド済み顧客を削除した場合、有効な KASIKA バインド関係のクリーンアップ結果、バインド無効ステータス、履歴 KASIKA フィールド保持結果、および本期で KASIKA 側に保存済みのアクセスリンクとアクセスパスワードをクリアしなかった処理結果を記録する必要がある。バックエンドの誤バインド対応ログには、履歴 KASIKA `customer_id`、メールアドレス、`customer_status` の保持結果、および再バインド禁止マークの書き込み成功有無も記録する必要がある。
5. バッチタスクのログは、個別顧客の明細を表示できる必要がある。
6. 顧客レベルのフロント側同期結果は統一して「同期更新成功」「変化なし未更新」「同期更新失敗」とする。
7. バックエンドログは、開発実装に応じて内部処理フェーズ、エラーコード、元の失敗理由、後続処理ステータスを記録できる。製品要件は同期アルゴリズム、処理順序、フェーズ分割を固定しない。
8. エラーコード、ページサマリー、次のアクションは「同期失敗プロンプトとエラー情報サマリー」に基づいて統一生成する。`04-统一顾客联动同步流程.md` はトリガーソース、業務ルール、フロント側結果基準を定義する責任を持ち、具体的な同期実装方式は定義しない。
9. ログは2層表示構造を採用する（プロトタイプとインタラクション実装）：
   - 第1層は「同期バッチ」層。1件のレコードが1回の同期バッチに対応する（単一同期も1件のバッチレコードで表す）。
   - 第2層は「現在のバッチ顧客リスト」独立ページ。そのバッチ内で同期に参加した顧客リスト、同期結果、結果説明を表示する。この層では完全なフィールドスナップショット、内部処理フェーズは表示せず、顧客同期詳細ポップアップも提供しない。
10. リスト層のオブジェクトフィールド表示：
    - 単一顧客バッチ：その顧客名を表示（必須項目）。
    - 複数顧客バッチ：「全 N 名の顧客」を表示。
11. 同期バッチリストで、単一顧客バッチか複数顧客バッチかを問わず、「結果を表示」をクリックすると「現在のバッチ顧客リスト」独立ページに入る。
12. バッチ顧客リストには次の3類の情報を固定表示する：
    - 顧客：氏名、メールアドレス。
    - 関連 ID：KASIKA customer_id、VISTA 顧客 ID。
    - 同期結果：同期更新成功、変化なし未更新、同期更新失敗。さらに管理者向けのページサマリーを1件付与する。同期成功かつ変更がある場合、サマリーには最大3つの変更フィールド名を補足できる。変化がない場合は「今回フィールド変更なし」を明確に表示する。
13. バッチ顧客リストには「顧客詳細」ボタン、顧客同期詳細ページ、顧客同期詳細ポップアップを提供しない。エラーコード、失敗フェーズ、KASIKA process_id、KASIKA 処理ステータス、マスク処理済みのリクエスト/レスポンスサマリー、完全な `customer_data` スナップショット、フィールド変更前後の値、後続処理範囲はすべてバックエンドのフォールトトレランス/トレーサビリティフィールドとし、B 端末の同期ログでは表示しない。
14. KASIKA `customer_data` の完全なスナップショットは、サーバー側のフォールトトレランスと管理された調査用データとしてのみ保存し、B 端末のリスト、詳細ページ、ダウンロード、インターフェース読み取りエントリは提供しない。スナップショット保存失敗時も失敗フェーズと理由を記録しなければならないが、B 端末のページ表示範囲は変更しない。
15. 顧客レベルの同期結果には、開発内部フェーズや中間状態を表示しない。バッチ実行中は「同期中」のみを記録し、フロント側に疑似進捗、処理中数量、予定完了時間を返さない。タスク完了後、顧客結果は同期更新成功、変化なし未更新、同期更新失敗に分類し、バッチ層では新規バインド、更新完了、失敗/待処理で集計する。
16. 一括同期は手動停止またはキャンセルをサポートしない。一括取得、VISTA ローカル比較/バインド、CSV 一括書き戻しは、完了後にのみ精算できるバックエンドタスクとして扱わなければならない。タスクロック競合、システム異常失敗、部分的な業務待処理は、それぞれ理由とトレーサブルなバッチを記録する。

### 検証基準

- ログはプロジェクト、顧客、KASIKA customer_id、メールアドレス、同期バッチまで特定できる。
- 権限変更は変更サマリーを確認できる。
- 削除と誤バインド対応は操作前後のバインド関係を確認できる。VISTA がバインド済み顧客を削除した場合、有効なバインド関係のクリーンアップとバインド無効ステータスを確認できる。
- 誤バインド対応は履歴 KASIKA フィールド保持結果と再バインド禁止マークを確認できる。その後にブロックされた自動バインド試行は、そのマークまでトレースできる。
- バッチタスクと単一顧客タスクの両方で独立した顧客リストページに入り、顧客氏名、メールアドレス、双方のID、統合後の同期結果を確認できる。ページには顧客同期詳細ポップアップは提供されない。
- KASIKA が process_id または処理ステータスを返した場合、ログでトレースできる。
- フロント側の顧客レベル同期結果は同期更新成功、変化なし未更新、同期更新失敗のみを表示する。バックエンドログでは業務待処理、部分失敗、システム異常失敗、タスクロック競合などの理由分類を引き続き区別できる。
- ログ明細は統一エラーコード、ページサマリー、次のアクション、フィールド変更を保存し、同期タスクポップアップ、バッチ顧客リスト、顧客詳細の KASIKA 連携モジュールで再利用できる。KASIKA `customer_data` スナップショットはサーバー側のフォールトトレランス保存のみで、B 端末への再利用や表示は行わない。

## 4. ログの照会とフィルタリング

| 項目 | 内容 |
| --- | --- |
| ユースケース名 | 同期ログと権限ログの照会 |
| 操作者 | B 端末管理者 |
| ページ範囲 | KASIKA 連携管理ページ - 同期ログ |

### 要件詳細

1. 同期ログは以下の照会条件のみをサポートする：
   - 開始時間。
   - 終了時間。
2. 同期ログのエントリは KASIKA 連携管理ページでのみ B 端末管理者に表示する。
3. B 端末管理者が同期ログに入った後は、開始時間と終了時間でのみログを照会できる。ページには顧客名、顧客メールアドレス、KASIKA ID、VISTA ID、その他の時間以外の照会条件を提供してはならない。
4. ログリストはバッチサマリーを表示する。バッチか単一顧客バッチかを問わず、独立した顧客リストページに入り、顧客リストと統合後の同期結果を表示する。完全なトレーサビリティフィールドはバックエンドログに保持する。
5. 本期では同期ログのエクスポート機能を提供しない。
   - ログリストは選択した時間範囲のバッチのみを返す。詳細に入った後は、照会条件によって顧客明細行をハイライトしたり非表示にしたりしない。

### ユースケース：時間範囲による同期ログの照会

- 前提：B 端末管理者が KASIKA 連携管理ページの「同期ログ」ページに入っている。
- 操作：開始時間と終了時間を入力し、「照会」をクリックする。
- 期待結果：
  - システムは実行時間がその時間範囲内にある同期ログバッチのみを返す。
  - ページには開始時間と終了時間の2つの照会入力項目のみを表示する。顧客名、顧客メールアドレス、KASIKA ID、VISTA ID、プロジェクト、ログタイプ、操作結果、操作者またはシステムタスクなどの照会項目は表示しない。
  - 「リセット」をクリックすると開始時間と終了時間がクリアされ、全ログの表示に戻る。

### 検証基準

- 開始時間と終了時間のみでログをフィルタリングできる。
- KASIKA 連携管理ページからログに入る場合、B 端末管理者は時間範囲でのみ対応するログバッチを照会できる。
- ページには顧客名、顧客メールアドレス、KASIKA ID、VISTA ID、その他の時間以外の照会条件を表示しない。また、顧客照会ヒット結果による明細行のハイライトも行わない。
- 顧客詳細とバッチタスク結果には完全な同期ログのエントリを提供しない。
- ページには同期ログのエクスポートエントリを提供しない。

## 5. 失敗処理とバッチのトレーサビリティ

| 項目 | 内容 |
| --- | --- |
| ユースケース名 | 失敗理由と後続処理の表示 |
| 操作者 | B 端末管理者 |
| ページ範囲 | KASIKA 連携管理ページ - 同期ログ、同期タスクポップアップ、バッチ顧客リスト、顧客詳細の KASIKA 連携モジュールサマリー |

### 要件詳細

1. 本期ではフロントエンドの手動再試行エントリを提供しない。失敗ログには失敗理由、失敗フェーズ、次のアクション、後続システム自動チェック基準のみを表示する。
2. 失敗フェーズをマークする必要があるタイプには以下を含む：
   - 初回バインド時の `VISTAURL` または該当する場合の `VISTAPWD` の書き戻し失敗。
   - KASIKA -> VISTA の取得または VISTA への書き込み失敗。
   - KASIKA 身份情報の取得または確認失敗。
   - フィールドスナップショット保存失敗。
   - 権限計算失敗。
   - タグ権限テンプレート変更後の権限計算失敗。
3. 削除類の失敗は失敗結果と失敗理由のみを記録し、再試行エントリは提供しない。
4. 後続のシステム自動フローが同じオブジェクトを再度処理する場合、新しいログを生成し、顧客とバッチの次元から以前の失敗記録をトレースできる必要がある。
5. 一括同期は部分成功、部分失敗を許可する。
6. 成功項目は直ちに有効になり、成功ログを記録する。失敗項目は失敗理由、失敗顧客明細、後続処理ステータスを記録する。
7. 一括同期は一部の顧客失敗によって同一バッチの成功済み顧客をロールバックしない。
8. 本期ではページから失敗項目を個別に再試行することはサポートしない。後続のシステム自動フローが再処理する場合、成功済みフェーズを重複作成または重複バインドしてはならない。
9. バッチタスク完了後、以下を記録しトレースできる必要がある：
   - 実際に取得し処理に参加した KASIKA 顧客の総数。
   - 新規バインド数。
   - 更新完了数。
   - 失敗/待処理数。
   - 成功、変化なし、失敗、スキップ、KASIKA 受付済みだが未完了などのバックエンド結果分類。
   - KASIKA process_id、CSV 書き戻し結果、必要な失敗理由。
   - 手動トリガーがタスクロックで拒否された場合、競合理由とその時点で占有していたタスク識別子を記録する。新しい同期バッチは作成しない。
10. バッチタスク完了後、ログで各顧客の処理結果を確認できる必要がある。
11. バッチタスクが KASIKA に受理されたが未完了の場合、タスク層のステータスは「KASIKA 処理待ち」と表示できる。顧客レベルの最終結果は、今回の比較結果が明確になった後に3つのフロント側結果に分類する。
12. 業務待処理項目はフロント側の顧客レベル結果では「同期更新失敗」に分類する。バックエンドログでは、マッチング競合、バインド競合などの理由を保持し続け、管理者がソースデータを修正し、バックエンドの誤バインド対応を行った後、後続のシステム自動フローによる再チェックを待てるようにする。`customer_status` に同名タグがない場合はインターフェース異常とはせず、バックエンドではスキップまたは変化なしの理由として記録する。
13. 変化なし項目は失敗としない。チェック時間、トリガー方式、変化なし結果のみを記録する。
14. 部分失敗項目は成功フェーズと失敗フェーズをマークする必要がある。後続のシステム自動フローが再処理する場合、成功済みフェーズに基づいて継続し、成功済みの作成やバインドを重複実行しない。
15. 後続のシステム自動チェックは、次のトリガー条件を満たす同期フローのみで実行する。毎時の定期同期、B 端末管理者または営業マネージャーが顧客リストページの「全量同期チェック」をクリック、初回バインドアクセスフィールド書き戻し失敗の補償を含む。4 つの API KEY が不完全な場合、毎時の定期再チェックは実行せず、アクセスフィールドの書き戻しも実行しないが、失敗ログと後続処理ステータスは保持する。管理者または営業マネージャーは 4 つの API KEY が完全な場合に「全量同期チェック」で再チェックをトリガーできる。

### 検証基準

- 失敗項目の失敗理由を確認できる。
- 顧客ページとログページにはフロントエンドの再試行エントリを提供しない。
- 後続のシステム自動フローが同じオブジェクトを再度処理する場合、新しいログが生成され、顧客とバッチの次元から以前の失敗記録をトレースできる。
- バッチタスクの集計結果と個別顧客結果を確認できる。
- バッチタスクが部分失敗した場合、成功済み項目はロールバックされず、後続の再処理で成功済みフェーズを重複作成または重複バインドしない。
- フロント側の「同期更新失敗」に含まれる業務待処理、インターフェース失敗、KASIKA 処理待ちなどの理由は、バックエンドログで引き続き区別でき、同一のインターフェース異常として誤って計上しない。

## 6. KASIKA バッチタスクステータスと呼び出し制限のトレーサビリティ

| 項目 | 内容 |
| --- | --- |
| ユースケース名 | KASIKA バッチタスク処理ステータスのトレース |
| 操作者 | B 端末管理者 |
| ページ範囲 | KASIKA 連携管理ページ - 同期ログ、バッチタスクログ |

### 要件詳細

1. HOMEVISTA アクセスリンク / アクセスパスワードの KASIKA への一括書き込み、KASIKA 顧客の一括取得、その他の一括連携タスクは、バッチタスクログを生成する必要がある。本期では VISTA 顧客削除により KASIKA へ一括削除またはフィールドクリアタスクを提出しない。
2. KASIKA が `process_id` を返した場合、ログはその ID を保存しなければならない。
3. KASIKA が処理ステータスを返した場合、ログはステータスの意味を表示する必要がある。以下を含む：
   - 受理済み。
   - 処理中。
   - 処理完了。
   - 処理失敗。
4. KASIKA が呼び出し回数上限を返した場合、ログは「呼び出し制限」と記録し、KASIKA が返したエラー情報、処理ステータス、理由サマリーを表示する。
5. KASIKA が未処理の KASIKA 一括新規追加、更新、削除リクエストがあることを返した場合、ログは「既存タスク処理中」と記録し、同種タスクの重複提出をブロックする。
6. KASIKA が認証失敗、権限不足、IP 制限を返した場合、ログは同期タスクの認証または権限失敗と記録し、管理者に API KEY または KASIKA 側権限の確認を促す。
7. バッチタスク完了後、ログは KASIKA が返したサマリー情報を表示する必要がある。
8. KASIKA が `error_rows_csv_download_url` などのエラー顧客リスト URL を返した場合、VISTA は同期ログに KASIKA が返したエラープロンプト、エラー行 URL、`process_id`、バッチステータス、処理時間のみを保存すればよい。
9. 本期では VISTA による KASIKA エラー CSV ファイルのダウンロード、解析、長期アーカイブは要求しない。
10. KASIKA API には呼び出し回数と同時受付制限が存在する可能性があるため、システムは拒否された提出の時間、理由、操作者をログに保持し、管理者が KASIKA の返信情報に基づいて後続処理を判断できるようにする必要がある。
11. 本期では VISTA が具体的な残り待ち時間を独自に計算または表示することは要求しない。KASIKA が再提出可能時間または残り待ち時間を明確に返した場合、VISTA はそのまま表示できる。それ以外の場合は推定しない。

### 検証基準

- KASIKA が process_id を返した場合、ログに保存・表示できる。
- KASIKA バッチタスクは受理済み、処理中、完了、失敗を区別できる。
- 呼び出し回数上限、既存タスク処理中、認証失敗、権限不足などの理由を照会できる。
- ページは KASIKA が返したエラー情報、処理ステータス、理由サマリーにのみ基づいてユーザーに提示する。具体的な残り待ち時間は独自に推定しない。
- KASIKA がエラー顧客リスト URL を返した場合、ログにエラープロンプトと URL を保存するが、エラー CSV ファイルのダウンロード、解析、長期アーカイブは要求しない。
- KASIKA に受理が拒否されたバッチタスクにもログがある。

## 7. 同期失敗プロンプトとエラー情報サマリー

本章では統一された同期失敗プロンプトとエラー情報辞書を定義する。`05A-顾客列表页.md` の同期タスクポップアップとバッチ顧客リストは軽量サマリー表示を担当する。`05B-顾客详情页.md` は KASIKA 連携モジュールのサマリーのみを表示し、`05C-顾客权限页.md` は KASIKA 同期失敗詳細を表示しない。`04-统一顾客联动同步流程.md` はトリガーソース、業務ルール、フロント側結果基準を担当する。本章は統一エラー分類、ページサマリー、次のアクション、後続処理基準、ログマスク処理ルールを担当する。具体的な内部処理フェーズは開発が同期実装に応じて記録する。

### プロンプト表示階層

1. 顧客リストページには KASIKA 同期ステータス列や最近の同期サマリーを新規追加しない。同期タスク結果ページとバッチ顧客リストでは「フロント側同期結果 + ページサマリー」を表示できる。例：「同期更新失敗：メールアドレス重複。同期ログを確認してください」。
2. 顧客詳細ページは `概要` タブの KASIKA 連携モジュールでのみバインドステータス、最近の同期時間/結果などのサマリーを表示する。処理フェーズ、エラーコード、後続処理ステータス、次のアクションは表示しない。関連する詳細情報は同期ログに入る。
3. バッチタスク結果ページは同期更新成功、変化なし未更新、同期更新失敗で顧客結果数を表示する。タスク実行中は同期中のみを記録し、完了後に実際の結果を表示する。バッチ顧客リストに入ることができる。
4. 同期ログは「同期バッチリスト -> バッチ顧客リストページ」で表示する。バッチ顧客リストは顧客識別情報と統合後の同期結果のみを表示し、今回の同期で取得した完全な `customer_data` スナップショットはサーバー側のフォールトトレランス保存のみで、B 端末での表示は提供しない。
5. ページ表示では API KEY、Secret Key、HOMEVISTA アクセスパスワードの平文、完全なリクエストヘッダー、完全なリクエストボディ、完全なレスポンスボディを露出してはならない。
6. KASIKA が返した元のエラー情報に機密情報が含まれる場合、ページとログはマスク処理後の理由サマリーのみを保存する。
7. 同期ログはマスク処理後の KASIKA リクエスト/レスポンスサマリーを保存でき、管理者と開発が失敗フェーズを特定するために使用する。完全な KASIKA リクエスト/レスポンス原文は保存してはならない。

### エラー情報フィールド

| フィールド | 説明 |
| --- | --- |
| エラーコード | システム内部で統一識別に使用するコード。ページ、ログ、統計で再利用する |
| フロント側結果 | 同期更新成功、変化なし未更新、同期更新失敗 |
| バックエンド理由分類 | 処理待ち、処理中、成功、失敗、部分失敗、業務待処理、変化なし、スキップ、KASIKA 処理待ちなど。開発がログ実装に応じて詳細化する |
| 処理フェーズ | 照会/取得、マッチング、作成、バインド保存、アクセスフィールド書き込み、フィールドスナップショット保存、`customer_status` タグ設定、アクセスフィールド書き戻し、権限判定、自動返信メール送信、KASIKA 入口ページ訪問、KASIKA 入口ページ顧客検証、メールアドレス検証、パスワード設定、初回訪問口座開設 |
| ページサマリー | 顧客リストとバッチ結果ページで表示する短い文案 |
| ユーザー向け説明 | 詳細ページまたはログ詳細で表示できる説明 |
| 次のアクション | ユーザーが実行できる処理アクション |
| 後続処理ステータス | システムが後続で再チェック可能、先にキーを処理する必要あり、先に権限を処理する必要あり、手動処理が必要、処理不要 |
| 後続処理範囲 | 後続で顧客全体を再チェック、失敗フェーズのみ継続、フィールド書き込みのみ継続、権限計算のみ継続など |
| ログ記録要件 | 保持が必要なログフィールドと機密情報の処理要件 |

### 統一エラー辞書

| エラーコード | 結果分類 | 処理フェーズ | ページサマリー | ユーザー向け説明 | 次のアクション | 後続処理ステータス | ログ記録要件 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| `KASIKA_QUERY_FAILED` | 失敗 | 照会/取得 | KASIKA 照会失敗 | システムが KASIKA 顧客またはタスクステータスを読み取れませんでした。 | 後続のシステム自動チェックを待つ。継続して失敗する場合は KASIKA 接続とアカウント権限を確認する。 | システムが後続で再チェック可能 | インターフェースタイプ、失敗サマリー、KASIKA customer_id またはメールアドレスを記録。完全なリクエスト/レスポンスは記録しない。 |
| `KASIKA_AUTH_FAILED` | 失敗 | 照会/取得 | KASIKA 認証失敗 | KASIKA が認証失敗を返しました。現在の API KEY は利用できません。 | 管理者が API KEY を確認し、設定復旧後に後続のシステム自動チェックを待つ。 | 先にキーを処理する必要あり | 認証失敗サマリーを記録。API KEY、Secret Key は必ずマスク処理する。 |
| `KASIKA_PERMISSION_DENIED` | 失敗 | 照会/取得 | KASIKA 権限不足 | KASIKA アカウントに現在のインターフェースを実行する権限がありません。 | 管理者が KASIKA アカウント権限を確認するか、API KEY を交換し、設定復旧後に後続のシステム自動チェックを待つ。 | 先に権限を処理する必要あり | 権限不足サマリー、インターフェースタイプ、操作者を記録。 |
| `KASIKA_RATE_LIMITED` | KASIKA 処理待ち | 照会/取得 | KASIKA 呼び出し制限 | KASIKA が呼び出し回数制限または一時的な提出不可を返しました。 | KASIKA の返信情報に基づいて後続の自動チェックを待つ。再提出可能時間が返された場合はそのまま表示する。 | システムが後続で再チェック可能 | 制限理由、返された再提出可能時間または処理ステータスを記録。待ち時間は独自に推定しない。 |
| `KASIKA_TASK_IN_PROGRESS` | KASIKA 処理待ち | 照会/取得 | KASIKA 既存タスク処理中 | KASIKA で現在同種のバッチタスクが処理中のため、重複提出できません。 | 現在のタスク完了後に後続フローで再提出する。 | システムが後続で再チェック可能 | process_id、タスクステータス、トリガー者、バッチを記録。 |
| `MATCH_DUPLICATE_EMAIL` | 業務待処理 | マッチング | メールアドレスが複数の顧客に一致 | メールアドレスが一意ではないため、システムは自動バインドできません。 | VISTA または KASIKA 側のメールアドレスを修正し、重複顧客をクリアした後、後続のシステム自動チェックを待つ。本期では手動選択バインドはサポートしない。 | 手動処理が必要 | 候補数、メールアドレスを記録。自動バインドはしない。 |
| `MATCH_DUPLICATE_PHONE` | 業務待処理 | マッチング | 電話番号が複数の顧客に一致 | 電話番号が一意ではないため、システムは自動バインドできません。 | VISTA または KASIKA 側の電話番号を修正し、重複顧客をクリアした後、後続のシステム自動チェックを待つ。本期では手動選択バインドはサポートしない。 | 手動処理が必要 | 候補数、電話番号を記録。自動バインドはしない。 |
| `MATCH_CANDIDATE_ALREADY_BOUND` | 業務待処理 | マッチング | 候補顧客はバインド済み | 候補顧客には既に有効なバインド関係が存在するため、重複バインドできません。 | 既存バインドを確認する。誤バインドの場合は管理者がバックエンドの誤バインド対応を行った後、後続のシステム自動チェックを待つ。 | 手動処理が必要 | 候補顧客 ID、バインド済みオブジェクトを記録。 |
| `BOUND_TARGET_NOT_FOUND` | 業務待処理 | マッチング | バインド対象が存在しない可能性 | バインド済みの相手側顧客の存在を確認できません。システムは有効なバインド関係を自動クリーンアップしません。 | 管理者が確認後、バックエンド対応を行うかトレーサビリティ保持のままにするかを判断する。 | 手動処理が必要 | 元のバインド関係、識別方法、異常マーク時間、トリガーバッチを記録。 |
| `VISTA_CREATE_FAILED` | 失敗 | 作成 | VISTA 顧客作成失敗 | KASIKA 顧客を VISTA 顧客として作成できませんでした。 | 失敗理由を修正した後、後続のシステム自動チェックを待つ。 | システムが後続で再チェック可能 | KASIKA customer_id、メールアドレス、氏名、失敗サマリーを記録。 |
| `BINDING_SAVE_FAILED` | 失敗 | バインド保存 | バインド保存失敗 | 顧客は作成に成功した可能性がありますが、双方のバインド関係の保存に失敗しました。 | 後続フローはバインド保存のみを継続する。作成に成功した顧客を重複作成してはならない。 | 失敗フェーズのみ継続 | 成功済みフェーズ、双方の顧客 ID、失敗サマリーを記録。 |
| `IDENTITY_WRITE_FAILED` | 失敗 | アクセスフィールド書き込み | アクセスフィールド書き込み失敗 | バインドは保存されましたが、`VISTAURL` または該当する場合の `VISTAPWD` の KASIKA への書き込みに失敗しました。 | 後続フローは失敗フィールドの書き込みのみを継続する。 | フィールド書き込みのみ継続 | 書き込みフィールド名と失敗サマリーを記録。アクセスパスワードは平文で記録してはならない。 |
| `IDENTITY_WRITE_PARTIAL_FAILED` | 部分失敗 | アクセスフィールド書き込み | アクセスフィールドの一部書き込み失敗 | `VISTAURL`、該当する場合の `VISTAPWD` の一部フィールドの KASIKA への書き込みに失敗しました。 | 後続フローは失敗フィールドの書き込みのみを継続する。 | フィールド書き込みのみ継続 | 失敗フィールド名を記録。アクセスパスワードはフィールド名と結果のみを記録し、値は記録しない。 |
| `SNAPSHOT_SAVE_FAILED` | 失敗 | フィールドスナップショット保存 | フィールドスナップショット保存失敗 | バインド関係は保存されましたが、KASIKA フィールドスナップショットが保存されませんでした。 | 後続フローはフィールドスナップショット保存と `customer_status` タグ設定のみを継続する。 | 失敗フェーズのみ継続 | KASIKA customer_id、同期バッチ、失敗サマリーを記録。 |
| `IDENTITY_CALLBACK_FAILED` | 失敗 | アクセスフィールド書き戻し | アクセスフィールドの KASIKA への書き戻し失敗 | VISTA 顧客とフィールドスナップショットは処理されましたが、`VISTAURL` または該当する場合の `VISTAPWD` の KASIKA への書き戻しに失敗しました。 | 後続フローは失敗フィールドの書き戻しのみを継続する。VISTA 顧客とフィールドスナップショットはロールバックしない。 | フィールド書き込みのみ継続 | 書き戻しフィールド名と失敗サマリーを記録。アクセスパスワードは平文で記録してはならない。 |
| `AUTO_REPLY_ID_MISSING` | スキップ | 自動返信メール送信 | 自動返信IDが未設定 | 初回バインドは完了しましたが、プロジェクトにバインド通知の自動返信IDが設定されていないため、システムは自動返信メールをトリガーしません。 | 管理者が自動返信IDを設定した後、後続の補償フローで再送信するかどうかを判断する。 | 手動処理が必要 | プロジェクト、VISTA 顧客 ID、KASIKA customer_id、トリガーバッチを記録。 |
| `AUTO_REPLY_SEND_FAILED` | 部分失敗 | 自動返信メール送信 | 自動返信メール送信失敗 | 顧客バインドとアクセスフィールドは処理されましたが、KASIKA 自動返信メールを送信できませんでした。 | 後続フローは自動返信メール送信のみを継続する。成功済みフィールドの重複作成、重複バインド、重複書き戻しはしない。 | 失敗フェーズのみ継続 | KASIKA customer_id、VISTA 顧客 ID、自動返信ID、失敗サマリー、トリガーバッチを記録。完全なリクエスト/レスポンスやアクセスパスワードの平文は記録しない。 |
| `ENTRY_PROJECT_INVALID` | 失敗 | KASIKA 入口ページ訪問 | 入口リンクが無効 | 現在のアクセス Host で VISTA プロジェクトを識別できないか、プロジェクトの入口が無効です。 | 顧客は正しいメールリンクを開き直す。継続して失敗する場合は営業に連絡する。 | 処理不要 | アクセス Host、解析結果、アクセス時間、セキュリティサマリーを記録。 |
| `ENTRY_KASIKA_UNAVAILABLE` | 失敗 | KASIKA 入口ページ顧客検証 | 顧客情報を確認できません | システムは暫時 KASIKA を通じて顧客情報を確認できません。 | しばらくして再試行する。継続して失敗する場合は管理者が KASIKA API KEY を確認する。 | システムが後続で再チェック可能 | KASIKA customer_id、プロジェクト、インターフェース失敗サマリーを記録。API KEY は必ずマスク処理する。 |
| `ENTRY_CUSTOMER_NOT_FOUND` | 失敗 | KASIKA 入口ページ顧客検証 | 顧客情報が存在しない | KASIKA でその顧客情報を取得できませんでした。システムは VISTA 顧客を作成しませんでした。 | メールリンクを確認するか、営業に連絡する。 | 処理不要 | KASIKA customer_id とプロジェクトを記録。完全なリクエスト/レスポンスは記録しない。 |
| `ENTRY_COOKIE_WRITE_FAILED` | 部分失敗 | KASIKA 入口ページ訪問 | アクセス統計識別 Cookie の書き込み失敗 | 顧客身份は KASIKA 検証を通過しましたが、システムは KASIKA 識別 Cookie を書き込みまたは確認できませんでした。 | 顧客の口座開設、ログイン、アクセスはブロックしない。後続のアクセス統計がその顧客に帰属できない可能性がある。 | 処理不要 | プロジェクト、KASIKA customer_id、アクセス Host、失敗サマリーを記録。Cookie の完全な値は記録しない。 |
| `ENTRY_EMAIL_VERIFY_FAILED` | 失敗 | メールアドレス検証 | メールアドレス検証失敗 | 入力されたメールアドレスが KASIKA 顧客のメールアドレスと一致しません。 | 顧客が登録メールアドレスを確認して再試行する。 | 処理不要 | 検証失敗結果とマスク処理済みメールアドレスサマリーを記録。完全なメールアドレス入力の平文は記録しない。 |
| `ENTRY_BOUND_EMAIL_MISMATCH` | 業務待処理 | 初回訪問口座開設 | バインド済みメールアドレス不一致 | この KASIKA 顧客は VISTA 顧客にバインド済みですが、KASIKA のメールアドレスがバインド済み VISTA 顧客のメールアドレスと一致しません。 | 顧客が口座開設や自動再バインドを続行することは許可しない。管理者が同期ログで確認後、解除またはバックエンド対応を行う。 | 手動処理が必要 | KASIKA customer_id、バインド済み VISTA 顧客 ID、マスク処理済みメールアドレスサマリー、トリガー時間を記録。 |
| `ENTRY_BINDING_CONFLICT` | 業務待処理 | 初回訪問口座開設 | バインド競合 | 入口ページでメールアドレスにより見つかった VISTA 顧客が他の KASIKA customer_id にバインド済みか、同一メールアドレスに複数の候補が存在するため、システムは自動バインドできません。 | 管理者が重複顧客または誤バインドを修正した後、後続の入口アクセスまたは同期フローによる再判定を待つ。 | 手動処理が必要 | 候補数、候補のバインドステータス、KASIKA customer_id、マスク処理済みメールアドレスサマリーを記録。 |
| `ENTRY_REBIND_FORBIDDEN` | 業務待処理 | 初回訪問口座開設 | 自動再バインドが禁止済み | この VISTA 顧客は削除により KASIKA の有効バインドが無効化されたか、バックエンド対応で再バインド禁止マークが付けられたため、入口ページは自動でバインドを復元しません。 | 復元が必要な場合は、バックエンドのデータガバナンスを行うか、別途復元要件を立てる。本期ではフロントエンドに復元エントリは提供しない。 | 手動処理が必要 | VISTA 顧客 ID、KASIKA customer_id、削除復元ステータスまたは再バインド禁止マーク、トリガー時間を記録。 |
| `ENTRY_PASSWORD_SET_FAILED` | 失敗 | パスワード設定 | パスワード設定失敗 | 顧客のアクセスパスワードを保存できませんでした。 | 顧客はページのプロンプトに従って再試行する。継続して失敗する場合は開発に調査を依頼する。 | システムが後続で再チェック可能 | VISTA 顧客 ID、KASIKA customer_id、失敗サマリーを記録。パスワードの平文は記録してはならない。 |
| `ENTRY_ACCOUNT_CREATE_FAILED` | 失敗 | 初回訪問口座開設 | 初回口座開設失敗 | システムは VISTA 顧客の作成またはバインドを完了できませんでした。 | しばらくして再試行する。継続して失敗する場合は管理者がログを確認する。 | システムが後続で再チェック可能 | 成功済みフェーズ、プロジェクト、KASIKA customer_id、失敗サマリーを記録。 |
| `ENTRY_ALREADY_BOUND` | 変化なし | KASIKA 入口ページ訪問 | 顧客はバインド済み | この KASIKA 顧客は既に VISTA 顧客にバインドされているため、今回のアクセスでは重複作成しません。 | 処理不要。 | 処理不要 | 既存のバインド関係とアクセス時間を記録。 |
| `CUSTOMER_STATUS_AUTO_UPDATE_OFF` | スキップ | `customer_status` タグ設定 | 状態権限自動更新がオフ | 新しい `customer_status` は保存されましたが、プロジェクトで自動更新スイッチがオフのため、システムは VISTA のタグと権限を更新しません。 | 最新ステータスに基づいて権限を更新する必要がある場合、管理者はスイッチをオンにした後、後続の同期または確認済みの補算フローを待つ。 | 処理不要 | スイッチステータス、フィールド変更前後の値、同期バッチを記録。タグは変更しない。 |
| `CUSTOMER_STATUS_TAG_NO_MATCH` | スキップ | `customer_status` タグ設定 | 同名タグなし | フィールドスナップショットは保存されましたが、`customer_status` フィールド値に対応する同名の VISTA タグがありません。 | 管理者は必要に応じて同名タグを作成するか、処理しないままにする。 | 処理不要 | フィールド値サマリーと同期バッチを記録。 |
| `CUSTOMER_STATUS_TAG_ADD_FAILED` | 失敗 | `customer_status` タグ設定 | 状態タグ追加失敗 | システムは新しい `customer_status` に対応する同名の VISTA タグを顧客に設定できませんでした。 | 後続フローは状態タグ設定のみを継続する。完了済みの顧客バインドやアクセスフィールド書き戻しはロールバックしない。 | 失敗フェーズのみ継続 | 新しい状態フィールド値、対象タグ、顧客 ID、失敗サマリー、同期バッチを記録。 |
| `CUSTOMER_STATUS_OLD_TAG_REMOVE_FAILED` | 部分失敗 | `customer_status` タグ設定 | 旧状態タグの削除失敗 | 新しい状態タグは追加に成功した可能性がありますが、前の状態に対応する旧タグを削除できませんでした。 | 後続フローは旧状態タグの削除と権限再計算のみを継続する。新タグの重複追加は避ける必要がある。 | 失敗フェーズのみ継続 | 新旧状態フィールド値、新タグ追加結果、旧タグ削除結果、顧客 ID、失敗サマリーを記録。 |
| `CUSTOMER_STATUS_TAG_UPDATE_PARTIAL` | 部分失敗 | `customer_status` タグ設定 | 状態タグ部分更新 | 状態タグ調整プロセスで一部の操作のみが成功しました。 | 後続フローは未完了のタグ更新ステップのみを処理し、最新のタグ結果に基づいて権限を計算する。 | 失敗フェーズのみ継続 | 各タグ操作の成功/失敗結果、フィールド変更前後の値、同期バッチを記録。 |
| `PERMISSION_CALC_FAILED` | 失敗 | 権限判定 | 権限計算失敗 | タグは処理されましたが、権限計算に失敗しました。 | 後続フローは権限計算のみを継続する。 | 権限計算のみ継続 | タグ、テンプレート、顧客 ID、失敗サマリーを記録。 |
| `NO_CHANGE` | 変化なし | 照会/取得 | 今回変化なし | 今回のチェックでは、同期または権限再計算が必要な変更は見つかりませんでした。 | 処理不要。 | 処理不要 | チェック時間、トリガー方式を記録。 |
| `UNKNOWN_ERROR` | 失敗 | その他 | 同期失敗 | 未分類のエラーが発生し、システムは今回の処理を完了できませんでした。 | 管理者がログ詳細を確認する。継続して失敗する場合は開発に調査を依頼する。 | システムが後続で再チェック可能 | セキュリティサマリー、関連バッチ、特定可能なオブジェクトを記録。機密情報は必ずマスク処理する。 |

### 辞書使用ルール

1. 同じ失敗は異なるページで同じエラーコードと同じページサマリーを使用しなければならない。
2. 顧客リストは長すぎる技術情報を表示してはならず、ページサマリーと次のアクションのみを表示する。
3. バッチ顧客リストの「同期結果」は、その顧客アカウントの今回の同期の同期結果説明と必要な変更フィールド名サマリーのみを表示する。処理フェーズ、エラーコード、後続処理ステータスなどのフィールドはバックエンドログのトレーサビリティのみに入り、フロント側の表示フィールドとはしない。
4. ログ詳細はマスク処理後の KASIKA 返信サマリー、システム内部失敗サマリー、関連バッチを表示できる。
5. 「業務待処理」はインターフェース失敗処理キューに入らない。ユーザーが処理した後、後続のシステム自動フローによる再チェックまたは再判定を待つ必要がある。
6. 「KASIKA 処理待ち」はシステム異常失敗と見なさない。KASIKA が process_id または処理ステータスを返した場合は、必ずログに保存しなければならない。
7. 「変化なし」は失敗と見なさず、失敗処理エントリを提供しない。
8. 同期失敗プロンプトの新規追加、統合、改名は、`05A-顾客列表页.md`、`05B-顾客详情页.md`、`05C-顾客权限页.md`、`04-统一顾客联动同步流程.md` と本ファイルの一貫性を同期確認する必要がある。
9. ログはマスク処理後のリクエスト/レスポンスサマリーを保持でき、インターフェース用途、ステータスコードまたは業務エラーコード、エラーサマリー、`process_id`、バッチステータス、エラー行 URL などの必要なトレーサビリティ情報を含む。完全なリクエストヘッダー、完全なリクエストボディ、完全なレスポンスボディは保存してはならない。
10. HOMEVISTA アクセスパスワード、API KEY、Secret Key はページサマリー、ユーザー向け説明、ログ明細に表示してはならない。
11. 開発調査で完全なメッセージが必要な場合は、サーバー側の管理されたデバッグまたは一時的な調査メカニズムで処理し、製品の同期ログには入れない。

### 検証基準

- 同期タスクポップアップ、バッチ顧客リスト、顧客詳細の KASIKA 連携モジュール、バックエンドログ詳細は同じエラーコードとページサマリーを使用する。
- フロント側の顧客レベル結果は統一して同期更新成功、変化なし未更新、同期更新失敗とする。バックエンドログは業務待処理、システム異常失敗、KASIKA 処理待ち、変化なしなどの理由分類を明確に区別できる。
- 失敗項目は後続処理範囲を特定でき、成功済みフェーズを重複実行しない。
- 機密情報はページサマリー、ユーザー向け説明、ログ明細に表示されない。

## 8. 権限と監査ルール

| 項目 | 内容 |
| --- | --- |
| ユースケース名 | ログ表示と監査の制御 |
| 操作者 | B 端末管理者 |
| ページ範囲 | KASIKA 連携管理ページ - 同期ログ |

### 要件詳細

1. B 端末管理者は KASIKA 連携管理ページから本プロジェクトの全 KASIKA 顧客同期データ関連ログを表示できる。
2. 営業担当者と営業マネージャーは完全な同期ログを表示できず、同期ログのページエントリも表示しない。
3. 同期タスクポップアップ、バッチ顧客リスト、顧客詳細の KASIKA 連携モジュール、同期情報ポップアップは必要なサマリーまたは現在の操作フィードバックのみを表示し、完全なログ照会は担わない。
4. 削除類ログ、誤バインド対応類ログ、権限変更ログは一般ユーザーが削除または変更できない。
5. 完全な同期ログのリスト、詳細、フィルタリング、照会インターフェースは B 端末管理者権限を検証しなければならない。営業マネージャーと営業担当者は直接リクエストを構築しても読み取ってはならない。
6. ログ記録自体は業務操作によって上書きされることを許可しない。

### 検証基準

- B 端末管理者のみが KASIKA 連携管理ページから完全な同期ログに入れる。
- 営業担当者と営業マネージャーは完全な同期ログを表示できず、同期ログのページエントリも表示しない。
- 完全な同期ログのリスト、詳細、フィルタリング、照会インターフェースは B 端末管理者のみが呼び出せる。営業マネージャーと営業担当者はインターフェース経由でも読み取ってはならない。
- 削除類、誤バインド対応類、権限変更類のログは業務ユーザーが削除できない。
- ログ詳細は編集によって上書きされない。
- ログはフィールドスナップショットの変更プロセスをトレースできるが、フィールドスナップショットの主保存場所とはしない。

## 9. 本モジュールの業務ルール

1. すべての顧客同期データ関連の自動タスクと手動操作はログを記録しなければならない。
2. すべての同期データの追加・削除・変更はログを記録しなければならない。
3. 削除類、自動バインド、バックエンドの誤バインド対応操作は、操作前後のバインド関係を記録しなければならない。初回バインドにより KASIKA 側の HOMEVISTA アクセスフィールドの書き込みまたは更新が発生する場合、書き込み結果を記録する必要がある。
4. KASIKA 側でバインド済み customer_id に対応する顧客が見つからない場合、システムは疑似削除またはバインド異常のマークのみを行い、VISTA 側の有効なバインド関係を自動クリーンアップしない。ログは識別方法、元の KASIKA customer_id、異常マーク時間、トリガーバッチを記録しなければならない。
5. 権限変更は変更前後のサマリーを記録しなければならない。
6. `customer_status` タグ設定の判定は、個別に保存された `customer_status` の現在値、前回保存値、最近の取得時間、ソースバッチ、自動更新スイッチのステータス、ヒットした同名タグ、状態タグ調整結果を記録しなければならない。完全な KASIKA フィールドスナップショットはトレーサビリティ資料としてのみ扱う。
7. 同期失敗はサイレント失敗してはならない。
8. 後続のシステム自動フローが失敗項目を再度処理する場合、元の失敗ログを保持し、新しい処理ログを追加しなければならない。
9. 履歴フィールドの再判定、タグ補完、タグ権限テンプレート変更後の権限計算はすべてログを記録しなければならない。
10. ログはプロジェクト、VISTA 顧客、KASIKA customer_id、メールアドレス、トリガー方式、操作者またはシステムタスクまで特定できる必要がある。
11. KASIKA が返した process_id、処理ステータス、呼び出し制限、同時実行制限はログに入れる必要がある。
12. バッチタスクが KASIKA に受理されなかった場合も、失敗理由を記録しなければならない。
13. 本期では同期失敗のサイト内通知や内部アラートメールは送信せず、通知受信者の設定も定義しない。顧客バインド通知メールは `04` の KASIKA 自動返信メール方案に従って処理する。
14. 本期では顧客リストページの「全量同期チェック」のみをフロントエンドの手動同期エントリとして提供する。顧客詳細ページには KASIKA 同期失敗詳細を表示しない。関連する失敗理由と後続処理ステータスは同期ログに入り、完全なログは B 端末管理者のみが KASIKA 連携管理ページから表示できる。
15. 定期同期、バックエンドバッチタスク失敗時は、ログ、バッチステータス、失敗明細、後続処理ステータスのみを記録し、管理者は KASIKA 連携管理ページの同期ログで照会する。
16. ログでは業務待処理、スキップ/変化なし、システム異常失敗を区別しなければならない。メールアドレスまたは電話番号のマッチング競合、候補顧客のバインド済みは業務待処理に属する。`customer_status` に同名タグがない場合はスキップまたは変化なしに属する。照会失敗、インターフェース利用不可、認証失敗、権限不足、呼び出し制限、保存失敗、書き込み失敗はシステム異常またはインターフェース失敗ステータスに属する。
17. VISTA 顧客の作成に成功したが、後続のバインド保存、フィールド書き込み、フィールドスナップショット保存、アクセスフィールド書き戻しに失敗した場合、ログは成功済みフェーズを記録し、再試行時の重複作成や重複バインドを避けなければならない。本期では KASIKA への顧客作成の成功フェーズは存在しない。
18. バックエンドの誤バインド対応と VISTA 顧客削除は KASIKA 側の HOMEVISTA アクセスフィールドをクリアせず、ログはその処理結果を記録する必要がある。同時にバインド関係の変更、有効なバインド関係のクリーンアップ結果、履歴 KASIKA フィールドの保持結果、再バインド禁止マーク、アクセス権限の再計算結果を記録する。VISTA 顧客削除後の元顧客が復元された場合、元の KASIKA 有効バインドは自動復元しない。バックエンド対応後の顧客が後続で同期または入口ページにヒットした場合、自動で再バインドせず、スキップまたは業務待処理の結果のみを記録する。
19. 同期失敗プロンプト、ページサマリー、次のアクション、後続処理基準は、優先して本ファイルの「同期失敗プロンプトとエラー情報サマリー」の統一エラー辞書を使用しなければならない。
20. KASIKA 連携設定フォームの保存成功、保存失敗、新規追加、変更、クリアは同期ログに書き込まない。

## 10. 本モジュールの受け入れ基準

| 受け入れポイント | 基準 |
| --- | --- |
| 同期ログ | すべての同期成功と失敗が照会可能 |
| 設定フォーム保存 | KASIKA 連携設定フォームの保存成功、保存失敗、新規追加、変更、クリアは同期ログに書き込まれない |
| フィールドログ | フィールドスナップショット保存、変更、`customer_status` タグ設定結果、自動更新スイッチのステータス、状態タグ調整結果が照会可能 |
| 権限ログ | 権限計算、権限変更、テンプレート変更後のリアルタイム計算結果が照会可能 |
| 削除/誤バインド対応ログ | 削除と誤バインド対応の操作前後ステータスがトレース可能 |
| 自動バインドログ | 同期フローが自動でバインド関係を確立または再確立する場合、バインド前後の関係、トリガーバッチ、マッチング根拠、操作結果、KASIKA 側 HOMEVISTA アクセスフィールドの書き込み結果がトレース可能 |
| バックエンド誤バインド対応ログ | バックエンド対応の操作者、操作時間、対応前後の関係、理由、結果、KASIKA 側 HOMEVISTA アクセスフィールドをクリアしなかった処理結果、権限再計算結果がトレース可能 |
| 履歴タスクログ | 履歴フィールドの再判定、タグ補完結果が照会可能。テンプレート保存で追加の履歴タスクは生成されない |
| バッチログ | 定期同期と一括同期に集計と明細がある |
| KASIKA バッチステータス | process_id、処理中、完了、失敗、呼び出し制限、既存タスク処理中などのステータスが照会可能 |
| フロント側結果 | 顧客レベル結果は統一して同期更新成功、変化なし未更新、同期更新失敗を表示 |
| バックエンド理由分類 | ログは処理待ち、処理中、成功、失敗、部分失敗、業務待処理、変化なし、スキップ、KASIKA 処理待ちなどの理由を区別できる |
| フェーズトレーサビリティ | VISTA 作成、バインド、フィールド書き込み、フィールドスナップショット保存、アクセスフィールド書き戻し、自動返信メール送信などのフェーズ失敗を個別にトレースできる |
| エラー辞書 | 同期タスクポップアップ、バッチ顧客リスト、詳細ページの KASIKA 連携モジュール、バックエンドログ詳細が統一エラーコード、ページサマリー、次のアクション、後続処理基準を再利用する |
| 失敗処理 | 同期、フィールドスナップショット、権限計算などの失敗項目は失敗フェーズと後続処理ステータスを記録する。削除類の失敗は失敗と理由のみを記録し、再試行は提供しない |
| 失敗通知 | 本期ではサイト内通知やメール通知は送信しない。失敗結果はページステータスと管理者ログで処理する |
| ログエントリ | KASIKA 連携管理ページのみが完全な同期ログのエントリを提供し、B 端末管理者のみが表示できる |
| ログエクスポート | 本期では同期ログのエクスポート機能を提供しない |

## 11. 本モジュールの確認待ち事項

1. 【確認済み】同期失敗、`customer_status` に同名タグがない場合など、本期ではログとページステータスのみを記録し、サイト内通知やメール通知は送信せず、通知受信者の範囲も定義しない。
2. 【確認済み】本期では同期ログの保存期間、アーカイブ戦略、ログクリーンアップルールを個別に設計しない。同期ログはプロジェクトデータのライフサイクルに従って保持し、プロジェクト満了時にデータをクリアする場合は一括処理する。
3. 【確認済み】本期では同期ログのエクスポート機能を提供しない。
4. 【確認済み】一括同期は一部顧客の成功、一部顧客の失敗を許可する。フロント側の顧客レベル結果は同期更新成功、変化なし未更新、同期更新失敗に分類し、バックエンドログは失敗理由、失敗顧客明細、後続処理ステータスを記録し、同一バッチの成功済み顧客はロールバックしない。
5. 【確認済み】KASIKA バッチタスクの呼び出し制限と同時受付制限について、本期では VISTA が具体的な残り待ち時間を独自に計算または表示することは要求しない。ページは KASIKA が返したエラー情報、処理ステータス、理由サマリーのみに基づいてユーザーに提示する。KASIKA が再提出可能時間または残り待ち時間を明確に返した場合、VISTA はそのまま表示できる。それ以外の場合は推定しない。
6. 【確認済み】完全な同期ログは B 端末管理者のみが表示でき、エントリは KASIKA 連携管理ページに置く。営業担当者と営業マネージャーは完全な同期ログを表示できず、同期ログのページエントリも表示しない。
7. 【確認済み】削除類の失敗は失敗結果と失敗理由のみを記録し、再試行エントリは提供せず、ログページで直接再試行もしない。
8. 【確認済み】KASIKA バッチ処理進捗確認 API は `error_rows_csv_download_url` などのエラー顧客リスト URL を返す可能性がある。本期では VISTA による KASIKA エラー CSV ファイルのダウンロード、解析、長期アーカイブは要求しない。同期ログに KASIKA が返したエラープロンプト、エラー行 URL、`process_id`、バッチステータス、処理時間のみを保存し、管理者がログから確認できるようにする。
9. 【確認済み】同期ログはマスク処理後の KASIKA リクエスト/レスポンスサマリーを保存でき、失敗トレーサビリティと開発調査に使用する。完全なリクエストヘッダー、完全なリクエストボディ、完全なレスポンスボディは保存してはならず、API KEY、Secret Key、HOMEVISTA アクセスパスワードの平文などの機密情報も記録してはならない。開発調査で完全なメッセージが必要な場合は、サーバー側の管理されたデバッグまたは一時的な調査メカニズムで処理し、製品の同期ログには入れない。
10. 【確認済み】HOMEVISTA アクセスパスワードはログ明細に平文で表示してはならない。アクセスパスワードの同期に関わる場合は、ログには同期成功有無、同期時間、対象顧客、処理フェーズ、失敗理由のみを記録し、パスワード値自体は記録しない。
11. 【確認済み】フロント側の顧客レベル結果は同期更新成功、変化なし未更新、同期更新失敗のみを表示する。ログでは「業務待処理」と「システム異常失敗」を引き続き区別する必要がある。メールアドレスまたは電話番号のマッチング競合、`customer_status` に同名タグがない、変化なしなどのステータスはインターフェース異常としない。照会失敗、インターフェース利用不可、認証失敗、権限不足、呼び出し制限、保存失敗、書き込み失敗などのステータスは失敗または異常として記録し、失敗理由と後続処理ステータスを提供する。
12. 【2026-07-20 改訂】同期失敗プロンプトとエラー情報サマリーは本ファイルの「同期失敗プロンプトとエラー情報サマリー」で一元的に管理する。同期タスクポップアップ、バッチ顧客リスト、顧客詳細の KASIKA 連携モジュール、バックエンドログ詳細は同じエラーコード、ページサマリー、次のアクション、後続処理基準を再利用する。フロントエンドには KASIKA 顧客同期情報ポップアップを提供しない。VISTA 顧客ファイルインポート結果ポップアップは VISTA インポートとタグ書き込み結果のみを表示し、KASIKA 同期エラー辞書の表示媒体とはしない。

## 12. 改訂履歴

| 日付 | 改訂内容 |
| --- | --- |
| 2026-07-13 | 完全な同期ログは B 端末管理者のみが表示・照会できることを明確化。営業マネージャーと営業担当者にはエントリを表示せず、インターフェース経由でもログを読み取ってはならない。 |
| 2026-07-13 | 非ストリーミング一括同期化に合わせて改訂：「手動停止／未完了」を通常のフロント側タスク結果および関連ログフィールドから削除。バッチ完了後は実際の処理総数、新規バインド、更新完了、失敗/待処理、KASIKA process_id、CSV 書き戻し結果を一括記録。同一プロジェクトのタスクロック競合記録を新規追加し、競合バッチは作成しない。フロント側の実行中は疑似進捗や処理中数量を表示しない。 |
| 2026-07-13 | 顧客同期詳細ポップアップから「同期基本情報 / KASIKA スナップショット」タブとすべての B 端末スナップショット表示エントリを削除。ポップアップには同期結論、顧客識別情報、フィールド変更のみを保持。完全な KASIKA `customer_data` スナップショットはサーバー側のフォールトトレランスと管理された調査用保存のみとし、B 端末での読み取り、表示、ダウンロードは提供しない。 |
| 2026-08-04 | KASIKA 書き戻しログは `VISTAURL` と該当する場合の `VISTAPWD` のみをカバーすることを明確化。VISTA 顧客 ID、バインドステータス、初回訪問完了時間は VISTA 内部情報としてのみ記録し、KASIKA 書き戻しフィールドには属さない。 |