株式会社Koinobori

CASE 05 | SaaS 置き換え

会員へのメール配信を、
自社の中で回す。

以前は年額制の顧客管理 SaaS を使っていましたが、使っていたのは配信機能だけでした。 その配信を、Mac mini 1台と自社の Google Workspace で回す仕組みが「Koibumi(鯉文)」です。 名前は「鯉のぼりからの便り(文)」です。

要点:Koibumi(鯉文)は、交流会の参加者や名刺交換した方などへのお礼・ご案内メールを送る、株式会社Koinobori が自社で作ったメール配信の仕組みです。 年額制の顧客管理 SaaS(使っていたのは配信機能だけ)から置き換え、顧客データを自社の1か所にまとめて、お会いした方それぞれに合ったメールを送っています。 約200名規模の配信を Mac mini 1台で動かし、第三者の配信サービスを通さず、自社のメールアカウントから送ります。 2026年5月に作り始め、2026年9月から事務の担当者が単独で本番配信しており、承認フローは置かず、送信前の5つの関所と自動報告で誤送信を防ぐ設計です。

規模
約200名
動いている場所
Mac mini 1台
自社内に設置
作り始め
2026年5月
本番配信
2026年9月〜
事務の担当者が単独で

WHY — なぜ作ったか

なぜ、自分たちで作ったのか。

REASON 01

使っていたのは、配信機能だけ

それまでは年額制の顧客管理 SaaS を使っていました。ただ、実際に使っていたのは配信機能だけでした。

REASON 02

顧客データを、自社の1か所に

交流会の参加者リスト、名刺、手入力。入口の違う連絡先を、自社の会員データベースにまとめています。

REASON 03

お会いした方に合ったメールを

参加回数など、お会いした方それぞれに合った文面で、お礼やご案内を送ることが目的です。

ARCHITECTURE — 構成

Mac mini 1台と、自社のメールアドレス。

入口は3つ。連絡先は Mac mini の中の会員データベースに集まり、送信前の関所を通ったものだけが、自社の Google Workspace のアドレスから送られます。

入口(3つ)

  • ① 交流会の参加者リスト

    Google スプレッドシートを、Google Sheets API で毎晩自動同期します。

  • ② 名刺の取り込み

    名刺の CSV を取り込みます。

  • ③ 手入力

    画面から手で入力します。

どの入口でも、「入手経路」(交流会・名刺交換・取引先など)を記録しないと、連絡先を登録できません。

Mac mini(自社内に設置)

  • 会員データベース

    SQLite

  • 送信の判断

    送信前の5つの関所

  • 社内向けの Web 画面

    Flask

Mac mini は、外からの接続を直接は受けません。

送信

Gmail API

自社の Google Workspace のアドレスから送ります。付与している権限は「送信」だけです。

お礼・ご案内メール

交流会の参加者や、名刺交換した方などへ届きます。

第三者の配信サービスは通りません。

Mac mini まわりの、ほかの2つの経路

担当者の画面アクセス(認証つきトンネル)

担当者は社外からでも画面を開けます。届くのは、Cloudflare の認証を通った通信だけです。

担当者

社外からでも、画面を開けます

Cloudflare Access

社内のメールアドレスに届くワンタイムコードで認証

Cloudflare Tunnel

認証を通った通信だけが届く

Mac mini の Web 画面

外からの接続は、直接は受けません

結果を社内チャットへ報告

送信の結果は、社内チャット(Slack)に自動で報告されます。

Mac mini

送信の結果

Slack(社内チャット)

自動で報告されます

使っている技術

  • Mac mini
  • Python
  • SQLite
  • Flask(社内 Web 画面)
  • Google Sheets API
  • Gmail API(送信のみの権限)
  • Cloudflare Tunnel・Access
  • Google Workspace
  • Slack(結果の自動報告)

5 CHECKPOINTS — 送信前の関所

送信前の、5つの関所。

本番配信は、次の5つの関所を通ります。担当者の注意力だけに頼らず、仕組みで止める作りです。

  1. 1

    自分宛てのテスト送信をしないと、本番に進めない

    参加回数の区分ごとの見本を、最大5通まで自分宛てに送って確認します。テスト送信を済ませるまで、本番には進めません。

  2. 2

    テストの後に変えたら、もう一度テスト

    テストの後に文面や設定を変えると、内容の「指紋」の違いで変更を検知し、もう一度テストが必要になります。

  3. 3

    宛先の人数を、手で入力する

    本番の前に、宛先の人数を手で入力します。実際の人数と一致しないと、送れません。

  4. 4

    同時に送れる配信は、1つだけ

    途中で止めても続きから再開でき、同じ配信で同じ方に二重に届きません。

  5. 5

    お礼メールは、送る直前に出席者を読み直す

    送る直前に参加者リストを読み直し、出席の印がある方だけに送ります。リストが読めなければ宛先は0名、つまり送りません。

承認フローは置いていません。 誤送信は、この5つの関所と、送信結果の Slack への自動報告という仕組みで防ぐ設計です。

WHERE NOT TO USE AI — AI を使わない判断

AI を入れない場所も、設計のうち。

最初は、お礼メールの一言をローカル AI に書かせていました。ところが敬語の崩れが出たため、参加回数に応じた固定文に切り替えました。固定文は、担当者が画面から直せます。

お礼の一言 ローカル AI に書かせる → 参加回数に応じた固定文

AI を入れる場所と入れない場所を分けるのも、設計のうちだと考えています。

MORE

ほかの取り組みも、あわせて。

CASE 06 | もう1つの実例

AI を使わずに組んだ、経費精算書の誤りを毎朝本人に知らせる仕組みです。誤った指摘を出さない決まりごとで動いています。

経費精算書チェックの事例を見る →

生成AI・ローカルLLM構築支援

当社自身が Mac mini 上で運用している、ローカル LLM の導入実例も掲載しています。

ローカル LLM・業務自動化の構築支援について →

経営者コラム

自社で AI や自動化を運用する中での、工夫や失敗を記録しています。

経営者コラムを読む →

※ 本ページは、当社が自社の業務のために作った仕組みの事例紹介です。

KOINOBORI ECOSYSTEM

私たちが運営するサイト