Temporal × ローカルLLM × Robot Framework 日本企業向け「止まらない・壊れない」業務自動化アーキテクチャ

日本企業で業務自動化を進めると、次のような課題に必ず直面します。

請求書処理が途中で止まり、再実行が怖い
承認フローが長く、システムがその間に壊れる
SAP / ERP が古く、APIが使えない
AIを使いたいが、誤動作・誤判断が許されない
内部監査（監査対応・証跡）が必須

これらは AIの性能不足ではありません。
多くの場合、問題は ワークフロー基盤の設計 にあります。

本記事では、日本企業に適した 実運用向けアーキテクチャ を紹介します。

Temporal：耐障害・長時間実行に強いワークフロー基盤
ローカルLLM（Ollama 等）：社内完結のAI理解エンジン
Robot Framework：APIのないSAP/ERPのUI自動化

日本企業の業務自動化が難しい理由

日本の業務システムには、次の特徴があります。

SAP GUI / レガシーERPが現役
承認はメール・社内ワークフローが中心
業務は「途中で止まり」「後日再開」される
監査・証跡・再現性が重要

一般的な自動化手法（スクリプト、RPA単体、低コードツール）は、

数日後の再開
人の介入
再実行の安全性

を前提に設計されていません。

設計の原則：役割を分離する

信頼できるシステムの共通点は、責務の分離です。

レイヤー	役割
Temporal	業務フロー制御・状態管理・再実行保証
ローカルLLM	文書理解・分類・情報抽出
Robot Framework	SAP/ERP画面操作

AIは「判断を補助」する存在であり、
最終判断は決定論的なシステムが行うべきです。

全体アーキテクチャ（概念図）

メール / API / スケジュール
        |
        v
 Temporal Workflow（業務の真実）
        |
        +--> ローカルLLM
        |       - メール/請求書解析
        |       - 種別判定
        |       - 信頼度算出
        |
        +--> ゲート（業務ルール）
        |
        +--> Robot Framework
        |       - SAP / ERP UI操作
        |
        +--> 人の承認（Signal）

Temporalが 業務状態の唯一の正解 になります。

なぜ Temporal なのか（日本企業向け視点）

Temporalは次を保証します。

システム再起動後も業務が継続
デプロイ後も状態を保持
再実行しても二重処理しない
全ステップの履歴を保持（監査対応）

これは日本企業で重視される
「再現性」「説明責任」「安定運用」 と非常に相性が良いです。

ローカルLLMを使う理由（日本市場では重要）

日本では以下が特に重視されます。

社外にデータを出さない
契約書・請求書の情報管理
セキュリティ・コンプライアンス

Ollama等のローカルLLMを使うことで、

社内ネットワーク完結
モデル選択の自由
コスト制御

が可能になります。

LLMは次の情報を返します。

{
  "workflow_key": "invoice.receive",
  "confidence": 0.86,
  "extracted_fields": {
    "invoice_no": "INV-2025-001",
    "amount": 125000,
    "vendor": "ABC SUPPLY"
  }
}