第2回　医療業界における生成AIの応用をアーキテクチャから考える

皆さんこんにちは。スリーシェイク代表の吉田です。

前回に続き、今回は医療業界で生成AIがすでにどう活用されているか、また課題や解決策について、前提となる法律や実現に必要なアーキテクチャを解説していきます。

「医療の世界とAI」と聞くと非常に先進的で、私達の生活向上に直結するイメージですが、さまざまな前提が存在し、エンジニアとして把握しておかないと知らず知らずのうちに法令違反してしまうケースがあります。あまりエンジニア向けに解説された記事が少ないので、そこを解説してみます。

医療行為を生成AIが代替できるのか

MLやDeep Learningの進歩により自動運転が実現しつつある今、エンジニア視点だと「医療行為（診察、検査、診断、治療など⁠）⁠」も自動化できるのではないかと考えるのは当然のことです。実際に技術的には可能なところまで来ています。しかし、ここには大きな前提があり、法律面での制限があります。

まず医師法第17条にて「医師でなければ、医業をなしてはならない。」とあります。

生成AIであれ、MLやDeep Learningを用いた推論であれ、いずれにせよ医療行為（診察、検査、診断、治療など）はできないのです。

この法律自体は昭和23年に制定されたものですが、のちに厚生労働省は「AIは診療プロセスの中で診断仮説形成支援や治療戦略立案支援などの効率を上げて情報を提示する支援ツールにすぎず、判断の主体は医師である」と整理しました。

つまり、生成AIの医療業界での活路は

院内業務の支援
医学教育
医学論文調査
医療記録や診断報告書などの事務作業
患者説明の支援

といった医療行為以外にまつわる膨大な業務の支援をゴールとして設計する必要があります（裏を返せば、今後生成AIを使った医療行為を検知し、警鐘を鳴らす仕組みも求められるでしょう⁠）⁠。

また開発するアプリケーションの内容によっては、「⁠医療機器プログラム」に該当するかどうかも注意しなければいけないポイントです。

これは診断、治療、予防に使用され、そのアプリケーションによる副作用または機能障害によって生命や健康に影響を与えるものが該当します（例: 手術用ロボットに生成AIを組み込んで、医師と対話できるようにする。治療計画をシミュレーションして、提案するなど⁠）⁠。この場合、実運用に際しては安全性試験、臨床試験、承認審査などを得ることが必要になります。

つまり、生成AIアプリケーション自体が生命、及び健康にほとんど影響がないものは医療機器に該当しないことになります。

個人情報の取扱について

医療業界において個人情報の取り扱いは非常に重要です。

前述した医療行為や医療機器に該当しないAIアプリケーション開発や生成AIを活用するうえで、正しく個人情報関連の法律を意識してデータ設計をする必要があります。

改めて「個人情報」とは、生存する個人に関する情報であり、下表のようなものが挙げられます。

氏名、生年月日
特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む）
個人識別符号	身体的特徴系符号	ゲノムデータ
		顔データ
		虹彩模様データ
		声紋データ
		歩行態様データ
		手の静脈形状データ
		手の静脈形状データ
		指紋・掌紋データ
	番号系符号	パスポート番号
		基礎年金番号
		運転免許証番号
		住民票コード
		マイナンバー
		健康保険証の記号・番号

このあたりは実際のアプリケーション開発現場でも意識されている領域だと思います。

さらに医療業界で意識しなければいけないのは、平成29年5月の改正個人情報保護法により定義された「要配慮個人情報」という概念です。

診療記録
病歴
医療従事者が知り得た診療情報や調剤情報（調剤録、薬剤服用歴、お薬手帳に記載された情報）
健康診断の結果及び保健指導の内容
障害の事実
犯罪により害を被った事実

などが挙げられます。つまり、その情報を第三者が知ることで不当な差別や偏見、不利益が生じてしまう可能性があるものが対象です。

これら個人情報及び要配慮個人情報については、

本人の同意なしの個人情報の目的外利用禁止
本人の同意なしの要配慮個人情報の取得禁止
本人の同意なしの個人情報の第三者提供禁止

と定義されており、たとえば個人情報や要配慮個人情報を社外のクラウドサービスが提供するストレージやデータベースに格納することは違反なのか？（＝情報を第三者に提供してるのか？クラウドサービスを利用することに対して本人の同意が必要なのか？）でいうと、あくまでクラウドサービス提供者に対してデータの取扱を「委託」していると整理することで第三者提供にはあたらない、つまり、個人情報保護法には抵触しません。

一方で「その取扱いを委託された個人データの安全管理が図られるよう、委託を受けた者に対する必要かつ適切な監督を行わなければならない。」とあります。

これは実際の現場でどうするかというと、クラウドサービスを選定するときに、事業者が保存したデータに対してアクセスしない旨が明記された利用規約を確認することをオススメします（クラウドサービス側からQ&Aセッションを個別に設けてもらうことも正しい判断として重要です⁠）⁠。

以下、各クラウドサービスに関してのポリシーや規約です。

全般的なプライバシーポリシーについて(PDF)

生成AIについて

ここで重要なのが、医療機関で取得したデータに基づいて構築した生成AI、もしくはDeep Learningアプリケーションなどを「誰が」使うのか？ということです。

取得した医療機関において活用されるのであれば第三者提供には該当しませんが、たとえば別の医療機関や研究機関、もしくは汎用的なサービスとして一般公開される場合は該当します。

つまり、日本中のあらゆる診療機関からデータを統合して、汎用的な医療LLM（誰でもどこでも使えるもの）を作ることは個人情報的に実質不可能なのです。

情報：令和6年4月に施行された次世代医療基盤法により、氏名など単体で個人を識別できる情報を削除（加工）すれば、第三者機関での利用が可能になりました。しかし、図1のような仮名加工処理ができる国の認定事業者は実質大手SIer数社に留まり、さらにその加工データを取り扱える事業者も国の認定が必要であることから、実際の医療現場において、汎用的な医療LLMが生まれるのは現実的ではないと考える人が多いようです。

さて、医療業界における前置きが長くなりましたが、前向きに捉えると、上記を踏まえたうえで、医療機関内で取得したデータを基に、正しくアプリケーションを構築、運用していけば、生成AIやDeep LearningなどのAIの恩恵をパブリッククラウド上で受けられるということです。

医療特化型のLLMについて

オープンLLM（LlamaやMistral）をベースに、医学論文やPubMedQAなどのオープンデータを用いて追加事前学習を行った医療特化型のLLMが複数存在します。BioMistralやMeditronなどです。

このようなオープンなモデルを用いて国内利用も今後広まると考えられます。

ちなみに弊社ではR&Dの一環として、Meditron-7BとELYZA-japanese-Llama-2-7bをモデルマージして日本語用LLMの開発に着手したことがありますが、Google Cloud上の環境でa2-highgpu-1g（12vCPU、85GB⁠）⁠、1×NVIDIA A100 40GBで、月80万円を超えそうな勢いでしたので、断念しました……。こちらは機会を見て再挑戦してみたいと思います。

またGoogle Cloudではクローズドモデルとして、医療に特化したMedLMモデルが提供されています。事例は少ないですが、今後パブリッククラウド事業者側が提供する業界特化型のモデルを活用したアーキテクチャも進むことでしょう。

以上から、現段階ではあくまで汎用的なLLMに対してRAGを構築するアーキテクチャを採用するのがベターと考えられます。

なぜ医療業界において生成AIが普及しないのか

私自身この数ヵ月間、医療システムについて実際の現場を見せていただく機会がありましたが、前段の法的な制約以外に、以下の課題があると認識しました。

医療システムは用途に応じてメーカーが異なる医療機器、システムが複雑に密結合している集合体であり、生成AIを活用には既存システム連携が必要（= システム連携コストが高い）
生成AIの生成物について、品質保証が難しい
現場（医師、看護師など）におけるITリテラシー
そもそも大規模なシステム投資は他業界と比べて難しい

2については、Nature Medicineの論文が提唱する「医療における責任ある機械学習ソリューションの展開のためのロードマップ」にて、機械学習モデルが出力する結果は必ずしも正しい内容であるとは限らず、それを使う医療従事者が機械学習モデルの仕組みと生成品質の限界を理解したうえで、利用することが求められるとあります。これは生成AIにも同じことが言えます。

たとえば、生成AIが出力した内容に従って医療文章を確認せずに作成し、その内容が間違っていた場合、その結果責任は生成AIの利用者が負うことになります。そういう意味で、医療現場が生成AIについて責任を持って利用する必要があり、開発するエンジニアは導入時に医療現場に対してシステムの内容（生成AIの仕組み）や生成物の品質について説明をすることが求められます。

3については、医療現場は当然ですがITリテラシーの高い業界ではありません。すでに導入されているシステムに最適化されたオペレーションを日々回している現場にとって、新しいUXを導入することは学習コストや業務フロー変更の負担が高く、それを受け入れられる状況にありません。

4については、医療は基本的に診療報酬と研究費に依存したビジネスモデルであり、半数以上が赤字運営という厳しい病院経営の中で、大規模なシステム投資に踏み切るのは容易ではありません。

つまり、日本の医療業界において生成AIを活躍させるポイントは、

いかに学習コストを下げられるか
いかに低コストで始められるか
いかに品質面をトレースできるか
いかに個人情報を守るか

の4点を押さえていく必要があります（とても難易度が高い...⁠）⁠。

海外の医療業界では生成AIはどう活用されているか

HCA Healthcare社は、ハンズフリーデバイスを用いて、医師と患者の会話から生成AIを用いて医療メモを作成し、自動的に電子カルテに転送する仕組みを提供することで、看護師間の引き継ぎ負荷を減らしました。音声と生成AIとの相性は良いですから、良い事例だと思います。

日本の医療業界では生成AIはどう活用されているか

まだまだ日本においては事例が少ないですが、音声や画像よりも電子カルテから医療文章（紹介状や検査依頼書）の作成補助を試みるケースが散見されます。

図3のようにAWSからユースケースが提示されています。オンプレミス環境にある電子カルテシステムからDirect Connectを通じて、生成AIを呼び出すアーキテクチャとなり構造としては比較的シンプルです。

医療業界においてクラウド上で生成AIを活用したアプリケーションを構築するには

前段が長くなりましたが、個人情報や品質面をクリアしつつ、低コストなアーキテクチャをどう作っていくかについて解説します。ここでは何をデータとして取り扱うのかに合わせて大きく2パターンで考えていくことを推奨します（すべてのアプリケーションを個人情報対応型にするとコストが肥大するため⁠）⁠。

個人情報（要配慮個人情報を含む）を扱わないアプリケーションの場合

各パブリッククラウドにおいて生成AIアプリケーションを構築する際の基本的なアーキテクチャは、前回の記事を参考にしていただくと良いと思います。

ここで重要となるのが、「⁠本当にこのアプリケーションは個人情報を扱ってないのか？」を評価する機構、さらに強制的に個人情報を扱えないようにするガードレールが必要です。

つまり

RAGとして誤って個人データが含まれてないか
プロンプトとして誤って個人データが含まれていないか（防げないか）

という2点です。そこでAWSとGoogle Cloud上の生成AIアプリケーションについて、以下の対策を提案します。

AWSの場合

AWS Macieを使ってS3上に保管されているRAGのRAWデータに個人情報がないか検知する
Amazon Bedrock Guardrailsを利用して、個人情報がプロンプトされた場合にフィルタリングする

AWS MacieはS3に保存しているデータ（画像、音声、動画はサポート外）に対して個人情報を検知することが可能です。またBedrockの機能の一部であるGuardrails for Amazon Bedrockにおけるsensitive information filtersオプションを用いることにより、仮にユーザーがプロンプトで誤って個人情報を入力しても、フィルタリングすることが可能です。

Google Cloudの場合

Cloud DLPを用いて、Cloud Storage上に保管されているRAGのRAWデータに個人情報がないか検知する
Guardrails for Amazon Bedrockに類似する機能はないため、アプリケーション側でプロンプト入力時にバリデーションを行うか、LLMが出力した内容に対して個人情報をマスキングして出力する機能をいれる

Google Cloudの場合は、Gemini API側で個人情報をフィルターする機能を提供しているので、それ以前にフィルタリングする機構はいらないよね、という発想に基づいているところが特徴です。

以上に加えて、各クラウドベンダが提供する次のセキュリティ原則を参考にするとよりベターです。

個人情報（要配慮個人情報を含む）を扱うアプリケーションの場合

個人情報を含んだアプリケーションを構築する場合は、上記セキュリティ原則に加えて厚生労働省などがまとめた「3省2ガイドライン」を遵守する必要があります（今回、詳細は割愛します⁠）⁠。

さらに万が一の漏洩リスクを鑑みて、個人情報を仮名加工（他の情報と照合しない限り特定の個人を識別できない情報にする）しておくと良いでしょう。

AWSの場合

Glue DataBrewの活用

RAGとしてS3に保存されたRAWデータに対して、図4のようにGlue DataBrewを用いて仮名加工したデータをRAGとして取り込みます。図ではRAWデータをGlueで加工してOpenSearchに取り込む（その後、Amazon Bedrock Knowledge Basesにてインデックス作成・検索できるようにする）と同時に、加工データをS3に保存する（その後、KendraまたはAmazon Bedrock Knowledge Basesにて検索可能にする）アーキテクチャとなります。このように用途に応じて細かくアーキテクチャを変更できるのがAWSの特徴ですね。

図4　Glue DataBrewを活用した個人情報の検出及びマスキングのアーキテクチャ：参考

Google Cloudの場合

Cloud DLPの活用

RAGとしてCloud Storageに保存されたRAWデータに対して、Cloud DLPを用いて仮名加工し、Cloud StorageもしくはBigQueryを経由してRAGとして利用します。図5ではCloud Storageに逐次保存されたデータに対して、Dataflowを用いてリアルタイム且つ大規模な個人情報の検知及びマスキング処理を行い、BigQueryやストレージに保存するアーキテクチャです。しかし、生成AIアプリケーションの特性上（アップロードした文章に対して、匿名加工のリアルタイム性や大規模処理能力を求められないケースが多いため⁠）⁠、Dataflowではなく、Cloud Functionsを用いることでより簡素なアーキテクチャにするほうがよいでしょう。

図5　Cloud DLPを用いた個人情報の検出及びマスキングのアーキテクチャ：参考

上記はいずれも一時的には（S3なりCloud Storageなり）個人情報がクラウド上に保存されるアーキテクチャになります。より厳しい要件を満たすには、RAGに使うための情報やプロンプトを入力時に即座に仮名加工処理する処理がアプリケーション側に必要ですが、自前で実装するためかなりコストがかかります。

ここは実際の現場で、どこまで情報漏洩のリスクを考えるかを議論して選定すると良いと思います。

最後に

医療業界における生成AIの活用はインパクトは大きくても非常に多くの制約条件があります。

エンジニアとしてこれらを把握しながら、アーキテクチャを考えていくことでtoo muchなシステムにならず、医療業界にとっても挑戦する敷居が下がるのではないでしょうか。