AIの共通基盤で、顧客ごとの状態をどう分けるか
顧客ごとにログインと画面を分けても、裏で使うキャッシュや処理待ちのキューで対象の識別が抜けると、別の顧客の情報が混ざるおそれがあります。再試行や再起動の後にも、誰の処理かを識別できなければなりません。
VEGAのマルチユーザー設計では、研究や判断の基盤を共通化しながら、利用者・口座ごとの設定、権限、処理の記録を分ける設計を進めてきました。確認の対象は、入力の取得から日次レポートの出力先までです。
設計で決めておくこと
入力から復旧、レポートまで、誰の設定・権限・記録かを保持する。
02
最初の認証から、再試行まで識別を持たせる
入口で利用者を確認しても、後段で全顧客共通のキャッシュやキューを使い、対象の識別が抜けると混在が起きます。判断、実行、外部応答、イベント記録、再起動後の復旧まで、同じ識別を保持します。
画面から渡された顧客IDだけを信用せず、認証された利用者の権限と対象の所有関係を確認します。過去の承認や処理結果が、別の顧客や別の口座へ流用されないことも確かめます。
顧客の識別を確認する場所
- 入力の取得と、設定の読み込み
- 評価結果と、実行許可の照合
- キュー、キャッシュ、重複防止の識別子
- 外部サービスへの接続と、応答の記録
- 再起動後の未確定処理の復旧
- 集計、レポート生成、出力先の決定
03
レポートを、内部の状態と照合する
レポートの文章を整える前に、どの顧客の、どの期間の、どの記録から集計したかを確かめます。VEGAでは、判断、実行、結果確認の記録と日次レポートを照合することも設計に含めています。
未確定の処理や取得できない値は、確定値やゼロとして表示しません。何が起きたか、影響は何か、対応が済んでいるか、利用者の操作が必要かを、読み手の言葉で示します。
04
異なる顧客を同時に動かして、混ざらないことを確かめる
一人ずつ動かす確認では、同時処理や復旧時の混在を見落とすことがあります。同じ対象を扱う異なる顧客、異なる設定、同じ外部イベントの再受信などを組み合わせて確認します。
分離を確認するシナリオ
- 同じ対象でも、顧客ごとの上限を別々に適用できる
- 別の顧客の許可や処理結果を受け付けない
- 一方の停止が、別の顧客の権限を変更しない
- 同時処理や再起動後も、対象の識別が維持される
- レポートの集計値と出力先が、その顧客の記録に一致する

