確認ダイアログの文言は、どう書くとよいですか

何が失われるのかを名指しします。「よろしいですか」だけでは、押す側が何を天秤にかけているのか読み取れません。録音が失われるのか、書きかけの記録が消えるのかをその場で分かる語にしておくと、内容を読まずに押す割合が下がります。

確認をはさむ箇所は、いくつまでなら許容できますか

数の上限は決めていません。見ているのは増え方のほうです。呼び出し箇所を台帳と突き合わせる検査が毎回走るので、足すときには「誰の操作が引き金で、確認をはさんでいるか」を書くことになります。止めているのは増やすことではなく、気づかないうちに増えることです。

この判定の考え方は、録音以外の操作にも使えますか

使えます。形は「この操作で、そのデータは本当に失われるのか」なので、対象が書きかけの記録でも取り込み中のファイルでも同じです。画面の作りによって答えが変わる点も共通していて、表示が消えることとデータが消えることは常に別に扱います。

確認ダイアログは、出す条件を間違えると壊す側にまわる

医療の記録は、その場でしか作れません。診察の会話も、訪問先での相談も、会議のやりとりも、録り直しがききません。だから、誤操作による消失の防止として「失われる前に確認する」という守りを入れます。

ところが、この守りは出す条件を間違えると、守るはずのものを壊す側にまわります。録音を抱えたまま画面を離れられる経路を塞いだときに、実際にそうなりかけました。何を確かめて避けたかをご説明します。

「失われるから確認する」は、失われるかを確かめてから

確認ダイアログの中身は、たいてい「はい」を押したときの後始末とセットになっています。録音を捨てる、書きかけの記録を消す、といった処理です。

ここで見落としやすいのは、確認を出した時点で「失われる」と決めつけていることです。もし実際には失われない場面で出してしまうと、利用者は「はい」を押した瞬間に、無事だったデータを自分の手で消すことになります。守るために入れた仕組みが、そのデータを壊す唯一の経路になるわけです。

最初の実装では、判定を「どの画面の録音か」で決めていました。これが誤りでした。正しい問いは「この移動で、その画面は本当に閉じるのか」です。

React では display:none か unmount かで結論が正反対になる

画面の作りによって、同じ「タブを切り替える」でも起きることが違います。

画面	タブを切り替えたとき	録音は	確認を出すべきか
患者さんの記録フォーム（診察・看護・面談）	画面が閉じる（unmount）	失われる	出す
議事録・福祉訪問記録の作成画面	表示だけ消えて残る（display:none）	残る。時間も進み続ける	出してはいけない
ログアウト・ブラウザの戻る・再読み込み	ページごと消える	失われる	出す

タブを切り替えても中身を保持する作りは、戻ったときに入力が消えていないという意味で親切な設計です。しかしそのぶん、「移動＝失われる」という素朴な前提が崩れます。表示が消えることと、データが消えることは別だからです。

実装では、画面ごとに「この移動で自分は閉じるのか」を持たせ、移動の種類（画面を閉じる／タブと患者の切り替え／ページごと消える）と突き合わせて、出すかどうかを決めるようにしました。

問うのは「どの画面の録音か」ではなく「この移動で、その画面は本当に閉じるのか」

後始末の順序で、マイクが回り続ける

「はい」を押したあとの処理にも順序があります。作成中の記録を消してから画面を閉じる、と書きたくなりますが、これは危険です。

消す処理は通信を伴うので、電波が悪ければ失敗します。失敗した時点で処理が止まると、画面を閉じる手前で止まる。つまり利用者は移動したつもりなのに、マイクは回り続けたままになります。精神科の診察室で、会話が無自覚に録られ続ける状態です。

そこで順序を逆にしました。先に画面を閉じてマイクを解放し、そのあとで消す。消すのに失敗しても、少なくとも録音は止まっています。失敗したことは記録の識別子つきで残すので、あとから追えます。

消す処理は失敗しうる。失敗しても困らない順に並べる

正常な操作の結果を、異常として通知しない

録音中は、音声を一定の間隔でサーバーへ送っています。利用者が破棄を選ぶと記録は消えますが、そのとき飛んでいた途中の音声は、少し遅れてサーバーに届きます。届いた先に記録はもうありません。

最初の実装では、これを「記録が見つからない」として異常のログに残していました。異常のログは通知に流れるので、利用者が破棄するたびに通知が鳴ることになります。通知が鳴りやまなくなると、本当の異常が読み飛ばされます。

分けるべきだったのは、「利用者が破棄した」と「そもそも存在しない識別子だ」の2つです。前者は正常な操作の結果なので、静かに捨てて記録だけ残す。後者だけを異常として扱う。

サーバーから見た状態	意味	扱い
記録が削除済み	利用者が破棄した。想定内	静かに捨てる。情報として記録
記録が存在しない	呼び出し側の不具合の疑い	異常として通知する
取得そのものが失敗	一時的な障害	異常として通知する

分けたあと、存在しない識別子を送る試験を実際に行い、いまも異常として残ることを確かめました。片方を静かにする変更は、もう片方まで黙らせていないかを測らないと意味がありません。

守りを足したら、壊す経路が増えていないかを機械で数える

ここまでの問題は、どれも「気をつける」では防げません。実際、2本のレビューのうち気づいたのは1本だけでした。人の目には残る型です。

そこで、消す操作の呼び出し箇所を全部数えて台帳と突き合わせる検査を作り、毎回自動で走らせるようにしました。件数がずれると止まり、「誰の操作が引き金で、確認をはさんでいるか」を書かないと更新できません。禁じるのは増やすことではなく、無自覚に増やすことです。

検査を作るときにも落とし穴がありました。わざと壊して赤くなることを確かめるという手順を踏んだのですが、1回目は「実際には起こらない書き方」で壊していたため検出されず、危うく赤くならない検査を合格として扱うところでした。壊し方は、現実に起こりうる形で選ぶ必要があります。

現場から見ると、確認は少ないほどよい

確認ダイアログは、増やせば安全になるものではありません。押す回数が増えるほど、内容を読まずに押すようになります。だから出す場所は、押し間違いが取り返しのつかない結果になるところに絞ります。

今回でいえば、録音を持っている間だけが対象です。サーバーへ送り終えたあとは、画面を離れても処理は進みます。そこで確認を出せば、移動できるのに引き止めるだけの邪魔な問いかけになります。

診察のあいだ、訪問先で、会議室で。記録が生まれる場所は落ち着いて操作できるとは限りません。だからこそ「押し間違えても大丈夫」の範囲を広げることが、そのまま現場の負担軽減になります。この考え方は、診察・看護記録・面談記録・議事録・福祉訪問記録の5つすべてに同じ形で入れています。

データの扱いや可用性についての考え方はセキュリティの考え方にまとめています。院内のシステム部門から確認がある場合は、貴院のチェックシートの様式のままご回答しますのでお気軽にお申し付けください。現状の棚卸しだけでも歓迎です。