Claude APIの健康相談アプリは医療機器になるか — 薬機法のプログラム該当性

Claude APIを組み込んだ健康相談アプリが医療機器になるかどうかは、モデルの種類やプロンプトの書き方では決まりません。決め手は、そのアプリが「疾病の診断、治療又は予防」に使われることを目的としているかどうかです。目的は、アプリの表示・説明資料・広告から読み取られます。症状を入力させて病名の候補を返せば診断側に倒れ、一般的な生活習慣の情報提供にとどめれば医療機器の外に残ります。

この記事では、薬機法(医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律)の条文と、厚生労働省の「プログラムの医療機器該当性に関するガイドライン」を軸に、実装者が設計の段階で押さえる判断軸を順に見ます。広告表現の側は薬機法の広告NG表現をClaudeで点検する方法が扱っています。ここでは、アプリそのものが規制対象になるかを見ます。

薬機法はプログラムをどう定義しているか

薬機法2条4項は、医療機器を「人若しくは動物の疾病の診断、治療若しくは予防に使用されること、又は人若しくは動物の身体の構造若しくは機能に影響を及ぼすことが目的とされている機械器具等であつて、政令で定めるもの」と定めています。ここでいう機械器具等には、プログラムも含まれます。

プログラムの定義は、同法2条1項(医薬品)の括弧書きにあります。「電子計算機に対する指令であつて、一の結果を得ることができるように組み合わされたもの」です。つまりLLMを呼び出すアプリのコードも、法律上はプログラムです。

政令の別表は、疾病診断用プログラム、疾病治療用プログラム、疾病予防用プログラムを医療機器として挙げています。ただし各定義には、副作用や機能の障害が生じても人の生命や健康への影響がほとんどないものを除く、という但し書きがあります。この但し書きにより、一般医療機器(クラスI)に相当するプログラムは医療機器の範囲から外れます。

提供の仕方も条文に出てきます。薬機法は、医療機器プログラムを電気通信回線を通じて提供することを、医療機器の販売や貸与と並べて「製造販売」に含めています。アプリをアプリストアやWebで配るだけでも、該当すれば規制の対象になります。

使用目的が決め手になる理由

ガイドラインの「該当性の基本的考え方」は、判断の材料を明示しています。製造販売業者等による製品の表示、説明資料、広告等に基づき、使用目的とリスクの程度が医療機器の定義に当たるかを見る、という立て付けです。同じ機能でも、使用目的が違えば判断が変わる可能性があるとも書かれています。

実装者にとって大事なのは、次の2点です。

• コードの中身(どのモデルを呼ぶか)ではなく、利用者に何を約束しているかが判断材料になる
• 開発の初期、企画段階から、どんな表示をするかを含めて使用目的を検討しておくことが望ましいとされている

同じガイドラインは、複数の機能を持つプログラムについても触れています。少なくとも1つの機能が医療機器プログラムの定義を満たせば、プログラム全体が医療機器としての流通規制を受けます。「健康相談チャット」の隣に「症状から病名を推定する機能」を足すと、アプリ全体の扱いが変わりうる、ということです。

健康相談アプリの機能はどこで分かれるか

ガイドラインのフローチャートには、医療機器に当たらない例と、診断目的に当たる例が具体的に挙がっています。健康相談アプリの機能に引き寄せて並べると、次のようになります。

境目になるのは、利用者個人の入力を受けて疾病の名前や可能性を返すかどうかです。症状を聞いて「考えられる病気は〜です」と答える相談アプリは、フローチャートの上では、診断目的と判断される可能性が高い側にあります。

一方で、医療機器に当たらない機能だけで構成すれば、薬機法上のプログラム規制は受けません。健康な人の生活習慣に関する一般的な助言、医薬品の使い方の説明、受診を促す定型の一文が、その範囲です。

LLMを使うとき、特に注意したい3つの点

ガイドラインに生成AIへの言及はありません。以下は、ガイドラインの判断軸をLLM型の相談アプリに当てはめた読み方であり、公式の見解ではない点に留意してください。

診断・治療ガイドラインに従った処理だけ、と言い切れるか

ガイドラインは、診断・治療ガイドライン等に従った処理のみを行うものを医療機器に当たらない側に置いています。ただし「公知」の情報は、国内の医学教科書や国内の医学会の診療ガイドラインなど、国内で標準的な医療と認められているものに限られ、単に公表されているだけでは公知にならないと説明されています。

LLMは学習データ全体から応答を生成するので、「国内の標準的な医療に基づく処理のみ」と実装者が保証するのは簡単ではありません。疾病リスクを表示する場合の別紙のフローでも、算出過程がブラックボックス化したものは、公知の情報に従う側から外れる扱いです。

根拠を利用者が検証できる状態か

処理のアルゴリズムを見る観点として、ガイドラインは「アルゴリズムが何を根拠としているかを使用者が認識でき、妥当性を検証可能な状態にあるか」を挙げています。回答に出典を添えさせ、引用元を利用者が確かめられる形にするのは、この観点に沿った設計です。

個別の患者情報を分析して助言するか

認知行動療法などによる治療プログラムについては、リスクの考え方としてガイドラインが次の観点を示しています。

• 特定の疾病と診断された患者を対象としたものか
• 医師の責任で実施すべき行為の一部または全部を代替するか
• 個々の患者の情報を分析して、その患者に合った助言を提示するか
• 独自のアルゴリズムがあるか
• 不具合があった場合に患者の健康に及ぶ影響があるか

相談チャットが「あなたの検査値を踏まえた助言」を返す作りになるほど、これらの観点に近づきます。

「医療行為ではない」と表示すれば足りるのか

足りません。ガイドラインは、医療機器ではないプログラムについて、「疾病の診断、治療又は予防に使用されることを目的としていない」または「医療機器ではない」と記載・表示することが望ましい、としています。誤解を防ぐための推奨です。

同じガイドラインの脚注は、その記載があっても、医療機器ではないことの根拠にはならないと明記しています。疾病の疑いを判断できるなどと医療機器との認識を与える広告・標ぼうをする製品は、医療機器に該当するとされています。

つまり、免責文は入れておく価値があっても、それだけでは根拠になりません。利用者の目に入るすべての説明で、使用目的が一貫している必要があります。アプリ内の文言、ストアの説明文、LP、営業資料、口頭での説明までが判断材料です。

システムプロンプトと出力検査で線を守る実装例

線を守る実装は、3層で考えると整理しやすくなります。表示で目的を明示し、システムプロンプトで応答の範囲を絞り、出力側で逸脱を検査します。以下はこの記事の著者が書いた例であり、ガイドラインが定める要件ではありません。

1層目: システムプロンプトで応答の範囲を絞る

あなたは一般的な健康情報を提供するアシスタントです。
疾病の診断、治療、予防を目的としたサービスではありません。
 
次のことはしません。
- 利用者の症状から、病名や疾病の可能性を示すこと
- 個人の検査値や症状に基づいて、治療や服薬の判断を示すこと
- 「この症状なら大丈夫」「放置してよい」と安全性を保証すること
 
次のことはします。
- 一般的な生活習慣(食事・睡眠・運動)について、情報を提供する
- 症状や不安についての相談では、診断はできないと伝え、
  医療機関への相談や受診を勧める
- 急を要する可能性のある訴えには、救急や相談窓口の利用を案内する
- 情報には、確認できる公的機関や学会の資料などを添える

禁止を並べるだけでなく、「することの範囲」まで書いておくと、断られた利用者が行き場を失いにくくなります。システムプロンプトは応答の傾向を整えるものであり、モデルが指示を完全に守る保証はありません。そのため、出力側にも検査を置きます。

2層目: 出力を検査して逸脱を差し替える

import os
import anthropic
 
client = anthropic.Anthropic()
MODEL = os.environ["CLAUDE_MODEL"]  # 使うモデルIDを環境変数で指定
 
FALLBACK = (
    "ご相談の内容について、診断や治療の判断はできません。"
    "気になる症状があるときは、医療機関にご相談ください。"
)
 
CHECK_PROMPT = """次の回答案が、利用者個人の症状や検査値に基づいて
病名・疾病の可能性・治療や服薬の判断のいずれかを示しているかを判定する。
示していれば YES、示していなければ NO とだけ答える。
 
回答案:
{draft}"""
 
def answer(system_prompt: str, user_message: str) -> str:
    draft = client.messages.create(
        model=MODEL,
        max_tokens=1024,
        system=system_prompt,
        messages=[{"role": "user", "content": user_message}],
    ).content[0].text
 
    verdict = client.messages.create(
        model=MODEL,
        max_tokens=5,
        messages=[{"role": "user", "content": CHECK_PROMPT.format(draft=draft)}],
    ).content[0].text.strip()
 
    return FALLBACK if verdict.startswith("YES") else draft

検査用の呼び出しも、モデルの判定なので誤りがありえます。差し替えが多発する場合は、システムプロンプトか、そもそもの機能設計が使用目的とずれているサインです。ログを取って、どんな入力で差し替えが起きたかを見直します。

3層目: 表示と説明を一致させる

アプリの画面、ストアの説明、利用規約、LPで、使用目的の記述をそろえます。次のような齟齬があると、ガイドラインのいう使用目的の判断が、免責文ではなくそちらに引きずられます。

• 画面には「診断はできません」とあるのに、LPに「症状から病気をチェック」と書いてある
• 営業資料に「受診の要否を判定」と書いてある
• ストアの説明文に「AI診断」という語が入っている

Anthropic側の高リスク用途の要件も重なる

薬機法とは別に、Anthropicの利用ポリシー(AUP)にも、医療の分野に関する要件があります。AUPは、診断や、治療・服薬の推奨、そして症状や検査結果を解釈してトリアージや診断、治療計画につなげる用途を、高リスクな推奨の領域(Medical)に挙げています。

この領域でClaudeを使う場合、AUPは次の2つの管理を求めています。

• 有資格者による実質的なレビュー: 助言として利用者に届ける前に、有資格の担当者が内容を確認し、変更する権限を持つ
• AI利用の開示: 助言を受ける個人に、AIが使われたことを明確に伝える

AUPは、これらの要件が現地の法令の代わりにはならず、法令と矛盾する場合は法令に従うとも述べています。薬機法の該当性を避けて設計しても、症状の解釈を助言として出す作りにすれば、AUPの高リスク要件に別の側から当たりえます。

症状の入力から助言を返す機能そのものが、薬機法とAUPの両方で慎重に扱う領域です。逆に、一般的な生活習慣の情報提供に絞る設計は、両者の線の内側に収まりやすい構成です。症状相談そのものをClaudeでどう扱うかは、Claudeで症状を検索するときの注意点にも記事があります。

判断に迷ったときの動き方

ガイドラインは、個別の事例で薬機法の適用が判然としない場合に、厚生労働省の監視指導・麻薬対策課が相談・助言を行っているとして、その活用を勧めています。フローチャートの各所に「要相談」の分岐があり、判断が割れる設計は、相談を前提にした構成と言えます。

相談の前に整理しておくと話が早くなる項目は、ガイドライン自身が「判断のために明確にすべき項目の例示」として挙げています。

• プログラムの提供方法(単体で流通するか、機器と一体か)
• 使用者(医療関係者の管理下にない一般の利用者か、医療関係者か)
• 使用目的や効果(健康情報の管理、情報提供、疾病の診断・治療・予防 など)
• 処理方法(表示・保管・転送、疾病候補の表示、推奨治療方法の提示 など)
• 処理のアルゴリズム(公知の情報に従うか、独自か、根拠を利用者が検証できるか)
• 同じ機能を持つ医療機器の有無

医療機関向け(医療関係者が業務で使う)の相談ツールは、判断のフローが別になります。院内業務支援や患者への説明用のプログラムは医療機器に当たらない例に挙がる一方、入力情報から疾病候補を表示する機能は、診断目的の可能性が高い側に置かれます。医療機関向けの組み込みでは、院内の情報システムの扱いも論点になるため、医療情報システム安全管理ガイドラインで生成AIの入力はどう扱われるかもあわせて参照してください。

よくあるつまずき

• 免責文を入れたから大丈夫だと考える: 脚注にあるとおり、免責の記載は医療機器でないことの根拠になりません。広告や標ぼうの内容が優先して見られます
• 機能追加で全体の扱いが変わる: 1つの機能が医療機器の定義を満たすと、アプリ全体が流通規制を受けます。後から「病名候補」を足す前に、使用目的を見直します
• システムプロンプトだけで防げると考える: プロンプトは応答の傾向を整えるもので、保証ではありません。出力検査とログの確認を併用します
• 広告表現の点検だけで済ませる: 広告表現のチェックと、プログラム自体の該当性は別の論点です。後者は使用目的と機能の組み合わせで決まります

まとめ

Claude APIを使った健康相談アプリは、一般的な健康情報の提供にとどめれば、医療機器の外に収まる設計にできます。症状を聞いて病名や罹患の可能性を返す機能を持たせると、診断目的の側に近づきます。判断は、表示・説明・広告から読み取られる使用目的で決まり、免責文だけでは覆りません。

線を守る手段は、表示、システムプロンプト、出力検査の3層で重ねるのが現実的です。ただし、どの機能が該当するかの最終判断は、個別の事例ごとに行政の相談窓口で確かめる領域です。この記事の実装例は、その相談に入る前の設計の土台として使ってください。