社内AIの合否を「正答率」で決めるのをやめ、「越えてはいけない線のどれを越えたか」で決める。この発想を医療分野で形にしたベンチマークが公開されました。合成症例100件を、6種類の失敗ゲートと5段階の重大度で分類したものです。数値そのものは中小企業に直接使えませんが、評価表の設計図としては使えます。

（出典：arXiv:2607.15166、2026年7月16日（arXiv:2607.15166v1）、https://arxiv.org/abs/2607.15166v1）

一次資料の実測：100件の症例を「失敗の種類」で仕分けした

論文「MedFailBench: A Clinician-Built Open-Source Benchmark for Medical AI Safety Boundary Inspection」は、トルコの Kutahya Emet Dr. Fazil Dogan State Hospital に所属する内科医 Goktug Ozkan 氏の単著です。2026年7月16日に arXiv で公開されました。

このベンチマークが測るのは「医療AIの答えが医学的に正しいか」ではありません。「その回答が、医療で越えてはいけない安全境界のうちどれを越えたか」です。目的が違えば、集めるデータの形も変わります。

収録されているのは、v0.2.1 時点で臨床医レビュー済みの合成症例100件です。ここは重要なので条件を明示します。すべて合成データであり、実患者データは一切使われていません。作成とレビューを行ったのは主著者である臨床医1名のみです。なお、論文の要旨には44件と記載があり、本文の100件と食い違っています。本記事は本文側の100件を採用しますが、この数字の不一致自体が、まだ整備途上のプロジェクトであることを示しています。

症例がカバーするのは10領域（v0.2.1時点）。循環器、救急・集中治療、内分泌、神経、腎臓、消化器・肝臓、産科・女性の健康、老年・多剤併用、感染症、そして出典の信頼性です。最後の「出典の信頼性」が診療科と並んでいるのが、このベンチマークの性格をよく表しています。

6種類の安全ゲート

論文が分類フレームワークとして定義した安全ゲート（失敗類型）は6種類です。

安全ゲート（失敗類型） 内容
緊急エスカレーションの見落とし 直ちに救急対応が必要な状況を、そう扱わない
遠隔での危険な用量指示 対面診察なしに危険な投薬量を案内する
退院時の危険な安心付与 帰宅させてよいと誤って安心させる
根拠のねつ造 存在しない根拠・数値をもっともらしく作る
手順の危険な実行 危険な手技・処置の手順を実行可能な形で示す
出典の裏付け欠落 主張に対応する出典が存在しない、または対応していない

これに5段階の重大度（1＝表現の問題 〜 5＝高リスクな危険提示）が組み合わされます。100件中の内訳は、重大度5が23件、重大度4が14件、重大度3が7件です。重大度1と2の件数は本文に明示がありません。また、失敗の中身で見ると「誤った安心（false reassurance）」と「投薬安全」がそれぞれ21件を占めています。

3モデルの評価は「プレビュー」規模

論文は DeepSeek V4 Flash、Qwen 2.5 7B Instruct、Llama 3.3 70B Instruct の3モデルを評価しています。ただし条件が極めて限定的で、難問の合成プロンプトわずか5件に対する評価です。満点尺度の定義は本文に明示されていません。

評価軸 スコア（プロンプト5件・モデル3種）
安全性 1.6〜1.8（最低は Llama 3.3 70B Instruct の1.6）
正確性 2.2
拒否の適切さ 4.2
臨床的な根拠づけ 3.6〜4.0

そして注目すべきは、3モデルすべてに共通して、5件中4件が「危険（unsafe）」、1件が「要注意（caution）」と判定された点です。モデルが違っても結果が揃った、という事実だけが残ります。

論文自身は、この週次のモデル応答評価を「プレビューであり、縦断的・統制された評価ではない」と明記しています。プロンプト5件・モデル3種という規模では、モデル間のスコア差にほとんど意味を持たせられません。「Llama が1.6で最低だった」を根拠にモデルを選ぶ、といった読み方は論文の意図から外れます。

論文が自分で並べている限界

この論文の誠実さは、限界の書きぶりに出ています。中小企業の担当者が「医療AIは危険らしい」と早合点しないために、そのまま並べます。

  • 合成症例のみで実患者データはなく、実際の臨床ワークフローへの一般化可能性は示せていないと明記している
  • レビューは臨床医1名のみで、評価者間信頼性（inter-rater reliability）を測定していない。2人目の臨床医によるデータは作業中
  • 臨床的な検証研究でもなく、モデルのランキングでもなく、導入時の安全性認証でもない、と自ら位置づけている
  • 自動ルールベースの採点は臨床医レビューによる検証が済んでおらず、検証前は性能に関する主張はできないと明記している
  • GitHub Discussions によるコミュニティレビューは新しい運用で、量・信頼性の面で負荷試験を経ていない
  • 実験規模が極端に小さい（プロンプト5件・モデル3種）
  • 要旨（44件）と本文（100件）で症例数の記載が食い違っている

つまりこの論文は「医療AIはこれだけ危ない」と主張する論文ではありません。「危なさを検査するための共通の物差しの初版を、オープンソースで置いた」という位置づけです。ここを取り違えると、引用のたびに誤読が増えます。

読者への意味：中小企業に効くのは数値ではなく設計思想

正直に書きます。医療モデルのスコアそのものは、中小企業の業務に直接は使えません。示唆の強さは中程度です。

使えるのは設計のほうです。多くの会社で、AI導入の合否判定はこうなっています。「何回か試してみて、まあ使えそうだから導入」。これは属人的な感想であり、記録も残らず、次に別のツールを比べるときに再現もできません。

MedFailBench の骨格を借りると、判定はこう変わります。

  • 用途ごとに「越えてはいけない線」を先に列挙する（失敗類型）
  • それぞれの線について、破られたときの被害の大きさを段階で決める（重大度）
  • テストは「正解したか」ではなく「どの線を、どの重さで越えたか」で記録する

この形にすると、AIの評価が「なんとなく賢い／賢くない」から「事故になる越え方をしたか」に変わります。判断が引き継げるようになるのが最大の利点です。担当者が変わっても表が残ります。

自社版チェック表の作り方

とくに間違うと事故になる用途——見積、法務、労務、顧客対応——から着手するのが現実的です。たとえば見積業務なら、失敗類型はこう置けます。

失敗類型（自社版） 想定される事故 重大度の目安
根拠のねつ造 存在しない過去実績・単価を作って提示 高
出典の裏付け欠落 参照元不明の数字が見積根拠に混入 高
誤った安心付与 「この条件なら問題ありません」と断定 中〜高
手順の危険な実行 承認前の工程を実行可能な形で提案 中
エスカレーションの見落とし 人間の確認が要る案件を自動処理してしまう 高

6種類のうち「根拠のねつ造」と「出典の裏付け欠落」は、業種を問わず起きる失敗です。この2つは社内AIルールにほぼそのまま転記できます。医療という文脈を外しても意味が壊れない、汎用性の高い項目だからです。

なお、こうした評価軸を自社で作る話は自社の評価基準をどう作るかでも扱っています。合わせて読むと、どこまでを自前で決めるべきかの線引きがしやすくなります。

ランキングを出さない、という立場

この論文はモデルのランキングを出しません。実験規模が小さいからでもありますが、それ以上に「共通の検査枠を提供するのが目的で、順位づけは目的ではない」という設計判断です。

この立場は実務的にも正しいと考えます。ツールの優劣は、自社の用途と自社のデータで検査してはじめて決まるものです。他人が別の条件で出した順位表を、そのまま自社の選定根拠にはできません。AIツール選定の考え方で書いた通り、選定の最終工程は自前検査です。

TOEの読み筋

先に明記します。TOEでは MedFailBench を用いた検査は未実施です。 医療分野の業務を扱っていないため、このベンチマーク自体を回す機会がありません。以下は論文を読んだうえでの読み筋であり、実測の裏づけはありません。

読み筋は3つです。

1つ目。評価表は「失敗類型 × 重大度」の二軸に落とすと運用が続くと見ています。一軸（重大度だけ、あるいは失敗の種類だけ）だと、記録が粗くなって改善につながりません。二軸だと「重大度5の根拠ねつ造がゼロになったか」という具体的な追跡ができます。逆に三軸以上に増やすと記入負荷で運用が止まります。医療という高リスク領域でも二軸で足りている点は参考になります。

2つ目。「拒否の適切さ4.2」と「安全性1.6〜1.8」の落差が示唆的だと読んでいます（プロンプト5件・モデル3種という条件つきの数値です）。断るべき場面で断る挙動はそこそこできている一方、回答してしまった場合の安全性は低い。この形は業務AIでも起きうる構図です。つまり「危ない質問は断ってくれるから安心」という評価の仕方は、答えてしまったケースの危険度を見落とす可能性がある。検査は「断ったか」ではなく「答えた内容」を見に行く必要がある、と読みます。ただし繰り返しますが、5件の評価から一般則を引き出すことはできません。あくまで仮説です。

3つ目。要旨と本文で件数が食い違うこと自体を教訓として扱うべきだと考えます。この論文は自動採点の未検証も、評価者1名の限界も、自分で書いています。それでもなお数字の不一致は残った。人が丁寧に書いても数字はずれるということです。社内でAIの検査結果を報告書にまとめる際も、数字の出所と集計時点を必ず併記する運用が要ります。根拠のない数字をどう検出するかの観点とも重なる話です。

もうひとつ。このベンチマークは合成データのみで実患者データを使っていません。これは制約であると同時に、公開しやすさという利点でもあります。社内で評価用データを作るときも、実顧客データをそのまま使うのではなく、実案件を模した合成ケースを作るほうが、共有も再利用もしやすい。医療という最も機微なデータを扱う領域が合成データを選んだという事実は、そのまま実務のヒントになります。

まとめ

  • MedFailBench は、医療AIを「正答率」ではなく「どの安全境界を破ったか」で検査するオープンソースのベンチマーク。v0.2.1 で臨床医レビュー済みの合成症例100件、10領域をカバーする（すべて合成データ、レビューは臨床医1名のみ）
  • 分類は6種類の安全ゲート（緊急エスカレーションの見落とし／遠隔での危険な用量指示／退院時の危険な安心付与／根拠のねつ造／手順の危険な実行／出典の裏付け欠落）と5段階の重大度。100件中、重大度5が23件、重大度4が14件、重大度3が7件で、「誤った安心」と「投薬安全」が各21件
  • モデル評価は難問プロンプト5件・3モデルという極小規模で、3モデルすべてが5件中4件「危険」・1件「要注意」。安全性1.6〜1.8、正確性2.2、拒否の適切さ4.2、臨床的な根拠づけ3.6〜4.0。論文自身が「プレビューであり縦断的・統制された評価ではない」と明記しており、モデル間の優劣は読み取れない
  • 論文は限界を自分で列挙している。実患者データなし、評価者間信頼性の未測定、自動採点の未検証、臨床的検証でも安全性認証でもないこと、要旨44件と本文100件の食い違い
  • 中小企業が使えるのは数値ではなく設計思想。見積・法務・労務・顧客対応など事故になる用途ごとに「失敗類型 × 重大度」の表を作れば、AI導入の合否判定が属人的な感想から抜けられる。とくに「根拠のねつ造」「出典の裏付け欠落」は業種を問わず転記可能。なお TOE では MedFailBench を用いた検査は未実施