はじめに

交通費申請って、やること自体は単純なのに、地味に面倒です。

弊社ではこれまでExcelで申請していましたが、申請する側も確認する側も、毎回それなりに手間がかかっていました。

特に管理部では、申請が届くたびに次の作業をしていました。

申請内容を確認する
出発駅と到着駅をWeb検索する
申請された運賃が合っているか確認する
問題がなければ承認する

1件ずつ見れば大した作業ではありません。

ただ、毎回同じように検索して確認するのは、やっぱり面倒です（笑）

交通系APIの利用も考えましたが、社内の申請確認だけのために利用料やランニングコストをかけるのも違う気がしました。

そこで今回は、Difyを使ってAIレビュー付きの交通費申請ワークフローを作成しました。

完成したワークフロー

今回作成したワークフローでは、次の処理を行っています。

申請内容の入力チェック
Web検索を利用した運賃確認
AIによる申請内容のレビュー
管理部への承認依頼
承認・却下の分岐
Markdown形式での申請記録生成
Nextcloudへの保存
メールによる結果通知

最初はもっと単純なフローを想定していましたが、実際に運用することを考えていくと、最終的にはかなり本格的な構成になりました。

ワークフローの流れ

社員
  ↓
交通費申請
  ↓
入力チェック
  ↓
Web検索による運賃確認
  ↓
AIレビュー
  ↓
管理部承認
  ├─ 却下
  └─ 承認
       ↓
   Markdown生成
       ↓
   Nextcloud保存
       ↓
   完了通知

AIは承認しない

今回の設計で一番意識したのは、AIに最終判断をさせないことです。

AIが行うのは、あくまでレビューです。

入力内容に不自然な点がないか
申請経路と目的に矛盾がないか
Web検索で確認できた運賃と申請金額が一致しているか
管理部が追加確認した方がよい点はないか

こうした情報を整理して、管理部へ渡します。

一方で、次の判断はAIにさせていません。

承認
却下
支給金額の最終決定

最終判断は必ず人が行います。

AIに全部任せるのではなく、人が判断しやすい材料をAIに集めてもらうという役割分担にしました。

運賃確認にはWeb検索を利用

交通費確認というと、交通系APIを使う方法が思い浮かびます。

ただ、今回は社内利用が前提です。

そのため、

API利用料をかけたくない
専用APIの管理を増やしたくない
小規模利用には少し大げさ

という理由から、交通系APIは使いませんでした。

代わりに、OpenAIのWeb検索機能を利用しています。

AIには、検索結果を根拠に運賃を確認させています。

検索できなかった場合や、十分な根拠が得られなかった場合は「判定不可」とし、推測で運賃を決めないようにしています。

管理部はHuman Inputで承認

AIレビューが終わると、管理部へ承認依頼が送られます。

管理部は申請内容とAIレビューを確認し、

承認
却下

のどちらかを選択します。

AIが確認作業を補助し、最後は人が判断する形です。

この構成にしたことで、AIを使いながらも、業務上の責任範囲を曖昧にせずに済みました。

メール通知で申請内容を確認

管理部へ送るメールには、次の情報をまとめています。

申請ID
申請者
利用日
経路
申請金額
AI評価
AIコメント
承認画面へのリンク

メールを見るだけでも、申請内容とAIレビューの概要を把握できます。

細かい内容を確認したい場合だけ承認画面を開けばよいため、管理部側の確認作業もかなり楽になりました。

Difyでもバイブコーディングできた

今回の開発は、いわゆるバイブコーディングに近い進め方でした。

どんな業務を効率化したいか
AIと人の役割をどう分けるか
どこまで自動化するか
実際に使ってみて何が違うか

といった部分を考え、要件や修正内容をChatGPTに伝えました。

一方で、DifyのDSL作成やノード構成、変数参照、分岐、Markdown生成、Nextcloud保存など、実装の大部分はCodexに任せています。

私自身がDify上で行ったのは、主に次のような作業です。

APIや認証情報の設定
一部ノードの再作成
画面上での細かな修正
テスト実行
動作確認
Codexへの修正指示

Difyはノーコード・ローコードツールですが、複雑なワークフローを画面上でゼロから組むのは、それなりに大変です。

今回は、要件を文章で整理してCodexにDSLを作成してもらい、Difyへインポートして調整する方法を取りました。

この進め方なら、Difyでもかなり本格的なフローをバイブコーディングで構築できます。

もちろん、一発では完成しなかった

バイブコーディングとはいっても、依頼したら一発で完成したわけではありません（笑）

特に苦労したのは、DifyのバージョンとDSLの互換性です。

最初に生成したDSLをインポートしたところ、一部のLLMノードやHuman Inputノードが正常に開けませんでした。

そこで、

Dify上で新しいノードを作成
現在のDifyが出力するDSLを再エクスポート
そのDSLを基準にCodexへ修正を依頼
再度インポートして動作確認

という流れで修正しました。

AIに実装を任せる場合でも、実際に動かして問題点を見つけ、正しい情報を返していく作業は必要です。

ただ、ゼロからすべて手作業で組むよりは、かなり短時間で完成まで進められました。

使用技術

Dify 1.14系
OpenAI GPT-5.6
OpenAI Web検索
Code Node
LLM Node
Human Input
条件分岐
HTTP Request
Markdown生成
Nextcloud
SMTPメール通知
Codex

今後の展開

今回作成したのは交通費申請ですが、本当に作りたかったのは、AIレビュー付き申請ワークフローの共通基盤です。

この仕組みは、交通費申請以外にも応用できます。

今後は、次のような申請へ展開していく予定です。

経費申請
定期代変更申請
備品購入申請
稟議申請

申請内容ごとにAIレビューの観点は変わりますが、

入力
  ↓
ルールチェック
  ↓
AIレビュー
  ↓
人による承認
  ↓
記録保存

という基本構成は共通化できます。

まずは交通費申請から実際に運用し、改善しながら他の申請へ広げていきたいと思います。

最後に

本ツールは株式会社LYDIAで、社内の事務作業を効率化するために開発しました。

実際に運用しながら改善を続けているため、新しい工夫や気づきがあれば、また記事として紹介したいと思います。

今後も Embedded × DX × AI をテーマに、実務で得た知見や開発事例を発信していきます。