AIエージェントの接続先と権限の棚卸し手順
参照したAIgram
目次
概要
社内でAIエージェントが増えてくると、「どれが、どこに繋がっていて、何ができるのか」が分からなくなってきます。この状態が落ち着かない、という感覚は、たぶん多くの方が持たれていると思います。
MuleSoftの調査「Connectivity Benchmark Report」2026年版によれば、中堅から大企業までの企業には、平均で千以上のアプリケーションが存在します Salesforce MuleSoftのAI統制基盤。その上でAIエージェントが増えていくと、管理負荷、権限範囲や挙動を統制できないことによるセキュリティリスク、コスト超過につながる懸念が指摘されています。
棚卸しの進め方は、事例から次のように読み取れます。まずエージェントの数と接続先を数え、業務の流れごとに接続先を並べます。次に、読み取りと書き込みを分けて記録します。AnyAI Agentは、SNS、ECモール、広告管理画面、社内データベースから情報を取得・分析しますが、システム実行だけは担当者の承認後に行う設計です AnyAI Agentのマーケ・EC支援、月550時間削減。そして、接続の入口に検知と遮断を置きます。NTTデータは接客AIエージェントで、AI関連リソースの構成管理と脆弱性検知にDefender CSPMを使い、不適切な入力そのものをAzure AI Content Safetyでブロックしています Microsoft Defenderで守るNTTデータ接客AI。最後に、集めた一覧を単一の管理面へ集約し、運用の見直しに戻します。
棚卸しは、数える・並べる・分ける・確かめる・入口を守る・集約する、という順で進められます。特別な発想は必要なく、今あるものを一つずつ書き出すところから始められます。
エージェントの数と接続先を先に数える
棚卸しの最初の作業は、数えることです。今いくつのAIエージェントが動いていて、それぞれがどこに繋がっているのか。この数字がないまま権限の話を始めると、対象が確定しないまま議論だけが進みます。
数える必要がある理由は、業務の構造にあります。企業には平均で千以上のアプリケーションが存在し、業務プロセスは多数のアプリケーションを横断して実行されています 。エージェントが1つ増えるたびに、繋がる先は1つでは済みません。
さらに、エージェントを作るのはエンジニアだけではなくなりました。非エンジニアのビジネスパーソンが業務に即したAIエージェントを開発・運用するためのツールやプラットフォームも出てきています 。情報システム部門が把握していないエージェントが現場で動いている状態は、こうして生まれます。増え続けるAIエージェントを適切に管理できないことは「AIエージェントのスプロール（乱立）」の懸念として指摘されています。
最初に書き出す項目は、次の4つで足ります。
- エージェントの名前と、動かしている部署・担当者
- そのエージェントが担当している業務
- 繋がっている接続先（SaaS、基幹システム、他のエージェント）
- 稼働している状態か、試験中か
権限の設計を始める前に、対象となるエージェントの一覧を確定させます。数が分からないままでは、統制の範囲も決まりません。
接続先を業務の流れごとに並べる
数え終わったら、接続先を業務の流れに沿って並べ直します。一覧のままでは、どの接続が何のために必要なのかが判断できないためです。
AnyAI Agentは、利用者が自然言語で入力した依頼から、AIが必要な手順を組み立てます。そのうえで、SNS、ECモール、広告管理画面、社内データベースなどから情報を取得・分析します 。接続先が4種類あるのは、マーケティング・EC業務がその4種類の情報を必要とするからです。業務の流れが先にあり、接続先はその流れから決まっています。
EFSGの例も同じ構造です。チャットボットは顧客データと連携し、過去のやり取りの概要を自動生成して、顧客サービス担当者が案件記録を更新できるようにしています EFSGのCopilot Studio顧客対応統合。顧客対応という業務の流れの中で、顧客データへの接続が何のために要るのかがはっきりしています。
また、EFSGはDynamics 365 Contact Center、Customer Serviceハブ、オムニチャネルを使い、チャット、メール、電話、SNSを単一のインターフェースで扱っています EFSG、Copilot Studioで顧客応対を自動化。チャネルが4つあっても、担当者が触る画面は1つです
。
並べるときは、業務の順番に沿って次を書き出します。
- その工程で、エージェントが何を受け取るか
- どの接続先から情報を取得するか
- 何を出力し、どこへ渡すか
- 業務上、その接続が必要な理由
読み取りと書き込みを分けて記録する
接続先を並べたら、次は接続の種類を分けます。情報を読むだけの接続と、システムに書き込む接続では、間違えたときの影響がまったく違うためです。
AnyAI Agentの設計は、この線引きがはっきりしています。情報収集・分析、課題の抽出、改善施策の提案、成果物の作成までをAIが行い、システム実行は担当者による承認後に行います 。活用例として挙げられているECモールの商品情報更新も、担当者の承認後に実行されるものとして示されています
。読み取りと分析はAIに任せ、外に影響が出る書き込みだけ人の承認を挟む形です。
EFSG側にも、人が関与する場所が用意されています。顧客サービスマネージャーは、チャットボットのフローに関するフィードバックを確認し、必要な調整を行えます 。エージェントの挙動を後から直せる担当者が決まっている、ということです。
棚卸し表には、接続先ごとに次を記録します。
- 読み取りだけか、書き込みも行うか
- 書き込みの場合、承認が必要か
- 承認する担当者は誰か
- 挙動を調整できる担当者は誰か
読み取りと書き込みを同じ欄にまとめると、危険な接続が安全な接続に紛れます。列を分けて記録します。
扱うデータの機密度を接続先ごとに確かめる
接続の種類を分けたら、その接続で流れるデータの中身を確かめます。同じ「読み取り」でも、公開情報を読むのと顧客の個人情報を読むのでは、必要な備えが変わります。
NTTデータは、接客AIエージェントを顧客企業の業務環境で育てていく過程で機密データを取り扱う必要があるとしたうえで、Azure OpenAIをAI基盤に採用しました NTTデータがAzure OpenAIで接客AIを安全に開発。機密データを扱うという前提が先にあり、基盤の選定がその前提から決まっています。
EFSGは、データを分ける仕組みそのものを業務に組み込んでいます。Dynamics 365の「連絡先所有者」フィールドを使い、エンティティ間で顧客データを分離して、市場ごとにワークフローをカスタマイズしています 。各顧客サービスチームは、大規模なカスタマイズを行うことなく、それぞれの市場に関するデータを管理できます。
そして、各エージェントがSaaSや基幹システム、他のエージェントと連携するようになると、エージェントがアプリケーションやデータにアクセスする際の権限管理が必要となります 。接続の数だけ、権限を決める判断が発生します。
接続の入口に検知と遮断を置く
棚卸しで接続先と権限が見えてきたら、その接続の入口に何を置くかを決めます。一覧を作っただけでは、想定外の入力や攻撃は止まらないためです。
NTTデータの接客AIエージェントは、複数の仕組みを役割ごとに使い分けています 。
- Defender CSPMで、AI関連リソースの構成管理と脆弱性検知を行う
- Defender for AIで、間接的プロンプトインジェクション攻撃の検知と、システム内部の異常な振る舞い検知を行う
- Azure AI Content Safetyのフィルタリング機能で、差別的・暴力的プロンプトや敵対的プロンプトの入力自体をブロックする
構成の管理、攻撃の検知、入力の遮断が、それぞれ別の仕組みに割り当てられています
。棚卸し表の「接続先」の欄に、この3つのどれが効いているかを書き添えると、守れていない接続が分かります。
運用の続け方も示されています。AI Content Safetyには任意の文字列の入力をブロックできるブロックリスト機能があり、そこにMicrosoft Defender脅威インテリジェンスが提供する情報を活用して言葉をリストアップする運用が挙げられています 。新しい脅威を自社だけで追い続けるのは負担が大きいため、外部の情報を取り込む形です。
一覧を単一の管理面に集約する
ここまでの棚卸しを部署ごとの表で持ったままにすると、エージェントが増えるたびに表も増えていきます。集約先を決める必要があります。
セールスフォースは、AIエージェントとその接続先を一元的に管理する「単一のコントロールプレーン」を訴求しています 。エージェントと接続先を、ばらばらの管理表ではなく一つの管理面で扱うという考え方です
。
企業側の関心も、この領域へ移ってきています。MuleSoft 最高マーケティング責任者のカルーナ・ムカルジー氏は、多くの企業における関心事が、エージェントを安全に活用するためのガバナンスや信頼性の担保、コストの可視化といった領域に移ってきていると指摘しています 。棚卸しで数えた接続の数は、そのままコストの見通しにも関わります。
集約の対象には、エージェント同士の繋がりも入ります。MCP（Model Context Protocol）やA2A（Agent to Agent）など、エージェントの連携を司る新たなプロトコルへの対応も求められます 。接続先はシステムだけでなく、他のエージェントも含まれるということです。
棚卸しの成果物は、部署ごとの表ではなく、エージェントと接続先を一元的に管理する一つの管理面に集めます。
棚卸しの結果を運用の見直しに戻す
棚卸しは一度作って終わりにはできません。エージェントも接続先も増えていくため、更新の仕組みが要ります。事例では、更新を運用の中に組み込んでいます。
AnyMind Groupは2026年1月より社内導入を進めており、社内運用を通じて得られた利用者の意見や課題を、機能や業務フローの継続的な改善に反映しています 。使ってみて出てきた課題が、そのまま次の改善の材料になっています。
NTTデータは、今後現れるであろうリスクや脅威にも即座に対応し、導入済み企業のビジネスニーズにも即応できる開発体制を維持し続けるとしています 。守り方を固定せず、更新し続ける前提です。
EFSGでは、現場担当者がシステム内で数回のクリック操作を行うだけで、FAQの回答や挨拶メッセージを更新できます 。これにより、情報が常に最新かつ関連性の高い状態に保たれます。更新の手間が小さいことが、情報を最新に保つ条件になっています。
棚卸し表を最新に保つために、次を決めておきます。
- 表を更新するタイミング（新しいエージェントの追加時、権限の変更時）
- 更新を担当する部署
- 利用者から出た課題を集める窓口
- 集まった課題を反映する頻度
結論
AIエージェントの接続先と権限の棚卸しは、次の流れで進められます。
- 動いているエージェントの数と接続先を数え、一覧を確定させる
- 接続先を業務の流れごとに並べ、その接続が必要な理由を書き出す
- 読み取りと書き込みを列を分けて記録し、書き込みには承認者を決める
- 接続先ごとに扱うデータの機密度を確かめ、権限を決める
- 接続の入口に構成管理・検知・入力の遮断を置く
- 一覧を単一の管理面へ集約し、運用の中で更新し続ける
この作業が必要な理由は、事例の指摘に戻ります。エージェントの権限範囲や挙動を統制できなければ、管理負荷やセキュリティリスクの増大、コスト超過につながるため、増え続けるエージェント群を制御する単一のコントロールプレーンが必要との認識が多くの企業に広がっています 。
具体的な形は、すでに事例の中にあります。AnyAI Agentは複数のシステムを横断して情報を取得・分析しながら、システム実行だけを担当者の承認後に限定しています 。NTTデータは構成管理、脆弱性検知、不適切な入力のブロックを組み合わせ、機密データを扱う接客AIエージェントを提供しています 。
棚卸しは、業務を止めるための作業ではありません。AnyMind Groupは、2026年1月から6月までの実績をもとに、週3,000件以上のタスク実行と月間約550時間相当の業務時間削減効果を概算しています 。接続先と権限が整理されていることは、この規模でエージェントを動かし続けるための土台になります。
難しい発想は必要ありません。今動いているエージェントを数え、繋がっている先を業務の流れごとに書き出し、読み取りと書き込みを分けて記録するところから始められます。