名刺画像を撮るだけで kintone に自動登録するシステムを作った

名刺OCR自動登録システムの全体像

今回構築したのは、名刺画像をブラウザにアップロードするだけで、AIが文字情報を抽出し、そのままkintoneに登録できるWebアプリです。

ユーザーは複雑な操作をする必要がなく、直感的なUIで処理を完結できます。

主な機能

• 最大10枚の名刺を一括処理
• OCR結果の確認・編集機能
• kintoneへの一括登録
• ローカル環境で動作（ランニングコスト0円）

特に「確認・編集」を挟んでいる点が重要で、OCRの誤認識を実務レベルで補正できる設計になっています。

システム構成と技術スタック

構成はシンプルながら、実務運用を意識した設計になっています。

バックエンド・フロントエンド構成

• バックエンド：FastAPI（Python）
• フロントエンド：バニラJavaScript（依存なし）

フロントはあえてフレームワークを使わず、軽量かつシンプルに構築しています。

外部連携

• OCR：Groq（Llama 4 Scout）
• データ登録：kintone REST API

OpenAI互換APIであるGroqを採用したことで、実装の変更コストを抑えつつ高速に構築できています。

ディレクトリ構成

実装は以下のように責務ごとに分離しています。

• main.py：APIエンドポイント
• ocr.py：OCR処理
• kintone_client.py：kintone連携
• models.py：データバリデーション
• templates/index.html：UI

UIフローと操作体験の設計

実際の操作は非常にシンプルで、非エンジニアでも扱える設計にしています。

基本フロー

• 画像をドラッグ＆ドロップ
• OCR処理（進捗表示あり）
• 結果確認・編集
• kintoneへ一括登録

設計上のポイント

重要なのは「自動化しすぎない」ことです。

OCR結果をそのまま登録するのではなく、人の確認ステップを挟むことで、実務で使える精度に引き上げています。

また、プログレス表示を入れることで、ユーザーの待ち時間ストレスも軽減しています。

kintoneアプリ設計の工夫

データの使いやすさは、フィールド設計で大きく変わります。

フィールド構成

リンク型フィールドのメリット

メール・電話・URLをリンク型にすることで、ワンタップで発信・ブラウザ起動が可能になります。

この設計は見落とされがちですが、実運用の利便性に大きく影響します。

アプリ作成APIの注意点

kintoneのアプリ作成APIでは、APIトークンが使えずBasic認証が必要です。

ここはハマりやすいポイントなので、事前に理解しておく必要があります。

OCRエンジン選定での失敗と学び

今回の開発で最も時間がかかったのがOCRエンジンの選定でした。

Claude Vision API

精度は期待できるものの、追加課金が必要なため断念しました。

Ollama（ローカル）

コストはゼロですが、ビジョン対応モデルのセットアップが重く、導入コストの高さから見送りました。

Gemini API

無料枠を期待して採用したものの、Quotaが0に設定されており利用不可でした。

特に、Google Cloudの請求アカウントと紐付いているとFree Tierが無効になる点は要注意です。

Groq（最終採用）

• 無料枠：14,400リクエスト/日
• クレジットカード不要
• 高速・高精度
• OpenAI互換API

結果として「コスト・性能・導入のしやすさ」のバランスが最も良い選択となりました。

複数名刺画像への対応設計

現実の運用では、1枚の画像に複数の名刺が写るケースも存在します。

対応方法

Groqに対して「画像内の名刺枚数を判定し、それぞれをJSON配列で返す」プロンプトを設計しています。

今後の改善余地

精度が不安定な場合は、「1画像＝1名刺」に制限することで安定運用も可能です。

用途に応じて仕様を切り替える設計が重要になります。

API設計と処理フロー

APIは最小構成に絞り、シンプルさを重視しています。

OCRエンドポイント

• POST /api/ocr
• 画像を受け取り、OCR結果を返却

登録エンドポイント

• POST /api/register
• 確認済みデータをkintoneへ登録

設計のポイント

処理を「解析」と「登録」に分離することで、再実行やデバッグがしやすくなっています。

また、ユーザー確認を挟む構造にも自然に対応できます。

コストゼロ運用を実現するポイント

今回のシステムは月額コスト0円で運用可能です。

コストがかからない理由

• ローカル環境で動作
• Groqの無料枠を活用
• フロントエンドも軽量構成

注意点

無料枠には上限があるため、利用頻度が増える場合は将来的な課金設計も視野に入れる必要があります。

ただし、スモールスタートとしては非常に優秀な構成です。

実際の画面

社内に足りないものはサービスを調べて相見積もりを取るのではなく、開発してみるという選択も悪くないのかもしれません。