S_ソールナビゲーター【障碍福祉事業向けシステム】

1. 背景

現在の OCR は、受給者証・手帳・本人確認資料・アセスメントシートなどの画像や PDF を Google Cloud Vision API に送って読み取っている。受給者証などは要配慮個人情報なので、外部に送らずに読めるならそのほうが望ましい。利用料もかからなくなる（費用の可視化は #119）。

Rust 製の OCR ライブラリ「pure-onnx-ocr」v0.2.0 は、PaddleOCR の PP-OCRv6 モデルを Python なしで動かせる。WebAssembly にしてブラウザだけで動かすこともでき、作者のデモでは日本語も読めている。作者の計測では、v6 small はネイティブ 8 スレッドで 1 枚あたり約 1 秒、ブラウザ（1 スレッド）では約 7.7 秒だった。

Vision より遅くなる見込みだが、アップロードから OCR までをバックグラウンド処理にすれば待ち時間は許容できると考えている。

1. スコープ

1. 精度の比較: 匿名化した実書類のサンプル（受給者証、通知書、手書きのアセスメントシートなど）を Vision と PP-OCRv6（small / medium）で読ませ、項目を正しく取り出せる率を比べる
2. 実行場所の検討: ブラウザで動かす（WASM）か、サーバーで動かす（ネイティブのバイナリをキューから呼ぶ）か
3. 処理時間の計測: 書類 1 枚あたり・PDF 1 件あたりの時間（PDF をページごとに画像にする処理も含む）
4. バックグラウンド化の設計: アップロードしたら OCR をジョブとして実行し、終わったら確認画面に結果を出す流れ
5. エンジン切替の設計: Vision とローカル OCR を、費用と時間のどちらを優先するかで切り替えられるようにする（事業所ごとの設定にするか、書類種別ごとにするか）

1. 実行計画

- [ ] 検証用の匿名化サンプルをそろえる
- [ ] pure-onnx-ocr でサンプルを読み、Vision の結果と比べる表を作る
- [ ] 結果を docs/requirements/ に検証メモとしてまとめ、採否と実行場所を決める
- [ ] 採用する場合は、バックグラウンド化と切替の設計を docs に書いてから、実装 Issue に分ける

1. 依存・未決事項

- 関連: #119（外部 API の費用の可視化）、#21（実書類での OCR 動作検証）
- 未決: 手書きをどこまで読めるか（作者の検証は印刷文字だけ）
- 未決: 今の項目抽出（氏名・番号・期間など）が Vision の返すデータ形式に依存している部分の洗い出し
- 未決: ブラウザで動かす場合、モデルファイルの配信サイズと端末の性能

1. AC（完了条件）

- [ ] 匿名化サンプルで Vision とローカル OCR の精度・処理時間を比べた結果が docs にある
- [ ] 採否と実行場所（ブラウザ／サーバー）が docs に決定として書かれている
- [ ] 採用する場合、バックグラウンド処理とエンジン切替の設計が docs にあり、実装 Issue が起票されている

参考: pure-onnx-ocr v0.2.0（PP-OCRv6 対応・WASM デモあり）

GitHub: https://github.com/iplusone/soulnavigator/issues/229