名刺帳をAIで自作したら営業CRMになった｜作って分かった設計と落とし穴

外出先で受け取ったばかりの名刺をスマホのカメラで撮ろうとして、はたと手が止まりました。「あれ、家のMacを起動しっぱなしにしてこなかった」。その瞬間、数日前に自分で作ったばかりの名刺管理アプリは、ただの動かない箱になりました。撮った名刺をAIで読み取って貯めるだけの小さな個人アプリ——それが、この記事でお話しする営業CRMの出発点です。

AI Lab OISHIでは、コードを自分で書くのではなく、AIに指示して作らせ、動かなくなったらAIに直させるという進め方で、いくつもの業務ツールを自前で組み上げています。この記事は、そのうちの1つ、名刺をスマホで撮ってAIで読み取り、フォロー予定・やり取り履歴・商談パイプラインまで持つ「1人運用の営業CRM」へと育っていったアプリの、約2週間・30回の保存にわたる実運用録です。きれいな完成品の紹介ではなく、前提が変わって作り直した判断、電波のない場所での二重登録、ラベル通り動かなかったボタンなど、実際につまずいた場所とその直し方を包み隠さずお届けします。第三者の個人情報である名刺を預かるアプリとして、何を守ったのかも合わせて整理します。

なぜ個人の名刺アプリが「営業CRM」に化けたのか

最初に作ったものは、驚くほど単純でした。名刺をスマホで撮る。AIが名前・会社・連絡先を読み取って、整った形に直してくれる。それを一覧で検索でき、必要ならCSV（表計算ソフトで開ける汎用のデータ形式）で書き出せる。ここまでが出発点です。文字を読み取るこの処理はOCRと呼ばれ、いわば写真に写った文字を機械が書き起こしてくれる清書係のようなものです。

ところが、使い始めるとすぐに欲が出ました。名刺を貯めるだけでは、営業は1ミリも前に進まないのです。「この人には来週連絡する」「前回はこの話をした」「この商談は今どの段階か」——本当に知りたいのはそこでした。そこで、フォロー予定を持たせ、やり取りの履歴を残し、商談のパイプライン（案件が今どの段階かを並べた一覧）を足し、連絡が途絶えた相手を自動で拾う放置検知まで組み込みました。気づけば、名刺を貯める箱は、1人でも回せる営業CRMに姿を変えていました。CRMとは顧客との関係を管理する仕組みで、いわば「誰と、いつ、何を話し、次に何をするか」を1か所にまとめた営業の司令塔です。

この成長は計画したものではなく、使いながら不満を1つずつ潰した結果です。既製サービスを使わず自作したのも、市販品では自分の営業の動き方に合わせて中身を作り替えられないからでした。同じ発想で自分の業務ツールをAIで組み上げる考え方は自分専用の業務ツールをAIで作る記事にまとめていますが、名刺アプリはその最もわかりやすい実例になりました。営業を仕組みで回す全体像は営業をAIで仕組み化する設計記事もあわせて読むと立体的につかめます。

技術的な土台も、この2週間で大きく入れ替わりました。最初の版は、自宅のMacの中だけで動く素朴な作りでした。標準的な部品だけで組み、追加の道具を入れない方針で、着手の翌日には最低限動く版ができています。読み取りは外部のAIに任せ、名前・会社・電話・メールといった項目へ自動で振り分けさせました。この読み取り部分はFirebase AI Logic（Google 公式ドキュメント）を通じてGeminiという高性能AIに任せており、ほぼ無料の範囲で高い精度が出ています。ここまでは、順調そのものでした。問題は、このアプリを「家の外」で使おうとした瞬間に噴き出しました。

事故で学ぶ①：Macを起動しないとスマホから使えなかった

冒頭の場面に戻ります。最初の版は自宅のMacが本体で、スマホは同じ自宅のネットワークから母艦のMacにつなぐ「窓口」にすぎませんでした。つまり、Macが起動していなければ、外出先のスマホでは何もできない。名刺は商談の現場で受け取るものなのに、その現場では使えないという、致命的な食い違いです。当初はVPNのような回避策で外から自宅のMacにつなぐ方法も試しましたが、これは根本解決ではなく、母艦が落ちていれば結局アウトでした。

ここで立ち止まって考えたことが、この記事で一番お伝えしたい判断です。「外出先から、スマホで使いたい」という要望は、一見すると小さな機能追加に見えます。しかし実際には、アプリが動く前提そのものを変える要求でした。誰が、どこから、どの端末で使うのか——この利用文脈が変わったときは、機能を足す話ではなく、土台を組み替える話になります。ここを「機能追加」と誤解して母艦Macに継ぎ足しを続けていたら、モグラ叩きのように回避策が積み上がっていたはずです。

直し方：継ぎ足しをやめ、クラウドへ土台ごと移す

そこで、母艦Macに依存する構造を捨て、クラウド上で完結する作りへ全面的に移しました。具体的には、Googleが提供するFirebaseというWebアプリの土台に載せ替えます。データはクラウドのデータベース（東京リージョン）に置き、ログインはGoogleアカウントで行い、持ち主本人以外は自動的にサインアウトされる。これで、Macの電源がどうであろうと、外出先のスマホから名刺を撮って登録できるようになりました。いわば、自宅の書斎にしか置けなかった名刺帳を、どこからでも開ける金庫付きのクラウド棚に引っ越したようなものです。

この移行の途中では、正直に言えば回り道もしました。名刺の読み取りをどこで中継するか、別の仕組みを2つ試して壁にぶつかり、最終的に「全部Firebaseに寄せる」と決めて落ち着いています。使わなくなったコードは消さず「未使用」と印をつけて残しました。回り道を隠さず残すのは、後で同じ検討をする自分への申し送りになるからです。利用文脈が変わったのに前提を変えずに継ぎ足しを続けると起きる失敗は、AI導入がつまずく典型パターンの記事で挙げたものとも重なります。

事故で学ぶ②：電波がない場所で同じ名刺を二度登録した

クラウド化で外出先から使えるようになった——と喜んだのも束の間、今度はその「外出先」ならではの事故が待っていました。地下の会議室やエレベーター、機内モードのスマホ。つまり電波が届かない場所で名刺を登録しようとすると、保存ボタンを押しても画面がうんともすんとも言わなくなったのです。利用者からすれば「保存できていない」ように見える。だからもう一度押す。すると、電波が戻った瞬間に、まったく同じ名刺が2枚登録されてしまいました。

原因は、クラウド保存の仕組みが持つ、少し意地の悪い性質にありました。クラウドのデータベースに書き込むと、通常は「書き込みが終わりました」という完了の合図が返ってきます。ところがオフラインのときは、この合図が永久に返ってこないのです。データは端末の中にちゃんと貯められ、電波が戻れば自動でクラウドへ送られる——つまりデータは消えません。にもかかわらず、完了の合図だけは待てど暮らせど来ない。この挙動はFirestoreのオフライン対応（Google 公式ドキュメント）でも説明されている、仕様どおりの動きです。素直に「合図を待つ」設計にしていたので、保存できているのに画面は固まったまま、という状態が生まれていました。

直し方：待つのをやめ、「端末に保存した」と伝えて先へ進める

ここで大事なのは、「合図が来るのを待つ」という当たり前の作法を、いさぎよく捨てたことです。書き込みを始めたら、一定の短い時間だけ完了の合図を待ち、その時間を過ぎても返ってこなければ「端末に保存しました。電波が戻れば自動で送信します」と利用者に伝えて、次の操作へ進めるようにしました。合図が間に合えば「送信済み」、間に合わなければ「端末に保存」。どちらに転んでもデータは失われず、画面は必ず前へ進む。これで、無反応に見えて二度押ししてしまう二重登録は起きなくなりました。イメージとしては、宅配便を出したあと配達完了の通知を延々と待つのをやめ、「集荷は済ませました、あとは自動で届きます」と割り切って次の仕事に移るようなものです。

もう1つ、この事故には見えにくい落とし穴がありました。連打を防ぐため「処理中は次の操作を受け付けない」という鍵をかけていたのですが、その鍵を握ったまま、永久に返ってこない合図を待つ箇所があったのです。こうなると、保存はできているのに操作が完全に固まり、アプリを再起動するまで何もできなくなる。「鍵を握ったまま、いつ終わるか分からない処理を待ってはいけない」——これは、一見すると正しく直したつもりの修正が、潜んでいた別の弱点を致命傷に変えてしまう典型でした。オフラインという特殊な状況でしか表面化しないので、普通に使っているだけでは気づけません。

事故で学ぶ③：「済にする」が済にしてくれなかった

CRMとして育ってくると、一番よく使う操作は「フォローを1件片付ける」ことになります。来週連絡すると決めた相手に実際に連絡し、その予定を完了にする。この日常動作のボタンに「済にする」というラベルをつけていました。ところが、このボタンには恥ずかしい裏があったのです。「済にする」を押しても、実際には完了しませんでした。押すと入力欄が埋まるだけで、続けて別の「追加」ボタンを押して、はじめて完了する。つまり二段構えだったのです。

これは、機能としては動いていました。手順どおり2回押せば、ちゃんと完了する。しかし利用者からすれば、「済にする」と書いてあるボタンは、押した瞬間に済にしてくれると信じます。それが実際には途中までしか進まない。ラベルが約束している動作を、ボタンが実行していなかったのです。バグというより、UX（使い心地）の設計そのものの誤りでした。しかもたちが悪いことに、2回目を押し忘れると「片付けたつもり」の予定が消えずに残り、あとで見返したときに混乱します。まるで「送信」と書いてあるのに下書き保存されるだけのメールフォームのようなもので、本人は送ったつもりでいる、という一番こわいすれ違いを生みます。

直し方：1タップで完了させ、1つの塊として書き込む

直し方はシンプルで、「済にする」を押したら、その1タップで本当に完了するようにしました。当たり前のことですが、ラベルが約束する動作をボタンにきちんと実行させる、それだけです。ただし、ここで技術的にもう一段の工夫を入れました。「完了」という操作は、実際には「やり取り履歴に1件書き足す」「フォロー予定から1件消す」という2つの作業に分かれます。この2つをバラバラに実行すると、たとえば消すほうだけ失敗して、履歴には残ったのにフォロー予定も残ったまま、という中途半端な状態が生まれます。すると利用者はもう一度「済にする」を押し、履歴が2件に増えてしまう。このフェーズが直そうとしていた症状を、直し方そのものが再生産してしまうわけです。

そこで、「履歴に足す」と「予定から消す」を、1つの分けられない塊として一度に書き込む形にしました。2つまとめて成功するか、まとめて失敗するか、どちらかしかありません。中途半端な状態が原理的に生まれず、後始末の帳尻合わせも要りません。加えて、書き込んだあとは必ず「今の最新の状態」をIDで引き直すようにしました。一覧を裏で読み直すと、古い名刺の情報を指したまま操作してしまい、「消したはずの予定が画面に残る」ことがあるためです。言い換えれば、手元の古いメモを見て指示を出すのではなく、毎回いちばん新しい台帳を開き直してから書き込む、という規律です。

事故で学ぶ④：出す順番を間違えると削除機能が全部壊れる

4つ目は、目に見えるアプリの挙動ではなく、それを世に出す「公開作業」で起きかけた事故です。Webアプリを更新するときは、大きく分けて「アクセス権限のルール」と「アプリ本体」の2つを本番に反映します。あるとき、手早く直したくて、アプリ本体だけを先に公開しようとしました。すると、名刺を1枚削除する機能が、全部のカードで壊れることが分かったのです。

理由は、機能どうしのつながりにありました。名刺を削除する処理は、ひもづくやり取り履歴や商談も一緒に片付ける必要があり、そのためには履歴や商談を読み取る権限が要ります。ところが本体だけ先に新しくして権限ルールを古いままにすると、新しい本体が必要とする権限がまだ許可されておらず、削除処理が途中ではねられて失敗する。「本体を先、ルールを後」にした瞬間に、削除が総崩れになるという、順番依存の落とし穴でした。

直し方：人の注意に頼らず、公開スクリプトに順番を守らせる

ここでも、「次からは順番に気をつけよう」で済ませませんでした。人の注意は必ずどこかで切れます。代わりに、公開作業を1本のスクリプト（決められた手順を自動で実行する小さなプログラム）にまとめ、①先に権限ルールを反映 ②次にアプリ本体を反映 ③最後に動作を検証という順番を、機械的に強制させました。人間がうっかり順番を飛ばすことが、そもそもできない形にしたわけです。いわば、順番を守らないと次の扉が開かない一方通行の関所のようなものです。

さらにこのスクリプトには、公開の直前に走る品質チェックも組み込みました。アプリが読み込む部品のバージョンと、オフライン用に先読みしておく部品のバージョンがズレていないかを自動で突き合わせ、ズレていたら本番に出る前に止める。こうした「壊れても外に出さない門」を仕組みとして持つ考え方は、AIと人間で運用全体を回している自社運用の事故と再発防止をまとめた記事とまったく同じ思想です。1つのアプリでも、大きな運用でも、効く原則は変わりません。

ちなみにオフラインまわりでは、もう1つ笑えない事故がありました。「電波ゼロでも起動できる」ようにするには、必要な部品を事前に端末へ焼き付けておく必要があります。ところが焼き付けが1つでも失敗すると、機内モードで開いたとき「骨だけの崩れたページ」が出てしまう。そこで、部品をすべて揃えられたときだけ完了とし、1つでも欠けたら中止する——歯抜けを絶対に焼き付けない守りに変えました。中途半端に動くより、いっそ入れないほうが安全だという判断です。

第三者の個人情報を預かるアプリの作法

ここまで機能の話を続けてきましたが、名刺アプリには、機能より先に向き合わなければならない重たいテーマがあります。名刺は、他人の氏名・会社・電話・メールが詰まった第三者の個人情報だということです。事業でこれを集めて管理する時点で、個人情報保護法が定める個人情報データベースに該当し得ます。ここは軽く扱えません。個人情報の取り扱いの基本的な考え方は個人情報保護委員会の解説が一次情報として参考になります。この記事でも、実在する名刺のデータは一切お見せしません。

そのうえで、健全なセキュリティ設計は具体的に語れます。私たちが預かった名刺を守るために敷いた層を、順に挙げます。第一に、持ち主だけが読み書きできるルール。データベースには、持ち主本人以外の読み書きを全部拒否するルールをサーバー側でかけています。仮に誰かがアプリの見た目を突破しても、サーバーが本人以外を門前払いします。この仕組みはFirestoreセキュリティルール（Google 公式ドキュメント）に沿って構成しました。第二に、実データはネット公開の対象から物理的に隔離。アプリのコードを保管する場所と、名刺の実データを置く場所を分け、実データが誤って公開の流れに乗らないようにしています。

第三に、悪意ある名刺への備え。もし誰かが細工した文字列を名刺に印刷して読み取らせ、アプリに悪さをさせようとしても、動的に表示する値はすべて無害化し、リンクとして扱うのは安全な形式のものだけに限定しています。たとえるなら、外から届いた郵便物を開ける前に必ず検査してから扱うようなものです。第四に、AIに画像を送る事実の開示。名刺を読み取る瞬間、その画像は外部のAIへ送信されます。避けられない部分なので、説明書きの中で利用者にはっきり伝えています。渡すデータそのものを最小限にする設計思想はAIに渡すデータを最小化する記事で、外部AIへ預ける際の見極めはAIベンダーのセキュリティを見極める記事で、それぞれ深掘りしています。

第五に、バックアップと開放形式。毎日、名刺データを丸ごと汎用形式で書き出し、複数世代を保管しています。書き出しに使う権限は読み取り専用の最小限に絞り、鍵は厳重に管理する。データはいつでもCSVなどの開放形式で取り出せるので、特定サービスに縛られて動けなくなる事態も避けられます。作り直せるコードは、いざとなれば作り直せます。二度と戻せないのは、消えたデータと、漏れた秘密だけ。だからこそ、機能を足すより先に、この2つを守る構造を土台に据えました。社内で個人情報を安全に扱うルール作りは生成AIの社内ガイドライン記事も合わせてご覧ください。

独自の学び｜レビューは「別のAI」に殴らせる

ここまでの事故を振り返ると、共通する教訓が1つ浮かびます。自分（や自分を作ったのと同じAI）のチェックは、驚くほど甘いということです。「済にする」ボタンの二段構えも、鍵を握ったまま待つ致命的な作りも、書いた本人は「ちゃんと直したつもり」でいました。人は自分の作ったものをひいき目で見ます。AIも同じで、自分が書いたコードを自分で採点させると、必ず点が甘くなります。

そこで採ったのが、別系統のAIにレビューさせるという進め方です。あるモデルに書かせたものを、別のモデルに容赦なく突っ込ませる。これを何周か繰り返したところ、面白いことが起きました。毎周、前の周で入れた修正が、新たな弱点を生んでいたのです。1周や2周で「もう大丈夫だろう」と止めていたら、その弱点は本番に出ていました。特に「そもそも2回に分けて書き込む設計が事故のもとだ」といった根っこの指摘は、作った本人と同じ視点からは出てきません。視点の違うレビュアーを立てる価値を、痛いほど実感しました。

もう1つの独自の学びは、「再現できない失敗は、直っていないのと同じ」ということです。入口のチェックではじかれて表面上「バグなし」に見えても、同じ操作を実際にやると事故が起きる場面が何度もありました。だから思い込みで「直ったはず」と考えるのをやめ、旧版と新版を並べて走らせ、挙動の違いを目で確かめる検証を毎回はさみます。地味ですが、この「事実で確かめる」規律が、動くだけのアプリと、毎日安心して使えるアプリの分かれ目になります。人間と別AIの役割分担でどこを機械に止めさせるかという設計は、自社運用の事故と再発防止の記事とも一貫しています。

ここまでの4つの事故を、原因と仕組みでの解決という形で一覧にまとめておきます。バラバラの不具合に見えて、どれも「注意ではなく構造で防ぐ」という同じ思想で後始末されているのが分かります。

まとめ｜「作る」より「前提を疑い、事故を仕組みで塞ぐ」

名刺アプリを営業CRMに育てた約2週間で、一番の収穫は機能ではなく、次の3つの姿勢でした。1つ目は、前提が変わったら土台ごと作り直す勇気。「外出先から使いたい」という一見小さな要望は、実は前提を変える要求で、そこに気づけたからクラウド化に踏み切れました。2つ目は、事故を人の注意でなく仕組みで塞ぐこと。公開の順番も、二重登録も、ボタンの挙動も、すべて「気をつける」ではなく「機械が構造的に防ぐ」形へ落とし込みました。3つ目は、チェックを自分の外に置くこと。別のAIに殴らせ、思い込みでなく事実で確かめる。この3つは、自分の業務ツールをAIで自作するあらゆる場面に効きます。

AIに任せれば、優秀なアプリはすぐに立ち上がります。けれど、それが毎日安心して使える相棒になるかは、AIの賢さではなく、作り手が「どこで前提を疑い、どこに門を置くか」で決まります。名刺という第三者の個人情報を預かるなら、なおさら便利さより先に守る構造を用意する。自作は保守の責任も背負う選択ですが、その分、自分の営業の動き方に寄り添う道具が手に入ります。もし自社でも「既製品では痒いところに手が届かない」と感じるなら、まずは毎日30分以上かけている作業を1つ選び、そこをAIで小さく自動化してみてください。派手な全自動より、自分の摩擦を1つずつ削る内向きの自動化のほうが、効果を実感できるはずです。

よくある質問

名刺管理アプリをAIで自作するのに、プログラミングの知識は必要ですか？

自分でコードを書く力よりも、「何を作りたいか」「どこで事故を止めたいか」を言葉で設計する力のほうが重要です。私たち自身、コードは自分で書かず、AIに指示して作らせ、動かなくなったらAIに直させる進め方で、撮った名刺をAIで読み取る個人アプリから1人運用の営業CRMまで育てました。ただし、うまくいったのは指示を出す前に落とし穴を洗い出していたからです。オフラインで保存が終わらない、ボタンがラベル通り動かない、削除が別の機能に依存して壊れる——こうしたつまずきは、AIに任せても勝手には消えません。作らせる前に「どんな失敗があり得るか」を3つ挙げておくと、手戻りが大きく減ります。

撮った名刺の画像はどこかに送信されますか？セキュリティは大丈夫ですか？

私たちのアプリでは、名刺を読み取る瞬間に画像を外部のAIへ送って文字を解析しています。つまり撮った名刺の写真は、いったん自分の端末の外に出ます。これを隠すのはフェアではないので、説明書きの中で「OCRの際に画像がAIに送信される」ことを利用者に明示しています。そのうえで、保存したデータは持ち主本人しか読み書きできないルールでサーバー側から締め、実データはネット公開の対象から物理的に隔離し、悪意ある名刺経由の攻撃も無効化する多層の守りを敷いています。第三者の個人情報を預かる以上、便利さより先に「漏れない・触れない構造」を用意するのが最低条件だと考えています。

オフラインでも名刺を登録できますか？電波がない場所で使えますか？

できます。むしろ、電波がない場所での挙動こそが、このアプリで最も苦労した部分です。クラウド保存の仕組みは、オフラインだと「保存の完了を知らせる合図」が永久に返ってこないという厄介な性質があります。素直に完了を待つ設計にしていると、実際には端末内に保存できているのに画面が無反応になり、利用者が不安になって同じ名刺を二度登録してしまう。そこで、一定時間で待つのをやめて「端末に保存しました。電波が戻れば自動で送信します」と伝えて先へ進める形に変えました。データは消えず、二重登録も起きない。地下や機内モードでも、まず端末に貯めて、つながったら裏で送る——この割り切りで、電波のない現場でも安心して使えます。

市販の名刺管理サービスがあるのに、なぜ自作したのですか？

既製サービスは優秀ですが、自分の営業の進め方に合わせて中身を作り替えられないという壁があります。私たちが欲しかったのは、名刺を貯める箱ではなく、「次にいつ誰を追いかけるか」「前回何を話したか」「この商談は今どの段階か」を1人でも回せる営業CRMでした。自作なら、フォロー予定・やり取り履歴・商談パイプライン・放置検知といった機能を、自分の動き方にぴったり合わせて足していけます。加えて、データを開放形式でいつでも書き出せるようにし、バックアップ先まで設計に組み込めるので、特定サービスに縛られて身動きが取れなくなるリスクも避けられます。ただし自作は保守の責任も背負う選択なので、そこは正直にお伝えします。

参照元・出典

• Access data offline（Firebase / Google 公式ドキュメント） — オフライン時の書き込みは端末に保持され、完了の合図は接続復帰まで確定しないというオフライン対応の挙動。
• Get started with security rules（Firebase / Google 公式ドキュメント） — 持ち主本人だけに読み書きを許し、それ以外を拒否する権限ルールの考え方。
• Firebase AI Logic（Google 公式ドキュメント） — クライアントからGeminiなどの生成AIを安全に呼び出し、名刺画像の読み取り・構造化に用いる仕組み。
• 個人情報保護法について（個人情報保護委員会） — 第三者の個人情報を事業で取り扱う際の基本的な考え方を示す一次情報。
• Service Worker API（MDN Web Docs） — 必要な部品を事前に端末へ保存し、電波がない状態でもアプリを起動させるオフライン対応の技術。