Governance
AIガバナンス｜承認・権限・監査ログでAIを管理する
社内AIを本番業務に使うには、回答品質だけでなく、誰の権限で何を参照し、誰が承認し、どの結果が使われたのかを説明できる必要があります。AGTOは人が管理できるAI運用を前提にしています。
Before
AIガバナンスで起きやすい課題
AIが見てよい範囲を説明できない
部署やロールごとの参照権限を決めないまま接続すると、情報管理が曖昧になります。
重要操作の承認基準がない
回答、スキル変更、通知、外部書き込みのリスクを分けないと、過剰自動化になります。
あとから判断経路を追えない
誰が何を承認し、どのスキルが使われたかを追えないと、本番運用に進めません。
Solution
権限、承認、監査ログを、AI運用の前提にする
AGTOはAIを本番業務に組み込む前に、参照範囲、承認Tier、監査ログ、例外処理を設計します。
ここで確認すること
AGTOの統制ポイントを、導入時に判断しやすい単位に分けて整理します。
権限に基づいて参照範囲を制御する
AIが便利でも、見てはいけない情報を参照してはいけません。AGTOではユーザーやテナントの権限を前提に、扱う情報の範囲を設計します。
HITLで重要な判断を確認する
回答、スキル化、Routine実行など、業務リスクがある場面では人の確認を挟みます。AIを止めるためではなく、安全に業務へ反映するための仕組みです。
監査ログで説明可能にする
誰が何を変更し、どのスキルが使われ、どの承認を経て業務に使われたかを追跡します。ログは監査だけでなく改善の材料にもなります。
Workflow
統制設計の進め方
参照してよい情報を決め、承認が必要な操作を分け、ログを改善に使います。
参照してよい情報を決める
接続データ、部署、ユーザー権限を整理します。
承認が必要な操作を分ける
回答、スキル変更、通知、レポートなどのリスクを分類します。
ログを運用改善に使う
例外、誤回答、承認待ちを見直し、ルールを更新します。
Scope
AIを動かす前に、統制する範囲を決める
AIガバナンスは導入後の監査だけではなく、参照権限、承認、ログ、例外処理を先に決める設計です。
できること
参照範囲をロールで分ける
ユーザー、部署、テナントごとにAIが扱う情報を設計します。
操作リスクで承認Tierを分ける
回答、スキル変更、通知、外部書き込みを分けて扱います。
監査ログを改善に使う
誰が何を承認したかを後から説明できる状態にします。
例外操作を制限する
高リスク操作は承認必須または禁止として扱います。
できないこと
権限外参照を許可しない
便利さを優先して見てはいけない情報を読ませません。
全操作を同じ承認にしない
低リスクと高リスクの確認負荷を分けます。
ログなしで本番化しない
判断経路を追えない運用は避けます。
個人情報や除外データを曖昧にしない
AIに見せない情報を先に定義します。
Design detail
ロール別の権限マトリクス例
AIガバナンスは方針だけでは運用できません。誰がどの情報を参照し、どこまで操作でき、誰が承認するかをロールごとに表に落とします。
| ロール | 参照できる範囲 | できる操作 | 承認権限 |
|---|---|---|---|
| 一般メンバー | 自チームの公開ナレッジ | 質問・回答候補の起票 | なし |
| チャネル管理者 | 自チャネルの資料とスキル | スキル承認、Routine設定 | 自チャネル内 |
| テナント管理者 | 全社ナレッジと監査ログ | 権限設計、除外データ設定 | 全社 |
| 監査担当 | 監査ログ（読み取り専用） | ログ閲覧、エクスポート | なし |
Design detail
HITL（人の承認）のTier設計
すべてを止めるのではなく、操作リスクに応じて承認の強さを分けます。学習が浅い段階は承認を厚くし、承認実績が積み上がるほど自動化できる範囲を広げます。
| Tier | 操作の例 | 承認 |
|---|---|---|
| Tier 0（自動） | 参照元つきの一次回答、要約 | 承認不要、ログのみ |
| Tier 1（確認推奨） | 回答候補のスキル化、標準手順への昇格 | レビュー担当の承認 |
| Tier 2（承認必須） | 外部システムへの書き込み、通知の一斉配信 | 承認者の明示承認とログ |
| Tier 3（制限） | 高リスク操作、除外データへのアクセス | 原則禁止。例外はホワイトリストで管理 |
Design detail
監査ログに残す項目例
あとから説明できるログにするには、利用量だけでは足りません。誰が、何を見て、なぜ提案し、どこまで実行したかを再構成できる粒度で残します。
| 項目 | 記録する内容 | 確認できること |
|---|---|---|
| 実行者・承認者 | 依頼者、レビュー担当、承認者 | 責任範囲と承認経路 |
| 操作種別 | 回答、スキル変更、Routine実行、通知、外部書き込み | どの業務操作が行われたか |
| 対象 | スキルID、チャネル、資料、外部システム | 影響範囲 |
| 参照データ・変更差分 | 参照元、生成理由、修正前後 | なぜその提案になったか |
| 実行結果・コスト・時刻 | 成功/失敗、失敗理由、利用コスト、タイムスタンプ | 効果と運用負荷 |
Operation image
管理者が統制し、現場が安全に使える状態を整える
権限、承認、ログを分け、AIに任せてよい範囲を段階的に広げます。
人が管理できる前提でAIを運用する
人の承認、権限、監査ログを前提に、任せる範囲を段階的に広げます。
操作リスクに応じて、承認の強さをTierで設計します。
業務の流れ、承認ポイント、再利用の流れを具体的に確認します。
Metrics
トライアルで測る統制指標
実測値を載せる前段階では、測定対象を明示します。承認待ちの滞留、スキル承認率、差し戻し理由、監査ログから再構成できた操作数を確認し、本番展開の判断材料にします。
承認待ちの滞留
承認フローが業務を止めていないか
スキル承認率
レビューを通過した割合
差し戻し理由
却下の理由を記録・分類できているか
監査ログ再構成
ログから操作を後追いできるか
例外操作の件数
高リスク操作の発生頻度
Trial
2週間で統制設計の運用負荷を見る
データ範囲、承認Tier、監査ログ項目を小さく検証します。
参照してよい情報を決める
接続データ、部署、ユーザー権限を整理します。
承認が必要な操作を分ける
回答、スキル変更、通知、レポートなどのリスクを分類します。
ログを運用改善に使う
例外、誤回答、承認待ちを見直し、ルールを更新します。
FAQ
よくあるご質問
承認範囲、監査ログ、部門別権限、個人情報の扱いなどを確認します。
全回答に承認が必要ですか？
必ずしも必要ではありません。情報の重要度や業務リスクに応じて、承認が必要な範囲を分けます。
監査ログには何を残しますか？
利用、スキル変更、承認、実行結果など、あとから説明・改善に使う情報を残します。
部門ごとに権限を分けられますか？
分ける前提で設計します。対象データとユーザー範囲を整理して2週間無料トライアルに反映します。
除外したい情報や個人情報はどう扱いますか？
2週間無料トライアル前に対象データ、除外データ、参照権限、保持・削除ルールを分けます。AIに見せない情報を先に定義し、承認ログで運用を確認します。
外部システムへの書き込みも自動化できますか？
高リスク操作は承認必須として扱います。通知の一斉配信、CRM更新、外部システムへの書き込みなどは、承認者とログ項目を決めて段階的に検証します。
認証や保管地域などの要件は確認できますか？
確認できます。認証、保管地域、契約上のデータ取り扱いは導入前に個別確認し、未確定の項目は2週間無料トライアル範囲から外して進めます。
Next Step
AIを本番業務で運用するための統制を設計する
データ範囲、承認ルール、監査ログの要件を整理し、2週間無料トライアルに落とし込めます。