> 本場以日文演講。 原文來自使用者提供之日文 SRT,譯文與日文原文逐段 1:1 對齊;結尾的轉錄幻覺段已剔除。
有請 Rakuten AI 的 General Manager,梶祐輔(Yusuke Kaji)上台。
兩條軸線:自律化 × 賦能
大家好,我是 Rakuten Group 的 General Manager 梶(加治)。今天的題目寫的是 Rakuten 的「AI-nization」——在 Anthropic 日復一日發布各種模型、各種 agent 的情況下,要怎麼從這些技術中創造出商業價值,我想以 Rakuten 的案例來跟大家分享。
今天我的分享,主要會以這兩條軸線為基礎,一路講下去。
這張圖是什麼意思呢?第一條是自律化,上方縱向的軸。上面寫著 autonomy——就像今天早上的場次也提到的,它表示模型或 agent 能多自律地、自主地長時間運作。右邊的橫軸,寫的是「擴及企業業務整體」,或者說賦能(empowerment)——它表示的不只是 coding、不只是軟體工程,而是 Claude 能用在多大範圍的企業實際業務上。除了工程以外,財務、會計、營業、行銷、產品、營運等等,透過把 Claude 用到各式各樣的業務上,盡可能從 Claude、從這樣的 AI 創造出最多的商業價值——這就是這張圖的出發點。
今天,在用這兩條軸線評估從 AI 獲得的價值時,我想分享四個具體行動——我們認為像我們這樣的大型企業組織做得到的事。
第一個是「在兩條軸線上都做評估」。這是什麼意思呢?其一,當新的模型或 agent 出現時,我們會評估:和之前相比,我們實際上能多完成多少既有的任務。同時,理所當然地,假設有一個困難的任務,讓 Claude 的 agent 花一萬日圓完成,不如花一百日圓完成——當然是後者好。就這個意義上,完成一個任務要花多少成本,是我們的另一條評估軸。
第二個,我寫的是「看清真正的天花板」。這是什麼意思呢?Anthropic 的模型——今天早上 Claude Fable 5也發布了——究竟是模型決定了極限,還是這裡寫的 workflow,也就是組織的型態、組織的設計決定了極限?關於這一點我想稍微談談。
第三個是:當然,如果今天我用基於 Claude 的 managed agent 執行了什麼並完成了,那固然開心;但重點不是「今天這一天做不做得到」,而是今天做不到的事明天能做到、後天變得更好——這裡日文翻成「複利」,也就是 compounding 的影響力要怎麼做出來,這是我要講的第三點。
最後,關於現在的 Anthropic——這其實也包含了對 Anthropic 的請求——當這三件事都完成之後,我們認為要獲得更多利益、ROI 的回報或商業價值,瓶頸在哪裡,我想談談這一點。
把剛才這四個重點歸納成一句話,我想就是:「光靠智慧,解決不了工作。」順帶一提,我這次簡報的日文翻譯可能稍微有點不自然——不是我翻的,是 Claude 翻的,還請大家多多包涵。回到正題,這是什麼意思呢?例如新模型出現時去試用它固然重要,但並不是只要新模型出現,我們日常面對的業務課題就能迎刃而解——這就是論點所在。
第一,如剛才所說,我們認為 agent 的價值——agent 能產出的價值——是沿著兩條軸線擴展的。
第二,特別是「能在那條軸線上擴展到什麼程度」,固然取決於 agent 本身的能力,但也很大程度受制於我們公司是怎麼被設計的、是怎麼運作的。
最後,透過這些獲得的學習,要如何在我們睡覺的時候——正如今天 managed agents 那段提到的「dreaming」——運用 Anthropic 的技術日復一日地改善,這是我最後想談的。
Rakuten SWE Bench:用自家實務來評估
首先,從這裡開始講得更具體一點。
以 Rakuten 來說,我們在公司內部有一套「Rakuten SWE Bench」——SWE 是 software engineering 的縮寫——這樣的基準測試。大家都知道,各種 AI 模型都有公開基準,常會聽到「這個軟體開發任務完成了百分之幾十」「下一個模型又更會做了一點」這樣的說法。
那當然有它的用處,但在企業實務上,那些公開基準是否真的重現了我們每天面對的任務?我認為多少是有些疑問的。
就這個意義上,我們公司用這裡寫的「Rakuten SWE Bench」,以自家實際程式碼 repository 裡產生的 pull request,來看 agent 在沒有人類協助下能解決多少,把它作為評估軸之一。藉此,在工程面上,我們評估新模型、新 harness 機制的能力,究竟能多大程度活用在自家實際業務課題的解決上。
第二個,寫的是「超越工程」。如剛才所說,會計、財務、營業、行銷、產品等等,各式各樣的任務,現在在 Rakuten 內部已經開始用 Claude 來解決了。就這個意義上,不只擁有軟體開發的評測、基準,對其他任務也要有合適的評估軸,這變得很重要。
左邊寫的是稍微舊一點的數字:把先前的 Opus 4.6和 4.7 相比,在公司內部這套 SWE Bench 上,實測到生產(production)環境 PR 的解決量相對是 3 倍,所以馬上就做出了「立刻遷移到 Opus 4.7 」的決策。
最後寫的是「每完成一個任務的成本」。如剛才稍微提過的,把「新模型能解決一百分之幾的任務」這個數字,跟「為了解決那一百分之幾的任務,每個任務花了 100 日圓還是 80 日圓」並列
——不是按 token、而是按任務來計量——
這在 Rakuten 已是每天的標準作業。到這裡為止,就是我們為了正確了解「智慧、新模型、新 agent 在現實假設下究竟能解決我們業務到什麼程度」所做的基底工作。
記憶與 dreaming:以複利改善的 agent
接下來,假設透過現在的評測基準,大致知道了能做到哪裡,下一個課題就成了下一個關鍵。
這裡寫的,主要是在 Anthropic 的 Claude Managed Agents 這個受管 agent 服務之下驗證的結果。今天也有我們團隊的工程師到場,他們用 managed agents 開發各種產品、解決方案。當初,在使用記憶或 dreaming 之前的階段,最初期出現了大量的 critical error。把這個記憶作為與單一 session 的 agent 分開的另一個程序來使用,試行驗證「明天再做同樣的任務時,錯誤能少多少」,結果——這個數字也許好得有點過頭——critical error 削減了 97%。
當然,不可能每天都削減 97%;
但假設哪怕每天改善 1%,從初期的 agent 算起,一年下來大約會成長到 360〜370% 左右。
這種日常的努力,不是由我們手動去做,而是作為流程、作為機制,讓 agent 每天自我改善——擁有這樣的機制,對於最大化商業價值非常重要。
把我所說的商業價值再具體化一點:講到 ROI,一邊是回報(return),而 ROI 的另一個構成單位是投資(investment)、成本——投入多少。大家都知道,大量使用 Claude 成本會變高;但藉由使用 managed agents 的記憶,完成一個任務所需的 token 更少、嘗試與迭代更少,就像這裡寫的,成本與延遲比起初次部署 agent 時削減了 30% 以上。這裡的重點是:不只是「絕對精度上完成了百分之幾的任務」,而是——假設初始值是 60%——「它每天能改善多少」,把這件事作為流程持續持有,我認為非常重要。
拓展橫軸:非工程師的進階使用者(「伽利略」)
下一個主題:剛才講的內容,就兩條軸線而言,偏向「agent 能多自律地運作」的縱軸。接下來是橫軸——從最初的 Claude 開始,到最近 Cowork 或 managed agents 的出現,要怎麼讓工程師以外的人的業務也能自律地改善、怎麼把橫軸拓展開來——我想把我們的學習分享給大家。
幾個月前,我們和 Anthropic 的各位一起,取了「伽利略(Galileo)」這個名字,做了一點宣傳、或者說行銷。這是什麼意思呢?在過去,例如要做一個儀表板、要看產品狀態,得去抓各種日誌和指標,做成儀表板、建 ETL 管線之類的——通常是工程職與非工程職的人協力,共同打造出一條業務工作流程,這是普遍的做法。但最近,藉由使用這裡寫的 managed agents 或 Claude 的 API,非工程師的進階使用者——我說「伽利略」的意思是,就像昔日的伽利略一樣,一個人就能涵蓋各種職種——這成為可能,我認為這是組織價值上的重大變革。
例如,一位產品經理在營運自己管理的產品時,不必每次都拜託工程團隊,而是能用公有雲上的指標或日誌,自己建構管線;又或者像午餐前那場提到的,用 managed agents,把可觀測性、或者偵測異常(anomaly detection)的 agent,用自然語言問「有沒有問題」「這個產品的 KPI 現在怎麼樣?」就能搞定——我認為這是非常大的變革。
這當然有 Claude 的功勞,但不只如此。那工程的工作會變成怎樣呢?不是去逐一應付每個儀表板的客製需求,而是利用可重用的——常被稱作「agent skill」的——可重用的模組化 skill,工程團隊得以打造出支撐那些進階使用者的基底、地基。把焦點放在打造這些東西上,不再把一個個請求當作單純的一次性請求來消化,而是——和剛才的記憶類似的概念——不斷累積 skill,讓整個企業成為更強韌、能更快做更多事的組織。我們以此為目標,而實際上現在就是這樣運轉的,所以我覺得這裡真的完成了變革。
Ambient / overnight agent
最後一個。前面講的兩點,比較是以人為主體——「我要怎麼用 Claude 把我手上的產品營運得更好、更快」的視角。第三個,這裡的 reliability・security,日文寫作「信賴性・安全性」——這是所謂「在我們夜裡睡覺的時候」,就像 Angela 早上講的那種框架:當發生事故(incident)、發生不正常的問題時,即使我們在睡覺,也能持續監視、持續運作,順利的話連修復都一併做掉。我們把這稱作「ambient agent」或「overnight agent」。把這樣的 agent 不斷套用到我們的 CI/CD 流程、套用到生產環境的應用程式上,我認為是今後最重要的事,這也是我們團隊、我們公司投入大量心力聚焦的地方。
把這三點歸納起來,就是這裡寫的「賦能的實踐」。Rakuten Group 從一開始——在 AI 出現之前——就把「持續賦能」作為公司的願景與使命。透過這些,把 AI 的民主化,擴展到懂 coding 的開發者、軟體工程師以外——也就是剛才說的橫軸——讓任何人、讓現在在我們公司工作的每一個人,都能最大限度地運用 AI 的力量、被賦能,我認為這非常重要。
兩個教訓:決定極限的是工作流程的設計
最後想談的是:假設我今天還沒開始,要以現在的知識、經驗、失敗為基礎,再從頭開始一次的話,我會注意哪些地方——剛才跳過了一段——以「兩個教訓」作為收尾。
第一個,今天我反覆說過:以我們的解讀、一路做下來的學習,決定「模型能完成多少任務」的,主要是工作流程的設計,而不是模型的智慧(Model Intelligence)——這是我們的洞見。
就像剛才說的,假設該解的課題有 100 個,只解得了 80 個,那剩下 20 個為什麼解不了?抽絲剝繭下去,多數殘留的原因不是模型智慧不夠,而是組織結構上、組織設計上存在著某種阻擋、某種制約——絕大多數是這樣的情況。這並不是說我們的組織有什麼問題;這恐怕是任何公司都常見的事。要怎麼改善它、提高任務完成率、更好地用 AI 萃取商業價值、把 agent 的智慧翻譯成商業價值——我想講得更具體一點。
第一個,日文不太好懂,寫的是部署狀態「Across Public Cloud」——指的是讓 Claude 的 agent 能了解「透過各家公有雲供應商,基礎設施現在是什麼狀態」。也許有人會說這是理所當然,但如果基礎設施主要是用公有雲的管理主控台來管理的,那麼當然,從 Claude 的 CLI 去存取,不會那麼直截了當。下點工夫是做得到的,但大概需要再多兩道工夫;而如果基礎設施是用程式碼管理(Infrastructure as Code)的,那就沒有那些障壁,Claude 或新模型就能順暢地處理那個任務。
接下來,寫的是「公司內部的規則・政策」。當然,這不是說要以 Claude 為優先去改規則;而是當公司內部的規則・政策、或公司內部的組織設計存在時,要怎麼把它——我們稱之為 AI-nization——以 AI、以 AI agent 為前提的時候,規則・政策應該更新成什麼樣子,由整個組織一起討論並改善,我認為這非常重要。例如 Anthropic 的情況,就第一方而言,伺服器在美國;在這樣的情況下,在我們的工作流程中越是重要的東西,現實上越不可能天真地、什麼都不想地全部放上 Claude 的伺服器。要制定什麼樣的規則・政策,在不增加太多風險的前提下,讓真正重要的工作流程、任務交給 Claude 解決——思考這件事非常重要。
最後第三個,寫的是「context 的所在」。和剛才講的一樣,對多數公司來說,最重要的 context——應該餵給模型的 context——恐怕大多是不能放上公開網路的。在這樣的制約下,context 既不能全部上傳,完全不上傳又解決不了問題,所以要如何以合適的形式把 context 交付出去。今天的演講裡也提到各種方案,例如 self-hosted sandbox,還有 MCP、tunneling——有各式各樣的解法,要如何運用這些,把 context 妥善地交給 AI、交給 agent,會變得非常重要。我認為那會成為決定模型極限的因素。反過來說,我們透過改善這些事——不只是去用新模型,而是把周邊的環境整備好——打造讓模型工作得舒服、讓 agent 能順利工作的環境,我們非常重視並持續在做。
對 Anthropic 的請求:會自省的長跑型 agent
這部分比較與 Anthropic、特別是今天的模型發布有關。最近幾次 Opus 的發布,日文寫作「持續奔跑的 agent」——long-running 的 agent,例如能連續工作 5 小時、8 小時、一天、兩天的 agent——我的解讀是,模型的預訓練或後訓練(post-training)就是朝著支撐這種 agent 去做的。那裡的問題在於:它會非常有韌性地、不斷地——不是失敗——而是直到成功、直到抵達目標為止一次又一次地迭代。這當然是好事;但另一方面,「咦,我到目前為止走的這條路——我,不對,是 agent 做過的這些事——真的是對的嗎?」讓模型自身、agent 自身回頭反省這件事,過去是有點落差(gap)存在的。
就這個意義上,今天發布的 Claude Fable 5,我們今天早上稍微試用了一下,或者說做了一點 early testing。以結果來說,這種自省的能力——例如做完某件事後做 self-verification、自己確認、回頭檢查一次「有沒有確實做好」——這樣的行為變得相當常見了。利用這樣的東西,就不再是「花了大把成本、跑了兩天、燒了 100、200 美元結果失敗了」的故事,而是在第二趟、第三趟時,稍微檢視自己的做法、回到起點重來一次、確認有沒有做對——把這樣的流程夾進去。即使任務完成率老實說沒什麼變化,抵達目標前的成本、token 效率卻大幅改善了。作為使用者端,我們也想好好吸收這樣的變化:如果現在 100 個任務能完成 80 個,那要怎麼用更省 token 的方式完成——今後我們會持續關注。
總結:作為企業資產、以複利累積的機制
最後用三分鐘總結今天講的內容。這裡寫了「數字」,我認為最重要的是最左邊的「critical error 的削減」:透過使用 Claude managed agents 所用的那種 agent 記憶,或在夜間執行的 dreaming 這類功能,最初部署的 agent,和它六個月後、一年後的樣子相比改善了多少——我認為這正在成為衡量一家公司能力(capability)的重要指標之一。就這個意義上,我們 Rakuten 在持續部署之後,也會一邊用記憶、一邊用 managed agents 的可觀測性這類功能,去看 agent 每天變好了多少;如果 100 個裡能做到 97 個,那剩下 3 個不行的原因是什麼——逐筆看紀錄、逐一解決——我認為持續做這件事很重要。如此一來,中間的「成本・延遲的削減」自然就會隨之而來。
最後的任務完成率——模型本身會不斷進步,這今後 Anthropic 會做下去;而我們使用者端、企業端把這套機制整備好,新模型一來就能立刻評估、納入每天改善的流程——「新的來了就自動轉起來」這樣的型態就能成立。
這麼做的結果能得到什麼呢?以我們為例,我們自己也有自家團隊持有的產品:過去是每季、三個月一次主要版本發布,現在速度大幅提升,大約兩週就能做到。特別是這裡寫的「非工程師員工」——產品經理等承擔那些業務時,不必每次都和工程團隊協調資源,就能不斷朝下一個任務持續改善。
利用這些東西來賦能人與社會,是我們公司的使命。當我們思考「要怎麼使用 AI agent」這個問題時,最上層、最高層次來說:透過使用 AI agent,在不推升前面說的治理、安全、合規這些企業風險、維持可妥善管理的狀態下,把創新所需的時間與成本最小化——這是我們今後也想持續做的。如此一來,例如有新點子時,不必先召集人、籌錢、湊運算資源,而是馬上先做 wireframe、做原型,並在合適的護欄、管線之下持續送進生產環境,就能找到下一個創新、下一個 product-market fit。
生產固然重要,但支撐它的機制——這裡寫作「實現的關鍵機制」:第一,反映自家公司真實課題的、自有的模型評估框架。第二,把包含組織設計在內的工作流程從頭重新定義。最後,作為 agent 的記憶,不讓今天做到的事只停在今天,而是作為企業資產,以複利、以 compounding 的方式不斷堆疊累積——擁有這樣的機制非常重要。我們也還在學習的路上,有些已經在做了,今後也想每天持續改善;如果大家有什麼好點子,等一下我也會在會場,非常歡迎來聊聊。
好的,雖然講得有點趕,今天我的簡報就到此結束。謝謝大家。