Home - You-keitou/dify-template-maker GitHub Wiki
Dify Template Generator Wiki
🚀 プロジェクト概要
Dify Template Generatorは、自然言語からDify DSLファイルを自動生成するAIエージェントです。技術的な知識がなくても、誰でも簡単に高品質なAIワークフローを構築できることを目指しています。
📚 ドキュメント
設計ドキュメント
- 要件定義書 - プロジェクトの目的、機能要件、非機能要件
- アーキテクチャ設計書 - システム構成、コンポーネント設計、技術スタック
- ツールインターフェース仕様書 - 各ツールの入出力仕様、エラー処理
- 実装ガイドライン - コーディング標準、テスト、セキュリティ
コアバリュー
- Simplicity: 複雑なDSL仕様を意識させない
- Reliability: 生成されたDSLは必ず動作する
- Intelligence: ユーザーの意図を正確に理解する
- Security: エンタープライズレベルのセキュリティ
- Performance: 高速でスケーラブルな処理
2. Agent アーキテクチャ
User Input → [Analyze] → [Structure] → [Generate] → [Validate] → [Optimize] → DSL Output
↓
[Fix Errors]
3. Tool 設計ガイドライン
analyze_request
- 要求分析ツール
3.1 目的: ユーザーの自然言語を構造化された要件に変換する
重要な責務:
- 曖昧な表現から明確な意図を抽出
- 不足している情報を推測または明示
- ワークフローの複雑度を適切に評価
成功基準:
入力例: "FAQボットを作りたい"
出力に含むべき要素:
- 明確なアプリ名(例: "FAQ応答ボット")
- ワークフロータイプの特定(simple_qa)
- 必要なノード(start → knowledge_retrieval → llm → end)
- 推奨機能(suggested_questions, citation)
開発者への指針:
- ユーザーが省略しがちな要素(エラー処理、ログ記録など)を補完する
- 業界標準のパターンを認識し、適切なテンプレートを選択する
- 過度に複雑な解釈を避け、シンプルで実用的な構造を目指す
generate_workflow_structure
- ワークフロー構造生成ツール
3.2 目的: 要件からDifyのグラフ構造(nodes + edges)を生成する
重要な責務:
- 論理的に正しいノード配置
- データフローの最適化
- 視覚的に理解しやすいレイアウト
成功基準:
良いワークフロー構造:
- すべてのノードが適切に接続されている
- データの流れが一方向で明確
- 必須ノード(start/end)が含まれている
- ノード間の距離が適切(重ならない)
開発者への指針:
- 左から右への流れを基本とする
- 条件分岐は上下に配置
- 関連するノードはグループ化
- 将来の拡張を考慮した余白の確保
create_dsl_yaml
- DSL生成ツール
3.3 目的: 構造化データから有効なDSL YAMLを生成する
重要な責務:
- Dify仕様に完全準拠
- 人間が読みやすいフォーマット
- 必要な依存関係の自動検出
成功基準:
生成されるDSL:
- version: 0.3.0(必須)
- すべての必須フィールドが存在
- インポート時にエラーが発生しない
- コメントによる説明(オプション)
開発者への指針:
- デフォルト値は実用的なものを選択
- 将来の互換性を考慮
- 冗長な設定を避ける
- メタデータを適切に設定
validate_dsl
- 検証ツール
3.4 目的: DSLの妥当性を多角的に検証する
重要な責務:
- 構文的正確性の確認
- 論理的整合性の検証
- セキュリティリスクの検出
- パフォーマンス問題の警告
成功基準:
検証レベル:
必須(Error):
- YAML構文エラー
- 必須フィールドの欠落
- 無効な参照
推奨(Warning):
- パフォーマンス上の懸念
- セキュリティのベストプラクティス違反
情報(Info):
- 改善の余地
- 代替案の提示
開発者への指針:
- エラーメッセージは具体的で実行可能
- 自動修正可能な問題を識別
- 過度に厳格にならない(実用性重視)
optimize_dsl
- 最適化ツール
3.5 目的: DSLを様々な観点から改善する
重要な責務:
- パフォーマンスの向上
- セキュリティの強化
- 保守性の改善
- コスト効率の最適化
成功基準:
最適化の原則:
- 機能を損なわない
- 測定可能な改善
- トレードオフの明示
- 元に戻せる変更
開発者への指針:
- 小さな改善の積み重ね
- 最適化の根拠を明確に
- ユーザーの意図を尊重
- 過度な最適化を避ける
4. 共通ガイドライン
4.1 エラーハンドリング
- 具体的で actionable なエラーメッセージ
- 可能な限り修正方法を提示
- グレースフルデグラデーション
4.2 相互運用性
- 各ツールは独立して動作可能
- 明確な入出力インターフェース
- 他のツールの実装に依存しない
4.3 拡張性
- 新しいノードタイプへの対応
- DSLバージョンアップへの準備
- カスタマイズポイントの提供