kintoneメール送信の設計方法｜個別送信・自動送信・履歴管理を分ける構成

kintoneから顧客や取引先へメールを送りたい、という相談では、最初にツール選定の話になりがちです。

kMailerを使うのか、メールワイズと連携するのか、外部メール配信サービスを使うのか、JavaScriptやAPIで送るのか。

たしかに、kintoneのレコードからメールを作成できれば、顧客情報のコピー、メールアドレスの転記、テンプレートの貼り付けは減らせます。

ただし、実務で問題になるのは、メールを送れるかどうかだけではありません。

次のような状態が起きると、メール送信はすぐに危なくなります。

• 標準通知と社外向けメール送信を同じものとして考えている
• 顧客マスタのメールアドレスが正しいか確認されていない
• 案件や問い合わせの状態に関係なく送信できてしまう
• テンプレートが古く、差し込み項目だけ最新になっている
• 添付ファイルの版が分からない
• 送信前に誰も宛先と本文を確認しない
• 送信履歴がメールツール側にだけ残り、問い合わせや案件から追えない
• 顧客からの返信が個人メールに入り、kintoneに戻らない
• 自動送信の条件が曖昧で、送るべきでない相手に送ってしまう

メール送信は、ボタンやプラグインの機能ではなく、顧客対応の業務フローです。

kintoneメール送信で最初に決めるべきなのは、送信ツールではなく、「どのレコードを根拠に、誰が確認し、送信結果をどこへ戻すか」です。

この記事では、kintoneから社外向けメールを送る業務を、標準通知、個別送信、自動送信、テンプレート、承認、送信履歴、問い合わせ・案件との紐づけに分けて整理します。

kintone問い合わせ管理の設計方法はこちら
kintone顧客管理の設計方法はこちら

先に結論：メール送信は「送信前」と「送信後」を分ける

kintoneからメールを送るとき、送信画面だけを作ると失敗しやすいです。

設計すべきなのは、送信前と送信後です。

分けるもの	1レコードの意味	役割
顧客・担当者	1社、1人	宛先、連絡可否、担当者の正本にする
問い合わせ・案件	1件の業務対象	何に関するメールかを明確にする
メールテンプレート	1つの文面	件名、本文、差し込み項目、利用条件を管理する
送信前確認	1回の確認	宛先、本文、添付、承認者、送信可否を確認する
送信履歴	1回の送信	送信日時、送信者、宛先、件名、本文版、結果を残す
対応履歴	1回の顧客対応	返信、送信理由、社内判断、次回アクションを残す
返信・反応	1回の受信や反応	顧客の返信、開封、クリック、エラーを確認する

顧客マスタは、誰に送るかを決める場所です。

問い合わせや案件は、なぜ送るかを決める場所です。

テンプレートは、何を送るかを決める場所です。

送信前確認は、送ってよいかを判断する場所です。

送信履歴は、送った事実を残す場所です。

この分け方にすると、メールを送った後に「誰が、どの案件で、どの文面を、どの宛先へ送ったか」を追えます。

標準通知と社外向けメール送信は別物

kintoneには通知機能があります。

アプリの通知設定、条件通知、リマインダー、メール通知などを使うと、ユーザーにレコード更新や期限を知らせられます。

kintoneヘルプ：アプリの通知設定でできること

kintoneヘルプ：メール通知を設定する

ただし、これは社外の顧客へ営業メールや問い合わせ回答を送る仕組みとは分けて考えます。

種類	主な相手	目的
kintone標準通知	kintoneユーザー	レコード更新、コメント、期限、作業依頼に気づく
メール通知	kintoneユーザーのメールアドレス	kintone内の通知をメールでも受け取る
社外向けメール送信	顧客、取引先、応募者、申請者	案内、回答、確認依頼、見積送付などを送る
メール配信	顧客リスト、見込み客リスト	セミナー案内、メルマガ、キャンペーンを送る
共有メール対応	サポート窓口、代表アドレス	受信、返信、担当割当、履歴共有を行う

標準通知は、社内の人に次の行動を促すものです。

社外向けメール送信は、顧客や取引先に正式な文面を送るものです。

ここを混同すると、社内通知の延長で顧客へメールを送ろうとして、承認、テンプレート、返信先、履歴管理が抜けます。

kintoneの標準通知は「社内に知らせる」仕組み、社外向けメール送信は「顧客へ正式に送る」業務です。設計の重さが違います。

個別送信・一斉送信・自動送信を分ける

kintoneからのメール送信は、送信方法ごとに設計を分けます。

送信方法	例	注意点
個別送信	問い合わせ回答、見積送付、日程調整	宛先、本文、添付、返信先を毎回確認する
一斉送信	条件に合う顧客への案内	配信同意、除外条件、配信停止を別途管理する
自動送信	受付完了、ステータス変更時の案内	条件、送信タイミング、再送、停止を決める
予約送信	案内メール、リマインド	送信前の変更、キャンセル、対象除外を決める
返信対応	問い合わせへの返信、代表メール対応	受信履歴と担当割当を管理する

kMailerの操作ガイドでは、kintone上の1つのレコードからメールを送信し、TO/CC/BCC、テンプレート、添付ファイル、署名、送信確認を扱う流れが説明されています。

kMailer操作ガイド：個別にメールを送信する

メールワイズ連携では、kintoneの顧客管理アプリからの個別送信、一斉送信、メール履歴表示、テンプレート利用が紹介されています。

kintone × メールワイズ：機能

ここで大事なのは、機能名ではなく送信リスクの違いです。

個別送信は、1件ごとの内容確認が重要です。

一斉送信は、送信対象と除外条件が重要です。

自動送信は、送信条件と停止条件が重要です。

この記事では、主に顧客・問い合わせ・案件に紐づく社外向けメール送信を扱います。メルマガやキャンペーン配信のような配信リスト管理は、別記事のメール配信設計で扱います。

顧客・案件・問い合わせと送信履歴をつなぐ

メール送信で最初に設計すべきなのは、どのレコードから送るかです。

宛先だけを見れば、顧客マスタや担当者マスタから送れます。

ただし、実務では「何に関するメールか」が重要です。

送信元	向いているメール	履歴を戻す場所
顧客マスタ	基本連絡、契約更新案内、担当変更	顧客の活動履歴
担当者マスタ	個人宛の確認、日程調整	担当者履歴、顧客履歴
問い合わせ	問い合わせ回答、追加確認、完了連絡	問い合わせ対応履歴
案件	提案、見積、条件確認、日程調整	案件活動履歴
申請	不備確認、承認結果、差し戻し	申請履歴
請求・契約確認	請求前確認、契約更新、入金確認	契約・請求確認履歴

問い合わせ回答を顧客マスタから送ると、顧客には届きます。

しかし、どの問い合わせへの回答だったのかが分かりにくくなります。

見積送付を顧客マスタから送ると、案件に戻りません。

そのため、メール送信は顧客マスタだけで完結させない方がよいです。

問い合わせ、案件、申請など、送信理由になるレコードから送るか、送信履歴をそこへ戻します。

kintone案件管理の設計方法でも整理したように、案件は顧客、活動履歴、見積とつながる必要があります。

メール送信も、案件の活動履歴として残せるようにします。

テンプレート・差し込み項目・添付ファイル

メール送信を安定させるには、テンプレートを作るだけでは足りません。

テンプレート、差し込み項目、添付ファイルの版を管理します。

設計するもの	例	注意点
テンプレート名	見積送付、問い合わせ回答、受付完了	用途が分かる名前にする
利用条件	案件フェーズ、問い合わせ種別、顧客区分	関係ない場面で使えないようにする
件名	[会社名] お問い合わせへのご回答	差し込み失敗時の見え方を確認する
本文	挨拶、回答、次回案内、署名	古い文言や不要な約束を残さない
差し込み項目	会社名、担当者名、案件名、期限	空欄時の表示を決める
添付ファイル	見積書、資料、申請控え	版、承認状態、添付可否を確認する
返信先	担当者、共有メール、窓口	個人宛てに閉じないようにする
本文版	v1、v2、改定日	どの文面を送ったか残す

kMailerでは、メールテンプレートを選択し、件名や本文に反映した上で、必要に応じて編集して送信する流れが用意されています。

このとき、差し込み項目を便利に使うほど、元レコードのデータ品質が重要になります。

会社名が古い。

担当者が退職している。

期限が空欄。

添付ファイルが未承認。

こうした状態で差し込み送信すると、テンプレートは正しくてもメールは間違います。

メールテンプレートの品質は、テンプレート本文だけで決まりません。差し込み元の顧客・案件・問い合わせデータが整っていることが前提です。

送信前承認と権限設計

社外メールは、誰でも送れるようにしない方がよいです。

特に、見積、契約、請求、クレーム、個人情報、採用、不採用、解約に関するメールは、送信前確認が必要です。

メール種別	承認の考え方
問い合わせ回答	一次担当が作成し、必要に応じて責任者が確認
見積送付	見積内容の承認後に送信可能
契約関連	契約条件、添付書類、送信先を確認
請求関連	金額、宛先、請求対象、会計側の状態を確認
採用関連	応募者情報、選考状態、文面を確認
一斉案内	対象者、除外条件、配信停止、同意を確認

権限設計では、次のように分けます。

役割	できること
作成者	メール案を作る、テンプレートを選ぶ
確認者	宛先、本文、添付、送信条件を確認する
送信者	承認済みメールを送信する
管理者	テンプレート、送信条件、権限を管理する
閲覧者	送信履歴だけ確認する

メール送信ツール側に手動送信の権限や条件設定がある場合でも、業務上の承認ルールは別に決めます。

ツールの権限は、最後の防波堤です。

本来は、案件や問い合わせの状態を見て、送信してよい状態になってからボタンを押せるようにします。

kMailer・メールワイズ・外部サービスの使い分け

kintoneからメールを送る方法はいくつかあります。

どれが正解かは、メールの種類によって変わります。

方式	向いている場面	注意点
kMailer	kintoneレコードから個別送信、自動送信、テンプレート送信をしたい	送信条件、履歴保存、テンプレート管理を設計する
メールワイズ連携	共有メール、問い合わせ返信、送受信履歴をチームで扱いたい	受信対応、担当割当、履歴表示の運用を決める
外部メール配信サービス	大量配信、配信停止、反応分析が重要	配信同意、除外条件、反応後フォローを設計する
SMTP/API連携	独自システムや特殊な送信条件がある	エラー、再送、ログ、保守責任を持つ
手動メール	件数が少なく、毎回個別判断が必要	kintoneへの履歴登録を忘れない仕組みが必要

問い合わせ返信をチームで扱うなら、受信履歴や担当割当も重要になります。

この場合、メールワイズのような共有メールの考え方が合うことがあります。

一方、案件レコードから見積送付や日程案内を送るなら、kMailerのようにkintoneレコードとテンプレートを結びつける形が分かりやすいです。

大量のセミナー案内やメルマガなら、配信停止や同意管理を持てるメール配信サービスを検討します。

無理に1つの仕組みで全部送らない方がよいです。

誤送信防止と監査ログ

メール送信で怖いのは、送れないことより、間違って送ることです。

誤送信を防ぐには、送信前と送信後の両方を設計します。

リスク	対策
宛先間違い	顧客・担当者マスタを正本にし、送信前に表示する
CC/BCC間違い	役割ごとの初期値を決め、手入力を減らす
添付間違い	承認済みファイルだけ添付対象にする
文面間違い	テンプレート版、利用条件、確認者を持つ
送信対象間違い	レコード状態、顧客区分、除外条件を確認する
重複送信	送信済みフラグ、送信履歴、再送理由を確認する
返信先迷子	共有メールや対応履歴へ戻す
エラー放置	送信失敗、バウンス、停止を担当者へ通知する

送信履歴には、最低限次を残します。

項目	理由
送信日時	いつ送ったか確認する
送信者	誰が送ったか確認する
送信元レコード	顧客、問い合わせ、案件へ戻れるようにする
宛先、CC、BCC	送信先を説明できるようにする
件名	送信内容を一覧で判別する
本文版	どのテンプレートを使ったか残す
添付ファイル名	どの資料を送ったか確認する
送信結果	成功、失敗、停止、再送を分ける
エラー内容	再送や修正の判断に使う

送信履歴をメールツールの画面だけに置くと、kintoneの問い合わせや案件から追えません。

顧客、問い合わせ、案件の関連レコードや対応履歴から確認できる形にします。

よくある失敗パターン

kintoneメール送信でよくある失敗を整理します。

失敗	起きること	対策
標準通知と社外メールを混同する	顧客向け文面、返信先、履歴が設計されない	社内通知と社外送信を分ける
顧客マスタから何でも送る	問い合わせや案件に履歴が戻らない	送信理由になるレコードへ紐づける
テンプレートだけ整える	差し込み元データが古く、誤った文面になる	顧客、案件、問い合わせのデータ品質を確認する
添付を手作業で選ぶ	古い見積や未承認ファイルを送る	承認済みファイルだけ送信対象にする
誰でも送れる	承認前の見積や契約文面が送られる	送信権限、条件、承認ステータスを設計する
送信履歴が分断される	問い合わせ対応や案件活動から追えない	対応履歴や関連レコードへ戻す
返信が個人メールに閉じる	チームで引き継げない	共有メール、問い合わせ履歴、返信先を決める
自動送信を止められない	条件変更後も古いメールが出る	停止条件、予約確認、エラー通知を用意する

メール送信は、便利になるほど事故の影響も大きくなります。

送信ボタンを置く前に、送信してよい状態、確認者、履歴の戻し先を決めます。

最小構成で始めるなら

最初から複雑に作る必要はありません。

問い合わせ回答や見積送付から始めるなら、最小構成は次の程度です。

構成	内容
顧客・担当者マスタ	宛先、連絡可否、担当者の状態を管理する
問い合わせ・案件アプリ	送信理由、状態、担当、期限を管理する
メールテンプレート	用途別に件名、本文、差し込み項目を管理する
送信前確認	宛先、本文、添付、承認状態を確認する
送信履歴	送信日時、送信者、宛先、件名、結果を残す
対応履歴	返信、電話、社内確認、次回アクションを残す

まずは、個別送信の設計から始めます。

誰かが1件ずつ確認して送る業務で、宛先、本文、添付、履歴が崩れないことを確認します。

その後、条件が明確なものだけ自動送信にします。

一斉送信やメール配信は、配信同意、配信停止、除外条件が必要になるため、別の設計として扱います。

kintoneフォーム連携の設計方法でも整理したように、外部入力から入った問い合わせや申請は、受付後に本データ化してから対応へ進める方が安全です。

メール送信も同じで、データの状態が確定してから送ります。

Bitlightに相談できること

Bitlightでは、kintoneからのメール送信を、ツール導入だけではなく業務フローとして設計できます。

例えば、次のような相談に対応できます。

• kintoneの顧客・問い合わせ・案件からメールを送りたい
• kMailer、メールワイズ、外部メール配信サービスの使い分けを整理したい
• テンプレート、差し込み項目、添付ファイルのルールを作りたい
• 見積送付や問い合わせ回答の送信前承認を設計したい
• 送信履歴を問い合わせ、案件、顧客の履歴として見えるようにしたい
• 返信が個人メールに閉じないようにしたい
• 自動送信の条件、停止、エラー通知を整理したい
• 誤送信しにくい権限と確認フローを作りたい

kintoneからメールを送れるようにするだけなら、ツールを入れれば始められることがあります。

ただし、業務で使い続けるには、宛先、送信理由、テンプレート、承認、添付、送信履歴、返信先を分ける必要があります。

メールは顧客に直接届くため、kintone内の入力ミスや状態管理の曖昧さが、そのまま外に出ます。

送信前に確認し、送信後に履歴へ戻す。

この設計にしておくと、kintoneからのメール送信を、属人的な作業ではなくチームで追える業務にできます。

kintoneメール送信は、送る機能ではなく、顧客対応の証跡を残す業務フローとして設計する方が安全です。