自動化したのに工数が増えた本当の理由：AIアプリの「動かし続ける設計」を後付けした話

「自動化したはずなのに、自分の工数が増えていく」。AIアプリを社内で運用してしばらくすると、そう感じる人は多いと思います。問題は精度ではなく、「誰が、何を、どう直すか」を決めていなかったこと。作ることと動かし続けることは別の仕事だと気づくまでの記録です。

AIアプリを作った後に気づいたこと

PDFの書類から必要な項目を読み取って、CSVに整形するワークフローをDifyで作りました。

DifyはAIを使った業務アプリを、コードなしで組み立てられるツールです。

完成したときは「これで毎月の手作業がなくなる」と思っていました。

でも実際は、完成してから2〜3週間で問い合わせが来るようになりました。

「エラーが出ているんですが、どうしたらいいですか？」
「書類の形式が変わったみたいで、うまく読み取れなくなりました」
「このケースはどうすればいいですか？」

自動化したつもりが、対応が自分に集まっていく。

「動かす設計」だけで、「動かし続ける設計」を何も考えていなかった。そう気づいたのは、しばらく経ってからでした。

壁はどこにあったか

問い合わせを整理してみると、3つのパターンに分かれていました。

① エラーの意味がわからない

Difyのワークフロー（自動で処理を進める仕組みのこと）がエラーを出しても、担当者には「何がおかしいのか」が分かりません。

作った側はすぐわかります。でも、その情報を伝えていなかった。

小さな問題でも、毎回自分が直しに行く状態が続きました。

② 書類のフォーマットが変わると壊れる

書類の様式変更や書式変更があると、読み取り設定がそのままでは機能しなくなります。

「どこを更新すればいいか」が自分の頭の中にしかないため、誰も直せない。

担当者が「また壊れた」と感じるたびに、アプリへの信頼が少しずつ下がっていきました。

③ 例外ケースの判断が属人化

「このケースはどうしますか？」という判断を毎回口頭で返していました。

判断基準が自分の頭の中にあるだけで、文書化されていない。

同じ質問が繰り返されるのは当然でした。

共通点は、どれも「アプリの精度の問題」ではありませんでした。「誰がどう動くか」が決まっていなかった、運用設計の問題でした。

動かし続ける設計とは何か

AIアプリを作ることと、現場で動かし続けることは、別の設計が必要です。

「作ること」は一回で終わります。
「動かし続けること」は毎日続きます。

「動かし続けること」の設計とは、こういうことです。

• どのエラーが来たら、誰がどう対処するか

• 書類や設定が変わったとき、どこを更新するか

• 例外が来たとき、何を確認して、誰が判断するか

これを「後でやろう」にしておくと、問い合わせが全部作った人に来ます。

自動化の本来の目的は「誰でも動かせる状態にすること」のはずです。作った人がいないと動かないシステムは、自動化としては半分しか完成していない。

そう気づいてから、「作ることと保守設計は並行作業」という考え方になりました。

実際に試した3つのこと

気づいた後、3つのことを後付けで整えました。

① エラーカタログを作った

よく出るエラーを5〜6パターン書き出して、「このメッセージが出たら、ここを確認する」というチェックリストを作りました。

担当者が自分で対応できる問題は、その場で完結できるようにする。どうしても分からないものだけ自分に来る、という棲み分けです。

ここで最初の失敗をしています。「エラーを全パターン網羅しよう」と思ったら手が止まりました。

書く粒度を変えてから、半月で問い合わせの頻度が半分以下になりました。完成度より、続けられる粒度のほうが効きました。

② 更新ポイントの一覧を作った

Difyのワークフローの中で、「ここが変わったときに更新が必要な設定」を書き出しました。

「書類フォーマットが変わったときは、ここのプロンプト（AIへの指示文）を直す」
「項目の並び順が変わったときは、この抽出ルールを直す」

コメントでも付箋でも何でもいいです。「どこを直すか」が分かれば、次の人が動けます。

③ 例外判断基準を書き出した

「このケースはどうしますか？」と聞かれるたびに、自分の判断を答えていました。

それをそのまま文書に書いていきました。

「読み取り項目が規定数以下のときは手動確認」
「フォーマットが2種類混在するときは別処理で対応」
「前月と照合できないケースは保留して担当者に確認」

条件と行動をセットで残すだけです。難しい形式は必要ありませんでした。

ここでも失敗しています。

形式を整えるのは、項目が10件たまってからで十分でした。

変わったこと

問い合わせの頻度は明らかに減りました。

担当者の言葉も変わりました。「これはどうしますか？」が「この手順でやりました」に変わった。自分で判断して動ける状態になったからだと思います。

自分がいなくてもアプリが動く日が、少しずつ増えました。これが自動化の本来の姿だと感じています。

そして気づいたのは、アプリを完成させた瞬間は、全体の半分もできていなかったということです。

残りの半分は「誰でも動かせる・直せる状態にすること」。最初のバージョンはあくまで動作確認で、運用しながら例外が見つかり、判断が蓄積され、対処フローが育っていく。そこまで含めてようやく「運用に乗った」と言える気がしています。

「作ること」と「育てること」を分けて考えるようになってから、最初から完璧なドキュメントを作ろうとするのをやめました。今来た質問をそのまま1行メモするところから始める。それが結果的に、一番続きました。

明日から試せる一歩

• 今使っているAIツールで、先週誰かに何か聞かれたことを1つ書き出す

• 「このエラーが出たら、ここを確認する」という対処メモを1件だけ作る

• 書式や設定が変わったとき、どこを直すかを1行でも書いておく

• 「このケースは自分が判断・このケースはそのまま処理」を1行ずつ書き分けてみる

全部やろうとしなくて大丈夫です。「今週来た質問の答えをそのまま1行メモ」が、最初の一歩になります。

関連記事

同じ「AIを現場で動かし続ける」テーマで書いた記事です。あわせて読むと、運用設計の引き出しが増えると思います。

• Difyで作る、書類読み取りアプリの失敗しやすいポイント全部のせ：https://note.com/clean_whale1844/n/nb49319d7c72e

• AIエージェントが現場で止まる本当の理由：判断基準を先に書くべきだった：https://note.com/clean_whale1844/n/n9f80696f2325

• AI議事録を入れたのに誰も見返さない。「記録する」と「拾う」は別だった：https://note.com/clean_whale1844/n/n3c5dcb032c91

この記事が参考になったら「スキ」で教えてください。次の実験の励みになります。

#AI活用100本ノック 進捗：78/100

次回の実験：AIエージェントに任せる前に「どう判断するか」を条件表にまとめてみる

このnoteでは、現場改善・AI活用・小さな自作ツールの試行錯誤を記録しています。
初めての方はこちらからどうぞ。
▶ はじめての方へ｜このnoteで書いていること