スプレッドシートの異常を見つけて照合レポートを作る方法

スプレッドシートの異常は、必ずしも誤りではありません。正当な例外、計上時期のずれ、重複取引、変更された識別子、あるいは新しい行までひそかに範囲が伸びなくなった数式かもしれません。したがって、信頼できる照合作業は、目立つセルに色を付けるだけでは不十分です。何と何が一致するべきかを定義し、差異ごとに根拠をたどり、どのように解決したかを記録します。

状況の診断

同じ活動を表すはずの二つのレポートが一致しない場合や、一つのブックに不完全、重複、入力ミス、不整合と思われる値がある場合に、この方法を使います。まず、照合する問いを平易な言葉で定めます。どのレコードが、どのキーで、どの期間について、どの会計規則または業務規則のもとで一致するべきなのかを明確にしてください。

構造上の異常と業務上の異常を分けます。構造上の問題には、列のずれ、複数の日付形式、数式が抜けた箇所、目に見えない空白、型が統一されていない識別子などがあります。業務上の異常には、予期しない返金、別の期間に計上された注文、一方のシステムに存在しない正当なレコードなどがあります。この区別により、誰がその項目を解決できるかが決まります。データ管理担当者は書式を修正できますが、業務上の処置は財務または業務の責任者が承認しなければなりません。

最終レポートでは、対象となる原資料の範囲、照合規則、例外の分類、根拠、処置、未解決項目を説明します。値が異常であるという理由だけで、不正または誤りだと断定してはいけません。

必要な入力

元データの読み取り専用エクスポート、抽出時刻、列定義、正式なキーフィールド、対象レポート期間、通貨とタイムゾーンの規則、既知の除外条件を集めます。システム責任者が提示するコントロール合計があれば取得します。システム間で変更された識別子の対応表と、許容差、取消、無効化、遅延計上に関するポリシーも用意します。

各列の意味と許容される形式を示すデータ辞書を作ります。属性ごとに、どのファイルが正式な情報源かを記録します。一方のデータが取引ステータス、もう一方が決済ステータスの正式な情報源なら、片方が両方のステータスを管理していると仮定してはいけません。分析前に、例外識別子、原資料への参照、照合状態、差異の種類、観測した根拠、考えられる説明、レビュー担当者、処置、フォローアップというレポートの項目を定義します。

データを安全に扱うための準備

稼働中の業務ファイルではなく、コピーを使って作業します。照合に不要な直接識別子や、機微な自由記述列を取り除きます。可能であれば、口座番号や顧客識別子を一貫したトークンに置き換え、トークン対応表は別にしてアクセスを制限します。使用する AI または分析環境が、そのデータ分類で承認されていることを確認します。

元のエクスポートを編集できないようにし、手順で対応できる場合はファイルのチェックサムを計算または記録します。機密性のあるブック全体を汎用チャットツールに貼り付けてはいけません。再現性のある比較にはローカルの数式やスクリプトを優先し、AI は、匿名化した例外サンプルからのパターン説明、調査手順の提案、文書草案の作成に使います。出所不明なファイルのマクロは無効にします。分析用にシートを値へ変換する前に、数式そのものを別途保存してください。

順を追ったワークフロー

原資料の棚卸しから始めます。ファイル名、シート名、対象行、抽出時刻、責任者を記録します。各表を変更せずに、ヘッダー、空欄率、重複を除いたキー数、重複キー、データ型、日付範囲、数式の適用範囲を把握します。値を比較する前に、このプロファイルを確認して、インポート時の問題を見つけます。

正規化は、派生した作業用テーブルでだけ行います。前後の空白を取り除き、大文字と小文字を区別しないキーは表記を統一し、明示したロケールに従って日付を解析し、識別子の先頭のゼロを保持します。元フィールドと正規化後フィールドの両方を残します。別の分析担当者が再現できるよう、すべての変換を規則として文書化します。

照合は段階的に定義します。最初に、承認済みの主キーで完全一致を試します。一致しない項目に限り、参照番号と日付と金額の組み合わせなど、承認された複合キーを明示的な許容差ポリシーとともに使います。言語モデルに、あいまい一致を最終的な事実として選ばせてはいけません。候補の提案は可能ですが、レビュー担当者による確認が必要です。結果は、完全一致、説明済みの時期差、正当な業務上の例外、原データの欠陥、重複の可能性、未一致、責任者のレビュー待ちに分類します。

差異は、再現性のあるスプレッドシート数式またはコードで計算します。元データの行参照を保持します。例外の分類ごとにサンプルを調べ、その規則を広く適用する前に業務分野の責任者へ確認します。次に、例外ごとに一行を使い、該当する原データ値、該当した規則、根拠、処置を記載した照合表を作ります。行単位の追跡経路を確保してから集計してください。

件数だけでなく、対象範囲と制約も示すエグゼクティブサマリーを作ります。原データの欠陥はシステム責任者へ、ポリシー上の疑問は説明責任を負う業務責任者へ回します。データの修正は権限のあるシステムでだけ行い、その後に再エクスポートして全件を再照合します。新しい根拠が処置を裏付けた場合に限り、項目を照合済みとします。

コピーして使えるプロンプト

```text 匿名化したスプレッドシートのプロファイルと例外行を確認する、データ品質アナリストとして対応してください。原データの値、照合規則、説明、修正内容を創作してはいけません。異常値は誤りの証明ではありません。

照合する問い：[問い] 原資料の定義と責任者：[定義] 承認済みのキーと正規化規則：[規則] 許容差、期間、タイムゾーン、通貨のポリシー：[方針] 列のプロファイル：[プロファイル] 変わらない行参照付きの匿名化済み例外サンプル：[サンプル]

次を返してください。 - 照合前に解決すべき構造上の問題 - 提供された根拠が裏付ける例外パターン - 各パターンについて考えられる別の説明 - 分析担当者が実行できる再現可能なテスト - 原資料の責任者に確認する質問 - 範囲、規則、追跡経路、処置、制約を含む照合レポートの構成案

すべての記述に「観測」「推論」「不明」のいずれかを付けてください。提供された確認情報なしに、レコードを誤り、不正、照合済みと分類してはいけません。 ```

具体例

注文エクスポートと決済エクスポートが同じ参照フィールドを使っているとします。いくつかの注文が未一致になりました。データのプロファイルを調べると、注文側の参照番号には先頭のゼロが含まれる一方、決済ツールはそれを数値として出力していました。ほかの差異はレポート期間の締め日前後に集中し、同じ参照番号が異なるステータス値で繰り返されている小さなグループもあります。

分析担当者は元の参照番号を保持し、責任者が承認したテキスト形式の正規化比較キーを作って完全一致を再実行します。先頭ゼロのグループは一致するようになりますが、何も記録せずに消すのではなく、構造的な表現の問題として文書化します。締め日前後のグループは、財務責任者が計上規則を確認するまで、時期差の候補のままです。同一参照番号が繰り返されるグループは自動削除せず、取消後に修正済みの決済が行われたケースかどうかを調べます。

レポートには、各グループ、そのテスト、元データの行、責任者の判断、処置を示します。すべてのレコードを無理に一致させるという、魅力的に見えて危険な近道は取りません。根拠が不十分なため、正しく未解決のまま残るレコードもあります。

検証チェック

変換の前後には毎回、行数とコントロール合計を照合します。正規化によって別々の識別子が統合されていないこと、先頭の文字が落ちていないことを確認します。数式の適用範囲はデータの先頭行と末尾行でテストします。非表示行、フィルター、結合セル、エラー値、数式領域に直接入力された定数も確認します。原データ責任者から受け取った既知の例を使い、日付の解析を再テストします。

照合済みとする各例外には、原資料への参照と、承認済み規則または責任者の確認を必須とします。あいまい一致や複合キーによる一致は、別の担当者が確認します。一つのレコードが複数の診断分類に入る可能性を考慮したうえで、一致、説明済み、未解決の各グループの合計を元の母集団と比較します。手を加えていないエクスポートから再実行し、再現性を証明します。二人目のレビュー担当者が例外を一つ選び、最初の分析担当者に尋ねなくても、処理の経緯を再構成できる状態にします。

問題が起きた場合の復旧

クリーニング中に合計が変わった場合は作業を止め、各変換手順を比較して、欠落または重複が生じた箇所を特定します。作業用テーブルを記憶で修復せず、読み取り専用のエクスポートから復元します。キーが一意でない場合は、照合前に原データ責任者と想定するレコード粒度を決めます。日付や小数の解析方法が曖昧な場合は元の文字列を残し、正しいロケール規則を確認します。

AI が根拠のない説明を提案した場合はレポートから削除し、根拠の境界を改めて明示します。広い規則で一部の例が解決しても、別の箇所で誤一致を生むなら、その規則を取り下げ、該当項目を未解決へ戻し、対象を絞った再現可能なテストを設計します。原データを修正できない場合は、例外、リスク、責任者、次にレビューする契機を記録します。レポートを完成したように見せるためだけの調整項目を、無理に追加してはいけません。

再利用できる最終手順

元データのエクスポートを凍結して棚卸しし、構造を把握し、レコード粒度と正式なフィールドを定義し、規則を文書化した正規化コピーを作成し、厳格なものから条件付きのものへ承認済み照合規則を適用します。すべての例外について行単位の追跡経路を保持します。観測した差異と考えられる説明を分け、業務上の処置には責任者の承認を得て、データは権限のある原システムでのみ修正し、まっさらなエクスポートから再実行します。対象範囲、規則、解決済み項目、未解決項目、制約、レビュー責任をまとめて公開します。次回の照合が即席のフィルター操作にならず、同じ管理された方法を使えるよう、変換ログを保存します。