薬剤師（ドメインエキスパート）と一緒に育てる薬局向けAIアシスタント

by KAKEHASHI

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

1. オープニング・課題設定 ● 薬局業務の流れ ― 服薬指導のたびに薬歴執筆が発生する ○ STEP1 処方箋受付・患者確認：前回薬歴・アレルギー歴・併用薬・要注意フラグを事前確認 ○ STEP2 処方監査：用法用量・禁忌・相互作用・重複投薬を確認。問題があれば疑義照会 ○ STEP3 調剤：計量・分包・一包化。別の薬剤師がダブルチェック（鑑査） ○ STEP4 服薬指導：患者と対話し「聞く・伝える・判断する」（平均3〜10分） ← 今回の対象 ○ STEP5 薬歴執筆：指導内容をSOAP形式で記録（平均2〜5分） ← 今回の対象 ○ STEP6 会計・お渡し：薬の手渡し・おくすり手帳・次回来局の案内 ○ STEP7 事後対応：医師へのトレーシングレポート送付・服薬期間中フォロー ● この毎回発生する記録業務の負荷が、本講演の出発点 © KAKEHASHI Inc. All Rights Reserved. 4

Slide 5

Slide 5 text

Slide 6

Slide 6 text

1. オープニング・課題設定薬歴とは ― 薬剤師に義務づけられた服薬指導の記録 SOAP形式（Subjective / Objective / Assessment / Plan）で書くのが標準 S＝患者の主観、O＝客観情報、A＝薬剤師の評価、P＝計画・指導内容。患者ごとの記録は法定義務であり、1件あたり数分かかる記録作業が薬剤師の大きな業務負荷になっている。本セッションの問い「良い薬歴」とは何か？そして、LLMが生成する薬歴の品質は、誰がどうやって担保するのか？ © KAKEHASHI Inc. All Rights Reserved. 6

Slide 7

Slide 7 text

1. オープニング・課題設定「良い薬歴」の判断は、エンジニアには難しい例：患者の一言「最近体がだるい」― 同じ対話から生成される2つの薬歴改善前のAIが生成する薬歴（NG）薬剤師が求める薬歴（OK） S）「体がだるい。旅行に行って疲れたかも。仕事は普通にできている」とのこと。 A）副作用の可能性があるため注意が必要です。 → 雑談まで全部書く。Aは誰にでも当てはまる一般論 S）「体がだるい」とのこと。服薬継続中。 A）だるさは降圧薬による血圧低下の可能性。前回の用量変更あり、経過観察。 → 薬学的に重要な情報だけを残し、この患者だけの評価を書く ↑実在のものではなくサンプルです旅行・仕事の話を省く「取捨選択」も、「血圧低下の可能性」という仮説も、処方内容と前回薬歴を踏まえた薬剤師の専門判断。文法も形式も正しい ― それでも「良い薬歴」かはエンジニアには判断が難しい。これが本セッションの核心問題 © KAKEHASHI Inc. All Rights Reserved. 7

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

2. プロダクト紹介スケールが品質問題を顕在化させる「1%の問題」が毎日1,000件以上になる世界数千店舗規模では「1%の問題が毎日1,000件以上」発生する事象になる。実際に起きた例：発言動詞の混入あるモデル更新後、文末に「〜と述べている」（薬歴には基本書かない）という表現が全体の数%で発生。1日数千件規模の問題になって初めて検知された。スケールしているからこそ、出力品質の管理が事業の命題になった © KAKEHASHI Inc. All Rights Reserved. 11

Slide 12

Slide 12 text

Slide 13

Slide 13 text

3. ドメインエキスパートとは何者か ● カケハシには薬剤師資格を持つドメインエキスパートが社内にいる ○ 服薬指導の実務経験・薬歴記載の現場感覚を持つ ○ 役割は「現場の言葉とプロダクトの言葉を翻訳し、一緒にプロダクトを創る人」 ● なぜエンジニアだけでは品質を担保できないのか ○ LLMは「それらしい文章」の生成は得意。しかし「薬剤師として正しい薬歴」かどうかは別問題 ○ Pフィールドを丁寧に長く出力するよう調整 → 「読みにくい・現場では使えない」。長さと品質は別物 ○ 「患者が〇〇と訴えた」→ 薬歴では「〇〇とのこと」が自然。文体の慣習すらドメイン知識 © KAKEHASHI Inc. All Rights Reserved. 13

Slide 14

Slide 14 text

3. ドメインエキスパートとは何者か「文脈の壁」― 現場の違和感は、そのままでは開発に届かない現場の薬剤師が感じる「なんかおかしい」を、開発チームに伝えるのは難しい顧客から「薬歴が使いにくい」というフィードバック。エンジニアが見ると文法的に正しく、SOAPの形式も満たしている ― どこが問題なのか分からない。ドメインエキスパートが見ると、一瞬で特定できた「Sに患者の主観ではなく薬剤師の解釈が入っている」という構造的な問題だと即座に言語化。「なんかおかしい」をissueに変換できるのはドメインエキスパートだけ © KAKEHASHI Inc. All Rights Reserved. 14

Slide 15

Slide 15 text

3. ドメインエキスパートとは何者か「文脈の壁」の実例 ― 言語化されて初めて直せる 01 02 03 発言動詞問題 S/P混入問題会計情報混入問題モデル変更後、「〜と述べました」が薬剤師の説明がSに混入。「Sは患者会計時の録音でSOAPに支払い情混入。文法は正しいが「薬歴の文体の声、薬剤師の説明はP。混ざると報が混入。「会計は薬学的介入では慣習」に反する。言語化を経て「発言薬歴の意味が変わる」と言語化し、ない」と定義し、「事務情報はPに記動詞禁止」ルールを追加。 S/P判別基準を明示して改善。載しない」ルールを追加。例：最近眠れないと述べていました薬剤師：「飲み薬は朝食後1回です」患者：「はい」 × S：飲み薬は朝食後1回であることを了承している。 © KAKEHASHI Inc. All Rights Reserved. 15

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

4. 開発サイクルへの組み込み方【1】プロンプト構築薬剤師は判断基準と境界例を持ち込み、プロンプトも「書く」エンジニアが分析の仕組み・実装・構造化を担い、薬剤師（ドメインエキスパート）が評価軸・優先順位・境界例を持ち込む。この分業でプロンプトを育てた。実例：薬剤師がプロンプトに持ち込んだ4つのもの・暗黙知の可視化 ― 文字起こし・AI生成案・薬剤師の確定薬歴の差分から「必ず補足／削除／変換される情報」を帰納的に抽出し、制約条件に落とし込む・評価軸の設計 ― 修正を「削除・修正・追加」×修正負荷（高・中・低）で分類する分析プロンプト自体を薬剤師が設計。・優先順位の設計 ― 「①事実性＞ ②分類境界＞ ③網羅性＞ ④文体」。S/P混同が起きたら事実性を優先してSを空にする、という判断は薬剤師にしかできない・境界例の記述 ― 「熱はないですか」→「はい」は肯定か否定か曖昧なので不採用 ― 現場の失敗から帰納したルールを薬剤師が直接記述 © KAKEHASHI Inc. All Rights Reserved. 18

Slide 19

Slide 19 text

4. 開発サイクルへの組み込み方 Sフィールドの禁止表現初期はほぼ存在しなかった禁止リストが、現在は具体的なルール群に Before：曖昧な指示「患者の主観情報を書く」とだけ記載。何を書いてはいけないかが不明確なまま。 After：具体的な禁止ルール「〜と述べている」「回答した」「了承している」「質問はない」「不安はない」等の表現を明示的に禁止。正規表現でカットするなどの対策。すべて「現場の薬剤師が実際に違和感を覚えた表現」をドメインエキスパートが言語化し、プロンプトと正規表現ルールに落とし込んだ結果。 © KAKEHASHI Inc. All Rights Reserved. 19

Slide 20

Slide 20 text

4. 開発サイクルへの組み込み方【2】品質評価 ― Human-in-the-loopの設計評価するだけでなく、「評価軸の設計」そのものを担う LLMが出力した薬歴草稿をドメインエキスパートが評価するパイプラインを構築。「採用したくなる薬歴の定義書」も共同作成し、評価基準を言語化した。評価事例をLLM as a Judgeに活用 ― 薬剤師の判断をスケールさせる仕組みただし、現状ではリリース前にドメインエキスパートの評価は必ず組み込んでいる © KAKEHASHI Inc. All Rights Reserved. 20

Slide 21

Slide 21 text

4. 開発サイクルへの組み込み方 ● 実例：薬歴評価プロンプトの5つの評価軸（ドメインエキスパート主導で設計） ○ 1. SOAP+OPの構造が正しく使われているか ○ 2. 文章が簡潔でわかりやすいか ○ 3. 記載に「個別性」があるか（← 特にドメイン知識が必要な軸） ○ 4. 内容が具体的に書かれているか ○ 5. 薬歴全体として内容に矛盾がないか ● 「個別性」＝一般論ではなく“この患者だけの情報”が書かれているか ○ エンジニアだけでは定義できない、薬剤師の実務経験から生まれた基準。 © KAKEHASHI Inc. All Rights Reserved. 21

Slide 22

Slide 22 text

4. 開発サイクルへの組み込み方【3】VOCの言語化 ― 現場の声を開発インプットに現場薬剤師の声を、開発が動ける問題定義に翻訳する薬局現場からのフィードバックをドメインエキスパートが受け取り、開発チームが理解できる言語に変換する。実例：「薬歴が長すぎる」というVOC 複数店舗から「長すぎる」の声。エンジニアが見ると文字数は適切範囲内で原因不明。分析の結果「Sに患者の雑談まで入っている。服薬指導に無関係な発言の除外ルールが必要」と特定 → プロンプト修正で解決。現場の「なんかおかしい」をissueに変換できるのはドメインエキスパートだけ © KAKEHASHI Inc. All Rights Reserved. 22

Slide 23

Slide 23 text

4. 開発サイクルへの組み込み方座組みの全体像 ― 三者が同じ開発サイクルの中で動くドメインエキスパートエンジニア PdM / PMM システムの品質出力の品質事業の品質モデル選定・システム設計・評価パイプロンプト設計・品質評価・VOC言ロードマップ策定・顧客コミュニケープラインの構築を担う。語化を担う。ションを担う。 © KAKEHASHI Inc. All Rights Reserved. 三者が同じ開発サイクルの中で役割分担して動く構造 23

Slide 24

Slide 24 text

Slide 25

Slide 25 text

5. 工夫・学び ● ドメインエキスパートを「レビュアー」ではなく「設計者」として位置づけた ○ レビュー依頼ではなく、プロンプト・評価軸の設計そのものを担ってもらう ● 「良い薬歴の定義書」を最初に共同作業でやりきった ○ プロンプト・評価・VOC対応、すべての基準になった ● 週次の品質レビュー会で、全員が同じ数字を見る ○ 採用率・利用率・差分分析結果を、エンジニアとドメインエキスパートが一緒に見る習慣 © KAKEHASHI Inc. All Rights Reserved. 25

Slide 26

Slide 26 text

5. 工夫・学び ● 最初は依頼が「なんとなくこれ見てください」になっていた ○ 評価観点を明示してから、レビューの質が劇的に上がった ● 「薬剤師が使いやすい」設計 ○ 正確でも読みにくい薬歴は採用されない。気づくのに時間がかかった ● ドメイン知識をプロンプトに全部詰め込むと破綻する ○ この失敗から、ユースケース別・フィールド別の階層化設計に至った © KAKEHASHI Inc. All Rights Reserved. 26

Slide 27

Slide 27 text

Slide 28

Slide 28 text

6. まとめ ● LLMプロダクトの品質は、モデルの性能だけでは決まらない ○ ドメイン知識を開発プロセスに組み込む「設計」が品質の鍵 ● ドメインエキスパートは「レビューア」ではなく「開発サイクルの一員」 ○ プロンプト構築・品質評価・VOC言語化 ― 3つの関与ポイントで機能させる ● 「文脈の壁」は、翻訳者を置くことで超えられる ○ あなたのチームに「文脈の壁」はありませんか？どの関与ポイントから始めますか？ © KAKEHASHI Inc. All Rights Reserved. 28