そのAIは医療機器なのか
機能開発の前に決めるべき6つの境界
医療・ヘルスケア領域でAIを使った新規事業を考えるとき、多くの企業は最初にモデルを探します。
どの生成AIを使うか。
画像認識の精度はどの程度か。
既存製品にAI機能を追加できるか。
研究論文では、どのモデルが高いスコアを出しているか。
もちろん、技術選定は重要です。
しかし、医療AIを事業として成立させるうえで、技術より先に決めなければならないことがあります。
それは、そのAIが「誰の、どのような判断を、どこまで支援するのか」です。
この問いが曖昧なまま開発を始めると、後から規制、表示、検証、契約、販売方法、現場責任のすべてが揺れます。
米国病院協会は2026年8月13日、FDAに対して、臨床意思決定支援ソフトウェア、ウェルネスアプリ、生成AIの医療機器・非医療機器の境界をより明確にするよう意見を提出しました。
これはFDAの最終判断ではありません。しかし、医療現場を代表する組織が、AIの進歩そのものではなく、「どこからが医療機器なのか」「市販後にどう評価するのか」という境界の問題を重視している点は重要です。
私は医師でも薬事専門家でもありません。PrimaDiemで医療機器・ヘルスケアのBizDevに関わる立場から、技術やアイデアを現場導入と事業に進めるための論点として整理します。
1. 「医療機器かどうか」は機能名だけでは決まらない
「診断機能ではありません」
「参考情報を表示するだけです」
「最終判断は医療者が行います」
このような説明は、事業の初期段階ではよく使われます。
しかし、製品の名称や説明文だけで、規制上の位置づけや責任範囲が決まるわけではありません。
重要なのは、実際に何を意図しているかです。
たとえば、同じ血圧データを扱うアプリでも、次のような違いがあります。
健康記録として過去の数値を表示する
生活習慣の改善を促す
異常の可能性を通知する
医療者に受診を勧める
医師の診療判断を支援する
薬剤変更や治療方針の判断材料を提示する
データが同じでも、出力の意味、利用者、表示方法、判断への関与度が変われば、製品の責任範囲は大きく変わります。
したがって、企画初期に「これは医療機器ですか」とだけ聞くのでは不十分です。
先に、「この製品は、誰のどんな判断に影響するものなのか」を分解する必要があります。
2. 境界①：誰が使うのか
最初に定義すべきなのは利用者です。
患者本人なのか。
家族なのか。
看護師なのか。
医師なのか。
介護職なのか。
病院の管理者なのか。
販売代理店の担当者なのか。
同じAIの出力でも、利用者によって求められる説明、教育、権限、責任は変わります。
たとえば、患者本人が見る健康情報と、看護師が業務中に参照するリスク通知では、求められる設計が同じではありません。
患者向けであれば、誤解しにくい表示、相談先、緊急時の案内が必要になります。
医療者向けであれば、根拠、信頼度、対象データ、限界、確認手順が必要になります。
管理者向けであれば、個別の判定よりも、導入効果、業務時間、記録、監査、費用対効果が重要になります。
「医療者が使う」と一括りにするのではなく、誰が、いつ、どの業務の中で使うのかまで明確にすることが必要です。
3. 境界②：何を入力し、何を出力するのか
AI製品の説明では、「大量のデータを分析する」「異常を検知する」「リスクを予測する」といった抽象的な表現が使われがちです。
しかし、事業化には入力と出力の具体化が欠かせません。
入力として何を使うのか。
医療画像
生体信号
電子カルテ情報
検査結果
介護記録
患者の自己申告
ウェアラブル端末のデータ
生活環境や行動データ
出力として何を返すのか。
数値
検出結果
リスクスコア
優先順位
推奨行動
アラート
自由記述
医療者への質問項目
「予測する」と言っても、何を予測するのかによって意味は変わります。
転倒リスクを示すのか。
再入院の可能性を示すのか。
服薬忘れを通知するのか。
検査画像の異常候補を示すのか。
入力と出力が曖昧だと、検証方法も、責任者も、導入場所も決まりません。
4. 境界③：AIは判断を支援するのか、実質的に決定するのか
「最終判断は人間が行います」という説明も、よく使われます。
しかし、実際の業務で人間がAIの出力をほぼそのまま採用しているなら、形式的に人が確認しているだけでは不十分です。
ここで確認すべきなのは、AIの出力が業務の中でどの程度の影響力を持つかです。
単なる参考情報なのか
確認すべき候補を絞るのか
優先順位を自動的に決めるのか
特定の患者や案件を見逃さないよう通知するのか
一つの行動を推奨するのか
複数の選択肢を比較するのか
人が拒否しない限り自動的に処理されるのか
特に、AIが一つの推奨だけを示す場合、利用者が「これが正解なのだ」と受け取りやすくなります。
そのため、画面上の説明だけでなく、業務手順、教育、確認記録、例外処理まで設計する必要があります。
AIの出力を確認する人が誰なのか。
確認したことをどこに記録するのか。
確認できない場合にどうするのか。
誤りに気づいたとき、誰が修正するのか。
これらが決まっていないAIは、技術的には完成していても、現場導入の準備ができていません。
5. 境界④：利用者は出力の根拠を独立して確認できるのか
医療AIでは、結果だけを表示するのではなく、その結果を人が確認できることが重要です。
これは、AIの内部処理をすべて説明するという意味ではありません。
少なくとも、次のような確認ができる必要があります。
どのデータを使ったのか
いつのデータを使ったのか
対象範囲に含まれるデータなのか
どの条件で注意が必要なのか
AIが苦手とするケースは何か
どの程度の確信度なのか
どの情報が不足しているのか
たとえば画像AIが「異常の可能性あり」と表示した場合、対象画像のどの領域を見ているのか、どの条件で精度が落ちるのか、利用者が確認できることが望まれます。
説明が不十分なまま、AIの結果だけが業務画面に表示されると、現場はその結果を過信するか、逆に信用しなくなります。
信頼性は、AIの性能だけでは作れません。
「確認できる」「疑問を持てる」「覆せる」という設計があって初めて、現場で使える道具になります。
6. 境界⑤：誤りや異常が起きたとき、誰が対応するのか
PoCでは、正常に動作したケースが評価されがちです。
しかし、現場では必ず例外が起きます。
データが欠ける。
センサーが外れる。
患者の状態が学習データと違う。
入力形式が変わる。
AIが回答できない。
通信が切れる。
利用者が誤った操作をする。
通知を誰も見ない。
このようなときに、システムが「判断できません」と表示するだけでは不十分です。
必要なのは、例外時の業務導線です。
誰に通知するのか
何分以内に確認するのか
代替手順は何か
患者や利用者にどう説明するのか
事象をどこに記録するのか
再発防止の責任者は誰か
サービス停止を判断する基準は何か
AI導入の議論では、正常時の効率化に目が向きます。
しかし、医療・介護の現場で本当に問われるのは、異常時に業務が止まらないことです。
BizDevの立場では、これを「開発後の運用課題」として残してはいけません。
販売代理店、保守会社、医療機関、現場責任者、製品提供者が、どのように連絡し、どこまで対応するのかを契約と運用設計に落とし込む必要があります。
7. 境界⑥：誰が購入し、運用し、費用を負担するのか
医療AIが技術的に優れていても、購入者と利用者が別の場合、導入は簡単ではありません。
現場スタッフが便利だと感じても、購入予算を持つのは経営企画部門かもしれません。
医師が必要だと考えても、情報システム部門がセキュリティ上の懸念を持つかもしれません。
病院が導入したくても、保険者や自治体の支払い構造と合わないかもしれません。
そのため、企画時点で次の関係者を整理する必要があります。
実際に使う人
導入を決める人
予算を出す人
効果を評価する人
問い合わせを受ける人
不具合時に対応する人
契約を更新する人
誰か一人を「顧客」と呼ぶだけでは、販売設計になりません。
AIの価値は、利用者の便利さだけでなく、組織全体の業務、記録、リスク、収益、患者体験に接続する必要があります。
例えば、看護記録の下書き支援なら、入力時間の短縮だけでなく、修正率、記録漏れ、監査証跡、教育コスト、情報システムとの連携まで評価対象になります。
誰がいくら払うのかが見えないPoCは、成功しても本番導入につながりません。
8. 開発前に使える「6項目シート」
医療AIの企画では、次の6項目を一枚にまとめるだけでも、議論の質が変わります。
1. 利用者
誰が使うのか。患者、家族、看護師、医師、介護職、管理者など。
2. 入力
何のデータを使うのか。データの取得元、更新頻度、欠損時の扱いも含める。
3. 出力
数値、候補、アラート、順位、推奨など、何を返すのか。
4. 判断への関与度
参考情報なのか、優先順位付けなのか、行動提案なのか、実質的な決定なのか。
5. 例外処理
誤り、異常、欠損、通信障害、緊急時に誰が何をするのか。
6. 事業導線
誰が購入し、誰が運用し、誰が費用を負担し、誰が契約を更新するのか。
このシートを、企画、開発、薬事、品質、営業、現場の関係者で確認します。
全員が同じ一枚を見て議論できることが重要です。
9. よくある失敗
医療AIの企画で起きがちな失敗は、技術不足ではありません。
一つ目は、AIの性能評価だけを先に行うことです。
精度が高くても、現場の業務に入らなければ使われません。
二つ目は、薬事を開発の最後に確認することです。
意図する使用や表示内容は、画面、営業資料、契約、導入教育に関わります。後から変更すると、開発範囲そのものが変わります。
三つ目は、PoCの成功指標が「使ってもらえた」で終わることです。
本番導入には、処理時間、修正率、エラー率、教育負担、継続利用率、支払意思、業務責任の所在まで必要です。
四つ目は、販売代理店を最後に探すことです。
医療機器の場合、販売後の教育、保守、苦情受付、回収、改善情報の伝達まで含めて商流を考える必要があります。
10. 最後に
医療AIは、AIモデルだけで完成する製品ではありません。
利用者、現場業務、規制、品質、責任、販売、支払いが接続されたときに、初めて事業になります。
だからこそ、開発の前に次の一文を書いてみてください。
「この製品は、誰が、どのデータを使い、どの判断を、どこまで支援するのか」
この一文が書けない場合、まだモデルを選ぶ段階ではないかもしれません。
まず決めるべきなのは、AIに何をさせるかではありません。
人と組織が、AIの出力に対して何を判断し、何を記録し、どこまで責任を持つのかです。
医療AIの事業化で、性能は重要です。
しかし、性能だけでは導入できません。
現場で使われ、異常時にも運用でき、購入者が価値を説明でき、導入後に改善を続けられること。
その全体を設計することが、医療・ヘルスケアBizDevの仕事だと考えています。
※本稿は、谷 和彦が医療機器・ヘルスケア領域のBizDev／導入設計の立場から整理したものです。個別製品の薬事該当性、法的評価、臨床判断については、各分野の専門家に確認してください。
参考資料：
いいなと思ったら応援しよう！
この記事は noteマネー にピックアップされました
