コンテンツへスキップ
2026年7月19日 · ハンドブック

マニュアル: Search ConsoleとAnalyticsを接続する

この記事は公開時点の製品について説明しています。最新の機能についてはAI BuilderおよびAgent Teamsをご覧ください。

マニュアル: Search ConsoleとAnalyticsを接続する

サービスアカウントの作成は4分。初回同期でSearch Consoleの16ヶ月分の履歴が一括取得されます。すでに認証・権限設定済みのドメインなら2秒。そして2ヶ月――この数字が、他の3つを合わせたよりも多くのサポート問い合わせを引き起こしています。これはGA4のデフォルトのデータ保持期間であり、接続前に確認すべきだと知っている人はほとんどいません。

設定自体は簡単です。設定 → Googleアカウントで認証情報を1つ登録し、ドメイン管理で2つの接続ボタンを押すだけで、あとはこのページの存在をほぼ忘れてしまうでしょう。しかし、あの「2ヶ月」という数字については詳しく説明する価値があります。なぜ一部のドメインでは初日から充実したAnalytics履歴が表示され、別のドメインでは数週間ほとんど何も表示されないのか――それはプラットフォームの不具合ではなく、この仕組みによるものだからです。

1つの認証情報を、一度だけ付与

アップロードするのはGoogleサービスアカウントキー――JSONファイルであり、個人ログインではありません。ロボットIDであり、パスワード変更で失効・破損する人間のOAuthトークンとは異なります。Google Cloudが一度発行すれば、削除するまで動作し続けます。これにより、誰もログインしていない深夜3時でもプラットフォームは同期を実行できます。

初めて作成する場合、その所要時間はおよそ4分です。新規または既存のプロジェクトを選び、「IAMと管理 → サービスアカウント → 作成」から進み、キーをダウンロードします。ドロップダウンの見た目以上に重要なのが権限設定です。Search ConsoleプロパティとAnalyticsプロパティに対して閲覧者権限のみを付与してください。それ以上は不要です。私はこれまで、単に一番上の選択肢だからという理由で「編集者」権限を与えてしまい、半年後にはなぜロボットアカウントがGA4設定への書き込み権限を持っているのか誰も説明できない、というチームを何度も見てきました。読み取り専用が正解です。プラットフォームは設定に一切触れません。

1つのキーで、そのGoogle Cloudプロジェクト配下のすべてのドメインをカバーできます。もし複数クライアントのサイトを運用する代理店であれば、すべてを1つにまとめるのではなく、クライアントごとにサービスアカウントを分けることをお勧めします。そうすれば、クライアントの契約終了時に必要なのはキーの削除だけとなり、退職した誰かと密かに認証情報を共有していたドメインがないかを確認する監査作業は不要になります。

サーチコンソール:速いときは速いが、そうでないときはイライラする

  • ドメインの接続を開きます。サーチコンソールとアナリティクスにはそれぞれカードがあり、アナリティクスには「サーチコンソールと同じ」ショートカットがあります。1つのキーで両方をカバーできることが多いためです。
  • すでにサービスアカウントにアクセス権を付与して確認済みですか?それなら瞬時に完了します——権限チェックが約2秒で終わります。
  • まだ確認されていない場合:レジストラのAPIキー(Cloudflare、Route 53、その他数社)を提供すればDNS自動確認、または自分で追加する手動のTXTレコードのいずれかになります。

手動の方法は、みんなが焦れてしまうところです。伝播にかかる時間は本当にまちまちで、90秒で終わることもあれば4時間かかることもあり、TTLやリゾルバーのキャッシュ次第です。プラットフォーム側で自動的にポーリングするので、レコードを追加したらそのまま放置しておいて構いません。1日経っても確認されない場合、伝播の問題であることはまれで、値のタイプミスか、レコードが誤ったゾーンに設定されている(サブドメインではなくルート、あるいはその逆)ことが原因です。Googleのせいにする前に、実際に公開されている内容に対して`dig TXT`を実行して確認してください。

APIキーによる方法は、レコードを自動で書き込むことでこの手間を省きますが、代わりにサードパーティ製ツールにDNSへの書き込み権限を渡すことになります——もしそのDNSが本番トラフィックの前段にあるなら、躊躇するのは無理もないと思います。手動での方法は最初に数分かかりますが、その後は二度と気にしなくて済みます。

アナリティクスと、誰も教えてくれないデータ保持期間のギャップ

アナリティクスは確認ではなく検出によって接続します——プラットフォームがそのドメインの既存のGA4プロパティを探し、サービスアカウントにアクセス権があれば接続します。GA4の権限はすでにGoogle側でゲートされているためです。何も存在しない場合は新規プロパティを作成できますが、これは本当に新しいサイトの場合にのみ使うべきです。ユニバーサルアナリティクスから移行した、あるいは何年も履歴のあるプロパティがある場合は、そちらに明示的に接続してください。3日分のデータしかない新しいプロパティは、季節変動が織り込まれた9年分のデータがあるものよりもはるかに悪いスタート地点であり、接続フローが示唆する以上に、最適化ループはその履歴に依存しています。

ここで人がつまずくギャップがあります:サーチコンソールは初回同期で最大16ヶ月分のクエリデータを遡って取得します。Googleが接続時期に関わらずそれだけの履歴をサーバー側に保持しているためです。GA4にはそれに相当する保証がありません——バックフィルはプロパティ自体のデータ保持設定の上限に制約され、その設定は組織の誰かが変更しない限りデフォルトで2ヶ月です。つまり、接続した瞬間、同じ日、同じセットアップフローで、あるドメインが16ヶ月分の表示回数とクリック数を示す一方で、セッションは2ヶ月分しかない、ということが起こり得ます。これは同期の失敗ではありません。Googleの保持デフォルトが設定通りに動作しているだけです。今後2ヶ月以上のデータが必要なら、修正方法はGA4プロパティ設定内で保持期間を直接変更することであり、このプラットフォーム側ではどうにもできません。接続後に食い違いに戸惑うのではなく、接続前に確認しておく価値があります。

共有プロパティとその後の挙動

アナリティクスに関するもう一つの注意点:もし組織で5つのサイトを1つのGA4プロパティで一括収集している場合——何年も前に誰かがトラッキングを設定し、それ以降誰も分割していないというよくあるケースです——接続自体は問題なく機能しますが、すべてのクエリは裏側でホスト名によってフィルタリングされます。チェックボックスでオン・オフできるものではなく、誤って無効化できるものでもありません。だからこそダッシュボードには常にこのドメインの数値だけが表示され、プロパティ全体の合計は決して表示されません。

その保証が重要な理由:それはクエリレイヤーで強制されるものであり、誰かがチェックを外せるような設定ではありません。代理店向けのダッシュボードを運用している場合、あるクライアントが別のクライアントのトラフィックを見てしまうのは単なる不便ではなく——取り返しのつかない信頼の裏切りです。

両方の接続が完了すると、同期は自分で設定したスケジュールに沿って毎日実行され(スケジュールの章を参照)、プラットフォーム上で構築したものについてはストア分析が自動的に結合されます。ドメイン行には「保留中」「一部完了」「有効」のいずれかが表示されます——「一部完了」は2つの接続のうち片方だけが機能していることを意味し、集計ステータスを鵜呑みにせず、どちらのカードが赤くなっているかを確認するきっかけになります。

実際につまずくポイント

私が見てきたほぼすべてのチケットは、決して珍しくない3つのパターンのどれかに当てはまります。1つ目:サービスアカウントキー自体は有効だが、誤ったGoogle Cloudプロジェクトにスコープされているため、キー自体はアップロードできても権限チェックが空で返ってくる。2つ目:サービスアカウントのメールアドレス——例えば [email protected] ——を、サーチコンソールまたはGA4自体のアクセス設定内で閲覧者として実際には誰も追加していない。プラットフォームにキーをアップロードしただけでは、Google側で何かの権限が付与されるわけではありません。3つ目、もっと厄介なもの:古いサービスアカウントが削除された後、新しいサービスアカウントでドメインが再接続されるが、スケジュールは古い認証情報に対して静かに失敗し続け、誰かが数値の更新が止まったことに気づくまで1週間かかる。

これらはプラットフォームのバグではありません——ロボットが2つの別々のGoogleプロダクトで権限を必要とすることの通常のコストであり、Google自身の仕組みがそれを分かりにくくしています。最初のドメインには、フローが示唆する2分ではなく15分を見込んでおいてください。その後のドメインは早く済みます。認証情報も慣れも引き継がれるからです。

ハンドブック
共有XLinkedInFacebookRedditQuoraWhatsAppTelegramメール
← すべての投稿