二段階認証の義務化対応｜管理者と共用アカウントから有効にする

二段階認証の義務化への対応は、止まると業務が止まる管理者アカウントから共用アカウント・外部委託先が持つアカウントの順に期限の前に有効にし、復旧の手段を二人で持つことです。告知と期限が管理画面に出たとき、最初に迷うのは自分のアカウントだけ設定すれば済むのかどうかです。各社のヘルプにあるのは一人分の設定手順で、共用の窓口や委託先の管理画面の確認コードが誰の電話に届くかの欄はありません。止まったときに止まる範囲の広い順に、四つのアカウントを並べた図と表を置きます。

Google Cloud と Google Workspace の期限や通知の時期は、2026年10月22日に開いた公式ページの記載です。アカウントの種類や組織によって日付は変わり、ページの記載も更新されることがあります。当社について書くのは、当社のコンソールに出た義務化の告知と有効にした日の運用記録だけで、対策の効果を測ったものではありません。業界の制度や行政の手続きで求められる多要素認証は、ここでは扱いません。

二段階認証（多要素認証・MFA）の義務化とは、提供側がパスワードに加えて別の確認を必須にし、期限後は登録のないアカウントで入れなくする変更である

二段階認証の義務化とは、クラウドや業務アプリの提供側が、パスワードに加えて二つ目の確認を利用者に求めるよう設定を変えることです。期限を過ぎると、二つ目の確認を登録していないアカウントでは管理画面やアプリに入れなくなります。利用者の側で選べるのは、期限までにどのアカウントから有効にするかの順番です。

Google は Google Cloud のすべての顧客に、アカウントで多要素認証（MFA）を有効にするよう段階的に義務付けています。同じページは MFA と「2 段階認証プロセス」を同じものとして扱い、パスワードに加えて「認証要素」と呼ぶ別の本人確認が要る仕組みだと説明しています（Google Cloud「Google Cloud の多要素認証の要件」／2026年10月22日時点の記載）。Google Workspace 管理者ヘルプも、Google が管理者アカウントに2段階認証プロセスを適用していると明記しています（Google Workspace 管理者ヘルプ「2 段階認証プロセスを導入する」／2026年10月22日時点の記載）。

Google だけの動きではありません。Microsoft も Azure と管理ポータルへのサインインに多要素認証を必須にしています。Azure portal と Microsoft Entra 管理センターと Intune 管理センターは2024年10月以降が対象で、Microsoft 365 管理センターは2025年2月から段階的に適用するとしています（Microsoft Learn「必須の Microsoft Entra 多要素認証 (MFA) を計画する」／2026年10月22日時点の記載）。

言葉の上では、二段階認証と多要素認証は同じではありません。国家サイバー統括室（旧 内閣サイバーセキュリティセンター）のハンドブックは、二段階認証を認証の手順を二段階に分けるものとし、使う要素の種類とは関係がないと説明しています。二段階でも要素が一つの場合があり、一段階でも二要素の場合があって、後者のほうが安全性は高いという整理です（国家サイバー統括室「インターネットの安全・安心ハンドブック Ver 5.10 第5章」（PDF）／2026年10月22日閲覧）。総務省の用語集も、同じ種類の要素で二段階に分けても二段階認証と呼び、異なる要素を組み合わせて二回認証するものは二要素認証とも呼ぶとしています。同じ要素を二回使うより異なる要素を二回使うほうが、安全性は高くなります（総務省「国民のためのサイバーセキュリティサイト 用語集(な行)」／2026年10月22日閲覧）。

この記事では、各社の告知に合わせて二段階認証と書きます。守りの強さを左右するのは段階の数より要素の種類だという点は、承認の癖を扱う節で効いてきます。

図は、有効にする順番を左から右へ並べたものです。箱の下には止まったときに止まるものと先に確かめることを置き、上には告知から期限までの帯を引きました。持ち主のいないアカウントは図の箱に入れず、社員全員に広げる前に止めるか持ち主を決めます。

期限後に困るのは、そのアカウントでしか変えられない設定を持つ会社である

Google Cloud の場合、期限を過ぎて入れなくなるのは管理画面で、動いている仕組みそのものは止まりません。困るのは、そのアカウントでしか変えられない本番の設定や請求の情報を持つ会社のほうです。

Google Cloud の公式ページでは、要件が適用されたアカウントは MFA を有効にしないと Google Cloud コンソールと Firebase コンソールにログインできません。Google Cloud で動いているアプリケーションやワークロードは影響を受けない一方で、開発者はそれらをコンソールで管理できなくなります。ページはこれを、コントロール プレーンは影響を受けてデータプレーンは影響を受けないと言い表しています（Google Cloud「Google Cloud の多要素認証の要件」／2026年10月22日時点の記載）。

サイトやアプリが動き続けるぶん、入れないことに気づくのは設定を変えたくなった日です。障害の対応で設定を戻したい日や請求先を差し替えたい日に、管理画面に入れる人がいない状態が起きます。期限の当日にサイトが止まるわけではないので、慌てる場面がないまま期限が過ぎます。それが、入れないことに気づく日を遅らせます。

Google Cloud の開始日はアカウントの種類で分かれ、日本語版と英語版で表が違う

Google Cloud の適用の開始日は一つではありません。日本語版のページ（最終更新 2026-02-03）の表は、開始日をアカウントの種類で分けています（Google Cloud「Google Cloud の多要素認証の要件」／2026年10月22日時点の記載）。英語版のページ（最終更新 2026-10-13）では、SSO を使わない Enterprise Cloud Identity の行が組織の作成日で二つに分かれ、連携認証を使う企業アカウントの行は「To be announced（未定）」に改められています（Google Cloud「2-step verification requirement for Google Cloud」／2026年10月22日時点の記載）。

表は横にスクロールできます。

告知の届き方も公式ページに書かれています。MFA を有効にしていないアカウントには、適用が始まる90日前までにコンソールのリマインダーとメールが届き、販売パートナーは60日前までです（Google Cloud「Google Cloud の多要素認証の要件」／2026年10月22日時点の記載）。表の日付はアカウントの種類ごとのもので、自社の期限は自社の管理画面に出た告知で確かめます。

Google Workspace の管理者は、登録しないまま使えるアプリが段階的に減る

Google Workspace でも、管理者アカウントへの二段階認証の適用は段階的に進んでいます。特権管理者には適用開始の約90日前、その他の管理者には約60日前に通知が届き、管理コンソールのホームにもリマインダーが表示されます（Google Workspace 管理者ヘルプ「管理者に対する 2 段階認証プロセスの適用について」／2026年10月22日時点の記載）。

通知の期間中に管理者が有効にしないと、7日後もリマインダーが出続けます。15日後にはモバイル端末の Workspace アプリに、30日後にはウェブアプリに、登録するまでアクセスできなくなります（Google Workspace 管理者ヘルプ「管理者に対する 2 段階認証プロセスの適用について」／2026年10月22日時点の記載）。Workspace のアプリは日々のメールや文書の作業そのものなので、管理画面だけが止まる Google Cloud と違って管理者本人の日常の作業にも響きます。

最初に有効にするのは管理者アカウントで、共用アカウントと外部委託先が持つアカウントがそれに続く

有効にする順番は、止まったときに業務が止まる範囲の広い順です。管理者アカウントが最初で、共用アカウントと外部委託先が持つアカウントが続き、社員全員はそのあとに広げます。

管理者アカウントが止まると、ほかの人のアカウントの復旧も設定の変更もできなくなります。共用アカウントは問い合わせの窓口や受付のように社外とつながる作業を持つことがあり、止まると取引先の側からも見えます。外部委託先が持つアカウントが止まると委託している作業が止まり、社内には直せる人がいません。社員一人ひとりのアカウントは止まっても範囲がその人の作業に限られ、管理者が復旧を手伝えます。

表は横にスクロールできます。

持ち主のいないアカウントは、この表に入れずに別に扱います。有効にする人がいないので、止めるか持ち主を決めるかの判断が先になるからです。

管理者アカウントは、管理者の数を減らしてから復旧の手段を二人で持つ

Google Workspace では、Google が設定した適用ポリシーの対象になった管理者は、そのポリシーを回避できません。Workspace 管理者ヘルプは、有効にできない管理者は管理者権限を削除するしかないとしています。いま対象になっているのは Cloud Identity や Workspace for Education などの組織で、今後数年かけて段階的に適用されます（Google Workspace 管理者ヘルプ「管理者に対する 2 段階認証プロセスの適用について」／2026年10月22日時点の記載）。

そこで最初に、管理者の権限を持つアカウントを書き出します。いまその権限が要らない人からは外し、残った管理者を期限の前に有効にします。管理者が少ないほど、期限の前に確かめる相手も復旧の手順を覚える人も少なくて済みます。

IPA のガイドラインは、システムや情報の重要度に応じて認証の強度と方法を決め、複数の要素を組み合わせる多要素認証を使うよう求めています（IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（PDF）／2026年10月22日閲覧）。管理者の権限は会社の中で最も重要度の高い入口なので、順番の先頭に置きます。

復旧の備えとして、Workspace 管理者ヘルプは三つを挙げています。管理者用の予備のセキュリティ キーを登録しておくこと、特権管理者が他の管理者のバックアップ コードを前もって作って保管しておくこと、特権管理者をもう一人置くことです（Google Workspace 管理者ヘルプ「2 段階認証プロセスで保護されているアカウントを復元する」／2026年10月22日時点の記載）。どれも、一人の端末が使えなくなった日に別の誰かが入れる状態を作るためのものです。管理者が一人しかいない会社では、有効にする前にもう一人の管理者を決めます。

共用アカウントは、確認コードの届く電話番号や端末が退職者や個人の手元に残っていないかを先に確かめる

共用アカウントで先に確かめるのは、確認コードが届く電話番号や端末が誰の手元にあるかです。登録した人が退職していたり、個人のスマートフォンにしか届かなかったりすると、有効にした日から入れる人が一人に限られるか誰もいなくなります。

IPA のガイドラインは、共有の ID はなるべく使わず、やむを得ず使う場合はその ID を使った利用者を特定できる仕組みを整えるよう求めています（IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（PDF）／2026年10月22日閲覧）。二段階認証の義務化は、共用アカウントを個人のアカウントに分けられないかを考え直す機会でもあります。分けられない窓口だけを共用に残し、残したアカウントはいつ誰が使ったかを後から確かめられるようにしておきます。

たとえば、問い合わせ窓口のアカウントを作った人の携帯番号が確認先に登録されたまま、その人が異動や退職でいなくなっている状態を考えます。パスワードを知っている人が社内に何人いても、二つ目の確認が届くのは前の持ち主の電話だけです。有効にする前にこの登録を確かめないと、義務化の日がそのまま窓口の止まる日になります。

確認先の電話番号を変えるときは、順番に気をつけます。Workspace 管理者ヘルプによると、直近に使った二つ目の確認手段（電話番号など）を削除すると警告が出て、新しい手段を追加しないとアカウントがロックアウトされる可能性があります（Google Workspace 管理者ヘルプ「組織によって 2 段階認証プロセスが適用されている場合にアカウントがロックされるのを回避する」／2026年10月22日時点の記載）。古い番号を消す前に新しい手段を足し、足した手段でログインできることを確かめてから消します。

共用アカウントの確認手段は、二人の手元に分けて持ちます。一人の端末が壊れたり、その人が休んだりした日にも、もう一人が入れるからです。二人目の手段が同じ人の別の端末では、分けたことになりません。

外部委託先が持つ管理画面は、確認コードが委託先の誰の端末に届くかを契約先に聞く

ホームページの管理画面や広告のアカウント、業務システムの管理者を外部委託先が持っている場合、二つ目の確認は委託先の誰かの端末に届きます。契約先に聞くのは、確認が届くのは誰の端末かと、その人が抜けたときに誰が代わりに入れるかの二点です。

IPA のガイドラインは、管理者権限でのリモート接続について、接続元の制限や端末の要件を定めるよう求めています（IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（PDF）／2026年10月22日閲覧）。委託先が社外から管理者の権限で入っているなら、どの端末から入りその端末で二つ目の確認を受けているかは、発注側が知っておく情報です。

そのアカウントが誰の名義で作られているかは別の問いで、ベンダーロックインの対策で扱いました。ここで決めるのは順番です。委託先のアカウントは、社内の共用アカウントを済ませたあと、社員全員に広げる前に有効にしてもらいます。委託先から期限の延長を頼まれた場合も、止まったときに止まる作業を契約先と一緒に確かめてから決めます。

ホームページの管理画面を制作会社が持っている場合の確かめ方は、ホームページの改ざん対策にまとめています。PHP の脆弱性 php2shell の経緯と、自社のサイトが対象かどうかの確かめ方はphp2shell の記事に書きました。

社内に広げるのは管理者を済ませてからで、全員への強制は猶予の期間と問い合わせ先を決めてから入れる

社員全員への強制は、管理者と共用と委託先のアカウントを済ませてから入れます。先に決めるのは、登録までの猶予の期間と、登録できない人が連絡する問い合わせ先です。

Workspace 管理者ヘルプは、導入の最初の手順に利用者へ計画を伝えることを置いています。伝える中身は、二段階認証の概要と会社が使う理由・任意か必須か・必須ならいつまでに有効にするか・勧める方式です（Google Workspace 管理者ヘルプ「2 段階認証プロセスを導入する」／2026年10月22日時点の記載）。この四つに、登録できなかったときの問い合わせ先を足して社内に送ります。問い合わせ先が決まっていないと、期限の朝に入れなくなった人の連絡が管理者の個人宛てに集まります。

期限までに登録しなかった人は、二段階認証が適用されないグループに入れればログインできるようになります。ただし Workspace 管理者ヘルプは、これを標準的な対処としては勧めていません（Google Workspace 管理者ヘルプ「2 段階認証プロセスを導入する」／2026年10月22日時点の記載）。例外のグループに頼らずに済むよう、猶予の期間は強制の前に置きます。

組織の部門を移すときにも注意が要ります。二段階認証を適用していない部門から適用している部門へ、登録していない人を移すと、その人はログインできなくなります（Google Workspace 管理者ヘルプ「組織によって 2 段階認証プロセスが適用されている場合にアカウントがロックされるのを回避する」／2026年10月22日時点の記載）。部門の移動と強制の開始は、同じ日に重ねません。

入社した人の扱いも決めておきます。初日に登録を済ませる手順を入社の手続きに入れておけば、猶予の期間を人ごとに管理せずに済みます。退職の手続きには、確認先の電話番号と端末を外す手順を入れます。

二段階認証をかけても乗っ取りはなくならず、確認の通知を確かめずに承認する癖が次の穴になる

二段階認証は盗まれたパスワードだけでは入れなくする仕組みで、乗っ取りをなくす仕組みではありません。次の穴になりやすいのは、届いた確認の通知を確かめずに承認してしまう癖です。

CISA は「MFA 疲労」（プッシュ爆撃）を、攻撃者が承認の通知を送り続けて利用者に承認させる手口だと説明しています。利用者が誤って押すか、鳴りやまない通知に嫌気がさして押すことを狙うものです。CISA がまず勧めるのはフィッシング耐性のある MFA で、それをすぐに入れられない場合の対策として、ログインの画面に出た番号を利用者に入力させる番号の照合を挙げています（CISA「Implementing Number Matching in MFA Applications」（PDF）／2026年10月22日閲覧）。確認を挟みすぎると確かめずに押す状態が生まれる点は AI エージェントの承認でも同じで、AIエージェントの権限設計でも MFA 疲労になぞらえて書きました。

CISA は、MFA の方式によって守りの強さは同じではないとし、フィッシングに耐性のある MFA を目指すべき標準に置いています。そのうえで、どの MFA でも無いよりはよいとしています。広く使えるフィッシング耐性のある認証は FIDO/WebAuthn だけだとも書いています（CISA「More than a Password」／2026年10月22日閲覧）。国家サイバー統括室のハンドブックも、多要素認証まで破る「中間者攻撃」があることを挙げ、多要素認証だからそれだけで絶対に安全とは限らないとしています（国家サイバー統括室「インターネットの安全・安心ハンドブック Ver 5.10 第5章」（PDF）／2026年10月22日閲覧）。

社内で決めておくのは、承認の仕方です。強制を入れる前の案内には、三つを書きます。自分がログインしていない時間に届いた通知は承認しないこと、身に覚えのない通知が続いたら管理者に知らせること、知らせを受けた管理者がパスワードを替えることです。どの方式に切り替えるかは、使っているサービスが選べる方式と、管理者が復旧を手伝える範囲で決めます。

持ち主のいないアカウントと自動の処理が使う人のアカウントは、義務化の前に止めるか持ち主を決める

持ち主のいないアカウントとは、退職した人のアカウントや昔の委託先が作ったアカウント、試しに作ったまま残っているアカウントのことです。有効にする人がいないので、義務化の前に止めるか、持ち主を決めて有効にしてもらうかを選びます。止めるかどうか迷うアカウントは、先にパスワードを変えて使えないようにします。困る人が出ないことを確かめてから、削除に進みます。

自動の処理が人のアカウントでログインしているなら、義務化の前にそのアカウントから外します。Google Cloud の MFA の適用はサービス アカウントには影響せず、ユーザー アカウントだけが対象です。ただし Google アカウントでサービス アカウントの権限を借用している場合は、MFA が必要になります（Google Cloud「Google Cloud の多要素認証の要件」／2026年10月22日時点の記載）。人のアカウントで動く処理は、その人の退職や端末の交換と一緒に止まりやすく、誰の処理なのかも分かりにくくなります。サービス アカウントの鍵を作る操作が既定で止められている場合の考え方は、サービスアカウントキーの作成無効の記事に書きました。

二段階認証の義務化対応についてよくある質問

Q. 管理者が二段階認証を解除することはできますか？

Google Workspace では、Google の適用ポリシーの対象になった管理者は解除できず、有効にできない管理者は権限を外すしかありません（Google Workspace 管理者ヘルプ「管理者に対する 2 段階認証プロセスの適用について」／2026年10月22日時点の記載）。Google Cloud の英語版のページには、2026年8月3日より前に作られた SSO なしの Enterprise Cloud Identity の組織は、組織単位で一度だけ90日の延長を有効にできると書かれています。SSO を使わない Enterprise Cloud Identity の組織は、要件のオプトアウトもできますが、Google は推奨していません（Google Cloud「2-step verification requirement for Google Cloud」／2026年10月22日時点の記載）。延長は期限を後ろにずらすだけなので、使うなら延ばした期間で管理者と共用のアカウントを済ませます。

Q. Microsoft 365 や Azure の義務化も同じ順番で進めてよいですか？

同じ順番で進められます。Microsoft の義務化も最初の段階の対象は Azure と管理ポータルへのサインインで、止まるのは管理画面に入るアカウントからです。2025年10月1日以降は、Azure CLI や Azure PowerShell などからの作成・更新・削除の操作にも段階的に MFA が求められます。自動化に人のアカウントを使っている場合は、ワークロード ID へ移すよう勧めています（Microsoft Learn「必須の Microsoft Entra 多要素認証 (MFA) を計画する」／2026年10月22日時点の記載）。そのため管理者アカウント・共用アカウント・外部委託先の順に済ませ、自動の処理は人のアカウントから外します。期限と通知の届き方は各社で違うため、日付は各社の管理画面の告知で確かめます。

Q. 確認コードを受け取る電話番号が変わったら、どうすればよいですか？

番号を替える前なら、新しい確認手段を足してから古い番号を消します。手順は共用アカウントの節に書いたとおりです。番号が使えなくなってから気づいた場合は、自分で直そうとせず、社内で決めた問い合わせ先に連絡して管理者に復旧を頼みます。管理者の確認手段を二人で持っておくのは、この場面で頼る先を残すためです。

Q. 個人の Gmail アカウントで Google Cloud を使っている場合も対象ですか？

対象です。Google Cloud の日本語版のページの表では、個人の Google アカウントへの適用は2025年5月12日以降です。Google Cloud に使っている Gmail アカウントは、MFA の要件をオプトアウトできません（Google Cloud「Google Cloud の多要素認証の要件」／2026年10月22日時点の記載）。会社の仕組みを個人のアカウントで持っているなら、有効にするのと同時に、そのアカウントを会社のアカウントに移せないかを確かめます。

SAIの視点：義務化の告知は、管理画面とメールを開く人のところにしか届かない

義務化の告知は期限の前から当社の Google Cloud のコンソールに出ていましたが、その画面を開く人が決まっていなければ告知は誰にも届きません。当社は告知の期限より前の2026年10月19日に、当社の Google アカウントで有効にしました。この期限は当社の画面に出た告知のもので、すべての会社に共通する期限ではありません。共用のアカウントや委託先が持つアカウントでは、告知を開く人がいないまま期限が来ることがあります。有効にする順番を決める前に告知を読む人をアカウントごとに決めておけば、期限を知らないまま当日を迎えるアカウントが減ります。

管理者の一覧を開いて、確認コードの届き先が個人の携帯だけになっている行に印を付けてください。印の付いた行が、期限の前に二人目の確認手段を足すアカウントです。お問い合わせには、使っている外部サービスの一覧とそれぞれの管理者が分かる範囲と届いている告知の期限を書いてもらえれば、そこから有効にする順番を一緒に決めます。確認コードやパスワードは送らないでください。

どの外部サービスに管理画面があって誰が管理者かを知る運用の持ち主を社内に置くところまでを、FDE伴走開発で一緒に作ります。AI導入支援で組み込む仕組みも、管理者の権限は発注側のアカウントに残します。

乗っ取りの疑いがあるときや脆弱性の診断は当社の伴走では受けられないので、IPA・JPCERT/CC の相談窓口か専門の事業者に先に連絡してください。

出典と確認日

外部の出典はいずれも2026年10月22日に開いた。Google Cloud・Google Workspace・Microsoft の期限と通知の記述は同日時点の記載で、変わることがある。Google Cloud の要件のページは日本語版と英語版で最終更新日と表の中身が異なり、本文では両方を示した。Google Workspace 管理者ヘルプの日本語版のうち、管理者への適用・アカウントの復元・ロックの回避の3ページは、ページの冒頭で AI による翻訳であり誤りを含む場合があると断っている。当社の一次情報は当社のコンソールに出た義務化の告知と、2026年10月19日に当社の Google アカウントで有効にした運用記録で、対策の効果を測ったものではない。

• Google Cloud「Google Cloud の多要素認証の要件」（日本語版・最終更新 2026-02-03）
• Google Cloud「2-step verification requirement for Google Cloud」（英語版・最終更新 2026-10-13）
• Google Workspace 管理者ヘルプ「2 段階認証プロセスを導入する」（最終更新 2026-09-03）
• Google Workspace 管理者ヘルプ「管理者に対する 2 段階認証プロセスの適用について」（最終更新 2026-10-15）
• Google Workspace 管理者ヘルプ「2 段階認証プロセスで保護されているアカウントを復元する」（最終更新 2026-10-21）
• Google Workspace 管理者ヘルプ「組織によって 2 段階認証プロセスが適用されている場合にアカウントがロックされるのを回避する」（最終更新 2026-10-15）
• Microsoft Learn「必須の Microsoft Entra 多要素認証 (MFA) を計画する」（ページの見出しは「Azure と管理ポータルの必須の多要素認証」）
• CISA「More than a Password」
• CISA「Implementing Number Matching in MFA Applications」（PDF）（2022年10月）
• IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（PDF）（2026年3月27日）
• 国家サイバー統括室「インターネットの安全・安心ハンドブック Ver 5.10 第5章」（PDF）
• 総務省「国民のためのサイバーセキュリティサイト 用語集(な行)」（「二段階認証」の項）
• 当社の運用記録: 当社の Google Cloud のコンソールに出た義務化の告知と、2026年10月19日の当社の Google アカウントでの有効化