Synthetic data / Demo掲載している画面はすべて合成データです。実顧客・実案件・本番運用の記録ではありません。
00CASE STUDYAI CRM Demo

小規模店舗向け 顧客・販促管理システム（CRM）

このシステムは何をするか

美容サロンなどの小規模店舗向けに、顧客・来店・売上を 1 か所にまとめ、次に声をかけるべき顧客を見つけ、販促の文案を用意し、人が承認するまでを回す業務システムです。

  1. 承認申請
  2. 人が承認
01顧客の状態を分類system最終来店からの日数と回数を、決まった規則で 6 区分に分ける。AI は使わない。
02AI が文案を下書きsystem施策の目的とチャネルに合わせて文案を生成する。既定の provider は mock。
03表現リスクチェックsystem問題になりやすい言い回しを、外へ出る前に辞書ベースで検出する。
04承認申請human文案を承認待ちへ上げる。ここまでは「下書き」のまま。
05人が承認humancan_approve_contents を持つ人だけが承認できる。手順を飛ばした操作は拒否する。BUSINESS_RULE_ERROR
06監査ログに記録system承認・顧客情報の変更・CSV 取込を before-after つきで残す。
07配信—このデモに配信実装は無い。画面に出る「配信（デモでは無効）」は将来形の文言。NOT IMPLEMENTED
01想定業務課題

想定業務課題

  1. 誰にいま声をかけるべきかが、担当者の記憶と感覚に依存する。
  2. 販促文を自作すると、法律上問題になりやすい言い回しに気づかないまま外部へ出る。
  3. 生成 AI に書かせると、誰の確認も通らないまま顧客向けの文面が確定してしまう。
02使う人と、いまのやり方

使う人と、いまのやり方

使うのは店舗のオーナーと店頭のスタッフで、日常的に触るのは予約表と表計算ソフトです。運用を専任で見る人はいません。台帳・予約・売上は別々にあり、突き合わせは手作業です。文面はオーナーが都度書き、送り先は記憶で決めています。

03満たすべきこと

満たすべきこと

機能

  • 顧客・来店・売上を 1 か所で見て、顧客の状態を同じ基準で分類し、月次の振り返りを出力する
  • 販促の文案を下書きさせ、問題になりやすい表現を出す前に検出する
  • 文案は承認を経ないと承認済みにならない（承認の段階管理／状態遷移）。承認できる人は共同作業者ごとの権限設定（StoreCollaborator）で限定する

制約

  • 権限のないスタッフに氏名・電話・メールを見せない
  • AI の契約・API キー無しで全機能を通しで確認できる
  • 対象を限定して誰が何をしたかを記録し、公開デモとして置いても壊されない
04作ったもの

作ったもの

01ダッシュボード顧客状態の内訳と今月の実績を 1 画面で確認
02顧客一覧・顧客詳細状態のバッジで分類を判別し、来店履歴と判定理由を見る
03施策一覧・施策詳細文案の下書き、表現チェック、承認申請、承認
04月次レポート期間の振り返りを出力
05ログイン画面デモ用の認証情報を明示した入口
05なぜこの設計にしたか

なぜこの設計にしたか

  • 画面側と業務ロジック側を分けた。

    権限で見せる情報を変える画面が増えるほど分岐が散らばる。

    画面（React / TypeScript）と業務ロジック（Django / DRF）を分離した。

    却下した案 — 却下したのは、業務ロジック側が画面まで描く一体構成です。分岐が散らばり、外部へ渡せる仕様の形（API 仕様書の自動生成／drf-spectacular）が残りません。

    代償 — frontend / backend の 2 デプロイ単位と、型定義の二重管理（OpenAPI からの生成は未導入）。

  • AI を使う場所を限定し、既定を見本応答にした（provider 抽象化／AI_PROVIDER=mock）。

    顧客状態の分類と表現チェックは決まった規則で判定します（ルールベース）。

    AI は文案生成に限定し、既定の provider を mock にした。

    却下した案 — 却下したのは、分類と表現チェックも AI に任せる案です。同じ顧客が日によって別の状態になり、理由を説明できません。既定を実 API にする案も、契約が無い人が通しで確認できないため却下しました。

    代償 — 表現チェックは辞書ベースで、辞書に無い表現は検出しません（法的判断ではありません）。

  • 承認を段階で管理し、手順を飛ばした操作を拒否する（BUSINESS_RULE_ERROR）。

    生成された文案が、誰の確認も通らないまま顧客向けに確定してしまう。

    下書き → 承認待ち → 承認済み の段階を強制し、飛ばした操作を拒否する。

    却下した案 — 却下したのは、生成物をそのまま承認済みにして後から取り消す方式です。外部に出た後では間に合いません。

06見どころ

見どころ

AI が書いた文案は、人が承認するまで「下書き」のままです。

承認後の画面には「配信（デモでは無効）」と出ますが、このデモに配信機能は含まれていません。

CRM-V06人による承認を経て承認済みになる人が承認して初めて「承認済み」に変化。配信はデモでは無効で、外部送信は行われない。

この画面で確認できること

  • 承認を経て「下書き」→「承認済み」に変わる
  • 同じ画面の 2 件目は「下書き」のままで、承認が文案単位の人の操作だと分かる
  • 画面内に「配信（デモでは無効）」が写っている

Evidence の対象外

  • 配信した証拠ではない。承認後に出る外部配信の文言は将来形で、このリポジトリに配信実装は無い
  • AI が承認した証拠ではない（承認は can_approve_contents を持つ人の操作）
この画像の出所と、拡大
種別
Screenshot（「承認申請する」→「承認する」後の同一画面）
出所
assets/ai-crm/publish/06-campaign-approved.png
掲載サイズ
1600×1856
倍率
等倍 1.000
SHA256
dfd7b2e6…
同じ画面が、見る人の権限で表示の粒度だけ変わります。

同一顧客・同一画面で、氏名・電話・メールだけが伏せ字になります。

顧客の状態が同じ基準で分類され、判定理由まで残ります。

一覧はバッジで判別でき、詳細に最終来店からの日数と回数が並びます。

07実装範囲

実装範囲

個人開発です。画面・API・データベース・AI 呼び出し・権限・テストまでを 1 人で実装しました。私的に開発中のプロダクトから公開可能な範囲を切り出したもので、外部配信・代理店管理・本番インフラは含めていません。

08品質の担保方法

品質の担保方法

  • 画面では気づけない部分 — 承認の段階管理、権限に応じた個人情報の伏せ字表示（Serializer マスキング）、ログイン状態の無効化、CSV 取込の失敗行、AI 呼び出しの差し替え — を自動の動作チェック（pytest）で固定しています。
  • 領域別は認証 30 / マスキング 19 / 承認 16 / CSV 出力 29 / AI 呼び出し 37。件数は静的な def test_ 定義 480 件、CI 実行ログの実測値は 484 passed（AI CRM CI の main 実行）。
  • backend のみで、frontend テストは 0 件です。

backend 静的 480 件 / CI 実測 484 passedAI CRM CI の main 実行ログ（run 32078586978）

09安全性とデータの扱い

安全性とデータの扱い

01権限に応じた個人情報の伏せ字表示（Serializer マスキング）一覧は見せて氏名と連絡先は見せない、を同じ画面で分けます。暗号化ではないため、データベースは平文で保持します。
02ログイン状態の一括無効化（JWT ／ token_version）別端末に残った状態を無効にできます。秒単位の即時失効ではありません。
03店舗ごとのデータ分離（店舗スコープ）URL を書き換えて他店舗を開けません。行単位セキュリティではありません。
04操作の記録（監査ログ）承認・顧客情報の変更・CSV 取込を追えます。予約・売上の書き込みは対象外（23 か所 / 7 アプリ）。差戻し理由は入力どおり残ります。
10運用と納品物

運用と納品物

区分内容
渡すものリポジトリ一式、docs/ の Markdown 24 本（連番の設計文書 23 本 + API_CONTRACT.md）、デモデータ投入コマンド python manage.py seed_demo
API 仕様書自動生成（drf-spectacular）。静的な仕様ファイルは同梱していないため参照にはローカル起動が必要。同梱の docs/API_CONTRACT.md は strategy-goals 機能を追加するときの契約書（8 エンドポイント）であり、実装済み API の仕様書ではない（この機能はこのデモに未実装）
依頼者側で行うこと環境構築とデータ投入。公開する場合は DJANGO_SECRET_KEY の再発行、デモ利用者の削除、DEMO_MODE=false の 3 点（README「Security Notes」の記載どおり）
運用者が回すもの取込エラー行の削除コマンド python manage.py purge_import_errors（自動実行なし）
本番運用の体制・監視・バックアップ未定義（このデモの範囲外）
11できること・含めていないこと

できること・含めていないこと

ImplementedNot IncludedWhy
AI 文案の生成 + 人の承認外部配信（LINE / メール）本番の認証情報・外部サービス運用を持たないため。このリポジトリには 1 行も含めていない
施策のチャネル区分の分類チャネルへの送信同上。チャネル値は分類のためのメタデータ
権限別の個人情報マスキングデータベースの暗号化マスキングは表示制御。暗号化は別レイヤの要件で、混同させない
サーバー側のトークン更新・失効画面側のトークン自動更新未実装。401 でログイン画面へ戻す挙動のみ
対象操作の監査記録（7 app / 23 か所）予約・売上の書き込みの記録現状の実装範囲。README で対象操作を列挙している
AI 利用の記録（5 サービス中 3 つ）AI コストの上限制御・集計画面制御に必要なデータを取る段階まで
backend テストfrontend テスト未着手。このデモの品質担保は backend の自動テストに寄せている
Anthropic API 経路（既定 off）本番運用実績実装済みの経路であり、稼働実績ではない
公開デモ用の破壊防止（DEMO_MODE）公開 Live Demo今回の公開条件に含めていない
12規模の目安

規模の目安

項目実測値取得方法
API エンドポイント55apps/*/urls.py の path() 総数 63 から、下位 urls.py を束ねる include() 8 件を除いた実数。DRF Router は不使用
モデル / アプリ26 / 11Django のモデルレジストリ（apps.get_models() のうち apps.* 所属）
設計文書24 本docs/ の Markdown（連番の設計文書 23 本 + API_CONTRACT.md）
backend テスト静的 480 件 / CI 実測 484 passedbackend/apps のテスト定義を数えた静的件数 480 件（2026-08-20 再計測）。CI 実行ログ run 32078586978 の実測は 484 passed
frontend テスト0 件frontend/ 配下に *.test.* / *.spec.* が 0 件（node_modules 除く）
13対応可能な作業の例

対応可能な作業の例

以下は対応できる作業の種類であり、受注実績ではありません。

  • 顧客・予約・売上を扱う社内向け Web 業務システムの新規開発
  • 権限別に見せる情報を変える管理画面の設計・実装
  • 生成 AI を業務フローに組み込む際の、人の承認・記録・切替の設計
  • REST API + データベース設計を伴うアプリケーション開発
14技術詳細

技術詳細

技術詳細のページへ→

15証拠へのリンク

証拠へのリンク

CI 実行ログは GitHub Actions で確認できます。閲覧には GitHub へのサインインが必要な場合があります。

目次Contents
原寸表示。掲載側の crop はレイアウト上の切り抜きで、ここでは全体を表示している。