DifyからAnsibleを叩く設計：曖昧さを排除して確実に動く自動化へ

LLMの曖昧さを運用で飼いならす

昨今、業務への生成AI利用が活性化するなか、生成AI（LLM）を業務に組み込む動きが加速する一方で、「本当にその実行、AIに任せて大丈夫か？」という違和感を持ったことはないでしょうか？

LLMは非常に強力ですが、本質的に確率的（ランダム性を含む）な存在です。
同じ入力を与えても、わずかに異なる出力を返すことがあります。
この特性は、アイデア出しや文章生成では強みになりますが、
設定変更やアカウント作成のような失敗できない作業ではリスクになり得ます。

本記事では、
「LLMの曖昧さを前提にしたうえで、業務の確実性をどう担保するか」
というテーマで、DifyとAnsibleを組み合わせた設計思想と実装アプローチをご紹介します。

なぜLLMに「実行」を任せないのか

LLMを業務に使う際によくある失敗は、「AIにすべてを任せようとすること」です。
たとえば、以下のような問題が発生します。

• コマンドや設定値を微妙に書き換えてしまう
• 入力の解釈を誤る
• 必要な手順を省略するエラー時の挙動が一定しない

これらはLLMの性質上、完全には避けられません。

この分離を前提に、
「判断はLLM,実行は決定的な仕組みへ委譲する」
という構成を取ります。

Difyはオーケストレーター、実行はAnsibleへ

サーバーのアカウント作成を一例にとって見てみましょう。
今回はオーケストレーターであるLLM側をDify、実行側をAnsibleで構成したものとします。

- Dify側

• 利用者からの依頼の受け取り
• ルールのチェック
• 何をやるかを確定させる

- Ansible

• 確定した内容で受け取り
• 毎回同じ手順でアカウントを作成

に倣って構成した結果下記のようになります

重要なのは
LLM自身は「考えるが、手は動かさない」
という点です。

Ansible側では実行する処理を明示的かつ冪等なPlaybookとして定義します。
これにより、実行結果の再現性と監査性を担保できます。

課題

この構成はシンプルですが、運用が進むと次のように作業の分岐は必ず増えていきます。

• 一時アカウントは期限必須
• 本番用は承認が必要
• 特定サーバーだけ手順が違う
• sudo 権限付きは追加チェックが必要

これを場当たり的にフローに足していくと、

• 変更のたびに事故が起きる
• ワークフローがスパゲッティ化する
• どこで何を判断しているのか分からなくなる

という状態になります。
この時重要なのは、分岐が増えること自体を問題にしない設計にすることです。

①処理はモジュール化する

- ユーザ作成、ログ取得などの処理はPlaybook/サブフローとして部品化
- 分岐ごとに処理を増やすのではなく、同じ部品の組み合わせを変えるだけにする

例)
ユーザ作成の処理が本番、検証、一時アカウント用フローにそれぞれコピペした状態で存在している。
⇒仕様変更が入ると、すべて直す必要がある。
こちらをモジュール化すると
＊Ansible側

• 「ユーザー作成」
• 「ログ取得」
• 「権限設定」
  を Playbookとして部品化する

＊Dify側

• 「ログ取得サブフロー」
• 「ユーザー作成サブフロー」
  を 再利用可能な部品として呼び出す

上記のようにすることで環境や用途によって分岐は増えますがその都度処理を増やす必要はなく、
同じ部品の組み合わせを変えるだけで済みます

②分岐ルールの判断をAIに任せない

「このケースは自動で行けるかAIに考えさせよう！」
この考え方は危険です。これをやると下記のような事象が発生します

- 同じ条件でも判断がぶれる
- なぜ自動実行されたのか／されなかったのかを、人が論理的に説明できない状態

よって分岐のルールを作成する際に、実行される処理に対して
サービス影響度、承認要否などの要素を精査する
決定表のようなものを作成し、自動実行の可否を決める
判断をルールとして可視化する運用が望ましいです。

③ブラックボックス化しない設計

仮に予期せぬ問題が発生したときに、

- どこで判断が変わったのかわからない
- AIの出力が原因なのか、フローの中身なのかわからない

というようにブラックボックス化してしまうと動いている理由も問題の止め方もわからないという状態が
出来上がってしまいます。
よって

• 誰が
• いつ
• どの入力で
• 何を実行し
• 結果がどうだったか

これらを必ずログとして残します。

おわりに

生成AI時代の業務自動化で重要なのは、「どこまでAIに任せるか」ではなく

「どこをAIに任せないかを決めること」

が、より重要だと考えています。

• LLMは「考える存在」
• 実行は「決定的な仕組み」
• Difyはその間をつなぐ制御層

この役割分担を意識することでLLMの柔軟性と業務システムの確実性を両立できると考えてます