MongoDB、ヘルスケア向け大規模AI実装事例を公開
本文の状態
日本語全文を表示中
詳細モードで約10分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
VentureBeat AI
Heidi は医療規制の厳格な要件に対応するため、データ所在地を強制する論理的分離アーキテクチャとドキュメント型データベースを採用し、190 カ国で安全かつ信頼性の高い AI 製品を提供している。
AI深層分析を開く2026年8月18日 00:33
AI深層分析
キーポイント
医療規制に準拠したアーキテクチャ設計
Heidi はデータ所在地(データレジデンシー)を機能ではなく前提条件とし、地域ごとの異なる法規制(GDPR, HIPAA など)に対応するため論理的に分離されたデプロイメントを構築している。
監査可能性と安全性の優先
変更の影響範囲を最小限に抑えるため、継続的インテグレーションゲートやカナリアリリースを導入し、データベーススキーマの変更すらコードレビューの対象として安全なデプロイを実現している。
多様な医療データの統合と MongoDB の採用
フォーム、紹介状、医師のメモなど多様なソースからのデータを統一フォーマットへ変換するため、柔軟性のあるドキュメント型データベースである MongoDB を基盤として選定した。
ドキュメント型データベースの柔軟性とスケーラビリティ
MongoDB は急速に変化するAIデータに対応し、頻繁なスキーマ変更やマイグレーション凍結なしに臨床ワークフローに沿ったデータ構造を維持できる。
ベクトルデータベースの統合によるパフォーマンス向上
MongoDB Atlas の Vector Search を利用することで追加のベクトルデータベース不要となり、主要APIのレイテンシが約33%削減された。
重要な引用
In most industries, an AI feature that is wrong two percent of the time registers as an inconvenience, while in healthcare that same error rate becomes a clinical safety issue.
The blast radius of change must be engineered down.
For Heidi, data residency is a precondition rather than a feature.
"The model is maybe 20% of the system, and the data architecture is what determines whether the other 80% holds up under real clinical load," Liu says.
編集コメントを表示
編集コメント
医療分野における AI 実装の難易度を示す好例であり、規制対応を技術的負債と捉えるのではなく、設計の前提条件として扱う視点は業界全体に示唆に富む。特にデータ所在地の厳格な管理と変更リスクの最小化手法は、高信頼性が求められる分野での参考となる。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
MongoDB 提供
医療、金融サービス、運輸業界など、コンプライアンス規制が厳しく適用される組織にとって、正確で安全かつ信頼性の高い AI を構築することは、大きなエンジニアリングの成果です。これらの産業では規制により慎重かつゆっくりとした進捗を余儀なくされるため、技術が他分野に比べて遅れがちであるという事実も、AI 駆動型製品の提供における課題をさらに複雑にしています。現在、多くの企業が今日求められる AI の需要に応えるために、データインフラの近代化プロジェクトにも取り組んでいます。
オーストラリア発の AI キャアパートナー「Heidi」は、この近代化が成功した好例です。同社の主力製品である「Heidi Scribe」は、現在 190 カ国以上で医師や看護師の日々を占領する事務作業の多くを自動化し、週に約 270 万件の患者とのやり取りをサポートしています。この拡大を支えているのは、同社がグローバルスケールに達する何年も前に下されたインフラに関する決断です。Heidi の共同創設者兼 CTO(チーフ・テクノロジー・オフィサー)である Yu Liu はそう語ります。
「多くの業界では、AI 機能が 2% の確率で誤った出力を出すことは不便として扱われますが、医療現場では同じ誤り率が臨床的な安全性の問題に直結します」と Liu は指摘します。「そのため、アーキテクチャは『すべての出力が患者のケアにおいて精査され、監査され、信頼される可能性がある』という前提の上に構築されなければなりません。」
なぜ医療分野における本番環境での AI 導入には、独自のアーキテクチャが必要なのか
Heidi にとって、データレジデンシーは機能の一つではなく、必須の前提条件です。シドニー、ロンドン、東京、デンバーの医療従事者はそれぞれ異なる規制体制の下で活動しており、オーストラリアプライバシー原則、GDPR、APPI、HIPAA が適用されます。そのため、患者データの保存場所は地域に限定されなければなりません。
Heidi は世界中で完全に論理的に分離された本番環境を運用しており、データレジデンシーはアーキテクチャによって強制されています。監査可能性も初日から組み込まれていなければなりません。組織は、数ヶ月後に問い合わせがあった際、任意のセッションにおいて「モデルが何を観測し」「何を生成し」「医療従事者が何を変更したか」を明確に説明できる必要があるからです。
「変更の影響範囲(ブラストラジウス)は、意図的に小さく設計する必要がある」と劉氏は語ります。「規制の緩い業界では迅速にリリースして後から修正することも可能ですが、医療分野ではデフォルトで安全な変更を実現するために多大な投資を行っています。危険な変更クラスには継続的インテグレーションのゲートを設け、カナリアリリースを実施し、データベーススキーマやインデックスの変更さえもレビューを経るコードとして扱います。私たちのスピードは、安全性を犠牲にして得たものではなく、安全性によって生み出されたものです」
AI ワークフローに接続するデータベースの選定
Heidi はフォーム、紹介状、医療従事者のノートなど、複数のソースから収集された多様な医療データを扱っています。これらを一貫した形式と単一の場所に統合し、AI ワークフローとシームレスに連携させる必要がありました。硬直した行と列の構造では、このワークロードには不向きです。
Heidi にとって、これらの要件はドキュメント型データベースを採用する自然な選択となりました。MongoDB はチームに柔軟性を与え、基盤となるデータベースを頻繁に変更することなく、急速に変化する AI データに対応できる環境を提供しています。
「このモデルはシステム全体の 20% に過ぎません。残りの 80% が実際の臨床現場の負荷に耐えられるかどうかを決めるのはデータアーキテクチャです」と Liu は語ります。
AI Scribe のセッションは単一のデータポイントではありません。それは、文字起こしテキスト、構造化されたノート、テンプレート、ドキュメント、患者のコンテキスト、EHR(電子カルテ)連携の状態など、週ごとに変わる数十種類の関連アーティファクトの集合体です。MongoDB を使えば、これらのデータを臨床医が実際に作業を行う形式に合わせて統合して保存でき、製品が更新されるたびに移行を停止する必要なく、データ構造を柔軟に進化させることができます。
「MongoDB Atlas が際立っていたのは、シームレスなスケーラビリティ、柔軟性、高性能を実現するドキュメントモデルの強みと、MongoDB Vector Search といった AI に即した機能を内蔵している点の両方を兼ね備えているからです」と Liu は説明します。「これにより、Heidi は既存プラットフォームを補完するために追加でベクトルデータベースを導入する必要がなくなります。」
世界中に 130 以上のクラウドリージョンに加え、オンプレミスやハイブリッド構成もサポートする MongoDB Atlas は、最も広く利用可能なグローバル分散データベースプラットフォームです。統一されたクエリ API を備えているため、開発者はアーキテクチャを複雑化させることなく、全文検索、リアルタイム分析、イベント駆動型の体験を構築できます。
「Heidi Scribe は、Atlas 上の LangChain を介して大量の医療文書をベクトル埋め込みに変換し、転記された医療用語を外部知識と直接結びつける意味検索を可能にします」と劉氏は付け加えます。「また、Atlas への移行により、主要な API のレイテンシが約 33% 短縮されました。」
信頼できる臨床 RAG システムに必要なもの
「検索は AI の問題というより、まずデータアーキテクチャの問題です」と劉氏は言います。「一般消費者向けの RAG ではオープンウェブから情報を取得して運を天に任せるのに対し、医療分野ではコンプライアンス対応が求められる領域から情報を取得する必要があります。」
Heidi Evidence は、BMJ Best Practice、NICE CKS、MIMS などのパートナー企業によるライセンスされた臨床知識ベースから情報を取得します。また、管轄区域に応じた対応も可能です。例えば、イギリスの医療従事者にはイギリスのガイドラインが、オーストラリアの医療従事者にはオーストラリアの処方箋リストが表示されます。国によって正解となる情報が異なるためです。
Heidi の埋め込みベクトルとインデックスは MongoDB Vector Search に格納されており、他のデータと同様に地域ごとに分離された環境内に配置されています。これにより、検索処理が物理的に居住境界を越えることがなく、セキュリティやコンプライアンスの要件を満たす別個のベクトルデータベースを運用する必要もありません。出典情報の提示はプロンプト上の提案ではなく厳格な契約事項であり、モデルが参照できるのは既にソース記録に紐付けられた断片のみです。
地域ごとの分離により、グローバル規模でのコンプライアンス対応とスケーラビリティが可能になります
「各リージョンは、MongoDB Atlas クラスターや計算リソース、暗号化キーをそれぞれ独自に持つ、完全かつ独立した本番環境です」と劉氏は説明します。
「これが、米国医療システムや英国の NHS トラスト、オーストラリアの病院グループなど、どこへ赴いても『居住権』に関する明確な回答が可能になる理由です。契約上の約束ではなく、インフラによって強制されているからです。少数のチームで複数の独立したリージョンを運用できるのは、データベース層が管理され、一貫性が保たれているおかげです。また、マルチクラウド構成を採用しているため、すでに構築した基盤(rails)の上に新たなリージョンを迅速に立ち上げることができます」
このアーキテクチャは米国で最も顕著な成果を示しています。ニューイングランド最大級の医療システムであるベス・イスラエル・レイヒ・ヘルスは、パイロット試験で臨床医の 74% が時間外でのドキュメント作成(いわゆる「パジャマタイム」)が減少したと報告した結果を受け、Heidi の AI スクリブを導入しました。また、非営利システムであるメインジェネラル・ヘルスも、地方医療における戦略的パートナーとして Heidi を選定しています。
「米国市場への参入とは、HIPAA 対応を事後に再設計するのではなく、すでに構築した基盤の上に新たなリージョンを立ち上げることを意味します」と劉氏は述べています。
教訓と今後のロードマップ
「大規模でホットな常時稼働コレクションの再パーティショニングは、本格的なエンジニアリングプログラムですが、最初の日からシャードキーを選ぶのは設計会議での決断です」と劉氏は語ります。「現在、私たちは MongoDB と連携してその作業を進めていますが、データ集約型 AI 製品を構築するすべての人への教訓として、最も急速に成長するデータの水平方向のスケールは、居住性(residency)と同様に、基盤となる意思決定であるということです。
Heidi は現在、診察メモだけでなく、訪問前のコンテキストから訪問後の文書、紹介状、ワークフロー自動化までを含む、臨床ワークフロー全体をサポートする範囲へと拡大しています。同社はまた、MongoDB、大規模言語モデル(LLM)、および独自のツールが、臨床ワークフローのためのエージェント型エコシステムをどのように支えられるかを探求中です。
「医療 AI において、信頼性エンジニアリングは信頼の構築そのものです」と劉氏は言います。「医師の信頼は、不具合なメモによって失われるスピードと同じく、ダウンタイムやレイテンシ、データの不一致によっても瞬時に失われます。そのため、私たちが最も影響力のある仕事として取り組んでいるのは、自動ロールバックを伴うカナリアリリース、データベース変更に対する CI ガート(ゲート)、およびクロスリージョン一貫性チェックなど、目に見えない部分です。医師の信頼こそが製品であり、信頼はアーキテクチャそのものです。」
スポンサー記事は、投稿料を支払っている企業または VentureBeat とビジネス関係にある企業が制作したコンテンツであり、必ず明確に表示されています。詳細については sales@venturebeat.com までお問い合わせください。
原文を表示
Presented by MongoDB
Building AI that is accurate, secure, and reliable is a major engineering feat for organizations subject to the compliance obligations that govern healthcare, financial services, and transportation. The challenge of delivering AI-driven products is compounded by the fact that technology in these industries has tended to lag behind other sectors because regulation requires organizations to move carefully — and slowly. Now, many are also confronting data infrastructure modernization projects as they try to catch up with today’s demand for AI.
Australian-founded AI Care Partner Heidi offers an example of successful modernization. Its flagship product, Heidi Scribe, now automates much of the administrative work that consumes clinicians’ days across more than 190 countries, supporting roughly 2.7 million patient interactions each week. That expansion rests on infrastructure decisions taken years before the company reached global scale, says Yu Liu, co-founder and chief technology officer at Heidi.
“In most industries, an AI feature that is wrong two percent of the time registers as an inconvenience, while in healthcare that same error rate becomes a clinical safety issue,” says Liu. “The architecture has to be built around the assumption that every output may be scrutinised, audited, and relied upon in a patient’s care.”
Why deploying production AI in healthcare is architecturally different
For Heidi, data residency is a precondition rather than a feature. A clinician in Sydney, London, Tokyo, or Denver is operating under different regulatory regimes, including the Australian Privacy Principles, GDPR, APPI, and HIPAA, and their patients’ data has to live in-region.
Heidi runs fully logically isolated production deployments across the world, so residency is enforced by architecture. Auditability also has to be built in from day one, because an organization needs to be able to answer what the model saw, what it produced, and what the clinician changed, for any session, months later, when called upon.
“The blast radius of change must be engineered down,” Liu says. “In less regulated industries you can ship fast and fix forward, but in healthcare we invest heavily in making change safe by default, with continuous integration gates on risky change classes, canary releases, and treating even database schema and index changes as code that goes through review. Our speed is a product of that safety rather than something we achieve in spite of it.”
Choosing a database to connect with AI workflows
Heidi handles a diverse set of medical data collected from multiple sources, including forms, referrals, and clinicians’ notes, all of which had to be consolidated into one consistent format and one location to connect seamlessly with AI workflows. Rigid rows and columns would have been ill-suited to that workload.
For Heidi, those requirements made a document database the natural choice.MongoDBgave the team the flexibility to accommodate rapidly changing AI data without constantly reshaping the underlying database.
“The model is maybe 20% of the system, and the data architecture is what determines whether the other 80% holds up under real clinical load,” Liu says.
An AI Scribe session isn’t a single piece of data. It’s a collection of transcripts, structured notes, templates, documents, patient context, EHR integration state, and dozens of other related artifacts that change from week to week. MongoDB lets a session’s data live together in shapes that match how clinicians actually work, and lets Heidi evolve those shapes without a migration freeze every time the product moves.
"MongoDB Atlas stood out because it combined the power of the document model, which allows seamless scale, flexibility, and high performance, with built-in AI-ready features such as MongoDB Vector Search,” Liu says. “This means that Heidi does not need another bolt-on vector database to augment its existing platform.”
With more than 130 cloud regions globally alongside on-premises and hybrid options, MongoDB Atlas is the most widely available, globally distributed database platform, and its unified query API lets developers build full-text search, real-time analytics, and event-driven experiences without complicating their architecture.
"Heidi Scribe converts large volumes of medical documents into vector embeddings via LangChain in Atlas, enabling semantic search that connects transcribed medical terms directly to corresponding external knowledge," Liu adds. "Migrating to Atlas reduced latency on key APIs by nearly 33%."
What a trustworthy clinical RAG system requires
“Retrieval is a data architecture problem before it is an AI problem,” Liu says. "In consumer RAG, you retrieve from the open web and hope, whereas in healthcare what you retrieve from is the compliance surface."
Heidi Evidence retrieves from licensed clinical knowledge bases, including partners like BMJ Best Practice, NICE CKS, and MIMS, and it is jurisdiction-aware, so a U.K. clinician gets U.K. guidance and an Australian clinician gets Australian formularies, because the right answer in one country can be the wrong answer in another.
Heidi’s embeddings and vector indexes live in MongoDB Vector Search, inside the same regionally isolated deployments as the rest of its data, which means retrieval physically cannot cross a residency boundary, and they are not operating a separate vector database with its own security and compliance story. Citations are a hard contract rather than a prompt suggestion, because the model only ever sees retrieved chunks that are already bound to source records.
Regional isolation enables global compliance and scale
“Each region is a full, isolated production deployment with its own MongoDB Atlas clusters, its own compute, and its own key,” Liu says.
“That is what lets us walk into a U.S. health system, an NHS trust, or an Australian hospital group and give a clean answer on residency, because it is enforced by infrastructure rather than promised by contract," he explains. "Running multiple isolated regions with a lean team only works because the database layer is managed and consistent. We are also multi-cloud, meaning a new region can stand up another deployment on rails we have already built."
That architecture has been most visible in the U.S., where Beth Israel Lahey Health, one of New England’s largest health systems, rolled out Heidi’s AI scribe following a pilot finding 74% of clinicians reported reduced after-hours documentation (“pajama time”), and where non-profit system MaineGeneral Health selected Heidi as a strategic partner in its rural healthcare work.
“Entering the U.S. market meant standing up another region on rails we had already built rather than re-engineering for HIPAA after the fact,” Liu says.
Lessons learned and the roadmap ahead
"Re-partitioning a large, hot, always-on collection is a serious engineering program, whereas choosing a shard key on day one is a design meeting," Liu says. "We are doing that work now in partnership with MongoDB, but the lesson for anyone building a data-heavy AI product is that horizontal scale for your fastest-growing data is a founding decision, just like residency."
Heidi is now extending beyond the consult note to support the full clinical workflow, from pre-visit context to post-visit documents, referrals, and workflow automation. The company is also exploring how MongoDB, large language models, and its own tooling can power an agentic ecosystem for clinical workflows.
“In healthcare AI, reliability engineering is trust engineering,” Liu says. “A clinician’s trust is lost just as fast by downtime, latency, or a data inconsistency as by a bad note, and some of our highest-leverage work is invisible, including canary releases with automatic rollback, CI gates on database changes, and cross-region consistency checks. Clinician trust is the product, and trust is architectural.”
Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み