Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Agentic ERPをどう設計するか ー 受発注エージェントを動かす、現場の知見と設計思想ー

Agentic ERPをどう設計するか ー 受発注エージェントを動かす、現場の知見と設計思想ー

2026年6月9日にAI Engineering Summit Tokyo 2026にて弊社執行役員CTOの平松とプロダクト責任者の梅田が登壇した際に投影した資料です。

ERPは「人が操作するシステム」から「AIエージェントが業務を自律的に遂行するシステム」へ転換する。リチェルカはこの構想を「Agentic ERP」と呼び、受発注領域で実現に取り組んでいます。しかしエンタープライズの受発注業務をエージェントに任せるには、非定型な帳票処理、取引先ごとの商慣習への適応、ミスが許されない業務での信頼性設計など、固有の難しさがあります。本セッションでは、その設計思想と技術的知見を共有します。

More Decks by 株式会社リチェルカ

Other Decks in Technology

Transcript

  1. 自己紹介 平松 拓 リチェルカ | 執行役員 CTO フリークアウト | エンジニア

    ⇩ カケハシ | Tech Lead ⇩ アトラスト・ヘルス | CTO ⇩ リチェルカ | CTO CTOとして、開発組織全体を管掌 2
  2. 自己紹介 梅田 脩平 リチェルカ | プロダクト責任者 KDDI | 代理店営業、プロジェクトマネジメント ⇩

    ウミトロン | 営業、CS、PdM ⇩ カケハシ | CS、エンジニア ⇩ リチェルカ | PdM、開発、FDE プロダクト責任者として開発業務全般を担当 3
  3. CONFIDENTIAL 会社概要 資本⾦等 800,000,000円 設⽴ 2022年4⽉8⽇ 会社名 株式会社リチェルカ 代表 代表取締役CEO

    梅⽥ 祥太朗 所在地 東京都港区芝浦4-11-17 中野スプリングビル6階 連絡先 [email protected] AIの社会実装を通じて、今までの“できない”を解決する 主要投資家 借⼊⾦融機関 4
  4. ペインが深く、個社毎にDeep-diveする必要のある受発注領域にフォーカス 見積 • 取引先管理 • 見積作成/承認WF • 履歴管理 販売 •

    注文受入 • 注文内容チェック • 納期確認/納期管理 • 請求書出力 出庫 • 出荷指示 • 注文内容チェック • 配送伝票出力 生産 • 生産管理 • 計画手配 • 製造管理 商品管理 • マスタ管理 • 情報更新 • 履歴管理 • 申請ワークフロー 在庫 • 販売品管理 • サンプル品管理 • 棚卸し • 拠点管理 仕入計画 • 発注点管理 • 発注残管理 • 納期確認 仕入 • 仕入予定管理 • 見積確認 • 発注 • 進捗管理 入庫 • ロス管理 • 検品管理 • 納品書/請求書照合 会計システム • 債権計上 • 入金 • 伝票転記 • 決算処理 • 伝票転記 • 決算処理 人事 • 人事管理 • 給与管理 • 申請管理 • 勤怠管理 CONFIDENTIAL 私たちが最終的に提供する領域 得 意 先 仕 ⼊ 先 6
  5. ペインが深く、個社毎にDeep-diveする必要のある受発注領域にフォーカス 見積 • 取引先管理 • 見積作成/承認WF • 履歴管理 販売 •

    注文受入 • 注文内容チェック • 納期確認/納期管理 • 請求書出力 出庫 • 出荷指示 • 注文内容チェック • 配送伝票出力 生産 • 生産管理 • 計画手配 • 製造管理 商品管理 • マスタ管理 • 情報更新 • 履歴管理 • 申請ワークフロー 在庫 • 販売品管理 • サンプル品管理 • 棚卸し • 拠点管理 仕入計画 • 発注点管理 • 発注残管理 • 納期確認 仕入 • 仕入予定管理 • 見積確認 • 発注 • 進捗管理 入庫 • ロス管理 • 検品管理 • 納品書/請求書照合 会計システム • 債権計上 • 入金 • 伝票転記 • 決算処理 • 伝票転記 • 決算処理 人事 • 人事管理 • 給与管理 • 申請管理 • 勤怠管理 CONFIDENTIAL 私たちが最終的に提供する領域 得 意 先 仕 ⼊ 先 Agt 現在提供中のエージェント ⾒積作成 Agt 受注登録 Agt リベート請求 Agt ⾒積査定 Agt 発注最適化 Agt 納品消込 Agt 品番特定 Agt 7
  6. 受発注業務とは? 登場するのは三者。注文に対して、モノは メーカー → 卸 → 飲食店 へ流れる 飲食店 (注文者)

    「ビールください」 卸(商社) 食品メーカー (供給元) 注文 ▶ 注文 ▶ 一見すると、とてもシンプルで簡単そうに見える。 ▶ 納品 ▶ 納品 | 受発注業務における現場の課題 13
  7. しかし実際には ── 判断と例外だらけ 飲食店 (注文者) 「いつものビール!20で!」 卸(商社) 在庫確認・発注 食品メーカー (供給元)

    ▶ ▶ 注文 注文 受注の課題 (飲食店 → 卸) 仕入・納品の課題 (卸 → メーカー / 飲食店) 品目特定:「いつものビール」=銘柄は?・容量・形状が曖 昧 単位解釈:ケース / バラ / 入数の解釈が違う 納期回答・受領連絡が要る取引先がある 注文書に書いていない納品先へ配送 最低注文ロットがある(少量だと発注できないので、他の 注文と調整・合算) 分納が発生し、納品日がバラバラになる 在庫切れ → 代替品を別メーカーへ発注 → シンプルに見えて、実は一件ごとに判断・例外がぎっしり。 ▶ 納品 ▶ 納品 頻繁に発生する価格改定(自社マスタとの乖離) | 受発注業務における現場の課題 14
  8. 暗黙知をナレッジ化しないと、自動化できない なぜ自動化できないのか 判断基準は、人の頭の中にしかない「暗黙知」。既存 ERP にはデータとして溜まっていない。 リチェルカのアプローチ 01 人は「例外対応の確認」だけを行う 02 例外時に「どう対応し、なぜそう判断したか」を記録する

    03 次回 Agent 起動時に、その判断を参照する 04 2回目以降は、自動対応の可否を確認しながらナレッジに蓄積する → 暗黙知が「資産」として溜まり、回すほど自動化率が上がる。 | 受発注業務における現場の課題 15
  9. | Agentic ERPとは何か • ERP = Enterprise Resource Planning(企業資源計画) • 企業の基幹業務を統合管理するシステム

    • 受注‧在庫‧購買‧請求‧会計などの状態を⼀元的に管理する ERPとは 19
  10. | Agentic ERPとは何か Agentic ERPとは 従来型 ERP ⼈間がUIを⾒て判断‧操作し、 業務を遂⾏することを前提とした設計。 ⼈ UI

    ERP Agentic ERP エージェントシステムが判断‧実⾏を担い、 直接状態を更新することを前提とした設計。 エージェント システム AOP 業務遂⾏ Agentic ERPは、エージェントシステムが判断と実⾏を担うERPである 21
  11. | Agentic ERPとは何か Agentic ERPは、画⾯操作の⾃動化ではない Agentic ERP 業務全体をエージェント主体で設計する 特定の操作だけでなく、AOPから導かれる Workflowに沿って判断と実⾏を担う。 エージェント

    システム → AOP → 業務遂⾏ Agent as RPA 特定の操作を代⾏する UIのボタンを押せても、業務意図‧統制‧監 査‧フィードバックループはERPの外に残り やすい。 Agent → UI → ERP 22
  12. | 暗黙知をどう扱うか 暗黙知の正体 従来のERP(状態の管理) 受注‧在庫‧発注などの「データ」は存在す る。しかし、それは静的な記録に過ぎない。 ⼈の暗黙知(状態の更新) そのデータをどう読み、例外時にどう動く か。現場の「判断」が業務を完遂させてい る。 受発注に潜む具体的な暗黙知の例

    • 品⽬‧単位の特定:「いつものビール」が何 を指すか。2Cが2ケースかカートンか。 • 優先順位の調整:⽋品時、重要顧客なら納期 再調整、⼀般なら分納を提案。 • 例外的な納品:注⽂書にない配送先や、特定 顧客のみの受領連絡ルール。 • リスクの⾒極め:「この注⽂は何か危ない」 という過去のトラブルに基づく直感。 25
  13. 暗黙知をシステムで扱うために設計するもの | 暗黙知をどう扱うか 設計対象 何を表すか AOP エージェント向け業務手順書 Workflow AOPから導かれる業務フロー Action Workflow内の実行単位

    Rule AIエージェントが判断時に参照する業務ルール Execution Policy 実行してよい条件 Audit 判断と実行の記録 フィードバックループ 次回改善の仕組み 26
  14. | 暗黙知をどう扱うか AOPとは何か SOPが⼈間向けの業務⼿順書なら、 AOPはエージェントシステム向けの業務⼿順書である SOP → AOP SOP = Standard

    Operating Procedures 人間向けの業務手順書 AOP = Agent Operating Procedures エージェントシステム向けの業務手順書 AOP ≠ Prompt Workflow AOPから導かれる業務フロー Action Workflow内の実⾏単位 Rule 何を選ぶかを判断する業務ルール Execution Policy 選ばれたActionを実⾏してよい条件 Eval 期待する判断‧実⾏かを確認する評 価ケース 27
  15. | 暗黙知をどう扱うか AOPはどう実⾏されるか Agentic ERPの中⼼は会話ではなく、業務イベントをきっかけにした実⾏である INPUT 業務イベント + 現在の業務状態 CORE LOGIC

    AOP / Workflow EXECUTION Action SYSTEM 業務結果を ERPへ反映 Audit / フィードバックループ ‧現在の業務状態を読み、Workflowに沿ってActionを実⾏ ‧判断と実⾏はAuditとして記録される ‧修正理由やログは、次回のAOP / Rule / Evalの改善に活⽤さ れる 28
  16. | 暗黙知をどう育てるか フィードバックループは例外から始まる Exception ⽋品 代替品を提案する 分納する 納期を再調整する 追加発注する 顧客に確認する 選ばれた対応と修正理由

    「重要顧客のため分納ではなく、 確実な納期再調整を優先」 Feedback Event Agentic ERPでは例外を構造化し、⼈間による修正とその理由を改善のデータ(Feedback Event)に変える ‧例外への対応履歴を構造化 ‧修正理由をルール改善の種に変換 30
  17. | 暗黙知をどう育てるか ⾃律的改善を⽣むフィードバックループ 1. Agent Proposal ⽋品: 「分納を提案します」 2. Human Intervention

    • 変更:分納 → 納期再調整 • 却下:代替提案を⽌め確認へ • 条件承認:送料負担ありで許 可 • エスカ:重要顧客につき責任 者へ 3. Feedback Event (Data) ‧提案Action / 最終対応 / 修正理由 ‧顧客特性 / 商品カテゴリ / ⾦額 ‧納期影響 / 例外種別 / 適⽤条件 暗黙知を構造化データとして蓄積 4. Next Agent Run 類似ケースで「分納」の優先度を下げる 業務⽂脈を学習し、精度が向上 ⼈間による修正(変更‧却下‧条件付‧エスカ)を改善の種に変え、システムに暗黙知を還流させる 31
  18. | 暗黙知をどう育てるか ⾃律的なルール改善:2つのフィードバックループ エージェントがルール改善案を⽣成‧評価し、Execution Policyの制御下で⾃律的に反映する Loop A: AOPからの抽出 AOP ルール候補 Eval

    ルール更新 Loop B: 現場知のルール化 (暗黙知の還流) 例外対応ログ / 修正理由 暗黙知のルール化 ルール改善案 追加/更新/削除 Eval ルール更新 • 重要な変更は Execution Policyと Evalで厳格に制御 33
  19. | 暗黙知をどう育てるか アウトカムを「業務完遂率」で測る エージェント単体の正答率ではなく、業務完遂できたかを評価指標にする • 従来指標の限界 • OCR精度だけでは⾜りない • エージェント単体の正答率だけでも ⾜りない

    • ⾒るべきは 業務完遂率 エージェントシステムが、⼈間の適切な関与を含めて、 業務状態を完遂状態まで進められた割合 業務プロセスの流れ • 業務完遂こそが最⼤の成果 ⼈間が介在しても、適切にルーティングされ最終的に業務が「完 遂」すれば成功と定義する ⼊⼒ Agent System ERP更新 完遂 34