AIコーディングエージェント 2026.05.31 更新: 2026.06.01

Codexにメール・通知文面を任せる前に決めること

3行まとめ

Visual通知変更前の4点送る前に分けます。

Audience

対象。

Purpose

目的。

Opt-out

停止。

Test

確認。

メール文面変更は、文章だけでなく送信対象と停止導線の変更です。

Codexにメール・通知文面を任せる時は、文面だけでなく、送信対象、primary purpose、unsubscribe、suppression、locale、template variable、test inboxを先に決めます。
commercial emailとtransactional/relationship emailを混同しないよう、法務・運用の判断と実装変更を分けます。迷う場合は社内の責任者に確認します。
本番宛先で試さず、test inbox、seed data、preview、raw payload、approval、送信ログを通してから公開します。

メールや通知の文面変更は、小さな作業に見えます。件名を直す。CTAを変える。翻訳を足す。テンプレート変数を追加する。送信条件を少し変える。Codexに任せると、文面とコードの差分はすぐ作れます。

ただ、メールは届いた後に取り消しにくいです。送信対象を間違えると大量誤送信になります。unsubscribeを壊すと、受け取りたくない人へ送ります。template variableが欠けると、{{firstName}} のような生のplaceholderが届きます。locale fallbackがないと、違う言語や空文面になります。

この記事では、Codexにメール・通知文面の変更を任せる前に決めることを整理します。外部メールAPIのtimeoutやretryは公開済みのCodexに外部API連携を任せる前に決めることで扱いました。ここでは、文面、対象、停止導線、test送信に絞ります。

この記事でわかること

Visual確認する材料Codexへ渡す前の整理です。

Template

文面。

Locale

言語。

Suppression

抑止。

Approval

承認。

通知は届いてから取り消しにくいため、送信前の確認を厚くします。

メール・通知文面変更をCodexへ頼む前に決める7項目
commercial emailとtransactional/relationship emailを混同しない考え方
unsubscribe、group unsubscribe、suppression listを壊さないreview観点
locale、fallback、template variableの確認方法
test inbox、seed data、dry-runで本番宛先を使わない流れ
copy reviewとsend approvalを分ける理由
Codexへそのまま渡せる依頼packet
reviewで止めるべき危ない差分

この記事は法務助言ではありません。米国向けのcommercial emailではFTCのCAN-SPAMガイド、利用中のメールproviderのDocs、社内規程、対象国・地域の規制を確認してください。ここでは、開発現場でCodexへ依頼する前の実装チェックに留めます。

前提知識

Visual見る一次情報制度とproviderを分けます。

項目	内容	見方
FTC		CAN-SPAM。
Purpose		主目的。
SendGrid		停止。
Suppression		抑止。

commercialかtransactionalかで、必要な確認が変わります。

メールや通知には、文面、送信対象、送信条件、配信停止、送信provider、locale、tracking、ログ、承認が絡みます。Codexに文面だけを直させても、周辺の条件が変わると事故につながります。

FTCのCAN-SPAMガイドでは、commercial message、transactional or relationship message、headerやsubject、広告表示、住所、opt-out、opt-out処理期限などが説明されています。SendGridのDocsでは、unsubscribe methods、unsubscribe groups、suppression listの考え方が説明されています。

法務判断と実装判断を分ける

「これはmarketingかtransactionalか」は、実装者だけで決めないほうが安全です。product、legal、marketing、support、securityなど、組織の責任者が判断する領域です。

Codexには、判断済みの分類を渡します。判断させるのではなく、「このtemplateはtransactional」「このtemplateはmarketing」「このgroup unsubscribeを使う」のように条件を固定します。

文面変更も送信処理の変更として見る

件名や本文だけの変更でも、primary purpose、CTA、unsubscribe位置、差出人、reply-to、tracking、template variableが変わることがあります。文面変更は送信処理の一部としてreviewします。

変更前に決める7項目

Visual7つの決定文面前に決めます。

項目	内容	見方
Audience		対象。
Purpose		目的。
Channel		経路。
Locale		言語。
Variables		変数。
Opt-out		停止。
Approval		承認。

送信対象と目的が曖昧なまま文面だけ直すと、誤送信に近づきます。

Codexへ頼む前に、7項目を決めます。

項目	決めること	曖昧なまま起きること
audience	誰に送るか	対象外へ送る
purpose	commercialかtransactionalか	unsubscribeや表記がズレる
channel	email、push、in-app	文面と制限が混ざる
locale	言語とfallback	空文面や誤訳が出る
variables	template変数	placeholderが露出する
opt-out	停止導線	停止済みへ送る
approval	誰が送信承認するか	copy OKで送信される

Codexは自然な文章を作れますが、誰に送るべきか、どの停止導線を守るべきか、どの国の規制に該当するかは知りません。

送信対象を固定する

まず送信対象を固定します。全ユーザー、無料ユーザー、有料ユーザー、trial中、特定feature利用者、障害影響者、管理者、社内member。対象が違えば文面も停止導線も変わります。

送信対象はqueryやsegment名だけでなく、除外条件も書きます。退会済み、suppressed、bounce、spam report、unsubscribe済み、社内test user、法務除外対象などです。

文面のprimary purposeを見る

同じtemplateでも、内容によってprimary purposeが変わることがあります。障害通知にpromotionを混ぜる、契約更新メールにsale CTAを入れる、機能案内をtransactionalに見せる。こうした混在はreviewで止めます。

reviewで見ること

subject、preheader、CTA、本文冒頭、unsubscribe、住所、差出人、送信対象、trackingをまとめて見ます。文面だけ自然でも、目的と導線がズレていれば差し戻します。

unsubscribeとsuppressionを壊さない

Visual停止導線の確認送らない条件を守ります。

Global

全停止。

Group

種類別。

Bounce

不達。

Spam

苦情。

送る条件だけでなく、送らない条件を先に守ります。

メール変更で一番守るべきものの1つが、「送らない条件」です。

SendGridでは、global unsubscribe、group unsubscribe、bounces、invalid emails、spam reportsなどのsuppressionが扱われます。providerによって名称は違いますが、停止済みや送ってはいけない宛先を尊重する考え方は同じです。

group unsubscribeを分ける

marketing newsletter、product update、event invitation、security notification、billing noticeなど、通知の種類によって停止導線が違うことがあります。SendGridのASM tagsやunsubscribe groupsのような仕組みを使う場合、templateごとにgroup IDを間違えないようにします。

Codexへは、次のように渡します。

このtemplateはmarketing newsletter。
unsubscribe groupは NEWSLETTER_UPDATES。
global unsubscribeとbounce/spam suppressionは必ず尊重する。
billing/security系のtransactional templateとはgroupを混ぜない。

suppression listを上書きしない

suppression listは宛先リストではありません。停止・不達・苦情など、送らないための情報です。古いCSVやseed dataで上書きしないようにします。

注意点

unsubscribe linkを消す、group IDを変える、providerのtracking設定を切る、custom unsubscribe URLを壊す、といった変更は文面差分に見えても運用影響が大きいです。

localeとtemplate variableを確認する

Visualtemplate checks文面崩れを防ぎます。

項目	内容	見方
Locale		言語。
Fallback		代替。
Variable		変数。
Preview		表示。

翻訳と変数は、template previewだけでなく実際の送信payloadでも確認します。

通知文面では、localeとtemplate variableがよく壊れます。

日本語だけ直したつもりが英語fallbackに影響する。firstNameを追加したが一部ユーザーに値がない。日付formatがlocaleと合わない。金額やタイムゾーンが違う。button textが長すぎて崩れる。こうした問題は、previewだけでは見落としやすいです。

fallback文面を決める

対象localeに翻訳がない場合、どの言語へfallbackするかを決めます。fallbackなしで空文面になるのは避けます。

変数の欠落をtestする

template variableは、値あり、値なし、長い値、特殊文字、複数localeで確認します。Codexへはfixtureを作らせます。

firstNameあり/なし。
companyNameが長い。
localeがja/en/unknown。
unsubscribeUrlがある。
optional CTAがない。

reviewで見ること

undefined、null、空文字、raw placeholder、HTML escape漏れ、long word、tracking URL、unsubscribe URL、locale fallbackを見ます。

test inboxとdry-runを作る

Visual送信前の流れ本番宛先へ出す前に確認します。

1Render
生成。
2Seed
宛先。
3Send test
試送。
4Inspect
確認。
5Approve
承認。

test inboxを通すと、文面だけでは見えない崩れを見つけられます。

本番宛先でtestしないために、test inboxとdry-runを作ります。

test inboxは、メール確認専用の宛先です。seed user、seed segment、sandbox provider、preview API、raw MIME exportを使い、本番ユーザーへ送らずに確認します。

本番宛先を使わない

「自分の本番アカウントへ1通だけ送る」は、条件によっては本番送信経路を通ります。templateやsegmentの条件を間違えると、1通のつもりが広がることがあります。

Codexへは、送信実行ではなく、preview、dry-run、test provider、seed listまでを許可します。本番send commandは承認制にします。

screenshotとraw MIMEを残す

確認では、browser previewだけでなく、実際に届いたemail、mobile表示、dark mode、plain text、raw header、unsubscribe link、tracking linkを確認します。

条件

test結果はPRに残します。件名、送信対象、locale、主要変数、unsubscribe link、screenshot、送信しなかった本番対象を記録します。

approvalと送信ログを残す

Visual承認の流れ誰が送ったか残します。

Draft
下書き。
Review
確認。
Approve
承認。
Send
送信。
Monitor
監視。

copy reviewとsend approvalを分けると、誤送信を止めやすくなります。

copy reviewとsend approvalを分けます。

copy reviewは、文面、表現、法務・ブランド・サポート観点を確認するreviewです。send approvalは、実際に誰へ、いつ、どのtemplate versionで送るかの承認です。

copy reviewとsend approvalを分ける

文面がOKでも、送信対象やタイミングがNGなことがあります。逆に、送信対象が正しくても、文面が誤解を招くことがあります。承認を分けると、止めやすくなります。

rollbackは停止と差し替えで考える

送ったメールは回収できません。rollbackは、送信停止、template差し替え、follow-up訂正、segment停止、unsubscribe修正、provider suppression確認として考えます。

Codexへ渡す依頼packet

Visual依頼packetそのまま渡せる型です。

項目	内容	見方
Scope		範囲。
No send		禁止。
Vars		変数。
Tests		確認。
Owner		承認。

packet化すると、文面変更と送信操作を分離できます。

Codexへは、次のようなpacketで渡します。

目的:
  trial終了3日前のreminder email文面を更新する。

分類:
  marketing要素を含むため、unsubscribe groupを必ず維持する。
  法務確認済みの文面だけ使う。

対象:
  active trial userのみ。
  unsubscribed、bounce、spam report、退会済み、社内除外対象は送らない。

変更範囲:
  subject、preheader、body copy、CTA text。
  segment queryとsend commandは変更しない。

禁止:
  本番送信。
  unsubscribe link削除。
  suppression list変更。
  provider API keyの表示。

locale:
  ja/enを更新。未知localeはenへfallback。
  firstNameなし、companyName長文、CTAなしのfixtureを確認する。

test:
  test inboxへ送る。
  screenshot、plain text、unsubscribe URL、raw headerを確認する。

approval:
  copy ownerとsend ownerをPRに明記する。

このpacketがあれば、Codexは文面だけでなく、壊してはいけない送信条件を理解しやすくなります。

よくある失敗

Visualbad patterns通知変更で崩れやすい点です。

Wrong list

対象違い。

No opt-out

停止なし。

Broken var

変数欠落。

Live test

本番試送。

通知の事故は、実装の小さな変更が大量送信へ直結する時に起きます。

文面だけのつもりでsegment queryを変える

文面変更のPRで送信対象が変わると危険です。segment query、schedule、send command、provider settingは別reviewにします。

unsubscribe linkをデザイン都合で消す

unsubscribe linkは装飾ではありません。commercial emailで必要な場合があります。削除や移動は文面reviewだけで決めません。

suppression listをcontactsと混同する

suppression listは、送らないための情報です。contactsの更新と同じ感覚で触ると、停止済み宛先へ送る可能性があります。

locale fallbackを確認しない

翻訳がないlocaleで空文面になる、fallbackが違う、日付や金額が崩れる。localeはfixtureで確認します。

本番sendでpreviewする

本番sendはpreviewではありません。test inbox、sandbox、dry-runを使います。

FAQ

Visual判断の入口迷った時の見方です。

項目	内容	見方
Marketing?		確認。
Test?		必須。
Locale?		fallback。
Rollback?		停止。

迷ったら、誰に、なぜ、何を、どの停止導線付きで送るかへ戻ります。

transactional emailならunsubscribeは不要ですか

一概には言えません。FTCのCAN-SPAMガイドでは、transactional or relationship messageの分類が説明されていますが、実際の判断は内容や地域で変わります。社内の責任者に確認してください。

Codexに件名案を作らせてもよいですか

よいですが、deceptive subjectにならないよう、本文の内容と一致しているかをreviewします。件名だけで過度に煽らないようにします。

test inboxだけで十分ですか

十分ではありません。test inboxに加えて、locale、変数欠落、plain text、mobile、unsubscribe、送信対象、suppressionを確認します。

unsubscribe group IDはCodexへ渡してよいですか

ID自体がsecretでない場合もありますが、providerや社内運用によります。少なくともAPI keyやsecretは渡さず、環境変数や設定名で参照させます。

送信後に間違いに気づいたらどうしますか

送信停止、template差し替え、follow-up訂正、support向け説明、suppression確認、送信ログ保存を行います。回収できない前提でrunbookを用意します。

次に読むなら

Codexに外部API連携を任せる前に決めること

メールprovider APIのtimeout、retry、quota、mockを整理したい時に使えます。

Codexに本番データを渡す前に決めること

宛先、本文、ログ、screenshotにPIIが混ざる可能性を整理したい時に使えます。

Codexに運用手順を任せる前に決めること

本番送信の承認、停止、訂正、操作ログをrunbookへ落としたい時に使えます。

参照した主な情報源

更新履歴

Visual更新メモ公開時点の整理です。

2026.06.01
初版。

メール規制やprovider仕様は変わるため、導入時に公式情報を確認します。

2026.06.01: 初版公開。Codexへメール・通知文面を任せる前の送信対象、unsubscribe、suppression、locale、test inboxを整理しました。