生成AIの利用ルールは整備した。それなのに、AIエージェント導入の稟議が上がってきた途端に判断がつかなくなる——最近この相談が目立って増えています。

理由は明快です。既存のAI利用ルールは「人がAIに指示し、出力を人が確認してから使う」ことを前提に組まれています。一方でエージェントは、目的を与えられた後は人の目を介さずに手順を決め、社内システムや外部サービスを自分で操作します。統制すべき対象が「人の使い方」から「エージェントの行動」へ移るため、従来のルールがそのままでは効きません。

本記事では、IT企画・情報システム部門が何を決めておくべきかを整理します。生成AI利用そのものの統制はAIガバナンスの実装で扱っているため、ここではエージェント固有の論点に絞ります。

課題 ― 稟議に「安全です」と書いてあるが、根拠が書かれていない

導入部門は「ガイドラインを守って使います」と申請する。しかしそこには、エージェントがどの権限で何を操作するのか、どこまで自動で実行させるのかが書かれていない。情報システム部門は止める根拠も通す根拠も持てず、「とりあえず保留」か「よく分からないまま承認」に落ち着きます。これは担当者の力量の問題ではなく、申請側に何を書かせるかが決まっていないという設計の問題です。

なぜ従来の統制が空振りするのか

原因は、既存の統制が暗黙に置いている三つの前提が崩れることにあります。

  • 主体が人である前提：アカウントと権限は人に紐づけて管理されてきました。エージェントは人ではないのに、人と同等以上の権限で動きます
  • 画面の前に人がいる前提：都度確認や目視チェックは、人が操作している間しか成立しません。エージェントは背後で処理を進めます
  • 権限の出どころが辿れる前提：エージェントが別のツールやエージェントを呼び出すと権限が連鎖し、最初に誰が何を許可したのかが曖昧になります

外部環境もこの認識に追いついています。2026年3月に公表された総務省・経済産業省の「AI事業者ガイドライン」第1.2版ではAIエージェントが記述の対象に加えられ、重要な判断に人間を介在させること（ヒューマン・イン・ザ・ループ）やログの記録・保存が求められています。リスクの発生源が、入力時の情報漏えいからAI自身が実行する処理へ移りつつあるという指摘です。

統制の対象を四つに置き直す

エージェントを前提にすると、決めるべきことは次の四点に整理できます。

論点 決めること 成果物
所在と権限 どのエージェントが動いており、どのIDでどの権限を持つか エージェント台帳、権限一覧
自律の境界 どこまで自律実行させ、どこから人の承認を挟むか 承認基準、承認フロー
外部との接点 どの外部データ・ツールに接続してよいか 接続許可リスト、検証ルール
記録と停止 何をしたかを追跡でき、異常時に誰が止められるか ログ要件、停止手順と権限者

要点は、エージェントを人のアカウントの延長ではなく、独立した管理対象として台帳に載せることです。棚卸しの対象になっていないものは、権限の見直しも停止の判断もできません。委託先やクラウドを重要度で仕分けて統制するサードパーティリスク管理と地続きの発想です。

自律の境界をどこに引くか

「どこから人の承認を挟むか」は、次の四つの軸で判断すると現場で運用できます。

  • 不可逆性：やり直せる操作か、取り消せない操作か
  • 外部への影響：社内で完結するか、社外へデータや意思表示が出るか
  • 金額の規模：支払・発注・契約に関わるか
  • 情報の機微度：扱うデータの区分は何か

可逆で社内に閉じた読み取り・整理・下書きは任せてよい領域です。外部へのデータ送信、契約・支払に関わる処理、本番データの変更は、人の承認を前置きすべき領域です。注意したいのは、承認は多いほど安全になるわけではないという点です。全件に承認を挟むと現場は内容を見ずに通すようになり、記録上は統制が効いているのに実質は無審査という状態に陥ります。線を引く目的は、承認を絞って一件あたりの審査を実質化することにあります。

進め方 ― 稼働前の申請と稼働後の棚卸し

  1. 棚卸し：動いている、あるいは検討中のエージェントを洗い出し、台帳の初版を作ります
  2. 申請様式の整備：対象業務、操作範囲、接続先、自律実行の範囲、承認者、ログの保存方法を書かせる様式を定め、稼働前の承認を必須にします
  3. 限定稼働：影響の小さい業務から、権限と接続先を絞って動かし、ログを見ながら任せる範囲を広げます
  4. 定期棚卸し：異動や施策終了で使われなくなったエージェントの権限を剥奪します。放置された権限が最も危険です

よくある失敗と回避策

  • 人のアカウントを流用する：誰の操作か区別できず、監査もできません。→ エージェントごとに専用のIDを発行し、台帳と紐づけます
  • 権限を広く取りすぎる：事故時の影響範囲が読めなくなります。→ 業務に必要な最小限から始めます
  • 外部から取り込んだ情報を信用する：外部のデータや文書に紛れ込んだ指示をエージェントが実行してしまう経路があります。→ 外部入力は信用しない前提で、実行可能な操作を絞ります
  • 導入部門任せにする：部門ごとに判断が分かれ、全社では統制が存在しない状態になります。→ IT企画やPMOが横断的な受け皿になり、基準と台帳を一元管理します

FAQ

Q. 既存のAIガバナンス方針を作り直す必要がありますか。

作り直す必要はありません。方針は活かしたうえで、エージェント向けに「台帳」「権限」「自律の境界」「停止手順」を追記するのが現実的です。ゼロから書き換えると公開が遅れ、その間に統制外の導入が進みます。

Q. 小規模な組織でも台帳は必要ですか。

必要です。件数が少ないうちは表計算ソフト一枚で足りますが、「何が動いていて、どの権限を持つか」を一覧できる状態は規模を問わず前提になります。数が増えてから遡って作るほうが高コストです。

Q. 推進の主体はどの部門が担うべきですか。

基準づくりと台帳の管理はIT企画・情報システム部門やPMOが担い、業務ごとの承認基準は導入部門と合意するのが実務的です。最終的な説明責任は経営が持つ形に整えます。

まとめ

AIエージェントのガバナンスは、新しい規制対応というより、統制の対象を「人の使い方」から「エージェントの行動」へ移す作業です。所在と権限を台帳で押さえ、自律の境界を基準で引き、外部との接点を絞り、記録と停止を用意する。この四点が揃えば、稟議は主張ではなく確認可能な事実に基づいて判断できるようになります。

株式会社PMOスクエアは、PMO・IT企画・エンタープライズアーキテクチャの知見をもとに、AI活用の統制設計から体制構築・運用定着までを支援しています。サービス紹介や導入事例もあわせてご覧ください。個別のご相談はお問い合わせから承っています。

参考資料