アカウント統合：データ、権限、および操作
アカウント統合は、明示的な優先順位ルールによって識別の衝突を解決し、生存アカウントの下にデータを移動し、不可逆なコミット境界を定義し、調整が完了するまでロールバックや不確定状態をサポートします。
パッケージステータス: AI支援リファレンスパッケージ。静的パッケージ検証は合格していますが、実装シナリオは未実行であり、安定採用前に人間によるドメインレビューが必要です。
決定事項
アカウント統合は段階的プレビュー、段階的意図設定、信頼シグナルに基づく生存者選択によるコミットとして実行します。merge-plan.yaml に記載されたルールを用いて識別の衝突を解決し、不可逆なコミット前のみロールバックを許可します。調整ジョブが部分的に失敗した場合は成功を装わず、uncertain のオペレーター可視状態に入ります。
範囲
- 1つのプロダクトテナントモデル内でのユーザー主導による2つのアカウントの統合。
- 識別属性：メール、ユーザー名、OAuth識別子、MFA要素。
- ユーザー生成コンテンツ、設定、および監査の由来のデータ移動。
- 両アカウントが組織オーナーである場合やOAuth主体が競合する場合の手動レビューなしでのブロック条件。
範囲外
- 請求エンティティを跨ぐ組織間の買収統合。
- 単一組織内での所有権移転。
- 統合後のGDPR消去（削除ブロックは参照可能だが消去を定義しない）。
契約
- プレビューフェーズは読み取り専用で、提案された解決策とともにすべての衝突を一覧表示します。ユーザーがプレビューを確認するまでデータの変更は行いません。
- 段階的フェーズはTTL付きで統合意図を記録します。コミット開始までユーザーはロールバックを中止できます。
- コミットフェーズは通常操作下で不可逆です。コミット後の元に戻す要求は例外的なサポート回復のみを案内して拒否します。
- 生存アカウントが移動されたコンテンツを受け取り、ソースアカウントのログインはコミット成功後に無効化され、セッションは取り消されます。
- 識別の衝突は統合計画戦略に従います：メールは一致するか検証済みエイリアスでなければならず、競合するOAuth主体は手動リンク完了まで自動統合をブロックします。
- 両アカウントが異なる組織の唯一のオーナーである場合、所有権移転または降格で競合を解決するまで統合はブロックされます。
- コミット中の部分的なジョブ失敗は即座に
uncertainに遷移します。uncertainがプロファイル最大期間を超えて続く場合、エスカレーションがオペレーターに通知され、承認まで自動完了をブロックします。 - 生存アカウントが移動されたコンテンツを受け取り、ソースアカウントのログインはコミット成功後に無効化され、アクティブなソースセッションは取り消され、ソーストークンによる認証は失敗します。
- 移動されたコンテンツに関するすべての過去の監査イベントは、元のアクターIDに加え統合相関識別子を保持します。
実装ガイダンス
- リトライ時に移動行が重複しないよう、統合IDでキー付けされた冪等なジョブステップを使用します。
- 統合状態機械はユーザーロウとは別に保存し、ワーカーは
merge-plan.yamlに記載された遷移のみでフェーズを進めます。 - プレビュー中に人間が読める衝突レポートを提示し、元帳統合で手動レビューが必要な場合は請求影響も含めます。
- コミット後に統合済みアカウントのトークンが認証されないよう、認可と連携して防止します。
障害処理と安全策
- 不可逆境界を越えた後にコミットトランザクションが失敗した場合は、ソースアカウントを削除せず
uncertainに入ります。 - プレビューTTLが切れた場合、段階的トークンを破棄し新たなMFA検証を要求します。
- 表示名の類似やIP重複のみでアカウントを統合しません。
- サポートツールは統合フェーズを目立つよう表示し、誤った重複サポート操作を減らします。
検証と運用
- プレビュー放棄数、コミット数、不確定統合数、不確定状態解決までの平均時間を監視します。
merge-plan.yaml由来のフィクスチャを用いて衝突ルールをテーブルテストします。- 生存者をバックアップから復元し、半分移動されたコンテンツ識別子を孤立させない災害復旧訓練を実施します。
採用前提
example.yamlとmerge-plan.yamlの名前と値は採用プロファイルであり、普遍的なデフォルトではありません。- チームはどのデータクラスを自動移動し、どれを手動レビューが必要か分類します。