公開日：2026年4月12日
Google共有アカウントの認証コードが届かない！複数人で受け取る仕組みをGASで解決
「ちょっとログインしたいだけなのに、認証コードが○○さんのスマホに届くから毎回聞かないといけない」——共有のGoogleアカウントを使っている職場なら、誰もが一度はぶつかる問題です。
業務別に分けられたGoogleアカウントを複数人で使い回すケースは、中小企業やチーム運用の現場では珍しくありません。ところが2段階認証が有効になっていると、ログインのたびに特定の人のスマホに確認が飛び、その人が席を外していたら仕事が止まる。かといって2段階認証をオフにすれば解決するかというと、実はそう単純でもありません。
この記事では、共有アカウントで認証コードの属人化が起きる原因を整理したうえで、複数人で認証を突破できるようにする3つの方法を解説します。
共有アカウントで2段階認証が厄介になる理由
Googleアカウントはそもそも1人が1アカウントを使う前提で設計されています。複数人で1つのアカウントを共有すると、Googleのシステムが「いつもと違う場所・端末からのログイン」と判断し、本人確認を求めてきます。
この本人確認の方法がくせもので、いくつかのパターンがあります。
パターン1：「ログインしようとしていますか？」の確認プロンプト。アカウントにログイン済みのスマホ（GoogleアプリやGmail）に「はい／いいえ」の確認通知が届きます。通知が届くのは、そのアカウントでログインしている端末だけなので、管理者や最初の設定者のスマホに操作が集中します。
パターン2：番号の一致確認（追加ステップ）。位置情報やデバイスが普段と大きく異なるとGoogleが判断した場合、パターン1に加えてPC画面に表示される数字とスマホに表示される候補から同じ番号を選ぶステップが追加されます。これは不審度が高いログインにのみ出現するため、同じオフィスから使っている限りは表示されないことも多いです。
パターン3：電話番号へのSMS送信。アカウントに登録された電話番号にSMSで確認コードが届きます。電話番号は基本的に1つしか登録できないため、やはり特定の1人にしか届きません。
どのパターンでも、結局「その人に聞く」「その人のスマホを操作してもらう」という運用になり、属人化が避けられない構造になっています。
「2段階認証をオフにすれば？」——逆に選択肢が減る罠
ここで「じゃあ2段階認証をオフにすれば、確認プロンプトもSMSもなくなるのでは？」と考える方がいるかもしれません。実はこれが落とし穴です。
2段階認証をオフにしても、Googleは不審なログインを検知すると独自に本人確認を要求してきます。そしてこのとき使える認証手段が、ログイン済み端末への確認プロンプト（「ログインしようとしていますか？」）だけに限定されるケースが多いのです。
2段階認証をオンにしている場合は、次のような手段が選択肢として使えます。
- SMSまたは音声通話での確認コード
- Google Authenticator（認証アプリ）のワンタイムパスワード
- バックアップコード（事前に発行した8桁の使い捨てコード）
- セキュリティキー（物理デバイス）
つまり、2段階認証をオフにすると、むしろ認証の選択肢が狭まり、管理者のスマホへの依存度が上がります。共有アカウント運用においては、2段階認証はオンにしたうえで、複数の認証手段を設定しておく方が柔軟に対処できます。
複数人で認証コードを受け取る3つの方法
2段階認証をオンにしたうえで、特定の1人に依存しない運用を実現する方法は主に3つあります。
方法1：Google Authenticatorを複数端末に登録する
2段階認証の設定画面で認証アプリ（Google Authenticator）を追加する際、QRコードが表示されます。このQRコードを表示している間に、複数人のスマホで同時に読み取ることで、全員の端末にワンタイムパスワードが生成されるようになります。
注意点として、「次へ」を押してQRコードの画面を閉じると同じQRコードは二度と表示されません。必ず全員分のスマホを手元に揃えてから操作してください。
この方法は最も手軽ですが、メンバーの入れ替わりがあると再設定が必要になる点と、全員がAuthenticatorアプリをインストールする必要がある点がデメリットです。
方法2：GAS×チャットツールで認証コードをオンデマンド生成する
Google Apps Script（GAS）に認証アプリと同じシークレットキーを登録し、チャットツール上のキーワードをトリガーにしてワンタイムパスワードを自動生成・投稿する方法です。
仕組みとしては次のような流れになります。
- 2段階認証で認証アプリ（Google Authenticator）を設定する際に表示されるシークレットキーを控える
- そのシークレットキーをGASのスクリプトプロパティに保存
- GASをウェブアプリとしてデプロイし、発行されたURLをチャットツール（Chatwork等）のWebhookに登録
- チャットルームにメッセージが投稿されると、チャットツールがGASにリクエストを送信
- GASがメッセージ内のキーワードを判定し、一致すればTOTPアルゴリズムで6桁のワンタイムパスワードを生成
- 生成したコードを同じチャットルームに投稿
つまり、GAS自体がAuthenticatorアプリと同じ役割を果たします。誰かがログインしたいときにチャットで合言葉を送るだけで、認証コードがチャットルームにリアルタイムで表示される仕組みです。時間トリガーによるポーリングではなくWebhookによるイベント駆動なので、遅延もほぼありません。
この方法の詳しい設定手順とサンプルコードは、noteの実装ガイドで公開しています。
方法3：バックアップコードを共有管理する
Googleアカウントの2段階認証設定から、10個のバックアップコード（8桁）を事前に発行できます。このコードは1回限り有効で、認証アプリやSMSが使えないときの緊急手段として機能します。
発行したコードをパスワードマネージャーや社内の共有金庫（暗号化されたファイル等）で管理しておけば、管理者が不在でもログインできます。
ただし、コードは使い切ったら再発行が必要なことと、コードの管理自体がセキュリティリスクになりうることには注意が必要です。あくまで緊急時の補助手段として位置づけましょう。
GAS×チャットツール通知の仕組み（概念解説）
方法2で紹介したGASによるコード生成について、もう少し詳しく構成を説明します。
全体のアーキテクチャ
処理の流れはシンプルです。
- Webhook受信：チャットルームにメッセージが投稿されると、チャットツールのWebhookがGAS（ウェブアプリとしてデプロイ済み）にPOSTリクエストを送信
- キーワード判定：GASの
doPost(e)関数がリクエストを受け取り、メッセージ内に特定のキーワード（合言葉）が含まれているかチェック - コード生成：キーワードが一致したら、保存済みのシークレットキーからTOTPアルゴリズムで6桁のワンタイムパスワードを算出
- 投稿：生成したコードをチャットツールのAPIで同じルームに投稿
ポイントは2つあります。1つ目は、GASがAuthenticatorアプリと同じTOTPアルゴリズム（HMAC-SHA1ベース、30秒ごとにコード更新）を実装している点。GmailやSMSを経由する必要がなく、シークレットキーさえあればGAS上でコードが完結します。
2つ目は、Webhookによるイベント駆動である点。時間トリガーで定期的にメッセージを取りに行くポーリング方式と違い、メッセージが投稿された瞬間にGASが起動するため、遅延がほぼなく、GASの実行回数制限にも優しい構造です。
外部サービス（Chatwork等）への通知にはAPIトークンが必要ですが、GASのスクリプトプロパティ（PropertiesService）に保存することで、コード上にハードコードせずに管理できます。シークレットキーも同様にプロパティに格納します。
スクリプトプロパティに保存する値は主に3つです。
- チャットツールのAPIトークン：チャットツールの管理画面から発行します。なお、Chatworkの場合はAPIトークンの発行に組織管理者の承認が必要です
- ルームID：認証コードを投稿するチャットルームのID
- TOTPシークレットキー：2段階認証で認証アプリを登録する際、QRコードの下に表示される「QRコードを読み取れない場合」のテキスト文字列がこれに該当します
なお、GASを実行するアカウント（APIトークンの発行元）にはBot専用のチャットアカウントを用意してください。Webhookはルーム内の全メッセージに対して発火するため、GASが投稿したメッセージでWebhookが再度発火し、それを受けてGASがまた投稿する——という無限ループが発生します。コード内で「送信者が自分自身なら処理をスキップする」制御を入れていますが、そもそもBot専用アカウントを分けておくのが安全です。
なぜこの方法が現実的なのか
SSOやIDaaS（月額100〜300円/人）を導入すれば認証の一元管理は実現できますが、5人以下のチームでは費用対効果が合わないことが多いです。GAS + チャットツールAPIはどちらも無料枠で運用でき、既存のGoogle Workspace環境に追加コストなしで導入できるのが最大のメリットです。
サンプルコードと具体的な設定手順はnoteの実装ガイドで公開しています。
セキュリティリスクと注意点
この仕組みは便利ですが、セキュリティ上のトレードオフがあることを正直に書いておきます。
2段階認証の意味が弱まる。2FAは「本人しか持っていないデバイス」で認証する仕組みです。認証コードをチャットルームに流すということは、その「第2要素」をチーム全員で共有することになり、2FAとしてのセキュリティ強度は下がります。
シークレットキーの保管リスク。TOTPのシークレットキーをGASのスクリプトプロパティに格納している以上、GASプロジェクトの編集権限を持つユーザーからはシークレットキーを閲覧できます。編集権限の範囲は最小限に絞り、不要になったら速やかに削除してください。
チャットログへのコード残留。生成されたワンタイムパスワードはチャットルームにテキストとして投稿されるため、チャットツール側のログに残ります。コード自体は30秒で無効になりますが、チャットルームのアクセス権限管理は慎重に行ってください。
Googleのポリシーとの関係。Googleはアカウントの共有利用を推奨しておらず、共有アカウントからの不審なログインが繰り返されるとアカウントがロックされるリスクがあります。この仕組みはあくまで「現状の運用を少しでも安全に回す」ための妥協案であり、ベストプラクティスではありません。
APIトークンの管理。チャットツールのAPIトークンも、シークレットキーと同様にGASのスクリプトプロパティ（PropertiesService）に格納し、コード上にはベタ書きしないでください。
SSOという正攻法
ここまで紹介した方法は、いずれも「共有アカウントを使い続ける前提」での対処法です。本来の正攻法は、アカウントの共有をやめて1人1アカウントに移行し、必要に応じてSSO（シングルサインオン）を導入することです。
Google Workspace自体にもSSO機能は備わっていますし、外部のSSO製品（CloudGate UNO、HENNGE One、Okta等）を使えば、1回のログインで複数サービスにアクセスでき、2段階認証の管理も一元化できます。
ただし、SSO製品の費用は月額100〜300円/人が相場で、これに加えてGoogle Workspace自体のライセンス費用もかかります。5人以下の小規模チームや、そもそもIT専任者がいない組織では、導入・運用のハードルが高いのが現実です。
判断の目安としては、チームが10人を超えるか、扱う情報の機密性が高い場合はSSOを検討すべきです。それ以下の規模であれば、Authenticatorの複数端末登録やバックアップコードの共有管理で当面は運用できます。GASによる通知は、その中間にある「SSOまでは要らないが、毎回人に聞くのは非効率」という層に向けた選択肢です。
まとめ
共有Googleアカウントの2段階認証が属人化する問題には、段階的な解決策があります。
まず試すべきは、2段階認証をオンにしてGoogle Authenticatorを複数端末に登録すること。これだけで「毎回○○さんに聞く」問題の大部分は解消します。それでもメンバーの入れ替わりが頻繁だったり、全員にアプリを入れてもらうのが難しい場合は、GAS×チャットツールによるワンタイムパスワードのオンデマンド生成が有効です。そしてチーム規模が大きくなったら、SSOの導入を検討するフェーズに入ります。
大事なのは、2段階認証を「面倒だからオフにする」のではなく、オンにしたまま運用を工夫すること。認証の選択肢を増やしておくことが、セキュリティと利便性を両立させる第一歩です。
よくある質問
Q. 共有Googleアカウントで認証コードが自分に届かないのはなぜ？
2段階認証のSMSは登録された1つの電話番号にしか届きません。また「ログインしようとしていますか？」の確認プロンプトは、そのアカウントでログイン済みの端末にしか表示されません。共有アカウントでは、最初に設定した人の端末に集中するのが原因です。
Q. 2段階認証をオフにすれば共有アカウントにログインしやすくなりますか？
逆効果になる場合があります。2段階認証がオフでも、Googleは不審なログインを検知すると独自の本人確認を要求します。このとき使える手段がログイン済み端末への確認プロンプトに限定されることが多く、認証手段の選択肢がむしろ減ります。
Q. Google Authenticatorを複数人のスマホに入れられますか？
はい。認証アプリの設定時に表示されるQRコードを、複数のスマホで同時に読み取ることで全員の端末にワンタイムパスワードが生成されます。ただしQRコードは一度閉じると再表示されないため、全員分のスマホを揃えてから操作してください。
Q. GASで認証コードを生成するのにコストはかかりますか？
GASはGoogle Workspaceに含まれる無料のスクリプト実行環境です。チャットツール（ChatworkやSlack）のAPIも無料枠の範囲で利用できるため、追加コストなしで構築できます。GAS上でTOTPアルゴリズムを実装するため、外部の有料サービスも不要です。
Q. 中小企業でSSO（シングルサインオン）は必要ですか？
チーム規模が10人を超える場合や、機密性の高い情報を扱う場合はSSOの導入を推奨します。5人以下の小規模チームでは、Google Authenticatorの複数端末登録やバックアップコードの共有管理で十分対応できることが多いです。
Q. この方法にセキュリティリスクはありますか？
あります。認証コードをチャットツールに投稿すると、2段階認証の「本人だけが持つ要素」が共有財になるため、セキュリティ強度は下がります。また、TOTPのシークレットキーをGASに保管するため、GASプロジェクトの編集権限管理やチャットルームのアクセス制御を適切に行う必要があります。リスクを理解したうえで運用してください。
開発者ノート
この記事で紹介したGAS×チャットツールの仕組みは、実際に筆者が現場で運用しているものがベースです。業務別に分けられたGoogle Workspaceのアカウントを複数人で共有しており、2段階認証の電話番号認証を毎回役員に確認する運用が非効率だったため、GASでTOTPコードを生成してChatworkに投稿するBotを構築しました。
チャットルームで合言葉を打つだけでワンタイムパスワードが返ってくるので、管理者の手を煩わせることなくログインできます。シークレットキーやAPIトークンはGASのPropertiesServiceに格納しているため、コードからの外部流出リスクは低いです。ただし、GASプロジェクトの編集権限管理とチャットルームのアクセス制御は適切に行う必要があります。
SSOを導入するほどの規模ではない現場向けの、現実的な妥協案として共有します。
— nor（キュリズムラボ運営）
関連リンク
- GAS×チャットツールによる認証コード自動生成の実装ガイド（note） — サンプルコードと設定手順
