logo

MedGemma Impact Challenge から感じるローカルLLMの可能性

March 28, 2026

この記事は、Claude で作成された原稿を手直して公開しています。

私自身や、協業者へのメッセージもそのまま記載しています。

MedGemma Impact Challenge

コンテストの概要

Google が Kaggle 上で開催した MedGemma Impact Challenge は、オープンウェイトの医療AI モデル群（MedGemma, HeAR, MedSigLIP 等）を活用して、実際に臨床で役立つプロトタイプを構築するコンテストです。賞金総額は10万ドル（約1,500万円）で、850以上のチームが参加し、2026年3月27日に受賞者が発表されました。

重要なのは、ベンチマークスコアの高さではなく、実世界での臨床的インパクトを審査基準にした点です。つまり「論文映えするAI」ではなく「現場で使えるAI」を評価したコンテストです。

MedGemma Impact Challenge 受賞全13プロジェクト解説

コンテストの概要

Google が Kaggle 上で開催した MedGemma Impact Challenge は、オープンウェイトの医療AI モデル群（MedGemma, HeAR, MedSigLIP 等）を活用して、実際に臨床で役立つプロトタイプを構築するコンテストです。賞金総額は10万ドル（約1,500万円）で、850以上のチームが参加し、2026年3月27日に受賞者が発表されました。

重要なのは、ベンチマークスコアの高さではなく、実世界での臨床的インパクトを審査基準にした点です。つまり「論文映えするAI」ではなく「現場で使えるAI」を評価したコンテストです。

🏆 Grand Prize（最優秀賞）4プロジェクト

① EpiCast — 西アフリカの感染症サーベイランス

西アフリカ諸国経済共同体（ECOWAS）地域の地域保健ワーカーが、現地語で収集した臨床観察データを、WHO の統合疾病サーベイランス・対応（IDSR）信号に自動変換するシステムです。

何が凄いのか： 3つの専門モデルを連携させるマルチモデル・パイプラインを構築しています。テキスト推論にはファインチューニング済みMedGemma、医療画像エンコードにはMedSigLIP、健康音響（咳など）の分析にはHeARを使用。1つのモデルに全部やらせるのではなく、各データ種別を専門モデルに振り分け、MedGemmaがオーケストレーター（指揮者）として統合する設計です。モバイルファーストで、インターネット接続が不安定な地域でも動作します。

② Sunny — 皮膚がんセルフチェックアプリ

オーストラリアの Daniel Bourke と Joshua Bourke が開発した iOS アプリで、ユーザーが自分の皮膚病変を撮影・追跡し、定期的な皮膚がんチェックを促すものです。

何が凄いのか： 技術的に最も詳細に文書化された受賞作品です。MedGemma 1.5 4B を ISIC-2024 皮膚病変データセットと日焼け止め写真を含む約1,100枚の画像で LoRA ファインチューニングし、3エポック学習させています。ビジョンバックボーンは凍結し、LLM部分のみをフルチューニング。その後、Apple の MLX フレームワークで4ビット量子化してオンデバイス iOS 展開しています。

つまり 全推論がiPhone上で完結し、皮膚の写真が一切外部に送信されない という完全ローカル処理です。GitHubリポジトリ（mrdbourke/sunny）でオープンソース公開されており、ファインチューニング済みモデル重みも HuggingFace で公開されています。

「LoRA + 4bit量子化 → ローカル推論」のパターンは Ollama/llama.cpp 環境でもそのまま応用可能です。

③ FieldScreen AI — 完全オフライン結核スクリーニング

リソースが限られた地域での結核（TB）スクリーニングを目的とした、インターネット接続なしで完全にデバイス上で動作するシステムです。

何が凄いのか： このコンテストで最も野心的なエッジ展開です。4つのモデルを1台のデバイスで同時にローカル実行しています：

  • MedGemma → 胸部X線画像の分析
  • HeARベースの分類器 → 咳の音声からのTB検出
  • MedASR → 医療音声のテキスト変換（音声入力対応）
  • TranslateGemma → 現地語への出力翻訳

インターネットがゼロの環境でも、視覚データ（X線）と音声データ（咳）の両方を処理できる完全エアギャップ医療AIの実証です。「クラウドLLMが物理的に使えない場所で、Local LLMしか解がない」ことを最も明確に示したプロジェクトです。

④ Tracer — 医療過誤の防止

医療ミスの予防を目的としたエージェント型ワークフローで、医師のノートから診断仮説を抽出し、検査結果と突合して不一致や未完了の検査を自動的にフラグするシステムです。

何が凄いのか： 他の受賞作が「リソース不足の地域」に焦点を当てているのに対し、Tracerは先進国の病院でも発生する認知エラーにフォーカスしています。医師が多忙な中で手動で行っている「仮説と検査結果の照合」という認知タスクを自動化し、信頼度スコアを付与して人間のレビューに回す仕組みです。MedGemmaをエージェント（自律的に複数ステップを実行するAI）として使うパターンの好例です。

🎯 Special Technology Theme Winners（技術テーマ賞）5プロジェクト

⑤ ClinicDX — サブサハラアフリカ向け完全オフライン診断（テーマ：ファインチューニング）

サブサハラアフリカの診療所向けに、カスタムファインチューニングした MedGemma を OpenMRS（オープンソース電子カルテ）と統合し、完全オフラインで動作する診断支援システムです。

何が凄いのか： 160以上のWHOおよびMSF（国境なき医師団）の臨床ガイドラインをローカルに保持し、オフライン RAG（Retrieval-Augmented Generation）で参照する設計です。モデルの内部知識だけに頼るのではなく、権威ある医療ガイドラインをベクトルストアに格納してローカル検索する、というパターンです。

これは n8n + Dify でRAGのワークフローと直接的に重なります。

⑥ UniRad3s — 放射線科ワークフロー自動化（テーマ：ファインチューニング）

放射線科の業務を3つの柱で自動化するシステムです。MedGemma で異常を検出（Spot）、MedSAM2 で3D病変のセグメンテーション（Segment）、そして画像所見を患者向けの平易な言葉に変換（Simplify）します。

何が凄いのか： MedGemma（テキスト・画像推論）と MedSAM2（3D医療画像セグメンテーション）という2つの専門モデルを組み合わせる設計です。1つの巨大モデルですべてをやるのではなく、検出・分割・要約をそれぞれ専門モデルに分担させるアプローチは、VRAM が限られたローカル環境で特に有効です。

⑦ BridgeDX — 災害時の救急判断支援（テーマ：エッジAI）

2015年のネパール大地震での医療ギャップに着想を得た、完全オフラインの救急判断支援システムです。WHO、MSF、Orphanet（希少疾患データベース）のガイドラインをローカルに搭載し、第一対応者を支援します。

何が凄いのか： 災害直後のような通信インフラが壊滅した状況を想定しています。希少疾患のガイドラインまで含めている点が独特で、**「ネットが使えない極限状況で、希少な症例にも対応できるAI」**というコンセプトは、日本の災害医療にも直接応用可能です。

⑧ CaseTwin — 胸部X線の類似症例マッチング（テーマ：エージェント型）

急性期の胸部X線画像を、過去の類似症例（”ツイン”ケース）と自動マッチングするエージェント型パイプラインです。従来は手動で数時間かかっていた症例検索を数分に短縮します。

何が凄いのか： MedGemmaのマルチモーダルエンコーダ（SigLIPベース）で画像をベクトル化し、エンベディングベースの類似度検索を行っていると推測されます。4Bモデルでも、エージェントとして複数ステップを実行させることで、単一推論では不可能な複雑タスクを処理できることを示しています。

⑨ BigTB6 — 音声駆動の結核・貧血スクリーニング（テーマ賞）

音声バイオマーカー（咳の分析）、X線レビュー、身体的蒼白度の評価を組み合わせた、リソース制約環境での結核・貧血スクリーニングシステムです。

何が凄いのか： 「咳の音」と「顔色（蒼白度）」と「X線」という3種類のまったく異なるモダリティを統合しています。高価な検査機器がなくても、スマートフォンのマイクとカメラだけでスクリーニングの第一段階を実行できる設計です。

🏅 Honorable Mentions（佳作）4プロジェクト

⑩ Dual Path ICU — 集中治療室のワークフロー管理

ICUという最もリアルタイム性が要求される環境で、MedGemmaを活用した臨床ワークフロー管理を行うシステムです。

⑪ Sentinel — 退役軍人のメンタルヘルスモニタリング

退役軍人の精神的健康状態をオンデバイスで継続的にモニタリングするシステムです。メンタルヘルスデータという極めてセンシティブな情報をクラウドに送らずローカル処理する必然性があります。

⑫ Enso Atlas — 病理学ワークフロー支援

病理医の診断ワークフローを支援するシステム。病理画像の分析と所見作成を支援します。

⑬ CAP CDSS — 市中肺炎の管理

市中肺炎（Community-Acquired Pneumonia）の診断・治療を支援する臨床意思決定支援システム（CDSS）で、エージェント型ワークフローを採用しています。

全体を通じた技術パターンの整理

13プロジェクトを横断して見ると、繰り返し出現するパターンがあります。

① 全受賞作が MedGemma をファインチューニングして使用

そのまま（out-of-box）では使っていない。Google自身も、MedGemmaは「特定ユースケースへの検証が必要で、プロンプトエンジニアリング、ファインチューニング、またはエージェント型オーケストレーションで適応可能」と明記しています。

② オフラインRAG + 権威あるガイドライン

ClinicDX、BridgeDX、EpiCastは全て、モデルの内部知識ではなく、WHOやMSFのガイドラインをローカルのベクトルストアに格納して検索・参照しています。

③ マルチモデル・パイプライン

最も高い評価を受けたシステムは、1つの巨大モデルではなく、複数の小型専門モデルを連携させています（FieldScreen AIは4モデル、EpiCastは3モデル、UniRad3sは2モデル）。

④ 4Bパラメータが実用的スイートスポット

オンデバイス/オフラインの受賞作は全て MedGemma 4B を使用。4bit量子化で5〜7GB VRAMに収まり、スマートフォンからコンシューマGPUまで対応可能です。

Local LLMならでは × さすがファインチューン

受賞プロジェクトが証明した「小さいモデルの勝ち方」

1. 「さすがファインチューン」── 数字で見る威力

まず、受賞プロジェクト群から読み取れるファインチューニングのインパクトを整理します。

全13プロジェクトが MedGemma をファインチューニングして使っているという事実が最も雄弁です。そのまま（out-of-box）で使って受賞したプロジェクトはゼロ。Google自身が公式ドキュメントで「特定ユースケースへの検証とファインチューニングが必要」と明記しており、コンテスト結果がそれを裏付けました。

では具体的にどの程度「効く」のか。DataCampの実証では、MedGemma 4B を脳MRIデータセットで LoRA ファインチューニングした結果、がん分類精度が 33% → 89% へと跳ね上がっています。約56ポイントの改善です。

Google公式のGRPO（強化学習）ノートブックでは、MedQAデータセットにおいて 14.1% → 70.5% への改善が報告されています。これはLoRAではなく強化学習（GRPO）を使った事例ですが、4Bモデルでも手法次第でここまで引き上げられるという証拠です。

学術論文のメタ分析では、LoRAファインチューニングにより15〜20ポイントの精度向上が得られ、ハルシネーション（幻覚）率が0.14%から0.00%に低下した事例も報告されています。

受賞プロジェクトごとに見ると、ファインチューニングの「効かせ方」に3つのパターンがあります。

パターン①：少量データ × LoRA → 専門タスク特化

Sunny が最も典型的です。わずか約1,100枚の画像で LoRA ファインチューニングを行い、3エポック学習しただけで、皮膚がんの自己チェックに実用的な精度を達成しました。ビジョンバックボーン（SigLIP）は凍結し、LLM部分のみをフルチューニングするという戦略です。

これが意味するのは、数千枚規模のドメイン固有データさえあれば、4Bモデルを専門家レベルに引き上げられるということ。大規模データセットは不要です。

電子カルテ（EMR）データや、商品画像データなど、中小企業が持つ規模のデータでも十分にファインチューニングが成立する世界です。

パターン②：ガイドラインRAG + ファインチューニング → 「根拠のある推論」

ClinicDX は 160以上の WHO/MSF ガイドラインをローカルのベクトルストアに格納し、ファインチューニング済み MedGemma で検索・推論しています。BridgeDX も同様に WHO/MSF/Orphanet のガイドラインをオフラインRAGで参照します。

ここでのポイントは、ファインチューニングとRAGの二重の知識注入です。ファインチューニングでモデルの「思考回路」を医療ドメインに最適化し、RAGで「参照できる根拠」を与える。どちらか一方ではなく、両方やることで信頼性が確保されています。

これはまさに、n8n + Dify で構築しているRAGワークフローに、ファインチューニング済みモデルを組み合わせるパターンそのものです。

パターン③：強化学習（RL）→ 出力形式の矯正

Google公式ノートブックでは、MedGemma 4B がベースラインだと長い推論チェーンを生成してトークン制限内に最終回答を出せないという問題が、GRPOによる強化学習で解決されています。精度が14.1%→70.5%に改善したのは、モデルの知識が増えたからではなく、「正しい出力形式で答える癖」がついたからです。

受賞プロジェクトの Tracer（医療過誤防止）や CAP CDSS（肺炎管理）のエージェント型システムでは、モデルが構造化された出力（信頼度スコア付きのフラグ、臨床判断のステップ等）を生成する必要があります。このような「出力の型」を教え込むには、LoRAよりもRL系のファインチューニングが効果的です。

2. 「Local LLM ならでは」── クラウドでは不可能な5つの勝ち筋

受賞プロジェクトが示した Local LLM の優位性は、「コストが安い」という単純な話ではありません。クラウドLLMでは物理的に実現できないユースケースが複数明確になりました。

勝ち筋①：ゼロ接続環境（インターネットがない場所）

FieldScreen AI、ClinicDX、BridgeDX の3プロジェクトは、インターネット接続が存在しない環境で動作します。これは「クラウドの方が性能は良いけどローカルで我慢する」という話ではなく、クラウドLLMという選択肢そのものが物理的に存在しない状況です。

FieldScreen AI は4つのモデル（MedGemma + HeAR + MedASR + TranslateGemma）を1台のデバイスでローカル実行し、胸部X線分析と咳の音声分析の両方をオフラインで処理しています。GPT-4oがどんなに優秀でも、ネットがなければ使えません。

日本でも、災害時（地震後の避難所、通信インフラ壊滅時）は同じ状況になります。BridgeDXが2015年ネパール大地震に着想を得たように、災害医療AIは本質的にLocal LLM案件です。

勝ち筋②：患者データの主権（データが外に出せない）

Sunny は全ての皮膚写真をiPhone上でローカル分析し、データを一切外部に送信しません。Sentinel は退役軍人のメンタルヘルスデータを完全オンデバイスで処理します。

日本の法規制を考えると、この優位性は極めて大きいです。個人情報保護委員会（PPC）は2023年6月に、AIサービスへの個人データ入力がAPPI違反になりうると警告しています。医療データは「要配慮個人情報」として最高レベルの保護が求められ、クラウドへの送信には明示的な本人同意が必要です。

EMRシステムを考えてみてください。月額数万円で運用しているシステムの患者データを、クラウドLLMに送信するには、患者一人ひとりの明示的同意が必要になります。ローカル推論なら、この法的ハードルがゼロになります。リコーが那須赤十字病院にオンプレLLMを導入し、NTT東が新潟大学で tsuzumi を使っている背景には、まさにこのデータ主権の問題があります。

勝ち筋③：ファインチューニングによる「自分専用モデル」の構築

これが Local LLM × ファインチューニングの最も強力な組み合わせです。

ClinicDX はサブサハラアフリカの特定地域の疾病分布に合わせてファインチューニングしました。Sunny は皮膚がんという特定タスクに特化しました。どちらも、汎用クラウドLLMでは到達できない「狭く深い専門性」をファインチューニングで獲得しています。

クラウドLLMをファインチューニングする方法もあります（OpenAIのFine-tuning API等）。しかし、訓練データをクラウドに送信する必要があるという根本的な問題が残ります。病院の内部データ、特定施設の診療ガイドライン、地域固有の処方パターンなどの機密データでファインチューニングするには、ローカル環境が必須です。

Google Colab（無料枠のT4 GPU）でも MedGemma 4B の QLoRA ファインチューニングが可能なことが実証されています。RTX 3060（12GB VRAM）でも、Unsloth + 4bit量子化 + LoRA を使えば 8Bパラメータモデルのファインチューニングが可能です。

つまり、学習はクラウドGPUをレンタル（A100を数時間）、推論は自前のRTX 3060という分離運用が現実的です。

勝ち筋④：マルチモデル・パイプライン（小型モデルの連携）

受賞作で最も特徴的な設計パターンが、1つの巨大モデルではなく、複数の小型専門モデルを連携させるアーキテクチャです。

プロジェクトモデル数構成
FieldScreen AI4MedGemma + HeAR + MedASR + TranslateGemma
EpiCast3MedGemma + MedSigLIP + HeAR
UniRad3s2MedGemma + MedSAM2
BigTB63+MedGemma + 音声分析 + 画像分析

これが Local LLM に有利な理由は明快です。4Bモデル1つなら5〜7GB VRAMで動くので、12GB の RTX 3060 でも複数モデルを順次実行できます。一方、クラウドの巨大モデル（GPT-4o、Gemini 2.5 Pro）は「1つのモデルで全部やる」設計なので、ローカルでは動きません。

Codex CLI + tmux でマルチエージェント・オーケストレーションを構築しているアプローチと、構造的に同じ発想です。「1つの賢いAI」より「複数の専門AIの連携」の方が、ローカル環境では実装しやすく、モジュール単位の差し替えや更新もできます。

勝ち筋⑤：レイテンシとコスト構造

Tracer（医療過誤防止）は検査結果が到着するたびにリアルタイムで仮説と照合する必要があります。ローカル推論なら30〜80msのレイテンシで処理できますが、クラウドAPIは200〜600ms。連続的なデータストリームを処理する場合、この差は無視できません。

コスト面では、ある実証事例で5年間のオンプレミスAIインフラが約195,000ドル vs クラウド同等性能が430万ドルという試算が報告されています。92%のコスト削減、損益分岐点は12ヶ月未満です。日々数百人の患者を処理する病院では、トークン単価課金のクラウドコストが急速に膨らみます。

3. さすがにクラウドLLMの方が楽だった部分

公平を期すために、受賞プロジェクトの中で「クラウドの大型モデルがあれば楽だったろう」と推測される部分も整理します。

複雑な多段推論 MedGemma 4B の MedQA スコアは 64.4%、27B でも 87.7% です。GPT-4o や Gemini 2.5 Pro はこれを上回る推論能力を持ちます。MedGemma 4B はエージェント型ベンチマーク（AgentClinic）では、システム指示に従うのが困難だったと報告されています。Tracer や CAP CDSS のようなエージェント型システムは、4B モデルで実装するには相当な工夫（プロンプト設計、ワークフロー分割）が必要だったはずです。

非英語対応 MedGemma の安全性評価は主に英語で行われており、日本語医療用語の性能は未検証です。受賞プロジェクトにも日本語対応のものはありません。日本の医療現場で使うなら、Preferred Networks の MedSwallow-70B や NII の SIP-jmed-llm-2 のような日本語特化モデルが必要で、これは MedGemma 単体では解決しません。

マルチモーダルの「楽さ」 FieldScreen AI が4つのモデルを苦心してパイプライン化したのに対し、Gemini 2.5 Pro ならテキスト・画像・音声をネイティブに単一モデルで処理できます。ローカルでのマルチモデル・パイプラインは強力ですが、統合の手間はクラウドの方が圧倒的に少ないのは事実です。

4. RTX 3060 で何ができるか ── 実践マップ

ここまでの分析を、実環境（RTX 3060 12GB / Ollama / Ubuntu）に引き直します。

今すぐできること：

  • MedGemma 4B の 4bit GGUF を Ollama で推論実行（VRAM 5〜7GB）
  • テキストベースの医療QA、臨床メモの要約、ガイドラインRAG
  • Unsloth の GGUF 変換済みモデル（unsloth/medgemma-1.5-4b-it-GGUF）が利用可能

クラウドGPUレンタルが必要なこと：

  • LoRA ファインチューニング自体は Google Colab 無料枠（T4 GPU）でも MedGemma 4B に対して実行可能ですが、本格的な学習にはA100を数時間レンタルが現実的
  • 学習後のモデルは4bit量子化してRTX 3060にデプロイ（Sunny方式）

マルチモデル・パイプラインの実装：

  • MedGemma 4B（テキスト/画像推論）+ Qwen3.5:9b（日本語テキスト処理）を Ollama で切り替え実行
  • n8n でオーケストレーション、Dify でRAGのガイドライン参照
  • 画像タスクは MedGemma、日本語テキストタスクは Qwen/MedSwallow と使い分ける
  • この「モダリティ別モデル分担」は、受賞作の FieldScreen AI や EpiCast と同じ設計思想

5. 結論：Local LLM + ファインチューニングは「制約下の工夫」ではなく「設計思想」

MedGemma Impact Challenge の結果から導かれる最大の教訓は、ローカル展開とファインチューニングは「クラウドが使えないからの妥協」ではなく、医療AIにおいて本質的に優れた設計アプローチであるということです。

クラウドの巨大モデルは「何でもそこそこできる」。しかし受賞プロジェクトが示したのは、**「ファインチューニングで狭く深く特化した4Bモデル + 権威あるガイドラインのRAG + マルチモデル・パイプライン」**という組み合わせが、特定タスクにおいてクラウドの汎用モデルを凌駕するという事実です。

そしてこのアプローチは、RTX 3060 + Ollama + n8n という、既に構築しているインフラの上にそのまま載ります。足りないのは「巨大なGPU」ではなく、「タスク特化のファインチューニング済みモデル」と「ドメイン固有のガイドラインベクトルストア」です。

bancom

株式会社バンコム 代表 山口清秀