AIアプリを病院で自作したらものの見事にすべった話を、学会で100人に赤裸々暴露してきた

メディカルAI学会で報告した「患者さんへの適用」の実装課題

※この記事は学会報告３部構成の１部目です。２部、３部は以下の内容で作成していく予定です、興味がある方は購読して楽しみにしていてください。

• ２部：出来た知り合い達とのディスカッションが面白かった話

• ３部：クリエイターは学会でビジネスチャンスを掴むといい話

先日、虎ノ門ヒルズフォーラムで開催された、日本メディカルAI学会のシンポジウムに登壇してきました。

テーマは「患者中心の医療において、AIを、現場で使える形にどう落とし込むか」。

最初に白状しておきたいことがあります。

僕が作ったプロトタイプは、実際の患者さんには一度も使えていません。

倫理委員会を通過できなかったからです。

普通なら、こういう話は表に出しません。失敗談ですし、見栄えもよくない。でも僕は、この「滑った経験」のほうが、きれいな成功事例より何倍も価値があると思っています。

なぜなら、作って、動かして、つまずいたからこそ、「AIを現場に実装するとき、本当に難しいのはどこなのか」がはっきり見えたからです。

今回はその話をします。医療者の方にも、そうでない方にも、「AIを現実の仕事に組み込むとき何が起きるのか」というテーマとして読んでもらえるはずです。

---

シンポジウムの中で、僕が担当したのは「APPLY」だった

シンポジウム全体では、いくつかの段階が扱われました。

患者さんの困りごとをどう拾うか。生活や検査のデータをどう貯めるか。患者さんの状態をどう測るか。そのサイクルをどう速く回すか。

その流れの中で、集めた情報とAIの力を、実際の診療現場で患者さんにどう「適用(APPLY)」するのか。僕が今回引き受け、語ったたのは、ここでした。

構想を描くのは、わりと誰でもできます。難しいのは、そのきれいな絵を、現場で本当に動く形に落とすときです。どこで詰まるのか。なぜ詰まるのか。それを、自分が実際に作って失敗した経験から話しました。

---

情報は増え続ける。でも、判断する人は増えない

医療現場には、毎日とんでもない量の情報が流れ込みます。

検査結果、処方、診療記録、紹介状、訪問看護の記録、家族からの一言、救急隊からの電話、そして患者さん本人の訴え。これからは、スマートウォッチや健康アプリが拾う日常の変化も、ここに積み上がっていきます。

情報は、放っておいても増えます。

ところが、その情報を見て「今この人にとって何が一番大事か」という判断・重み付けを決定できる人、つまり医師は、そう簡単には増えません。

医師不足という言葉の裏には、単に頭数が足りないという話だけでなく、増え続ける情報量に、判断する人間の処理能力が追いつかなくなっているという側面があると、僕は思っています。

ここで僕が考えたのは、総合診療医が普段やっている「考え方」そのものを、AIに移植できないか、ということでした。

総合診療医は、患者さんを一つの臓器として見ません。体の病気、心の状態、家族や暮らしの事情を、まとめて一人の人間として捉えます。

• がんの進行や薬の副作用を見る「からだの軸」

• 不安や落ち込み、死への恐怖を見る「こころの軸」

• 家族関係、介護の負担、お金、使える福祉サービスを見る「くらしの軸」

この三つを束ねて考える見方を、医療では Bio-Psycho-Social モデル(略してBPSモデル) と呼びます。

雑多な患者情報を、この三つの軸で仕分けられれば、AIでも現場の判断を助けられるのではないか。そう考えたわけです。

---

Slackに「患者チャンネル」を作り、AIにBPSで仕分けさせた

そこで、当時丁度ハッカソンもやっていたこともあり、意思決定支援のアプリを開発することにしました。ざっくりとしたアーキテクチャは以下の通り。

まず、医療者が気軽に書き込めるように、患者さんごとのチャンネルを Slack の上に作る。

そこに、患者さんに関するメモを放り込んでいく。体調の変化、家族のひとこと、訪問看護師がふと感じた違和感、暮らしの困りごと。形式を問わず、思いついたまま。

そのメモをAIが読み取り、さきほどのBPSモデルに沿って自動で仕分ける。

「これはからだの問題」「これはこころの問題」「これはくらしの問題」と。

仕分けた情報を貯めて、患者さんごとの画面に要約し、適宜アラートを飛ばす。そうすれば、医療者がその人の全体像を一目でつかめるのではないか…そういう設計でした。

(念のため再度の説明ですが、使ったのはすべて架空の練習用データです。)

正直、構想の段階ではかなりうまくいきそうに見えていました。BPSという確かな枠組みがあるし、Slackという入力しやすい道具がある。AIもモデルが十分賢くなっている。

「これはいける」と思いました。

そして、実際にテストしてみたら、見事に滑りました。

---

失敗1：コンテキストがすぐ腐った

最初の壁は、コンテキストの腐敗でした。

コンテキストとは、ざっくり言えば「背景」や「文脈」のこと。

患者さんの情報は、バラバラの点ではありません。過去の経過、家族関係、本人の気持ち、医療者の判断。それらがつながって、はじめて意味を持ちます。

ところが、AIに次々と情報を処理させると、このつながりがじわじわ崩れていきました。

どれが本当に重要な情報で、どれが周辺のノイズなのか。何を強調し、何を背景に沈めるべきなのか。その整理が、回を重ねるほど狂っていく。結果として、どうでもいい情報がやけに目立ち、肝心の情報が薄まる、ということが起きました。

これはAIが悪いというより、僕の設計の問題でした。

「何をシグナル(意味のある合図)として扱い、何をノイズ(雑音)として捨てるのか」を、僕がちゃんと決めていなかった。AIに放り込めば、勝手にいい感じに整理してくれるだろう――そう甘く見ていた部分があったのです。

現場ではそれでは通用しません。AIに渡す前に、情報の重みづけをある程度こちらで制御しておかないと、文脈はあっという間に腐ってしまいます。

---

失敗2：やり取りを重ねるほど、AIが平気で嘘をつき始める

二つ目の壁は、ハルシネーションです。

AIが、事実でないことを、いかにももっともらしく言ってしまう現象のことです。

一回目のやり取りでは、大きな問題はありませんでした。ところが、二回、三回と会話を重ねるうちに、前後関係や因果関係が崩れ始めたのです。

言ってもいないことを「言った」ことにする。別の情報と混ざる。まるで別の患者さんの話のようなものが、しれっと出てくる。

繰り返しますが、使っていたのは架空の練習用データです。それでも、これを現場に置くことを想像すると、致命的だと感じました。

患者さんの情報が混ざる。経過の意味が変わる。因果がずれる。こんなことが起こりうるAIを、臨床判断のすぐそばに置くことはできません。

そしてこれも、「もっと賢いモデルに替えれば解決」という話ではありませんでした。

AIが何を根拠にそう言ったのか。どの情報を見たのか。どの時点の文脈を参照したのか。どこから先は人間が確認するのか。所謂「ログ監査」の仕組みがないと、AIの出力は現場では扱いに困るものになると実感しました。

---

失敗3：アラートが多すぎて、かえって邪魔になる

三つ目の壁は、アラートの暴力でした。

もともと僕は、AIで医療者の負担を減らしたいと思っていました。大事な変化を拾ってくれる。見落としそうな情報を知らせてくれる。状態が変わったら通知してくれる。そうすれば現場は楽になるはずだ、と。

ところが、現実は真逆でした。

AIが真面目に働きすぎて、Slackに通知が鳴りやまなくなったのです。

1分おき、2分おきに何かが届く。しかも、その全部が本当に重要なわけではない。

完全に逆効果でした。負担を減らすはずのAIが、新しい負担を生み出してしまった。

通知が多すぎると、人はやがて見なくなります。本当に大事なアラートまで、洪水の中に埋もれてしまう。「またAIが何か言ってる」で済まされるようになったら、システムとしては終わりです。

ここで必要なのは、何でもかんでも知らせてもらうことではありません。どれは通知すべきで、どれは記録だけでよく、どれは人間の確認を待つべきか。その線引きのほうが、よほど重要でした。

---

見えてきたのは、「モデル」ではなく「ハーネス」の問題だった

三つの失敗を並べてみて、はっきり見えたことがあります。

患者中心AIの本当の課題は、AIモデルそのものの賢さではない、ということです。

もちろん性能は大事です。でも、現場で使うには、それ以上に「ハーネス設計」が重要になってきます。

ハーネスとは、AIを安全に、安定して、目的どおりに働かせるための「枠組み」のことです。馬具や安全帯のハーネスと同じで、強い力を暴れさせず、行ってほしい方向へ導くための仕掛けだと思ってください。

• どんな情報を入れるのか

• どの段階で仕分けるのか

• 何を保存し、何を捨てるのか

• どこで人間が確認するのか

• どの出力なら判断に使ってよいのか

• どんな記録を残すのか

• どんな画面で人に見せるのか

この全体の設計がないと、AIはいとも簡単に発散します。

今回のプロトタイプも、「BPSモデルで患者情報を仕分ける」という方向性そのものは、間違っていなかったと思っています。間違っていたのは、入力の設計、情報の仕分け、文脈の管理、通知の制御、そして人間が確認する場所、つまりハーネスが甘かったことでした。

だから、構想としては面白くても、現場でそのまま使えるものにはならなかった。

---

結局、人間が「どこで関わるか」を設計するしかない

この経験で改めて重要性を感じたのが、Human-in-the-loop(人間を仕組みの中に組み込む)という考え方です。

AIにすべてを任せるのではなく、人間がどこで確認し、どこで承認し、どこで判断に使うのかを、あらかじめ設計しておく。

AIが情報を整理する。候補を出す。アラートを上げる。そこまでは、AIにもできるかもしれません。

でも、その情報を実際の判断にどう使うかは、人間が確かめる必要があります。

特に医療では、出力が正しいかどうかだけでなく、その出力をどう扱ったかが問われます。

誰が確認したのか。何を根拠に承認したのか。どの時点の情報を使ったのか。結果として何を判断したのか。

この流れを後から追えるようにしておかないと、安心して現場には入れられません。患者中心AIの実装とは、AI単体を磨くことではなく、AIと人間の分担を設計することなのだと思います。

---

「APPLY」とは、AIを患者さんにそのままぶつけることではない

今回の発表で僕が一番伝えたかったのは、「AIで患者さんを診断できます」という話ではありませんでした。

AIをそのまま患者さんに当てようとすると、簡単に失敗します。文脈は腐り、AIは嘘をつき始め、通知は溢れ、情報は混ざり、確認すべき場所は曖昧になる。

だからこそ、APPLYには設計がいる。

患者さんの情報をどう入れ、AIがどう整理し、どこで人間が確認し、どんな形で現場に返し、どの情報を判断に使い、どの情報を次の改善につなげるのか。この一連の仕組みを作ることが、「患者中心AIを現場で使う」ということの正体でした。

プロトタイプは、うまくいきませんでした。

でも、滑ったおかげで、どこを設計しなければいけないのかが、くっきり見えました。

患者中心AIに必要なのは、ただ賢いモデルではありません。患者さんの文脈を腐らせず、必要な情報だけを取り出し、人間が適切に確認できる形で現場に返す「ハーネス設計」です。

AIを患者さんにAPPLYするとは、AIを医療現場に放り込むことではない。AIが安全に働ける枠組みを作り、人間の判断とつなぐこと。

そして僕は、いつもこう考えています。そういう枠組みが「ない」のなら、つくるしかない。 これからの医療AI実装の本当の課題は、たぶんそこにあります。

今回の発表はそこを伝えるために行いましたが、発表の反響もかなりあってよかったです。次回以後はそこから人間関係が「繋がった」話をしようと思います。

---

ここまで読んでくださって、ありがとうございました。

もしあなたが医療者なら、「自分の現場でAIを使うとしたら、どこで人間が確認すべきか」を一度だけ想像してみてください。医療者でない方でも、あなたの仕事にAIを入れるときも、たぶん同じ「ハーネスの問題」が起きます。きっと参考になると思います。

うまくいった話より、滑った話のほうが学びは多かった。この記事を読んでそう思ってくれた方は、よかったらフォロー・購読して、以後の記事にも付き合ってもらえたら嬉しいです。