メインコンテンツへスキップ
ご注意ください X API v2 向けに新しいコンプライアンスツールであるバッチコンプライアンスをリリースしました。このツールを使うと、Post またはユーザーの id からなる大規模データセットをアップロードし、そのコンプライアンス状態を取得して、データセットを適合させるために対応が必要なデータを特定できます。
また、バッチコンプライアンスとコンプライアンス Firehose の両方が Post の編集に対応するよう更新されました。コンプライアンス Firehose には新たに「tweet_edit」イベントが追加されています。詳細はCompliance Data Objectsのドキュメントをご覧ください。Edit Posts の基本ページでは、Edit Post メタデータの仕組みについて詳しく説明しています。

​
概要

Enterprise X の中核的な価値のひとつは、ユーザーの声を守り尊重することです。これには、ユーザーが X 上で共有するコンテンツを削除・変更・編集するときの期待や意図を尊重することが含まれます。これは、世界最大級の公開リアルタイム情報プラットフォームの長期的な健全性にとって極めて重要であると私たちは考えています。X はコントロールをユーザーの手に委ね、各個人が自身の X 体験を管理できるようにしています。X のデータを受領するビジネス利用者には、エンドユーザーの期待と意図を尊重する責任があると信じています。 X プラットフォームで発生し得るコンプライアンスイベントの種類については、記事「X におけるユーザーの意図の尊重」を参照してください。 API を通じて X のデータを利用するすべての開発者や企業には、ユーザーコンテンツの変更を尊重するために、合理的に可能なあらゆる努力を尽くす義務があります。この義務は、削除、変更、共有オプションの変更（例: コンテンツが保護対象になる、または公開停止される）などのユーザーイベントにも及びます。ユーザーが自身の Post を編集した場合も含まれます。この義務が X データの利用にどのように影響するかについては、Developer Policy および/またはお客様の X Data Agreement の該当箇所を参照してください。 X は、これらのユーザーコンプライアンスイベントに関する情報と、特定の Post または User が公開状態か否かを提供する以下のソリューションを提供しています。各ソリューションの概要と一般的な統合パターンを以下に示します。

​
GET statuses/lookup と GET users/lookup

  • 形式: REST API。参照: GET statuses/lookup および GET users/lookup。
  • これらのエンドポイントは、常にPostの編集に関する最新バージョンを返します。編集機能の導入以降に作成されたPostを表すすべてのPostオブジェクトには、Post編集メタデータが含まれます。これは、実際に編集されていないPostでも同様です。
  • すべてのPostについて、作成から30分を超えて行われたリクエストでは、Postの最終状態が返されます。
  • APIリクエスト内で呼び出し元が指定した特定のPostまたはUserの可用性情報を返します。
  • 特定のPost／Userグループの現在の可用性状態をアドホックにスポットチェックする用途に使用できます。
  • 特定の時点における特定のPostまたはUserの現在の状態を確認する必要があるお客様に最適です。
  • これらのAPIは、コンテンツの可用性を確認する必要があるお客様に役立つ手段を提供します。たとえば次の場合:
    1. Postの表示
    2. PostやUserとの1対1でのエンゲージメント
    3. 許可されたファイルダウンロードを通じたXコンテンツの第三者への配信
    4. Postの長期保存

​
Compliance Firehose（エンタープライズ限定）

  • 形式: ストリーミング API　詳細: Compliance Firehose。
  • X 上のコンプライアンスアクティビティをリアルタイムでストリーミング配信します。これらのアクティビティには、Post の編集などが含まれます。
  • プラットフォームで新たなコンプライアイベントが発生するたびに、保存済みデータ一式のコンプライアンス状態を維持する用途に利用できます。
  • X のデータを長期間にわたり大量に収集・保存するお客様に最適です。

​
ガイド

​
コンプライアンスのベストプラクティス

​
推奨事項とベストプラクティス

  • 数値の Post ID と User ID を格納するデータストレージスキーマを設計する: ユーザーに関するメッセージは、そのユーザーのすべての Post に対してアクションが必要です。すべてのコンプライアンスメッセージは数値 ID のみで配信されるため、数値 ID に基づいて Post と User の関係を保持できるよう、ストレージスキーマを設計することが重要です。データ利用者は、Post ID と User ID の両方でコンプライアンスイベントを監視し、ローカルデータストアを適切に更新できる必要があります。
  • すべてのコンプライアンスステータスに対応するスキーマを構築する: アプリケーションでのコンプライアンス対応方法によっては、データストアに追加のメタデータを持たせる必要がある場合があります。たとえば、status_withheld メッセージの対象となる国でのコンテンツ表示制限を容易にするため、既存のデータベースにメタデータを追加する判断をすることがあります。
  • リツイート削除の取り扱い: リツイートは、元のメッセージがその内部のオブジェクトとしてネストされる特殊な種類の Post です。この場合、リツイートでは 2 つの Post ID が参照されます—リツイート自体の ID と、ネストされたオブジェクトに含まれる元のメッセージの ID です。元のメッセージが削除されると、元の ID に対して Post の削除メッセージが発行されます。Post の削除イベントは通常、すべてのリツイートの削除イベントを誘発しますが、場合によってはすべてが送信されないことがあるため、クライアントシステムは不完全なリツイート削除に耐性を持つべきです。元の ID の削除だけで、後続のすべてのリツイートを削除するには十分なはずです。ベストプラクティスとして、リツイートを保存する際は元の Post ID を参照し、Post の削除イベントを受信した際には参照されているすべてのリツイートを削除することを推奨します。

​
コンプライアンス・データオブジェクト

​
Compliance Firehose API

想定されるコンプライアンスイベントには、Post（または「status」）イベントとUserイベントが含まれ、各種タイプは以下のとおりです。   ご留意ください：
  • Userのステータスの詳細はこちら、削除されたPostに関する開発者向けポリシーはこちらをご覧ください。
  • Compliance Firehoseは’tweet_edit’イベントに対応するよう更新されました。 
  • 一部のUserのdelete、protect、suspendイベントは必ずしも恒久的ではなく、状態が無期限に切り替わる可能性があります。これには、user_delete、user_undelete、user_protect、user_unprotect、user_suspend、user_unsuspendが含まれます。
  • user_deleteの後続としてのstatus_deleteは、ユーザーがアカウントのuser_undeleteを選択していない場合に限り30日後に発生します。user_deleteがユーザーによって取り消され、そのユーザーのすべてのPostに対する30日後の削除が発生しない可能性があります。
  • user_suspendは、ユーザーがuser_unsuspendイベントの対象とならない限り有効のままです。これらは30日間の猶予期間による変更の対象ではありません。
エンドユーザーのプライバシーと意図を尊重するため、各イベントタイプの処理方法については「Recommended Action」列を参照してください。
Original Message TypeObjectPermanent (Yes/No)Recommended Action
deleteStatusYes関連するPostを削除。
status_withheldStatusYesstatus_withheldメッセージに記載の特定の国で関連するPostを抑止する。
dropStatusNoPostを公開表示から外す。
undropStatusNoStatusは再度表示され、公開として扱われ得る。
tweet_editStatusYes変更を反映し、該当する場合は新しい編集内容を表示する。
user_deleteUserNo当該ユーザーのすべてのPostを抑止または削除する。
user_undeleteUserNo当該ユーザーのすべてのPostは再度表示され、公開として扱われ得る。
user_protectUserNo当該ユーザーのすべてのPostを抑止または削除する。
user_unprotectUserNo当該ユーザーのすべてのPostは再度表示され、公開として扱われ得る。
user_suspendUserNo当該ユーザーのすべてのPostを抑止または削除する。
user_unsuspendUserNo当該ユーザーのすべてのPostは再度表示され、公開として扱われ得る。
scrub_geoUserYesscrub_geoメッセージで指定されたPost以前の、当該ユーザーのすべてのPostに対してXが提供した地理データを削除する。なお、その後のPostには利用可能な地理データが含まれる場合がある。
user_withheldUserYesuser_withheldメッセージに記載の特定の国で当該ユーザーのPostを抑止する。
deleteFavoriteYes関連するlike/favoriteを削除。

​
ペイロード例

上の表で説明した各コンプライアンスイベントのペイロード例を以下に示します。 Post の編集 
{"tweet_edit":
   {
     "id": "1557445923210514432"
     "initial_tweet_id": "1557433858676740098",
     "edit_tweet_ids": ["1557433858676740098", "1557445923210514432"],
     "timestamp_ms": "1660155761384"
   }
 }
Post の削除
{
  "delete": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220608",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}
保留された Post
{
  "status_withheld": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220608",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "withheld_in_countries": [
      "XY"
    ],
    "timestamp_ms": "1432228155593"
  }
}
ドロップ
{
  "drop": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220600",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}
Undrop
{
  "undrop": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220600",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}

​
位置情報の消去

{
  "scrub_geo": {
    "user_id": 519761961,
    "up_to_status_id": 411552403083628540,
    "up_to_status_id_str": "411552403083628544",
    "user_id_str": "519761961",
    "timestamp_ms": "1432228180345"
  }
}
ユーザーの削除
{
  "user_delete": {
    "id": 771136850,
    "timestamp_ms": "1432228153548"
  }
}
ユーザーの削除取り消し
{
  "user_undelete": {
    "id": 796250066,
    "timestamp_ms": "1432228149062"
  }
}
ユーザーの情報非公開
{
  "user_withheld": {
    "user": {
      "id": 1375036644,
      "id_str": "1375036644"
    },
    "withheld_in_countries": [
      "XY"
    ],
    "timestampMs": "2014-08-27T23:49:41.839+00:00"
  }
}
ユーザー保護
{
  "user_protect": {
    "id": 3182003550,
    "timestamp_ms": "1432228177137"
  }
}
ユーザーの保護解除
{
  "user_unprotect": {
    "id": 2911076065,
    "timestamp_ms": "1432228180113"
  }
}
ユーザーの一時停止
{
  "user_suspend": {
    "id": 3120539094,
    "timestamp_ms": "1432228194217"
  }
}
ユーザーのアカウント停止解除
{
  "user_unsuspend": {
    "id": 3293130873,
    "timestamp_ms": "1432228193828"
  }
}

​
Compliance Firehose の統合

Compliance Firehose は、X プラットフォーム上で発生するコンプライアンスイベントをリアルタイムで配信するストリーミング API です。X におけるコンプライアンスイベントの概要と生成方法については、X におけるユーザーの意図を尊重するをご参照ください。 Post と User のイベントはそれぞれ独立して配信され、個別に処理する必要があります（例：Post の削除は User イベントを意味せず、その逆も同様です）。いくつかの User イベントは必ずしも恒久的ではなく、状態が繰り返し切り替わる可能性があります。これらには user_delete、user_undelete、user_protect、user_unprotect、user_suspend、user_unsuspend が含まれます。 user_delete の後には、ユーザーがアカウントの user_undelete を選択しなかった場合に限り、30 日後に status_delete が発生します。ユーザーが user_delete を撤回した場合、そのユーザーのすべての Post に対する削除は 30 日後に発生しない可能性があります。 user_suspend は、ユーザーに対して user_unsuspend イベントが発生しない限り継続します。これらは 30 日という期間によるいかなる変更の対象にもなりません。 コンプライアンスイベントをソフトウェアの利用者に直接表示したり、製品やユーザー体験に組み込んだりすることは決して適切ではありません。これらは、コンプライアンスの維持と X ユーザーの行為を尊重することのみを目的としています。

​
Compliance Firehose との統合

Compliance Firehose をシステムに統合するには、以下を実行できるインテグレーションを構築する必要があります。
  1. Compliance Firehose の各ストリーミング API パーティションに対してストリーミング接続を確立する
  2. 大量データに対応する — 非同期プロセスを用いて、ストリームの取り込みを後続処理から分離する
  3. いかなる理由で切断された場合でも、ストリームパーティションに自動的に再接続する
  4. 上記のガイダンスに従い、保存している Post および User のデータに関連するコンプライアンスイベントを処理する

​
X におけるユーザーの意図を尊重する

私たちは、X ユーザーのプライバシーと意図を尊重することが、世界最大級の公開・リアルタイム情報プラットフォームの長期的な健全性にとって極めて重要だと考えています。X はプライバシー設定をユーザーに委ね、各個人が自身の X 体験をコントロールできるようにしています。X の data をビジネスで利用する立場として、信頼と敬意に基づく環境を維持するため、エンドユーザーのプライバシーと行動を尊重する共同責任があります。 プラットフォーム上での表示に影響を与え得る、Post やユーザーアカウントに起こり得る事象はさまざまです。プライバシーと意図に影響するアクションは、Status（Post）レベルおよびユーザーレベルの双方で定義されています。これらのアクションには次のものが含まれます。

​
ユーザー

アクション説明
アカウントを保護X のユーザーは、いつでも自分のアカウントを保護または保護解除できます。保護されたアカウントでは、そのアカウントの Post を閲覧できるユーザーを一人ひとり手動で承認する必要があります。 
詳細は、公開 Post と保護された Post についてをご覧ください。
アカウントを削除X のユーザーは、いつでも自分のアカウントと関連するすべてのステータスメッセージを削除できます。X は、ユーザーが削除を取り消して実質的にアカウントを再有効化できるよう、削除後 30 日間アカウント情報を保持します。
位置情報をスクラブX のユーザーは、いつでも過去の Post からすべての位置情報データを削除できます。これは「scrub geo」と呼ばれます。
アカウントを凍結X は、X ルールに違反しているアカウント、またはハッキングや不正アクセスの疑いがあるアカウントを凍結する権利を有します。アカウントの凍結解除は X のみが行うことができます。
アカウントを保留X は、特定の国において特定のコンテンツへのアクセスを必要に応じて差し止める（保留にする）権利を有します。保留となったアカウントの解除は X のみが行うことができます。 
詳細は、国別の差し止めコンテンツをご覧ください。

​
ステータス

アクション説明
ステータスの削除X のユーザーはいつでもステータスを削除できます。削除されたステータスは元に戻せず、恒久的に削除されます。
ステータスの保留X は、必要に応じて特定の国において特定のコンテンツへのアクセスを保留する権利を有します。保留されたステータスは、X のみが保留解除できます。
詳細は Country Withheld Content を参照してください。

​
ユーザーおよびステータスの変更の追跡

ユーザーまたはステータスの状態は、上記のいずれかのアクションによりいつでも変わる可能性があり、Xのdataを利用する側は、関連するすべてのコンテンツの利用可否およびプライバシーの扱い方にその影響を反映する必要があります。これらのアクションが発生すると、ステータスまたはユーザーの状態が変更されたことを示す対応するコンプライアンスメッセージが送信されます。

​
API リファレンス

​
GET compliance/firehose

​
メソッド

メソッド説明
GET /compliance/:streamデータストリームに接続

​
認証

Compliance Firehose API へのすべてのリクエストは、console.gnip.com のアカウントにログインする際に使用する有効なメールアドレスとパスワードの組み合わせから生成した HTTP ベーシック認証を使用する必要があります。各リクエストの Authorization ヘッダーで認証情報を送信してください。

​
GET /compliance/:stream

Compliance firehose データストリームへの永続的な接続を確立し、これを通じてコンプライアンスイベントが配信されます。
Request MethodHTTP GET
Connection TypeKeep-Alive
URLダッシュボードのストリームの API Help ページに記載されており、次の構造に類似します:


https://gnip-stream.x.com/stream/compliance/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1

Note: “partition” パラメータは必須です。全ボリュームのそれぞれ 12.5% を含む 8 つのパーティションすべてに接続する必要があり、フルストリームを取得するには全てに接続してください。
CompressionGzip。Gzip 圧縮を使用してストリームに接続するには、接続リクエストで Accept-Encoding ヘッダーを送信します。ヘッダーは次のとおりです:

Accept-Encoding: gzip
Character EncodingUTF-8
Response FormatJSON。レスポンス形式として JSON を指定するヘッダーを設定してください。
Rate Limit60 秒あたり 10 リクエスト。
Read Timeoutクライアントで読み取りタイムアウトを設定し、30 秒を超える値にしてください。
Support for Tweet editsすべての Tweet の編集は “tweet_edit” コンプライアンスイベントをトリガーします。詳細は Compliance Data Objects ドキュメントをご参照ください。
Example Curl Request 次の例は、コマンドラインで cURL を使用して実行するリクエストです: 
curl --compressed -v -uexample@customer.com "https://gnip-stream.x.com/stream/compliance/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1"
注記: 上記のリクエストは Compliance firehose の partition=1 にのみ接続しています。ストリーム全体を取得するには、8 つすべてのパーティションに接続する必要があります。

​
レスポンスコード

これらのリクエストに対して、API からは以下のレスポンスが返される場合があります。多くのエラーコードには、本文に追加の詳細を含む文字列が返されます。200 以外のレスポンスの場合、クライアントは再接続を試みてください。
ステータステキスト定義
200成功接続は正常に確立され、到着次第、新しいアクティビティが送信されます。
401認証失敗無効な認証情報のため、HTTP 認証に失敗しました。リクエストで正しく使用できているか確認するため、認証情報で console.gnip.com にログインしてください。
406受理不可一般的には、クライアントがストリームの gzip 圧縮を受け入れるためのヘッダーを正しく含めていない場合に発生しますが、他の状況でも発生することがあります。本文には次のような JSON メッセージが含まれます。「この接続には圧縮が必要です。圧縮を有効にするには、リクエストに ‘Accept-Encoding: gzip’ ヘッダーを送信し、クライアント側で読み取り時にストリームを解凍できるようにしてください。」
429レート制限アプリが接続リクエストの上限を超過しました。
503サービス利用不可X サーバー側の問題です。指数バックオフ方式で再接続してください。この問題に関する通知が X API Status Page に掲載されていない場合は、サポートに連絡してください。

​
その他の推奨事項とベストプラクティス

  • 数値の Tweet ID と User ID を保存するデータストレージスキーマを構築する: ユーザーに関するメッセージは、そのユーザーのすべての Tweet に対する対応を必要とします。したがって、すべてのコンプライアンスメッセージは数値 ID でのみ配信されるため、数値 ID に基づいて Tweet と User の関係を保持できるストレージスキーマを設計することが重要です。データ利用者は、Tweet ID と User ID の両方でコンプライアイベントを監視し、ローカルデータストアを適切に更新できる必要があります。
  • すべてのコンプライアンスステータスに対応するスキーマを構築する: アプリケーションごとにコンプライアンス対応の方法は異なるため、データストアに他のメタデータを追加する必要が生じる場合があります。たとえば、データ利用者は、status_withheld メッセージの対象となる国でコンテンツ表示を制限しやすくするため、既存のデータベースにメタデータを追加する判断をすることがあります。
  • リツイート削除の取り扱い: リツイートは特殊な種類の Tweet で、元のメッセージがリツイート内のオブジェクトとしてネストされています。この場合、リツイートには 2 つの Tweet ID が参照されます — リツイート自体の ID と、（ネストされたオブジェクトに含まれる）元のメッセージの ID です。元のメッセージが削除されると、元の ID に対して Tweet の削除メッセージが発行されます。以後、すべてのリツイートに個別の削除メッセージが発行されるわけではありません。元の ID の削除のみで、その後のすべてのリツイートの削除に十分です。