第2章 統制設計と運用の有効性

学習目標

• 統制の設計の有効性と運用の有効性を区別し、評価手続を選定します。
• 発見した問題が設計上の不備と運用上の不備のどちらに該当するかを判定します。
• 人によるレビュー統制が実質的なものか、単なる形式的な承認にとどまるかを見分けるテストを選定します。
• AIシステムにおいてアクセス管理と変更管理の対象をモデル、判定基準、指示文、知識文書まで広げて点検します。
• ベンダー契約やサービス組織報告書を読み、企業側で別途確認すべき事項を見つけ出します。

はじめに

ある保険会社の補償チーム長が監査チームに自信ありげに語ります。「AIが算定した金額はすべて担当者が確認して確定しています。人が最終決定を下すため問題ありません。」手順書にもそのように記載されており、確定ボタンは担当者しか押せません。監査チームがシステムの記録を確認したところ、前四半期に担当者がAIによる金額を修正した案件は1,000件中わずか3件であり、1件あたりの処理時間は平均20秒でした。

この統制は有効でしょうか。答えは「まだわからない」です。手順書と確定ボタンは、統制がそのように設計されている証拠にすぎず、期間中に実際に機能した証拠ではありません。そして、低い修正比率もそれ自体では何も証明できません。AIがほとんど誤っていなければ修正する必要がなかったはずですし、AIが頻繁に誤っていたのであれば担当者がエラーを見過ごしていたことになります。両者を見分けるにはさらなる証拠が必要です。統制を評価することは、このように「統制が存在する」と「統制が機能している」を分けて問うことから始まります。

本章では、統制評価の2つの軸である設計と運用をまず区別し、問題がどこで発生したかを判定する方法を学びます。続いて、AI監査で最も頻繁に論点となる人によるレビュー統制と形式的承認を掘り下げて扱い、アクセス管理、変更管理、ベンダー管理統制をAIシステムの特性に合わせて点検する方法を整理します。

重要な概念

統制の種類

統制とは、リスクが結果へとつながらないようにするための仕組みです。PCAOB AS 2201は、統制をエラーや不正が生じないように防ぐ予防統制と、生じたエラーを適時に発見する発見統制に分類し、有効な内部統制では往々にしてこの2つが組み合わせて用いられると説明しています（AS 2201 .A8）。実施主体としては、人が行う手作業統制とシステムが行う自動統制があります。

この区分によってテスト手法が決まります。人が繰り返し実施する統制は期間全体からサンプルを抽出して確認する必要があり、完全に自動化された統制は設定およびその変更管理を確認する方法によって効率的に検証できます。

設計の有効性と運用の有効性

設計の有効性は、統制が権限と能力を備えた人物によって所定のとおりに実施された場合、統制目標を達成し、エラーや不正を防ぐか発見できるかを評価します（AS 2201 .42）。運用の有効性は、その統制が実際に設計どおりに運用されているか、そして実施者が必要な権限と能力を備えているかを評価します（AS 2201 .44）。

たとえるなら、設計の評価は消火器が適切な場所に適切な種類で置かれているかを確認することであり、運用の評価は過去1年間にわたり点検表どおりに圧力を確認して交換したかを確認することです。消火器が見当違いの場所にあれば、点検記録がどれほど誠実であっても火災を防ぐことはできません。そのため、設計の評価が先に行われます。IIA基準でも、統制が適切に設計されていなければ、その有効性をすべて評価するのに要するコストに見合う便益を得ることは難しいと説明されています（IIA 4.2）。

設計上の不備と運用上の不備

AS 2201はこの2つの不備を次のように定義しています（AS 2201 .A3）。

• 設計上の不備：統制目標を達成するために必要な統制が存在しないか、既存の統制が設計どおりに運用されたとしても目標を達成できないように設計されている場合。
• 運用上の不備：適切に設計された統制が設計どおりに運用されていないか、統制を実施する人物が効果的に遂行するために必要な権限や能力を備えていない場合。

AIシステムにおいて、この区分は思いのほか混同されがちです。次の例を見てみましょう。

判定が重要である理由は、是正勧告が異なるためです。設計上の不備に対しては方針やシステムを改修する必要があり、運用上の不備に対しては実施状況を是正するか実施者を変更する必要があります。

テスト技法と証拠の強さ

統制をテストする技法には4つあります。担当者に尋ねる質問、実施プロセスを見守る観察、実施記録を確認する文書検査、監査人が統制を独自にやり直してみる再実施です。AS 2201はこの4つを通常得られる証拠が弱い順から強い順に挙げ、質問だけでは統制が有効であるという結論を裏付けることはできないと明記しています（AS 2201 .50）。実際の証拠の強さは、統制の性質と実施した手続の組み合わせによって異なります（.49、.51）。

設計の評価には、質問、観察、文書検査を組み合わせたウォークスルーで通常は十分です（AS 2201 .43）。ウォークスルーはリスクや実施した手続に応じて運用の有効性の十分な証拠となることもありますが（.49）、リスクが大きい場合や期間中の実施状況を広く確認する必要がある場合は、サンプルテストが必要となります。ウォークスルーとは、1つの取引を開始から終了まで追跡しながら担当者に質問し、実際の画面と記録を併せて確認する手法です。運用の評価では、期間全体からサンプルを抽出して文書検査や再実施を行います。より長い期間をテストするほど、統制の有効性に関する証拠も強くなります（AS 2201 .52）。

逸脱に直面したとき

サンプルにおいて統制が実施されなかった案件、すなわち逸脱が出たからといって、直ちに統制が有効でないと結論を下すわけではありません。AS 2201は、有効な統制であっても絶対的な確信を与えることはできないため、個々の統制が逸脱なしに運用されて初めて有効であるとは限らないと説明しています（AS 2201 .48）。監査人は逸脱の頻度を許容逸脱率と比較し（第3章）、逸脱の原因や性質も評価します。ミスから生じた逸脱と意図的な迂回とでは重大性が異なります。

逆に、実際の被害がなかったからといって不備を軽視してはいけません。AS 2201は、不備の重大性はエラーが実際に生じたかどうかではなく、統制がエラーを防止または発見できない合理的な可能性とその大きさに左右されると説明しています（AS 2201 .63–.64）。退職者のアカウントが2週間にわたって無効化されていなかったもののログイン記録がなかったという事実は、影響度の評価には用いられますが、逸脱そのものを帳消しにすることはできません。

人によるレビュー統制が備えるべきもの

AIシステムにおいて最も一般的な統制は、「人が確認した上で確定する」というものです。AI基本法（韓国）は高影響人工知能を提供する事業者の責務として人の管理・監督を挙げており（第34条第1項第4号）、NIST AI RMFは人の監督手続を定義・評価して文書化すること（MAP 3.5）、意図と異なる結果を出すAIシステムを代替または停止させる仕組みと責任を設けることを求めています（MANAGE 2.4）。GAOフレームワークも説明責任のために人の監督手続を定めるよう規定しています（実務 3.9）。

人によるレビューが実質的なものとなるためには、4つの要素が備わっていなければなりません。

1. 権限：レビュー担当者がAIの結果を覆すことができなければなりません。意見を残すだけでAIの結果が自動的に優先適用されるのであれば、監督は形式的なものにすぎません。
2. 情報：判断に必要な元データと、AIがそのように判断した根拠を確認できなければなりません。
3. 時間：1件あたりの処理目標やキューのプレッシャーによって、実質的な判断が不可能になっていてはなりません。
4. 能力：レビュー担当者がその判断を下すための知識と教育訓練を備えていなければなりません。

レビュー手順が当初から覆す権限、元データ、時間を与えないように作られていたとすれば、設計上の不備です。手順は適切に作られているものの、実際にレビューを担当した人物に必要な権限や能力がなかったのであれば、AS 2201の定義どおり運用上の不備となります。

形式的承認と自動化バイアス

形式的承認（いわゆる「ゴム印」）とは、手順上はレビューが存在するものの、実際にはAIの結果をそのまま素通りさせている状態を指します。その根底には自動化バイアスが存在します。NIST AI 600-1は、生成AIの信頼性が高まるほど、人がシステムに過度に依存したり、その結果を他の情報源よりも高く評価したりする傾向があり、こうした自動化されたシステムへの過度な依存が、もっともらしい誤答（confabulation）や偏向（バイアス）といった他のリスクを増大させかねないと説明しています。

形式的承認の兆候には、通常以下のようなものがあります。

• 修正・覆滅の比率が、AIの既知のエラー率よりもはるかに低い。
• 1件あたりの処理時間が、元データを読むには短すぎる。
• 一括承認機能が存在し、実際に使われている。
• 結果を覆す際には理由を残すことが求められるのに対し、そのまま従う際には何の記録も残らない。

これらの兆候は「疑い」であって「結論」ではありません。経験の長いレビュー担当者も例外ではないため、熟練度を理由にテスト対象から除外してはなりません。

形式的レビューを見抜くテストの選択

どのテストが適切であるかは、どのような証拠が残されており、何が許容され、監査チームが何を判断できるかによって決まります。

テストケースの投入は強力ですが、本番システムに影響を与える可能性があるため、社内規程の確認と経営陣の合意が先決です。再実施は監査チームが同様の判断を下せる場合にのみ意味があり、そうでない場合は資格ある専門家を関与させます。面談（質問）だけで終わらせるテストは、どのような状況であっても十分ではありません。

アクセス統制

AIシステムのアクセス統制は、「誰が結果を変更できるか」を扱います。モデルファイルやデプロイ設定だけでなく、生成AIの指示文（プロンプト）、判定基準スコア、検索に用いられる知識文書、外部ツール連携設定のすべてが結果を変えます。監査人は以下の点を確認します。

1. 変更権限が真に必要な人物にのみ付与されているか（最小権限）。
2. 権限リストを定期的にレビューしているか。レビューは、権限リストを人事記録の在職者名簿と照合するなど、独立した資料と突き合わせて確認します。
3. 退職・異動時に方針が定めた期限内に権限を回収しているか。
4. 変更履歴が記録され、誰かがその履歴をレビューしているか。

変更履歴は事後的に発見する発見統制です。履歴が残るという事実が、最小権限のような予防統制の代わりになるわけではありません。

変更管理統制

従来のIT監査における変更管理は、プログラムコードの変更を確認します。AIシステムでは変更の単位が広範です。モデルの再学習や交換、判定基準スコアの調整、指示文の修正、知識文書の更新、外部ベンダーの基盤モデルの交換がすべて結果を変えます。変更管理方針がこのうち一部のみを承認対象と定めている場合、残りは統制の枠外に残されることになり、設計上の不備となります。

変更管理統制をテストする手順は、通常次のようになります。方針において承認対象となる変更と承認権者を確認し、本番システムから実際のデプロイ履歴を監査人が直接抽出して承認記録と1件ずつ照合し、一致しない案件の原因を調査します。申請者と承認者が同一人物であるか、承認された内容とデプロイされた内容が一致しているかも併せて確認します。

自動統制とベースライン戦略

「根拠を入力しなければ確定ボタンが有効化されない」といった完全な自動統制は、一般的に人為的ミスによって破綻するリスクにさらされません（AS 2201 .B28）。AS 2201は、プログラムの変更、アクセス、運用に関する全般統制が有効かつ継続的にテストされており、自動統制がベースラインを設定した（前回テストした）時点以降に変更されていないことを確認できれば、自動統制は継続して有効であると結論付けることができると説明しています（.B29）。これをベースライン（ベンチマーク）戦略と呼びます。

ただし、自動統制の機能は関連するファイル、テーブル、データ、パラメータに依存することがあり（AS 2201 .B30）、時間が経過すればベースラインを再設定しなければなりません（.B33）。AIシステムであれば、判定基準スコアや参照単価表がそのようなパラメータに該当します。「ボタンの設定はそのままだが参照テーブルが変更された」という場合、統制は変更されたことになります。

ベンダー管理統制

多くのAIシステムは、外部ベンダーのモデルやサービスの上で稼働しています。外部に委託しても、リスクは企業側に残ります。NIST AI RMFは、第三者に関連するAIリスクを取り扱う方針と手順を策定し（GOVERN 6.1）、高リスクと判断された第三者データやAIシステムの障害に備えた緊急手順を準備し（GOVERN 6.2）、第三者リソースのリスクを定期的にモニタリングすること（MANAGE 3.1）、開発に用いられた事前学習モデルを定期的なモニタリングに含めること（MANAGE 3.2）を求めています。個人情報の処理を委託した場合は、個人情報保護法（韓国）第26条の委託文書および受託者の監督も併せて確認します。

AIベンダーとの契約において、監査人が特に着目する条項は以下のとおりです。

セキュリティ認証、障害補償、秘密保持条項も重要ですが、予告のないモデル交換や性能低下といったAI固有のリスクを直接扱えないという点を区別しなければなりません。

サービス組織報告書の読解

ベンダーは多くの場合、独立監査人が作成したサービス組織報告書を提示します。PCAOB AS 2601は財務諸表監査においてこうした報告書を扱う基準ですが、報告書を読み解く原則は、AI事業者が提示する他の保証報告書にもそのまま応用できます。AS 2601が整理している留意すべき点は以下のとおりです。

1. 報告書の種類。 特定の基準日現在で統制が設計され適用されているかのみを扱った報告書は、監査計画には役立ちますが運用の有効性の証拠にはなりません（AS 2601 .12、.37）。期間を通じた運用の有効性をテストした報告書であって初めてその証拠となります。
2. 範囲。 報告書は記載された統制目標に対してのみ意見を表明しており、テストしていない統制目標については意見を述べていません（.44）。アクセス管理と可用性のみを扱った報告書は、モデル学習への利用の有無について何も語っていません。
3. 期間。 テスト期間が短い場合や、テスト終了後に時間が長く経過しているほど、報告書が与える確信は薄れます（.16）。
4. 利用会社側の補完的統制（complementary user organization controls）。 サービス組織の統制が利用者側の統制を前提として設計されている場合、報告書はその統制を明らかにします（.31、.46）。企業がその統制を運用していなければ、報告書の結論は前提を失うことになります。

さらに深く

意味のある人によるレビューのコスト

「すべての案件を人が綿密に確認する」という設計は、耳で聞く分には安全に思えますが、実際には形式的な承認を生みやすくなります。1日に数百件を処理しなければならないレビュー担当者に1件あたり数秒しか許されないとすれば、手順書が何を求めていようとも、レビューはAIの結果に従う方向へと流れてしまいます。監査人がこのような状況で「レビューを強化せよ」とだけ勧告しても、同じ問題が繰り返されます。

より優れた設計は、レビューをリスクに応じて分けることです。金額が大きい案件や顧客に不利な決定、AIの確信度が低い案件は人が深く精査し、それ以外の案件はサンプリング再レビューのような発見統制で代用する、といった形です。このとき監査人が確認すべき点は3つあります。分ける基準がリスクに即しているか、深く精査する案件に十分な時間と情報が与えられているか、サンプリング再レビューの結果が実際に基準やモデルの改善につながっているか、です。人によるレビューを減らす決定自体は経営陣のリスク判断であり、監査人はその決定がリスク許容水準の範囲内にあるか、そしてその決定を誰が承認したのかを確認します。

エージェントのツール権限と人による承認

AIエージェントは、メールを送信し、発注を行い、記録を修正するツールを直接呼び出します。アクセス統制の対象が、人間のアカウントからエージェントの権限へと広がるわけです。OWASPは、プロンプトインジェクション（ユーザー入力や外部文書に潜む指示がモデルの挙動を意図と異なるものに変えてしまう攻撃）への対策として、モデルのアクセス権限を意図されたタスクに必要な最小限に制限し、大きな権限を伴うタスクには人による承認を設け、モデルを信頼できないユーザーのように扱うペネトレーションテストを定期的に実施することを推奨しています。指示文に「個人情報を漏洩させないこと」と記載するのはその対策の1つにすぎず、それだけで安全であると見なすことはできません。

監査人の問いは、人間のアカウントと同じ枠組みへと変わります。エージェントが保有するツール権限のリストが存在するか、その権限は業務に必要な最小限であるか、取り消しが困難なタスク（送金、削除、外部送信）に人による承認が組み込まれているか、エージェントの行動記録はエージェント自身が改ざんできない場所に残されているか、です。最後の問いは、第3章のログの完全性へとつながります。

実務の場面

ひとすじ保険：修正割合0.6%の意味

損害保険会社「ひとすじ保険」では、AIが旅行傷害保険の請求を「支払」と「審査」に振り分けると、担当者9名が「支払」案件を確認して確定します。監査チームが受領した運用データにおいて、担当者がAIの判断を「審査」に戻した割合は0.6%、1件あたりの確認時間の中央値は11秒でした。補償部門長は「AIが正確であるため、修正することが少ないのだ」と説明しました。

監査チームはまず、この説明が正しいかを確認するための基準を探しました。リリース前の検証報告書には、「支払」判定の約4%が約款上は支払対象外であったという結果がありました。AIが4%誤っているにもかかわらず、人間が0.6%しか修正していないとすれば、その乖離は大きくなります。ただし、リリース後にモデルが改善された可能性もあったため、この差異を結論とするのではなく、テストの出発点としました。

テスト手法を巡り、3つの案が出されました。担当者へのインタビューは質問だけでは結論を出せないため、補助的な手続に回しました。テスト用のエラー案件を待機列に混入させる案は、本番運用システムに処理されるべきでない請求を投入することになるため、社内規程上、情報保護委員会の承認が必要であり、監査期間内に承認を得ることは困難でした。残ったのは再実施でした。請求書類の原本がすべて保管されており、旅行傷害保険の約款に基づく判断は、その商品の審査に関与したことのない監査チームの保険業務経験者が行うことができました。

監査チームは前四半期に確定した「支払」案件2万1,000件からランダムに60件を抽出し、約款に従って再判断を行いました。そのうち2件が支払対象外であったにもかかわらず、担当者の確認を通過していました。監査チームは確認画面も併せて確認しました。画面上にはAIの判断と金額だけが大きく表示され、添付書類は別タブをクリックしなければ開かず、画面には「一括確認」ボタンが存在していました。監査チームは結果を2つに整理しました。2件は運用上の逸脱として評価し（許容逸脱率と比較した評価は第3章の方式に沿って行いました）、書類を開かなくても確定できる画面構成や一括確認ボタンは、レビュー担当者に必要な情報を提供できていない設計上の原因として記録しました。報告書には、この設計上の問題を指摘事項の原因として、見落とされた2件をその影響を示す証拠として記載しました。

柳食品：委託先報告書1冊で十分か

食品メーカー「柳食品」は、外部ベンダーの生成AIサービスを利用して取引先の契約書を要約し、リスク条項を明示しています。監査チームがベンダーの統制に関する証拠を求めたところ、購買チームはベンダーが提供したサービス・オーガニゼーション報告書を提示し、「適正意見が出ているので特に確認することはない」と答えました。

監査チームは報告書を3つに分けて読み解きました。第1に、種類です。その報告書は、12か月間にわたる統制の運用の有効性をテストした報告書でした。第2に、範囲です。統制目標はアクセス管理、変更管理、バックアップとリカバリでした。監査チームの関心事の1つであった「契約書の原文がベンダーのモデル学習に使用されているか」は、どの統制目標にも含まれていませんでした。第3に、ユーザー側の補完統制です。報告書は「顧客企業は退職者のアカウントを管理コンソール上で速やかに無効化する」という前提を置いていました。

監査チームは、報告書で確認された事項と確認されなかった事項を表にまとめました。変更管理とアクセス管理については報告書を証拠として利用しつつ、補完統制を確認するために柳食品のコンソールユーザーリスト34名を人事記録と照合しました。退職者2名のアカウントが有効なまま残っており、1名は退職から6週間が経過した状態でした。学習への利用の有無は報告書の対象外であったため、契約書やデータ処理条件、管理者の設定画面を別途確認しました。契約書には学習利用の禁止条項がありましたが、管理者設定の「サービス改善のためのデータ共有」がオンになっていました。

購買チームは「適正意見」という言葉に依拠していましたが、その意見が何に対するものであるかを読み解くと、自社が直接実施すべき2つの事項が明らかになりました。監査チームは、退職者アカウントの回収漏れを運用の不備として、データ共有設定を契約条件と一致しない設定として、それぞれ指摘事項に挙げました。2点目の原因としては、契約で定めたデータ条件を管理者設定に反映し確認する手順が存在しなかった点を記載しました。

間違えやすいポイント

1. 「手順書があるのだから、統制は有効である。」 手順書は設計の証拠にすぎません。期間中の動作は運用のテストで確認します。
2. 「人間が最終決定を下しているのだから、監督は十分である。」 人間に結果を覆す権限、情報、時間、能力があって初めて、実質的な監督となります。
3. 「修正割合が低いのだから、AIは正確である。」 修正割合は、人間がAIに従った程度にすぎません。AIの実際のエラー率と比較して初めて意味を持ちます。
4. 「レビュー時間が長ければ、実質的なレビューである。」 画面を開いていた時間は判断の質を示すものではありません。再実施のような直接的な証拠が必要です。
5. 「複数人にヒアリングを行えば、運用の有効性を確認できる。」 質問だけでは結論を出すことができず、同じ種類の証拠を増やしても質は補えません。
6. 「逸脱が1件でも発生すれば、統制は失敗である。」 逸脱の頻度と原因を許容基準と併せて評価し、判断します。
7. 「修正履歴が残るのだから、権限が広範であっても問題ない。」 履歴は発見統制です。最小権限のような予防統制の代わりにはなりません。
8. 「ベンダーの報告書が適正であれば、ベンダー関連のリスクは解消される。」 報告書の種類、範囲、対象期間、ユーザー側の補完統制を精読して初めて、何が確認されたのかが分かります。

ひと目でわかるまとめ

公式ドキュメントで確認する

• PCAOB — AS 2201：設計・運用の有効性（.42–.52）、不備の定義（.A3）、深刻度（.62–.64）、自動統制のベースライン（.B28–.B33）。
• PCAOB — AS 2601：サービス・オーガニゼーション報告書の種類、範囲、対象期間、ユーザー側の補完統制。
• NIST AI RMF — Core：MAP 3.5（人間の監督）、MANAGE 2.4（フォールバック・停止機能）、GOVERN 6.1・6.2、MANAGE 3.1・3.2（第三者）。
• NIST AI 600-1：Human-AI Configurationと自動化バイアスの説明。
• GAO-21-519SP：実務3.9（人間の監督）と監査手続の例。
• OWASP GenAI — LLM01 Prompt Injection：最小権限、人間による承認、ペネトレーションテストなどの対策。
• The IIA — Global Internal Audit Standards：基準4.2のコスト・ベネフィットの考慮。

セルフチェック

2-1. 消火器の例えを使わずに、設計の有効性と運用の有効性の違いを、AI判定基準の変更承認を例に挙げて2文で説明してください。

2-2. レビュー担当者が教育を受けていない新入社員に変更された状況は、設計の不備と運用の不備のどちらに該当しますか。AS 2201の定義を根拠に答えてください。

2-3. 統制テストの4つの技法を証拠能力が弱いものから順に並べ、質問だけで終わらせたテストがなぜ結論の根拠にならないのかを記述してください。

2-4. 人によるレビューが実質的なものとなるために備えるべき4つの要素を挙げ、そのうちの1つが欠けた際に現れる形式的な承認の兆候を1つずつ結び付けてください。

2-5. AIシステムにおいて変更管理の対象とすべき5つの変更を挙げ、そのうち従来のIT変更管理で見落としやすいものを2つ選んでください。

2-6. サービス組織報告書を受領した際に確認すべき4つの項目を書き、そのうちAI固有のリスクと最も頻繁に衝突する項目を理由とともに選んでください。

2-7. （設計）顧客にメールを送信し、返金を執行できるAIエージェントについて、監査人が点検すべきアクセス統制の質問を4つ作成してください。

実習課題