X公式アカウント @Arctanote

領収書チェッカーを実装して見えた技術課題

領収書チェッカーを実装して見えた技術課題

領収書チェッカーを実装して見えた技術課題 ブラウザ内処理、遅延読み込み、スマホ対応、メモリ制約。公開機能として組み込むまでの設計メモ。 --- 前回の記事では、領収書チェッカーの考え方を整理しました。 今回の記事では、そのコンセプトを実際のWeb機能として組み込んだときに、どのような設計を行い、どこで苦労したのかをま...

領収書チェッカーを実装して見えた技術課題 ブラウザ内処理、遅延読み込み、スマホ対応、メモリ制約。公開機能として組み込むまでの設計メモ。 --- 前回の記事では、領収書チェッカーの考え方を整理しました。 今回の記事では、そのコンセプトを実際のWeb機能として組み込んだときに、どのような設計を行い、どこで苦労したのかをまとめます。 この機能は、単なる文字認識デモではありません。 画像を選択し、ブラウザ内で文字を読み取り、帳票種別を判定し、領収書形式であれば必須項目まで確認する流れを、1つの画面で完結させることを目指しています。 --- 実装した画面の役割 領収書チェッカーは、利用者が領収書やレシート画像を選択し、その場で判定結果を確認できる画面として設計しています。 主な機能は次のとおりです。 機能 内容 --- --- 画像選択 ファイル選択またはドラッグ&ドロップで画像を読み込む 進捗表示 文字ブロック認識、文字読み取り、判定処理の進行を表示 画像表示 選択した画像を画面上に表示 文字ブロック枠 読み取った領域を画像上に重ねて表示 帳票種別判定 領収書、レシート、請求書などの候補を判定 必須項目チェック 領収書形式の場合に、発行元・宛名・日付・金額などを確認 処理情報 処理時間や実行方式を簡易表示 利用者向け画面では、内部の専門用語や内部名称を出さず、「領収書チェッカー」として自然に使えることを優先しています。 一方で、検証用の画面では、実行方式、処理件数、文字ブロック、ログなどを確認できるようにし、開発・調整に必要な情報を残しています。 --- 公開画面と検証画面を分ける理由 この種の機能では、開発者が見たい情報と、一般利用者が見たい情報が大きく違います。 画面 目的 表示する情報 --- --- --- 公開画面 迷わず試せること 画像選択、進捗、判定結果、必須項目 検証画面 精度や挙動を調整すること 読み取り結果、内部ログ、処理件数、実行方式 公開画面に専門的なログや内部情報を出しすぎると、利用者にとっては分かりにくくなります。 逆に、検証画面から情報を削りすぎ...