自動でやり直すと、同じ記録が二重にできませんか

できません。やり直すのは止まったままのその記録そのものなので、新しい記録が増えることはありません。現場でもう一度操作して重ねてしまう心配も要らなくなります。

自動で直っている途中、現場の画面はどう見えますか

処理中のままです。やり直しは裏で進むので、操作をお願いすることはありません。しばらくすると下書きが出来上がった状態になります。

何度やり直しても戻らない記録は、どうなりますか

止まったままの記録は見張りが拾い続けるので、放置されることはありません。やり直しを重ねても戻らないものは当社側で検知して原因を追いますので、院内で原因の切り分けをしていただく必要はありません。

医療システムの止まった処理を、自動で復旧させるには

医療システムでは、処理が止まったことに気づくだけでは足りません。気づいたあとに誰が直すのかまで決めて、はじめて仕組みになります。

現場に「もう一度押してください」とお願いするのは、一見すると小さな負担です。しかし記録は毎日発生するので、その一手は毎日積み上がります。しかも止まったことに気づくのはたいてい忙しい時間帯で、そのときに操作を1つ増やすのは、思っている以上に重い依頼です。

ここでは、長い会議の録音を記録の下書きに変える処理を作り直したときに踏んだことを、一般化してご説明します。

エラーが出ない障害がある

まず前提として、エラーとして観測できない止まり方があります。

処理の実行環境が使えるメモリの上限を超えると、多くの場合はプログラムに例外が渡されるのではなく、実行環境ごと強制的に終了させられます。このとき、失敗に備えて書いておいた後始末の処理も、「一定時間で失敗にする」ためのタイマーも、まとめて一緒に消えます。アプリケーションのログには1行も残りません。

結果として、記録の状態は「処理中」のまま止まります。画面はぐるぐると回り続け、利用者から見れば「まだ終わらない」だけで、失敗したことすら分かりません。

ここから引ける一般則は1つです。保険を、落ちる側の中に置いてはいけない。 落ちうる処理の外側に、別の仕組みとして見張りを置く必要があります。私たちは5分ごとに動く見張りに、一定時間を過ぎても「処理中」のままの記録を回収させる役割を持たせました。

「同時に何本まで」では守れない

次に、なぜ上限を超えたのかという話です。

長い録音は分けて並行に処理します。このとき素直に思いつくのは「同時に4本まで」といった本数での制限です。ところがこの制限は、1本が軽いという前提でしか成り立ちません。

上限を超える条件は、実際には次の掛け算です。

同時に扱う本数 × 1本あたりの大きさ × 内部で持つ複製の数

本数だけを押さえても、1本が重ければ簡単に超えます。押さえるべきは本数ではなく、同時に抱えている量そのものでした。 そこで「同時に抱えてよい量」を決め、その範囲に収まる限りで並行させる形に変えました。重いものが来れば同時本数は自然に減り、軽いものが多ければ多く流れます。

もう1つ、ここには落とし穴があります。その「量」を、利用者側から送られてきた申告値で数えてはいけません。 申告値は間違うことも、欠けることもあります。サーバ側で実際の大きさを測り、測れなかったときは「軽い」ではなく「重いかもしれない」と見なす。安全側に倒すのは、こういう分岐のことです。

直すのは、人ではなく機械にする

そのうえで、止まったものをどう戻すかです。

私たちが採ったのは、気づく → 条件を軽くする → やり直す の3段です。単に同じ条件でやり直しても、同じ理由でまた止まります。そこで「この記録は前に重さで止まった」という事実を残しておき、次のやり直しでは同時に抱える量を自動的に絞ります。取り込みの段階でも、大きな音声は自動的に軽くしてから送るようにしました。

軽くすることに抵抗があるとすれば、記録の中身が変わってしまわないかという点でしょう。ここは実際に測りました。同じ会話を軽くした場合と、そのまま処理した場合を突き合わせたところ、差は読点の位置が4か所だけで、語句と数値は変わりませんでした。同じ音源を2回通したときの結果が一致することを先に確かめてあるので、この差が軽くしたことによるものだと言い切れます。

医療の記録では「速いが中身が変わる」は選べません。測って初めて、安全側に倒したと言えます。

守りを入れたら、それが成立しない条件を1つ考える

この作り直しで、いちばん学びが大きかったのはここです。

音声を軽くしたあと、念のため「短くなっていないか」を長さで検証する処理を入れました。壊れた音声を記録に回さないための守りです。ところが実際に動かしてみると、利用者が別のタブを見ているあいだ、ブラウザは音声の長さを読み取れないことが分かりました。

守りとしては正しく書けているのに、成立しない条件が1つあった。そのまま出していれば、「利用者が画面から目を離しているときだけ、軽くする処理が黙って行われない」という壊れ方をしていたはずです。しかも誰にもエラーは見えません。

そこで、長さが読み取れないときは大きさから妥当性を確かめる経路を足し、わざと短い結果を作って、ちゃんと弾かれることまで確認しました。

守りを入れたら、それが成立しない条件を必ず1つ考える。 「直した」と「壊していない」は別のことです。

踏んだことと、そこから引ける一般則を並べます。

踏んだこと	何が起きたか	引ける一般則
実行環境がメモリの上限を超える	後始末もタイマーも一緒に消え、ログに1行も残らない。記録は「処理中」のまま止まる	保険を、落ちる側の中に置かない
「同時に何本まで」で並行を制限する	1本が重ければ、本数を押さえていても簡単に超える	押さえるのは本数ではなく、同時に抱えている量
送られてきた申告値で量を数える	申告値は間違うことも、欠けることもある	サーバ側で測り、測れなければ「重いかもしれない」と見なす
同じ条件でやり直す	同じ理由でまた止まる	止まった事実を残し、次は条件を軽くしてから試す
音声の長さで軽量化を検証する	別のタブを見ているあいだ、ブラウザは長さを読み取れない	守りを入れたら、それが成立しない条件を1つ考える

止まったままが、いちばん困る

カンファレンスの議事録、訪問看護の記録、診察の記録。どれも「あとでまとめて」が効かない仕事です。その日のうちに形になっていないと、翌日の申し送りや会議の資料が作れません。

だからこそ、止まったときの設計が効いてきます。現場から見て一番よいのは、止まったことに気づかないまま、いつのまにか終わっていることです。

今回作り直した経路では、処理が止まった記録を見張りが拾い、条件を軽くして自動でやり直し、人が何も操作しないまま数分で下書きが仕上がるところまでを実際に確認しています。この考え方は、診察・看護記録・面談記録・議事録・福祉訪問記録の5つの記録すべてに同じように入れました。

こうした可用性や復旧の考え方はセキュリティの考え方にまとめています。院内のシステム部門から確認がある場合は、貴院のチェックシートの様式のままご回答しますのでお気軽にお申し付けください。

長い会議の録音をどう記録に変えているかは議事録の作成をご覧ください。「うちの会議は2時間を超えるが大丈夫か」「録音機の設定はどうすればよいか」といったご相談から始めていただけます。現状の棚卸しだけでも歓迎です。