Vibe Coding Level 301 連携編
第7回 セキュリティ 医療情報をどう守るか
このレッスンで終わる頃には
- 「AIに渡してはいけない医療情報」の基準が具体的に言える
- APIキーの安全な管理方法が実装できる
- 連携設計の際にセキュリティを後付けではなく最初から組み込める
なぜ今、これを扱うのか
Lesson 03〜06で、MCPを使って多くのツールを繋いできました。
PubMed・Notion・Slack・Googleカレンダー。
繋ぐたびに便利になります。 と同時に、Claudeが「外部に接触できる先」が増えています。
連携の数だけ、情報の出口が増えます。 これは医療情報を扱う立場では、軽く考えてはいけない変化です。
このレッスンは「できること」ではなく「やってはいけないこと」を中心に扱います。
まず：医療情報とは何か
「医療情報」は広い言葉です。 具体的に何が問題なのかを最初に整理します。
PHI（Protected Health Information）
米国のHIPAA法で定義される「保護すべき健康情報」です。 日本の個人情報保護法でも、健康情報は要配慮個人情報として特に保護されます。
PHIに含まれる18項目（例）：
- 氏名
- 生年月日
- 住所（都道府県より細かい情報）
- 電話番号・メールアドレス
- 患者ID・医療記録番号
- 顔写真・指紋などの生体情報
- 診断名・検査結果（個人と結びついた場合）
- 処方内容（個人と結びついた場合）
これらは、単独でも、組み合わせでも個人を特定できます。
絶対NGの行動
以下の行動は、ツールや設定に関わらず行いません。
1. 患者情報をAIサービスに入力する
ChatGPT・Claude・Geminiなどのチャット型AIに、患者の個人識別情報を入れない。
「〇〇さん、42歳女性、高血圧と糖尿病があって...」 この文章をAIに入力することは、患者の同意なく第三者（AIサービス企業）に情報を送ることになります。
2. 電子カルテの文章をコピー&ペーストする
電子カルテの記録は、患者の固有情報が含まれています。 そのままAIに貼り付けることは、情報漏洩にあたります。
診断名や症状だけを取り出し、「Aさん」を「50代の女性」に置き換えてから使います。
3. MCPを通じて患者情報が含まれるファイルを送信する
Dispatchや他のMCPでも同じです。 患者情報が含まれるファイルのパスを指定したり、その内容を含む指示を送ったりしない。
4. APIキーを平文でGitHubやドキュメントに書く
APIキーは認証情報です。 GitHubのリポジトリ（パブリックでもプライベートでも）、Notion・Slackに直接貼り付けない。
やっていいこと
以下は問題ありません。
疾患名・症状の一般論 「小児の発熱のマネジメント」「成人の気管支喘息」 → 特定患者と結びついていなければOK
薬剤名・用量の一般情報 「アセトアミノフェンの小児への投与量」「ペニシリンの添付文書の要点」 → 公開情報の整理はOK
公開文献の要約 PubMedの論文、ガイドライン、添付文書 → 元々公開されているものをAIに処理させることはOK
自分の業務タスクの内容 「学会発表の準備」「カンファの議事録の形式を整える」 → 個人情報が含まれなければOK
匿名化の方法
どうしても実際の症例を使いたい場合は、事前に匿名化します。
最低限の匿名化
| 元の情報 | 匿名化後 |
|---|---|
| 田中花子、42歳 | 40代女性 |
| 患者ID：12345 | 削除 |
| 2026年5月15日 入院 | 5月 入院（年月だけ） |
| 三田病院 | 当院（名称削除） |
匿名化の確認
匿名化できたか確認する方法は1つです。
「この文章だけ見て、誰のことか特定できるか？」
特定できるなら、まだ匿名化が不十分です。
APIキーの安全な管理
APIキーは、サービスへのパスワードです。 流出すると、料金が不正請求されたり、データが盗まれたりします。
正しい保存場所：.envファイル
プロジェクトフォルダの直下に.envファイルを作り、ここに書きます。
NCBI_API_KEY=your_ncbi_key_here
NOTION_API_KEY=secret_xxxxxx
SLACK_BOT_TOKEN=xoxb-xxxxxx
このファイルは.gitignoreに必ず追加します。
# .gitignore
.env
.env.local
.gitignoreに入れると、GitHubに上げても.envの内容は送られません。
プログラムからの読み込み
Pythonで読み込む場合：
import os
from dotenv import load_dotenv
load_dotenv()
api_key = os.getenv("NCBI_API_KEY")
python-dotenvライブラリを使います。
pip install python-dotenv
間違えてGitHubにAPIキーを上げた場合
すぐに以下の2ステップを踏みます。
- 該当サービスのダッシュボードで、そのAPIキーを失効させる（Revoke）
- 新しいAPIキーを発行し直す
キーを削除したコミットをGitHubに上げても、過去のコミット履歴には残ります。 必ずキー側を失効させることが最初のステップです。
MCPの接続時のセキュリティ確認
新しいMCPを繋ぐとき、以下を確認します。
1. MCPの出所を確認する
コミュニティ製のMCPを使う場合、GitHubのリポジトリを見て確認します。
- コードが読める状態で公開されているか
- 不審な外部通信をしていないか（コード内にAPIキー送信があるなど）
- スター数・コントリビュータ数で一定の信頼性があるか
公式が出しているMCP（Notion・Slack公式など）は基本的に安全です。
2. 権限は最小限にする
NotionのAPIトークンは、必要なページだけに共有を絞ります。 Slackのbotは、必要なチャンネルだけにアクセス権を付与します。
「全部のページに繋いでおいた方が楽」という判断はリスクを広げます。 最初から必要な範囲だけに絞る設計が正しいです。
3. 定期的にキーを棚卸しする
使っていないAPIキーは削除します。 3ヶ月に1回、.envファイルを見直して不要なキーを失効させます。
院内システムとの連携について
電子カルテや病院のHISシステムとAIを繋ぐことを検討する場合は、以下のステップが必要です。
- 病院の情報管理部門・セキュリティ担当への相談
- 個人情報保護方針との整合確認
- 患者同意の取得（研究利用の場合）
- 外部委託契約の確認（AIサービス企業への情報提供に相当する場合）
これは個人の判断で進められる領域ではありません。 現時点でのAI連携は、公開情報・一般情報の範囲で行うことを強く推奨します。
セキュリティ判断の即決フロー
迷ったとき、この順で考えます。
AIに送ろうとしている情報は何か？
↓
特定の患者と結びつく情報が含まれるか？
YES → 匿名化してから使う、または使わない
NO ↓
APIキーや認証情報が含まれるか？
YES → .envに分離してから
NO ↓
公開されていない院内情報が含まれるか？
YES → 担当部門に確認
NO → 使ってOK
このフローを通れば、大多数のリスクは防げます。
まとめ
- 患者の個人識別情報（PHI）は絶対にAIに入力しない
- 電子カルテをそのままコピペしない
- APIキーは.envファイルで管理し、GitHubには上げない
- 院内システムとの連携は情報管理部門に相談してから
- 新しいMCPを繋ぐときは出所と権限を最小限に確認する
次は Lesson 08。ここまで使う側だったMCPを、自分で作る側に回ります。
演習：自分の現在の設定を棚卸しする
このチェックリストを確認してください。
□ .envファイルがプロジェクトフォルダにある
□ .gitignoreに.envが追加されている
□ GitHubのリポジトリに.envがアップロードされていない
□ 使っていないAPIキーを把握している
□ 各MCPの権限が必要最小限に設定されている
全部チェックできれば、基本的なセキュリティ設定は整っています。 1つでも「わからない」があれば、そこから確認を始めてください。