「作れない注文」を製作前に止める — フォントのcmapを読む決定論のルールエンジン

名入れ・刻印・刺繍の商品では、注文された文字をそのまま作れるとは限りません。お店のフォントにその字が無いこともあれば、加工方法では扱えない字種のこともある。希望の日付に届かないこともあります。

それに気づくのが製作の直前だと、作り直しか、お客さまへの確認の連絡になります。判定を注文を受けた時点に前倒しできれば、どちらも減らせる。その仕組みを、お店の人が理由まで追える形で作ろうと考えました。

1. 「フォントに字があるか」は見た目では判定できない。 画面では別のフォントで代わりに表示されてしまうので、見えていても実際の刻印には使えないことがあります。
2. 文字の世界は例外だらけ。 機種依存文字、互換漢字、全角と半角、ローマ字表記の揺れ。
3. 配送日数の公開データが無い。 大手の運送会社は配達日数の早見表を提供しておらず、検索フォームから表を作り直して配ることは利用条件にも抵触しえます。
4. 注文データは個人情報。 受注CSVには氏名も住所も入っています。

生成AIを使わないと決めました。同じ注文には必ず同じ答えを返し、なぜ止めたのかを1行で説明できることが、検品の道具としての最低条件だからです。

判定は副作用のない純粋関数のルールに分け、判定しなかったルールは「未評価」として理由つきで申告させています。フォントが登録されていない、配送日数が入っていない、といった理由でスキップしたものを、黙って合格に見せないためです。

配送日数は、推測の表を同梱しないことにしました。入っていないことを画面で明示し、お店の実績日数を入力してもらいます。

捨てたものは自動化の網羅性です。推測で埋めれば「全部自動で判定」と書けますが、それは誤った安心を売ることになります。

フォントファイルの cmap（文字とグリフの対応表）を読み、注文文字のグリフが存在するか、描画したときの幅が枠に収まるかを判定します。ローマ字はヘボン式の規則で揺れを検出し、互換漢字や機種依存文字も拾います。

楽天の受注CSVはブラウザの中で文字コードを判定して読み込み、個人情報の列を落としてから検査します。受注データを扱う画面は CSP の connect-src から自サイトを外してあるので、運営者のサーバーへ送る通信はブラウザ自身が拒否します。

この画面ではアクセス解析（GA4・Clarity）も読み込みます。Clarity は画面の文字まで記録するため、判定結果の表など顧客の文字が描かれる領域を要素単位でマスクし、実際に描画した DOM と突き合わせるテストで足し忘れを検出しています。

有料の年額プランは、ECDSA P-256 の署名つきライセンスキーを WebCrypto で検証します。検証に通信は要りません。

サイトは静的に書き出し、S3 と CloudFront から配信しています。CSP はエッジで強制しています。

2026-08-31 から 09-18 までの122コミット（マージを除く）。判定ルールは10本で、文字の行ごとに8本、注文ごとに2本。テストは TypeScript が127ファイル、調査用スクリプトの Python が5ファイル。

設計判断の記録（ADR）が9本あり、ホスティングを Vercel から AWS へ切り替えた判断や、配送日数の表を同梱しない判断と、その撤回条件が書いてあります。

受注後の検品、社内ルールのチェック、入稿データの事前確認。人が目で確かめている工程を、理由を説明できるルールに置き換える案件では、判定の精度と同じくらい、判定しなかったことを隠さない設計が効きます。

個人情報を含むCSVをサーバーに上げずにブラウザの中で処理する作りも、そのまま持ち込めます。フォントの cmap を読んでグリフの有無と描画幅を判定する実装は、フォントの対応文字を JavaScript で判定する解説記事にコードつきでまとめました。

EC事業者向けの業務ツールは、業務効率化・EC向けシステムの開発としてお請けしています。