Azure AI Foundryでエージェントを運用しているチームがまず押さえるべき点は、MCP Server Endpointsを「外部ツールとして接続できる」だけでなく、認証・承認・ネットワーク分離・監査の設計まで見直す必要があるということです。
Microsoft Learnの「Connect to MCP Server Endpoints for agents」では、Foundry Agent ServiceのエージェントにMCPツールを追加し、リモートMCPサーバー、Foundry Toolboxes、Azure DevOps MCP Serverなどを利用する方法が整理されています。なお、参照元ページはMicrosoft Learn上では2026年4月23日更新と表示されています。2026年5月19日の更新情報として社内展開する場合も、実装前にはページ本文と更新日を確認してください。 (Microsoft Learn)
結論から言うと、管理者は「どのMCPサーバーを許可するか」「どの認証方式を使うか」「承認を必須にするか」「Private MCPを使うならStandard Agent Setupを満たしているか」を確認すべきです。開発者は、server_url、server_label、allowed_tools、require_approval、project_connection_idの設定をコード・REST API・ポータル上で正しく扱う必要があります。 (Microsoft Learn)
Azure AI FoundryのMCP Server Endpoints対応で何が変わるのか
Azure AI FoundryのFoundry Agent Serviceでは、エージェントにmcpツールを追加することで、既存のリモートMCPサーバーを外部ツールとして利用できます。MCPは、LLMやAIエージェントが外部ツール・データソースにアクセスするための標準プロトコルです。Microsoftの公式ドキュメントでは、Python、C#、JavaScript、Java、REST APIの各実装例が示されており、Basic agent setupとStandard agent setupの両方でMCP接続を扱えると説明されています。 (Microsoft Learn)
これまで個別APIや独自関数で実装していた外部連携を、MCPサーバー単位でエージェントに接続できるようになるため、次のような使い方が現実的になります。
| 利用シーン | できること | 確認すべき点 |
|---|---|---|
| GitHubやAzure DevOpsとの連携 | リポジトリ情報、作業項目、仕様情報などをエージェントが参照する | 個人アクセストークンやOAuth権限の範囲 |
| 社内データソースとの連携 | 内部API、検索基盤、業務システムをMCPサーバー経由で呼び出す | Private MCP、VNet、認証方式 |
| 複数ツールの統合 | Foundry Toolboxesで複数ツールを1つのMCPエンドポイントとして扱う | バージョン管理、既定バージョン、承認設定 |
| 開発・検証環境での試験導入 | Foundryチャットテストでツール動作を確認する | 本番と検証でserver_labelや接続先を分ける |
重要なのは、MCPサーバーを接続すると、エージェントが外部サービスへリクエストを送る可能性が生まれることです。単なる機能追加ではなく、データ送信先・認証情報・操作権限・ログ監査まで含めた運用変更として扱うべきです。
管理者が最初に確認すべき影響範囲
MCP Server Endpointsの導入で影響を受けるのは、開発者だけではありません。Azure管理者、セキュリティ担当、ネットワーク担当、アプリ運用担当も関係します。
| 担当者 | 確認すべき内容 | 具体的な判断基準 |
|---|---|---|
| Azure管理者 | Foundryプロジェクト、RBAC、接続リソース | ContributorまたはOwner相当の作業権限が必要か |
| セキュリティ担当 | 接続先MCPサーバー、認証方式、送信データ | 非Microsoftサービスにプロンプトや業務データを渡してよいか |
| ネットワーク担当 | Public MCPかPrivate MCPか | Private MCPならStandard Agent Setupと専用サブネットが必要か |
| 開発者 | ツール定義、承認フロー、エラー処理 | allowed_toolsとrequire_approvalを適切に設定しているか |
| 運用担当 | ログ、承認履歴、トラブルシュート | どのツールがいつ呼ばれたか追跡できるか |
特に注意したいのは、非MicrosoftのMCPサーバーです。Microsoftの公式ドキュメントでは、非Microsoftサービスを使う場合、プロンプト内容などのデータが外部サービスへ渡る可能性があり、その利用条件、データ、費用について利用者側が責任を持つ必要があると説明されています。また、第三者が作成したリモートMCPサーバーについて、Microsoftが検証するわけではない点も明記されています。 (Microsoft Learn)
そのため、社内で導入する場合は「便利そうだから接続する」では不十分です。最低限、接続先の運営者、データ保持方針、認証方式、操作可能なツール、監査ログの取得方法を確認してから許可しましょう。
MCP接続の基本設定で見るべき項目
Azure AI FoundryでMCPサーバーを接続する際の基本は、エージェントのツール定義にmcpツールを追加することです。公式ドキュメントでは、リモートMCPサーバーごとに一意のserver_labelと、接続先を示すserver_urlを指定すると説明されています。複数のMCPサーバーを同じエージェントに追加することも可能です。 (Microsoft Learn)
実務では、次の項目を必ずレビューしてください。
| 設定項目 | 役割 | よくある失敗 |
|---|---|---|
server_url | MCPサーバーのエンドポイントURL | 検証環境と本番環境のURLを取り違える |
server_label | エージェント内でのMCPサーバー識別名 | 同一エージェント内で重複させる |
allowed_tools | エージェントが使えるツールを制限するリスト | 未指定のまま全ツールを使える状態にする |
require_approval | ツール呼び出し時の承認要否 | 書き込み操作なのにneverにしてしまう |
project_connection_id | 認証情報などを保存したProject connectionのID | 接続名とIDの扱いを混同する |
allowed_toolsを指定しない場合、MCPサーバーが公開しているすべてのツールが対象になり得ます。読み取り専用のMCPサーバーなら影響は限定的ですが、チケット作成、リポジトリ更新、データ削除、設定変更などの操作が含まれる場合は危険です。最初は必要なツールだけを許可し、利用実績を見ながら段階的に広げるのが安全です。 (Microsoft Learn)
require_approvalは原則「承認あり」から始める
MCPツールの運用で特に重要なのがrequire_approvalです。公式ドキュメントでは、既定値はalwaysであり、承認が必要な場合はレスポンスにmcp_approval_requestが含まれます。その後、previous_response_idと承認リクエストIDを使ってmcp_approval_responseを返し、処理を続行します。 (Microsoft Learn)
本番導入では、次のように判断すると実務で迷いにくくなります。
| ツールの種類 | 推奨設定 | 理由 |
|---|---|---|
| ドキュメント検索、README要約、読み取り専用API | 検証後に一部neverを検討 | 影響範囲が比較的小さい |
| チケット作成、コメント投稿、メール送信 | alwaysまたは対象ツールのみ承認必須 | 誤実行がユーザーや外部関係者に影響する |
| リソース作成、設定変更、削除 | 原則always | 変更・削除系は監査と人間の確認が必要 |
| 個人情報や機密情報を扱う検索 | alwaysに加えてログ確認 | データ露出のリスクがある |
承認フローは、単に「人間がOKを押す」仕組みではありません。承認画面やログには、少なくともツール名、引数、対象リソース、実行ユーザー、時刻を残すべきです。特に、自然言語の指示からツール呼び出しが生成されるため、「ユーザーの意図」と「実際に呼ばれる操作」が一致しているかを確認できるUIが重要です。
認証はProject connectionを中心に設計する
MCPサーバーの多くは認証を必要とします。Foundry Agent Serviceでは、APIキーやBearerトークンをアプリケーションコードに直接書くのではなく、Project connectionに保存して利用する方法が示されています。MCPツール側ではproject_connection_idを指定し、エージェントがMCPサーバーに接続する際にその認証情報を使います。 (Microsoft Learn)
公式の認証ドキュメントでは、主な方式としてキーベース認証、Microsoft Entra認証、OAuth identity passthrough、認証なしアクセスが整理されています。共有IDで利用するならキーベース認証やMicrosoft Entra認証、ユーザーごとの権限を維持したいならOAuth identity passthroughを検討します。 (Microsoft Learn)
| 認証方式 | 向いているケース | 注意点 |
|---|---|---|
| キーベース認証 | GitHub PATやAPIキーで共有接続する | Project connectionに保存した共有シークレットの閲覧権限を絞る |
| Microsoft Entra認証 | 社内AzureサービスやEntra対応MCPサーバーに接続する | エージェントIDまたはプロジェクト管理IDに適切なロールを付与する |
| OAuth identity passthrough | ユーザーごとの権限で外部サービスへ接続する | 同意リンク、ユーザー同意、テナント条件をアプリ側で扱う |
| 認証なし | 公開情報のみを返すMCPサーバー | 利用規約、レート制限、データ送信先を確認する |
管理者目線では、Microsoft Entra認証を使えるMCPサーバーでは、シークレット管理を減らせる利点があります。一方で、ユーザーごとのアクセス制御が必要な業務では、共有トークンで済ませると権限過多になりやすいため、OAuth identity passthroughを検討してください。
Public MCPとPrivate MCPの違い
MCP Server Endpointsには、パブリックに到達可能なエンドポイントと、インターネットに公開しないプライベートエンドポイントがあります。公式ドキュメントでは、Public endpointsはBasicとStandardの両方で利用できる一方、Private endpointsはStandard Agent Setup with private networkingと、仮想ネットワーク内の専用MCPサブネットが必要と説明されています。 (Microsoft Learn)
| 項目 | Public MCP | Private MCP |
|---|---|---|
| 接続先 | インターネットから到達可能なMCPサーバー | VNet内など非公開のMCPサーバー |
| Agent setup | Basic / Standard | Standard Agent Setupが必要 |
| 主な用途 | SaaS、公開API、外部MCPサービス | 社内API、機密データ、基幹システム |
| 管理ポイント | 外部送信、認証、利用規約 | VNet、DNS、サブネット、Private Link、権限 |
| 導入難度 | 低〜中 | 中〜高 |
Private MCPを使う場合、MCPサーバーはAzure Container Appsに内部専用イングレスでデプロイし、専用MCPサブネットをMicrosoft.App/environmentsに委任する構成が案内されています。Basic agent setupではPrivate MCP endpointsをサポートしないため、ネットワーク分離が必要な企業環境では、最初からStandard Agent Setupを前提に設計する必要があります。 (Microsoft Learn)
また、Foundry Agent Serviceのプライベートネットワーク構成では、パブリックエグレスをなくし、委任サブネット経由でAzureリソースへアクセスする設計が説明されています。ネットワーク分離を導入する場合は、Foundry本体だけでなく、Azure Storage、Azure AI Search、Azure Cosmos DBなどのBYOリソースやPrivate Endpoint、DNS解決まで含めて確認しましょう。 (Microsoft Learn)
Foundry ToolboxesをMCPエンドポイントとして使う意味
今回の更新で見逃せないのが、Foundry ToolboxesをMCP-compatible endpointとして使える点です。Foundry Toolboxesはプレビュー機能として、Web Search、Code Interpreter、File Search、Azure AI Search、MCP servers、OpenAPI tools、Agent-to-Agent connectionsなど複数のツールを1つのMCP互換エンドポイントにまとめられます。エージェント側は標準的なmcpツール構成で、server_urlとserver_labelを指定してToolbox endpointへ接続できます。 (Microsoft Learn)
これにより、エージェントごとに個別ツールを設定するのではなく、組織側で管理したToolboxを参照させる運用がしやすくなります。たとえば、営業支援エージェントには「社内FAQ検索、製品ドキュメント検索、Web検索」を束ねたToolbox、開発支援エージェントには「Azure DevOps、コード検索、仕様書検索」を束ねたToolboxを用意できます。
Foundry Toolboxesの強みは、ツール構成を変更してもエージェントコードを変更せずに済む点です。さらに、Toolbox endpointはFoundry Agent Serviceだけでなく、Microsoft Agent Framework、LangGraph、GitHub Copilot SDKなどのMCP対応クライアントでも利用できると説明されています。 (Microsoft Learn)
ただし、Toolboxはプレビュー機能です。運用では、次の点を事前に決めておくと安全です。
| 項目 | 推奨運用 |
|---|---|
| Toolbox名 | 業務用途が分かる名前にする。例：sales-support-tools |
| バージョン | 検証用バージョンと本番用default versionを分ける |
| 承認 | 書き込み系ツールは承認必須にする |
| 認証 | Toolbox側で集中管理し、個別エージェントに秘密情報を渡さない |
| 変更管理 | Tool追加・削除時に影響を受けるエージェント一覧を確認する |
Toolboxのバージョンは不変のスナップショットとして扱われ、MCP endpointはdefault_versionを提供します。新しいバージョンを作っても自動的に本番へ昇格するわけではなく、検証後にdefault versionへ昇格する流れです。これにより、本番エージェントに影響を与えずにツール構成を試せます。 (Microsoft Learn)
Azure DevOps MCP Serverを使う場合の注意点
公式ドキュメントでは、Azure DevOps MCP Serverがプレビューのカタログ項目として利用できることも説明されています。FoundryポータルのAdd ToolsからCatalogを開き、Azure DevOpsを検索して追加できます。組織接続時にAzure DevOpsへ認証し、利用するツールのサブセットを選択できるため、コード変更なしでエージェントにMCPツールを追加できます。 (Microsoft Learn)
実務では、Azure DevOps MCP Serverを「開発チーム向けに便利な検索ツール」としてだけ見ないことが重要です。Azure DevOpsには、リポジトリ、Work Items、Pull Request、Pipelineなど、開発プロセスに直結する情報や操作が含まれます。読み取りだけならまだしも、作成・更新・コメント投稿などの操作を許可する場合は、承認フローと監査ログを必ず組み合わせてください。
安全に始めるなら、最初は以下のように段階導入するのがおすすめです。
| フェーズ | 許可する操作 | 目的 |
|---|---|---|
| 検証 | 読み取り系ツールのみ | MCP接続、認証、応答品質を確認する |
| 限定展開 | 特定プロジェクトの読み取りと一部作成操作 | 実務効果と誤操作リスクを評価する |
| 本番 | 必要なツールのみallowed_toolsで許可 | 最小権限で運用する |
| 拡張 | 書き込み系操作を承認付きで追加 | 監査可能な形で自動化範囲を広げる |
カタログUIでツールのサブセットを選ぶことは、コードでallowed_toolsを指定するのと同じ考え方です。便利だから全部許可するのではなく、「エージェントが業務目的を達成するために本当に必要な操作だけ」を選んでください。 (Microsoft Learn)
ローカルMCPサーバーはそのまま接続できない
開発者がつまずきやすい点として、Foundry Agent ServiceはローカルMCPサーバーをそのまま参照するのではなく、リモートMCP server endpointを必要とします。公式ドキュメントでは、ローカルで開発したMCPサーバーやオープンソースのローカルMCPサーバーを使う場合、Azure Container AppsまたはAzure Functionsなどにホストして、リモートエンドポイントを用意する必要があると説明されています。 (Microsoft Learn)
特に検証段階では、手元のMCPサーバーが動いているだけで「Foundryからも使える」と誤解しがちです。Foundry側から到達可能なHTTPエンドポイント、認証、TLS、ネットワーク経路、レスポンスタイムを確認してください。
| ホスティング候補 | 向いているケース | 注意点 |
|---|---|---|
| Azure Container Apps | 任意の言語・依存関係でMCPサーバーを動かしたい | Linux amd64、依存関係の同梱、ステートレス設計が必要 |
| Azure Functions | 軽量なHTTP処理として公開したい | 一部機能や認証方式に制約がある |
| App Serviceなど | 既存運用基盤を使いたい | 公式に検証済み構成とは限らない |
Private MCPでは、Azure Container Appsの内部専用イングレスと専用MCPサブネットが案内されています。Function AppsやApp ServicesでPrivate MCPをホストできる可能性はあっても、公式ドキュメントでは内部検証済み構成としては扱われていません。 (Microsoft Learn)
既存エージェントから移行・展開する時のチェックリスト
すでにAzure AI Foundryでエージェントを運用している場合、MCPを追加する前に次の順番で確認すると失敗しにくくなります。
接続先の棚卸し
まず、接続予定のMCPサーバーを一覧化します。GitHub、Azure DevOps、社内API、外部SaaS、Foundry Toolboxなど、接続先ごとにデータ分類と操作権限を分けてください。
確認項目は次の通りです。
| 確認項目 | 例 |
|---|---|
| 接続先の運営者 | Microsoft、社内チーム、外部ベンダー |
| 扱うデータ | 公開情報、社内限定情報、個人情報、機密情報 |
| 操作範囲 | 読み取り、作成、更新、削除 |
| 認証方式 | Entra、OAuth、APIキー、PAT |
| ログ取得 | Foundry側、MCPサーバー側、外部サービス側 |
非MicrosoftのMCPサーバーを使う場合は、プロンプト内容やアプリケーションデータが外部サービスに渡る可能性があります。社内規定上、外部AIサービスやSaaSへのデータ送信に制限がある場合は、MCPサーバーの接続も同じ審査対象にしてください。 (Microsoft Learn)
認証と権限の設計
次に、認証方式を決めます。共有トークンで簡単に始めると、誰の操作か分かりにくくなり、権限も広がりがちです。ユーザーごとの権限を維持したい業務ではOAuth identity passthroughを検討してください。Microsoft Entra対応の社内サービスなら、エージェントIDやプロジェクト管理IDに必要最小限のロールを付与する設計が有効です。 (Microsoft Learn)
特にProject connectionに保存する認証情報は、プロジェクトにアクセスできるユーザーが扱える可能性があります。共有シークレットを保存するプロジェクトは、参加者を最小限に絞り、トークンのローテーション手順も決めておきましょう。
allowed_toolsで最小権限にする
MCPサーバーは複数のツールを公開できます。エージェントに全ツールを使わせる必要はありません。allowed_toolsを使って、業務に必要なツールだけを許可します。
たとえば、社内FAQを検索するエージェントなら、search_docsやget_articleだけで十分かもしれません。create_ticketやdelete_recordのような操作系ツールは、別エージェントに分けるか、承認必須にするのが安全です。
承認フローを本番UIに組み込む
検証コードでは、コンソール上で承認する例が示されています。しかし本番アプリでは、ユーザーが自然に確認できるUIを用意する必要があります。
承認画面には、少なくとも次の情報を表示しましょう。
| 表示項目 | 理由 |
|---|---|
| 実行予定のツール名 | 何が呼ばれるかをユーザーが理解するため |
| 引数の内容 | 対象リソースや送信内容を確認するため |
| 影響範囲 | 読み取りか、作成・更新・削除かを判断するため |
| 承認・拒否ボタン | ユーザーが明示的に判断するため |
| ログ記録の有無 | 監査対象であることを明確にするため |
承認後は、previous_response_idとapproval_request_idを使って処理を継続します。この対応を忘れると、エージェントが承認後に進まないトラブルにつながります。 (Microsoft Learn)
よくあるエラーと対処法
MCP接続では、設定ミスやスキーマの不一致でエラーが起きやすくなります。公式ドキュメントでも、Invalid tool schema、Unauthorized、モデルがMCPツールを呼ばない、承認後に処理が続かないといった例が挙げられています。 (Microsoft Learn)
| 症状 | 主な原因 | 対処 |
|---|---|---|
Invalid tool schemaが出る | MCPサーバー定義にanyOf、allOf、複数型パラメーターが含まれる | ツールスキーマを単純化して再登録する |
UnauthorizedまたはForbidden | トークン期限切れ、ヘッダー名違い、権限不足 | Project connectionの認証情報とMCPサーバー仕様を確認する |
| モデルがMCPツールを呼ばない | instructionsが曖昧、allowed_toolsの名前不一致 | エージェント指示、server_label、ツール名を見直す |
| 承認後に続行しない | previous_response_idやapproval_request_idの指定ミス | 承認リクエストのIDを使ってフォローアップレスポンスを送る |
| Private MCPに到達できない | 専用MCPサブネット、DNS、委任設定の不備 | VNet、Private DNS、Microsoft.App/environments委任を確認する |
| 処理がタイムアウトする | MCPサーバー側の応答が遅い | 100秒以内に応答するよう処理を分割・最適化する |
非ストリーミングのMCP tool callには100秒のタイムアウトがあります。長時間かかる処理を1回のMCP呼び出しに詰め込むと失敗しやすいため、検索、計算、更新などを小さな操作に分割する設計が必要です。 (Microsoft Learn)
本番展開前に決めておくべき運用ルール
MCP Server Endpointsを安全に使うには、技術設定だけでなく運用ルールが必要です。次のルールを事前に決めておくと、後からの混乱を避けられます。
MCPサーバーの許可リストを作る
誰でも任意のMCPサーバーを追加できる状態は避けてください。接続可能なMCPサーバーを許可リスト化し、申請・審査・承認の流れを作ります。
許可リストには、次の情報を記録します。
| 項目 | 記録例 |
|---|---|
| MCPサーバー名 | GitHub MCP Server、社内検索MCP |
| URL | 本番・検証のエンドポイント |
| 管理者 | 社内担当チームまたは外部ベンダー |
| 認証方式 | Entra、OAuth、APIキー |
| 許可ツール | search_docs、get_issueなど |
| 承認要否 | 常時承認、一部承認、不要 |
| データ分類 | 公開、社内、機密 |
書き込み系ツールは別扱いにする
読み取り系ツールと書き込み系ツールは、同じポリシーで扱わないでください。チケット作成、コメント投稿、リソース変更、削除などは、ユーザーの自然言語指示が曖昧なまま実行されるとトラブルになります。
書き込み系ツールを使う場合は、次の条件を満たしてから本番化するのが安全です。
allowed_toolsで対象ツールを明示的に制限するrequire_approvalをalwaysまたは対象ツールのみ承認必須にする- 実行前に操作内容をユーザーに表示する
- 実行ログと承認ログを保存する
- 失敗時・拒否時のメッセージを用意する
検証環境と本番環境を分ける
MCPサーバーは外部システムを操作できるため、検証と本番の混在は危険です。server_url、Project connection、Toolbox versionを環境ごとに分け、検証用エージェントが本番データを更新しないようにしましょう。
Foundry Toolboxesを使う場合は、version-specific endpointで新しいバージョンを検証し、問題がなければdefault versionへ昇格する流れが適しています。 (Microsoft Learn)
開発者向けの最小構成イメージ
実装の考え方はシンプルです。エージェントにMCPツールを追加し、必要に応じてProject connectionと承認フローを組み込みます。
{
"type": "mcp",
"server_label": "internal-docs",
"server_url": "https://example.com/mcp",
"allowed_tools": ["search_docs", "get_doc"],
"require_approval": "always",
"project_connection_id": "internal-docs-connection"
}この例では、エージェントが使えるツールをsearch_docsとget_docに限定し、すべての呼び出しで承認を求めています。実際の本番コードでは、承認リクエストをユーザーに表示し、承認・拒否の結果をレスポンスAPIへ返す処理が必要です。
読み取り専用の検索ツールで十分に検証できたら、対象ツールだけ承認不要にすることも検討できます。ただし、最初からrequire_approvalをneverにするのは避けましょう。まずは呼び出しログを確認し、エージェントがどのようなタイミングでどのツールを使うかを把握することが大切です。
導入判断の目安
Azure AI FoundryのMCP Server Endpointsは、すべてのエージェントにすぐ導入すべき機能ではありません。向いているケースと慎重に進めるべきケースを分けて考えると判断しやすくなります。
| 判断 | 向いている条件 |
|---|---|
| 早期に検証すべき | 外部ツール連携を個別APIで多数実装している、社内検索やDevOps連携を標準化したい |
| 小さく始めるべき | GitHub、Azure DevOps、社内FAQなど読み取り中心の業務で使いたい |
| 慎重に設計すべき | 個人情報、機密情報、顧客データ、基幹システムに接続する |
| まだ待つべき | 監査ログ、承認UI、MCPサーバーの管理責任者が決まっていない |
特に、Foundry Toolboxesは複数ツールを束ねられるため、組織横断の標準ツール基盤として有効です。一方で、Toolboxの中身を誰が管理し、どのバージョンを本番に昇格するかを決めないまま使うと、エージェントの挙動が分かりにくくなります。
まず実施すべきアクション
Azure AI FoundryでMCP Server Endpointsを使うなら、最初の一歩はコードを書くことではなく、接続方針を決めることです。
まず、利用したいMCPサーバーを1つ選び、読み取り専用ツールに限定して検証します。次に、Project connectionで認証情報を管理し、allowed_toolsで利用ツールを絞り、require_approvalを有効にした状態でエージェントの挙動を確認します。Private MCPが必要な場合は、Basic agent setupではなくStandard Agent Setup、専用MCPサブネット、Azure Container Appsの内部専用イングレスまで含めて設計してください。
最終的には、以下の4点が揃ってから本番展開するのが安全です。
- 接続を許可するMCPサーバーが明確になっている
- 認証方式とProject connectionの管理ルールが決まっている
allowed_toolsとrequire_approvalで最小権限・承認フローを実装している- ログ、監査、Toolboxバージョン管理、障害時対応の運用手順がある
MCPは、Azure AI Foundryのエージェントを単なるチャット応答から、実システムと連携する業務エージェントへ進化させる重要な仕組みです。ただし、外部ツールに接続できるということは、誤操作やデータ送信のリスクも増えるということです。管理者と開発者が同じ設定項目を見ながら、小さく検証し、権限を絞り、承認と監査を組み込んで展開することが成功の近道です。
コメント