BtoB展示会に出展すると、数日で数百枚の名刺が集まります。しかし本当の勝負は会期後です。誰と何を話したかを思い出せないまま名刺の束だけが残り、リスト化が終わる頃には相手の記憶からこちらが消えている。展示会リードの価値は、対応の速さで決まります。

この記事では、名刺のスキャンから商談メモ（ボイスメモ含む）の記録、スプレッドシートへの構造化保存までをスマホ1画面で完結させるアプリを、生成AIで自作する取り組みを紹介します。弊社の生成AI活用支援の実例として、設計の考え方と「なぜそう作るのか」の根拠をそのまま公開します。

先に結論だけまとめます。

  • マルチモーダルLLMに名刺画像を直接渡すと、文字の読み取り・項目分解・表記の正規化までを一度に行える。従来のOCRが苦手だった部分こそLLMの得意領域
  • 名刺1,000枚を処理しても、API費用は概算で1,000円前後。名刺管理SaaSの年額数十万円と比べると桁が3つ違う
  • ただし「LLMなら全部解決」ではない。確認UI・分類の設計・個人情報の扱いが品質を分ける

本記事は設計と実装の途中経過を含みます。プロトタイプの実測精度（フィールド別の正解率）は、検証が済み次第この記事に追記します。

展示会ブースで実際に起きること

想定するのは来場者1,000人規模のBtoBイベントです。ブースでの流れはシンプルで、自社サービスをカジュアルに紹介し、相手の課題を聞き、名刺交換をする。この繰り返しです。

問題は、ブースにはメモを書く時間がないことです。次の来場者はもう目の前にいます。手書きメモは走り書きになり、後日のExcel転記で文脈が失われ、名刺スキャンのCSVと突合する頃には「どの人がどの話をしたか」がわからなくなる。この転記にかかる日数が、そのまま初動の遅れになります。

そこで要件をこう定めました。

  1. スマホで名刺を撮影すると、構造化されたデータになる
  2. 同じ画面から商談メモを記録できる。選択式タグ（興味度・次アクション・紹介サービス）＋自由記述＋ボイスメモ
  3. 保存先は自社のGoogleスプレッドシート。統一フォーマットで、タグ付きで貯まる
  4. 会期後は、貯まった営業リストに対してAIが企業情報を追加調査し、一次情報のリンク付きで追記する

なぜ「OCRだけ」では営業リストにならないのか

「名刺の読み取りなんてOCRで昔からできるのでは？」という疑問は当然です。実際、名刺のデータ化を長年やってきたSansanは公式リリースでこう述べています。

現在の技術では、OCRエンジン単体で、その精度は担保ができません 出典: Sansan「DSOC OCR」プレスリリース（2020年）

同社が謳う99.9%というデータ化精度は、OCRとオペレーターの手入力を組み合わせたフローによるものです。つまり業界最大手ですら、名刺はOCRだけでは処理できないと結論づけて人力を挟んでいる。その分、データ化完了までにタイムラグが生じます。

OCR単体で難しい理由は、大きく3つに分けられます。

1つ目はレイアウト解釈です。名刺には決まったフォーマットがありません。「文字を読む」ことと「その文字列が会社名なのか氏名なのか役職なのか判定する」ことは別の問題です。たとえばGoogleのノーコード基盤AppSheetに組み込まれたOCR関数（OCRTEXT）は、公式ヘルプにあるとおり画像内のテキストをひとまとまりの文字列として返すだけで、氏名や電話番号への項目分解までは行いません。

2つ目は、誤読が致命的なフィールドの存在です。OCRの定番の誤読に0とO、1とlとI、8とBがあります。住所なら人間が補正できますが、メールアドレスは1文字違えば絶対に届きません。氏名の旧字体・異体字（髙と高、﨑と崎）もよく混同されます。営業リストで相手の名前を間違えるのは、最悪の失敗です。

3つ目は表記の正規化で、これはそもそもOCRの仕事ではありません。名刺上の電話番号は 03-1234-5678、03(1234)5678、+81-3-... と表記がバラバラで、TEL・FAX・携帯のラベル判別も必要です。OCRは「見えた通りの文字列」を返すだけなので、リストとして使うには別途正規化が要ります。住所も同様です。「浦安市舞浜2-11」が「舞浜二丁目11番」とも「舞浜2番地11」とも解釈できるなど、日本の住所は分割・正規化自体が難しいことで知られています。

既存の名刺管理サービスという選択肢

自作の前に、既存サービスで済むならそれが一番です。主要な選択肢を「1,000枚規模・単発イベント」の観点で整理しました（2026年8月時点の調査。金額は公開情報・参考値を含みます）。

選択肢 費用の目安 導入までの時間 データの自由度
Sansan 年60万〜100万円超（見積制・年間契約） 営業商談を経て数週間 CSV出力は管理者権限。APIはオプション
Eight Team 年約24万円（月19,800円〜） 即日（申込約5分） 管理者がCSV一括出力可
無料系（Eight個人・Wantedly People等） 0円〜 即日 CSV出力は有料版限定。無料版はデータを外に出しにくい
生成AIで自作（本記事） API費用 約1,000円＋開発工数 プロトタイプなら数日 最初からスプレッドシート直結

比較して見えてくる論点は2つあります。

ひとつはデータの自由度です。展示会リードの目的は「営業リストとして今すぐ使う」ことなのに、無料系サービスは取り出しに課金が必要で、エンタープライズ系は管理者権限やオプションAPIを経由します。集めたデータを自社の営業フローにすぐ流し込めるか、が分水嶺になります。

もうひとつは商談メモとの一体化です。名刺のデータ化はどのサービスもやりますが、「その場で話した内容」を名刺と同じ動線で残せるものはほとんどありません。Sansanが2025年12月に音声入力とAI要約による商談メモ機能を出したくらいなので、確かなニーズはあるはずです。ただし利用には法人契約が前提です。

公平のために書くと、全社の名刺資産を継続管理したい、SFA/CRMと深く連携したい、監査や認証（ISMS等）を重視する。そういう組織には専用SaaSが向きます。今回のような「単発イベントで、すぐ、自由に使えるリストが欲しい」ケースが、自作の刺さりどころです。

マルチモーダルLLMで何が変わるか

ここ数年での大きな変化は、画像をそのままLLMに渡せるようになったことです。OCRで文字列に起こしてから処理するのではなく、名刺の画像自体をモデルに渡し、JSONスキーマを指定して構造化データを受け取ります。前述の「OCR単体で難しい3つの理由」は、それぞれこう解決されます。

レイアウト解釈は、LLMが文脈ごと判定します。「株式会社」が付けば会社名、という単語レベルの話ではなく、デザイン名刺の縦書きやロゴ内の社名も含めて画像全体から読み取ります。誤読リスクには、出力スキーマにフィールドごとの確信度（high / medium / low）を含めさせて対処します。確信度の低いフィールドだけUI上でハイライトし、人間の確認に回す。そして正規化はプロンプトで指示するだけです。「電話番号は 0X-XXXX-XXXX 形式に統一」「英数字は半角」「判読できないフィールドは推測せず null」。抽出と同時に正規化まで終わります。

一方で、LLM特有の弱点もはっきりあります。低品質な画像から存在しない値を作り出す（ハルシネーション）、実行ごとに結果が微妙に変わる、複数枚をまとめて読ませると精度が落ちやすい、といった挙動です。だからこの設計では1枚ずつ処理し、保存前に必ず人間が確認する画面を通します。LLMに任せる部分と人間が担保する部分の線引きが、この種のアプリの品質を決めます。

ちなみに「アプリを作らなくても、GeminiのチャットUIに名刺を読ませればいいのでは」という案も検討しました。読み取り自体はできます。ただ、抽出結果をスプレッドシートに移すコピー＆ペーストが毎回発生し、スマホでは操作が面倒で、原本画像と結果を見比べての確認もしづらい。ブースで1日に何十回も繰り返す操作としては成立しないと判断して、専用のUIを作ることにしました。

プロトタイプの設計

全体構成です。LLMはGoogleのGemini 2.5 Flash（有料枠）、データの置き場は要件どおりGoogleスプレッドシートにしています。

構成図: スマホのPWAで撮影・録音し、API（Lambda）を経由してGeminiが構造化と文字起こしを行い、スプレッドシートに1リード1行で追記、名刺画像と音声の原本はS3に保管する

UIは1画面で完結させます。「撮る → 確認 → メモ → 保存」を1スクロールに収め、確認フォームでは確信度の低いフィールドだけが黄色くハイライトされる。ブースの喧騒の中で操作するものなので、判断が必要な箇所だけに目が行くようにします。展示会場の回線は不安定なので、送信失敗分は端末内のキューに退避して自動リトライします。

スプレッドシート側は、名刺情報（会社名・氏名・連絡先など）、商談情報（興味度・次アクション・メモ・ボイスメモの文字起こし）、分類（業種カテゴリ・リード温度）、原本リンクの列グループで構成します。1イベント1シートで、会期後はこのシートがそのまま営業リストになります。

LLMを「品質の高い分類器」として使う

保存時には、業種カテゴリ（12種）とリード温度（hot / warm / cold）の自動分類も行います。LLMを分類器として使うときのポイントは、自由に書かせないことです。

  • 選択肢をenumで固定する。出力スキーマでカテゴリを列挙型として定義すると、定義外のラベルが構造的に返せなくなります
  • few-shotで判断基準を固定する。カテゴリごとに2〜3個の実例をプロンプトに含め、「人材紹介と人材派遣はどちらに入れるか」のような境界の判断をブレさせない
  • temperatureは低く（0〜0.2）。分類と抽出に創造性は不要です
  • 確信度の低い分類は人間に回す。分類にも確信度を出力させ、低いものはシート上でフラグを立てて後から見直せるようにします

名刺の抽出も分類も、要するに、LLMの出力を検証可能な形に制約して、怪しいものだけ人間が見るという設計です。

商談メモを声で残す

今回の設計でこだわった機能がボイスメモです。来場者が去った直後の30秒で「何を話したか」「温度感」「次に何をするか」を吹き込めば、音声はそのままLLMに渡され、全文の文字起こしと3行の要約になってメモ欄に入ります。タイピングより速く、手書きより正確で、後から聞き直すこともできます。

技術的にはブラウザ標準の録音API（MediaRecorder）で録音し、Geminiの音声入力に渡すだけです。文字起こしのコストは1分あたり約0.3円。1,000件すべてにボイスメモを付けても数百円です。ブースの騒音の中でどこまで正確に聞き取れるかは、正直なところ会場で試さないと分かりません。ここは検証項目に入れています。

会期後、営業リストをAIで育てる

会期後の運用も設計に含めています。貯まったリストの各社について、AIが会社名とURLを起点にWeb検索を行い、企業概要・規模・直近の動き(資金調達、新サービスなど)をシートに追記します。鍵になるのは一次情報リンクの担保です。

最近のLLM APIには検索結果の引用元URLを構造化して返す機能があり(GeminiのGrounding、Claude/OpenAIのweb searchツール)、「リンクで裏付けられない記述はしない」「確認できない項目は『不明』と書く」をプロンプトで強制することで、ハルシネーションを一次情報リンクの有無で機械的に検出できるようにします。営業担当がリストを見たとき、AIの記述の根拠を1クリックで確認できる状態が目標です。

個人情報の扱いは避けて通れない

名刺は個人情報です。自作する場合はここを丁寧に設計する必要があります。調査した範囲の実務整理を共有します（2026年時点の整理です。制度は変わり得るため、実施時は最新の情報をご確認ください）。

  • スプレッドシートでの名刺管理は、個人情報保護法ガイドラインが挙げる「個人情報データベース等」の事例そのものです（通則編2-4事例1）。安全管理措置などの義務が正面から適用されます
  • 一方で、事業者として名刺交換で取得する行為自体は、利用目的の通知・公表が不要とされる典型場面です（通則編3-3-5、個人情報保護委員会Q&A Q3-12-2）。取得後の営業メールも、特定電子メール法の「書面（名刺）による通知」例外により事前同意なく送れます。ただし送信者表示と配信停止手段は必須です
  • 生成AIへの入力については、個人情報保護委員会が2023年の注意喚起で「入力した個人データが学習に利用されないことの確認」を求めています。OpenAIとAnthropicのAPIはデフォルトで学習に不使用、GeminiのAPIは有料枠のみ学習に不使用（無料枠は製品改善に利用され得る）です。今回Geminiの有料枠を使うのはこれが理由です。一番実務的な注意点はシンプルで、個人アカウントの無料チャットUIに顧客の名刺を貼り付けないこと。ここだけは社内で徹底する必要があります

安全管理措置としては5点を実装します。取扱責任者を決める。シートは特定ユーザーのみに共有して権限を最小化する。二段階認証を必須にする。原本データには保持期限と削除ルールを設ける(このプロトタイプではS3の180日自動削除)。問い合わせ・削除依頼の窓口をプライバシーポリシーに明記する。いずれも中小規模事業者向けのガイドライン例示に沿ったラインです。

かかるお金の話

1,000件をフル処理した場合のAPI費用の概算です(2026年8月時点の公開価格からの計算値)。

処理 概算費用
名刺1,000枚の構造化＋分類（Gemini 2.5 Flash） 約150円
ボイスメモ1,000件（各1分）の文字起こし＋要約 約300〜450円
会期後の企業リサーチ1,000社 約150〜450円（検索は無料枠内）
AWS（Lambda・API Gateway・S3・配信） 数十〜数百円
合計 約1,000円前後

もちろんこれはAPI費用だけで、開発の工数は別にかかります。ただ、生成AIで安くなったのは、この種の業務アプリを作ること自体のコストです。かつて名刺のデータ化は専用サービスを契約するしかない領域でした。いまは汎用のLLM APIと数日のプロトタイピングで、自社の業務フローにぴったり合った道具を作れます。

「自作できる」と「自作すべき」の間

最後に、この取り組みから一般化できる判断軸を挙げておきます。

  1. データを自社でどう使うかが明確なら、自作の価値は跳ね上がります。既製サービスの制約(エクスポート、API、権限)と自社の使い方のギャップが大きいほど、自作が効きます
  2. LLMは制約して使う。スキーマで出力を固定し、確信度で人間の確認に振り分け、検証できない記述を禁止する。この設計ができるかどうかが、デモと実用の分かれ目です
  3. 個人情報の扱いは最初から設計に入れる。後付けでは間に合いません。逆に、ここまで含めて設計できれば中小規模の事業でも十分に運用できます

プロトタイプの実装が進み次第、実測の精度データとあわせてこの記事を更新します。

Tenrechでは、生成AIを「どこに差し込むと効くのか」の見極めから、小さく作って検証するところまでを支援しています。この記事のような取り組みに関心があれば、生成AI導入支援のページ、またはお問い合わせからお気軽にご相談ください。