監査法人で、スタッフが作った監査調書を目的・手続・結論のつながりと記載ルールで点検し、主査のレビュー前に直し案を返す

処理の起点を決める

スタッフが調書を点検用のフォルダに書き出したことを起点にします。 電子調書のシステムから外へ通知を出せるかは製品によるため、この構成では書き出しをスタッフの操作にします。法人のサーバーで Python のスクリプトを10分ごとに動かし、新しい書き出しを見つけて処理します。

点検は「査閲待ち」にする前に1回だけ行います。 直したあとにもう一度点検させることもできますが、AIの指摘がゼロになるまで直す運用にすると、AIに合わせた書き方が身につきます。 2回目以降はスタッフが必要と思ったときだけにします。

監査報告書日のあとに行う監査ファイルの最終的な整理の段階では、この点検を動かしません。報告書230は、最終的な整理が完了したあとの調書の修正や追加に、理由と実施者・査閲者などの記録を求めています。整理の段階でAIの指摘に沿って調書を書き換えることは、この構成の対象外です。

入力データを集める

質を決めるのは、監査計画の該当部分です。 調書の目的が計画で識別したリスクに対応しているかは、計画を見なければ分かりません。計画を渡さないと、AIは調書の中だけで目的と結論のつながりを見ることになり、計画とのずれを見落とします。

指摘の例は、主査の基準をそろえるための材料です。 法人の記載ルールは抽象的になりがちで、AIはそれを一般論で解釈します。「この書き方にはこう指摘した」という例を20〜30件渡すと、指摘の粒度が法人の主査に近づきます。

データの取得方法を決める

調書は、電子調書のシステムからPDFで、表計算で作った調書はテキストに変換して取り出します。Claude API はPDFをそのまま読めますが、表計算のファイル（.xlsx）は文書として渡せません。 公式の説明では、.xlsx や .docx はテキストかPDFに変換してから渡す必要があるとされています。

表計算の調書はセル番地を残してテキストにします。 「C15のティックマークの説明が無い」と指せるようにするためです。画像にしてPDFにすると、どのセルの話かを指せなくなります。 数式のセルは、計算結果の値と数式の両方を書き出します。値だけだと、合計の行が手で打ち込まれたものか計算されたものかが分からず、「合計の根拠が書かれていない」という指摘が誤って出ます。

被監査会社から入手した資料（試算表、明細、契約書の写し）は送りません。 点検するのは調書の書き方で、資料そのものではないからです。調書の中に資料の内容が貼り付けられている場合も、入手元と参照番号が書かれているかだけを見ればよく、資料の中身を読ませる必要はありません。

PDFには上限があります。 公式の説明では、1リクエストあたり32MB、600ページ（コンテキストが100万トークン未満では100ページ）までで、パスワードや暗号化のかかったPDFは扱えません。 電子調書のシステムがパスワード付きで書き出す設定なら、点検用の書き出しだけ設定を分けます。

AIへ渡す前に整形する

1. 欄の空きの確認 … 実施者、完了日、参照番号、勘定科目が空いていないかを、調書の属性から確かめます
2. 参照番号の存在の確認 … 調書に書かれた他の調書への参照番号が、同じ監査ファイルに実在するかを、調書番号の一覧と照らします
3. ティックマークの置き換え … 記号を、法人の凡例に沿って「証憑と照合済み」のような文字に置き換えます。凡例に無い記号はそのまま残し、印を付けます
4. 被監査会社の特定情報の扱い … 会社名、取引先名、個人名を記号に置き換えます。金額は残します
5. 監査計画の該当部分の切り出し … 調書の勘定科目に対応するリスクと計画の部分だけを取り出します

1番目と2番目をAIにさせないのは、規則で確実に見られるからです。 欄が空いているか、参照先が実在するかは、プログラムで漏れなく見られます。AIには、文章を読まなければ分からないつながりだけを渡します。

3番目は、AIの読み違いを防ぐためです。 ティックマークは記号で、そのままでは意味が分かりません。凡例に無い記号に印を付けておけば、それ自体が「凡例の書き漏れ」という指摘になります。

4番目の置き換えは、監査チームの中で対応表を持ちます。 置き換えた記号と元の名前の対応は、点検用のフォルダの外、監査ファイルと同じ権限の場所に置きます。点検結果をスタッフに返すときに、記号を元の名前に戻してから返します。 記号のまま返すと、スタッフが調書と照らすのに手間がかかります。

AIに処理させる

させるのは、5つの観点で指摘を挙げ、直しの案を付けることだけです。

いちばん効くのは、1つ目の「目的と結論の対応」です。 スタッフの調書でいちばん多いのは、手続をこなしたあと、結論に「問題ない」とだけ書いてしまう形です。何について問題が無いのかが目的と対応していないと、関与していない人には何が確かめられたのかが分かりません。

3行目を禁じるのが大事です。 「売掛金の確認状の回収率が低いので、代替手続を追加してください」とAIが書くと、監査の判断がAIの提案に引っ張られます。 手続が足りないかどうかは主査が判断し、AIは書かれていることのつながりだけを見ます。

指示内容を固定する

あなたは監査法人で、スタッフが作成した監査調書を、主査の査閲の前に点検する担当です。
点検するのは調書の書き方だけです。監査上の判断はしないでください。

【点検の観点】
1. objective_conclusion: 冒頭の目的・アサーションと末尾の結論が同じことを述べているか。
   監査計画で識別したリスクに対応しているか。
2. nature_timing_extent: 実施した手続の種類・時期・範囲が書かれているか。
3. item_identification: 手続の対象を識別する特性（母集団、選び方、開始点、間隔、
   日付・番号、質問の相手と役職など）が書かれているか。
4. results_exceptions: 結果が書かれ、例外事項があればその扱いが結論に反映されているか。
5. firm_rules: 法人の記載ルールに沿っているか。

【指摘の書き方】
- 指摘ごとに、根拠にした調書の文をそのまま evidence に写してください。
- 書かれていないことの指摘は、evidence に「記載なし」と書き、
  どこに書かれているべきかを location に書いてください。
- 直しの案は、何を書き足せばよいかを1〜2文で示してください。
  調書の文を書き直した全文は出さないでください。
- 指摘の例と同じ粒度で書いてください。

【厳守事項】
- 証拠が十分か、結論が妥当か、手続が適切かは書かないでください。
- 追加の手続を提案しないでください。
- 金額を計算し直さないでください。
- 調書に無い事実を補わないでください。
- 判断がつかないものは severity を check にしてください。

【法人の記載ルール】{firm_rules}
【指摘の例】{review_examples}
【監査計画の該当部分】{plan_excerpt}
【調書の属性】{wp_meta}
【調書】（このあとに添付）

「追加の手続を提案しない」は、書かないと必ず出てきます。 手続の記載が薄い調書を渡すと、AIは親切に「〜も実施してはどうか」と書きます。それは書き方の指摘ではなく監査の判断です。 禁じたうえで、出力の項目にも提案の欄を作りません。

「記載なし」の書き方を決めておくのも大事です。 書かれていないことの指摘は、写す文がありません。写す文が無いときの書き方を決めておかないと、AIは調書に無い文を作って写します。 「記載なし」とどこにあるべきかを書かせれば、照合で区別できます。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "workpaper_id": "",
  "findings": [
    {
      "aspect": "objective_conclusion | nature_timing_extent | item_identification | results_exceptions | firm_rules",
      "severity": "fix | check",
      "location": "",
      "evidence": "",
      "comment": "",
      "suggestion": ""
    }
  ],
  "unknown_tickmarks": [""]
}

1つ目の理由は、aspect で指摘を数えられることです。 観点は5つの値に限っているので、スタッフごと、チームごとに、どの観点の指摘が多いかが出ます。item_identification が多いスタッフには、サンプリングの記録の書き方を教えれば済みます。

2つ目は、evidence を照合できることです。 「記載なし」以外の evidence は、調書の文に文字どおりあるかをプログラムが確かめます。見つからない指摘はスタッフに返さず、点検のログにだけ残します。 根拠の無い指摘を返すと、スタッフはAIの指摘全体を読まなくなります。

location は、調書のどこを直せばよいかを指す欄です。 PDFならページと見出し、表計算ならシート名とセル番地を書かせます。場所の無い指摘は、スタッフが調書の中を探すことになり、直す時間が延びます。 プログラムで location が空の指摘を見つけたら、点検結果の最後に回します。

3つ目は、出力に「判断」の欄が無いことです。 証拠の十分性や結論の妥当性を書く欄を作らなければ、AIがそこに何かを書くことはありません。禁止の指示と欄の設計の両方で、判断を出させないようにします。

システムへ連携する

電子調書のシステムへは書き込みません。 AIの点検結果を調書に取り込むと、査閲の記録とAIの指摘の区別がつかなくなります。 報告書230が求める査閲者・査閲日・査閲の対象の記録は、主査が残すものです。

点検結果のファイルは、調書番号を名前に入れて置きます。 スタッフは自分の調書番号でファイルを開き、主査は査閲のときに同じ番号のファイルを並べて開きます。通知は監査チームの中のやり取りに限り、外部のメールには流しません。 点検結果には調書の文が写されているので、調書と同じ扱いが要ります。

人が確認する

AIの指摘は、スタッフと主査の2段で読みます。

1. スタッフが指摘を読む … 指摘ごとに「直した」「直さない（理由）」を書きます
2. スタッフが調書を直す … 直しの案は書き足すべき内容の示しで、調書の文はスタッフが自分で書きます
3. 主査が指摘と返事を読む … 「直さない」の理由が妥当かを見ます
4. 主査が調書を査閲する … 証拠の十分性と結論の妥当性を判断し、査閲の記録を残します

4番目は、AIの点検の前と変わりません。 AIの点検を通ったことを、査閲の範囲を狭める理由にしません。変わるのは、主査が4番目にたどり着くまでの時間です。

スタッフの「直さない」には、主査が一言返します。 理由が妥当なら「了解」、妥当でなければ直してもらいます。この往復が、以前のレビューノートの代わりになります。 主査が書く量は減りますが、スタッフの判断を見る機会は残ります。

主査がAIの指摘に同意しなかったときは、その記録を残します。 「この指摘は法人のルールの読み違い」と主査が書いたものは、品質管理の部署が集めて、記載ルールか指摘の例を直します。

例外に対処する

凡例に無いティックマークは、その調書だけの問題でないことが多いものです。 同じ記号が複数のスタッフの調書に出るなら、法人の凡例のほうに足りないものがあります。

最後の行で、点検できないときに調書を止めないのは意図してのことです。 AIの点検は主査の査閲を助けるためのもので、査閲の前提条件ではありません。 点検できなかった調書は、今までどおり主査が査閲します。

記録を残す

• 点検した調書の番号と、書き出しの日時
• Claude API に送った内容（置き換え後）と、返ってきたJSON
• 規則の確認の結果
• スタッフの返事（直した／直さない理由）
• 主査が同意しなかった指摘と、その理由
• 使った記載ルールと指摘の例の版

ログは監査ファイルの外に置きます。 AIの点検結果は査閲の前の作業の材料で、監査調書そのものではありません。監査ファイルに入れるかどうかは、法人の品質管理の部署が決めます。 置く場所と保存の期間も、法人の文書管理の決まりに合わせます。