イントロダクション：構造化データの限界と「見えない患者」の課題
「もっとデータがあれば、患者さんは見つかるはずだ」
製薬業界のマーケティング担当者やDX推進リーダーの間で、この言葉は頻繁に聞かれます。多くの組織が、高額なレセプトデータベース（診療報酬明細書データ）を導入し、ICD-10コード（国際疾病分類）の分析に注力しています。
しかし、AI開発の最前線から見ると、あえて厳しい現実を指摘せざるを得ません。希少疾患において、レセプトデータだけを見ていても、本当に救うべき患者さんにはたどり着くことは困難です。
なぜなら、レセプトに記載される病名は「結果」であって、診断に至るまでの苦悩に満ちた「プロセス」ではないからです。希少疾患の患者さんの多くは、確定診断がつかずに複数の診療科をたらい回しにされる「診断オデッセイ（診断の旅）」の渦中にいます。そこにはまだ、正しいICD-10コードは付与されていません。
では、彼らのシグナルはどこにあるのでしょうか？ それは、電子カルテの自由記述欄、看護記録、あるいは画像診断レポートといった「非構造化データ」の中に埋もれています。
なぜ希少疾患患者はデータから漏れるのか
構造化データ（数値やコード化されたデータ）は、扱いやすく分析も容易です。しかし、そこには「医師の迷い」や「非特異的な症状の羅列」は記録されにくいという側面があります。例えば、「原因不明の全身倦怠感」や「非典型的な皮疹」といった記述は、特定の病名コードに変換される過程で情報量が圧縮され、切り捨てられてしまいます。
先進的な医療AIプロジェクトの事例を見ても、成功の鍵は常に「活用されてこなかったテキストデータ」の中にあります。日本の製薬業界においても、DX（デジタルトランスフォーメーション）の本丸は、この非構造化データの活用にあると言えます。
今回のエキスパート紹介
今回、この複雑なテーマについて解説するのは、株式会社テクノデジタル 代表取締役であり、AIエージェント開発・研究者として最前線に立つHARITA氏です。
HARITA
株式会社テクノデジタル 代表取締役 / AIエージェント開発・研究者。35年以上の開発キャリアを持ち、AIエージェント開発、高速プロトタイピング、AIモデル比較・研究、業務システム設計を専門としています。「まず動くものを作る」というプロトタイプ思考を軸に、ReplitやGitHub Copilot等のツールを駆使して仮説を即座に検証。経営者視点とエンジニア視点を融合させ、技術の本質を見抜いてビジネスへの最短距離を描く「実装できるAI戦略」の提唱者です。
本記事では、単なる技術解説ではなく、組織内で企画を立案し、実際にプロジェクトを推進するための「判断基準」を、HARITA氏との対話形式で深掘りしていきます。
Q1：なぜ今、「非構造化データ」が希少疾患特定の鍵となるのか？
── HARITAさん、多くの組織がレセプトデータの分析に力を入れていますが、なぜそれだけでは不十分なのでしょうか？
HARITA： まず、「データを見ている」という安心感が一番の敵かもしれませんね。レセプトデータは確かに有用ですが、それはあくまで「保険請求のために整理された情報」です。そこにはバイアスがかかっています。
希少疾患の場合、確定診断がつくまでに平均して数年、場合によっては10年以上かかると言われています。この長い期間、患者さんは「不定愁訴（ふていしゅうそ）」と呼ばれる、原因のはっきりしない症状を抱えています。
構造化データの世界では、これらは「その他」や一般的な症状コード（例：R53 倦怠感）として処理されます。これでは、何千人もの「倦怠感のある患者」の中に、本当に希少疾患が疑われる1人が埋もれてしまう。これを見つけ出すのは、砂漠で特定の砂粒を探すようなものです。
一方、非構造化データである電子カルテのテキストには、医師の「思考の痕跡」が残っています。「〇〇病の疑いもあるが、症状Aが非典型的」「家族歴に××あり」といった記述です。これこそが、早期発見のためのゴールデン・ナゲット（金の塊）なんです。
構造化データ vs 非構造化データ：情報の質の比較
── なるほど。情報の「解像度」が違うということですね。
HARITA： その通りです。わかりやすく比較してみましょう。
構造化データ（レセプト等）：
- 形式：数値、カテゴリ、フラグ
- 特徴：集計・統計が容易。しかし、文脈が欠落している。
- 希少疾患での限界：確定診断前の「予兆」を捉えられない。
非構造化データ（カルテ自由記述、レポート等）：
- 形式：自然言語テキスト、画像（検査画像等）
- 特徴：文脈、時系列の変化、医師の主観が含まれる。
- 希少疾患での価値：症状の組み合わせや、否定された診断の履歴から、隠れたパターンを検出できる。
これまで、この非構造化データは「解析不能なダークデータ」として扱われてきました。人間が全部読むには量が多すぎるからです。しかし、近年のLLM（大規模言語モデル）の飛躍的な進化と、マルチモーダルAIの台頭によって状況は劇的に変わりました。
最新のAIモデルは、単語の出現頻度だけでなく、数万トークンに及ぶ長大な文脈を保持し、複雑な因果関係まで理解できるようになっています。さらに、テキストだけでなく画像や音声データも統合して解析するマルチモーダル化も進んでおり、「解析不能」だったデータが「宝の山」へと変わったのです。
医師の「違和感」をAIで言語化する
── 技術の進化がコストに見合うレベルになったということでしょうか？
HARITA： ええ。以前ならスーパーコンピュータが必要だったような解析が、今はより身近になっています。クラウド上のAPI利用はもちろん、セキュリティ要件の厳しい医療現場向けには、オンプレミス環境で動作する高性能な日本語特化モデルや軽量モデルも選択肢に入ってきました。
また、モデル自体をゼロから作るのではなく、既存のLLMに対して問いかけを工夫する（プロンプトエンジニアリング）だけで解析精度を向上させる手法も確立されつつあります。大規模な追加学習コストをかけずに、プロトタイプを素早く構築して実務レベルの成果が出せるようになってきた点は見逃せません。
重要なのは、AIに「診断」をさせることではありません。それは医師の仕事です。AIの役割は、医師がカルテを書くときに感じた、しかし忙しさの中で見過ごしてしまった「微細な違和感」を再発見し、ハイライトすることです。
例えば、「若年での白内障」と「原因不明の腎機能低下」が、別々の診療科のカルテに書かれていたとします。人間はこれらを結びつけるのが苦手ですが、AIエージェントなら「ファブリー病の可能性」としてフラグを立てることができる。これが、非構造化データ解析の真骨頂です。
Q2：導入検討の最大の壁「プライバシーと精度」をどう評価するか
── 非常に可能性を感じますが、実務担当者が一番頭を抱えるのが「個人情報保護」です。カルテの自由記述は個人情報の塊ですよね。
HARITA： おっしゃる通りです。ここが最大のボトルネックであり、多くのプロジェクトがPoC（概念実証）止まりになる原因でもあります。AIプロジェクトを成功させる鉄則として、「技術の前に、ガバナンスを設計せよ」という点が挙げられます。
自由記述の中には、患者さんの名前だけでなく、「〇〇商事に勤めている」「娘の結婚式が近い」といった、高度なプライバシー情報が含まれる可能性があります。これをそのままAIに食わせることは、倫理的にも法的にもNGです。
個人情報保護と解析精度のトレードオフ
── 具体的にどう対策すればよいのでしょうか？
HARITA： アプローチは大きく分けて2つあります。
匿名化（De-identification）技術の活用：
テキストデータから個人特定につながる固有表現（人名、地名、病院名、日付など）を自動で検出し、マスキングあるいは置換する技術です。最近のAIは文脈を読んで、「田中さん」が患者なのか医師なのかまで判別してマスキングできます。
ただし、ここでトレードオフが発生します。マスキングを厳しくしすぎると、「臨床的に重要な情報」まで消してしまうリスクがあるのです。例えば、希少疾患では「特定の地域出身」や「年齢」が重要な手がかりになることがありますが、これらをすべて隠すとAIの検出精度は下がります。フェデレーテッドラーニング（連合学習）などの分散学習技術：
データを一箇所（クラウドなど）に集めるのではなく、各病院のサーバー内でAIモデルを学習させ、学習した「重み（パラメータ）」だけを中央に集約する方法です。これなら生データは病院の外に出ないので、プライバシーリスクを劇的に下げられます。
匿名化技術の最新トレンドと法的リスクの評価
── 日本の法規制、特に次世代医療基盤法などとの兼ね合いはどう考えればいいですか？
HARITA： 日本は世界的に見てもユニークな規制環境にあります。次世代医療基盤法認定の事業者を介することで、「匿名加工情報」としてデータを扱えるスキームがありますが、希少疾患の場合はN数（患者数）が少なすぎて、匿名加工するとデータとしての価値が失われる（特異値が丸められてしまう）というジレンマがあります。
実務の現場で推奨される現実的なアプローチは、「院内設置型（オンプレミスまたはプライベートクラウド）での解析」です。
外部組織がデータを受け取るのではなく、解析アルゴリズムを病院側に提供し、病院内で解析を実行してもらう。そして、結果として出力される「統計情報」や「匿名化されたシグナル」だけを受け取る、あるいは医師に直接通知する仕組みです。
これなら、個人情報保護法のリスクを最小限に抑えつつ、生の非構造化データの豊かさを活かした解析が可能になります。もちろん、病院側のIT部門との綿密な連携が必要ですが、コンプライアンス部門を説得するには最も論理的なルートです。
Q3：AIモデル選定の落とし穴：汎用LLMと特化型モデルの比較
── 最近はChatGPTなどの生成AI（LLM）が話題です。「ChatGPTにカルテを読ませればいいのでは？」という意見も現場で出ますが。
HARITA： ははは、よく聞く話ですね。確かにChatGPTに搭載されているモデルは飛躍的に進化しており、一般的な健康相談などでは高い性能を示します。しかし、それをそのまま専門的な「希少疾患のカルテ解析」に使うのは、「危険な賭け」であると断言します。
汎用的なLLM（大規模言語モデル）は、流暢な自然言語を操りますが、専門性の高い医療領域に関しては依然として「自信満々に嘘をつく」リスクを孕んでいます。これがいわゆるハルシネーション（幻覚）です。特に学習データが極端に少ない希少疾患の領域では、いくら最新の強力なモデルであっても、この傾向を完全に排除することは困難です。
さらに、コストとガバナンスの問題も無視できません。何万件もの機微なカルテデータをAPI経由で外部のLLMに投げれば、トークン課金で莫大なコストがかかります。また、データレジデンシー（データの保管場所）やセキュリティポリシーの観点からも、安易な外部送信は推奨されるべきではありません。
ChatGPTなどの汎用モデルは使えるか
── では、どのようなアプローチをとるべきなのでしょうか？
HARITA： 2026年現在のベストプラクティスは、単一の万能モデルに頼るのではなく、「タスクの複雑度に応じたモデルの使い分け」と「AI間の連携設計」です。
例えばソフトウェア開発の現場では、GitHub CopilotのようなAIコーディングアシスタントが単なるコード補完にとどまらず、プロジェクト全体の文脈を理解して複雑なリファクタリングを支援するアプローチが一般的になりつつあります（具体的な機能やサポート状況の最新情報は、公式ドキュメントで確認することをお勧めします）。医療データ解析も同様に、汎用モデルと特化型モデルを組み合わせるワークフローが不可欠です。
特にChatGPTの基盤モデルは急速に世代交代が進んでいます。2026年の最新バージョンであるGPT-5.2（InstantおよびThinking）は、長い文脈の理解力や汎用知能が大幅に向上しています。一方で、GPT-4oなどの旧モデルは2026年2月13日をもって廃止されました。
このようにモデルのライフサイクルが短いため、旧モデルに依存したシステムは早急にGPT-5.2系などへの移行ステップを踏む必要があります。APIの向き先を変更するだけでなく、プロンプトの応答特性の変化に合わせた出力の構造化テストや、精度検証の再実施が求められます。
| タスク | 推奨モデル | 理由 |
|---|---|---|
| 一般的な要約・翻訳 | 汎用LLM（GPT-5.2 Instantなど） | 長い文脈理解力が高く、自然な文章生成や要約が得意 |
| 複雑な推論・分析 | 推論強化モデル（GPT-5.2 Thinkingなど） | 段階的な思考（Chain of Thought）により論理的整合性を担保 |
| 希少疾患の兆候抽出 | ドメイン特化型モデル (SLM) | 専門用語の理解度が深く、誤検知が少ない。オンプレミス運用も容易 |
| データ匿名化処理 | 特化型ルールベース/軽量モデル | 高速処理と確実性が求められるため |
最終的な答えは「ドメイン特化型モデル（Domain-Specific Model）」の活用にあります。
医療用語、特に希少疾患に関連する専門用語や略語を大量に学習させた、比較的小規模なモデル（SLM: Small Language Models）の方が、特定のタスクにおいては精度もコストパフォーマンスも高いケースが多いのです。
例えば、BERTベースの医療用モデルをファインチューニング（微調整）して、「特定の疾患の兆候抽出」に特化させるアプローチです。これなら、オンプレミスのサーバーでも十分に高速に動作しますし、推論の根拠も追いやすいという明確なメリットがあります。
疾患特有の語彙（オントロジー）理解の重要性
── 「言葉の定義」をAIに教え込む必要があるわけですね。
HARITA： その通りです。これを「オントロジー（概念体系）の構築」と呼びます。最新のAI活用では、単にモデルを学習させるだけでなく、RAG（検索拡張生成）やナレッジグラフと組み合わせる手法が主流になりつつあります。
例えば、「歩行障害」という言葉一つとっても、それが神経由来なのか、筋骨格由来なのか、文脈によって意味が異なります。希少疾患特有の症状表現、例えば「アンダーソン・ファブリー病」における「被角血管腫」のような専門用語を、AIが正しく認識し、類義語も含めて拾えるように辞書や知識グラフを整備する。
泥臭い作業ですが、ここをサボって「魔法のAI」に頼ろうとすると、プロジェクトは高い確率で頓挫します。「最新のGPT-5.2などの汎用モデルで80点は取れるが、残りの20点（希少疾患の特定に必要な精度）を埋めるには、特化型モデルと専門知識が必要」。これが医療AI開発における現実なのです。
Q4：成功事例はここが違う。組織横断的なプロジェクト設計
── 技術的な課題をクリアしたとして、最後に待っているのが「運用」の壁です。AIが候補者を見つけても、医師が動いてくれなければ意味がありません。
HARITA： そこが一番の難所であり、成功の分かれ道です。これは一般に「ラストワンマイル問題」と呼ばれます。
AIが「この患者さんは〇〇病の疑いがあります」とアラートを出したとき、医師はどう感じるでしょうか？ 「AIに指図されたくない」「診断は私の領域だ」と反発する先生も少なくありません。また、突然外部の担当者がやってきて「AIがこう言ってます」なんて伝えたら、信頼関係が崩壊しかねません。
データ解析結果をどう医師へのアクション（啓発）に繋げるか
── 非常にデリケートな問題ですね。成功事例ではどのような工夫がされているのでしょうか？
HARITA： 成功事例の多くでは、「AIを黒子（くろこ）にする」という戦略がとられています。
AIの解析結果を直接突きつけるのではなく、院内の「希少疾患対策チーム」や「専門医」を通じて、自然な形で主治医にコンサルトが行くようなワークフローを構築しています。
あるいは、電子カルテシステムの中に、あくまで「診断支援ツール」としてポップアップを出す機能を組み込む（CDSS: Clinical Decision Support System）。ここでは「診断」ではなく、「鑑別疾患のリストアップ」として情報提供を行うのです。「先生、この症状の組み合わせだと、念のためこの検査も検討しませんか？」という控えめなサジェストです。
IT部門任せにしないマーケティング部門の関わり方
── マーケティング部門やメディカルアフェアーズ（MA）はどう関わるべきでしょうか？
HARITA： プロジェクトをIT部門任せにしてはいけません。IT部門はシステムを作ることはできますが、「医師の行動変容」を設計することはできません。
マーケティングやMAの方々は、KOL（キーオピニオンリーダー）との関係性を持っていますよね。彼らを巻き込んで、「AIによるスクリーニングの有用性」を医学的なエビデンスとして確立していく活動が必要です。
また、法務・コンプライアンス部門とも早期から連携し、「患者利益の最大化」という大義名分のもとで、リスクを許容できる範囲を合意形成しておくこと。これがプロジェクトリーダーに求められる最大のスキルです。技術の話よりも、この「組織間の連携とステークホルダーマネジメント」に時間の7割を使う覚悟で臨んでください。
編集後記：テクノロジーは「診断の旅」を終わらせるために
HARITA氏との対話を通じて見えてきたのは、非構造化データ活用という「魔法」の裏にある、極めて現実的で泥臭い課題の数々でした。
しかし、それでも私たちがこの技術に挑戦すべき理由は明確です。それは、データの海の中で助けを求めている「見えない患者」を見つけ出し、彼らの長く苦しい「診断の旅」を終わらせるためです。
レセプトデータという「街灯の下」を探すのはもうやめましょう。暗闇の中にこそ、光を当てるべき場所があります。プライバシー保護技術の進化と、特化型AIモデルの登場により、そのための懐中電灯はすでに手の中にあります。
あとは、その光をどう照らすか、その勇気と戦略を持つだけです。
検討段階から実行段階へ進むためのチェックリスト
最後に、本記事で議論したポイントを整理し、明日からのアクションに繋げるための簡易チェックリストを用意しました。
- 目的の明確化： ターゲットとする希少疾患の診断プロセスにおける「ボトルネック」はどこか？（認知不足？ 検査漏れ？ 症状の見落とし？）
- データアセスメント： 提携可能な医療機関に、解析に耐えうる質の電子カルテデータ（テキスト）が存在するか？
- リスク許容度の合意： コンプライアンス部門と、匿名化レベルやデータ持ち出しの可否について早期に協議できているか？
- モデル戦略： 汎用LLMではなく、疾患特化型のモデル開発やチューニングの予算・期間を見込んでいるか？
- ラストワンマイル設計： 解析結果が出た後、誰がどのように医師へフィードバックし、診断へ繋げるかのフローが決まっているか？
これらが全て「Yes」になった時、プロジェクトはPoCを超えて、真に患者さんの人生を変えるソリューションへと進化するでしょう。
コメント