Redditのコメント収集が不完全になる理由：MoreCommentsを空データとして扱わない

Redditのコメント収集中にエラーが出なかったからといって、コメントツリー全体を読み込めたとは限りません。PRAWを使う場合、MoreCommentsは本文が空のコメントではなく、展開待ちの位置を表します。またreplace_more(limit=0)は収集量の上限を解除するのではなく、これらのプレースホルダーを削除します。この点だけでも、一見整ったエクスポートから議論全体が抜け落ちることがあります。

r/redditdevの元のディスカッションでは、PrincessYukonが投稿のコメントを取得するために、ツリーの展開、レスポンス構造、認証ヘッダーのエラーを順に追跡しました。この事例が参考になるのは、古いリクエストをそのまま真似できるからではなく、トラブルシューティングの進め方にあります。まず実際に受け取ったデータを正確に確認し、そのうえで走査アルゴリズムを検討するという順序です。

本記事は、2026-9-5時点のPRAW作者によるドキュメントとRedditの公式ルールを確認したうえで、許可されたデータ収集において完全性をどう示すかを論じます。実際の投稿収集は行っておらず、過去のフォーラムでの事例を現在のインターフェースの問題として説明するものでもありません。

コメントツリーがページネーションの問題ではない理由

多くのリスト系インターフェースでは、カーソルの連鎖をたどって1ページずつ順に読み込めます。しかしディスカッション欄には、同じ階層の続きのコメントに加えて、特定のコメントの下にさらに深い返信があります。トップレベルの配列だけを走査すると、各議論の冒頭しか取得できない可能性があります。またbodyを持たないオブジェクトを読み飛ばすと、未展開の部分があることすらプログラムは警告しません。

PRAWのコメント抽出チュートリアルでは、MoreCommentsをページ上の「load more comments」や「continue this thread」に対応づけています。1回の展開で新たな展開待ちの位置が現れることもあります。そのため、ノード数とリクエスト数は単純に置き換えられません。プレースホルダーを10個処理しても、取得できるコメントが10件だけとは限らず、10個のスレッドを完全に網羅したことにもなりません。

パーサーを書く際は、まず本文ノードと展開待ちノードを区別すべきです。読み込まれていないサブツリーは「まだ観測していない」のであって、「誰も返信していない」わけではありません。この区別は分析レイヤーで特に重要です。未展開の部分が深い議論であれば、トップレベルの意見分布は議論全体を代表していない可能性があります。

replace_moreのlimitが実際に制限するもの

現行のPRAWチュートリアルによると、デフォルトの呼び出しでは最大32個のMoreCommentsを置き換えます。limit=0はそれ以上展開せずにプレースホルダーを削除し、limit=Noneは置き換え数に上限を設けませんが、他の条件による制約は引き続き受けます。これらは似たような3つのパフォーマンス設定ではなく、3通りの異なるサンプリング結果です。

たとえばクイックプレビューでは、あえて展開せずに読み込み済みのコンテンツを表示することもできます。これは妥当な製品機能ですが、ボタン名は「全コメントのエクスポート」ではなく「読み込み済みコメントのプレビュー」とすべきです。より広い範囲が必要な場合は、上限付きの展開予算を設定できます。予算に達したら部分的な結果を返し、その判断を記録します。

Noneも、本番システムで無制限に処理してよいという許可ではありません。各タスクには引き続き、最大実行時間、エラー時の停止条件、許可されたリクエスト範囲を設定する必要があります。インターフェースから返されないコンテンツやアクセスできないコンテンツは、SDKの件数上限を外しただけで自動的に現れるわけではありません。

thresholdも明示的に記録すべきです。CommentForestのメソッド説明によると、このパラメータはどのプレースホルダーを展開するかに影響します。「全件取得」用のパラメータを1つだけ覚えて、もう1つのフィルター条件を見落とすと、完了を早まって宣言してしまうおそれがあります。

最終配列だけに頼らない未展開項目の保存

replace_moreは、置き換えられなかったMoreCommentsインスタンスのリストを返します。現在のツリーから削除されたプレースホルダーは、それ自体が最終的な配列に現れなくなる場合があります。そのため「最終リストにMoreCommentsがない」ことだけでは、取りこぼしがゼロであることを証明できません。メソッドが返した未置換の項目はタスク結果に含めるべきです。

ここでもう1つ注意すべきなのは、未展開のプレースホルダーが5個あっても、コメントが5件欠けているとは限らないことです。1個のプレースホルダーがサブツリーを表すこともあり、さらに展開するとプレースホルダーが増えることもあります。対外的には「未展開の位置が5か所残っている」と説明できますが、安易に完了率を算出すべきではありません。

タスクでは少なくとも3種類の情報を出力することをおすすめします。読み込み済みのコメント（重複除外）、未完了の範囲、停止理由です。停止理由には、プレビューモードの選択、展開予算の上限到達、レート制限、認証失敗、パース例外などがあります。フィールド名はアプリケーション側で決めて構いません。重要なのは、下流のシステムが「結果なし」と「実行が未完了」を区別できることです。

サードパーティのラッパーインターフェースを利用する場合は、その「コメント数」がトップレベルの件数なのか、読み込み済みの全階層の件数なのか、タスクで切り詰めた件数なのかも確認すべきです。パラメータ名に同じlimitが使われていても、意味が同じとは限りません。PRAWのパラメータ解釈をEveryInfraや他のインターフェースに当てはめないでください。

フラット化後のコメント返信先の追跡

CommentForestのlist()は読み込み済みのコンテンツを走査順に展開できますが、フラット化はデータを追加で補完するものではありません。1次元配列を得た後も、コメントID、投稿との関連、親子関係を捨てるべきではありません。

あるトップレベルのコメントが「新リリースで問題が修正された」と述べ、その返信が「デスクトップのみで、モバイルには入っていない」と続いているとします。エクスポートに2つ目の文しか残っていなければ、モデルはそれを独立した新しい不満として扱うかもしれません。親コメントすら欠けている場合は、モデルに前の文脈を推測させるのではなく、文脈の欠落をフラグとして示すべきです。

重複排除もIDを軸に行う必要があります。リトライ後に同じコメントが再び現れた場合は、別のユーザーの意見として扱うのではなく、現在の観測内容を更新します。また、テキストが一致していても、文字列の一致だけで別々のコメントを統合してはいけません。内容の編集、作成者情報の欠落、親ノードが見えない状態は、すべて空文字列にするのではなく、それぞれ別の状態として保持します。

これらの記録は、該当するデータの利用・保持範囲内でのみ管理します。関係性の保持に関する推奨は、すべての元テキストを永続的に保存してよいという許可ではありません。

件数、権限、削除も分析範囲の一部

PRAWのチュートリアルでは、投稿のnum_commentsには削除済み、除去済み、またはスパムのコメントが含まれる場合があると説明されています。つまり、この値が抽出可能な件数と一致する保証はありません。この値は検証の手がかりにはなりますが、リトライを重ねて一致させるべき目標として扱うことはできません。

収集の権限は別途確認する必要があります。RedditのData API Wikiでは、適切なOAuth認証情報と明確なUser-Agentが求められており、レート制限に関するレスポンスヘッダーとアクセスルールが記載されています。PRAWをインストールできることは、任意のプロジェクトでデータを使う許可を得たことと同じではありません。古い投稿で動いたコードが、現在の連携条件の代わりになるわけでもありません。

同じ公式ページでは、プラットフォーム上ですでに削除されたコンテンツへの対応も求めています。分析システムでは、削除を元のテーブルだけで終わらせることはできません。テキストが検索インデックス、キャッシュ、その他の派生ストレージに入っている場合は、そこでも適用されるクリーンアップ要件を確認すべきです。運営側から明示的に削除を求められたコンテンツを、「匿名化」を口実に保持しないでください。

これは再現性の設計にも影響します。より安全な目標は、観測したすべての元テキストを永続的に保存すると約束することではなく、許可された手法とタスク範囲を記録・保持することです。研究の結論には収集日とサンプル範囲を明記する必要があり、現在入手できなくなった過去のテキストを、いつまでも再検証できる証拠として扱うことはできません。

Redditコメントのエクスポートを検証する方法

まず、合成ツリーで3つの反例を確認します。未展開のサブツリーを持つトップレベルノード、本文がまったく同じ2つの異なるコメント、そして同じコメントが結果に複数回入るケースです。正しい実装であれば、それぞれ未完了の状態を保持し、同じ本文の2つのコメントを別々に保持し、同一コメントの重複を統合します。「プログラムで例外が発生しなかった」ことを成功の判断基準にしてはいけません。

次に、上限付きタスクの停止結果を確認します。展開上限に達した場合は部分完了、認証情報が無効な場合は認証失敗、想定外のレスポンス構造の場合はパース失敗を示すべきです。3つすべてが空のリストを返してはいけません。一般的なエラー分類については、サイト内のAPIエラー処理を参照できますが、プラットフォームのレスポンスの詳細は現行のインターフェースに従います。

最後に、レポートの書き方を確認します。どの投稿から得た結果か、なぜその投稿を選んだか、どこまで展開したか、未完了の項目が残っているかを明記します。人気のある投稿を数件収集しただけでは、「Redditユーザーは一般的に〜と考えている」とは結論づけられません。サイト内のマルチプラットフォームのセンチメント監視ブループリントも同様に、収集範囲とビジネス上の判断を分けています。EveryInfraのRedditコメントAPIでエクスポートする際も、同じ項目で範囲を明記してください。

信頼できるRedditコメントデータは、欠損がないふりをする必要はありません。必要なのは、欠損を可視化し、親子関係を追跡可能な状態に保ち、削除リクエストへの対応と併せて利用範囲を遵守することです。これにより、後続の分析で、どの判断に根拠があり、どの部分を未知のまま残すべきかがわかります。