GENSHI AI
「APIを出してくれない」「カスタマイズ見積もりが数千万、納期1年」——人間が画面を見て操作できることを、AIに肩代わりさせる選択肢はないのか。ローカルGPU1枚で動くOSSの視覚AIで、どこまで現実的か実測した記録です。
（GENSHI AI 共同創業者 大塚直人）
TL;DR
- 電子カルテ（EMR）の業務自動化は、ベンダーAPIではなく 画面操作AIエージェント（VLMベースのcomputer-useエージェント） で回避できる時代に入りつつある
- 自前で立てたEMRモック画面で、OSSのQwen3.6-27B (Dense) + JSON Schema制約 がGUI grounding精度 84.4% を達成し、GUI特化モデルHolo3-35Bと並んだ
- 一方、同じ「Qwen3.6」でも MoE構造の35B-A3B（active 3B）は6〜9% と壊滅。総パラ数ではなくactiveパラ数が天井を決める
- 「クリックできる場所を全部列挙する」タスク（キーワードヒントなし）のF1は 0.53。完全自動化はまだ早く、Human-in-the-loop前提の業務補助なら今すぐ実用射程
- 全部A100 1枚＋ローカル完結。画像が外に出ない構成 なので医療情報安全管理ガイドラインとの整合説明もしやすい
なぜこの話を書くか
電子カルテのベンダーに「この画面のデータをCSVで吐けるようにして」と頼んだことがある人は分かると思います。返ってくる答えはだいたいこうです。
- 「カスタマイズ対応になります。見積もりは追ってご連絡します」（数百万〜数千万）
- 「次期バージョンでFHIR対応を予定しています」（時期未定）
- 「ベンダー間連携は弊社のSaaSでのみ可能です」（実質ロックイン）
結果、画面では一瞬で見える情報 が機械的に取り出せず、転記・集計・部門間共有は人手のままです。退院サマリ、検査結果一覧、処方履歴、病名サマリ、紹介状作成——どれも「人が画面を見て、人が別の画面に打ち込む」が残ったままです。
これに対して、近年急速に立ち上がってきたのが Computer-use型の視覚言語モデル（VLM） です。Anthropic Claude Computer Use、Mind2Web、Holo3、Qwen3-VLシリーズ、UI-TARSなど、「スクリーンショットを見て、クリック座標を返す」 モデルが揃ってきました。
つまり、ベンダー協力ゼロで、人間オペレータの仕事を肩代わりするエージェント が、技術的には現実になりつつあります。問題は「OSSでどこまで使えるのか」「自前GPUで動くのか」「医療現場で安全に運用できるのか」です。この記事は、その射程を実測した記録です。
実験設定：MedBridgeサンドボックス
ベンダー製の本物のEMRで実験するわけにはいかないので、社内で 電子カルテ風のWebアプリケーション を作って計測台にしました。
- フロント: Next.js（病院EMRっぽい6画面：ログイン／患者一覧／カルテ／検査結果／処方／病名）
- 起動: ElectronでCDP（Chrome DevTools Protocol）を開き、headless Linux上でXvfb + openboxで表示
- 推論: A100 80GB 1枚にllama.cpp llama-server（CUDA）で各種VLMをロード
EMR自動化エージェントに必要な能力を3つに分解して測ります。
| タスク | 何を測るか | 病院業務での意味 |
|---|---|---|
| Grounding | 「ログインボタンの座標を返して」のような指示で正しい場所をクリックできるか | 既知の操作シナリオを自動化できるか |
| OCR | 画面に表示された患者名・検査値を正確に読めるか | 転記・集計の精度 |
| Detection | キーワードなしで「クリック可能な要素」を全列挙できるか | 未知画面で自律的に動けるか（汎用computer-use） |
比較したモデルは以下です。
| モデル | 種別 | サイズ | 備考 |
|---|---|---|---|
| Holo3-35B-A3B | GUI特化VLM | MoE 35B（active 3B） | vLLM BF16、GUI grounding専用学習 |
| Qwen3.6-35B-A3B | 汎用VLM | MoE 35B（active 3B） | BF16 / Q8 両方 |
| Qwen3.6-27B | 汎用VLM（Dense） | 27B全部active | BF16 / Q8 両方 |
すべてのテストで enable_thinking: false（Qwen3.6のデフォ思考モードを切る）とJSON Schemaによる出力構造強制を行っています。後述しますが、これをやらないと結果が読めるレベルになりません。
結果1：Grounding——「ボタンの場所、教えて」
最初に「画面のスクリーンショット＋『ログインの座標』のような指示」で正しい場所を当てられるかを32タスク × 6画面で測りました。
| モデル | Hit率 | 平均ピクセル誤差 | 平均レイテンシ | 備考 |
|---|---|---|---|---|
| Holo3-35B-A3B（GUI特化） | 84.4% | 149 px | — | 既存EMR操作の自動化が「今すぐ」設計可能 |
| Qwen3.6-27B BF16 + JSON Schema | 84.4% | 127 px | 2.82 s/call | 汎用OSSがGUI特化と並んだ |
| Qwen3.6-27B Q8_0 + JSON Schema | 84.4% | 148 px | 3.32 s/call | 量子化でも精度ほぼ不変 |
| Qwen3.6-35B-A3B BF16 + JSON Schema | 6.3% | 376 px | 2.18 s/call | active 3Bではgroundingに不足 |
| Qwen3.6-35B-A3B Q8_0 + JSON Schema | 9.4% | 388 px | 1.94 s/call | 同上 |
画面別のgrounding精度（Holo3-35B、参考値）
| 画面 | 正解 / タスク数 |
|---|---|
| ログイン | 2/2 |
| 患者一覧 | 6/6 |
| カルテ | 5/6 |
| 検査結果 | 5/6 |
| 処方 | 5/6 |
| 病名 | 4/6 |
何を意味するか
- 「ベンダー画面のクリック自動化」をOSSスタックで設計できる ことが実測ベースで言える
- A100 1枚で1クリック判断に2〜3秒。RPA的な用途には十分速い
- OCRは全モデルでRecall 1.0、検査値・氏名読み取りは信頼できる水準
結果2：MoE 35BがDense 27Bに負けた——activeパラメータの効き方
ここが今回一番面白い発見です。同じ「Qwen3.6」シリーズで、サイズが大きいはずの35B-A3Bが、27B-Denseにダブルスコアどころか「桁違いに」負けました。
| モデル | 公称サイズ | activeパラメータ | Grounding Hit率 |
|---|---|---|---|
| Qwen3.6-35B-A3B | 35B | 3B（MoE） | 6〜9% |
| Qwen3.6-27B（Dense） | 27B | 27B（全部active） | 84.4% |
MoE（Mixture of Experts）は、合計パラメータが大きくても1トークンあたりに動く専門家は一部だけ という構造です。Qwen3.6-35B-A3Bはactiveが3Bしかなく、その「3B相当の推論能力」が画像と座標の幾何的対応付けに必要な容量に足りていない、と読めます。
これは量子化のせいではありません。BF16（フル精度）でもQ8（8bit量子化）でも結果はほぼ同じ で、構造的な天井です。
結果3：「キーワードなしで操作可能要素を見つけられるか」——computer-useの本丸
ここまでは「『ログインボタン』のように 何を探すか を教えた」ベンチでした。本当のcomputer-useエージェントは、未知の画面を見て、自分で操作可能な要素を発見する 必要があります。
そこでDetectionベンチを作りました。プロンプトには キーワードを一切含めず、「画面を見て、クリックできる場所と入力できる場所をJSONで全部返して」とだけ指示します。GTはCDPでブラウザのDOMから button, input, [role=button] などを実際に列挙して生成しました。
結果（Qwen3.6-27B BF16 + JSON Schema）：
| 画面 | TP | FP | FN | Precision | Recall | F1 |
|---|---|---|---|---|---|---|
| ログイン | 4 | 1 | 0 | 0.80 | 1.00 | 0.89 |
| 患者一覧 | 11 | 22 | 0 | 0.33 | 1.00 | 0.50 |
| カルテ | 11 | 39 | 13 | 0.22 | 0.46 | 0.30 |
| 検査結果 | 22 | 28 | 3 | 0.44 | 0.88 | 0.59 |
| 処方 | 23 | 27 | 6 | 0.46 | 0.79 | 0.58 |
| 病名 | 24 | 26 | 1 | 0.48 | 0.96 | 0.64 |
| 全体 | 95 | 143 | 23 | 0.40 | 0.81 | 0.53 |
観察
- Recallは高い（0.81）が、Precisionが低い（0.40）。「見逃しは少ないが、過検出が多い」
- カルテ画面のカレンダーUIで「日付セル」を全部クリック対象として列挙してしまう
- ログインのようなシンプル画面ではF1 = 0.89と実用域
病院オペレーションへの示唆
- 完全自動操作（人間が見ないRPA）にはまだ早い。「過検出」を実行に移すと事故になる
- Human-in-the-loop（候補提示→人間確認）なら今すぐ十分に有用
- 例：退院サマリ作成時、「この画面で次にクリックしそうな場所」を3つ候補表示
- 例：転記補助で「読み取り候補欄」をハイライトし、人間が承認したものだけ転送
- 段階導入シナリオ：① 転記補助 → ② 下書き生成（編集前提）→ ③ 確認付き自動実行
実装ハック：「動くこと」を阻む3つの罠
罠1：素の出力はJSONが壊れる
JSON Schema制約をかけないと、Qwen3.6はこういうものを返してきます。
{"x":[69,33],"y":[27]}座標を返してほしいのに配列。これだけでgrounding精度は0.63 → 0.84に跳ねました（27B Dense）。llama.cpp側で response_format: {type: "json_schema", json_schema: {...}} を渡すと、内部的にGBNF（文法制約）が効いて出力構造が強制されます。
payload = {
"model": MODEL,
"messages": [...],
"response_format": {
"type": "json_schema",
"json_schema": {
"name": "out",
"schema": {
"type": "object",
"properties": {
"x": {"type": "integer"},
"y": {"type": "integer"}
},
"required": ["x", "y"]
}
}
}
}運用での意味：「壊れたJSONで業務エージェントが停止する」事故を構造的に防げます。
罠2：座標は0-1000正規化規約
Qwen-VL / Holo3系は座標を 画像サイズで割って0-1000にスケールした値 で返してきます。ドキュメントが薄いので、最初は「全部画面の左上に集まっている」ように見えて混乱します。ベンダー乗り換え時にこの規約の違いが互換性ハマりポイントになる ので、抽象化レイヤを最初から噛ませるのが安全。
罠3：思考モードでトークンが枯渇する
Qwen3.6はデフォルトで <think>...</think> ブロックを大量に吐きます。max_tokensを512程度にしていると本文が全く返ってきません。
payload["chat_template_kwargs"] = {"enable_thinking": False}これでgroundingのような短い構造化出力ではレイテンシが1/3になります。運用での意味：医療現場のリアルタイム性に乗せるには必須設定。
アーキテクチャ：医療情報安全管理ガイドラインとの整合
このスタックの構成上、患者画面のスクリーンショットもVLMの推論も、すべて院内GPUで完結 します。
[EMR端末]──CDP/RPA経由──→[院内GPUサーバ (A100 1枚)]
├ llama-server (Qwen3.6-27B BF16)
├ 業務エージェント (Python)
└ ログ・監査トレース- モデル重み：完全ローカル（モデル課金なし）
- 推論：完全ローカル（外部API不使用 → クラウド送信問題なし）
- 監査：全プロンプト・全画像・全応答をローカルDBに記録可能
- ベンダー：不要（ベンダー間連携契約・データ提供同意書の追加不要）
医療情報システムの安全管理ガイドライン上、外部送信なし で構成できることは「情報共有同意」「越境データ問題」を一気に消せる強みです。
概算コスト感
- モデル重み：0円（OSS、Hugging Faceから取得）
- GPU：A100 80GB 1枚（中古 ~250万、クラウド ~400円/h）
- 電力：A100 ~300W、年間24h稼働で電気代 ~7万円
- 構築：エンジニア1〜2人月でPoC、本番運用にはUI設計込みで6人月程度
ベンダーAPIカスタマイズ見積もり 数千万 / 1年と比べると、自前PoCの方が早くて安いケース は確実に存在します。
まとめ：数年後を見据えた早めの実験を
正直に言えば、この領域はまだ市場が立ち上がっていません。「画面操作AIで電子カルテを動かす」プロダクトが普通に病院に入る世界は、おそらく数年先です。
ただ、このベンチで分かったのは、「人が画面で1〜2秒で判断できるUI操作」は、OSSのVLM＋A100 1枚で2〜3秒の精度84%で再現できる ところまで来ているということです。完全自動はまだ早いが、Human-in-the-loopの業務補助なら検証は今すぐ始められます。
ベンダーがAPIを出してくれないなら、画面の方をAIに見せればいい——少なくとも技術的な前提条件は揃ってきた、と言える段階です。数年後にこの選択肢が当たり前になったとき、「うちは試したことがある」と言える病院・企業が、案外少数派だと思います。
付録：使ったモデルとベンチ可視化ビューワー
- Holo3-35B-A3B: huggingface.co/Holo1/Holo3-35B-A3B
- Qwen3.6-35B-A3B: huggingface.co/Qwen/Qwen3.6-35B-A3B
- Qwen3.6-27B: huggingface.co/Qwen/Qwen3.6-27B
- 推論バックエンド: llama.cpp（CUDA sm_80 自前ビルド）
ベンチ結果の生データ・プロンプト全文・予測座標などを 1 件ずつ確認できる可視化ビューワーを公開しています。
- MedBridge Sandbox — Experiment Viewers（Grounding / OCR / Detection 全モデルの per-trial 可視化）