複数組織を切り替える画面の注意点｜別タブ・キャッシュ・入力途中の扱い

1. 操作対象の組織をどこで確定するか

本稿では、組織を切り替えた後の画面を、その組織専用の作業領域として扱うことを提案する。例えば同じ利用者が組織Aと組織Bの問い合わせを処理するとき、画面上部に組織名を常時表示し、案件詳細や送信確認にも対象組織を添える。色だけに頼らず、名称と短い識別表示を組み合わせる。切り替えメニューで選択した瞬間ではなく、権限と初期データの確認が終わった時点で切り替え完了とし、それまでは更新操作を受け付けない状態を設ける。

ただし、組織名が正しく見えることと、その組織のデータを操作できることは別である。認証は利用者の識別、認可は対象への操作の許可を扱い、認可の判定はサーバー側などで実施するという原則がある。そこで本稿では、要求に含まれる組織、利用者の所属・権限、対象レコードの所属を照合する設計を提案する。例えばAの画面からBの案件識別子が送られた場合、Bへの所属があっても自動的に操作先を読み替えず、不整合として扱う。[1]

• 一覧、詳細、確認画面で対象組織の表示が一致しているか。
• 組織の初期化に失敗したとき、前の組織の画面を操作可能なまま残していないか。

2. 別タブとセッションをどう分けるか

別タブの扱いでは、全タブを同じ組織にそろえる方式と、各タブで異なる組織を開ける方式を先に選ぶ。本稿では、複数組織を並行して処理する業務を前提に、タブごとに操作組織を固定する方式を提案する。例えば一方でAの問い合わせを編集中に、もう一方でBを開いても、Aの送信先は変えない。最後に選んだ組織を共通の保存領域から送信直前に読み出す設計は避け、画面が保持する組織を要求に結び付ける。新しいタブの初期組織も明示的に決める。

一方、ログイン状態は組織の選択とは分けて管理する。セッションは認証済み利用者の要求とアクセス制御を結び付ける仕組みであり、失効やタイムアウトはサーバー側で扱う必要がある。組織切り替えをログアウトと同一視せず、ログアウト時には別タブも次の要求で失効を検知できるようにする。例えば休止していたAのタブを再表示した際は、以前のログイン状態を前提に送信させず、有効性を確認してから操作を再開する流れを設ける。[2]

• AとBを別タブで開いたとき、それぞれの操作先が保たれるか。
• ログアウト後に残ったタブから送信すると、サーバー側で拒否されるか。

3. キャッシュと遅れて届く応答をどう扱うか

キャッシュ破棄は、一覧を空にする処理だけでは完結しない。本稿では、画面内の取得結果を管理するキーに組織識別子を含め、検索条件、件数、候補一覧、詳細情報を組織ごとに区別することを提案する。例えばAで担当者候補を取得した直後にBへ切り替えると、同じ検索語でも候補の所属は異なる。切り替え時には旧データを表示から外し、取得済み情報を再利用できる範囲を決める。権限やデータ更新を反映する再取得条件も、単なる経過時間だけで決めない。

さらに、Aへの要求が遅れて返り、切り替え後のBの画面を上書きする場合を想定する。本稿では、要求開始時の組織と画面の世代を応答時に照合し、一致しない結果は表示に採用しない設計を提案する。ブラウザーのHTTPキャッシュも別の確認対象であり、資料ではセッション終了後も機微情報が残り得ること、機微なセッションデータなどを含む応答へのno-store指定が示されている。HTTPの方針と画面内の状態管理は、分けて確認する。[2]

• Aの応答を意図的に遅らせても、Bの一覧や候補を上書きしないか。
• 戻る操作、再表示、通信復帰で、異なる組織のデータが再利用されないか。

4. 入力途中のフォームは移すか、残すか

本稿では、組織切り替え時に未保存の入力があれば、切り替えを中止する、元の組織に下書き保存する、破棄して進む、という選択肢を業務に合わせて設けることを提案する。例えば問い合わせの返信文には、氏名や契約内容が含まれる可能性がある。その入力をBの新規フォームへ自動で引き継がない。下書き保存を選ぶ場合も、保存先は入力開始時のAとし、添付ファイルや宛先を含む一式を同じ所属で管理する。本文だけを残す設計では不十分である。

送信ボタンを押した後は、未保存の編集とは別の状態として扱う。本稿では、処理が受け付けられたか不明な間に組織を切り替えても、送信先を変えたり同じ内容を自動送信したりしない設計を提案する。例えばAへの登録要求が通信切断で結果不明になった場合、まずAの受付結果を確認し、未受付と確認できた場合に再送の判断へ進む。送信確認には組織、対象、操作内容を表示し、結果画面にも所属を残して、Bに移った後でも処理の帰属を追えるようにする。

• 添付、宛先、入力補助の選択値も下書きの所属と一致しているか。
• 送信結果不明の状態を、単なる未送信として扱っていないか。

5. RAGの検索結果と生成中の回答をどう分離するか

RAGでは、検索画面だけでなく、参照文書、引用表示、会話履歴、生成中の回答にも組織の対応が必要になる。本稿では、質問を受け付けた時点の組織と会話を処理に固定し、検索対象の絞り込みと参照可能性の確認をサーバー側で行う設計を提案する。例えばAの規程を検索中にBへ切り替えても、その回答をBの会話へ追加しない。クライアントの指定だけを根拠に閲覧を許さないという認可の原則を、文書取得や引用先へのアクセスにも適用する。[1]

生成中の切り替えについては、処理を止めるのか、Aの履歴で継続するのかを選ぶ。本稿では、画面から離れても処理を継続する業務なら、完了結果を元の会話に保存し、通知からAの会話へ戻れる設計を提案する。ただし、通知本文に質問や個人情報をそのまま載せる必要はない。処理を止める設計では、画面表示の停止とバックエンド処理の停止を区別する。どこまで中断できたかが不明なら、完了したようにも完全に取り消せたようにも表示しない。

• 回答本文だけでなく、引用文書と会話履歴の所属も確認したか。
• 切り替え後に届く生成結果の保存先と通知先が決まっているか。

6. API・Webhook・再実行の対象は何で決めるか

本稿では、バックグラウンド処理に組織、依頼者、対象、操作内容の対応を持たせ、ワーカーが利用者の現在の画面設定から組織を決めない設計を提案する。例えばAで開始した帳票作成が待機中に利用者がBへ移っても、処理先はAのままとする。APIの資格情報が利用できる範囲と、要求が対象とする組織・資源をサーバー側で照合する。画面上でボタンを隠すだけでは認可の代わりにならず、直接の要求でも同じ制約が働く必要がある。[1]

Webhookと再実行では、元の処理の所属を保持することと、再実行時にも許可されていることを分ける。本稿では、Aの失敗ジョブをBの管理画面から再実行できない導線を基本とし、必要ならAへ移動して対象を確認する設計を提案する。所属変更後の実行可否は、利用者の代理処理か組織の定期処理かによって条件を定める。Webhookの送信先と資格情報の参照先もジョブに対応付け、再送による二重登録を識別する情報は組織との組で管理する。

• 再実行時に、対象組織と実行主体の権限を確認する箇所が決まっているか。
• 外部送信先の変更が、待機中ジョブにどう反映されるか定義したか。

7. 本番公開前に使う組織切り替え確認表

確認では、異なる組織で同じ名前の案件や文書を用意すると、組織名だけを見て通過する不十分な確認を避けやすい。本稿では、架空の利用者と識別可能なテストデータを使い、画面表示、送信要求、保存結果を照合することを提案する。下表は未実施の確認項目であり、合格済みを示すものではない。担当者は各行に実測結果と証跡を追記し、不一致が出た場合は表示だけの問題か、保存先まで異なるのかを分けて公開判断に回す。

通常の切り替えだけでなく、通信遅延、権限不足、再読込を組み合わせると、状態の境界を確認できる。例えばAの詳細取得中にBへ移り、その後Aの応答を返す条件を固定して再現する。認可については単体・結合テストで継続的に確認することが資料で推奨されているが、それだけであらゆる問題を検出できるわけではない。ここでは画面操作の確認とサーバー側の許可・拒否のテストを組み合わせ、変更時にも同じ条件を再現できる形で残す。[1]

• 期待結果と実測結果を別欄で管理し、未実施を合格にしていないか。
• 公開を止める不一致と、修正期限を設けて扱う表示上の課題を区別したか。

8. 公開後の保守と引継ぎに何を残すか

本稿では、引継ぎ資料に組織の決定方法、画面状態の保存先、処理の状態遷移、問い合わせ時の確認項目をまとめることを提案する。例えば「Bを開いていたのにAの通知が来た」という連絡では、通知がAで開始した処理の正常な完了なのか、誤った画面への表示なのかで対応が異なる。受付担当が質問文や個人情報の提出を求めなくても、発生時刻、操作組織、処理識別子で開発担当へ伝えられるようにする。担当交代時も、既知の未確認事項を残す。

ログは、表示の変化と実際の処理先を照合できる範囲を定める。認可資料は過剰な記録による機微情報の蓄積にも注意を促し、セッション管理資料は生のセッション識別子を記録しないよう示している。本稿では、組織切り替えの成否と業務処理の対象組織を関連付けつつ、質問全文、添付内容、資格情報を安易に残さない構成を提案する。公開後に不一致が疑われた場合の更新停止手順と、再開判断を担う役割も運用手順に含める。[1][2]

よくある質問

業務担当者が不在で、組織間の下書き移動の要否を決められない場合は？

本稿では、自動移動を設けず、元の組織に残す案を暫定候補とする。未決事項として承認者と決定期限を記録し、業務上必要な操作が成立するか確認する。担当者不在を、個人情報を別組織へ転記してよい根拠にはしない。必要な業務確認が終わらなければ、その機能の公開範囲を絞る。

本番相当の確認環境がない場合、画面だけの確認で公開できますか？

画面だけでは、保存先や非同期処理の所属まで確認したことにはならない。本稿では、架空データでAPIとワーカーを含む最小の結合環境を用意する案を提案する。環境差が残る場合は未確認箇所を明示し、影響を切り分けられない更新機能は公開対象から外す判断を検討する。

一時休職中の利用者の下書きは、別の担当者へ移してよいですか？

利用者の状態変更と下書きの移管は別の判断とする。本稿では、組織を変えずに担当だけを変更できる承認付き手順を提案する。閲覧可能な担当者、移管対象、添付の扱いを業務責任者が決め、個人端末への書き出しを引継ぎの前提にしない。保存期間は組織の運用方針で確認する。

期限付きで複数組織を横断する担当者には、確認操作を省略できますか？

横断業務が必要でも、対象組織の表示まで省略する必要はない。本稿では、利用可能な組織と操作を限定し、承認者、期限、終了条件を持つ例外設定を提案する。期限到来後に画面表示だけが変わるのではなく、サーバー側の許可にも反映されるかを確認してから運用する。

参考・関連資料

• [1] Authorization - OWASP Cheat Sheet Series ↗
• [2] Session Management - OWASP Cheat Sheet Series ↗

公式資料の確認日：2026-10-27。業務例は説明用で、顧客の実績ではありません。編集：株式会社N2i。執筆にAI支援を使用し、別のAIによる出典・品質確認に合格した記事を公開する方針です。