400 million件の文書を数か月で分類したScribdのバッチ処理

利用者が自由に投稿できる場を持つと、「過去の分をもう一度全部見直す」という仕事がどこかに残ります。これから投稿されるものを審査する仕組みは作れても、すでに積み上がった分を点検し直すのは別の話です。件数が億の単位になると、見積もりの時点で年単位・複数チームの計画になり、優先順位の下のほうに置かれたまま動かなくなります。

Scribd, Inc. は、その棚卸しを一度やり切ったと公表しました。Google Cloud の公式ブログに2026年9月25日付で掲載された導入事例によると、同社は Gemini のネイティブなPDF理解と Gemini Enterprise のバッチ予測を使い、利用者が投稿した 400 million 件を超える文書（ページ数にして 12 billion 超）に対する信頼と安全（trust and safety）の分類を、数か月で通しています。

この記事が扱えるのは、その導入事例と、Gemini API の公式ドキュメント2本、そして Scribd, Inc. の会社案内ページに書かれている範囲だけです。確認日は2026年10月23日です。かかった費用の総額、分類の精度、対象期間の開始日と終了日は、いずれも公表されていません。読みどころは数字の大きさではなく、年単位に見えていた仕事がどの選択によって数か月の仕事に変わったのか、という組み立ての部分です。製品を推すための記事ではありません。

カテゴリごとに専用の検知モデルを積み上げるのをやめた

会社案内ページによると、Scribd, Inc. が運営しているのは Scribd、Everand、Slideshare、Fable の4つです。掲載されているコンテンツは50以上の言語にわたるとされています。文書も、スライドも、書籍も、同じ会社の下に並んでいる状態です。

導入事例は、この規模での審査が難しい理由を、件数ではなく種類の側に置いています。ポリシーの区分ごとに内容のふるまいが違うため、従来はそれぞれに専用の検知モデルが要り、自前で作るなら年単位の開発、外から買うなら相応の費用になりました。しかも、そうした製品は 400 million 件の遡及処理（backfill）には向いていなかったと書かれています。既製のモデレーション用ツールや公開モデルも検討したものの、この規模で必要な品質には届かなかったとされています。

Senior Engineering Manager の Sachin Sebastian 氏の言葉が載っています。「This is a genuinely hard problem that we have been working on for a long time. Every category of content behaves differently, and historically each one required its own specialized solution. Gemini collapsed all of that into one model, one prompt, and one pipeline.」内容の区分ごとにふるまいが違い、歴史的にはそれぞれが専用の解決策を必要としていたが、それが1つのモデル、1つのプロンプト、1つのパイプラインにまとまった、という説明です。

ここで注意しておきたいのは、「1つのモデルにまとまった」のは解決策の数であって、判断の正しさではないことです。区分ごとの精度がどうだったかは公表されていません。クリエイターの過去投稿を審査する側から同じ問題に取り組んだ例はViral Nationのクリエイター審査にまとめています。あちらは人が起用を決める前の確認、こちらは投稿済みの山に対する遡及処理で、求められる速さの性質が違います。

PDFをそのまま入れたので、前処理の工程が丸ごと消えた

技術の選択として、導入事例がいちばん強く書いているのはここです。Gemini はPDFを一級の入力として受け取り、各ページを文字としても画像としても読む。そのため、OCRのパイプラインも、ページの描画も、画面取得の仕組みも作らずに済んだ、という説明になっています。

Sebastian 氏の言葉です。「Gemini’s peculiar advantage is that it meets our content in its native format. It reads the text, layout, and images of a PDF directly. More than 99% of our corpus went in exactly as it lives on our site without any pre-processing」自社のサイトに置かれているそのままの形で、99%超が前処理なしに入った、という意味になります。

費用の予測がしやすい理由も、同じところから来ています。Gemini はPDFの1ページを固定的で予測可能なトークン数として処理するため、費用が線形に伸び、12 billion ページの規模でも低いまま保たれる、と書かれています。総量が読めることと、単価が安いことは別の利点です。前者がないと、そもそも予算の承認が取れません。

多様な形式を1つの入口に揃えられたことには、もう1つの効果があったとされています。文字だけを見るモデレーション用のエンドポイントが取りこぼしていた、視覚的な違反の手がかりを拾えた、という記述です。文書に含まれる画像や紙面の体裁まで同じ流れで見るのであれば、確かに別の仕組みを足さずに済みます。

パイプラインそのものは拍子抜けするほど単純です。文書を Cloud Storage に置き、Gemini Enterprise のバッチ予測に出し、結果を自社のデータ基盤へ戻す。導入事例は、配信用のサーバーも、流量制御の仕組みも、GPUの確保も要らなかったと書いています。

バッチを選んだのは処理の都合ではなく、費用の都合

ここが、この事例でいちばん実務に移しやすい部分です。導入事例は、Gemini Enterprise のバッチ予測が対話型の価格に対して50%引きであることが、コーパス全体の規模でLLMによる分類を成立させた、と書いています。Sebastian 氏の言い方では「Batch pricing, at 50% below interactive rates, is what made the economics work at corpus scale.」です。

バッチ処理の条件は、Gemini API の公式ドキュメントにも書かれています。Batch API は大量の要求を非同期で処理するもので、標準の費用の50%とされています。返ってくるまでの目標時間は24時間で、多くの場合はそれより短いとされています。入力ファイルの上限は2GB、バッチの結果は既定で6週間保存されたのち削除される、という記載もあります。

言い換えると、差し出しているのは即時性だけです。棚卸しのように今日中に答えが要らない仕事では、即時性は使われないまま費用に乗っています。導入事例の書き方を借りれば、この種の処理が「できる／できない」を分けていたのは精度ではなく単価のほうでした。半額になったから成立した、と明言されています。

自社で試すときの検討順も、ここから決まります。先に「どのモデルが賢いか」を比べるのではなく、その仕事に即時性が要るかどうかを先に仕分けるほうが効きます。要らないものをバッチへ寄せるだけで、同じモデル・同じプロンプトのまま単価が変わります。

分類したあとに、もう一度モデルで見直している

品質の担保の仕方も具体的です。導入事例によると、モデルの系列と版を比較検討したうえで、分類の主役には Gemini 2.5 Flash Lite を選び、Gemini 2.5 Pro を LLM judge として、コーパス全体に対する2回目の一貫性確認の通し処理に使ったとされています。

つまり、安いモデルで全件を分類し、賢いモデルで全件を点検している構成です。抜き取りで検査するのではなく、もう一度全部を通している点が目を引きます。ここもバッチの単価が効いています。2回通しても対話型の1回より安く収まる計算になるからです。

ただし、この二段構えで何がどれだけ改善したのかは公表されていません。食い違いが出た文書をどう扱ったのか、最終的な判定を人が確認したのか、確認したならどの割合かも書かれていません。「全件を点検した」と「正しかった」は別のことです。社内で紹介するときに、この2つを続けて読ませない書き方にしてください。

動かない文面を先頭に置くと、キャッシュに当たる

導入事例には、後から効率を押し上げた工夫が1つ書かれています。Gemini Enterprise の暗黙のプレフィックスキャッシュ（implicit prefix caching）を使うため、プロンプトの構成を組み替え、動かないポリシー文がキャッシュに当たるようにした、というものです。分類の品質を落とさずに効率が上がったとされています。

この挙動は Gemini API の公式ドキュメントにも説明があります。暗黙のキャッシュは Gemini 2.5 以降のモデルで既定で有効になっており、設定は要りません。キャッシュに当たった場合は費用の削減が自動的に反映されるとされています。当たりやすくするための助言として、大きくて共通する内容をプロンプトの先頭に置くこと、似た先頭部分を持つ要求を短い時間のうちに送ること、が挙げられています。あわせて、キャッシュの対象になる最小のトークン数がモデルごとに示されているため、短いプロンプトでは対象にならない点にも注意が要ります。

実務に移すと、やることは地味です。プロンプトのうち全件で同じ部分と、文書ごとに変わる部分を分け、同じ部分を前に寄せる。分類の指示文やポリシーの定義は前者、対象の文書は後者です。順序を入れ替えるだけなので、品質の検証をやり直す必要もほとんどありません。大量に同じ指示を送る処理を持っているなら、最初に確認する価値があります。

公表されている数値と、公表されていないこと

数値を整理します。いずれも導入事例に書かれている値で、原文の数字列のまま記載します。

分類の対象として書かれているのは、Scribd と Slideshare に投稿された文書です。会社案内ページには Everand と Fable も製品として並んでいますが、今回の遡及処理がそこまで及んだとは書かれていません。範囲を広げて読まないでください。

期間の書き方にも幅があります。導入事例は「This past year」に行った取り組みだとし、処理そのものは「in a matter of months」で終えたとしています。開始日と終了日は示されていないため、何か月だったのかは確定できません。

確認しようとして見つからなかった項目を残します。

確認したかった項目	記載の状況	どう扱うか
処理にかかった費用の総額	記載がありません	自社の試算の根拠にしない
分類の精度（適合率・再現率）	記載がありません	品質の水準として引用しない
対象期間の開始日と終了日	「数か月」とだけ記載	期間を特定して語らない
ポリシーの区分の数と内容	記載がありません	どんな分類体系かは不明
人が確認した割合	記載がありません	完全に無人だったと読まない
Everand と Fable の扱い	対象は Scribd と Slideshare	全製品に及んだと読まない
言語ごとの精度の差	記載がありません	日本語での性能は確認できない

導入事例に書かれていない項目が多いのは普通のことです。問題になるのは、社内の資料でこの空欄を自分たちの見立てで埋め、出典付きの事実と混ぜてしまうときです。行を分けて書いてください。

日本の実務者が確認できること

第一に、「これからの分」と「過去の分」を別の仕事として見積もることです。新規投稿の審査は件数が少なく即時性が要るため、同期の呼び出しが向きます。過去の棚卸しは件数が多く即時性が要らないため、まったく別の構成が向きます。この2つを1つの要件にまとめると、即時性の条件に引きずられて棚卸しの費用が跳ね、着手できなくなります。

第二に、入力の形式をそのまま渡せるかを先に確かめることです。この事例で消えた工程は、モデルの性能ではなく入力の受け口から来ています。PDFをPDFのまま渡せたから、OCRも描画も要らなくなりました。自社の資料が画像なのかPDFなのか、紙面の体裁に意味があるのかを棚卸しし、前処理を作らずに済む経路があるかを調べるほうが先です。

第三に、即時性の要らない処理をバッチへ移すことです。Batch API の記載では、費用は標準の50%、目標の所要時間は24時間です。夜間に回して翌朝に受け取れる仕事であれば、モデルを変えずに単価だけを下げられます。あわせて、同じ文面を先頭に寄せてキャッシュに当てる余地がないかも確認してください。

第四に、点検の工程を最初から設計に入れることです。この事例は、安いモデルで全件を分類したあと、別のモデルで全件を点検しています。品質を人の抜き取りだけに頼らない作り方として参考になりますが、食い違いが出たときに誰がどう決めるかは別に用意する必要があります。現場の担当者がそれぞれAIの使い道を作っていく形の設計はGE Appliancesがエージェントを配った事例にまとめています。

一度きりの棚卸しが、常時の検査に変わった

この事例でいちばん効いているのは、終わらせ方です。導入事例によると、遡及処理のために作った仕組みはそのまま運用に残り、新しく投稿された文書も同じ分類の経路を通るようになりました。定期的に掃除をするのではなく、常に評価された状態を保つ形へ移っています。Cloud Storage に置いたPDFをバッチ予測に通し、結果をデータ基盤へ戻すという形が単純だったため、ほかの内容理解の仕事にも同じ型を広げているとされています。

Sebastian 氏は、その変化をこう述べています。「This project changed how we think about our roadmap. Work we had classified as multi-year, multi-team efforts is now a prompt, a batch pipeline, and a few weeks of runtime.」年単位・複数チームの取り組みに分類していた仕事が、プロンプトとバッチのパイプラインと数週間の実行時間になった、という意味です。

変わったのは分類の精度ではなく、着手できる仕事の範囲です。やらなかった理由が「技術的に無理だから」ではなく「見積もりが大きすぎて優先順位が付かないから」であった仕事は、どの会社にも残っています。自社の積み残しを見直すときは、精度の議論から入らず、即時性・入力形式・単価の3つを先に並べ替えてみてください。順番を変えるだけで、見積もりの桁が動くことがあります。