AIエージェントの社内規程の作り方｜権限・ログ・責任分界の決め方
目次
目次
AIエージェントの社内規程の作り方｜権限・ログ・責任分界の決め方
結論：規程作成では「禁止を増やす」よりも、ユースケース単位で「何を・どの条件で・自動実行できるか」を定義し、権限・ログ・責任を一体で設計することが最重要です。
AIエージェントに生成AIとは異なる統制が必要な理由
要約：生成AIは入出力の管理が中心ですが、AIエージェントは外部システムの操作を行うため、権限・実行上限・停止・ログ・責任分界のルールが不可欠です。
- 生成AIも個人情報や機密データの取り扱い統制が必要だが、AIエージェントは「更新・削除・発注・決済・権限変更」といった業務操作が加わる点が違い。
- 既存の生成AIガイドラインへ追記で済む場合と、独立した細則／規程が望ましい場合がある。判断は用途・影響範囲・複数部門横断性で決める。
規程化の前に整理する5項目
要約：ユースケース、利用者、参照データ、外部連携、実行範囲を明確化してから規程設計を始める。
- 対象業務（要約／送信／更新／発注等）を部門別に列挙する。
- 利用者区分（一般・管理者・委託先）と利用対象システムを明示する。
- 参照・処理するデータの機密性・個人情報の有無を評価する。
- 外部APIやクラウド、SaaSとの連携範囲を洗い出す。
- 自動実行の範囲（下書き→承認→自動送信等）を定義する。
社内規程のひな形・章立て（必須）
要約：長期的な原則は基本規程、可変要素は細則、個別情報は申請書や台帳へ分ける。
第1章 総則（条文例）
目的：本規程は、AIエージェントの安全かつ説明可能な利用を確保するための基本原則を定める。
適用範囲：本社および事業所が導入する全てのAIエージェントに適用する。
第2章 管理体制（条文例）
各AIエージェントには社内責任者（オーナー）を置き、運用状況の管理・本番移行の承認・定期点検を行うものとする。RACIは別表に定める。
第3章 導入申請・リスク審査（条文例）
導入前に申請書を提出し、リスク評価（機密性、可逆性、金銭影響、法令影響等）に基づく審査を経て本番移行を承認する。
第4章 権限・承認（条文例）
AIの操作権限は最小権限の原則とし、削除・発注・決済・権限変更を伴う操作は原則事前承認を要する。ただし、事前に定義された条件（送信先・文面・金額上限等）を満たす定型処理は自動化を許可できる。
第5章 ログ・監視（条文例）
指示、参照データ、承認、実行結果をトレースIDで紐づけて記録し、監査と事故調査が可能な形で保管する。保存期間はログ種別ごとに法令・契約・監査要件を踏まえて定める。
第6章 変更管理（条文例）
モデル変更、データソース追加、権限拡大等は変更申請を行い、再審査のうえ承認を受けるものとする。
第7章 インシデント対応（条文例）
異常検知時は直ちに停止し、影響範囲の特定→関係部門への第一報→復旧／ロールバック→原因分析→再稼働審査の流れで対応する。
第8章 委託先・ベンダー管理（条文例）
ベンダー契約ではデータ利用目的、学習利用の有無、ログ提供範囲、インシデント通知手続き、監査権等を明示することを必須とする。
第9章 教育・例外・見直し（条文例）
利用者教育を定期実施し、例外申請は理由・代替統制・期限を明記のうえ承認する。規程は定期的に見直す。
操作分類と権限レベルの決め方
要約：操作を7分類し、影響度と可逆性で権限レベルを段階化する。
操作の7分類：読み取り／作成／更新／外部送信・公開／削除／発注・決済／アカウント・権限変更
レベル | 許可する操作 | 統制の原則 |
|---|---|---|
L0 | 回答・提案のみ | 実行は人 |
L1 | 限定データの読み取り | 参照範囲を制限 |
L2 | 下書き・更新案の作成 | 人の確認後に反映 |
L3 | 限定的な更新・送信（事前承認済み条件） | 送信先／件数／金額などの条件付きで自動実行を許可 |
L4 | 削除・発注・決済・権限変更 | 原則として事前承認 |
L5 | 横断的自律実行 | 個別審査・継続監視 |
注：L3での自動送信は「事前に定義した条件を満たす定型処理」に限定し、条件外は事前承認を必要とする旨を規程で明記すること。
認証方式：AI専用ID、サービスアカウント、ワークロードID、または委任認証など、システム要件に合わせて「実行主体を識別できる方式」を採用する（共有個人アカウントは禁止）。
ログ設計と保存方針
要約：入力→参照→承認→実行→結果をトレースIDで紐付け、改ざん検知と閲覧権限を定める。
- 必須項目：実行主体、時刻（指示・承認・実行）、入力内容、参照元、モデル/プロンプト版、呼び出しAPI、承認履歴、操作内容、結果、エラー
- 保存期間：法令・契約・監査要件・事故発覚可能期間・個人情報の有無を勘案してログ種別ごとに決定する（以下は例示で義務ではありません）—操作ログ（社内例：最長の監査要件に合わせる）、デバッグログ（短期）等。
- 改ざん防止：追記型ストレージ、SIEM連携、監査ログの別保管等。
- 個人情報：可能な限りマスキング／匿名加工／暗号化し、閲覧は必要最小限に限定する。
責任分界（RACI）と法的責任の区別
要約：社内の役割分担はRACIで明確にするが、法的責任は適用法令・契約・事故原因により個別判断する。
RACIは社内の実務責任・承認フローを示す道具です。条文例では「社内責任者（オーナー）を置く」と定め、オーナーの職務（利用目的妥当性、本番承認、定期点検、緊急停止判断等）を列記してください。法的責任や損害賠償責任の帰属は契約条項・法令に基づいて別途定めます。
例外申請テンプレ（短縮）
要約：例外は理由・対象・代替統制・期限・承認者を明示して臨時許可する。
例外申請書（要旨）
- 申請者：
- エージェント名：
- 例外対象項目：
- 例外理由：
- 代替統制（監視・ログ増強等）：
- 適用期間（開始／終了）：
- 承認者：
インシデント発生時の停止・報告フロー
要約：検知→停止→影響範囲→第一報→回復→原因分析→再稼働審査が基本フロー。
- 異常検知（アラート/ユーザ通報）
- 当該エージェントの即時停止（自動停止条件も含む）
- 認証情報の一時無効化（必要時）
- 影響範囲（データ・顧客・決済等）の暫定把握
- 関係部門への第一報（所定の連絡網に従う）
- 可能なら実行の取消し／ロールバック／通知
- 原因分析・責任分界の確認
- 再発防止策と再稼働審査
注：インシデント通知期限（例：契約上72時間等）は契約・法令ベースで定める。一般文言で「重大インシデントは速やかに第一報を行い、契約に定めた期限内に追報する」と規程化するのが無難です。
参考（ガイドライン・規格）
- 総務省・経済産業省のAI関連ガイドライン（各省の最新公表資料を参照）
- 個人情報保護委員会の生成AI・個人情報に関する資料
- NIST AI Risk Management Framework
- ISO/IEC 42001（AIマネジメントシステム）概要
FAQ（抜粋）
Q：既存の生成AIガイドラインに追記で良いか？
A：読み取りや下書きのみで運用範囲が限定的なら追記で対応可能。外部送信・更新・決済を含む場合は細則や独立規程を検討してください。
Q：ログはすべて長期保存すべきか？
A：保存目的を明確にし、法令や契約上の義務、監査・事故調査要件に応じて最短期間を設定してください。個人情報は短期保存・マスキングが望ましいです。
Q：RACIで「オーナー」を置くと法的責任になる？
A：RACIは社内の実務責任を明確にするもので、法的責任は別途契約・法令により判断します。規程ではこの点を明記しておくと良いです。
まとめ・次のアクション
- まず部門別にユースケースを洗い出し、リスク評価表を作成する。
- 操作分類ごとに権限レベルを決め、承認ポイントとログ要件を設計する。
- 各エージェントにオーナーを定め、RACIで役割を明示する（法的責任との区別を明記）。
- 規程（基本）・細則・申請書・台帳・本番チェックリストを揃え、法務・情シスと協議のうえ運用を開始する。
（注）本稿は実務ガイドです。法令解釈、個人情報保護、契約上の責任判断は社内法務や外部専門家と必ず確認してください。
