Engineer Blog

Takahiro Hayashi

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

<h1>はじめに</h1>
こんにちは。プレイドのKARTE Messageチームでエンジニアをしている林(<a href="https://x.com/smoothbronco">Twitter</a>)です。
この記事では、動的にSQLを生成する機能の実装を無事故で改善し、その後の開発スピードを向上させたことについてお話しします。
<h1>KARTE Messageについて</h1>
<a href="https://karte.io/package/message/">KARTE Message</a>は、メール・アプリプッシュ・LINEなどのチャネルからエンドユーザーにパーソナライズした配信を効率化したMAツールです。
<a href="https://tech.plaid.co.jp/karte_message_mass_delivery_architecture">メール配信サービスの運用について紹介している記事</a> があるので、こちらもぜひ併せてご覧ください。
<h2>配信対象抽出機能について</h2>
KARTE Messageでは、SQLが書けないマーケターでもGUIベースでメールやLINEの配信対象を抽出できるための機能を提供しています。
配信対象はデータ統合・利活用プラットフォームである<a href="https://developers.karte.io/docs/about-datahub">KARTE Datahub</a>内のテーブルまたはクエリをベースにしており、「リスト」と呼びます。
リストには配信対象のメールアドレスやユーザーID、クーポンコード等のコンテンツに埋め込むデータが入っています。
たとえば、会員マスタのうちGOLDランクの会員にだけメールを送りたい場合は、以下のような操作で対象を絞り込むことができます。ある対象を除外する、パーソナライズした値をコンテンツに埋め込む、施策内で1ユーザーに対してx回まで配信する、といったこともこの機能で実現しています。
※ データはすべてダミーです。
<img src="https://ik.imagekit.io/plaid/ab4a4133-596b-42e1-986a-164fa2a444fb/merge_list.webp" alt="merge_list.webp">
配信対象抽出の裏側では、クライアントの設定した値から動的にSQLを生成しています。
先ほどのGOLD会員の例では、以下のようなSQLを生成します。
<pre><code class="language-sql">WITH result AS (
	WITH master_{list_id} AS (
		-- &quot;【デモ】マスターデータ_メール&quot;のクエリ
		SELECT * FROM demo_master_mail
	),
	subset_{list_id} AS (
		-- &quot;gold会員&quot;のクエリ
		SELECT * FROM demo_master_mail WHERE rank = 'gold'
	),
	merge_list AS (
		WITH master AS (
			SELECT * FROM master_{list_id}
		),
		subset AS (
			SELECT user_id FROM subset_{list_id}
		)
		SELECT
			master.user_id AS user_id,
			master.email AS target
		FROM master
		LEFT JOIN subset ON master.user_id = subset.user_id
		WHERE subset.user_id IS NOT NULL
	)
	-- (中略)
)
SELECT * FROM result;
</code></pre>
このSQLは配信する時とクライアントが対象ユーザーをプレビューする時にKARTE Datahubのテーブルに対してクエリします。
対象抽出のデータ結合に用いるキーはユーザーIDか配信先 (メールアドレスやLINE ID) を使っており、ユーザーIDのカラムがある場合はユーザーIDで結合します。
クライアントの持っているデータによってはユーザーIDカラムのないデータもあるので、その場合は配信先のカラムで結合します。
また、一部のユーザーIDがnullになっていることもあります。
<h2>改善前の課題</h2>
たとえば以下のようなケースだと、メールアドレスが一致していても一部でuser_idがnullになっている場合はパーソナライズする値が落ちてしまいます。
<img src="https://ik.imagekit.io/plaid/acd9c458-90cd-404f-a92d-bc3f94f36254/user_id_null.png" alt="user_id_null.png">
このようなケースを含め、配信対象抽出機能を改善する前は以下のような課題がありました。
<ul>
<li>データに関する課題
<ul>
<li>targetやuser_idという一般的な名前が予約語になっており、クライアントの設定次第でカラム名が衝突する</li>
<li>user_idがnullableなので、対象抽出やパーソナライズする値を結合する際にレコードが落ちる場合がある</li>
</ul>
</li>
<li>ロジックに関する課題
<ul>
<li>配信時のクエリとプレビュー時のクエリを返すロジックの共通化ができておらず、出力に差分が生じてしまう</li>
<li>コードが複雑で処理の分割がうまくできておらず、キャッチアップコストが高い</li>
</ul>
</li>
</ul>
配信対象抽出機能はKARTE Messageの中でもコアになる機能であることや、今後も頻繁にアップデートがかかることが想定される機能でした。この状態のまま運用していくと予期せぬバグやインシデントを起こしかねないので、機能全体に手をいれることにしました。
<h2>やったこと</h2>
以下2つのアプローチを取って行いました。
<ol>
<li>リストの元データを view table にし、クエリするときは view table を参照する</li>
<li>既存の仕様からデータモデルを再定義し、コードをまるっと作り替える</li>
</ol>
1つ目に関しては、view tableにすることでクライアントのデータに一定の前提を設けられるので、データに関する課題を解決することができると考えました。
2つ目に関しては、仕様が明確だったこと、既存のコードに対してテストが不十分だったことなどから、改めてデータモデルから作り替えた方がメンテナブルになるだろうと考えました。
<h3>view tableにする対応について</h3>
先に、viewのクエリを示します。
<pre><code class="language-sql">SELECT
 *,
 cast(
 ifnull(
 cast(`user_id` as string),
 concat('null_embedded_', `email`)
 ) as string
 ) as masspush_user_id,
 cast(`mail` as string) as masspush_target,
FROM
 (
 -- リストの元データのクエリ
 SELECT
 *
 FROM
 demo_master_mail
 )
</code></pre>
ポイントは2つです。
<ul>
<li>予約語はクライアントが設定する可能性が限りなく低い命名にする</li>
<li>user_idがnullの時は<code>null_embedded_{配信先}</code> で埋める</li>
</ul>
こうすることで、カラム名が重複することや最終的に配信対象が抜け落ちてしまうことが減りました。リストの元データのクエリは数百〜数千行になることもあるので、最終的なクエリをシンプルに保つことができるようにもなりました。
移行する中で難しかったのが、viewのクエリが参照するデータの鮮度を保つことです。
リストの中には、「先月10,000円以上購入した人」や「30分前にカゴ落ちした人」などの相対日時を条件に含むものがあります。これらは絶対日時に変換してクエリにしているので、配信やプレビューが実行される直前でviewのクエリを更新する必要がありました。
また、KARTE DatahubはBigQuery上にテーブルを保持しています。BigQueryのテーブル更新オペレーションは10秒で最大5つまでというクォータがあるので、都度viewを更新するのは現実的ではありません。
そこで、以下のような実装で更新オペレーションを極力減らすことにしました。
<pre><code class="language-tsx">export const updateListViewQueryIfBaseSQLModified = async (
	baseSQL: string;
	list: List;
) =&gt; {
 const tableName = createTableName(list);
 const cachedQueryHash = await findCachedQueryHash(tableName);
 const newQueryHash = hashQuery(baseSQL);
 // 最新のqueryとcacheしたqueryのhashが一致してれば処理を終える
 if (cachedQueryHash === newQueryHash) {
 return;
 } else {
 // BigQueryに問い合わせてviewのqueryを比較する
 const isEqualBaseSQL = await compareViewToBaseSQL({
 list_id: list.id,
 baseSQL: baseSQL,
 });
 // queryが異なればviewのqueryを更新する
 if (!isEqualBaseSQL) {
 const viewQuery = buildQuery(list, baseSQL);
 await updateView(viewQuery, list.id);
 }
 // table名をkeyに、queryのhashをvalueにしたcacheを保存する
 await cacheQueryHash({ key: tableName, query: baseSQL });
 }
}
</code></pre>
まず、BigQueryにリクエストする手前にcacheを挟むようにしました。同じリストを使い回して同時刻に複数個の配信を実行するクライアントは多いです。このようなケースはcacheのおかげでBigQueryへのリクエストを減らすことができました。
次のステップでは、BigQueryに問い合わせて最新のviewのqueryを取得し、比較するようにしました。テーブル取得のクォータは更新に比べて制約が緩いので、更新前に最終チェックをしています。
このようなステップを踏むことで、配信が集中する時間帯でもクォータを超えることなくviewのクエリを最新の状態に保つことができました。
<h3>コードの作り替えについて</h3>
コードの作り替えはTDDライクに行いました。まず仕様からテストケースを起こし、そのテストケースに従ってテストが通るようにコードを書くようにすることで、仕様の抜け漏れやエッジケースの見落としなどがないかを確認しながら進めることができました。
また、リリースに関してはview table対応とは別で行う、一部のテナントから段階的に行うなど、万が一問題があったときの影響範囲を最小限に抑えながら進めました。
<h2>結果</h2>
かなり大規模かつ問題が起きた時のリスクが大きい修正でしたが、配信に影響なくすべてリリースすることができました。
またこのリリース後、キャッチアップコストが大幅に減り、開発工数がより正確に見積れるようになりました。新しくチームに入ってきたエンジニアの方が新規に機能拡張をすることになった時も、キャッチアップが大変という感覚は無かったそうです。改善前に比べてテストも充実する形になったので、変更を加える際の影響範囲やエッジケースのバグ取りこぼしも見えやすくなりました。
課題の種類をデータとロジックに分けて、それぞれを解決するアプローチにしたことでシンプルになったと個人的には思っています。
<h2>最後に</h2>
私が所属するKARTE Messageチームでは、大量配信を支える配信基盤の改善や、より良いMAツールにしていくための機能開発など、まだまだやりたいことがたくさんあります。
少しでもこのような領域に興味を持ってくださった方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。応募待ってます！

非エンジニアでも直感的に動的なSQLを生成できる、GUIのノーコードツールの改善方法の紹介

動的にSQLを生成する複雑なロジックに立ち向かい、開発スピードを向上させた話

こんにちは！プレイドでエンジニアをしている土佐といいます。
先日、社内で「生成AI」をテーマにしたLightning Talk（LT）会が開催されました！🎉プレイドだけでなく、グループ会社のRightTouchメンバーも集結し、総勢なんと約80名が参加する、とっても賑やかなオンラインイベントになりました。
ここ数ヶ月、社内でもCursorやCline、Vertex AI経由のGPTモデルなど、さまざまな生成AIツールの活用がどんどん進んできて、「お、そろそろ各チームで溜まってきた知見や『こんなことやってみた！』をシェアする良いタイミングじゃない？」ということで、今回のLT会が企画されたんです。
この記事では、当日の熱気や発表の面白さ、そして私たちが感じた「これから」の可能性を、少しでも皆さんにお届けできればと思います。LT会の雰囲気や学びが伝わると嬉しいです！
<h2>当日の熱気：オンラインでも伝わる一体感！</h2>
会場はオンライン。それぞれの場所から参加する形でしたが、画面越しにも伝わる熱気…！🔥 発表が始まると、みんな真剣な表情で聞き入り、Slackのスレッドも質問や感想、「なるほど！」「それ面白い！」といったコメントで、めちゃくちゃ盛り上がっていました。
<h2>発表ハイライト 🚀</h2>
今回のLT会では、本当に多種多様なテーマで10件の発表がありました。どれも興味深く、刺激的な内容ばかりでした！すべての発表をダイジェストでご紹介します。
<ul>
<li>「採用面談の日程調整をAIにやってもらうワークフローを構築しました」
<ul>
<li>候補者と複数面接官の複雑なカレンダー調整を、Zapier AIとDifyを駆使して自動化！ Slackから使える「Google Calendar 日程提案くん」で、面倒な調整業務をスマートに解決する実用的な工夫が光りました。</li>
<li>詳細な記事はこちら
<ul>
<li><a href="https://note.com/kantetsu/n/n00958cea908d">https://note.com/kantetsu/n/n00958cea908d</a></li>
</ul>
</li>
</ul>
</li>
<li>「お客さんの商品データを検索するMCPサーバー作ってみた」
<ul>
<li>通常のキーワード検索だけでなく、ベクトル検索で&quot;似ている商品&quot;も提案できるAPIサーバーを自作。ユーザーの「見つからない…」を減らす、既存技術を組み合わせた価値創造の好例でした。</li>
</ul>
</li>
<li>「Cline + ChatGPT 4o 画像生成を使ったOSS開発をしてみた」
<ul>
<li>自作OSS「Gunshi」の開発で、Clineによるコーディング支援やドキュメント生成、ChatGPT 4oによるロゴ・OGP画像作成までAIを活用！ 開発プロセス全体でのAI活用スタイルが新鮮でした。</li>
<li><a href="https://gunshi.dev/">https://gunshi.dev/</a></li>
</ul>
</li>
<li>「生成AIにサポートサイトドキュメントを書かせて公開してみた」
<ul>
<li>Cursor等のAIツールを使い、コードベースからサポートサイトのドキュメントを効率的に生成・公開。人間には手間のかかる表作成などもAIに任せる、実践的なノウハウが共有されました。</li>
</ul>
</li>
<li>「ボランティアのイベント告知サイトの更新をClineを使ってほぼ自動化した件」
<ul>
<li>ボランティアで運営するWordPressサイトの更新作業を、Cline、RPA、ChatGPT生成HTMLで見事に自動化！ Gutenberg記法を活用することで、ビジュアルエディタとの互換性を持たせる工夫を行い、大幅な効率アップを実現した、技術による社会貢献の素敵な事例でした。</li>
</ul>
</li>
<li>「AI開発基盤を作ってみた」
<ul>
<li>AI機能をより簡単に開発できる基盤を開発中。AIエージェント開発の知見集約や再利用性を高める土台作りのお話にワクワクしました。</li>
</ul>
</li>
<li>「code-bugsというCLIツールを作った」
<ul>
<li>複数ファイルにまたがる定型的なコード修正を、AIが自動で行ってくれるCLIツール「code-bugs」を開発。簡単なレシピで面倒な作業を効率化する、開発者の頼もしい味方になりそうです！</li>
</ul>
</li>
<li>「AI Agentにセキュリティレビューをやってもらう」
<ul>
<li>Copilot AgentやCursorにセキュリティルールを学習させ、コードレビューを補助させる試み。AIをセキュリティチェックの「心強い相棒」として活用する可能性が示されました。</li>
<li>詳細な記事はこちら
<ul>
<li><a href="https://tech.plaid.co.jp/security-review-by-ai-agent-101">https://tech.plaid.co.jp/security-review-by-ai-agent-101</a></li>
</ul>
</li>
</ul>
</li>
<li>「誰でもできるvibe-coding」
<ul>
<li>エンジニア以外の職種の方がAIで機能を実装！顧客解像度の高い人が直接開発できる可能性と、レビュー負荷軽減のためのプロセス改善（仕様レビュー、PR分割）というリアルな試行錯誤が共有されました。</li>
</ul>
</li>
<li>「Codatumで組織サーベイの分析にLLMによる要約を埋め込んでみた」
<ul>
<li>BigQueryとVertex AIを連携し、SQL関数 <code>ML.GENERATE_TEXT</code> を活用して従業員サーベイの大量の自由記述回答をグループ別に要約。SQLだけで高度なテキスト分析を実現するパワフルな活用事例でした。</li>
<li>Codatumとは
<ul>
<li><a href="https://codatum.jp/">https://codatum.jp/</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h2>LT会を終えて：見えてきた景色と、これからの私たち</h2>
本当に刺激的なLT会でした！
個人的に最も印象的だったのは、「誰でもできるvibe-coding」の発表です。プロダクトやお客様に一番近いメンバーが、AIを使って直接価値を生み出せる。これって、開発のあり方やスピード感を根本から変える可能性を秘めていると感じました。
もちろん、「じゃあ、私たちソフトウェアエンジニアの価値ってどこにあるんだっけ？」という問いも同時に生まれます。AIがコードを書けるようになった今、私たちはより本質的な課題解決や、アーキテクチャ設計、そしてAIを最大限に活用するための環境構築といった領域で、さらに価値を発揮していく必要があるのかもしれません。今回のLT会は、そんなことを考える素晴らしいきっかけになりました。
プレイドでは、**「技術はトレンドを追うためではなく、長期的なインパクトと組織的な再現性を生み出す原動力である」**と考えています。今回のLT会で見られた多様なチャレンジは、まさにその思想を現場レベルで体現しているように感じました。
単に「生成AIが流行っているから使う」のではなく、「どうすれば顧客への価値提供や、私たちの働き方を本質的に良くできるか？」という視点で、みんなが主体的にAIと向き合い、試行錯誤を楽しんでいることがわかったイベントでした。
参考
<a href="https://blog.plaid.co.jp/n/nb08d947606f3">https://blog.plaid.co.jp/n/nb08d947606f3</a>
<h2>おわりに：プレイドのAI環境</h2>
実は、あまり大々的には言っていませんが、プレイドでは、エンジニアは Cursor、Cline、Vertex AI経由の各種モデルといった生成AIツールを、かなり自由に試せる環境が整っています。これ、個人的にはものすごい「福利厚生」だなと思っていて…（だって、個人で契約したら、日に数万円かかることもありますからね！）
「生産性のための環境投資は死ぬほど安い」 というのがプレイドのエンジニアのマインドセットの一つ。セキュリティには最大限配慮しつつも、これからも価値創出につながる新しい技術は積極的に取り入れていくんだろうな、と感じています。
そんなプレイドでは、一緒に未来のプロダクトを作るソフトウェアエンジニアを絶賛募集中です！
今回のLT会のような、技術への探求心や「やってみよう！」の精神を大切にする環境に興味のある方は、ぜひ採用ページを覗いてみてくださいね。
👉 プレイド採用ページ： <a href="https://recruit.plaid.co.jp/product">https://recruit.plaid.co.jp/product</a>
最後まで読んでいただき、ありがとうございました！
P.S. このブログ記事も、実はGoogle MeetのGemini議事録とGemini 2.5 Proの力を借りて、構成案から執筆までサポートしてもらいました！

プレイド社内で開催された生成AIのLT会レポート。グループ会社RightTouchも参加し、CursorやVertex AI経由GPT等の活用事例や開発知見を共有。当日の発表をサマリでお伝えします

生成AI、どう使う？ プレイド社内LT会で活用のヒントを探ってみた！

文字やアイコンのコントラスト比、focusしたときに表示されないツールチップ、重複する代替テキスト、「アクセシブルな名前」のないリンク、ターゲット領域を広げるための重複するリンク。これらの問題と解決策、その背景にある考え方についての解説。

当エンジニアブログで実施したアクセシビリティ改善の方法についての解説

アクセシビリティの概念的な理解から、取り組むべき理由、ガイドライン、実践方法、その学び方など、幅広いテーマについての概説と、それら各論の参考資料の紹介。

アクセシビリティ学習の手引きとしての入門講座

プレイドでエンジニアをしている田宮です。今回は Cloud Logging と BigQuery 用いて開発した 監査ログ の紹介をします。

マルチプロダクトにおける全操作を網羅する監査ログ収集基盤：設計思想と実装 - 収集編

<h1>はじめに</h1>
こんにちはプレイドの<a href="https://cxclip.karte.io/products/info/message-beta/">KARTE Message</a>チームでエンジニアをしている<a href="https://x.com/prooooograming">土谷</a>です。
今回は大量メール配信を実現するためにKARTE Messageで取っている仕組みを紹介していきます。
<h1>KARTE Messageについて</h1>
本題に入る前に、まずKARTE Messageについて説明します。
KARTE Messageはマルチチャネル(Mail/アプリPush/LINE *)での大量配信を行えるMAツールとなっており、主に以下の機能を備えています。
<ul>
<li>配信の管理
<ul>
<li>配信対象抽出の設定</li>
<li>配信コンテンツの設定・コンテンツへの埋め込み</li>
<li>配信速度・頻度の管理</li>
</ul>
</li>
<li>配信対象の管理
<ul>
<li>誰に配信するのかを取り扱うための配信対象を管理するためのリスト機能</li>
<li>リストに対するフィルタリング機能</li>
<li>リスト同士を組み合わせて配信対象を絞り込む機能</li>
</ul>
</li>
<li>配信コンテンツの管理
<ul>
<li>配信コンテンツをテンプレートとして管理</li>
</ul>
</li>
</ul>
これらの機能に加えてKARTEの特有の機能を利用した配信対象の抽出などもできるようになっています。
* LINEとの連携機能は現状β版として提供しています。
<h1>このブログで出てくる用語</h1>
まずメール配信においてよく使われる用語の説明をします。理解している人は読み飛ばしてください。
<code>Eメール</code> : 一般的にEメールはマーケティングメールとトランザクションメールに大別できます。
<code>マーケティングメール</code> : 受信者がアクションをしていなくても送信者側が能動的に送信するメールです。メルマガ配信やクーポンメールなど。
<code>トランザクションメール</code> : 受信者が何かしらのアクションを起こした時に受等的に送信するメールです。ログインメールやパスワードリセットメールなど。
<code>メールバウンス</code> : 送信したメールが何らかの理由で相手のメールサーバーに拒否されて、送信者に戻ることです。メールバウンスはハードバウンスとソフトバウンスに大別できます。
<code>ハードバウンス</code> : メールの拒否理由が恒久的な問題の場合のメールバウンスのことです。メールアドレスが存在しないなど。
<code>ソフトバウンス</code> : メールの拒否理由が一時的な問題の場合のメールバウンスのことです。受信者のメールボックスがいっぱいなど。
<code>IP/ドメインレビュテーション</code> : メール送信時に利用するサーバーのIPアドレスやFromドメインに対して付けられる評価をレピュテーションと呼びます。スパムメールのようなメールをたくさん配信しているとレピュテーションが下がり、メールプロバイダー(GmailやYahoo!メールなど)から受信を拒否される場合があります。レピュテーションの管理はメールプロバイダーがやっていたり、第三者機関がやっていたり、さまざまなパターンがあります。
<code>SPF</code> : SPFレコードというDNSレコードを利用して、送信されたメールの送信元IPを確認することで送信者がなりすましをしていないかを確認する仕組みです。
<code>DKIM</code> : DKIMレコードというDNSレコードを利用して、送信されたメールの内容が第三者に改竄されていないことを確認する仕組みです。
<code>DMARC</code> : SPF/DKIMの確認に引っかかった時に、どのように対応すべきかを送信元のサーバーが表明しておく仕組みです。
<h1>大量メール配信の運用における課題</h1>
マーケティングメールが大量に送信されている現在の環境では、同様に大量のスパムメールも送信されています。メールプロバイダーはメールの大量送信に対して、スパムメールかどうか・送信者がスパマーではないかという判定を厳しく行なっています。
そのためマーケティングメールをエンドユーザーに届けるためには、送信したメールがスパムメールでないことを証明する必要があります。
メールプロバイダーは送信されたメールがスパムメールでないことを確認するために、以下のような項目を確認しています。
<ul>
<li>SPF/DKIM/DMARCの設定確認
<ul>
<li>これらのDNSレコードの設定がされていないとスパムメールと判断される場合があります。</li>
</ul>
</li>
<li>IPレピュテーション・ドメインレピュテーションの確認
<ul>
<li>送信元のIPレピュテーションやドメインレピュテーションが低いと、スパムメールと判断される場合があります。</li>
</ul>
</li>
<li>メールコンテンツの正当性の確認
<ul>
<li>メール内のコンテンツにhttpのセキュアではないリンクがあったり、不審なスクリプトなどが含まれていたりすると、スパムメールと判断される場合があります。</li>
</ul>
</li>
<li>メール配信量の急増の検知
<ul>
<li>特定IPからのメールの配信量が急増すると、スパムメールと判断される場合があります。</li>
</ul>
</li>
</ul>
上記のようなスパムメールかどうかの大量のチェックが各メールプロバイダーごとで設定されているため、マーケティングメールをエンドユーザーに届けることが簡単ではないことが課題となっています。
<h1>KARTE Messageにおける大量のメールをエンドユーザーに届けるための仕組み</h1>
ここからは、KARTE Messageで行なっているマーケティングメールを正常にエンドユーザーに届けるための仕組みを紹介します。
<h2>AWS SESを利用したマルチテナント構成</h2>
大量メール配信においてIPレピュテーションを高く保つことは、上述した通り非常に重要です。これを実現するには、スパムメールと判定される可能性のある質の低いメールの送信を極力避け、メールプロバイダーに確実に受信される質の高いメールを送信する必要があります。
そのため、質の高いメールの配信量を最大限に増やすことが有効なアプローチの一つです。これにより、仮に少量の質の低いメールが送信されたとしても、全体におけるその割合を低く抑えることができ、結果としてIPレピュテーションを高く維持することにつながります。
<img src="https://ik.imagekit.io/plaid/913abcd7-570a-481a-bc9b-b9cb0c8ff3e4/blog_image1.png" alt="blog_image1.png">
KARTE Messageでは、それを実現する仕組みとしてマルチテナントなメール配信を行なっており、KARTE Messageが所有しているIPアドレスをクライアントごとに固定せず、全てのIPに均等に振り分けて送信しています。
<img src="https://ik.imagekit.io/plaid/c3e46daa-6c2d-4f66-b27e-b7a349813334/blog_image2.png" alt="blog_image2.png">
結果として冒頭で述べた通り、KARTE Messageを利用しているクライアント全配信量が母数となるので、特定のクライアントで質の低いメールが多少送信されても影響を小さくすることができます。
また、複数のクライアントの配信をKARTE MessageのIPで送信しているため、配信はほぼ24時間常に行われています。そのため、1クライアントが急な大量配信をしたとしてもKARTE Message全体では配信量の急増にはなりにくく、メール配信量の急増によるIPレピュテーションの低下を防ぐことができ、送信されたメールもスパムメールと判定されづらくなります。
こういったIPレピュテーションの運用は、1クライアントでやろうとすると配信量や配信時間の問題で運用が難しくなる場合があります。KARTE Messageではマルチテナント配信にすることで、その運用負荷をクライアントから取り除いています。
<h2>まとめ</h2>
マルチテナント配信以外にも、KARTE Messageではメール配信の細かなモニタリングを行ったり、SPF/DKIM/DMARCの設定の補助機能なども提供することで、なるべくマーケティングメールの運用負荷を下げるような機能提供を行なっています。
KARTE Messageでは、メールという長年コミュニケーションツールとして中心になっている技術であるからこそ難しくなっている部分を管理することで、価値を届けるプロダクトを作っています。
興味がある方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。お待ちしております！

KARTE MessageというMAツールでメールの大量配信を安定的に行うためのシステム設計やIP運用の考え方などを説明

KARTE Messageで採用している大量配信を実現するためのアーキテクチャ

KARTE Messageの大量メール配信を支える技術

こんにちは！10月初旬から4月末までの7ヶ月間、ソフトウェア開発のインターンとしてプレイドで働いていた[上野海吏](https://x.com/kairi_noel)(@kairi_noel)です。

プレイドで7ヶ月間の開発インターンで体験したことと得られた学び

AIエージェントによるセキュリティレビューの試みを紹介します。

AIエージェントによるセキュリティレビューことはじめ

この記事では、MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーションシステムについて解説します。

MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーション

プレイドが提供する<a href="https://karte.io/">KARTE</a>では、オンライン上のエンドユーザの行動データを活用するためにさまざまな分析機能を提供しています。 
その中で非常によくある集計がユニークユーザのカウントです。SQLで言うところのCOUNT(DISTINCT user_id)です。KARTEはMAU約8億の膨大な量のユーザを扱っていて、ユニークユーザ数を効率的に集計することは重要なテーマです。 
最適化のためにこのアルゴリズムについて深掘りする機会があったので、調べたことを説明していきます。
<h1>HashTable</h1>
最も一般的なのは、HashTable にキーを追加してカウントしていく方法でしょう。 
擬似コードは以下です(Linear Probing)
<pre><code class="language-bash">initialize table
count = 0

insert(key):
 h = hash(key)
 bucket = h mod capacity;
 while table[bucket] is occupied:
 if table[bucket] == key:
 break
 bucket = (bucket + 1) mod capacity
 
 table[bucket] = key
 count = count + 1
 if load_factor() &gt; threshold:
 resize()
</code></pre>
挿入の計算量はO(1)ですが、擬似コードからもわかる通り実際には以下のようなオーバヘッドが乗ります。
<ul>
<li>ハッシュ計算</li>
<li>キーの一致判定</li>
<li>リサイズ(テーブルが埋まってきたら、大きくして作り直す)</li>
</ul>
全体的にキーが長いほど、またテーブルが埋まっていくほど遅くなります。固定長で短いキーと比べて、可変長で長いキーの方が一致判定は遅くなりがちです。
使う側でできる最適化の余地としては以下のようなものがあります。
<ul>
<li>リサイズの発生を抑えるために初期サイズを賢く設定する</li>
<li>データの特性に合わせて適切なアルゴリズムを選択する
<ul>
<li>主に別々のキーでバケットが衝突した時に代わりのバケットを選ぶ方法について、Robin hoodやQuadratic probingなどさまざまな手法があります。</li>
<li><a href="https://thenumb.at/Hashtables/">Optimizing Open Addressing</a></li>
</ul>
</li>
</ul>
<h1>Sketch</h1>
結果が近似値で良ければ Sketch が使えます。 
HyperLogLog が有名ですが、すでに多くの記事で紹介されてるので代わりに KMV（K-Minimum Values）Sketchを紹介します。HyperLogLogも面白いので知らない方はぜひ調べてみてください。
KMV ではハッシュ関数をキーに適用して、得られた値のうち小さい順に k 個だけを保持します。 
ユニークなキーが多ければ多いほど小さい数字(と大きい数字)もたくさん現れるわけですから、保持するk個の値はより小さい値で埋まっていくことになります。 
言い換えると、k に含まれる値が小さいほどユニーク数が多そうだと言えます。
KMV ではこの k 個の中の最大の値 R を使って、ユニーク数を推定します。
<pre><code class="language-bash">推定値 = k / R
</code></pre>
たとえば、 ハッシュ関数の出力が[0, 1)、 k=3 、R=0.5であれば、6個のユニークなキーがあると推定されます。
<img src="https://ik.imagekit.io/plaid/9d6a250e-5997-42ce-93fd-a3102b6cb6e6/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-04-0415.36.59.png" alt="スクリーンショット2025-04-0514.30.38.pngスクリーンショット2025-04-0415.36.59.png"> 
挿入の計算量はO(log k)で他の手法に劣りますが、メモリはかなり小さく保てます。
分散システムで顕著ですが、集計処理ではノード間での中間集計結果の受け渡しにコストがかかりがちです。そのコストが減らせるのも大きいメリットでしょう。
HyperLogLogより良いところとして、KMVはintersectionができます。実際の要素を保持していて、複数のSketchの共通要素を割り出せるためです。 
HyperLogLogでもunionはできるため包除原理で共通要素数の推定ができますが(|A ∩ B| = |A| + |B| - |A ∪ B|)、以下のように、対象のSketchが増えるほど非効率になっていきます。 
∣A∩B∩C∣=∣A∪B∪C∣−(∣A∣+∣B∣+∣C∣)+(∣A∩B∣+∣A∩C∣+∣B∩C∣) 
https://agkn.wordpress.com/2012/07/09/sketch-of-the-day-k-minimum-values/
<h1>Bitmap</h1>
入力が小さな整数であれば、Bitmap が使えます。キーに対応する位置のビットを立てていきます。たとえば入力のキーが42であればビット列の42番目を1にします。
挿入処理が軽いことと、最大値が小さければ小さい容量で表現できるのがメリットです。
以下は挿入処理の擬似コードです。
<pre><code>bitmap = int64[(N + 63) / 64]

insert(key):
 # word(int64)の位置の計算。key &gt;&gt; 6 は key / 64 の意味
 word_index = key &gt;&gt; 6
 # word内でのbit位置の計算。key &amp; 63 は key % 64 の意味
 bit_offset = key &amp; 63
 bitmap[word_index] |= (1 &lt;&lt; bit_offset)
</code></pre>
1キーに1byteを割り当てるシンプルなByteArrayにすれば、メモリを使う代わりにワードとビットの位置の計算も省略できそうです。CPUキャッシュミスが増える分遅くなることもあるので、データの特性によって検討するといいでしょう。
全てのキーを挿入したあと、立ってるビットを数えるにはCPU命令のpopcntを使うのが最も速いです。
古い言語や環境で動いていてpopcntが使えない場合はビットカウントアルゴリズムの出番です。もはや出番は少なさそうですが、面白いので紹介します。
ビットカウントアルゴリズムでは、ビット演算を駆使してビット列を2bit-&gt;4bit-&gt;8bitずつと小分けにして加算していきます。
以下分かりやすさのため8bitの入力を例にしますが、実際には64bitで処理することがほとんどです。
<pre><code>bit_count(bits):
 bits = (bits &amp; 0b01010101) + (bits &gt;&gt; 1 &amp; 0b01010101);
 bits = (bits &amp; 0b00110011) + (bits &gt;&gt; 2 &amp; 0b00110011);
 bits = (bits &amp; 0b00001111) + (bits &gt;&gt; 4 &amp; 0b00001111);
 return bits
</code></pre>
<img src="https://ik.imagekit.io/plaid/f72cdfe2-c328-4d7d-81b5-c53d8806fe53/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-04-0514.30.38.png" alt="スクリーンショット2025-04-0514.30.38.png">
基本的な演算をいくつか組み合わせるだけで何重にも並列で計算できてしまうのがすごいところです。
また、まとめてカウントするのではなく挿入時にビットのチェックをして都度カウントを増やす方法も取れます。空間に対して入力のキー数が少ないとわかっている場合は、その方が効率が良さそうです。ただしまとめてカウントする方も、分岐がない分CPU内での並列化も効いて速いので、多くの場合はそちらを採用していいと思います。(都度カウントしたいくらい入力が少ないとわかってるなら、そもそもBitmapよりHashTableの方が適してる気もします。最初のメモリ確保が小さく済ませられるため)
<h1>ベンチマーク</h1>
以下の3パターンでベンチマークを取りました。(kmvは良い実装が見つからず、AIもうまく書いてくれなかったので断念)
<ol>
<li>HashTable(key=32byte, <a href="https://github.com/attractivechaos/klib/blob/5c1451caa1ee476624d00eed71810532c89b82d1/khash.h">klibのkhash</a>)
<ol>
<li>ハッシュ関数はdjb2に類似した反復ハッシュ。Open AddressingでQuadratic Probing。初期サイズはデフォルトの16</li>
</ol>
</li>
<li>HashTable(key=4byte, kilibのkhash)
<ol>
<li>ハッシュ関数はThomas Wangハッシュ。他は同上</li>
</ol>
</li>
<li>Bitmap(key=4byte)</li>
</ol>
パターン1だけ入力のキー長が違います。意図としては、HashTableによるナイーブなユニークユーザカウント(UUIDを想定して32bytesのstring)と、最適化を意図してキーをint32にした手法を比較することです。
入力のデータセットは下記で、全てのキーを追加してユニークカウントを取るまでの時間を測りました。
<ul>
<li>トータルのキー数: 10,000,000</li>
<li>ユニークなキー数: 100,000</li>
<li>int32の場合の最大のキー: 10,000,000</li>
</ul>
それぞれ5回実行し、かかった時間の平均をとります。
コード: <a href="https://gist.github.com/takaaki7/5cdcee9cacd5133fde10c7f9edf114a2">uniqueue_count_algorithm_benchmark</a>
<h3>ベンチマークの結果</h3>
入力が32bytes stringのHashTableとint32(4bytes)のHashTableで、30倍の差が出ました。
<img src="https://ik.imagekit.io/plaid/aea5e11a-689f-4549-a63a-26c775cf601e/hashtablebench.png" alt="hashtablebench.png"> 
stringの方をperfで見ると、strcmpが特に重いです。キーの一致判定をしてる部分ですね。
<img src="https://ik.imagekit.io/plaid/c7bded59-2b26-4903-8479-63cbdbcc865c/hashtableperf.png" alt="hashtableperf.png"> 
今回はCPU観点だけでの比較ですが、データベース上での扱いを考えると、安くて遅いストレージとの通信を減らして如何にキャッシュに載せるかも肝になります。その観点でもデータを小さくすると圧倒的に速いです。
また、同じint32でもHashTableよりもBitmapの方が6倍速い結果でした。
<img src="https://ik.imagekit.io/plaid/fd06c926-424d-4ef8-9d1a-1d2f24316fc6/hashvsbitmap.png" alt="hashvsbitmap.png">
<h1>終わりに</h1>
行動分析に関して言えば、匿名ユーザも含めたデータ活用であればIDを4bytesまで短くすることは簡単ではないです。実際にはユニークユーザのカウントでここまで最適化した手法を使えることは多くないでしょう。
ただ本来は日本の全人口(1.2億)であってもわずか15mbのBitmapで表現できる量であり、空間分割や並列化を駆使しながら前処理をすればIDの短縮やBitmapカウントの適用も現実的なはずです。
この記事の内容はほんの一つに過ぎませんが、人の行動分析に対して、こういったアイデアを適用しながら新しいエンジンを開発中です。採用強化中です。応募待ってます！！
<div class="iframely-embed" data-embedded-url="https://open.talentio.com/r/1/c/plaid/pages/106299"><div class="iframely-responsive" style="padding-bottom: 30.2778%; padding-top: 120px;"><a href="https://open.talentio.com/r/1/c/plaid/pages/106299" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fopen.talentio.com%2Fr%2F1%2Fc%2Fplaid%2Fpages%2F106299&key=878c5bef402f0b2911bf6d4ce6261abd">Software Engineer, Database Internals / 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>

異なり数を数えるアルゴリズムの概要と、それらのパフォーマンスについて比較しています

異なり数を数えるアルゴリズムとパフォーマンス比較

Engineer Blog

Recent Article

動的にSQLを生成する複雑なロジックに立ち向かい、開発スピードを向上させた話

生成AI、どう使う？プレイド社内LT会で活用のヒントを探ってみた！

当エンジニアブログで実施したアクセシビリティ改善の方法についての解説

アクセシビリティ学習の手引きとしての入門講座

マルチプロダクトにおける全操作を網羅する監査ログ収集基盤：設計思想と実装 - 収集編

KARTE Messageの大量メール配信を支える技術

プレイドで7ヶ月間の開発インターンで体験したことと得られた学び

AIエージェントによるセキュリティレビューことはじめ

MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーション

異なり数を数えるアルゴリズムとパフォーマンス比較

Popular Articles

Popular Tags

Archives

Writers

Recent Article

動的にSQLを生成する複雑なロジックに立ち向かい、開発スピードを向上させた話

生成AI、どう使う？ プレイド社内LT会で活用のヒントを探ってみた！

当エンジニアブログで実施したアクセシビリティ改善の方法についての解説

アクセシビリティ学習の手引きとしての入門講座

マルチプロダクトにおける全操作を網羅する監査ログ収集基盤：設計思想と実装 - 収集編

KARTE Messageの大量メール配信を支える技術

プレイドで7ヶ月間の開発インターンで体験したことと得られた学び

AIエージェントによるセキュリティレビューことはじめ

MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーション

異なり数を数えるアルゴリズムとパフォーマンス比較

Popular Articles

Popular Tags

Archives

Writers

生成AI、どう使う？プレイド社内LT会で活用のヒントを探ってみた！