🔒

エンタープライズにおけるDify×MCPのガバナンス

に公開

こんにちは、本田です。

今回はDifyでMCPを利用するにあたり、企業が留意するべきことをまとめました。

1. はじめに:MCP活用におけるガバナンスの必要性

Dify × MCP とは

Model Context Protocol(MCP)は 「AI 界の USB-C」 と呼ばれる標準プロトコルで、LLM が外部ツールやデータソースと自律的に通信して処理をする(AIエージェント的な)機能を実現するために使われる技術です。

Dify × MCP のパターン
Dify が MCP Client を担う場合

  • Zapier, Slack, Firecrawl 等が提供し、外部 MCP サーバーを利用
  • Dify アプリ内の LLM が Zapier に登録したツールリストから必要なツールを自律的に選択・実行できる

Dify が MCP Server を担う場合

  • Dify アプリをツールとして公開し、Cursor, Claude Desktop などから呼び出せる
  • Cursor, Claude 内の LLM が 自律的に判断して Difyアプリを実行できる

こうした機能は Dify × MCP の組み合わせによって実現し、タスクの代行能力が飛躍的に向上します。

とはいえ、Dify 単体と比べてガバナンスに注意するべき

Dify に MCP 機能を導入すると統合範囲が拡大し、攻撃対象領域も広がります。
したがって 堅牢でカスタマイズ可能なガバナンスフレームワーク が不可欠です。

本稿では、
(既にDify Saas/OSS版を導入している)企業のAI/DX推進, IT企画担当の方等に向けて、
「Dify MCP(クライアント/サーバー両役割)利用に関するガバナンス」をスコープとして、

  • ツール選定基準
  • 導入・運用時の注意点
  • 必要な体制・プロセス・ルール
    を体系立てて提示します。

2. 全体像の理解:Dify・MCP とエンタープライズの課題

さて、DifyにMCPを導入する上で、どんな課題があるのか、まずは全体像をつかんでいきましょう。

主なガバナンスの論点

  1. Dify のバージョン管理(OSS版の場合)
    ※OSS版の場合、エージェントノードが使えるv1.0以降でないとMCPを利用できません。

  2. 要件に応じたプラグイン選定:Dify × MCP を連携するために必要
    <Dify が MCP Client を担う場合>

    • MCP SSE Plugin(Tool 型):単発アクションを実行
    • MCP Agent Strategy(Agent-Strategy 型):ロジックを考えながら複数アクションを実行

    <Dify が MCP Server を担う場合>

    • mcp-server(Extension 型):Cursor, Claude Desktop 等から呼び出せる
  3. 外部MCPツールのセキュリティ(TPRM: Third-Party Risk Management)

    • Zapier などの外部サービスと連携する場合、そのサービス自体のセキュリティチェックは必須です。
    • 加えて、特に Zapier MCP, Composio MCP のようなアプリ連携ハブ型の MCP Server の場合、その先に連携している数千(Zapierなら7,000以上!)のアプリのリスクも間接的に負うことになります。(これを Nth-Party リスクと呼びます)連携するアプリ一つひとつに対してセキュリティチェック体制を敷くなどが必要です。
    • また、個人情報や機密情報の入力に関して、許容範囲を規定する等も行うべきです。
  4. エージェント自律性リスク

    • AIが自律的にツールを使うのは便利ですが、「意図せず実行して問題を起こす」などが考えられます。
    • 人間の確認や、問題が起きたときの責任の所在をどうするか考える必要があります。
  5. 可観測性ギャップ

    • AIやツールが内部で何をやっているのか、ちゃんと監視できていますか?
    • Langfuseのようなログ観測外部ツールと連携して、動きを可視化する必要があります。
  6. データプライバシー
    個人情報や機密情報を扱う場合、データの暗号化や、アクセス権限を最小限に絞る(最小権限)等対策するべきです。

  7. 運用上の依存性
    (言い出したらキリがないですが)連携先のサービスが停止したら、自社の業務も止まってしまう可能性があります。

3. ガードレールの定義:評価基準を決める

Dify で外部ツールやMCP連携を使うにあたって、「何でもOK」というわけにはいきません。安全に活用するために、利用できるツールや連携の「ガードレール」、つまり承認ルールを明確にしましょう。
※3~5. は厳密な話が続きます。いきなりここまで整備する必要はないので、これから検討する方はまず6. を確認してください。

まず、どんな基準でツールや連携を評価するかを決めます。
シーン: 例えば、Zappier MCP でメール(Gmail等)の送信機能を有効化する場面を想像してみましょう。

評価のポイント例

  • セキュリティ体制:そのツールやサービスは、セキュリティ認証(SOC 2やISO 27001など)を取得しているか?
  • データ処理とプライバシー:データの扱いは適切か? 暗号化されているか? プライバシーポリシーやデータ処理契約(DPA)はしっかりしているか?
  • 機能性とビジネス必然性:本当に必要な機能か? 導入することで明確なメリットがあるか?
  • 運用安定性:安定して動作するか? サービスレベル保証(SLA)やサポート体制はあるか?
  • プラグイン固有:どんな権限を要求しているか? 開発元は信頼できるか?(署名の確認など)
  • MCP 固有:プロトコルに準拠しているか? どのような認証方式を採用しているか?

4. 実装のナビゲーション:主要な考慮事項と注意事項

ガードレールが決まったら、いよいよ導入と運用です。ここでは、特に注意すべき点を整理します。

セキュリティ体制管理

  • 認証・認可:誰がシステムにアクセスでき、何をして良いかを厳格に管理しましょう。役割ベースのアクセス制御(RBAC)を基本とし、必要に応じて属性ベース(ABAC)やクライアント証明書(mTLS)なども検討します。
  • API キー管理:APIキーやパスワードなどの「秘密情報」は、専用の金庫(シークレットマネージャー)で安全に保管し、定期的に鍵を交換(ローテーション)しましょう。
  • プラグイン署名/ランタイム分離:利用するプラグインは、信頼できる発行元による署名があるか確認しましょう。また、プラグインが他のシステムに悪影響を与えないよう、隔離された環境で動かす(ランタイム分離)ことも検討します。
  • ネットワークセキュリティ:システム間の通信経路を適切に分割(ネットワークセグメンテーション)し、通信は必ず暗号化(TLS)しましょう。

データプライバシーとコンプライアンス

  • データ分類・マッピング:扱うデータがどんな種類で、どこに保管され、誰がアクセスするのかを把握し、機密レベルに応じて分類しましょう。
  • 契約とプロセス:外部サービスと連携する場合は、データ処理に関する契約(DPA)を締結します。また、個人からのデータ開示請求など(DSARフロー)に対応できるプロセスを整備しておきましょう。
  • 連携先の準拠確認:連携先のサービスが、関連する法規制(GDPR、日本の個人情報保護法など)を遵守しているか確認しましょう。

システムプロンプトガバナンス

  • アクセス制御とバージョン管理:AIへの指示(プロンプト)も重要な情報資産です。誰が編集できるかを管理し、変更履歴はGitなどでしっかり管理しましょう。
  • レビューとテスト:作成したプロンプトは、意図通りに機能するか、セキュリティ上の問題はないかなどをレビューし、十分にテストしてから本番環境に適用しましょう。

TPRM 統合

  • 継続的な監視:連携している外部サービス(ベンダー)をリスト化し、定期的にリスク評価を行い、継続的に監視するプロセスを確立しましょう。
  • 標準化された評価:リスク評価には、業界標準の質問票(SIG: Standardized Information Gathering Questionnaire や CAIQ: Consensus Assessments Initiative Questionnaire など)を活用すると効率的です。
  • 契約への反映:契約書には、セキュリティ要件、サービスレベル保証(SLA)、監査権(必要に応じて立ち入り調査などを行える権利)などを明確に記載しましょう。

一歩進んだガバナンス

  • 動的アクセス制御:AIエージェントが実行するタスクに応じて、その時必要な最小限の権限だけを動的に付与する仕組みを検討します。
  • プロンプトエンジニアリングの活用:プロンプトの設計段階で、不正な利用を防いだり、特定の操作を制限したりするなど、プロンプト自体をガバナンスの制御点として活用することも考えられます。

5. 基盤の構築:不可欠なメカニズム・運用・ルール

Dify MCPを組織全体で安全かつ効果的に活用するためには、しっかりとした土台、つまり、それを支える体制、運用プロセス、そして明確なルール作りが不可欠です。

既存ガバナンスフレームワークとの整合

ゼロから作る必要はありません。すでに社内にあるIT管理の仕組みやルールと連携させましょう。

  • ITIL / COBIT:変更管理、インシデント対応、サービスデスクなどの既存プロセスを活用します。
  • NIST CSF + NIST AI RMF:セキュリティ対策の標準的な考え方(特定、防御、検知、対応、復旧)や、AI特有のリスク管理フレームワークを参考にします。
  • クラウドガバナンス:クラウド利用に関する既存のルール(集中監視、ID・アクセス管理(IAM)、コスト管理など)をDifyの運用にも適用します。

ポリシーと手順

具体的なルールを文書化し、関係者全員が理解できるようにします。

  • 利用規定:Difyや連携ツールの適切な利用方法、禁止事項などを定めます (Acceptable Use Policy)。
  • データ処理手順:データの分類、アクセス権限、保管期間などのルールを明確にします。
  • APIセキュリティポリシー:APIキーの管理方法、アクセス制御、利用状況の監視などに関するルールを定めます。
  • プロンプト管理手順:プロンプトの作成、レビュー、テスト、承認、バージョン管理などのプロセスを定義します。
  • インシデント対応計画:プラグインの脆弱性発見時、プロンプトインジェクション攻撃を受けた場合など、問題発生時の対応手順を事前に準備しておきます。
  • 変更管理フロー:Difyの設定、プラグインの追加・更新、プロンプトの変更などを行う際の申請、承認、実装、テスト、リリースといった一連の手順を厳格に定めます。

役割と責任

誰が何に対して責任を持つのかを明確に定義します。(以下例)

役割 主な責務
プラットフォームオーナー Difyプラットフォーム全体の運用管理、アップデート、設定変更の管理
プロンプトエンジニア 効果的で安全なプロンプトの設計、レビュー、テスト、最適化
セキュリティチーム ツールや連携のリスク評価(TPRM)、セキュリティ監査、インシデント対応の主導
コンプライアンス担当 法令・規制の遵守状況の確認、データプライバシー保護に関する助言・指導
リスク管理/法務 契約内容のレビュー、リスク許容度の設定、法的アドバイス
内部監査 定期的な監査を通じて、定められたガバナンスルールが有効に機能しているか評価

監視・ロギング・監査

システムの動作状況や利用状況を常に把握し、問題の早期発見や原因究明に役立てます。

  • 集中ログ管理:Difyや連携ツールのログをSIEM(Security Information and Event Management)などのツールに集約し、一元的に監視できるようにします。LangfuseのようなAIアプリケーション向けの観測ツールも活用しましょう。
  • 自動アラートと監査:異常なアクティビティやポリシー違反を検知したら自動で通知(アラート)が飛ぶように設定します。また、定期的に監査を実施し、操作履歴(監査トレイル)を確認できるようにします。

調達・検証の統合

新しいツールやサービスを導入するプロセスに、AI特有のリスク評価を組み込みます。

  • AI-TPRMの必須化:ソフトウェアやSaaSを導入する際の既存の調達・購買プロセスに、AIツールや連携サービスに特化した第三者リスク評価(TPRM)を必須項目として追加します。
  • 評価基準の拡張:標準的なリスク評価質問票(SIG/CAIQなど)を、AIの特性(学習データ、モデルの公平性、プロンプトインジェクション耐性など)を考慮した項目で拡張します。

変更管理

Difyの設定、プラグイン、MCP連携、プロンプトなど、システム構成要素への変更は、安全かつ確実に実施する必要があります。

  • CI/CDとの統合:可能であれば、構成変更やプロンプトの更新などを、CI/CD(継続的インテグレーション/継続的デリバリー)パイプラインに組み込み、テストや承認プロセスを自動化・標準化します。
  • ロールバック計画:変更後に問題が発生した場合に備え、迅速に変更前の状態に戻せる手順(ロールバック計画)を必ず用意しておきましょう。

6. 結論:まずは小さいところから始めよう

さて、ここまでDifyとMCPを企業で活用する上でのガバナンスについて、様々な角度から見てきました。
こうしてみるとかなり大がかりに感じますが、最初からここまで整える必要はありません。

企業がDify MCPのパワフルな機能を安全かつ効果的に活用するためには、以下の4つがガバナンスの柱となります。

■ ガバナンスの柱

  1. ツール検証:利用するプラグインやMCP連携サービスは信頼できるものか?
  2. セキュリティ:不正アクセス、データ漏洩、意図しない操作のリスクは管理されているか?
  3. コンプライアンス:関連する法規制や社内ルールを遵守できているか?
  4. 可観測性:システムやAIが何を行っているのか、適切に監視・追跡できているか?

■ スモールスタートモデル

  1. (Dify OSS版を利用する場合)自社のDifyを v1.0 以降のモデルに更新する。
  2. 社内のAI・DX推進担当とセキュリティ担当が話し合って、MCP SSE Plugin, MCP Agent Strategy, mcp-server の3つのプラグインを最低限の運用ルールとセットで有効化する。
  3. Zapier MCP などアプリ連携ハブ型の MCP にトライアルして、2~3件のユースケースを開発環境で実装する。
  4. その過程で、まず該当 MCP に関して連携ツールを増やす場合のルールを「4つの柱」を基に定めておき、運用しながら更新/他の MCP サービスにも横展開していく。

AI技術も、ビジネスを取り巻く環境も、日々進化し続けています。したがって、一度構築したガバナンスのフレームワークも、定期的に見直し、変化に合わせて改善し続けることが不可欠です。

Dify MCPの可能性を最大限に引き出すためには、導入の初期段階から、明確な意図を持って、包括的で、かつ変化に柔軟に対応できるガバナンス戦略を策定し、実行していくことが何よりも重要です。これにより、リスクを賢く管理しながら、ビジネス価値の創出を加速させることができるでしょう。

7. 参考

https://github.com/hjlarry/dify-plugin-mcp_server/blob/main/README.md?utm_source=chatgpt.com

https://github.com/hjlarry/dify-plugin-mcp_server?utm_source=chatgpt.com

https://github.com/hjlarry/dify-plugin-mcp_server/blob/main/GUIDE.md?utm_source=chatgpt.com

https://docs.dify.ai/ja-jp/plugins/best-practice/how-to-use-mcp-zapier?utm_source=chatgpt.com

https://qiita.com/DifyJapan/items/c23f703f5ed3c8abcb0c?utm_source=chatgpt.com

https://dify.ai/blog/turn-your-dify-app-into-an-mcp-server?utm_source=chatgpt.com

UPGRADE tech blog

Discussion