音声認識を看護師に渡したら、想定と違うことが起きた｜内科医のAI開発記

前回（#33）では、バイブコーディングの限界──壊れる日は突然やってくる、という話を書いた。今回は、壊れるのとはまた別の、「思ったように使ってもらえない」という話をする。

音声認識SOAPの話は#32で書いた。

有料のサービスを解約して、自前のWhisperで置き換えた。診察中に話した内容が、S（主訴）・O（所見）・A（評価）・P（計画）に自動で整形される。僕の診察スタイルに合わせてプロンプトを調整して、かなり使えるものになった。

次に考えたのは、これを看護師にも使ってもらうことだった。

看護師の記録業務

看護師の仕事には記録が多い。

患者さんのバイタルを測る。問診を取る。処置の補助をする。そのたびに、電子カルテに記録を入力する。

それが音声で済むなら、手が空く。手が空けば、患者さんに向き合える時間が増える。

そう考えた。

最初にやったのは、SOAPの出力からA（評価）とP（計画）を消すことだった。

医師のSOAPには評価と計画が必要だが、看護師の記録にそれは要らない。S（患者さんが言ったこと）とO（看護師が観察したこと）だけでいい。

これは簡単だった。プロンプトを変えるだけだ。

問題は、そこからだった。

僕は診察室の椅子に座ったまま話す。マイクとの距離は一定だ。看護師は違う。処置室を歩き回る。患者さんの横に立ったり、機材を取りに行ったり、別の部屋に移動したりする。

マイクとの距離が変わると、音声認識の精度がガタ落ちする。

ワイヤレスマイクが要る、と気づいた。ピンマイクか、ヘッドセットか。でもクリニックの看護師がヘッドセットをつけて仕事をしている姿は、患者さんにどう映るだろう。

音声認識にはGPUが必要だ。僕のPCにはRTX 3070が載っていて、VRAM（GPUのメモリ）は8GBある。

僕が一人で使う分には十分だった。でも看護師が同時に使うと、VRAMが足りなくなる。同時処理の排他制御を入れて、医師の処理を優先する仕組みにした。看護師側は医師が使っていないタイミングで処理が走る。

リアルタイム性は少し落ちたが、運用上は許容範囲だった。

僕は診察のルーティンが決まっている。患者さんが入ってきて、話を聞いて、診察して、説明して、帰る。その間に録音ボタンを押して、終わったら止める。

看護師の業務は違う。ひとりの患者さんの対応が途切れ途切れになる。バイタルを測って、別の患者さんの採血をして、また戻ってきて処置をする。

「録音開始」と「録音停止」の単位が、医師と看護師で根本的に違った。

正直に言うと、まだうまくいっていない。

看護師用の画面は作った。S/Oだけ出力するプロンプトも組んだ。でも「業務に組み込めている」かというと、そこまでは至っていない。

僕のツールは、僕の動き方を前提に作られている。座っている。マイクとの距離が一定。一人の患者に集中する時間がある。GPU資源を独占できる。

看護師の環境はそのどれも当てはまらない。

バイブコーディングで35個のツールを作ってきたが、そのほとんどは僕専用だ。僕の操作ルーティン、僕の診察スタイル、僕のPCスペック。それに最適化されたツールは、同じクリニック内で動く看護師にすら、そのままでは使えない。

これは技術の問題ではない。「誰が」「どう動くか」を理解しないまま作ったツールは、渡す相手に合わない、ということだ。

じゃあどうするか。

看護師業務を観察するしかない。どのタイミングで何を記録しているのか。手が空くのはいつか。マイクを意識できるのはどの瞬間か。

それを見て、もう一回作り直す。

たぶんそれは、プログラミングやAIの問題ではなくて、「現場を見る」という、もっと古くからある仕事の話だと思う。

ひろつ内科クリニック（福岡市博多区）
開業1年3ヶ月 / MedBoard 37ツール稼働中
AI構成：AWS Bedrock Claude Sonnet（ZDR）+ ローカルWhisper large-v3

この記事は hirotsu.clinic/blog/ にも掲載しています。