# 払った額と使った額を突合して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 で実物のヘッダ・行数を確認してから本実行する運用が最後の安全装置になる。 ---