病院のAIは、診断より先に書類に向かう。Google Cloudが売り出したのは、電子カルテと保険請求の間を埋める層だ。
Gemini for healthcareは診断の道具ではない
Google Cloudは2026年11月上旬、Gemini for healthcareをpreviewで公開した。最高経営責任者のThomas Kurianは、業種向けに作り込んだソリューションだと説明する。10月のGemini at Workで出した汎用のエージェントを、医療の業務に広げた形だ。
狙いは診療報酬に関わる事務と、カルテの周辺にある。診断そのものではない。医療向けのAIは診断支援として語られることが多いが、今回の発表はそこを外し、書類と審査の側から入った。
agentic layerは4つの部品でできている
構成は4つに分かれる。医療の業務知識を書いたスキル、臨床・財務・運用のシステムにつなぐコネクタ、提携先のエコシステム、そしてモデルを選べる統制された土台だ。
このagentic layerが、既存の電子カルテの上に乗る。カルテを置き換えるのではなく、その周りで動く。部品を分けたのは、病院ごとに使うシステムが違うためだ。電子カルテも会計も、同じ製品が入っているわけではない。提携先のモデルも同じ統制の下で混ぜられる。
Gemini for healthcareは患者の年表とカルテ準備を担う
医療提供者側の業務では、患者の年表を作る。続いている問題と解決済みの問題を分け、薬の食い違いに印を付ける。受診の前には、カルテの準備を1枚にまとめる。
日本の病院でいえば、紹介状と前回の処方を持ち寄って申し送りを作る作業に近い。人が画面をまたいで集めていたものを、1つの流れに置き換える発想だ。
prior authorizationの申請と不服申し立て
事前承認の申請は、支払者の方針に照らして書類を組み立ててから出す。否認が返ってきた場合は、診療記録と保険の規定に根拠を置いた不服申し立ての下書きを作る。
米国のprior authorizationが抱える手間は、日本のレセプト請求や返戻対応と質が似ている。どちらも、記録を読み直して書き直す作業が発生する。件数が増えるほど、そこに人が張り付く。
Google Cloud healthcare AIは支払者側の審査も担う
支払者の側では、届いた依頼を医療政策と突き合わせ、臨床の審査担当者向けに論点を整理する。加入者には、自分の保険証券の文書から給付と費用を説明する。
同じagentic layerが、出す側と受ける側の両方で動く。片方だけを速くすると、負荷はもう片方に移る。審査の件数が増えれば、返ってくる否認も増える。両方が同じ土台を使えば、言い分の食い違いは記録の側で見つけやすくなる。
HIPAAは準拠認定ではなく、準拠を支える設計
Googleの説明は、HIPAA complianceを支えるように作った、というものだ。認定を取ったとは言っていない。エージェントはそれぞれ別のIDを持ち、利用者の権限を引き継ぎ、必要範囲の境界を守る。
監査ログと引用も付く。審査する人が、その答えの根拠を後からたどれるようにするためだ。医療の現場では、速さより説明できることが効く。患者や家族に説明する場面でも、根拠を示せるかどうかが問われる。
Google Cloud healthcare AIの28時間という数字
効果を測る材料として、同社は1つの数字を出している。臨床医が週に28時間近くを、つながっていないシステム間の情報突き合わせに使っているという。同社の数字で、独立した調査ではない。
日本の医療機関が検討するなら、最初に見るのは費用と、対応する電子カルテの範囲だ。患者数も導入病院数も公表されていない。料金も書かれていない。previewの間に何を確かめておくべきか？試せる範囲は契約の条件で変わる。判断材料は、まだ足りない。
