Intake AI · 現場でいちばん痛いこと
新しいファイルは毎月届き、形式も変わります。これまでの道は 1 つだけでした。誰かが 1 マスずつ読み、意味を判断し、システムへ移す。正しくできても誰も気づきません。間違えても、やはり誰も気づきません。間違ったマスは静かにカルテになり、次にそれを読む人には、それが間違いだと分かる手立てがありません。そしてこれに 8 年を費やす価値があるのは、ひとりの人の健康記録を次にケアする人が引き継げるかどうかが、すべてのマスが正しく移されたことにかかっているからです。土台が狂っていれば、その上に賢いものを建てるほど危険になります。このページで扱うのは、プラットフォーム内でこの仕事を担うエンジン——私たちは Intake AI と呼んでいます——の仕組みと、意図的に AI を入れていない場所です。
どこが痛いのか
「他院」の列には、病院名・改行・アルファベット 2 文字が入った 1 マスがあります。その 2 文字は疾患の略語です。1 マス、2 つの事実、間にあるのは改行 1 つだけ。データを移す人は、後半が疾患であることも、それがどの診断に対応するかも、自分で知っている必要があります。見落とせば、この方の病歴が 1 つ足りなくなる——しかも、足りないことに誰も気づきません。
同じ表には他にもあります。氏名とカルテ番号が 1 マスに詰まっている。血圧が「120/2」——拡張期 2 はありえないので入力ミスですが、本来の値はもう分かりません。見出しが「欄16」だけの列もあります。「血圧」と書かれた列の中身が実は心拍数、という列もあり、列名どおりに移せば、この方の血圧が脈拍になってしまいます。
これは例外ではなく、日常です。帳票は忙しい合間に書かれ、列名は前任者から引き継がれ、形式は毎年変わります。そして移し間違いはその場でエラーになりません。記録の中に残り、次に誰かがその記録を根拠に判断するときまで待っています。
上記はすべて書き換えた例示です。残したのはこれらのマスが実際に持っている「形」だけで、実在の方のデータではありません。実際のファイルにある氏名・カルテ番号・施設名がここに現れることはなく、機関自身のサーバールームから出ることもありません。
そして彼女の本当の仕事は、データを移すことではなく、人をケアすることです。
どう動くのか
難しいのは「AI にファイルを読ませること」ではありません。信頼できる形で読み、なぜそう読んだか説明でき、しかもカルテをクラウドに送らないこと。だから順序は意図的です。
本当の見出し行は何行目か。1 行は 1 人か、それとも 1 回のサービスか。横に展開された回次はあるか、シートは複数か。表計算ファイルはこうした事実を（結合セルやセル書式として）そのまま持っています。統計で近似する前に、それを読みます。この層に AI は一切ありません。
肝心なのは列名を信じないことです。列名は嘘をつくので、その列の値の姿も一緒に見ます。「137/67」が並ぶ列は血圧、「123/AC」は空腹時血糖、「V(114年)」はその年に実施済み。典型的なファイルでは、この層だけで 9 割以上が AI に触れずに解決します。
人が一度確認した対応は記憶されます。しかも列名だけでなく、「列名＋値の形＋そのとき理解した意味」の組み合わせで記憶します。だから同じ拠点の翌月の表や、薬局の毎月の表は、2 回目以降 AI すら通りません。
しかも 1 バッチでまとめて尋ね、列ごとには呼びません。使うのは自分たちで訓練したオンプレの意味モデルで、機関自身の機械の上で動きます。ネットワークも課金もありません。モデルは決定論的な層が読めなかった部分だけを埋め、確定した判断を上書きできません。モデルが壊れた結果を返したら 1 つ下の層に戻り、取り込み全体が失敗することはありません。
本当に答えが存在しないものだけです。「120/2」のように元の値が失われているマス。尋ねるときは、その列の値のサンプルとシステム自身の推測を添えます。白紙の表を渡して最初から確認させることはしません。もらった答えは記憶され、次は尋ねません。
私たちが自分を測る指標は 1 つだけです。ファイルが 1 つ入ってきたあと、まだ人の手が必要な列がいくつ残るか。この数字をゼロへ向けて動かし続けます。
意図的にやらないこと
すべてのマスをクラウドモデルに送れば、請求は機関に回り、オンプレの層は成立しなくなります。だから 1 ファイルあたりのモデル呼び出しは「1 回のバッチ」か「0 回」（記憶にヒット）で、列数と等しくなることはありません。
血圧が 120/2 なら、印をつけて元の値を残します。親切に「120/82 へ直す」ことはしません。システムは間違えて直してもらってよいのですが、もっともらしい数字をこっそりカルテに書き込むことは許されません。
本当に解けた列は、その本当の意味を表示します。形だけ認識した列は正直にこう言います。「これがコード列の集まりだとは分かりますが、何を尋ねているかは分かりません。確認するか、対照表をください」。画面上を完成させるほうが簡単で、そしてそれは「もう確認済み」と人に思わせてしまいます。
判断するモデルは機関自身の機械で動きます。患者データがサーバールームを出る必要はなく、1 マスを正しく読むために越境移転の同意を交わす必要もありません。
移し間違えていないと、どうして言えるのか
移し間違いはその場でエラーにならないので、確かめる方法は 1 マスずつ照合する以外にありません。この 6 冊は別の拠点・別の人が作った年度名簿と電話訪問追跡表で、私たちが作った問題ではありません。システムが各事実をどこへ送ったかを照合し、1,088 件のうち 9 件が誤った場所に入りました。
その 9 件がどう間違ったかは、私たち自身が報告に書いています。先に挙げた「病院名＋改行＋疾患の略語」のマスもその 1 つです。病院名は正しく切り出せましたが、疾患の略語がくっついたまま残りました。修正するたびに 6 冊を再実行します。ある種のくっつき方を直しても、次の種類が直ったとは限らないからです。
取り込まないデータもあります。氏名のない電話訪問行、書式が判別できない身分証番号。これらは人に渡す印をつけます。推測もせず、無理に通しもしません。誰かがもう一度見るほうが、間違った記録が静かに入るよりましです。
1,088
実物の名簿 6 冊で 1 マスずつ照合した件数
9
誤った場所に送られた件数。すべて報告に記載
9 割以上
典型的なファイルで決定論的に読み終え、AI に触れない列
院内で完結
判断するモデルは機関自身の機械で動く
なぜ自分たちのモデルが必要なのか
4 番目の層が読む相手は、「他院」列の CV、健診名簿の L-CT、看護記録の「皮蛇」です。市場で最も評価の高い中国語モデルを試しましたが、ほとんど読めませんでした。公開されている学習データに存在しないからです。だから自分で訓練し、公開しました。
もう半分は音の話です。面談や訪問で話された内容も、以前は事務所に戻って打ち直していました。しかも高齢者が話すのは台湾語です。それがもう 1 種類のモデルの話になります。