自然言語だけでワークフローが完成する時代：ワークフローDevOpsへの変革

こんにちは。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つの自動化を実装しています。

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

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

作成前チェック：仕様書の構文検証、必須パラメータの存在確認

作成後チェック：構文エラー検出、形式の検証、Difyとの互換性確認

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

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

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

テスト実行時の画面とDOM情報を取得

定義された仕様を成功基準と一緒にLLMに渡す

LLMがこのWorkFlowは仕様を満たしているかを判定

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

1. 改善点の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ネイティブな開発プロセスです。

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

自動の修正で解決できなかった問題は、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