メインコンテンツへスキップ
AMPL
公開前チェックリストと、事故が起きた日
レッスン 11 / 15|13分で読めます

公開前チェックリストと、事故が起きた日

10回分を毎回回せるチェックリストに固める。AI自己監査の限界、事故発生時の初動、利用者への開示の考え方。個人編の卒業ゲート。

個人編の締めくくりです。

ここまでの10回で、個別の鍵はすべて手に入りました。

最後の仕事は、それを毎回忘れずに回す仕組みに変えることです。

医療者には説明不要だと思います。手術前のタイムアウト、投薬前の指差し確認。優秀さではなく手順が事故を防ぐことを、私たちは毎日の仕事で知っています。セキュリティも同じです。

ㅤ

公開前チェックリスト（保存版）

新しいアプリを公開する前、そして大きな機能を足したときに、上から順に回します。

明日のアクション

公開前チェックリスト

データベース（第3回）

  1. 全テーブルでRLS有効・「RLS disabled」警告ゼロ
  2. シークレットウィンドウで他人のデータが見えないことをテスト済み
  3. 別アカウント間でデータが混ざらないことをテスト済み

鍵（第4回・第5回） 4. service_role系の鍵がフロントエンドのコードに存在しない 5. NEXT_PUBLIC_付き変数は全部「見せてよい値」 6. デプロイ先の環境変数はSensitive/Secrets指定 7. GitHub Push Protectionが有効 8. git log --all -- .env で履歴に秘密が残っていない

ログイン（第6回） 9. 自分の管理アカウント（Supabase/Vercel/GitHub）にMFA設定済み 10. パスキーまたはMagic Link、少なくとも漏洩パスワード照合あり

入力・AI機能（第7回） 11. データベース操作はパラメータ化（AIに確認させ、自分の目で結果を見た） 12. AI出力を直接実行・保存していない 13. AI機能にレート制限と課金上限アラート

作業環境（第8回） 14. MCPサーバーは提供元を説明できるものだけ 15. チャットの学習利用設定を確認済み

医療情報（第9回・第10回） 16. 実在の患者情報を入力していない（ダミー化・構造化・一般化で変換済み） 17. 端末の全ディスク暗号化が有効で、医療情報のスクショ・履歴を棚卸し済み

17項目。慣れれば20分で回れます。

公開のたびに、毎回。 一度合格したアプリも、機能を足せば新しい穴が開きます。

ㅤ

AIに監査させる。ただし、盲信しない

このチェックリストは、AIに手伝わせることができます。

「このアプリを公開前チェックリストの観点で監査して。RLS、鍵の露出、インジェクション、レート制限」と指示すれば、かなりの精度で問題を挙げてくれます。公開前の線引きでやった型と同じです。

ただし、同じレッスンで確認したとおり、AIの「安全です」を鵜呑みにしない。

理由は2つあります。第一に、AIは自分の書いたコードに甘い判定を出すことがある。第二に、この講座で見てきたとおり、穴の多く（RLS未設定・管理画面のMFA・Push Protection）はコードの外側の設定にあり、コードだけ読んでも見えません。

だから型はこうです。

AIに監査させる。結果を自分の目でダッシュボードと突き合わせる。最後のテスト（見えないことの確認）は自分の手でやる。

診療と同じ構図です。検査機器の結果は使う。しかし最終判断は、患者を診ている人間がする。

ㅤ

事故が起きた日の初動

それでも事故は起きます。起きたときの行動は、第5回の「漏れた日の最初の10分」を全体に拡張したものになります。

事故が起きた日の流れ

1

止血

キー無効化・緊急遮断が最優先

2

記録

時系列でメモを残す

3

開示判断

個人情報なら通知・報告の検討

4

再発防止

チェックリストに1項目足す

1. 止血（数分〜1時間）

何が漏れているかで最初の一手が変わります。鍵の漏洩ならキーの無効化（第5回）。データの露出なら該当テーブルの緊急遮断（RLSで全拒否にする、またはアプリを一時停止する）。「調査してから」ではなく、止めてから調べます。

2. 記録

気づいた時刻、何が・いつから・誰に見えた可能性があるか、取った対応を時系列でメモします。あとで必ず要ります。

3. 影響評価と開示の判断

漏れた可能性のある情報に個人情報（利用者のメールアドレス等）が含まれるなら、本人への通知と、場合により個人情報保護委員会への報告が法律上必要になることがあります。ここから先は技術ではなく法律の領域です。医療データと法規の講座を参照し、判断に迷う規模なら専門家に相談してください。

4. 再発防止を1つ、チェックリストに足す

事故はチェックリストの育て親です。塞いだ穴を項目に変えて、17項目を18項目にして終わります。

視点

隠すより、直して伝える

利用者が同僚の医療者であるほど、「黙って直す」は信頼を削ります。影響が及んだ可能性のある人に、事実と対応を簡潔に伝える。誠実な開示は、事故対応であると同時に、医療者としての信頼の守り方でもあります。

注意

セキュリティの外にある、2つの境界線

公開する医療者ツールには、この講座の範囲外に法規上の境界が2つあります。①医療広告: ツールやサイトが特定の医療機関への受診を誘う内容（誘引性）を持つと、医療広告ガイドラインの規制対象になりえます。学習・情報整理ツールは通常対象外ですが、プロフィール欄からの自院誘導や効果をうたう体験談で一線を越えます。②医療機器プログラム（SaMD）: 計算ツールが「診断・治療に寄与」し、かつ計算過程がブラックボックスだと、医療機器プログラム該当性の検討が必要になります。ガイドラインの公知の計算式を出所明記で実装する範囲なら非該当側です。詳しくは医療データと法規の講座へ。

ㅤ

卒業ゲート

この講座の卒業条件は、知識ではなく行動です。

自分が公開している（またはこれから公開する）アプリ1本に、17項目のチェックリストを実際に回しきる。

すべてにチェックが付いたら、あなたのアプリは、2026年の実被害統計で98%側ではなく、2%側にいます。

セルフチェック

1. 公開後にデータベースの内容が第三者から見える状態だと気づいた。最初の一手は？

2. AIによるセキュリティ自己監査の正しい位置づけは？

ㅤ

今日のまとめ

3行で振り返ります。

  • セキュリティは優秀さではなく手順。17項目を公開のたびに回す
  • AIに監査させ、設定とテストは自分の手で確かめる
  • 事故の初動は止血→記録→開示判断→再発防止1つ。隠すより直して伝える

ㅤ

個人編を終えたあなたへ

セキュリティの知識は、これで終わりではありません。OWASP Top 10は数年ごとに更新され、プラットフォームの推奨も変わります。ただ、幹は変わりません。

ブラウザに届いたものは見えている。外から来た文字列は命令ではない。鍵は金庫に。最終確認は人間。

そしてここから先は、組織編です。自分のツールを守れるようになった次の壁は、「病院や組織の中で、セキュリティ部門の審査と経営層の意思決定を通す」こと。次回からの4回で、審査する側の視点、経営層のリスク言語、組織のAI利用ルールづくり、段階導入までを扱います。

ㅤ

参考・出典