富士ソフト株式会社

AIエージェントのガバナンスとは？
エージェントIDで「誰が・何を・どのデータで」を統制する仕組みを解説

公開日：2026年11月11日
TOP画

■はじめに

AIデータプラットフォームアーキテクトとして活動しているネットインテグレーション事業部の左手です。

「AIエージェントを試したいが、社内データをどこまで触らせてよいか判断できない」

「エージェントが実行した操作を、後から『誰の指示で動いたのか』と説明できるだろうか」

このような声を聞く機会が増えてきました。
2026年9月の「Snowflake World Tour Tokyo 2026」（以下、SWTT 2026）では、構想より先に実際に動くデモが披露され、全社約650の業務のうち120件でAIエージェント向けのスキル化に着手した国内事例なども紹介されました。 こうした発表から、Agentic Enterprise（定型業務はエージェントが担い、人は方向づけと意思決定に時間を使う組織）が「実践」の段階に入ったことを実感しました。

本記事では、AIエージェントのガバナンスとは何か、なぜ従来の統制では不十分なのか、そしてその中心となる「エージェントID」の考え方を、データ基盤の視点から解説します。

■執筆者

Author

左手 克明

Katsuaki Sate

ソリューションビジネスユニット ネットソリューション事業本部
ネットインテグレーション事業部 第5技術グループ ／ 担当 シニアマスター

■目次

■本文

1.AIエージェントのガバナンスとは

◆AIエージェントのガバナンスの全体像
AIエージェントとは、目標を与えると自ら計画を立て、ツールやデータにアクセスしながらタスクを実行するAIです。質問に答える従来の生成AIと異なり、エージェントは次に何をすべきかを自ら判断して動きます。例えば「先月の売上が落ちた原因を調べて」と頼むと、見るべきデータを自分で選んで分析し、結果に応じて追加の調査や担当者への報告まで進めます。
AIエージェントのガバナンスとは、こうした行動について「誰の指示で、どのエージェントが、どのデータに、何をしたか」を組織として把握し、必要に応じて制限できる状態にする取り組みです。
国内では、AIガバナンスの統一的な指針である「AI事業者ガイドライン」の第1.2版（総務省・経済産業省、2026年3月31日公表）で、AIエージェントの定義とリスクが整理され、権限の適切な設定、人間の判断の介在、操作履歴の定期的な確認が対策として示されました。

2.なぜ「人向けの統制」だけでは足りないのか

◆人のアクセスとエージェントのアクセスの違い
多くのデータ基盤には、ロールベースのアクセス制御（RBAC）やマスキング、アクセスログがすでにあります。それでもエージェントには、次の3つの理由から追加の考慮が必要です。

既定では、作成者の認証情報と権限のまま動作するエージェントも少なくありません。

エージェントは複数のツールを連鎖させながら、人よりも多くのクエリを24時間実行し続けます。ログに残るのが人のユーザー名だけでは、人の操作とエージェントの操作を区別できません。

エージェントは読み込んだ文書やWebページの内容の影響を受けるため、そこに悪意ある指示が埋め込まれていると、本来の目的から外れた操作を実行するおそれがあります（プロンプトインジェクション）。OWASP（Open Worldwide Application Security Project）が2025年12月に公開した「OWASP Top 10 for Agentic Applications for 2026」でも、IDと権限の悪用が主要リスクの一つに挙げられています。

3.ガバナンスを支える3つの柱：識別・権限・監査

◆ガバナンスを支える3つの柱
AIエージェントのガバナンスは、次の3つの柱で整理すると設計しやすくなります。

人のアカウントを使い回すのではなく、エージェント専用のID（非人間ID）を発行します。「どのエージェントが動いているか」を基盤側が認識できることが出発点です

最小権限の原則をエージェントにも適用します。考え方は「エージェントの権限＝人の権限とエージェント用の制限範囲の重なり」です。エージェントが外部ツールへ接続する規格のMCP（Model Context Protocol）でも、認可を利用するHTTPベースの接続について、アクセストークンの利用対象を特定のMCPサーバーに限定し、別のサーバーでトークンが流用されるリスクを抑える仕組みが定められています。

ユーザーがどのエージェントを呼び出し、エージェントがどのクエリを実行し、どのデータにアクセスしたかを、単なる操作ログではなく一連の因果関係として監査証跡に記録します。

4.エージェントIDの2つの形：委任型と自律型

エージェントIDを設計するときは、エージェントが「誰の権限で動くか」で2つに分けて考えます。

項目 委任型（Delegated） 自律型（Autonomous）
動き方 ユーザーの代わりに、ユーザーのセッション内で動く エージェント自身のIDと認可で動く
典型的な用途 対話型の分析エージェント、業務担当者のアシスタント 夜間に自動実行される監視・集計エージェント
IDの持ち方 ユーザー本人のIDのまま動き、セッションに「エージェント動作中」の目印（フラグ）を付けて人の直接操作と区別する 専用のユーザー（サービスID）を発行し、非対話型の認証を使う
監査で追うこと どのユーザーが、どのエージェントを使ったか どのエージェントが、誰の承認のもとで動いているか

例えば担当者のAさんが分析エージェントに質問すると、クエリはAさんの権限で実行され、基盤側では「Aさんの代わりにエージェントが行った操作」として識別されます。
また、どちらの型でも、監査では次の3点を押さえます。

5.データ基盤側で実装するポイント（Snowflakeの例）

◆Snowflakeにおけるエージェントガバナンスの構成
私が日々扱っているSnowflakeを例に、3つの柱の実装方法を紹介します。Snowflakeには、セッションの中でエージェントが動作しているかを基盤が認識する「Agent Identity」の仕組みがあります。

Snowflake Cortex AgentsやSnowflake CoWorkなどSnowflake製のエージェントは、自動的に「エージェント動作中」のセッションとして扱われます。
自律型のエージェントには、専用のユーザータイプ「SERVICE_AGENT」（2026年7月に一般提供）を使います。

マスキングポリシーや行アクセスポリシーの条件に、エージェント動作中かを判定する「IS_AGENT_ACTIVATED」を組み込めます。 次の例では、エージェント経由のクエリではメールアドレスを常に伏せ字にし、人が直接参照する場合はANALYSTロールだけが元の値を確認できます。

■SQL 
CREATE OR REPLACE MASKING POLICY email_mask_for_agent
    AS (val STRING) RETURNS STRING ->
    CASE
　　　-- エージェント経由のクエリは常にマスクする
      WHEN SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED')::BOOLEAN = TRUE
        THEN '********'
　　　-- 人が直接参照する場合は、ANALYSTロールのみ元の値を表示する
      WHEN CURRENT_ROLE() IN ('ANALYST') THEN val
      ELSE '********'
    END;
-- 顧客テーブルのメールアドレス列にポリシーを適用する
ALTER TABLE customers MODIFY COLUMN email SET MASKING POLICY email_mask_for_agent;

さらに「Restricted Session Scope」（2026年9月に一般提供）を使うと、エージェントが動作している間だけ有効な権限の上限を設定できます。ユーザー権限との重なりだけが有効になり、新たな権限は付与されません。 例えば読み取り専用のスコープ「SNOWFLAKE$DATA_READ」をセッションポリシーに設定すれば、更新権限を持つユーザーでも、エージェント経由の操作は読み取りに限定されます。
▶【参考】Snowflake公式ドキュメント- Restricted Session Scope for agents

クエリ履歴（QUERY_HISTORY）のagent_type列にはクエリを呼び出したエージェントの種別が、アクセス履歴（ACCESS_HISTORY）のagents_info列には関与したエージェントの一覧が記録され、因果関係をSQLで追跡できます。

AIクライアントやエージェントからモデルへのアクセスを一か所で統制する「Cortex AI Gateway」も2026年7月に発表されました（2026年10月時点ではパブリックプレビュー）。経路を一元化することで、次の利点があります。

●モデルの利用権限を一か所で付与・取り消しでき、無許可の利用を防ぎやすい
●リクエストごとのモデル、処理時間、トークン数などが記録され、AIがユーザーの代わりに何をしたかを確認できる
●利用料金をチームやユーザー単位で把握し、予算や利用上限を設定できる
最新の提供状況は公式ドキュメントをご確認ください。

▶【参考】Snowflake公式ドキュメント- Cortex AI Gateway

6.導入時の注意点

専用の仕組みを一から作るのではなく、既存のRBACやポリシーにエージェントの観点を加えます。管理者ロールや共有ロールをそのまま渡さず、タスクごとに最小限のロールを定義します。
土台となるデータマネジメントが整っていなければ、エージェントの統制も機能しません。

作成者の異動や退職で「誰も管理していないエージェント」が残らないよう、エージェントにもオーナーを定め、ライフサイクルを管理します。

7.まとめ

SWTT 2026のデモや国内事例を通じて、ガバナンス設計をしっかり行えば、AIエージェントを本番ワークロードで利用できる段階に来ていると実感しました。
統制されたデータ基盤があってこそ、エージェントは安心して任せられる存在になります。
エージェントIDを中心とする識別・権限・監査は、どれか一つが欠けても成り立ちません。3つをそろえた土台の上で、一緒にAgentic Enterpriseの実践を進めていきませんか？
▼データマネジメントを詳しく知りたい方はこちらの記事もご覧ください。
data management
関連記事

データマネジメントとは？基礎知識から実践・導入ステップまで徹底解説
▼Snowflake World Tour Tokyo 2026の参加レポートはこちらをご覧ください。
swtt2026 keynote
関連記事

～Agentic Enterpriseは日本で『実践』の段階へ～Snowflake World Tour Tokyo 2026 Keynote参加レポート

8.富士ソフトのデータ利活用支援について

富士ソフトでは、SIerとして培ってきた技術力と豊富な実績を基盤に、お客様の要件を起点としたデータ基盤全体の構成検討からご支援しています。
データ基盤において「どのツールや機能を選択すべきかわからない」「全体としてどのような構成が適切か判断できない」といったお悩みに対し、ツール選定から分析基盤の導入までを一貫してご提案いたします。
データ基盤の構想段階から、製品選定、導入後の活用に至るまで、お困りのことがございましたらお気軽にご相談ください。

富士ソフトのデータ利活用支援

データ利活用する際、以下のお悩みを抱えていますでしょうか？

  • 「データ基盤を新規で構築したい、または刷新したい」
  • 「SQLが記述できない現場担当者でもデータを活用できる仕組みを構築したい」
  • 「データ基盤のメタデータ設計についてサポートを受けたい」

富士ソフトでは、上記のお悩みを解決することが可能です。
また、お客様の業務内容およびデータ特性に合わせたPoCならびに導入支援も提供いたします。
本記事がAIエージェントのガバナンスの活用を検討する際の参考になれば幸いです。
また、データ分析・利活用ソリューションにご関心のある方は下部のボタンよりお問い合わせください。

データ分析・利活用ソリューションに関するお問い合わせ

データ分析・利活用・POCに関する
資料請求・お問い合わせはこちらから！

データ分析・利活用ソリューション | 富士ソフト