公開: 2026年5月6日
最終更新: 2026年5月6日
ワークフロー自動化の試作から本番アプリへ
ローコードのワークフローツールは、学習コストを下げるために役立ちます。
アプリをつなぎ、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つ残ります。本番システムと、次の新規ワークフロー学習に再利用できる試作環境です。