Dify導入で逆に仕事が増えた話。事務仕事がハマる『自動化の罠』と脱出の全記録

2026年4月2日、22時15分。
Difyを入れれば仕事がラクになる。そう信じていた私は、その夜、自分で作ったフローに2時間以上殺されました。

最初は小さなズレでした。
出てくる文章が、全部微妙におかしい。読める。でも使えない。
社内に投げたら、「これ誰向け？」で止まるレベルです。
原因もすぐには分からない。変数の渡し方を雑に理解したまま進めたせいで、直したつもりの修正が次のエラーを呼び、また別の場所で止まる。ログを見て、直して、流して、また壊れる。その繰り返しでした。

あの夜いちばんきつかったのは、Difyが動かなかったことじゃありません。
自分が“分かったつもり”で触っていたせいで、止まった理由すらすぐ説明できなかったことです。

Difyそのものは悪くない。
むしろ、ちゃんと使えればかなり強い。
でも少なくとも、あの夜の私は「自動化ツールを触っている人」ではなく、自分の甘い設計を延々と増幅させている人でした。

この記事は、Difyをきれいに紹介する記事ではありません。
「AIでラクになる」と思って触った人間が、どうやって逆に仕事を増やしたのか、その失敗記録です。
同じ地雷を踏む人を一人でも減らしたいので、かなり正直に書きます。

---

最初に定義すべきだった要求仕様｜この出力でないと実務では使えなかった

あの時の失敗を振り返ると、最初に足りなかったのはDifyの知識ではありませんでした。
要求仕様の定義です。

私は「事務作業を少しラクにしたい」という気持ちだけで触り始めました。
でも本来、先に決めるべきだったのは感情じゃない。
何を入力して、どんな形で返ってきたら成功なのか。そこでした。

少なくとも、あの時に必要だった条件はこうです。

入力側で必要だったもの

• 元になる本文データが欠けずに入ること
• 誰向けの文面かが分かること
• 最低限、落としてはいけない確認項目が揃っていること
• 空欄や表記ゆれがあっても、致命的に壊れないこと

出力側で必要だったもの

• そのまま社内確認に回せる文面であること
• 必須項目が抜けていないこと
• 勝手な補足や余計な配慮を足さないこと
• 文体の温度が毎回ブレないこと
• 人が最後に確認しやすい長さと構造になっていること

今見ると、かなり当たり前です。
でも、あの時の私はこの当たり前を先に書き出していなかった。

つまり、Difyに渡したのは
“要件が曖昧な仕事”だったんです。

これがまず最初の論理的過失でした。
AIに雑な依頼をすれば、雑な出力が返る。
しかも今回は、雑でも一応読める日本語が返ってきたから余計にタチが悪かった。
あの夜に必要だったのは
「なんとなくいい感じ」ではなく
どの条件を満たしたら実務で使えるかを先に固定することだった。これが現実です。

---

事故の概要｜何を自動化しようとして、何が止まったのか

やりたかったのは、毎回ほぼ同じ流れでやっている事務作業を少しでも軽くすることでした。

• 情報を受け取る
• 必要な部分を抜く
• 文章を整える
• 返せる形にする

一個ずつ見れば重くない。
でも、毎回やるにはじわじわ面倒。
しかも、少しズレると人の手で直さないといけない。
この「全部は重くないけど、毎回積み上がるとしんどい」仕事を、Difyで半自動にできないかと思ったんです。

問題は、この時点で“成功の形”が曖昧だったことでした。

当時の頭の中はかなり雑でした。

• 入力を受ける
• 必要な情報だけ拾う
• それっぽい文章を作る
• 人が最後に確認して使う

たぶん、最初にDifyを触る人の多くがこの発想になると思います。
私もまったく同じでした。
でも、この「それっぽい文章」が何を満たせば合格なのか、自分で定義していなかった。
ここが事故の起点です。

---

比較検証ログ①｜「一応動いた」のに現場では使えなかった理由

最初の段階では、フロー自体は一応動いていました。
入力を入れる。出力も返る。
画面だけ見れば、「もう少しで完成しそう」に見えたんです。

でも、現場では止まりました。

この時の状態

• 入力：元データとなる本文情報
• 処理：Difyの基本フローで、そのまま文面生成まで実行
• 想定していた出力：そのまま確認に回せる、短くて抜けのない文面
• 実際の出力：読めるが、実務では使えない文章

どこがダメだったか

壊れ方は、完全停止ではありませんでした。
もっと嫌な壊れ方です。

• 必要な確認項目が抜ける
• 入れていない余計な配慮が混ざる
• 文体が毎回微妙に揺れる
• 一見きれいだが、そのまま出すと止まる

つまり、出力は存在するのに、業務フローには乗らない。
ここが一番危ない状態でした。

この時点で私は、
「返ってきた＝使える」
とかなり甘く判定していました。

でも本来見るべきだったのは、

• そのまま使えるか
• 必須要素が落ちていないか
• 出力の再現性があるか

この3つです。

このログの時点で分かるのは
壊れていたのは文法ではなく、要求仕様との一致率だったということです。
日本語として成立しているかどうかではなく、現場で通るかどうか。
あの時の私は、そこを完全に見誤っていました。

---

比較検証ログ②｜原因を間違えて、プロンプトを盛ってさらに壊した

1回目の失敗を受けて、私はかなり典型的な誤修正をしました。
それが、原因を特定しないまま、指示文を増やしたことです。

当時の頭の中はかなり単純でした。

• 抜けるなら、もっと細かく指示すればいい
• 文体が揺れるなら、トーンを厳しく指定すればいい
• 余計なことを書くなら、禁止事項を増やせばいい

理屈としては、それっぽい。
でも実際は違いました。

この時の状態

• 入力：1回目と同じ元データ
• 処理：プロンプトに条件や指示を追加
• 想定していた出力：抜けが減り、安定した文面
• 実際の出力：前より長く、重く、くどい文章

何が悪化したか

• 文が無駄に長くなる
• 必要項目は相変わらず落ちる
• 今度は“丁寧すぎて使いにくい文”になる
• 一文ごとの温度差がむしろ広がる

しかも厄介だったのは、ノイズがきれいに見えたことです。
実際、2回目の出力では、必要な確認事項が抜けたまま、

「恐れ入りますが、念のためご確認いただけますと幸いです。何卒よろしくお願いいたします。」

みたいなクッション言葉だけが増えました。

一見すると丁寧です。
でも、欲しいのは“丁寧そうな文章”じゃない。
必要な情報が落ちていない、使える文面です。

ここでやっと分かりました。
問題は「AIが自由すぎる」ことではなく
前段の入力と工程が整理されていないことだったんです。

私はこの時、出口の文章だけを無理やり整えようとしていました。
でも実際には

• そもそも何の情報が入っているか
• どの情報が抜けているか
• どの工程で加工すべきか

が曖昧なままだった。

だから、プロンプトを盛れば盛るほど、
前段の曖昧さを抱えたまま、もっと整って見えるだけのズレた文が返るようになった。
今ならはっきり言えます。
原因が工程設計にあるのに、出口の文章だけを直そうとすると、かなりの確率で悪化します。
2回目の私は、まさにそれをやっていました。

---

比較検証ログ③｜一回止めて、工程を分けたらやっとマシになった

3回目でようやく、少しまともな方向が見えました。
きっかけは単純です。
フローを触る前に、一回全部止めたことでした。

ここで初めてやったのが
「最終的に何が出れば成功なのか」を文章で決めることです。

それまでの私は、

• 情報を受け取る
• 要約する
• 文面にする
• 使える形にする

この工程を、頭の中で全部まとめていました。
でも、それだとズレた時に原因が追えない。

なので3回目では、工程を切りました。

変更したこと

• 必要情報を抜く工程を先に分けた
• 文面生成は後段に回した
• 最後は人が確認する前提にした
• 一気に全部自動で終わらせるのをやめた

この時の状態

• 入力：必要情報を明確に切り出す前提で再整理
• 処理：要約と文面生成を分離
• 想定していた出力：下書きとしては使える安定した文
• 実際の出力：まだ完全ではないが、ズレ方が読めるようになった

ここでの変化は大きかった。
完璧な成功ではない。
でも少なくとも、どこで崩れたかが見える状態にはなりました。

さらにこの段階で、変数の見方も変えました。

それまでは、
「ちゃんと入ってそう」
で流していた。
でも3回目では、
どの値が、どの形で、どのノードに渡っているかを一つずつ確認するようにしました。

ここでようやく
「何を渡したつもりで、実際には何が渡っていたのか」
が見えるようになったんです。

最終的に見えた正解は、かなり地味でした。

完全自動を狙うほど壊れやすい。
“下書きまで進めて、人が最後に見る”くらいがちょうどいい。

これです。

3回目でうまくいったというより、
欲張るのをやめたことで、やっと壊れ方が制御できるようになった。
それが正確でした。

---

あの夜に消えた2時間の内訳｜いちばん無駄だったのは、原因を間違えた時間

あの夜に消えた2時間を、今ならこう分解できます。

• 約30分
  出力文の違和感を、プロンプトの言い回しだけで直そうとしていた時間
• 約60分
  変数の受け渡しと工程のつながりを理解しないまま、どこでズレたのかを探していた時間
• 約30分
  ようやく「これは文章の問題じゃなく、設計の問題だ」と気づいて、Difyの仕様と自分のフローを見直していた時間

こうして見ると、いちばん無駄だったのは、Difyそのものより
原因を間違えていた時間でした。

ここはかなり大きい。
ツールを触っている時間が全部学びになるわけじゃない。
間違った仮説にしがみついたまま触る時間は、普通に損失です。

---

“気持ち悪い出力”の正体｜何が実務で使えなかったのか

最初に私は、出力を「気持ち悪い」と表現しました。
でも、これは感想で逃げる言い方でした。
実際に起きていた問題を分解すると、もっとはっきりしています。

実務で使えなかった理由

• 必要な確認項目が落ちる
  一番困るのはこれでした。文章がきれいでも、必要項目が抜けていたら使えません。
• 入力していない余計な配慮が混ざる
  こちらが求めていない一文が足されるせいで、文面の重さやニュアンスがズレました。
• 文体の温度が揺れる
  一文だけ妙に丁寧、でも前半は雑。こういう揺れ方は、実務ではかなり目立ちます。
• 簡潔さが崩れる
  もともと短く済ませたい場面なのに、余計な説明が入り、確認の手間が増える。

つまり、壊れていたのは日本語ではありません。
要求仕様に対して、安定して合格できないことが問題でした。

ここを「なんか気持ち悪い」で済ませると、ただの感想になります。
でも実際には、
必要要素の欠落・余計な補足・トーンの揺れ・長文化
という、かなり具体的な壊れ方をしていました。

こういう「読めるけど使えない出力」を減らしたいなら、精度の見張り方そのものを先に固定した方が早いです。
PDFや領収書の転記ミスを減らす時に使った考え方は、Difyの出力監視にもそのまま応用できます。
ChatGPTの「コピペミス」を減らす。領収書やPDFからExcelへ正確に転記させる“型”も合わせてどうぞ。

---

今も残っている異常系｜壊れる可能性がある入力パターン

ここはハッピーエンドにはしません。
今も、100％安心しているわけではないです。

少なくとも、次のような入力はまだ警戒しています。

• 元データが長すぎる時
• 必須欄に空欄がある時
• 項目の順番が普段と違う時
• 想定していない形式で情報が入った時
• 途中に曖昧な表現が混ざっている時

つまり今の状態は、
完成ではなく、
異常系をある程度想定して監視できる状態に近い。

この認識がないまま触ると、また同じ事故を起こす。
ここはかなり大事です。

---

安定稼働のために今見ている監視項目

「ちょっと不安」で終わらせるのは無責任なので、今は最低限これを見ています。

監視している項目

• 必須項目が全部出力に残っているか
• 余計な補足が勝手に増えていないか
• 文体の温度が崩れていないか
• 長さが想定以上に膨らんでいないか
• 出力をそのまま確認に回せるか

止める基準

• 必須項目が抜けたら止める
• 文体が崩れたらその回は使わない
• 入力形式がいつもと違う時は流さない
• “一応読める”では通さない

ここまで決めておくと
少なくとも前みたいに
壊れているのに期待して触り続ける事故は減ります。

ただし、ここでひとつ不都合な事実があります。
自動化で消えたのは作業そのものではありませんでした。
正確には、作業の性質が変わっただけです。

自分で全部書く時間は減った。
その代わりに、出力を監視し、崩れ方を見張り、異常系を止める仕事が増えた。
つまり、自動化とは「仕事が消えること」ではなく、実行の仕事が、監視と判断の仕事に変わることでした。

ここを理解しないと
「自動化したのに、なんでまだ見てるの？」
というズレた期待を持ったまま事故ります。
私はそれで一回やられました。

---

もしもう一度ゼロから作り直すなら、絶対にやらない3つのこと

もしあの夜に戻れるなら、私は次の3つを絶対にやりません。

1. ゴールが曖昧なままフローを組み始める

「とりあえず組んでみる」は、今回かなり危険でした。
最終的に何が出れば成功かを決めずに触ると、ズレた時に戻る場所がなくなります。

2. 変数を“たぶんこれで合ってる”で流す

ここ、本当にダメでした。
見た目でつながっていることと、意図通りに渡っていることは別。
ここを雑にしたせいで、あとでかなり苦しみました。

3. 「一応動いた」を成功扱いする

これは一番やらない。
実務で使えないなら、それはまだ成功じゃない。
返ってきたことより、そのまま使えるかを先に見るべきでした。

---

この3つを理解していないなら、まだDifyを触らないほうがいい

今の自分が、あの夜の自分に言うならこれです。

1. 最終的に何が出れば成功なのか、先に言葉で決めろ
2. AIにやらせる工程と、人が確認する工程を分けろ
3. “返ってきた”ではなく、“そのまま使える”を成功条件にしろ

この3つが曖昧なままDifyを触ると、かなり高い確率でハマります。
少なくとも私は、それで2時間以上を無駄にしました。

---

まとめ｜Difyで増えたのは業務量ではなく、“設計の甘さの請求書”だった

今回の失敗で一番きつかったのは
Difyが難しかったことじゃありません。
自分が“分かったつもり”で進めた設計の甘さを、ツールがそのまま増幅して返してきたことです。

Difyは便利です。
でも、便利さだけ見て入ると痛い目を見ます。

特に

• 自動化したい作業を分解していない
• ゴールの形を決めていない
• 変数の意味を曖昧なまま進める
• 一応動いたことを成功だと思う

このあたりをやると、かなり危ない。

逆に言うと
このへんを最初に潰せば、Difyはかなり強い道具になります。

少なくとも私は、あの夜に2時間以上溶かしてやっと分かりました。
自動化で最初に直すべきなのは、ツールじゃなくて自分の設計なんだと。

AIで効率化したのに、なぜか前より仕事が増える。
その“逆流”が起きる仕組み自体を整理したのがこちらです。
→ AI活用を隠すべき？事務職が「仕事を押しつけられない」ための生存戦略