この記事で扱う問題

医療従事者向けの Web アプリ休薬レンズ (KyuyakuLens) を作っています。手術・造影 CT の前に「休薬が必要な薬」を服用中の患者を見落とすと、出血・血栓・造影剤腎症・乳酸アシドーシスといった重篤な有害事象に直結します。このアプリは、スマホでお薬手帳を撮影 (または処方内容を貼付) すると、 Google Cloud Vision で OCR したテキストを 155 剤の休薬対象マスタに照合し、該当薬が見つかれば警告する、という判定アシストツールです。

医療現場で使うアシストツールに求められる要件は、相反する 2 つを両立することです。

取りこぼしゼロ (recall 100%): マスタに載っている薬を見逃せば、それはそのまま医療事故に直結する。この目的でツールを見ている人間に「あるはずのアラートが出なかった」は許されない
誤検出最小 (precision 高): 関係ない薬に対して逐一「休薬候補です」と出せば、現場は「またこのツールか」とアラート疲れを起こし、やがて本当のアラートも無視するようになる。いわゆる alarm fatigue で、これも安全性の毀損

普通の情報検索では「recall と precision のトレードオフ」で済ませられますが、医療安全アシストでは片方を諦めないための工夫が必要でした。骨格は 6 step の normalize + kata run 索引 + 3 段 scoring 照合。実コード込みで書き残します。

実装はブラウザで動く JavaScript の単一ファイル (約 700 行、依存ゼロ) です。

1. 素朴な部分一致がなぜ両方の要件を満たせないか

最初、素朴に text.includes(drug.name) から始めましたが、 recall / precision 双方でズタボロに敗北します。実際に踏んだ失敗パターンを 6 つ、それぞれどちらの要件を壊すかを明示して並べます。

(a) 用量・剤型・メーカー名がくっつく (取りこぼしと誤検出の両方)

バイアスピリン錠100mg「サワイ」
リクシアナOD錠30mg

マスタは バイアスピリン / リクシアナ の 1 語だけ持っているので、素朴 includes は片側包含にはなる。が、剤型記号を含む長い raw を素朴に扱うと、メーカー名 サワイ トーワ を含む raw と別の短い薬剤名が誤マッチする経路も生まれる。「マッチする方向を制御しないと両方壊れる」パターン。

(b) ひらがな・カタカナ・全角半角の混在 (取りこぼし)

ばいあすぴりん / バイアスピリン / ﾊﾞｲｱｽﾋﾟﾘﾝ

表記揺れで単純比較が外れる → 見逃し。

(c) OCR の形似誤読 (取りこぼし)

シアリス → ツアリス   (シ↔ツ)
アスピリン → アヌピリン    (ス↔ヌ)

擦れた薬手帳・角度の悪い撮影で Vision API が 1〜2 字誤読する。これを吸収しないと該当患者を丸ごと見落とす。

(d) 濁点・半濁点の 1 字差で別薬剤が存在する (誤検出)

プラビックス vs ブラビックス
シアリス vs ジアリス

「濁点差くらい許せば見逃しが減る」と安易に思うと、実在する全然別の薬剤に化ける。 recall のために閾値を緩めると precision が破綻する典型例。

(e) 括弧付き情報 (取りこぼし)

バイアスピリン (アスピリン)
リクシアナ (エドキサバン)

括弧内は一般名・製造メーカーの併記。剥がしておかないと素朴包含が失敗する。

(f) 配合剤 + mono 剤の共存 (誤検出)

サクビトリル・バルサルタン → mono の バルサルタン も併記マッチしてしまう
デノスマブ・プラリア    → デノスマブ・ランマーク (別剤名) に化ける

配合剤の名前は複数の一般名を「・」で連ねる規則があります。単純に「バルサルタン」を含むかで検索すると、サクビトリル・バルサルタンを服用している患者に対して「mono のバルサルタン (配合剤の弟分)」も検出される。患者は片方だけ内服しているので、これは実質的な誤検出。

2. 骨格: normalize → wildcard 索引 → 3 pass scoring

上の 6 パターンを個別の regex で潰していくと、「別剤なのに 1 字差」型のケース (プラビックス vs ブラビックス、バルサルタン vs サクビトリル・バルサルタン) を安全に扱えなくなる。骨格をこうします。

raw text (1 行)
    │
    ▼
[Step 1] normalize
    NFKC → ひらがな→カタカナ → 漢字 lookalike (口→ロ 等)
    → 濁点/半濁点 lookalike (ハ° / ハ" / smart quotes / prime / 結合 mark)
    → 長音 strip (ー↔''、 ーー↔ー) → 小書き→大書き
    │
    ▼
[Step 2] segmentByKatakana
    非カタカナ を \n (= ワイルドカード) に 置換
    「バイアスピリン錠100mg「サワイ」」 → 「バイアスピリン\nサワイ」
    │
    ▼
[Step 3] 3 pass matching
    (A) exact indexOf       ← 正確な一致 (score = 2 * len)
    (B) scored 位置合わせ    ← CHAR_ALTS で「似た文字」 に 1 点
    (C) edit distance ≤ 1   ← char 挿入/欠落 の 拾い上げ
    │
    ▼
finding { drug, matchVia, matchedSpan, score }

「括弧の中身」「用量」「剤型」は全て「非カタカナ = ワイルドカード」に含まれるので、個別 regex で事前に剥がす処理は必要ない (この抽象化が効く理由は節 4 で詳述)。

以下、各 step を実コードとともに見ていきます。各 step の設計判断は「recall を上げる方向」と「precision を守る方向」の両方が絡み合っているので、その都度どちらの要件にどう寄与しているかを明示します。

3. Step 1: normalize (recall の土台、順序が全て)

一番地味で、一番効きます。表記揺れを吸収して recall を確保する土台。マスタの薬剤名側も raw 側も同じ関数に通して比較する、それだけです。

function normalizeText(input) {
  if (typeof input !== 'string' || input === '') return ''
  let s = input.normalize('NFKC')
  s = hiraToKata(s)                          // ひらがな → カタカナ
  s = normalizeKanjiLookalike(s)             // 口/工/二/力 → ロ/エ/ニ/カ
  s = normalizeDakutenLookalikes(s)          // ハ° → パ、 ハ" → バ 等
  s = normalizeLongVowel(s)                  // ー / 一 / ― / − 等 を strip
  s = s.replace(SMALL_RE, c => SMALL_TO_LARGE[c] || c)  // 小書き → 大書き
  return s
}

判断ポイントは 6 つ。

(1) NFKC で全角半角・合成文字の揺れを吸収。 ﾊﾞｲｱｽﾋﾟﾘﾝ が バイアスピリン になる。 recall 側。

コラム: 濁点・半濁点まわりの静かな取りこぼし 2 種

(その 1) 半角濁点・半濁点が空白で離されているケース

半角の ﾊﾟ は ﾊ (U+FF8A) と ﾟ (U+FF9F) の独立した 2 コードポイントです。 NFKC は互換分解で ﾟ を結合半濁点 (U+309A) に変換し、 canonical composition で直前の ハ と合成して パ (U+30D1) に統一する — これが仕組みの上での期待動作。

ところが ﾊﾟ のように間に空白が挟まる入力だと、 NFKC の合成は「隣接した combining mark のみ合成」のルールで働くため、 ハ + 空白 + U+309A にしかならない。見た目は パ に見えても中身は 2 コードポイントのまま残る。マスタの パ (1 コードポイント U+30D1) と === 比較が silently 失敗し、静かな取りこぼしになる。

(その 2) OCR が濁点・半濁点を形似記号として読み取るケース

印字が擦れた薬手帳では、濁点 (゛ 二つの点) を " (ダブルクォート) や '' (アポストロフィ 2 個) 、半濁点 (゜ 小さな丸) を ° (度記号) や ○ (白丸) として OCR が読み取ることがあります。 NFKC は救ってくれない (別の文字として認識されるため canonical composition に載らない) 。

補正パターンは 2 系統に分けて安全に組みます。対策コードは (4) を参照。

(2) ひらがな → カタカナ変換。 医療系テキストは大抵カタカナ表記だが、 OCR がひらがな寄りに誤読するケース・paste でひらがなが混じるケースを救う。 code point オフセット + 0x60 の 1 行変換で済む。 recall 側。

(3) 漢字 → カタカナ (形似) の変換。 OCR が カタカナを見た目が似た漢字と誤認 するパターン: ロ → 口 (U+53E3 くち)、 エ → 工 (U+5DE5 こう)、 ニ → 二 (U+4E8C に)、 カ → 力 (U+529B ちから) 。これらを事前にカタカナに戻す。これを 濁点 / 長音の前に 実施するのが重要で、「口"」が「ロ"」になってから濁点処理に渡り、 lookalike と干渉しない。 recall 側。

(4) 濁点/半濁点 lookalike の吸収。 これが一番詰まる箇所。「印字が擦れて OCR が濁点マークだけ別の記号に読み替えた」ケースを救う。半濁点 lookalike は [ハヒフヘホ] の直後に限定 (可半濁カナがこの 5 音だけなので誤爆リスク極小)、濁点 lookalike は可濁カナ + 直後に仮名/行末の文脈で限定 (メーカー suffix の開きクォート アスピリン"サワイ" を誤って濁点に化けさせないため)。

const HANDAKU_TARGETS = 'ハヒフヘホ'
const DAKU_TARGETS    = 'カキクケコサシスセソタチツテトハヒフヘホウ'

// NFKC 後 の 「半濁点 の ように 見える char」 集合。 NFKC で 「空白+結合 mark」 に 分解される
// 元 char (˚ / ゜) の 結合 mark form も 含める
const HANDAKU_LOOKALIKES = /[°○◦゚̊゜˚]/

// NFKC 後 の 「濁点 の ように 見える char」 集合
//   " U+0022 / ' U+0027 ASCII クォート、  ゙ U+3099 / ゛ U+309B 結合・spacing 濁点、
//   ′ U+2032 / ″ U+2033 prime、  ‘ ’ “ ” smart quotes
const DAKU_LOOKALIKES = /["'゙゛′″‘’“”]/

function normalizeDakutenLookalikes(s) {
  // NFKC 由来 の 「空白 挟み」 を \s* で 吸収、 連続 lookalike (「ハ""」) を + で 吸収
  s = s.replace(new RegExp(`([${HANDAKU_TARGETS}])\\s*${HANDAKU_LOOKALIKES.source}+`, 'gu'),
    (_, kana) => String.fromCharCode(kana.charCodeAt(0) + 2))   // ハ→パ (+2)
  s = s.replace(new RegExp(`([${DAKU_TARGETS}])\\s*${DAKU_LOOKALIKES.source}+(?=[ァ-ヶー]|$)`, 'gu'),
    (_, kana) => String.fromCharCode(kana.charCodeAt(0) + 1))   // ハ→バ (+1)
  return s
}

recall 側 (OCR 誤読の救済) と precision 側 (誤変換の抑止) を、「左に可濁カナ」「右に仮名または行末」の 2 方向の文脈条件で挟み込んで両立。

(5) 長音記号 (ー) の統一と消失。 OCR は「ー」を別の dash 系記号と誤認したり、逆に読み落としたりする。一 (漢数字 1) / ― / - / − / – / — / ─ / ｰ / ーを 全て strip して「ーがあってもなくても同じ」に揃える。「エフピー」と「エフピ」が同じになる。 recall 側。

(6) 小書き → 大書きの統一。 OCR は「ッ」と「ツ」、「ャ」と「ヤ」を混同する。全部大書きに統一。「ゼップバウンド」 → 「ゼツプバウンド」、「マンジャロ」 → 「マンジヤロ」。 recall 側。

順序が重要: (3) 漢字 → (4) 濁点 lookalike → (5) 長音 strip → (6) 小書き→大書きの順。例えば (6) を先に実施すると「口"」が「口"」のまま (口が漢字で「ロ」になっていないので濁点 lookalike の対象外)、 (4) で「ロ"」 → 「ロ゛」を期待したいのに空振りする。

4. Step 2: segmentByKatakana (非 kata をワイルドカードに)

ここが骨格の核心。マッチング対象になる「薬剤名の識別情報」は カタカナ部分だけ に集中している、という観察が基盤。剤型 (錠 / カプセル / 皮下注)、用量 (100mg)、括弧内 (「サワイ」「メーカー名」)、中黒 (・)、空白、全てカタカナではない。

そこで、 normalize 済 text の非カタカナを全て \n (単一 delimiter) に置換する。

const KATA_RE = /[゠-ヺー-ヿ]/         // カタカナ 範囲 (中黒 U+30FB は 除外)
const NON_KATA_RE = /[^゠-ヺー-ヿ]+/gu   // + で 連続 非 kata を 単一 \n に

function segmentByKatakana(normalized) {
  return normalized.replace(NON_KATA_RE, '\n')
}

これで:

バイアスピリン錠100mg「サワイ」 → バイアスピリン\nサワイ
サクビトリル・バルサルタン → サクビトリル\nバルサルタン
マンジャロ皮下注2.5mgアテオス → マンジャロ\nアテオス

「非 kata は何であっても同じ」 = 事実上ワイルドカード。 STRIP_BRACKETS も STRIP_DOSE も STRIP_FORM も個別 regex は一切要らなくなる (「非 kata」と一括で扱える)。

5. Step 3: dict 索引 (compound + individual runs + isFullName filter)

各マスタ薬剤の name / brand_names / generic_brands / combination_brands / aliases を全て normalize + segmentByKatakana に通して、 2 種の key を生成する:

compound key: segmented form の全体 (「サクビトリル\nバルサルタン」)
individual run: 各 kata run (「サクビトリル」「バルサルタン」)

function buildDict(drugs) {
  const kataDict = []
  for (const drug of drugs) {
    const drugNameRawKataChars = extractSegmentedName(normalizeTextRaw(drug.name)).replace(/\n/g, '').length
    const candidates = [drug.name, ...brands, ...aliases]
    const drugKataEntries = new Map()
    for (const c of candidates) {
      const normalized = normalizeText(c)
      const compound = extractSegmentedName(normalized)       // 「サクビトリル\nバルサルタン」
      const runs = extractAllKatakanaRuns(normalized, 2)      // ["サクビトリル", "バルサルタン"]
      const totalKataChars = compound.replace(/\n/g, '').length
      const isFromName = c === drug.name
      const keys = []
      if (compound.indexOf('\n') >= 0 && totalKataChars >= 2) {
        keys.push({ key: compound, isFullName: isFromName && totalKataChars === drugNameRawKataChars })
      }
      for (const run of runs) {
        keys.push({ key: run, isFullName: isFromName && run.length === drugNameRawKataChars })
      }
      // drug 内 で 同 key は isFullName=true 昇格 を 優先 して 1 件
      for (const { key, isFullName } of keys) {
        if (key.length < 2) continue
        const prev = drugKataEntries.get(key)
        if (prev && prev.isFullName) continue
        drugKataEntries.set(key, { key, drug, original: c, isDrugName: isFromName, isFullName })
      }
    }
    for (const entry of drugKataEntries.values()) kataDict.push(entry)
  }
  kataDict.sort((a, b) => b.key.length - a.key.length)   // 長い順
  return { kataDict }
}

判断ポイントは 2 つ。

(1) 「compound + individual runs」の併用。 compound key (「サクビトリル\nバルサルタン」 13 char) は長いのでソートの先頭に来て、「サクビトリル・バルサルタン」という完全な OCR 入力に 最長一致 して先取りする。これで mono 剤の「バルサルタン」と誤マッチしない (compound が消費した領域は blank_out され、 mono の individual run キーはそこを拾えなくなる)。

一方で、短い OCR 入力 (「マンジャロ皮下注」だけでアテオスを含まない場合) も個別 run 「マンジヤロ」で拾える。「両方の経路を用意して、長い方を常に先に走らせる」のが味噌。

(2) isFullName filter で mono / compound の誤爆抑止。 dict 内で同 key を複数剤が持つケース (例「バルサルタン」が mono バルサルタンと配合剤サクビトリル・バルサルタンの両方に出現) は、「その剤の drug.name 全 kata content を 完全にカバーする 側」を優先する。 mono バルサルタンにとっては「バルサルタン」 key = 全 kata content なので isFullName=true、配合剤にとっては個別 run でしかないので isFullName=false。

function groupDictByKey(dict) {
  const map = new Map()
  for (const entry of dict) {
    if (!map.has(entry.key)) map.set(entry.key, [])
    map.get(entry.key).push(entry)
  }
  // 同 key に isFullName=true が 1 件 でも あれば その 集合 に 絞る
  for (const [key, entries] of map) {
    const fulls = entries.filter(e => e.isFullName)
    if (fulls.length > 0 && fulls.length < entries.length) map.set(key, fulls)
  }
  ...
}

これで「バルサルタン」単独入力は mono だけに hit、「サクビトリル・バルサルタン」は compound key で配合剤だけに hit、となる。 precision 側。

6. Step 3 の 3 pass: exact → scored → fuzzy

各段の意図はこう:

Pass A (exact indexOf): normalize 後の完全一致 (score = 2 * len)。最速パスで最高優先。
Pass B (scored 位置合わせ): CHAR_ALTS で「self=2 点、 alt=1 点、 mismatch=0 点 (却下)」の位置合わせ scoring。 lookalike (ソ↔ン、濁点対ハ↔バ↔パ等) を拾う。
Pass C (fuzzy edit distance ≤ 1): OCR の char 挿入/欠落の拾い上げ。長め key に限定 (fuzzyMinLen=5)。

段を分ける意味は、「別 drug の fuzzy が実剤の exact を先取りする」事故を防ぐため。例えば バルデナフィル 入力で シルデナフィル の fuzzy (シ↔バ 1 char) が先に走ってしまうと バルデナフィル 自身の exact 一致が空振りする。全 key の exact を走らせてから fuzzy、という 2 段順序で誤マッチを抑止する。

6.1 scored 位置合わせの中身

function charMatchScore(ocrChar, dictChar) {
  if (ocrChar === dictChar) return 2                       // self match
  const alts = CHAR_ALTS[ocrChar]
  if (alts && alts.indexOf(dictChar) >= 0) return 1        // alt match
  return 0                                                  // mismatch → reject
}

function scoredSubstringSearch(haystack, needle) {
  let best = null
  for (let start = 0; start <= haystack.length - needle.length; start++) {
    let score = 0, ok = true
    for (let j = 0; j < needle.length; j++) {
      const s = charMatchScore(haystack[start + j], needle[j])
      if (s === 0) { ok = false; break }
      score += s
    }
    if (!ok) continue
    // 前後 が \n or 端 = 境界 チェック
    const before = start === 0 || haystack[start - 1] === '\n'
    const after = start + needle.length === haystack.length || haystack[start + needle.length] === '\n'
    if (!before || !after) continue
    if (!best || score > best.score) best = { start, matchLen: needle.length, score }
  }
  return best
}

「全 char で self か alt が一致する」を必須条件にして、 total score が最大の位置を返す。 mismatch (score=0) が 1 char でもあればその位置は却下。

これが「OCR 結果とぴったり一致の剤が lookalike で一致の剤より高得点になり、誤マッチを抑止する」の実体。

6.2 CHAR_ALTS (「似た文字」テーブル)

字形形似 pair と濁点/半濁点 pair の 2 系統を収録:

const CHAR_ALTS = {
  // (1) 字形 形似 pair
  'ソ': ['ン', 'ゾ'],  'ン': ['ソ'],
  'シ': ['ツ', 'ジ'],  'ツ': ['シ', 'ヅ'],
  'ノ': ['リ'],        'リ': ['ノ'],
  'コ': ['ユ', 'ゴ'],  'ユ': ['コ'],
  'ク': ['ワ', 'グ'],  'ワ': ['ク'],
  'チ': ['テ', 'ヂ'],  'テ': ['チ', 'デ'],
  'マ': ['ヌ'],        'ヌ': ['マ'],
  'オ': ['ホ'],        'ホ': ['オ', 'ボ', 'ポ'],
  // (2) 濁点/半濁点 pair
  'ハ': ['バ', 'パ'],  'バ': ['ハ', 'パ'],  'パ': ['ハ', 'バ'],
  'ヒ': ['ビ', 'ピ'],  'ビ': ['ヒ', 'ピ'],  'ピ': ['ヒ', 'ビ'],
  'フ': ['ブ', 'プ'],  'ブ': ['フ', 'プ'],  'プ': ['フ', 'ブ'],
  'ヘ': ['ベ', 'ペ'],  'ベ': ['ヘ', 'ペ'],  'ペ': ['ヘ', 'ベ'],
  'ボ': ['ホ', 'ポ'],  'ポ': ['ホ', 'ボ'],
  'カ': ['ガ'],  'ガ': ['カ'],  'キ': ['ギ'],  'ギ': ['キ'],  'グ': ['ク'],
  'ケ': ['ゲ'],  'ゲ': ['ケ'],  'ゴ': ['コ'],  'サ': ['ザ'],  'ザ': ['サ'],
  'ジ': ['シ'],  'ス': ['ズ'],  'ズ': ['ス'],  'セ': ['ゼ'],  'ゼ': ['セ'],
  'ゾ': ['ソ'],  'タ': ['ダ'],  'ダ': ['タ'],  'ヂ': ['チ'],  'ヅ': ['ツ'],
  'デ': ['テ'],  'ト': ['ド'],  'ド': ['ト'],  'ウ': ['ヴ'],  'ヴ': ['ウ'],
}

これで「ホナロン (ボナロン半濁点消失)」がアレンドロン酸 (ボナロンはアレンドロン酸の商品名) に scoring 経由で hit する。 exact でも fuzzy でも拾えていないケースを scoring が拾う。

「ぴったり一致の剤」が「lookalike で一致の剤」より高得点になる性質が効いて、実剤の名前が OCR 入力に完全一致する場合はそちらが常に優先される。「全 char が self or alt」という必須条件で「短い候補が距離 1 で誤マッチする」型の罠を構造的に防ぐ。

7. kanji route: 純粋 kanji alias 用の別経路

「朝鮮人参」「銀杏葉」「高麗人参」など、 カタカナが全く含まれない alias がマスタにあります (漢方系)。これらは kata route (compound / individual run) では索引化できない (kata run が 0 個)。

対策として「kata run が皆無の候補」だけに対して、 normalize 後の全文を key にする 別 route を用意する:

function isKanjiRouteCandidate(normalized) {
  const runs = extractAllKatakanaRuns(normalized, 2)
  return runs.length === 0
}

function findMatches(text, dict, options = {}) {
  ...
  // ── kanji pass ── normalize 後 の 全体 に substring match、 hit した 領域 は
  // \n で blank_out して kata route の 誤爆 を 抑止
  let normalized = normalizeText(text)
  for (const entry of kanjiDict) {
    const key = entry.key
    const idx = normalized.indexOf(key)
    if (idx < 0) continue
    findings.push({ drug: entry.drug, ..., matchVia: 'kanji', score: 2 * key.length + 1 })
    normalized = normalized.substring(0, idx) + '\n'.repeat(key.length) + normalized.substring(idx + key.length)
  }
  // ── kata pass ── blank_out 済 の normalized を segment。 通常 の 3 pass
  let working = segmentByKatakana(normalized)
  ...
}

対象は純粋 kanji のみで、「低分子ヘパリン」「結合型エストロゲン」「α-トコフェロール」のような「先頭は非 kata だが kata run が存在する」 alias は kata route 側で「先頭に最も近い連続カタカナを抽出」で処理する。これは曖昧マッチ (低分子ヘパリン → エノキサパリンとヘパリンナトリウムが両方 hit する等) が残るが、データの制約と割り切り、別 route を増やさない方針。

8. 実装上の 3 つの補足 (静かな誤検出の根絶と UI 信頼性)

8.1 ASCII 英字略号は自動的に除外される

マスタには EPA (エイコサペンタエン酸)、 OC (経口避妊薬) といった英字略号を別名に持つ薬剤があります。 raw 側の記号ノイズ EP」 (お薬手帳の縦線・鍵括弧が OCR で 」 になる) と距離 1 でマッチすると誤検出になりかねない。

この設計では そもそも ASCII は非 kata として segmentByKatakana で \n になり、 index の key にならない。明示的な除外コードは不要。「アーキテクチャで防ぐ」型の解決。

8.2 「マスタにない薬剤」による誤マッチは scoring が自動で落とす

オメプラゾール (胃薬)、 マイスリー (睡眠導入剤) はマスタに無い非対象薬剤です。素朴 impl では raw 側の プラゾール 部分文字列が対象内の プラノバール (経口避妊薬) と距離 2 で誤マッチする経路がありました。これが「静かな誤検出」の典型。

この設計では プラゾール は 5 char、 プラノバール は 6 char、 position-aligned scoring で 3 char 目が ゾ vs ノ (CHAR_ALTS になし → score=0 → 却下) の段で落ちる。 fuzzy edit distance ≤ 1 も距離が大きすぎて落ちる。 構造的に誤マッチが発生しない ため、非対象辞書の blank_out は不要。

8.3 span 復元 (highlight UI の前提)

判定結果を UI に表示する時、「この行のこの部分がバイアスピリン」とハイライトします。現場のツールで「なぜこの判定が出たか」が説明できない = 現場は信用しない。 span を返すことで 根拠可視化 しています。

matchedText は normalize 後の形 (「ゼップ」 → 「ゼツプ」、「ウゴービ」 → 「ウゴビ」)。 raw の生文字と差があるので、単純な raw.indexOf(matchedText) は null を返すケースがある。対策は「normalize(raw) 内で位置を特定 → raw を 1 char ずつ進めて normalize 位置と対応させて raw 上の開始/終端を復元」:

function computeSpan(raw, finding) {
  const target = finding.matchedText
  // Fast path: raw に そのまま 存在
  let idx = raw.indexOf(target)
  if (idx >= 0) {
    let end = idx + target.length
    // 末尾 に normalize で 消失 する char (ー 等) が 続く 場合 は 前方 延長
    while (end < raw.length && normalizeText(raw[end]) === '') end += 1
    return { start: idx, end }
  }
  // Slow path: normalize 経由 の back-projection
  const normalized = normalizeText(raw)
  const nIdx = normalized.indexOf(target)
  if (nIdx < 0) return null
  const nEnd = nIdx + target.length
  let rawPos = 0, normPos = 0, startInRaw = -1, endInRaw = -1
  while (rawPos < raw.length) {
    if (normPos >= nIdx && startInRaw < 0) startInRaw = rawPos
    if (normPos >= nEnd) { endInRaw = rawPos; break }
    normPos += normalizeText(raw[rawPos]).length
    rawPos += 1
  }
  ...
  return { start: startInRaw, end: endInRaw }
}

一般化された normalize 逆引きで全変換 (小書き→大書き、長音 strip、 dakuten lookalike、 hira→kata、 NFKC) に一括対応する。個別パターン regex は不要。

9. まとめ: recall と precision、どちらも譲らない設計

recall / precision のどちらに寄与するかで対策マップを整理します。

対策	recall 寄与	precision 寄与
NFKC + ひらがな→カタカナ + 漢字 lookalike + 長音 strip + 小書き→大書き	○ (表記揺れ 6 系統の吸収)	—
濁点/半濁点 lookalike の文脈条件付き変換	○ (OCR 誤読救済)	○ (メーカー suffix 誤変換の回避)
segmentByKatakana (非 kata を \n = ワイルドカードに)	○ (剤型/用量/括弧の一括吸収)	—
「compound key + individual run」の併用 (長い順索引)	○ (部分入力の拾い上げ)	○ (最長一致で配合剤が mono 剤に先取り)
isFullName filter (同 key の剤内で全 kata cover を優先)	—	○ (mono / compound の誤爆抑止)
3 pass 順 (exact → scored → fuzzy) の分離	—	○ (別 drug の fuzzy が実剤の exact を先取りする事故回避)
CHAR_ALTS scoring (self=2 alt=1、全 char 一致必須)	○ (形似 + 濁点 pair 救済)	○ (「ぴったり一致」が高得点で誤マッチ抑止)
kanji route (純粋 kanji alias の全文一致)	○ (漢方系 alias)	—
span 復元の normalize 逆引き	—	— (UI 信頼性の補助)

「recall のために normalize を汎用化する時、必ず別軸の制約 (compound の最長一致、 isFullName filter、 CHAR_ALTS の全 char 一致) を同時に入れる」が全体を貫く原則。「非 kata = wildcard」という抽象化で剤型/用量/括弧/中黒を一括処理するのが骨格。

依存パッケージゼロ、単一ファイル ~700 行の JavaScript で成立します。バックエンド側には同等ロジックの PHP 版を持ち、両者は同じ入力に対して同じ finding を返すよう unit test で回帰させています (frontend / backend で挙動が分岐すると、それ自体が新たな見落とし源になるため)。

医療系日本語 OCR の後段は、判定を出すかどうか以前に「静かな誤検出を出さないための地味な足元固め」が主戦場でした。「アーキテクチャで構造的に防ぐ」型の設計 = 「normalize → wildcard 索引 → 3 pass scoring」の骨格が、同種のアシストツールを作る人にひとつの参考になれば幸いです。

参考リンク