Ninchy Blog
ビジネスツール

GASでSNSレポートを自動化する方法|毎月の集計作業をゼロにする

  • #GAS
  • #SNSレポート
  • #スプレッドシート
  • #自動化

SNS運用の報告業務、毎月手作業でスクリーンショットを撮って数字を転記していませんか?Google Apps Script(GAS)を使えば、フォロワー数やリーチなどのインサイトデータを自動で取得し、スプレッドシートにレポートとして蓄積できます。この記事では、当社(SNS運用代行を行う制作会社)が複数クライアントのInstagram・Threadsレポートを実際に自動化したときの構成をもとに、APIの準備からスクリプトの設計、定期実行の設定までを順を追って解説します。

なぜSNSレポートを自動化すべきか

手作業レポートの3つの問題点

当社も以前は、月初にInstagramアプリのインサイト画面を開き、数字をスプレッドシートに転記する運用でした。実際にやっていたからわかるのですが、手作業レポートには3つの構造的な問題があります。

1つ目は工数です。アカウント1つなら10分でも、クライアントが増えれば掛け算で増えます。アプリを開いて、期間を切り替えて、数字を読み取って、転記して——を全アカウント分。月初の数時間がこの単純作業に消えていました。

2つ目は転記ミスです。人間が画面の数字を手で書き写す以上、桁の読み間違いや行のズレは必ず起きます。レポートの数字が一度でも間違っていると、クライアントからの信頼に関わります。

3つ目はデータの粒度です。Instagramアプリのインサイトは表示できる期間が限られており、「先々月と比べてどうか」「半年のトレンドはどうか」を後から振り返るのが困難です。手作業で日次データを毎日記録するのは現実的ではないので、粒度の細かいデータはそもそも残せません。

実際、手作業の頃は1アカウントあたりインサイトの確認・転記に約20分かかっており、クライアント10社分だと単純計算で月200分——3時間強を集計作業だけに費やしていました。しかもこれはInstagramだけの数字で、TikTokの分も同様に手作業だったため、確認するアカウント数もかかる時間も実際にはほぼ倍。しかもこの時間はレポートの「集計」そのものにしかなっておらず、本来やるべき分析や改善提案には1分も使えていない、というのが一番の課題でした。

自動化で得られるもの

自動化して一番大きかったのは、工数削減よりも「過去データが勝手に蓄積されていく」ことでした。毎週・毎月のデータが機械的にスプレッドシートへ積まれていくので、「このアカウント、リールを強化した月からプロフィールアクセス率が変わったか?」といった検証が、いつでも過去に遡ってできます。手作業時代は「先月の数字」しかなかったのが、自動化後は「時系列の資産」になった、というのが実感です。

事前準備:APIアクセスの取得

Meta Graph APIのセットアップ

InstagramのインサイトはMeta Graph API経由で取得します。必要な手順は次のとおりです。

  1. InstagramアカウントをプロアカウントにしてFacebookページと連携する
  2. Meta for Developersでアプリを作成する
  3. instagram_basic、instagram_manage_insights、pages_read_engagement などの権限を設定する
  4. Graph APIエクスプローラでInstagramビジネスアカウントID(IGID)を確認する

Threadsの場合は別途Threads API(graph.threads.net)を使いますが、考え方は同じで「アプリを作り、権限を付け、トークンを発行する」流れです。

アクセストークンの取得と注意点

つまずく人が一番多いのがトークンです。注意点は2つあります。

1つ目は有効期限。Graph APIエクスプローラで手軽に発行できる短期トークンは数時間で失効します。運用に使うなら長期トークンに交換するか、ビジネスマネージャの**システムユーザートークン(無期限)**を発行するのが確実です。当社は最初、長期トークン(60日)で運用していてある朝突然レポートが止まり、原因調査に時間を溶かした経験から、Instagram側は無期限のシステムユーザートークンに切り替えました。

2つ目はクライアントごとのトークン管理。運用代行では、アカウントごとに権限元(クライアントのビジネスマネージャ)が違うため、1本のトークンで全アカウントはカバーできません。当社は「アカウント設定のJSON」をスクリプトプロパティに持たせ、アカウントごとに使うトークンのキー名を指定する構成にしています。トークンやIDをコードに直書きしないことは、セキュリティ面でも保守面でも必須です。

GASスクリプトの作成

スプレッドシートの準備

出力先は「週次」「月次」の2シート構成にしています。列は次のイメージです。

  • 週次シート — 週、開始日、終了日、アカウント、フォロワー数、リーチ、インプレッション、合計インタラクション、プロフィールアクセス
  • 月次シート — 上記に加えて、フォロワー増減、外部リンクタップ、保存数、そしてプロフアクセス率・フォロワー転換率・エンゲージメント率・保存率などの計算指標

ポイントは、率の指標(エンゲージメント率など)もスクリプト側で計算して数値として書き込んでしまうことです。シート関数で計算させると行の追加でズレたり壊れたりするので、シートには完成した値だけを置くほうが運用が安定します。

インサイト取得スクリプトの書き方

処理の流れは全体でこうなります。

  1. スクリプトプロパティからアカウント設定(IGID・トークン)を読み込む
  2. アカウントごとに /{IGID}/insights エンドポイントを叩き、期間指定でリーチ・表示数・合計インタラクション・プロフィールアクセスを取得する
  3. フォロワー数はプロフィール情報から別途取得し、前回値との差分で「増減」を計算する
  4. 取得した値と計算指標をまとめて、該当する週・月の行としてシートに書き込む(既存行があれば上書き=upsert)

実装で効いた工夫は、メトリクス取得を1つずつ「失敗しても0で継続」にすることです。Graph APIはアカウントの状態やメディアの種類によって特定メトリクスだけエラーを返すことがあり、1指標の失敗で全体を止めると「今週のレポートが丸ごと無い」事故になります。当社は各メトリクスをtry-catchで包み、失敗時は警告ログを出して0扱いで先へ進める設計にしています。

もう1つは**upsert(あれば上書き、なければ追加)**にすること。単純な追記にすると、手動で再実行したときに同じ週の行が二重に増えます。「週ラベル+アカウント名」をキーに既存行を探して上書きする形にしておくと、何度実行しても結果が同じ(冪等)になり、再実行を恐れずに済みます。

トリガーで毎日自動実行する

GASのトリガー機能で、週次レポートは毎週月曜の朝、月次レポートは毎月1日に自動実行するよう設定します。トリガー設定自体もスクリプト化しておく(ScriptApp.newTrigger で一括登録する関数を作っておく)と、スクリプトを別環境に移すときに設定漏れがなくなります。

Threadsは投稿単位のインサイト(表示数・いいね・返信・再投稿・引用)も欲しかったので、日次で「直近30日の投稿のインサイトを更新」する処理を毎日実行しています。投稿ごとの数字が毎日更新されて蓄積されるため、「どの型の投稿が伸びたか」の分析までスプレッドシート上で完結します。

自動化で工夫した点・つまずいた点

APIのレート制限対応

複数アカウント×複数メトリクス×投稿ごとのインサイトを取りに行くと、APIコール数はすぐ数百回になります。当社が実際に入れている対策は2つです。

  • 連続コールの間に Utilities.sleep() で短い待ち時間(100〜500ミリ秒)を挟む
  • Threads APIで429(レート制限)が返ったら、30秒待って1回だけリトライする

特に後から効いたのは429リトライです。普段は発生しなくても、後述のバックフィルのような大量取得時には確実に踏みます。「エラーで止まる」ではなく「少し待ってもう一度」を仕組みに入れておくと、夜間実行が安定します。

過去データのバックフィル

自動化を始めた時点では、シートには「これからのデータ」しか溜まりません。過去分も欲しかったので、遡り取得(バックフィル)用の関数を別に用意しました。週数・月数を引数に取り、過去に遡ってループしながら同じupsert処理を回すだけです。Threadsは過去90日分を初回に一括取り込みしました。

つまずいたのは、バックフィルは通常実行の何十倍もAPIを叩くため、レート制限に一番かかりやすいことです。ループ内のsleepを通常より長め(300〜500ミリ秒)に取り、GASの実行時間制限(6分)に収まらない場合は期間を分けて数回に分けて実行する、という運用で乗り切りました。

メトリクスの仕様変更への追従

Graph APIはバージョンアップでメトリクス名や取得方法が変わることがあります。実際、インプレッション系の指標は取得方法が変更され、スクリプトの修正が必要になりました。API連携は「作って終わり」ではなく、エラーをSlackに通知する仕組みをセットで入れておくことを強くおすすめします。当社はエラー時にSlackのWebhookへ通知を飛ばすようにしており、「気づいたら1ヶ月分データが欠けていた」を防いでいます。

実際、Meta側の仕様変更やAPIの不具合は珍しくなく、ある日突然レポートが正しく取得できなくなることが何度かありました。そういうときは無理に自動化側で解決しようとせず、少し時間を置いてMeta側の状況が落ち着くのを待つか、スマートフォンアプリ版のインサイト画面から数値を直接確認しに行く、という手動フォールバックで対応しています。完全に自動化を過信せず、いざというときの手動確認ルートを残しておくことの大切さを実感した出来事でした。

レポートの見せ方の工夫

数字が自動で溜まるようになったら、見せ方をひと工夫します。当社では、生データのシートとは別に「クライアント提出用」のサマリーシートを作り、月次の主要指標と前月比、簡単なグラフだけを載せています。生データを直接見せるより、「今月はここが伸びた/落ちた」が一目でわかる形に整えるほうが、報告ミーティングの質が上がります。

さらに一歩進めるなら、月次データをNotionのデータベースにも自動登録して、社内の案件管理と同じ場所でSNSの数字を見られるようにする、といった発展も可能です(当社はスプレッドシートとNotionの両方に書き込んでいます)。

まとめ

GASによるSNSレポート自動化の要点をまとめます。

  1. Meta Graph API / Threads APIのアプリとトークンを準備する(運用は無期限のシステムユーザートークンが安心)
  2. スプレッドシートは週次・月次の2層構成、率の指標もスクリプト側で計算して書き込む
  3. 取得処理は「1指標の失敗で止めない」「何度実行しても同じ結果(upsert)」を徹底する
  4. sleepと429リトライでレート制限に備え、過去分はバックフィル関数で一括取り込みする
  5. エラーのSlack通知を必ずセットで入れる

GASはサーバー不要・無料で動くので、SNSレポートの自動化には最適な選択肢です。まずは自社アカウント1つ、週次レポートだけからでも始めてみてください。月初の転記作業が消えるだけでなく、蓄積されたデータそれ自体が運用改善の資産になっていきます。