# Instagramの研究データ収集量を実行前に見積もる方法

大規模なデータ収集を始める前に、研究課題を絞り込み、入力するURLの対象枠と観測件数の上限を明確に定めてください。重複を除いた投稿数と、繰り返し観測する回数は分けて数えます。計画した件数、取得を試みた件数、保存した件数、利用可能な件数、課金された件数を区別してください。小規模な研究で答えられるのは、範囲を絞った問いです。規模を小さくしても、便宜的に選んだサンプルが百万社を代表するようにはなりません。

## 件数を限定した投稿の対象枠を作る

Actorは、ホスティング環境で動作するデータ収集プログラムです。Taskは、保存済みの入力設定です。Instagram Metricsの公開ビルド1.0.35は、modeをcontentUrlsに設定し、startUrlsに既知の公開投稿またはリールのURLを指定する方式に対応しています。必要に応じて、maxItemsで合計件数の上限も指定できます。最初の確認では、Taskのサンプル入力を、収集対象として意図した既知のコンテンツURL 1件に置き換え、modeをcontentUrlsに設定してください。保存済み設定のmaxItems 100は、maxItems 1に変更します。実在しないmaxItemsPerProfileフラグを追加しないでください。プロフィールの探索は別のモードです。現時点のソース検証で行った予備試験ではブロックされており、受け入れ確認を通過していません。

関係する標準フィールドは、inputUrl、postUrl、postId、shortCode、mediaType、publishedAt、profileId、profileUrl、likes、comments、views、plays、postMetricStatus、status、statusReason、scrapedAtです。現時点で受け入れ確認を通過した、既知のリールを直接指定して再試行した結果では、一致する識別情報と日付、公開のいいね数・コメント数・閲覧数、および指標の取得状態が返されました。playsはnullでした。標準フィールドのpostMetricStatusでは、指標の取得可否と数値の精度を区別できます。

OUTPUTのprovidedInputs、contentUrls、profileUrls、inputUrls、maxItems、resolvedUrls、metricRows、noPublicMetricRows、blockedRows、failedRows、invalidRows、unsupportedRows、statusCounts、stopReasonは、収集処理の実績を集計する項目です。プロジェクトの計画件数、利用可能な件数、課金件数を管理する台帳ではありません。

## 予定する収集量を計算する

1. 分析単位と、必要な公開フィールドを定義してください。企業単位のモデル、投稿単位の記述、繰り返し観測による変化の研究では、それぞれ異なる対象枠が必要です。仮定したプロフィール数や投稿数を、実際に取得可能と確認された件数として扱ったり、無料で大規模に収集できる代替手段を約束したりしないでください。
2. 対象枠と組み入れ基準、および既知の公開プロフィールや投稿のURLをどのように入手したかを記述してください。受け入れ確認を通過した方法は、事前に確認した投稿URLを出発点とします。この方法で、存在を仮定した数百万件の企業プロフィールを探索することはできません。有効な対象枠がない場合は、利用が許可された適切な既存データセットを入手するか、研究課題を変更する必要があります。
3. 明示した仮定に基づいて、予定する収集量を計算してください。選定したプロフィール数に、各プロフィールについて入力する重複のない投稿数と、記録する観測時点の数を掛けます。同じ投稿を繰り返し観測しても、新しい投稿には数えません。変わらない識別情報を照合し、重複投稿や共有された投稿を適切に扱ってください。プロフィールの確認は、別の取得レコードとして管理します。
4. 明示した限定的な調査範囲と、提案されている全数調査を比較してください。研究課題に適した調査設計を文書にし、それに従ってアカウントと投稿を選びます。有意抽出や便宜抽出の場合は、その限界を明記してください。情報源の欠落や公開範囲の違いは、対象に含められるかどうかに影響します。行数を減らすだけでは、母集団を推定できません。
5. 観測時点を1回にするか、今後繰り返し観測する日程を設定するかを選んでください。現在のActorが取得するのは、現時点で公開されている観測値であり、過去の件数ではありません。今後の観測時点を3回にすると、同じ選定済みの投稿枠に対する指標の予定観測件数は3倍になります。情報源から取得できなかった値は欠損のままとし、ゼロにしないでください。[過去の月次推移を必要とする研究には、保存済みの履歴が必要です](/ja/articles/instagram-%E6%9C%88%E6%AC%A1%E9%96%B2%E8%A6%A7%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%88-%E9%81%8E%E5%8E%BB%E3%81%AE%E6%8A%95%E7%A8%BF%E3%81%A8%E6%96%B0%E8%A6%8F%E6%8A%95%E7%A8%BF%E3%81%AE%E5%88%86%E3%81%91%E6%96%B9/)。または、適切な既存の情報源を利用してください。過去の値を作り出して補完してはいけません。
6. 現在の料金と課金ルールを確認し、対応している場合は実行設定で実行ごとの課金上限を設定してください。行数の上限と課金の上限は、異なる制御です。文書に記載された開始イベントと結果イベント、および別途課金される利用量やストレージの費用も予算に含めてください。ここでは、一般的な単価や実際の販売価格は仮定していません。
7. 収集規模を拡大する前に、既知の投稿1件で予備試験を行い、必要なフィールド、情報源の識別情報と状態、件数の精度を確認してください。処理時間と情報源側の遅延は分けて考えます。1件の結果が速く得られても、入力が数百万件になったときに処理量が比例して増えることや、今後も情報源から取得できることの根拠にはなりません。
8. 計画と実績・請求明細を比較する表を作成してください。予定観測件数は意図した作業量を示し、取得を試みた入力件数は実行状況を示します。保存レコード数は保存先に到達したデータを含み、利用可能なレコード数はフィールドの要件を満たすデータを示します。課金対象イベント数は、実際の請求明細に適用されるイベント定義に基づきます。保存件数、利用可能件数、課金件数が等しいと仮定しないでください。必要な調査範囲が予算を超える場合は、適切なデータセットを探すか、研究課題を絞ってください。

## プロジェクト台帳と予算を作る

この節では、説明のために独自に作成した架空の例を使います。

過去の情報源にある仮定を使った計算例では、1,000,000社に、プロフィールを持つ割合60パーセントと投稿数60件を掛けると、36,000,000件の投稿になります。投稿あたり10秒なら、合計360,000,000秒です。日数に換算すると4,166.6667日になります（日あたり86,400秒として計算）。これは読者が示した情報源に関する仮定を使った例であり、実測した取得可能件数、Actorの遅延、実行時間の予測ではありません。別の仮定である80パーセントを使うと推定値は変わるため、両者を混ぜてはいけません。

独自に作成した、範囲を限定した架空の研究では、事前に確認した40件のプロフィールから、それぞれ既知の異なる投稿IDを5件ずつ選びます。重複を除いた投稿数は合計200件です。今後の観測時点を三つ予定すると、指標の予定観測件数は600件になります。四十件のプロフィール確認は、別のレコードとして扱います。変わらない識別情報を使って、投稿が重複していないことを確認します。有意抽出や便宜抽出で作った対象枠から、百万社の母集団について推論することはできません。

以下に、5区分のプロジェクト台帳と2行の予算表を示します。課金対象の観測あたりUSD 0.002、実行ごとの開始料金USD 0.001という架空の料金を設定し、三度実行するものとします。

表：独自に作成した架空のプロジェクト台帳

| プロジェクト台帳 | 件数 |
| --- | --- |
| 予定観測件数： | 600 |
| 取得を試みた入力件数： | 600 |
| 保存レコード数： | 570 |
| 利用可能な観測件数： | 540 |
| 課金対象イベント数： | 540 |

取得を試みたうち30件はレコードが保存されず、保存されたレコードのうち30件は利用に必要なフィールドの要件を満たしませんでした。いいね数とコメント数が利用可能でも、公開の閲覧数カウンターが取得できなければ、閲覧数は不明のままです。

表：独自に作成した架空の予算明細

| 予算 | 計算 |
| --- | --- |
| 1行目（計画した範囲）： | 予定した観測600件がすべて課金される場合、600 × 0.002 ＋ 3 × 0.001という計算になり、合計はUSD 1.203です。 |
| 2行目（結果に基づく請求明細）： | 別途示した架空の実績台帳では、課金対象イベント数は540件です。同じ架空の単価と開始料金を使うと、540 × 0.002 ＋ 3 × 0.001となり、合計はUSD 1.083です。 |

実際の課金は、実際のイベント定義と請求明細に従います。保存件数、利用可能件数、課金件数が等しいという仮定には従いません。実行ごとの課金制御は、プロジェクト全体の費用上限ではありません。

## 次に行うこと

[Instagram Metrics Scraper](https://apify.com/chronometrica/instagram-metrics-scraper)のActorを設定し、[Instagram Post Metrics Tracker](https://apify.com/chronometrica/instagram-metrics-scraper/examples/instagram-post-metrics-tracker)のTaskでテストしてください。既知の入力1件による確認から収集規模を拡大する前に、件数を限定した投稿の対象枠、観測時点、必須フィールドの要件、観測件数と予算の計画を文書にしてください。

## 出典と参考資料

- [Instagram Post Metrics TrackerのTask](https://apify.com/chronometrica/instagram-metrics-scraper/examples/instagram-post-metrics-tracker)
- [Instagram Metrics ScraperのActor](https://apify.com/chronometrica/instagram-metrics-scraper)
- [Apify Actor Storeの料金ドキュメント](https://docs.apify.com/actors/running/actors-in-store)
- [Redditに投稿されたInstagramのスクレイピングに関する質問](https://www.reddit.com/r/learnpython/comments/qq22zy/question_about_instagram_scraping_problem_for/)