Anri Nakamura

icon.JPG

Kakemu Fujii

image.png

Kento Kaseda

IMG_7153.jpg

Reo Hakuta

T024HQQE3-U092QGQE6TD-6a515e5ed5a1-512.jpeg

Erika Sakurai

PL00879_櫻井絵理香.jpg

erikasakurai

Takaharu Nakamura

64473501.jpeg

Daichi Hachisuka

DSC04612_Original.jpg

Louis Avondet

PL00872_アボンデットルイ.jpg

Sota Sato

スクリーンショット2025-08-0410.34.30.png

Taira Ouchi

rami.png

Yuta Azumi

1000000936.jpg

Takahiro Hayashi

T024HQQE3-U05ECP8NVNC-90c78b4316d9-512.png

Kairi Ueno

2025-04-3019.32の画像.jpeg

Hiroki Tamiya

DSC01440@0.5x.jpg

Yugo Tsuchiya

登壇用.jpg

TomokiIchikawa

T024HQQE3-U05R70YBU2Z-bec7c6fdb311-512.jpeg

Yoshito Ikeda

IMG_3849_Original2.jpg

Haruki Tazoe

PL00808_田添春樹.jpg

Hajime Shiozawa

me_2.jpg

Kazuki Katsurada

PL788_桂田一輝.jpg

masashi kobayashi

LINE_ALBUM_夏合宿1日目_211219.jpg

lapla

qXlgxIG.JPG

Takehiko Okayama

ising.jpg

Kotaro Ito

IMG_5615.jpg

Yuhei Yasuda

yuhei.png

naoyashiga

1988660.jpeg

Takumi Ishii

ta9mi141.jpg

Sojiro Nishimura

icon.jpg

Katsumi Kobayashi

Kota Momoki

kF5sqT1m.jpg

Calloc

Shohei Shiraki

shiraki______.jpg

Takaaki Kanetsuki

IMG_4303.jpg

Yui Taniyama

profile_square.jpg

Kota Yatagai

icon.jpeg

Shuhei Kondo

DSC08585(3).jpg

kenshin tanaka

T024HQQE3-U05PBDAFRL6-979e9b2e96f8-512.jpg

KARTE Team

Security Team

Tomoya Koike

DSC02389.jpg

Haruki Tosa

DSC07358.jpg

Daiki Sakuma

スクリーンショット2022-09-1619.42.09.png

Takuma Shibuya

MCDV-G5y_400x400.jpeg

Takami Yamada

263231d5b255b21a5ccd1162caf4083d.jpg

Blocks Team

blocks_kaologo.png

Takanori Koga

iOSの画像.jpg

Takumi Katayama

me.jpeg

Yu Nishimura

unnamed.jpeg

Takuya Ogawa

akira.kasuga

Image-from-iOS--6------.jpg

Kosuke Oya

T024HQQE3-ULFR092SZ-a4325a429fda-512.jpeg

Yoshiyuki Komazaki

18051810.jpeg

mizchi

saboten.jpeg

Ryosuke Suzuki

myicon.jpg

koichi tanaka

Arnaud Avondet

githubprofile.png

6123322.png

kazupon

kazupon.jpg

daigo.isamatsu

-------.jpg

Jun Kusahana

kusahana.jun.jpg

Shinnosuke Ozawa

13511952_1732262680380481_2882139288629919103_n.jpg

Rei Ishikawa

rei_120.jpg

Hiroto Harada

profile_picture.jpg

Kei Tamiya

DSC06712_428.jpg

Nobuhiro Ito

itou.jpg

kazushi oohira

img_jobs_member_engineer31.jpg

Yohei Meguro

profile.jpg

Kazuto Kojima

kojimakazu.jpg

Tomoki Koga

photo_small.jpg

Kenichi Suzuki

11149348_10152861565996849_7684135567764915302_n.jpg

Takaaki Nakama

img_jobs_member_engineer24.jpg

Takahiro Tokunaga

Kohei Kadowaki

img_jobs_member_engineer21.jpg

kantetsu

img_jobs_member_engineer26.jpg

Makoto Kataigi

0404f91a9221606863b30a9472cbde90.jpg

Tatsuya Monoi

T024HQQE3-U1TBZVDEV-10a0922337c3-192.png

Jumpei Ikegami

ikegami.png

Masahiro Yamauchi

1666877493439_2.jpg

Shinji Eto

icon_eto.jpg

Yuta Nishimura

nishimura.yuta.jpg

Hideyuki Okada

IMG_8569-1.jpg

Wataru Ikarashi

20.png

Naoto Kato

kato02_480.png

Yuki Makino

img_makino.jpg

Atsushi Fujikawa

50065592145_352030691b55e725600d_1024.png

Naohiko Takemura

plaid_takemura.jpg

Daikichi Sasamori

13315227_1049838825099360_5485113047721634423_n.jpg

Atsushi Kobayashi

koba.png

Naoki Shibayama

c2c65af5b873f0db61c538c89284c9ad.jpg

Daiki Matsui

ikemonn.jpeg

Yohei Noda

profile2.jpeg

plaidinc

cover-image.png

cover-image

今回はKARTE Messageの管理画面の開発で行った、契約による設計を参考にしたエラー通知の切り分け方法を紹介します。

KARTE Messageはマルチチャネル(Mail/アプリPush/ LINE

 )での大量配信を行えるMAツールです。

最大2000rps近くの速度で配信しており、大量かつ高速な配信ができるMAツールとなっています。

で紹介しているので、そちらをご覧ください。

KARTE Messageにおけるエラー通知の課題

多様なユーザー入力とエラーの関係

KARTE Messageでは、自由度の高いユーザー入力を取り扱っています。

これらの入力値の中には、構文エラーや論理的に無効な設定が含まれる場合があります。これらは「ユーザーが修正すべきもの」であり、必ずしも「システム的に問題がある状態」ではありません。

を呼び出すと、Datadogへの記録と同時にSentry（およびSlack）へ通知が飛ぶ仕組みになっています。
しかし、ユーザー入力に起因するエラーまで全てSentryに通知されていたため、以下の問題が発生していました。

「契約による設計」をベースにしたエラーの再定義

ユーザー起因のエラーとシステム起因のエラーを明確に分けるため、

 メソッド実行時に呼び出し側が満たすべき条件です。

メソッド終了時に保証されるべき条件です。

エラーハンドリングをしやすくするため、それぞれ型を実装しています。

export class PreConditionError extends Error {
  constructor(public readonly message: string) {
    super(message);
    this.name = 'PreConditionError';
  }
}

export class PostConditionError extends Error {
  constructor(
    public readonly message: string, 
    public readonly originalError?: unknown
  ) {
    super(message);
    this.name = 'PostConditionError';
  }
}

アプリケーションの処理が完了して、レスポンスを返す処理のあるhandlerで以下のようなエラーハンドリングを行っています。

export const errorHandler = (_request, res, error: unknown) => {
  if (error instanceof PreConditionError) {
    // ユーザー起因なので Info ログ（通知しない）
    logger.info('PreConditionError occurred', { error });
    return res.status(400).send({ error_message: error.message });
  } 
  
  if (error instanceof PostConditionError) {
    // システム起因なので Error ログ（Sentry通知）
    logger.error(error.message, { 
      isUnknownError: false, 
      originalError: error.originalError 
    });
    return res.status(500).send({ error_message: "Internal Server Error" });
  }

  // 想定外のエラーも通知対象とする
  logger.error("Unknown Error occurred", { error });
  return res.status(500).send({ error_message: "An unexpected error occurred" });
};

導入後の変化とこれからの課題

Slack通知が「対応が必要なもの」だけに絞られたことで、チーム内のアラートに対する意識が改善しました。「通知が鳴った＝すぐに確認」という文化が徐々に醸成されてきています。

開発時も全てエラーとしてしまうのではなく、ユースケースから考えてどのようにエラーハンドリングすべきかを考えるきっかけにもなっています。

ライブラリが内部で発生させるランタイムエラーなど、本来は事前条件違反だが実装時には判断できないものがあり、事後条件違反として誤アラートされるケースがあります。これらをどう分類し直すかは、今後の改善ポイントです。

KARTE Messageは大規模な配信をしているので、そちらの配信基盤に目が向きがちですがシステムの安定稼働のためwebアプリケーションの開発・改善にも力を入れています！

はじめに

こんにちは、プレイドのKARTE Messageチーム エンジニアの土谷です。

今回はKARTE Messageの管理画面の開発で行った、契約による設計を参考にしたエラー通知の切り分け方法を紹介します。

KARTE Messageについて

KARTE Messageはマルチチャネル(Mail/アプリPush/ LINE[1] )での大量配信を行えるMAツールです。

最大2000rps近くの速度で配信しており、大量かつ高速な配信ができるMAツールとなっています。

詳しくは過去のブログで紹介しているので、そちらをご覧ください。



KARTE Messageにおけるエラー通知の課題

多様なユーザー入力とエラーの関係

KARTE Messageでは、自由度の高いユーザー入力を取り扱っています。





配信対象を抽出するためのクエリ



相対日付（「n日前」など）による複雑なフィルタ条件



配信スケジュール（開始日とタイミングの組み合わせ）

これらの入力値の中には、構文エラーや論理的に無効な設定が含まれる場合があります。これらは「ユーザーが修正すべきもの」であり、必ずしも「システム的に問題がある状態」ではありません。

従来の通知の仕組みと課題

KARTE Messageでは、独自実装したlog.error()を呼び出すと、Datadogへの記録と同時にSentry（およびSlack）へ通知が飛ぶ仕組みになっています。
しかし、ユーザー入力に起因するエラーまで全てSentryに通知されていたため、以下の問題が発生していました。





オオカミ少年化: 通知が多すぎて、誰も即座には反応しなくなる。



管理コストの増大: SentryのIssueが膨れ上がり、トリアージが困難になる。

「契約による設計」をベースにしたエラーの再定義

ユーザー起因のエラーとシステム起因のエラーを明確に分けるため、契約による設計の概念を取り入れました。

1. 事前条件(PreCondition)

 メソッド実行時に呼び出し側が満たすべき条件です。





例: キャンペーンの公開時に開始時刻が現在時刻よりも前（過去） に設定されている。



対応: ユーザーに修正を促す（400系エラー）。エンジニアの即時対応は不要。

2. 事後条件(Postcondition)

メソッド終了時に保証されるべき条件です。





例: キャンペーン公開時にネットワークエラーでDBへのデータの書き込みに失敗する。



対応: システムの異常、外部サービスのダウンなど。エンジニアが調査・対応すべき（500系エラー）。



実装例

エラークラスの定義

エラーハンドリングをしやすくするため、それぞれ型を実装しています。

export class PreConditionError extends Error {
  constructor(public readonly message: string) {
    super(message);
    this.name = 'PreConditionError';
  }
}

export class PostConditionError extends Error {
  constructor(
    public readonly message: string, 
    public readonly originalError?: unknown
  ) {
    super(message);
    this.name = 'PostConditionError';
  }
}

handlerでのハンドリング

アプリケーションの処理が完了して、レスポンスを返す処理のあるhandlerで以下のようなエラーハンドリングを行っています。

export const errorHandler = (_request, res, error: unknown) => {
  if (error instanceof PreConditionError) {
    // ユーザー起因なので Info ログ（通知しない）
    logger.info('PreConditionError occurred', { error });
    return res.status(400).send({ error_message: error.message });
  } 
  
  if (error instanceof PostConditionError) {
    // システム起因なので Error ログ（Sentry通知）
    logger.error(error.message, { 
      isUnknownError: false, 
      originalError: error.originalError 
    });
    return res.status(500).send({ error_message: "Internal Server Error" });
  }

  // 想定外のエラーも通知対象とする
  logger.error("Unknown Error occurred", { error });
  return res.status(500).send({ error_message: "An unexpected error occurred" });
};

導入後の変化とこれからの課題

良かったこと

Slack通知が「対応が必要なもの」だけに絞られたことで、チーム内のアラートに対する意識が改善しました。「通知が鳴った＝すぐに確認」という文化が徐々に醸成されてきています。

開発時も全てエラーとしてしまうのではなく、ユースケースから考えてどのようにエラーハンドリングすべきかを考えるきっかけにもなっています。

残っている課題

ライブラリが内部で発生させるランタイムエラーなど、本来は事前条件違反だが実装時には判断できないものがあり、事後条件違反として誤アラートされるケースがあります。これらをどう分類し直すかは、今後の改善ポイントです。

最後に

KARTE Messageは大規模な配信をしているので、そちらの配信基盤に目が向きがちですがシステムの安定稼働のためwebアプリケーションの開発・改善にも力を入れています！

興味がある方は採用ページをご覧ください。お待ちしております！



[1]: LINEとの連携機能は現状β版として提供しています。



「契約による設計」を応用し、エラー通知のノイズを激減させる — KARTE Messageにおけるエラーハンドリング改善

Engineer Blog

Recent Article

ArduinoとDatadogでオフィスの温度と湿度を可視化する

プレイドのエンジニアブログを始めました！

Popular Articles

Popular Tags

Archives

Writers