概要

Claude Codeのskill機能を使い、自然言語の要件からDifyワークフローのDSL（YAML）を自動生成するskillsを作った。
https://github.com/amenohabakiri-hue/dify-generator-skill/tree/main

AIが生成したYAMLをルールベースの静的解析で検証し、Dify OSSへのインポートテストで最終確認するテスト駆動開発（TDD)方式を採用し、DSLファイルそのもののエラー率を下げた。
OSS版で通ってもクラウド版でGUIがクラッシュするケースがあるため、Cloud互換バリデータも用意
完全自動ではないが、GUIポチポチで数十分かかるワークフロー構築が自然言語 → YAML → インポートの流れで大幅に短縮できる

何故Difyの自動生成に取り組んだか？

Difyの利点として、以下の二点がある。

非エンジニアでも開発・メンテナンスしやすいこと、
定常業務でルールベースに作りたい場合はアウトプットの精度に揺らぎが生じやすいAIエージェントよりも運用として安定すること

とはいえ、difyでワークフローを作成するには一定程度作り方を知る必要があるのと、やりたいことによっては構築するのにGUIで作るのでは時間がかかる操作もある。
そして、DSLを取り込めばワークフローが生成できるものの、その構文自体は公式で厳密に公開されているわけではなく、完全な生成には難しいところもあった。

そこで、OSSのソースコードやドキュメントを参考とした静的解析と、OSS版をインポートテストの基盤として利用することで、AIのみで自律的にコード検証とフィードバックを行い、品質を担保するアプローチを採った。

技術スタックと選定理由

なぜこの構成か？

Dify OSSをフルで立ち上げると今回使わない機能まで構築してしまい、Docker全体で数GBのメモリを消費する。今回の目的は「AIが生成したDSLが正しくインポートできるかのテスト」であり、ワークフローを実行する必要はない。よって、PostgreSQL + Redisだけの最小構成でAPIサーバーを動かし、インポートの成否だけを確認する方式にした。

一覧

カテゴリ	技術	選定理由
AI生成	Claude Code + skills	SKILL.mdにルールを書けばスキル発動時に毎回参照される。プロンプトの外出し管理
DSL形式	YAML (DSL version 0.6.0)	Difyのインポート/エクスポート形式そのもの。
静的解析	Python + Pydantic	Dify本体のPydanticモデルを直接importして型検証。スキーマの二重管理が不要
ランタイム	Dify OSS (Flask, port 5001)	Cloud APIにはインポート用エンドポイントがない。OSSならローカルで自由にテスト可能
ミドルウェア	Docker (PostgreSQL + Redis)	最小構成。APIテストに特化
実行環境	WSL2 Ubuntu 24.04	Dify APIサーバーはLinux前提。Windows上ではWSL2経由で動かす
テスト	pytest	YAML構造バリデーション + APIインポートテストを `pytest tests/ -v` で一発実行

Windows上での環境構築

全体構成

Windows側でYAML生成・静的解析・テスト実行、Docker DesktopでDB、WSL2でDify APIサーバーという分担。

Step 1: Dify OSSのソースを取得

Dify OSSを取得する。
※インストールされていない方はdocker desktopとubuntuをあらかじめインストール+起動しておくこと。

cd C:\Users\user\Desktop
git clone https://github.com/langgenius/dify.git

Step 2: Docker Desktopでミドルウェア起動

Docker Desktopの設定でWSL2統合を有効化しておく。
PostgreSQLとRedisだけに絞る

docker compose -f docker-compose.middleware.yaml --env-file middleware.env \
  up -d docker-db_postgres-1 docker-redis-1

これでメモリ消費は数百MB程度に抑えられる。

Step 3: WSL2でDify APIサーバー起動

wsl -d Ubuntu-24.04

# Pythonパッケージマネージャ（uv推奨）
curl -LsSf https://astral.sh/uv/install.sh | sh
source $HOME/.local/bin/env

# Dify API の依存インストール＆起動
cd ~/dify/api
uv run flask run --host 0.0.0.0 --port=5001 --debug

Running on http://127.0.0.1:5001 が出ればOK。WindowsからもWSL2のポートフォワーディングにより http://localhost:5001 でアクセスできる。

Step 4: Python環境

pip install pytest pyyaml requests python-dotenv pydantic

Step 5: 環境変数の設定

プロジェクトルートに .env を作成：

DIFY_BASE_URL=http://localhost:5001
DIFY_CONSOLE_EMAIL=your-email@example.com
DIFY_CONSOLE_PASSWORD=your-password

注意: Difyの認証はBase64エンコードが必要だが、テストスクリプトが自動でエンコードするため.envにはプレーンテキストで書く。

Step 6: 動作確認

# YAML構造テスト（API不要）
pytest tests/test_import.py::test_yaml_structure -v

# APIインポートテスト（Dify起動中のみ）
pytest tests/test_import.py::test_import_workflow -v

tests/test_import.py::test_yaml_structure PASSED  [ 50%]
tests/test_import.py::test_import_workflow PASSED  [100%]
============================= 2 passed in 12.26s ==============================

各アーキテクチャ解説

全体フロー

SKILL.mdの役割

Claude Codeのskillは SKILL.md に生成ルールを記述する仕組み。このプロジェクトでは以下を定義している：

モード選択ルール — workflow / advanced-chat / chat の判定基準
ノードIDの採番規則 — タイムスタンプベースの文字列ID ("1732000001")
エッジのReact Flowメタデータ — isInIteration, isInLoop, zIndex の必須設定
20項目の品質チェックリスト — version形式、コメント禁止、LLM vision構造等
Cloud互換ルール — OSSでは通るがCloudでGUIがクラッシュする6パターンの回避策

これにより、AIは「何となくそれっぽいYAML」ではなく Difyのパーサーが受け入れる正確なフォーマット で出力する。

ワークフロー生成例（email_triage_workflow）

自然言語で作りたいワークフローをこちらに記載


**「問い合わせメールを自動で仕分けして、一次対応文案まで作るワークフロー」**

流れはこう。

1. **メール受信**

   * 件名、本文、送信元、添付有無を取得

2. **前処理**

   * 署名除去
   * 文字化けや改行整理
   * 個人情報らしき文字列をマスク候補として抽出

3. **問い合わせ分類**

   * 「障害報告」
   * 「料金・契約」
   * 「操作方法」
   * 「要望」
   * 「クレーム」
   * 「その他」
     にAIで分類

4. **緊急度判定**

   * “業務停止”“至急”“全員使えない”みたいな文言を見て
   * 高 / 中 / 低 に分岐

5. **顧客属性照合**

   * 送信元メールアドレスをDBやCSVと照合
   * 契約プラン
   * 担当営業
   * 過去問い合わせ件数
   * VIP顧客か
     を引く

6. **過去事例検索**

   * FAQ
   * 過去チケット
   * 社内ナレッジ
     を検索して、類似ケース上位3件を取得

7. **対応方針分岐**

   * 障害報告 × 緊急高 → 即エスカレーション
   * 操作方法 × 類似FAQあり → FAQベースで返信案作成
   * クレーム → 人間承認必須
   * 契約変更 → 営業担当へ転送

8. **返信文案生成**

   * 丁寧版
   * 簡潔版
   * 社内確認待ち版
     の3パターン生成

9. **リスクチェック**

   * 誤情報
   * 断定表現
   * 返金確約など危険表現
     をルールベースで弾く

10. **担当者承認**

* Slack/Teamsに要約送信
* 「送信」「修正」「保留」を選ばせる

11. **送信後処理**

* チケット発行
* 類似カテゴリとして保存
* KPI記録（初回応答時間、分類精度など）

DSLがアウトプットとして出力され、クラウド版で読み込むとGUI上に以下のように生成される。

クラウド版でのGUI

プロンプト、各変数も入っているのが確認できる。

手動でやるべきこと

自動化できない/すべきでない部分は以下の通り。

作業	理由
Dify OSSのローカル環境構築	Docker + WSL2 + PostgreSQL + Redis の初期セットアップは一度だけ手動で行う
GUI上での最終動作確認	ノード間の変数参照やプロンプトの挙動はGUIで実行して目視確認が必要
クラウド版へのインポート確認	OSS版とクラウド版でフロントエンドの挙動が異なるケースがあり、最終的にはクラウド側でも確認が望ましい
プロンプトのチューニング	LLMノードのプロンプト品質はAI生成のままでは不十分な場合があり、要件に応じた調整が必要

アウトプット

生成されるのは .yml ファイル1つ。Difyの「DSLファイルをインポート」からそのまま取り込める。

# 生成されるYAMLの構造（概要）
app:
  mode: workflow
  name: "email-triage"
kind: app
version: 0.6.0
workflow:
  features: { ... }
  graph:
    edges: [ ... ]   # ノード間の接続（React Flowメタデータ付き）
    nodes: [ ... ]   # 各ノードの定義（position, data, zIndex等）

まとめ

Claude Codeのskillとして、Dify DSLを自動生成するパイプラインを構築した。静的解析4段（patch→cloud→graph→node）とOSSインポートテストによるTDD的な品質担保を行った。
AIライクに設計したことにより、GUIでのワークフロー構築よりも高速に作成できる仕組みを作れた。
ただし非公式の仕組みであり、OSSで動作してもクラウド版で完全互換とは限らないため、環境に応じたカスタマイズや追加ルール整備が適宜必要である。