払った額と使った額を突合してAI費用の計上漏れを洗い出す

AIの利用費は必ず2系統の記録に分散する。払った額（会社カード・個人カードの明細、会計ソフトの取引）と、使った額（CLIエージェントの実行ログ、各プロバイダの管理画面）。片方だけ見ると、カードを止めたのにログだけ残る契約、ログに残らない画面からの利用、複数支払い元に別れて計上される月額費などが見えず、未登録分の棚卸しが毎月手作業になる。

この手順は「2データ源を月次で機械突合し、経理の人は『登録待ち』リストだけ見て確認すれば済む」形にするものである。会計ソフトへの書き込みは自動化しない（判定は機械、登録は人）。

全体像

カード明細（全支払い元）          実行ログ（全PC・全ツール）
  払った額                         使った額
      └──────── 突合（年月×サービス単位）────────┘
                     │
        ┌────────────┼────────────┐
   両方にあり    会計に無い（要確認）   実測に無い
                     │
             「登録待ち」リスト → 経理が請求書で金額確定 → 登録 → 登録済み印

手順

1. 払った額: カード明細を全支払い元分まとめて取得する

対象期間（例: 13か月。当年月分を含めて遡る）の全支払い元——会社カード、経費精算に出る個人カードまで——の明細を読み、period / vendors / payers / unmatched（ベンダー名を分類できなかった明細）を持つJSON 1つにまとめる。unmatched が多いようなら先にベンダー名の辞書（表示名→正規名）を整える。ここで支払い元を1つでも漏らすと、以降の「会計に無い」が全部偽陽性になる。

2. 払った額の側の網羅を、明細だけでは無く請求書で確認する

カード明細は引き落とし単位なので、月額契約の前払い・年払い・為替差額で対象月がずれる。各サービスの管理画面で請求書・領収書を対象期間分取得し、全案件がステップ1の取得対象に含まれるかを確認する。

重要: ローカルの実行ログに無いことは、未利用の証拠にはならない。 画面からの利用、別PCでの利用、モバイルアプリの利用はログに残らない。ログ欠如を「使っていない」の根拠に使わないこと。

3. 使った額: 実行ログを年月×プロバイダで集計する

CLI型エージェント（Claude Code、Codex など）はセッショントランザクションの JSONL にトークン実績が残る。これを年月×プロバイダに集計し、単価表で円換算する。ポイント:

• 採用した換算レートは出力JSONの jpyPerUsd などのフィールドに必ず残す（後から「この円額はいくらレートか」を追跡可能にするため。請求書の確定円額とは別物であり、区別して扱う）
• 複数PCのログをまとめる場合は、同じ集計をPCごとに重複実行せず、年月×プロバイダに集約した同一形式のJSONを合成して渡す（二重計上防止）
• 定額プラン（月額固定のシート契約・サブスク）と単価不明・未計測の項目は金額を null にする。 null は無料の意味ではない。概算額をねじ込むと経理がそれを確定額と誤認する
• 安い従量APIは実行ログの usage 行から集計し、検索等の付帯費用も含める

4. 突合の判定は4状態に限定する

年月×サービスをキーに2データ源を突合し、各セルを次の4状態のいずれかに落とす:

状態	意味	扱い
両方にあり	明細と実測の両方に記録がある	差額は双方が数値のときだけ表示。差額が大きければ契約・為替を確認
会計に無い（要確認）	実測だけに記録がある	登録待ちリストに入れる。ただし入力期間外・未分類明細・支払月ずれ・定額枠の可能性もあり、未登録と断定しない
実測に無い	明細だけにある	定額利用・画面利用でも発生する。登録待ちには入れない（すでに払っているので計上漏れではない）
判定不能	双方の金額不明	定額枠と分かるなら金額 null でも記録の有無で状態付けする

「登録待ちに入れるか」の判断を機械に任せない。機械は状態の付与までで、リスト化された候補を人が確認する。

5. 台帳（スプレッドシート等）への書き込みは dry-run → read-back → 本実行

集計結果は既存の管理台帳ブックに「サマリ」「登録待ち」の2タブで書き込む。新しいブックを作らない（正本が分裂するため）。書き込みの安全則:

1. まず --dry-run を付け、write 先の実ヘッダ・実行数を読み戻して想定と一致することを確認する。診断が失敗したら中止する。想定値で代用しない
2. 既定では空セルのみ更新し、更新日時・検出日だけ常に更新する。過去月の再計算値で確定値を上書きしたいときだけ --force を付ける
3. 人の記入列（勘定科目・税区分・登録済み印・確認メモ）は force でも絶対に書かない。 機械が書いてよい列を許可リストで明示する
4. サマリと登録待ちが別リクエストになる場合は、後続だけ失敗しても同じ入力で再実行できる冪等性を持たせる
5. 登録待ちリストは「当月を含むNか月」の範囲で置換し、候補0件の月の古い行も消す。ただし範囲外の行・登録済み行・人の記入がある行は削除しない

6. 経理への引き渡し

登録待ちリストの摘要案は AI利用料 <サービス名> <年月> の形式で機械が提案する。ここで効くのが手順3の区別で、トークン概算の円換算をそのまま確定支払額として登録させない。金額・支払い元・対象月は請求書で確定させ、勘定科目と税区分は経理が決めて手動登録し、登録後に「登録済み」列に印を付ける。この分工（機械=検出、人=確定）を守ると、経理の確認は月あたり数十分で済む。

集計単位と支払い元の注意

• 突合の単位は年月×サービスであり、契約・アカウント別の取引明細ではない。1事業者に複数契約があるプロバイダはベンダー名の1行に集約する
• 支払い元は入力から1つに絞れる場合だけ記載し、複数名義があり得るなら空欄にする（推測で書くと経理の照合を歪める）
• 金額 null は無料ではない、差額 null は一致しているわけではない——null の意味を実装と運用で一言語化しておく

検証

書き込みロジックは HTTP を注入した単体テスト（mockで WebApp の応答を差し替える形）で検証できる。実際の本番ブックへの書き込み・会計ソフト登録はテスト対象にしない。dry-run の read-back で実物のヘッダ・行数を確認してから本実行する運用が最後の安全装置になる。