内部監査AI支援 — 使い方と考え方
AIは判断材料を整え、判断は監査員が下す–これが全体を貫く原則
| AIがすること | 監査員がすること |
|---|---|
| 事実が十分か確認する質問を出す | 質問に事実で答える |
| 事実を監査記録の文体に整える | 内容を確認・修正する |
| 該当しそうな規格条項を3つ提示する | どの条項にするか決める |
| 指摘文の案を作る | 文面を確認・修正して確定する |
AIは「答えを出す装置」ではなく、監査員が見落としがちな点を問い、 候補と根拠を示し、文章化の手間を減らす役割
AIの提案に対する反論
誤った反論が通らない設計– 誰でも反論できますが、通るのは規格に照らして正しい反論だけ—これによって、間違った学習が防がれます
| 応答 | 意味 | 対応 |
|---|---|---|
| 認める | 反論が正しい。修正案を提示 | 「この内容で生成し直す」を押す |
| 部分的に認める | 争点の一部だけ修正 | 内容を見て判断 |
| 維持する | 反論が誤り、または根拠不足。理由を示して現状維持 | 納得すれば従う。しなければ手で編集 |
監査におけるAIによる解釈原則
AI支援の判断規律を定める「解釈原則」は現在、Dropbox内のマークダウンファイルを直接編集し php artisan ia:import-principles –force で投入する運用になっている・・・このため原則を1行足すのにファイル編集とコマンド実行が必要で、監査作業の流れが途切れる・・・原則を画面から編集できるようにし、気づいた瞬間に追記できる状態にする
| 種別 | 編集できる人 | 効果範囲 |
|---|---|---|
| 共通原則(company_id = NULL) | システム管理者(role=1)のみ | 全テナント |
| テナント原則(company_id = 値) | 管理責任者 / 会社管理者 | 自社のみ |
会社概要ページの「内部監査」カードに「解釈原則設定」ボタンを追加する。
- 表示条件: 管理責任者 / 会社管理者 / システム管理者
- 既存の「監査員設定」(AUD-USER)と並べて配置し、同じ扱いにする
- 共通原則: システム管理者でログインしている場合のみ [編集][削除][＋追加] を表示
- 自社の追加原則: 管理責任者・会社管理者に [編集][削除][＋追加] を表示
- 章立て(■1.、■2.…)は本文中の見出しとして扱う——現在の原則集はマークダウンの見出し+番号付き項目という構造なので、無理にDB上で章と項目に正規化せず、1レコード=原則集全体のテキストという現行構造を維持する(ia_principles.body は既にテキスト全体を保持している)
現在の原本は Dropbox 内の audit_assist_proto/principles/audit_principles.md
画面編集を導入するとDBが原本になり、ファイルとの二重管理になる。
現在の原本は Dropbox 内の audit_assist_proto/principles/audit_principles.md
画面編集を導入するとDBが原本になり、ファイルとの二重管理になる
原則集のマークダウンをリポジトリ内に移す
(例: docs/audit_principles.md)。機密ではないためgit管理して問題ない
- ファイルは初期投入用のシードと位置づけ、以後の編集は画面から行う
- ia:import-principles コマンドは新規環境の初期セットアップ用として残す
(本番デプロイ時の初回投入に使う) - この位置づけを README またはコマンドのdocblockに明記すること
AIを育てる — 2つの経路
| 原則udit_principles.md | 憲法に当たるものであり、常に効く、判断の規律を伝える | 原則にすべきもの: 同じ型の誤りが2回以上起きた 規格の記述に基づいて一般化できる 審査員としての規律に関わる(過大解釈の抑制、表現の強度など) |
| 事例 | 判例であり、似たときだけ効く、具体的な紐づけと力点を伝える | 指摘を「決定・保存」すると、その判断が次回以降の参考事例になります–特別な作業は不要です。監査業務そのものが教材を生みます |
原則は事例の誤りを打ち消せます–事例に古い判断が混じっていても、原則が効いてAIはそれを真似しません
原則については、AIの判断に繰り返し違和感があるとき、原則を1行足します
「解釈原則設定」→ 編集して保存
次のAI呼び出しから効きます。版が記録され、履歴から復元もできます