DifyのワークフローをMCP（Model Context Protocol）として公開し、Claudeから利用する試みで、試行錯誤の上に、ついに成功を収めることができました。しかし、その過程で発見した重要なポイントがあります。それは「日本語はダメ」という、一見すると意外な制約でした。

今回の成功事例では、YouTubeから適切なクエリを持ってきて回答するワークフローを構築しました。例えば「Claudeについての最新ニュースを紹介して」と入力すると、MCPとして設定された「get_data_from_youtube_log」がClaudeから呼び出され、Dify側でGemini 2.5がクエリを最適化し、ログから検索してQ&Aでデータを取得するという仕組みです。

MCP連携の仕組みと実際の動作

MCPを通じてDifyのワークフローをClaudeから呼び出すと、以下のような処理フローが実行されます：

• Claude側：ユーザーの質問を受け取り、適切なMCPツールを選択
• Dify側：Claudeからの入力を受け取り、Gemini 2.5がクエリを分析・最適化
• データ取得：YouTubeログから関連情報を検索し、Q&A形式でデータを抽出
• 結果返却：取得したデータをClaude経由でユーザーに提供

実際の動作では、若干の処理時間はかかりますが、外部の処理をMCPで導入できることの価値は非常に大きいと感じています。取得されるデータには動画のタイトルや内容が含まれ、元データはIDで管理されているため、プロンプトで「YouTubeリンクにして」と指示することで、適切な形式での連携も可能です。

失敗の原因：日本語とワークフロー名の制約

前回の動画でDifyをMCP活用する際に失敗した原因は、実は非常にシンプルでした。問題はワークフロー名が日本語になっていたことです。

DifyのMCP連携における制約は以下の通りです：

1. ワークフロー説明文の言語制約

ワークフローを作成する際、説明欄でMCPのパラメータやデータ形式を記述しますが、この説明文が日本語だとバグが発生します。MCPの仕様上、英語での記述が必要となります。

2. ワークフロー名の命名規則

ワークフロー名には厳格な制約があります：

• 小文字のみ使用可能
• ハイフン（-）またはアンダースコア（_）のみ使用可能
• 64文字以内

この制約の背景には、DifyのMCP設定における技術的な仕様があります。コネクタ設定で使用される「ツール名」が、作成したワークフロー名と完全に一致する仕様になっているためです。つまり、ワークフロー名 = ツール名という関係性があり、ツール名の制限がそのままワークフロー名の制限となっています。

正しい設定方法と注意点

成功するためのポイントを整理すると：

設定項目	正しい設定	NGな設定例
ワークフロー名	get_data_from_youtube_log	YouTubeデータ取得、youtube-データ-取得
説明文言語	英語で記述	日本語で記述
文字数制限	64文字以内	65文字以上

これらの制約を守ることで、DifyのワークフローをMCPとして公開し、Claudeから問題なく利用することができるようになります。

MCP連携がもたらす可能性の拡大

今回の成功により、DifyのワークフローをMCPとして簡単に公開し、Claudeから使用することができるようになりました。これにより、打ち手が大幅に広がると考えています。

具体的なメリットとしては：

• 外部処理の統合：複雑な処理をDify側で実行し、結果をClaudeで活用
• 手軽な公開機能：一度設定すれば、簡単にワークフローを外部から利用可能
• 柔軟な連携：Claude以外のMCP対応ツールからも利用可能

ただし、導入直後は認識に時間がかかったり、若干の挙動の不安定さがある場合もあります。それでも、手軽に公開できる利便性を考えると、今後の可能性は非常に高いと感じています。

まとめ

改めて、DifyワークフローのMCP連携成功のポイントは以下の通りです：

• ワークフロー名は英数字・ハイフン・アンダースコアのみ使用
• 説明文は英語で記述する
• 64文字以内の命名制限を守る
• ツール名とワークフロー名が一致する仕様を理解する
• 導入後の認識遅延や挙動の不安定さを想定した運用を行う

これらの制約を理解し適切に設定することで、DifyとClaudeの強力な連携が実現でき、AI活用の幅が大きく広がります。特に、複雑な外部処理をDify側で実行し、その結果をClaudeの自然言語処理能力と組み合わせることで、従来では困難だった高度なAIアプリケーションの構築が可能になります。

---

---

■合わせて読みたい

■関連記事