株式会社Koinobori

CASE 05 | SaaS 置き換え

作り方:生成AIで作成動き方:プログラムが判断

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

以前は年額制の顧客管理 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 画面

    社内の人だけが使う画面

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

送信

Gmail API

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

お礼・ご案内メール

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

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

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

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

画面に届くのは、認証を通った社内の人の通信だけです。

担当者

画面を開く

認証

社内の人だけが通れる

暗号化した専用の経路

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

Mac mini の Web 画面

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

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

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

Mac mini

送信の結果

Slack(社内チャット)

自動で報告されます

使っている技術

  • Mac mini
  • Python
  • SQLite
  • Google Sheets API
  • Gmail API(送信のみの権限)
  • 認証つきの専用経路(外からの直接の接続は受けない)
  • Google Workspace
  • Slack(結果の自動報告)

5 CHECKPOINTS — 送信前の関所

送信前の、5つの関所。

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

  1. 1

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

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

  2. 2

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

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

  3. 3

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

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

  4. 4

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

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

  5. 5

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

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

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

HOW IT RUNS — 動くときの判断

作るのは生成AI、送るのはプログラム。

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

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

仕組みは生成AIで作り、動くときは毎回同じ結果になるプログラムに任せる。どこに AI の判断を置くかも、設計のうちだと考えています。

MORE

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

CASE 06 | もう1つの実例

生成AIで作った、経費精算書の誤りを毎朝本人に知らせる仕組みです。判定はプログラムが行います。

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

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

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

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

経営者コラム

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

経営者コラムを読む →

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

KOINOBORI ECOSYSTEM

私たちが運営するサイト