HigLabo
Latest posts
何が起きた？IBMのAI戦略転換と、90日監査に弱い会社の3つの空白
IBMの論点は「方針整備」から「運用証拠」へ移った
IBMのAI関連の発信でいま注目したいのは、AI governanceからAI assuranceへ論点を広げる見方です。結論から言うと、内部監査部門、リスク管理責任者、CISO、AIガバナンス担当者にとっては、方針の有無だけでなく運用証拠まで見る視点がいっそう重要になります。もう「方針を作った」「会議体を置いた」だけでは足りません。
この記事では、IBM Think 2026以後のAI assuranceの考え方を手がかりに、なぜ「方針整備済み」でも90日監査に耐えにくいのかを整理します。あわせて、内部監査が見落としやすい3つの空白と、実務で埋める方法を初心者にもわかる形で解説します。
AI governanceの全体像は、IBMの解説ページが参考になります。統制の設計だけでなく、説明責任や運用の継続性まで視野に入れる必要があります。
IBMは何を変えたのか――AI governanceとAI assuranceの違いが監査実務に与える影響
まず整理したいのは、AI governanceとAI assuranceは似ているようで重点が違うという点です。AI governanceは、方針、役割、ルール、意思決定の枠組みを整える発想です。一方のAI assuranceは、その枠組みが本当に機能しているかを、証拠で示せる状態まで含みます。比較すると、前者は設計中心、後者は監査可能な運用中心と言えます。
IBMのThink 2026に関する発信では、watsonx.governanceに関連して、継続的な可視化、実効的なコントロール、明確な説明責任を重視するAI assuranceの方向性が示されています。本稿では、ここで重視されているのは、定期レビュー中心の統制ではなく、日常運用の中で確認可能な統制だと読めます。
たとえば社内で生成AIの利用方針を定めたとしても、それだけでは「使い方が適切だったか」「高リスク用途は誰が承認したか」「問題が出た後にどう是正したか」は証明できません。AI assuranceでは、この「後から検証できること」が重視されます。
IBM ResearchのTrustworthy AIの発信でも、信頼できるAIはモデル性能だけでなく、説明可能性、公平性、堅牢性、透明性といった論点まで含めて扱う考え方が示されています。技術の話に見えて、実は監査実務と深くつながる論点です。
https://research.ibm.com/topics/trustworthy-ai
ここで重要なのは、AI assuranceが新しい流行語というより、監査可能性を前面に出した実務言語だという点です。方針を作る段階から、将来の監査で何を見せるかまで設計しておかないと、短期間のレビューで一気に弱さが表面化します。
なぜ「方針整備済み」でも90日監査に弱いのか――監査が見るのは文書より運用の連続性
結論は明快です。90日監査で問われるのは、文書の有無よりも「運用の連続した流れ」だからです。監査人は、規程、承認、利用、例外、見直しまでが一本の線でつながっているかを見ます。
IBMの発信が重視する論点を踏まえると、独立したAIガバナンス監査のような短期間のレビューでは、対応に不安が残る企業もあると考えられます。背景にあるのは、AI活用の拡大に対して、統制の見え方と追跡性が追いついていないことです。
多くの企業では、最初の整備フェーズでAI利用ガイドラインやリスク分類表を作ります。ところが、その後の運用になると、現場の利用申請は別のツール、ベンダー審査はメール、モデル評価は表計算、ログ保管は情報システム部門と分散しがちです。これでは、統制が回っているかを短期間で説明しにくくなります。
NIST AI Risk Management Frameworkは、Govern、Map、Measure、Manageという機能を通じて、AIリスク管理を継続的な実践として整理しています。文書を作って終わりではなく、測定、管理、改善を繰り返す前提です。90日監査に弱い会社は、この継続部分が設計されていないことが多いです。
監査の現場では、1件のユースケースを起点にたどれるかが大きな差になります。たとえば「この生成AI利用は、誰が、いつ、どの基準で承認し、どんな制約を付け、あとで何を見直したのか」を追えれば強いです。逆に、その途中で担当者依存や口頭運用が混じると、一気に脆く見えます。
空白① 責任の空白――AIの判断と統制のオーナーが案件単位で曖昧になる
最初の空白は責任の空白です。AIは部門横断で使われるため、オーナーがぼやけやすいという特徴があります。現場部門は業務効果を重視し、情報システム部門は安全性を見て、法務は規制を気にし、監査は統制の有効性を見ます。全員が関わるのに、最終責任者が不明確になりやすいのです。
この状態で監査が入ると、「モデルの採用判断は誰がしたのか」「高リスク用途の利用停止判断は誰が持つのか」「外部ベンダーの説明責任は誰が受けるのか」に答えづらくなります。方針書に役割一覧があっても、実案件で意思決定した人が追えなければ弱いです。
OECDのAI原則でも、透明性と説明可能性、説明責任は主要原則に含まれています。理念に見えますが、実務では責任分界表や承認権限表に落ちていなければ意味を持ちません。
https://www.oecd.org/en/topics/ai-principles.html
実務上は、AI利用のライフサイクルごとに責任を切るのが有効です。導入判断、データ確認、モデル評価、本番利用、監視、停止判断の各工程に対し、責任者と承認者を分けて定義します。
内部監査は「部門名が書いてあるか」ではなく、「個別案件で名前と日付までたどれるか」を確認する必要があります。
空白② 証跡の空白――統制規程、実行ログ、第三者連携記録が後から連結できない
次の空白は証跡です。AI assuranceで最も痛いのは、実際には何かをやっていても、後から示せないことです。内部監査の観点では、存在しないのと近い扱いになる場面すらあります。
よくあるのは、PoCでは評価したが本番移行時の記録が残っていないケースです。あるいは、生成AIの利用条件を周知したものの、プロンプトの保存方針、出力確認の手順、個人情報入力の制御、外部API利用時の契約確認が別々に管理されているケースです。これでは、統制が「点」でしか存在しません。
ISO/IEC 42001は、AIマネジメントシステムに関する国際規格です。要求事項への対応では、方針だけでなく、規格で求められるdocumented informationとして、リスク評価、管理策、レビュー結果などの記録を整えることが重要になります。証跡整備の方向感をつかむ参考になります。
https://www.iso.org/standard/81230.html
具体例として、採用支援で生成AIを使う場面を考えてみます。監査で問われるのは「利用禁止情報をどう制御したか」だけではありません。評価基準、承認記録、テスト結果、出力レビュー、問題発生時の連絡先まで、連続した証跡が必要です。
内部監査部門は、台帳とログと承認履歴を横につなぐ設計を最優先で見るべきです。特に、AI案件ごとに統制規程、実行ログ、是正履歴、第三者連携記録が連結しているかを点検する視点が欠かせません。
生成AIのリスクと統制の考え方は、OWASPのLLM向け資料も実務ヒントになります。技術部門だけでなく監査部門が読んでも、どこに証跡が必要かを考えやすい内容です。
空白③ 改善の空白――是正履歴が統制の更新に結び付かず単発で終わる
3つ目は改善の空白です。これは見落とされがちですが、90日監査ではかなり重要です。なぜなら、AIは導入時より運用後の変化のほうが大きいからです。
たとえば、生成AIが不適切な回答をした、想定外のデータ入力が発生した、ベンダーのモデル更新で挙動が変わったとします。このとき、現場が都度修正して終わっているだけでは、改善の統制とは言えません。再発防止策が標準手順に反映され、次回レビューに組み込まれて初めて「回っている統制」になります。
EU AI Actは段階的に適用される制度で、特に高リスクAIでは、リスクベースでの管理、継続的な監視、文書化が重視されています。現時点でも、改善を単発で終わらせず、継続的な管理に接続する発想は強まっています。
内部監査がここで見るべきなのは、問題件数そのものではありません。重要なのは、発見から是正、再評価、ルール更新までの流れが閉じているかです。インシデント管理票とAI利用ルールがつながっていない会社は、表面上は整備されていても実はかなり脆いです。
90日監査に耐える会社は何が違うのか――比較で見える3つの空白を埋める実務設計
では、強い会社は何をしているのでしょうか。共通点は、AI統制を「文書セット」ではなく「追跡可能な運用システム」として設計していることです。難しく見えますが、実務は次のように整理できます。
- AIユースケース台帳を作り、用途、責任者、リスク区分、承認日を一元化する
- 評価記録、ベンダー確認、利用ログ、例外申請を案件IDでひも付ける
- 高リスク用途だけでも、四半期ごとの再評価日を先に決めておく
- 問題発生時は、是正処置だけでなく統制文書の更新履歴も残す
- 内部監査は整備率ではなく、1案件を端から端まで追えるかで試査する
この考え方を考えるうえでは、Google CloudのResponsible AIに関するページも参考になります。技術だけでなく運用プロセスに目を向ける点には、AI assuranceと通じるところがあります。
重要なのは、完璧な統制を最初から目指さないことです。まずは高リスクな生成AI利用を数件選び、責任、証跡、改善の3点がつながるかを確認します。そこから全社展開したほうが、90日監査にも現実的に備えられます。
次の行動として有効なのは、AI案件ごとに統制規程、実行ログ、是正履歴、第三者連携記録が連結しているかを点検する監査証跡表を作成することです。これにより、方針整備の有無ではなく、監査実効性の不足箇所を短期間で把握しやすくなります。
最後にひと言でまとめると、IBMの発信が示唆するのは、「AIを管理しているつもり」から「AIを説明できる状態」への移行です。内部監査部門が次に持つべき視点は、方針の完成度ではなく、追跡可能性の完成度です。ここを押さえると、AI governanceの整備が初めてAI assuranceとして機能し始めます。