Poyoを使うと、小規模チームはユーザー生成コンテンツモデレーションに無料のAIチェックを追加できます。Omni Moderationで投稿、コメント、レビュー、静止画像を評価し、カテゴリーの結果をチームがすでに使用しているルールやレビューツールに接続できます。
実務上の利点は、繰り返し実行できる初回評価です。対応コンテンツを送信し、タスクを追跡して、結果を取得するか完了コールバックを受け取ります。チームはそのシグナルを使って通常の投稿を振り分け、文脈が必要なケースに人の注意を集中できます。
まずは、Playgroundで1つのコンテンツサーフェスと、代表的な例をいくつか用意します。このガイドでは、無料チェックを公開ルール、レビュー担当、ユーザーの異議申し立てに接続し、投稿数が増えてもプロセスを管理しやすくする方法を説明します。
実際に担当するコンテンツと意思決定を特定する
ユーザー生成コンテンツ、つまりUGCとは、人々がプロダクトに投稿する素材を指します。コミュニティの投稿、コメント、プロフィール写真、商品レビュー、商品掲載文、アップロードされた画像などが含まれます。
ツールを選ぶ前に、一覧を作成します。それぞれの種類がどこに表示され、誰が閲覧でき、ユーザーが編集できるか、またどの程度の速さで判断する必要があるかを記録します。公開表示されるプロフィール画像と、作成者だけが見られる下書きでは、結果が異なります。
アプリケーション内のコメントやストアの商品写真など、既存の公開ツールに接続されたサーフェスを選びます。Poyoの評価結果は、タスクの結果とコールバックを通じて、これらのツールに連携できます。外部ソーシャルプラットフォーム上のコンテンツも管理する場合は、そのプラットフォームの認証済みインテグレーションを使って公開や削除の操作を行います。
Trust & Safety Professional Associationは、モデレーションを、運用、プロダクト、エンジニアリングに支えられたポリシーの執行と説明しています。小規模な会社では、1人がそのうち複数の機能を担当することがあります。それでも責任範囲は明確にする必要があります。
人が適用できるルールから始める
役立つルールは、行動を示し、その適用範囲を説明し、利用できる対応を明記します。「コミュニティを安全に保つ」は意図を表しますが、難しい投稿への対応を決めることはできません。
たとえば、プロダクトでは次のように記述できます。「他のメンバーに対する直接的な脅迫は禁止します。脅迫の疑いがある投稿はレビューのため保留し、緊急の対応が必要な場合はエスカレーションプロセスを使用します。」これにより、レビュー担当者は具体的なカテゴリーと次の対応を把握できます。
ルールをモデルのカテゴリー名とは分けて管理します。有害コンテンツモデルが関連するフラグを返さなくても、コミュニティで反復的な広告を禁止することはできます。ニュースコミュニティでは、暴力についての適切な議論を許可しながら、メンバーへの脅迫は禁止することもできます。
| ポリシー領域 | チームが定義すべき内容 |
|---|---|
| 脅迫とハラスメント | どの行動がルール違反となるか、どのようにエスカレーションするか |
| 性的または生々しいコンテンツ | 各サーフェスで何が許可され、何をレビューする必要があるか |
| スパムと広告 | 反復、リンク、プロモーションに関する制限 |
| 個人情報 | 何を共有でき、露出にどう対処するか |
| 話題から外れた投稿や低品質な投稿 | 移動、編集、却下、変更依頼のどれを行うか |
| 意思決定への異議申し立て | 誰が異議申し立てをレビューし、何を修正できるか |
Omni Moderationが対応する有害コンテンツカテゴリーと、プロダクトですでに使用しているチェックを組み合わせます。スパム、個人情報、投稿品質、異議申し立てには、専用のルール、ツール、またはレビュー担当者が必要です。それぞれの要件を具体的な手順に割り当てると、プロセス全体を運用しやすくなります。
いくつかの例を使って文言をテストします。2人のレビュー担当者が同じルールを異なる方法で適用する場合は、自動化によって判断を一貫させようとする前に、ルールを明確にします。
モデレーションを実行するタイミングを選ぶ
タイミングは、露出とユーザー体験の両方に影響します。各コンテンツサーフェスについて定義します。
公開前。 必須のチェックと判断が完了するまで、コンテンツを保留します。公開画像のアップロードや、チームが事前確認を選択した投稿に適しています。また、待機が必要な理由をユーザーに明確に説明する必要があります。
公開後。 コンテンツを表示し、その後で評価します。初期段階での摩擦は減りますが、対応が行われるまで禁止コンテンツが表示される可能性があります。チームには、その露出に見合った対応プロセスが必要です。
報告後。 ユーザーが問題を報告し、チームがレビューします。報告は文脈や見逃したケースを明らかにするのに役立ちますが、誰からも報告されないコンテンツは調査されないまま残る可能性があります。
混合型のプロセスも実用的です。たとえば、新しいプロフィール写真は公開前に保留し、コメントには通常のテキストチェックを実行し、両方について報告を受け付け続けることができます。これは設計例であり、普遍的なポリシーではありません。
これらのアプローチの概要については、Streamのコンテンツモデレーションガイドを参照してください。オーディエンス、露出、利用可能なレビュー能力に基づいて選択します。
モデレーションワークフローに無料のAIチェックを追加する
Poyoでは、多言語テキスト、単一のHTTPS画像、または画像付きテキストを1つのタスクフローにまとめられます。テキストは13のリスクカテゴリーに対応し、画像は性的コンテンツ、暴力、自傷行為を対象とする6つのカテゴリーに対応します。カテゴリーのフラグとスコアにより、どの投稿を通常のルールで処理でき、どの投稿を詳しく確認する必要があるかを判断するためのシグナルをアプリケーションに提供します。
カテゴリーの概要を使って、それぞれのチェックを対応する入力に割り当てます。テキスト専用のカテゴリーでは画像のピクセルを評価できません。ポリシーが埋め込みテキスト、音声、動画、または専門的な検出に依存する場合は、適切な別の処理手順を追加します。画像の対応範囲と子どもの安全に関する取り扱いについては、画像モデレーションガイドを参照してください。
実務的な手順は次のとおりです。
- 投稿を受け取り、コンテンツIDとバージョンを記録します。
- アプリケーションでテキストまたはアップロードされたファイルを検証します。
- 対応するテキストまたは画像をPoyoに送信し、タスクIDを保存します。
- 完了した結果を取得するか、完了コールバックを受け取ります。
- ルールを適用して公開、変更依頼、却下、またはレビュー担当者への割り当てを行います。
- 判断を記録し、報告と異議申し立ての経路を維持します。
PoyoのタスクIDを使うと、評価を正しい投稿に関連付けられます。完了コールバックは、既存のアプリケーションやレビューツールで次の手順を開始できます。対応する各シグナルを業務上の対応にどのように割り当てるかを設定し、文脈やエスカレーションが必要なケースには人によるレビューを行います。
小規模チームが管理できるレビュージキューを設計する
パイロットでは、既存のサポートツールや管理ツールで十分な場合があります。各レビュー項目には、レビュー担当者が履歴全体を再構成しなくても判断できるだけの情報を含めます。
コンテンツそのもの、または制御された閲覧方法、関連する文脈、検討対象のルール、モデルのシグナル、コンテンツのバージョン、このケースに必要な過去の判断を含めます。担当者とステータスも追加し、2人が同じ項目を知らずに作業しないようにします。
有用なステータスには、評価待ち、人によるレビュー待ち、承認済み、却下済み、異議申し立て中などがあります。技術的な失敗は別に追跡します。「画像を取得できなかった」は、コンテンツポリシー上の判断ではありません。
チームが実際に維持できる優先度を設定します。潜在的に深刻な脅迫は、判断が不確かな商品写真よりも迅速なエスカレーションが必要になる場合があります。担当者と代替担当者を定義し、どちらも対応できない場合の処理も決めます。
キューが増えた場合は、ルールを緩める前に原因を調べます。誤ったフラグが多すぎる、ポリシーが不明確である、タスクが重複している、またはチームが評価していない新しいコンテンツパターンがある可能性があります。それぞれの問題には異なる対応が必要です。
文脈と異議申し立てをプロセスに含める
自動化されたシグナルでは、ユーザーが何のために投稿したのかを見逃すことがあります。苦情の中で引用されたハラスメント、歴史的な出来事についての議論、教育目的の画像などでは、初回評価だけでは完全に捉えられない文脈が必要になる場合があります。
レビュー担当者が判断を下したら、適用したルールと理由を記録します。ユーザー向けの文言では、有害な素材を不必要に再現せず、次に何が起こるかを説明します。
たとえば、「この画像は生々しいコンテンツに関するルールに該当する可能性があるため、レビューを待っています」は保留中のケースを説明します。「画像チェックを完了できなかったため、再試行する間、アップロードは非公開のままです」は技術的な遅延を説明します。これらのメッセージは、ユーザーに異なる有用な見通しを伝えます。
異議を申し立てられる判断には、異議申し立ての経路を用意します。レビュー担当者は、元のコンテンツバージョン、関連する文脈、以前の理由、ユーザーからの新しい説明を確認できる必要があります。人員に余裕がある場合は、異議申し立てを別の担当者が扱います。
判断が変わった場合は、コンテンツの実際の公開状態と、関連するアカウント対応を更新します。意図した状態を復元せずに謝罪だけを送っても、根本的なエラーは解決されません。
否定的であるという理由だけで、批判をポリシー違反として扱わないようにします。レビューを基盤とするプロダクトでは、BazaarvoiceのUGCモデレーションに関する解説が、本物の否定的なフィードバックを保持する重要性を強調しています。ルールでは、批判的な顧客体験と、嫌がらせや禁止された情報開示を区別する必要があります。
判断の品質と作業量を測定する
チームが具体的な問題を見つけるのに役立つ指標から始めます。投稿量、完了した評価、処理の失敗、保留中のレビューは作業量を示します。レビューの所要時間と異議申し立ての結果は、ユーザーが経験することを示します。
分類と振り分けを評価するには、ポリシーが期待する判断で許可サンプルにラベルを付けます。ワークフローがフラグを付けたコンテンツと、そのまま通過させたコンテンツの両方を含めます。レビュージキューだけを見ても、システムが見逃したものをすべて明らかにすることはできません。
次の例は完全に説明用のものであり、Poyoやモデルのベンチマーク性能を示すものではありません。
| 100件の投稿サンプル | レビューに送信 | レビューに送信せず | 合計 |
|---|---|---|---|
| 人がラベル付けしたポリシー違反 | 18 | 2 | 20 |
| 人がラベル付けした許容コンテンツ | 8 | 72 | 80 |
| 合計 | 26 | 74 | 100 |
このサンプルからは、3つの異なる問いが生まれます。
- キューのうち、どの程度が該当していたか? フラグが付いた26件のうち、18件が違反とラベル付けされました。18 ÷ 26、約69.2%です。
- 違反をどの程度検出できたか? ラベル付けされた20件の違反のうち、18件にフラグが付けられました。18 ÷ 20、つまり90%です。
- 許容コンテンツにどの程度フラグが付いたか? 許容された80件のうち、8件にフラグが付けられました。8 ÷ 80、つまり10%です。
これらの指標は分母が異なるため、1つの「正確性」という主張にまとめるべきではありません。その背後にあるケースをレビューします。チームには、より明確なルール、異なるしきい値、別のチェック、またはより多くの文脈が必要かもしれません。
実運用では、未解決の異議申し立ても数え、最も古い待機項目の経過時間を確認します。完了数が多くても、少数のケースが長時間待たされていることを隠している可能性があります。
Poyoを既存のレビューツールに接続する
ユーザーが投稿する言語と画像スタイルをテストするには、Omni Moderation Playgroundを使用します。サインインして代表的な例を実行し、コードを書いたりAPIキーを手動で作成したりせずにカテゴリーの結果を確認します。
アプリケーションからリクエストする場合は、POST /api/generate/submit、model: "omni-moderation-latest"、および対応するテキストまたは画像フィールドとともにPoyo APIキーを使用します。同じPoyo認証情報で、対応する他のモデルにもアクセスできます。これにより、生成とモデレーションを共通のプラットフォームインテグレーション内で管理しやすくなります。
返されたタスクIDをコンテンツのバージョンとともに保存します。ステータスを照会するか、オプションのcallback_urlを設定して、完了した評価で公開システム、サポートツール、またはレビュージキューのレコードを更新できるようにします。振り分けを定義し、公開やレビュー担当者の割り当てを実行するのはアプリケーションです。
ステータスレスポンスからはdata.output.resultsを、コールバックからは外側のラッパーを省いたoutput.resultsを読み取ります。finishedタスクには完了した評価が含まれ、flagged: trueは潜在的なコンテンツリスクを示します。failedタスクは、別の技術的な再試行経路で扱います。
編集された投稿や差し替えられた画像は、新しいバージョンとして再評価します。コールバック処理は繰り返し実行しても安全にし、重複配信によって同じレビュー記録を更新できるようにします。また、古い結果が新しい判断を上書きしないようにします。
レビュー記録へのアクセス権限と保持ルールを設定し、本番データを送信する前に適用されるサービス規約を確認します。Poyoリファレンスではリクエストの契約を説明し、Webhookガイドではコールバックの統合を扱っています。
よくある質問
ユーザー生成コンテンツモデレーションとは何ですか?
ユーザー生成コンテンツモデレーションとは、投稿、コメント、レビュー、写真など、ユーザーが送信した素材をプラットフォームのルールに照らしてレビューするプロセスです。潜在的な違反の検出、対応方法の決定、報告や異議申し立ての解決が含まれます。
Poyoは小規模なモデレーションチームをどのように支援しますか?
Poyoは、対応するテキストと画像について、カテゴリーシグナル、タスク追跡、オプションの完了コールバックを備えた無料の初回評価を提供します。チームはその結果を使って既存のツールで投稿を振り分け、文脈が必要なケースにレビュー担当者を集中させることができます。まずは1つのコンテンツサーフェスと、チームが一貫して適用できるルールから始めます。
どのモデレーション手順を自動化できますか?
アプリケーションからコンテンツを送信し、タスクIDを保存し、評価を取得し、コールバックを処理して、レビュー記録を更新できます。独自の例でルールをテストした後は、定義された公開操作や振り分け操作も自動化できます。Poyoが提供するのは評価結果とタスク処理です。業務上のルール、エスカレーション、異議申し立てはチームが設定します。
繰り返しの手動レビューを減らすにはどうすればよいですか?
コンテンツのバージョンごとに1つの記録を保持し、それをPoyoのタスクIDに関連付け、コールバック処理を繰り返し実行しても安全にします。これにより、アプリケーションが重複したレビュー項目を作成するのを防ぎやすくなります。ラベル付きの例を使ってカテゴリーの振り分けを調整し、許容される投稿がキューに入る理由を確認すると同時に、見逃した違反も継続して確認します。自動化を拡大する前に、その効果を測定します。
Poyoを既存のレビューツールに接続できますか?
ステータス照会または完了コールバックを使って、分類結果をアプリケーションの公開システム、サポートツール、レビュージキューに送信します。記録には、コンテンツID、バージョン、カテゴリーシグナル、適用するルールを含めます。レビュー担当者の割り当てと公開操作はインテグレーションが処理するため、チームは既存のツールを使い続けられます。
無料で始めるにはどうすればよいですか?
1つのサーフェスを選び、関連するルールを定義して、Poyo Playgroundで代表的なテキストまたは画像をテストします。この試用では、コードも手動で作成したAPIキーも必要ありません。Omni Moderationの呼び出しにクレジットはかかりません。振り分けの準備が整ったら、APIを既存のワークフローに接続し、ストレージとレビュー担当者の時間は別途計画します。
AIコンテンツモデレーションの概要でシグナルの解釈方法を確認し、コストガイドで無料の呼び出しを前提に作業を計画します。