金融システムは、一度の障害が社会的な信用失墜や利用者の資産毀損に直結する「社会基盤」です。 そのため、メガベンチャーのようなスピード感が重視される環境であっても、他業界とは比較にならないほど厳格な品質管理と統制が求められます。 しかし、現場では「チームごとにテスト方針がバラバラ」「膨大なExcel管理が破綻している」「監査対応が形骸化し、現場が疲弊している」といった課題に直面しているQAマネージャーも少なくありません。 QAが開発のボトルネックではなく、事業成長の中核として機能するためには、部分最適から脱却した「全体最適」のテスト管理への転換が不可欠です。 そこで今回は金融システム特有の難しさを踏まえた上で、品質・進捗・網羅性を可視化する具体的な手法や、3ヶ月で体制を立て直すための実践的なロードマップを解説します。 現場の板挟みから脱却し、論理的な根拠をもって品質を証明できる「評価されるテストマネージャー」への第一歩を踏み出しましょう。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テスト管理ツール11製品の完全比較はこちら▼ 【2026年最新】テスト管理ツール11製品の徹底比較！【脱Excel】 なぜ金融システムのテスト管理は難しいのか？ 金融システムにおけるテスト管理が極めて困難とされる背景には、単なる技術的な複雑さ以上に、社会基盤としての重責と厳格な統制が求められるという特殊性があります。 メガベンチャーのようなスピード感が重視される環境であっても、金融領域を扱う以上は一歩のミスが致命的な損失に直結するため、アジリティと安全性の両立に多くのマネージャーが頭を悩ませています。 他業界と違う「3つの厳しさ」 第一の厳しさは、品質要求の水準が他業界とは比較にならないほど高い点にあります。 金融システムにおける障害は単なるサービスの停止に留まらず、利用者の資産毀損や決済の滞留を招き、社会的な信用を瞬時に失墜させます。 そのため、わずかな不具合も許容されないというプレッシャーの中で、精緻な品質設計が求められます。 第二に、監査や規制への対応が必須となる点が挙げられます。 金融機関としての認可や法令遵守の観点から、どのようなテストを実施し、誰が承認したのかという証跡（エビデンス）と、要件からテスト結果までを紐づけるトレーサビリティの確保が不可欠です。 これにより、効率性だけを追求した柔軟な開発手法が制限される場面も少なくありません。 第三に、システムの多重構造という複雑さがあります。 基幹系システムから周辺のサブシステム、さらには外部の決済ネットワークやベンダー提供のモジュールが複雑に連携しており、自社プロダクト単体での検証では不十分です。 複数のステークホルダーやレガシーな仕組みが絡み合う中で、全体を俯瞰したテストを完遂させるには、高度な調整能力と深いドメイン知識が必要とされます。 よくある失敗パターン 多くの現場で陥りがちな失敗の一つに、Excelを用いた進捗管理の破綻があります。 初期段階では手軽で管理しやすいExcelですが、テスト項目数が万単位に膨れ上がり、複数のチームが同時に更新を行うようになると、最新版の判別が困難になります。 結果として、集計作業に追われるマネージャーと現場の実態が乖離し、正確な進捗把握ができなくなります。 また、不具合の影響範囲を正確に追いきれないことも深刻な問題です。 マイクロサービス化が進む中で、一つの修正が予期せぬ場所で連鎖的なエラーを引き起こすリスクが増大しています。 コードの依存関係や業務フローの繋がりを可視化できていないと、場当たり的な修正と再テストを繰り返すことになり、リリース直前に重大な欠陥が発覚する事態を招きます。 さらに、テスト観点の抜け漏れも頻発します。 金融業務特有の複雑な条件分岐や例外処理が網羅されていない場合、本番稼働後のイレギュラーな操作によって大規模障害が発生する恐れがあります。 これに加え、上層部への報告資料はきれいに整えられているものの、実際には未完了のテストや未解決の不具合が放置されているといった、形式的な報告と現場の乖離が組織的なリスクを増大させているケースも少なくありません。 品質事故を防ぐためのテスト管理の全体像 金融システムにおけるテスト管理の本質は、単なるバグ出しの進捗確認ではなく、事業継続を脅かすリスクを最小化し、社内外への説明責任を果たすための統制活動にあります。 メガベンチャーが提供する金融サービスにおいても、一度の品質事故がブランド毀損や法的制裁を招くため、個別の機能検証を超えたマクロな視点での管理が不可欠です。 全体最適を目指すQAマネージャーは、開発スピードを殺さずに、いかにして「品質の確からしさ」を客観的に証明するかに注力する必要があります。 テスト管理で本当に見るべき3つの軸 効果的なテスト管理を実現するためには、品質、進捗、網羅性の3つの軸を定量的かつ多角的に捉える必要があります。 まず品質の軸では、単なる不具合数だけでなく、不具合の発生傾向や重大度の分布に注目します。 特定のマイクロサービスや機能群に致命的な欠陥が集中していないか、あるいは修正後のデグレードが発生していないかを分析することで、リリース判断の重要な指標となります。 次に進捗の軸ですが、これは単にテストケースの消化率を追うだけでは不十分です。 残存しているテストの難易度や、不具合修正待ちによるブロック状況を可視化し、潜在的な遅延リスクを早期に検知することが求められます。 特に複数プロダクトが連動する環境では、他チームの遅れが全体のリリーススケジュールにどう波及するかを予測する視点が欠かせません。 最後に網羅性の軸です。これはビジネス要件や非機能要件が、漏れなくテストケースに反映されているかを確認するものです。 複雑な金融ロジックや例外系シナリオがカバーされているかを担保することで、場当たり的なテストから脱却し、根拠のある品質保証が可能になります。 金融システムで重要な「トレーサビリティ」とは 金融業界のテスト管理において最も特徴的であり、かつ厳格に求められるのがトレーサビリティ（追跡可能性）の概念です。 これは、定義された要件、作成されたテストケース、そして発生した不具合の三者が、常に双方向に紐づいている状態を指します。 要件の変更があった際に、どのテストケースを修正すべきか、あるいは特定の不具合がどの業務要件に影響を与えるかを即座に特定できる体制が理想です。 また、監査対応の観点からもこのトレーサビリティは決定的な意味を持ちます。 外部の監査法人や規制当局に対して、システムが意図した通りに動くことを、いつ、誰が、どのようなエビデンス（証跡）をもって確認したのかを、後から客観的に証明しなければなりません。 テスト実行時のスクリーンショットやログ、承認ワークフローの記録など、単なる「実施済み」という報告を超えた、改ざん不能な証跡の管理が金融システムには求められます。 テスト管理の全体フロー 持続可能な品質体制を築くためには、テスト管理を計画、設計、実行、報告、改善という一連のライフサイクルとして捉え、各工程での管理ポイントを明確にする必要があります。 計画段階では、リスクベースのアプローチを取り、どの機能にリソースを重点配分するかを決定します。 ここで品質目標を開発・PdMと合意しておくことが、後の合意形成をスムーズにします。 設計から実行のフェーズでは、テストケースの粒度を揃え、実行結果をリアルタイムで集計できる仕組みを整えます。 属人化を防ぐため、誰が担当しても同じ結果が得られるような手順の標準化が重要です。 報告フェーズでは、現場の泥臭い進捗と経営層が求める意思決定材料を繋ぎ合わせ、現在のリスクを正しく伝えることに集中します。 そして最後の改善フェーズでは、今回のテストで見えた組織的な課題や不具合の根本原因を分析し、次期開発のプロセス改善へとフィードバックします。 このサイクルを回し続けることで、QAは単なるチェック機能から、プロダクトの価値を最大化する中核へと進化します。 現場で使えるテスト管理の具体手法 金融システムのQAマネジメントにおいて、理論を現場の運用に落とし込むプロセスは最も困難な障壁の一つです。 特にメガベンチャーのようなスピード感が求められる環境では、ガチガチの管理ルールは開発を阻害し、逆に緩すぎる管理は致命的な事故を招きます。 ここでは、全体最適を実現しつつ、現場の負担を最小限に抑えながら品質を担保するための、より具体的かつ実践的な手法を紐解いていきます。 脱Excelの第一歩：管理方法の見直し 多くの現場で慣習的に使われているExcel管理ですが、金融システム特有の膨大なテスト項目や頻繁な要件変更に対しては、すでに限界を迎えています。 Excelには同時編集によるデータの競合、履歴管理の難しさ、そして何より複雑な集計作業が属人化しやすいという大きなリスクが潜んでいます。 管理ファイルが肥大化し、ファイルを開くだけで時間がかかるような状態は、すでに管理が破綻しているサインと言えるでしょう。 これを打破するためには、専用のテスト管理ツールを導入するか、既存のワークフローを抜本的に再整備するかの判断が必要です。 判断の基準としては、対象となるプロダクトの寿命やチームの規模感が重要になります。 長期的な保守運用が見込まれ、複数チームが横断的に関わる金融システムであれば、初期コストを払ってでもツール導入による「情報の透明化」を優先すべきです。 一方で、ツールの導入が難しい場合でも、スプレッドシートの関数を駆使するのではなく、情報の入力規則を厳格化し、データソースを一元化するルール整備から着手することが、脱Excelの第一歩となります。 進捗と品質を見える化する方法 マネージャーが現場の板挟みから解放されるためには、主観を排除した定量的なデータによる「見える化」が欠かせません。 ダッシュボードで常に監視すべき指標は、主にテスト消化率、不具合検出率、そして残課題数の3点です。 テスト消化率は単なる進捗だけでなく、予定との乖離を早期に検知するために使います。 不具合検出率は、テストの密度が十分か、あるいは特定の機能に欠陥が集中していないかを図る品質のバロメーターとなります。 これらの指標を共有する際は、ステークホルダー別に「見せ方」を変える工夫が必要です。 例えば、経営層やPdMに対しては、細かいバグの数よりも「現在の品質状況がリリース判断の基準をクリアしているか」というリスクベースの要約を提示します。 対して開発現場には、どのモジュールに課題が集中しているか、ブロックされているテストはどれかといった、即座にアクションに繋がる詳細なデータを共有します。 このように、相手が必要とする粒度に情報を加工して提示することで、品質に関する議論が建設的なものへと変わります。 不具合管理を強化するポイント 不具合管理の質を向上させるためには、まず重大度と優先度の定義を組織全体で統一することが重要です。 金融システムでは「データ整合性に影響があるか」「資金決済が停止するか」といった明確な基準を設け、個人の感覚による判断のブレを排除しなければなりません。 これが曖昧だと、修正の優先順位付けで開発チームとQAの間で不必要な摩擦が生じる原因となります。 また、単に不具合を修正して終わりにするのではなく、原因分析と再発防止の仕組み化をセットで行う必要があります。 特に「なぜテスト工程で漏れたのか」というプロセス面での振り返りを定例化し、根本原因（Root Cause）を分類・集計することで、将来的なテスト設計の改善に繋げます。 不具合を「責める材料」ではなく「プロセス改善のヒント」として扱う文化を醸成することが、持続可能な品質体制を築く鍵となります。 多ベンダー環境での管理のコツ 複数のベンダーやチームが混在する環境では、責任の所在が曖昧になりがちです。 これを防ぐためには、まずテストの共通ルールを策定し、全ての関係者が同じ品質基準、同じ報告フォーマットで動くよう強制力を持たせることが不可欠です。 各社が独自の管理手法を持ち込むと、全体の品質状況を統合して把握することが不可能になります。 定例会議においても、単に進捗を確認するだけでなく「境界領域のテスト責任」や「環境の競合状況」など、チーム間でのこぼれ落ちが発生しやすい項目を重点的に確認します。 責任の曖昧さをなくす設計として、RACIチャート（実行責任者、説明責任者、協議先、通知先）などを用いて、不具合発生時の対応フローや最終的な品質承認の責任者を明確に定義しておくべきです。 これにより、トラブル発生時の押し付け合いを防ぎ、組織として一貫した品質保証が可能になります。 監査・コンプライアンスに強いテスト管理の作り方 金融サービスを扱うメガベンチャーにおいて、QAマネージャーが直面する最大の壁の一つが監査対応です。 一般的なWebサービスではスピードが最優先されますが、金融システムでは「正しく動くこと」と同じくらい「正しく検証されたことを証明できること」が重視されます。 監査に強い体制を構築することは、単なる事務作業の強化ではなく、万が一の障害時に会社を守る防波堤を築く行為です。 経営層や規制当局に対し、論理的な根拠をもって品質を説明できる仕組みが、QA組織の信頼性を決定づけます。 監査で見られるポイント 監査において最も厳格にチェックされるのは、テストの網羅性です。 これは単にテストをたくさん実施したかではなく、定義されたビジネス要件やセキュリティ要件が、漏れなくテストケースとして展開され、そのすべてが実行されたかという「紐付け」が問われます。 要件定義書からテスト結果までが一気通貫で追跡できるトレーサビリティが、網羅性を証明する唯一の手段となります。 次に重視されるのが証跡の一貫性です。 テスト結果のステータスが「合格」となっていても、それを裏付ける実行ログやスクリーンショット、あるいはデータベースの更新結果などの客観的な証拠が揃っていなければ、検証は完了したとはみなされません。 最後に、承認プロセスの記録も不可欠です。 誰がテスト計画を承認し、誰が最終的なリリース判定を下したのかというワークフローの履歴は、内部統制の観点から非常に厳しく確認されます。 監査に耐えるドキュメント設計 監査に耐えうるテスト計画書や結果報告書を作成するためには、「後から説明できる」状態を逆算して設計する必要があります。 計画書においては、テストの範囲だけでなく「何をテストしないか（デスコープ）」とその理由を明文化しておくことが重要です。 これにより、監査人から特定の項目について問われた際も、リスクベースでの判断であったことを論理的に説明できます。 結果報告書では、単なるサマリーだけでなく、発生した不具合の対応履歴や、未修正のままリリースする判断を下した不具合の妥当性を記録に残します。 特に金融システムでは、既知の不具合を抱えたままリリースする場合の回避策や、運用でのカバー体制が明確であるかが注視されます。 これらをドキュメントのテンプレートに組み込み、属人的な判断が入り込まないフォーマットを構築しておくことで、いつ誰が監査を受けても一貫した回答が可能になります。 現場負担を増やさないコツ 厳格な管理は現場の疲弊を招きやすく、結果として形骸化するリスクを孕んでいます。 これを防ぐためには、可能な限り自動記録の仕組みを導入し、手動での証跡作成を減らす工夫が求められます。 例えば、CI/CDパイプラインとテスト管理ツールを連携させ、自動テストの結果や実行ログが直接テストケースに紐付くように設計します。 これにより、エンジニアは本来のテスト活動に集中でき、管理者は自動的に生成された証跡を確認するだけで済むようになります。 また、二重管理を防ぐ設計も極めて重要です。 開発チケット、テスト管理ツール、監査用ドキュメントがバラバラに存在していると、情報の転記ミスや更新漏れが必ず発生します。 一つのツールを真実のソース（Source of Truth）として定め、そこから各ドキュメントが自動出力される、あるいはリンク参照で完結する仕組みを作るべきです。 現場のフローに自然と監査対応が組み込まれている状態を目指すことで、アジリティを損なわずに強固なコンプライアンス体制を実現できます。 3ヶ月で立て直すテスト管理改善ロードマップ 急成長を続けるメガベンチャーにおいて、バラバラになったテスト方針を統合し、全体最適化された管理体制を構築するのは容易ではありません。 しかし、四半期という区切りの中で着実なステップを踏めば、現場の混乱を抑えつつ経営層が納得する品質水準へと引き上げることが可能です。 現場と上層部の板挟みに遭いやすいマネージャーにとって、この3ヶ月のロードマップは、自身の判断が正しい方向を向いているという確信を得るための道標となります。 Step1（1ヶ月目）：現状把握と課題の見える化 最初の1ヶ月は、まず各チームやプロダクトに分散している品質の現状を徹底的に棚卸しすることに専念します。 金融システムという性質上、わずかな認識の乖離が致命的な障害に繋がるため、現在の進捗管理方法、不具合の定義、テスト実行の承認フロー、そしてそれらを支える人員体制の実態を可視化します。 各チームがどのような基準で「品質が担保された」と判断しているのかをヒアリングし、共通言語が欠如している箇所を特定することが重要です。 このプロセスを通じて、現状の進捗・品質・体制における問題点をリストアップし、最優先で改善すべきポイントを絞り込みます。 例えば、特定のマイクロサービスでデグレードが頻発している、あるいは監査証跡が不十分でコンプライアンスリスクが高いなど、ビジネスインパクトが大きく、かつ早急に対処が必要な領域を明確にします。 この段階で「何がボトルネックか」をデータに基づいて説明できるようにしておくことが、次ステップでの合意形成を支える土台となります。 Step2（2ヶ月目）：ルールと仕組みの整備 2ヶ月目は、特定した課題を解決するための共通ルールを策定し、組織横断で機能する仕組みを構築します。 まず着手すべきは、テスト管理ルールの統一です。 金融システムとして最低限遵守すべきテスト観点や、不具合の重大度、ステータス遷移の定義を標準化します。 これにより、別々のチームが開発していても、同じ品質の物差しで評価ができる状態を目指します。 同時に、要件とテストケース、そして不具合を紐付けるトレーサビリティの確立を急ぎます。 これは監査対応のためだけではなく、仕様変更時の影響範囲特定を迅速化し、テスト漏れによる手戻りを防ぐための実務的な防衛策でもあります。 さらに、会議体やレポートラインの改善も行います。 週次での進捗報告を形骸化させず、リスクを早期に共有できるフォーマットへ刷新することで、ステークホルダーとの意思疎通を円滑にします。 現場の負担を最小限に抑えつつ、必要な証跡が自然と蓄積されるフローを設計することが、成功の鍵を握ります。 Step3（3ヶ月目）：運用定着と改善サイクル 最終段階となる3ヶ月目は、整備した仕組みを定着させ、自律的に品質が向上していくサイクルを回し始めます。 策定したKPI（テスト消化率、不具合検出密度、修正までのリードタイムなど）を用いて継続的なモニタリングを行い、目標値から乖離した際の迅速なフォロー体制を確立します。 この数値管理によって、QAの取り組みがプロダクトの安定性とリリーススピードの両立にどれほど寄与しているかを、経営層に対しても説得力を持って提示できるようになります。 また、各リリースの節目で振り返りを実施し、不具合の根本原因分析を組織の知見として蓄積するプロセスを習慣化します。 これにより、特定の担当者に依存していたテスト設計や判断が標準化され、属人化からの脱却が進みます。 この3ヶ月を経て、QAが単なる「リリースのブレーキ」ではなく、事業成長を持続可能にする「品質の司令塔」として認識されるようになれば、マネージャーとしての社内評価と市場価値は自ずと高まっていくはずです。 評価されるテストマネージャーになるために必要な視点 金融システムのQAマネージャーとして、単なる「テストの実行責任者」に留まらず、組織全体の価値を最大化するリーダーとして評価されるためには、技術的な卓越性以上に、多角的な視点とバランス感覚が求められます。 特にメガベンチャーのような変化の激しい環境では、現場のエンジニア、プロダクトマネージャー、そして経営層のそれぞれが求める「品質」の定義を汲み取り、それらを一つの戦略に統合する力が、マネージャーとしての真価を決定づけます。 現場視点と経営視点の両立 現場のエンジニアは「技術的な完璧さ」や「不具合ゼロ」を追求しがちですが、経営層は「市場への投入スピード」や「投資対効果」を最優先に考えます。 この相反するニーズの間で、品質と納期の最適なバランスを見出すことこそが、評価されるマネージャーの役割です。 金融システムにおいては、一度の障害が事業継続を脅かすため、決して「スピードのために品質を犠牲にする」ことは許されません。 しかし、過度な検証はリリースの遅延を招き、機会損失を引き起こします。 そこで必要となるのが、リスクベースのアプローチです。 システムのどの機能がビジネス上最も重要で、どこに障害が発生した際の影響が大きいかを分析し、リソースを重点的に配分する判断を下します。 現場に対しては「なぜこのテストが必要か」という論理的な裏付けを示し、経営層に対しては「どの程度のリスクを許容し、どのようなガードレールを敷いているか」を説明することで、双方の納得感を得ながらプロジェクトを推進することができます。 説明できるテスト管理へ 信頼を構築するためには、感覚的な「大丈夫です」という報告を排除し、数値と根拠で語る力を磨かなければなりません。 金融業界におけるステークホルダーは、不確実性を最も嫌います。 そのため、テスト消化率や不具合検出数といった基本指標に加え、過去のリリース時と比較した不具合密度の推移や、残存リスクがビジネスに与える具体的な影響度を定量的に示す必要があります。 こうしたデータに基づいた報告を継続することで、PdMや経営層との間に「品質に関する共通言語」が生まれます。 品質の問題が発生した際も、単なるトラブル報告ではなく、客観的な事実に基づいた「意思決定の材料」として提示できるようになれば、QAはボトルネックではなく、事業の確実性を高めるパートナーとして認識されます。 ステークホルダーとの信頼関係は、こうした「予測可能性」の積み重ねによってのみ強固なものとなります。 次のキャリアにつながるスキル 将来的にQAディレクターやVPoQAといった上位職を目指す、あるいは市場価値の高い人材として自立するためには、目の前のプロジェクトを完遂させる力に加え、標準化と仕組み化の経験が不可欠です。 金融システムのような複雑な領域で、属人化を排除し、誰が担当しても一定の品質を担保できる「持続可能なテスト体制」を構築した実績は、あらゆる組織で高く評価されます。 特に、複数プロダクトやマイクロサービスが混在するメガベンチャー規模において、組織横断での品質改善をリードした経験は、希少性の高いスキルとなります。 各チームの個別の事情を尊重しつつ、組織全体の生産性を底上げするための共通基盤や品質基準を策定し、それを現場に浸透させていくプロセスは、高度なファシリテーション能力と戦略的思考を証明するものです。 こうした「仕組みで品質を作る」経験を積み重ねることで、キャリアの選択肢は大きく広がり、組織内外から不可欠な存在として認められるようになります。 まとめ 金融システムにおけるテスト管理は、単なるバグ出しの工程ではなく、事業の信頼性を担保し、社会的な責任を果たすための重要な統制活動です。 アジリティと安全性の両立という難題を解決するためには、以下の3点が鍵となります。 数値と根拠に基づく見える化： 主観を排除し、定量的な指標でリスクを語る。 トレーサビリティの確立： 要件、テスト、不具合を一気通貫で管理し、監査に耐えうる証跡を自動的に蓄積する。 組織横断の仕組み化： 属人化を排除し、多ベンダー・多チーム環境でも一貫した品質を担保するルールを定着させる。 今回ご紹介した3ヶ月のロードマップに沿って、まずは現状の課題を可視化することから始めてみてください！ QAマネージャーが「現場視点」と「経営視点」を両立させ、仕組みで品質を作る力を証明できれば、QA組織は価値創出の中核として、より強固な信頼を勝ち取ることができるはずです。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

Azure Storageの共有アクセス署名（SAS）は、キーを共有せずリソースへのアクセス許可を限定的に発行する仕組みです。操作、期間、IPアドレス、プロトコルを制限でき、アカウントSAS、サービスSAS、ユーザー委任SASの3種類があります。セキュリティのため、有効期限の短期化や最小限の権限設定などのベストプラクティスが推奨されます。

Google アカウントでは、2段階認証として登録した携帯電話の番号が使えなくなったなどの理由で、アカウントからロックアウトされてしまう場合があります。当記事では、アカウントにログインできなくなった場合の解決策と復旧手順を解説します。 アカウントからのロックアウト 別の方法を試す 管理者による対応（Google Workspace の場合） アカウント復旧プロセス（個人アカウントの場合） アカウントからのロックアウト Google アカウントの2段階認証（2要素認証）では、パスワードの入力後に、登録した電話番号への SMS 送信やワンタイムパスワード、またはモバイルアプリへの通知などによって本人確認を行います。 しかし、以下のような理由で2段階目の認証を通過できなくなることがあります。 機種変更や解約により、電話番号が使えなくなった （Google Workspace の場合）アカウントの初期作成後に、2段階認証の登録の猶予期間を過ぎてもユーザーが2段階認証を設定しなかった このような場合には、複数の復旧経路が用意されています。 別の方法を試す ログイン画面でコードの入力を求められた際、まず確認すべきなのが画面下部にある「 別の方法を試す 」または「 ログインできない場合 」というリンクです。 Google は、メインの電話番号が利用できない場合に備え、複数の認証パスを提示することがあります。以下の選択肢が表示されるかを確認してください。 選択肢 操作 信頼済みのデバイス すでにログイン済みの PC やタブレットで「はい」を押す 再設定用メールアドレス 予備として登録した別のアドレスにコードを送信する バックアップコード 事前に保存していた（あるいは管理者から発行される）8桁の使い捨てコードを入力する 参考 : 2 段階認証プロセスに関する一般的な問題を修正する これらの対処手段を使うには、予め Google アカウントに複数の2段階認証手段やメールアドレス、信頼済みデバイスが登録してあること、あるいはバックアップコードが発行済みであることが前提です。 管理者による対応（Google Workspace の場合） 使用しているアカウントが組織向けの Google Workspace アカウントである場合は、組織の特権管理者が管理コンソールから以下の操作を行うことで、ログインさせることができます。 操作 説明 2 段階認証の一時的な無効化 管理者が、2段階認証の設定をオフにした 設定グループ を作成して対象アカウントを一時的に移動するなどする バックアップコードの発行 管理者が8桁の使い捨てコードを管理画面で生成してユーザーに伝える 参考 : 組織によって 2 段階認証プロセスが適用されている場合にアカウントがロックされるのを回避する 参考 : ユーザーのセキュリティ設定を管理する - ユーザーのバックアップ確認コードを取得する 2段階認証を必須している Google Workspace 組織では、新しいユーザー作成直後に2段階認証を設定していなくてもログインできる猶予期間（ 新しいユーザーの登録期間 ）を設定できます。この期間のうちにユーザーが2段階認証をセットアップしないと、アカウントからロックアウトされてしまいます。このようなときにも、上記のような対処が取れます。 アカウント復旧プロセス（個人アカウントの場合） Google Workspace アカウントではなく、個人アカウントの場合、最終手段として アカウント復旧 （Account Recovery）の手続きを行います。 Google アカウント復旧ページ（ https://accounts.google.com/signin/recovery ）にアクセス 復旧したいメールアドレスを入力 画面の指示に従い、本人確認のための質問に回答 このプロセスでは、Google のシステムが「操作している人物が真の所有者であるか」を多角的に判断します。電話番号が間違っていても、過去に使用したパスワードや再設定用メールアドレスの有無によって、復旧が認められる場合があります。 なおアカウント復旧を成功させるためには、Google が所有者を特定しやすい環境で操作することが重要です。 環境 説明 普段と同じ場所 自宅や職場など、いつもログインしている Wi-Fi ネットワークを利用する 普段と同じデバイス 以前そのアカウントでログインに成功したことがある PC やスマートフォンを使用する ブラウザの利用 普段から使い慣れているブラウザ（Chrome など）を使用する 参考 : Google アカウントや Gmail を復元する方法 参考 : アカウント復元手順を完了するためのヒント G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、2021年よりクラウドの導入から最適化までを支援しているGoogle Cloud専業のクラウドインテグレーターです。