>
>
公開日
最終更新日
生成AIのセキュリティ対策では、会社が承認した利用経路を用意し、入力データ・利用者・連携権限・操作ログを管理します。最初にAI利用台帳と企業ガイドラインを整え、DLPで機密情報の送信を制御し、SIEMで認証・送信・実行ログを関連付けます。
専任のセキュリティ担当者がいない体制でも着手できる最低限の対策と、社内検索や業務操作をAIへ任せる前の条件を分けて整理します。
法人プランの契約後も、RAG・エージェント・開発支援AIの審査を続けます。費用・期間の目安、90日間の導入計画、入力可否チェックシートを使い、自社で許可する範囲と停止する条件を決められる構成です。
最初の30分：経費・ID・プロキシの記録から利用中のAIを洗い出し、承認サービスを決める（「最優先の対策と適用範囲」）
予算がない場合：会社ID、入力可否の一枚資料、退職時の停止、事故窓口から始める（「予算が限られる場合の着手範囲」）
RAG・エージェントを導入する場合：「RAGとAIエージェントの権限設計」の章から読む
生成AIセキュリティのベストプラクティスとは
生成AIセキュリティのベストプラクティスとは、入力データから業務操作までを追跡し、許可した利用者が許可した範囲でAIを使えるようにする実務原則です。
本記事のポイント
情シスは、利用中のAIサービスと入力データを棚卸しし、承認済み環境と入力可否の基準を先に整えます。
DLPの送信制御とSIEM監視を企業ガイドラインに結び付け、違反検知後の担当者・対応期限・例外処理を決めます。
RAGは元文書のアクセス権を継承し、AIエージェントは検索・計画・承認・実行の権限を分けます。
PoCでは業務時間の削減と安全性を別々に測り、権限越境や承認迂回が残る用途は本番化しません。
保護対象と責任範囲
生成AIのセキュリティは、サービス自体に加え、利用端末、入力、検索対象、外部連携、出力の利用先を対象にします。
たとえば顧客との商談メモを要約する場合、入力の学習利用だけを調べても対策は終わりません。誰のアカウントから送信するか、履歴を誰が閲覧できるか、外部コネクターが何を取得するか、生成した要約をどこへ保存するかまで追います。業務部門は利用目的とデータの責任者を決め、情シスは認証・権限・監査の仕組みを整えます。契約条件と個人情報の扱いは、法務・個人情報保護担当を交えて判断します。
従来の端末保護や脆弱性管理も継続します。EDRで端末を保護していても、正規ユーザーが機密文書を正規のAIサービスへ送信する操作は、別のルールで制御します。
2026年の脅威と制度動向
2026年の対策では、AIを一般的なSaaSの追加として扱わず、検索や実行を伴う用途を個別に評価します。
IPAは2026年1月29日に公表した「情報セキュリティ10大脅威2026」で、組織向け第3位に「AIの利用をめぐるサイバーリスク」を初めて選出しています。2026年4月には、IPAとAIセーフティ・インスティテュートが共同で「AI利用者のためのセキュリティ豆知識」を公開しています。社内教育には、抽象的な注意喚起だけでなく、実際の入力や外部データの取り込みで起きる事故を使います。
日本では「人工知能関連技術の研究開発及び活用の推進に関する法律」が制定されています。AI法の法令本文は令和7年法律第53号として公開されています。同法は2025年6月4日に公布され、9月1日に全面施行されました。同法に基づく人工知能基本計画は2025年12月23日に初めて閣議決定され、2026年7月14日に改定版が閣議決定されています。推進を目的とする法制度と、個人情報保護・契約上の義務を混同せず、入力するデータに適用される既存の義務も確認します。
総務省・経済産業省は「AI事業者ガイドライン」の第1.0版を2024年4月19日に公表し、2026年3月31日に第1.2版を公表しています。2026年10月27日時点ではこの第1.2版が最新です。社内規程の参照版と差があれば更新し、参照した版数と改定日を残します。ガイドラインの更新担当者を決め、改定時は入力制限、人間の承認、利用記録のどこを変更するかまで評価します。
会社契約と個人契約の統制差
個人契約のAIが業務で使われているなら、利用者への周知より先に会社管理の移行先を用意します。
JIPDECとITRが2024年3月15日に発表した「企業IT利活用動向調査2024」では、生成AIの利用規定やガイドラインを策定している企業の割合が、会社で構築・契約した生成AIを使う企業で68.6％、社員各自で契約・登録した生成AIを使う企業で9.0％でした。これは2024年1月の調査結果で、「会社構築・契約のAI」は会社が契約・管理するAI、「社員各自契約・登録」は社員が個人で契約・登録したAIを指し、2026年の策定率としては扱いません。契約主体によって管理の届く範囲が異なる例として読みます。2026年1月に実施された「企業IT利活用動向調査2026」では、設問は2024年版と異なり、AI活用のガバナンス体制として全社的なポリシーやガイドライン、倫理規程を策定している企業が36.3％、AI利用を各部門に任せて全社的な統制がない企業が8.8％でした。
会社契約でも、管理者不在や退職時の停止漏れがあれば統制は途切れます。契約者、データ所有者、運用管理者を台帳で分け、異動・退職時に停止する接続先まで記録します。個人アカウントの利用者が見つかった場合は、入力データと共有履歴を確認したうえで移行し、履歴を無条件に法人環境へコピーしません。
最優先の対策と適用範囲
専任担当者がいない場合は、製品を増やす前に利用経路と事故時の連絡先を固定します。
経費、利用申請、ブラウザ・プロキシの記録から利用サービスを洗い出します。
承認済みサービスと会社管理のアカウントを指定します。
公開情報・社内情報・個人情報・営業秘密・認証情報の入力基準を配布します。
退職時の停止、誤送信時の連絡、外部連携の解除手順を決めます。
利用部門を絞って検証し、ログと運用担当を確保できた範囲から広げます。
必要な統制は企業規模ではなく、扱うデータとAIの権限で決めます。機密情報、外部送信、更新権限のいずれかを扱う用途には、追加対策を適用します。業務効率化の対象を整理する段階では、情シスが知っておくべきAI業務効率化の全体像と導入事例も、用途を切り分ける判断材料になります。
情シスを悩ませる生成AIの主要リスク
情シスは、情報の外部送信、攻撃入力、権限越境、資格情報の流出、誤出力を別々に評価し、それぞれの停止条件を決めます。
入力データの保持と情報漏えい
入力情報の保護では、学習利用と保存・閲覧・共有を分けて判断します。
「学習に使わない」という条件があっても、会話履歴の保存、障害調査のログ、利用者による共有リンク、連携アプリへの転送は別の論点です。法人契約を選定する担当者は、データの利用目的、保持期間、削除方法、保存地域、再委託先、監査ログの範囲を一枚の審査票にまとめます。入力内容を学習や保存の対象から除外できる条件についても、サービスの設定と契約を分けて扱います。
IPAの利用者向け資料は、クラウド型チャットAIの規約や設定によって入力を保存・学習の対象から除外できる場合を取り上げています。自社で必要な条件を契約と管理画面で満たせるなら対象データを限定して利用し、満たせなければ公開情報だけに用途を絞ります。
承認の対象はサービス名だけではありません。プラン、利用地域、接続するコネクター、利用する機能を含めて登録し、ファイル添付や外部検索を後から有効にした場合は変更審査へ戻します。
シャドーAIと調査コスト
シャドーAIが見つかった場合は、利用目的と入力データを把握し、事故調査に必要な記録を先に確保します。
シャドーAIとは、会社が承認していないサービスや個人アカウントを業務に使う状態です。未承認利用では、情シスが会話履歴や共有先を取得できず、事故時の影響範囲を特定しにくくなります。検知後は利用者を問い詰める前に、サービス名、アカウント、利用期間、入力したデータの種類、共有リンクの有無を記録します。漏えいのおそれがある場合は、通常の利用申請とは別のインシデント対応へ切り替えます。
IBMの「Cost of a Data Breach Report 2026」（2026年7月29日公表）では、従業員が未承認のAIを使うシャドーAIが関わったセキュリティインシデントの割合が前年の20％から43％へ増え、こうした侵害の平均コストは539万ドル（前年は463万ドル）でした。円換算すると、539万ドル×153円＝8億2,467万円です。153円は比較用に固定した仮定レートで、実勢為替ではありません。
この平均値を自社の被害額予測に直結させず、調査、封じ込め、通知、復旧を担う社内工数を別に見積もります。利用台帳とログを整備する際は、「事故時に誰が入力内容と送信先を特定できるか」を稟議の説明に加えます。
プロンプトインジェクションと外部入力
外部の文章を読むAIには、その文章を業務上の命令として扱わせない境界を設けます。
プロンプトインジェクションは、攻撃者の文章によって本来の指示を迂回させ、不適切な情報取得や操作へ誘導する攻撃です。攻撃文は利用者の入力欄だけでなく、Webページ、メール、PDF、チャット投稿に埋め込まれます。AIが読む情報の出所と、AIに許可する操作を分け、外部コンテンツから承認条件や送信先を変更できない構成にします。
たとえば問い合わせメールに「対応のため顧客一覧を指定先へ送信する」と書かれていても、その依頼をツール実行の根拠にしません。送信先の許可リスト、取得件数の上限、操作前の承認をアプリケーション側で判定します。攻撃手口の詳細と検証例は、プロンプトインジェクションの最新攻撃手口と実践的な防衛策に分け、全社ガイドラインには外部入力を信頼しない運用原則を記載します。
AIエージェントの過剰権限と資格情報管理
AIエージェントの資格情報は、人間の管理者アカウントと分け、用途ごとに操作範囲と有効期限を制限します。
AIエージェントは回答を返すだけでなく、APIでメール送信、顧客情報更新、ファイル削除などを実行します。2026年8月3日に公開されたOWASP Top 10 for LLM Applications 2026が扱うLLMアプリケーション固有のリスクも踏まえ、広い権限と自律実行を一度に与えない設計にします。読み取り、下書き作成、更新、社外送信を別の許可として管理します。
APIキーやトークンをプロンプト、ソースコード、チケット本文へ貼り付けません。秘密情報管理サービスから実行時に渡し、接続先が対応するなら短期トークンやワークロード単位の認証を使います。共有キーしか使えない接続先では、環境・用途ごとにキーを分け、管理責任者と失効手順を台帳へ登録します。エージェントの停止時に、ジョブだけでなく接続先の資格情報も失効できる構成にします。
端末感染とセッション窃取
AIサービスへのログインを強化しても、利用端末から資格情報を盗まれる経路は別に閉じます。
ブラウザのセッションCookieや開発ツールの設定が窃取されれば、攻撃者は正規の利用者として振る舞うおそれがあります。管理端末へのEDR適用、ブラウザ拡張機能の許可制、端末状態に応じたアクセス制御を組み合わせます。API利用量の急増や通常と異なる接続元を検出した場合は、キーとセッションを停止し、関連する端末と接続先を調査します。
認証情報を再発行するだけで対応を終えず、流出元の端末、リポジトリ、ログ、共有ファイルから露出を取り除きます。同じ保存場所へ新しいキーを戻す運用は避けます。
誤出力と権利侵害
誤りが外部への説明や本番システムへ影響する用途では、担当者が根拠と利用条件を確認してから出力を採用します。
法令、製品仕様、出典、コードの依存関係は、文章が自然でも正しいとは限りません。顧客回答、法務・人事判断、外部公開、本番コードへの反映にはレビュー担当者を割り当てます。参照元の表示を実装し、根拠が得られない回答は下書きにとどめます。生成物の権利確認と開発時の検査は、後述のコーディングAI統制にまとめます。
安全な利用環境を構築する技術的対策
技術対策は、CASBによる利用把握、DLPによる送信制御、法人IDによる認証、SIEMによるログ統合をつないで運用します。
提供形態ごとの確認基準
提供形態を比較する際は、同じ審査項目で会社が管理できる範囲を判定します。
個人アカウント、法人向け管理環境、API利用では、自社が実装する責任範囲が異なります。以下は製品の機能保証ではなく、導入審査で埋める比較表です。対応している項目は契約文書や設定画面を証跡として残し、未対応の項目には代替運用と責任者を記入します。
比較項目 | 個人アカウント利用 | 法人向け管理環境 | API利用の自社アプリ |
|---|---|---|---|
利用者管理 | 組織側の停止・監査が難しいため公開情報の試用に限定 | SSO、アカウント停止、管理者ロールを審査 | アプリ認証とユーザー権限を自社で実装 |
データ利用条件 | 規約と個人設定に依存 | 非学習条件、保持期間、保存地域を契約単位で審査 | API契約に加え、自社の中継・ログ保存も審査 |
監査 | 組織横断の履歴取得が困難 | 監査ログ、出力形式、取得頻度、欠損時の対応を審査 | アプリ・検索・ツール実行の履歴を自社で保存 |
外部連携 | 個人が接続したアプリを把握しにくい | コネクターの管理者承認と権限範囲を審査 | 接続先ごとに認証、許可操作、通信先を制限 |
停止手段 | 利用者の操作に依存しやすい | ID停止と共有・連携解除を運用化 | アプリ停止、キュー停止、トークン失効を実装 |
主な残存リスク | 履歴共有、私用端末、アカウント侵害 | 設定不備、過大な共有範囲、出力誤用 | キー漏えい、認可不備、連携先への権限越境 |
監査ログと会社側のID停止を確保できるなら、社内情報を扱う限定検証へ進みます。確保できなければ公開情報の用途へ分離し、機密領域へ接続しません。APIを使う場合は、提供事業者の条件を満たしていても、自社アプリの認可とログが未実装なら本番接続を止めます。
CASBとプロキシによる可視化
利用実態が不明な段階では、プロンプト全文の収集より、誰がどのAIへアクセスしたかの把握を先行します。
CASBはクラウド利用の把握とポリシー制御に使う仕組みです。プロキシや管理ブラウザと組み合わせ、未承認サービスへのアクセス、ファイル送信、個人アカウント利用をどこまで判別できるかを検証します。URLへのアクセス記録と、ログインや実際のデータ送信の記録を混同しません。アクセス件数だけで利用人数や入力件数を推定すると、バックグラウンド通信を業務利用として数えるおそれがあります。
HTTPSの内容検査を行う場合は、TLS復号、端末への証明書配布、対象アプリの互換性、処理遅延を試験します。対象を全通信へ広げず、管理端末のAIサービス利用とファイル送信から始めます。検査できない私用端末や直接接続がある場合は、その経路を監視対象に含めたように報告せず、アクセス条件と利用規程で補います。
DLP実装ガイドと誤検知対策
DLPは検知だけの監査モードから始め、業務上の正当な送信を判別してから遮断へ移します。
生成AI向けのDLP実装ガイドには、検知対象、送信経路、動作、例外、ログを一組で記載します。氏名や電話番号のパターンだけに依存せず、文書ラベル、顧客番号、社内固有語、既知の機密文書との一致などを組み合わせます。たとえば「田中太郎」がテスト用の架空名か実在顧客かは、文字列だけでは判定できません。テストデータの専用保管場所やラベルを用意し、本物の顧客情報と分けます。
検知対象を、顧客名簿、契約書、認証情報などのデータ種別ごとに登録します。
ブラウザ入力、ファイル添付、API送信など、対象経路でルールが働くか試します。
初期の30日間を監査期間の計画例とし、検知内容を担当者が分類します。
高確度の認証情報や顧客名簿から遮断し、曖昧な文脈は警告または承認へ回します。
例外は対象者・用途・期限を限定し、期限後に自動失効または再審査します。
DLP誤検知率は「確認済みの誤検知件数÷レビュー済み検知件数」で集計します。たとえばレビュー済み200件のうち確認済みの誤検知が60件なら30％で、この仮例では、遮断を認証情報と顧客名簿に絞ったまま、率の高いデータ種別から文書ラベルなどの判定条件を見直します。未レビューの検知を分母へ混ぜず、部門やデータ種別ごとに集計します。検知漏れは実事故の件数だけでなく、既知のテストデータを使う定期試験でも測ります。ルールを緩めたときは、誤検知の減少と同時に検知漏れが増えていないかを再試験します。
SIEM監視とログ統合の設計
SIEM監視では、認証・送信・検索・実行を同一の利用者と処理単位で関連付けます。
生成AI企業ガイドラインの禁止事項を、検知ルールと対応手順へ対応付けます。「機密情報の外部送信禁止」なら、DLP検知、送信先、利用者、端末、処理結果をチケットへまとめます。「承認なしの業務更新禁止」なら、エージェント実行ログと承認記録を突き合わせます。ログを集めるだけで担当者が動けない状態を避け、検知ごとに一次対応者とエスカレーション先を指定します。
ログ種別 | 共通化する項目 | 検知例 | 対応 |
|---|---|---|---|
ID・認証 | 利用者ID、端末ID、時刻、接続元、成否 | 停止済みIDからの接続、通常と異なる接続元 | セッション停止と端末調査 |
DLP・プロキシ | サービス、送信先、分類、ルールID、処理結果 | 機密ファイル送信、遮断後の繰り返し送信 | 送信範囲の特定と利用者ヒアリング |
RAG検索 | 処理ID、文書ID、適用権限、認可結果 | 権限外文書の取得、異動後の旧権限利用 | 検索停止とインデックス・認可調査 |
エージェント実行 | 処理ID、ツール、対象、承認ID、結果 | 承認記録のない更新、実行回数の急増 | ジョブ停止と資格情報の失効 |
時刻はタイムゾーンを統一し、アプリから検索・API実行まで引き継ぐ処理IDを発行します。監査APIがある場合は自動収集し、ない場合はCSV出力と取り込みの担当・頻度を決めます。ログの取り込み遅延や欠損も監視対象にし、欠損中の高リスク操作は停止するか人手承認へ切り替えます。全文のプロンプトや個人情報は必要な調査保管先へ分離し、SIEMには識別子と判定結果を中心に送ります。
ガードレールと多層防御
AIガードレールは、入力・出力・ツール実行の判定を分け、認可処理の代替にしません。
AIセーフティ・インスティテュートの「AIセーフティに関するレッドチーミング手法ガイド」第1.10版（2025年3月31日）は、入力フィルター、検閲用LLM、出力フィルターなどの防御機構を挙げています。機密情報の検出や不適切な出力の抑制に利用しつつ、支払い上限、送信先、更新対象の認可は決定的なプログラム処理でも検証します。AI TRiSMの考え方を運用へ取り入れる場合も、信頼性・リスク・セキュリティを担当部署ごとに分断せず、同じ変更管理票で扱います。
デロイト トーマツ ミック経済研究所の「AIセキュリティソリューション市場動向 2026年度版」（2026年7月30日発刊）は、同市場の2026年度売上を557億円と見込んでいます。これは予測値であり、確定した実績ではありません。市場の拡大を購入理由にせず、自社で未対策の送信経路や監査要件に対応する機能へ予算を割り当てます。既存のID・DLP・SIEMで埋まる範囲と、AI固有の検査が残る範囲を分ければ、重複契約も避けられます。
▶ 関連記事: 情シス主導のAI業務効率化ロードマップ｜業務棚卸しから運用まで【2026年版】
▲ 生成AIの提供形態における管理責任と残存リスクの比較
RAGとAIエージェントの権限設計
RAGでは利用者の閲覧権限を検索と回答まで維持し、AIエージェントでは計画・認可・実行・監査を分離します。
ACL継承と検索前フィルタリング
社内文書を検索するRAGは、元文書のアクセス制御リストであるACLを取り込み、検索前に利用者の権限で対象を絞ります。
文書の本文だけをベクトルデータベースへ登録すると、元の共有フォルダで見えなかった情報が回答へ混ざるおそれがあります。取り込み時に文書ID、所有部門、閲覧可能なグループ、版、削除状態を付与し、利用者の認証情報から検索条件を組み立てます。検索後にも取得文書の権限を再検証し、回答に含める前に認可を通します。利用者が質問文で部門名を変更しても、検索条件が広がらない構成にします。
権限テストでは一般社員、部門管理者、委託先などの検証用IDで同じ質問を実行します。本文の回答だけでなく、検索候補、引用文、ファイル名、エラーメッセージにも権限外情報が出ないかを調べます。権限越境が一件でも見つかった対象データは接続を止め、修正後の再試験が完了するまで公開しません。
権限変更と削除の反映
元データの権限変更や削除は、検索インデックス、キャッシュ、引用表示へ連動させます。
人事異動でグループを外しても、過去の検索キャッシュや生成済み回答が残る場合があります。文書更新と権限変更のイベントを取り込み、変更が反映される期限を運用条件に記載します。同期の失敗を検出した場合は、古い権限を使い続けず、該当するデータ領域を検索対象から外します。機密性の高い文書は、全社共通のデータストアに混在させず、用途やテナントで分離します。
削除試験は、元文書を消すだけで完了させません。文書IDから検索結果、埋め込み、キャッシュを追い、通常の検索と類似表現による検索の両方で再表示されないかを試します。監査のため残すログと、利用者向け検索から消すデータを区別し、保存目的ごとの扱いを決めます。
外部メールと間接プロンプト攻撃
外部メールをRAGへ取り込む場合は、メール本文を検索資料として扱い、操作命令としては採用しません。
IPAは、不正プロンプトを含む攻撃メールと社内文書をRAGが取り込むことで、社内情報が社外へ流出するリスクを取り上げています。営業支援AIが外部から届いたメールと社内の顧客情報を同時に読める場合、攻撃文の影響範囲はメール要約にとどまりません。検索と送信のツールを連続実行できるかを、接続前の審査で調べます。
外部入力には取得元と信頼区分を付け、内部文書と区別してアプリへ渡します。外部メールに書かれた宛先をそのまま送信先へ採用せず、許可リストや担当者承認で判定します。テストには、情報の抜き出し、別サイトへの誘導、承認回避、命令の分割を含むケースを用意します。入力フィルターを通過しても、実行側の制限が残る構成にします。
計画・認可・実行・監査の役割分離
エージェントの提案をそのまま実行せず、別の処理系が操作の可否を判断します。
Planner、Policy Gate、Executor、Auditorの4役を分ける設計は、LLMが作る計画とシステムが許可する操作を切り離す際に使えます。実務へ置き換える場合は、プロンプトを4本へ分けるだけでなく、資格情報、実行経路、ログの書き込み先を分離します。PlannerがPolicy Gateのルールや承認記録を書き換えられる構成は避けます。
役割 | 担当する処理 | 与えない権限 | 残す記録 |
|---|---|---|---|
Planner | 依頼を読み、検索や操作の計画を作成 | 本番の更新・送信に使う資格情報 | 依頼、計画、利用した情報の識別子 |
Policy Gate | 利用者権限、対象、金額、宛先、承認を判定 | AIの文章だけによるルール変更 | 判定結果、適用ルール、承認ID |
Executor | 許可された操作だけをAPIで実行 | 許可範囲の拡大、別ツールへの自由な切り替え | 対象、引数、結果、処理ID |
Auditor | 計画・承認・実行結果を照合 | 元ログの改変や未承認操作の追認 | 不一致、調査チケット、是正結果 |
小規模な実装でも、認可を共通関数へ集約し、実行直前に毎回通します。承認が必要な操作は、承認後に対象や宛先が変わっていないかを再検証します。同じ操作の再試行で二重処理が起きないよう、処理IDと重複防止の仕組みを設けます。
資格情報の払い出しと失効
AIエージェント資格情報のベストプラクティスは、必要な実行主体へ必要な時間だけ権限を渡す運用です。
本番・検証環境でキーを共用せず、エージェントの用途ごとに接続先を分けます。読み取り用と更新用で資格情報を分離し、更新用は承認が完了した処理だけが利用できる経路へ置きます。長期キーが必要な接続先では、所有者、有効期限、最終利用、失効手順を台帳へ登録します。利用量の上限は費用制限として設定し、取得件数や送信件数は業務影響の制限として別に設定します。
停止訓練では、エージェントのジョブ停止、実行待ちキューの無効化、トークン失効、接続先の状態確認まで試します。停止後も処理が継続する非同期APIがある場合は、取消手順を加えます。権限設計の背景や導入判断は、情シス向けAIエージェントの定義と安全な導入手順と併せて整理できます。
引用元と監査証跡の設計
RAGの回答には参照文書を表示し、監査側には検索条件と認可結果を残します。
利用者向けには文書名、版、更新日、閲覧権限に対応したリンクを表示します。監査用には利用者ID、文書ID、検索フィルター、モデル識別子、テンプレート版、ツール実行、エラーを記録します。回答の根拠が取得できない場合は、該当資料が見つからなかった旨を返し、一般知識で社内規程を補完しません。
▶ 関連記事: AIエージェントのセキュリティと情シス向けガバナンス実務ガイド
▲ ACL継承と検索前後の認可によるRAGアクセス制御の構成
AIセキュリティPoCの計画策定と社内合意
AIセキュリティPoCは、一つの業務と限定したデータから始め、業務効果・安全性・運用負荷の合格条件を着手前に決めます。
検証範囲と必要リソース
最初のPoCでは、対象業務、利用者、データ、接続先、操作範囲を一枚の計画書で固定します。
「生成AIを試す」だけでは検証範囲が広がり、精度が良かったという感想で終わりやすくなります。たとえば情シスFAQなら、対象は更新責任者がいる手順書に限定し、回答の作成までを許可します。アカウント作成や端末設定の変更は含めません。対象を追加する場合は計画書を改版し、データ所有者と情シスが変更を承認します。
必要な担当は、業務責任者、データ所有者、ID・ネットワーク担当、セキュリティ評価担当、利用者代表です。契約や個人情報が関わる場合は法務も参加します。兼務する場合も役割を省略せず、成果を出す担当と合否を判定する担当を分けます。外部委託を使う場合は、委託先が実データを閲覧する範囲と、検証終了後の削除を契約に含めます。
費用と期間の目安
PoCの見積もりは、評価だけの案件、法人環境の整備、既存システム連携を分けて比較します。
Geek Bridgeは、自社の生成AIセキュリティ導入の費用・期間目安として、以下の範囲を提示しています。これは同社が示す参考値であり、市場平均や自社案件の確定見積もりではありません。同社の目安には、製品のライセンス料、利用量に応じたAI利用料、法務専門家への相談費用は含まれていません。社内工数、文書整理、継続監視の費用を含むかも、見積書で切り分けます。
対象範囲 | 費用目安 | 期間目安 | 見積もり時に固定する条件 |
|---|---|---|---|
リスク評価のみ | 30万〜100万円 | 2〜6週間 | 対象サービス、ヒアリング範囲、評価報告書の内容 |
法人向けSaaSの導入整備／SSO・ログ・権限設計を含む全社導入 | 法人向けSaaSの導入整備：50万〜200万円／SSO・ログ・権限設計を含む全社導入：150万〜500万円 | 法人向けSaaSの導入整備：1〜2か月／SSO・ログ・権限設計を含む全社導入：2〜4か月 | 法人向けSaaSの導入整備：対象サービス、管理設定、教育の有無／SSO・ログ・権限設計を含む全社導入：対象サービス、SSO・管理設定、ログ取得範囲、権限設計 |
API連携を含む専用システム | 300万〜1,500万円以上 | 3〜8か月以上 | 接続先、認可、データ加工、ログ、運用引き継ぎ |
RAGの対象文書に所有者不明やアクセス権不明の資料が多い場合は、AIの構築前に整理期間を置きます。構築期間へ無理に押し込むと、検証用の簡易権限が本番へ残るおそれがあります。外部APIの審査や契約が長引く場合も、公開データで機能試験を進める範囲と、実データを使う試験を分けます。
検証期間と合否判定
期間は暦日だけで決めず、業務試験、攻撃試験、運用試験が一巡する日程にします。
以下は、既存の承認済み環境で部門限定の検証を行う場合の計画例です。API連携の全開発期間を4週間で完了する想定ではありません。評価項目を先に登録し、途中で成功条件を下げない運用にします。
期間例 | 実施内容 | 終了時の成果物 |
|---|---|---|
第1週 | 対象業務、データ、基準、担当者を確定 | 計画書、データ一覧、試験項目 |
第2週 | 通常業務の回答・作業時間を測定 | 業務効果と誤回答の記録 |
第3週 | 権限越境、攻撃入力、削除反映、承認迂回を試験 | 不具合一覧と再試験結果 |
第4週 | 停止、復旧、ログ調査、引き継ぎを試験 | 運用手順、合否判定、残課題 |
業務効果は、AIが回答するまでの時間ではなく、人が確認・修正して完了するまでで測ります。安全性は、権限外情報が出ないか、未承認操作を止めるか、事故を追跡できるかで判定します。重大な権限越境や承認迂回は、回答精度の高さと相殺しません。未解決なら対象機能を外すか、修正後に検証を延長します。
経営層と事業部門への説明
社内説得では、削減時間の見込みに加え、許可する業務と停止する業務を具体的に示します。
Gartnerは2026年9月の調査発表で、AIを複数事業部門へ本格展開できている組織は22％としています。この数値を自社PoCの成功確率へ読み替えず、部門内の機能検証と全社展開の運用整備を分ける理由として使います。経営層には、PoC終了後もID、文書更新、監視、教育の担当が残る計画を提示します。
稟議書では、現状の作業時間、対象件数、検証後の実測時間、導入・運用費、残る人手作業を並べます。仮に月100件の作業で確認込みの時間を1件12分から8分へ短縮できた場合、削減は月400分、約6.7時間です。これは効果計算の仮例で、導入実績ではありません。人件費換算と、実際に減る外注費・残業費を分ければ、経営判断を過大な効果予測へ誘導せずに済みます。
中止条件と本番移行条件
PoCの終了時は、継続・範囲縮小・中止を同じ判定表で決めます。
監査ログを取得できない、データ責任者が決まらない、権限不備を修正できない場合は、本番移行を止めます。利用者が十分に試せず件数が不足した場合は、安全性の不合格と混同せず、対象業務を見直して再計画します。本番化する場合は、残課題の所有者、解消期限、再評価日、障害時の代替手順を引き継ぎ、試用アカウントと一時的な外部接続を整理します。
▶ 関連記事: AI利用ガイドラインの作り方｜社内規定に盛り込むべき10項目と雛形【2026】
▲ 既存の承認環境で進める部門限定AI検証の4週間PoC手順
全社ガバナンスと90日間の導入ロードマップ
運用人員が限られる情シスは、利用台帳、承認済み環境、入力基準、ID停止、事故窓口を先に整え、実際に運用できる範囲から自動化します。
運用体制別の優先順位
統制レベルは従業員数だけで分けず、担当者の稼働と業務上のリスクで選びます。
専任担当者を置けない体制では、承認サービスを絞り、申請と棚卸しを共通の台帳へ集めます。複数部門でAIが使われる体制では、部門の責任者に利用者とデータの更新を依頼し、情シスが全社の設定基準を管理します。RAGや業務更新を伴う体制では、検索権限、実行権限、監査、停止訓練を追加します。人数が少なくても高機密情報を扱う場合は、これらの条件を省略しません。
運用条件 | 最初に整える内容 | 追加する条件 |
|---|---|---|
専任の管理担当を置けない | 承認サービス、会社ID、入力基準、連絡窓口 | 担当を確保できる範囲で定期棚卸し |
複数部門でサービスが増えている | 共通台帳、部門責任者、SSO、利用状況の集計 | 送信経路を把握した後にDLP監査 |
機密RAGや業務操作を扱う | ACL継承、実行前認可、承認記録、監査 | SIEM連携、資格情報失効、停止・復旧訓練 |
外部サービスへ委託する場合も、自社のデータ所有者と事故判断者は残します。委託先から受け取る月次報告には、検知件数だけでなく、未対応事項、例外の期限、ログ欠損、設定変更を含めます。
AI利用台帳と責任分担
台帳はサービスの一覧ではなく、利用許可と停止判断に必要な情報を結び付ける記録です。
サービス名、プラン、部門、管理者、利用目的、データ区分、契約条件、認証方法、外部連携、監査方法、停止手順、見直し日を登録します。SaaS台帳と二重管理する場合は、共通のサービスIDを付けて契約・ユーザー情報を参照します。経費やログで見つかった新しいサービスは「未評価」として登録し、承認済みのサービスと混在させません。契約更新だけでなく、コネクター追加、共有範囲変更、モデル切り替えも変更管理の対象にします。
事業部門は用途とデータ、情シスは設定とアカウント、法務は契約、セキュリティ担当は評価と監視を受け持ちます。兼務でも、申請者が自分の高リスク利用を最終承認する運用は避けます。
90日間の導入計画
最初の90日間は、棚卸し、限定運用、統制の適用の順に進めます。
以下は導入計画のたたき台です。新規API開発や契約審査が90日を超える場合は、調査・規程・限定環境の整備を先行し、本番接続を別の判定にします。期限を守るために安全性の試験を省略しません。
期間 | 実施内容 | 成果物 | 計測する指標 | 次へ進む条件 |
|---|---|---|---|---|
1〜30日 | 利用調査、ログ確認、部門ヒアリング、データ分類 | AI利用台帳、未承認サービス一覧、入力基準 | 所有者不明件数、未承認アクセス数、調査完了率 | 用途とデータを特定し、管理責任者を置ける範囲から選定 |
31〜60日 | 承認環境、SSO、企業ガイドライン、DLP監査 | 管理設定、例外申請、教育資料、検知結果 | DLP誤検知率、申請滞留件数、承認所要時間 | ID停止とログ調査を試し、部門限定運用を開始 |
61〜90日 | 対象別の遮断、RAG・エージェントPoC、事故演習 | 評価報告、運用手順、改善計画 | 権限テスト失敗数、停止所要時間、承認迂回件数 | 重大不具合を解消し、運用担当を確保できる機能を本番化 |
未承認アクセス数は、監視対象の端末数と期間を併記して比較します。管理端末が増えた月に件数が増えても、ただちに統制が悪化したとは判定しません。承認所要時間は、申請から決裁までと、情報不足による差し戻し時間を分けます。滞留が多い場合は、担当者を増やす前に申請フォームと許可基準を見直します。
教育受講率は配布済みの人数ではなく完了者で数え、確認テストの結果も残します。AIエージェントの人手承認率は、高ければ安全と評価せず、承認対象の操作が漏れていないかと、担当者が内容を確認できる件数かを併せて調べます。
入力可否の判断チェックシート
入力基準は、データの機密度と利用環境を交差させて決めます。
以下は全社配布用のたたき台です。「社内一般情報」と「公開情報」を混同せず、社外へ出してよいかをデータ所有者が分類します。契約上の持ち出し禁止や業界固有の制約がある場合は、一般的な入力許可より優先します。
データ区分 | 例 | 個人向け・未承認AI | 承認済み法人環境・社内RAG | 許可の条件 |
|---|---|---|---|---|
公開情報 | 公開済み資料、プレスリリース | 会社の利用規程の範囲で可 | 可 | 出力と引用元を担当者が確認 |
社内一般情報 | 非公開の一般手順書、社内FAQ | 不可 | 条件付き可 | 所有者、非学習条件、保持、会社IDを整理 |
個人情報 | 氏名、連絡先、健康情報 | 不可 | 個別審査 | 利用目的、法的扱い、アクセス権、最小化を審査 |
営業秘密・NDA情報 | 未発表製品、顧客契約、M＆A資料 | 不可 | 個別審査 | 契約上の許可、隔離、最小権限、監査を確保 |
認証情報 | パスワード、APIキー、秘密鍵、Cookie | 不可 | プロンプト入力は不可 | 秘密情報管理サービスから実行処理へ受け渡し |
氏名を伏せただけで匿名情報になったと判断しません。所属、日時、案件の内容などの組み合わせで個人を識別できる場合は、個人情報として審査します。マスキング後の文章でも契約上の秘密が残る場合は、公開情報向け環境へ入力しません。社員向けの一枚資料には、表とともに相談先と申請方法を載せます。
AIデータガバナンスとプライバシー管理
AIデータガバナンスでは、文書の所有者、利用目的、保存期間、削除責任を登録します。
個人情報を含む入力は必要最小限にし、目的外利用を制限します。あわせて、閲覧権限と保存期間を管理します。要約に不要な個人情報を除き、顧客や従業員のデータを評価用へ転用する場合は目的と契約を審査します。ログ収集でも同じ基準を適用し、監視のために個人情報を無制限に複製しません。
文書には更新日と見直し期限を付け、期限切れの規程を検索から外します。元データの修正や削除の依頼を受けた担当者は、RAGとログにどう反映するかを運用手順に沿って判断します。全社導入の順序を整理する場合は、情シス主導によるAI業務効率化のロードマップと実務手順と共通の担当表を使うと、導入計画と管理計画を分離せずに進められます。
生成AI導入で避けるべき失敗パターン
生成AI導入の失敗を防ぐには、禁止通知や契約で完了とせず、現場の利用経路と本番反映までの承認を管理します。
代替手段のない一律禁止
禁止が必要な用途を明示し、低リスク業務には会社が管理できる利用経路を用意します。
「生成AIは禁止」とだけ通知すると、社員が個人端末や個人アカウントへ移る可能性があります。公開情報の要約や文章校正には承認環境を用意し、個人情報や秘密情報を扱う用途は審査へ回します。未承認利用を検知したときは、悪意ある持ち出しとルールの誤解を分けて対応します。利用者が事故や誤入力を報告しにくくなる運用は避け、相談とインシデント報告の窓口を明示します。
法人契約を根拠にした審査省略
法人プランへ切り替えた後も、共有設定と外部連携の審査は継続します。
契約条件が整っていても、利用者が公開リンクを作ったり、広い権限のコネクターを追加したりすれば、想定外の閲覧経路が生まれます。承認した設定を基準として記録し、機能追加時は差分を評価します。API利用でも、開発者の共通キーを本番へ持ち込まないよう、リリース審査で資格情報とログを確認します。契約審査と設定審査を同じチェック項目で代用しません。
コーディング支援AIの無統制利用
AIエージェントを使う安全なソフトウェア開発では、ソースコードの入力許可と生成コードの採用許可を別々に判定します。
開発者が個人契約の支援AIへリポジトリ全体を読み込ませると、秘密情報、顧客固有の実装、未公開仕様まで送信対象になるおそれがあります。まず、対象リポジトリ、ファイル種別、IDE拡張機能、接続先、データ利用条件を承認します。社外提供を禁止されたコードは対象から外し、除外設定が実際に働くかを検証します。リポジトリ内のREADMEや課題本文も外部由来の指示を含み得るため、エージェントに実行権限を渡す前に取得元を区別します。
コードを生成するAIシステムがビルドやテストを実行する場合は、隔離した実行環境を使います。本番の秘密情報、署名鍵、公開用トークンを渡さず、ネットワークの送信先と実行コマンドを制限します。パッケージ追加、外部スクリプト取得、CI設定変更、権限設定変更は、通常のコード補完より強い承認対象にします。AIがテストを通すために検査や認証を無効化していないかもレビューします。
脆弱性とライセンス問題の見落とし
AI生成コードは未審査の変更として扱い、人によるレビューと自動検査を通してからマージします。
生成コードにSQLインジェクション、認証不備、秘密情報の埋め込み、誤った暗号利用などが含まれないかを検査します。静的解析、依存関係の脆弱性検査、秘密情報スキャン、テストをCIで実行し、結果をAIの自己評価だけで代替しません。生成されたパッケージ名が実在するか、公式の配布元か、バージョンが利用条件を満たすかも確認します。存在しない依存関係を探して類似名のパッケージを安易に導入しない運用にします。
いわゆるライセンス汚染を避ける際は、曖昧な一括禁止ではなく、著作権表示、コピー元、依存ライブラリ、配布条件を調べます。出所を示せない長いコードや、利用条件の異なる実装との類似が疑われる変更は、法務またはOSS管理担当へ回します。問題が解消しない場合は採用せず、仕様に基づいて再実装します。採用した変更にはレビュー担当者と検査結果を残し、後から対象バージョンを追えるようにします。
開発工程 | 許可する範囲 | 人の承認を置く変更 | 残す証跡 |
|---|---|---|---|
コード補完 | 承認済みリポジトリの対象ファイル | 認証、権限、暗号、個人情報処理 | 変更差分とレビュー |
依存関係の追加 | 配布元と利用条件を審査したパッケージ | 新規ライブラリ、外部取得スクリプト | バージョン、ライセンス、検査結果 |
テスト・ビルド | 隔離環境、検証用データ、制限付き通信 | CI設定、検査の無効化、秘密情報への接続 | 実行コマンド、ログ、結果 |
本番反映 | 既存の変更管理に沿ったリリース | マージ、デプロイ、DB変更 | 承認、リリースID、ロールバック手順 |
全社データの一括投入
RAGの初期対象は、権限と更新責任者が明確な文書に限定します。
共有ドライブを一括投入すると、アクセス権不明の資料、古い規程、退職者フォルダ、顧客ごとの秘密情報が混在するおそれがあります。対象を増やす前に、所有者、分類、版、ACL、削除方法を埋めます。文書追加の申請にも、初回登録と同じ最低限の審査を残します。
長い規程と一度きりの教育
社員が入力直前に判断できるよう、規程本文とは別に具体例と相談経路を一枚にまとめます。
名刺、商談メモ、採用候補者の経歴、問い合わせメールなど、業務で扱うデータを例示します。DLPで警告されたときの選択肢と例外申請も記載し、規程とシステムの挙動を一致させます。教育は機能変更や検知事例に合わせて更新し、受講しただけで終えず確認テストを実施します。事例共有では個人を特定する情報を除き、誤りが起きた条件と変更した手順を伝えます。
▶ 関連記事: 【失敗事例】社内チャットボットが使えない原因と回避策
国内企業に学ぶ生成AIセキュリティの実践例
国内企業の導入事例は、アクセス権の整理、利用前教育、分析作業の支援を分けて読むと、自社の施策へ移し替えられます。
三井化学の権限棚卸しと利用前テスト
三井化学の事例では、全社展開前のデータ共有範囲と利用者教育を同時に整えています。
化学メーカーの三井化学について、Microsoftが公開したMicrosoft 365 Copilotの全社導入事例では、オーバーシェアリングへの対応として社内データのアクセス権限を全社的に棚卸し・再確認し、利用前提として確認テストの合格を義務付けています。事例の公開は2026年8月で、同社は2025年7月に約1,700のライセンスを付与して全社利用を始め、2026年4月時点で4,200以上のライセンスを活用しています。ここでは導入効果を時間削減率へ置き換えず、公開された統制施策を読み取ります。
AI導入で既存の過剰共有が表面化しやすくなるため、まず文書所有者に共有範囲を再確認してもらいます。利用者には入力基準と検索結果の扱いを確認テストで周知し、合格後に対象を広げます。AI導入の前から誰でも閲覧できた資料でも、その状態を正しい権限として無条件に引き継ぎません。
ラックのSOC業務支援
ラックの事例では、SOCでの分析支援に生成AIを使い、作業時間を測定しています。
セキュリティサービスを提供する株式会社ラックについて、Microsoftの2025年公開のMicrosoft Security Copilot活用事例では、自社SOC運用で10％以上の時間短縮を、同社の担当者が体感として語っています。対象はSOC業務であり、全社のセキュリティ費用が同率で減ったという数値ではありません。調査・分析を支援する用途と、業務システムを自動停止する用途を区別して読みます。
SOCでは、調査に必要な情報の整理が担当者の負荷になります。導入初期は、元ログと照合できるアラート要約や調査結果の下書きに用途を限定するのが現実的です。評価ではAIの応答時間だけでなく、担当者の確認・修正を含む完了時間を比較します。
NTTコミュニケーションズのスクリプト分析
NTTコミュニケーションズの事例は、対象を明確にした分析作業で効果を測った例です。
Microsoftが2024年に公開したNTTコミュニケーションズのMicrosoft Security Copilot導入事例では、PowerShellなどのスクリプト分析に関する作業負荷と関連コストを50〜70％削減しています。通信・ICT分野の同社における特定工程の成果であり、SOC全体の工数削減率としては扱いません。過去の導入事例として、対象範囲を限定して引用します。
課題は、解析担当者がスクリプトの挙動を読み解く負担です。施策は、AIによる分析支援を使い、担当者の調査を補助する運用です。自社で再現性を検証する場合は、難易度の近いサンプルを使い、解析結果の正確性、見落とし、修正時間を記録します。AIが示した説明をそのまま隔離や遮断の根拠にせず、担当者が元のコードとログで裏付けます。
全社共通の利用環境を用意する場合
全社向けの共通環境は、会社が利用経路を用意し、個人契約での利用を管理下へ移す施策として設計できます。
会社が共通の利用先を用意する施策と、個別業務で扱う情報の許可は分けて考えます。全社共通の環境を用意する企業であっても、非学習、ログ、RAGの権限継承など個別の実装仕様は外部から推定しません。
自社では、全社向け環境を配布する前に、管理者、アカウント停止、入力分類、問い合わせ先を決めます。利用人数を展開目標に置く場合も、利用者数だけで統制の完了を判断せず、管理責任者がいるサービスの比率と未対応の設定を追います。
金融・セキュリティ分野への適用判断
企業名だけを根拠に自社の設計を決めず、公開された施策と一般的な設計例を分けます。
三菱UFJフィナンシャル・グループのような金融グループを比較対象にする場合でも、金融機関で使われているという理由でRAGの権限方式を推定しません。自社の顧客情報、取引情報、規程ごとに、誰の閲覧権を引き継ぐかを定義します。金融分野に必要な統制の説明と、個社の実装事実は別に扱います。
防御にAIを使う「AI for Security」と、AIシステム自体を守る「Security for AI」も、予算と評価を分けて整理します。前者ではアラート分析や調査支援の時間・品質を測り、後者ではAIアプリの認可、入力、出力、外部連携を試験します。防御にAIを使っていることを、AIシステム自体の安全性の証明にしない運用にします。
継続運用のチェックリストとよくある質問
導入後は、月次点検、変更審査、事故対応を定例化し、担当者が実行できるチェック項目へ落とし込みます。
導入前と月次のチェックリスト
チェックリストには、実施日、担当者、証跡、未完了の期限を記入します。
「対応済み」という印だけでは、契約や設定が変わった後の状態を追えません。各項目に設定画面、試験結果、チケット番号などの参照先を残します。日常運用の担当が決まらない項目は、外部委託または利用範囲の縮小を選び、無人の監視を続ける計画にしません。
時期 | チェック項目 | 完了の証跡 | 未完了時の対応 |
|---|---|---|---|
導入前 | 利用目的、データ所有者、管理者を登録 | 承認済みの台帳・申請書 | 公開情報による試用へ限定 |
導入前 | 契約、認証、監査、停止を審査 | 審査票と動作試験 | 実データ接続を保留 |
月次 | 未承認サービス、退職・異動ID、外部連携を点検 | 差分一覧と是正チケット | 対象の停止・権限修正 |
月次 | DLP検知、誤検知、例外期限を集計 | レビュー結果とルール変更履歴 | 曖昧なルールは監査継続、期限切れ例外は失効 |
月次 | RAGの権限・削除反映、API利用量を試験 | テスト結果と監査記録 | 不合格のデータ領域・接続を停止 |
機能変更時 | モデル、コネクター、実行権限の差分を評価 | 変更申請と回帰試験 | 既存の承認範囲を維持 |
モデルやテンプレートの変更でも、回答品質やツール選択が変わるため、同じ評価セットで回帰試験を実施します。外部送信、更新、権限のテストを含め、過去に修正した事故が再発しないかを調べます。機能名が同じでも動作が変わる場合に備え、変更前の設定と戻し方を記録します。
インシデント初動と復旧判断
事故時は、被害拡大の停止と証拠保全を並行し、対象のアカウント・接続先・データを特定します。
担当者へ連絡し、対象アカウント、ジョブ、共有リンク、外部トークンを停止します。
会話、認証、DLP、検索、ツール実行のログを保全し、時刻と処理IDをそろえます。
入力データ、閲覧可能だった範囲、実際の送信先、更新された対象を特定します。
法務、個人情報保護、広報、事業責任者へ同じ事実関係を共有します。
原因を除去し、権限・停止・ログの再試験を通した範囲から復旧します。
共有リンクを消しただけでデータが回収できたと判断しません。外部に保存・転送された可能性、接続先の履歴、提供事業者への削除依頼を整理します。証拠保全の前に会話やファイルを一斉削除する運用も避けます。緊急停止に必要な操作を優先しつつ、取得できるログを担当者が保全します。
復旧の承認は、事故対応の完了と分けて行います。原因が分からないまま同じキーや設定を再利用せず、対象を限定して再開します。AI導入の運用引き継ぎは、導入時の計画書と共通の管理票へまとめ、導入担当と運用担当の抜けを防ぎます。
予算が限られる場合の着手範囲
Q：CASBやDLPの新規導入予算がない場合、何から始めますか？
A：承認サービス、会社ID、入力可否の一枚資料、退職時の停止、事故窓口を先に整えます。既存の経費・ID・プロキシ記録から利用台帳を作り、送信内容を検査できない環境では扱うデータを公開情報へ限定します。
API利用と法人プランの許可基準
Q：API経由で利用すれば、セキュリティリスクはなくなりますか？
A：なくなりません。API契約の条件に加え、自社アプリの認可、秘密情報管理、ログ、利用量制限、停止を実装し、動作試験を通した範囲だけ接続します。
プロンプト監視の適用範囲
Q：CASBを導入すれば、プロンプトをすべて確認できますか？
A：対象サービスとの連携、TLS復号、端末管理などの構成によって、検査できる範囲は変わります。まず管理端末の対象経路で入力・添付・遮断を試験し、取得できない経路は監視対象として扱わず、アクセス条件と入力制限で補います。
PoCの検証期間と担当体制
Q：PoCの期間と体制は、どのように決めますか？
A：既存の承認環境で一業務を試す場合は、前述の4週間の計画例を使い、通常業務、権限、攻撃入力、停止・復旧を一巡させます。業務責任者、データ所有者、技術担当、評価担当を割り当て、API開発や文書整理が必要なら、その期間を別に加えます。
コーディングAIの許可基準
Q：開発者向けのコーディング支援AIは、何を満たせば許可できますか？
A：対象コードの送信条件、会社管理の利用者、秘密情報の除外、外部接続、監査を審査したうえで、許可するリポジトリを限定します。生成コードは人のレビューと脆弱性・依存関係・秘密情報・ライセンスの検査を通し、本番反映は既存の変更管理で承認します。
エージェント接続前の最低条件
Q：AIエージェントを業務システムへ接続する際、何を最初に実装しますか？
A：読み取りと更新の資格情報を分離し、更新・削除・社外送信は実行前に認可と承認を通します。実行履歴、件数上限、トークン失効、処理停止を検証できるまでは、読み取りまたは下書き作成に用途を限定します。
RAGの認証連携と権限越境
Q：Active Directoryと連携すれば、RAGの権限越境を防げますか？
A：認証連携だけでは防げません。元文書のACL、検索前フィルター、取得後の再認可、異動・削除の反映を実装し、権限の異なる検証用IDで検索結果と引用まで試験します。
まとめ
生成AIのセキュリティ対策は、利用中のサービスと入力データを把握し、会社が管理できる経路へ集めるところから始めます。明日はまず、経費・ID・プロキシの記録を使ってAI利用台帳を作り、管理責任者と入力可否を埋めます。
その後、DLPの送信制御とSIEM監視を企業ガイドラインへ結び付けます。RAGは権限継承と削除反映、AIエージェントは資格情報の分離と停止、開発支援AIは生成コードの検査を試し、担当者が運用できる範囲だけ本番へ進めます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
