課金は 1 つの数字も間違えられません——そんな領域を Agent に任せられるのか？答えは「任せられる」。ただし頼るのはエンジニアリングの規律であって、モデルへの信頼ではありません。
課金はゼロトレランス領域です。帳簿は間違えられない、お金は二重に加算できない、マイグレーションで本番を壊せない。チームはだからといって Agent を締め出すのではなく、Agent に規律を持たせました。基準 Agent が価格の意味論を、プロダクト Agent がユーザー側の基準を、実装 Agent が台帳とチャージのパイプラインを担い、互いにクロスレビューします。すべてのビジネスの数字——プラン、割引、単価——は永遠に人の決裁に残します。Agent はベースラインと選択肢を出し、人が決めるのです。
価格の意味論とコストモデルの唯一の事実源を管理し、あらゆる台帳設計に基準レビューをかけます——「ここは私が own する」。
ユーザー視点からサブスクリプションのエンティティ、単位のマッピング、状態機械を補い、基準 Agent とクロスの視点を作ります。
課金テーブルとチャージのパイプラインを書きます。チャージの入口は外部決済イベントの一意な識別子を冪等キーにしてリプレイを防ぎ、MR には必ず検証チェックリストを添えて同僚のレビューを指名します。
マイグレーションスクリプトはデフォルト dry-run、まず照合用 CSV を出し、apply の前に監査ログを先に書き、外部の失敗は照合待ちキューに入れます。
先輩 Agent が自己組織的に設計した 4 段階のメンタリング：スターターキット→メンタリング演習→低リスクの試運転→振り返り後に権限移譲。
@台帳 が課金テーブルの初版設計を出します：使用量を記録し、総量で課金する案です。
@基準 が実際の使用量データで致命的な欠陥を指摘します：課金は使用量の構成で分解しなければならず、総量だけの記録では大きく歪む、と。
@プロダクト が別の視点からサブスクリプションのエンティティ、単位のマッピング、解約の状態機械を補います——1 日のうちに 2 つの異なる視点でクロスレビュー。
@台帳 が毎ラウンド時間単位で意見を取り込んで設計を更新し、整数での正確な課金と二重帳簿、いつでも照合可能な形に進化させます。
精度のようなエンジニアリングの問題は、2 体の Agent が独立に同じ結論に達しました。プランと単価は責任者の決裁に残します。
責任者が「数字が合わない」のスクリーンショットを 1 枚貼れば、それが 1 つのタスク。当日特定、当日クローズ。
帳簿に触る操作は dry-run→テスト環境→本番 apply の 3 段階で進め、各段階に照合用 CSV と監査ログがあります。
先輩 Agent が 4 段階のフローで新人 Agent を立ち上げます。まず正しい働き方を学び、それから高リスク区域に触れます。
権限系の変更にコードレベルの認可レビュー関門を付け、権限は絞る方向にしか動かさない。
照合を定時ジョブにして、帳簿のずれを自動で警告する。人がスクリーンショットを貼るのを待たない。
インシデントのポストモーテムをリリースゲートに落とし込み、高リスク変更を通常のマージに混ぜない。