病院の多職種カンファレンスの記録から、患者ごとの方針・各職種の担当・次回の確認事項を要約して、記録の下書きにする

処理の起点を決める

書記がメモを所定のフォルダに保存したことを起点にします。 カンファレンスは病棟ごとに曜日と時間が違うので、毎日決まった時刻にまとめて動かす設計にはしません。 終わった病棟から順に下書きが出るほうが、書記がその日の勤務の中で確定させやすくなります。

保存するのは病棟・日付ごとに1ファイルです。ファイル名は 病棟コード_日付.txt に決め、名前が規則に合わないファイルは処理せず、書記に知らせます。 同じ名前で保存し直したときは、前の下書きを置き換えます。

確定の操作も、もう一つのきっかけです。 書記が確認画面で「確定」を押すと、翌週のカンファレンスシートへの書き出し（第5章の10番目）が動きます。確定前の下書きから書き出すことはしません。

入力データを集める

質を決めるのは、下の2つの一覧です。 職種名の一覧が無いと、「Ph」が薬剤師なのか理学療法士の誤記なのかを生成AIが推測します。担当の職種を推測で埋めると、第1章で避けたかった「引き受けていない仕事」がそのまま生まれます。 略語の一覧は、略語を勝手に展開させないための材料です。

書記のメモの書き方は、1つだけ決めます。 患者ごとに ■ 病室番号 患者の呼び名 の行で区切ることです。区切りが無いと、隣の患者の話が混ざります。 それ以外の書き方は今までどおりで構いません。

メモは、たとえば次のような形です。

■ 503 Aさん
Dr 肺炎は改善、来週抗菌薬終了予定
PT 歩行器で病棟内自立、階段は未
MSW 妻と面談まだ。自宅or施設 → 家族の意向確認してから
Ph 退院処方 一包化？ → 確認
次回 家族面談の結果

このメモの「→ 確認」には、誰が確認するのかも期日もありません。 薬剤師の行にあっても、医師に確認を頼んだのかもしれません。下書きでは「担当：薬剤師」とはせず、「担当：未定」として書記に返します。

データの取得方法を決める

患者の特定は、病室番号と呼び名の組で行います。 1つに決まらないとき（同じ病室番号に同じ呼び名の患者がいる、メモの病室番号が一覧に無い）は、その患者の分を処理せず、書記に確かめてもらいます。 別の患者の記録に混ざるのが、この業務でいちばん避けたい失敗です。

前回の確認事項は、確定した記録の控えからしか引きません。 下書きの段階のものを引くと、書記が消した項目が翌週に戻ってきます。

AIへ渡す前に整形する

1. 患者ごとの分割 … ■ の行で分け、各区切りの病室番号と呼び名を取り出します
2. 患者の特定 … 基本情報の一覧と照合し、1つに決まらない区切りは処理から外します
3. 記号への置き換え … 氏名・呼び名を {PT1}、患者IDを {ID1}、家族の氏名を {FAM1} のような記号にします
4. 事前記入と前回の確認事項の添付 … 患者ごとに、シートの記入と前回の宿題を同じ区切りに付けます
5. 退院予定日までの日数 … 基本情報から計算して添えます。生成AIには計算させません
6. 長さの確認 … 1名分のメモが極端に長い（目安として1,500字を超える）ときは、書記に区切り漏れが無いかを確かめてもらいます

3番目を軽く見ないでください。 カンファレンスのメモには、患者本人だけでなく、家族の氏名や続柄、勤務先が出てきます。 要約に必要なのは「妻」「長男」といった続柄で、氏名ではありません。

5番目は、前回の宿題の重さを判断する材料です。 退院予定日まで3日しかない患者の「家族の意向確認」が持ち越されていれば、下書きの先頭に出すように後段で並べ替えます。

AIに処理させる

させるのは、患者1名分のメモと事前記入から、次の項目を取り出して短く書き、それぞれに根拠の文を添えることです。

表の右端の列が、この構成でいちばん大事な部分です。 どの項目も、分からないときに「分からない」と書く場所を先に用意しておきます。 用意していないと、生成AIは前後の文脈からそれらしい担当や期日を作ります。

最後の行がいちばん起きやすい失敗です。 カンファレンスシートに「来週退院予定」と書いてあると、メモに退院の話が無くても、シートの記入を根拠に「来週退院で決定」と書きます。 事前記入は話し合いの前提として渡し、決定の根拠はメモの文に限ります。

指示内容を固定する

あなたは病棟の多職種カンファレンスの書記を補助する立場です。
渡すのは、患者1名分の【書記のメモ】【事前記入】【前回の確認事項】です。
記録の下書きを作りますが、確定させるのは書記です。

【取り出す項目】
1. 治療の方針
2. 退院の方針（行き先と時期）
3. 決まったこと・検討中のこと（1件ずつ）
4. 担当と期日（職種・すること・期日）
5. 本人・家族の意向（誰の意向か）
6. 次回の確認事項
7. 前回の確認事項それぞれが、今回のメモで触れられたか

【status の選び方】
- decided ....... メモに「決定」「〜で行く」「〜とする」など、決まったと読める文がある
- under_review .. 「検討」「方向で」「〜してから」「視野に」など、決まっていない
迷ったときに decided を選ばないでください。

【厳守事項】
- 決定の根拠は【書記のメモ】の文に限ってください。
  【事前記入】は話し合いの前の記入であり、決定の根拠にしないでください。
- 担当の職種・担当者・期日は、メモに書かれた範囲で書いてください。
  書かれていなければ「未定」とし、文脈から補わないでください。
- 「確認」「検討」とだけ書かれ、誰がするのかが無いものは、担当を「未定」にしてください。
- 職種は【職種名の一覧】の表記に合わせてください。一覧に無い略語は変えずに残し、
  unknown_terms に書き出してください。
- 方針を勧めたり、評価を足したりしないでください。
- 意向は、誰の意向かを書いてください。伝聞なら伝聞と分かるように書いてください。
- evidence には、根拠にしたメモの文をそのまま写してください。
- {PT1} {FAM1} のような記号は、そのまま残してください。

【書記のメモ】{memo}
【事前記入】{pre_notes}
【前回の確認事項】{previous_checks}
【職種名の一覧】{role_list}
【略語の一覧】{abbr_list}

「迷ったときに decided を選ばない」を明記しないと、文末の言い切りに引っ張られます。 「自宅の方向で」というメモは、話し言葉では決まったように聞こえても、記録としては検討中です。 迷う側を決めておくことで、書記の確認が under_review の項目に集まります。

「事前記入を決定の根拠にしない」は、指示とスキーマの両方で守ります。 evidence にはメモの文だけを入れさせ、後段でメモに実在する文かどうかを照合します。シートの文が入っていれば、その項目を under_review に戻します。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "patient_ref": "{ID1}",
  "treatment_policy": { "text": "", "evidence": "" },
  "discharge_policy": {
    "destination": "home | facility | transfer | not_stated",
    "timing": "", "status": "decided | under_review", "evidence": ""
  },
  "items": [
    { "text": "", "status": "decided | under_review", "evidence": "" }
  ],
  "tasks": [
    { "role": "", "action": "", "owner_stated": true,
      "due": "", "due_stated": false, "evidence": "" }
  ],
  "wishes": [
    { "whose": "patient | family | not_stated", "content": "",
      "hearsay": false, "evidence": "" }
  ],
  "next_checks": [ { "text": "", "role": "", "evidence": "" } ],
  "previous_checks": [
    { "text": "", "status": "addressed | not_addressed | unclear", "evidence": "" }
  ],
  "unknown_terms": []
}

1つ目の理由は、決定と検討を項目ごとに持てることです。 自由文の要約では、「自宅退院の方向で、家族の意向を確認」が1文に収まり、どこまでが決まったのかを読む人が判断することになります。 status を項目ごとに持たせると、確認画面で under_review だけを色分けできます。

2つ目は、owner_stated と due_stated で「言われたかどうか」を残せることです。 確認画面では、この2つが false の行を「担当未定」「期日未定」として書記に返します。

3つ目は、previous_checks で持ち越しを機械的に決められることです。 not_addressed と unclear のものは、確定のときに翌週の「次回の確認事項」へ自動で残します。書記が消さない限り、宿題は消えません。

構造化出力では、すべてのフィールドを必須にし、additionalProperties: false を設定する必要があります。項目が無いときは空の配列か not_stated を返させ、フィールドを省かせません。 スキーマは最大100個のオブジェクト プロパティ、5レベルの入れ子までという制限があるので、上の形はその範囲に収めています。

システムへ連携する

生成AIへは、患者1名ずつ送ります。 15名分をまとめて送ると、隣の患者の担当が混ざったときに見つけにくくなります。1名1回にすれば、混ざる経路そのものがありません。

照合は中継の処理で行います。 role が職種名の一覧にあるか、evidence の文がメモに実在するか、due が日付として読めるかを確かめ、どれかが合わなければその項目を under_review に戻して書記に返します。

人が確認する

確定させるのは書記で、確認の順番を決めておきます。

1. 「担当未定」「期日未定」の行を先に見る … カンファレンスで実際に誰が引き受けたかを思い出して埋めます。思い出せなければ「未定」のまま確定し、次回の確認事項に回します
2. under_review の項目を読む … 本当に検討中だったか、決まっていたのかを確かめます
3. decided の項目の根拠を確かめる … evidence の文を読み、決定と読めるかを見ます
4. 前回の宿題の扱いを確かめる … addressed になっているものが、本当に今回話されたかを見ます
5. 確定を押す

1番目に「未定のまま確定してよい」としているのは、意図してのことです。 書記が担当を推測で埋めると、生成AIに推測させないようにした意味がなくなります。未定は未定として残し、次の話し合いで決めます。

医療の質管理室は、月に1回、確定した記録から1病棟あたり10名分を抜き取ります。 下書きと確定版の差分を見て、書記が直した箇所の多い項目を数えます。直しが多い項目は、指示の書き方か一覧の整備に戻します。

例外に対処する

上から2行目を軽く見ないでください。 同じ病室に同じ姓の患者がいることは珍しくありません。特定できないまま下書きを作るより、作らないほうが安全です。

7行目は、宿題が消えないための行です。 取り上げなかった患者は記録が作られないので、何もしないと前回の宿題がどこにも残りません。

記録を残す

• 書記のメモの原本と、保存した日時
• 生成AIへ送った入力（記号に置き換えた後のもの）と、返ってきたJSON
• 照合の結果（under_review に戻した項目と理由）
• 書記が確定した記録と、下書きからの差分
• 翌週のシートへ書き出した確認事項と、持ち越した宿題
• 記号と元の氏名の対応表（院内のファイルサーバーにだけ置く）

4つ目の差分が、改善の材料になります。 どの項目を、どちらに直したか（decided を under_review に、未定を担当ありに）を数えると、指示の書き方の弱いところと、メモの書き方の弱いところが分かれて見えます。

最後の対応表は、生成AIの側には送りません。 記号のまま返ってきた下書きに氏名を戻すのは、院内の中継の処理だけです。