社内の業務システムにAIチャットボットや生成AIを組み込んだあと、既存のセキュリティ監査プロセスをそのまま流用している企業は少なくありません。
従来型のITシステム監査は「決まった入力に対して決まった出力が返る」という前提で設計されています。
しかし大規模言語モデル（LLM、テキストを生成する生成AIの中核技術）はこの前提を崩します。
本記事では、既存の監査体制がAI導入企業のどこを見落としがちか、業務システム保守運用の観点から整理します。
A-LIGN社が実施した2026年の企業コンプライアンス調査では、72%の企業が「AI統合が規制対応や監査体制に与える影響」に強い懸念を示しています。
この数字が示すのは、AIの技術的な難しさというより「既存の監査の物差しが通用しない」という運用上の不安です。
業務システムの保守担当者にとって、これは他人事ではない話です。
何が起きるか：監査のすり抜けと影の利用
最初に起きるのは、AIの利用実態が監査対象から漏れる問題です。
典型例が「シャドーAI」と呼ばれる現象で、従業員が会社支給のPCに個人アカウントでチャットボットを入れたり、IDE（統合開発環境）にコーディング支援拡張機能を勝手に追加したりする状態を指します。
これらは情報システム部門の資産管理台帳にもネットワーク監視のホワイトリストにも載っていません。
次に起きるのが、正規導入した生成AI機能そのものの挙動不安です。
同じプロンプト（AIへの指示文）を入れても、LLMは毎回微妙に異なる出力を返す非決定的な性質を持ちます。
加えてプロンプトインジェクション（悪意ある指示文を紛れ込ませてAIの制御を乗っ取る攻撃）のリスクもあり、入力検証の考え方が従来のSQLインジェクション対策とは別物になります。
三つ目は、AIエージェントやMCP（Model Context Protocol、AIが外部ツールやデータベースを呼び出すための標準規格）経由の連携です。
AIが自律的に外部APIを呼んだりローカルスクリプトを実行したりする構成では、「誰が何にアクセスしたか」の記録が従来のアプリケーションログの形式に収まりません。
監査担当者が見るべきログの場所自体が変わってしまうのです。
なぜ起きるか：監査モデルの前提が古い
原因を段階的に分解すると、まず「静的コードベース」を前提にした監査設計があります。
従来のITシステム監査は、決まった処理ロジックとデータベースへの書き込みを追跡する形で組み立てられています。
AI機能はこの前提の外側で動くため、既存のチェックリストに項目を追加するだけでは不十分です。
次の原因は、AI利用が「推論レイヤー」「連携レイヤー」「エンドポイントレイヤー」という3層に分散していることです。
推論レイヤーは業務アプリからAI提供元へのAPI呼び出しそのもの、連携レイヤーはベクトル検索やMCP経由の外部ツール呼び出し、エンドポイントレイヤーは従業員の端末にインストールされたAIアプリを指します。
この3層はそれぞれ管理責任者が異なることが多く、統一的な可視化がされていない状態が起きがちです。
三つ目の原因は、ガバナンスフレームワークが「紙の上のルール」で止まっていることです。
NIST AI RMF（米国国立標準技術研究所によるAIリスク管理の任意ガイドライン）、ISO/IEC 42001（AIマネジメントシステムの認証可能な国際規格）、EU AI Act（欧州連合の拘束力あるAI規制）はいずれも組織の方針や体制を定めるものです。
しかしこれらを実行時の技術的な制御に落とし込まないと、監査書類上は準拠していても実際のトラフィックは素通りしているという状態になります。
自分のプロジェクトが該当するか確認する
自社が該当するかどうかは、次の観点で確認できます。
- 社内PCの資産管理台帳とネットワークプロキシのログを突き合わせ、AI関連ドメイン（chat.openai.com やAPIエンドポイントなど）への通信が台帳外の端末から出ていないか確認する
- IDEの拡張機能一覧（VS Codeなら「拡張機能」ペイン）を主要開発チームでサンプル確認し、コーディング支援AIプラグインの導入状況を洗い出す
- 社内でMCPサーバーを稼働させているチームがあるか、リポジトリの依存関係やDockerfileに
mcp関連パッケージが含まれていないかgrepで検索する - 生成AI機能を持つ社内システムで、APIキーの発行元・利用量・アクセス権限が一覧化された台帳が存在するか確認する
- セキュリティ監査のチェックリストに「プロンプトインジェクション」「モデルの非決定性」という項目が含まれているか確認する
# リポジトリ内でMCP関連の依存が使われていないか確認する例
grep -r "mcp" --include="package.json" .
grep -r "model-context-protocol" --include="*.py" .これらのうち2つ以上が「未確認」「わからない」であれば、既存の監査体制はAI導入の実態に追いついていない可能性が高いといえます。
対策の手順
対策は「見える化」と「制御の一元化」の2段階で進めます。
ステップ1：AIトラフィックをゲートウェイに集約する
まず、AI呼び出しを分散させたままにせず、一箇所を経由させる仕組みを検討します。
Bifrost（Maxim AI社がGo言語で開発したオープンソースのAIゲートウェイ）のようなツールは、モデルへのルーティング、アクセス管理、ガードレール（AIの出力や振る舞いを制限する仕組み）の適用を一元的に扱えます。
この層を挟むことで、どの部署のどのシステムがどのモデルを呼んでいるかをログとして一箇所に集約できます。
既存の業務システムがAI提供元のAPIを直接呼んでいる場合、まずはステージング環境でゲートウェイ経由に切り替え、レイテンシとログ出力形式を確認するところから始めるのが現実的です。
本番切り替えは、既存のAPIキーをゲートウェイのプロキシキーに置き換える形で段階的に行えます。
ステップ2：エンドポイントの棚卸しを定期化する
ゲートウェイで制御できるのは正規導入されたAI機能に限られます。
シャドーAI対策には、資産管理ツール（MDM: モバイルデバイス管理など）でインストール済みアプリケーションを定期棚卸しする運用を組み込む必要があります。
四半期に1回など頻度を決め、IDE拡張機能とブラウザ拡張機能も棚卸し対象に含めることが実務上の抜け漏れを防ぎます。
ステップ3：フレームワークを実行時ポリシーに翻訳する
NIST AI RMFやISO/IEC 42001の要求事項を、ゲートウェイやアクセス制御の具体的な設定値に変換します。
たとえば「機密データを外部モデルに送らない」という方針があれば、ゲートウェイ側でPII（個人識別情報）検出時に該当リクエストをブロックするルールとして実装します。
方針文書と技術設定の対応表を作っておくと、監査時に「この規定はこの設定で担保している」と説明できます。
まとめ：既存監査に3つの視点を足す
AIを組み込んだ業務システムの保守運用では、既存の監査フローに以下3点を追加することが現実的な出発点になります。
- 推論・連携・エンドポイントの3層でAI利用の実態を棚卸しする
- AIトラフィックをゲートウェイなど一箇所に集約し、ログとアクセス制御を一元化する
- ガバナンスフレームワークの条文を、実際の設定値やブロックルールに翻訳して対応表を作る
まずは自社のIDE拡張機能とネットワークログを突き合わせるところから着手できます。
小さな確認作業からで構わないので、AI利用の実態と監査台帳のズレを一つずつ埋めていくことが現実的な対策になります。