目次(12項目)
同じパスワードを複数のサービスで使っていると分かっていても、どこから直せばよいのか決められないまま先延ばしになります。一覧を作ろうとすると、どの値をどこに書くのかで手が止まります。変更した途端にログインできなくなる心配もあって、業務で使うメールほど後回しになりがちです。
直す単位は、サービス全体ではなくアカウント1件です。パスワードの管理方法は、影響の大きい1件を選んで移す手順として組み立てます。ここでは架空の業務メール1件を題材にします。独立したパスワードへの切り替え、使える認証強化、復旧の準備、新しい方法でのログイン確認までが範囲です。
- 直すのはサービス全体ではなく、アカウント1件です。
- ルールは3つで、サービスごとに独立した値を生成し、使える認証強化を設定し、変更の前に復旧手段を確かめます。
- Googleの案内では、パスワードを変更すると一部の例外を除くすべての端末がログアウト状態になるとされています。変更の前に、今使える回復手段を確かめてください。
- 移行済みの判断は、使い回しの有無、認証強化の設定状態、復旧手段と管理ツールの保護、新ログイン確認の結果、未移行の残作業の5つで見ます。
- 端末の紛失や漏えいの疑いは、通常の移行ではなく事故対応です。
使い回しを直す単位は、アカウント1件
パスワードの使い回しは、全サービスを一度に直すのではなく、アカウント1件を移すところから手を付けます。使い回しとは、複数のサービスで同じパスワードを使っている状態です。1か所から値が漏れると、同じ値を使った別のサービスまで開かれかねません。
NISTのパスワードの作り方の解説は、同じパスワードを複数のサイトで使うと、1か所の漏えいが使い回し先すべての侵害につながると説明しています。IPAの不正ログイン対策特集ページも、パスワードを「できるだけ長く」「複雑で」「使い回さない」ものにすることと、多要素認証の設定を挙げています。いずれも2026年10月28日に確認した記載です。多要素認証とは、覚えている情報と手元の端末のように、種類の違う要素を組み合わせて本人を確かめるやり方を指します。
破られにくい状態へ近づけるために決めることは、次の3つです。
- サービスごとに独立した値を生成します。記憶や手入力に頼らず、会社が許可した管理ツールに作らせる形です。
- 使える認証強化を設定します。2段階認証(Googleでは2段階認証プロセス)を有効にすると、ログインはパスワードと2つ目の手順、またはパスキーで行う形になります。パスキーは端末のロック解除で本人を確かめる方法で、使うと2つ目の手順は省略されると案内されています。追加の確認が1段増えるとは限りません。
- 変更の前に復旧手段を確かめます。元のログイン手段を失うと、復旧に日数がかかることがあります。
共通の文字列にサービス名を足して作る方式は、この記事では採りません。どこか1つが漏れた時点で、残りの値の作り方まで推測される手がかりが残ります。
長さの目安も、公的な文書で確認できます。NISTのSP 800-63Bは、パスワードだけで認証する場合は15文字以上、多要素認証の一部として使う場合は8文字以上を、認証の提供側へ求めています。読者個人の義務を定めた基準ではなく、8文字なら安全という意味でもありません。実際に設定できる文字数や文字種は、サービス側の条件と社内の規則に従います。

移行の前にそろえる4つの準備と、対象1件の選び方
操作に入る前に、手元の情報と権限をそろえておきます。公式画面を開く前に用意するのは、次の4つです。
- 秘密の値を書かないサービス一覧。アカウントの用途と、同じパスワードを使っている心当たりだけを並べます。
- 変更できる権限と、会社の運用規則。パスワードの条件や変更時期の決まりが社内にあるかを確かめます。
- 今使える回復用の連絡先と、管理者の相談窓口。受信できるメールアドレスや電話番号が現役かどうかを見ます。
- 会社が許可した管理ツールと、そのツール自身の守り方。ツールのログインには、ほかで使っていない値を設定します。ツール側で使える多要素認証の有効化、端末の画面ロック、ツールに入れなくなったときの回復方法と相談先も確かめます。対応していない設定や足りない権限が見つかったら、管理者へ相談します。
対象は、影響の大きい1件から選びます。業務で使うメールは、ほかのサービスのパスワード再設定の受け取り先になりやすいため、先に移す価値があります。社内の共有IDを使っている場合は、個人IDへ分ける相談を管理者へ先に出してください。共有のまま値だけ変えると、誰が使える状態なのかが分からなくなります。
復旧の準備から新ログイン確認までの6手順
6手順で外せないのは、復旧の準備をパスワードの変更より前に、新ログイン確認を古い記録の整理より前に置くことです。操作の確認先は、Google公式ヘルプの案内です。「セキュリティとログイン」から「パスワード」「2段階認証プロセス」「パスキー」の各項目へたどれます。画面の表記や並びは変わることがあるため、記事の文言ではなく公式の案内で確かめてください。
- 影響の大きいアカウントを1件選びます。共有IDの場合は、個人IDへ分ける相談を先に管理者へ出します。
- 今使える回復方法とアクセス手段を、変更の前に確かめます。回復用の連絡先で実際に受け取れるか、すでに保管しているバックアップコードが未使用のまま手元にあるかを見ます。使えない、または分からないときは変更を止めて、管理者へ相談します。
- 正規のURLから公式の設定画面へ入り、会社が許可した管理ツールで、そのサービス専用のランダムな値を長めに生成して設定します。文字数や文字種の条件は、サービス側の指定に合わせます。
- 利用できる2段階認証を有効にします。パスキーは、サービスと端末が対応し、組織の許可があり、自分が管理する端末で画面ロックを設定している場合に検討します。共有端末には自分のパスキーを作りません。設定した方式で必要になる回復手段は、設定の直後に準備します。パスワードの置き換えと、確認手段の追加は別の作業です。
- 今のログイン状態に左右されない経路から、新しい方法のログインを確かめます。たとえば、ブラウザのプロファイル(利用者ごとにログイン情報を分けて持つ設定)を別に用意する方法があります。使えるかどうかは認証方式とブラウザと端末で変わるため、対応を確認できたときの一例として扱ってください。
- 古い記録の整理は、確認が済んだあとに回します。ほかのサービスでまだ使っている値や回復手段を、まとめて消さないようにします。
3番目の手順で気をつけたいのは、変更の影響です。Googleのパスワードの変更・再設定の案内には、変更または再設定でほとんどの端末がログアウト状態になると書かれています。本人確認に使う端末など、一部の例外は挙げられています。2026年10月28日に確認した記載です。だからこそ、今使える回復手段の確認を2番目の手順に置いています。
5番目の新ログイン確認が済むまでは、今使えているログイン手段を自分から閉じないでください。確認に使う経路は、使う方式が対応しているものを選びます。Googleのパスキーの案内には、環境によってシークレットモードではパスキーを作成・使用できないことがあると書かれています(2026年10月28日確認)。変更でログアウトが起きるかどうかはサービス側の仕様によるため、復旧の準備は変更より先に終えておきます。

架空例でたどる、移行前と移行後の5つの軸
架空の例では、業務メールを独立した値へ移して新ログイン確認まで終えても、請求サービスは未移行として残ります。題材は、同じパスワードを業務メールと請求サービスの2件で使っている状態です。実在の企業や実際の事故ではなく、説明のために置いた例です。
今回移すのは、業務メール1件に絞ります。請求サービスは未移行のまま残す形です。1件ずつ進めるのは、つまずいたときに見直す範囲を狭く保つための順番です。ただし1つのアカウントで複数のサービスを使っている場合、変更の影響はそのアカウントで使う他のサービスにも及びます。
見る軸は5つです。使い回しの有無、認証強化の設定状態、復旧手段と管理ツールの保護、新ログイン確認の結果、未移行の残作業です。
| 確認軸 | 移行前の業務メール | 移行後の業務メール |
|---|---|---|
| 使い回しの有無 | 請求サービスと同じ値を共用 | 業務メール専用に生成した独立の値。請求サービスとの共用は解除 |
| 認証強化の設定状態 | パスワードだけ | 利用できる2段階認証を有効化。パスキーは対応と許可と画面ロックの確認後 |
| 復旧手段と管理ツールの保護 | 回復用の連絡先が受信できるか不明 | 回復用の連絡先で受信できることを確認済み。発行済みで未使用のバックアップコードを印刷し、重要書類と一緒に保管して取り出せる状態。管理ツールはほかで使っていない値でログインし、使える多要素認証を有効化。端末の画面ロックと、ツールの回復方法も確認済み |
| 新ログイン確認の結果 | 未確認 | 今のログイン状態に左右されない経路から、新しい方法でログインできることを確認 |
| 未移行の残作業 | どのサービスで共用しているかが未整理 | 請求サービス1件を未移行として記録。値の作り直しと認証強化は次の作業 |
業務メールの値を独立させた時点で、請求サービスと値を共用している状態は解けます。ただし、請求サービスのパスワードは以前のままで、管理ツールで生成した独立の値にも置き換わっていません。認証強化と復旧準備も未了のため、請求サービスは未移行として次の作業に残します。過去にどこかへ漏れていた場合、請求サービス側の露出はそのまま残ります。
状態の呼び方は、未移行、保留、移行済みの3つだけです。権限が足りない、方式に対応していない、待機中、新しい方法でまだログインできていないといった場合は、移行済みにせず保留に置きます。移行済みを付けるのは、新ログイン確認が済んだあとだけです。保留のまま放置せず、相談先と次に見る日を一緒に書いておきます。

移行済みと判断できる5つの条件
移行済みと言えるのは、5つの軸が次の状態になったときです。設定を変えた時点ではなく、新しい方法で実際に入れたことを確かめた時点が分かれ目です。
- 使い回しの有無:対象1件のパスワードが、ほかのどのサービスとも違う値になっています。
- 認証強化の設定状態:利用できる2段階認証が有効か、対応と許可と画面ロックの条件を満たしたパスキーが使える状態です。
- 復旧手段と管理ツールの保護:回復用の連絡先で実際に受け取れること、公式の回復導線、設定した方式で必要になる回復手段が準備済みであることを確認しています。バックアップコードを使う場合は、未使用のコードを安全な場所に保管し、必要なときに取り出せる状態にします。管理ツールもほかで使っていない値でログインし、使える多要素認証、端末の画面ロック、入れなくなったときの回復方法を確認しています。コードの値そのものを一覧表へ写しません。
- 新ログイン確認の結果:今のログイン状態に左右されない経路から、新しい方法で実際にログインできています。
- 未移行の残作業:使い回しが残るサービスを名前で書き出し、次に移す1件を決めています。
待機が入る場合は、完了にしません。Googleの2段階認証プロセスの設定案内には、新しく追加した電話番号の確認に最長で7日かかることがあると書かれています。パスキーの案内には、作成したパスキーがログイン時に使えるようになるまで7日ほど待つ場合があると書かれています。どちらも2026年10月28日に確認した記載で、必ずその日数という意味ではありません。待機中は保留のままにして、使えるようになってから新ログイン確認へ進みます。
共有IDをそのまま残した状態も、完了にはしません。個人IDへ分ける相談の結果が出るまでは保留です。1件が移行済みになったら、同じ手順で次の1件へ進みます。業務全体の点検へ広げるときは、業務全体の情報漏えい対策の進め方をあわせて確かめてください。
定期変更は、期限より先に変更する理由を見る
定期変更の扱いは、期限の有無ではなく、変更する理由から見ます。3か月ごとに全員で変える決まりは、やめてよいのでしょうか。自社の決まりを担当者の判断で止めることはできません。やめるかどうかを決めるのは、社内の規則を所管する人です。規則の見直しを待たずに手を付けられるのは、使い回しの解消と認証強化のほうです。
外部の基準の位置づけも押さえます。NISTのSP 800-63Bが定めているのは、認証を提供する側への要件です。利用者へ定期的な変更を一律に求めないよう定める一方、侵害の証拠があるときは変更を強制するよう求めています。米国の基準であり、日本の会社が社員へ課す義務をそのまま示したものではありません。2026年10月28日に確認した記載です。
判断の目安を、場面別に並べます。
| 場面 | 変更の扱い | 先に確かめるもの |
|---|---|---|
| 漏えいの証拠や不審な通知がある | 期限を待たずに変更 | 侵害された認証手段の無効化と管理者への連絡 |
| 使い回しが残っている | 期限を待たずに独立した値へ | 影響の大きい1件の選定 |
| 会社やサービスに変更時期の決まりがある | 決まりに従う | 社内規則とサービス側の条件 |
| 兆候も決まりも見当たらない場合 | 期限だけを理由にした一律変更は対象外 | 使い回しと認証強化の状態 |
表の1行目と4行目は、混同しやすい組み合わせです。期限が来たからと値を変えるときも、新しい値を複数のサービスで共用すれば使い回しは残ります。定期変更と使い回しの対策は別の話なので、先に減らすのは同じ値を使っているサービスの数です。
ログインできないときと、端末を失ったときの戻し方
詰まり方によって、戻る先が変わります。移行の作業と、事故への対応は分けて考えます。向きが逆になる場面があるからです。
- 新しい方法でログインできないとき:移行済みにはせず、保留のまま置きます。今使えているログイン手段は、あわてて閉じないでください。正規の回復手順か管理者を頼り、旧パスワードを使い回しの状態へ戻すことは復旧策にしません。移行済みにしたあとで入れなくなった場合も、同じ扱いで保留へ戻して回復手順をたどります。
- 端末の紛失や漏えいの疑い、心当たりのない認証要求:移行ではなく事故対応です。信頼できる端末から公式の手順と管理者の指示で、失った端末やパスキーのアクセスを止めます。新ログイン確認を待つあいだ、侵害されたアクセスを残しておくことはしません。
- 変更権限がない、方式に対応していない、回復先が使えない:設定を無理に変えません。管理者へ相談し、代わりに使える方式が決まるまで保留に置きます。
端末を失ったときの手当ては、公式の案内に沿って進めてください。Googleの2段階認証プロセスの問題解決の案内には、紛失した端末からログアウトし、パスワードを変更する方法が挙げられています。本人確認の手段として並ぶのは、別の端末、追加済みの別の電話番号、保存済みのバックアップコード、ハードウェアセキュリティキー、別の端末で作ったパスキーです。職場や学校のアカウントでログインできない場合は、管理者への問い合わせも案内されています。2026年10月28日に確認した記載です。
回復の手続きには時間がかかる場合があります。公式の案内に沿って進めても、本人確認が必要なときは即日で戻せるとは限りません。だからこそ、業務で使うメールほど変更前の確認が効いてきます。
バックアップコードを回復手段に使う場合は、変更の前から準備しておく対象です。Googleのバックアップコードの案内には、使ったコードが無効になり、新しいセットを作ると古いセットは自動的に無効になると書かれています。2026年10月28日に確認した記載です。
取得できるかどうかは、公式の設定画面で確かめます。同じ案内には、バックアップコードを使うには2段階認証プロセスを有効にする必要があると書かれています。高度な保護機能プログラムに登録している場合は、バックアップコードをダウンロードできないとも案内されています(2026年10月28日確認)。使えない場合は、公式に案内されている別の回復方法か管理者の窓口を確かめ、分からないままなら保留に置いてください。
すでに発行済みで未使用のコードがあるなら、取り直さずに保管先を決めます。同じ案内では、印刷して重要書類と一緒に保管する例が挙げられています。必要なときに取り出せることを確かめたら、回復手段の準備は完了です。コードの値を一覧表や連絡手段へ写す使い方は避けてください。
まとめ:今日は1件だけ選んで、復旧手段の確認から始める
使い回しを直すときは、全部を一度に変えるのではなく、アカウント1件を移します。サービスごとに独立した値を生成し、使える認証強化を設定し、変更の前に復旧手段を確かめる、という3つのルールをその1件へ当てる形です。5つの軸がそろい、新しい方法で実際にログインできたと確かめた時点で、移行済みになります。
今日できるのは、対象の1件を決めて、回復用の連絡先が今も受け取れるかを確かめるところまでで十分です。受け取れない連絡先が見つかったら、その修復が最初の作業になります。
Q&A
Q1. 会社が管理ツールを用意していない場合は、どう進めればよいですか。
自分の判断で導入せず、使えるツールがあるかを管理者へ確かめてください。決まるまでは、対象1件の認証強化と復旧手段の確認を先に進め、独立した値の生成は保留に置く形が無理のない順番です。秘密の値を自分のメモ帳や表計算ファイルへ書き写す運用は、そのファイルが持ち出されたときに被害が広がります。
Q2. バックアップコードは、保管先を決めておけば準備は済んだことになりますか。
場所を決めるだけでは足りません。発行済みで未使用のコードを実際にその場所へ置き、必要なときに取り出せるかを確かめてください。Googleのバックアップコードの案内では、印刷して重要書類と一緒に保管する例があります。同じ案内によると、利用には2段階認証プロセスの有効化が必要です。高度な保護機能プログラムに登録している場合は、コードをダウンロードできないとも書かれています(2026年10月28日確認)。取得できるかは公式の設定画面で確かめ、使えないときは別の回復方法を管理者と決めるまで保留にします。コードの値は一覧表や連絡手段へ写さず、取り直したときは保管しているものを差し替えます。
Q3. パスキーを作ったら、パスワードは消えるのですか。
消えません。Googleのパスキーの案内では、パスキーを追加してもアカウントに設定されている認証要素や復元要素は変更も削除もされないと説明されています(2026年10月28日確認)。パスキーはパスワードの代わりにログインする方法で、使うと2つ目の手順は省略されるため、確認の段数が必ず増えるわけではありません。既定ではパスキーを先に使う方法へ切り替わる一方、設定でパスワードを先に使う形へ戻せます。自分が管理する端末で画面ロックを設定したうえで作り、共有端末には作らないでください。



