結論から言うと、PP-OCRv6は小規模SaaSでも即使える水準に来た。
Hugging Faceに上がったPaddleOCRの最新モデル、PP-OCRv6を読んだ。パラメータ数が1.5Mから34.5Mまで三段階あって、一番軽いtinyは1.5Mパラメータでエッジデバイスでも動く。一番重いmediumでも認識精度83.2%、前世代比で+5.1ポイント改善。50言語対応で、日本語・中国語繁体字・英語もカバーしている。
これを読んで最初に思ったのは、「ライセンス費用で外部ベンダーに払ってた分が消える」という話だ。うちは顧客がアップロードする請求書や契約書のテキスト抽出に、月で数十万円規模の外部OCRサービスを使っている。精度の問題で乗り換えを躊躇していたが、medium tierの認識精度83.2%というのは、実用域の話だ。
うちのSaaSは従業員8人、ARRでまだ数千万円台のステージだ。外部OCRへの支出は固定費として重くのしかかっている。投資家との対話でも「インフラコストの最適化」は必ず突っ込まれるポイントで、先月のVC面談でも同じ質問が出た。そのとき自分は「現状把握中です」と曖昧に答えてしまった。正直、代替手段の調査が後回しになっていた。
PP-OCRv6がOSSで使えて、ONNX RuntimeやTransformersバックエンドでも動くと知って、状況は変わった。外部API依存を段階的に剥がせる選択肢が現実的になってきた。ROIの計算は単純で、インフラに移行してもサーバーコストが月数万円以下に収まるなら、年換算で数百万円の差が出る。その分をプロダクトエンジニアの採用に回したい。
うちのエンジニアは今3人。バックエンド寄りが2人、フルスタック1人という構成だ。PP-OCRv6はpip install paddleocr一発で動くと記事に書いてあった。推論コードも数行で済む構造になっている。これなら既存メンバーで1〜2スプリントで検証が回せる。新たに機械学習エンジニアを採用しなくていい。
採用コストは1人あたり最低でも年収500万円以上のオファーになる。今のステージでそこに張るより、既存チームでポン置きできるモデルを使い倒す方がROIは高い。競合の話を先月聞いた。同じ領域で戦っている別のSaaSが、OCR処理をすでにオープンモデルに切り替えて、浮いたコストをセールスヘッドの採用に当てたらしい。GTM強化にコストを振った形だ。悔しいが、筋のいい判断だと思う。
まず今週中にエンジニアにPP-OCRv6_smallで検証環境を立てさせる。tinyとsmallの精度差を実際のデータで確認したい。うちの顧客が上げてくる書類は日本語の手書き混じりも多いので、ベンチマークのスコアがそのまま使えるかは確かめる必要がある。
その結果次第で、Q3中に外部OCR依存を50%以下に落とすことを目標に設定する。次回の投資家アップデートで「インフラコスト改善のマイルストーン達成」として報告できるようにしたい。
先月「現状把握中」と答えた質問に、今度はちゃんとした数字で返せる。それだけで十分な動機になる。
Hugging Faceに上がったPaddleOCRの最新モデル、PP-OCRv6を読んだ。パラメータ数が1.5Mから34.5Mまで三段階あって、一番軽いtinyは1.5Mパラメータでエッジデバイスでも動く。一番重いmediumでも認識精度83.2%、前世代比で+5.1ポイント改善。50言語対応で、日本語・中国語繁体字・英語もカバーしている。
これを読んで最初に思ったのは、「ライセンス費用で外部ベンダーに払ってた分が消える」という話だ。うちは顧客がアップロードする請求書や契約書のテキスト抽出に、月で数十万円規模の外部OCRサービスを使っている。精度の問題で乗り換えを躊躇していたが、medium tierの認識精度83.2%というのは、実用域の話だ。
コスト構造に直撃する話だと判断した
うちのSaaSは従業員8人、ARRでまだ数千万円台のステージだ。外部OCRへの支出は固定費として重くのしかかっている。投資家との対話でも「インフラコストの最適化」は必ず突っ込まれるポイントで、先月のVC面談でも同じ質問が出た。そのとき自分は「現状把握中です」と曖昧に答えてしまった。正直、代替手段の調査が後回しになっていた。
PP-OCRv6がOSSで使えて、ONNX RuntimeやTransformersバックエンドでも動くと知って、状況は変わった。外部API依存を段階的に剥がせる選択肢が現実的になってきた。ROIの計算は単純で、インフラに移行してもサーバーコストが月数万円以下に収まるなら、年換算で数百万円の差が出る。その分をプロダクトエンジニアの採用に回したい。
採用観点で見ると、実装コストも読める
うちのエンジニアは今3人。バックエンド寄りが2人、フルスタック1人という構成だ。PP-OCRv6はpip install paddleocr一発で動くと記事に書いてあった。推論コードも数行で済む構造になっている。これなら既存メンバーで1〜2スプリントで検証が回せる。新たに機械学習エンジニアを採用しなくていい。
採用コストは1人あたり最低でも年収500万円以上のオファーになる。今のステージでそこに張るより、既存チームでポン置きできるモデルを使い倒す方がROIは高い。競合の話を先月聞いた。同じ領域で戦っている別のSaaSが、OCR処理をすでにオープンモデルに切り替えて、浮いたコストをセールスヘッドの採用に当てたらしい。GTM強化にコストを振った形だ。悔しいが、筋のいい判断だと思う。
次にやること
まず今週中にエンジニアにPP-OCRv6_smallで検証環境を立てさせる。tinyとsmallの精度差を実際のデータで確認したい。うちの顧客が上げてくる書類は日本語の手書き混じりも多いので、ベンチマークのスコアがそのまま使えるかは確かめる必要がある。
その結果次第で、Q3中に外部OCR依存を50%以下に落とすことを目標に設定する。次回の投資家アップデートで「インフラコスト改善のマイルストーン達成」として報告できるようにしたい。
先月「現状把握中」と答えた質問に、今度はちゃんとした数字で返せる。それだけで十分な動機になる。