AIに「ログから収益シミュレーション結果を集計して」と頼んだら、+1億4000万円 という景気のいい数字が返ってきました。
念のため検証したら、架空の決済価格でログ書き出し されている疑惑、重複計上 の疑惑、部分利確の二重カウント が次々判明。最終的な保守的推定は -3000万円〜-5000万円。
プラス1.4億 → マイナス3000万。AIの数値レポートを鵜呑みにすると、経営判断を1.7億円間違えます。本記事は、AI出力の数値検証で実際に使った作法のまとめです。
発端：「集計して」と頼んだだけだった
データ処理パイプラインのDry-Run結果が複数のログに分散していました。AIに以下を頼みました。
1ユーザー: 直近1ヶ月のDry-Run収益シミュレーション結果を、2 ログから集計して合計値を出してAIは20個ほどのログファイルを読んで、以下のレポートを返しました。
1集計結果（楽観値）:2- パイプラインA: +1億9500万円3- パイプラインB-Pre: -2500万円4- パイプラインB-Pre-T8: -1900万円5合計: +1億4100万円6
7✅ ポートフォリオは収益性を確認できました「✅」マークと断言調が気になりました。
検証ステップ1: ログ取得経路の信頼度
最初に確認したのは「ログがどう生成されているか」。AIに尋ねました。
1ユーザー: パイプラインAの「+1.95億円」の元になっているログは2 どのプロセスがどう書き出している?AIの追加調査で判明したこと。
- パイプラインAは 外部APIからリアルタイム価格取得 が必要
- しかし、その API の有料プラン（Lv1）が未購入
- リアルタイム取得失敗時、フォールバックで「過去のTP価格をそのままログ書き出し」 していた
- つまり、ログの「+1.95億」は 実際の市場価格を反映していない架空の数字
⚠️ 集計の元データが「架空のTP価格」だったら、合計値は意味がない
検証ステップ2: 重複計上の疑惑
次に確認したのは「ログ間で同じデータが重複していないか」。
1ユーザー: パイプラインB-Pre と B-Pre-T8 のログ、2 対象期間と対象データセットを比較して調査結果。
- B-Pre: 2026-03-15〜04-15 の Dry-Run ログ
- B-Pre-T8: 同じ期間・同じデータセット の Dry-Run ログ（テスト施策版）
つまり、両方を合計すると同じ取引が2回カウント されていました。-2500万 + -1900万 = -4400万 ではなく、実態は -2500万のみ。
検証ステップ3: 部分利確の二重カウント
最後に、ログの個別レコードを確認しました。
1ユーザー: 「決済[TP]」ログと「record_exit 失敗」ログの整合性は?調査結果。
- 「部分利確 PnL=$+xxx」が記録されている
- しかし、その後の
record_exit 失敗で クローズ処理が完了していない ケースが多数 - 「部分利確 PnL」だけ集計対象に入り、最終ロスが集計対象外になっていた
これはプラス側のみカウント、マイナス側はカウント外という構造的バイアスでした。
修正後の保守的推定
3つの検証ステップを経て、保守的推定を再計算しました。
| 項目 | 楽観値 | 保守値 | 修正理由 |
|---|---|---|---|
| パイプラインA | +1.95億 | ±0 | 架空TP価格、信頼不能のため除外 |
| パイプラインB-Pre | -2500万 | -2500万 | そのまま |
| パイプラインB-Pre-T8 | -1900万 | 0 | B-Pre と重複計上のため除外 |
| 部分利確の二重カウント | （加算側のみ） | -1000万〜-3000万 | 失敗クローズの逸失 |
| 合計 | +1.4億 | -3000万 〜 -5000万 | - |
プラス1.4億からマイナス3000万への修正。差は1.7億円。
もし最初の楽観値で「ポートフォリオは収益性あり」と判断していたら、誤った経営判断に直結していました。
AI出力の数値検証 4作法
この経験から、AI が出した数値レポートを検証する4つの作法を抽出しました。
作法1: ログ取得経路の信頼度を必ず確認
「そのログは何のプロセスが、どんな条件で書き出しているか」を必ず追跡。フォールバック処理・モック値・テストデータが混入していないか。
作法2: 期間・データセットの重複チェック
複数ログを合算する場合、対象期間と対象データセットが排他か を必ず確認。「Pre」「Pre-T8」のような名前違いで実は同じデータの可能性。
作法3: プラスとマイナスの非対称性を疑う
「プラスのレコードだけ完全に記録され、マイナスのレコードが欠損している」というバイアスは、データパイプラインで起きやすいものです。集計合計が想定より楽観的 な場合は、片側カウントを疑います。
作法4: 「✅」の断言調を信じない
AIは「✅ 収益性確認」「結論：問題なし」のような断言を出しがち。断言の言葉ほど検証スイッチを入れます。
チェックリスト：AI数値レポートの検証
経営判断に使う前に以下を確認します。
- ログ生成プロセスは把握できているか
- フォールバック・モック値混入の可能性をチェックしたか
- 複数ログを合算する場合、期間・データセットの重複を確認したか
- プラス/マイナスの非対称性（片側カウント）を確認したか
- サンプリング1〜3件を手作業で検算したか
- 楽観値だけでなく保守値も提示させたか
6項目とも YES になるまで、その数字で判断しません。
AIに「保守値も出して」と頼む
最後に重要なテクニック。AIに集計を頼むときは、最初から楽観値+保守値+留保事項の3点セット を要求します。
1ユーザー: 集計してください。出力フォーマットは:2 - 楽観値（前提を最大限信用した場合）3 - 保守値（疑わしい前提を全て除外した場合）4 - 留保事項（信頼度が低いデータの一覧）これだけで、AIは検証スイッチを入れた状態で集計してくれます。
まとめ
- AI数値レポートで楽観値+1.4億→保守値-3000万の修正があった
- 検証4作法: ログ取得経路 / 重複 / 非対称性 / 断言調
- 経営判断前のチェックリスト6項目
- 集計依頼時は「楽観値+保守値+留保事項」3点セット
AIが綺麗な数字を出してきたときが、一番危ない。検証作法を内在化することで、経営判断の品質が大きく変わります。