SendGridログインの手順と入れない時の対処｜Twilio Login・2FA・APIキー権限

SendGridのログインで迷うのは、入口が契約経路によって分かれているためです。Twilioから直接契約したアカウントはTwilio Loginという共通ログインに移っており、構造計画研究所が提供する国内版はマイページとダッシュボードで使うIDが別です。この記事では、契約経路の見分け方、Twilio本体のConsoleへのログイン、入れないときに確かめる順番、二要素認証の端末をなくした場合の解除依頼を順に整理します。後半は、共有アカウントをTeammatesやSSOへ切り替える設定と、送信プログラムをAPIキーへ移す手順です。APIキーの権限の選び方と、curl・Pythonによる棚卸しもここで扱います。

まとめ｜SendGridログインで最初に確かめる契約経路と認証方式

最初に確かめるのは契約経路です。ドル建てでカード請求されているならTwilio直販で、ログインはTwilio Loginのメールアドレスとパスワードです。円建ての請求書が届くなら構造計画研究所版で、契約者はマイページID、送信設定はサブユーザ名またはTeammate名でダッシュボードに入ります。メールアドレスで弾かれたら、まず契約経路と入力するIDの種類を見直します。

次に二要素認証の桁数です。Twilio Loginへ移っていない直販と国内版ダッシュボードは7桁、国内版マイページとTwilio Consoleは6桁で、Twilio Login利用者はTwilio側の設定に従います。端末を失ったときの戻し方も入口ごとに違います。Twilio Consoleはリカバリーコード、旧認証の直販はSendGridサポートへのチケット、国内版マイページはフォームでの解除申請、国内版ダッシュボードはAuthyへの復旧依頼です。

最後に、人のログインとシステムからの送信を切り離します。2FAを有効にしたユーザーの資格情報では、Basic認証のAPI呼び出しが受け付けられません。送信プログラムはMail Sendだけを許可したAPIキーで認証し、人のログインは個別のTeammateかSSOにする。送信がAPIキーだけで認証していれば、人のパスワード変更や2FAの設定変更が送信に響くことはありません。

SendGridのログイン画面が2系統ある理由と直販・国内版の入口

同じSendGridでも、契約の窓口が違えばログインの仕組みが別物になります。ここを取り違えたまま操作すると、正しいパスワードでも入れません。

Twilio直販アカウントのTwilio Loginへの移行と入口

Twilio Login for SendGrid（2026年10月6日更新）は、SendGridの新規登録とTeammateの招待はすべてTwilio Loginを使うと明記しています。Twilio LoginはTwilio Console、Segment、SendGridで同じメールアドレス、パスワード、認証設定を使う仕組みです。login.sendgrid.comを開いてTwilio Loginの画面へ転送されれば、そのアカウントはTwilio Login利用者です。

2024年半ばより前に登録したアカウントは、旧来のSendGridユーザー名で入る状態が残っていることがあります。ログイン後に表示される案内からTwilioのユーザーとリンクすると、従来のSendGridの資格情報は無効になります。1つのSendGridアカウントにリンクできるTwilioアカウントは1つだけで、リンク後は同じメールアドレスで別のSendGridアカウントを作れません。メールアドレスを変えたいなら、リンクの前に変えます。旧パスワードで急に入れなくなったときは、誰かがリンクを済ませていないかを先に確かめてください。

Twilio Loginで入ると、複数のSendGridアカウントに招待されている人にはアカウント選択画面が出ます。既定の表示名はすべて「My SendGrid account」なので、管理者はTeammatesのドキュメントにあるとおりアカウント設定で名前を変えておくと、本番と検証の取り違えを防げます。

構造計画研究所版のマイページとダッシュボードのIDの違い

国内版は、契約や請求を扱うマイページと、送信設定や統計を扱うダッシュボードに分かれています。親アカウントのログイン手順では、親アカウントはマイページIDでマイページに入り、トップの「SendGridダッシュボードへ」からダッシュボードへ移ります。

サブユーザとTeammateは、サブユーザやTeammateでログインするの手順どおりダッシュボードへ直接入ります。ユーザ名欄にはサブユーザ名かTeammate名を入れ、メールアドレスやマイページIDでは入れません。ダッシュボードの2FAは必須で、初回ログイン時に設定を求められます。

2つの画面は2FAも別の仕組みです。マイページは2026年3月25日から2FAが必須になり、確認コードは6桁です。TOTP方式の認証アプリで受け取り、アプリを設定していなければ登録メールアドレスに届きます。SMSでは受け取れません。ダッシュボードは7桁で、AuthyかSMSで受け取ります。

契約経路ごとのログイン先・ID・2FAの対応表

請求通貨と、手元にあるIDの形式を見れば判別できます。

国内版では、1人の担当者がマイページIDとTeammate名の2つを持つ構成が珍しくありません。どちらの2FAを設定した端末なのかも、別々に記録しておきます。

Twilio ConsoleへのログインとProduct SwitcherでSendGridへ移る手順

Twilio Loginに移ったSendGridアカウントは、Twilio本体のログインがそのまま入口になります。SMSや音声のAPIを使っていなくても、ここでつまずくとSendGridにも入れません。

www.twilio.com/loginからSendGridを開く操作

ログイン画面はwww.twilio.com/loginです。メールアドレスとパスワードを入れて送信すると、Twilio Consoleが開きます。新しいConsoleでは左のレールの最下部、旧ConsoleとSendGridの画面では上部の右端にProduct Switcherがあります。ここで「Twilio SendGrid」を選ぶと、SendGridのダッシュボードが別のタブで開きます。

Twilio Login利用者の2FAは、SendGridの設定画面ではなくTwilio側で管理します。Twilio Consoleの操作ガイドでは、新ConsoleのPersonal settingsで2FAの方式変更とリカバリーコードの再発行ができ、旧ConsoleではUser Settingsが同じ役割です。SendGridの2FAドキュメントの手順（Settings→Two-Factor Authentication）は、Twilio Loginへ移っていないユーザー向けです。電話番号の変更をSendGrid側で探しても見つからないのはこのためです。

6桁の確認コードが届かないときのリカバリーコードと管理者リセット

2FA電話番号の変更手順によると、Twilioの2FAは有料アカウントでは必須です。無料トライアルで無効にできるかは公式記事の間で記述が食い違っているので、無効化を前提にしないでください。端末を失ったときにまず使うのは、2FAを最初に設定したときに表示されるリカバリーコードです。

1. ログイン画面でメールアドレスとパスワードを入れ、確認コードの入力画面で「Try another method」から「Recovery code」を選ぶ
2. リカバリーコードを入れて「Continue」を押す
3. 新しいリカバリーコードが表示されるので控え、「I have safely recorded this code」を選んで進む

手順はHow to Sign In to a Twilio Account With 2FA Enabledにあります。リカバリーコードも失った場合は、ヘルプセンターから本人確認の依頼を出します。依頼にはメールアドレスとAccount SIDを必ず書きます。組織のAdminかOwnerなら、管理下のユーザー（Managed User）の2FAをリセットでき、そのユーザーは次のログインで新しい番号を登録します。担当者が退職して2FAの番号が分からなくなったときは、まず組織の管理者に頼めるかを確かめます。有料（従量課金）アカウントの所有者なら、アカウント情報を確認する「Reset MFA」フォームでも2FAをリセットできます。

リカバリーコードは、表示された画面を離れると二度と見られません。User Settingsの「Generate new code」で作り直せますが、そのとき古いコードは無効になります。控えた場所を社内のパスワード管理ツールに決めておきます。

SendGridにログインできない原因と確認する順番

原因の候補は多いものの、確認は次の順で進めると早く片づきます。入口とIDの形式、2FA、パスワード、請求状態の順です。入口とIDは前の2章で確かめられるので、ここでは残りの3つを扱います。

2FAのSMSが届かない・端末を紛失したときの契約経路別の解除依頼

Twilio Loginへ移っていない直販アカウントについては、Twilioのヘルプ記事Unable to login to Twilio SendGrid Direct Account due to 2FAが確認項目を挙げています。VoIPや固定電話の番号には送れません。「おやすみモード」や番号ブロックが有効になっていないか、他のサービスからのSMSは届くかを先に確かめます。「Sorry, we were unable to send SMS at this Time」と出る場合は、番号の許可登録をサポートに依頼します。

2FAの番号が分からない、または番号の持ち主が退職している場合は、Twilio SendGridサポートへチケットを出します。ログイン画面の「Trouble Logging In」から入れます。チケットには、コードが届かないユーザー名、分かれば2FAの番号、有効なAPIキーで今も送信できているか、登録電話番号に連絡がつくかを書きます。Authyを使ったことがない場合は「Two-factor Authentication code not received」ではなく「I am having a different login issue」を選ぶよう案内されています。

国内版のマイページは、二要素認証アプリの設定によると、端末を紛失したら契約者本人または同一企業に属する人がフォームから解除を依頼します。フォームにはマイページID・メールアドレス・氏名を入れます。解除後は確認コードが登録メールアドレスに届くようになり、2FAそのものを無効にはできません。国内版のダッシュボードは別扱いで、ダッシュボードの二要素認証の説明では、端末を紛失・破損したらAuthyに復旧を依頼します。なお、親アカウントがマイページからダッシュボードへ移るときは、ダッシュボード側の2FAは求められません。

サポートやAuthyへの依頼は、本人確認と返信待ちで時間がかかることがあります。2FAの端末を担当者の私物1台に寄せないことが先決です。TOTPアプリで受け取る方式ならシードを、Twilio Consoleならリカバリーコードを社内のパスワード管理ツールに保管し、端末をなくしても自分たちで戻せるかを事前に試しておきます。

パスワード変更で本番のAPI連携が止まる事故とユーザー名忘れ

Troubleshooting account login issuesは、パスワードを変えると本番環境のAPIやSMTPの連携が壊れることがあると警告しています。アカウントのユーザー名とパスワードを送信プログラムに埋め込んでいる古い構成では、ログインのためにパスワードを変えた瞬間に送信が止まります。共有アカウントがある組織では、パスワードを変える前に送信処理が何で認証しているかを確かめてください。

同じドキュメントは、認証情報を共有している相手が変更した可能性も挙げています。ユーザー名を忘れた場合は、サポートの専用フォームから問い合わせます。登録直後なら、確認メールのリンクを押していないとアカウント自体が作られていません。

未払いやアカウント停止でログインできない場合の復旧可否

同ドキュメントによると、前月分の請求が未払いのアカウントは月末の最終週に停止され、ログインも送信もできなくなります。それまでに警告メールが複数回届くので、請求先のメールボックスを確かめます。一方、禁止（banned）されたアカウントは恒久的に解約され、サポートでも再開できません。サブユーザーも一緒に止まります。

無償枠から有償プランへの移行を見送ったアカウントが止まっていることもあります。無償枠の終了日程と現行プランの月額はSendGrid料金の実額とFreeプラン終了後の選択肢に整理しました。

共有ログインをやめてTeammatesとSAML SSOへ切り替える設定作業

1つのアカウントを複数人で使い回している状態は、2FA端末の紛失とパスワード変更事故の両方の温床になります。人ごとにログインを分けるのが先です。

Admin・Read-only・Restrictedの3権限と招待期限7日の運用

Teammatesのドキュメントでは、権限はAdmin、Read-only Access、Restricted Accessの3段階です。Read-onlyは設定を見られるが変えられず、Restrictedは機能ごとに許可を与えます。Developer Access、Marketer Access、Accountant Accessというプリセットもあります。作れる人数はFreeとEssentialsで1名、Pro以上で最大1,000名です。

招待の有効期限は7日で、過ぎたら再送します。Teammateを削除すると復元できませんが、その人が作ったテンプレートやAPIキーは消えません。退職者を削除したあとも、その人が発行したAPIキーは生き続けます。削除と同時にAPIキーの一覧を確かめる手順を、退職処理のチェックリストに入れておきます。

Pro以上で使えるSAML SSOのIdP設定項目とTeammateの移し方

SendGrid Single Sign-Onの対象はEmail API Pro、Premier、Marketing Campaigns Advancedの各プランです。SAML 2.0でOktaやMicrosoft Entra IDなどのIdPとつなぎ、設定は次の順に進めます。

1. SendGrid側でSSOを追加し、Single Sign-On URLとAudience URL（SP Entity ID）を控える
2. IdPにSendGridアプリを登録し、1で控えた2つのURLを入力する
3. IdPが発行するSAML Issuer ID、Embed Link、X509証明書をSendGrid側へ貼り付ける
4. SSO Teammateを作成するか、JITプロビジョニングを有効にしてIdPからユーザーを割り当てる

SSO Teammateの2FAはSendGrid側ではなくIdP側で管理します。JITプロビジョニングで作られるユーザーは読み取り専用の権限から始まります。1人のTeammateはパスワード型かSSO型のどちらか一方にしかなれません。既存のパスワード型を移すときは、別の管理者のアクセスを確保したうえで、旧Teammateを削除し、SSO Teammateとして追加し直します。SSOの方式全体はシングルサインオン（SSO）の実現方式とIdP選定で解説しています。

送信プログラムをAPIキー認証へ移す手順とcurl・Pythonでの確認

ログインの問題を根本から減らすには、システムからの送信を人のアカウントから切り離します。作業はBasic認証の撤去、権限を絞ったAPIキーの発行、権限とログインできる人の棚卸しの順です。

2FA有効化後にBasic認証のAPI呼び出しが拒否される仕様

SendGridの2FAドキュメントは、ユーザーが2FAを有効にするとAPI呼び出しでのBasic認証（ユーザー名とパスワード）を受け付けなくなると注意しています。古いSDKや自作スクリプトでapi_userとapi_keyを渡している箇所は、2FAを有効にした時点で認証エラーになります。移行先はAPIキーによるBearer認証です。

APIキーの作成手順と送信用キーに付ける権限

API Keysのドキュメントの手順は、Settings→API Keys→「Create API Key」で名前を付け、権限を選んで「Create & View」を押すだけです。選べる権限は次の4種類です。

送信だけのプログラムには、Custom AccessでMail Sendだけを許可したキーを渡します。Full Accessのキーが漏れると、Teammateの追加やAPIキーの新規発行までできてしまいます。IDCFの導入ガイドのようにFull Accessで作る手順を載せた解説もありますが、本番では避けてください。請求系のAPIを呼ぶには、別のキーが要ります。

同じドキュメントには、運用で効く制約が並んでいます。キーは作成時に一度しか表示されず、Twilioでも再表示や復元はできません。1アカウントで作れるキーは100本までで、自分の権限より強い権限は付けられません。発行から失効までの手順はAPIキー管理の発行・保管・失効とローテーションにまとめています。

scopesエンドポイントでAPIキーの権限を確かめるcurl

手元のキーに何の権限が付いているかは、Retrieve a list of scopesのAPIで確かめられます。管理画面にログインせずに実行できるので、2FA端末を持つ担当者が不在のときも使えます。

# Bashで対話入力する。キーの値をコマンド履歴や画面に出さない
read -r -s -p 'SendGrid API key: ' SENDGRID_API_KEY
printf '\n'
export SENDGRID_API_KEY

# パイプ途中の失敗も終了ステータスに反映する
set -o pipefail
# 権限一覧を取得する。-f で401などのHTTPエラーを失敗として扱う
curl -sSf "https://api.sendgrid.com/v3/scopes" \
  --header "Authorization: Bearer $SENDGRID_API_KEY" \
  | jq -r '.scopes[]' | sort

レスポンスは{"scopes": ["mail.send", ...]}の形です。送信用のキーからteammates.readやapi_keys.createのような管理系の権限が出てきたら、権限を絞った新しいキーに差し替えます。無効なキーでは401が返ります。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", body.get("results"))
        if not isinstance(rows, list):
            raise ValueError("Unexpected teammates response schema")
        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はキーの値ではなく、この6文字そのものです。キーにはMail Sendの権限が要ります。ホストはIPアドレスではなくsmtp.sendgrid.netで指定します。SendGridのIPアドレスは予告なく変わることがあると、公式ドキュメントが注意しているためです。

SendGridのログイン管理を自社で抱えない判断と外部に任せる条件

必要な工数は、連携しているシステムの数、IdPの設定権限、APIキーの配布先、本番切り替えの確認範囲で変わります。問題は、一度整えた状態を続けられる体制かどうかにあります。

1アカウント共有を続けてはいけない組織の条件と退職時の失敗パターン

次のどれかに当てはまるなら、共有ログインはすぐにやめます。送信プログラムがアカウントのパスワードで認証している。2FAの端末が特定の担当者の私物である。退職者の発行したAPIキーを誰も把握していない。これらが重なった組織では、担当者の退職と同時に、ログインもキーの失効もできない状態に陥ります。

逆に、送信がAPIキーに移っていて、管理画面を使うのが所有者と追加のTeammate1名までで、SSOを必須とする社内規程も無いなら、Pro以上へ上げてSSOを入れる必要はありません。Essentialsで所有者とは別にTeammateを1名追加し、それぞれの認証方式に合った復旧手段を用意すれば足ります。費用をかけるのは、人数が増えて退職処理が月に何度も発生する段階からで十分です。

送信基盤ごと見直すべき場面と相談先

ログインの整理を始めると、複数のシステムがそれぞれ別のキーやSMTP設定で送っている実態が見えてくることがあります。送信の結果をシステムに取り込めていないなら、SendGrid API Event Webhookの実装手順で受信側の設計から揃えるのが近道です。

送信元がばらばらで、どのキーを止めると何が止まるか誰も答えられない状態なら、送信を1つのAPI層に集約する改修を検討します。既存システムの送信処理の棚卸しや、認証方式を揃える連携基盤の設計を外部に相談する場合は、API開発・システム連携のページで対応範囲を紹介しています。

よくある質問

SendGridとTwilioのログイン、2FA、アカウント管理に関する質問を取り上げます。

SendGridにメールアドレスでログインできないのはなぜですか？

国内版のダッシュボードはサブユーザ名またはTeammate名でログインする仕組みで、メールアドレスは受け付けません。Twilio直販なら、Twilio Loginへリンク済みかどうかで使う資格情報が変わります。

TwilioとSendGridのログインは同じですか？

Twilio直販のSendGridでTwilio Loginを使っているなら同じです。www.twilio.com/loginで入り、Product Switcherから「Twilio SendGrid」を選びます。国内版のSendGridはTwilioのアカウントとは別で、マイページIDとダッシュボードのIDを使います。

二要素認証を無効にしてログインすることはできますか？

できません。SendGridのダッシュボードは2FAが必須で、国内版のマイページも2026年3月から必須です。Twilio Consoleも有料アカウントでは必須です。端末を失った場合は、Twilio Consoleならリカバリーコード、旧認証のSendGrid直販ならサポートへのチケット、国内版のマイページならフォーム申請、国内版のダッシュボードならAuthyへの依頼で戻します。

TwilioアカウントとSendGridアカウントのリンクは解除できますか？

Twilio Login for SendGridには、リンクすると従来のSendGridの資格情報が無効になることは書かれていますが、リンクを元に戻す手順は書かれていません。1つのSendGridアカウントにリンクできるTwilioアカウントは1つだけなので、個人のメールアドレスで作ったTwilioアカウントと会社のSendGridをつなぐ前に、どのアドレスで管理するかを決めておきます。

退職者のTeammateを削除すると送信が止まることはありますか？

Teammatesのドキュメントによると、削除したTeammateが作成したAPIキーやテンプレートは削除されません。そのため削除しただけで送信が止まることはありません。裏を返せば、退職者が作ったキーは手作業で失効させない限り有効なままです。そのキーを使っているシステムを特定し、新しいキーへ差し替えてから旧キーを失効させる順で進めます。

関連記事

• センドグリッド（SendGrid）とは｜直販と国内版の違いと最初の1通を送る実装手順
• SendGrid料金の実額と落とし穴｜Freeプラン終了後の円建てプランと代替比較
• SendGrid API Event Webhookの実装手順｜署名検証と再送・障害設計
• 多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFAをコード付きで解説
• API認証の設計｜方式選定マトリクスとトークン寿命・監査ログの決め方