人と会ったあと、「何を話したか」「次に何をするか」が、いつの間にか消えてしまう。名刺は箱にたまり、約束はメッセージアプリの奥に埋もれ、「あの件、どうなったっけ」と思い出したときには時間が経っている。
そんな経験から、出会いを記録し、次の行動につなげるための個人用CRMを作っています。
現時点では、架空データで動作を確認したローカル版です。 本番公開や、実在の人の情報での運用はまだ行っていません。
この記事で書くこと、書かないこと
この記事では、次の3つを中心に紹介します。
- 概要： このCRMで何ができるのか
- 使い方： どんな場面で、どう役に立つのか
- アーキテクチャ： どんな部品で構成し、どう守っているのか
一方で、ソースコード、テーブルの具体的な構造、使っている製品の組み合わせ、試験の手順は載せていません。このCRMは将来、他の人の連絡先や会話のメモを預かる可能性があります。守る仕組みの「考え方」は共有する価値がありますが、攻撃の手がかりになる「設計図」まで公開する必要はない、と判断しました。
🔰 この記事に出てくる言葉
- CRM： Customer Relationship Management の略。もとは企業が顧客との関係を管理する仕組みのこと。ここでは「人との出会いと、その後のやり取りを記録する個人用の手帳」の意味で使います。
- データベース： 記録を整理してしまっておく倉庫。
- API： 画面とサーバーの間で、データをやり取りする窓口。
- 認証： 「あなたは誰ですか」を確かめること。ログインのこと。
- 認可（利用許可）： 「あなたはこれをしていいですか」を確かめること。
- アーキテクチャ： システム全体の構成。どんな部品があり、どうつながり、どこで何を守るか。
- 架空データ： 実在しない人物の名前や会話で作った、試験用の記録。
概要：このCRMでできること
最初の版でできることは、3つだけです。
- 人物を記録する： 名前、所属、肩書き、出会った日、出会いのきっかけ、自分用のメモ。登録、検索、編集、削除ができます。
- 出来事を記録する： その人との会話、打合せ、メッセージ、電話、イベントでの出会い。いつ、どんなやり取りをしたかを残します。
- 次の一手を管理する： その出来事から生まれた「やること」と期限。自分が動くのか、相手の返事を待つのかも区別し、完了したら印を付けます。
たとえるなら「名刺フォルダ＋日記＋やることリスト」
紙の道具でいえば、名刺フォルダ（人物）、日記（出来事）、やることリスト（次の一手）を1冊にまとめたものです。
紙だと、この3つはバラバラの場所に書かれがちです。「あの人に資料を送る約束、どの会話でしたっけ？」とならないように、やることを、それが生まれた会話にひも付けておく。これがこのCRMのいちばんの特徴です。
次の一手を「人」ではなく「出来事」に付けた理由
同じ人と、複数の話が同時に進むことはよくあります。たとえば、ある人と「勉強会の登壇」と「共同研究の相談」の2つが動いているとき、人物に期限を1つだけ付ける形では整理しきれません。
次の一手を出来事に付けておけば、「どの会話から生まれた、どの約束か」がはっきりします。将来、案件ごとの管理を足すときにも、出来事を案件にひも付けるだけで済みます。
あえて入れなかった機能
最初の構想には、組織、案件、連絡先の一括取り込み、外部ツールとの連携、紹介のネットワークまで入っていました。でも全部を一度に作ると、何ができたら最初の版として十分かが曖昧になります。
そこで「この3つが安全に動けば合格」と先に決め、残りは次の段階に回しました。
どういうふうに使えるか：5つの場面
場面1：イベントや勉強会のあと
交流会で10人と名刺交換した夜。帰りの電車で、スマホから一人ずつ登録します。名前と所属に加えて、「出会いのきっかけ」に「〇〇勉強会の懇親会」、メモに「AIの医療応用に関心。来月の勉強会に誘う」と残しておく。
そして出来事として「懇親会で立ち話」を記録し、次の一手に「勉強会の案内を送る・今週金曜まで」を付けます。翌週、名刺の束を見ても誰が誰か分からない、という事態を防げます。
場面2：打合せのあと
打合せが終わったら、決まったことと、それぞれの宿題を出来事として記録します。
- 自分が動くもの：「見積もりを送る・水曜まで」
- 相手を待つもの：「先方の社内確認の結果を待つ・来週」
「自分が動く」と「相手を待つ」を分けておくと、催促すべきなのか、自分が遅れているのかが一目で分かります。
場面3：久しぶりに連絡するとき
半年ぶりに連絡を取る相手の画面を開くと、出会ったきっかけ、これまでの会話、最後に何を約束したかが並んでいます。「前回お話しされていた〇〇、その後いかがですか」と、自然に話を再開できます。
場面4：週に一度の振り返り
未完了の次の一手を見直し、期限が過ぎているもの、相手の返事が止まっているものを確認します。終わったものに完了の印を付け、新しい一手を足す。週に10分の習慣で、取りこぼしが減ります。
場面5：誰かを紹介したくなったとき
「この人とこの人がつながると面白そう」と思ったとき、二人の出会いのきっかけと関心をすぐに見返せます。紹介を支える機能そのものは、まだ構想段階です（後述）。
向いている人
- 研究会、勉強会、交流会で人と会う機会が多い人
- 複数のプロジェクトや相談を並行して進めている人
- 名刺管理アプリだけでは「その後の約束」が追えないと感じている人
画面と操作の流れ
パソコンとスマホで、見せ方を変える
- パソコン： 左に人物の一覧、右に選んだ人の詳細を並べて表示します。一覧を見ながら、次々に記録を確認できます。
- スマホ： 一覧と詳細を切り替える形です。外出先やイベントの帰りに、片手で登録できることを優先しました。
基本の操作は4ステップ
- 人物を登録する： 名前、所属、出会いのきっかけを入れる。
- 出来事を記録する： その人の画面から、会話や打合せの内容を残す。
- 次の一手を付ける： 出来事に、やることと期限を付ける。自分が動くか、相手を待つかも選ぶ。
- 終わったら完了にする： 間違えて完了にしたら、未完了に戻せる。
検索で、名前や所属からすぐに人物を探せます。
細かいけれど大事な使い勝手
実際にスマホで触りながら、次のような点を直しました。
- 日本語の変換を確定するためにEnterを押しても、送信されないようにした。
- 日時の入力欄に見えている値と、保存される値がずれないようにした。
- 読み込み中に一覧へ戻ったとき、表示が中途半端に残らないようにした。
どれも自動の試験では見つからず、人が触って初めて気づいたものです。
アーキテクチャ：全体像
システムは、大きく4つの部品でできています。いちばん大事な設計方針は、画面には何も決めさせないことです。
4つの部品と、それぞれの役割
- 画面（ブラウザ）： 一覧や詳細の表示と、入力の受け付けだけを担当します。「この人として操作します」のような、誰の記録かを決める情報は送りません。画面のボタンを隠しても、API に直接リクエストを送られれば意味がないからです。
- 外部の認証サービス： ログインそのものは、専門のサービスに任せています。パスワードの保管や本人確認の仕組みを自前で作らないことで、守るべきものを減らしています。
- サーバー（API）： すべての依頼は、ここで4つの確認を順番に通ります。①ログインしているか、②このサービスを使ってよい人か、③入力の中身が正しいか、④誰の記録として扱うか。④の「持ち主」は、ログインの結果からサーバーが決めます。
- データベース： 記録は持ち主ごとに分けて保存します。さらに、データベース自身にも「つながりの制約」と「接続ごとの権限」を持たせ、サーバー側の確認とは別の層で守っています。
「使えない側に倒す」
①〜④のどこかで条件を満たさなければ、その先には進みません。設定が足りないときも、エラーになる側に倒します。また、許可していない項目が入力に混ざっていたら、黙って無視せず、エラーとして返します。
「とりあえず動く」より「迷ったら止まる」。他人の情報を預かる可能性がある道具では、この方針が基本だと考えています。
アーキテクチャ：データの持ち方
記録は、「持ち主 → 人物 → 出来事 → 次の一手」という入れ子の形で持っています。
入れ子にした理由
- 持ち主： ログインした人ごとに、このCRM専用の「持ち主」を用意します。外部の認証サービスのIDをそのまま使い回すのではなく、CRMの中の持ち主を介して紐付けることで、将来ログインの仕組みを変えても、記録の形は変えずに済みます。
- 人物： 1人の持ち主が、複数の人物を持ちます。
- 出来事： 1人の人物に、複数の出来事がぶら下がります。
- 次の一手： 出来事に付きます。これで「どの会話から生まれた約束か」が必ず辿れます。
「必ず同じ持ち主の中」をデータベースでも守る
出来事は、自分の持ち主の中にある人物にしか結び付けられません。プログラム側で確認するだけでなく、データベースの制約としても「出来事の持ち主と、その人物の持ち主は一致すること」を求めています。プログラムにミスがあっても、他人の人物に自分の記録が紐付くことはありません。
人物を消すと、その人の出来事と次の一手も一緒に消えます。他の持ち主の記録には影響しません。「消したはずの人の会話メモだけが残る」という状態を作らないためです。
ただし、この制約が守るのは「つながりが正しいか」までです。「誰が読めるか」は、次の節の別の層で守ります。
アーキテクチャ：守りの設計
1つの仕組みに全部を任せない
守りは、それぞれが何を守るかで層に分けています。
- サーバーの確認： この人が、この機能を使えるか。
- データの取り出し条件： この人の、どの記録を扱うか。取り出す、直す、消す、一覧、検索のすべてで、「その記録であること」と「本人の記録であること」を両方の条件にします。
- データベースの制約： 記録どうしのつながりが、同じ持ち主の中で正しいか。
- データベースの権限： その接続の経路に、何を許すか。
- コードの境界の検査： 意図していない部品や接続を、画面側に持ち込んでいないか。
どれか1つで全部を守れるわけではありません。データベースの制約は「つながりの正しさ」は守っても「誰が読めるか」は決めません。プログラムの型の仕組みは書き間違いを減らしても、実行時の権限にはなりません。データベースの行単位のアクセス制御も、接続の仕方によっては効かないことがあります。
たとえるなら「マンションの鍵」
- オートロック（認証）： 住人でなければ建物に入れない。
- 入居者名簿（利用許可）： 建物に入れても、このサービスを使ってよい人かを確かめる。
- 自分の部屋の鍵（取り出し条件）： 開けられるのは自分の部屋だけ。
- 管理規約（データベースの制約）： 他人の部屋の荷物を、自分の荷物として登録できない。
オートロックだけで安心すると、建物に入った人は誰でも他の部屋に入れてしまいます。層を重ねるのは、どれか1つが破られても、一度に全部は取られないようにするためです。
よくある落とし穴：番号を書き換えると他人の記録が見える
個人で作るWebサービスで多いのが、この欠陥です。人物の詳細ページを開くとアドレスに「人物の番号」が入っていて、その番号を1つずらすと、他の利用者の人物が表示されてしまう。ログインは確認していても、「その記録が本人のものか」を確かめていないと起きます。
このCRMでは、すべての操作で本人の記録であることを条件にしたうえで、「他人の番号を指定しても操作できない」ことを試験で確かめています。
データを置く場所を減らす
記録を「必要な場所にだけ置く」ことも、アーキテクチャの一部と考えています。
- 検索した言葉を、アドレスバーに残る形で送らない。
- 人物や出来事の中身を、ページの最初の読み込みに埋め込まない。
- 通信の応答を、ブラウザや途中の経路に保存させない。
- 人物の情報や下書きを、ブラウザの保存領域に残さない。
- 画面を離れたとき、ログインや利用許可が切れたときに、表示中の内容を消す。
- 古い通信の結果が、消したあとの画面に戻ってこないようにする。
送り方を変えただけで中身が秘密になるわけではありません。通信の保護、アクセス制御、記録（ログ）の扱いは、それぞれ別に確かめる前提です。また、画面を離れると下書きが消える仕様は、便利さとのトレードオフです。どんな保存の仕方が本当に必要かは、使いながら決めていきます。
これからのアーキテクチャ：「非公開」と「広場」の2層
将来は、招待制で利用者を広げ、無料で使い始められる形も考えています。そのときの構成は、「自分だけの非公開のCRM」と「本人が選んだものだけが出る招待制の広場」の2層に分ける計画です。
2層に分ける理由
CRMには、他人についてのメモが入ります。「この人は来月、転職を考えているらしい」のようなメモが、紹介や検索の機能を通じて他の利用者に見えたら、取り返しがつきません。
そこで、広場は非公開のCRMとは別の領域として持ちます。つながりは一方向だけで、本人が自分で書き、公開すると選んだ自己紹介だけが広場に出ます。
広げる前に決めているルール
- 自分だけのメモと、本人が選んで公開するプロフィールは分ける。
- 紹介機能を作るとしても、他の利用者の非公開の記録を、検索やマッチングに使わない。
- 連絡先の開示や紹介は、両者の了承を前提にする。
- メールやSNSを自動送信しない。送るときは人が中身を確認する。
- 連絡先の取り込みは、重複と中身を確認してから登録する。
機能を増やしても、このルールは変えないつもりです。他の人の情報を預かる以上、「便利だからつなげる」より先に「つなげていいか」を決める必要があると考えています。
確認できていること、まだのこと
確認できていること
使い終わったら捨てる試験専用のデータベースに、架空の利用者Aと利用者B、架空の人物だけを入れて確かめました。本番の接続情報は使っていません。
- Aは、自分の人物を見る、直す、消すことができる。
- BがAの人物を指定しても、同じ操作はできない。
- 検索やページ送りでも、結果は自分の記録だけになる。
- 別の持ち主の人物に出来事を結び付けようとすると、データベースが拒否する。
- 人物を消すと、その人の出来事も消え、他の持ち主の記録は残る。
あわせて、試験の判定そのものも見直しました。「完了日時が付いたか」を確かめるつもりの判定が、値が存在しない場合でも合格になる書き方だったため、通信の成功、値の型、日時としての正しさ、保存し直したあとに同じ値が読めるかを、分けて確かめる形に直しています。
まだ確認していないこと
- 本物の認証サービスと組み合わせた動き
- 本番の配信環境を含めた、ログインから画面までの一連の動き
- 実際の利用者が増えたときの性能
- 記録の保持期限と削除、バックアップ、操作ログの運用
通った試験の数は、守れている脅威の数とは違います。「確かめたこと」と「確かめていないこと」を分けて残しておくと、次に何をやるべきかが自然に決まります。
ロードマップ
目指しているのは、出会いを次の行動につなげるための道具です。順番は次のように考えています。
- 自分用として使い込む（いま）： 人物、出来事、次の一手の最小版を、実際の暮らしの中で使い勝手を確かめる。本番に出す前に、ログインから画面までの一連の試験と、記録の保持・削除・バックアップの方針を固める。
- 取り込みやすくする： すでに持っている連絡先を、重複と中身を確認してから登録できるようにする。
- 行動につなげる： 複数の人にまたがる「次の一手」を一覧にし、期限切れや返事待ちをまとめて見られるようにする。
- 案件を整理する： 出来事を案件にひも付け、進み具合を見られるようにする。タスク管理などの道具との連携も検討する。
- 紹介を支える： 招待制の広場を作り、紹介の候補や文面の下書きを、人が確認できる形で用意する（構想段階）。
各段階の手前で、「この段階で新しく預かる情報は何か」「誰に何が見えるようになるか」を確認してから進めます。
まとめ
- 概要： 人物、出来事、次の一手の3つを1か所にまとめ、「どの会話から生まれた約束か」をたどれる個人用CRM。
- 使い方： イベントや打合せのあとに記録し、久しぶりの連絡や週1回の振り返りで見返す。「自分が動く」と「相手を待つ」を分けて、取りこぼしを減らす。
- アーキテクチャ： 画面には何も決めさせず、サーバーの4つの確認とデータベースの制約・権限で、記録を持ち主ごとに分けて守る。将来は、非公開のCRMと招待制の広場を別の領域に分け、本人が選んだものだけを一方向に出す。
全部を最初から完成させる必要はありません。小さく動かし、確かめた範囲を正直に残しながら、使い続けられる道具に育てていきたいと思います。
注記： この記事は、2026年10月時点の個人開発の記録です。架空データによるローカル環境での確認結果であり、本番運用での安全性を保証するものではありません。セキュリティ上の理由から、ソースコード、具体的な構成、使用している製品、試験の手順は意図的に省略しています。