はじめに
今回は、社内で利用するAI経費精算ワークフローをDifyで開発してみました。
目的はとてもシンプルです。
申請する人と承認する人の両方を楽にすること。
申請者は入力の手間を減らし、承認者は確認の手間を減らす。
そのために、AIを「判断する存在」ではなく「人を支援する存在」として設計しました。
また今回も、ほぼバイブコーディングで開発しています。
前回作成した交通費申請ワークフローのDSLをベースに、Codexへ改善指示を出しながら実装を進めました。
自分でコードを書く時間より、「どんなシステムにするか」を考えている時間の方が長かった気がします。
※前回の記事はこちら
DifyでAIレビュー付き交通費申請ワークフローを作ってみた
完成したワークフロー
ワークフローは約33ノードになりました。最初はもっとシンプルな構成を想定していましたが、申請者・承認者それぞれの負担を減らすことを考えていくうちに、この形へ落ち着きました。
申請者
↓
領収証アップロード
↓
AI① 申請書ドラフト作成
↓
申請者が確認・修正
↓
AI② 承認者向けレビュー
↓
承認者
↓
Nextcloud保存
↓
メール通知
AIは「承認」しません
今回、一番時間を掛けて考えたのがAIの役割です。
AIに承認まで任せるのではなく、
AIは判断しない。人が判断しやすくする。
という設計を採用しました。
AI①は領収証から申請書ドラフトを作成。
AI②は承認者向けレビューを作成。
最後の承認は必ず人が行います。
OCR APIを作る予定でした
実は最初は、OpenCV・PaddleOCR・FastAPIを組み合わせた OCR API を作る前提で設計を進めていました。
仕様構成をFIXさせて、Codexへ渡す実装指示書まで作成していました。
でも途中で、
「Vision対応LLMを試してみよう。」
と思って動かしてみたところ......
普通に読めました（笑）
別方向で事前準備を進めてたので少し悔しかったですが（笑）、結果的にはシステム構成がシンプルになったので、この判断は正解だったと思っています。
なので結局、OCR APIを作るのはやめました。
当初
領収証
↓
OCR API(OpenCV + PaddleOCR)
↓
JSON
↓
Dify
最終
領収証
↓
Vision対応LLM
↓
JSON
↓
Dify
APIを1つ減らせたことで、構築も保守もかなりシンプルになりました。
今回もほぼバイブコーディング
今回はゼロから実装したわけではありません。
以前作成した交通費申請ワークフローのDSLをベースに、
「このDSLを参考に、経費精算ワークフローへ作り変えてください。」
という形でCodexへ依頼しました。
その結果、
- システム構成を考える
- 要件を整理する
- AIへ実装を依頼する
- レビューして改善する
というサイクルで開発を進めることができました。
AIにゼロから作らせるよりも、「過去に作った資産をベースに改善していく」方が、現時点では品質もスピードも高いと感じています。
作ってみて思ったこと
今回一番感じたのは、AIは人の代わりに仕事をするものではなく、
人が仕事をしやすくするための存在
だということです。
そしてもう一つ。
AIはコードを書くのが得意です。
一方で、何を作るか
どんな業務フローにするか
AIにどこまで任せるか
は、まだ人が考える部分だと感じました。
もちろん、まだAIだけで完璧なシステムは作れません。
でも、設計して、 AIに実装してもらい、 レビューして改善する。
この開発スタイルは、これからますます当たり前になっていく気がしています。
最後に
本ツールは株式会社LYDIAで、社内の事務作業を効率化するために開発しました。
実際に運用しながら改善を続けているため、新しい工夫や気づきがあれば、また記事として紹介したいと思います。
今後も Embedded × DX × AI をテーマに、実務で得た知見や開発事例を発信していきます。