この記事のポイント（3行要約）
- 訪問診療の巡回順最適化は、オペレーションズ・リサーチの「Home Health Care Routing and Scheduling Problem（HHCRSP）」という研究領域があり、遺伝的アルゴリズム（GA）やメタヒューリスティクスを使った最適化手法が査読論文として多数報告されています。
- 個人情報保護法上、診療情報は「要配慮個人情報」に該当するため、外部クラウドAI（ChatGPT・Claude等の一般UI）にそのまま患者情報を入力するのは原則避けるべき行為です。院内オンプレミス環境か、匿名化・仮名化した「移動時間」「推定診療時間カテゴリ」等の非個人情報を扱うのが現実的な落としどころです。
- Claudeなど生成AIは「最終的な巡回順の決定」には使わず、「GA・機械学習のハイパーパラメータ候補の提案」「特徴量設計のブレインストーミング」「コードレビュー」「法令整合性チェック」といったメタレベルの用途に限定すると、患者情報を外に出さずに業務効率化に活用できます。
はじめに：なぜ「訪問順」の最適化が経営課題になるのか
在宅医療を提供する診療所では、医師1人が1日に10〜20件の訪問を行うことが珍しくありません。車での移動が多く、渋滞・駐車・悪天候などの不確実性も大きい。さらに、急変リスクのある患者は先に診たい、服薬指導の時間帯が決まっている患者もいる、といった制約が重なります。
この「巡回順をどう決めるか」という問題は、数学的には**巡回セールスマン問題（TSP）や車両配送問題（VRP: Vehicle Routing Problem）**の派生として長く研究されてきました。医療分野に特化した派生形が「Home Health Care Routing and Scheduling Problem（HHCRSP＝在宅医療ルーティング・スケジューリング問題）」です。
According to PubMed, この領域では近年、メタヒューリスティクス（meta-heuristics＝厳密解ではなく近似解を高速に求める工夫された探索手法の総称）を用いた研究が活発に行われています。例えば2024年の研究では、在宅医療の訪問スケジューリングを「移動コスト最小化」と「患者満足度最大化」の2つの目的関数で同時に最適化する手法が提案されています（Zhao et al., 2024, Int J Environ Res Public Health, DOI）。
本記事では、こうした研究成果を日本の中小〜中規模の在宅医療現場で安全に応用するために、
- 個人情報保護法と医療情報ガイドライン第6.0版の観点から、どこまでAIを使っていいのか
- 遺伝的アルゴリズム（GA）と機械学習をどう役割分担させるか
- 生成AI（Claude等）をパラメータチューニングにどう使うか
を、初心者向け（🔰）・中級者向け（🔧）・上級者向け（🎯）の3段階で整理します。
🔰 初心者向け：そもそも「訪問順最適化」とは？
たとえ話：宅配ピザの配達順
宅配ピザの配達員を想像してください。1時間の間に10軒のお客さんに届けるとき、どの順番で回れば一番早く全員に届けられるでしょうか？
- 距離だけで考えれば「近い順」が最短に見えます
- でも、「Aさんはアツアツを期待している」「Bさんは不在で再配達になる」という情報があれば、単純な近い順では最適ではありません
- さらに「道路が混む時間帯」「一方通行」といった制約も加わります
訪問診療もこれと似ています。ただし、ピザと違って患者さんの命に関わる優先度があります。
- 急変リスクの高い患者さんは午前のうちに診たい
- 点滴の予定時刻がある患者さんは時刻指定
- 家族が同席できる時間帯に来てほしいという希望もある
これを「パズルのように」コンピューターに解かせるのが、今回紹介する**遺伝的アルゴリズム（GA: Genetic Algorithm）**です。
遺伝的アルゴリズムとは？（5分で理解する）
遺伝的アルゴリズムは、「生物の進化をまねて、よい答えを少しずつ育てていく」方法です。
| ステップ | 生物の進化での意味 | 巡回順最適化での意味 |
|---|---|---|
| ①初期集団 | ランダムに生まれた個体たち | ランダムに作った訪問順のパターンを100通り作る |
| ②評価 | 生存に適した個体が強い | 総移動時間・優先度違反が少ないパターンが「強い」 |
| ③交配 | 強い個体同士を交配 | 強い訪問順2つの一部を入れ替えて新パターンを作る |
| ④突然変異 | 偶発的な変化 | 一部の訪問順をランダムに入れ替える |
| ⑤淘汰 | 弱い個体は消える | 評価の悪いパターンを捨てる |
| ⑥世代交代 | ①〜⑤をくり返す | 100世代繰り返すと、相当よい訪問順が残る |
なぜこれが有効かというと、訪問先が20件あると「すべての順番」は20!（約2400京通り）になり、コンピューターでも全部は試せないからです。進化のしくみをまねることで、全部試さなくても「かなりよい答え」を速く見つけられるのがGAの強みです。
機械学習は「何を予測する」のか
GAが「訪問順を最適化する」のに対して、機械学習は**「各患者の優先度をどう決めるか」の根拠を提供する**役割を担います。
例えば：
- 過去の訪問記録から「バイタル変化が大きかった翌週は再訪間隔を短くすべきだった」というパターンを学ぶ
- 「冬季の独居高齢者は脱水リスクが高い」といった季節要因を学ぶ
- 「退院直後の30日は再入院リスクが高い」といった時系列パターンを学ぶ
According to PubMed, 75歳以上の高齢者の30日再入院リスクを多変量の機械学習モデルで予測した研究では、AUROC（予測の正確さを示す指標。1.0が完璧で、0.85以上は高精度と評価される）で0.87〜0.93という高い性能が報告されています（Loutati et al., 2024, Am J Med, DOI）。これは入院患者対象の研究ですが、「どの患者を重点的に診るべきか」の優先度スコアを作るという発想は、在宅医療にも応用可能です。
ただし この種の研究はあくまで「研究段階」であり、臨床で使うにはさらなる検証が必要である点は、本記事全体を通じて繰り返し強調します。
🔧 中級者向け：法律上「どこまで」使っていいのか
ここが本記事で一番重要な部分です。技術的にできることと法律上やっていいことはイコールではありません。
基本の確認：診療情報は「要配慮個人情報」
個人情報保護法第2条第3項により、病歴・診療記録・処方情報は「要配慮個人情報」に分類され、一般の個人情報よりも厳しいルールが適用されます。
- 取得・第三者提供には本人の明示的な同意が必要（法第20条第2項、第27条第2項）
- オプトアウト方式での第三者提供は認められていません
- 外国にある第三者への提供は、さらに法第28条で制限されます（米国サーバーへの送信は要注意）
加えて、医師法第17条・保健師助産師看護師法等で医療従事者には守秘義務が課せられ、刑法第134条の秘密漏示罪（6ヶ月以下の懲役または10万円以下の罰金）の対象にもなります。
「訪問順最適化」で医師が使えるデータの範囲
ここから具体的な線引きに入ります。筆者の理解では、以下のような分類が現実的です。
| データ区分 | 例 | 外部クラウドAIに入力 | 院内AIで処理 | 匿名化して研究 |
|---|---|---|---|---|
| 直接識別情報 | 氏名、住所、電話番号 | ❌ 原則不可 | ⚠️ 最小限 | ❌ 削除必須 |
| 医療情報（個別） | 病名、処方、検査値 | ❌ 原則不可 | ⚠️ 必要最小限 | ⚠️ 仮名化必須 |
| 医療情報（統計） | 訪問頻度の分布、平均滞在時間 | △ 識別不能なら可 | ⭕ 可 | ⭕ 可 |
| 業務情報 | 移動時間、駐車場所、ルート | ⭕ 可 | ⭕ 可 | ⭕ 可 |
| 医師自身の情報 | スケジュール、勤務時間 | ⭕ 可 | ⭕ 可 | ⭕ 可 |
重要なのは、「訪問順最適化」に必要な情報の大半は、実は業務情報（移動時間・訪問時間枠・医師のシフト）で済むということです。病名や具体的な症状を入れなくても、「A宅→B宅→C宅の移動時間と推定診療時間」だけで、かなり実用的な最適化ができます。
法律上「大丈夫なこと」と「注意が必要なこと」
✅ 大丈夫な可能性が高いこと：
- 患者の住所を座標（緯度経度）に変換し、さらに相対座標にしたうえで移動時間を計算する
- 訪問時間枠（例：9:00-10:00希望）を、個人と切り離した形で最適化対象にする
- 過去3ヶ月の「訪問回数の分布」など統計量から、需要予測を作る
- 医師自身のスケジュール・休憩時間を入力に入れる
⚠️ 注意が必要なこと：
- 「Aさんは糖尿病で足が悪いから最後のほうに回したい」のような具体的な病歴情報を外部AIに入れる
- 住所そのものを外部ジオコーディングAPIに投げる（どのAPIを使うか、データの取り扱いを必ず確認する）
- 家族構成・同居人情報を最適化に使う（家族情報も個人情報）
❌ やってはいけないこと：
- 患者の氏名・病名・カルテ内容をそのまま ChatGPT・Gemini・Claude等の一般UIに貼り付けて「最適な順番を教えて」と聞く
- 米国サーバーで動くクラウドAIに、要配慮個人情報を同意なしに送信する
- 匿名化したと思い込んで、日時・属性・症状の組み合わせで個人が特定できる形にしてしまう
厚生労働省「医療情報システムの安全管理に関するガイドライン第6.0版」でも、クラウドサービスを選ぶ際の責任分界点（どこまでが医療機関の責任で、どこからが事業者の責任か）を契約書で明確化するよう求めています（厚労省ガイドライン第6.0版）。
推奨アーキテクチャ：「院内オンプレAI＋クラウドAIのメタ利用」の二層構成
筆者が考える、現場で現実的に動く構成は以下の通りです。
┌───────────────────────────────────────────┐
│ 【院内オンプレ層】 │
│ ・患者の住所・病名・優先度データ │
│ ・院内サーバー or 医師PC上で処理 │
│ ・Python + DEAP/PyGAD で GA を実行 │
│ ・LightGBM等で優先度スコアを学習 │
│ → ここに患者情報が留まる │
└─────────────┬─────────────────────────────┘
│ ↑ 出力される情報を
│ 「個人情報を含まない形」で取り出す
│ （例：ハイパーパラメータ、性能評価、コードの構造）
↓
┌───────────────────────────────────────────┐
│ 【クラウドAI層（Claude等）】 │
│ ・GA/MLのハイパーパラメータ提案 │
│ ・特徴量エンジニアリングの相談 │
│ ・コードレビュー・ドキュメント生成 │
│ ・法令整合性のチェック │
│ → 患者情報は一切入れない │
└───────────────────────────────────────────┘
この二層構成のポイントは、患者情報の入る「一次処理系」と、コード・モデル設計の「メタ処理系」を物理的に分けることです。
院内オンプレAIの選択肢
「院内サーバーでAIを動かす」と聞くと大がかりに感じますが、小規模診療所でも可能な構成があります。
- Ollama + Qwen2.5 / Llama3 系モデル：無料・オープンソースで、RTX 3060程度のGPUで動作する軽量モデルもあります
- MacBook Pro（Apple Silicon）：統合メモリ64GB搭載機なら、中規模モデルもローカルで推論可能です
- NAS + コンテナ環境：Synology等のNASでDockerを動かし、小規模モデルを常駐させることもできます
ただし、ローカルLLMを医療業務に組み込む場合も、医療情報システム安全管理責任者の承認・運用規程の整備・アクセスログの保管が必要です。技術的に動くからといって、組織的なガバナンス抜きで運用するのは避けるべきです。
🎯 上級者向け：GA × ML × Claude のパラメータチューニング設計
ここからは実装レベルの具体論に入ります。
Step 1: 問題の数理モデル化（HHCRSPの定式化）
在宅医療ルーティング・スケジューリング問題（HHCRSP）を定式化します。変数・制約は以下の通り。
決定変数：
- $x_{ij}$: 医師がiからjに移動するかどうか（0 or 1）
- $t_i$: 患者iを訪問する開始時刻
目的関数（複数目的）：
- 総移動時間の最小化
- 時間窓違反の最小化
- 優先度スコア加重の最大化
制約：
- 各患者はちょうど1回訪問される
- 医師の稼働時間内に収まる
- 時間窓（例：9:00-11:00に訪問希望）の遵守
- 昼休憩の確保
この問題はNP困難（＝計算量が爆発的に増える種類の問題）なので、20件を超えると厳密解を求めるのは現実的でなくなります。そこでGAのようなメタヒューリスティクスの出番になります。
Step 2: GAの設計（PyGAD実装例）
以下は実際のコード例ですが、患者情報は含まない業務データのみで動くように設計しています。
# -*- coding: utf-8 -*-
"""
訪問順最適化GA（患者情報を含まないサンプル）
注意：このコードは教育目的のサンプルです。
実運用では医療情報システム安全管理責任者の承認、
運用規程の整備、アクセスログの保管等が必要です。
"""
import numpy as np
import pygad
# ============================================
# 入力データ（すべて匿名化・非個人情報）
# ============================================
# 患者インデックスは P01, P02, ... のような連番のみ
# 実名や住所は別途オンプレDBで管理し、
# この最適化エンジンには座標・時間窓のみを渡す
# 10件の訪問先（起点=診療所を0番目とする）
n_patients = 10
rng = np.random.default_rng(42)
# 相対座標（実座標を診療所からの差分に変換済み）
coords = rng.uniform(-10, 10, size=(n_patients + 1, 2))
coords[0] = [0, 0] # 診療所を原点に
# 移動時間行列（単位：分）
def travel_time_matrix(coords, speed_km_per_min=0.5):
n = len(coords)
mat = np.zeros((n, n))
for i in range(n):
for j in range(n):
dist = np.linalg.norm(coords[i] - coords[j])
mat[i, j] = dist / speed_km_per_min
return mat
T = travel_time_matrix(coords)
# 各患者の推定診療時間（分）と時間窓
service_time = rng.integers(15, 45, size=n_patients)
time_window_start = rng.integers(0, 240, size=n_patients) # 9:00起点からの分
time_window_end = time_window_start + rng.integers(60, 180, size=n_patients)
# 優先度スコア（機械学習モデルの出力を想定、0〜1）
# ※注意：実際は院内サーバーで学習したMLモデルから取得
priority = rng.uniform(0, 1, size=n_patients)
# ============================================
# 目的関数（GAは最大化するので符号反転）
# ============================================
def fitness_func(ga_instance, solution, solution_idx):
# solutionは[0, n_patients)のインデックスの順列
route = [0] + [int(x) + 1 for x in solution] + [0]
total_travel = 0
time_window_penalty = 0
priority_gain = 0
current_time = 0
for i in range(len(route) - 1):
from_node = route[i]
to_node = route[i + 1]
current_time += T[from_node, to_node]
total_travel += T[from_node, to_node]
if to_node != 0: # 最終地点（診療所帰着）以外
patient_idx = to_node - 1
tw_start = time_window_start[patient_idx]
tw_end = time_window_end[patient_idx]
# 時間窓違反のペナルティ
if current_time < tw_start:
current_time = tw_start # 早着は待機
elif current_time > tw_end:
time_window_penalty += (current_time - tw_end)
# 優先度加重（早く訪問した患者ほど高スコア）
position_weight = 1.0 - (i / len(route))
priority_gain += priority[patient_idx] * position_weight
current_time += service_time[patient_idx]
# 複合目的関数（重みは業務要件に応じて調整）
fitness = -(
1.0 * total_travel +
5.0 * time_window_penalty -
10.0 * priority_gain
)
return fitness
# ============================================
# GAの実行
# ============================================
ga_instance = pygad.GA(
num_generations=200,
num_parents_mating=10,
sol_per_pop=50,
num_genes=n_patients,
gene_space=list(range(n_patients)),
fitness_func=fitness_func,
gene_type=int,
allow_duplicate_genes=False,
parent_selection_type="tournament",
crossover_type="scattered",
mutation_type="swap",
mutation_probability=0.1,
random_seed=42,
)
ga_instance.run()
best_solution, best_fitness, _ = ga_instance.best_solution()
print(f"最適訪問順: {best_solution}")
print(f"Fitness値: {best_fitness:.2f}")
このコードは pygad を使ったGA実装のスケルトンです。実運用に入れる前に、以下を必ず実施してください：
- 医療情報システム安全管理責任者によるレビュー
- 入力データに本当に個人情報が含まれないかの検証（連番IDから逆引きできないか）
- 出力結果の最終判断は必ず医師が行う運用設計
- ログ保管・変更管理の手順整備
Step 3: 機械学習による優先度スコアの算出
上記コードの priority 変数は、本来は過去の訪問記録から学習したMLモデルの出力です。この学習は院内サーバーで完結させるのが基本です。
特徴量の候補：
| 特徴量カテゴリ | 具体例 | 個人情報該当性 |
|---|---|---|
| 時系列統計 | 前回訪問からの経過日数 | △ 低 |
| バイタル傾向 | 過去3回の血圧傾きの符号 | ⚠️ 要配慮個人情報 |
| 処方変更 | 直近30日の処方薬剤数変化 | ⚠️ 要配慮個人情報 |
| 季節要因 | 訪問月、曜日 | ⭕ 非該当 |
| 環境要因 | 天気予報（訪問日） | ⭕ 非該当 |
要配慮個人情報を含む特徴量をMLモデルの入力にする場合、そのモデル自体を院内サーバーから外に出さないことが重要です。モデルのバイナリファイルには訓練データの痕跡が残る可能性があります。
モデル選択の指針：
- LightGBM / XGBoost：構造化データに強く、軽量・学習も速い
- Logistic Regression：解釈性が高く、医師に説明しやすい
- Random Forest：特徴量重要度を可視化しやすい
- Deep Learning：在宅医療のデータ規模（数百〜数千件）では過学習のリスクあり、慎重に
According to PubMed, 類似研究では、LACEスコア（従来の再入院予測スコア）のAUC 0.66に対し、勾配ブースティングを用いた機械学習モデルではAUC 0.83まで性能が向上したとの報告があります（Davis et al., 2022, BMC Health Serv Res, DOI）。ただしこれは入院患者の再入院予測であり、在宅医療での訪問優先度とは直接結びつきません。自院データでの検証が必須です。
Step 4: Claude（生成AI）をパラメータチューニングに使う
ここが本記事の新しい提案部分です。Claudeなどの生成AIを、患者情報を一切入れずに、以下のメタレベルの用途で使います。
用途①：GAのハイパーパラメータ提案
【Claudeへの安全なプロンプト例】
以下の条件の訪問順最適化問題を、PyGADで解こうとしています。
ハイパーパラメータの初期値として妥当な値を提案してください。
・訪問先数: 15
・目的関数: 総移動時間 + 時間窓違反ペナルティ - 優先度加重
・制約: 時間窓、昼休憩、総稼働時間8時間
・実行環境: ローカルPC、実行時間制約10分以内
特に以下の観点でコメントをください：
- num_generations（世代数）
- sol_per_pop（集団サイズ）
- crossover_type、mutation_type の選択理由
- mutation_probability の妥当な範囲
このプロンプトには患者情報が一切含まれないことが重要です。問題の「形」だけを伝えています。
用途②：特徴量設計のブレインストーミング
【Claudeへの安全なプロンプト例】
在宅医療における訪問優先度を機械学習で予測したいです。
査読論文で報告されている特徴量のうち、
日本の医療保険制度・在宅医療現場でも取得可能で、
かつ個人情報保護法上問題が少ないものを整理してください。
用途③：コードレビュー
【Claudeへの安全なプロンプト例】
以下のGA実装コードをレビューしてください。
特に以下の観点を中心にお願いします：
1. 医療業務にそのまま使う場合の注意点
2. ログ保管・エラー処理の不足点
3. パフォーマンスのボトルネック
[コードを貼り付け ※患者情報を含まないダミーデータで動くもの]
用途④：法令整合性チェック
【Claudeへの安全なプロンプト例】
厚生労働省「医療情報システムの安全管理に関するガイドライン第6.0版」に
照らして、以下のシステム構成図に不足している要件があれば指摘してください。
[構成図をテキストで記述]
Claude利用時の3つの禁則事項
- 患者の氏名・住所・病名・処方内容を絶対に入力しない
- 実データではなく、必ずダミーデータ・モック値でコードを動かしてから共有する
- Claudeの出力をそのままコピペして本番運用しない（必ず院内でテスト＆医療情報システム安全管理責任者の承認）
PubMed から見る関連研究（参考文献）
According to PubMed, この分野では以下のような研究が報告されています。日本の在宅医療への直接適用には追加検証が必要ですが、設計思想の参考になります。
在宅医療ルーティング・スケジューリング（HHCRSP）関連
-
Zhao J, Wang T, Monteiro T. (2024). A Bi-Objective Home Health Care Routing and Scheduling Problem under Uncertainty. Int J Environ Res Public Health, 21(3), 377. DOI
- 不確実性下での在宅医療ルーティング・スケジューリング問題に対する2目的最適化モデル。Adaptive Large Neighborhood Search（ALNS）を使用。
-
Khodabandeh P, Kayvanfar V, Rafiee M, Werner F. (2021). A Bi-Objective Home Health Care Routing and Scheduling Model with Considering Nurse Downgrading Costs. Int J Environ Res Public Health, 18(3), 900. DOI
- 看護師のスキル過剰配置（ダウングレード）コストを考慮したモデル。ε制約法を使用。
-
Shiri M, Ahmadizar F, Thiruvady D, Farvaresh H. (2022). A sustainable and efficient home health care network design model under uncertainty. Expert Syst Appl, 211, 118185. DOI
- 不確実性下での在宅医療ネットワーク設計。社会的責任と効率性の両立。
-
Zhao A, Bard JF. (2024). Weekly home healthcare routing and scheduling with overlapping patient clusters. Health Syst (Basingstoke), 14(2), 145-165. DOI
- 週間単位の在宅医療スケジューリング。患者クラスタリングとMILP（混合整数線形計画）による2段階アプローチ。
-
Fathollahi-Fard AM, Ahmadi A, Goodarzian F, Cheikhrouhou N. (2020). A bi-objective home healthcare routing and scheduling problem considering patients' satisfaction in a fuzzy environment. Appl Soft Comput, 93, 106385. DOI
- ファジィ環境下での患者満足度を目的関数に含めたモデル。SEOメタヒューリスティクスの改良版を提案。
-
Euchi J, Zidi S, Laouamer L. (2020). A Hybrid Approach to Solve the Vehicle Routing Problem with Time Windows and Synchronized Visits In-Home Health Care. Arab J Sci Eng, 45(12), 10637-10652. DOI
- 時間窓と同期訪問制約を持つ在宅医療VRP。AIベースのハイブリッド手法。
-
Suwatcharachaitiwong S, Lin CC, Huang W, Hung LP. (2020). On the medication distribution system for home health care through convenience stores, lockers, and home delivery. Health Informatics J, 26(4), 3163-3183. DOI
- 在宅医療における医薬品配送問題を、遺伝的アルゴリズムで解く研究。
機械学習による医療リスク予測関連
-
Loutati R, Ben-Yehuda A, Rosenberg S, Rottenberg Y. (2024). Multimodal Machine Learning for Prediction of 30-Day Readmission Risk in Elderly Population. Am J Med, 137(7), 617-628. DOI
- 高齢者の30日再入院リスクを多変量機械学習で予測。AUROC 0.87〜0.93を達成。
-
Davis S, Zhang J, Lee I, Rezaei M, Greiner R, McAlister FA, Padwal R. (2022). Effective hospital readmission prediction models using machine-learned features. BMC Health Serv Res, 22(1), 1415. DOI
- 機械学習による自動特徴量生成を用いた再入院予測モデル。LACEスコア（AUC 0.66）を大きく上回るAUC 0.83を達成。
-
Lin WC, Chen JS, Chiang MF, Hribar MR. (2021). Machine learning for early prediction of in-hospital cardiac arrest in patients with acute coronary syndromes. Clin Cardiol, 44(3), 349-356. DOI
- 急性冠症候群患者の院内心停止を機械学習で早期予測する研究。
※ これらの論文は、日本の在宅医療現場にそのまま適用できる形で書かれていません。「こういうアプローチがある」という研究動向の把握に使うのが正しい読み方です。自施設で運用する場合は、自院データでの性能検証（内部バリデーション・外部バリデーション）が必須です。
実際に現場で始めるなら：段階的ロードマップ
Phase 1（0〜3ヶ月）：紙運用のデジタル化
- 訪問先の住所・時間窓をスプレッドシートで構造化
- 現在の訪問順を記録し、総移動時間の「ベースライン」を測定
- この段階ではAIは不要。何を改善すべきかを数値で把握することが目的
Phase 2（3〜6ヶ月）：ルーティング単機能の導入
- Google Maps APIのルート最適化機能、または OR-Tools（Googleのオープンソース）で、移動時間のみを目的関数にした最適化を試す
- 住所は緯度経度に変換し、必要に応じて診療所からの相対座標に変換
- まだ医学的優先度は入れない。「最短ルート」と「現行ルート」の差分を医師がレビューする運用
Phase 3（6〜12ヶ月）：優先度スコアの加味
- 過去の訪問記録から、医師の判断を「教師データ」として抽出（同意取得・倫理審査委員会の確認が必要）
- 院内サーバーで優先度スコアモデルを学習
- GAで「移動時間＋優先度」の多目的最適化に拡張
Phase 4（12ヶ月〜）：継続的改善
- 実運用データから学んだモデルを、月次で再学習
- 定期的に医療情報システム安全管理責任者と監査
- 年1回、個人情報保護委員会や外部監査人の評価を受ける
急がないこと。Phase 1〜2だけでも、実感できる業務改善になります。Phase 3以降は医療AIとしての体制整備が必須で、一気に飛ぶと法令違反のリスクが跳ね上がります。
まとめ
在宅医療の訪問順最適化は、学術的には成熟した研究領域であり、遺伝的アルゴリズム・機械学習の応用可能性は十分にあります。一方で、日本の医療現場で実装する際の最大のハードルは技術ではなく法律とガバナンスです。
押さえるべき原則は3つ。
- 患者情報は院内に留める。外部クラウドAIには絶対に入れない
- 最適化に必要なデータの大半は業務情報である。病名を入れなくても実用的な最適化はできる
- Claudeなど生成AIは「メタ用途」に限定する。ハイパーパラメータ提案、コードレビュー、法令整合性チェックなど、患者情報を含まない用途にだけ使う
最後に、筆者の見解として書いておきたいこと。医療AIは「すごい未来が来る」という期待よりも、「こういう根拠があり、こういう可能性がある。だから段階的に動く価値がある」という地に足のついた議論が大切です。一人の医師、一つの診療所、一人の患者さんに、本当に役立つものを積み上げていきたいと思います。
参考資料・連絡先
- 公式サイト：taichiendoh.com
- アイデア掲示板：taichiendoh.com/ideas
- X：@endoh_taichi
著者プロフィール
遠藤太一（えんどう・たいち）
AIエンジニア / 臨床工学技士
11年間の臨床工学技士としての臨床経験を経て、AIエンジニアに転向。現在は医療AI・医療DX領域で記事執筆・コンサルティング・研究活動を行っている。
出典一覧
法令・ガイドライン
- 個人情報保護法（e-Gov法令検索）: https://elaws.e-gov.go.jp/document?lawid=415AC0000000057
- 医療法（e-Gov法令検索）: https://elaws.e-gov.go.jp/document?lawid=323AC0000000205
- 医療情報システムの安全管理に関するガイドライン第6.0版（厚生労働省）: https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html
- クラウドサービス事業者が医療情報を取り扱う際の安全管理に関するガイドライン（総務省）: https://www.soumu.go.jp/main_content/000552029.pdf
査読論文（PubMed）
上記「PubMed から見る関連研究」セクションに10本を記載。
関連記事
- 遠藤太一（2026）「医療情報を守るためのガイドラインを正しく理解する── 厚労省・総務省の公式指針から学ぶ、医療システムセキュリティの全体像」note.com: https://note.com/taichi_endoh/n/nac9497d78464
- 遠藤太一（2026）「【医療IT担当者向け】医療情報システム安全管理責任者って何をする人？ 役割・法律・ChatGPTのNG理由・兼任負担・AI効率化・補助金まで一気に解説」Qiita: https://qiita.com/TaichiEndoh/items/1575063e292b349e5e0a
免責事項
本記事は執筆時点での公開情報と筆者の見解に基づくものです。個別の医療機関・患者さんのケースに適用する際は、必ず医療情報システム安全管理責任者・個人情報保護担当者・顧問弁護士・顧問税理士等の専門家にご相談ください。法令は改正されることがあるため、最新の一次情報を必ずご確認ください。特定の実施主体（病院・クリニック・法人等）を想定した記述ではなく、一般的に考えられる設計と注意点の整理を目的としています。