ワークフロー自動化の試作から本番アプリへ
ローコードのワークフローツールは、学習コストを下げるために役立ちます。
アプリをつなぎ、APIアクセスを試し、AI分類を入れ、レコードを流し、事業責任者に動く経路を見せられます。
これは良いことです。
間違いは、試作をそのまま永遠に本番システムとして扱うことです。試作はリサーチ成果物です。問いに安く答えるために存在します。一度答えが出たら、その役割は次の構築に「情報を与える」ことであって、それ自体が次の構築になることではありません。
試作で証明すべきこと
ワークフロー自動化の試作では、次の問いに答えるべきです。
何がワークフローを開始するか
どのデータが必要か
どの判断は決定論的か
どの判断にAIが必要か
人の確認はどこに入るか
最終結果はどのシステムへ渡るか
失敗時に何が起きるべきか
これらに答えられたなら、試作は価値を作っています。
試作フェーズの出口文書として有用な、A4 1枚(チーム自身の言葉で):
トリガー。 「共有受信箱 invoices@ にメールが到着」。
入力。 「PDF添付 + メール本文 + 送信元ドメイン」。
決定論的ステップ。 「10MB超は却下、送信元を許可リストで検査」。
AIステップ。 「文書種別を分類、必須7項目を信頼度付きで抽出」。
レビュー。 「必須項目のいずれかで信頼度0.85未満ならAP担当へ」。
出力。 「承認時に会計APIへ仕訳投稿、原本をアーカイブ」。
失敗経路。 「一時的エラーは3回再試行、検証失敗はAI出力をヒントに手動キューへ」。
ボリュームとコスト。 「月600件程度、試作の現コストは月X円」。
チームがこのページを書けるなら、試作は仕事を終えています。曖昧に残っている部分があれば、再構築前にもう少し学習が必要というサインです。
本番ソフトウェアが追加するもの
本番ソフトウェアは、拡大するワークフローキャンバス内では維持しづらい要素を追加します。
使いやすいUI
型のあるデータモデル
API契約
テスト
権限
監査証跡
配備環境
監視とアラート
引き継ぎドキュメント
同じワークフローに対応する、最小だが本物の本番構成:
APIサービス。 FastAPIまたはNext.js Route Handlersでユースケースごとに型付きエンドポイント。入力はPydantic/Zodで検証、出力も同形式でシリアライズ。
ワーカー。 バックグラウンドキュー(BullMQ、Temporal、pgmq)が受信イベントを処理、アダプタを呼び、状態をPostgresへ永続化。
データベース。 Postgresに最低3テーブル:ドメインエンティティ(例 `invoices`)、監査用 `events`、AI実行用 `runs`。
LLMラッパー。 ユースケースごとに小さなモジュール:プロンプトバージョン、構造化出力、再試行、コスト集計、評価フック。
レビューUI。 レビュアー向けキュー、根拠表示、上書きに絞った管理画面。
可観測性。 ログを1箇所(Datadog、Grafana Loki、あるいはPostgresクエリ)へ。エラー率・レイテンシ・キュー深さでアラート。
CI/CD。 PRごとにテスト、IaCまたは文書化されたデプロイ、ステージングと本番の分離。
ワークフローは、壊れやすいノードの連鎖ではなく、プロダクト画面またはサービスになります。
Urbano DXの進め方
Urbano DXは、ワークフローが生んだ証拠から始めます。学びを捨てません。
動いている自動化を整理し、安定したロジックを特定し、重要な経路をアプリ、API、ダッシュボード、バックエンドサービスとして再構築します。
典型的なエンゲージメント形:
第1週。 試作を監査、出口文書を執筆、本番スコープと受入条件を合意。
第2〜3週。 背骨を再構築:API、ワーカー、DB、LLMラッパー、レビューUI。スモークテストと試作との並行稼働。
第4週。 フィーチャーフラグで本番切替、試作はフォールバックとして残す。監視、引き継ぎ文書、ランブックを整備。
判断。 試作を廃止、サンドボックスとして残す、または本番が意図的に扱わないエッジケース用に保持。
その結果、試作のスピードを残しながら、実運用に必要な制御を備えたソフトウェアになります。チームには資産が2つ残ります。本番システムと、次の新規ワークフロー学習に再利用できる試作環境です。