AIエージェント、 社内展開の前に知っておきたいこと

チャット型AIとは異なり、AIエージェントはシステムへの「書き込み・更新・送信・発注」といった実行を伴います。その強力さゆえに、導入前の設計が欠かせません。
本資料では、AIエージェントを社内展開する前に押さえておくべきポイントを整理しています。

・チャット型AIとAIエージェントの本質的な違い（応答 vs 実行）
・まず決めるべき3つのルール：スコープ定義、承認フロー設計、オーナーシップ
・リスクレベル別のエージェント分類と対策の考え方
・セキュリティ・ガバナンスの4本柱：認証認可、ガードレール、データ層の防御、可観測性
・認証はAPIキー埋め込みではなく環境ベースのアイデンティティへ
・ガードレールは突破される前提で、データ層を「最後の砦」として守る設計

AIエージェントの展開前に検討しておくべき基本をまとめています。
荒川 裕二（日本オラクル株式会社 / OCI Platform COE本部 ソリューションズ・アーキテクト部）

Transcript

1. AIエージェント、 社内展開の前に知っておきたいこと 2026年3月9日 荒川 裕二 日本オラクル株式会社 クラウド事業統括 製品事業統括 OCI Platform COE本部 ソリューションズ・アーキテクト部
2. Copyright © 2026, Oracle and/or its affiliates 3 チャット型AI AIエージェント 動き方 人間が問いかけ、AIが応答 トリガーに応じてAIが自律的に処理・実行 主役 人間 AI（人間は設計者・監督者） システムへの影響 原則なし 書き込み・更新・送信・発注が起きる 間違えたとき 「おかしな答えが返ってきた」 「誤発注が起きた」 エージェントは強力なぶん、展開前に「誰が何をどこまで許可するか」を設計しておくことが不可欠です。 チャット型AIと業務用AIエージェントの最大の違いは「応答するか」「実行するか」 AIエージェントは、「実行」する
3. ① スコープ定義 何をやらせて、何はやらせないか ② 承認フロー設計 人間が確認するポイントはどこか ③ オーナーシップ 誰が責任者か Copyright © 2026, Oracle and/or its affiliates 3 まず決めるべき「3つのルール」 セキュリティ・ガバナンス 認証認可 ガードレール データ層の防御 可観測性
4. Copyright © 2026, Oracle and/or its affiliates 5 リスク低め 始めやすい リスク高め 実績を積んでから ✓ 社内ドキュメントの検索・Q&A対応 ✓ サポートチケットの自動分類・振り分け ✓ 請求書・伝票のデータ抽出 ✓ ITアクセス申請の受付・ルーティング ✓ 在庫・需要データのモニタリング 発注書・契約書の自動起票（ERP書き込み） 顧客への自動返信・外部メール送信 支払い処理・財務情報の更新 権限の自動付与・削除 在庫の自動発注・サプライヤーへの自動連絡 ① スコープ定義 判断の目安 そのエージェントが「間違えたとき、影響がどこまで広がるか」 社内の1人で完結するなら低リスク、顧客・外部システム・金銭が絡むなら高リスク 何をやらせて、何はやらせないか
5. リスクレベルでエージェントを分類する Copyright © 2026, Oracle and/or its affiliates 5 低リスク 例）社内ドキュメントQ&A、チケット分類、レポート要約 アクセス制御： 基本的なアクセス制御と監査ログで対応可 データの防御： 読み取り対象データの範囲を明示的に限定。機密テーブル・カラムへのアクセスを除外 中リスク 高リスク 読み取り専用・社内限定・影響範囲が1人 例）ITアクセス申請の自動処理、帳票データのERP入力 アクセス制御： 承認フロー必須・担当オーナーの紐づけ必須 データの防御： 行レベル・列レベルのアクセス制御を適用。個人情報・機密カラムには動的データマスキ ングを設定。書き込み対象テーブルを限定し、監査ログを有効化 社内システムへの書き込み・複数人に影響 例）顧客への自動通知、発注処理、財務データの更新 アクセス制御：厳格な権限設計・監査・段階的な自動化が前提 データの防御：行レベル・列レベルの厳格なアクセス制御に加え、データの暗号化（保存時・通信時）を 徹底。AIモデルに渡すデータはメタデータのみに制限し、データ露出を最小化。全アクセ スの監査ログを自動取得し、異常検知アラートと連携 外部送信・金銭・顧客情報・規制対象データ
6. 決済領域の例 「AIの役割が変わるとリスクも変わる」 Copyright © 2026, Oracle and/or its affiliates 6 タイプA：カード情報を扱うAI 「お財布を持って買い物に行くロボット」のイメージ 主なリスク ・ カード情報の露出（攻撃面の拡大） ・ フィッシング・偶サイトへの入力 ・ なりすまし検出リスク 主な対策 セキュアな実行環境、フィッシング検知、認証強化 タイプB：サブスク判断をするAI 「家計簿を管理する秘書AI」のイメージ 主なリスク ・ フレンドリーフロード（予期せぬ返金要求） ・ 責任境界の不明瞭さ ・ オペレーショナルリスク 主な対策 行動ログ・説明責任（KYAI）、通知の明確化 AIが担う役割に応じて対策を切り分けることが重要です。タイプAは「情報セキュリティ」、タイプBは「同意・説明責任」が主たるリスクです。
7. ユースケースを集めるには Copyright © 2026, Oracle and/or its affiliates 7 ご参考 社内AI活用の「何から始めれば？」をAIで突破する～AI駆動AI普及活動 AAAP(triple-A P)～ https://qiita.com/yuji-arakawa/items/79027bb7688a5f1b94e2
8. ② 承認フロー設計 Copyright © 2026, Oracle and/or its affiliates 8 エージェントが処理 人間が確認 実行 金額・数量に閾値を設ける 「◦万円以下は自動処理、超えたら担当者承認」 外部への送信・公開 顧客メール・外部API・一度出たら取り消せない処理 個人情報・機密情報が絡む処理 人事データ・医療情報・財務情報の更新 新規レコードの作成 新規ベンダー登録・新規顧客登録など 人間が確認するポイントはどこか
9. どのエージェントにも「人間のオーナー」を1人紐づける ③ オーナーシップの明確化：誰が責任者か Copyright © 2026, Oracle and/or its affiliates 9 1 定義・承認 そのエージェントのスコープと権限を 定義・承認する人 2 緊急対応 異常動作が起きたときに 最初に連絡が来る人 3 監査 監査ログを定期的に 確認する人 WEF（世界経済フォーラム）は、エージェントの導入を「新入社員のオンボーディングと 同じ厳密さで扱うべき」と提言しています。 https://www.weforum.org/stories/2025/12/ai-agents-onboarding-governance/ “組織がチームの補強や物理世界での活動のためにAIエージェントを導入する際には、新入社員を迎え入れるときと同等の厳密さをもって オンボーディングに取り組むべきである。これには、明確に定義された役割、セーフガード、そして体系的な監督体制の整備が含まれる。 ”
10. 認証・認可～「誰が何をできるか」を整理する Copyright © 2026, Oracle and/or its affiliates 10 従来の方式 エージェントごとにAPIキーを発行・埋め込み キーが漏洩するまで気づきにくい 侵害されたエージェントの特定・停止に時間がかかる 望ましい方式 環境ベースのアイデンティティ（リソースプリンシパル等） プラットフォームが一元管理・ローテーション そのアイデンティティだけを即座に無効化可能 最小権限 読み取り専用で済むなら書き込み権 限は与えない 短命トークン ツール実行ごとに短命な一時トークンを 使い捨てる 即時停止機構 異常な振る舞いを検知したら即座に無 効化 エージェントが増えると攻撃面積が広がる
11. ガードレール Copyright © 2026, Oracle and/or its affiliates 11 入力側のガードレール 個人情報・機密情報の混入 エージェントへの入力に含まれていないか自動検出・除去 プロンプトインジェクション 悪意ある指示が外部データから紛れ込まないか検知 スコープ外の操作要求 定義されたスコープを超える動作を命じていないか 出力・実行前のガードレール 機密情報の漏洩 出力や外部送信データに機密が含まれていないか 高リスク操作の実行前確認 削除・外部送信・大量処理に人間の承認を挟む 閾値チェック 金額・件数・頻度が設定した範囲内か確認 マルチエージェント構成では、あるエージェントへのプロンプトインジェクションが 連携する別のエージェントに伝播するリスクもあります
12. ガードレールは突破されることがある前提でデータを守る データ層の防御：「最後の砦」を作る Copyright © 2026, Oracle and/or its affiliates 12 第1の防衛線 認証認可 第2の防衛線 AIへの入出力ガードレール 行レベル・列レベルのアクセス制御 Need-to-Knowの原則を強制 動的データマスキング 権限のないエージェントには機密項目を自動的に伏せる 意図しないアクセスの検知・遮断 想定外のデータアクセスパターンをブロック AIモデルに渡すデータの制御 メタデータのみで処理しデータ露出を最小化 保存データ・通信経路の暗号化 バックアップ含む全データを保護 監査ログの自動取得 誰が・いつ・どのデータにアクセスしたか記録 最後の砦 データ層の保護
13. 「何が起きているか」を見える化する 可観測性 Copyright © 2026, Oracle and/or its affiliates 13 → アイデンティティの特定 → 想定外の経路でのアクセスがないか → 処理の追跡 → 異常な大量アクセスの検知 → 意図しない動作の検知 異常検知の仕組みを最初から用意する 即時アラート 短時間での大量アクセス・大量データ読み込みなど異常な振る舞いを検 知したら即座にアラート キルスイッチ 問題のあるエージェントのアイデンティティを即座に無効化できる仕組み インシデント対応 ログの保全・関係者への通知手順をあらかじめ定めておく どのエージェントが どのツール・APIを呼んだか 何を入力として受け取り、何を実行したか いつ・どれだけの頻度で動いたか エラーや例外はなかったか
14. まとめ Copyright © 2026, Oracle and/or its affiliates 14 スコープ データ層の セキュリティ ➢ リスクで分類 ➢ 何か OK で、何が NG ➢ ガードレールは突破される前提で！ ➢ Need-to-Knowの原則を強制 ➢ 承認フロー ➢ オーナーシップ ガードレール 認証・認可 ➢ エージェントに API キーを持たせない ➢ ロールベース（例：OCI IAMポリシー＋動的グループ＋リソースプリンシパル） ➢ プロンプト・インジェクション対策 ➢ 個人識別情報の検知