監査の独立性とClaude利用 — 外部送信をどう考えるか
クライアントデータを生成AIに入力する行為が監査の独立性を損なうかを整理し、外部送信の技術的な対策をClaudeの契約形態で確認します。
被監査会社のデータを生成AIに入力すると、監査人の独立性を損なうのでしょうか。JICPA研究文書第11号の構成をたどると、外部送信は独立性の論点ではなく、情報セキュリティ(機密性)の論点として置かれています。「独立性」を見出しに掲げているのは、AI自体を保証する側の話です。監査人がAIを使う場面で文書が繰り返すのは、責任・補助的な利用・懐疑心です（研究文書が示す監査AIの利用領域全体はJICPA監査AI研究文書が示すClaude活用と限界で扱っています）。
研究文書で「独立性」が出てくるのはAIを保証する側の話
研究文書で独立性が見出しになるのは、「AIに関連する保証」の節だけです。AIのリスクが高まる以上、各企業の自主的なチェックに任せず、独立した第三者が信頼性を付与していく必要がある。この文脈で、公認会計士・監査法人が貢献できる理由の一つに独立性が挙げられています。
独立性は職業倫理の一つとして強く要求される事項で、保証業務実施者の要件は、財務諸表監査の監査人に求められる独立性が参考になるとされています。つまりここでの独立性は、AIを保証する立場の資格要件です。監査人が生成AIに入力する行為そのものを、独立性の要件に照らして論じた箇所ではありません。
同じ「AIを使う」でも、確認する相手が分かれる
監査人がAIを使う側の話は別の章にあります。そこで問われるのは意見形成の主体で、データの行き先は情報セキュリティの章で別に扱われます。
研究文書が分けている2つの問い
AIの出力をどう扱うか
監査人は監査意見に単独で責任を負い、AIや専門家の業務を利用しても責任は軽減されません。生成AIの利用は補助的な用途にとどめ、出力は鵜呑みにせず、職業的専門家としての懐疑心を保ちます。
被監査会社のデータをどこへ送るか
生成AIの利活用は、機密性の目的を阻害するリスクが高いとされます。機密情報の入力は、適切な情報セキュリティが確保されていなければ避ける、という立場です。利用規則は各監査事務所で定めることが重要とされます。
左の問いは監査人自身と事務所の品質管理が、右の問いはAI提供会社との契約と事務所内のルールが担います。「Claudeは安全か」という一問で両方を済ませようとすると、どちらの確認が終わったのかが見えなくなります。
AIの出力は処理結果の種類ごとに扱いが違う
研究文書の図表10は、AIの処理結果を説明可能性の観点から6区分し、監査上の取扱いを割り当てています。生成AIのハルシネーション(事実に基づかない出力)は、説明可能かどうかが場合によるとされ、監査では利用できない区分です。
| 処理結果のケース | 監査上の取扱い |
|---|---|
| 通常の監査人では思いつかない独創的な見解 | 監査上の取扱い根拠を検証して監査に活用する |
| 意味不明で説明できない出力 | 監査上の取扱い監査では利用できない |
| 被監査会社がロジックを不正に操作したケース | 監査上の取扱い再計算など根拠を慎重に検討する |
| 学習データのバイアスによる誤った見解 | 監査上の取扱い再計算など根拠を慎重に検討する |
| バイアスがなく合理的な見解 | 監査上の取扱い監査で利用可能 |
AI監査ツールの使いどころにも線が引かれています。売上全明細を調べて不正の兆候を概括的に把握するような使い方はリスク評価手続の補助にとどまり、リスク対応手続で使うときは、手続を細分化したうえで監査人が最終的な判断を行います。AIの処理結果を見落としても、AIに責任能力はなく、利用を理由に監査人が免責されることはありません。
利用例ごとに、事務所の外へ出る情報の重さが違う
研究文書の図表7は、監査における生成AIの利用例を挙げています。入力するものに注目すると、外部送信の論点が重くなる場面と軽い場面が分かれます。
| 利用例 | 文書が想定する入力 | 被監査会社の情報 |
|---|---|---|
| 調書のドラフト作成 | 文書が想定する入力実施した手続と結果の端的な情報 | 被監査会社の情報個別の手続結果を含みうる |
| 調書の査閲 | 文書が想定する入力計画した手続と結果、複数の調書の内容 | 被監査会社の情報調書そのものが入力になる |
| 手続の提案 | 文書が想定する入力被監査会社の業界や財務状況 | 被監査会社の情報財務状況を含みうる |
| 情報収集 | 文書が想定する入力プレスリリース、業界情報、開示情報 | 被監査会社の情報公開情報が中心 |
| 議事録の作成 | 文書が想定する入力経営者との協議や監査チーム内討議の音声 | 被監査会社の情報協議内容が入力になる |
公開情報の収集と、調書や協議内容を読み込ませる使い方では、同じClaudeでも前提にする契約形態が変わります。文書は、生成AIが専門知識なしで使えるからこそ、利用規則を各監査事務所で定めて不適切な利用を防ぐことが重要だと述べています。
学習への利用は、契約形態の確認で答えが変わる
研究文書は、生成AIへの入力情報について2つのリスクを挙げています。作成元企業の学習データに使われるリスクと、入力した機微情報が第三者への回答に利用されてしまうリスクです。前者への低減策は、AI提供会社との契約で、入力を学習データとしない生成AIを使うことと書かれています。
Anthropicの商用製品(Claude for Work、Anthropic API、Claude Gov等)は、入力・出力をモデルの学習に既定で使いません。個人向けのClaude Free・Pro・Maxには別建ての方針ページがあり、商用の既定とは扱いが違います。
学習に使われる例外は2つです。親指ボタンでフィードバックを報告したときと、利用者が別途許諾したときです。ボタンで報告すると、関連する会話全体が最長5年保存され、学習に使われることがあります。TeamとEnterpriseのOwnerは、組織設定の「Rate chats」でこのボタンを無効にできます。
ゼロデータ保持(ZDR)は「保存しない」契約で、例外も残る
第三者への回答への混入は、入力が学習に使われなければ生じにくい経路と考えられます。そのうえで研究文書の図表12は、AIサービス提供側の設定不備による情報漏えいも別行で挙げています。ZDRは、APIレスポンスを返した後にプロンプトや応答を保存しない契約です。保存されないぶん、提供側の保管データから漏れる経路は小さくなります。ただしフラグが付いた入出力は例外で、保持が残ります。
ZDRは組織単位の契約で、Claude Codeでは商用組織のAPIキー利用時と、ZDRを有効化したClaude Enterprise経由の利用時に適用されます。Claude Teams・Enterpriseの製品インターフェース自体は対象外です（契約形態ごとの適用範囲はClaude Zero Data Retentionが有効になる契約形態の切り分け、ZDRとHIPAA対応の違いはClaude APIのZDRとHIPAAのデータ保持ポリシー比較で詳しく扱っています）。
ZDR契約があっても保持が残る場面
フィードバック報告
最長5年
ZDR対象外のclaude.aiで、親指ボタンで報告した会話全体
安全性システムの検知
最長2年
ZDRやHIPAA対応があっても、フラグが付いた入出力
Fable 5.1・Mythos 5.1など
30日
Fable 5・Mythos 5を含め、30日保持が前提でZDRは原則使えない
Claude Enterprise向けのClaude Code ZDRは、標準プランに含まれず、管理画面の設定からも有効にできません。営業窓口か担当チーム経由で依頼し、適格と認められたアカウントに限り、Anthropicが組織ごとに有効化します。新しい組織を作れば、その組織にも別途の有効化が必要です。有効化の操作は監査ログに記録されます。対象は推論の呼び出しで、claude.aiのチャット・CoworkはZDRの外です。プロンプトの保存が要るクラウドセッション(Desktopから始めるものを含む)、Claude Tag、Artifactsは、ZDRの有効化と同時にバックエンド側で無効になります。MCPサーバーなどの外部連携が扱うデータも対象に入らないため、連携先のデータの扱いは別に調べる必要があります。利用状況の分析機能も、プロンプトと応答は保存しませんが、アカウントのメールアドレスや利用統計といったメタデータは集めます。
入力する前の切り分けは、契約・経路・モデルの順に進む
被監査会社のデータをClaudeに入力する前に、次の順で確かめる流れが考えられます。
入力前の切り分け
- 1
契約形態を見る
個人向けのFree・Pro・Maxなのか、Team・Enterprise・APIなどの商用契約なのか。研究文書が前提にする「学習データとしない」契約に当たるのは後者です。
- 2
使う経路がZDRの対象か見る
APIキーは商用組織のものか、Claude CodeならEnterpriseのZDR組織にログインしているか。Claude Consoleのプレイグラウンドは対象外です。APIキー経由のClaude Codeでは、メトリクス記録を有効にすると、利用統計がZDRの例外として保持されることがあります。
- 3
ログインを組織に縛る
個人アカウントや別組織のAPIキーでサインインしたセッションは、ZDRの対象になりません。managed settingsの
forceLoginMethodとforceLoginOrgUUIDで、claude.aiのログインを自組織に限定できます。 - 4
モデルの条件を見る
データ保持の条件を満たさない組織からFable 5をAPIで呼ぶと、400の
invalid_request_errorが返ります。
出力に他社の権利が混入するリスクも別枠で扱う
研究文書は情報セキュリティリスクの一つとして、著作権や知的財産権など他社の権利を侵害する出力がされるケースも挙げています。入力の外部送信とは逆方向のリスクです。図表12には、回答に他社の機密情報が含まれていて、監査人が気づかないまま不適切に使ってしまうケースも並んでいます。他社の権利を侵害する出力がされてしまう場合、調書に組み込むと事務所の成果物にも影響します。
対応策として研究文書が示すのは、信頼性の高い生成AIの活用と、利用会社側に有利な約款の生成AIの活用です(図表12の出力データ行)。出力の中身を利用側で制御するのは難しい、というのが前提です。そのためClaudeの文章を調書に採用する前に、監査人が内容を確かめて推敲する工程を挟むことになります。
技術対策だけでは完結しない
研究文書がリスク低減策として挙げるのは、不適切な利用を禁じるガイドラインやマニュアルの策定、AIリテラシー教育、利用のモニタリング、AI関連法規制の遵守の4点です。図表12には、入力時にNGワードをブロックする制御も入っています。何を入力するかは利用者のリテラシーに左右される、というのが教育を置く理由です。モニタリングは、不適切な情報が入力されていないか、出力の利用がルールに沿っているかを継続的に見て、不備があれば是正する工程です。法規制については、従来は問題なかった利活用が、今後の規制で問題になる場合もあると書かれています。
ZDRを契約していても、未公表の決算情報をプロンプトに入れれば、被監査会社の情報を事務所の外へ出した事実は残ります。Anthropic側で保存されないことと、外部へ渡してよいかは別の問いです。
品質管理基準の観点からも外部送信は説明を求められる
研究文書は、AI監査ツールの活用を、品質管理基準に関する報告書第1号「監査事務所における品質管理」に照らして整備する論点にも取り上げています。その中の「データ管理」は、被監査会社から入手したデータを学習データに使う場合や、被監査会社の情報を監査事務所の外部の法人に使用させる場合を想定し、機密性や個人情報保護の観点でより高度な管理を求めています。外部の生成AIサービスにデータを送る行為は、この「外部の法人に使用させる」場面に近く、同じ観点で説明を求められると読めます。
そのため説明の単位は、監査人個人ではなく事務所になります。被監査会社との監査契約の約款にAIサービス利用の扱いが書かれているか。Anthropicとの契約条件(商用契約かZDRか)を品質管理部門が把握しているか。この2点は、監査チームごとではなく事務所の品質管理部門がまとめて持つ情報です。
まとめ
契約形態・経路・モデルのどこまでが保存なしの対象かを、事務所の品質管理の中で説明できる形にしておくと、研究文書の構成に沿います。契約を確かめたあと、実際にどのデータがいつ送信されたかを追う手段はClaude監査ログの見方にあります。