SendGridのログインで迷う原因は、入口が一つではないことにあります。Twilioから直接契約したアカウントはTwilio Loginという共通ログインに統合され、構造計画研究所が提供する国内版はマイページとダッシュボードで使うIDが別々です。この記事では、どちらの契約かを見分ける方法、ログインできないときに確かめる順番、二要素認証の端末をなくした場合の解除依頼、共有アカウントをTeammatesやSSOへ切り替える設定を順に整理します。後半では、2FAを有効にするとBasic認証のAPI呼び出しが通らなくなる仕様を踏まえ、APIキーの権限とログインできる人をcurlとPythonで棚卸しする手順も示します。
まとめ｜SendGridログインで最初に確かめる契約経路と認証方式
最初に確かめるのは契約経路です。ドル建てでカード請求されているならTwilio直販で、入口はlogin.sendgrid.comです。円建ての請求書が届くなら構造計画研究所版で、契約者はマイページID、実際の送信設定はサブユーザ名またはTeammate名でダッシュボードに入ります。メールアドレスで入ろうとして弾かれる事例の多くは、この取り違えです。
次に二要素認証です。直販もダッシュボードも2FAは必須で、コードは7桁です。端末を失うと自力では戻れず、直販はTwilio SendGridサポート、国内版は契約者本人からの解除依頼が必要になります。
最後に、管理画面へのログインとシステムからの送信を切り離します。2FAを有効にしたユーザーの資格情報ではBasic認証のAPI呼び出しが受け付けられません。送信プログラムはAPIキーで認証し、人のログインは個別のTeammateかSSOにする。この形にしておけば、担当者の異動やパスワード変更で本番の送信が止まる事故を防げます。
SendGridのログイン画面が2系統ある理由と直販・国内版の入口
同じSendGridでも、契約の窓口が違えばログインの仕組みが別物になります。ここを取り違えたまま操作すると、正しいパスワードでも入れません。
Twilio直販アカウントのログインURLとTwilio Login統合の中身
Twilioから直接契約したアカウントは、login.sendgrid.comまたはapp.sendgrid.com/loginから入ります。現在はTwilio Loginという共通ログインが用意されていて、Twilio Comms・Segment・SendGridで同じメールアドレス、パスワード、認証設定を使えます。
注意したいのはリンク後の挙動です。Twilio Login Overviewには、SendGridアカウントをTwilio Loginにリンクすると従来のSendGridのログイン資格情報が無効になると書かれています。1つのSendGridアカウントをリンクできるTwilioアカウントは1つだけで、リンク後は同じメールアドレスで新しいSendGridアカウントを作れません。旧パスワードで入れなくなった場合は、リンク済みかどうかを先に疑います。
構造計画研究所版のマイページとダッシュボードで異なるログインID
国内版は、契約や請求を扱うマイページと、送信設定や統計を扱うダッシュボードに分かれています。国内提供元のログイン手順によると、ダッシュボードに直接ログインできるのはサブユーザとTeammateだけです。マイページIDでは入れず、ユーザ名欄にはメールアドレスではなくサブユーザ名かTeammate名を入れます。
ダッシュボードでは2FAの設定が必須で、初回ログイン時に設定を求められます。認証コードは7桁の数字で、AuthyまたはSMSで受け取ります。マイページ側の2FAはこれとは別の仕組みで、2026年3月から必須化されました。
契約経路ごとのログイン先とIDの対応表と請求通貨による見分け方
請求通貨と、手元にあるIDの形式を見れば判別できます。
| 契約経路 | ログイン先 | 入力するID | 2FAの方式 |
|---|---|---|---|
| Twilio直販 | login.sendgrid.com | メールアドレス（Twilio Login） | SMSまたは認証アプリ |
| 国内版マイページ | sendgrid.kke.co.jp | マイページID | TOTPアプリまたはメール |
| 国内版ダッシュボード | login.sendgrid.com/login/ | サブユーザ名・Teammate名 | AuthyまたはSMS |
国内版では、1人の担当者がマイページIDとTeammate名の2つを持つ構成が珍しくありません。どちらの2FAを設定した端末なのかも別々に管理します。
SendGridにログインできない原因と確認する順番の作業手順
原因の候補は多いものの、確認は次の順で進めると早く片づきます。契約経路とIDの形式、2FA、パスワード、請求状態の順です。
二要素認証の端末紛失やSMS不達で止まるときの契約経路別の解除依頼
直販のTwo-factor authenticationのドキュメントでは、2FAの方式はSMSと認証アプリの2つで、2FAが原因でアクセスを失った場合はTwilio SendGridサポートへ連絡するよう案内されています。管理者が画面上で解除できる手段は示されていません。
国内版のマイページは、二要素認証アプリの設定の説明どおり、Authy・Google認証システム・Microsoft AuthenticatorなどTOTP方式のアプリで確認コードを受け取ります。アプリ未設定の場合、コードの送付先は登録メールアドレスです。端末を紛失した場合は、契約者本人がマイページID・メールアドレス・氏名をフォームで送り、解除を依頼します。
どちらも復旧まで日数がかかります。2FAの端末は担当者の私物1台に寄せず、TOTPのシードを社内のパスワード管理ツールに保管する運用へ切り替えておくと、解除依頼そのものが不要になります。
パスワード変更で本番のAPI連携が止まる事故とユーザー名忘れ
Troubleshooting account login issuesには、パスワードのリセットは本番環境のAPIやSMTPの連携を壊す可能性があると明記されています。アカウントのユーザー名とパスワードを送信プログラムに埋め込んでいる古い構成では、ログインのためにパスワードを変えた瞬間に送信が止まります。
ユーザー名を忘れた場合は、サポートの専用フォームから問い合わせます。同じドキュメントは、認証情報を複数人で共有していると誰かが変更した可能性がある点も挙げています。共有アカウントがある組織では、パスワードを変える前に送信処理が何で認証しているかを確認してください。
未払いやアカウント停止でログインできない場合の支払い状況と復旧可否
請求の未払いも原因になります。同ドキュメントによると、月末の最終週に未払い残高があるとアカウントが凍結され、事前に警告メールが複数回送られます。支払いを済ませれば戻せますが、恒久的に停止されたアカウントは復元できません。
Freeプランを使い続けていたアカウントは、この経路で止まっている可能性があります。無償枠の終了日程と現行プランの月額はSendGrid料金の実額とFreeプラン終了後の選択肢に整理しました。
共有ログインをやめてTeammatesとSAML SSOへ切り替える設定作業
1つのアカウントを複数人で使い回している状態は、2FA端末の紛失とパスワード変更事故の両方の温床になります。人ごとにログインを分けるのが先決です。
Admin・Read-only・Restrictedの3権限と招待期限7日の運用
Teammatesのドキュメントでは、権限はAdmin、Read-only Access、Restricted Accessの3段階です。Read-onlyは設定を見られるが変更できず、Restrictedは機能ごとに個別で許可を与えます。作れる人数はEssentialsで1名、Pro・Premierで最大1,000名です。
招待メールの有効期限は7日で、過ぎたら再送します。Teammateを削除すると復元はできませんが、その人が作ったテンプレートやAPIキーは消えません。退職者を削除したあとも、その人が発行したAPIキーは生き続けます。削除と同時にAPIキーの一覧を確認する手順を、退職処理のチェックリストに入れておきます。
Pro以上で使えるSAML SSOのIdP設定項目と2FAの移管手順
SendGrid Single Sign-Onの対象はAPI Pro、Premier、Marketing Campaigns Advancedの各プランで、SAML 2.0でOktaやMicrosoft Entra ID（旧Azure Active Directory）などのIdPとつなぎます。設定画面で扱う項目は次のとおりです。
- SendGrid側でSSOを追加し、Single Sign-On URLとAudience URL（SP Entity ID）を控える
- IdPにSendGridアプリを登録し、1で控えた2つのURLを入力する
- IdPが発行するSAML Issuer ID、Embed Link、X509証明書をSendGrid側へ貼り付ける
- SSO Teammateを作成するか、JITプロビジョニングを有効にしてIdPからユーザーを割り当てる
SSO Teammateの2FAはSendGrid側ではなくIdP側で管理します。JITプロビジョニングはIdP起点のサインオンでしか動かず、親アカウント限定です。1人のTeammateはパスワード型かSSO型のどちらか一方にしかなれず、作成後にメールアドレスも変えられません。既存のパスワード型Teammateを移すときは、SSO型を新規に作ってから旧Teammateを削除する順になります。SSOの方式全体はシングルサインオン（SSO）の実現方式とIdP選定で解説しています。
管理画面に頼らない運用へ移すAPIキー認証とcurlでの確認手順
ログインの問題を根本から減らすには、システムからの送信を人のアカウントから切り離します。作業は3つで、Basic認証の撤去、APIキー権限の確認、ログインできる人の棚卸しです。
2FA有効化後にBasic認証のAPI呼び出しが拒否される仕様への対応
Two-factor authenticationのドキュメントには、ユーザーが2FAを有効にするとTwilio SendGridはAPI呼び出しでのBasic認証（ユーザー名とパスワード）を受け付けなくなると書かれています。古いSDKや自作スクリプトでapi_userとapi_keyを渡している箇所は、2FAを有効にした時点で認証エラーになります。
移行先はAPIキーによるBearer認証です。キーは用途ごとに分け、送信だけのプログラムにはMail Sendの権限だけを与えます。発行から失効までの管理手順はAPIキー管理の発行・保管・失効とローテーションにまとめています。
scopesエンドポイントでAPIキーの権限を確かめるcurlの例
手元のキーに何の権限が付いているかは、Retrieve a list of scopesのAPIで確認できます。管理画面にログインしなくても実行できるため、2FA端末を持つ担当者が不在のときの確認手段にもなります。
# 環境変数にAPIキーを入れておく（コマンド履歴に残さない）
export SENDGRID_API_KEY="SG.xxxxxxxx"
# 権限一覧を取得し、mail.send を含むかだけを確かめる
curl -s -X GET "https://api.sendgrid.com/v3/scopes" \
--header "Authorization: Bearer $SENDGRID_API_KEY" \
| jq -r '.scopes[]' | grep -x "mail.send"レスポンスは{"scopes": ["mail.send", ...]}の形です。送信用のキーからteammates.readやapi_keys.createのような管理系の権限が出てきたら、権限を絞った新しいキーに差し替えます。EUリージョンのアカウントではapi.eu.sendgrid.comを使います。
teammatesエンドポイントでログインできる人を棚卸しするPython
誰が管理画面に入れるかは、Retrieve all teammatesのAPIで一覧化できます。limitの既定値と最大値は500で、offsetでページを送ります。
import os
import requests
API = "https://api.sendgrid.com/v3/teammates"
HEADERS = {"Authorization": f"Bearer {os.environ['SENDGRID_API_KEY']}"}
def list_teammates():
offset = 0
while True:
r = requests.get(API, headers=HEADERS,
params={"limit": 500, "offset": offset}, timeout=10)
r.raise_for_status()
body = r.json()
# スキーマ表記は result、公式の例示は results のため両方を受ける
rows = body.get("result") or body.get("results") or []
if not rows:
return
yield from rows
offset += len(rows)
for t in list_teammates():
print(t["username"], t["email"], t["user_type"], "admin" if t["is_admin"] else "-")このキーにはteammates.readの権限が必要です。送信用とは別の棚卸し専用キーを発行し、実行後は失効させます。user_typeがownerの行はアカウント所有者で、Teammateの削除では消せません。出力を人事の在籍名簿と突き合わせ、退職者やadminが多すぎる状態を見つけます。
SMTP連携のユーザー名をapikeyへ差し替える設定ファイルの例
SMTPで送っているシステムも同じ考え方で移せます。Integrating with the SMTP APIでは、ユーザー名に文字列のapikey、パスワードにAPIキーそのものを入れると定めています。
# Postfix の relayhost 設定例（/etc/postfix/main.cf）
relayhost = [smtp.sendgrid.net]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt
# /etc/postfix/sasl_passwd（作成後に postmap を実行し、権限は600にする）
[smtp.sendgrid.net]:587 apikey:SG.xxxxxxxxユーザー名のapikeyはキーの値ではなく、この7文字そのものです。キーにはMail Send以上の権限が要ります。ホストはIPアドレスではなくsmtp.sendgrid.netで指定します。公式ドキュメントが、SendGridのIPアドレスは予告なく変わることがあると注意しているためです。
SendGridのログイン管理を自社で抱えない判断と外部に任せる条件
ここまでの作業は、担当者1人でも半日あれば終わる量です。問題は、それを続けられる体制かどうかにあります。
1アカウント共有を続けてはいけない組織の条件と退職時の失敗パターン
次のどれかに当てはまるなら、共有ログインはすぐにやめます。送信プログラムがアカウントのパスワードで認証している。2FAの端末が特定の担当者の私物である。退職者の発行したAPIキーを誰も把握していない。この3つが重なった組織では、担当者の退職と同時に、ログインも鍵の失効もできない状態に陥ります。
逆に、送信がAPIキーに移っていて、Teammateが2名以下、SSOを入れるほどの人数もいないなら、Pro以上へ上げてSSOを導入する必要はありません。Essentialsの1名枠と、TOTPシードの社内保管で足ります。費用をかけるのは、人数が増えて退職処理が月に何度も発生する段階からで十分です。
送信基盤ごと見直すべき場面と複数システムの料金・連携設計の相談先
ログインの整理を始めると、複数システムがそれぞれ別のキーやSMTP設定で送っている実態が見えてくることがあります。送信の結果をシステムに取り込めていないなら、SendGrid API Event Webhookの実装手順で受信側の設計から揃えるのが近道です。
送信元がばらばらで、どのキーを止めると何が止まるか誰も答えられない状態なら、送信を1つのAPI層に集約する改修を検討します。既存システムの送信処理の棚卸しや、認証方式を揃える連携基盤の設計を外部に相談する場合は、API開発・システム連携のページで対応範囲を紹介しています。
よくある質問
SendGridのログインまわりで、問い合わせの多い論点を5つ取り上げます。
SendGridにメールアドレスでログインできないのはなぜですか？
構造計画研究所版のダッシュボードを使っている可能性が高いです。国内版のダッシュボードはサブユーザ名またはTeammate名でログインする仕組みで、メールアドレスは受け付けません。マイページIDでも入れないため、契約者は先にマイページでTeammateを作成し、その名前でログインします。Twilio直販のアカウントなら、Twilio Loginにリンク済みかどうかで使う資格情報が変わります。
二要素認証を無効にしてログインすることはできますか？
できません。直販のSendGridは2FAが必須で、国内版もダッシュボードは初回ログイン時に設定を求められ、マイページも2026年3月から必須化されています。端末を失った場合は、直販ならTwilio SendGridサポート、国内版のマイページなら契約者本人のフォーム申請で解除を依頼します。解除を待つ時間を避けるなら、TOTPのシードを社内で共有保管する運用が現実的です。
TwilioアカウントとSendGridアカウントのリンクは解除できますか？
Twilio Login Overviewには、リンクすると従来のSendGridのログイン資格情報が無効になることは書かれていますが、リンクを元に戻す手順は記載されていません。1つのSendGridアカウントにリンクできるTwilioアカウントは1つだけなので、個人のメールアドレスで作ったTwilioアカウントと会社のSendGridをつなぐ前に、どのアドレスで管理するかを決めておきます。
APIキーを発行するには管理画面へのログインが必要ですか？
最初の1本は管理画面のSettingsのAPI Keysから発行します。以降はapi_keys.createの権限を持つキーを使えばAPIで発行と失効ができるため、ログインせずにローテーションを回す構成も組めます。ただし、そのキーはアカウント全体を操作できる強い鍵になるので、送信用のキーとは必ず分け、保管場所と利用者を限定してください。
退職者のTeammateを削除すると送信が止まることはありますか？
Teammatesのドキュメントによると、削除したTeammateが作成したAPIキーやテンプレートは削除されません。そのため削除しただけで送信が止まることはありません。裏を返せば、退職者が作ったキーは手作業で失効させない限り有効なままです。削除の前に、その人が発行したキーを使っているシステムを特定し、新しいキーへ差し替えてから旧キーを失効させる順で進めます。
関連記事
- SendGrid料金の実額と落とし穴：円建てプランとドル建て直販の月額、Freeプラン終了後の代替比較
- SendGrid API Event Webhookの実装手順：署名検証と再送に耐える受信側の設計
- 多要素認証（MFA）とは：3要素の考え方と耐フィッシングMFAの実装方式
- API認証の設計：方式選定マトリクスとトークン寿命・監査ログの決め方
- メール配信システムとは：仕組みとメルマガ配信ツールとの違い、導入判断の基準
