社内AIを本番環境に置くと、監視すべき事象が一気に増えます。モデルが誤った回答を社内規程として配布した、閲覧権限のない文書が回答の根拠に混ざった、外向きの生成AIサービスへプロンプトが送信された——いずれも、従来のIT障害処理では扱ってこなかった種類の出来事です。AIは落ちない代わりに誤るため、サーバーの稼働状況には頼らず、回答と操作の履歴を監視対象にする必要があります。本稿では、インシデント管理システムを初めて導入する現場責任者向けに、検知から恒久対策までの工程、体制とサービスレベル契約（SLA）の設計、監査に提出できる証跡の残し方を整理します。
AI導入でインシデント管理の適用範囲は3つ広がる
従来のインシデント管理は、サービスの停止と不正アクセスを中心に扱ってきました。社内AIの運用を考えると、ここに3つの類型が加わります。
ひとつは回答品質に関する事象です。社内文書から生成した回答が誤っており、それが社内Wikiや業務メールに転記された。この種の事象はサーバーが正常なため、稼働状況を見る通常の監視では検知できません。
ふたつめはデータ境界に関する事象です。閲覧権限のない文書が検索の候補に混ざり、回答の根拠として引用された。権限の制御がチャンク単位まで 及んでいなければ、一つのチャンクの混在が文書全体への露出につながります。
みっつめは利用形態に関する事象です。承認されていない生成AIサービスへ社内の機密情報を入力した、あるいは従業員が私用の生成AIを業務文書に用いた。この種の事象は検知より予防に重きを置く領域で、利用状況の可視化が必要になります。
この3類型に共通するのは、サーバーが止まらないことです。監視項目を「障害」から「回答・根拠・操作履歴」へ広げる必要があります。
検知・初動・恒久対策の3段階で、工程を運用に落とす
インシデント管理の骨格は検知、初動、恒久対策の3段階です。AI導入後も構造は同じですが、各段階の完了条件が具体化します。検知では「条件が吻合したこと」を記録し、初動では「影響範囲と封じ込め」を記録し、恒久対策では「再発防止策と承認」を記録します。3つを「対応完了」という言葉でまとめてしまうと、監査で追及されたときに何をしたか説明できません。
| 段階 | 時間の目安 | 担当 | 主な作業 | 残す記録 |
|---|---|---|---|---|
| 検知 | 常時 | 監視・ログ | 条件に一致した操作や回答の抽出 | 検知ログ |
| 初動 | 検知後30分以内 | 当番の運用担当者 | 影響範囲の切り分け、封じ込め | 対応記録 |
| 恒久対策 | 3営業日以内 | 技術責任者 | 再発防止策の決定と実装 | 変更履歴 |
初動で最初に行うのは封じ込めです。外部との通信を遮断する、該当利用者の権限を停止する、誤った回答の配信を止める。用意できる選択肢は概ね3つで、実運用ではどれを先に実行するかを決めておく必要があります。社外へ出る経路を切った状態を前提にできるかどうかは、オンプレミスのセキュリティ対策5選の考え方と組み合わせると整理しやすいです。
SLAは優先度ごとに4段階で設計する
サービスレベル契約（SLA）は、対応の速さを測る道具として使えます。AI事象では被害の性質で優先度を分けるのが実用的です。回答の誤りであることを理由に、すべて同じ初動時間にしてしまうと現場が疲弊し、逆に緩めると重大事象が放置されます。
| 優先度 | 判定基準 | 一次応答の目標 | 復旧の目標 | 報知先 |
|---|---|---|---|---|
| P1 | 社外への情報流出、または事業停止 | 15分 | 4時間 | 経営責任者、情報システム責任者 |
| P2 | 特定の利用者への誤回答の配布 | 1時間 | 1営業日 | 該当部門責任者 |
| P3 | 回答品質低下、利用統計の異常 | 4時間 | 5営業日 | 運用担当者 |
| P4 | 改善提案、暫定運用の記録 | 1営業日 | 次期計画に統合 | なし |
設計時に手順を一つ決めておく必要があります。検知の時刻がログに記録されていなければ、SLAの判定基準そのものが立ちません。時刻の残っていないインシデントは、監査で「初動は早かった」と説明できません。検知の定義は「条件が吻合した時刻」で固定し、ログの記録項目に含めてください。
体制は初動担当と技術責任者を分ける
インシデント管理の失敗要因として多いのは、1人が初動から恒久対策までを一気に対応することです。初動しながら原因を判断すると、判断の根拠が後から書き換えられ、証跡として意味を持たなくなります。役割を分けると、記録がそのまま証跡として機能します。
| 役割 | 担当 | 決めること | 判断の期限 |
|---|---|---|---|
| 検知・記録 | 監視担当 | 通知条件の閾値調整 | 週次 |
| 初動 | 当番の運用担当者 | 封じ込めと一時的な回避 | 検知後30分 |
| 技術判断 | 技術責任者 | 恒久対策の承認 | 3営業日 |
| 経営報告 | 情報システム責任者 | 外部への情報開示の判断 | 24時間 |
P1とP2の境界が事後になって曖昧にならないよう、判定基準を事前に定めておく必要があります。技術責任者が常駐していない夜間や休日でも、P1の初動だけは誰でも実行できる状態にしておく必要があります。手順書を1枚にまとめ、必要な権限を付与済みで用意しておけば、夜間も初動が滞りません。オンプレミスの運用・保守ガイドでは、閉域構成で運用体制を組み立てる方法を扱っています。
証跡は「誰が・いつ・何を・なぜ」の4要素で残す
監査対応で求められる証跡は、各種センサーで集めたログの束ではありません。事象の前後関係が読める記録です。最低限、次の4要素が揃っている必要があります。
| 要素 | 記録する内容 | 保存する場所 | 保持の目安 |
|---|---|---|---|
| 誰が | 操作者のID、認証方式 | 操作ログ | 1年 |
| いつ | 検知・初動・復旧の各時刻 | 操作ログ | 1年 |
| 何を | 対象（文書・Bot・権限）と変更内容 | 操作ログとデータベース | 3年 |
| なぜ | 判断の根拠と承認者 | 承認記録 | 3年 |
保持期間が設計の分岐点になります。個人の機密情報を含む質問履歴は1年で消したい。一方、権限変更や設定変更の履歴は再発防止の判断根拠として3年残したい。この2つを同じログに混ぜると、どちらの保持期間にも合いません。ログの種類ごとに保持期間と閲覧権限を分ける設計が実用的です。文書管理システムのオンプレミス導入ガイドに、改変の履歴を管理する構成の考え方をまとめています。
閉域構成は検知の入力そのものを守る
セキュリティ監視にSIEM（セキュリティ情報を一元管理する仕組み）を組み込む場合、ログが社外へ送られます。AIシステムのログには、利用者の質問そのもの、個人情報、参照された文書本文が含まれるため、外部へ出た時点で機密が流出します。検知の入力を社内で閉じることは、インシデント管理の前提条件です。
閉域構成で守れる境界は4つあります。検知ログを社内のデータベースに留めること。ログ出力時に氏名や番号をマスキングすること。保持期間を種類別に管理すること。追記専用の領域に書き、操作者による改ざんができない状態にすることです。ここまで整えると、検知のための仕組みが新たな漏洩経路になりません。
GBase OnPremでインシデント管理の基盤を組む
GBase OnPremは、外部へのデータ送出なしで運用できる構成を標準で備えています。運用設計に直結する主な仕組みは次の5つです。
- ローカルJWT認証とメールMFA：認証トークンの発行と検証が社内ネットワーク内で完結し、外部の認証基盤に認証コードが渡りません
- 操作ログ（監査証跡）：ミドルウェアが全操作を自動記録し、Bot・ナレッジ・認証など8カテゴリで分類します。変更前後の差分と認証イベントも保存され、CSVで提出資料に変換できます
- Sub-Agent：業務カテゴリーごとに実行できるツールを分離できます。部門単位で参照できる範囲を分けられるため、P1事象の封じ込みで対象を絞る作業が速くなります
- MCP連携：基幹システムや社内ツールは社内ネットワークにデプロイされたMCPサーバー経由で参照され、外部インターネットへの露出がありません
- ナレッジベース管理：回答の根拠となる文書を部門と機密区分ごとに管理し、参照範囲を閉域構成のまま制御できます
社内に閉じた構成で運用すると、検知の閾値を見直す余地が残ります。ログが社外へ出ていないため、回答と参照先の相関を詳細に記録し、誤答が集中する利用者と文書を特定する、という運用を回せます。社内AIのオンプレミス導入ガイドは、この閉域構成を組み立てる手順を扱っています。
GBase OnPremなら、検知から証跡まで閉域で運用できます
よくある質問
Q1: インシデント管理システムはいつ導入すべきですか？
「社内でAIを実際に使い始めた時点」が導入の目安です。試行の段階では被害が出ておらずログも残らないため、体制の検討だけ先に進めても構いません。ただし、運用開始と同時に検知項目と証跡の記録を確定しておくと、後から仕組みを作り直す手間を避けられます。
Q2: 小さな組織でもSLAの設定は必要ですか？
数字の厳しさは緩めにして構いません。ただし、検知・初動・恒久対策の3段階を役割で分けておくこと、そして「誰が初動するか」を名指しで決めておくことは、小規模でも必須です。夜間に事象が起きたときに誰も動かない状態を防ぐ、最小限の装置として働きます。
Q3: 回答の誤りはインシデントとして扱ってよいですか？
扱います。ただし、優先度の判定基準は「誤りが業務へ波及したか」に置きます。利用者1名への誤回答で支障がなければP2、社外の回答が誤った規程として配布されたならP1です。回答の正確性を上げることは別の課題で、インシデント管理ではその波及をどう止めるかを決めます。
Q4: ログの保持期間に法令上の決まりはありますか？
金融や医療のように業界ごとの指針がある分野では定められています。一般企業では、社内規程と監査の要求から期間を決めます。目安は操作ログ1年、権限や設定の変更履歴3年です。項目が増えることを恐れるより、監査で提示する資料の範囲から逆算して決めるほうが確実です。
Q5: 既存の監視ツールと併用できますか？
並行して運用して構いません。ただし、ログを外部の監視基盤へ送る構成では、質問本文が社外へ出ます。併用する場合は送信項目を絞り、識別子と種別だけを送る設定にしてください。運用状況の可視化だけが必要なら、閉域のダッシュボードで完結させられます。
まとめ
AI導入後のインシデント管理で変わるのは、監視対象の性質です。監視対象は障害から誤答と権限の逸脱へ広がります。検知・初動・恒久対策の3段階を役割ごとに固定し、SLAの判定に必要な時刻ログを社内に残します。その前提となるのは、ログも回答も社外へ出さない構成です。生成AI オンプレミスで運用で確認した構成を前提に、閉域の運用へ段階的に移行してください。
