何が起きたか
Heidiはオーストラリア発の「AI Care Partner」で、主力製品Heidi Scribeは臨床医の一日を圧迫する事務作業を自動化します。現在190カ国以上で稼働し、週あたり約270万件の患者対応を処理しています。共同創業者兼CTOのYu Liu氏は、この規模を支えているのは「グローバル展開の何年も前に下したインフラの意思決定」だと述べています。
注目すべきは、同社が語る内容が「どのLLMを使ったか」ではなく、データをどこに置き、どう分離し、どう監査可能にしたかというインフラ設計に終始している点です。
なぜ重要か：許容誤差の違いが設計を変える
Liu氏は「多くの産業では2%間違えるAI機能は不便で済むが、医療では同じエラー率が臨床安全性の問題になる」と指摘します。ここから導かれる要件は、精度向上の話ではありません。「すべての出力が精査され、監査され、患者ケアの根拠として使われうる」前提でアーキテクチャを組む、という要件です。
実際Heidiは初日から監査性を作り込み、数カ月後でも「モデルが何を見て、何を出力し、臨床医が何を修正したか」をセッション単位で答えられるようにしています。生成AIのPoCでよく後回しにされる部分が、ここでは製品の前提条件になっています。
リージョン分離は「契約ではなくインフラで守る」
シドニー、ロンドン、東京、デンバーの臨床医は、それぞれオーストラリア・プライバシー原則、GDPR、APPI、HIPAAという異なる規制下にあります。患者データは域内に留めなければならない。Heidiはこれを、リージョンごとに論理的に完全分離した本番環境として実装しました。各リージョンが独自のMongoDB Atlasクラスタ、独自のコンピュート、独自の鍵を持ちます。
Liu氏はこれを「契約で約束するのではなくインフラで強制されている」と表現します。米国の医療システム、英国のNHSトラスト、豪州の病院グループのいずれに対しても、レジデンシーについて同じ明快な回答ができる。この一貫性が営業サイクルを短くしている構図です。
RAGの「取得元」がコンプライアンス面になる
HeidiはLangChainを使い大量の医療文書をAtlas上でベクトル埋め込みに変換し、文字起こしされた医療用語と外部知識を意味的に結び付けています。Atlas移行によって主要APIのレイテンシは約33%削減されました。文書モデルとMongoDB Vector Searchが統合されているため、別途ベクトルDBを外付けする必要がなかった点も選定理由に挙がっています。
重要なのは、埋め込みとベクトルインデックスが他のデータと同じ分離環境内に置かれていることです。これにより検索がレジデンシー境界を越えることが構造的に起こりえません。Liu氏は「消費者向けRAGはオープンウェブから取得して祈るが、医療では取得元こそがコンプライアンス面だ」と述べます。Heidi EvidenceはBMJ Best Practice、NICE CKS、MIMSといったライセンス済み知識ベースから、英国の医師には英国のガイダンス、豪州の医師には豪州の処方集を返す管轄認識型の設計です。
医療データに行と列は合わなかった
フォーム、紹介状、医師のメモ——出所も形式もばらばらな医療データを一つの一貫した形式に統合する必要があり、硬直的な行と列は不向きでした。1つのAI Scribeセッションは文字起こし、構造化ノート、テンプレート、文書、患者コンテキスト、EHR連携状態など数十種の関連成果物で構成され、その中身は週単位で変わります。ドキュメントDBを選んだことで、マイグレーション凍結なしにスキーマを進化させられています。
変更の「爆風半径」を小さくする
Liu氏は、規制の緩い産業なら速く出して直せばよいが、医療では「変更が既定で安全になること」に重く投資すると語ります。リスクの高い変更クラスへのCIゲート、カナリアリリース、そしてDBのスキーマ・インデックス変更すらレビュー対象のコードとして扱う。速度は安全性の副産物であり、安全性を犠牲にして得るものではない、という整理です。
後から取り返せない判断もある
一方で率直な反省も語られています。「初日にシャードキーを選ぶのは設計会議だが、巨大でホットな常時稼働コレクションを再パーティションするのは本格的なエンジニアリング事業だ」。同社は現在その作業をMongoDBと共同で進めています。水平スケールは、レジデンシーと同様に創業時に決めるべき事項だという教訓です。
米国では、ニューイングランド最大級の医療システムBeth Israel Lahey Healthがパイロットを経て導入し、臨床医の74%が時間外の記録作業（いわゆる「パジャマタイム」）の減少を報告しました。非営利のMaineGeneral Healthも地方医療の取り組みで戦略パートナーに選定しています。米国参入は「HIPAA対応をあとから作り直す」のではなく、既存のレールの上に新しいリージョンを立てるだけで済んだ、とLiu氏は述べています。
※本記事はMongoDBがスポンサーとしてVentureBeatに提供した記事の事実に基づいています。
💼 事業会社視点：これは自社にどう効くか
日本企業の役員が読むべきは「医療AIの事例��ではなく「規制産業でAIを事業化する順序」です。金融、保険、人材、公共向けSaaSでPoCが本番に届かない典型的な理由は、モデル精度ではなくデータの置き場所と監査性が後付けだからです。Heidiは監査ログとリージョン分離を初日に作り込み、結果として米国参入時に「HIPAA対応の作り直し」を回避しました。
国内SaaS事業者への含意は明確です。APPI準拠だけで設計した基盤は、そのままではGDPRやHIPAAの顧客に売れません。海外展開を1年でも視野に入れるなら、リージョンごとに鍵とクラスタを分ける構成を今の設計に織り込むべきです。逆に、国内の大手企業に売る側も「どのリージョンのどのクラスタに、どの鍵で保管されるか」を契約書ではなく構成図で示せるかが、稟議の通過速度を左右します。
受託開発・SIerにとっては提案の切り口が変わります。「生成AI導入」ではなく「変更の爆風半径を下げる基盤整備」——CIゲート、カナリアリリース、スキーマ変更のコードレビュー化——が、規制産業の顧客には刺さる商材になります。
そして最も実務的な教訓はシャードキーの話です。初日なら設計会議、後からなら一大プロジェクト。RAGの取得元をどの境界内に閉じるか、最速で伸びるデータをどう水平分割するか。この2点は、AI企画がPoC段階のうちにCTOに確認させておくべき論点です。