AIエージェントのガバナンスとは？権限・実行前確認・監査ログの設計
AIエージェントが本当に怖いのは、答えが間違うことだけではありません。社内ファイル、CRM、チャット、ドライブのような実データに接続し、下書きだけでなく更新や送信まで行えるようになると、事故の形そのものが変わります。
AIエージェントのガバナンスとは、エージェントに何を読ませ、何を提案させ、何を更新・送信させるかを段階で分け、段階ごとに「実行の直前に何を確かめるか」と「ログに何を必ず残すか」、そして「誰が止めるか」を決めることです。読み取りと提案は自動で通しやすく、更新は対象と差分の確認、送信は宛先と内容の人による承認を前提にします。こうした実行前の確認は、2026年7月3日にシンガポール金融管理局（MAS）が公表したSAFRでも重視されています。
本記事のポイント
- AIエージェントのガバナンスは、読み取り・提案・更新・送信の段階ごとに、実行前の確認、人へ戻す条件、ログの必須項目を決める仕事です。
- 更新は対象・差分・件数上限を、送信は宛先・内容・承認者を実行直前に確かめ、変更前後の値と承認記録をログに残します。
- 本番接続の承認、テストと本番の認証情報の分離、止める担当者の明記まで決めると、モデルに問題がなくても起きる事故を防げます。
AIエージェントのガバナンスは「権限の強さ」と「止める位置」を決める仕事
対話型AIでは、誤答や情報漏えいが主な論点でした。AIエージェントではそこに加えて、実行権限、接続先、更新履歴、例外時の停止条件が論点になります。
特に重要なのは、読み取り、提案、更新、送信の4段階を一気に許可しないことです。営業やマーケの現場でAIを使うときも、導入手順 や 運用定着 を見ると、事故が少ないのは段階的な権限設計をしているケースです。
接続先の管理が抜けると、モデルに問題がなくても事故が起きます。たとえば、テスト用と本番用の接続設定が混在したまま自動化を動かすと、検証中の文面が本番の顧客へ送られるおそれがあります。本番環境への接続には別の承認を必須にし、テストと本番で認証情報を分けておくと、この種の事故を防げます。
| 統制ポイント | 決めること | 見落としやすい点 |
|---|---|---|
| 権限 | 読むだけか、更新まで許すか | 書き込み権限を安易に広げがち |
| 接続先 | どのSaaSとどの環境をつなぐか | テスト環境と本番環境の分離不足 |
| 記録 | 何をログとして残すか | 入力データと出力だけで満足しがち |
| 承認 | どの操作で人が確認するか | 送信前確認の抜け漏れ |
| 責任分界 | 誰が設計し、誰が運用するか | 利用部門と情シスの役割が曖昧 |
権限の段階ごとの実行前確認とログの必須項目
権限を段階に分けたら、段階ごとに実行の直前で確かめることと、あとから説明できるように残すログを対応させます。上の段階ほど確認とログを重くします。ロールごとにどの段階まで許すかは権限設計で決めます。
| 権限の段階 | 実行前に確かめること | 止める・人へ戻す条件 | ログに必ず残す項目 |
|---|---|---|---|
| 読み取り | 依頼者がそのデータを見られるか（エージェントの権限ではなく依頼者の権限で判定） | 依頼者の閲覧範囲外のデータが含まれる | 依頼者、参照したデータの所在、日時 |
| 提案（下書き） | 根拠にしたデータが最新か、出力先が下書き領域か | 根拠が見つからない、出力先が公開・共有領域 | 依頼内容、根拠にしたデータ、出力した下書き |
| 更新 | 対象レコード、変更前後の差分、件数が事前に決めた上限内か | 上限件数を超える、金額やステージなど重要項目を変える、本番環境への初回接続 | 対象、変更前の値、変更後の値、承認者（必要な場合）、実行結果 |
| 送信・公開 | 宛先、宛先数、本文、添付、送信元アカウント | 社外宛て、宛先数が上限超、価格・契約条件・個人情報を含む | 宛先、送信内容、承認者、承認日時、送信結果 |
ログは、モデル内部の動きよりも「誰の依頼で、どのデータを根拠に、何を変え、誰が承認したか」という業務上の行為を中心に残します。項目の雛形は監査ログテンプレートにまとめています。
実行前チェックポイントをruntimeに置く
AIエージェントが外部送信、CRM更新、支払い、権限変更のような操作に進む場合、承認書を作るだけでは足りません。操作が走る直前に、予定された行動が許可範囲、業務ポリシー、リスク上限に収まっているかを機械的に確認し、確認結果を証跡として残す必要があります。
Monetary Authority of Singapore が公表した SAFR は金融領域の枠組みですが、BtoBの営業・マーケティング自動化にも応用できます。重要なのは、AIエージェントが「何をしようとしているか」を実行前に構造化し、承認、検証、記録を同じ流れに置くことです。
| チェックポイント | 確認すること | 営業・マーケでの例 |
|---|---|---|
| 意図 | 依頼された目的と操作内容が一致しているか | 商談フォローの下書きなのに一斉配信へ広がっていないか |
| 権限 | AIが読めるデータ、書ける項目、送信できる範囲が許可内か | 担当外の顧客リストや機密案件を更新しないか |
| リスク上限 | 金額、件数、対象顧客、公開範囲が事前に決めた上限内か | 承認なしで高額案件のステージや見込金額を変えないか |
| 証跡 | 提案行動、根拠、承認者、実行結果をあとから追えるか | CRM更新前後の差分と承認ログを残せるか |
この考え方を入れると、Human-in-the-loopは「最後に人が読む」だけではなくなります。AIが実行しようとする操作を構造化し、危険度が低いものは自動通過、高いものは承認待ち、禁止条件に触れるものは停止、という実行時の分岐にできます。
エージェント間通信では信頼設計を5つの問いに分ける
1つのAIエージェントを社内システムへ接続する場合と、複数企業のエージェント同士が見積もり、契約条件、在庫、配送などを調整する場合では、必要な統制が異なります。後者では、自社の権限だけでなく、相手のエージェントが誰を代理し、どこまで約束できるかを検証できなければなりません。
Salesforceは2026年7月10日の AI Trust Architectureに関する公式解説 で、エージェント間通信の信頼設計を、ルールを補う共通基準、持続するIDと評判、スクリプトより境界、構造化された説明責任、リスクに応じたエスカレーションの5点に整理しています。これは完成した業界標準ではなく、企業がA2A連携を評価するための設計フレームとして使うのが適切です。
| 信頼設計の問い | 実装・運用で確認すること | 不足した場合のリスク |
|---|---|---|
| 共通基準 | 禁止ルールだけでなく、交渉品質や妥当性を何で評価するか | 形式上は違反しなくても、不公平・不適切な判断が残る |
| 検証可能なID | エージェント、運用企業、委任された権限、対応履歴を結び付けられるか | 誰の代理か分からず、相手の権限や信頼性を評価できない |
| 行動境界 | 扱えるデータ、金額、契約条件、相手先、禁止操作を範囲として定義できるか | 想定外の状況で、細かな手順をすり抜けて行動範囲が広がる |
| 追跡可能な責任 | 判断根拠、参照情報、承認者、実行結果を人と組織へ遡れるか | 異議や事故が起きても、説明・差し戻し・是正ができない |
| 段階的エスカレーション | 金額、法務、個人情報、例外条件に応じて停止・承認へ切り替えるか | 止めすぎて自動化が機能しないか、止まらず重大な約束を行う |
実務では、A2AやMCPなどの通信方式を選ぶ前に、この5問へ回答します。特に、Agent Cardのような能力・権限情報があっても、それだけで信頼が完成するわけではありません。発行主体の確認、失効、権限変更、取引履歴、異議申立て、最終承認をどこで管理するかまで決めて初めて、企業間で説明できる統制になります。
なぜ今「control gap」が問題になるのか
AIエージェントの統制が難しくなる理由は、モデルの性能が上がったこと自体ではありません。現場の部門が、CRM、Drive、Chat、メール、各種SaaSに対して、小さな自動化やエージェント実装を先に進め、ITや情シスが全体像を追い切れなくなることが本質です。2026年6月8日に IBM が公表した tech CxO 向け調査では、技術責任者の3分の2が、自分で十分に制御できないAIの責任を負っている とされ、70%が「各部門の技術導入はITが追跡できる速度を上回っている」 と回答しています。
さらに同調査では、77%がAI採用は現在のガバナンス能力を上回っている と回答し、今後1年で想定されるAIエージェント展開に完全に準備できているのは11% に留まっています。ここで重要なのは、「AIを導入しているか」よりも「誰が、どの接続先で、どの権限まで持ち、停止権をどこに置いているか」が見えなくなることです。ガバナンスの論点は、技術的安全性だけでなく、責任の所在と可視性の維持に移っています。
| IBM調査の示唆 | 数値 | ガバナンス上の意味 |
|---|---|---|
| 十分に制御できないAIの責任を負っている技術責任者 | 3分の2 | 責任だけ先に来て、可視性と統制が追いついていない |
| 部門側の技術導入速度がITの追跡速度を上回る | 70% | シャドー運用や部分最適のエージェント実装が増えやすい |
| AI採用が現在のガバナンス能力を上回っている組織 | 77% | 既存の承認、ログ、権限設計では追い切れない |
| AIエージェント展開に完全に準備できている組織 | 11% | PoCから本番へ移る前に統制設計を先に置く必要がある |
この数字は、ガバナンスを後工程に置くと間に合わないことを示しています。PoCで便利さを確認してから権限やログを考えるのではなく、最初から「何が見えるか」「何を止められるか」を決めておく方が、本番化したあとにやり直しが少なくなります。
生成AIガバナンスでは5つの役割を分ける
ECIS 2026 Proceedings に掲載された 生成AIガバナンス研究では、8組織の実践分析から、生成AIを統制する役割を5つに分けて整理しています。重要なのは、AI導入を「エンジニアが作り、事業部が使う」だけで見ないことです。AIが業務知識、顧客データ、規程、現場判断に深く入り込むほど、技術側だけでは統制できなくなります。
| 役割 | 主に持つもの | AIエージェント運用での確認点 |
|---|---|---|
| 技術オーナー | モデル、接続基盤、権限、ログ | どの環境に接続し、どの操作を許すか |
| 業務オーナー | 業務目的、KPI、優先順位 | 自動化する業務と、人が持つ判断を分ける |
| 知識オーナー | 正本データ、業務知識、ナレッジ更新 | 古い手順書や誤ったFAQを根拠にしない |
| リスク・コンプライアンス | 規程、法務、セキュリティ、監査 | 禁止事項、保持、説明責任、例外承認を定義する |
| エンドユーザー | 現場の例外、使い勝手、フィードバック | 実務に合わない承認やログ設計を早めに直す |
この役割分担で見ると、ガバナンスの重心は「事業部がエンジニアにAIを作ってもらう」から、「エンジニアが業務知識、リスク判断、現場フィードバックを頼らないと安全に作れない」へ移ります。AIエージェントをCRM、Drive、メール、チャットへ接続するほど、この依存関係は強くなります。
ADLCは「作った後の責任」を分けるフレームとして使う
Salesforceは2026年7月7日の記事で、AIエージェント運用では構築後の監視、劣化検知、改善判断まで含めた Agent Development Lifecycle が必要だと説明しています。ここで重要なのは、AIエージェントは通常のシステム障害のようにエラーを出して止まるとは限らないことです。ナレッジベースが古くなる、顧客の質問傾向が変わる、プロンプトでは想定していない例外が増える、といった形で静かに精度が落ちます。
そのため、ガバナンス体制では「誰が作ったか」だけでなく、「誰が成功基準を決め、誰がテストし、誰が本番後の会話や失敗傾向を見て、誰が改善を承認するか」を分けておく必要があります。既存のQA、プロダクトマネージャー、情シス、業務責任者で兼務しても構いませんが、役割名だけでなく判断責任を明文化することが重要です。
| ADLCの段階 | 置くべき責任 | 確認すること |
|---|---|---|
| Plan | 事業成果と成功基準を決める | 何を達成したら合格か、誤回答率や差し戻し率の上限はどこか |
| Build | 接続先、指示、権限を設計する | 本番データ、CRM更新、外部送信の境界が分かれているか |
| Test / Evaluate | 失敗モードを検証する | 想定質問、例外質問、古いナレッジ、権限外要求で崩れないか |
| Observe | 本番後の劣化を見つける | 会話ログ、差し戻し、ユーザーの言い換え、未解決率を定例で見るか |
| Improve | 改善と再評価を回す | プロンプト変更、ナレッジ更新、権限変更のどれで直すかを判断する |
営業・マーケティング領域では、AIエージェントがCRM、メール、商談メモ、資料、FAQにまたがって動きます。ADLCの発想を入れると、「担当者が便利だから使う」段階から、「成果基準、監視、改善責任まで含めて運用する」段階へ移せます。
組織の型はAI Business Unit、AI Squads、AI Spineで考える
同研究では、組織内の調整メカニズムとして AI Business Unit、AI Squads、AI Spine の3つも示されています。自社でどれを採るかは、AI活用の成熟度とリスクの大きさで変わります。
| 型 | 向く状態 | 注意点 |
|---|---|---|
| AI Business Unit | AI専門組織が標準基盤や共通ルールを作る段階 | 現場から遠いと、使われない統制になりやすい |
| AI Squads | 業務ごとに小さな横断チームでPoCから運用まで進める段階 | チームごとのルールがばらつきやすい |
| AI Spine | 全社横断の基盤、承認、ログ、ナレッジ更新を背骨として整える段階 | 中央統制が強すぎると現場改善が止まる |
AIエージェントを本番業務へ入れるなら、最初はSquads型で小さく検証し、共通化できる権限、ログ、承認、ナレッジ更新だけをSpineとして横断化するのが現実的です。すべてを中央組織に集めるより、業務ごとのスピードと全社の説明責任を両立しやすくなります。
モデル選定だけではガバナンスになりません。接続、権限、記録、承認まで決めて初めて統制になります。
ガバナンスで先に押さえるべき3つの論点
1. 接続先を業務ごとに分ける
CRM、Google Drive、社内ファイル、メールのように、接続先ごとにリスクは違います。全部まとめて一律管理するより、業務単位で接続先を棚卸しして許可範囲を決める方が事故が減ります。
2. 読み取りと書き込みを分ける
読み取りと提案から始め、更新・送信は段階的に広げます。ロール別の切り方は権限設計で扱います。
3. 承認ゲートを操作の直前に置く
レビューを最初にまとめて1回だけ行うより、送信、更新、公開の直前に止める方が実務では効きます。承認は数を増やすことより、事故コストの高い操作の直前に置くことが重要です。
ガバナンス運用で見るべき指標
ガバナンスはルールを作って終わりではありません。逸脱が減っているか、承認が詰まっていないかを継続的に見る必要があります。
| 指標 | 意味 | 見方 |
|---|---|---|
| 権限逸脱件数 | 許可外操作の発生数 | 月次で減っているかを見る |
| 承認差し戻し率 | AI成果物の再確認負荷 | 高すぎるなら運用設計を見直す |
| ログ欠損率 | 追跡不能な処理の割合 | 0に近づけることが重要 |
| 本番停止件数 | 運用中断の頻度 | 停止理由の分類が必要 |
| 例外対応時間 | 事故時の復旧負荷 | ルールが実務に合っているか分かる |
AIエージェント ガバナンスの整え方
ステップ1. 接続先と操作権限を棚卸しする
まずはAIが関わる予定のSaaS、共有ドライブ、ローカルフォルダ、メール送信先を洗い出します。そのうえで、前述の権限の段階（読み取り、提案、更新、送信）ごとに許可範囲を決めます。
ステップ2. 業務ごとの承認ゲートを定義する
顧客送信、CRM更新、公開コンテンツのように、事故コストが高い操作ではHITLを必須にします。承認者は役職名ではなく、実際に止められる人に寄せると機能しやすくなります。
ステップ3. ログ設計を先に作る
ログの必須項目は、前述の「権限の段階ごとの実行前確認とログの必須項目」の表を最低限とします。後から増やそうとすると欠損期間ができるため、PoCの段階から記録を始めます。
ステップ4. 例外時の停止フローを決める
誤送信、誤更新、誤判定が起きた場合に、誰が止め、誰が復旧し、誰へ共有するかを明文化します。停止フローがないと、小さな事故でも現場がパニックになりやすくなります。
ガバナンス設計で失敗しやすいポイント
モデル選定だけで安心してしまう
安全そうなモデルを選んでも、接続先や権限が広すぎれば事故は起きます。問題はモデル名より運用境界です。
承認フローが重すぎて現場が使わなくなる
すべての操作に同じ承認をかけると利用率が落ちます。事故コストが高い操作に絞ってゲートを置く方が定着しやすくなります。
ログを取っても見返さない
監査ログは保存するだけでは意味がありません。差し戻しや逸脱を定例で確認し、ルールへ戻す運用が必要です。
よくある質問
AIエージェントは全部禁止した方が安全ですか？
一律禁止は短期的には安全でも、現場がシャドー運用に流れることがあります。禁止ではなく、接続先と権限を設計する方が現実的です。
承認は毎回必要ですか？
毎回ではなく、事故コストが高い操作に絞って置く方が機能します。閲覧や下書きと、送信や更新は分けて考えるべきです。
更新や送信を自動で通してよい条件は？
対象件数や金額が事前に決めた上限内で、社外宛てでなく、価格・契約条件・個人情報を含まない操作に限ると判断しやすくなります。条件に当てはまらないものは人の承認へ戻します。
監査ログは何を残すべきですか？
依頼者、参照したデータ、変更前後の値、送信先と内容、承認者と承認日時、実行結果です。段階が上がるほど必須項目を増やします。
情シスだけでガバナンスを作れますか？
単独では難しいです。利用部門、セキュリティ、管理職が関わり、実務に沿ったルールにする必要があります。
AIガバナンスでは誰が何を担当すべきですか？
技術オーナーだけでなく、業務オーナー、知識オーナー、リスク・コンプライアンス、エンドユーザーを分けて考えます。AIエージェントが業務知識や顧客データを扱うほど、正本データ、例外判断、現場フィードバックを持つ人の関与が欠かせません。
AIエージェントの運用責任はどの段階で分けるべきですか？
計画、構築、テスト、本番評価、監視、改善の各段階で分けるべきです。特に本番後は、回答精度、ユーザーの言い換え、差し戻し、ナレッジの古さを継続的に見る担当が必要です。AIエージェントはエラーで止まらず、もっともらしい誤答を続けることがあるため、改善判断まで含めて責任者を置きます。
