新たに確認したInstagramコメントを台帳で管理する方法

1. 対象の投稿と収集の制約を決める

対象が分かっている公開投稿のURLを一覧にします。URLはウェブ上のアドレスです。実行結果を比較するときは同じ一覧を使い、変更した場合はその都度記録してください。実行とは、1組の入力を使って収集プログラムを1回動かすことです。

収集する前に、次の項目を決めて記録します。

1. 確認する公開投稿を一覧にします。
2. 確認の間隔を決めます。
3. 用途に応じて、どの程度の遅れや収集漏れを許容できるか明記します。
4. 投稿ごとに保存するコメント数の上限を設定します。
5. コメントの並び順を選びます。
6. 公開日時のフィルターを使う場合は、その設定を記録します。
7. 各収集に、エクスポートとともに保存できる参照情報を付けます。

上限とは、保存を要求するレコード数の最大値です。その件数を取得できるという約束ではありません。収集間隔は、次に確認する予定の時点を示します。確認と確認の間に投稿されたすべてのコメントが結果に含まれることは証明しません。

新しいコメントをすべて取得したという証明が必要な用途には、この方法は使えません。この方法で残せるのは、確認できたコメントと、把握できる収集上の制約の記録です。

ChronometricaのInstagram Comments ScraperはActorです。Actorとは、ホストされた環境で動く収集プログラムです。確認済みの公開仕様には、対象が分かっている公開投稿の入力、トップレベルコメントのレコード、日時フィルター、投稿ごとの上限が記載されています。前回の実行以降だけを対象にする入力や、新しいコメントだけを対象にする入力は記載されていません。未登録のIDは、利用者側の比較処理で判定する必要があります。Instagram Comments Scraper、2026年10月25日確認。公開データ収集への適合性を仕様で確認。このガイドでは実行テストなし。

このガイドでは公開レコードを使います。非公開アカウントのレコードや、アカウント所有者だけが閲覧できるレポートは取得しません。台帳を、アカウントの完全な通知履歴や、ある利用者のInstagramコメント履歴の全体として説明しないでください。

2. 台帳と確認履歴を分けて保存する

2つの表を保存して使います。表では、行にレコードを、列に名前の付いた値を保存します。キーとは、1件のレコードを特定する値、または値の組み合わせです。

コメント台帳では、`commentId`をキーにします。公開仕様では、このフィールドはトップレベルコメントに付く、変わらないInstagram IDと説明されています。文字を正確に保持するため、IDは文字列として保存してください。

確認履歴には、そのIDを確認した収集を毎回記録します。`commentId`と収集の参照情報の組み合わせをキーにしてください。これにより、同じコメントが複数回の収集に現れても、複数の別コメントとして扱わずに済みます。

次の表は、保存用フィールドの提案です。`first_seen_at`や`collection_ref`などは、利用者側の処理で使うフィールドです。Actorが出力する追加フィールドではありません。

元のエクスポートも全体を保存してください。JSONは、構造を持つレコードを表すテキスト形式です。元のJSONを残しておくと、表を作った後でも値を確認できます。

3つの時刻を区別する

`createdAt`には、情報源が示すコメントの公開時刻を記録します。取得できないことを示すnullの場合もあります。

`collectedAt`には、Actorがコメントを収集した時刻をUTCで記録します。UTCは共通の時刻基準です。元の行にある時刻をそのまま保持してください。

`first_seen_at`には、台帳でそのコメントIDを初めて受け入れた時刻を記録します。このルールを手順の注記に明記してください。過去のエクスポートを今日取り込んだ場合、収集時刻は過去の時刻のままです。台帳で初めて受け入れた時点は今日になります。定めたルールの下で実際に同じ時刻になる場合を除き、これらの時刻を同じにしないでください。

確認した出力仕様には、投稿者の詳細、いいね数、返信数も記載されています。返信数は返信本文ではありません。件数がゼロの場合と取得できない場合は区別してください。`ownerVerified`のfalseとnullも区別します。投稿者IDの欠損は、投稿者IDがゼロという意味ではありません。また、有効なコメントIDまで無効にするものでもありません。公開ビルド0.1.21、2026年10月25日確認。フィールドとnullの扱いを仕様で確認。現在の実行結果ではない。

この台帳が数えるのは、IDで区別したコメントの件数です。重複を除いたアカウント数や人数ではありません。確認済みの作業用ファイルも必要な場合は、公開コメントのサンプル作成ガイドで、別のエクスポートと取り込みの手順を説明しています。その作業と、IDを新たに確認したかどうかの判定は分けてください。

3. 少量の入力で投稿1件を確認する

対象が分かっている公開投稿1件を、上限10件で収集するところから始めます。提示した入力を使ってください。

{"collectAllAvailable":false,"commentSortMode":"default","maxCommentsPerPost":10,"postUrls":["https://www.instagram.com/reel/DZu6dkVyImf/"]}

サンプルのリールのアドレスを、対象の公開投稿またはリールのアドレスに置き換えます。サンプルを残してアドレスを追加するのではなく、サンプルを置き換えてください。

`postUrls`には対象のアドレスを指定します。`maxCommentsPerPost`は、投稿ごとに保存するトップレベルコメントの件数を、重複を除いて制限します。`commentSortMode`は並び順を選びます。値が`default`なら、Instagramの標準の並び順を保ちます。`collectAllAvailable`をfalseにすると、数値の上限が有効になります。

提示した入力は、実行を伴わない静的なスキーマ確認に合格しています。スキーマとは、受け付ける入力フィールドと値の型を定めたものです。この確認で分かるのは、入力の形式が正しいことです。このガイドのための実行は行っておらず、現在の実際の取得可否を確認したものではありません。公開入力仕様、2026年10月25日確認。静的な検証のみ、有料実行なし。

自分で実行した後は、次の手順に従ってください。

1. 使った入力を正確に保存し、収集の参照情報も保存します。
2. エクスポートを変更せずに保存します。
3. 返された各投稿のアドレスと短縮コードを、要求した投稿と照合します。
4. コメントID、本文、各時刻を元のレコードと照合します。
5. コメントの識別情報や対象投稿との一致を確認できないレコードを分けます。
6. 受け入れたIDを初期台帳に追加します。

出力仕様では、`postId`がnullでも認められています。投稿IDを作り出さず、取得できた投稿アドレスと短縮コードを確認してください。`commentId`が欠損していると、台帳と確実に照合できません。その行は未解決として保持します。未解決とは、受け入れる前に確認が必要な状態です。本文が同じでも、欠けたIDの代わりにはなりません。

最初の収集結果を、台帳の開始点にします。そこに含まれるIDは、その台帳にとって初めて知るIDです。結果に含まれていることだけでは、最近投稿されたコメントだとは証明できません。

4. 次のエクスポートをIDで比較する

その後の各収集では、受け入れたコメントIDを、今回の更新前の台帳と比較します。

1. 台帳にないIDなら、コメントの項目を1件追加します。
2. 事前に定めた初回受け入れのルールに従って、`first_seen_at`を設定します。
3. 情報源の`createdAt`を保持します。取得できずnullの場合も、そのまま保持します。
4. 収集の参照情報と`collectedAt`を付けて、確認記録を追加します。
5. IDがすでに存在する場合は、台帳の項目を保持し、新しい確認記録を追加します。
6. 本文を、前に保存した本文と比較します。
7. 変更された本文は日時付きの別の版として保存し、差異があることを示します。

「新たに確認」は、それまで台帳にないIDだったことを意味します。「再確認」は、今回の収集による更新前から台帳にあるIDだったことを意味します。どちらの区分も、コメントの公開日時とは無関係です。

2件のコメントが、同じ本文で異なるIDを持つことがあります。両方を残してください。1つのIDが複数回の収集に現れることもあります。台帳の項目は1件に保ち、複数の確認記録の参照情報を残します。

既知のIDで本文が異なる場合は、過去の報告に使った以前の本文も保持します。比較で分かるのは、保存したレコード間に差異があることです。それだけで、誰が、なぜ本文を変更したかは分かりません。

更新結果は、収集の参照情報と結び付けて保存します。再処理では、その結果を再利用してください。最初の処理で新規と判定したIDを、再び新しい発見として扱わないでください。再処理とは、保存済みの同じエクスポートをもう一度処理することです。

指標の履歴では、数える単位が異なります。単位は、ある時点で読み取って保存した件数の値です。この別の課題は、Instagramスナップショットガイドで説明しています。ここでは、同じコメントを後で確認すると、同じIDのコメントについて根拠が増えます。別のコメントが1件増えるわけではありません。

5. 後から見つかったコメントの例で確認する

以下の具体例は、このガイドのために作成した架空の例です。Actorの出力、顧客の結果、テスト結果ではありません。時刻はすべて、架空の同じ日のUTC時刻です。記載した確認時刻に、台帳が各エクスポートを受け入れるものとします。

10:00の最初のエクスポートは、件数に上限があり、C1とC2を含んでいます。空の台帳に、両方のIDを追加します。

11:00の2回目のエクスポートには、C2とC3が含まれています。情報源が示すC3の公開時刻は09:30です。最初の確認より前に公開されていますが、最初のエクスポートには含まれていませんでした。

台帳の件数は、次のように計算します。

• 1回目の更新後：既知のコメントID 0件 + 新規ID 2件 = 既知のID 2件。
• 2回目の更新：既知のID 2件 + 新規ID 1件 = 既知のID 3件。
• 2回目のエクスポート：再確認したID 1件 + 新たに確認したID 1件 = 重複を除いたエクスポート内のID 2件。

台帳には、C1、C2、C3が入っています。これは、IDで区別した既知のコメント3件です。3人という意味ではありません。

C3の`createdAt`は09:30、`first_seen_at`は11:00のまま保持します。10:00より後に投稿されたとは説明しないでください。C1とC2の「記載なし」は、この架空の例で公開時刻を示していないという意味です。午前0時やゼロを意味するものではありません。

C1は台帳に残ります。2回目のエクスポートに含まれていないことは、削除やモデレーションによる除外の証拠にはなりません。この例からは、含まれていなかった理由は分かりません。

2回の収集には、確認記録が合計4件あります。確認記録2件 + 確認記録2件 = 確認記録4件です。台帳には、IDで区別したコメントが3件あります。この2つの合計は、異なるものを数えています。

次に、同じ収集の参照情報を使って、2回目のエクスポートを再処理します。台帳で期待する結果は次のとおりです。

• 既存のコメントID 3件 + 新規ID 0件 = 既知のID 3件。
• 初回確認として新たに追加される項目は0件。
• コメントと収集の組み合わせが同じキーに対して、追加される確認記録は0件。

C3の初回確認時刻は11:00のままです。ファイルを再処理しても、新たな発見は増えません。

6. 重複期間を明記して日時フィルターを使う

Actorの仕様では、`commentsFrom`と`commentsUntil`は、コメントの日時を対象にしたフィルターです。台帳の初回確認時刻を対象にするものではありません。公開入力仕様、2026年10月25日確認。日時入力を仕様で確認。前回の実行以降だけを対象にするスイッチの記載なし、実行テストなし。

日時フィルターを使う場合は、収集対象期間に重複期間を設け、その範囲を明記します。重複期間とは、次の対象期間に前の対象期間の一部を含めることです。IDを比較し、重複するレコードから台帳の新規項目が作られないようにします。

用途に合う重複期間を選び、記録してください。提示された確定済みの資料からは、どの用途でも安全といえる重複期間の長さは分かりません。

架空のC3の例は、なお残るリスクを示しています。次の要求で10:00より前の公開時刻を除外すると、公開時刻が09:30のC3も除外されます。台帳で一度も確認していなくても、このコメントは見つからないままになります。

重複期間を設けると、古い公開日時も対象に含められます。ただし、すべてを発見したことは証明できません。選んだ期間外のコメントは、結果に含まれない可能性が残ります。

並び順の設定にも制約があります。`newest`と`oldest`は、収集できたトップレベルコメントのサンプルを日時順に並べます。条件に合うすべてのコメントがサンプルに含まれたことを示すものではありません。標準の並び順も、時系列に沿った収集を示すものではありません。

`collectAllAvailable`をtrueにすると、数値の上限はなくなります。ただし、仕様に記載された動作では、公開フィードの終端、時間切れ、情報源の障害によって実行が止まることがあります。そのため、上限を外しても情報源全体を収集した証明にはならず、費用が大きく増える可能性もあります。台帳の手順を確認する間は、上限付きの設定を維持してください。

7. 要求した投稿ごとに収集の抜けを記録する

各収集に、収集範囲の記録を添えます。収集範囲とは、要求した情報源のうち、保存した結果で裏付けられる部分を指します。要求した投稿の一覧を各エクスポートと照合してください。受け入れ可能な行が返らなかった要求も対象に含めます。

不明な状態を、成功した結果に置き換えないでください。収集が止まった理由を確認できない場合は、理由不明と記録します。

次の失敗の状態は、それぞれ区別して扱います。

• 返された行がない：その結果ではコメントを確認できなかったことを意味します。投稿のコメント数がゼロだった証明にはなりません。
• コメントの識別情報が欠損：確認用に未加工の行を保持します。本文や投稿者名で照合しないでください。
• 対象投稿との一致が未確認：対象を確認できるまで、その行を未解決のまま保持します。
• 設定した上限への到達を確認：上限を収集範囲の制約として報告します。投稿のコメント総数として扱わないでください。
• 既知のIDが後の結果にない：台帳の項目を保持します。削除やモデレーションによる除外と断定しないでください。
• 時刻を取得できない：欠損のまま保持します。公開時刻や初回確認時刻を代わりに入れないでください。
• 入力の変更：変更内容を記録します。上限、並び順、対象期間が変わると、比較の範囲も変わります。

出力仕様には、公開されているいいね数と返信数が記載されています。ゼロは、値がゼロだと分かっている状態です。nullは取得できない状態です。返信数が欠損していても、ゼロ以外の返信数があっても、返信本文が得られるわけではありません。未加工のレコードを保存するときも、これらの意味を保ってください。

8. 更新結果を使う前に確認する

各収集では、新たに確認したID、再確認したID、本文に変更がある事例、収集範囲が未確定の部分の4つを分けて提示します。本文に変更がある事例は、再確認したIDにも該当することがあります。重複するグループを、別々のコメント件数として合計しないでください。

次の確認を終えてから、更新を受け入れます。

1. 受け入れた各IDについて、元の投稿と未加工のエクスポートをたどれることを確認します。
2. 新規IDが、更新前の台帳になかったことを確認します。
3. 古い公開時刻が変更されずに保持されていることを確認します。
4. 既知のIDの初回確認時刻が、元のまま保持されていることを確認します。
5. 本文に変更がある場合、日時付きの各版が保持されていることを確認します。
6. 同じ収集の参照情報を使い、同じエクスポートを再処理します。
7. 再処理で、新規のコメントIDが0件、初回確認として新たに追加される項目も0件であることを確認します。
8. 要求したすべての投稿に、結果または収集の抜けの説明があることを確認します。

これらは、利用者側の処理に対する確認項目の提案です。この記事のために実行した結果ではありません。