Michael JohnsonIGクリエイターを2人、プロフィールの一時点の情報だけで比べるのは簡単です。しかし、誰が継続的に投稿しているか、投稿へのリアクションが時間とともにどう変化するかを把握するのは、より困難です。一度だけ確認すると投稿ごとの経過時間が混在し、手作業の表はすぐに古くなります。実用的な解決策は、公開メディアを定期的に収集し、各レスポンスを個別の観測データとして保存して、自分で蓄積したデータから変化を算出することです。
以下では、同じ分野の公開アカウントを毎週比較したいマーケター、アナリスト、開発者向けの実践的な手順を説明します。データ取得にはjsonscraperのIG Scraper APIを使い、Pythonでスケジュール設定、正規化、履歴の保存を行います。これはプロフィールや競合の投稿をモニタリングする方法の続編であり、ここでは比較レポートに使える、一貫した観測データのモデルに焦点を当てます。
まず、何を比較するかを決める
課題は「効果的なクリエイターを見つける」と大まかに表現されがちです。技術的に有用なモニタリングを行うには、測定可能な問いに絞りましょう。投稿頻度、投稿される形式、確認時点で公開されている「いいね」とコメントの数、投稿後の数値の変化などです。こうした指標を使えば、手作業で詳しく調べるアカウントを選んだり、比較サマリーを作成したりできます。
公開カウンターの値は、リクエスト時点のスナップショットです。そのため、複雑なモデルよりも重要な設計上の決定は、値とともに取得時刻を保存することです。毎晩同じメディアのデータを取得して以前の行を上書きすると、増加分の計算に必要な履歴が失われます。代わりに、観測データは変更せずに保存します。つまり、投稿と取得時刻の組み合わせごとに1行を記録します。
比較対象は、同じ期間のものや相互に比較できる投稿に限定しましょう。たとえば、同じ暦月に初めて確認された投稿を見る、または各スナップショットの時点での投稿経過時間を考慮する方法があります。そうしないと、昨日のリールは、リアクションを集める時間が短かっただけなのに、古い投稿より反応が少なく見えてしまいます。
パイプライン：リクエスト、正規化、履歴保存
最小構成のプロセスは4段階です。選んだプロフィールの公開メディア一覧を取得し、レスポンスを共通スキーマに変換し、データを保存して、スケジュールに沿ってレポートを作成します。IG Scraper APIのページには、基本URLとエンドポイント一覧が掲載されており、投稿をチャンク単位で取得するユーザールートも含まれています。連携前に、各ルートのパラメーターとレスポンス例をPostmanコレクションで確認してください。
APIの基本URLはhttps://ig.jsonscraper.comです。初回の確認用として、ドキュメントではユーザー名によるプロフィール取得リクエストが示されています。公開されている例では、GET /v1/user/by/usernameにusername、license_key、cache_timeoutの各パラメーターを指定します。投稿の取得にはGET /v1/user/medias/chunkルートが記載されています。正確な引数、継続取得用のフィールド、レスポンスの構造は、そのリクエスト専用のドキュメントを参照してください。あるルートのスキーマを別のルートに流用してはいけません。
import os
import requests
BASE = "https://ig.jsonscraper.com"
KEY = os.environ["JSONSCRAPER_LICENSE_KEY"]
def get_profile(username: str) -> dict:
response = requests.get(
f"{BASE}/v1/user/by/username",
params={
"username": username,
"license_key": KEY,
"cache_timeout": 60,
},
timeout=30,
)
response.raise_for_status()
return response.json()
print(get_profile("example_account"))
この短い例は、ドキュメントに記載されたプロフィール取得ルートを再現し、HTTP GETでパラメーターを渡す方法を示します。cache_timeout=60は公開例に含まれています。このパラメーターがサポートされているルートでのみ使用し、詳細はドキュメントで確認してください。キーはコードやブラウザーアプリケーションに埋め込まず、環境変数に保存します。
投稿取得を追加する
プロフィールを確認したら、メディア一覧のリクエストを追加します。APIページにはGET /v1/user/medias/chunkが記載されています。結果を処理する際は、ドキュメントで指定されているチャンク取得の手順に従ってください。パラメーター名とページネーションの終了条件は、ルート名から推測せず、Postmanにある最新のリクエスト説明を確認してください。
以下は通信処理のひな型であり、エンドポイントの完成済み仕様ではありません。実行前に、ドキュメントに記載された引数をparamsに設定してください。レスポンスを受け取った後、アダプターは、選択したルートの実際のJSONで確認できたフィールドだけを読み取るようにします。
def fetch_media_chunk(username: str, params: dict) -> dict:
query = {
**params,
"username": username,
"license_key": KEY,
}
response = requests.get(
f"{BASE}/v1/user/medias/chunk",
params=query,
timeout=30,
)
response.raise_for_status()
return response.json()
次に、レスポンスを内部形式に変換するアダプター関数を作成します。分析には、安定した投稿ID、投稿者、リンク、公開日時、メディア形式、取得可能な公開カウンターが役立つでしょう。ドキュメントとJSONの例で正確なフィールド名と型を確認してください。指標が存在しない場合は、0を代入せず空の値として保存します。0はカウンターが測定されてゼロだったことを意味し、空の値はデータがないことを意味します。
def normalize_media(item: dict, username: str, observed_at: str) -> dict:
# 選択したエンドポイントのJSONを確認してから、キーを指定してください。
return {
"username": username,
"media_id": item.get("DOCUMENTED_MEDIA_ID_KEY"),
"media_url": item.get("DOCUMENTED_MEDIA_URL_KEY"),
"published_at": item.get("DOCUMENTED_PUBLISHED_AT_KEY"),
"media_type": item.get("DOCUMENTED_MEDIA_TYPE_KEY"),
"likes": item.get("DOCUMENTED_LIKE_COUNT_KEY"),
"comments": item.get("DOCUMENTED_COMMENT_COUNT_KEY"),
"observed_at": observed_at,
}
プレースホルダーの名前を該当エンドポイントのレスポンスにある正確なキーに置き換え、保存したJSONサンプルを使ったテストでマッピングを固定します。こうすることで、連携の更新時にスキーマ変更を検出できます。また、未確認のフィールド名を確定済み仕様であるかのように扱わずに済みます。
現在の値だけでなく、観測データを保存する
試作にはCSVが使えますが、定常運用にはPostgreSQL、Supabase、または分析用データウェアハウスが適しています。観測テーブルには、username、media_id、published_at、observed_at、likes、comments、未加工のJSONを含められます。media_idとobserved_atの組み合わせで、スナップショットを一意に識別します。別のプロフィールテーブルには、追跡対象アカウントの一覧とモニタリング開始日を保存します。
未加工のレスポンスを保存しておくと、デバッグや正規化データの再構築に役立ちます。プロジェクトの目的と組織のルールに従って保存期間を制限し、テーブルへのアクセスを管理するとともに、選択した分析に不要な情報は収集しないでください。CRMやダイレクトマーケティングに利用する場合は、適用される法的根拠を別途確認してください。公開データを技術的に取得できることだけでは、この問題は解決しません。
CREATE TABLE media_observations (
username TEXT NOT NULL,
media_id TEXT NOT NULL,
media_url TEXT,
published_at TIMESTAMPTZ,
observed_at TIMESTAMPTZ NOT NULL,
media_type TEXT,
likes BIGINT,
comments BIGINT,
raw_json JSONB,
PRIMARY KEY (media_id, observed_at)
);
レスポンスを正常に検証できたら、まとめてレコードを追加します。同じジョブを再実行しても、主キーの組み合わせによりスナップショットの重複作成を防げます。アプリケーションでは、競合時に挿入をスキップする方法が使えます。別の時刻に新たなジョブを実行すれば、別行として保存され、時系列データが続いていきます。
問いに答える指標を計算する
投稿ペースの基本指標は、選択した期間内のアカウントごとのユニークなメディア数です。published_atフィールドが存在し、正しく解釈できる場合に計算できます。公開リアクションの変化を評価するには、同じmedia_idに対する2つの観測データを比較します。「いいね」の絶対変化は後のカウンターから前のカウンターを引いた値、相対変化はその差を前の値で割った値です。コメントにも同じ計算を適用します。
前の値がゼロまたは欠損している場合、相対増加率は定義できません。絶対差を表示し、パーセンテージを計算する基準がないことを明示してください。観測間でカウンターが変化することがあるため、レポートにはスナップショット間の期間と最終取得時刻を記載します。こうした情報があれば、読者は数値を正しく解釈できます。
def growth(previous, current):
if previous is None or current is None:
return {"delta": None, "rate": None}
delta = current - previous
rate = None if previous == 0 else delta / previous
return {"delta": delta, "rate": rate}
説明できる重み付けなしに、アカウントを単一のランキングにまとめないでください。実用的なレポートでは通常、投稿数、投稿あたりの「いいね」とコメントの中央値、形式ごとの内訳、同じ経過時間で比較したリアクションの変化を並べて表示します。中央値は突出した1件の投稿の影響を抑え、投稿数は比較の根拠となるサンプルの規模を示します。
投稿の経過時間は、2つの方法で考慮できます。1つ目は、メディアを初めて検出した後、たとえば一定間隔でカウンターを定期的に記録する方法です。2つ目は、同じ時間帯に投稿されたものを対象とし、ほぼ同じ経過時間の観測データを使って比較する方法です。スケジュールどおりに実行できなかった場合は、実際の変化を「正確な24時間の増加」と表現してはいけません。タイムスタンプから実際の間隔を計算してください。
実行と品質管理を自動化する
cron、GitHub Actions、またはETLオーケストレーターを使って、収集を定期実行します。ジョブの手順はシンプルです。アカウント一覧を読み込み、必要なチャンクをリクエストし、HTTPステータスとレスポンス構造を確認し、データを正規化してスナップショットを保存し、実行ログを記録します。実行ごとに、処理したアカウント数、メディア数、エラー、処理時間を記録すれば、実際の活動変化と収集の失敗を区別しやすくなります。
一時的なエラーには、回数を限定して間隔を空けながら再試行します。エラーレスポンスが返った場合は、秘密鍵を除いてリクエストのコンテキストを保存します。カーソルを使った無限ループを実行してはいけません。停止条件は、エンドポイントのレスポンスに示された条件に従ってください。ドキュメントにレート制限や利用規則がある場合は、それに合わせて頻度と取得件数を設定します。
サポート対象のルートでは、IG APIのページにcache_timeoutパラメーターが記載されています。短時間内の再リクエストに価値がなければ、キャッシュが役立ちます。変化を追跡するには、分析の問いに合った収集間隔を選びます。たとえば、具体的な目的なく同じプロフィールに何度もリクエストを送るより、毎日のスナップショットのほうが週次レビューに適しています。
定期実行を有効にする前に、小規模なサンプルでテストしてください。レスポンス例を保存し、IDと日付を確認して、正規化後のフィールドを元のJSONと照合し、複数の行を手作業でチェックします。欠損値、空のリスト、予期しない形式のテストも追加してください。APIが変更された際、こうした検証があれば週末に不整合なレポートが出る前に問題を検出できます。
AIが役立つ場面
AIの活用が適しているのは、最後の段階、つまり計算済みの結果を簡潔にまとめる場面です。未加工のアーカイブ全体ではなく、集計値と投稿へのリンクをモデルに渡します。たとえば、週ごとのメディア数、公開リアクションの中央値、指定期間に変化が大きかった投稿の一覧などです。モデルには、得られた観察結果をまとめ、根拠となるレコードIDを添えるよう依頼します。
同じルールから再現性のある結果を得るため、指標の計算は通常のコードに任せるのが望ましいでしょう。モデルは文章の要約、あらかじめ定義したテーマによるキャプションの分類、手作業で確認するための問いの提案に使えます。テーマ分類では、モデルが付けたラベルを元のキャプションとは別に保存し、指示文や分類器のバージョンを記録します。そうすれば、後の変更によって過去の履歴が気付かないうちに書き換わることを防げます。
自動レポートを、採用、契約、特定の人の評価に関する自動判断に使わないでください。公開データはコンテンツに限定した分析に用い、特にビジネス上の判断に影響する場合は、結論を人が確認してください。こうすることでモニタリングの有用性を保ち、測定可能なカウンターとその解釈を切り分けられます。
どのような結果が得られるか
収集を数回繰り返すと、各投稿がいつ検出され、各観測時点でリアクションがいくつあり、指標がどのように変化したかを確認できるテーブルができます。週次サマリーでは、誰が継続的に投稿したか、どの形式が多かったか、比較可能なスナップショット間でどの投稿のリアクションが増えたか、確かな比較に必要なデータがまだ足りないのはどこか、といった実務的な問いに答えられます。
このプロセスにより、時折行う手作業の確認を、再現可能な調査に置き換えられます。ただし、質的なコンテンツ分析の代わりにはなりません。指標が示すのは投稿頻度と取得可能な公開リアクションであり、内容の意味、オーディエンス、ブランドとの適合性は別途評価する必要があります。一方で、一定のスケジュール、保存された履歴、明示された計算ロジックがあれば、評価を検証でき、チームで活用しやすくなります。
まずIG Scraper APIのページを開き、投稿取得ルートのパラメーターをPostmanドキュメントで確認します。次にテスト用アカウントでアダプターを実装し、最初のスナップショットを保存してください。スキーマが確認できたら、スケジュール設定、エラー管理、選択した指標によるレポートを追加します。