Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ドメインエキスパートは いかにして AI を使って プロダクト開発をするか

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers. →
Avatar for tshiraishi tshiraishi
October 26, 2026

ドメインエキスパートは いかにして AI を使って プロダクト開発をするか

「巨大産業で新たなプロダクトを“つくれる人”は、AIでどこまで広がるか」
https://enechain.connpass.com/event/406517/
の登壇資料です。

Avatar for tshiraishi

tshiraishi

October 26, 2026

Other Decks in Technology

Transcript

  1. 自己紹介 白石 達也 Ubie株式会社 ドメインエキスパート医師 〜2019 2019〜2021 2021〜2024 2024.10〜2025 2026〜現在

    病院勤務医 Ubie 入社。「AI 問診」の医学データを設計する PO として toC 医療メディア立ち上げ、300 万 MAU に 病院向け生成 AI の探索と DPC 提案ツールの原型 DPC 提案ツールの開発と精度改善
  2. ドメインエキスパートとして事業を考える 例: 医療メディア事業 ドメインエキスパートあるある 詳しく書こうとしすぎる 専門的で難しい 目的に合わない内容になる 時間がかかる = コスト

    PO として求められる 生成 AI と GAS で仕組み化する 速さ コスト 骨組みと言葉遣いを、 たたきとレビューで考える → AI が、わかりやすく読める わかりやすさ AI が記事を採点するシート(イメージ) 同僚が GAS と AI を使っていたので、 それを参考にできた
  3. DPC = 主な病名で入院料が決まる制度 まとめて決まる(包括) 1 日あたりの点数 病名ごとに 1 日いくら 期間

    I 期間 II 入院の基本料金・薬・検査などは、区分ごと に決まった1 日あたりの点数で払われる 期間 III 以降は出来高 入院日数 つまり どの区分を選ぶかで、入院 1 件の請求額が決まる 別に足す(出来高) 手術・処置などは加算 手術・麻酔・リハビリなどは、行った分をそ のまま足す
  4. 約 3,300 のコードから 1 つ選ぶには、診療記録を読み込む 040080 主な病名 x0 99 x

    0 x x 入院 1 件ごとに、 約 3,300 から 1 つ 年齢など 手術 処置1 処置2 副傷病 重症度 例: 同じ胆石による炎症でも、胆嚢炎なら 060335、胆管炎なら 060340 と区分が変わる レセプト 診療記録 何をしたか(処置・手術・薬) + なぜしたか・経過・どの病気が中心か 医師 医事 レセプト △ 請求のルールはわからない ◦ レセプトから考える力が強い → 両方をちゃんとできる人は稀 診療記録 → ◦ 診療の中身がわかる △ 難しい。長いと 100 万文字 DPC の 区分
  5. 医事課のドメインエキスパートがいればベストだが 都合よくは獲得できない → 医師職が、次の 3 つを活用して仲立ちする 公的資料 厚労省のルールを 探して読み込む 現場

    観察・ヒアリングと 実際の請求コード ドメインの中での越境が求められることも 業務委託 医療事務の専門家に 聞ける
  6. 医師と医事の判断をそのまま AI の処理の流れにした きっかけ SNS で structured output を知り、選択肢から 1

    つ選ぶ DPC コーディングに使えると思った AI の処理の流れ(Colab で作った原型) AI AI × 医学 AI × ルール AI × 医学 AI × 医学 ルール → → → → → カルテ要約 主病名 ICD-10 手術・処置 副傷病 DPC コード もともとの専門: 医学 広げた: DPC の決まり(医療事務の専門家に教わる)
  7. 初期検証ができることと安定稼働は別物、土台はエンジニアに 当時の作り 完了 完了 エラー 未処理 未処理 未処理 1 件のエラーで全体が止まる

    あるべき作り 完了 完了 記録 完了 完了 完了 さらに PR をたくさん出して、シニアにレビューの負担をかけていた 振り返ると 土台を担うエンジニアに、もっと早く入ってもらえばよかった その 1 件を記録して残りは進む
  8. ドメインが関わるプロダクトの精度に集中 例: 同じ入院に胆嚢炎と胆管の結石・胆管炎の両方。どちらを主にするかで区分が変わる 材料を重ねて決める 決めたルール 国の決まり どちらが主か書かれていない 決まらない 胆管に内視鏡で処置 +

    同じ入院で胆嚢を摘出 カルテ 医師がどちらを中心に診ていたか 寄る 胆嚢に外から管を入れる → レセプトの処置 入院中にどの処置・手術をしたか 補う 両方ある 他の病院の統計 同じ処置でどちらを請求したか 裏付ける → 胆管炎へ → 切り替えない → 胆嚢炎へ → 機械では決めない 複数病院のデータで測ると 正しくなる 96% 誤りになる 4% 集中すること 暗黙の判断を言葉とロジックに落とし、その落とし込みを繰り返し回せるスキルにする
  9. もらった指摘からレビュースキルに 「想定外の値が来たら止まらずに進みま 想定漏れ せんか?」 対症療法 「データの出どころで直すべきでは?」 制約不足 「値は数種類なので型で縛りましょう」 ↓ 163

    本の PR についた指摘から考え方をまとめてス キルにし、PR を出す前に AI が同じ観点で確かめる (7/7〜) 出来上がったスキル dpc-sim-basic-review 材料: シニアの指摘(163 PR)+ リポジトリの開発ルール 間違った使い方ができな 直すべき層・責務はどこ 防 い設計か 所 か 使われていないコードは 名前が概念を正しく表す 廃 ないか 名 か 値の範囲を型で縛ってい 実データで動くと確かめ 型 るか 検 たか その実装の「なぜ」を言 秘 患者データを外に出さな 問 いか えるか 機械検査で候補を集める → AI が 8 観点で判断 → 出す前に指摘 を疑い直す 周りの助け シニアが毎回ていねいにくれた指摘そのものが教材になった
  10. 土台は任せて 2 か月で精度改善に集中 精度改善の PR 59 本 請求額が高すぎる誤った区分を 1 位に出す症例

    いま(10/20) 直す前(9/18) 4.5% → 22 件 直したいことごとに PR を積み重ねて並行に進める(gh stack) 自分 医学+医事の ロジック エンジニア 土台・インフラ 492 症例中 0.6% 3件 何を誤りとし、何を許容範囲とするかは、自分で線を引いた 医師と医事の知識を学んでロジックを作っていたので、ロジック改善も回しやすい
  11. PRレビューによりシニアの負担も軽減 PR 数(週あたり) 7.6 約 2.1 倍 3.6 → PR

    1 本あたりの指摘数 0.11 −79% 0.52 → 7/7 スキル作成 PR 数/月 17 27 21 19 33 29 28 31 3 4 0 0.24 0.14 0 0 0.11 0.06 1.58 指摘数/PR 0.59 0.26 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月
  12. ドメインエキスパートが work するには 1 事業 2 ドメイン 3 作り方 前提

    事業に責任を持つ役を担い、 専門家として正しいことと、事業として求められることのズレに気づく 隣の領域まで学んで跨ぎ、何が正解かを決めて、 言葉と AI のロジックにする 初動は AI で作り、土台はエンジニアと組む。 もらった指摘はスキルにする 許される範囲で、誰でも開発に踏み込める仕組みを作る 例: 誰でも PR を出せて、AI を安全に使える