【2026年版】医療現場の自作アプリ開発：薬機法と安全管理の境界線

医療DXの進展とAIエージェントの普及により、医師や看護師が自ら業務効率化アプリを開発するケースが増えています。しかし、医療現場でのソフトウェア利用には「薬機法（医薬品医療機器等法）」や「個人情報保護」といった高い壁が存在します。

本記事では、自身でアプリを作る際に「どこまでが許されるのか」「どこからが規制対象（薬事承認が必要）なのか」を、2026年最新のガイドラインに基づき解説します。

---

1. 薬機法の壁：そのアプリは「医療機器」か？

ソフトウェア単体でも、特定の目的を持つ場合は「プログラム医療機器（SaMD: Software as a Medical Device）」として規制対象になります。

医療機器に該当する（承認が必要な）基準

• 診断・治療・予防を目的としている。
• プログラムが機能しなかった場合に、患者の生命や健康に影響を与える恐れがある。
• 例：AIが画像から自動診断を下す、特定の数値に基づき正確な投薬量を決定・指示する。

医療機器に該当しない（自作して良い）範囲

厚生労働省の「プログラムの医療機器該当性に関するガイドライン」では、以下のものは原則として医療機器に該当しないとされています。

1. 事務・管理の効率化: 予約管理、会計、物品管理、統計作成など。
2. 情報の整理・提示: カルテ情報の要約、データのフォーマット変換、検索性の向上など。
3. 教育・説明用: 患者への病状説明を補助する動画やスライド（これ自体で診断しないもの）。

【結論】 雑務作業を効率化するためのアプリケーションは 「情報の整理・提示」 にあたるため、自前でアプリを作って使用することに法律上の問題はありません。ただし、最終的な医療判断はあくまで「医師」が行うというプロセス（Human-in-the-Loop）が必須です。

---

2. 忘れがちな「3省2ガイドライン」：安全管理の義務

ソフトウェアが医療機器に該当しなくても、患者の個人情報（医療情報）を取り扱う以上、避けて通れないのがセキュリティ基準です。

現在は「3省2ガイドライン」（厚生労働省「医療情報システムの安全管理に関するガイドライン v6.0」および経産省・総務省の事業者向けガイドライン v2.0）への準拠が求められます。

• アクセス制御: 誰がいつデータにアクセスしたか記録を残す（監査ログ）。
• 暗号化: データの保存時および通信時の暗号化。
• ゼロトラスト思考: 院内ネットワークだから安全だと過信せず、端末ごとの認証を徹底する。

個人で作成したツールであっても、院内LANに接続したりクラウドAI（Gemini/Claude等）を利用したりする場合は、このガイドラインに沿った運用が必要です。

---

3. クラウドサービスの選定と日本法への対応

「医療データをクラウドに預けても大丈夫か？」という問いに答えるには、まず日本の法律が何を求めているかを正確に理解する必要があります。

3-1. 法的な前提：日本で求められること

注意: クラウドサービスとの「BAA（Business Associate Agreement）」という契約形態をよく目にしますが、これはアメリカのHIPAA法に基づく概念であり、日本法の要件ではありません。日本では以下の2つの法的根拠に基づいた対応が必要です。

① 個人情報保護法 第24条（委託先の監督義務） 医療機関がクラウド事業者に個人データの処理を委託する場合、委託先が「必要かつ適切な安全管理措置を講じているか監督する義務」が課されます。これを文書化するために、クラウド事業者との「データ処理に関する補足条項（DPA）」への同意が必要です（管理画面から電子署名で完了できます）。

② 3省2ガイドライン（厚労省v6.0・経産省/総務省v2.0） 医療機関側の運用体制として、アクセスログの保管・暗号化・権限管理・責任分界点の文書化が求められます。

---

3-2. クラウドDBを使う場合の対応手順

ステップ1：サービスの「適格性確認」

主要サービスの対応状況

※1 2026年以降、Microsoft 365の価格は改定が予定されています。契約前に公式サイトで最新価格をご確認ください。

※2 GASはGoogle Workspaceの一機能ですが、スクリプトの実行基盤がどのリージョンで動作するか明確でないため、医療データの直接処理には慎重な判断が必要です。Google Cloudの別サービス（Cloud Functions等）の利用を検討してください。

※3 SupabaseのISMAP未登録・英語のみの契約対応という点が、日本の医療機関での採用ハードルになります。小規模開発には魅力的ですが、機微な医療データの本番運用前に法務・管理者への確認を推奨します。

ステップ2：院内の運用体制整備

クラウド事業者との契約以上に重要なのが、利用する側の院内体制です。

---

3-3. クラウドAI（Claude / Gemini等）を使う場合の追加要件

クラウドAIはDBと同じ要件に加え、さらに2つの固有の問題があります。

追加問題①：コンシューマー版（無料サービス）は使用禁止

同じ「Claude」「Gemini」でも、使い方によって医療データの扱いが全く異なります。

追加問題②：海外へのデータ移転規制（個人情報保護法 第28条）

Claude API（Anthropic・米国）やGemini API（Google・米国）にデータを送ると、個人情報が国外に出ます。このとき「相手国が十分な保護水準にある」か「契約等で同等の保護を確保する」必要があります。

最も確実な対策は「仮名化」です：

``` 【AIに送る前の仮名化の例】

Before: 「田中太郎（患者ID: 12345）の血圧が...」 After: 「患者Aの血圧が...」

→ 元データとの対応表を院内で厳重管理すれば、 個人情報の海外移転規制の適用対象外になりうる ```

クラウドAIサービスの対応状況

---

4. 2026年最新：生成AI利用のリスク管理

2026年現在、生成AIを医療現場で使う際の最大の注意点は　「ハルシネーション（もっともらしい嘘）」 と 「責任境界」 です。

• 医師の確認義務: AIが要約したカルテ内容は、必ず医師が元データと突き合わせて確認する必要があります。AIの出力をそのまま公的な記録として採用することは、医療過誤につながるリスクがあり、法的責任は開発者ではなく最終利用者の医師に帰属します。
• 学習データの除外: クラウド経由でAIを利用する場合、入力した医療データがAIの学習に再利用されない設定（API利用やオプトアウト設定）が必須です。

---

まとめ：自作アプリで安全に効率化するために

自施設専用のアプリを作る際は、以下のステップを意識しましょう。

1. 「医学的判断」を含まないように設計する: あくまで「データの整理」「見やすさの向上」に徹する。
2. 医師の目を通す: AIの要約や整理結果を鵜呑みにせず、必ず確認できるUIにする。
3. セキュリティを担保する: ID/パスワードによる管理や通信の暗号化を実装する。

医療現場の課題を一番知っているのは、現場のスタッフです。法的境界線を正しく理解し、AIエージェントを味方につけることで、安全かつ劇的な業務改善が可能になります。

---

リファレンス

• 厚生労働省：プログラムの医療機器該当性に関するガイドライン（令和5年3月一部改正）
• 厚生労働省：医療情報システムの安全管理に関するガイドライン 第6.0版
• 経済産業省・総務省：医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 第2.0版
• デジタル庁：AI事業者ガイドライン（第1.1版〜第1.2版）