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

ドメインエキスパートの知見を“チームの資産”に変える方法
https://levtechlab.connpass.com/event/400228/
での登壇資料です

Transcript

1. 薬剤師（ドメインエキスパート）と一緒に育てる 薬局向けAIアシスタント Building Pharmacy AI alongside Pharmacists 2026/09/08 株式会社カケハシ 藤村 浩司 © KAKEHASHI Inc. All Rights Reserved.
2. 目次 1. オープニング・課題設定 ― 「良い薬歴」とは何か 2. プロダクト紹介 ― 音声薬歴生成機能 3. ドメインエキスパートとは何者か ― 「文脈の壁」 4. 開発サイクルへの組み込み方 ― 3つの関与ポイント 5. 工夫・学び ― うまくいったこと、試行錯誤 6. まとめ ― 正解を知っている人と一緒に創る © KAKEHASHI Inc. All Rights Reserved. 2
3. 1 オープニング・課題設定 © KAKEHASHI Inc. All Rights Reserved. 3
4. 1. オープニング・課題設定 • 薬局業務の流れ ― 服薬指導のたびに薬歴執筆が発生する ◦ STEP1 処方箋受付・患者確認：前回薬歴・アレルギー歴・併用薬・要注意フラグを事前確認 ◦ STEP2 処方監査：用法用量・禁忌・相互作用・重複投薬を確認。問題があれば疑義照会 ◦ STEP3 調剤：計量・分包・一包化。別の薬剤師がダブルチェック（鑑査） ◦ STEP4 服薬指導：患者と対話し「聞く・伝える・判断する」（平均3〜10分） ← 今回の対象 ◦ STEP5 薬歴執筆：指導内容をSOAP形式で記録（平均2〜5分） ← 今回の対象 ◦ STEP6 会計・お渡し：薬の手渡し・おくすり手帳・次回来局の案内 ◦ STEP7 事後対応：医師へのトレーシングレポート送付・服薬期間中フォロー • この毎回発生する記録業務の負荷が、本講演の出発点 © KAKEHASHI Inc. All Rights Reserved. 4
5. 皆さん、薬剤師さんがどのような薬歴を 書くべきか想像できますか？ © KAKEHASHI Inc. All Rights Reserved.
6. 1. オープニング・課題設定 薬歴とは ― 薬剤師に義務づけられた服薬指導の記録 SOAP形式（Subjective / Objective / Assessment / Plan）で書くのが標準 S＝患者の主観、O＝客観情報、A＝薬剤師の評価、P＝計画・指導内容。患者ごとの記録は法定義務であ り、1件あたり数分かかる記録作業が薬剤師の大きな業務負荷になっている。 本セッションの問い 「良い薬歴」とは何か？ そして、LLMが生成する薬歴の品質は、誰がどうやって担保するのか？ © KAKEHASHI Inc. All Rights Reserved. 6
7. 1. オープニング・課題設定 「良い薬歴」の判断は、エンジニアには難しい 例：患者の一言「最近体がだるい」― 同じ対話から生成される2つの薬歴 改善前のAIが生成する薬歴（NG） 薬剤師が求める薬歴（OK） S）「体がだるい。旅行に行って疲れたかも。仕事は普通にでき ている」とのこと。 A）副作用の可能性があるため注意が必要です。 → 雑談まで全部書く。Aは誰にでも当てはまる一般論 S）「体がだるい」とのこと。服薬継続中。 A）だるさは降圧薬による血圧低下の可能性。前回の用量変更 あり、経過観察。 → 薬学的に重要な情報だけを残し、この患者だけの評価を書く ↑実在のものではなくサンプルです 旅行・仕事の話を省く「取捨選択」も、「血圧低下の可能性」という仮説も、処方内容と前回薬歴を踏まえた薬剤師の専門判断。 文法も形式も正しい ― それでも「良い薬歴」かはエンジニアには判断が難しい。これが本セッションの核心問題 © KAKEHASHI Inc. All Rights Reserved. 7
8. 2 プロダクト紹介 ― 音声薬歴生成機能 © KAKEHASHI Inc. All Rights Reserved. 8
9. 2. プロダクト紹介 音声薬歴生成機能の仕組み 録音 AI生成 確認・保存 © KAKEHASHI Inc. All Rights Reserved. 9
10. 2. プロダクト紹介 現在の規模感 ― 全国の薬局現場で毎日稼働 数万 数千 本番展開店舗数 1日の対話処理件数 全国数千店舗超の薬局に本番展開中 毎日約数万件の服薬指導対話を 処理 © KAKEHASHI Inc. All Rights Reserved. 10
11. 2. プロダクト紹介 スケールが品質問題を顕在化させる 「1%の問題」が毎日1,000件以上になる世界 数千店舗規模では「1%の問題が毎日1,000件以上」発生する事象になる。 実際に起きた例：発言動詞の混入 あるモデル更新後、文末に「〜と述べている」（薬歴には基本書かない）という表現が全体の数%で発生。1日数千件規模の 問題になって初めて検知された。 スケールしているからこそ、出力品質の管理が事業の命題になった © KAKEHASHI Inc. All Rights Reserved. 11
12. 3 ドメインエキスパートとは何者か © KAKEHASHI Inc. All Rights Reserved. 12
13. 3. ドメインエキスパートとは何者か • カケハシには薬剤師資格を持つドメインエキスパートが社内にいる ◦ 服薬指導の実務経験・薬歴記載の現場感覚を持つ ◦ 役割は「現場の言葉とプロダクトの言葉を翻訳し、一緒にプロダクトを創る人」 • なぜエンジニアだけでは品質を担保できないのか ◦ LLMは「それらしい文章」の生成は得意。しかし「薬剤師として正しい薬歴」かどうかは別問題 ◦ Pフィールドを丁寧に長く出力するよう調整 → 「読みにくい・現場では使えない」。 長さと品質は別物 ◦ 「患者が〇〇と訴えた」→ 薬歴では「〇〇とのこと」が自然。文体の慣習すらドメイン知識 © KAKEHASHI Inc. All Rights Reserved. 13
14. 3. ドメインエキスパートとは何者か 「文脈の壁」― 現場の違和感は、そのままでは開発に届かない 現場の薬剤師が感じる「なんかおかしい」を、開発チームに伝えるのは難しい 顧客から「薬歴が使いにくい」というフィードバック。エンジニアが見ると文法的に正しく、SOAPの形式も 満たしている ― どこが問題なのか分からない。 ドメインエキスパートが見ると、一瞬で特定できた 「Sに患者の主観ではなく薬剤師の解釈が入っている」という構造的な問題だと即座に言語化。 「なんかおかしい」をissueに変換できるのはドメインエキスパートだけ © KAKEHASHI Inc. All Rights Reserved. 14
15. 3. ドメインエキスパートとは何者か 「文脈の壁」の実例 ― 言語化されて初めて直せる 01 02 03 発言動詞問題 S/P混入問題 会計情報混入問題 モデル変更後、「〜と述べました」が 薬剤師の説明がSに混入。「Sは患者 会計時の録音でSOAPに支払い情 混入。文法は正しいが「薬歴の文体 の声、薬剤師の説明はP。混ざると 報が混入。「会計は薬学的介入では 慣習」に反する。言語化を経て「発言 薬歴の意味が変わる」と言語化し、 ない」と定義し、「事務情報はPに記 動詞禁止」ルールを追加。 S/P判別基準を明示して改善。 載しない」ルールを追加。 例：最近眠れないと述べていました 薬剤師：「飲み薬は朝食後1回です」 患者：「はい」 × S：飲み薬は朝食後1回であることを了承している。 © KAKEHASHI Inc. All Rights Reserved. 15
16. 4 開発サイクルへの組み込み方 © KAKEHASHI Inc. All Rights Reserved. 16
17. 4. 開発サイクルへの組み込み方 ドメインエキスパートの3つの関与ポイント 01 02 03 プロンプト構築 品質評価（HITL） VOCの言語化 「AIへの指示書」の設計に、薬剤師の LLM出力を薬剤師の目で評価し、評 現場の声を、開発チームが動ける言 ドメイン知識を直接埋め込む。 価軸そのものも設計する。 葉に翻訳する。 © KAKEHASHI Inc. All Rights Reserved. 17
18. 4. 開発サイクルへの組み込み方 【1】プロンプト構築 薬剤師は判断基準と境界例を持ち込み、プロンプトも「書く」 エンジニアが分析の仕組み・実装・構造化を担い、薬剤師（ドメインエキスパート）が評価軸・優先順位・境界 例を持ち込む。この分業でプロンプトを育てた。 実例：薬剤師がプロンプトに持ち込んだ4つのもの ・暗黙知の可視化 ― 文字起こし・AI生成案・薬剤師の確定薬歴の差分から「必ず補足／削除／変換される情報」を帰納的に抽出し、 制約条件に落とし込む ・評価軸の設計 ― 修正を「削除・修正・追加」×修正負荷（高・中・低）で分類する分析プロンプト自体を薬剤師が設計。 ・優先順位の設計 ― 「①事実性 ＞ ②分類境界 ＞ ③網羅性 ＞ ④文体」。S/P混同が起きたら事実性を優先してSを空にする、という 判断は薬剤師にしかできない ・境界例の記述 ― 「熱はないですか」→「はい」は肯定か否定か曖昧なので不採用 ― 現場の失敗から帰納したルールを薬剤師が直接 記述 © KAKEHASHI Inc. All Rights Reserved. 18
19. 4. 開発サイクルへの組み込み方 Sフィールドの禁止表現 初期はほぼ存在しなかった禁止リストが、現在は具体的なルール群に Before：曖昧な指示 「患者の主観情報を書く」とだけ記載。何を書いてはいけ ないかが不明確なまま。 After：具体的な禁止ルール 「〜と述べている」「回答した」「了承している」「質問はな い」「不安はない」等の表現を明示的に禁止。正規表現でカ ットするなどの対策。 すべて「現場の薬剤師が実際に違和感を覚えた表現」をドメインエキスパートが言語化し、プロンプトと正規表現ルール に落とし込んだ結果。 © KAKEHASHI Inc. All Rights Reserved. 19
20. 4. 開発サイクルへの組み込み方 【2】品質評価 ― Human-in-the-loopの設計 評価するだけでなく、「評価軸の設計」そのものを担う LLMが出力した薬歴草稿をドメインエキスパートが評価するパイプラインを構築。 「採用したくなる薬歴の定義書」も共同作成し、評価基準を言語化した。 評価事例をLLM as a Judgeに活用 ― 薬剤師の判断をスケールさせる仕組み ただし、現状ではリリース前にドメインエキスパートの評価は必ず組み込んでいる © KAKEHASHI Inc. All Rights Reserved. 20
21. 4. 開発サイクルへの組み込み方 • 実例：薬歴評価プロンプトの5つの評価軸（ドメインエキスパート主導で設計） ◦ 1. SOAP+OPの構造が正しく使われているか ◦ 2. 文章が簡潔でわかりやすいか ◦ 3. 記載に「個別性」があるか（← 特にドメイン知識が必要な軸） ◦ 4. 内容が具体的に書かれているか ◦ 5. 薬歴全体として内容に矛盾がないか • 「個別性」＝一般論ではなく“この患者だけの情報”が書かれているか ◦ エンジニアだけでは定義できない、薬剤師の実務経験から生まれた基準。 © KAKEHASHI Inc. All Rights Reserved. 21
22. 4. 開発サイクルへの組み込み方 【3】VOCの言語化 ― 現場の声を開発インプットに 現場薬剤師の声を、開発が動ける問題定義に翻訳する 薬局現場からのフィードバックをドメインエキスパートが受け取り、開発チームが理解できる言語に変換す る。 実例：「薬歴が長すぎる」というVOC 複数店舗から「長すぎる」の声。エンジニアが見ると文字数は適切範囲内で原因不明。分析の結果「Sに患者の雑談まで入っ ている。服薬指導に無関係な発言の除外ルールが必要」と特定 → プロンプト修正で解決。 現場の「なんかおかしい」をissueに変換できるのはドメインエキスパートだけ © KAKEHASHI Inc. All Rights Reserved. 22
23. 4. 開発サイクルへの組み込み方 座組みの全体像 ― 三者が同じ開発サイクルの中で動く ドメイン エキスパー ト エンジニア PdM / PMM システムの品質 出力の品質 事業の品質 モデル選定・システム設計・評価パイ プロンプト設計・品質評価・VOC言 ロードマップ策定・顧客コミュニケー プラインの構築を担う。 語化を担う。 ションを担う。 © KAKEHASHI Inc. All Rights Reserved. 三者が同じ開発サイクルの中で役割分担して動く構造 23
24. 5 工夫・学び © KAKEHASHI Inc. All Rights Reserved. 24
25. 5. 工夫・学び • ドメインエキスパートを「レビュアー」ではなく「設計者」として位置づけた ◦ レビュー依頼ではなく、プロンプト・評価軸の設計そのものを担ってもらう • 「良い薬歴の定義書」を最初に共同作業でやりきった ◦ プロンプト・評価・VOC対応、すべての基準になった • 週次の品質レビュー会で、全員が同じ数字を見る ◦ 採用率・利用率・差分分析結果を、エンジニアとドメインエキスパートが一緒に見る習慣 © KAKEHASHI Inc. All Rights Reserved. 25
26. 5. 工夫・学び • 最初は依頼が「なんとなくこれ見てください」になっていた ◦ 評価観点を明示してから、レビューの質が劇的に上がった • 「薬剤師が使いやすい」設計 ◦ 正確でも読みにくい薬歴は採用されない。気づくのに時間がかかった • ドメイン知識をプロンプトに全部詰め込むと破綻する ◦ この失敗から、ユースケース別・フィールド別の階層化設計に至った © KAKEHASHI Inc. All Rights Reserved. 26
27. 6 まとめ © KAKEHASHI Inc. All Rights Reserved. 27
28. 6. まとめ • LLMプロダクトの品質は、モデルの性能だけでは決まらない ◦ ドメイン知識を開発プロセスに組み込む「設計」が品質の鍵 • ドメインエキスパートは「レビューア」ではなく「開発サイクルの一員」 ◦ プロンプト構築・品質評価・VOC言語化 ― 3つの関与ポイントで機能させる • 「文脈の壁」は、翻訳者を置くことで超えられる ◦ あなたのチームに「文脈の壁」はありませんか？ どの関与ポイントから始めますか？ © KAKEHASHI Inc. All Rights Reserved. 28
29. 「現場の正解を知っている人と一緒に創る」 © KAKEHASHI Inc. All Rights Reserved.
30. ご清聴ありがとうございました。 株式会社カケハシ 〒105-0003 東京都港区西新橋二丁目8番6号 住友不動産日比谷ビル5階 URL : www.kakehashi.life お問い合わせ先 h.fujimura@kakehashi.life 担当：藤村 © KAKEHASHI Inc. All Rights Reserved.