目次
この記事のポイント
- AIに任せるのは理解・要約・推薦・抽出・生成の5つ。検証・計算・権限・承認・転記は決定論的ロジックとしてCAP・S/4HANA側に残す
- エージェントはGoal→Reason→Tool→Observe→Decideのループ、ワークフローはStep A→B→Cの固定パス。「経路が変わってよいか」で選ぶ
- 金額とリスクの閾値で分岐し、閾値未満は自動承認＋記録、閾値以上はBuild Process Automationの人手承認に回す
- LLMからS/4HANAへ直接転記しない。CAP検証→承認→転記の3つの関門を必ず通す
01WHAT なぜ「AIに全部やらせる」設計は本番で止まるのか
生成AIのデモは、驚くほど自然に業務を説明してくれます。「この購買依頼を承認して」「在庫を見て発注をかけて」と話しかければ、それらしい手順とパラメータを返してくれます。しかし、その出力をそのままS/4HANAの伝票登録に流し込む設計は、本番運用では通用しません。
理由は性能ではなく、AIの出力が本質的に確率的であることです。同じ入力でも結果が揺れ、もっともらしいが誤った値を返すことがあり、判断の根拠を事後に完全再現できないこともあります。監査・統制・再現性のいずれの観点でも、この性質を業務の最終判断に持ち込むことはできません。
確率的タスクと決定論的業務ロジックは、そもそも性質が違う
AIが得意なのは、理解（Understand）・要約（Summarize）・推薦（Recommend）・抽出（Extract）・生成（Generate）です。曖昧な自然言語を扱える代わりに、出力は確率的で100%同じ結果を保証できません。使う側が「もっともらしい候補」として受け取り、採否を判断する前提のタスクに向きます。
一方で、検証（Validate）・計算（Calculate）・権限判定（Authorize）・承認（Approve）・転記（Post）は、同じ入力に対して必ず同じ結果を返し、誰がいつ何を根拠に実行したかを記録できる必要があります。ここを決定論的業務ロジックと呼びます。性質の違う2つを1本のフローに混ぜると、誤りがどこで混入したかを追えなくなります。
用語補足：決定論的とHuman-in-the-loop
決定論的とは「同じ入力なら必ず同じ結果になり、手順が検証できる」という性質です。会計計算や権限判定、伝票転記はこの性質が必須になります。Human-in-the-loopは、AIの提案とシステムの実行の間に人の承認判断を挟む設計を指し、統制と自動化を両立させるための基本パターンです。
AIエージェントとワークフローは、実行モデルが違う
2つ目の混同ポイントは「AIエージェント」と「ワークフロー」です。この2つは優劣の関係ではなく、実行モデルが根本的に異なります。ワークフローはStep A→Step B→Step Cのように経路が事前に定義され、エージェントはGoal→Reason→Select Tool→Observe→Decideのループで、その場で次の一手を選びます。
エージェントは情報収集や複数ツールの使い分け、推薦に強く、ワークフローは承認・コンプライアンス・財務統制・転記に向きます。つまり「探索はエージェント、統制はワークフロー」という役割分担になります。エージェントに実行権限まで渡すと、経路の再現性が失われ、監査に耐えられません。
| 観点 | AIエージェント | ワークフロー |
|---|---|---|
| 実行モデル | Goal→Reason→道具選択→観察→判断（ループ） | Step A→Step B→Step C（固定パス） |
| 経路の再現性 | 入力や状況によって変わる | 同じ入力なら常に同じ |
| 得意な業務 | 情報収集・複数ツールの使い分け・推薦・下書き | 承認・コンプライアンス・財務統制・伝票転記 |
| 監査への適合 | 根拠提示の設計が別途必要 | 経路と承認記録がそのまま証跡になる |
| 失敗時の影響 | 回答の質が下がる（人が気づける） | 誤転記・統制違反に直結する |
| 主な実装 | Joule／Joule StudioとAI Core・Generative AI Hub | SAP Build Process Automation |
やってはいけない設計：LLMから直接トランザクションを実行する
もっとも危険なのは、LLMの出力をそのままS/4HANAの登録APIに渡す構成です。ハルシネーションや項目の取り違えが、そのまま誤転記・統制違反になります。AIには「提案」までを担わせ、実行は必ず検証と承認を経由させるのが原則です。
02POINTS Human-in-the-loopを組み込む5ステップ
ここからは、実際の業務プロセスにHuman-in-the-loopを組み込む手順を5ステップで整理します。ポイントは、AIの出力を業務データに変換する「関所」を明確にし、各ステップの責任範囲をシステム側に固定することです。
- ①業務を「確率」と「決定」に仕分ける対象プロセスを1つ選び、そこに含まれる作業をAI側（理解・要約・推薦・抽出・生成）とシステム側（検証・計算・権限・承認・転記）に分類します。迷ったら「同じ入力で結果が変わってよいか」で判断し、変わってはいけない作業はAI側に置きません。
- ②AIの出力を「提案」に限定するJouleやGenerative AI Hubから返すのは、転記内容そのものではなく「推奨案＋根拠＋確信度」です。Joule Skillとして業務データを取得するツール（仕入先情報、未処理の発注、納入履歴など）を呼び出し、判断材料を集めるところまでを担わせ、実行権限は与えません。
- ③CAPで決定論的検証を挟むAIの提案をCAPのサービスで受け、必須項目・整合性・重複・権限を業務ルールとして検証します。ここがAIの出力を業務データに変換する関所になります。金額・税・在庫数量はCAPまたはS/4HANA側で計算し直し、AIが提示した数値をそのまま採用しません。
- ④Build Process Automationで承認と統制を入れる閾値を超える案件や高リスクの変更は、SAP Build Process Automationの承認ワークフローに回します。上長承認やコンプライアンス確認をフォームとユーザータスクで受け、判断の記録を残します。承認条件は業務ルールとして外に出し、アプリのコードに埋め込みません。
- ⑤承認済みの内容だけをS/4HANAへ転記する最後の実行はS/4HANAの標準API（またはCAPのサービス経由）で行い、実行者・日時・根拠を監査ログに残します。却下や差戻しは転記せず、理由とともに記録します。この最終ステップにAIは関与させません。
閾値は「金額」だけで決めない
影響範囲、取消しの可否、規制対象かどうかも分岐条件に含めると安全です。たとえば少額でも取引先マスタの変更や与信限度の変更は人手承認に回す、といった設計が実務的です。運用初期は閾値を低めに設定し、承認ログを見ながら自動化範囲を広げるほうが、後から統制を足すよりはるかに低コストです。
03INSIGHT 「どこまで自動で実行してよいか」を設計として決める
実務で問われるのは「AIで何ができるか」ではなくどこまで自動で実行してよいかです。同じAIの提案でも、購買依頼の下書き作成と発注の確定では、求められる統制の重みがまったく違います。前者は誤りを人が直せば済みますが、後者は誤ると在庫と支払が動いてしまいます。
そこで設計の起点になるのが業務プロセスの棚卸しです。各作業を確率的タスクと決定論的タスクに仕分け、決定タスクの実行主体をCAP・SAP Build Process Automation・S/4HANAのどこに置くかを決めます。ADTでは、この仕分けから検証サービスの設計、承認フローの構築、S/4HANA APIとの接続までを一貫して支援しています。
AIの提案を作る側の土台はSAP AI Core／Generative AI Hubとは？BTP上でLLMを安全に使う仕組みで、S/4HANAとLLMをつなぐ拡張アプリの実装はSAP BTP CAP入門：Cloud Application Programming Modelで作るS/4HANA拡張アプリで解説しています。検証ロジックをS/4HANA本体側に持たせたい場合は、SAP RAPとは？ABAP RESTful Application ModelでS/4HANA本体を拡張すると組み合わせると設計の幅が広がります。
豆知識：SAP Build Process Automationの位置づけ
SAP Build Process Automationは、BTP上で承認・フォーム・業務ルールといったワークフロー機能と、API連携やロボットによる自動化を1つの環境にまとめたサービスです。ローコードで業務担当者がフローを組み替えられるため、「承認条件を変えるたびにアプリを改修する」という事態を避けられます。
まとめ
- AIは確率的タスク（理解・要約・推薦・抽出・生成）に限定し、決定論的業務ロジック（検証・計算・権限・承認・転記）はシステム側に残す
- エージェントは経路を都度決めるループ、ワークフローは固定パス。統制が必要な業務はワークフローに置く
- AIの出力は「推奨案＋根拠＋確信度」までとし、転記内容そのものは返させない
- CAPの検証を関所にし、金額・税・在庫数量はシステム側で計算し直す
- 金額とリスクの閾値で分岐し、閾値以上だけBuild Process Automationの人手承認に回す
- 最終的な転記は承認済みの内容のみ。実行者・日時・根拠を監査ログに残す
04FAQ よくある質問
AIエージェントを導入すれば、ワークフローは不要になりますか？
不要にはなりません。企業の設計は「エージェント→ワークフロー→人→伝票」の順につなぐのが基本です。エージェントは判断材料の収集と推薦までを担い、実行の統制はワークフローが担います。役割を分けたほうが、監査にも運用にも耐えます。
承認を挟むと自動化の意味が薄くなりませんか？
すべての案件に承認を挟む必要はありません。金額やリスクの閾値で分岐し、閾値未満は自動承認＋記録、閾値以上だけ人手承認にすれば、統制と速度を両立できます。運用初期は閾値を低めに設定し、ログを見ながら自動化範囲を広げるのが現実的です。
承認フローは何で作るのが標準ですか？
SAP BTP上であれば、SAP Build Process Automationが標準的な選択肢になります。承認・フォーム・業務ルール・自動化を同じ環境で扱え、CAPのサービスやS/4HANAのAPIと組み合わせられます。既存のSAPワークフローを活かす構成も選択できます。
PoCの段階でもHuman-in-the-loopは必要ですか？
PoCでも、提案→検証→承認という型だけは通しておくことをおすすめします。実行系の操作はダミー環境やテストクライアントに限定しつつ、フローの骨格を先に作っておけば、本番化のときに構成を作り直さずに済みます。
出典・参考
- SAP Help Portal — SAP Build Process Automation（SAP） https://help.sap.com/docs/build-service/
- SAP Help Portal — SAP AI Core（SAP） https://help.sap.com/docs/sap-ai-core
- Generative AI Hub — Concepts（SAP Developer Center） https://developers.sap.com/concepts/generative-ai-hub/
- What Is SAP Business Technology Platform?（SAP Help Portal） https://help.sap.com/docs/btp/sap-business-technology-platform/what-is-sap-business-technology-platform
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-09-21）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。