概要
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で動作してもクラウド版で完全互換とは限らないため、環境に応じたカスタマイズや追加ルール整備が適宜必要である。