案例速覽
| 項目 | 內容 |
|---|---|
| 國家 | 日本（總公司位於大阪） |
| 產業 | 西洋料理食材的企劃、開發、製造與批發（客戶以飯店、餐廳、婚宴業者為主） |
| 企業規模 | 員工 114 人；1957 年創業；全國約 6,000 家客戶（見註解） |
| 導入項目 | (1) RPA：自動下載、列印網路平台訂單（2021 年起實際運作）；(2) 接單 AI Agent：將訂單上的商品名、客戶資訊比對自家主檔，產出可匯入銷售管理系統的資料（2024 年 11 月起進行 PoC） |
| 來源與日期 | 主要來源：ITmedia Keyman's Net（2025-05-08）；另參考 Usac System 新聞稿（2024-11-29、2025-02-13）、內田洋行講座報告（2025-04-21）、Usac System RPA 導入案例頁等。完整網址見文末。 |
註：員工數出自 ITmedia；創業年與客戶數出自 2025 年 2 月新聞稿。2022 年前後的 RPA 案例頁寫的是「全國約 1 萬家店鋪」、「1972 年設立」，計算單位與定義不同。
背景與問題：只有老手才看得懂的訂單
食品批發業的早上很趕。Matsuya（マツヤ）系統管理部門主管小嶋康之在 RPA 導入案例中說明過這個作業節奏：大型飯店多半會提前下單，小型餐廳則往往營業到深夜，打烊後才訂購隔天的食材。批發商從一早開始處理這些訂單，並安排當天送達。訂購量大的客戶，一張單子就有 50 到 60 個品項。
在同一篇案例中，常務董事大谷浩平補充了當時的出勤狀況：公司表定早上 7 點上班，員工通常 6 點到 6 點半就到公司，為了把訂單印出來這種單純的準備工作，每天提早半小時。這是他們導入 RPA 的起點。
印訂單花時間，是因為訂單來源很雜。Matsuya 有許多飯店客戶，大量訂單透過飯店專用的採購網站 IPORTER 進來；此外還有企業間交易平台 BtoB Platform（由 Infomart 營運），以及電話、FAX 和 Email。
這些管道的處理難度不同：
- 能直接匯入系統的：EOS、EDI 這類標準化的電子訂單，資料可以直接進到銷售管理系統。
- 必須人工轉打的：以 IPORTER 為例，每家飯店的網址都不同，員工必須一家一家登入，下載 PDF 或 CSV 格式的訂購單。訂購單上印的是客戶自己內部的商品代號與品名，業務人員要對照過去的交易明細，換成 Matsuya 自家的品號，再輸入銷售管理系統（2024 年 11 月新聞稿寫明為 OBIC7）。
廠商在講座中說，從 IPORTER 進來的訂單「本質上和 FAX 手寫訂單是同一種形態」，中間一定要靠人判斷。
人工判斷難在哪裡？參考來源列出了不少實例：
- 簡稱與習慣叫法：客戶不寫正式商品名稱，而是寫簡稱或習慣叫法，屬於「懂的人就懂」的類型。
- 字面比對對不上：日文漢字寫法、送假名不一致，直接用字串比對對不上。
- 外文名稱與近似品多：西洋食材常有法文、義大利文等不同叫法，類似商品又多，小嶋說這連老手都覺得難。
- 品項寫在備註欄：商品名稱欄位只填了大類別，具體品項寫在備註欄裡。
- 每家客戶規矩不同：溫度帶（常溫、冷藏、冷凍）、尺寸、指定出貨倉庫，以及客戶的訂購單位與批發商的出貨單位換算，每家客戶各有規矩。
系統廠商 Usac System 的上野真裕指出，這類接單工作通常要學 3 個月到半年才能上手，容易變成只有特定某個人會做。Matsuya 當時就是這樣：平常負責的人不在，換別人代班處理，就會接錯單。
他們怎麼做：先 RPA，再 AI
第一階段（2021 年起，實際運作）：先把不用判斷的動作自動化
Matsuya 在 2021 年導入 Usac System 的 RPA 工具 Auto Job Meijin（Autoジョブ名人）。根據廠商的導入案例頁，過程如下：
- 先試用，2021 年 9 月正式開始開發。
- 套用廠商預先做好的標準化腳本範本，只要填入各家飯店的名稱、帳號密碼等固定參數，就能產生對應不同平台的腳本。
- 9 月內做出 106 支腳本：IPORTER 89 支、BtoB Platform 17 支。
- 10 月先在客戶量最大的大阪據點上線，11 月擴展到東京、名古屋、京都、神戶、福岡 5 個據點，趕上 12 月的年底旺季。
- 全公司每天由 RPA 自動執行約 400 次作業。
兩個平台的自動化終點不同。BtoB Platform 的訂單可以一路自動化到把資料匯入核心系統；IPORTER 只做到自動下載並印出訂購單，印出來之後，還是由熟手看著紙本一筆一筆打進系統。
2025 年的講座上，廠商說 Matsuya 累計已有 203 支自動化腳本在運作。
第二階段（2024 年 11 月起，PoC）：讓 AI 接手需要判斷的那一步
RPA 做完之後，剩下的是最仰賴經驗的環節：把客戶寫的商品名對應到自家品號、設定交期、處理備註要求。2024 年 11 月，Matsuya 和 Usac System 開始接單 AI Agent（受注AIエージェント）的 PoC（概念驗證），範圍收得很小：
- 測試對象：只針對 IPORTER 進來的訂單，且只挑 3 家有歷史往來紀錄的老客戶。
- 做法：先把這 3 家客戶過去的交易資料交給 AI 學習與累積，之後遇到類似的新訂單時，由 AI 自動轉換。
- 預定檢驗項目：OCR 讀取、商品檢索、兩者配對、業務人員判斷規則的反映、輸出成核心系統格式，共 5 項（出自 2024-11-29 新聞稿）。
這套 AI Agent 怎麼判斷？綜合各篇來源，機制分為四塊：
- 查閱公司內部資料（RAG）：透過檢索增強生成（RAG），讓 AI 參考商品主檔、歷史交易明細與內部規則。ITmedia 舉的規則例子是：訂購單上寫「最短」，交期就設為接單日加 3 天。這類規則可以整理成資料庫讓 AI 查閱。廠商在講座上的比喻是，RAG 等於讓 AI「看小抄」。
- 處理簡稱與寫法出入：針對懂的人才懂的簡稱，先把對照規則寫成類似手冊的說明交給 AI；針對寫法有出入的商品名，AI 綜合「語意與字串的相似程度」以及「與其他欄位的關聯性」，選出最可能的商品代號。
- 解讀備註欄：備註欄裡的特殊指示也交由 AI 讀取並處理，過去這部分只能靠人看。
- 由人做最後確認：AI 產出準備匯入銷售管理系統的 CSV 檔後，由人檢查並按下確定。上野的比喻是「新人負責輸入、前輩負責檢查」。
這是 AI Agent 和傳統 AI-OCR 的主要差別：人要檢查的東西不同了。傳統 OCR 只負責把紙上的字轉成文字，人要逐字核對有沒有認錯字、代號跟品名對不對得上；Agent 模仿的是熟手看到這張單子時會在主檔裡選哪個品號，檢查的人只要確認 AI 選的品號和自己想的一樣，負擔輕很多。
廠商在講座中也說明了這套產品設計上的完整流程（以下為產品藍圖，Matsuya 這次 PoC 實際測試的只有 IPORTER 訂單）：
- FAX 進來的訂購單，由多功能事務機轉成 PDF，存入指定資料夾。
- Web 平台與 Email 進來的訂單，由 RPA（Auto Job Meijin、Auto Mail Meijin）自動收集。
- 接單 AI Agent 依照學過的規則與歷史實績，產出符合銷售管理系統格式的接單資料。
- 人確認無誤後，按下確定匯入。
PoC 的測試樣本裡也放了難題：傳票號碼、訂購日、交貨日寫在同一行；商品代號拆成好幾行；商品名稱欄位只寫了大類別。根據來源，Agent 都能從商品主檔中選出對應商品；不過也遇到商品名稱連一個字都對不上的訂單，最後要靠個別處理才解決。
時程與成本
公開時程表
| 時間 | 事件 | 性質 |
|---|---|---|
| 2021 年 9 月 | RPA 試用結束，正式開始開發（當月完成 106 支腳本） | 實際運作 |
| 2021 年 10 月 | 大阪據點率先上線 | 實際運作 |
| 2021 年 11 月 | 擴展至東京等其他 5 個據點，於 12 月旺季前完成部署 | 實際運作 |
| 2024 年 7 月 31 日 | Usac System 與 WEEL 共同發表接單 AI Agent PoC 服務 | 廠商動態 |
| 2024 年 11 月 | Matsuya 開始接單 AI Agent PoC（新聞稿於 11/29 發布） | PoC |
| 2025 年 2 月 13 日 | 雙方公布 PoC 驗證結果 | PoC |
| 2025 年 3 月 11–23 日 | 於內田洋行「食品 IT 展 2025 線上」講座發表案例 | 公開講座 |
| 2025 年 5 月 8 日 | ITmedia 刊出報導 | 媒體報導 |
從宣布開始 PoC 到公布結果，大約兩個半月（依新聞稿日期推算）。廠商在講座中說明，這項 PoC 服務的標準期程約 2 個月：第 1 個月進行業務訪談與開發，第 2 個月反覆檢驗與調整；客戶只需配合開幾次會、提供既有資料。這是廠商對服務流程的一般說明，來源沒有說 Matsuya 是否完全照這個安排。
成本與技術底座：PoC 是付費服務，金額未公開
- PoC 與導入費用：Usac System 與 AI 顧問開發公司 WEEL 在 2024 年 7 月共同推出這項 PoC 服務時，頁面註明為付費服務，需洽談報價。Matsuya 這次 PoC 的費用、前期 RPA 的授權與導入費，以及正式導入 AI 的費用，都沒有公開。
- 底層模型：Matsuya 在 PoC 階段用的是哪一款大型語言模型，沒有公開。AWS 日本官方部落格（2025-07-02）寫到，這項服務產品化後的 Knowfa 接單 AI Agent 建在 Amazon Bedrock 上，由 3 名工程師加 1 名 PM，花約 4 個月開發出 β 版。
- 唯一和錢有關的數字：常務董事大谷浩平對 RPA 效益的估算。每年省下 3,276 小時，若以假設時薪 2,000 日圓計算，相當於每年省下 600 萬日圓以上的人力成本。這是粗估，沒有扣除 RPA 的授權與維護費用。
PoC 之後有沒有正式上線：未公開
2025 年 2 月的結果新聞稿寫道，Matsuya 認為這次結果值得正式評估導入。小嶋的評語是：這次驗證讓他確信不可能會變成可能，只是細節上還有課題。
截至本文撰寫時（2026 年 10 月），公開資料中查不到 Matsuya 正式上線這套 AI Agent 的消息。廠商在 2025 年 6 月推出產品 β 版（定名為 Knowfa 接單 AI Agent），2026 年 4 月推出正式版 V1；廠商表示自 β 版推出至 2026 年 2 月已累計導入超過 50 家企業，但沒有說明 Matsuya 是否在其中。
成果數字拆解
這類案例裡，不同階段、不同定義的數字很容易被混在一起。以下把所有公開數字拆開對照：
| 數字 | 指的是什麼 | 性質 | 前提與限制 |
|---|---|---|---|
| 每年 3,276 小時 | RPA 自動下載、列印（及部分匯入）IPORTER 與 BtoB Platform 訂單所省下的時間 | 實際運作（公司換算） | 每月 273 小時 × 12 個月。出自 2022 年前後的 RPA 案例頁，當時有 106 支腳本；以每筆人工操作約 2 分鐘換算。 |
| 600 萬日圓以上 | 上述 3,276 小時折算的人力成本 | 公司估算 | 假設時薪 2,000 日圓，未扣除系統建置與授權成本。 |
| 203 支 | 運作中的 RPA 自動化腳本總數 | 實際運作 | 2025 年講座公布的數字；腳本數比初期多了將近一倍，但省下的時數沒有更新。 |
| 86% → 100% | 商品資訊與客戶資訊的檢索比對一致率 | PoC | 出自 ITmedia。樣本為 3 家老客戶 × 16 張 = 48 張訂單，經多次調整後的結果（可能與下方第 3 項為同一指標的不同寫法）。 |
| 第 1 項：93.03% | 取得訂購單資訊（OCR 讀取）的準確度 | PoC | 出自 2025 年 2 月新聞稿，同一批 48 張樣本。 |
| 第 2 項：100% | 輸出成核心系統可匯入的格式 | PoC | 出自 2025 年 2 月新聞稿，同一批樣本。 |
| 第 3 項：100% | 轉換成自家商品代號的準確度 | PoC | 出自 2025 年 2 月新聞稿，同一批樣本。 |
| 第 1–3 項整體：100% | 第 1 到第 3 項一連串動作的驗證結果 | PoC | 出自 2025 年 2 月新聞稿。第 1 項只有 93.03%，整體卻是 100%，見下節第 3 點。 |
| 「93.0% 以上」 | 從 IPORTER 取得資料到核心系統連動的自動化程度 | PoC | 新聞稿標題與導言的總結寫法。 |
| 80% | 傳統 RPA 做不到的非定型接單工作，已可自動化 80% | 廠商宣稱 | 出自 AWS 部落格。指 Knowfa 產品整體，不是 Matsuya 單一案例，也沒有說明計算基準。 |
| 70% → 80% → 90% | 小嶋希望自動化程度分階段提高的目標 | 內部期望 | 小嶋自己說，馬上做到 100% 是不可能的。 |
踩坑與數字背後的前提
比對原始資料後，以下 7 個前提需要先看清楚。
1. 48 張樣本很少，而且都是好處理的老客戶
PoC 的樣本只有 3 家客戶、共 48 張訂單，都是有歷史交易紀錄的老客戶。Matsuya 全國約有 6,000 家客戶，每家寫法不同。ITmedia 報導的導言卻寫道，PoC 後「已能以 100% 的精度判斷既有客戶的訂購單」，把 3 家、48 張的結果講成了全體既有客戶。
廠商自己在講座上的說法比較保守：對有交易實績、能套用公司經驗的老客戶已可實用；沒有歷史經驗可循的新客戶，準確度達不到同樣水準。廠商也補充，換成人來做也是一樣。
2. 100% 是調出來的，沒有說明調整用和驗收用的訂單是否分開
商品比對一致率從 86% 起步，反覆調整後到 100%。如果調整規則時看的訂單，和最後驗收算成績的是同一批 48 張，這個 100% 比較接近「這 48 張都調對了」，不代表下一張新訂單也是 100%。公開來源沒有交代是否另外保留一組 AI 沒看過的訂單（hold-out test set）做最終測試。在這個前提沒交代的情況下，媒體導言把結果推廣到所有既有客戶，推論範圍已經超出樣本。
3. 第一步只有 93%，整體卻是 100%；同一個結果在各處說法不同
新聞稿的結果表裡，第 1 項取得訂購單資訊（OCR）的準確度是 93.03%，第 1 到 3 項串起來的整體結果卻是 100%。
新聞稿的解釋是：事先登錄對應模式後，OCR 讀錯時，後段的 Agent 會回頭補正讀取結果。但新聞稿沒說補正了幾筆，也沒說明 100% 是否全靠這個補正。同一份成果，各來源的寫法也不同：
- 廠商新聞稿標題：實現 93.0% 以上的自動化
- 內田洋行講座報告：達到與人工處理幾乎同等的精度
- ITmedia 內文：比對一致率 100%
- ITmedia 導言：既有客戶的訂購單都能以 100% 精度判斷
- OCR 能否做到 100%：新聞稿寫已確認可行，講座上只說認為可行
說法越往媒體導言走，結論就越大。 讀到這類數字時，可以先問兩個問題：每一列的分母是什麼？前一步讀錯的那約 7% 資料，後來去哪裡了？
4. 預定檢驗 5 項，結果只公布 4 列，判斷規則那一項沒有獨立數字
2024 年 11 月宣布開始 PoC 的新聞稿，列出要驗證 5 個項目，其中第 4 項是「業務人員判斷基準的反映程度」。2025 年 2 月公布結果時，表格只有 OCR 讀取、格式輸出、商品代號轉換，以及前 3 項整體結果共 4 列，沒有這一項。這個案例要證明的正是 AI 能不能接手老手的判斷，但這一項沒有公布單獨的數字。
5. PoC 只做到產出檔案，還沒寫進核心系統，也只測了單一平台
小嶋在講座中說，這次 PoC 做到產出與訂單對應好的資料為止，下一步才是匯入核心銷售管理系統，而他預期大概會在那一步出現需要改善的地方。他也擔心客戶第一次訂購某個商品時，AI 比對商品主檔可能出錯。此外，系統設計上可以接 FAX 和 Email，但這次實測的只有 IPORTER；對於手寫 FAX 和 Email，小嶋的說法是期待未來也能這樣處理，這是還沒驗證的下一步。
6. 年省 3,276 小時是 RPA 的成果，而且是舊數字
不少轉述文章把「AI 準確率 100%」和「每年省下 3,276 小時」放在同一段，讀起來像是 AI Agent 省下的時間。AI 這一段省了多少工時，來源從頭到尾沒有公布。
ITmedia 的報導也把「目前有 203 個自動化流程在運作」和「每年省下 3,276 小時」寫在同一句，讀起來像是 203 支腳本的總效益。但廠商的 RPA 案例頁顯示，3,276 小時是 2022 年前後算出來的，當時只有 106 支腳本。之後腳本數多了將近一倍，省下的時數仍沿用舊數字。媒體把新舊數字寫在一起時，讀者很難察覺其中的時間差。
7. 所有數據都是當事人與利害關係人自述
資訊來源的結構：主要媒體報導改寫自線上講座，講座由 Matsuya 與 Usac System 共同發表；主辦講座的內田洋行，是當年把這套 RPA 介紹給 Matsuya 的合作廠商；PoC 服務由 Usac System 與 WEEL 共同提供（是付費服務，但來源沒有說明 WEEL 在本案中的分工）；AWS 部落格則由 AWS 與 Usac System 共同撰寫。
這個案例背後的 6 個實務原則
數字有上述限制，但 Matsuya 的推進方式仍有幾點可以參考。
- 先把固定動作做完，再處理需要判斷的：Matsuya 沒有一開始就導入 AI。他們先花一個月用 RPA 把登入、下載、列印這些每次都一樣的動作自動化，2021 年就開始省時間。RPA 做不到的部分，才交給 AI 試。這個順序讓 AI 的任務範圍很清楚，PoC 的範圍也容易界定。
- AI 的判斷力來自整理好的資料：AI 能把客戶的簡稱對到正確品號，靠的是它查得到商品主檔、歷史交易明細和寫下來的規則。最重的工作在資料整理與系統整合。 這些知識本來就在公司裡，只是散在老手的腦袋、過往交易紀錄和默契中，要先整理成 AI 查得到的形式。
- 省下的時間要先規劃去處：上野在報導中提到，把打單時的判斷交給 AI 後，接單人員可以把時間放在交期協調、庫存調度、缺貨處理這類需要和客戶溝通的工作上。工作會重新分工，不會全部消失。導入前就該想好，省下來的時間要放到哪裡。
- 檢查方式決定系統能不能長期使用：從傳統 OCR 換成 AI Agent，人工檢查從逐字核對變成確認選中的品號對不對。正式上線後一定會遇到新客戶、新商品、新寫法；AI 判斷錯誤時，要讓人看得到、改得了，系統才能持續使用。
- 最終責任在人：上野強調，就算導入了 AI，最後為結果負責的還是人，「是 AI 做的」不能當作出錯的理由。哪些情況可以讓 AI 直接處理、哪些一定要人工確認，要事先劃清楚。
- 分段放手：相較於報導中的 100%，小嶋自己的目標是 70%、80%、90% 逐步提高；廠商也建議從有歷史實績的老客戶開始。先在最有把握的範圍內跑順，再逐步擴大。
其他企業可以怎麼開始
上野在報導中提到日本職場的現況：長期雇用不再是前提，常常業務人員剛把接單規矩學會就離職，經驗很難傳下去。
這不只是日本的問題。許多批發商和中小企業的接單現場都類似：客戶用 FAX、Email、電話或通訊軟體下單，寫的是自己習慣的簡稱，全公司看得懂的只有一兩位資深同仁。透過 LINE、WhatsApp、WeChat 等通訊軟體下的單更難處理：群組裡的文字訊息、手機拍的紙本截圖、語音留言，格式比 FAX 更不固定。
可以分兩個階段開始。
下週就能做的 5 件事
- 算清楚一週的訂單底數：按管道（FAX、Email、電話、通訊軟體、電商平台）統計一週的訂單張數、每張平均處理時間、由誰處理、事後被修正過幾次。沒有這張基準表，之後導入任何工具都算不出省了多少時間。
- 從過去的銷貨紀錄拉一張對照表：Matsuya 的做法是查歷史交易明細。你可以從 ERP 匯出近 3 到 6 個月的銷貨單，比對客戶傳來的原始訂單，整理成「客戶名稱、客戶的寫法、公司正式品號」三欄的試算表。這張表現在就能用來交接給新人，之後也能當作 AI 參照的資料。
- 把老手的判斷規則寫下來：問清楚資深同仁，某客戶寫「老樣子」是指哪幾個品項？「一箱」是幾包？備註寫「急用」交期要怎麼算？哪家客戶的某個簡稱其實是另一個規格？Matsuya 把「寫『最短』就是接單日加 3 天」寫成規則，就是這類做法。寫不出來的規則，AI 也學不會。
- 挑 30 到 50 張真實訂單當考卷：請資深同仁在歷史訂單上標註正確答案，放進手寫 FAX、通訊軟體截圖、品項寫在備註欄等常見難題。考卷要分成兩份：一份用來測試和調整工具，另一份不給任何人調整用，留到最後驗收，避免同一批題目既用來調整、又用來算成績。
- 確認測試工具的資料安全：拿真實訂單測試 AI 工具之前，先遮蔽客戶個資，並使用有企業資料保護條款（不將資料用於模型訓練）的商務帳號，不要用員工的個人免費帳號上傳公司訂單。可以參考我們之前的文章〈員工還在用個人帳號使用 AI？〉。
3 個月以上
- 設計一個嚴謹的 PoC：測試樣本要分層（老客戶與新客戶、印刷字與手寫字、通訊軟體的文字與截圖）。指標要拆開算：字有沒有讀對、品號有沒有配對正確、格式能不能匯入、業務規則有沒有照做。事先定好「連續幾週準確率達到多少，才減少人工確認」的條件。
- 先輸出匯入檔，再談直接寫進 ERP：第一階段先讓 AI 產出符合你們 ERP 或自建系統匯入格式的 CSV 或 Excel 檔，由人確認後再匯入。錯誤率穩定之後，再談 API 自動寫入。Matsuya 的 PoC 也停在這一步，而小嶋預期真正的問題會在寫入核心系統時出現。
- 處理通訊軟體訂單的現實：客戶在私人群組裡傳訊下單，技術和權限上都很難穩定地自動擷取。可行的做法是逐步引導常態客戶改用公司的官方商業帳號（例如 LINE 官方帳號、WhatsApp Business）或固定格式的表單；不願改變習慣的客戶，先由同仁把訊息轉存到指定資料夾或表單，再交給 AI 處理。
- 讓對照表跟著更新，也記錄隱性成本：公司會上新品，客戶也會換寫法。人工確認時修正了 AI 的錯誤，要有機制把修正回寫到對照表與規則裡，否則上線半年後準確度會慢慢下降。評估效益時，除了打單工時，也記錄打錯單、送錯貨、退換貨重送與客訴賠償的次數和成本；對批發商來說，這些成本常常比打單工時更高。
參考資料
- 平行男、溝田萌里（Scribe LLC，合同会社スクライブ），〈老字號食品批發商用生成式 AI 自動化「需要人判斷」的接單業務：幕後實錄〉（老舗の食品卸企業が生成AIで「人の判断」が必要な受注業務を自動化できた舞台裏），ITmedia Keyman's Net（キーマンズネット），2025-05-08 10:49（日本時間）。https://kn.itmedia.co.jp/kn/articles/2505/01/news012.html 文末註明內容改寫自內田洋行 2025 年 3 月 11 日至 23 日舉辦的「食品 IT 展 2025 線上」（食品ITフェア2025 オンライン）講座。
- 內田洋行，〈挑戰接單業務自動化！年省 3,000 小時以上，用生成式 AI 連人的判斷一起朝完全自動化邁進〉（【食品ITフェア2025 オンライン】受注業務の自動化に挑戦！年間3,000時間以上の削減に成功 生成AIを活用し人の判断含め完全自動化を目指す），IT 報告，2025-04-21。https://www.uchida.co.jp/system/report/20250016.html
- Usac System（ユーザックシステム），〈因應人手不足與招募困難，本公司與 Matsuya 開始以接單 AI agent 朝接單業務完全自動化的驗證實驗〉（人手不足や採用難を見据え、当社とマツヤが『受注AIエージェント』による受注業務の完全自動化を目指す実証実験を開始），新聞稿，2024-11-29。https://www.usknet.com/news/34559/
- Usac System，〈本公司與 Matsuya 公開接單 AI agent 完全自動化驗證實驗結果〉（当社とマツヤ、『受注AIエージェント』による受注業務の完全自動化を目指す実証実験結果を公開），新聞稿，2025-02-13。https://www.usknet.com/news/35336/
- Usac System，導入案例〈Matsuya：一個月開發 100 支以上腳本，成功削減 3,276 小時！〉（株式会社マツヤ 様：1カ月に100以上のスクリプトを開発し、3,276時間の削減に成功！），頁面未標示日期（內文提到「2022 年 3 月現在」）。https://www.usknet.com/jirei/matsuya/
- Usac System，〈運用生成式 AI agent 的接單 AI agent PoC 服務〉（生成AIエージェントを活用した「受注AIエージェント」のPoCサービスを提供），2024-07-31。https://www.usknet.com/aipoc_usk-weel
- AWS 日本官方部落格，〈Usac System：以 Amazon Bedrock 自動化非定型接單業務，開發 Knowfa 接單 AI agent〉（ユーザックシステム株式会社様：非定型の受注業務の自動化にAmazon Bedrockを活用し「Knowfa 受注AIエージェント」を開発），2025-07-02。https://aws.amazon.com/jp/blogs/news/genai-case-study-usacsystem/
- Usac System，〈Knowfa 接單 AI agent V1 於 4 月 9 日正式推出〉（「Knowfa 受注AIエージェント V1」を4月9日に正式リリース），新聞稿，2026-04-10。https://www.usknet.com/news/38345/