# AI 動画ジョブログと請求書を照合するには？ > ローカル操作 ID、プロバイダージョブ ID、モデルパラメータ、利用単位、時刻、課金軸を持つ不変の試行台帳で費用を照合します。請求明細を同じ単位へ正規化し、正確な ID を優先して紐づけ、真の例外だけを手動確認へ送ります。 # AI 動画ジョブログと請求書を照合するには？ 請求照合は最初の動画生成前から始まります。ログにプロンプトと成功フラグしかなければ、後の請求を顧客、キャンペーン、出力、再試行へ確実に割り当てられません。必要なのは、事業上の識別子とプロバイダーの課金識別子を両方保存する不変の試行台帳です。 すべての元データを 1 つの生形式へ強制する必要はありません。元の証拠を保存し、共通の費用 schema へ正規化し、信頼度の高い記録から紐づけ、残りを隔離します。良い月次締め処理は通常差異を自動説明し、短い例外一覧だけを人に渡します。 ## 照合するオブジェクトを定義する 制作ジョブと課金対象の試行は同じではありません。1 本の要求動画が承認されるまで複数回生成されることがあります。 少なくとも次を使います。 * 意図した納品物を表す操作 * プロバイダー送信ごとの試行 * 返されたメディアごとの出力 * 計測された数量ごとの利用イベント * 請求明細または課金記録 * 顧客、キャンペーン、コストセンターへの配賦 この構造により、再試行が 1 つの `job_cost` に隠れず、複数候補を無関係な事業要求として誤認しません。 ## 要求時に課金証拠を取得する ログのローテーションやダッシュボード集計前に ID とパラメータを保存します。 | フィールド | 例 | 照合での役割 | |---|---|---| | 社内操作 ID | `op_01J...` | 費用を事業目的へ接続 | | 社内試行 ID | `att_03` | 再試行を分離 | | プロバイダージョブ ID | `job_8f...` | 正確な一致 | | アカウントまたはプロジェクト | `production-us` | 請求範囲を一致 | | モデル ID | 正確なモデル名 | 価格軸を選択 | | 送信パラメータ | 長さ、解像度、比率 | 数量と単価を説明 | | 受理時刻と完了時刻 | UTC 時刻 | 請求期間を整合 | | 終了状態 | 完了、失敗、キャンセル | 課金ルールを確認 | | 利用量フィールド | 秒、credits、画像、tokens | 期待額を計算 | | 出力チェックサム | SHA-256 | 課金を資産へ接続 | ポリシー上許される場合、未加工レスポンスまたはマスキング済みコピーを保持します。分析用に正規化しても、値の由来を示す証拠は捨てません。 ## プロバイダー中立の利用 schema を作る 動画サービスは生成秒、要求秒、解像度、credits、完了出力など異なる単位で課金します。すべてを `tokens` 列へ押し込まないでください。 正規化イベントには数量と単位、モデル、価格階層、品質、通貨、単価、元時刻と取り込み時刻、報告値か計算値か、元レコード ID、価格版を残します。 金額換算前に元の単位を保存します。プロバイダーが 60 credits を報告し請求も credits 単位なら、推定ドル表示があっても照合数量は 60 credits です。 ## 見積もりに使った価格ルールを固定する 価格ページが変わると、今日の期待費用を翌月再現できないことがあります。見積もり時の単価、通貨、適用時刻、価格軸を保存します。 ```text 期待請求額 = 正規化数量 × 適用単価 ``` 課金単位が分かる場合だけ有効です。失敗やキャンセルが無料とは推測しません。資料または実請求で確認できるまで不明とします。 プロモーション credits、税、契約割引、為替は基本利用と分けます。請求書レベルだけに現れる場合は配賦ルールが必要です。 ## 元データを上書きせず請求を取り込む 元の請求書、CSV、利用レポートをチェックサム付きで永続保存します。構造化しても元の行番号と値を保持します。 | 元フィールド | 正規化フィールド | |---|---| | 要求またはジョブ参照 | `provider_job_id` | | 商品またはモデル表示 | `model_id` と元ラベル | | サービス期間 | UTC の開始と終了 | | 利用量 | 10 進数量と単位 | | 単価 | 10 進金額と通貨 | | 請求額 | 税引前明細額 | | credits または割引 | 別の調整行 | | 請求書番号 | `invoice_id` | 金額には 10 進演算を使います。浮動小数点の丸めは大量利用で多数の微差を作ります。 ## 信頼度の層で記録を一致させる 曖昧な時刻一致から始めず、可能な限り正確な ID を使い、一致ルールを記録します。 1. 正しいアカウント内でプロバイダー ID を完全一致する。 2. 文書化された冪等キーまたは参照を一致する。 3. ジョブを参照する利用イベントを使う。 4. アカウント、モデル、日、単位、地域で集計する。 5. 時刻とパラメータの類似は例外キューだけで使う。 | 層 | 信頼度 | 処理 | |---|---|---| | 正確なプロバイダー ID | 高 | 自動照合 | | 正確なクライアント参照 | 高 | 一意性確認後に自動照合 | | 利用イベント経由 | 高 | データ系譜付きで自動照合 | | 集計グループ | 中 | グループ合計を照合 | | 時刻とパラメータ類似 | 低 | 手動確認 | 明示的な集計でなければ、1 明細を複数試行へ暗黙配分しません。関連テーブルで 1 対多を保持します。 ## タイムゾーンと請求期間をそろえる 23:59 に送ったジョブが翌日完了し、受理、完了、利用イベントのいずれかで課金される場合があります。運用時刻は UTC、請求タイムゾーンは別に保存します。 正確な ID がなければ次を比較します。 * 送信時刻 * 受理時刻 * 完了時刻 * 利用イベント時刻 * 請求サービス日 公開されていれば基準時刻を記録します。なければ日次配賦を推論として扱い、十分な証拠が得られるまで広い期間で照合します。 ## 再試行、失敗、重複を説明する 再試行は過剰請求に見える主因です。制作画面に 1 本しかなくても、プロバイダーが 3 回処理している場合があります。 ```text 操作費用 = sum(すべての生成試行) + 保存 + 転送 + 関連処理 ``` 結果と原因で試行を分類します。終了失敗、不明タイムアウト、ユーザー要求の変種、品質拒否、誤重複送信を区別します。 同じ操作キーで異なるプロバイダー ID がある場合、片方を削除しません。重複関係と両方の請求を保持し、予防改善と問い合わせの証拠にします。 ## 系統的なずれを隠さず許容範囲を使う 絶対値と割合の許容範囲を定義します。絶対値は低額の丸め、割合は大きな請求に対応します。 数量と金額一致、単価差、数量差、期間差、請求のみ、ログのみ、未配賦 credits、通貨または税差へ分類します。 各行が範囲内でも集計ずれを確認します。1 件あたりの微差も大規模では重要で、誤った丸めや価格階層を示す可能性があります。 ## 照合コントロールレポートを作る | コントロール | 目標結果 | |---|---| | 請求総額 | 照合済みと未解決の合計 | | 利用数量 | モデルと単位ごとに一致 | | 正確 ID の網羅率 | 高く安定 | | 未一致請求額 | 承認閾値未満 | | ログのみの試行 | 時期またはルールで説明 | | 重複費用 | 原因と担当を割り当て | | 価格差 | 価格版または契約で裏付け | 承認後は期間を固定します。後発調整は新しい調整記録として追加し、過去の締めを履歴なしに書き換えません。 ## 帰属を失わず統合を集約する [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=reconcile-ai-video-job-logs-with-invoice) は、OpenAI 互換の単一プラットフォームと請求関係でテキスト、画像、動画を使う運用を簡素化できます。ただしジョブ単位の帰属はアプリが保存する ID に依存します。 各アダプターに社内操作 ID と試行 ID を残し、正確なモデル、パラメータ、返された参照を保存します。請求が商品、顧客、資産へ追跡できて初めて、単一請求が管理しやすくなります。 ## まとめ 課金データが来る前に永続的な試行台帳を構築します。社内とプロバイダーの ID を保持し、元単位を失わず利用量を正規化し、正確な参照を優先して一致させ、再試行を納品意図と分けます。明確な許容範囲、信頼度別の照合、管理された例外キューにより、財務は締め処理を行い、エンジニアは費用原因を把握できます。 ## FAQ ### 動画請求の照合で最も重要な識別子は何ですか？ 社内操作 ID とプロバイダーのジョブまたは要求 ID を両方保存します。社内 ID は事業目的を説明し、プロバイダー ID は利用量と請求を結ぶ最も強い証拠です。 ### 失敗した動画ジョブも台帳に含めますか？ はい。課金ルールはモデルや失敗種別で異なる可能性があるため、すべての試行と終了状態を記録します。現在の資料や請求で確認できない限り、失敗は無料と仮定しません。 ### 日次合計しかない請求書はどう照合しますか？ 同じアカウント、日付、モデル、地域、通貨、課金単位で正規化済み利用量を集計して比較します。精度の低い集計照合は正確なジョブ単位照合と分けてください。 ### 費用差の許容範囲はどのように決めますか？ 通貨の丸め、報告遅延、予想量に基づいて絶対値と割合の許容範囲を明示します。個々の差が小さくても、系統的なずれは調査します。 ### 再試行は別ジョブとして数えますか？ 制作操作は 1 つのまま、各生成試行を別に記録します。これにより意図した納品物との関係を保ちながら再試行費用を把握できます。 ### 1 つのゲートウェイで複数モデルの照合を簡素化できますか？ Atlas Cloud のようなプラットフォームは利用量と請求を集約できますが、商品、キャンペーン、出力へ費用を割り当てるため、アプリ側でジョブ単位の ID とパラメータを保存する必要があります。