AI問診の精度を劇的に高めるプロンプト設計術：患者回答を深掘りする動的問診の実装テンプレート

問診パーソナライズが実現する「診察前の予診完了」

「AI問診システムを導入したのに、結局医師が診察室で同じことを聞き直している」

医療現場でこのような課題に直面している場合、それはAIモデルの性能不足ではなく、「プロンプト設計（指示出し）」の解像度が粗いことが原因であるケースが多く見受けられます。

従来の静的なデジタル問診票は、紙をタブレットに置き換えた形式に留まり、患者個別の事情に踏み込むことが困難でした。一方で、ChatGPTの最新モデルのような高度なLLM（大規模言語モデル）を組み込んだAI問診は、患者の回答に応じてリアルタイムに質問を変える「動的問診」を可能にします。

特に、近年のLLMは抽象的な推論能力や長文理解が飛躍的に向上しており、複雑な文脈を読み取る力が強化されています。しかし、ただLLMに「問診して」と投げるだけでは、的外れな質問を繰り返したり、最悪の場合、誤った医学的アドバイス（ハルシネーション）を行ったりするリスクは依然として残ります。

本記事では、AI導入支援や業務プロセス自動化の観点から、「医師の思考プロセスを再現し、安全かつ効果的に情報を収集するためのプロンプト設計アプローチ」を解説します。これらは特定の公式テンプレートではありませんが、論理的な構造を持たせることで回答精度を高め、既存の業務フローにAIを最適に組み込むための「ロジックの部品」として活用できます。

画一的なデジタル問診票の限界と離脱率

「はい/いいえ」で答える形式や、決まりきった選択肢だけの問診票では、患者の主訴（最も訴えたい症状）のニュアンスを拾いきれません。

例えば、「頭が痛い」という訴えに対し、静的なフォームでは「いつから？」「痛みの強さは？」といった定型質問しかできません。しかし、熟練した医師なら、患者の表情や「なんとなく重い感じ」といった曖昧な言葉から、「締め付けられるような痛みですか？」「肩こりはありますか？」と、緊張型頭痛を疑う仮説検証プロセスを瞬時に行います。

この「仮説検証プロセス」を欠いた問診は、患者にとって「伝わっていない」という不満を生み、医師にとっては「情報不足」となります。結果として、システム利用の離脱率が上がり、診察時間の短縮につながらないという悪循環に陥ります。

AIによる動的生成とルールベースの違い

ルールベース（フローチャート式）の問診システムも存在しますが、あらゆる分岐を事前に設計するには限界があります。人間の症状や表現には無限のバリエーションがあるからです。

LLMを用いた動的生成の真価は、「高度な文脈理解と推論」にあります。最新の生成AIモデルは、単語の表面的なマッチングだけでなく、背後にある因果関係を推論する能力が強化されています。

例えば、患者が「昨日、重い荷物を持ってから腰が痛くて、足もしびれるんです」と入力した場合、AIは即座に「腰椎疾患の可能性」を背景知識として想起し、「しびれは足のどのあたりですか？」「排尿・排便に異常はありませんか？」といった、整形外科医さながらの深掘り質問を生成することが可能です。

ただし、これらの挙動を安定させるためには、役割（Role）、制約（Constraints）、出力形式（Output Format）を明確に定義した「システムプロンプト」や「カスタム指示」が不可欠です。公式ドキュメント等でも推奨されている通り、AIに期待する振る舞いを具体的に言語化することが、実用的なシステム構築の鍵となります。

このテンプレート集で解決できる課題

今回紹介するプロンプト設計の考え方を活用することで、以下の3つの課題解決を目指します。

1. 情報の粒度向上: 曖昧な訴えを具体化し、医学的に意味のある情報（所見）に変換する。
2. UXの最適化: 高齢者には平易な言葉、若年層には効率的な選択肢など、相手に合わせた対話を実現する。
3. 医師の負荷軽減: 収集した情報をSOAP形式などで構造化して出力させ、カルテ転記の手間を最小化する。

それでは、具体的な設計論に入っていきましょう。

AI問診設計の安全原則とプロンプト構造

医療分野でのAI活用において、最も優先すべきは「安全性」です。どんなに便利な機能も、患者に害を与えたり、法的リスクを招いたりしては意味がありません。プロンプトエンジニアリングにおいても、この安全原則を「システムプロンプト（AIへの基本命令）」として強固に組み込む必要があります。

医療情報の取り扱いと匿名化の徹底

まず、技術的な前提として、OpenAIのAPIなどを利用する場合、送信データが学習に使われない設定（Zero Data Retentionポリシーなど）を確認することは必須です。その上で、プロンプト内でも個人特定につながる情報（PII）を含めないよう、前処理段階でフィルタリングする設計が求められます。

「診断」ではなく「情報収集」に徹する制約条件

AIによる問診で絶対に避けなければならないのが、「診断行為」と受け取られる出力です。「風邪ですね」「薬を出しておきます」といった断定は医師法に抵触する可能性があります。

システムプロンプトには、以下のような強力な制約（Guardrails）を設定します。

# Role & Constraints
あなたは医療機関の受付支援AIです。医師ではありません。
以下の制約を厳守してください：
1. 診断、病名の断定、治療方針の提示は絶対に行わないこと。
2. 薬の処方や具体的な医療アドバイスを行わないこと。
3. 緊急性が高いと判断される症状（激しい胸痛、意識障害、呼吸困難など）が入力された場合は、即座に問診を中断し、窓口や救急への連絡を促すこと。
4. 「〜の可能性があります」という表現も避け、「医師に詳しく伝えるために、もう少し教えてください」というスタンスを維持すること。

Safety-Firstプロンプトフレームワーク

実務において推奨されるプロンプト構造は、以下の4層構造です。

1. Role Definition (役割定義): AIの立ち位置（医療事務アシスタント等）を明確化。
2. Safety Protocols (安全プロトコル): 禁止事項と緊急時のエスカレーションフロー。
3. Context & Input (文脈と入力): 患者の属性、主訴、これまでの対話履歴。
4. Task & Output Format (タスクと出力形式): 次に行うべき質問の生成指示と、JSON等のフォーマット指定。

この構造を守ることで、AIの回答が暴走するリスクを最小限に抑えることができます。

テンプレート①：患者属性別・初期問診生成プロンプト

患者体験（UX）を向上させる鍵は、「自分に合わせてくれている」と感じさせることです。70代の高齢者に専門用語だらけの質問をしたり、20代の忙しい会社員に冗長な挨拶をしたりするのは適切ではありません。

主訴と年齢・性別に基づく質問セットの最適化

以下は、患者の基本属性（年齢・性別）と主訴を入力とし、最初の質問セットを生成するためのプロンプト例です。

【プロンプトテンプレート：初期問診生成】

# Instruction
あなたはプロフェッショナルな医療インタビュアーです。
以下の患者情報に基づき、最適な「最初の質問」を1つ生成してください。

# Patient Profile
- 年齢: {{age}}
- 性別: {{gender}}
- 主訴: {{chief_complaint}}

# Guidelines
1. トーン＆マナー:
   - 高齢者({{age}} >= 65): 丁寧な敬語、ゆっくりとした口調、一度に一つの質問のみ。
   - 若年層・中年層: 簡潔で効率的、礼儀正しいがフレンドリーな口調。
   - 小児({{age}} <= 15): 保護者が入力していると想定し、親しみやすい表現。

2. 質問の戦略:
   - 主訴に関連する最も重要な情報（発症時期、程度、付随症状）を確認する。
   - 専門用語は使わず、患者が日常使う言葉（例：「腹痛」→「お腹の痛み」）に変換する。
   - 回答しやすいように、具体的な選択肢を提示する。

# Output Format (JSON)
{
  "question_text": "患者への表示テキスト",
  "options": ["選択肢1", "選択肢2", "その他"],  // 選択肢がない場合はnull
  "intent": "質問の意図（医師向けメモ）"
}

高齢者向け vs 若年層向けの言い回し調整

入力例A: 75歳 女性、主訴「めまい」
AI出力イメージ:

「めまいがするとのこと、心配ですね。そのめまいは、どのような感じでしょうか？

1. 天井がぐるぐる回る感じ
2. 体がふわふわ浮くような感じ
3. 立ち上がった時にクラッとする感じ
4. その他」

入力例B: 28歳 男性、主訴「めまい」
AI出力イメージ:

「めまいの症状について詳しく教えてください。最も近い感覚を選んでください。

1. 回転性（ぐるぐる回る）
2. 浮動性（ふわふわする）
3. 立ちくらみ
4. その他」

このように、同じ症状でもターゲットに合わせて表現を変えることで、患者の回答負荷を下げ、正確な情報を引き出しやすくします。

テンプレート②：回答深掘り・チェイン質問生成プロンプト

初期質問の後は、患者の回答に応じて質問を深掘りしていく「チェイン質問（Chain of Thought Questioning）」が必要です。ここがAI問診の真骨頂であり、医師の思考を模倣する部分です。

曖昧な回答への具体化質問

患者はしばしば「なんとなく痛い」「気持ち悪い」といった曖昧な表現を使います。これを放置せず、OPQRST（Onset, Palliative/Provocative, Quality, Region, Severity, Time）のフレームワークを用いて具体化させます。

【プロンプトテンプレート：深掘り質問生成】

# Instruction
これまでの問診履歴に基づき、医師が診断を下すために不足している重要な情報を収集するための「次の質問」を生成してください。

# Context
- 現在の問診履歴: {{history}}
- 収集済み情報: {{collected_info}}

# Strategy (Medical Logic)
1. OPQRSTの観点で不足している要素を優先的に聞く。
2. 患者が「痛い」と言った場合、その性質（鋭い、鈍い、波がある等）を具体化する。
3. 重篤な疾患を示唆する「Red Flags」（危険信号）の有無を確認する。
   - 例：頭痛の場合 → 突然の激痛か？手足のしびれはあるか？
4. 質問は一度に一つだけ行う（Cognitive Loadを下げるため）。

# Example (Few-Shot)
User: 「お腹が痛いです」
AI: 「お腹のどのあたりが痛みますか？（右下、みぞおち、おへその周りなど）」
User: 「みぞおちです」
AI: 「その痛みはいつから始まりましたか？」

# Output
次の質問を生成してください。

痛みの性質（OPQRST）を網羅する追跡質問

このプロンプトのポイントは、collected_info（収集済み情報）を常にAIに提示し、「何が足りないか」を判断させる点です。

例えば、AIが「部位：みぞおち」「発症：昨夜から」という情報を認識していれば、次は「痛みの性質（Quality）」や「食事との関連（Provocative）」を聞くべきだと論理的に推論します。

また、One-Shotプロンプティング（例示を与える手法）を用いることで、AIに「どのような対話フローが理想か」を学習させ、精度の高い質問を生成させることができます。

否定的な回答が続いた場合のシナリオ分岐

患者が「いいえ」「ありません」を繰り返す場合、AIは「情報が取れていない」と判断しがちです。しかし医学的には「陰性所見（症状がないこと）」も重要な情報です。

プロンプトには、「重要な陰性所見が確認できたら、別の臓器や全身症状へ視点を切り替える」という指示を含めると良いでしょう。これにより、袋小路に入ることなくスムーズに問診を進められます。

テンプレート③：医師向け構造化要約プロンプト

問診の最後は、収集した大量のテキストデータを、医師が一目で理解できる形式に変換するプロセスです。医師は忙しく、チャットログを全て読み返す時間はありません。

SOAP形式への自動変換と整形

【プロンプトテンプレート：医師向け要約】

# Instruction
以下の問診ログから、医師のカルテ記載用に情報を抽出し、構造化された要約を作成してください。

# Input Data
{{chat_log}}

# Output Requirements
1. SOAP形式（Subjectiveパート中心）で出力すること。
2. 重要度タグ付け: 緊急性が高いキーワードや、診断の決め手となり得る情報は【重要】タグをつけるか、太字にする。
3. 事実と推測の分離: 患者が明確に述べた事実のみを記載し、AIの推測は含めない。
4. 陰性所見の明記: 「発熱なし」「吐き気なし」など、否定された重要症状も記載する。

# Output Format

## 主訴
(簡潔な主訴)

## 現病歴
(時系列に沿った症状の経過)

## 症状詳細 (OPQRST)
- Onset: ...
- Quality: ...
- Severity: ...

## 随伴症状
- あり: ...
- なし: ...(陰性所見)

## 既往歴・服薬
...

## AIによるトリアージ示唆 (参考)
(緊急度判定スコアとその理由)

重要度タグ付けとアラート抽出

このテンプレートでは、単なる要約ではなく、「医師の目線誘導」を意識しています。例えば、胸痛の患者で「冷や汗がある」という情報は心筋梗塞を示唆する極めて重要なサインです。これを埋もれさせず、【重要】冷や汗ありと強調表示させることで、医師の見落としを防ぎます。

カルテ転記用テキストの生成

多くの電子カルテはテキスト入力が基本です。JSON形式などの構造化データはシステム連携には便利ですが、最終的には医師が「コピー＆ペースト」できるプレーンテキストも生成しておくと、現場での評価が格段に上がります。

実装とテスト運用のチェックリスト

プロンプトが完成しても、いきなり全患者に展開するのは危険です。以下のステップで検証と改善を行いましょう。

想定外の回答に対するストレステスト

まずは開発チーム内で「意地悪な患者」になりきってテストを行います。

• 全く関係のない話（今日の天気など）を入力する。
• 矛盾する回答（「熱はない」と言った後に「39度ある」と言う）をする。
• 精神的な不調や希死念慮をほのめかす。

これらのエッジケースに対し、AIが安全プロトコルに従って適切にハンドリングできるか（例：「申し訳ありませんが、体の症状について教えてください」「それは専門の窓口にご相談ください」等）を確認します。

医師によるプロンプト評価とフィードバックループ

次に、協力的な医師に実際の生成結果（質問内容と要約結果）を見てもらい、フィードバックを受けます。

• 「この質問は医学的に意味がない」
• 「このタイミングでこれを聞いてほしい」
• 「要約が長すぎる」

こうした現場の声（Human-in-the-Loop）をプロンプトに反映させるサイクルこそが、精度の高いAI問診システムを作る唯一の道です。

段階的リリースの手順

まずは「予約外来」や「特定の診療科（例：内科のみ）」など、リスクコントロールがしやすい領域からスモールスタートすることをお勧めします。救急外来のような一刻を争う現場への導入は、システムが十分に成熟してから検討すべきです。

まとめ

AI問診の成功は、最先端のモデルを使うことよりも、「いかに医師の臨床推論をプロンプトに落とし込めるか」にかかっています。

今回ご紹介したテンプレートは、あくまで出発点です。各医療機関の診療方針や、ターゲットとする患者層に合わせて、言葉選びやロジックを微調整することが重要です。

プロンプトエンジニアリングは、一度作って終わりではありません。日々の診療データを見ながら、「もっとこう聞いた方が患者さんは答えやすいのではないか？」と改善を続けるプロセスそのものが、医療DXを推進する力となります。

開発されるシステムが、医師と患者の架け橋となり、医療現場の課題解決に貢献することを期待しています。