【Data Engineering Summit2026_登壇資料】医療ビッグデータ×AIエージェントを支えるデータ基盤とハーネスエンジニアリング

2026年10月9日（金）に登壇したData Engineering Summit2026の発表資料です。

Transcript

1. 医療ビッグデータ×AIエージェントを支える データ基盤とハーネスエンジニアリング 株式会社JMDC 2026年10月9日
2. 登壇者 © JMDC Inc. 加納 真 瀬川 雄太 北野 道春 執行役員 データイノベーション部 AIエンジニアリンググループ AIエンジニア データイノベーション部 データサイエンティスト/ AIエンジニアリンググループマネージャー 2
3. 株式会社JMDC Vision 健康で豊かな人生をすべての人に Mission データ と ICT の力で 持続可能なヘルスケアシステムを実現する 事業内容 医療データベースの構築と PHR等の健康増進サービス提供 © JMDC Inc. 3
4. JMDCの保有する医療データ資産 保険者由来 レセプトデータ 3,000万人超 病院由来 DPC/電子カルテ 5,000万人超 PHR 発行ID数 800万人超 病名/薬剤/検査等の 患者ジャーニーを捕捉 検査結果等 患者の状態を詳細把握 ウェアラブルとも連携、 患者への介入も可能 国内の医療実態のリアルを患者単位で把握可能 © JMDC Inc. 4
5. 提供価値ごとに区分されたJMDC医療データの処理区画 JMDCでは同じヘルスケアデータでも用途ごとに残す情報を変える形で、 複数系統のデータ加工区分と処理区画を整備 出所 元データ 健康 保険組合 レセプト 加工区分 主な提供価値 仮名化データ 高リスク者への 受診勧奨 健診結果 病院 診療所 製薬マーケティング支援 保険商品設計支援 電子カルテ PHR (Pep Up) ウェアラブル 匿名加工情報 官公庁/アカデミアへの データ提供・研究支援 … © JMDC Inc. 5
6. 直面していた課題 エンジニアへの集計依頼待ちで仮説検証が回りづらい 分析用途やデータ種類拡大にツール開発が追い付かない 労働集約的な抽出エンジニアの稼働高止まり © JMDC Inc. 6
7. AIエージェントによる解決の方向性 専門スキル不要で自然言語で即座に分析と示唆出し 分析用途やデータ種類の拡大に柔軟に対応 膨大な実績に基づく継続的改善ループの実現 © JMDC Inc. 7
8. 医療データ分析AIエージェント ログ・フィードバック ①質問 ユーザ （社内） ナレッジベース AIエージェント ④回答 関連部門社員 の約7割が日々利用 © JMDC Inc. ②知識を 検索 ③分析を 実行 データ基盤 評価・改善提案 8
9. JMDCにおける AIエージェントとデータ基盤 © JMDC Inc. 9
10. レイクハウスの技術スタック AWS環境にセルフホストdbtとAthenaを中心としたレイクハウスを構築 データ保管 S3 モデリング dbt クエリエンジン Iceberg © JMDC Inc. Athena Athena for Spark BI Lightdash データナレッジ Bedrock Knowledge base 10
11. dbtコミュニティでの活動 dbtの活用に全社で力を入れており、コミュニティへの貢献も進めている dbt Technical Contributor of the Year 受賞 谷脇 大輔（JMDC） @dtaniwaki © JMDC Inc. 11
12. データモデリングの層別化とレシピ 案件ごとに条件が変わる実務に合わせて、データモデルだけでなく 「レシピ」テンプレートを柔軟に活用 © JMDC Inc. 概念レイヤー 役割 データ モデル 案件共通の 事業データモデル Semantic レイヤー 事前定義した集計表を 様々な切り口で見せる レシピ 案件ごとにパラメタだけ 変えられる抽出定義 12
13. レシピの活用例 期間/疾病/薬剤/処置等の条件の組み合わせ次第で多数あり得るmartsを 都度作らず「組み合わせ方」を定義してdbt内にリネージ管理 加入者 台帳 レセ プト 健診 ✕ あり得るmartsの 組み合わせが多い 期間 × 患者 mart 疾病xxの診断と 薬剤xxが同時に処方 新規で疾病xx診断かつ BMIがxxx以上 … © JMDC Inc. ある期間中に疾病xxと 診断された患者 <dbt_project>/analyses/recipes/ 患者数の集計レシピ.sql ref {%- set diseases = […] %} {%- set drugs = […] %} {%- set procedures = […] %} {%- set ym_from_to = […] %} ---期間×条件を満たした母集団の抽出 WITH cohort AS ({{ cohort(…) }} ) ---ビジネス向け集計出力 SELECT … GROUP BY … ORDER BY … ✓ レシピには「組み合わせ方」を定義 ✓ 実行時にcompileしてクエリに変換 ✓ dbt管理下のため関係が追いやすい 13
14. データガバナンス向上の工夫 データやナレッジの変更は、自動テストや専門家レビューなどの仕組み を通ってから、段階的に利用者とエージェントに届く仕組み dbt モデル CI/CD ・レビュー • データ知見のある基盤チーム がモデリングし、自動テスト やピアレビュー スキーマ定義 / レシピ 専門家 レビュー • 各事業部からユースケースの 専門家を集めてレビュー データもナレッジも環境を分離す るブランチ戦略を取り、ユーザー やエージェントに見せる本番反映 タイミングをコントロール © JMDC Inc. エージェントが認識可能な Glueデータベース エージェントが検索可能な ナレッジベース 14
15. エージェント活用に向けたハーネスエンジニアリング レビューを通って反映された最新レシピやナレッジを検索しクエリ実行 する共通ツール群を用意し、分析品質安定と継続改善ループを実現 Bedrock AgentCore Slack Runtime Strands Agent Gateway レシピ/スキーマ 定義等の検索 クエリ実行 / 中間テーブル作成 MCP Client 品質 安定 定型分析は レシピで完結 精度 向上 専門家ノウハ ウを踏まえた 実用的な分析 改善 高速化 分析ノウハウ をAI自らdraft PRを起票 レシピの コンパイル ナレッジ追加提案 © JMDC Inc. ハーネス効果 15
16. ナレッジ収集と評価 © JMDC Inc. 16
17. 分析エージェントの全体像(再掲) 継続的な改善が重要！！ ①質問 ユーザ （社内） ナレッジベース AIエージェント ④回答 © JMDC Inc. ②知識を 検索 ③分析を 実行 データ基盤 17
18. ナレッジを集める仕組み①：Field Note ナレッジを「集める層」と「整理する層」に分離し、集めてから昇格させる 改善コスト ナレッジを 集める層 Field Note（mdファイル） カラム定義 カバレッジ 品質管理 小 × 大 ◦ レビューを経て昇格 ナレッジを 整理する層 © JMDC Inc. データモデル レシピ 18
19. ナレッジを集める仕組み①：Field Noteの実例 集める層はただのmdファイル、レビューを通してmetric等へ昇格 実例 ナレッジを 集める層 Field Note（mdファイル） カラム定義 総医療費は (医科レセと調剤レセの合計点数)×10円 除外条件は・・・ レビューを経て昇格 ナレッジを 整理する層 © JMDC Inc. データモデル レシピ • • レセプト種別を統合したfact 「総医療費」をmetricとして定義 19
20. ナレッジレイヤーごとのユースケース ユーザ側で品質管理できるユースケースであれば、Field Noteのみでも活用可能 ユースケース Field Note（mdファイル） カラム定義 社内アナリストによる分析業務 誤りはユーザ自身が修正可能 レビューを経て昇格 データモデル レシピ © JMDC Inc. 顧客提供サービス 品質管理の仕組みが必要 20
21. ナレッジを集める仕組み②：PR起票スキル PR/Issueの起票スキルを配ることで非エンジニアでもPR起票が可能に。 エージェント起点で暗黙的に起票させることも可能。 …を除外する必要がある 人起点 ナレッジに追加しといて 非エンジニア エージェント 起点 規約に整えてPR起票 エージェント 次は間違えないようナ レッジを修正しよう この集計は誤りで、 非エンジニア 正しくは… エージェント →規約に整えてPR起票 規約対応はスキル側が担うため気軽に起票でき、専門家の承認を経て本番反映される（不要なら気軽にクローズ） © JMDC Inc. 21
22. 評価①：評価パイプライン Strands Evals SDKでE2Eな精度評価を実施 GitHub Actions SQS EventBridge Pipes ケース選択 1ケース1通 → Fargate起動 eval-worker（Fargateコンテナ） © JMDC Inc. ケース 分析エージェント Input 分析定義書＋ expected 正解 Inputのみ渡して実行 （正解は見せない） 採点 Strands Evals SDK built-in evaluator ＋LLM judge 評価シート 22
23. 評価②：評価シート 利用部門との対話ツールとして評価シートを作成し、エージェントの精度とカバレッジを 可視化 ① 利用部門にてケースを選定 ② 評価パイプラインで評価 ③ 改善 精度・速度・コストを算出 誤答はナレッジの修正へ 過去案件の定義書と納品物から 重要なケースを選び 重要度・目標水準を記入 © JMDC Inc. 23
24. ガバナンスとガードレール エージェントの権限をツールで制約し、入力の検査も実施 プロンプト攻撃の検査 外部コンテンツの検査 監査ログ すべてのモデル呼び出しに 外部サイトから取得した本文は、 ツール実行と発行SQLを Bedrock Guardrailを適用し、 文脈に入れる前に検査し、 すべて記録し、回答の根拠を 攻撃的な入力を遮断する 問題があれば破棄する 後から追跡できる 実行の制約と変更レビューは前章のとおり、本章の検査・監査と合わせてAIを安心して使える状態に保つ © JMDC Inc. 24
25. FBループを回すTips①：改善される基盤だと認識してもらう 素早い対応と巡回でその場の改善を見せ、使えば良くなる基盤だと認識してもらう © JMDC Inc. その日のうちに返す 巡回してその場で直す 改善の推移を見せる 対応可能な誤答報告は 当日中に修正・再回答 FBを待たず利用スレッドを 巡回し、失敗を見つけて直す アップデート案内等で 良くなっていく過程を共有 25
26. FBループを回すTips②：用語・定義書は業務側にも直してもらう 曖昧な用語はシステム側で吸収するより、 業務側に働きかけて用語自体を変えてもらう方が効率的 課題 曖昧・不統一な用語を辞書（ナレッジ）側で吸収し続けると、混乱が固定化する 実例 同じDBを部門ごとに別の名前で呼んでいたため、正式名称を定義し業務側の呼び方も 統一 方針 依頼文・定義書の用語もAIが解釈できる語彙へ寄せる（辞書を作る方向と業務の言葉を 直す方向の両方） © JMDC Inc. 26
27. FBループを回すTips③：最初のユーザは一番の熟練者 最初に使ってもらう相手は新人ではなく、その業務の一番の熟練者がよい 理由① 熟練者は誤りに気づけるため、安心して任せられて検証も速い （熟練者ほどAIエージェントの評価も高い傾向） 理由② 質の高い誤答検知（FB）をくれるので、改善ループの立ち上がりが速い 裏返し 新人が最初だと誤答を見抜けず、そのまま流れるリスクがある © JMDC Inc. 27
28. 最後に：AIエージェントがもたらすフライホイール効果 ユーザーと問いが 拡がり続ける AIエージェント データ基盤の拡充を 即、フル活用できる © JMDC Inc. ナレッジの蓄積が 複利で効いていく 28
29. ご清聴ありがとうございました データエンジニア／ データプロダクトエンジニア 募集中 会場・懇親会で声をかけてください！ データエンジニア データプロダクトエンジニア hrmos.co/pages/jmdc/jobs/be-00032（データエンジニア）／ds-00010（データプロダクトエンジニア） © JMDC Inc. 29