amazon-ses

Amazon SES

概要

推奨：サンドボックス環境での実行と CloudTrail の監査ログ記録には、SES の権限を付与した AWS MCP Server を使用してください。 MCP を使用しない場合：すべての操作で標準の AWS CLI 構文（aws sesv2 ...）を使用します。

メール認証の専門知識がない開発者でも、空の AWS アカウントから、認証済みのメールを受信トレイに届けられるようにします。AWS が申請を承認した場合は、その後、本番環境での送信へ進めます。

何かに手を加える前にアカウントとアイデンティティの状態を確認し、実際に不足しているドメイン設定だけを完了してください。ドメイン設定が完了し、ユーザーから明示的な同意を得た後にのみ、本番アクセスを申請してください。テスト送信は任意です。ユーザーから依頼があった場合に、アカウントの現在の状態で送信が許可されている宛先へ実行してください。

ルーティング

ユーザーの要望	参照先
SES を使い始める、メール送信を設定する、最初のメールまたはテストメールを送信する、サンドボックスを解除する、または MessageRejected: Email address is not verified の原因を調べる	SES の導入：最初のメール配信まで
送信用のドメインを設定する、メール認証を設定する、または DKIM の問題をトラブルシューティングする	SES ドメインアイデンティティの設定

ガードレール — このスキルのファイルの保存場所（MCP とローカルインストール）

このスキルは 2 通りの方法で読み込まれ、それぞれ同梱ファイルの参照先が異なります。リファレンスを読む前に、スキルがどの方法で読み込まれたかを確認してください。

• AWS MCP の retrieve_skill ツール経由で読み込まれた場合： スキルはローカルファイルシステム上にありません。file パラメーターを指定して retrieve_skill 経由で各リファレンスを取得する必要があります（例：file="references/onboarding.md"）。これらのパスはディスク上に存在しないため、ローカルで file_read を使って読み込まないでください。
• ローカルにインストールされている場合（例：~/.kiro/skills/amazon-ses/、.kiro/skills/amazon-ses/、または ~/.claude/skills/amazon-ses/）：上記の相対パスを使って、ローカルのスキルディレクトリからファイルを読み込んでください。

この区別が適用されるのは、スキルに同梱されたファイルのみです。ユーザーデータとセッションの成果物は常にユーザーの作業ディレクトリから読み書きしてください。顧客データを retrieve_skill 経由で取得したり、書き込んだりしないでください。

重要なルール

• 必ず SES v2 API を使用してください。aws sesv2 ... を使用し、v1 の aws ses ... コマンドは決して使用しないでください。v1 コマンドは、誤った API が選択されたことを示すエラーを返さないため、間違いに気づけないままになります。また、このワークフローで必要となる本番アクセスのリクエストと、DKIM および MAIL FROM 属性を単一のアイデンティティ読み取りで取得する機能は、v2 にしかありません。公開されている CLI の例でトレーニングされたモデルは、v1 の構文をデフォルトで使用する傾向があります。
• API バージョンの仕組み、内部の制限値、その他の内部処理について、自発的に説明してはいけません。 ユーザーが決定、同意、支払い、または実行する必要があることだけを説明してください。それ以外は、ユーザーから尋ねられた場合、問題の解決に関わる場合、または参照ファイルで開示が必須とされている場合にのみ伝えてください。
• 不足している入力は、個別に一つずつ尋ねるのではなく、一度の質問セットにまとめて尋ねてください。また、リクエストで必要とされていない入力を尋ねてはいけません。 質問の範囲はユーザーの依頼に合わせてください。ドメインと MAIL FROM サブドメインがすでに指定されている依頼は、ドメイン設定の依頼として完結しています。そのため、送信時期や本番アクセスに関する入力がなくても、状態を読み取って実行し、質問のために処理を止めてはいけません。選択した範囲で不足している情報がなければ、質問は不要です。
• AWS CLI のプロファイルまたはリージョンを特定できる可能性がある限り、どちらを使用するか尋ねてはいけません。 --profile は、ユーザーが指定した場合にのみ使用してください。次の順にリージョンを解決し、値が得られた最初の項目を採用してください。ユーザーが指定したリージョン、AWS_REGION、AWS_DEFAULT_REGION、aws configure get region。ユーザーがプロファイルを指定した場合は、プロファイルに独自のリージョンが設定されている可能性があるため、最後のコマンドに --profile '{PROFILE}' を追加してください。この最後のコマンドが読み取るのは CLI 設定ファイルのみで、環境変数は参照しません。そのため、2 つの環境変数は別途、かつ先に確認します。変更を行う前に、解決したリージョンを伝えてください。 SES の状態はリージョンごとに異なるためです。また、aws sts get-caller-identity の結果からアカウントとプリンシパルを報告してください。質問が必要なのは次の 2 つの場合に限られます。どの方法でもリージョンが得られない場合（リージョンがなければ aws sesv2 の呼び出しはすべて失敗します）、および認証情報の期限切れまたは無効により aws sts get-caller-identity が失敗する場合です。後者の場合は、設定済みのデフォルトを信頼できなくなるため、認証情報が更新された後に使用するアカウント（プロファイル）とリージョンを尋ねてください。どちらの場合も、質問のために追加のターンを設けず、一度の質問セットにまとめてください。
• リクエストのペイロード（変更バッチやメッセージ内容）は、必ずインライン JSON 文字列として CLI に渡してください。file:// パスは使用しないでください。 file:// は AWS CLI 固有であり、AWS MCP サーバー経由で CLI を実行した場合には解決されません。
• 各ステップの前に現在の状態を読み取り、すでに満たされているステップはスキップしてください。 特に、すでに存在するアイデンティティに対して create-email-identity を呼び出してはいけません（AlreadyExistsException が返されます）。また、DkimAttributes.Status が SUCCESS のアイデンティティに対して put-email-identity-dkim-signing-attributes を再実行してはいけません。再初期化によってトークンが変わる場合があります。この呼び出しの実行可否は、公開された CNAME が名前解決されるかどうかではなく、ステータスで判断してください。 FAILED のアイデンティティでは、レコードが名前解決されても有効として扱われていないことがよくあります。これこそが FAILED の意味であり、レコードが名前解決されることは復旧処理を控える理由にはなりません。ステータスに基づく復旧パスと、それに先立つ BYODKIM の確認は、setting-up-ses-domain-identity.md が扱います。
• ドメインを設定する場合は、ドメインアイデンティティを作成してください。 メールアドレスアイデンティティを作成するのは、ユーザーが個別のアドレスの検証を明示的に選択した場合に限ります。

不変条件

これらは、このスキル全体に適用されます。参照ファイルはこれらを適用し、ワークフロー固有の詳細を追加できます。たとえば、特定のステップで不変条件を確認する方法を示したり、そのステップの状態に合わせて適用範囲を狭めたりできます。いずれの参照ファイルも、ここに記載された内容に反したり、緩和したりしてはいけません。

• ドメイン設定完了とは、1 回の aws sesv2 get-email-identity レスポンスで次の 3 つすべてが真であることを意味します。VerifiedForSendingStatus が true であること、かつ DkimAttributes.Status が SUCCESS であること、かつ MailFromAttributes.MailFromDomainStatus が SUCCESS であること。3 つのうち 2 つでは完了ではありません。MailFromDomainStatus が PENDING、FAILED、または TEMPORARY_FAILURE の間、AWS のドキュメントによると SES はカスタム MAIL FROM のフォールバック設定を使用します。USE_DEFAULT_VALUE の場合、amazonses.com のサブドメインを使って送信するため、SPF は検証されますが、エンベロープ送信者が From ドメインとアラインメントせず、DMARC はその SPF レッグで通過できません。REJECT_MESSAGE の場合、SES は MailFromDomainNotVerified を返し、配信を試みません。これが、このスキルの残りの部分が「ドメイン設定完了」と呼ぶゲートです。
• サンドボックスの受信者ルール。 ProductionAccessEnabled が false の間、AWS のドキュメントによると、検証済みのメールアドレスおよびドメイン、または Amazon SES メールボックスシミュレーターにのみ送信できます。つまり、このスキルが常に提示する順序で言うと、(1) それ自体がメールアイデンティティとして検証されたアドレス、(2) Amazon SES メールボックスシミュレーター、または (3) アカウント内の任意の検証済みドメインの任意のアドレス — 設定したばかりのドメインだけでなく — です。制限は送信者ではなく受信者に課されます。完全に検証された送信ドメインがあってもこの制限は解除されず、決してこれを回避しようとしてはいけません。プロダクションアクセスは ProductionAccessEnabled のみによって決まります — これが false である間は、Details.ReviewDetails.Status が何を言っていても、これらの 3 つの選択肢が適用されます。ユーザーにこの制限を説明するときは、プロダクションアクセスを解決策として提案する前に、今すぐ機能する 3 つの受信者オプションすべてを同じ番号順で挙げなければならず、この制限を「各受信者を個別に検証する必要がある」と説明してはいけません。検証済みのドメインは、そのドメインのすべてのアドレスをカバーします。
• 送信者も、どのアカウント状態でも検証されている必要があります。 AWS のドキュメントによると、アカウントがプロダクションに移行した後も「『From』、『Source』、『Sender』、または『Return-Path』アドレスとして使用するすべてのアイデンティティを検証する必要があります」。したがって、MessageRejected: Email address is not verified には 2 つの原因があります。サンドボックスで許可されていない受信者と、どの状態でも検証されていない送信アイデンティティです。修正方法を選ぶ前に、エラーで示されたアドレスを読み、From アドレスがこのリージョンで検証されたドメインまたはアドレスにあることを確認してください。
• 検証済みの送信者は SES サービスの最低要件であり、このスキルのジャーニーはそれ以上のものを求めます。 SES 自体は、DKIM が SUCCESS に達していなくても、送信用に検証されたアイデンティティからの送信を受け付けます。このスキルは、あえてそこで止まりません。その目標は配信され、認証された最初のメールであるため、ドメイン設定や認証が完了したと主張する前、および送信する前に、DkimAttributes.Status: SUCCESS を要求します。このより厳しい基準は、onboarding.md のドメイン検証ステップにおける送信の前提条件として一度述べられており、すべての送信パスに適用されます。この 2 つは矛盾していません。一方はサービスが強制するものであり、もう一方はこのジャーニーがユーザーに約束するものです。
• 代入するすべての値を検証し、その後、そのコンテキストに応じて引用符で囲みます。 シェルコマンドに直接補間される値はシングルクォートで囲みます。インライン JSON 内に配置される値は JSON エンコードし (JSON の規則に従い二重引用符を使用)、シェル用にシングルクォートで囲むのは JSON ブロック全体のみです — JSON 内の個々の値をシェル用にクォートしないでください。これは、このスキルが代入するすべてのユーザー提供値 — DOMAIN、MAIL FROM サブドメイン、FROM_ADDRESS、TEST_RECIPIENT、CHOSEN_RECIPIENT、MAIL_TYPE、WEBSITE_URL、REGION、PROFILE — に適用され、DNS 名だけではありません。シングルクォートまたは二重引用符、バッククォート、$、;、バックスラッシュ、または空白文字を含む値は拒否し、ユーザーに再提供を求めてください。拒否された値を無理やり整えてエスケープしないでください。値ごとの形式: DOMAIN と MAIL FROM サブドメイン — DNS ラベルのみ、英字、数字、ハイフン、ドット。From アドレスとすべての受信者値、TEST_RECIPIENT と CHOSEN_RECIPIENT の両方 — @ を 1 つ含む単一のアドレスとし、カンマ区切りのリストは拒否してください (複数の受信者は代わりに ToAddresses 配列に入れます)。MAIL_TYPE — 正確に TRANSACTIONAL または MARKETING。WEBSITE_URL — 1〜1000 文字の http/https URL で、検証済みドメインにある必要はありません。メールに関連する事業サイトであれば AWS にとって許容されるため、質問セットでは提案されるデフォルトとしてのみ https://{DOMAIN} を提示してもかまいません。REGION — AWS リージョンコード。PROFILE — CLI プロファイル名。ユーザーではなくスキルが提供するオプション — メールボックスシミュレーターアドレス — からバインドされる CHOSEN_RECIPIENT も同様に検証されます。ユーザー提供の件名または本文テキストは、引用符の間に貼り付けるのではなく、シリアライザーで JSON エンコードしてください。

IAM のアクセス許可

実行するワークフローが実際に呼び出すアクションだけを許可し、それ以外は許可しないでください。ses:* や*FullAccessは決して許可しないでください。各リファレンスファイルのRequired IAM actionsセクションには、呼び出すアクションが正確に列挙されています。ワイルドカードではなく、そのリストを使用してください。

ID ごとのアクションは、各呼び出しが実際に対象とする ID にスコープしてください。

• ドメインの操作にはarn:aws:ses:{region}:{account-id}:identity/{domain}を指定します。
• メールアドレスの ID にはarn:aws:ses:{region}:{account-id}:identity/{address}を指定します。これは、サンドボックスの受信者確認で使用する ID であり、送信者が別途確認済みのメールアドレスで、ドメインのアドレスではない場合は、From ID にもなります。ドメインだけにスコープされたポリシーでは、これらの呼び出しは拒否されます。読み取りも同じ方法でスコープします。ses:GetEmailIdentityステートメントには、実際に読み取るすべての ID の ARN を含める必要があります。これには、受信者のメールアドレス ID と、サンドボックスの受信者オプション 3 でユーザーが指定する、別の確認済みドメインの正確な ID ARN が含まれます。送信元ドメインだけにスコープされたポリシーでは、その読み取りが拒否され、受信者が指定されていないのではなく、権限が壊れているように見えます。送信はFromアドレスをカバーする ID によって許可されるため、ses:SendEmailは該当する ID にスコープしてください。3 つのケースはonboarding.mdのRequired IAM actionsに記載されています。
• Route 53 のゾーンアクション（route53:GetHostedZone、route53:ListResourceRecordSets、route53:ChangeResourceRecordSets）はarn:aws:route53:::hostedzone/{hosted_zone_id}に指定します。ここではゾーン ID のみを使用してください。list-hosted-zones-by-nameは/hostedzone/Z123ABCを返すため、ARN の作成前にこのプレフィックスを取り除いてください。そうしないと、プレフィックスが二重になり、何にも一致しません。エージェントが Route 53 でドメインをホストしているかどうかを確認する場合は、ゾーンの読み取りが必要です。route53:ChangeResourceRecordSetsのみ、ユーザーが書き込みを承認した場合に必要です。

アカウントレベルまたは一覧取得に該当するアクション（sts:GetCallerIdentity、ses:GetAccount、ses:ListEmailIdentities、route53:ListHostedZonesByName、route53:TestDNSAnswer）だけはリソースレベルでスコープできないため、*に対して許可する必要があります。ses:PutAccountDetailsはアカウント全体の送信設定を変更するため、意図を持って許可してください。

セキュリティに関する考慮事項

• **一時的な認証情報。**STS を使用する IAM ロールを使い、長期有効なアクセスキーは決して使用しないでください。
• **同意ゲート。**本番アクセスの審査を開始することも、実際のメッセージを送信することも、API では取り消せない形でユーザーの意思を確定します。また、Route 53 の変更は実際のトラフィックに影響する可能性があります。本番アクセスへの同意ゲート、送信確認、DNS 書き込みの許可という各ゲートは、アクションを実行するリファレンスファイルが管理します。このファイルに要約されているからといって、ゲートを通過して先に進んではいけません。
• **配信時の TLS は、デフォルトではベストエフォートです。**AWS のドキュメントによると、SES は受信メールサーバーへのセキュアな接続を常に試み、確立できない場合は暗号化せずにメッセージを送信します。また、TLS を必須にするには、構成セットのTlsPolicyをREQUIREに設定する必要があります。構成セットを使うワークフローは、このスキルの対象外です。
• シェルコマンドやインライン JSON に値を渡す前に、ユーザーが指定した値をすべて検証し、引用符で囲んでください。ルールと文字セットは、上記の「不変条件」に記載されています。
• メッセージ本文や受信者リストをログに記録しないでください。
• **例に認証情報、エンドポイント、シークレットをハードコードしないでください。**アプリケーションの認証情報は AWS Secrets Manager または Parameter Store に保存してください。
• SES API 呼び出しの監査には CloudTrail を有効にし、AccessDeniedExceptionの繰り返し発生や異常な送信量に対してアラームを設定してください。証跡のログファイルは AWS KMS キー（SSE-KMS）で暗号化し、証跡の S3 バケットと CloudWatch Logs グループへのアクセスを制限してください。また、ロググループも KMS キーで暗号化してください（create-log-groupで--kms-key-idを指定）。SES の CloudTrail エントリには、メールアドレス、ドメイン名、アカウントの詳細が含まれます。

Additional Resources

• Request production access
• SES Domain Verification
• DKIM in SES
• Custom MAIL FROM
• DMARC Authentication
• SESv2 API Reference