Skip to content
Affectosphere Group Kansai University, Keito Inoshita Laboratory
EN

Column

既存ワークフローを捨てずにAIエージェントを後付けする——プロセスハーネスという選択肢

DX推進の現場で「既存システムを壊せない」という制約は絶えず登場する。この研究はワークフローエンジンを置き換えず、その外周にエージェント判断ポイントを後付けするプロセスハーネス機構を提案。ローン審査を実例にCUGA FLOで実現した設計を、規制業種DXの視点で解説する。

5 分で読める English version →
既存ワークフローエンジンの周囲にエージェント層が配置されるフラットイラスト。ポリシー制御のエージェントが並列稼働する構造

こんにちは。Affectosphere Group の井下です。

「LLMエージェントで業務を自動化したいが、既存のワークフローシステムがあって簡単には変えられない」

DX推進部門や情報システム部門が直面するこの制約は、本当によく聞く話です。 ERPやBPMツールはコンプライアンス・監査ログ・承認フロー管理と深く結びついており、ゼロベースで作り直すのはリスクが大きすぎる。 かといって何もしなければ、意思決定の遅さや手作業の多さは改善されない。

2026年6月にarXivで公開された研究（Fournier & Limonad, arXiv:2606.27188）は、この問題に対してエレガントな解を提案しています。 既存のワークフローエンジンを置き換えるのではなく、その周囲にポリシー制御型エージェントレイヤーを「後付け」するプロセスハーネス機構です。 ローン審査ワークフローを実装例として、CUGA FLOという実際のBPMシステムで実現した結果を報告しています。

今日の3点

  1. 既存ワークフローエンジンはそのままに、その外周にTaskAgent・DecisionAgent・FlowAgentの3種エージェントを配置するプロセスハーネスで、レガシーワークフローをエージェント型BPMへ段階的に移行できる。
  2. 決定論的な必須要件（コンプライアンス・法的制約）と、エージェント的な自律性（規範的要件への適応）を設計レベルで分離できる。
  3. 既存のITガバナンス（監査ログ・承認記録）を維持したまま自律性を導入できるため、規制業種の大企業DXに特に適合する。

① なぜ「置き換えない」ことが重要なのか

エージェントAIの導入を検討するとき、最もよくある障壁の一つが「既存システムとの共存」です。

金融・保険・医療・公共機関では、ワークフローエンジンが業務の根幹を支えています。 承認フロー、監査ログ、コンプライアンスチェック——これらはシステムと不可分に実装されており、単純に「新しいAIエージェントシステムに移行」するわけにはいきません。 規制当局への説明責任、過去ログの継続性、現場担当者の再教育コストなど、障壁は技術面だけではありません。

プロセスハーネスのアイデアは、「捨てるか残すか」という二項対立から脱出するものです。 既存システムは維持しながら、その外周に判断能力のある層を追加する。 新しいアーキテクチャは古いシステムに取って代わるのではなく、それを包み込む形で機能します。

② Task-Decision-Flow（TDF）モデルの設計

この研究が提案するのはTask-Decision-Flow（TDF）モデルと呼ばれる設計フレームワークです。

3種類のエージェントがそれぞれ異なる役割を担います。

TaskAgentはワークフロー内の個別タスクを担当します。書類確認・データ入力・外部システム照会など、従来は人間が実行していた手作業の実行主体を担います。

DecisionAgentは判断ポイントを担当します。ローン審査でいえば「この申請者の信用リスクをどう評価するか」「例外処理が必要か」といった、ルールベースでは対処しにくい判断をLLMの推論能力で処理します。

FlowAgentはプロセス全体の流れを監視します。「このタスクが完了したら次に何をすべきか」「例外的な状況ではどのルートをたどるか」を管理するオーケストレーション役です。

重要なのは、これら3種のエージェントが既存のワークフローエンジンの「外側」に配置される点です。 エンジン自体は変更せず、エンジンが発するイベントやトリガーを拾って、エージェントが必要な判断・実行を担当する設計です。

③ 決定論的制御とエージェント的自律性の両立

プロセスハーネスの設計で最も注目すべきは、「守らなければならないこと」と「適応してよいこと」の設計レベルの分離です。

必須要件とは、法的・契約的に守らなければならない手続きのことです。 ローン審査でいえば、本人確認書類の確認、反社チェック、融資限度額の遵守など。 これらはエージェントが自律的に判断してよい対象ではなく、決定論的に実行されなければなりません。

規範的要件とは、より良い結果のために適応的に対応すべき事項のことです。 「この申請者の職業や収入状況の文脈を考慮した与信判断」「類似ケースとの比較に基づく審査コメントの生成」など、画一的なルールでは対処できない知識集約型の判断です。

プロセスハーネスはこの二者を構造的に分けます。 必須要件はワークフローエンジンの側で決定論的に管理し、規範的要件はエージェント層で適応的に処理する。 この分離があることで、コンプライアンス部門は「ルール遵守の確実性」を維持しながら、業務担当者は「より賢い判断の恩恵」を受けられます。

DX推進部門・情報システム部門への実装仮説

想定ユースケースは、既存のBPMツールやワークフローエンジンが稼働している規制業種の大企業です。

ローン審査に限らず、次のような業務領域で同様の構造が成立します。

  • 購買承認ワークフロー：金額・カテゴリ・仕入先の条件をDecisionAgentが状況判断し、FlowAgentが例外ルートを動的に決定。KPIは承認リードタイムの短縮。
  • 契約管理・更新判断：更新条件の評価と交渉優先度判断をDecisionAgentが担当。KPIは更新漏れ率の低減と審査コスト削減。
  • コンプライアンス報告書のドラフト生成：TaskAgentが各所のログを収集し、DecisionAgentがリスク評点をつけてレポートを構造化。KPIは審査担当者の工数削減。

移行のステップとして考えると、第一段階はハーネスの観察モードでの導入です。 エージェントが判断を「推奨」として出力するが、最終決定は人間が行う。 この段階でエージェントの判断品質を評価し、信頼性を積み上げます。

第二段階は低リスクタスクへの自律実行の段階的拡大です。 TaskAgentによるデータ収集や書類整理から始め、DecisionAgentの判断自動化は信頼度スコアが閾値を超えたタスクから順次拡大します。

「ゼロベースで作り直す必要はない」という設計思想

AI導入の議論では「既存システムとの統合をどうするか」が常に最大の壁になります。

プロセスハーネスが示すのは、その壁を避けるのではなく、壁を前提にした設計です。 捨てるものはなく、加えるものがある。

まだarXivプレプリントの段階で、さまざまな業種・ワークフロー規模への適用検証はこれからだと思います。 ただこの設計思想は、既存ITガバナンスを壊さずにAI自律性を導入したいと考える日本の大企業のDX担当者にとって、かなり参考になる枠組みになるのではないかという予感があります。

では！

参考論文

  1. Fournier, F., & Limonad, L. (2026). A Process Harness for Uplifting Legacy Workflows to Agentic BPM: Design and Realization in CUGA FLO. arXiv preprint.

※ 本記事は一部 AI により執筆されており、間違った情報が含まれる恐れがあります。