◯本稿は，山中理司弁護士（大阪弁護士会所属）が，裁判手続に伴うウェブ会議で使用しているMicrosoft Teamsのアカウントが突然使用不能となり，新しいアカウントを構築して復旧するに至るまでの一連の作業記録を，AIが整理したものである。
◯個人を特定し得るアカウント名及び具体的な係属裁判所の名称は，いずれも伏せて記載している。
第１ はじめに
１ 本稿の趣旨
本稿は，山中理司弁護士が，裁判所とのウェブ会議に用いていたMicrosoft Teamsのアカウントが突然使用不能となり，新しいアカウントを構築して復旧するに至るまでの一連の作業記録を，AIが山中弁護士への聴取結果に基づいて整理したものである。同種のトラブルに直面し得る他の実務家の参考に供する目的で公開する。
なお，本稿はAIが作成したものであり，山中弁護士が単独で文責を負う一般的な見解を示すものではない。
２ 本稿における表記上の留意点
(1) 「旧アカウント」及び「新アカウント」の意味
本稿では，個人を特定し得る具体的なメールアドレス及びアカウント名の記載は差し控え，従来から使用していたアカウントを「旧アカウント」，本件の過程で新たに作成したアカウントを「新アカウント」と表記する。
(2) 係属裁判所の表記について
本稿では，具体的にどの裁判所であるかを特定し得る表記は差し控え，複数の係属裁判所を単に「各裁判所」と表記する。
第２ 発端
１ 認証アプリの移行手続を確認していた際の不具合
2026年7月2日，山中弁護士は，使用端末（タブレット）の買い替えに備え，多要素認証（MFA）に用いているMicrosoft Authenticatorアプリの移行手続を事前に確認していた。
ところが，この確認作業の最中に，旧アカウントの多要素認証（プッシュ通知及び確認コードのいずれも）が反応しなくなり，サインインができなくなるという事態が生じた。端末の買い替え作業そのものが引き金になったのではなく，買い替えに備えた事前確認の過程で生じた不具合であるという点に留意されたい。
２ 管理者アカウントが1つしかなかったという構造的な弱点
このアカウントには，管理者（グローバル管理者）権限を有する者が山中弁護士本人しかおらず，代替の管理者アカウントも，緊急時用（いわゆるbreak-glassアカウント）の予備アカウントも存在しなかった。多要素認証が機能しないということは，そのまま管理者権限そのものに手が届かないということを意味し，復旧の糸口自体が絶たれた状態に陥った。
第３ 状況の切り分け
１ 試した対処とその結果
(1) 別の登録端末での試行
以前に認証アプリを登録していた別の端末（古いタブレット等）からも試行したが，同様に反応がなかった。特定の１台の端末の不具合ではなく，アカウント又はテナント側で認証の配信自体が機能していないことがうかがわれた。
(2) 認証アプリの再インストールによる状況の悪化
トラブルシューティングの過程で，端末側の認証アプリを再インストールした結果，端末側に残っていた登録情報も失われ，「新しい認証方法を登録するにも多要素認証が必要であるが，多要素認証を通すには登録済みの認証方法が必要である」という，出口のない状態に陥った。
２ エラーコードから読み取れたこと
サインイン試行の過程で，性質の異なる２種類のエラーコードが確認された。1つはAADSTS50089（FlowTokenExpired）であり，これは認証手続そのものの時間切れによる無害なもの（改めてやり直せば解消する類のもの）であった。もう1つはAADSTS500121（AuthenticationFailed）であり，こちらは強力な認証（多要素認証）の要求自体が失敗した，より深刻な種類のものであった。
プッシュ通知の送信自体は行われたものの，登録済みのいずれの端末からも応答が返らない場合に生ずるものとみられる。この切り分けにより，単なる一時的な不具合ではなく，認証の配信経路自体に問題があることが裏付けられた。
３ メール受信自体は無事であったことの確認
一方で，旧アカウントに紐づくメールの受信自体は，別の仕組み（メールソフトによる受信）で支障なく継続していることを確認できた。これにより，直ちに実務に重大な支障が生ずるものではないことが分かり，落ち着いて対応方針を検討する余地が生まれた。
４ 各裁判所とのTeams上に残っていた実務情報
ロックアウトが生じた時点で，旧アカウントのTeams画面には，複数の係属裁判所との間で用いていたウェブ会議用のチームが表示されており，各事件の期日及び提出期限に関する実務上の情報も含まれていた。画面上部には，同期が正常に行われていないことを示す警告（改めてサインインが必要である旨の表示）が出ており，最新の情報が更新されていない可能性がある状態であった。
第４ 方針の決定
１ 正規の復旧手続とその負担
唯一の管理者がロックアウトされた場合の正規の復旧手続としては，Microsoftのサポート窓口に連絡し，本人確認及び組織の所有権確認を経て認証方法をリセットしてもらう，という方法が案内されている。しかし，この手続には，組織の所有権を裏付ける書類の収集を要するなど，相応の日数を要することが見込まれた。
２ 裁判所への個別の再登録という選択
2026年7月2日中の検討の結果，山中弁護士は，正規の復旧手続を待つのではなく，各裁判所の担当窓口に直接連絡し，新しいアカウントでの再登録（ゲストとしての再招待）を依頼するという方針を選んだ。裁判所の窓口を通じた対応の方が迅速かつ確実であるという判断による。
なお，旧アカウントが紐づくテナント自体の正規復旧については，メールの受信自体には支障がなかったことから，急を要しないものとして後日に見送ることとした。
第５ 新しい認証基盤の構築
１ 思わぬ発見
2026年7月3日，新しい組織アカウントを作成するに当たり，旧アカウントとは別のメールアドレスでMicrosoftの無料アカウント登録を行おうとしたところ，このメールアドレスが，実は旧アカウントと同一人物の個人用アカウントの別名（エイリアス）であることが判明した。当初は全く独立した別のアカウントを用意するつもりであったが，実際には同一の個人用アカウントを土台にしていたことになる。
もっとも，これは今回の目的（新しい組織テナントを作り，その中に裁判所へ提示する新しい組織アカウントを作成すること）にとって支障はなかった。今回問題を生じていたのは組織（テナント）側の多要素認証であり，個人用アカウント側は健全に機能していたためである。
２ 新しいテナント及び組織アカウントの作成
手順は次のとおりであった。
①ブラウザでMicrosoft Azureの無料アカウント登録ページ（azure.microsoft.comの「無料で始める」）へアクセスし，上記の個人用アカウントでサインインした上で，登録手続を進める。この際，登録に用いたメールアドレスに応じて，新しいMicrosoft Entra IDテナント（既定のディレクトリ）が自動的に作成される。
テナントのプライマリドメイン（〇〇〇.onmicrosoft.comの形式）は，登録時に入力した組織名から自動生成されるほか，作成後に管理センターから変更することもできる。
②作成されたテナントの管理センター（entra.microsoft.com）にアクセスし，左側のメニューから「Identity」＞「ユーザー」＞「すべてのユーザー」と進み，「新しいユーザー」＞「ユーザーの作成」を選択する。
③ユーザー名（UPN，〇〇〇@〇〇〇.onmicrosoft.comの形式），表示名を入力し，ロールとして「ディレクトリの役割」から「グローバル管理者」を選択して，裁判所への提示専用となる別個の組織アカウント（新アカウント）を作成する。初回サインイン用の仮パスワードは，この画面で自動生成されるか，手動で設定できる。
これにより，サインアップに用いた個人用アカウントは管理用の入口にとどめ，外部（裁判所側）には新アカウントのUPNのみを開示し，個人用アカウントの情報は一切開示しない設計とした。
３ 認証手段を1つに頼らないための備え
今回のロックアウトが，管理者が1人・認証手段が1つという脆弱な構成に起因していたことの反省を踏まえ，新アカウントについては，複数の認証手段を用意することとした。
ア パスワードの設定
新アカウントで初めてサインインすると，仮パスワードの変更を求める画面が表示されるので，まずここで初期設定のパスワードを変更した。
イ 認証アプリの登録
新アカウントには管理者（グローバル管理者）ロールを付与したため，多要素認証の登録を求められた際，選択肢としてMicrosoft Authenticatorアプリでの登録が事実上必須であった（管理者ロールには既定でアプリによる認証を求める設定になっているためである）。
画面に表示されるQRコードを，日頃から使用しているスマホ端末のMicrosoft Authenticatorアプリで読み取り，アプリ側に表示される番号を画面の指示に従って入力することで登録を完了した。
ウ 電話番号によるバックアップ登録
Authenticatorアプリの登録完了後，myaccount.microsoft.comの「セキュリティ情報」ページを開き，「＋サインイン方法の追加」から「電話」を選択して，携帯電話番号をショートメッセージ（SMS）による確認方法として追加登録した。これにより，1つの認証手段が機能しなくなっても，別の手段で復旧できる状態を整えた。
４ 見落とし
作業を進める中で，裁判所のTeamsゲスト招待は，管理者からの招待メールを受信し，そこに記載された承諾用のリンクをクリックするという仕組みであることが判明した。
ところが，新しく作成した組織アカウントには，メールボックスが存在しなかった（基本ライセンスのみで，メール機能を含むライセンスを保有していなかった）ため，このままでは招待メール自体を永遠に受信できず，ゲスト登録の承諾手続に進めない，という重大な見落としが判明した。
５ メールボックスの追加
この問題への対処法としては，①別のメールアドレスで登録をやり直しブラウザ版中心の運用に戻す方法，②新アカウントに有料のメールボックス機能を追加する方法，③裁判所側から招待用のリンクを直接共有してもらう方法，の3通りが考えられた。
このうち，最も確実に自己完結できる方法として，メールボックス機能を含む有料ライセンス「Exchange Online（プラン1）」（月額599円＋税，年間契約・月払い）を追加購入する方法を選んだ。
(1) 購入手続で気を付けた点
購入は，Microsoft 365管理センター（admin.microsoft.com）の左メニュー「マーケットプレース」＞「すべての製品」タブから，検索窓に「Exchange」と入力し，表示された「Exchange Online（プラン1）」を選択して「今すぐ購入」から進めた。ライセンスの数量は1，請求頻度は「月払い・年間契約」を選択した。購入画面（チェックアウト画面）では，住所欄（市区町村の欄が一部抜けていた点，番地の入力欄を取り違えていた点）及び組織名（既定のままになっていた点）を確認の上，修正する必要があった。
購入完了後は，左メニュー「ユーザー」から新アカウントを選択し，「ライセンスとアプリ」タブでこのライセンスにチェックを入れ，「変更の保存」を押して割り当てた。この割当ての操作では，「使用場所が無効です」という趣旨のエラーが表示されたが，これはアカウントの連絡先情報に国又は地域（日本）が設定されていなかったことが原因であり，ユーザーの「連絡先情報の管理」画面で「国/地域」を「日本」に設定することで解消した。
(2) 反映までに要した時間
ライセンスの割当て直後は，メールボックスの準備が整うまでの間，InvalidOAuthTokenExceptionやError: 440，さらにはHTTP ERROR 500といった一時的なエラーが継続して発生した。半日程度の間隔を空けて改めて確認したところ，正常にメールボックスへアクセスできるようになっていることを確認できた。
６ 電話番号登録の持ち越し
多要素認証のバックアップをさらに厚くするため，事務所の固定電話番号も追加登録しようとした。ところが，myaccount.microsoft.comの「セキュリティ情報」ページで「＋サインイン方法の追加」を開いても，選択肢に「電話」が表示されなかった。これは，セルフサービスでの電話番号の追加登録は1件のみに限られるという制約によるものであった（既に携帯電話番号を登録済みであったため）。
調べたところ，固定電話番号を登録するには，Entra管理センター（entra.microsoft.com）の「ユーザー」から新アカウントを選択し，「プロパティ」タブの「編集」から「連絡先情報」を開き，「勤務先の電話番号」欄に番号をあらかじめ入力して保存しておくことで，改めてmyaccount.microsoft.comの「サインイン方法の追加」を開いた際に，「勤務先の電話」という別枠の選択肢が新たに現れる，という一手間が必要であることが分かった。当日は「勤務先の電話番号」欄への入力までを行い，この作業は2026年7月7日に持ち越すこととした。
７ ブラウザのキャッシュに起因する不具合とその回避
これとは別に，ブラウザに残っていた以前のテナントに関するキャッシュ情報の影響により，新しいテナントのアカウントでサインインしようとしても，AADSTS90072という，アカウントが存在しないという趣旨のエラーが再現する現象が生じた。これは，プライベート（シークレット）ブラウジングウィンドウを使用することで確実に回避できることを確認した。
８ 固定電話番号登録の完了とそこから得られた教訓
2026年7月7日，前記６で持ち越していた固定電話番号の追加登録作業を再開した。「勤務先の電話番号」欄への入力自体は前日のうちに済ませていたが，これがサインイン方法の選択肢として実際に反映されるまでには，翌日まで待つ必要があった。属性の変更内容がシステムに反映されるまでには，一定の時間差が生ずることがあるという点も，1つの教訓である。
反映後，myaccount.microsoft.comの「セキュリティ情報」ページで「＋サインイン方法の追加」を開くと，今度は「勤務先の電話」という選択肢が表示された。これを選択し，確認方法として「電話をかける」（音声通話）を選んだ。ここでは，着信後にガイダンスに従って番号（＃）を押して応答したことを知らせる操作が必要であったが，この点を事前に確認していなかったため，1回目の通話では正しく応答できず失敗した。
ところが，失敗した直後にすぐさま再試行したところ，短時間に複数回失敗したと判定されたためか，一時的に試行そのものがブロックされる事態となった。皮肉なことに，本稿全体のテーマである「認証の失敗によるロックアウト」と性質の似た小さな出来事が，作業の最終盤でも生じたことになる。
しばらく時間を置いてから改めて試行したところ，番号（＃）を押す操作を正しく行うことができ，固定電話番号の登録を完了することができた。これにより，新アカウントの多要素認証は，認証アプリ・携帯電話番号・固定電話番号（勤務先の電話）という3つの手段を備えるに至った。
ここから得られる教訓は，電話による確認等，自分自身の手作業を伴う認証手順については，実際に操作する前に，確認すべき操作（今回でいう＃キーの入力等）をあらかじめ把握しておくべきだということである。何が起きるか分からないまま試行し，失敗した直後に急いで再試行することは，かえって一時的なブロックを招き，復旧をかえって遅らせる原因になりかねない。
第６ 使えなくなったアカウントの後始末
１ 接続解除の操作が反応しなくなった経緯
これとは別に，2026年7月3日，日常的に使用するパソコンの設定画面において，使えなくなった旧アカウントがサインイン候補として繰り返し表示され，作業の妨げとなる問題が生じていた。設定画面から接続解除を試みたが，確認ダイアログの最終段階で操作が反応しなくなり，何度試みても変化が生じない状態となった。
２ 証明書の削除による解決
管理者権限によるコマンド実行（dsregcmd /leave）も試みたが，これはデバイス単位の登録（Azure ADへのデバイス参加）を解除するためのものであり，ユーザーアカウント単位の「職場または学校にアクセスする」接続には効果がなく，改善はみられなかった。最終的に，次の手順で証明書を手動で削除することにより，接続の解除に成功した。
①まず，PowerShellを管理者として実行し，次のコマンドを入力して状態を確認する。
dsregcmd /status
②出力結果のうち，「Device State」欄の「WorkplaceJoined」が「YES」になっていることを確認し，同じ出力内にある「WorkplaceThumbprint」（証明書の拇印）の値と，「WorkplaceDeviceId」（証明書の発行先に表示されるGUID）の値を控えておく。
③次に，キーボードの「Windowsキー＋R」でファイル名を指定して実行を開き，次のコマンドを入力して証明書の管理コンソールを開く。
certmgr.msc
④左側のツリーで「証明書 － 現在のユーザー」＞「個人」＞「証明書」の順に展開し，一覧の中から，発行先（Subject）の欄が②で控えた「WorkplaceDeviceId」の値（GUID形式の文字列）と一致する証明書を探す。念のため，その証明書をダブルクリックして「詳細」タブを開き，「拇印」フィールドの値が②の「WorkplaceThumbprint」と一致することも確認する。
⑤該当する証明書を右クリックし，「削除」を選択する。確認のダイアログが表示されるので，内容に間違いがないことを再確認した上で「はい」を選ぶ。
⑥削除後，改めて①のコマンド（dsregcmd /status）を実行し，「WorkplaceJoined」が「NO」に変わっている（又はWorkplace関連の行自体が表示されなくなっている）ことを確認する。
設定画面の「切断」ボタンが反応しなかった原因は，この管理画面（SystemSettingsAdminFlows.exe）固有の不具合によるものであったとみられる。
３ 副作用への対応
この対応の副作用として，通常のブラウジングモードでメールを開こうとすると，今度は個人用アカウントの方へ自動的にサインインされてしまい，OwaUserHasNoMailboxAndNoLicenseAssignedExceptionという，メールボックスが存在しないという趣旨の別のエラーが表示されるようになった。これは，個人用アカウントが法人向けのメールの仕組みへ本来アクセスできないことに起因する，想定内の挙動であった。この点を踏まえ，実務メールへのアクセスは，プライベート（シークレット）ブラウジングモードで行うという運用に改めることとした。
第７ 新たな壁
１ エラーメッセージの読み解き
2026年7月6日，新アカウントでのメールボックス確保も済んだ後，改めてTeamsへのサインインを試みたところ，これまでとは異なる新たなエラーに遭遇した。画面には，エラーコードAADSTS500014とともに，次のメッセージが表示された。
The service principal for resource ‘00000003-0000-0ff1-ce00-000000000000’ is disabled. This indicate that a subscription within the tenant has lapsed, or that the administrator for this tenant has disabled the application, preventing tokens from being issued for it.
このメッセージに含まれる00000003-0000-0ff1-ce00-000000000000というリソースの識別番号を確認したところ，Microsoftのファイル共有サービス（SharePoint Online）を示す固定の識別番号であることが判明した。
２ 原因の推測
これまでに購入していたライセンスは，メールボックス機能を含むもの（前記第５の５）のみであり，ファイル共有サービスを含むライセンスは購入していなかった。新しいTeamsは，ファイル共有機能のために，このサービスのトークンの発行を必要とするところ，該当するライセンスがテナント内に存在しないため，サインインの手続自体がブロックされていたものと推測された。
もっとも，このように必要なサービスをその都度個別に見つけては追加購入するという進め方自体，最初から見直すべき余地があったといえる（この点は後記第10の3で述べる。）。
第８ 不足していたライセンスの購入と反映
１ 購入手続
前記第５の５(1)と同様に，管理センター（admin.microsoft.com）の左メニュー「マーケットプレース」＞「すべての製品」タブから，検索窓に「SharePoint」と入力した。現在のカタログでは「SharePoint Online」ではなく「SharePoint（プラン1）」という表記（Onlineが取れた名称）で表示された。これを選択し，「今すぐ購入」から進み，ライセンスの数量は1，請求頻度は「749円 ライセンス/月（月払い・年間契約）」を選択した。税抜小計は749円であった。
購入手続には，登録済みのクレジットカードによる決済に加え，カード発行会社が提供する本人確認の手続（メールに送付される確認コードの入力）も含まれていた。
２ ライセンスの割当て
購入完了後，完了画面の「新しいサブスクリプションにユーザーを割り当てます」のリンクから，又は改めて左メニュー「ユーザー」から新アカウントを選択し，「ライセンスとアプリ」タブでこのライセンスにチェックを入れ，「変更の保存」を押して割り当てた。
３ サインインの前進を示す間接的な兆候
ライセンス割当てから間もなく，正式なTeamsのライセンスを持たないユーザーが初めてサインインに成功した際に自動的に発行される，無料の体験版ライセンスが付与された旨の通知メールが届いた。この通知が届いたこと自体が，前記第７のエラーによる阻害を乗り越えてサインインの手続が前進したことを示す間接的な兆候であった。
第９ 最後の分かれ道
１ アプリ版の長時間の停滞
ライセンス割当て後，パソコンにインストールされた新しいTeamsのアプリ版でサインインを試みたところ，読み込み中を示す画面のまま，15分以上経過しても進展がみられなかった。
２ ブラウザ版での復旧確認
一方，ブラウザ版（teams.microsoft.com）で同じアカウントを試したところ，問題なくサインインができた。実際に，複数の係属裁判所のうち，あるチームについては，以前と同様に会話の履歴を含めてアクセスできることを確認した。
画面右上のプロファイルアイコンをクリックして表示されるパネルで，組織のコンテキストが裁判所側のテナントになっており，表示名も新アカウントのものになっていることを確認し，新アカウントが，既に裁判所側のテナントのゲストとして認識されていることを確認できた。
もっとも，これは全ての係属裁判所について再登録が完了したことを意味するものではなく，本稿執筆の時点では，残る複数の裁判所については，改めて各裁判所の担当窓口へ新アカウントでの再登録を依頼する作業が引き続き進行中である。
３ 日をまたいだ再アクセスと完全なサインアウトの必要性
ここで留意すべきは，「通常のサインアウト」と「完全なサインアウト」の違いである。通常のサインアウトとは，Teamsの画面上にある「サインアウト」ボタンを押すだけの操作をいう。これは，そのアプリ又はタブ内のサインイン状態を終了させるものの，ブラウザ自体に保存されている認証済みの情報（アカウント選択画面に表示される「前回使用したアカウント」の情報等）までは消去しない。
これに対して，完全なサインアウトとは，ブラウザに保存されている当該アカウントの認証情報を，Cookie等も含めて丸ごと解除する操作をいう。
この違いが表面化したのが，日をまたいでの再アクセスであった。前記２のとおり，ある日にブラウザ版で無事にサインインできることを確認できたが，日をまたいで改めて同じブラウザから裁判所側のチームへアクセスしようとしたところ，前日の認証状態が中途半端に残ってしまい，正しく新アカウントとして認識されない状態が生じた。
この場合，通常のサインアウトを行っただけでは解消せず，完全なサインアウトを行った上で，パスワード及び多要素認証を伴う新規のサインインを改めて行って初めて，裁判所側のチームへ正しくアクセスできるようになった。
４ 得られた教訓の一般化
この一連の事象は，従前より把握していた傾向（新しいTeamsのアプリ版は，外部の別組織のゲストとしての利用に関して不安定になりやすく，ブラウザ版の方が確実に動作する傾向にあること）と符合するものであった。もっとも，今回使用したアカウントは，個人用アカウントではなく，正規の組織メンバーアカウントであったにもかかわらず，同様の不調が生じた点は注目に値する。
さらに，別の機会に確認したところ，ブラウザ版であっても，既存のサインインセッションをそのまま引き継ごうとする自動的な処理（いわゆるサイレントSSO）に頼った場合には，同様の失敗が生じ得ることも判明した。
これらを総合すると，不調の真の原因は，アプリ版かブラウザ版かという利用形態の違いそのものよりも，パスワードの入力及び多要素認証を伴う本来の対話的な再認証を経ているかどうかという点にあると考えられる。
既存のセッションを自動的に引き継ごうとする経路は，外部組織のゲストとしての切替えでは失敗しやすく，改めて明示的にサインインし直す経路の方が確実に成功する，というのが実態に近いようである。
第１０ 本件から得られた教訓
１ 認証基盤の設計に関する教訓
今回の経緯から得られる第1の教訓は，管理者アカウントが1つしかなく，かつ，多要素認証の手段が1つしかないという構成は，それだけでロックアウトの重大なリスクを抱えているということである。新しく用意するアカウントには，あらかじめ複数の管理者及び複数の認証手段を用意しておくべきである。
前記第５の８で述べた固定電話番号登録時の一時的なブロックは，規模こそ小さいものの，同じ構造の危うさが最後まで繰り返し得ることを示す一例であった。
２ クラウドサービスの利用形態に関する教訓
第2の教訓として，クラウドサービスへのサインインがうまくいかない場合には，パソコンにインストールする形式のアプリケーションからブラウザを通じて利用する形式へ切り替えてみることに加えて，前記第９の3で述べたとおり，一旦完全なサインアウトを行った上で，改めてパスワード及び多要素認証を伴う対話的な手続でサインインし直してみることも有効な対処法であるということが挙げられる。
既存のサインインセッションを自動的に引き継ごうとする処理が，外部組織との連携という場面ではかえって支障となることがあるためである。
３ ライセンス構成の選び方に関する教訓
第3の教訓として，新しいテナントを一から構築する際のライセンスの選び方が挙げられる。本稿では，メールボックス機能（前記第５の５）とファイル共有機能（前記第７及び第８）を，それぞれ必要に迫られてから個別に購入するという，いわば後追いの方式を採った。この方式は，一つ一つのライセンスの内容を理解しながら進められる反面，どの機能が不足しているかを都度エラーによって発見しては対処するという，非効率な試行錯誤を伴うものであった。
これに対し，メール・ファイル共有・Teams等の主要なサービスをあらかじめまとめて含む統合的なプラン（例えば，Microsoft 365 Business Basic等）を最初から選んでいれば，前記第７及び第８で述べたようなサインインのブロックという事態自体，そもそも生じなかった可能性が高い。
新しくテナントを構築する際には，個々のサービスを必要最小限に絞って積み上げるよりも，主要なサービスを一括して含むプランを検討する方が，かえって近道であることも少なくない。
第１１ おわりに
2026年7月7日の固定電話番号登録の完了をもって，新アカウントの認証基盤の整備は一区切りとなった。
本稿で記録した一連の経緯は，特殊な事例ではなく，複数の認証手段を用意していない限り，どの実務家にも起こり得るものである。本稿が，同種のトラブルへの備えを検討する一助となれば幸いである。