自然言語だけでワークフローが完成する時代：ワークフローDevOpsへの変革
Algomatic は自然言語入力からワークフローを自動生成・テスト・修正する「WorkFlow DevOps」システムを開発し、ノーコードツールの運用課題と LLM の非決定的な出力に対する検証難題を解決した。
キーポイント
AI エージェントによる E2E 自動生成サイクル
自然言語の仕様から AI エージェントがワークフローを生成し、Dify へのインポート、ブラウザテスト、LLM-as-a-Judge による判定まで人間を介さず完結させる。
LLM-as-a-Judge による非構造化出力の検証
従来のルールベースでは不可能な LLM の自然言語出力に対し、画面情報と DOM を LLM に渡し、人間のような曖昧な基準で仕様適合性を判定する仕組みを採用。
Issue 蓄積による継続的改善とナレッジ化
自動修正が失敗したケースを GitHub Issue として構造化し、エラーパターンと解決策を蓄積することで、AI エージェントのコンテキストエンジニアリングを強化する。
ノーコードツールの運用矛盾の解消
非エンジニア向けツールが専門知識を必要とするという矛盾に対し、バリデーションチェックと自動テストにより品質担保されたワークフローを高速に提供することを目的としている。
AI と人の役割の明確な分離
AI に自動修正やテストを任せ、人間の判断が必要な領域に集中させることで、双方のパフォーマンスを最大化します。
試行錯誤コストの劇的低下
自然言語での指示だけで生成・テスト・修正が完結するため、従来の長Cycle な開発プロセスから脱却し、迅速な検証が可能になります。
影響分析・編集コメントを表示
影響分析
このアプローチは、LLM を活用したアプリケーション開発における「検証の壁」を打破する重要なステップです。特に LLM の出力が確定的でない状況下でも、AI が自らを検証・修正できる仕組みは、開発スピードと品質担保の両立を実現し、ノーコード/ローコード領域のパラダイムシフトを促す可能性があります。
編集コメント
LLM の非決定的な出力をどう検証するかという業界共通の課題に対し、AI が自らを検証者として機能させる「自己完結型」の開発プロセスは非常に示唆に富んでいます。
こんにちは。Algomaticの大塚です。 今回はDifyやn8nといったAIアプリケーションのWorkFlowを自動で作成する取り組みをご紹介します。
はじめに：ノーコードツールの限界
Dify、n8nといったノーコードツールは非エンジニアでも触れる点がプログラミングとの違いと言われています。しかし、実務の観点から見ると状況は異なります。
プロンプトを1行変更するだけでも、GUIの操作手順を覚える必要がある
作ったWorkFlowのテストは手動でやるしかない
エラーが起きたら、どこが悪いのか特定するのに時間がかかる
結局、非エンジニアでも触れるはずのツールが、専門知識を持った人しか運用できない矛盾が生まれています。
そんな課題を解決するために、社内でWorkFlowを自動で生成するシステムを開発しています。このシステムは自然言語からWorkFlowを自動生成するツールです。
ユーザーが実現したい内容を自然言語で伝えるとWorkFlowの作成から動作確認までAIエージェントがE2Eで実施します。 これにより品質の担保がされたWorkFlowを高速で作成することが可能になりました。
このシステムのアーキテクチャは、3つのAIエージェントによるプロセスで構成されています。 
仕様をプロンプトに含め、LLMでWorkFlowを生成。Difyインポート可能な形式かチェック。作成されたWorkFlowをDify上で実際にテスト実行。
テスト結果をAIに渡し、正しく動作しているか判定。エラー内容はIssueに蓄積
失敗時にエラー内容を分析しWorkFlowを修正
このシステムでは、WorkFlowの品質を担保するために3つの自動化を実装しています。
- WorkFlowを作成前後でバリデーションチェック
作成されたWorkFlowがコード上で問題ないか、作成の前後でバリデーションチェックを実施します。
作成前チェック：仕様書の構文検証、必須パラメータの存在確認
作成後チェック：構文エラー検出、形式の検証、Difyとの互換性確認
実行前に検出できるエラーは実行前に潰す方針を徹底しています。
- ブラウザテストとLLM-as-a-Judge
WorkFlowをDifyにインポートした後、ブラウザ自動化ツールで実際にテストを実行。テスト結果はLLM-as-a-Judgeで判定します。
テスト実行時の画面とDOM情報を取得
定義された仕様を成功基準と一緒にLLMに渡す
LLMがこのWorkFlowは仕様を満たしているかを判定
人の目で見て判断するような曖昧な基準も、LLMなら自然言語で表現できます。
- 改善点のIssue化と継続的な改善
判断された結果、改善点がある場合はGitHub Issueを自動で作成し、ログを残しつつ改善を進めます。
エラー内容を記録：何が起きたか、どのステップで失敗したか、スクリーンショットを含めて記録
修正の履歴：どのIssueに対してどの修正が行われたかを追跡可能
ナレッジの蓄積：過去の失敗パターンと解決策がIssueとして蓄積され、将来の改善に活用
このサイクルにより、作って終わりではなく継続的に品質を高めていく仕組みを実現しました。 ※以下は作成できたDifyのワークフロー例です 
WorkFlow DevOpsの特徴
このシステムの特徴は、AIを使ってAIアプリケーションを自動で改善し続ける仕組みです。
LLMによる自動テスト・自動判定
従来のテスト自動化では、正解を事前に定義する必要がありました。しかしDifyなどLLMを介したWorkFlowの出力の多くは自然言語であり、正解を厳密に定義しづらい場面が多いです。
そこで、このシステムではLLM-as-a-Judgeを採用しました。テスト結果の画面とDOM情報をLLMに渡し、このWorkFlowは仕様を満たしているかを判定させます。人が目で見て判断するような曖昧な基準も、自然言語で表現できるためLLMなら対応可能です。これにより、テスト設計のボトルネックを解消できます。
このシステムには2つの改善サイクルがあります。
作成→インポート→テスト→AIで判定→修正のサイクルを、成功するまで自動で回します。
失敗したらその場で修正し、成功するまでリトライする。人の介入なしにリアルタイムで品質を高めていく、まさにAIネイティブな開発プロセスです。
- 人を介した継続的な改善サイクル
自動の修正で解決できなかった問題は、GitHub Issueとして起票されます。
エラーの種類や発生箇所に応じたIssueを自動で作成
エラー内容、画面キャプチャ、ログへの参照を記録
開発者がレビューし、手動で修正・改善
過去の失敗パターンと解決策がナレッジとして蓄積
自動で解決できる問題は自動で、人の判断が必要な問題は明確に可視化する。2つのサイクルが連携し、継続的に品質を高めていく仕組みです。
AIの進化速度は驚異的で、新しいモデルが出るたびにプロンプトの書き方も変わり、ベストプラクティスも更新されます。
従来の開発プロセスでは、この変化についていくのが難しくなっています。しかしこのシステムなら、仮説を自然言語で書いてすぐに検証できます。
このプロンプトで精度が上がるか試してみよう
新しいモデルに切り替えたら動くか確認しよう
エラーハンドリングを追加したらどうなるか見てみよう
こうした仮説をすぐに検証できるため、AIの進化速度に追従しながら品質を担保できます。
Issueを活用したコンテキストエンジニアリング
このシステムの特徴は、蓄積されたIssueがAIの改善コンテキストになる点です。
従来のAI開発では、プロンプトに含める情報を人が都度設計する必要がありました。しかしこのシステムでは、過去の失敗パターンと解決策がGitHub Issueとして構造化されて蓄積されます。
失敗パターンを自動で分類：どのステップで、どんなエラーが発生したかを記録
解決策の紐付け：各Issueに対してどの修正が有効だったかを追跡
コンテキストの自動注入：エージェントが類似のIssue履歴を参照して修正の方針を決定
これにより、AIが過去の経験を踏まえて判断できるようになります。人が毎回プロンプトを調整しなくても、システムが自律的に学習していく。コンテキストエンジニアリングとしての工夫も取り入れました。
WorkFlow DevOpsでは、AIと人の役割を明確に分離しています。
ブラウザテストの実行と結果取得
LLM-as-a-Judgeによる成否判定
自動修正で解決できないエラーの対応
Issue内容のレビューと優先度付け
この分担により、AIが得意な繰り返し作業は自動化し、人の判断が必要な領域に集中できる体制を実現しました。ポイントは、AIと人の境界を曖昧にしない点。自動で解決できる問題と、人の介入が必要な問題を明確に切り分ければ、どちらも最大限のパフォーマンスを発揮できます。
To-Be（WorkFlow DevOps導入後）
小さな改善でも要件定義から外注
プロンプト1行の変更でもコスト発生
従来のWorkFlow開発では、ちょっとした改善でも要件をまとめて→依頼して→実装を待って→手動でテストして→フィードバックを伝えて...のサイクルを回す必要がありました。このサイクルに時間がかかるため、その間にビジネス要件が変わってしまう場合もあります。
WorkFlow DevOpsでは、このサイクルが短縮されます。実現したい内容を自然言語で伝えるだけで、AIがWorkFlowを作成し、自動でテストし、問題があれば自動で修正。人が介入するのは最初の依頼と最終確認だけです。
この違いは単なる効率化ではありません。試行錯誤のコストが劇的に下がり、とりあえず試してみようが当たり前になります。AIの進化する速度に追従しながら、品質を担保できる。これがWorkFlow DevOpsです。
WorkFlow DevOpsは、自然言語からWorkFlowを自動で生成・テスト・修正する開発手法です。
AIエージェントを使った開発は、単にコードを生成するだけではありません。自動で解決できる問題は即座に修正し、人の判断が必要な問題はデータを蓄積し、今後の改善に役立てます。この仕組みによって、AIエージェントと協働した次世代の効率的な開発が実現します。
Algomaticでは、こうしたAIネイティブな開発体験を追求しています。
AIでこんな面白い仕組みが作れるのではとアイデアを持っている方
プロンプトエンジニアリングやエージェント設計に興味がある方
AIネイティブなアーキテクチャ設計やシステム設計に興味がある方
一緒に、AIを使った新しい開発パラダイムを作っていきませんか？カジュアル面談やお問い合わせ、お待ちしています。
algomatic.notion.site
原文を表示
こんにちは。Algomaticの大塚です。 今回はDifyやn8nといったAIアプリケーションのWorkFlowを自動で作成する取り組みをご紹介します。
はじめに：ノーコードツールの限界
Dify、n8nといったノーコードツールは非エンジニアでも触れる点がプログラミングとの違いと言われています。しかし、実務の観点から見ると状況は異なります。
プロンプトを1行変更するだけでも、GUIの操作手順を覚える必要がある
作ったWorkFlowのテストは手動でやるしかない
エラーが起きたら、どこが悪いのか特定するのに時間がかかる
結局、非エンジニアでも触れるはずのツールが、専門知識を持った人しか運用できない矛盾が生まれています。
そんな課題を解決するために、社内でWorkFlowを自動で生成するシステムを開発しています。このシステムは自然言語からWorkFlowを自動生成するツールです。
ユーザーが実現したい内容を自然言語で伝えるとWorkFlowの作成から動作確認までAIエージェントがE2Eで実施します。 これにより品質の担保がされたWorkFlowを高速で作成することが可能になりました。
このシステムのアーキテクチャは、3つのAIエージェントによるプロセスで構成されています。
仕様をプロンプトに含め、LLMでWorkFlowを生成。Difyインポート可能な形式かチェック。作成されたWorkFlowをDify上で実際にテスト実行。
テスト結果をAIに渡し、正しく動作しているか判定。エラー内容はIssueに蓄積
失敗時にエラー内容を分析しWorkFlowを修正
このシステムでは、WorkFlowの品質を担保するために3つの自動化を実装しています。
- WorkFlowを作成前後でバリデーションチェック
作成されたWorkFlowがコード上で問題ないか、作成の前後でバリデーションチェックを実施します。
作成前チェック：仕様書の構文検証、必須パラメータの存在確認
作成後チェック：構文エラー検出、形式の検証、Difyとの互換性確認
実行前に検出できるエラーは実行前に潰す方針を徹底しています。
- ブラウザテストとLLM-as-a-Judge
WorkFlowをDifyにインポートした後、ブラウザ自動化ツールで実際にテストを実行。テスト結果はLLM-as-a-Judgeで判定します。
テスト実行時の画面とDOM情報を取得
定義された仕様を成功基準と一緒にLLMに渡す
LLMがこのWorkFlowは仕様を満たしているかを判定
人の目で見て判断するような曖昧な基準も、LLMなら自然言語で表現できます。
- 改善点のIssue化と継続的な改善
判断された結果、改善点がある場合はGitHub Issueを自動で作成し、ログを残しつつ改善を進めます。
エラー内容を記録：何が起きたか、どのステップで失敗したか、スクリーンショットを含めて記録
修正の履歴：どのIssueに対してどの修正が行われたかを追跡可能
ナレッジの蓄積：過去の失敗パターンと解決策がIssueとして蓄積され、将来の改善に活用
このサイクルにより、作って終わりではなく継続的に品質を高めていく仕組みを実現しました。 ※以下は作成できたDifyのワークフロー例です
WorkFlow DevOpsの特徴
このシステムの特徴は、AIを使ってAIアプリケーションを自動で改善し続ける仕組みです。
LLMによる自動テスト・自動判定
従来のテスト自動化では、正解を事前に定義する必要がありました。しかしDifyなどLLMを介したWorkFlowの出力の多くは自然言語であり、正解を厳密に定義しづらい場面が多いです。
そこで、このシステムではLLM-as-a-Judgeを採用しました。テスト結果の画面とDOM情報をLLMに渡し、このWorkFlowは仕様を満たしているかを判定させます。人が目で見て判断するような曖昧な基準も、自然言語で表現できるためLLMなら対応可能です。これにより、テスト設計のボトルネックを解消できます。
このシステムには2つの改善サイクルがあります。
作成→インポート→テスト→AIで判定→修正のサイクルを、成功するまで自動で回します。
失敗したらその場で修正し、成功するまでリトライする。人の介入なしにリアルタイムで品質を高めていく、まさにAIネイティブな開発プロセスです。
- 人を介した継続的な改善サイクル
自動の修正で解決できなかった問題は、GitHub Issueとして起票されます。
エラーの種類や発生箇所に応じたIssueを自動で作成
エラー内容、画面キャプチャ、ログへの参照を記録
開発者がレビューし、手動で修正・改善
過去の失敗パターンと解決策がナレッジとして蓄積
自動で解決できる問題は自動で、人の判断が必要な問題は明確に可視化する。2つのサイクルが連携し、継続的に品質を高めていく仕組みです。
AIの進化速度は驚異的で、新しいモデルが出るたびにプロンプトの書き方も変わり、ベストプラクティスも更新されます。
従来の開発プロセスでは、この変化についていくのが難しくなっています。しかしこのシステムなら、仮説を自然言語で書いてすぐに検証できます。
このプロンプトで精度が上がるか試してみよう
新しいモデルに切り替えたら動くか確認しよう
エラーハンドリングを追加したらどうなるか見てみよう
こうした仮説をすぐに検証できるため、AIの進化速度に追従しながら品質を担保できます。
Issueを活用したコンテキストエンジニアリング
このシステムの特徴は、蓄積されたIssueがAIの改善コンテキストになる点です。
従来のAI開発では、プロンプトに含める情報を人が都度設計する必要がありました。しかしこのシステムでは、過去の失敗パターンと解決策がGitHub Issueとして構造化されて蓄積されます。
失敗パターンを自動で分類：どのステップで、どんなエラーが発生したかを記録
解決策の紐付け：各Issueに対してどの修正が有効だったかを追跡
コンテキストの自動注入：エージェントが類似のIssue履歴を参照して修正の方針を決定
これにより、AIが過去の経験を踏まえて判断できるようになります。人が毎回プロンプトを調整しなくても、システムが自律的に学習していく。コンテキストエンジニアリングとしての工夫も取り入れました。
WorkFlow DevOpsでは、AIと人の役割を明確に分離しています。
ブラウザテストの実行と結果取得
LLM-as-a-Judgeによる成否判定
自動修正で解決できないエラーの対応
Issue内容のレビューと優先度付け
この分担により、AIが得意な繰り返し作業は自動化し、人の判断が必要な領域に集中できる体制を実現しました。ポイントは、AIと人の境界を曖昧にしない点。自動で解決できる問題と、人の介入が必要な問題を明確に切り分ければ、どちらも最大限のパフォーマンスを発揮できます。
To-Be（WorkFlow DevOps導入後）
小さな改善でも要件定義から外注
プロンプト1行の変更でもコスト発生
従来のWorkFlow開発では、ちょっとした改善でも要件をまとめて→依頼して→実装を待って→手動でテストして→フィードバックを伝えて...のサイクルを回す必要がありました。このサイクルに時間がかかるため、その間にビジネス要件が変わってしまう場合もあります。
WorkFlow DevOpsでは、このサイクルが短縮されます。実現したい内容を自然言語で伝えるだけで、AIがWorkFlowを作成し、自動でテストし、問題があれば自動で修正。人が介入するのは最初の依頼と最終確認だけです。
この違いは単なる効率化ではありません。試行錯誤のコストが劇的に下がり、とりあえず試してみようが当たり前になります。AIの進化する速度に追従しながら、品質を担保できる。これがWorkFlow DevOpsです。
WorkFlow DevOpsは、自然言語からWorkFlowを自動で生成・テスト・修正する開発手法です。
AIエージェントを使った開発は、単にコードを生成するだけではありません。自動で解決できる問題は即座に修正し、人の判断が必要な問題はデータを蓄積し、今後の改善に役立てます。この仕組みによって、AIエージェントと協働した次世代の効率的な開発が実現します。
Algomaticでは、こうしたAIネイティブな開発体験を追求しています。
AIでこんな面白い仕組みが作れるのではとアイデアを持っている方
プロンプトエンジニアリングやエージェント設計に興味がある方
AIネイティブなアーキテクチャ設計やシステム設計に興味がある方
一緒に、AIを使った新しい開発パラダイムを作っていきませんか？カジュアル面談やお問い合わせ、お待ちしています。
algomatic.notion.site
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み