利益:
- サンプリングのリスクと全母集団テスト (100% テスト) のロジックを理解し、データの準備、ルールの作成、結果の解釈に人工知能を使用できるようになります。
- 人工知能のサポートを利用して、大規模なデータセットでのマッチング、完全性、精度のテストを設計および実装する能力
- 全母集団テストの例外リストは結果ではなく、監査人が検討する始まりであり、最終的な評価は監査人に属することを理解する能力。
監査という職業の最も基本的な制限の 1 つは、監査人が長年にわたってサンプリングに取り組む必要があるということでした。ビジネスが年間に発行する 180,000 件の請求書を手動で確認することはできません。そこで、統計的または判断的手法を使用して数百のレコードを選択し、テストして、その結果を母集団全体に一般化します。サンプリングは強力で正当な手法ですが、固有のリスクが伴います。サンプリング リスク - 選択したサンプルが母集団を代表していない可能性があり、そのサンプルに含まれる真の誤差が、探している場所に正確に当てはまらない可能性があります。
データ分析と AI はこの状況を変えます。母集団全体、つまり 100% をテストできるようになりました。これは完全母集団テストと呼ばれます。私たちはこの単元を、「サンプルから全体へ」の移行、それがもたらす力、そして多くの人が見落としている新たな責任を理解することに専念します。なぜなら、全人口検査は検査を促進しないからです。それはテストの性質を変え、試験官に新たな負担を課すことになります。
サンプリングと全集団検査の違い
古典的なサンプリングでは、ロジックは次のとおりです。「小さいながらも代表的なグループを徹底的にテストし、結果を全体として解釈しましょう。」全母集団テストでは、論理が逆になります。「一定のルールに従って全体をスキャンし、ルールから外れる例外を見つけて徹底的に調べます。」最初のアプローチでは、リスクは「間違ったサンプルを選択する」ことです。 2 番目のリスクは、「間違ったルールを記述する」ことと「不完全または誤ったデータを扱う」ことです。
次の表では、2 つのアプローチを比較しています。
サイズ
サンプリング
全集団検査 (100%)
範囲
人口の一部
人口全体
主なリスク
サンプリングリスク（表現誤差）
ルールエラー + データ整合性エラー
出力
テスト結果の数には限りがあります
ルールに従わない例外のリスト
監査人の負担
選択 + テスト
ルール設計 + 例外評価
AIの役割
サンプル選択のお手伝い
データの準備、ルールの作成、例外のマーク付け
注: 全集団テストは、「すべてをテストした、仕事は完了した」という意味ではありません。それどころか、通常は、より多くの項目を調べることができます。日付、金額、承認ルールに従って 180,000 件の請求書すべてを実行すると、おそらく 900 件の例外が見つかるでしょう。これらはそれぞれ質問です。答えではありません。ここで監査司法が登場します。
データの完全性: テストの目に見えない基礎
全母集団テストの最大の落とし穴は、テストの品質がデータの品質に依存することです。 「データの 100% をテストしました」という言葉は、所有しているデータが実際に母集団の 100% である場合にのみ意味を持ちます。システムからデータを取得するときにフィルターが間違っていた場合、一部のレコードが省略された場合、または金額列が小数点エラーで転送された場合、実際には不完全なデータまたは破損したデータに対して「完全な」テストが実行されます。したがって、データの完全性と正確性を確認することは、全集団検査における最初の不可欠なステップです。
完全性を検証するための実際的なチェック:
- レコード数の調整: 取得したデータセット内の行数は、システム内のレコードの合計数と一致しますか?
- 金額の調整: データセット内の合計金額は、試算表/子会社内の関連する勘定科目の合計と一致していますか?
- 日付範囲: データに含まれる期間の最初の日と最後の日です。欠落している月/日はありますか?
- 空スペースと不良スペースのスキャン: 必須フィールド (日付、金額、口座コード) にスペースや意味のない値はありませんか?
AI は、データのクロール、合計の取得、空きスペースのカウント、日付範囲のレポートなど、これらすべてのチェックを支援します。しかし、合意が「成立」するかどうかを判断し、差異を調査し、データが監査の目的に適していることを確認するのは監査人です。
注意: データの完全性を検証せずに、ワークシートに「すべてのデータをテストしました」と書き込まないでください。欠損データに対する全母集団テストは、一見完全であるように見えますが、誤解を招きやすい保証を提供します。
AI を使用した全人口テスト: ステップバイステップ
- データを安全に準備します。個人/プライベートフィールドを匿名化するか、プレースホルダーに置き換えます。可能であれば法人契約車両をご利用ください。
- 完全性を確認します。レコード数と金額を調整します。
- テストルールを明確に定義します。何が「例外」に該当するのでしょうか? (例: 未承認の請求書、週末に発行された請求書、多額の支払い、締め日以降に記録された収入。)
- AI を使用してルールを適用します。 AI はルールをデータに適用し、例外のリストを生成します。監査できるようにルールを明確に記述します。
- 優先順位を付けて例外を確認します。すべての例外を証拠とともに調査します。誤検知に対処し、実際の結果を正当化します。
- 結果を文書化します。ルール、例外の数、検査された項目、結論をワークシートにリンクします。
ミニケース3個
ケース 1 — 切断テスト。監査人は年末の収益カットをテストしたいと考えていました。彼は 42,000 件の販売請求書を全母集団として取り上げ、AI に「請求書の日付は 12 月 31 日までであるが、発送/配達日は 1 月 1 日以降であるリストレコード」を強制させました。 YZは118の記録をマークした。監査人はこれらを検査しました。96 件はタイミングの違いのない正当な取引 (同日納品)、22 件は実際には翌年の収益であり、前期に記録されました。これら 22 項目は、重要性には劣るものの、パターンを示していたため報告されました。 AIは118の質問をしました。監査人は 22 件の回答を見つけました。
ケース 2 — 完全性が省略された場合。チームメンバーの一人は、18万件の請求書に対して全集団検査を行ったと述べた。例外はなく、彼は安心しました。担当者はデータセットの総量を試算表と比較しました：データ 1 億 5,500 万 TL、試算表 2 億 1,000 万 TL。システムからデータを取得しているときに、ブランチがフィルタリングされて除外されていたことが判明しました。 「完全な」テストでは、実際にはデータの 4 分の 1 が欠落していました。テストは正しいデータで実行されました。教訓: 完全性の確認なしに完全な母集団テストはありません。
ケース 3 — ルールエラー。監査人は AI に「50,000 TL を超える未承認の支払いをリストする」というルールを作成させましたが、「承認」フィールドがシステム内の 2 つの異なる列 (電子承認と手動承認) に保持されていることには気づきませんでした。 AI は 1 件だけを調べたため、300 件の支払いを「不承認」としてマークしました。調べてみると、そのほとんどが他の欄で承認されていることがわかりました。間違ったルールにより、数百もの誤検知が発生しました。監査人は両方の列を含めるようにルールを修正しました。教訓: 監査人は、ルールがデータとビジネス プロセスに準拠していることを検証します。
弱いプロンプト / 強いプロンプト
弱いプロンプト:
この請求書データ内で問題のあるレコードを見つけます。
問題: 「問題がある」の定義がない。 AI は何を例外とみなすべきかを知りません。彼はランダムな信号に従って、または自分が作成した基準に従って動作します。再現性や監査性はありません。
強力なプロンプト:
あなたの役割: あなたは、独立監査人のデータ分析アシスタントです。判断は私にあります。ルールを適用し、例外リストを生成します。コンテキスト: 以下は匿名化された販売請求書データです (列: invoice_no、invoice_date、delivery_date、amount、approval_status、branch)。年度末: 31.12.STEP 1 - 完全性: 試算表と比較できるように、レコードの総数と合計金額を教えてください。空のスペースや不足しているスペースがあるかどうかを報告します。ステップ 2 - カット テスト ルール: 請求書日付 <= 31.12 かつ納品日 >= 01.01 のレコードを「カットオフ例外」としてリストします。ステップ 3 - 監査できるように、ルールをプレーン テキストで記述します (どのような条件を適用したか)。ルール: ルールは私が指定しました。変更しないでください。 「レビューの例外」としてフラグを立てたレコードを送信します。 「エラー/発見」とは言わないでください。データから推測できないことをでっち上げないでください。
このリクエストは、最初に完全性を確認し、例外ルールを明確に定義し、ルールの平文 (監査可能性) を要求し、出力を「例外」として位置付けるため、強力です。
よくある間違い
- 完全性検証をスキップします。不完全または破損したデータに対して「完全な」テストを実行し、誤った保証を与える。
- 例外を発見と誤解する。 AI によってマークされたレコードを検証せずにエラーをカウントする。誤検知の排除を回避します。
- ルールを確認していない。ルールがデータとビジネスプロセスに準拠しているかどうかを確認せずに、何百もの偽フラグを生成します。
- 曖昧なルールを書くこと。 「問題のあるレコードを検索」などの未定義のプロンプトを使用すると、再現不可能な結果が得られます。
- 一度のスタートで満足すること。例外の数が予期されたものと大幅に異なる場合は、ルールまたはデータをクエリしません。
ヒント: 例外の数が少なすぎる (ゼロに近い) か、または多すぎる場合は注意してください。ゼロは通常、「ルールが正しく書かれていない」または「データが欠落している」ことを意味します。数値が極端に大きい場合は、ルールが広すぎることを示します。優れた監査人は、「例外がない」ことと「すべてが例外である」ことの両方を疑います。
要約すれば
全集団テストは監査における大きな進歩です。サンプリングのリスクを排除し、データを 100% スクリーニングします。しかし、無料ではありません。これにより、(1) データの完全性と正確性の検証、(2) 発生した個々の例外の評価という 2 つの新たな責任が生じます。 AI がデータを準備し、ルールを適用し、例外にフラグを立てて、数時間のスキャンを数秒に短縮します。ただし、ルールの正確性、データの完全性、例外の評価は監査人に属します。例外は結果ではなく、始まりです。
アプリケーションタスク
既存の (または仮想の) トランザクション データセットを考えてみましょう。まず、2 つの完全性チェック (レコード数と金額調整) を定義します。次に、監査目的で明確な例外ルールを作成します (例: 週末に発行される請求書や例外のカットなど)。上記の強力なプロンプト パターンを使用して、AI に最初に完全性を実行させ、次にルールを実行させます。表示される例外の最初の 10 個は、「実際の結果か、それとも誤検知か?」です。次のように分類する練習をし、それぞれについてどのような証拠を探すかを書き留めます。
チェックリスト
- [ ] データを匿名化して安全運転しました。
- [ ] レコード数と量を照合してデータの完全性を確認しました。
- [ ] 空き領域/不良領域をスキャンしました。
- [ ] 例外ルールを明確で再現可能な方法で定義しました。
- [ ] AI からルールの平文を受け取り、データとビジネス プロセスへの準拠を検証しました。
- [ ] 例外の数の妥当性 (少なすぎる/多すぎない) に疑問を抱きました。
- [ ] 私はそれぞれの例外を調査結果ではなく、調査すべき質問として扱いました。誤検知を排除しました。