画像や音声の投稿を審査しても、生成元を裏付ける根拠が結果から読み取れず、公開判定に迷っていませんか。
今週は、OpenAIが対応する来源信号を確認する目的でContent Provenance APIをアップロード審査に接続してください。これは汎用AI検出器ではなく、信号が未検出でもAI生成ではないとは判断できません。
コンテンツ審査や事実確認機能を開発する方は、呼び出し方と結果の扱いを確認できます。
画像の来歴確認を設計する技術責任者は、審査の配置と対応範囲を整理できます。
メディアのアップロード機能を保守する方は、ファイル形式や失敗時の分岐を点検できます。
接続前に確認する信号の対象範囲
OpenAIコンテンツ来歴検証APIは、対応するOpenAI由来の信号を調べるためのAPIです。世の中のあらゆる生成AIで作られた画像や音声を識別するものではありません。導入の目的は「AI生成かどうかを断定すること」ではなく、検出可能な来歴情報を審査材料に加えることです。
混同しやすい信号は、画像に付与されるC2PA Content Credentialsと、画像や音声に埋め込まれることがあるSynthIDです。OpenAIの説明では、対応する信号と検査結果の範囲が示されていますが、対応状況は製品、モデル、メディアの種類、加工や配信の経路で変わる可能性があります。OpenAIの来歴信号の説明とContent Provenance APIガイドを、実装時点で確認してください。
C2PAは、コンテンツに結び付いた来歴情報を検証するための仕様です。画像の再圧縮やメタデータの扱いによって情報が失われる場合があるため、仕様上も処理後のコンテンツと資格情報の関係を踏まえた確認が必要です。C2PA Content Credentialsの処理仕様も併せて参照すると、アップロード後の変換を検証経路に含めるべきか判断しやすくなります。
検査したい信号と入力可能なファイル形式は、同じ意味ではありません。音声由来の信号があることだけを根拠に、任意の音声ファイルをAPIへ送れると設計しないでください。対応形式とリクエスト要件は、現行のガイドで確認します。
第一段階：検証を置くタイミングを決める
検証をアップロード直後に行えば、公開前に結果を審査キューへ渡せます。一方、公開後の監査で使う設計なら、処理済みの画像ではなく、受け取った元ファイルを検証できるようにする必要があります。画像変換やメタデータ除去が先に走る構成では、確認できる信号が変わる可能性があります。
実装前に、次の流れを図にしてください。
- 受信したファイルの形式とサイズをアプリ側で確認する。
- 必要なら原本を安全な保管先に保存し、審査用のコピーを作る。
- 公式ガイドにある対応形式とリクエスト要件を照合する。
- 対応ファイルだけを検証APIへ送る。
- 検出、未検出、判定不能、呼び出し失敗を別々の審査状態にする。
- 検証結果、対象ファイルの識別情報、審査判断を必要な範囲で記録する。
投稿時にAPIを呼び出すなら、呼び出し待ちでアップロード全体が止まらない設計も検討してください。検証を非同期ジョブに分ける場合は、検証前・検証中・結果待ちの状態を公開処理と区別します。利用者の投稿をいったん保留するのか、他の審査だけ先に進めるのかは、誤検出時の影響と運用要件で選びます。
次にAPIを呼び出し、記録項目を固定する
公式のAPIリファレンスには、検証リクエストを作成するメソッドと、ファイルを送るための仕様が掲載されています。Python SDKを使う場合は、現在のSDKと引数を照合したうえで、公式の作成メソッドを使います。実装例は次の形を出発点とし、動作する実コードは現行の作成リクエスト仕様に合わせてください。
# media_file は、公式リファレンスで対応が確認できたファイルを開いたもの
result = client.content_provenance_checks.create(file=media_file)
SDKのメソッド名や引数を固定したままにせず、デプロイ時に使うSDKのバージョンも管理します。APIの入力形式や返却フィールドが変わったとき、依存パッケージだけ更新してパーサーが古いまま残ると、判定不能な結果を誤って通常処理へ流しかねません。
返却値を受け取ったら、現在のレスポンス仕様に記載されている信号種別、検出結果、検証状態をそれぞれ読み取ります。フィールド名を推測して直接業務ロジックに散らさず、API応答をアプリ内の共通状態へ変換するアダプターを一つ設けてください。
API応答を読み取る
├─ 対応信号を検出した → 来歴信号あり・追加審査へ
├─ 対応信号を検出しなかった → 信号未検出・他の審査へ
└─ 結果を確定できない → 判定不能・再試行または手動確認へ
ここで「来歴信号あり」は、コンテンツが本物である、編集されていない、説明文脈が正しい、という認定ではありません。APIが返す信号の意味を超えて「真正」と書き換えると、ユーザーへの説明やモデレーション記録が誤解を招きます。
結果を公開判断へ直結させない
detectedは、対応する信号が検出されたことを示す結果として扱います。画像の内容そのものが事実か、投稿者の説明が正しいかまでは証明しません。審査画面では「対応信号を検出」と表示し、事実確認や公開可否は別の判断項目にしてください。
not_detectedも「AI生成ではない」という判定ではありません。メタデータが剥がれている、ファイル変換で信号が失われている、対象モデルや形式が未対応である、別の生成ツールが使われている、といった理由で検出されない場合があります。したがって、検出の有無を単一の公開スコアに置き換えず、投稿の文脈、利用者からの申告、他の審査結果と組み合わせます。
結果が不明、または想定外の応答の場合は「信号なし」に寄せず、独立した例外状態にしてください。APIの障害と実際の未検出を同一視すると、障害発生中だけ審査が緩くなる設計になり得ます。
公開前に条件分岐と運用記録を整える
次の条件分岐で、APIをどの業務へ組み込むか決めます。
- 対応するOpenAI由来の信号を確認したい場合は、対応ファイルを送って検出結果を追加審査へ渡します。
- あらゆる生成AIの画像や音声を識別したい場合は、このAPIだけで要件を満たすと判断せず、別の審査手段を組み合わせます。
- 入力形式や対象信号が公式資料で確認できない場合は、公開判定に使わず、対応範囲を確定するまで手動確認へ回します。
- タイムアウト、アップロード失敗、未知の応答が起きた場合は、未検出ではなく判定不能として記録します。
- 元ファイルの保管が不要な業務なら、アクセス権と保存期間を見直し、審査に必要な情報だけを残します。
APIキーはサーバー側で管理し、クライアントアプリや公開ログへ出さないでください。ログには、審査状態や内部のファイル識別子など、運用に必要な項目を選んで記録します。APIエラーの種類と復旧方法は公式のエラーコードガイド、リクエスト制限への対応は公式のレート制限ガイドを参照し、再試行の対象と人手へ切り替える条件を決めます。
運用前の確認には、VPSSparkのサービス案内も参照できます。開発環境の利用条件が実装計画に関わる場合は、事前に問い合わせ窓口で確認してください。
審査方式を比較して、公開前のテストを設計する
| 方式 | 向いている工程 | 得られる情報 | 注意点 |
|---|---|---|---|
| アップロード直後に検証 | 公開前審査 | 元ファイルに近い状態での信号確認 | 同期処理にすると投稿完了を待たせる可能性があります |
| 変換後に検証 | 配信データの監査 | 実際に扱う派生ファイルの状態 | 変換でメタデータや信号が変化していないか確認が必要です |
| 公開後に検証 | 事後監査 | 既存コンテンツの確認 | 公開前の抑止にはならず、原本が残っていない場合があります |
| APIの状態 | アプリ内の扱い | 次の処理 |
|---|---|---|
| 対応信号の検出 | 来歴信号あり | 文脈確認や通常の内容審査へ |
| 対応信号の未検出 | 信号未検出 | 非AI生成と断定せず、他の審査を継続 |
| 判定不能・未知の結果 | 要確認 | 手動確認または仕様確認へ |
| タイムアウト・送信失敗 | 呼び出し失敗 | 再試行条件を適用し、未検出に変換しない |
| 受け入れテスト | 確認する動作 | 合格の考え方 |
|---|---|---|
| 対応形式のファイル | API送信と応答の読み取り | 仕様に沿って状態へ変換できる |
| 未対応形式のファイル | 送信前またはAPIエラーの処理 | 対応外として扱い、検出結果を捏造しない |
| 信号未検出の応答 | 審査画面とログ | AI生成ではないと表示しない |
| 通信失敗や未知の応答 | 例外分岐 | 審査を止めるか手動確認へ渡す |
各テストでは、リクエストの入力形式、SDKのバージョン、公式仕様を照合した日付、アプリが保存した審査状態を記録します。再現用のメディアを保管する場合は、保存権限と削除方針も定めてください。APIの現行仕様は更新されるため、公開前やSDK更新時に、Content Provenance APIガイドとリファレンスでフィールドや対応形式を再確認します。
よくある疑問
Content Provenance APIは、どのような形でメディアを送ればよいですか？
公式リファレンスに記載された作成メソッドから、対応が明記されているファイル形式を送ります。Python SDKを使う場合も、利用中のバージョンと現在の引数名をAPIリファレンスで照合してください。形式や送信方法を独自に決め打ちせず、実際のアップロード経路で得たファイルを使って確認することが重要です。
not_detectedなら、その画像はAIで生成されていないと判断できますか？
いいえ。not_detectedは、検査時に対応する信号が検出されなかったことを表す結果で、非AI生成の証明ではありません。メタデータの削除、画像変換、水印の劣化、未対応のモデルや他の生成サービスなどが理由になり得ます。審査では「未検出」として記録し、必要なら別の確認手段へ回してください。
OpenAIの検証APIで、他のAIツールが作った画像も判定できますか？
このAPIは、対応するOpenAI由来の来歴信号を確認するためのものです。他の生成ツールの出力を網羅して検出する汎用判定器ではありません。画像に信号がない結果を、他のサービスで生成されていない根拠として扱わないでください。C2PAやSynthIDの対象範囲も、媒体や処理経路によって異なります。
検証結果をコンテンツ審査の流れにどう組み込めばよいですか？
アップロード後に検証を呼び出し、検出あり、未検出、判定不能、呼び出し失敗を別の状態として保存します。検出ありでも公開可否を自動決定せず、投稿の文脈や他の審査項目と合わせて判断してください。タイムアウトや形式不一致を未検出に変換しないことも、誤判定を防ぐうえで欠かせません。
API接続だけで全ての真偽確認を置き換えたい場合は、この方式は適しません。自前の審査基盤なら判定ルールを細かく管理できますが、対応範囲の確認、例外処理、SDK更新、監視を継続して担う必要があります。開発環境を短期に用意して動作検証したい場合は、VPSSparkの日本向け利用案内で利用条件を確認し、APIの状態を手動確認へつなぐ運用まで試してから本番へ進めてください。
来歴確認の開発・検証に、専用のクラウドMacを
アップロード審査の処理を実装・検証する環境として、VPSSparkのクラウドMacをご活用いただけます。
専用ハードウェアと専用IPv4で、開発作業に使うMac環境を分けて運用できます。