Bubble.ioでMicrosoftアカウント（Microsoft Entra ID）ログインを実装しようとすると、認証の途中で「Text too long for this field」が表示されて先に進めないことがあります。本記事では原因の切り分けと、Bubble側の制限を回避して安定させる実装ポイントをまとめます。
よくある症状：「ログインできそうなのに最後で落ちる」
このエラーは、Microsoftのサインイン画面までは進み、資格情報の入力や多要素認証（MFA）も完了したのに、Bubbleアプリに戻ってきた瞬間にエラー表示になって止まる、という形で現れることが多いです。
- Microsoftのログイン画面→同意（consent）までは正常
- リダイレクトでBubble側に戻る
- トークン取得の直前／直後で「Text too long for this field」
- Azure（Entra ID）の設定を変えても改善しない
見た目は「OAuthの設定ミス」に見えるのですが、実務ではAzure側の登録が正しくても発生します。
結論：Azure（Entra ID）ではなくBubble側の保存制限に当たっている可能性が高い
「Text too long for this field」は直訳すると「このフィールドには長すぎるテキストです」。つまり、どこかに長い文字列を書き込もうとして失敗しています。Microsoft（Entra ID）のOAuth 2.0／OpenID Connect連携で長い文字列といえば、最有力はトークン（多くはJWT）です。
BubbleのOAuth連携（特にOAuth 2.0 User-Agent Flow系の実装）では、ログイン後に返ってくるアクセストークンやIDトークンをBubble側で保持します。ところが、その保持先が「短いテキストフィールド相当」の上限（目安として約2,000文字前後）になっているケースがあり、返ってきたトークンが長いと保存できずエラーになります。
| 観点 | Azure（Entra ID）起因の典型 | Bubble側の保存制限起因の典型 |
|---|---|---|
| ログイン画面 | そもそも表示されない／即エラー | 表示され、認証も完了する |
| 落ちるタイミング | リダイレクト前（認可要求の段階） | リダイレクト後（トークン取得・保存の段階） |
| エラーメッセージ | invalid_client / redirect_uri_mismatch 等 | Text too long for this field 等の保存系 |
| 設定変更の効き方 | 登録内容に応じて挙動が変わりやすい | Azure側を直しても変わらないことが多い |
重要なのは、Bubble側でこの上限を引き上げる手段が基本的にないことです。だからこそ、Bubbleフォーラム等で共有されている回避策（ワークアラウンド）を前提に、設計を「制限に当たらない形」へ寄せるのが近道になります。
なぜMicrosoft（Entra ID）のトークンは長くなりやすいのか
Microsoft Entra IDが発行するトークンは、多くの場合JWT（JSON Web Token）です。JWTは「ヘッダー」「ペイロード」「署名」をドットで連結した形式で、各パートがBase64URLでエンコードされています。つまり、中身（クレーム）が増えるほどトークン自体が長くなる構造です。
| 増えやすい要素 | 具体例 | トークンが長くなる理由 |
|---|---|---|
| グループ情報 | groupsクレーム、グループ数が多いユーザー | GUIDの配列が膨らむ |
| アプリロール | rolesクレーム | ロール名が入る |
| 追加クレーム | Optional claims（email、upn、tenant情報等） | ペイロードのキー・値が増える |
| スコープ・同意範囲 | Graphの広いスコープ、複数リソース | 発行ポリシーによりクレームが増えることがある |
このため「一部のユーザーだけ再現する」ケースもあります。たとえば、テストユーザーでは通るのに、本番の社員アカウントでは失敗する場合、本番ユーザーの所属グループやロールが多く、トークンが長くなっている可能性が高いです。
OAuthフローの選び方で安定性が変わる
BubbleでMicrosoft（Entra ID）ログインを組み込むとき、同じ「OAuth 2.0」でもフローの選び方で、トークンの扱い・保存場所・失敗しやすさが変わります。特に「User-Agent Flow（ブラウザ中心）」に寄せると、プラットフォーム側の保存仕様に引っ張られやすくなります。
| 項目 | User-Agent Flow系（フロント中心） | Authorization Code Flow系（バックエンド中心） |
|---|---|---|
| トークンの扱い | ブラウザ側で受け取り、Bubbleの内蔵機構で保持されがち | バックエンドでトークン交換し、保存設計を自分で決められる |
| 長いトークンへの耐性 | 保存先の上限に当たると詰まる | 保存先を工夫できるため回避しやすい |
| セキュリティ設計 | クライアント側に寄るほど取り扱いが難しい | 秘密情報（client secret等）をサーバー側に置ける |
| Bubbleでの実装難易度 | 簡単に始められるが、制限に当たると打つ手が少ない | 最初は手間だが、運用まで見据えると安定しやすい |
切り分けの基本：どの段階で落ちているかを3つに分解する
OAuth 2.0ログイン連携は、ざっくり次の3段階に分けると原因が見えやすくなります。
| 段階 | 何が起きているか | 失敗時に出やすいサイン | 次に見るポイント |
|---|---|---|---|
| 認可（Authorize） | ユーザーがMicrosoftでログイン・同意 | redirect_uri_mismatch、invalid_client | リダイレクトURI、Client ID、テナント |
| トークン取得（Token） | コード／トークンを受け取り、アクセストークン等を得る | invalid_grant、AADSTS系エラー | スコープ、Client Secret、コードの有効期限 |
| 保存・セッション化 | 取得したトークンを保持し、以後のAPI呼び出しに使える状態にする | Text too long for this field | 保存先の制限、保持の設計 |
今回の「Text too long for this field」は、3段階目（保存・セッション化）で起きる代表例です。言い換えると、認可やトークン取得そのものは成功しているのに、Bubbleが保持できずに落ちている状態です。
最初にやるべき確認：トークンが返っているか、どれだけ長いかを可視化する
原因の当たりを付けるには、まず「トークンが返っているか」「返っているなら長さはどの程度か」を確認します。開発者ツールを使えば、Azure側の成否とBubble側の問題を切り分けやすくなります。
ブラウザの開発者ツールで確認する手順
- Chrome/Edgeの開発者ツールを開き、Networkタブを表示します。
- ログイン操作を最初からやり直し、login.microsoftonline.com や /token を含む通信を探します。
- トークンエンドポイントのレスポンスに access_token や id_token が含まれていれば、Azure側は「発行」まで到達しています。
- トークンをコピーし、長さをざっくり把握します（セキュリティ上、共有はしない）。
簡単に長さを確認するだけなら、開発者ツールのコンソールで次のように見られます。
// 例：トークン文字列を token 変数に入れた場合
token.length
「長いトークン＝即Azure側の不具合」ではありません。多くの場合、Azureは仕様通りにJWTを返しており、受け取った側（Bubble）の保持設計が追いついていないのが本質です。
対処の考え方：Bubbleの「内蔵保存」に依存しない設計へ寄せる
Bubble側の制限が疑われるときの基本方針は次の2つです。
- 方針A：トークンをBubble内蔵の保存機構に任せず、別の場所（自分のDB項目／外部サービス）に保管する
- 方針B：どうしてもBubble内で完結させたい場合は、Azure側でトークンが肥大化しないようにクレームを減らす
Bubbleフォーラムで共有される回避策は、実装の表現は違っても、最終的にはこのどちらか（または併用）に収束します。
ワークアラウンドA：認可コードフローを「バックエンドで」完結させる
Bubbleのフロント（ブラウザ）でOAuthを完結させると、トークンの扱いがプラットフォーム依存になりがちです。そこで、リダイレクトで受け取ったコードをバックエンドでトークン交換し、保存もバックエンド主導にする構成にすると安定します。
| 手順 | Bubble側でやること | ポイント |
|---|---|---|
| 認可URLを作る | ログインボタンでMicrosoftのAuthorize URLへ遷移 | stateを付与してCSRF対策。必要ならテナント固定 |
| コールバックを受ける | BubbleのBackend workflows（API endpoint）で code を受け取る | redirect URIはこのエンドポイントに合わせる |
| トークン交換 | API Connectorを「サーバー側（Use as: Action）」で呼び出し、/token にPOST | client_secretを使える構成（Webアプリ）なら実装が簡単 |
| 保管と更新 | トークンをユーザー紐づけで保存し、期限前にrefreshする | 保存先はプライバシールールで厳格に制御 |
Authorize URLとTokenリクエストの例（Entra ID v2.0）
実装イメージを掴むために、一般的なパラメータ例を載せます。実際の値は環境に合わせて置き換えてください。
Authorize（認可）の例：
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize
?client_id={client_id}
&response_type=code
&redirect_uri={redirect_uri}
&response_mode=query
&scope=openid%20profile%20email%20offline_access%20User.Read
&state={random_state}
Token（トークン交換）の例（application/x-www-form-urlencoded）：
POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
client_id={client_id}
&scope=openid profile email offline_access User.Read
&code={authorization_code}
&redirect_uri={redirect_uri}
&grant_type=authorization_code
&client_secret={client_secret} Bubbleで組む場合、TokenのPOSTはAPI Connectorでアクション化し、Backend workflowから呼び出すと「クライアント側に秘密情報を置かない」形になりやすいです。
この構成のメリットは、Bubbleの「OAuth設定画面の制約」を避けられる点です。トークンが長くても、保存先を自分で設計できるため、エラーの土台を取り除けます。
ワークアラウンドB：トークン保管を外部に委ね、Bubbleは短いキーだけ扱う
セキュリティと運用を重視するなら、トークンをBubbleのDBにそのまま置かず、外部の安全な保管場所に寄せるのも現実的です。代表的には次のような形が考えられます。
- 自前のAPI（Azure Functions / Cloudflare Workers など）でOAuthとトークン保管を担当し、Bubbleには短いセッションキーだけ返す
- OAuth連携の中継サービスを利用し、トークン管理をサービス側に寄せる
Bubbleが保持するのは短い識別子だけなので、「長いトークンを保存しようとして落ちる」問題を根本から回避できます。
ワークアラウンドC：Azure側の発行内容をスリム化してトークンを短くする
外部保管が難しい場合は、Azure（Entra ID）側の設定でトークン肥大化の原因を減らすことで、Bubbleの制限に当たりにくくできます。ここは「Azureが悪い」という話ではなく、Bubble側の制約に合わせて発行内容を調整するという割り切りです。
- グループクレームを付けない：必要なときはGraph APIで都度取得する（/me/memberOf など）
- Optional claimsを増やしすぎない：本当に必要な項目だけに絞る
- スコープを最小化：まずはユーザー識別に必要な範囲だけで動作確認し、段階的に増やす
- アプリロールの設計を整理：ロール名が長い／数が多い場合は見直す
「トークンを短くする」方向は、再現条件がユーザー属性に依存するケース（特定ユーザーだけ失敗）に特に効きます。
IDトークンとアクセストークンの混同を防ぐ
Microsoft（Entra ID）連携でよくある落とし穴が、「何のためのトークンか」を曖昧にしたまま実装してしまうことです。Bubble側の保存制限に当たるときも、どのトークンを保持しているかで対処が変わることがあります。
| 種類 | 用途 | Bubble実装での扱い方の例 |
|---|---|---|
| IDトークン | ログインしたユーザーが誰かを表す（OpenID Connect） | ユーザー識別だけなら、必要情報を取り出して自前ユーザーに紐づける |
| アクセストークン | Microsoft Graph等のAPIを呼ぶ権限を表す | API呼び出し時だけヘッダーに付与。保存・更新の設計が重要 |
| リフレッシュトークン | アクセストークン更新用 | 運用上必要なら保持。ただし取り扱いは最も慎重に |
「ログインができればよい」のか、「Graph APIを継続的に呼びたい」のかで、必要なトークンが違います。要件に対して過剰にトークンを抱えると、保存や運用が難しくなります。
Bubble側の実装で失敗しやすいポイント
同じMicrosoft（Entra ID）OAuth連携でも、Bubbleの実装次第でハマりどころが変わります。次のチェックリストを潰すと、調査が一気に進みます。
| チェック項目 | ありがちなミス | 改善の方向性 |
|---|---|---|
| リダイレクトURI | Bubble側のURL末尾スラッシュ違い、環境（dev/prod）混在 | Azure側に完全一致で登録。環境ごとに分ける |
| エンドポイントの選択 | v1とv2が混在し、パラメータ（resource/scope）が噛み合わない | 基本はv2で統一し、scopeで設計する |
| スコープ設計 | 最初から大きく取りすぎて、動作確認が難しくなる | 最小スコープ→段階的に増やす |
| 保存設計 | Bubble内蔵のOAuth保存に依存し、トークン肥大化で落ちる | バックエンドで交換・保存する、または外部保管に寄せる |
| プライバシールール | トークンをUserに保存したが閲覧権限が緩い | トークン関連フィールドは原則サーバー専用にする |
再現しないテストユーザーで「成功」と判断しない
この問題は、テストユーザーでは発生せず、本番ユーザーで突然発生することがあります。理由はシンプルで、ユーザーごとにトークンの中身（クレーム）が違うからです。
- テストユーザー：所属グループが少ない、ロールが少ない、クレームが少ない → トークンが短め
- 本番ユーザー：所属グループが多い、ロールが多い、追加クレームが多い → トークンが長くなりやすい
そのため、検証では「権限が強いユーザー」「グループが多いユーザー」でも試し、失敗するなら早めに回避策へ舵を切るのが安全です。
どうしても解決しない場合に、サポートへ渡すと調査が早い情報
回避策を試しても改善しない場合は、Azure側・Bubble側のどちらにボトルネックがあるかを、より具体的に調査する必要があります。その際、次の情報が揃っているとやり取りがスムーズです（秘密情報は共有しない）。
- Azure（Entra ID）のテナント種別（シングル／マルチ）と、アプリ登録のClient ID（Application ID）
- 設定しているリダイレクトURIの一覧（開発／本番）
- 認可要求（Authorize）のURL例（client_secretやトークンは含めない）
- tokenエンドポイントが返している項目（access_token / id_token / refresh_token の有無）
- 発生するユーザーの特徴（グループ数が多い、特定のロールを持つ等）
- Bubble側で利用している方式（API ConnectorのOAuth、プラグイン、独自実装）
- エラー発生のタイムスタンプと、ブラウザ種別（Chrome/Edge）
特に「トークンは返ってきているのに、Bubbleが保持できずに失敗している」状況を示せると、原因特定が一気に進みます。
まとめ：トークン取得の前後で落ちるなら、まずBubble側の保存制限を疑う
Microsoft（Entra ID）のOAuth 2.0ログイン連携で「Text too long for this field」が出るとき、最初に疑うべきはAzureの設定ミスではなく、Bubble側が長いトークン（JWT）を保存しきれない設計になっていることです。Bubble側で上限を引き上げられない以上、トークンの扱いを変える（バックエンドで交換・保存する／外部に保管する）か、発行内容をスリム化して短くする方向で対処すると、再現性の高い解決につながります。
コメント