SIGNALでGoogle再接続を繰り返し求められる問題に、私たちがどう対応したか

2026年10月、Netsujo株式会社が開発・運営する「Netsujo SIGNAL」に、ログインし直すたびにGoogleとの再接続を求められるという顧客からの申告が届きました。SIGNALは、Webサイトの状況を把握し、改善を進めるためのサービスです。Google Analytics 4（GA4）やSearch Consoleとの連携で何度も操作を求められれば、顧客は本来進めたい分析や改善へ進みにくくなります。

私たちはこの申告を自社プロダクトの問題として引き受け、症状を切り分け、コード上の不備を3つ修正し、本番環境で再ログイン後も計測データを取得できることを確認しました。修正したコードの数より、顧客が仕事を再開できる状態を何で判断するかが、この対応の焦点でした。

私たちは自社製品の障害対応で得た知見を、顧客の現場で製品と業務をつなぐFDE（Forward Deployed Engineer）型の支援にも生かせると考えています。

申告を受けて、私たちは「Googleの認可が切れた」と決めつけなかった

当初の申告は、Google連携を繰り返し求められるという体験でした。一方、共有された画面には、診断に確定済みの判断がないことを伝える表示が映っていました。その画面だけでは、Googleの認可そのものが失効しているかどうかは分かりません。

ここで私たちは、利用者に見えている症状と、その背後にあるシステム状態を分けて調べました。

ログインし直せること、Googleとの接続が残っていること、計測データを取得できること、診断に判断が表示されることは、それぞれ別の状態です。私たちが目指したのは、状況に合った案内を出し、顧客に不要な再接続を求めないことでした。

コードを調べると、再接続の誤案内につながる3つの経路があった

調査で分かったのは、少なくとも3つの実装上の不備が、接続状態を誤って扱う原因になり得ることでした。当初申告をした顧客の症状が、どの不備によって何回発生したかまでは特定していません。そこは区別したうえで、コード上の欠陥を修正しました。

1. Googleデータ取得時の一般的なHTTP 401を、認可の失効と分類していた

ここでいう401は、GA4・Search ConsoleのAPIがデータ取得時に返すHTTP 401（Googleデータ取得時の401）です。SIGNAL自体のアプリセッションの401とは別のものです。GA4・Search ConsoleのAPIでHTTP 401を受けたとき、当社のエラー分類に、それを広くinvalid_grantとして処理する経路がありました。invalid_grantは再認可を要する場合がある具体的な失効情報です。一方、一般的な401には、アクセス時点のトークンや認証状態など別の要因もあります。

私たちは、一般的な401、invalid_token、UNAUTHENTICATEDと、明示的なinvalid_grantを区別するように修正しました。保存済みの更新トークンが欠落した場合など、実際に再認可が必要な状態への対処は残しました。

結果として、原因を確定できない401だけを理由にGoogle再接続へ誘導する経路を解消しました。

2. 保存済みの接続を「初回未設定」と表示する場合があった

設定がデータベースに残っていても、現在読み取れるリソースがなければ、初めて設定する場合と同じ案内を出すことがありました。実際には、権限の不足、設定の不整合、確認中、同期の失敗などで必要な操作は変わります。

私たちは、保存済みの接続の状態が悪い場合と、まだ設定していない場合を区別しました。画面は原因に沿った案内を出す形へ変更し、未確認のリソースへの読み取り権限を勝手に広げる変更は加えていません。

3. Googleアカウント接続済みでも、データソース未選択を「未接続」と扱っていた

Googleアカウントとの連携自体は保存されているのに、どのGA4プロパティやSearch Consoleサイトを使うかが未選択の場合、初回のGoogle接続へ誘導する経路がありました。

私たちは「Googleアカウントの接続」と「データソースの選択」を別々に表示するように修正しました。顧客が次にすべき操作を、アカウントの再認可とデータソースの選択で取り違えないようにするためです。

修正して本番へ反映したあと、実際にログインし直して確かめた

3つの修正は2026年10月に実装され、テストと通常の公開工程を経て本番へ反映されました。回帰テストでは、通常の401と明示的な認可失効、保存済み接続と未設定、確認済みリソースと未確認リソースを区別する動作を確認しています。

私たちは、テスト成功やデプロイ完了をもって対応の最終成果とは扱いませんでした。10月21日、当社が管理する、本番のGoogle接続済みワークスペースでブラウザ操作による受入確認を行いました。

確認した一連の操作は次のとおりです。

1. ログアウト前：GA4とSearch Consoleが接続され、選択済みの対象と計測データが表示されることを確認。
2. ログアウト・再ログイン：通常のログアウト操作を行い、オーナー本人による認証操作を経て再度SIGNALへログイン。
3. 再読み込み：計測画面をリロードし、以前に選択したGA4とSearch Consoleの対象が残っていることを確認。
4. 実データの読み取り：両データソースの取得成功を画面で確認。Googleの再認可を強制する画面は現れませんでした。
5. 別タブでの確認：同じブラウザセッションを使う別タブでも、接続状態が継続していることを確認。

これにより私たちは、自社の本番ワークスペースでは通常の再ログイン後もGoogle連携が維持され、計測情報を再取得できることを確かめました。ログイン時の秘密情報は取得せず、本人が操作する境界も維持しました。

今回の別タブ確認は同じログインセッションの範囲で行いました。Cookieを分離した別ブラウザと申告元の外部顧客環境については、別の条件で検証する必要があります。私たちは確認した範囲を明示し、技術修正と自社本番での実利用確認を成果として残しました。

この経験から、FDE型の仕事で重視するようになったこと

「連携できない」という相談を、単純にGoogle側の問題、顧客側の設定の問題、当社側のコードの問題へ振り分けるだけでは、顧客は仕事を再開できません。まず顧客の一連の操作を理解し、次にどの層が停止しているかを調べ、修正後は同じ操作が通るかを確かめる必要があります。

このSIGNAL対応から、私たちは導入・障害対応の受入を次の順番で考えています。

• 症状を具体化する：どの画面で、何をした直後に仕事が止まるか。
• 状態を分ける：ログイン、外部認可、取得対象、API結果、画面表示を区別する。
• 最小限の原因へ対処する：再認可が必要なケースは残し、不要な再認可の案内は修正する。
• 利用手順で受け入れる：権限のある環境で、ログアウトから再ログイン、データ取得まで実際に確認する。

これは、今回の障害を通じて当社が整理した実務上の考え方です。顧客の環境によって権限や検証範囲は変わります。第三者のアカウントへ無断でログインすることも、再現のために認可情報を不用意に変更することもありません。

私たちの成果を、顧客が使える状態までつなぐ

今回のSIGNAL対応で私たちが達成したのは、Google再接続の誤案内につながる3つの不備を修正し、当社の本番環境で再ログイン後のGA4・Search Consoleの取得が継続することを確認したことです。

一方、外部顧客全体の問い合わせ件数の減少や、利用継続率・売上への影響について、今回の記録から数値を示すことはできません。外部顧客の個別環境での再現と受入は、当該顧客の許可と実際の操作記録に基づいて判断する必要があります。

この区別も含めて、私たちは技術的な実装と顧客の実利用をつなぐ仕事を重視しています。システムの連携や導入で行き詰まったときは、まず実際に止まっている一つの操作を一緒に特定します。Netsujo株式会社では、AI・SaaSの導入、外部連携、運用へ向けた技術判断と実装支援に対応しています。

AI導入・業務改善支援 ／ 連携・導入について相談する

---

当社の記録について：本稿は2026年10月のSIGNAL障害調査、修正、当社本番ワークスペースでの実利用確認を基に構成しました。顧客の識別情報、認証情報、生のアクセスログは本文に掲載していません。