「全部チェックした」はなぜ嘘になるのか
私は株式会社USとUSサービスを併営しながら、NDT検査現場で20年のキャリアを積んできた。検査報告書・見積書・請求書といった帳票作成は日常業務の一部だが、ある時期に大量の帳票を連続で作成する案件があった。そこで同種の見逃しを3回連続で出し、「全部チェックした」という自分の宣言が何の保証にもなっていないことを思い知った。
原因は単純だった。私の検証は「バッチ単位」「列単位」で、全体を貫く健全性チェックが無かった。個別の指摘を潰し込んでも、構造的な不整合は見逃される。この経験から、私は「完成」の定義を作り直し、全数×全項目の不変条件バリデータを組んだ。以降、違反ゼロを「完成」の新定義とした結果、見逃しはゼロになった。
本記事では、その実装プロセスと学びを公開する。AI導入を検討している中小経営者やデータ実務者にとって、品質担保の設計指針になれば幸いだ。
なぜ個別指摘の潰し込みでは見逃しが消えないのか
私が連続で見逃したのは、次のような構造的な不整合だった。
- 請求書の合計金額と内訳の総和が一致しない
- 見積書の単価×数量が小計と合わない
- 報告書の検査箇所IDが他の帳票と不一致
これらは「個別の指摘」としては発見できる。だが、私の検証フローは「Excelシートを開く→目視で確認→修正→次のシートへ」という線形処理だった。1枚ずつは正しく見えても、全体を横断する条件（例: ID の一意性、金額の総和一致）は検証できていなかった。
加えて、チェック項目が頭の中にあるだけで、明文化されていなかった。「だいたい見た」「たぶん大丈夫」という感覚で完了を宣言していた。これでは品質は担保できない。
私が学んだのは、品質は個別対応の積み上げでなく、全体を一度に貫く自動検証で担保するという原則だった。
全数×全項目の不変条件バリデータを組む
そこで私は、全帳票を一括で検証する不変条件バリデータを設計した。実装はPythonで行い、次の7本のルールを機械的にチェックする仕組みにした。
- ID の一意性: 全帳票で同一IDが重複していないか
- 金額の総和一致: 請求書の合計金額が内訳の総和と一致するか
- 単価×数量の整合性: 見積書の単価×数量が小計と一致するか
- 必須項目の欠損ゼロ: 全行で必須フィールドが埋まっているか
- 日付の論理整合性: 検査日≦報告日、発注日≦納品日など
- カテゴリ値の許可リスト: 検査種別・取引先名が事前定義の値のみか
- 外部キー整合性: 見積書IDが請求書で参照されているか
これらのルールは、NDT検査報告書でいう「JIS規格の判定基準」に相当する。合否の閾値を明文化し、全数を機械的に検証する。違反があれば即座にリストアップされ、修正漏れを出さない。
実装後、私は「完成」の定義を次のように変更した。
完成 = バリデータ実行時の違反ゼロ
これにより、「全部チェックした」という人の宣言は不要になった。違反ゼロという状態が、完成の証明になる。
実装後の変化：見逃しゼロと修正コストの削減
バリデータ導入後、私の業務フローは次のように変わった。
- 帳票作成→バリデータ実行→違反修正→再実行→違反ゼロ確認→完成
このサイクルを回すことで、見逃しはゼロになった。加えて、次の副次効果があった。
- 修正コストの削減: 後工程（請求書発行後・報告書提出後）での修正は、前工程（作成中）の10倍のコストがかかる。バリデータで前工程の段階で全違反を検出できるため、後戻りコストが消えた。
- チェック項目の蓄積: 新しい見逃しパターンが見つかったら、バリデータにルールを追加する。これにより、過去の失敗が将来の品質向上に直結する。
- 認知負荷の軽減: 「全部見たかな」という不安が消え、バリデータの実行結果だけを信頼すればよくなった。
特に、NDT検査現場では「見逃し」が致命的なリスクになる。設備の安全性を担保する検査で、報告書の不整合は信頼の失墜に直結する。私は検査報告書にも同様のバリデータを組み、提出前の品質担保を自動化した。
Claude Codeとの組み合わせで加速する実装
私はこのバリデータをClaude Codeで実装した。Claude Codeは「何を書かないか」の判断を助けてくれるツールだが、バリデータ設計では特に有効だった。
具体的には、次のプロンプトでルール追加を繰り返した。
「見積書の単価×数量と小計が一致しない行をリストアップするバリデータルールを追加してください。既存の7本のルールと統合し、違反をJSON形式で出力する設計にしてください」
Claude Codeは既存コードを読み込み、新ルールを統合したコードを生成する。私はそれをレビューし、必要に応じて修正する。このサイクルで、7本のルールを2時間で実装できた。
従来なら、Pythonのコードを自分で書き、テストケースを用意し、デバッグする必要があった。Claude Codeを使うことで、ルール定義に集中でき、実装の手間を大幅に削減できた。
この経験から、私は「AI導入の価値は、人の判断を代替することではなく、人の判断を機械的に実行することにある」と考えている。バリデータは私が定義したルールを、機械的に全数実行する道具だ。
まとめ：完成は人の宣言でなく状態で定義する
私が帳票作成で同種の見逃しを3回出してから学んだのは、次の3点だった。
- 品質は個別対応の積み上げでなく、全体を貫く自動検証で担保する
- 「完成」は人の宣言でなく、違反ゼロという状態で定義する
- バリデータはルールの蓄積装置であり、過去の失敗を将来の品質に変換する
この設計は、NDT検査報告書・見積書・請求書だけでなく、あらゆるデータ実務に適用できる。AI導入を検討している中小経営者は、まず「完了宣言をバリデータに置き換える」ところから始めるとよい。
私は今後も、業務の中で「人が判断すべきこと」と「機械が実行すべきこと」を切り分け、品質担保の仕組みを磨いていく。違反ゼロという状態が、完成の証明になる世界を目指している。