Agentic WorkflowをAgentと共に構築するために：ValidatorとLSPで支えるAI協働開発

こんにちは。LayerX Ai Workforce事業部 FDEグループエンジニアの藤田と申します。

今回は、Agentic WorkflowなどのフローをAgentとともに作る際には、Validatorがあると便利という話をしようと思います。

TL;DR

エージェントと人が協働してAgentic Workflow（yamlファイルのDSL）を構築できるようにするため、LLMで生成されたDSLを即座に人間とエージェントが意味的に検証・修正できる「Validator & LSPサーバー」を簡易的に作ってみました。

背景

言わずもがな、AIエージェントの能力が飛躍的に進化しており多くの業務を変えています。一方で、コーディングエージェントを使ったことがある方ならご存知のように、適切にアラインしないと品質の低いアウトプットをしてしまうこともよくあります。そのため、安定的に業務で使うには、ある程度エージェントの業務を事前に決めておくような「ワークフロー」が重要になります。

多くのワークフローはDSLで記述され（例: Dify DSL）、その実体は特定の形式のyamlやjsonでタスク実行・条件分岐や繰り返しを表現したものです。

このDSL構築用のグラフ的なUIもありますが、それでもなお精度検証及び精度改善やLLMの不確実な挙動に伴うエラーハンドリング等もあり、人手で作るのは大変です。

そこで、ワークフロー自体をもっとAI自身に作らせることができないか？という試みが各所で行われています。

例えば最近も、n8nが自然言語からワークフローを作成する機能をリリース予定との発表がありました。： AI-powered workflow-building coming soon - Community Highlights - n8n Community

当事業部もR&Dのテーマとして進めている取り組みでもあります： tech.layerx.co.jp

余談ですが、「DSLをLLMに書かせる」こと自体は意外とあるケースなのではないかと思います。例えば「データ分析や画像処理のパイプラインを自然言語インターフェースで構築できる機能」は、ワークフローのDSLの生成と似た問題になるかと思います。

ワークフローDSLをAIに書かせる上での課題

AIにDSL（ワークフロー定義）を書かせようとすると、ワークフローの精度はもちろんなのですが、それ以外にもいくつかの壁があります。

まず、LLMはワークフローDSLの仕様や文法を事前に知らないため、構文エラーや依存関係の不整合など、DSL内で意味的な誤りが起こりやすいです。また、ワークフロー自体がLLM等の重い処理を含むことが多いため、「一度実行して間違いを見つける」という試行錯誤はコストと時間が大きいです。

そのため、「静的にDSLを解析してミスをエージェントや人間がすぐに修正できる形」を実現したくなります。

DSLのValidatorとLSPサーバーの試作

実際に、簡単なDSLの意味解析を行うValidatorを作成し、LSPサーバーにすることでエディタ上から即座にDSLを検証できるようにしてみました。

LSP（Language Server Protocol）は、エディタと言語解析ロジックを分離して、構文チェックや補完を行える仕組みのことです。LSPに準拠して作れば様々なエディタから共通の形で利用できるのが特徴です。

今回作成したものを用いると、例えば以下のように、ワークフローのDSLについて循環依存を検出し、エディタ上に可視化できます。

これにより、まず人間がDSLの間違いに気づいて修正しやすくなりました。

全体像は以下の通りです。

LSPクライアント：LSPサーバーの起動等を行う
パーサー（ruamel.yaml）：yamlファイルをパースし、各キーの値とファイル内の位置情報を抽出するために用いています。
スキーマ検証（jsonschema）：構文レベルのエラーの検出。例えばid: キーには文字列が入っているべき、など。
意味解析：循環依存の検出
LSPサーバー（pygls）：validatorを用いてクライアントにDSLの診断情報を返す。pyglsを用いると比較的簡単に作れて便利です。 pygls.readthedocs.io

エージェントがValidatorを用いて自らDSLを修正する

また、Validatorのコア部分はエージェントがTool的にも用いることができるため、エージェントがDSL構築中に自ら間違いに気づいて正すことが可能です。

例えば、以下のような、ニュースを分析するようなダミーのワークフローがあるとします。（yamlだと長いのでグラフだけ記載しています。）

このワークフローについてエージェントに

 方針チェックの結果を踏まえて詳細要約に反映するようにyamlを書き換えて

と指示して、以下に示す「詳細要約_方針チェック反映」のような新しくタスクを追加することを期待しましょう。

Validatorなしの場合

しかし実際に指示してみると、以下のように単に「詳細要約」タスクに「方針チェック」タスクを依存させて、循環参照を生むミスをしてしまいます。（※余談ですが、Claude Opus 4.1では循環依存を作ってしまいましたが、Sonnet 4.5では正しく依存解決していました。さすが。）

Validatorありの場合

では、Validatorがあるとどうでしょう。

Validatorをツール的に用いることで、エージェントは循環依存を作成してしまったことに自ら気づくことができます。

この後何度かエージェントが試行錯誤して、最終的にはワークフローは以下の形になりました。

少し見づらいですが、「方針チェック_詳細要約」というタスクが追加され、循環依存は解決されていることを確認できます。

指示通りのワークフローではないので惜しい。。。。ものの、循環依存自体は解消できており、「エージェントが独力で、より正しいワークフローの修正を行える」ことに繋がることが実感できるかと思います！

まとめ

当たり前かもしれませんが、上記のように、ワークフローのValidatorがあることで不具合をすぐにエージェントにFBすることができ、より信頼性高い形でワークフローをエージェントと作ることができます。また、LSPサーバーにすることで、普段使い慣れているエディタやコーディングエージェントとともにワークフロー開発ができるため、人間にとってもより修正・編集しやすくなることが示せたかと思います。

今回はワークフローDSLのValidatorを通して「AIと人が共に開発する体験」の基礎の一部分を作りました。今後は、AIが自律的に業務ノウハウを吸収し、役立つエージェントが自然発生していく世界を目指しています。もしこのような「AIと共に働く未来」を一緒に作っていきたい方がいれば、ぜひお話しましょう。