8月22日、InfoQが「SafeChat: Building AI-Powered Safety Systems at Scale in a Real-Time Marketplace」と題した記事を公開した。この記事では、DoorDashが構築したLLMハイブリッドモデレーション基盤「SafeChat」の設計思想と実装詳細について詳しく紹介されている。
「LLMに全部投げる」では通用しない理由
DoorDashのプラットフォームでは、1日あたり400万件以上のチャットメッセージ、40万件以上の通話、20万件以上の画像がユーザー間で交わされる。消費者・配達員・飲食店という3者がリアルタイムで交流する場であり、配達中の会話は最短6分で完結する。問題が起きたとき、即座に対処しなければならない。
最初に検討されたのは「LLMにメッセージを投げて安全か判断させる」シンプルな構成だ。しかし、現実的には2つの壁がある。LLM呼び出しのレイテンシは平均2〜10秒とばらつきが大きく、チャット体験を著しく損なう。さらに、400万件/日のLLM呼び出しコストは現実的ではない。
DoorDashのSrエンジニア・Bruna Pereiraが選んだのは、「LLMの使いどころを絞る」アーキテクチャだった。
2層フィルタリング：安価な層と高価な層
まず数ヶ月かけてデータ分析を行い、実際に「unsafe」なメッセージは全体の数%程度に留まることを確認した。この事実がアーキテクチャ全体を規定した。
第1層：内製小型分類器（目標レイテンシ < 100ms）
自社インフラ上で動くMLモデル。役割は「明らかに安全なメッセージを弾く」だけに特化している。空メッセージ・画像添付・定型的な挨拶文を除去したうえで判定し、全メッセージの90%以上をここで処理する。空港の金属探知機のような役割であり、「危険かどうか」を判断するのではなく「詳しく見るべきか」を振り分けるだけだ。なお、100ms未満というのは第1層の応答時間要件であり、第2層のLLMについては処理対象が全体の10%未満に絞られることでスループット要件が緩和される設計になっている。
第2層：LLMによるスコアリング（残り< 10%）
第1層で安全と判定できなかったメッセージだけをLLMに送る。ここでのポイントは、「このメッセージは安全か？（Boolean）」を聞かないことだ。代わりに複数の軸でスコアを出力させる。
- 脅迫度（threatening）
- 冒涜度（profane）
- 性的度（sexual）
Pereiraはこの設計についてプレゼンテーション内でおよそ次のように述べている。「BooleanはフラグだがスコアはKnob（ノブ）だ。スコアがあれば段階的なアクションが取れる。閾値も後から調整できる。カテゴリも追加できる。LLMの得意領域を活かした聞き方でもある」。
スコアに応じた段階的アクション
スコアが出れば、深刻度に応じたアクションを自動化できる。
| 深刻度 | 例 | アクション |
|---|---|---|
| 低 | 軽い罵倒語 | メッセージをマスクして通過させる |
| 中 | 侮辱 | メッセージをブロック |
| 高 | 脅迫 | ブロック＋被害者側に無料キャンセルを提供 |
| 最高 | 重大な脅威 | ブロック＋オーダーキャンセル＋加害者への警告＋被害者を完全に切り離す |
この仕組みを音声・画像にも展開した。画像はOCRや分類の代わりに外部のビジョンAPIを第1層として利用する。音声は「検出時点ですでに相手に届いている」という制約から、通話を即時切断して注文キャンセルを提示するという形で対応している。
SafeChat導入後、言語的ハラスメントに起因するインシデントが約50%減少した。 元記事（発表資料）でPereiraが報告している数値であり、モデル精度の改善ではなく実際の人的被害の削減として計測されたものとされている。ただし、計測期間や比較基準（導入前の期間・指標の定義など）の詳細は発表資料内では明示されておらず、数値の解釈には留意が必要だ。
SafeChat 2.0：汎用モデレーションプラットフォームへ
SafeChat が社内で注目され始めると、別チームから要望が相次いだ。「Dasherのプロフィール画像もモデレートしたい」「会員登録時の名前もチェックしたい」「飲食店レビューも対象にしたい」「チャットでの不正検知もできないか」。
これらすべてにゼロから対応するのは非効率だと判断し、DoorDashはコンテンツ非依存のモデレーションプラットフォームを構築し直した。システムは業種や内容のセマンティクスを知る必要がない。プラットフォームが担うのは「ロギング」「モデルプロバイダーとの統合」「ステップ間の条件分岐」だけで、業務ロジックはチームが持ち込む。
プラットフォームが提供する3種のモデル構成要素：
- 内製モデル（Internal Models）：自社MLプラットフォームでトレーニング・ファインチューニング・デプロイ。SafeChat の小型分類器もここに位置付けられた
- 外部モデル（External Models）：既にサービス化されている商用APIをそのまま利用。画像安全判定などはすでに十分な精度があり再実装しない
- 外部プロンプト（External Prompts）：LLMゲートウェイを介し、任意のベンダーのLLMにプロンプトを送る。フォールバック戦略やリトライ戦略も設定可能
これらを組み合わせて「モデレーションエージェント」と呼ばれるワークフローを構成する。発表資料によれば、各ステップの条件分岐はUIから設定できる設計とされており、エンジニアリング工数なしで新規ユースケースに対応できることが目標として示されている。なお、ノーコードでの設定範囲や実際の運用上の制約については発表資料内で詳述されていないため、詳細は元資料の確認を推奨する。
設計上の最重要ポイント
この発表で最も汎用性が高いのは、PereiraがLLM活用設計の核心として繰り返し強調した以下の考え方に集約される。
LLMにBooleanではなくスコアを返させること。
安全・危険の2値判定はLLMに不向きで、判定ブレが生じやすい。それよりも「この文章はどの程度脅迫的か」のように軸を定義してスコア化させる方が安定し、アクションの細分化も容易になる。「cheap層でスループットを確保し、expensive層でインテリジェンスを発揮する」という2層構造と組み合わせると、コスト・レイテンシ・精度のバランスを同時に取りやすくなる。
LLMをプロダクション環境に組み込む際の現実的な制約（レイテンシ・コスト・判定の安定性）に正面から向き合い、「どこでLLMを使い、どこで使わないか」を明示した設計事例として、参考になる部分が多い。
詳細はSafeChat: Building AI-Powered Safety Systems at Scale in a Real-Time Marketplaceを参照していただきたい。
