外部AIサービスへの送信を前提にせず、導入者の環境で処理できる構成へ。
OPENKYC-JPセルフホスト・オープンソース
日本の本人確認を、自分たちで運用できるように。
身分証と顔を外部へ送らず、自分のインフラの中だけで完結できる、オープンソースの本人確認基盤。
本人確認には、まだ大きな選択肢がない。
本人確認が必要になったとき、多くのサービスは外部のeKYC事業者へ身分証画像や顔画像を送り、API利用料を払って判定を受けます。
導入しやすい一方で、機微な情報をどこで処理するか、費用をどう持続させるか、サービスに必要な情報だけを取得できるかは、外部サービスの設計に左右されます。
OCRや顔認証のOSSはあります。しかし、同意、撮影、書類検証、Liveness、不正検知、判定、監査、削除までを一つの基盤として安全につなぐものは、ほとんどありません。
部品はある。本人確認としてつなぐ基盤が足りない。
OpenKYC-JPは、既存の認識技術を必要に応じて使いながら、その間にある設計・判定・監査・削除を一つの基盤にまとめます。
既存の部品
OCR顔認証LivenessIC / NFC
OpenKYCJP
理由を説明できる本人確認結果
何を大事につくるか。
本人確認は、便利さと安全とプライバシーのどれかを削れば簡単になります。OpenKYC-JPは、その3つを同時に守ることを設計の前提にします。
設定次第で極端に弱くならないよう、目的に応じた安全な標準フローを用意。
結果だけでなく、審査や再撮影になった理由をReason Codeとして残す。
撮影から判定までを、一つの流れに。
単なるOCRツールではなく、本人確認を始めてから結果を返すまでを一貫して扱えるプラットフォームを目指します。
01 書類の読み取り
日本の書類を、書類ごとに正しく読む。
券面の位置や和暦、番号体系を書類ごとに踏まえて解析し、後続の照合や判定にそのまま使える構造化データへ整えます。申告された氏名でOCR結果を書き換えず、独立して読み取ってから照合します。
02 複数の根拠
一つのAIスコアに、本人確認を委ねない。
書類・顔・Liveness・改ざん・ICを、それぞれ独立した根拠として扱います。平均点ではなく、明確なルールとリスクスコアで判定し、どの根拠でその結論になったかを残します。
03 プライバシー
集める量ではなく、必要な結果から設計する。
原画像や氏名をすべてサービスへ渡すのではなく、「本人確認済み」「18歳以上」など目的に必要な結果だけを返せる形へ。原画像は既定で永続保存せず、保存期間を過ぎたら自動削除します。
既存の部品を、本人確認へ組み上げる。
「既存OSSを接続しただけ」にはしません。認識技術は必要に応じて部品として使い、本人確認として成立させる中核エンジンを自分で設計・実装します。
使う既存技術
- OCRPaddleOCR (PP-OCRv5)
- 顔認識モデル交換可能なProvider方式
- 顔ランドマークMediaPipe
- 画像処理OpenCV
自分で設計・実装する中核
- 書類解析エンジン券面レイアウト・和暦・番号体系を書類ごとに解析し整合を取る
- 不正・改ざん検知再撮影・改ざん・レイアウト異常を複数の信号で検知する
- Livenessエンジンチャレンジ生成・応答検証・リプレイ対策を統合する
- 判定エンジン根拠を統合し、ルールとReason Codeで結論を出す
- フロー生成書類・端末・要求強度から最適な手順を組み立てる
- 保証レベル / Privacy確認の強さを設計し、原画像を極力見せない審査をつくる
日本の書類を、日本の文脈で。
最初から全部をうたわず、運転免許証の読み取りから実装と評価を始めます。IC・電子署名の検証は書類ごとに段階的に対応します。
運転免許証
券面OCR・レイアウト検証・顔抽出
最初のMVPマイナンバーカード
表面の必要項目だけを処理
v1対象在留カード
券面・IC・ECDSA電子署名を照合
段階対応パスポート
MRZ・顔画像・ePassport(NFC)
段階対応「本人だ」と、どれだけ強く言えるか。
スコアとは別に、どれだけ強い方法で本人確認できたかを5段階で表します。導入サービスは「最低レベル3以上」のように、必要な強度を指定できます。
- L1
書類画像
券面の解析のみ
- L2
＋ 顔照合
券面の顔と本人が一致
- L3
＋ Liveness / Fraud
なりすまし・改ざん耐性
- L4
＋ IC / NFC
券面とICチップの整合
- L5
＋ 電子署名
暗号学的に真正性を確認
自分のサーバーで、丸ごと動かせる。
SaaSではなくOSSとして公開します。導入者は自分のインフラに立ち上げ、身分証・顔・判定のすべてを自分の管理下で処理できます。
- docker compose だけで基本環境が起動する
- 身分証・顔画像を外部へ送らず自分の環境で完結
- REST API と Webhook でサービスに組み込める
件数が増えるほど、差が開く。
外部eKYCは「月額基本料 + 1件ごとの従量課金」が基本。件数に比例して費用が伸びます。自前のOpenKYC-JPはサーバー代が中心で、件数が増えても大きくは変わりません。
試算 ―― 各社の公開単価(基本フロー・為替¥150/$換算)に基づく:Stripe Identity ≈ $1.50/件(月額なし)、Sumsub $1.35/件 + 月$149、Veriff $0.80/件 + 月$49、Didit 月500件無料 + $0.33/件。国内のTRUSTDOCK・LIQUID等は料金非公開(要問い合わせ)のため、公開料金のある海外サービスを参考にしています。Diditのように無料枠が手厚く、少件数ではOpenKYCより安い外部もあります。それでも外部サービスは身分証・顔を先方へ送る前提 ―― OpenKYCの主眼はコストだけでなく「原本を自分の環境から出さない」ことにあります。この件数帯(〜3,000件/月)は各社ほぼ公開料金どおり(例:Stripeは3,000件で $1.50×3,000 = $4,500 ≈ ¥67万)。大量利用時の個別割引は非公開のため未反映、為替は¥150/$、OpenKYC(自前)のサーバー代¥1.5万は概算です。
今の限界を、研究で押し広げる。
基本フローを動かすだけでは越えられない、本人確認の難しい部分を研究・開発のテーマとして扱います。今の課題と、それにどう取り組むかを分けて考えます。
課題
少ない実データでの不正・改ざん検知
アプローチ
架空のテストカードを角度・反射・再撮影などで変形した合成データと複数信号の統合で、画像だけに依存しない真正性評価を研究する。
課題
なりすましに強いLiveness
アプローチ
受動・能動の判定と顔照合を一度のセッションに束ね、ランダムなチャレンジ応答・時系列解析・リプレイ対策を設計する。
課題
ICによる暗号学的な本人確認
アプローチ
在留カードのECDSA署名やパスポートのPassive Authenticationを検証し、券面とICチップの整合を暗号学的に確認する。
課題
管理者にも原画像を見せない審査
アプローチ
まず根拠だけで判断し、必要な領域だけを段階的に開示するPrivacy-preserving Reviewを実装する。
まず、動く一歩から。
現在は基盤設計の段階です。製品機能はこれから実装し、評価結果とともに公開していきます。
- 01NOW
基盤設計
Web UI、API、データモデル、安全な既定値
- 02NEXT
書類の読み取り
運転免許証の撮影、OCR、構造化JSON
- 03LATER
確認プラットフォーム
顔照合、Liveness、不正検知、判定、手動審査
よくある質問。
犯収法に対応していますか?
犯罪収益移転防止法(犯収法)が定めるeKYCの本人確認方式 ―― ICチップ読み取り、身分証画像+セルフィー 等 ―― に対応することを目指します。ただし最終的な適合の判断と記録の保存は特定事業者(導入者)側の責任であり、これは法的助言ではありません。
個人情報・プライバシーはどう扱いますか?
身分証・顔画像・氏名などは個人情報で、顔認証データは個人識別符号にあたります。OpenKYC-JPはセルフホスト型で、原本を外部へ送らず導入者の環境で処理し、保存期間を過ぎたら自動削除できる設計にすることで、個人情報保護法が求める安全管理措置を導入者が守りやすくします。
マイナンバー(個人番号)は収集しますか?
収集しません。マイナンバーカードは表面の必要項目(氏名・住所・生年月日・顔)だけを対象とし、裏面の個人番号は通常の本人確認では扱わない設計です。番号法の重い義務を設計段階で回避しています。
セルフホストでも法令に対応できますか?
できます。犯収法が定めるのは「確認方式」と「記録の保存」であって、ソフトウェアがどこで動くかは問われません。むしろ自前運用のほうが、データを自分の管理下に置けます。
どの書類に対応しますか?
運転免許証から着手し、マイナンバーカード・在留カード・パスポートへ段階的に対応します。IC・電子署名の検証は書類ごとに順次進めます。
外部のeKYCサービスと何が違いますか?
最大の違いは、身分証や顔を外部へ送らず、自分のインフラの中だけで確認を完結できること。加えて、件数が増えるほどコスト面でも有利になります。
今すぐ使えますか? オープンソースですか?
まだ使えません。現在は基盤設計の段階で、まず運転免許証の読み取りから公開していきます。OSSとして公開予定で、docker compose で自分のインフラに立ち上げられることを目指します(ライセンスは準備中)。