AIエージェントセキュリティデータ連携

外部のAIから業務システムを安全に使う。入口が変わってもルールは同じ

外部のAIから業務システムを安全に使う。入口が変わってもルールは同じ

「普段使っているAIアシスタントから、社内の売上や顧客のデータを直接聞けるようにしたい」。 こうしたご相談が増えています。 外部のAIから社内の業務システムやデータ基盤に安全につなぐための設計の考え方を、事例とあわせて整理します。

AIの入口は、社内の画面の外に広がっている

これまで業務システムのデータは、決まった画面から、決まった人が見るものでした。 いまは、汎用のAIアシスタント、他部門や他社が作ったエージェント、分析ツールに組み込まれたAIなど、 社内の画面の外から業務データを使いたい、という場面が当たり前になりつつあります。

AIと業務システムをつなぐ標準的な接続方式(MCPのようなもの)も広がり、技術的には「つなぐこと」自体はそれほど難しくなくなりました。 難しいのは、つないだあとも、これまでと同じ統制を保てるかです。

AIエージェントの権限そのものの考え方は、 「AIエージェントに顧客データを渡す前に」と 「AIエージェントの権限は影響度で設計する」で紹介しました。 今回は「外部のAIが入口になる」ときに、何を追加で考えるべきかに絞ります。

原則は「オープンアクセスであって、オープンバイパスではない」

外部のAIとつなぐときの原則は、ひとことで言えば「オープンアクセスであって、オープンバイパスではない」です。 どの外部エージェントからの呼び出しにも、通常の画面操作とまったく同じガバナンスを適用します。

入口が変わってもルールは同じ。通常の画面、AIアシスタント、外部エージェント、分析ツールのどこから来ても、同じ認証・権限チェック・監査記録を通って業務システムに届く 通常の画面 人が直接操作 AIアシスタント 汎用のチャットAI 外部エージェント 他部門・他社製 分析ツール 組み込みのAI どの入口でも、同じ関所を通る IDと認証 誰からの依頼か 権限 見てよい範囲だけ 監査記録 誰が何をしたか 業務システム・データ基盤 セキュリティモデルは1つだけ オープンアクセスであって、オープンバイパスではない
入口が増えても、データに届くまでに通る関所は1つにする

入口が画面からAIアシスタントに変わっても、セキュリティモデルと認証情報のチェックは変わりません。 画面で見られないデータは、AI経由でも見られない。画面でできない操作は、AI経由でもできない。 入口ごとに別のルールを作るのではなく、すべての入口が同じ関所を通るように設計します。

こうしておけば、新しいAIツールが登場するたびに、セキュリティの議論を一からやり直す必要もありません。 「どのAIを使うか」と「どのデータを誰に見せるか」を、切り離して考えられるようになります。

自前でつないだ連携が、危うい理由

よくあるのが、部門の担当者が外部のAIと業務データを自前(DIY)でつないでしまうケースです。 見た目はきちんと動き、便利になったと評判も上々です。 ところが中身を見ると、権限・監視・統制という「根」が弱くなっていることが少なくありません。

例1の具体例:全権限の連携キーで、外部AIをつないだ。部門で外部のAIを業務データにつなごうと管理者の連携キーで自前の連携を作った。社員の誰が聞いても、AIは管理者としてすべての顧客データを検索して答える。本来見られない人に情報が渡り、記録もないAIが誤ってデータを消す恐れもある。利用者本人の権限で接続し、参照専用に限定誰が何を見たかも記録に残る 具体例 例1|全権限の連携キーで、外部AIをつないだ 1. 場面 部門で外部のAIを業務データにつなごうと 管理者の連携キーで自前の連携を作った 2. 起きること 社員の誰が聞いても、AIは管理者として すべての顧客データを検索して答える 3. 結果 本来見られない人に情報が渡り、記録もない AIが誤ってデータを消す恐れもある 4. 設計すると 利用者本人の権限で接続し、参照専用に限定 誰が何を見たかも記録に残る

たとえば、管理者の連携キーを使って接続していると、AIは質問した人が誰であっても、管理者と同じ範囲のデータにアクセスします。 エージェントが本来許されていないデータを共有したり、削除したりする、といった問題が起きやすくなります。 しかも、誰が何を聞いたのかが記録に残らないため、問題が起きても調べようがありません。

自前の連携そのものが悪いわけではありません。 問題は、画面に適用していた統制が、連携の部分だけすっぽり抜け落ちることです。

まずは、社内にどんなAI連携がすでにあるのかを棚卸しすることから始めます。 どの認証情報で、どのデータにつながっているのか。担当者の異動とともに、誰も中身を知らない連携が残っていないか。 ここが見えていないと、次の設計に進めません。

安全な接続口をつくる5つの設計

標準的な接続方式で外部のAIと業務システムをつなぐ場合、私たちは次の5点を基本にしています。

  • 専用の接続用アプリを用意する:外部AI向けの接続用アプリを作り、そこに専用の権限範囲を持たせます。既存の連携や管理者の認証情報を流用しません
  • 認可は OAuth 2.0 の認可コード方式+PKCE で行う:利用者がその都度ログインして許可する方式にし、認証情報の横取りも防ぎます
  • 参照専用の接続口から始める:AIからデータを更新させない接続口を基本にします
  • クエリは、あらかじめパラメーター化して限定する:AIに自由なクエリを組み立てさせず、「指定した期間の、自分の担当顧客の売上」のように、形の決まった問い合わせだけを用意します
  • 公開する操作を絞る:業務システムのすべての機能ではなく、特定の操作だけをAIから呼び出せるようにします
外部のAIと業務システムを自前でつなぐ場合と、安全な接続口を設計する場合の比較。認証、権限範囲、更新、クエリ、操作の5項目 自前でつなぐ 動くが、根が弱い 安全な接続口 画面操作と同じ統制 認証 全権限の連携キーを共有 OAuth 2.0+PKCE 権限範囲 管理者と同じ 専用の範囲に限定 更新 何でも書き換えられる 参照専用から始める クエリ 自由に組み立てられる パラメーター化して限定 操作 すべての機能 特定の操作だけ
「何でもできる鍵」ではなく、「決まった窓口」だけを開ける

ポイントは、AIに「何でもできる鍵」を渡すのではなく、「決まった窓口」だけを開けることです。 窓口の数と形が決まっていれば、テストも監視もしやすくなります。

「誰の権限で動くか」を選べるようにする

外部のAIから呼び出されたアプリやエージェントを、誰の権限で動かすか。 ここは、用途に応じて選べる設計にしておくのが理想です。

作成者の権限で動く場合と、利用者本人の権限で動く場合の比較。同じ質問でも、作成者の権限では全員に全国の顧客が見え、本人の権限ではそれぞれの担当地域の顧客だけが見える 作成者の権限で動く 作成者・連携用ユーザーとして 「顧客の一覧を見せて」 Aさん(東日本の営業) 全国の顧客が見える Bさん(西日本の営業) 全国の顧客が見える 向いている用途 全員に同じ範囲を見せてよい用途 例:公開済みの規程・FAQの検索 ※ 範囲を明確に絞ることが前提 利用者本人の権限で動く 本人に代わってトークンを取得 「顧客の一覧を見せて」 Aさん(東日本の営業) 東日本の顧客だけ Bさん(西日本の営業) 西日本の顧客だけ 向いている用途 人によって見える範囲が違う用途 例:顧客・案件データの参照 ※ 本人が見られる範囲しか見えない
社内データの参照は、利用者本人の権限で動かすのが基本
  • 作成者の権限で動かす:アプリやエージェントを作った人(または専用の連携用ユーザー)の権限で動きます。誰が使っても同じ範囲が見えるため、範囲を明確に絞り込んでおくことが前提です
  • 利用者本人の権限で動かす:利用者本人に代わってトークンを取得し、その人の権限で動きます。本人が見られる範囲しか見えないため、既存の権限設計がそのまま効きます

社内のデータを参照する用途では、利用者本人の権限で動かすのが基本です。 同じ「顧客の一覧を見せて」という質問でも、担当地域の違う2人には、それぞれ自分が見てよい顧客だけが返ります。 作成者の権限は、全員に同じ情報を見せてよい用途に限って使います。

利用者本人の権限で動かしておけば、異動や退職で本人の権限が変わったとき、AI経由で見られる範囲も自動的に変わります。 AIのために別の権限表を管理しなくてよいことも、運用の面では大きな利点です。

つないだ後に必要な4つの運用

接続口を正しく作っても、運用が伴わなければ統制は保てません。 外部のAIとつなぐ連携ごとに、次の4つを決めておきます。

  • タスクを把握する:その連携は何のために使うのか。所有者は誰で、誰が使い、どのデータに触れ、どんな操作をするのかを一覧にします
  • アクセスを制限する:把握した用途に必要な範囲まで、権限と公開する操作を絞ります
  • 監視する:通常の状態がどういうものか、どのステップで確認が必要になるかを知っておき、いつもと違う動きに気づけるようにします
  • 問題を阻止する:問題が起きたときの止め方、連絡先、接続の遮断方法を、事前に決めておきます

1つ目の「把握する」は、連携ごとに1枚の台帳にまとめておくと便利です。 新しい連携の申請を受けるときも、この台帳の項目を埋めてもらうことを条件にすれば、統制の外で連携が増えるのを防げます。

とくに4つ目は、後回しにされがちです。 接続用アプリを無効にすれば外部からのアクセスをすべて止められる、という形にしておくと、いざというときに迷わず動けます。

事例:外部のAIから、社内のデータを安全に使う

約1,000人が、汎用のAIアシスタントから社内データを参照
あるネット企業では、約1,000人の社員が、汎用のAIアシスタントから標準的な接続方式で社内のデータ基盤を参照しています。 各アカウントの権限と監査の仕組みはそのまま保たれており、AIを経由しても、見られるデータは本人の権限の範囲に限られます。

参照専用で運用し、利用開放は設定変更1本で即日
あるエンタメ企業では、接続を参照専用で運用し、60人以上が利用しています。 ロールは機能単位で細かく分け、事業領域ごとのワークスペースと、読み取り/読み書きのロールをコードで管理しています。 新しい利用者への開放は、設定の変更1本で即日に行える運用です。

売上の確認が、1〜2時間から15分に
あるOA機器メーカーでは、データの意味の定義とエージェントを標準的な接続方式で提供し、複数の汎用AIツールから同じように使えるようにしました。 売上の確認にかかる時間は、1〜2時間から15分に短くなっています。

社内のエージェントを、外部の分析ツールから呼び出す
ある化粧品グループでは、社内で作ったエージェントを、認可つきの接続で外部の分析ツールにつなぎました。 外部のツールを入口にしながらも、認可の仕組みを通すことで、社内と同じ統制のもとで使える形にしています。

つなぐ先は増やさず、1か所に絞る

接続が簡単になると、AIにあちこちのシステムをつなぎたくなります。 しかし、AIが外部の複数の接続先を次々に経由すると、途中で情報が少しずつ欠けたり変わったりする「伝言ゲーム」になりがちです。 答えの精度が落ちるうえ、呼び出しの回数が増えるぶんコストもかさみます。

おすすめは、データを信頼できる1か所に集約し、AIがつなぐ先を絞ることです。 意味の定義をそろえた1つの窓口を用意しておけば、どのAIツールから聞いても、同じ定義にもとづいた答えを返せます。

書き込むエージェントには、もう一段の備えが必要です。

参照だけでなくデータを更新するエージェントをつなぐ場合は、「実行してよいか」の判定をエージェントのコードの中に置かず、 外部のポリシーとして判定し、その結果を監査記録として残します。 エージェントの作りに頼らず、システムの側で止められるようにしておくことが重要です。

まとめ:外部のAIとつなぐ前に確認したいこと

  • 外部のAIからの呼び出しにも、画面操作と同じ認証と権限チェックが効いているか
  • 管理者や既存連携の認証情報を流用せず、専用の接続用アプリを用意しているか
  • 接続口は参照専用で、クエリと公開する操作が限定されているか
  • 社内データの参照は、利用者本人の権限で動く設計になっているか
  • 連携ごとに、用途・所有者・利用者・データ・操作を把握しているか
  • 問題が起きたときの止め方と連絡先が決まっているか
  • AIがつなぐ先を、信頼できるデータの置き場所に絞っているか

外部のAIを社内のデータにつなぐこと自体は、もう特別なことではありません。 差がつくのは、入口が増えても統制が変わらない作りにできているかどうかです。 私たちは、接続口の設計から権限・監視の運用まで、業務の現場と一緒に組み立てています。

外部のAIと業務システム・データ基盤の安全な接続も、ご相談ください。

AI受託開発を見る

CEO・PM / 代表取締役

古川 舜也Shunya Furukawa

京都大学大学院卒業後、フューチャーアーキテクト、Dirbato にてITコンサルタントとして 大規模基幹システムの構築・CRM/SFA案件に従事。2023年に株式会社PartnerOptimize を設立。

—Related insights

関連記事

AIエージェント AIエージェントの権限は「影響度」で設計する。実務の4ステップ セキュリティ AIエージェントの事故に備える:本番前に決めておく監視とインシデント対応 データ基盤 全社データを「組織で運営する」データメッシュの考え方 データ基盤 ベンダーロックインを避けるデータ戦略。製品ではなく「データと定義」を自社で握る データ連携 データを「コピーせずに」共有する。取引先・グループ会社との連携は「参照の許可」へ データ基盤 AIの回答精度を上げる「意味の層」の整え方:指標と言葉の定義を揃える実践手順 AI活用 暗黙知をAIで継承する:ベテランの判断を組織の資産にする方法 AI駆動開発 AI駆動開発で、データ基盤を作り直す データ基盤 非エンジニアが進める、データ活用の内製化の4つの条件 AI活用 現場で使えるプロンプト設計の基本 AI活用 AIで、音声・手書き・PDFを「分析できる資産」に変える データ基盤 従量課金クラウドの「想定外コスト」を防ぐ方法 AI活用 PoCで終わらせないAI導入の進め方 データ連携 データモダナイゼーションとは?システムを作り直さずに、AIで使えるデータへ AI活用 ChatGPT・Claude・Copilotを「単体で」使う5つのリスク データ基盤 AI時代に、データ基盤が重要な4つの理由 データ連携 SalesforceとSnowflake、どう使い分ける?役割の違いと4つのつなぎ方 AIエージェント AIエージェントに顧客データを渡す前に。Salesforceに学ぶセキュリティの3層 AI駆動開発 AI駆動開発で、受託開発の見積りはどう変わるか Salesforce Salesforceが現場に定着しない3つの理由と、FDE型という解き方

AIと業務設計で 事業を再構築する。

AI活用の進め方の整理から、データ基盤・AIエージェントの構築まで。
構想段階のご相談も歓迎です。お気軽にお問い合わせください。