SMTP・API連携で高速メール配信するならブラストエンジン

kintoneのメール配信をAPI連携で自動化する方法|Node.jsとblastengineで作る送信の仕組み

更新日:
執筆者: 森神 佑希

kintoneに蓄積した顧客データを使って、請求明細や契約更新のお知らせ、申込受付の通知を自動で送りたい。kintoneを業務の中心に置く企業ほど、こうした要望はよく寄せられます。

ところが、kintoneには顧客など外部のメールアドレスへメールを一斉配信する標準機能がありません。一般的なのはkintone向けのメール配信プラグインを導入する方法ですが、「自社システムと同じ基盤で送信を管理したい」「送信のタイミングや内容を細かく制御したい」という場合は、サーバー側のプログラムからメール配信APIを呼び出す構成が有力な選択肢になります。

本記事では、kintoneからメールを送る方法を整理したうえで、Node.jsとメール配信API「blastengine(ブラストエンジン)」を使ってkintoneと連携する手順を、サンプルコード付きで解説します。定期実行(バッチ)とkintone Webhookによるリアルタイム送信の2パターン、さらにお知らせの一斉配信まで扱うため、kintoneのメール配信を自社の仕組みとして組み込みたい開発者は、そのまま設計の参考にしてください。

※本記事の仕様・料金・上限値は2026年10月時点の情報です。

blastengineのバナー画像2

kintoneからメールを送る3つの方法

kintoneのデータを使ってメールを送る方法は、大きく分けて3つあります。最も一般的なのはプラグインの導入で、仕組みを自作する場合は、どこでプログラムを動かすかによって2つに分かれます。

kintoneには標準のメール一斉配信機能がない

kintoneの標準機能にある「通知」は、kintoneのユーザーに向けた社内通知です。顧客など外部のメールアドレスに、レコードの内容を差し込んだメールを送る機能は標準では備わっていません。

そのため、外部にメールを送るには「プラグインや連携サービスを追加する」「自分たちで送信の仕組みを作る」のどちらかが必要です。なお、どちらの方法もkintoneのプラグイン機能やREST APIを使うため、スタンダードコース以上の契約が前提になります。

プラグイン・連携サービスを使う方法

1つ目は、kintone向けのメール配信プラグインや連携サービスを導入する方法です。kintoneからメールを送る手段としては最も一般的で、kintoneの画面上でテンプレートを選び、レコードの項目を差し込んでメールを送れるため、開発なしで始められる点が最大のメリットです。

料金体系はサービスごとに異なるため、想定する送信件数で総額を比較することが重要です。

GASで仕組みを自作する方法

2つ目は、Google Apps Script(GAS)でkintoneのデータを取得し、メールを送る仕組みを自作する方法です。サーバーを用意する必要がなく、すでにGoogle Workspaceで業務を自動化している企業には取り組みやすい選択肢です。

ただし、GASから直接メールを送る場合は、Google Workspaceアカウントで1日あたり1,500宛先という上限があります。GASとblastengineを組み合わせて上限を解消する方法は、別記事で詳しく解説しています。

kintoneのデータをGASでメール送信する方法|1日1,500宛先の上限をblastengineで解消する手順

サーバーのプログラムからメール配信APIを呼び出す方法

3つ目は、Node.jsなどで書いたプログラムをサーバーで動かし、kintoneのデータを取得してメール配信APIで送信する方法です。サーバーの用意と開発が必要ですが、送信のタイミング・内容・エラー処理を自由に設計でき、自社の他システムと同じ基盤で運用できます。3つの方法の違いを、比較表で整理します。

比較項目プラグイン・連携サービスGASで自作サーバー(Node.jsなど)+メール配信API
開発の必要性不要(設定のみ)必要(GAS)必要(Node.jsなど)
実行環境kintone上・サービス提供元の環境Googleのサーバー自社のサーバー・クラウド
送信の上限サービスの契約内容による直接送信はGoogle Workspaceで1日1,500宛先(メール配信APIと組み合わせれば解消できる)日次の上限なし(月間通数の超過分は従量課金、API呼び出しは1分あたりの上限あり)
送信のきっかけサービスの機能範囲内時間主導型トリガーが中心定期実行・Webhook・自社システムからの呼び出しなど自由
一斉送信の方法サービスの機能によるMailAppでの直接送信、またはメール配信APIを利用メール配信APIのトランザクション配信・一斉配信
向いているケース開発なしで、すぐ始めたいサーバーを持たず、GASで自動化したい自社システムに組み込み、送信を細かく制御したい

開発なしで手軽に始めたい場合や、プラグインの機能で要件を満たせる場合は、プラグインの導入が近道です。自社のシステムに組み込みたい場合は、サーバーからメール配信APIを呼び出す3つ目の方法が適しています。以降は、この方法を中心に解説します。

Node.js×blastengineでkintoneと連携するメリット

サーバー側のNode.jsからblastengineを呼び出す構成には、kintoneのJavaScriptカスタマイズだけで完結させる方法にはない利点があります。

APIキーをブラウザに出さずに管理できる

kintoneのJavaScriptカスタマイズは、アプリを開いたユーザーのブラウザで実行されます。コード内にblastengineのAPIキーを書くと、アプリを閲覧できるすべてのユーザーからAPIキーが見える状態になります。

Node.jsで動かすプログラムなら、APIキーはサーバーの環境変数やシークレット管理サービスに保管でき、kintoneの利用者には一切見えません。メール送信のように悪用されると被害が大きい処理ほど、サーバー側に置くのが安全です。

一斉配信APIを含むすべてのAPIを使える

kintoneから外部APIを呼び出すkintone.proxy()で指定できるHTTPメソッドは、GET・POST・PUT・DELETEの4つのみです。blastengineの一斉配信は、最後の「配信確定」がPATCHメソッドのため、kintone.proxy()経由では完結できません。

Node.jsならHTTPメソッドの制約がないため、1件ずつ送るトランザクション配信に加えて、多数の宛先にまとめて送る一斉配信も同じプログラムから扱えます。

連携の全体像:定期実行とWebhookの2つの起動方法

構成の基本は、kintoneを「データと操作画面」、Node.jsを「本文の組み立てと送信処理」、blastengineを「メール配信」と役割分担する形です。担当者はkintoneでレコードを「送信待ち」にするだけで、あとはNode.jsのプログラムが送信し、結果をkintoneに書き戻します。プログラムを起動するきっかけは、次の2つから選べます。

定期実行(バッチ)で送信する

cronなどで数分おきにプログラムを起動し、「送信待ち」のレコードをまとめて取得して送る方法です。請求明細のように、月末・月初にまとまった件数を送る業務に向いています。

kintone Webhookでリアルタイムに送信する

kintoneのWebhookは、レコードの追加・編集・削除、コメントの書き込み、プロセス管理のステータス更新といった操作が行われたときに、外部のURLへ通知を送る機能です。この通知をNode.jsのサーバーで受け取れば、操作の直後にメールを送れます。申込受付の通知のように、すぐに届けたいメールに向いています。

なお、cybozu.com共通管理でWebhookの利用が禁止されている場合は、Webhookを設定できません。事前に管理者に確認してください。2つの起動方法の違いは次のとおりです。

比較項目定期実行(バッチ)kintone Webhook
送信までの時間実行間隔に依存(数分程度)操作の直後
必要な環境cronなどを実行できるサーバーインターネットから受信できるHTTPSのURL
大量送信得意(まとめて取得・送信)不向き(通知は1分間に60回まで、一括操作では通知されない)
実装の注意点多重起動の防止受信URLの保護、通知の取りこぼし対策
向いているメール請求明細、月次のお知らせ申込受付、問い合わせへの自動返信

kintoneのWebhookは、ドメイン単位で1分間に60回までしか通知されず、それを超えた操作は通知されません。また、Excel/CSVファイルの読み込みや、REST APIによる複数レコードの一括更新でステータスを変えた場合も、通知は送信されません。受信サーバーの停止中に行われた操作の通知を取りこぼすおそれもあります。Webhookで即時に送りつつ、定期実行で「送信待ち」の残りを拾う併用にすると、取りこぼしを防ぎやすくなります。

実装手順:Node.jsでkintoneの請求明細をblastengineから送信する

ここからは、kintoneの請求管理アプリから請求明細メールを送る仕組みを、7つのステップで構築します。サンプルコードはNode.js 20以降(CommonJS形式)を前提にしています。なお、本記事の構成はkintoneのREST APIを使うため、スタンダードコース以上の契約が前提です。本番運用の前に、必ずテスト環境で動作を確認してください。

STEP 1:blastengineのアカウント作成とAPIキーの確認

blastengineの無料トライアルに申し込み、管理画面にログインします。管理画面で「ID」と「APIキー」を確認しておきます。blastengine SDKは、この2つからAPI認証用のBearerトークンを自動で生成します。

トライアル環境では、スパム行為を防ぐため、送信先のアドレスを「配信可能アドレス」として事前に登録する必要があります(5件まで)。管理画面上部の「スタートアップガイド」から「API連携で試す」を選び、「アドレス登録」で社内の検証用アドレスを登録してから、テスト送信を行ってください。なお、トライアルで配信できるのは月間10,000通までです。

検証が終わって実際の顧客へ配信する場合は、本契約が必要です。管理画面の「プラン変更」からプラン選択・契約者情報・支払方法を入力して申し込みます。環境の切り替えは、即日〜2営業日程度で完了します。

blastengineの無料トライアルはこちらから:https://app.engn.jp/be/order/request-form

STEP 2:送信ドメインのSPF・DKIM・DMARC設定

自社ドメインからメールを送るため、送信ドメインのDNSにSPFレコードとDKIMの設定を追加します。SPFレコードの設定例は次のとおりです。

v=spf1 include:spf.besender.jp ~all

既存のSPFレコードがある場合は、SPFレコードを新たに追加するのではなく、既存のレコードにinclude:spf.besender.jpを追記してください。末尾の-allなどの設定は変更しません。1つのドメインにSPFレコードが2つあると、SPFの検証自体が失敗します。また、includeを重ねてDNSの参照回数が10回を超えた場合もエラーになるため、追記後は検証ツールで確認します。

あわせて、DMARCレコードも設定します。Googleのメール送信者のガイドラインでは、Gmailアカウントに1日5,000件以上のメールを送る送信者に、SPF・DKIM・DMARCの設定が求められています。認証設定が不十分なまま送信すると、迷惑メールとして扱われる可能性が高まるため、本番送信の前に必ず設定を済ませてください。

STEP 3:kintoneアプリの準備とAPIトークンの発行

請求管理アプリに、次のフィールドを用意します。カッコ内はフィールドコードです。

  • 顧客名(customer_name):文字列(1行)
  • メールアドレス(email):文字列(1行)またはリンク(必須項目に設定)
  • 請求月(billing_month):文字列(1行)
  • 請求金額(amount):数値(必須項目に設定)
  • 送信ステータス(send_status):ドロップダウン(未送信/送信待ち/送信中/送信済み/送信エラー、初期値:未送信)
  • 配信ID(delivery_id):文字列(1行)
  • エラー内容(error_message):文字列(複数行)

フィールドを追加したら、アプリの設定からAPIトークンを発行します。権限は「レコード閲覧」と「レコード編集」の2つで十分です。発行後は、アプリ設定画面で「アプリを更新」をクリックしてください。更新しないと、APIトークンもフィールドの変更も有効になりません。

担当者は、レコードの編集画面で送信ステータスを「送信待ち」に変更して保存するだけで、メールを送信できます。送信ステータスは、担当者が手動で「送信済み」から「送信待ち」に戻すと再送につながるため、フィールドのアクセス権で、編集できるユーザーを限定しておきます。また、kintoneでIPアドレス制限を設定している場合は、Node.jsを動かすサーバーのIPアドレスを許可しておく必要があります。

STEP 4:Node.jsのプロジェクトを作成する

プロジェクト用のフォルダを作成し、必要なライブラリをインストールします。

mkdir kintone-mailer && cd kintone-mailer
npm init -y
npm install @kintone/rest-api-client blastengine dotenv express

本記事のコードは、@kintone/rest-api-client 6.4.0、blastengine 2.3.8、Express 5.3.0、dotenv 18.0.7(2026年10月時点の最新版)の仕様に合わせて作成しています。実行時にpunycodeに関する非推奨の警告が表示される場合がありますが、blastengine SDKが利用しているライブラリによるもので、動作には影響しません。

認証情報は、プロジェクト直下の.envファイルに保存します。.envは必ず.gitignoreに追加し、Gitリポジトリにコミットしないでください。本番環境では、クラウドのシークレット管理サービスなどに保管するのが安全です。

KINTONE_BASE_URL=https://example.cybozu.com
KINTONE_APP_ID=123
KINTONE_API_TOKEN=your_kintone_api_token
BE_LOGIN_ID=your_blastengine_id
BE_API_KEY=your_api_key
FROM_EMAIL=billing@example.jp
FROM_NAME=株式会社サンプル 請求窓口
WEBHOOK_TOKEN=推測されにくい十分に長いランダム文字列

WEBHOOK_TOKENには、node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"などで生成したランダムな文字列を設定します。

STEP 5:送信処理の共通部分を作る

kintoneとblastengineの初期化、本文の組み立て、送信と書き戻しをlib.jsにまとめます。定期実行とWebhookの両方から、この関数を呼び出します。

// lib.js
require('dotenv').config({ path: require('path').join(__dirname, '.env'), quiet: true });
const { KintoneRestAPIClient } = require('@kintone/rest-api-client');
const { BlastEngine, Transaction } = require('blastengine');

const APP_ID = process.env.KINTONE_APP_ID;
const kintone = new KintoneRestAPIClient({
  baseUrl: process.env.KINTONE_BASE_URL,
  auth: { apiToken: process.env.KINTONE_API_TOKEN },
});
new BlastEngine(process.env.BE_LOGIN_ID, process.env.BE_API_KEY);

const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

function buildMail(r) {
  const amount = Number(r.amount.value).toLocaleString('ja-JP');
  return {
    subject: `【ご請求明細】${r.billing_month.value}分のご案内`,
    text: [
      `${r.customer_name.value} 様`,
      '',
      'いつもご利用いただき、ありがとうございます。',
      `${r.billing_month.value}分のご請求金額は ${amount}円 です。`,
      '',
      '株式会社サンプル 請求窓口',
    ].join('\n'),
  };
}

async function sendTransaction(r) {
  const mail = buildMail(r);
  const transaction = new Transaction();
  const res = await transaction
    .setFrom(process.env.FROM_EMAIL, process.env.FROM_NAME)
    .setSubject(mail.subject)
    .setTo(r.email.value)
    .setText(mail.text)
    .send();
  // 添付ファイル付きの送信では、APIがエラーを返しても例外にならない場合があるため確認する
  if (!res || !res.delivery_id) throw new Error(JSON.stringify(res));
  return res.delivery_id;
}

// 「送信待ち」のレコード(最大100件)を送信し、結果を書き戻す
async function processRecords(records) {
  if (records.length === 0) return;

  // 1. 送信前に「送信中」へ更新する。revisionを指定し、取得後に他の処理が
  //    更新していた場合は失敗させる(=二重送信を防ぐ)
  await kintone.record.updateRecords({
    app: APP_ID,
    records: records.map((r) => ({
      id: r.$id.value,
      revision: r.$revision.value,
      record: { send_status: { value: '送信中' } },
    })),
  });

  // 2. 1件ずつ送信し、結果をためる
  const results = [];
  for (const r of records) {
    try {
      const deliveryId = await sendTransaction(r);
      results.push({ id: r.$id.value, record: {
        send_status: { value: '送信済み' },
        delivery_id: { value: String(deliveryId) },
      } });
    } catch (e) {
      results.push({ id: r.$id.value, record: {
        send_status: { value: '送信エラー' },
        error_message: { value: String(e && e.message ? e.message : e).slice(0, 1000) },
      } });
    }
    await sleep(200); // APIの呼び出し間隔を空ける
  }

  // 3. 結果をまとめて書き戻す(失敗時は「送信中」のまま残し、ログで確認する)
  try {
    await kintone.record.updateRecords({ app: APP_ID, records: results });
  } catch (e) {
    console.error('kintoneへの書き戻しに失敗しました', JSON.stringify(results), e);
  }
}

module.exports = { kintone, APP_ID, processRecords };

ポイントは、「送信中」への更新でrevision(レコードのリビジョン番号)を指定している点です。定期実行とWebhookが同じレコードをほぼ同時に処理しようとした場合でも、後から更新しようとした側はエラーになり、送信まで進みません。複数の起動方法を併用するときの二重送信を、kintone側の仕組みで防げます。後から処理した側では、リビジョン不一致(GAIA_CO02)のエラーがログに出力されますが、二重送信を防いだ結果のため問題ありません。

STEP 6:定期実行のスクリプトを作る

「送信待ち」のレコードを最大100件取得し、STEP 5の関数に渡すスクリプトです。

// batch.js
const { kintone, APP_ID, processRecords } = require('./lib');

(async () => {
  const { records } = await kintone.record.getRecords({
    app: APP_ID,
    query: 'send_status in ("送信待ち") order by $id asc limit 100',
  });
  await processRecords(records);
})().catch((e) => {
  console.error(e);
  process.exit(1);
});

サーバーのcronに登録すれば、5分おきに自動で実行されます。1回の処理件数を100件に区切っているため、件数が多い場合も実行のたびに順番に処理されます。この設定では1万件の送信完了まで8時間程度かかるため、急ぐ場合は実行間隔や1回あたりの処理回数を調整してください。

*/5 * * * * cd /path/to/kintone-mailer && flock -n /tmp/kintone-mailer.lock /usr/bin/node batch.js >> batch.log 2>&1

cronは環境変数PATHが最小限のため、nvmなどで入れたnodeが見つからない場合があります。nodeはwhich nodeで確認した絶対パスで指定してください。また、flockで前回の処理が実行中なら起動しないようにしています(revisionの指定により、重複して起動しても二重送信にはなりません)。

STEP 7:Webhookを受け取るサーバーを作る

kintoneのWebhookを受け取り、対象のレコードを即時に送信するサーバーです。ここではExpressを使います。

// webhook.js
const crypto = require('crypto');
const express = require('express');
const { kintone, APP_ID, processRecords } = require('./lib');

const app = express();
app.use(express.json({ limit: '1mb' }));

function isValidToken(token) {
  const a = Buffer.from(String(token || ''));
  const b = Buffer.from(process.env.WEBHOOK_TOKEN || '');
  return a.length > 0 && a.length === b.length && crypto.timingSafeEqual(a, b);
}

app.post('/kintone-webhook', async (req, res) => {
  if (!isValidToken(req.query.token)) return res.sendStatus(403);
  res.sendStatus(200); // 先に応答を返し、送信処理はその後で行う

  try {
    if (String(req.body?.app?.id) !== String(APP_ID)) return;
    const recordId = req.body?.record?.$id?.value;
    if (!recordId) return;

    // Webhookの内容をそのまま使わず、最新のレコードを取り直す
    const { record } = await kintone.record.getRecord({ app: APP_ID, id: recordId });
    if (record.send_status.value !== '送信待ち') return;
    await processRecords([record]);
  } catch (e) {
    console.error('Webhookの処理に失敗しました', e);
  }
});

app.listen(process.env.PORT || 3000);

kintoneのアプリ設定でWebhookを追加します。Webhook URL欄には先頭の「https://」があらかじめ入力されているため、続けて(サーバーのドメイン)/kintone-webhook?token=(WEBHOOK_TOKENの値)を入力します。通知を送信する条件には「レコードの追加」と「レコードの編集」を選び、保存したらアプリ設定画面で「アプリを更新」をクリックします。

webhook.jsはHTTPで待ち受けるため、HTTPSはリバースプロキシ(nginxなど)やロードバランサーで終端してください。また、このサンプルは常時起動のサーバーを前提としています。サーバーレス環境では応答後の処理が止まる場合があるため、処理の完了後に応答するか、キューを使う構成にしてください。このサーバーには、3つの安全策を入れています。

  • URLのトークンを照合する:トークンを知らない第三者からのリクエストを拒否します
  • レコードを取り直す:通知の内容を鵜呑みにせず、kintone REST APIで最新のデータを取得してから判定します
  • 送信待ち以外は無視する:レコードの削除やコメントの通知、送信対象外のレコードの通知は処理しません

なお、トークンを含むURLは、サーバーやプロキシのアクセスログに記録される場合があります。ログの閲覧権限を絞り、トークンは定期的に変更してください。本番環境では、応答にエラーの詳細(スタックトレース)が含まれないよう、環境変数NODE_ENVにproductionを設定してください。

補足:お知らせを一斉配信する場合

全員に同じ文面のお知らせを送る場合は、一斉配信(Bulk)を使います。宛先をまとめて登録して1つの配信として扱えるため、1件ずつ送るよりAPIの呼び出し回数を抑えられます。

const { Bulk } = require('blastengine');

async function sendAnnouncement(records) {
  const bulk = new Bulk();
  bulk
    .setFrom(process.env.FROM_EMAIL, process.env.FROM_NAME)
    .setSubject('【お知らせ】年末年始の営業日について')
    .setText('__name__ 様\n\n年末年始の営業日についてお知らせします。\n…\n\n配信停止をご希望の方はこちら:https://example.jp/unsubscribe')
    .setUnsubscribe({ url: 'https://example.jp/unsubscribe' }); // 配信停止用のヘッダーを付ける
  await bulk.register(); // 配信を作成

  for (const r of records) {
    bulk.addTo(r.email.value, { name: r.customer_name.value }); // __name__ に差し込み
  }
  await bulk.update(); // 宛先を登録
  await bulk.send();   // 配信を確定(即時配信)
  return bulk.deliveryId;
}

宛先が51件以上になると、SDKが自動でCSVファイルによる一括登録に切り替えます(blastengine SDK 2.3.8の場合)。差し込みコードの指定方法など、SDKの細かな仕様はバージョンによって異なる場合があるため、実装時はblastengine SDKのREADMEとAPIドキュメントで最新の仕様を確認してください。

また、お知らせやメールマガジンなど、広告・宣伝を含むメールを送る場合は、特定電子メール法に基づく受信者の同意取得と、送信者情報・配信停止方法の表示が必要です。

運用で失敗しないためのチェックポイント

仕組みが動いたあとも、安定して運用するためには押さえておきたい点があります。

blastengineとkintoneのAPI上限を意識する

blastengine APIには、デフォルトで1分あたり500回のレートリミットがあります。サンプルコードは1件ごとに200ミリ秒の間隔を空けているため、上限に余裕を持って収まります。レートリミットの引き上げが必要な場合は、オプションで上限を緩和することも可能です。

kintone REST APIにも、1アプリにつき1日10,000回(スタンダードコース。ワイドコースは100,000回)のリクエスト数の上限があります。定期実行はステータスの更新を最大100件ずつまとめて行うため、100件あたり3回で済みます(送信待ちのレコードがない回は、取得の1回のみ)。一方、Webhook経由の送信は1件ごとに3回使います。また、Webhookは送信対象でないレコードの編集でも通知されるため、サンプルコードでは通知ごとに取得の1回を使います。まとまった件数は定期実行に任せ、編集の多いアプリでは使用回数に注意してください。

添付ファイルの送り方と容量に注意する

blastengine SDKのトランザクション配信では、addAttachment()でファイルを添付できます。kintoneの添付ファイルフィールドにある請求書を送る場合は、kintone REST API Clientでファイルをダウンロードし、一時ファイルとして保存してからaddAttachment()にファイルパスを渡します。送信後は一時ファイルを削除してください。ファイルのダウンロードも、kintone REST APIのリクエスト数に数えられます。

なお、添付ファイル付きの送信では、APIがエラーを返しても例外にならない場合があるため、サンプルコードでは配信IDの有無で成功を判定しています。

また、blastengine APIでは、デフォルトで添付ファイルの上限が1MBです。1MBを超える添付ファイルが発生する場合は、オプションで上限を引き上げられます。

二重送信と送信漏れを防ぐ

サンプルコードでは「送信待ち→送信中→送信済み」とステータスを順に進め、revisionの指定で同時処理による二重送信を防いでいます。

処理が途中で止まって「送信中」のまま残ったレコードは、自動で再送せず、担当者が配信ログで送信の有無を確認してから手動で戻す運用がおすすめです。自動再送よりも、確認してから戻すほうが二重送信のリスクを抑えられます。

「送信エラー」になったレコードは、エラー内容を確認し、宛先の誤りなどを直してから「送信待ち」に戻せば再送できます。ただし、通信のタイムアウトなどでエラーになった場合は、実際には送信されていることがあります。この場合も、配信ログで送信の有無を確認してから戻してください。

既存システムがSMTPで送信しているならSMTPリレーも選択肢

blastengineは、APIに加えてSMTPリレーにも対応しています。すでにNode.jsのアプリケーションからSMTPでメールを送っている場合は、送信先のSMTPサーバーをblastengineに切り替える方法もあります。SMTPリレーの接続には、APIキーとは別に、管理画面で確認できるSMTP用のIDとパスワードを使います。

一方、kintoneのデータを起点に新しく送信の仕組みを作る場合は、配信IDの取得やエラー処理を扱いやすいAPI連携が適しています。

kintoneのメール配信を自社の仕組みにするならblastengineを活用する

kintoneのデータを使ったメール送信は、Node.jsなどのプログラムがあれば比較的シンプルに作れます。しかし、送信件数が増えるほど、送信基盤の運用・エラーメールの処理・配信ログの管理といった「メール配信そのものの難しさ」が表に出てきます。こうした課題を、自社のシステム構成を大きく変えずに解消できるのが、メール配信API「blastengine(ブラストエンジン)」です。

kintone×Node.jsの課題をblastengineで解決できる理由

本記事で紹介した構成のように、データ管理はkintone、送信処理はNode.js、メール配信はblastengineと役割を分けると、それぞれの得意分野に集中できます。

  • メールサーバーを持たずに済む:送信IPの評価管理やエラーメール(バウンスメール)の処理をblastengine側で行うため、自前でメールサーバーを構築・保守する必要がない
  • 定期実行もWebhookも同じAPIで送れる:請求明細のようにまとめて送るメールも、申込受付のようにすぐ届けたいメールも、同じ仕組みで扱える
  • 配信ログで問い合わせに即答できる:配信IDをkintoneに書き戻しておけば、「いつ、誰に、何を送ったか」を管理画面ですぐに確認できる

送信の仕組みを自作する場合も、メール配信の部分を専門サービスに任せることで、開発と運用の負担を抑えられます。

kintone連携で役立つblastengineの機能

ブラストエンジン

blastengineは、開発者向けに特化した日本製のメール配信サービスです。kintoneとの連携では、次の機能が役立ちます。

  • トランザクション配信と一斉配信のAPI:1件ごとに内容が異なる請求明細も、全員に同じ内容を送るお知らせも、同じサービスで送れる。一斉配信では、SDKが宛先の件数に応じてCSVでの一括登録に自動で切り替える
  • SMTPリレーにも対応:新しく作る仕組みはAPI、SMTPで送信している既存システムはSMTPリレーと、システムに合わせて接続方法を選べる
  • SPF/DKIM/DMARC対応:送信ドメイン認証に対応し、迷惑メール判定のリスクを低減
  • バウンスメール自動対応:宛先不明などのエラーメールの管理を自動化し、運用負荷を削減
  • 配信ログ管理:配信IDごとに送信結果を確認でき、問い合わせ対応がスムーズ
  • 用途に合わせたオプション:APIのレートリミット緩和や添付ファイルの容量上限アップなど、送信件数や請求書PDFの添付にも対応できる

料金と無料トライアル

blastengineは初期費用無料で、月間1万通のプランを月額3,000円(税抜)から利用できます。上限を超えた分は1通あたり0.60円(税抜)の超過料金で送信でき、送信件数に合わせてプランを選べます(2026年10月時点)。

メールアドレスの入力だけで無料トライアルを始められ、トライアルでも月間10,000通まで配信できます(配信可能アドレスは5件まで)。まずは本記事のサンプルコードで、APIでのテスト送信から試してみてください。

ブラストエンジン公式サイト:https://blastengine.jp/

まとめ

kintoneには外部へメールを一斉配信する標準機能がないため、外部にメールを送るにはプラグインを導入するのが一般的です。一方で、自社のシステムに組み込み、送信のタイミングや内容を細かく制御したい場合は、Node.jsなどのサーバー側プログラムからメール配信APIを呼び出す構成が適しています。

kintoneをデータと操作画面、Node.jsを送信処理、blastengineをメール配信と役割分担すれば、APIキーを安全に管理しながら、定期実行とWebhookを組み合わせて、取りこぼしを防ぎやすい送信の仕組みを作れます。

次にやるべきことは、次の4つです。

  • プラグインで要件を満たせるか、自作が必要かを判断する
  • 送信のきっかけ(定期実行・Webhook・併用)と、月間の送信件数を整理する
  • blastengineの無料トライアルに申し込み、本記事のサンプルコードでテスト送信する
  • 送信ドメインのSPF・DKIM・DMARC設定を、本番送信の前に済ませる

FAQ

kintoneだけでメールの一斉配信はできますか?
A:kintoneの標準機能には、顧客など外部のメールアドレスへメールを一斉配信する機能はありません。外部にメールを送るには、kintone向けのメール配信プラグインを導入するか、GASやNode.jsなどでメール配信APIと連携する仕組みを用意する必要があります。
以前のkintone JS SDKで書いたコードはそのまま使えますか?
A:kintone JS SDK(@kintone/kintone-js-sdk)は現在利用が非推奨です。これから新しく作る場合や改修する場合は、サイボウズ公式のkintone REST API Client(@kintone/rest-api-client)への移行をおすすめします。
kintone Webhookだけで送信の仕組みを作れますか?
A:作れますが、kintoneのWebhookはドメイン単位で1分間に60回までしか通知されず、CSVファイルの読み込みやREST APIによる一括更新では通知されません。受信サーバーの停止中に通知を取りこぼすおそれもあるため、Webhookで即時に送信しつつ、定期実行で「送信待ち」のレコードを拾う併用がおすすめです。
APIではなくSMTPリレーで連携できますか?
A:blastengineはSMTPリレーにも対応しているため、Node.jsのアプリケーションからSMTPで送信することも可能です。ただし、kintoneのJavaScriptカスタマイズやGASからはSMTPで直接接続できないため、SMTPリレーを使う場合はサーバー側のプログラムから送信します。
月1万件程度の送信だと、blastengineの料金はいくらですか?
A:blastengineは初期費用無料で、月間10,000通のプランは月額3,000円(税抜)です。上限を超えた分は1通あたり0.60円(税抜)の超過料金で送信できます(2026年10月時点)。

※kintoneはサイボウズ株式会社の登録商標です。Google Workspace、Gmail、Google Apps ScriptはGoogle LLCの商標です。

森神 佑希
この記事の執筆者

株式会社ラクスライトクラウド Webマーケティングリーダー
森神 佑希

顧客導入社数シェアNo.1のメール配信システム「blastmail」・「blastengine」のWebマーケティング担当。2年以上メルマガ配信の実務を行っており、先頭に立ってPDCAを回してきた。メルマガのノウハウは日本最高クラスと言っても過言ではない。

販売パートナー募集

クライアント企業様へブラストエンジンの提供をお考えの企業様はパートナープログラム登録も併せてご検討ください。SIer・マーケティング支援・Web制作企業様におすすめの制度です。

パートナープログラム詳細