https://tech.algomatic.jp/entry/2025/12/27/121807

こんにちは。Algomaticの大塚です。
今回はDifyやn8nといったAIアプリケーションのWorkFlowを自動で作成する取り組みをご紹介します。

はじめに：ノーコードツールの限界

Dify、n8nといったノーコードツールは非エンジニアでも触れる点がプログラミングとの違いと言われています。しかし、実務の観点から見ると状況は異なります。

プロンプトを1行変更するだけでも、GUIの操作手順を覚える必要がある
作ったWorkFlowのテストは手動でやるしかない
エラーが起きたら、どこが悪いのか特定するのに時間がかかる

結局、非エンジニアでも触れるはずのツールが、専門知識を持った人しか運用できない矛盾が生まれています。

社内の取り組み

そんな課題を解決するために、社内でWorkFlowを自動で生成するシステムを開発しています。このシステムは自然言語からWorkFlowを自動生成するツールです。

ユーザーが実現したい内容を自然言語で伝えるとWorkFlowの作成から動作確認までAIエージェントがE2Eで実施します。これにより品質の担保がされたWorkFlowを高速で作成することが可能になりました。

仕組み

このシステムのアーキテクチャは、3つのAIエージェントによるプロセスで構成されています。

各エージェントの役割

プロセス	役割	詳細
作成	WorkFlow生成	仕様をプロンプトに含め、LLMでWorkFlowを生成。Difyインポート可能な形式かチェック。作成されたWorkFlowをDify上で実際にテスト実行。
蓄積	結果判定	テスト結果をAIに渡し、正しく動作しているか判定。エラー内容はIssueに蓄積
改善	エラー修正	失敗時にエラー内容を分析しWorkFlowを修正

品質を担保する3つの自動化

このシステムでは、WorkFlowの品質を担保するために3つの自動化を実装しています。

1. WorkFlowを作成前後でバリデーションチェック

作成されたWorkFlowがコード上で問題ないか、作成の前後でバリデーションチェックを実施します。

作成前チェック：仕様書の構文検証、必須パラメータの存在確認
作成後チェック：構文エラー検出、形式の検証、Difyとの互換性確認

実行前に検出できるエラーは実行前に潰す方針を徹底しています。

2. ブラウザテストとLLM-as-a-Judge

WorkFlowをDifyにインポートした後、ブラウザ自動化ツールで実際にテストを実行。テスト結果はLLM-as-a-Judgeで判定します。

テスト実行時の画面とDOM情報を取得
定義された仕様を成功基準と一緒にLLMに渡す
LLMがこのWorkFlowは仕様を満たしているかを判定

人の目で見て判断するような曖昧な基準も、LLMなら自然言語で表現できます。

3. 改善点のIssue化と継続的な改善

判断された結果、改善点がある場合はGitHub Issueを自動で作成し、ログを残しつつ改善を進めます。

エラー内容を記録：何が起きたか、どのステップで失敗したか、スクリーンショットを含めて記録
修正の履歴：どのIssueに対してどの修正が行われたかを追跡可能
ナレッジの蓄積：過去の失敗パターンと解決策がIssueとして蓄積され、将来の改善に活用

このサイクルにより、作って終わりではなく継続的に品質を高めていく仕組みを実現しました。
※以下は作成できたDifyのワークフロー例です

WorkFlow DevOpsの特徴

このシステムの特徴は、AIを使ってAIアプリケーションを自動で改善し続ける仕組みです。

LLMによる自動テスト・自動判定

従来のテスト自動化では、正解を事前に定義する必要がありました。しかしDifyなどLLMを介したWorkFlowの出力の多くは自然言語であり、正解を厳密に定義しづらい場面が多いです。

そこで、このシステムではLLM-as-a-Judgeを採用しました。テスト結果の画面とDOM情報をLLMに渡し、このWorkFlowは仕様を満たしているかを判定させます。人が目で見て判断するような曖昧な基準も、自然言語で表現できるためLLMなら対応可能です。これにより、テスト設計のボトルネックを解消できます。

2つの改善サイクル

このシステムには2つの改善サイクルがあります。

1. 完全自律型サイクル

作成→インポート→テスト→AIで判定→修正のサイクルを、成功するまで自動で回します。

失敗したらその場で修正し、成功するまでリトライする。人の介入なしにリアルタイムで品質を高めていく、まさにAIネイティブな開発プロセスです。

2. 人を介した継続的な改善サイクル

自動の修正で解決できなかった問題は、GitHub Issueとして起票されます。

エラーの種類や発生箇所に応じたIssueを自動で作成
エラー内容、画面キャプチャ、ログへの参照を記録
開発者がレビューし、手動で修正・改善
過去の失敗パターンと解決策がナレッジとして蓄積

自動で解決できる問題は自動で、人の判断が必要な問題は明確に可視化する。2つのサイクルが連携し、継続的に品質を高めていく仕組みです。

高速な仮説検証

AIの進化速度は驚異的で、新しいモデルが出るたびにプロンプトの書き方も変わり、ベストプラクティスも更新されます。

従来の開発プロセスでは、この変化についていくのが難しくなっています。しかしこのシステムなら、仮説を自然言語で書いてすぐに検証できます。

このプロンプトで精度が上がるか試してみよう
新しいモデルに切り替えたら動くか確認しよう
エラーハンドリングを追加したらどうなるか見てみよう

こうした仮説をすぐに検証できるため、AIの進化速度に追従しながら品質を担保できます。

Issueを活用したコンテキストエンジニアリング

このシステムの特徴は、蓄積されたIssueがAIの改善コンテキストになる点です。

従来のAI開発では、プロンプトに含める情報を人が都度設計する必要がありました。しかしこのシステムでは、過去の失敗パターンと解決策がGitHub Issueとして構造化されて蓄積されます。

失敗パターンを自動で分類：どのステップで、どんなエラーが発生したかを記録
解決策の紐付け：各Issueに対してどの修正が有効だったかを追跡
コンテキストの自動注入：エージェントが類似のIssue履歴を参照して修正の方針を決定

これにより、AIが過去の経験を踏まえて判断できるようになります。人が毎回プロンプトを調整しなくても、システムが自律的に学習していく。コンテキストエンジニアリングとしての工夫も取り入れました。

AIと人の分担アーキテクチャ

WorkFlow DevOpsでは、AIと人の役割を明確に分離しています。

AIが担当する領域

WorkFlowの自動生成
形式チェック・バリデーション
ブラウザテストの実行と結果取得
LLM-as-a-Judgeによる成否判定
軽微なエラーの自動修正

人が担当する領域

自動修正で解決できないエラーの対応
アーキテクチャレベルの判断
ビジネス要件の最終確認
Issue内容のレビューと優先度付け

この分担により、AIが得意な繰り返し作業は自動化し、人の判断が必要な領域に集中できる体制を実現しました。ポイントは、AIと人の境界を曖昧にしない点。自動で解決できる問題と、人の介入が必要な問題を明確に切り分ければ、どちらも最大限のパフォーマンスを発揮できます。

このシステムで変わる開発状況

観点	As-Is（現状）	To-Be（WorkFlow DevOps導入後）
依頼方法	小さな改善でも要件定義から外注	自然言語で依頼するだけ
テスト	手動テストに時間がかかる	自動テスト・自動修正
変更コスト	プロンプト1行の変更でもコスト発生	すぐに変更・検証が完了
フィードバック	時間がかかる	すぐに結果がわかる
運用者	専門知識を持った人のみ	非エンジニアでも本当に使える