監査の独立性とClaude利用 — 外部送信をどう考えるか

監査人が被監査会社のデータを生成AIに入力するとき、最初に問われるのは「独立性を損なわないか」です。独立性は公認会計士の職業倫理の中核であり、AI利用の是非を判断する場面でも最初に立ち返る基準になります。この記事では、JICPA研究文書第11号が示す独立性・職業的判断の考え方と、クライアントデータの外部送信という技術的な論点を切り分けて考えます（研究文書が示す監査AIの利用領域全体はJICPA監査AI研究文書が示すClaude活用と限界で扱っています）。

独立性はAIの利用可否をどう判断するか

独立性は、監査人が被監査会社から独立した立場で意見を表明するための要件です。JICPA研究文書第11号は、AIが社会に浸透する時代における独立性の意味を、AI自体に対する保証業務の文脈で論じています。AIのリスクが高まる中で「独立した第三者が信頼性を付与していく必要がある」という立場です。この考え方を監査業務そのものへのAI利用に置き換えると、要点は一つに絞れます。AIの出力をどれだけ活用しても、意見表明の主体は監査人であり続けるということです。

生成AIに監査調書のドラフトを作らせても、それは独立性の要件そのものに触れる話ではありません。独立性が問われるのは、AIの判断に監査人が実質的に依存し、自らの職業的懐疑心を働かせずに結論を採用してしまう場合です。研究文書は生成AIの出力について「あくまでも参考の一つ」であり、監査人自身がチェックし推敲・完成させ、成果物に責任を持つという基本姿勢を明記しています。この姿勢が保たれている限り、AIを使うこと自体が独立性を損なうわけではありません。

AIに代替できない領域が独立性の輪郭を決める

研究文書は、AIモデルが本質的にブラックボックスであり、統計的処理のため100%の信頼性を保証できないという技術的限界を指摘しています。学習データのバイアスや環境変化の影響を受けるため、ある時点で信頼できたAIモデルも、その後の状況変化で信頼性が低下することがあります。この限界がある以上、AIの出力に無条件でお墨付きを与えることは避けるべきだという立場です。

この技術的限界は、そのまま独立性・職業的懐疑心が代替されない理由になります。AIは大量のデータを高速に処理できますが、何が重要な虚偽表示リスクかを判断し、被監査会社の説明を懐疑的に検討する役割は残ります。生成AIに任せてよい範囲を「判断そのものではなく補助」に限定する研究文書の立場は、独立性と職業的懐疑心という監査人固有の役割を、AI利用の拡大後も維持するための線引きです。

クライアントデータの外部送信という別の論点

独立性が「誰が結論を出すか」の問題であるのに対し、外部送信は「データがどこに渡るか」という技術的な論点です。研究文書は、生成AIへの入力情報が「生成AIの作成元企業の学習データに活用されるリスク」と「入力した機微情報が第三者への回答に利用されてしまうリスク」の2つを情報セキュリティ上の課題として挙げています。この2つは、監査人が実務でClaudeを使うときに具体的な契約確認へと落とし込める内容です。

学習データへの活用リスクについて、Anthropicの商用製品（Claude for Work、Anthropic API、Claude Gov等）は既定でユーザーの入力・出力をモデルの学習に使いません。学習に使われるのは、フィードバックボタンで明示的に報告した会話や、利用者が別途許諾した場合に限られます。この既定ルールはAnthropicの商用製品向けの方針であり、個人向けのClaude Free・Pro・Maxには別建ての方針ページが用意されているため、契約形態を混同しないことが最初の確認点です。監査業務で被監査会社の情報を入力する以上、個人アカウントではなく組織契約のもとで利用する必要があります。

第三者への回答への混入リスクについては、ゼロデータ保持（ZDR）契約が対応します。ZDRが有効な組織では、APIレスポンスを返した後にプロンプトや応答をAnthropic側が保存しないため、他の利用者の回答に情報が混入する経路そのものが技術的に断たれます。ZDRは組織単位の契約で、Claude Codeでは商用組織のAPIキー利用時、またはZDRを有効化したClaude Enterprise経由での利用時に適用されます。一方でClaude Teams・Enterpriseの製品インターフェース自体はZDR対象外なので、監査事務所がどの経路でClaudeを使っているかによって、この保護が実際に及ぶかどうかは変わります（契約形態ごとの適用範囲はClaude Zero Data Retentionが有効になる契約形態の切り分け、ZDRとHIPAA対応の違いはClaude APIのZDRとHIPAAのデータ保持ポリシー比較で詳しく扱っています）。

出力に他社の権利が混入するリスクも別枠で扱う

研究文書は情報セキュリティリスクの一つとして「著作権や知的財産権など他社の権利を侵害する出力がされてしまう」ケースも挙げています。これは入力データの外部送信とは逆方向のリスクです。生成AIが学習した大量のテキストの一部を、意図せず既存の著作物と類似した形で出力してしまう可能性があり、監査調書の一部にそのまま組み込むと、権利侵害が監査事務所側の成果物に持ち込まれることになります。

研究文書はこのリスクへの対応策として「信頼性の高い生成AIを活用する」「利用会社側に有利な約款の生成AIを活用する」ことを挙げるにとどめ、生成AIの出力をコントロールすること自体は利用側では難しいとしています。実務上は、Claudeが生成した文章をそのまま監査調書として採用せず、監査人が内容を確認・推敲する工程を挟むことが、独立性の節で触れた「参考の一つとして扱う」という基本姿勢と同じ形でこのリスクにも効きます。入力の外部送信と出力の権利侵害は発生源が逆でも、どちらも「AIの出力を無検証で採用しない」という運用でカバーされる点は共通しています。

技術対策と組織ルールは別レイヤーで確認する

研究文書はリスク低減策として、契約形態の選択に加えて「ガイドラインやマニュアルの策定」「AIリテラシー教育」「利用のモニタリング」の3点を挙げています。これは、ZDRのような技術的対策だけでは情報セキュリティが完結しないという指摘です。ZDRを契約していても、監査人が被監査会社の未公表決算情報をプロンプトにそのまま入力すれば、Anthropic側でデータが保存されないというだけで、送信した事実自体は残ります。

4つの論点はそれぞれ別の主体が担っています。独立性の維持は監査人自身の職業的判断に属し、契約形態の確認はAnthropicとの取り決めで完結し、不適切な入力の防止は監査事務所側のガバナンスに属します。この切り分けをせず「Claudeは安全か」という一問一答で片づけようとすると、どのレイヤーの確認が済んでいて、どこが未確認かが見えなくなります。監査事務所内で導入を検討する際は、この表をそのままチェックリストとして使い、4つの論点それぞれについて確認済みか未確認かを個別に記録しておくと、後から抜けを追跡しやすくなります。

品質管理基準の観点からも外部送信は説明を求められる

研究文書は、AI監査ツールの活用を監査事務所が守るべき品質管理基準に関する報告書第1号「監査事務所における品質管理」に照らして整備すべき論点としても取り上げています。ここで挙げられる「データ管理」の項目は、被監査会社から入手したデータを学習データに使用する場合や、被監査会社の情報を監査事務所の外部の法人に使用させる場合を想定し、機密性や個人情報保護の観点からより高度なデータ管理体制を求めています。Claudeのような外部の生成AIサービスにデータを送信する行為は、この「外部の法人に使用させる」場面そのものです。

つまり外部送信の論点は、監査人個人の判断だけでなく、監査事務所全体の品質管理体制の一部として説明できる状態にしておく必要があります。被監査会社との監査契約の約款にAIサービス利用の可否が触れられているか、Anthropicとの契約条件（商用契約かZDRか）を品質管理部門が把握しているか、という2点は、個々の監査チームではなく事務所単位で整備すべき事項です。研究文書がこれを品質管理基準の文脈に位置づけているのは、外部送信の是非を個々の監査人の裁量に委ねない、という考え方の表れです。

まとめ

監査業務でClaudeを使う際の独立性の論点は、AIの判断に依存せず監査人が最終責任を持ち続けられるかという職業的判断の問題です。一方でクライアントデータの外部送信は、商用契約かどうか、ZDRの対象範囲に入っているかという技術的な契約条件の確認に還元できます。この2つを混同せず、監査事務所内のガバナンス整備とあわせて別々に確認することが、JICPA研究文書第11号が示す枠組みに沿った進め方です。独立性という職業的判断の問題を技術対策で解決しようとしたり、逆に外部送信という契約条件の確認を職業的判断の一言で済ませたりすると、どちらの論点も曖昧なまま残ります。契約形態の確認後、実際にどのデータがいつ送信されたかを追跡する手段はClaude監査ログの見方を参照してください。