Search ConsoleとGASを連携して、指標を決めて監視するツールを作成しました。
GCPを使いますが、無料でツールを作れます。
ブログ運営をできるだけ自動化したいという場合、問題を洗い出すのに導入すると最低限の保守ができると思います。
ここからは、無料パートで解説したツールを実際に自分の環境で動かすまでの手順を、ひとつずつ追っていきます。
GAS自体は書いたことがあっても、「GCPプロジェクトとの紐付け」で止まってしまう人はとても多いです。
そしてもうひとつ、見落とされがちな関門が appsscript.json でのスコープ宣言です。
GASの『サービス』追加だけでは UrlFetchApp でSearch Console APIを直叩きする構成は通りません。
ここを正しくやらないと、最後の最後で 403 が返ってきます。
この記事では、そのGCP連携を新規プロジェクトの作成から、つまずきポイントを名指ししながら進めます。
全体の流れはこうです。
- GCPプロジェクトを新規作成する
- Search Console APIを有効化する
- OAuth同意画面（Google Auth Platform）を構成する
- OAuthクライアント（認証情報）を作成する
- GASプロジェクトを作り、コードを貼る
appsscript.jsonにOAuthスコープを宣言する- GASとGCPプロジェクトを紐付ける
- スクリプトプロパティ（Slack情報）をセットする
- Slackアプリを用意してBotを招待する
- 手動実行して権限を承認する
- テスト通知で配線を確認する
- トリガーを登録して自動運転に乗せる
所要時間は、初めてGCPを触る場合で40〜50分ほど。
一度通してしまえば2サイト目以降は配列に1行足すだけです。
事前準備：サチコの権限を確認しておく
手順に入る前にひとつだけ。
このツールを動かすGoogleアカウントが、監視したいサイトのSearch Consoleプロパティに「オーナー」または「フルユーザー」として登録されている必要があります。
「制限付きユーザー」では Search Analytics の一部や URL Inspection API が叩けません。
複数アカウントを使い分けている人は、どのアカウントでGASを動かすかを最初に決めておいてください。
そのうえで、そのアカウントの権限をサチコ側で確認しておきます。
ここがずれていると、後半で原因の分かりにくいエラーに悩まされます。
サチコの「設定 > ユーザーと権限」で、自分のアカウントの権限が確認できます。
ステップ1：GCPプロジェクトを新規作成する
まず Google Cloud Console（console.cloud.google.com）を開きます。
GASを使っているGoogleアカウントと同じアカウントでログインしてください。
ここが別アカウントだと、後で紐付けできません。
画面上部、Googleロゴの右隣にあるプロジェクト選択のプルダウン（現在のプロジェクト名が表示されている部分）をクリックします。
初めてなら「My First Project」などと出ているはずです。
開いたダイアログの右上「新しいプロジェクト」をクリック。
プロジェクト作成画面で次を入力します。
- プロジェクト名：
gsc-monitorなど分かりやすい名前。 - 後から変更できますが、プロジェクトID（名前の下に自動生成される
gsc-monitor-xxxxxxのような文字列）は変更できないので、ここで多少こだわってもOKです。 - 場所（組織）：個人利用なら「組織なし」のままで問題ありません。
「作成」を押すと、画面右上に作成中の通知が出ます。
10〜20秒ほどで完了するので、完了したら必ず画面上部のプルダウンから、いま作ったプロジェクトに切り替えてください。
ここで切り替え忘れたまま次のステップに進み、別のプロジェクトでAPIを有効化してしまう──これが最初のつまずきポイントです。
プルダウンに表示されているプロジェクト名が、今作ったものになっているか確認します。
後で使うので、プロジェクト番号を控えておきます。
Cloud Consoleの「ダッシュボード」または「プロジェクト設定」に「プロジェクト番号」（12桁前後の数字）が表示されています。
プロジェクトID（文字列）とプロジェクト番号（数字）は別物で、GASとの紐付けに使うのは番号のほうです。
ステップ2：Search Console APIを有効化する
プロジェクトが選択された状態で、左上のハンバーガーメニュー（≡）から「APIとサービス > ライブラリ」を開きます。
または検索バーに「ライブラリ」と入れても辿り着けます。
APIライブラリの検索ボックスに「Search Console」と入力します。
検索結果に「Google Search Console API」が出てきます。
https://console.cloud.google.com/marketplace/product/google/searchconsole.googleapis.com
これをクリックして、詳細ページの「有効にする」ボタンを押します。
ここで注意。
検索結果に似た名前のものが複数出ることがありますが、有効化するのは「Google Search Console API」です。
「Search Console」関連で別のものを有効にしても、このツールは動きません。
名前を正確に確認してください。
「有効にする」を押すと数秒で完了し、APIの管理画面に切り替わります。
これでこのGCPプロジェクトはSearch Console APIを叩けるようになりました。
ステップ3：OAuth同意画面（Google Auth Platform）を構成する
ここが「GCPが不安」な人にとっての本丸です。
順を追えば難しくありませんが、項目が多いので落ち着いて進めます。
このツールは、スクリプトを実行するあなた自身の権限でAPIを叩きます。
そのために「このプロジェクトはどんなアプリで、誰が使うのか」をGoogleに登録する作業がOAuth同意画面の構成です。
「Google Auth Platform」を開く
左メニューから「APIとサービス > OAuth同意画面」を開きます。
環境によっては「Google Auth Platform」という名前で直接表示されます。
まだ未構成の場合は「Google Auth Platform はまだ構成されていません」と出るので、「スタートガイド（始める）」をクリックします。
このスタートガイドが「アプリ情報 → 対象 → OAuthクライアント → 連絡先情報」という流れのウィザードになっています。
ブランディング（アプリ情報）を入力する
まずアプリの基本情報（ブランディング）を入れます。
- アプリ名：
GSC異常監視など。これは認証時に「○○がGoogleアカウントへのアクセスを求めています」と表示される名前です。自分しか使わないので分かれば何でも構いません。 - ユーザーサポートメール：自分のメールアドレスを選択。
- デベロッパーの連絡先情報：同じく自分のメールアドレス。
ロゴやアプリのドメインなどは任意なので空欄のままで問題ありません。
自分だけが使う内部ツールなので、ここを作り込む必要はありません。
対象（Audience）：User Type を選ぶ
次に「対象（Audience）」で「User Type（ユーザーの種類）」を選びます。
- 外部（External）：個人のGoogleアカウントで運用するならこちらを選びます。Google Workspaceの組織アカウントでも、組織外を含む構成にするならこちら。
- 内部（Internal）：Google Workspaceを使っていて、組織内のアカウントだけで完結させる場合に選べます。選べるなら同意画面まわりがシンプルになります。
個人利用なら基本は「外部」でOKです。
対象（Audience）：テストユーザーに自分を追加する
User Typeで「外部」を選んだ場合、アプリは最初「テスト」という公開ステータスになります。
テストステータスのアプリは、登録した「テストユーザー」しか認証を通せません。
「対象」画面の下のほうにある「テストユーザー」で「Add users（ユーザーを追加）」を押します。
そこにこのツールを動かすGoogleアカウントのメールアドレス（＝あなた自身）を追加します。
ここを忘れると、後でGASを実行したときに認証が止まります。
具体的には、こういう画面が出て先に進めません。
「アクセスをブロック: ○○ は Google の審査プロセスを完了していません」「エラー 403: access_denied」と出たら、原因はほぼこれです。
「このアプリは現在テスト中で、デベロッパーに承認されたテスターのみがアクセスできます」というのは、承認しようとしているアカウントがテストユーザーに入っていないという意味です。
複数アカウントを使っている人が、別アカウントで承認しようとして詰まるのも同じ原因です。
自分自身をテストユーザーに入れる──これを必ずやってください。
補足：「公開」する必要はありません。
自分だけが使うツールなので、アプリのステータスは「テスト」のままで問題ありません。
「アプリを公開」ボタンを押すとGoogleの審査対象になり得るので、押さないでください。
テストユーザーに自分を入れてあれば、テストステータスのまま運用できます。
データアクセス（スコープ）は、ここでは触らなくてよい
「データアクセス」または「スコープ」の画面が出たら、ここは何も追加せずに進めて構いません。
意外に思うかもしれませんが、このツールが使うスコープ（アクセス権限の範囲）は、同意画面側ではなく後述する appsscript.json の側で宣言します。
そして実際の同意は、GASを初めて実行するときに「このスクリプトはこういう権限が必要です」という形でまとめて行います。
ここで何か追加しようとして手が止まりがちですが、同意画面側のスコープはスルーで正解です。
「スコープは appsscript.json で宣言する」──この一点だけ、頭の片隅に置いて先へ進んでください。
ステップ4：OAuthクライアント（認証情報）を作成する
新しいGoogle Auth Platformでは、同意画面の構成を完了させるためにOAuthクライアント（認証情報）の作成が求められます。
スタートガイドのウィザードを進めていると、「OAuthクライアント」のステップが出てきます。
あるいは左メニューの「クライアント」から「クライアントを作成」で作れます。
「アプリケーションの種類」を聞かれたら、個人ツールなら「ウェブ アプリケーション」または「デスクトップ」のどちらかを選んでおけば構成は完了します。
名前は gsc-monitor-client など分かるものでOKです。
「作成」を押すと、クライアントIDとクライアントシークレットが発行されます。
クライアントシークレットは作成時にしか表示されない仕様ですが、このツールではコードに埋め込まないので、控え損ねても問題ありません。
これで「同意画面の構成」と「認証情報の作成」が完了です。
ステップ5：GASプロジェクトを作り、コードを貼る
ここからGAS側です。
script.google.com を開きます。
GCPと同じGoogleアカウントであることを確認して、「新しいプロジェクト」をクリックします。
エディタが開いたら、最初からある myFunction のひな形を含めて中身を全部削除します。
そこに、無料パートで配布したコード（コード.gs）を丸ごと貼り付けます。
貼り終えたら、左上のプロジェクト名（「無題のプロジェクト」）をクリックして、GSC異常監視 など分かりやすい名前に変更しておきます。
フロッピーディスクのアイコン、または Ctrl + S（Macは Cmd + S）で保存します。
この時点ではまだ実行しません。
先にスコープ宣言・GCPとの紐付け・設定の記入を済ませます。
SITES配列を自分のサイトに書き換える
コード上部の SITES 配列を、自分の監視したいサイトに書き換えます。
const SITES = [
{
name: 'サイトA',
property: 'sc-domain:example.com',
sampleUrls: ['https://example.com/'],
},
];
property はサチコの「プロパティ」文字列を登録されている通りに入れます。
- ドメインプロパティなら
sc-domain:example.com - URLプレフィックス型なら
https://example.com/（末尾スラッシュ必須）
自分がどちらのタイプで登録しているかは、サチコの画面左上のプロパティ選択で確認できます。
ここの表記がサチコの登録と1文字でも違うとデータが取得できないので、コピペで正確に入れてください。
ステップ6：appsscript.json にOAuthスコープを宣言する
この記事で一番ハマりやすい、隠れた必須ステップです。
結論から言うと、appsscript.json に必要なスコープを手で書かないと、コードが正しくても 403 で落ちます。
理由を簡単に説明します。
GASは普段、コードを読んで「このスクリプトにはどんな権限（スコープ）が必要か」を自動で判断してくれます。
ところが今回は、Search Console APIを UrlFetchApp で直接叩いています。
GASから見えるのは「外部にHTTPリクエストを送っている」ことだけで、その送り先がSearch Console APIだとまでは判断できません。
そのためSearch Consoleを読む権限（webmasters.readonly）が自動では付与されず、ScriptApp.getOAuthToken() が返すトークンにもその権限が含まれません。
結果、権限の足りないトークンでAPIを叩くことになり、403 が返ってくる、というわけです。
これを防ぐために、appsscript.json に必要なスコープを自分で宣言しておきます。
appsscript.json を表示する
appsscript.json（マニフェストファイル）は、初期状態ではエディタに表示されていません。
GASエディタ左メニューの歯車アイコン「プロジェクトの設定」を開きます。
「「appsscript.json」マニフェスト ファイルをエディタで表示する」にチェックを入れます。
エディタに戻ると、左のファイル一覧に appsscript.json が現れます。
スコープを書き込む
appsscript.json を開き、中身を次の内容に差し替えます。
{
"timeZone": "Asia/Tokyo",
"dependencies": {},
"exceptionLogging": "STACKDRIVER",
"runtimeVersion": "V8",
"oauthScopes": [
"https://www.googleapis.com/auth/webmasters.readonly",
"https://www.googleapis.com/auth/script.external_request",
"https://www.googleapis.com/auth/spreadsheets"
]
}
各スコープの意味は次のとおりです。
webmasters.readonly：Search Console（サチコ）のデータを読み取るための権限。これが無いと403になります。script.external_request：UrlFetchAppで外部に通信するための権限。Search Console APIの直叩きにも、Slackへの通知にも必要です。spreadsheets：スプレッドシートを読み書きする権限。このツール単体では使いませんが、後でログをシートに残すなど拡張する余地を見て入れてあります。不要なら1行削除してOKです。
書き換えたら保存します。
このスコープ宣言が、後のステップ10「権限承認」の画面に出てくる権限一覧の元になります。
つまずきポイント：すでに一度コードを実行して権限承認まで済ませたあとで
oauthScopesを足した場合、追加したスコープは「再承認」しないと有効になりません。スコープを足したのに
403が消えないときは、もう一度checkNowを手動実行して、新しい権限の承認ダイアログを通してください。
ステップ7：GASとGCPプロジェクトを紐付ける
ここを飛ばすと、コードが正しくてもAPIが通りません。
GASエディタの左メニューから、歯車アイコンの「プロジェクトの設定」を開きます。
下のほうにスクロールすると「Google Cloud Platform（GCP）プロジェクト」というセクションがあります。
初期状態では「デフォルトのプロジェクト」が紐付いています。
このデフォルトプロジェクトでは自分でAPIを有効化したりできないため、ステップ1で作ったプロジェクトに切り替えます。
「プロジェクトを変更」ボタンを押します。
「GCPプロジェクト番号」の入力欄が出るので、ステップ1で控えておいたプロジェクト番号（12桁前後の数字）を入力します。
プロジェクトID（文字列）ではなく番号（数字）です。
ここを取り違える人が多いので注意。
「プロジェクトを設定」を押して、エラーが出なければ紐付け完了です。
うまくいかないとき：「番号が見つからない」「権限がない」と言われる場合、たいていは①番号の打ち間違い、②GASとGCPでログインアカウントが違う、③そのアカウントがGCPプロジェクトの権限を持っていない、のどれかです。
ステップ1〜2を同じアカウントでやったか、もう一度確認してください。
これで「GASプロジェクト」と「Search Console APIを有効化したGCPプロジェクト」が結びつきました。
GASがAPIを叩いたときに、ステップ2で有効化したAPIと、ステップ3で構成した同意画面、ステップ6で宣言したスコープが使われるようになります。
ステップ8：スクリプトプロパティをセットする
次に、Slack通知に必要な情報をGASに登録します。
コードに直接書かず、スクリプトプロパティに保存するのがセオリーです（コードを誰かに共有してもトークンが漏れません）。
GASエディタの「プロジェクトの設定」（ステップ7と同じ画面）を開き、一番下までスクロールすると「スクリプト プロパティ」のセクションがあります。
「スクリプト プロパティを追加」を押して、次の2つを登録します。
値は次のステップ9でSlackから取得するので、いったんこの画面の場所だけ確認して、ステップ9のあと戻ってきて入力しても構いません。
| プロパティ | 値 |
|---|---|
SLACK_BOT_TOKEN | Slackアプリの Bot User OAuth Token（xoxb- で始まる文字列） |
SLACK_CHANNEL | 通知先チャンネル（#seo-alert のような名前、またはチャンネルID C0XXXXXXX） |
プロパティ名（左側）はスペルを正確に。
コードはこの名前でプロパティを読みに行くので、SLACK_BOT_TOKEN が SLACK_TOKEN になっているだけで動きません。
入力したら「スクリプト プロパティを保存」を押します。
ステップ9：Slackアプリを用意してBotを招待する
ステップ8で必要になるSlackの2つの値を取得します。
Slackアプリをまだ持っていない前提で進めます。
Slackアプリを作る
api.slack.com/apps を開き、「Create New App」をクリックします。
「From scratch」を選び、アプリ名（GSC Monitor など）と、通知を送りたいワークスペースを選択して「Create App」。
chat:write 権限を付与する
アプリの管理画面左メニューから「OAuth & Permissions」を開きます。
下にスクロールして「Scopes」セクションの「Bot Token Scopes」で「Add an OAuth Scope」を押し、「chat:write」を追加します。
これがメッセージ投稿に必要な最小限の権限です。
ワークスペースにインストールしてトークンを取得
同じ「OAuth & Permissions」画面の上部に戻り、「Install to Workspace」（または Install to ～）を押します。
確認画面で「許可する」。
インストールが完了すると、「Bot User OAuth Token」として xoxb- で始まる文字列が表示されます。
これが SLACK_BOT_TOKEN の値です。
コピーして、ステップ8のスクリプトプロパティに貼り付けます。
Botを通知先チャンネルに招待する
最後に、Slack本体（アプリ）で通知を送りたいチャンネルを開き、メッセージ欄に次のように打ち込みます。
/invite @GSC Monitor
（@ のあとはステップ9で付けたアプリ名）
これでBotがチャンネルに参加します。
この招待を忘れると、トークンが正しくてもメッセージが投稿できません（not_in_channel というエラーになります）。
SLACK_CHANNEL の値には、このチャンネル名を # 込みで（例：#seo-alert）入れます。
チャンネルIDでも構いません（チャンネル名をクリックして開く詳細の一番下にあります）。
ここまでで、ステップ8のスクリプトプロパティ2つが両方とも埋まっているはずです。
埋まっているか確認してください。
実際のGAS
以下、実際のコードです。
