医療分野におけるオンプレミス・エッジ生成AIでのセキュアな診断支援

医療データは1バイトも外に出さない。完全オフラインで構築する診断支援RAGハンズオン【Python/Ollama】

この記事は急速に進化する技術について解説しています。最新情報は公式ドキュメントをご確認ください。

2026年1月5日更新 2026年5月13日約12分で読めます

文字サイズ:

医療データは1バイトも外に出さない。完全オフラインで構築する診断支援RAGハンズオン【Python/Ollama】

この記事の要点

医療データの厳格なセキュリティとプライバシー保護
完全オフラインでの生成AIモデル運用
低遅延かつ迅速な診断支援

「生成AIの可能性は十分に理解しているが、機微な患者データをクラウド環境に送信するわけにはいかない」

AIソリューションのアーキテクチャ設計において、このようなジレンマは医療機関のシステム担当者や開発エンジニアにとって決して珍しいものではありません。

現在、クラウド型LLM（大規模言語モデル）の進化は凄まじく、OpenAIのGPT-4o等のレガシーモデルが廃止されてGPT-5.2が新たな標準モデルへ移行したり、AnthropicのClaude 4.6 Sonnetが高度な推論能力を実現したりと、日進月歩で機能が強化されています。しかし、どれほど強力なクラウドAIが登場しようとも、3省2ガイドラインをはじめとする医療情報の厳格なセキュリティ要件の前では、外部APIへのデータ送信そのものが極めて高い導入ハードルとなります。加えて、クラウドサービス特有の突然のモデル廃止や仕様変更に伴うシステム改修リスクも、安定稼働が求められる現場では軽視できません。

では、高度なAI活用を諦めるしかないのでしょうか。その明確な解決策となるのが、「エッジ（オンプレミス）環境での推論実行」です。

近年のオープンソースモデルの進化は目覚ましく、NPU/TPUの活用や、適切な量子化・プルーニング（枝刈り）といったモデル軽量化技術を駆使すれば、GPUを搭載したローカルサーバー1台で実用レベルの対話AIを稼働させることが可能です。インターネット接続を物理的に遮断した完全な閉域網であっても、AIの恩恵をフルに受けることができます。

本記事では、外部APIへの依存を完全に排除し、100%ローカル環境で動作する「医療用診断支援RAG（検索拡張生成）システム」のプロトタイプ構築手法を解説します。エンドツーエンドの視点で開発から運用までの全体最適を考慮しつつ、セキュアで実用主義的なAI開発のアプローチを探ります。

1. なぜ医療現場には「完全オフライン」のAIが必要なのか

まず、手を動かす前にアーキテクチャの全体像と、なぜこの構成がビジネス価値の最大化に繋がるのかを整理しておきましょう。

クラウドAPIのリスクと3省2ガイドライン

医療情報システムにおいて最も懸念されるのは、個人情報（PII）や要配慮個人情報（PHI）の漏洩リスクです。クラウドベースの生成AIを使用する場合、入力データがサービス提供者のサーバーに送信され、学習に利用される可能性があります（エンタープライズ版などで学習除外設定は可能ですが、通信経路上のリスクや第三者提供の解釈など、コンプライアンス上の調整コストは甚大です）。

完全オフライン環境であれば、データは院内の閉域網（イントラネット）から一歩も出ません。これはセキュリティ上の最強の盾となり、導入の技術的・心理的ハードルを大幅に下げます。

エッジコンピューティングによる低遅延のメリット

セキュリティ以外にもメリットがあります。それは「レイテンシ（遅延）」のコントロールです。

診断支援やカルテ要約といったタスクでは、医師の思考を妨げないレスポンス速度が求められます。インターネット回線の帯域に依存せず、ローカルバス（PCIe）経由でGPUに直結できるエッジAIは、安定した推論速度を提供できます。特に、画像診断データなどの大容量ファイルを扱う場合、この差は顕著になり、現場の業務効率化という実用的な価値に直結します。

本チュートリアルのゴール：診断支援ボットの自作

今回作成するのは、以下のような構成のアプリケーションです。

ユーザーインターフェース: 医師が症状や所見を入力（Streamlit）
セキュリティ層: 患者名などを自動マスキング（Presidio/正規表現）
検索エンジン（RAG）: 院内の過去症例データベースから類似症例を検索（ChromaDB）
生成AI（LLM）: 検索結果を元に、診断のヒントや考慮すべき疾患を提示（Ollama + Llama等の最新LLM）

これら全てを、インターネットに繋がっていない1台のPC（サーバー）の中で完結させます。

2. 開発環境のセットアップ：インターネット遮断環境への準備

医療現場のサーバールームは、セキュリティポリシーによりインターネットから遮断されている（エアギャップ環境）ことが多々あります。そのため、「pip install でエラーが出る」「モデルがダウンロードできない」といった事態を防ぐため、必要なリソースを事前に準備する手順が重要です。現場の制約を前提とした戦略的な準備が求められます。

ハードウェア要件（GPUメモリと量子化の関係）

ローカルLLMを動かす上で最も重要なのは、GPUのVRAM（ビデオメモリ）容量です。

7B/8Bパラメータモデル（4bit量子化）: 最低6GB、推奨8GB以上のVRAM
70Bクラスのモデル: 24GB VRAM×2枚以上が必要

今回は、一般的な業務用ワークステーションやハイエンドゲーミングPC（RTX 3060/4060以上）で動作する8Bクラスのモデルをターゲットにします。低スペックな環境下でも動作する効率的なモデル構築を目指します。

DockerとNVIDIA Container Toolkitの導入

環境依存を避けるため、Dockerを使用します。ホストマシンにNVIDIA DriverとDocker、そしてGPUをコンテナから利用するためのnvidia-container-toolkitがインストールされていることを前提とします。

# 動作確認: GPUが見えているかチェック
docker run --rm --gpus all nvidia/cuda:12.1.1-base-ubuntu22.04 nvidia-smi

必要なモデルファイルの事前ダウンロードと配置

インターネット接続がある環境で、Dockerイメージとモデルファイルをあらかじめ取得し、USBメモリや社内ファイルサーバー経由でオフライン環境へ持ち込む想定で進めます。

今回は、LLMの実行エンジンとして非常に軽量で扱いやすいOllamaを使用します。

準備用マシン（ネット接続あり）での作業:

# Ollamaのイメージをプル
docker pull ollama/ollama:latest

# イメージをファイルとして保存（オフライン環境への持ち込み用）
docker save ollama/ollama:latest -o ollama_image.tar

同様に、Python環境用のベースイメージや、使用するライブラリ（LangChain, Streamlitなど）を含んだrequirements.txtを元に、独自のDockerイメージをビルドしてsaveしておくとスムーズです。

3. Step 1: 医療特化型軽量モデルの選定とローカル起動

開発環境のセットアップ：インターネット遮断環境への準備 - Section Image

環境が整ったら、まずは「脳」となるLLMを起動させましょう。

Llama vs Meditron vs BioMistral：医療ドメインでの性能比較

モデル選びは戦略的に行う必要があります。

Llama (8B): 汎用的な推論能力が非常に高く、指示従順性が良い。日本語もある程度理解する。
Meditron / BioMistral: 医療論文で追加学習されており専門知識に強いが、日本語能力が低い場合が多い。

日本の医療現場での利用を想定する場合、英語の専門用語と日本語のカルテ記述が混在するため、「日本語能力の高い汎用モデル」に「RAGで専門知識を補完する」アプローチが、現時点では最も実用的です。今回は、Meta社のLlamaをベースに日本語能力を強化したモデル（例: Llama-3-ELYZA-JP-8Bなど）の使用を想定しますが、チュートリアルの汎用性を保つため、標準的なLlamaモデルを使って解説します。

Ollamaを使ったローカルAPIサーバーの立ち上げ

オフライン環境のサーバーで、Ollamaをコンテナとして起動します。

# オフライン環境でイメージをロード
docker load -i ollama_image.tar

# GPUを使用してOllamaサーバーを起動
docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

次に、モデルを実行します。通常はollama run Llamaモデルでダウンロードが始まりますが、オフライン環境では事前にモデルファイル（GGUF形式など）を配置し、Modelfileを作成して取り込む必要があります。ここでは、すでにモデルがロードされている状態と仮定して進めます。

# コンテナ内でモデルを実行（初回のみ）
docker exec -it ollama ollama run Llamaモデル

Pythonからの推論テストとレスポンス確認

APIサーバーが立ち上がっていれば、PythonからHTTPリクエストを送るだけでAIと対話できます。外部のOpenAI APIなどは一切経由しません。

import requests
import json

url = "http://localhost:11434/api/generate"

payload = {
    "model": "Llamaモデル",
    "prompt": "あなたは医療診断支援AIです。次の症状から考えられる一般的な疾患を3つ挙げてください：38度の発熱、咽頭痛、頸部リンパ節の腫れ",
    "stream": False
}

response = requests.post(url, json=payload)
result = response.json()
print(result['response'])

実行結果（例）:

提示された症状（発熱、咽頭痛、リンパ節腫脹）から、以下の疾患が一般的に考慮されます。

急性扁桃炎

伝染性単核球症

インフルエンザ
※これは診断ではありません。必ず医師の診察を受けてください。

このように、ローカル環境だけでAIが応答を返してくれます。レスポンスもGPUを使えば数秒です。

4. Step 2: 院内データを活用するローカルRAG（検索拡張生成）の構築

LLM単体では、院内固有のガイドラインや過去の類似症例を知りません。RAG（Retrieval-Augmented Generation）を実装して、AIに「カンニングペーパー」を持たせましょう。

模擬電子カルテデータの準備と前処理

※注意：本記事では実データではなく、ダミーデータを使用します。

まず、検索対象となるドキュメントを用意します。ここでは簡易的にテキストデータとして定義します。

# dummy_data.py
medical_docs = [
    {
        "id": "case_001",
        "content": "患者番号001: 30代男性。主訴は右下腹部痛。マックバーニー点に圧痛あり。反跳痛陽性。急性虫垂炎の疑いで緊急手術を実施。"
    },
    {
        "id": "case_002",
        "content": "患者番号002: 60代女性。突然の激しい頭痛と嘔吐。CTにてくも膜下出血を確認。クリッピング術施行。既往歴に高血圧あり。"
    },
    # ... 他のダミーデータ
]

ローカルVector DB（ChromaDB）の構築

検索エンジンとして、軽量でサーバーレスに動作するChromaDBを使用します。また、文章をベクトル（数値の羅列）に変換するEmbeddingモデルも、HuggingFaceからダウンロードしたものをローカルで動かします。

ここではLangChainライブラリを使用して実装を簡略化します。

from langchain_community.vectorstores import Chroma
from langchain_community.embeddings import OllamaEmbeddings
from langchain.schema import Document

# EmbeddingモデルもOllama経由で利用（nomic-embed-textなどを使用）
# 事前に `ollama pull nomic-embed-text` が必要
embeddings = OllamaEmbeddings(
    model="nomic-embed-text",
    base_url="http://localhost:11434"
)

# ドキュメントオブジェクトへの変換
docs = [Document(page_content=d["content"], metadata={"source": d["id"]}) for d in medical_docs]

# ベクトルDBの作成と保存（永続化）
persist_directory = "./chroma_db"
vectorstore = Chroma.from_documents(
    documents=docs,
    embedding=embeddings,
    persist_directory=persist_directory
)

print("データベース構築完了")

これで、「右下腹部痛」と検索すれば「case_001」がヒットする仕組みがローカルに出来上がりました。

5. Step 3: セキュアな診断支援エージェントの実装

Step 2: 院内データを活用するローカルRAG（検索拡張生成）の構築 - Section Image

いよいよアプリケーションとして統合します。ここでは特に「セキュリティ」を意識し、AIにデータを渡す前のPII（個人特定情報）マスキング処理を実装します。

個人情報（PII）の自動マスキング処理の実装

LLMは入力された情報を一時的に保持する可能性があるため、念には念を入れて、患者名などを伏せ字にします。

import re

def mask_pii(text):
    # 簡易的な正規表現によるマスキング例
    # 実際の運用ではMicrosoft Presidioなどの専用ライブラリと辞書を推奨
    
    # 「患者番号〇〇」パターンを検出して置換
    text = re.sub(r'患者番号[0-9]{3}', '患者[MASK]', text)
    text = re.sub(r'[0-9]{3}-[0-9]{4}-[0-9]{4}', '[PHONE]', text) # 電話番号
    return text

input_text = "患者番号001は昨日から腹痛を訴えています。"
masked_text = mask_pii(input_text)
print(f"Masked: {masked_text}")
# -> Masked: 患者[MASK]は昨日から腹痛を訴えています。

医師の思考プロセスを模倣するプロンプトエンジニアリング

検索した情報を元に、医師にとって有用な回答を生成させるためのプロンプトを設計します。Chain-of-Thought（思考の連鎖）の手法を取り入れます。

from langchain.chains import RetrievalQA
from langchain_community.llms import Ollama

llm = Ollama(model="Llamaモデル", base_url="http://localhost:11434")

# プロンプトテンプレート
template = """
あなたは経験豊富な総合診療医のアシスタントです。
以下の【参考情報】のみに基づいて、医師の診断をサポートするコメントを作成してください。
推測を含めず、事実に基づいた情報のみを提示すること。

【参考情報】
{context}

【医師の入力】
{question}

【回答】
"""

from langchain.prompts import PromptTemplate
QA_CHAIN_PROMPT = PromptTemplate(
    input_variables=["context", "question"],
    template=template,
)

qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=vectorstore.as_retriever(),
    chain_type_kwargs={"prompt": QA_CHAIN_PROMPT}
)

# 実行
query = "右下腹部に痛みがある患者。考慮すべき疾患は？"
# マスキング処理を入れるならここで masked_query = mask_pii(query)
result = qa_chain.invoke({"query": query})
print(result['result'])

これで、過去の類似症例（虫垂炎のケース）を参照しながら回答するAIが完成しました。

Streamlitによる簡易UIの作成

PythonだけでWebアプリが作れるStreamlitを使えば、デモ画面もすぐに作れます。

# app.py (抜粋)
import streamlit as st

st.title("🏥 オンプレミス診断支援AI (PoC)")
st.warning("※本システムはオフライン環境で動作しています。入力データは外部に送信されません。")

user_input = st.text_area("症状や所見を入力してください")

if st.button("AIに相談"):
    with st.spinner("院内DBを検索中..."):
        # 前述のqa_chainを実行
        response = qa_chain.invoke({"query": user_input})
        st.success("回答生成完了")
        st.write(response['result'])
        
        with st.expander("参照した類似症例"):
            # 参照元の表示ロジックなどを記述
            pass

6. トラブルシューティングとパフォーマンス最適化

ローカル環境では、リソースの制約が最大の敵です。よくある課題と解決策を共有します。

推論速度が遅い場合の対処法（GPUオフロード設定）

「レスポンスが遅い」と感じる場合、モデルの一部がCPUで処理されている可能性があります。Ollamaの場合、モデルロード時にGPUへのオフロード層数を最大化することで改善します。

確認コマンド: docker logs ollama でログを確認。
対処: VRAMに余裕があれば、量子化レベルを下げる（q4_0 -> q5_k_m）よりも、モデルサイズ自体を小さいものに変えるか、より高速な量子化手法（EXL2など）を検討します。Ollamaでは自動最適化されますが、他のバックエンド（vLLMなど）を使う場合はgpu-memory-utilizationの設定やONNX/TensorRTへの変換による推論最適化が重要です。

「幻覚（ハルシネーション）」の抑制テクニック

医療AIで最も危険なのが、もっともらしい嘘（ハルシネーション）です。

System Promptの強化: 「分からない場合は『情報がありません』と答えてください」と強く指示する。
Temperatureを下げる: 生成のランダム性を制御するパラメータtemperatureを0.0〜0.2程度に設定し、事実に基づいた出力に固定する。
引用元の明示: RAGの回答に、必ず参照したドキュメントIDを付記させる。

メモリ不足エラー（OOM）の回避策

GPUメモリが溢れる（Out Of Memory）場合、コンテキスト長（一度に読み込める文字数）を制限します。デフォルトの8192トークンは大きすぎる場合があるため、4096や2048に制限することでVRAM消費を抑えられます。

7. 本番運用に向けたセキュリティチェックリスト

ベクトルDBの作成と保存（永続化） - Section Image 3

最後に、PoCから実運用環境（院内トライアル）へ進むためのセキュリティチェックリストを提示します。技術的に動くことと、安全に運用できることは別問題であり、運用フェーズを見据えた全体最適の視点が不可欠です。

ネットワークアクセスの完全遮断確認

サーバーのファイアウォール設定（iptablesやufw）で、許可された院内IPアドレス以外からのアクセスを全てブロックします。また、Dockerコンテナ自体にもネットワーク制限をかけ、外部への通信（Outbound）を遮断します。

# Docker run時にネットワークを制限する例（noneネットワークや内部ネットワークのみ接続）
docker run --network internal_only ...

アクセスログの監査設計

「誰が」「いつ」「どんなプロンプトを」入力し、「AIが何を返したか」を全てログに残すことは必須です。万が一の医療過誤やトラブルの際、AIの回答が原因かどうかの証跡となります。このログ自体も暗号化して保存する必要があります。

次のステップ：モデルのファインチューニングへの展望

今回はRAGを使いましたが、さらに精度を高めるには、院内のテキストデータを使ってモデル自体を追加学習（ファインチューニング）する選択肢もあります。LoRA（Low-Rank Adaptation）などの技術を使えば、今回のGPUサーバーでも数時間で学習が可能です。将来的には、クラウドとエッジのハイブリッド構成を視野に入れ、コストと性能のバランスをさらに最適化していくアプローチも有効です。

まとめ

医療現場での生成AI活用は、セキュリティとの戦いです。しかし、今回紹介したような「完全オフライン構成」であれば、その壁を乗り越えることができます。まずは手元のGPUマシンで、小さなPoCから始めてみませんか？

自院の環境に合わせたサイジングや具体的な導入手順については、専門家に相談することをおすすめします。適切な戦略を描くことで、エッジAI導入の技術的ハードルを下げ、ビジネス価値を最大化することが可能です。

医療データは1バイトも外に出さない。完全オフラインで構築する診断支援RAGハンズオン【Python/Ollama】 - Conclusion Image

コメントは1週間で消えます

コメントを読み込み中...