結論: 監査調書のレビューは「証憑とのつき合わせ」「形式チェック」「例外抽出」の3層に分解でき、このうち下2層はClaude Codeのサブエージェント並列実行とHooksでかなり機械化できます。リスク評価と最終的な監査意見は人が担う前提を崩さずに、レビュアーの一次チェック工数を圧縮する設計が現実的です。
この記事の要点:
- 調書レビューを
~/.claude/agents/に置いたサブエージェント（形式チェック係・証憑突合係・例外抽出係）に分担させ、1セッションで並列に走らせる構成 PostToolUse/SubagentStopHooksで「数値の根拠リンクが付いていない指摘」を自動で弾く、レビュー品質の二重ゲート- 本番運用で詰まった4つの失敗パターンと、士業・監査領域ならではの回避策（最終判断は必ず人、という線引きの実装方法）
対象読者: 監査法人のシニア・マネージャー、事業会社の内部監査部門、J-SOX対応の業務プロセス改善を担うエンジニア・PM
今日やること: まず.claude/agents/に「形式チェック専用」のサブエージェントを1つ書いて、過去の調書1冊で空回し検証してみる。これだけなら30分で試せます。
事例区分: 実装パターン解説
本記事は、Claude Codeの公式ドキュメントと筆者の導入支援経験をもとに構成した実装パターンの解説です。特定の監査法人の実案件をそのまま記述したものではなく、複数のレビュー業務に共通する構造を一般化しています。数値で「試算」と明記したものは想定値、それ以外は公式ドキュメントで確認した仕様です。監査意見・リスク評価・不正の最終判断は、必ず公認会計士・監査責任者が行う前提で読んでください。
「調書、まだ全部見れてない」——四半期レビューの締め切り前、深夜のオフィスでマネージャーがつぶやく光景。監査・内部監査の現場を支援していると、これは本当によく聞きます。
監査調書（ワークペーパー）のレビューは、シニアやマネージャーの時間を最も食う作業のひとつです。証憑との金額のつき合わせ、参照番号の整合性、テスト件数のカウント、サンプリングの記録漏れ……。一つひとつは単純なのに、調書が数十冊あると人間の集中力が持たない。しかも、こういう「形式的だが量が多い」チェックでこそ、人は見落とします。
ここで効くのが、Claude Codeのサブエージェントとフックです。「形式チェックは機械に一次レビューさせ、人はリスク評価に集中する」という分業を、設定ファイルだけで組めるようになりました。この記事では、その実装を7ステップに分けて、設定ファイル付きで解説します。
監査調書レビューの自動化とは——「形式チェック」と「監査判断」を分ける発想
レビュー作業を3層に分解する
そもそも調書レビューを自動化する前に、何を機械に任せ、何を人が握るのかを切り分ける必要があります。筆者がレビュー業務を整理するとき、いつも次の3層に分けています。
- 形式チェック層: 参照番号の整合、必須項目の記載漏れ、テスト件数とサンプル一覧の件数一致、日付の前後関係。ルールが明確で正解が一意に決まる
- 証憑突合層: 調書に記載された金額・取引先・契約番号が、添付された証憑（請求書・契約書・銀行明細のテキスト）と一致するか。半構造化データの照合
- 監査判断層: 検出された差異が重要かどうか、追加手続きが必要か、内部統制の不備に当たるか。ここは人間の専門的判断
Claude Codeで機械化するのは1層目と2層目だけです。3層目に踏み込ませると、後述する失敗パターンに直結します。この線引きを設定で強制するのが、本記事の肝になります。
なぜサブエージェントを使うのか
形式チェックと証憑突合を1つのプロンプトで一気にやらせると、長い調書では途中でコンテキストが膨らみ、指摘の粒度がぶれます。Claude Codeのサブエージェントは「それぞれ独立したコンテキストウィンドウで動き、結果のサマリーだけを親に返す」仕組みなので、レビュー観点ごとに係を分けるのに向いています（Claude Code Subagents Docs、参照日: 2026-05-21）。
サブエージェントの基本的な分担設計は、契約書レビュー自動化の実装事例でも触れた「観点ごとにレビュアーを分ける」考え方と共通しています。監査調書はそれを定型業務に応用したかたちです。
動作環境と前提条件——始める前に確認すること
| 項目 | 要件 | 備考 |
|---|---|---|
| Claude Code | v2.1.0 以上 | サブエージェントの並列実行・HooksのSubagentStopが安定して使える |
| Anthropicプラン | Max plan（月100ドル）以上を推奨 | 調書を複数冊まとめて流すとトークン消費が大きい。Pro plan（月20ドル）でも動くが上限に届きやすい |
| 調書データ | テキスト化済み（Markdown / CSV / プレーンテキスト） | PDFや画像のままだと精度が落ちる。OCR・テキスト抽出は前段で済ませる |
| 実行場所 | 監査法人・社内の管理端末 | クライアントの機密データを扱うため、所属組織の情報管理規程に従うこと（後述） |
重要なのは、調書と証憑を扱う環境を所属組織のルールに合わせることです。監査データは典型的な機密情報なので、どの端末で、どのプランで、ログをどう残すかは、必ず情報セキュリティ部門・監査責任者の承認を取ってから決めてください。本記事は技術的な実装手順であり、特定の運用が情報管理上問題ないと保証するものではありません。
Step 1: レビュー観点ごとにサブエージェントを定義する
まずは.claude/agents/（プロジェクト単位）または~/.claude/agents/（全プロジェクト共通）に、係ごとのMarkdownファイルを置きます。サブエージェントはYAMLフロントマターと本文（システムプロンプト）で定義し、必須フィールドはnameとdescriptionだけです。
# .claude/agents/form-checker.md
# 動作環境: Claude Code v2.1.0
# 役割: 調書の「形式チェック層」だけを担当する係
---
name: form-checker
description: 監査調書の形式チェック係。参照番号の整合、必須項目の記載漏れ、テスト件数の一致を確認する。差異を見つけたら指摘するが、重要かどうかの判断はしない。
tools: Read, Grep, Glob
model: haiku
---
あなたは監査調書の形式チェック専門のレビュアーです。
渡された調書ファイルについて、以下「だけ」を確認してください。
1. 参照番号（W/P No.）が本文・索引・相互参照で一致しているか
2. 必須項目（作成者・査閲者・作成日・テスト目的・結論）の記載漏れがないか
3. 「テスト件数」と「実際のサンプル一覧の件数」が一致しているか
4. 日付の前後関係に矛盾がないか（査閲日 < 作成日 など）
ルール:
- 各指摘には必ず「該当箇所（行・W/P No.）」を添える
- 差異が監査上重要かどうかは絶対に判断しない（人間レビュアーの領域）
- 不足情報があれば、推測せず「確認が必要」と明記する
model: haikuにしているのは、形式チェックは判断を要しない定型作業なので、速くて安いモデルで十分だからです。Claude Codeは観点ごとにモデルを変えられるので、コストを観点単位で最適化できます。
同じ要領で、証憑突合係evidence-matcher.md（金額・取引先・契約番号を証憑テキストと照合）と、例外抽出係exception-finder.md（しきい値超えの取引・連番の飛び・週末計上などの異常パターンを列挙）を作ります。それぞれdescriptionに「いつ呼ぶか」を明確に書くのがポイントです。Claudeはこの説明文を見てどの係に振るかを決めるためです。
Step 2: 親セッションから3係を並列で走らせる
サブエージェントは1つのセッション内で並列に動かせます。レビュー対象の調書を渡して、3観点を同時に投げます。
# Claude Code セッション内での指示例
audit-wp/2026Q1/ 配下の調書を全件レビューしてください。
form-checker / evidence-matcher / exception-finder の3エージェントに
それぞれの観点で並列にチェックさせ、結果を W/P No. ごとに突き合わせて
1枚のレビュー指摘一覧（Markdown表）にまとめてください。
各指摘には必ず「観点」「該当W/P No.」「根拠（証憑名 or 行番号）」を付けること。
重要性の判断・追加手続きの要否は書かないでください（人間が判断します）。
サブエージェント同士は入れ子にできない（サブエージェントが別のサブエージェントを呼べない）仕様なので、束ねるのは常に親セッションの役割です。これは無限ネストを防ぐための制約で、レビューの統括役が1つに固定されるという点ではむしろ運用しやすい構造です。
Step 3: Hooksで「根拠なき指摘」を機械的に弾く
レビューの自動化で一番怖いのは、AIが「それっぽいが根拠のない指摘」を量産することです。これを防ぐために、Claude CodeのHooksで品質ゲートを2段構えにします。Hooksはsettings.jsonに定義し、特定のイベントでスクリプトを発火させる仕組みです（Claude Code Hooks Docs、参照日: 2026-05-21）。
まず、サブエージェントが仕事を終えた瞬間（SubagentStop）に、出力された指摘に「根拠（W/P No. または証憑名）」が付いているかを検査します。
// .claude/settings.json
{
"hooks": {
"SubagentStop": [
{
"matcher": "form-checker|evidence-matcher|exception-finder",
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/check-evidence.sh",
"timeout": 30,
"statusMessage": "指摘の根拠リンクを検査中..."
}
]
}
]
}
}
check-evidence.sh側で、指摘1件ごとに「W/P No.」または「証憑名」の参照があるかを正規表現でチェックし、欠けていれば終了コードを立てて差し戻します。これで「根拠を書かないレビュアー」は構造的に排除できます。
Step 4: PreToolUseで監査判断への踏み込みを止める
もう1つの品質ゲートは「機械が監査判断に踏み込まないこと」の強制です。サブエージェントのtoolsを読み取り系（Read, Grep, Glob）に絞っているので調書を書き換える事故は起きませんが、それでも出力テキストの中で「重要な不備である」「修正が必要」と断定してしまうことがあります。
ここはPostToolUse系のHookで、出力に「重要」「不備確定」「要修正」といった判断ワードが含まれていたら警告を出す運用にします。完全にブロックすると正常な引用までかかってしまうので、本番では「人間レビュアーに目視確認を促す警告」に留めるのが実用的でした。「最終判断は人」という線をシステムで可視化するイメージです。
Step 5: 段階的に導入する（3フェーズ）
いきなり全調書を流すと、現場の信頼を失います。段階を踏みます。
Phase 1（1〜2週間）: 既にレビュー済みの過去調書1冊で空回し。AIの指摘と、人間レビュアーが実際に見つけた指摘を突き合わせ、「拾えた／拾えなかった／誤検知」を分類します。誤検知率が許容範囲かをここで見極めます。
Phase 2（3〜4週間）: 当期の調書で、人間レビューの「前」にAI一次レビューを挟む並走運用。人間は最終レビュアーとして残し、AIの指摘一覧を出発点にする。工数が減るかをこの期間で測定します。
Phase 3（2〜3ヶ月）: 形式チェック層の指摘は信頼できると判断できたら、その層は確認の比重を下げ、人間はリスク評価・例外の重要性判断に時間を振り向けます。証憑突合層は引き続きサンプリングで人間が裏取りします。
Step 6: 効果の測り方（想定試算）
効果は「削減できた」と一言で言わず、測定方法とセットで残します。以下は実装パターンを当てはめた場合の想定試算であり、実測の保証ではありません。
| 指標 | 導入前（想定） | 導入後（想定試算） | 測定方法 |
|---|---|---|---|
| 調書1冊あたり一次レビュー時間 | 約45分 | 約18分 | 形式・証憑チェックをAI一次レビューに置換し、人間は確認に専念した場合の試算 |
| 形式不備の検出 | レビュアーの集中力に依存 | 機械が網羅的に走査 | 過去調書での再現テストで「人間が見落とした形式不備」の検出件数を比較 |
| 調書1冊あたりトークンコスト | — | 0.5〜2ドル程度（試算） | 形式チェックをHaiku、突合をSonnetに振り分けた場合の概算 |
「人間が見落とした形式不備を機械が拾う」効果は、時間削減より価値が大きいことがあります。レビュー品質の底上げという観点でも測っておくと、稟議が通りやすくなります。
Step 7: 監査ログとガバナンスを残す
監査業務でAIを使う以上、「いつ・どの調書に・どのAIが・何を指摘したか」のログは必須です。Claude CodeのSessionEnd Hookで、その日のレビュー指摘一覧と使用モデル・トークン数を監査ログとして保存する運用にしておきます。
これは品質保証のためでもあり、後から「AIの指摘をどう扱ったか」を説明できるようにするためでもあります。AIはあくまで一次レビューの補助ツールであり、監査調書の十分性・適切性に責任を持つのは人間のレビュアーです。この前提は、所属組織の品質管理基準・職業倫理規程に従って明文化しておくことを強くおすすめします。
【要注意】よくある失敗パターンと回避策
失敗1: 監査判断までAIにやらせてしまう
❌「この差異は重要な不備なので報告すべき」とAIに結論を書かせる
⭕ AIは「差異がある事実」と「根拠」だけを出し、重要性の判断は人間が行う
なぜ重要か: 重要性の判断は専門的職業判断であり、AIに代替させると監査の品質と責任の所在が崩れます。Step 4のHookで判断ワードに警告をかけるのは、この線引きを運用に埋め込むためです。
失敗2: PDF・画像のまま流す
❌ スキャンしただけのPDF調書をそのまま投げる
⭕ テキスト抽出・OCRを前段で済ませ、構造化したテキストを渡す
なぜ重要か: レイアウト崩れや読み取りミスが、そのまま誤検知・見落としになります。証憑突合の精度は入力データの質で決まります。
失敗3: 根拠のない指摘を信用する
❌ AIが出した指摘をそのまま調書修正に反映する
⭕ Step 3のHookで根拠リンクを必須化し、人間が証憑に当たって裏を取る
なぜ重要か: 正直にお伝えすると、AIは時々もっともらしい誤った指摘をします。だからこそ「根拠なき指摘を弾く仕組み」と「人間の裏取り」をセットにしないと、かえってレビュー品質を下げます。
失敗4: 機密データの扱いを決めずに走り出す
❌ どの端末・どのプランで動かすかを決めないまま本番調書を流す
⭕ 情報セキュリティ部門・監査責任者の承認を取り、扱う環境を明文化してから始める
なぜ重要か: 監査データは典型的な機密情報です。技術的に動くことと、組織として許容されることは別問題です。所属組織の規程・コンプライアンスに必ず従ってください。
まとめ：今日から始める3つのアクション
- レビュー観点を3層に分ける: 自分のチームの調書レビューを「形式チェック／証憑突合／監査判断」に分解し、機械に任せられる範囲を紙の上で線引きする
- 形式チェック係を1つ書く:
.claude/agents/form-checker.mdを作り、過去調書1冊で空回し検証する（30分で試せます） - 根拠ゲートのHookを入れる:
SubagentStopHookで「根拠なき指摘」を弾く仕組みを入れ、人間が裏取りする運用を最初から組み込む
監査・内部監査領域でのClaude Code活用は、まだ各社が手探りの段階です。Uravationでは士業・専門業務でのAI実装を個別にサポートしています。自社のレビュー業務をどこまで機械化できるか相談したい方は、士業・専門業務の実装事例一覧もあわせてご覧ください。実際の導入設計のご相談はお問い合わせフォームからどうぞ。
よくある質問（FAQ）
Q1. 監査調書のレビューをAIに任せて、監査の品質基準を満たせますか？
A. AIに任せるのは形式チェックと証憑突合の「一次レビュー」までです。重要性の判断・監査意見・内部統制の不備認定は、必ず公認会計士・監査責任者が行う前提です。AIは補助ツールであり、最終判断者ではありません。品質管理基準・職業倫理規程に従って運用してください。
Q2. クライアントの機密データをClaude Codeに入れて大丈夫ですか？
A. それは技術ではなく組織のガバナンスの問題です。どの端末・どのプランで扱うか、ログをどう残すかを、情報セキュリティ部門・監査責任者の承認を得て決めてください。本記事は特定の運用が情報管理上適切であると保証するものではありません。
Q3. サブエージェントは何個まで並列で動かせますか？
A. 1セッション内で複数のサブエージェントを並列に動かせます。ただしサブエージェントが別のサブエージェントを呼ぶ入れ子はできません（公式仕様）。束ねる統括役は常に親セッションです。
Q4. どのプランが必要ですか？費用はどのくらいですか？
A. Anthropicのプランは月20ドルのProから利用できますが、調書を複数冊流すならMax plan（月100ドル）以上を推奨します。調書1冊あたりのトークンコストは、観点ごとにモデルを振り分けた場合で0.5〜2ドル程度の試算です（2026年5月時点の概算。最新の料金は公式サイトで確認してください）。
Q5. 形式チェック係にHaiku、突合係にSonnetと分けるのはなぜですか？
A. 形式チェックは正解が一意に決まる定型作業なので、速くて安いHaikuで十分です。証憑突合は半構造化データの照合で多少の推論が要るためSonnetを使います。Claude Codeはサブエージェントごとにmodelを指定できるので、観点単位でコストを最適化できます。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（@SuguruKun_ai、フォロワー約10万人）で活用法を発信。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。
