> 本場以日文演講。 原文來自使用者提供之日文 SRT,譯文與日文原文逐段 1:1 對齊;結尾的轉錄幻覺段已剔除。

有請みずほ金融集團執行役員、數位戰略部長兼最高 AI 責任者藤井達人,以及みずほ Lab Lead 染谷謙太郎上台。

藤井達人:不是「活用 AI」,而是以 AI 為前提重新設計業務流程

好的,大家好。我是みずほ金融集團的藤井,請多指教。今天,我想用 30 分鐘的時間,介紹みずほ如何打造以 AI 為前提的組織與開發機制。主題不是單純的 AI 應用案例,而是業務、組織、開發基盤要怎麼改變。前半由我說明全公司變革的思路,以及企業整體的全貌;後半,則由敝公司的染谷介紹自製開發(內製開發)現場正在發生什麼。

簡單自我介紹一下。我其實是中途採用(社會招聘)進入みずほ的,三年前加入。我職涯大概有一半在科技、IT。出社會以來一直在「金融 × IT」這個領域,長期參與創新與孵化相關的工作。以這樣的經驗來看,AI、生成式 AI 的浪潮真的是異質的、極其特別的。這樣的變化,我們這個既是大企業、又是金融機構的みずほ如何看待、打算如何投入——前半我的部分就想談這些。

這是我最想傳達的訊息:不是「活用 AI」,而是重新設計成「以 AI 為前提」的業務流程。

把 AI 加到既有業務上,當然不是我們的目標。而是以「AI 在場」為前提,重組業務流程本身——我認為這才是關鍵。關鍵字是「端到端(end-to-end)」,我們在公司內經常這樣講。

如這張圖所示,左邊寫著「傳統型組織的流程」:

過去是以人的流程為中心,系統或工具是輔助。

下一個階段,AI 開始替代一部分人的作業,人用 AI 來提升效率——我們正開始進入這個世界。

再下一個、最右邊寫著 AI-native:這是 AI 驅動整個流程,人轉而負責設計、監督,或例外處理的應對。

也就是說,該改變的不是一個個作業,而是端到端的整體流程。AI 原生的設計思想,不是配合人去切分業務,而是以 AI 的能力為前提去最佳化。

我們認為這是非常具挑戰性的取組。這場 AI 轉型,丟給現場推不動、只靠總部也推不動;由技術部門主導推不動,全部交給現場又會失去整體統御——會陷入這樣的局面。

我們的做法,是左上寫的 CDTO——Chief Digital Transformation Officer 直屬的司令塔功能,結合各現場的推進領導者,一起推進,這算是我們的一個特色。以 CDTO 為首的全公司任務小組:決定優先順序、做 Go/No-Go 判斷、監測進度、進行協調。再加上,作為卓越中心(Center of Excellence)、由我掌管的數位戰略部,以及流程變革部門,橫向串聯地支援——是這樣的型態。盡量不讓經營層的決策與現場的實作斷裂,而是一體推進。

承接這樣的做法,實際上要怎麼推進——這是時間軸的話題。端到端、由 AI 作為主體驅動流程的世界,恐怕會到來。

從最右邊講起:以現在 AI 進化的速度——大家常說 Anthropic 的 trajectory 正出現指數型的變化——這樣想的話,5 到 10 年後,所謂 AGI、ASI 這種超級智慧還沒實現,反而才是不自然的吧。在那樣的未來實現之後,恐怕就像最右邊畫的,各種流程會由 AI、以 AI 為主軸自律地運轉。

在那個世界裡,人的業務會更偏向監視 AI、稽核 AI,或轉向更有創造性的工作。

不過不可能一步跳到第二階段,所以第一階段是把 AI 當工具用,先提升既有業務的生產力。總之先把一個一個 AI agent 紮實地實作起來。隨著時間推移,AI agent 的實作推進、橫向的串聯推進,就會開始驅動整個流程——我們是以這樣的大概念來推進的。

AIOA・WizBase・內製開發團隊・AI Agent Factory

下一節是:面對這樣的推進方式,我們みずほ打算怎麼打造企業級的 AI 模式。

第一個關鍵字,乍看不知道是什麼——是我們自創的詞:AIOA。粗略地說,就是 AI Oriented Architecture(AIOA),是 AI agent 開發的全公司規則,以及標準化、統御的基石。

第二個,WizBase。這是以 AWS 為基礎,支撐模型、agent、到資料連接的共通基盤。

第三個是公司內部開發團隊——抱歉這裡反白看不清楚——Scrum、PO、DEV、R&D 一體化,快速把業務需求做成形。

第四個是 AI Agent Factory。從 factory 這個詞應該能聯想到:我們必須大量地做出 AI agent,而這是為了能確實、持續、有效率地量產 AI agent 的加速機制。

也就是說,把規則、基盤、量產機制成套地定下來,作為一個框架開始運轉——這是我們的一個特色。不是單純做 app、做單個 agent,而是在打造「能安全、快速、反覆生產」的企業能力——這樣理解會比較貼切。其結果是,公司內部已經有數十個、應該超過一百個 AI agent 在運作。這裡列的是其中與生產力提升相關的一部分應用,例如能使用公司內部資訊的 AI 聊天、會議記錄 app 之類的當然也有。

現在這些應用、AI agent 是以人為前提的 app,所以有 UI/UX;

而下一個階段,是讓這些東西能在幕後被 agent 使用。

透過這樣的內製開發,我們也在學習要怎麼把 AI 做進去、怎麼施加統御。許多這類 app 和 agent 都是用 Claude Code 做的——幕後正是 Claude 大顯身手。

我的前半部分到此告一段落。接下來,我們實際在使用 Claude Code 等開發基盤——用這些工具,內製開發部隊實際上是怎麼運作的、速度有了什麼變化——就請染谷來談。染谷さん,拜託了。

染谷謙太郎:Claude Code 改變的內製開發速度與型態

大家好。從這裡開始,由我來講「Claude Code 改變的內製開發速度與型態」。在我們團隊推進開發與審查的過程中,為了把流程自動化、確保資安,我們做了這些活動:spec-driven、test-driven、deploy-driven、cloud-driven。除此之外,還有可觀測性、資安,當然還有做產品開發用的應用;不只這些,還有剛才藤井介紹的、被稱為 Agent Factory 的平台工程,以及 Claude Code、AI coding 工具這類工具的整備。我們團隊不只做產品開發,也負責整備支撐它的開發基盤本身。最下面的 WizBase,剛才介紹過了,是みずほ自有的 AI 基盤,作為今天的關鍵字,後面還會出現幾次。

在那之前,先講一下我們團隊的規模感。內製開發團隊 40 人,全員都配了 Claude Code;剛才介紹的各種產品,都是活用 Claude Code 開發的。一個產品由 1 到 5 人的工程團隊負責,目前 25 個產品平行開發中——這也體現了 AI coding 帶來的壓倒性生產力。

我們把資安稽核日誌、模型都集約在 Amazon Bedrock 上,兼顧敏捷性與治理;像 Opus、Sonnet 這樣的新模型,只要在 Bedrock 上提供,就能立刻提供給團隊。以金融機構來說,「當天就能用上」恐怕比大家想像的快。今天剛出的 Fable 5,我也很好奇看了不少;不過那個我想還是先做各種確認之後,再推進使用。

多層疊加 skill:注入企業 context

呃,順序是這個對吧。從這裡開始介紹我們的工夫。

果然,把 Claude Code 直接發下去,在整個產品開發現場是沒辦法被好好用起來的。關鍵還是:みずほ這個企業的 context 要怎麼注入。我們的做法——大家可能也在做——是把 skill 多層地疊起來。這是某個專案的例子。舉個例:疊上 Anthropic 官方的前端設計 skill,讓 UI、體驗、品質保持一致;剛才介紹的 AI 共通基盤 WizBase 是企業級 AWS 的型態,所以疊上 AWS 的 skill;再往上還有更固有的 context,把固有 context 疊上去,agent 就處於容易在我們環境裡運作的狀態。右邊就是剛才說明的這些 skill。

這個 demo 的資料也是用 Claude Code 做的,後面會再介紹。重點是:不是單純讓 agent 寫程式,而是讓它先讀入固有的 context 再推進開發。畫面上顯示的是在 Claude Code 上能確認的 skill:不只是一般的開發 skill,而是加入了立足於みずほ context 的 skill,讓它更容易在我們的現場運作。這個 demo 裡,下指示要它做一個範例 app,就會從多個觀點進行確認:設計對不對、資安上——以我們的資安規則來說——有沒有問題、是不是做成可測試的形態,這些觀點都由 skill 來補足。最後,對生成的 app 執行測試,確認順利通過。這裡展示的是:讀入固有 context、按規則做實作確認、到啟動測試,都在 Claude Code 上完成——最終 Claude Code 不只是個寫程式的 agent,而是立足於我們的 context、在現場能用的存在。

這裡補充一下幕後。剛才出現過幾次的 WizBase,是公司內部的 AWS 企業基盤;金融特有的治理、要件、開發時必須遵守的前提非常多。

我們把這些作為 context 注入 Claude Code,讓它在生成與審查中能自然地參照。我們用 Claude Code 外掛(plugin)來實現,並發布給工程師。今後不只這樣的 harness,我們近期也在準備結合名為 CDK Nag 的靜態護欄;把這樣的機制不只用在個別專案、產品,而是共通地整備起來,也是我們內製開發團隊的職責。

開發流程:用 slash command 從設計到 PR

接下來,用這套機制實際怎麼轉開發流程,詳細介紹一個例子。如這裡所示,把規則與前提交給 agent 側持有,再組進各種開發流程。在那個開發流程中怎麼使用 Claude Code,這裡介紹一下。用 slash command——/plan、/design——進行設計方針的討論與對練,自動生成設計書;用 /tdd 先寫測試,以最小實作讓測試通過。之後——重複剛才說的——用資安、效能、WizBase 這些固有 context,對程式碼與架構取得第二意見(second opinion),再疊上一輪人工審查。最後是　/pr　——這頁資料來不及改、還寫著 second opinion——把 pull request 的說明整理成能送審的形態。

到這裡介紹了具體的開發流程。要讓這樣的 agent 在現場穩定地使用,我認為需要支撐它的思考方式。

我們內製開發團隊把它整理成兩根支柱:注入領域 context 的 harness——注入我們的領域 context 的 harness——以及統御模型使用的共通基盤。

LLM 一般的護欄有照顧不到的領域;就像前面一直說的,みずほ固有的 context——設計思想、治理、資安規則、開發規則這些——把這些 context 整備成文件、作為 harness 注入,讓它能沿著領域運作。再加上,模型使用集約在 Bedrock 上:像 Opus、Sonnet 都能立即提供,治理、模型管理也一併能在共通基盤側統御。

到這裡都以 Claude Code 為中心,但這套思路不只適用於 Claude Code 的活用,也適用於我們做的 agent 型產品——如剛才所說,現場有各業務的應用程式,裡面有高度的業務領域知識。

能不能把它以 context、工具、harness 的形式外部化——我們已開始實驗性的驗證。這些也是因為模型的推理能力與 context window 變大了,才實驗性地可行;能不能持續做出對變化有韌性的產品,我們現在正在實驗性驗證。

接著,要在這之上更穩定地運作,我們打算整備評估、驗證、context 設計、工具設計這些持續性的、可謂 LLMOps 的機制。

把不足的知識落成 context、把不足的操作整備成工具、評估它、再送回驗證。建立這樣的回饋迴圈,是讓 Claude Code 和 agent 產品穩定運作的重要因素,我們也正在推進這套機制的整備。

當各種東西都能穩定地實作出來,大家看生產力的方式應該也在改變。不再像過去那樣——我自己也當了 15 年工程師——只看程式碼量、實作速度,而是例如「不確定性減少了多少」「對產品價值貢獻了多少」這樣的觀點會變得重要。資安、code review 這類領域,作業時間已大幅縮短;但真正該看的,不是單純快了幾倍,而是「做了幾次原型、和使用者對話、轉了幾輪驗證」——那種對產品價值的貢獻才是關鍵。這頁是回顧,請大家過目;最後交回給藤井收尾。

藤井達人:兩個實例 — Mizuho LLM 與 RM Studio

那麼,由我來講第二部分。想介紹兩個實例。第一個是 Mizuho LLM 的開發——這也是上上個月發表過的內容。我們以 Mizuho LLM 為名,在做自己的 LLM——說是做,其實是以 open-weight 模型為基礎的 LLM,並不是真的從零開始做,但我們也在做這樣的東西,實際讓它學習、做出來。

思考在金融機構的實務上活用這項 AI 技術時,當然,Claude 或其他超大規模雲端商出的模型都非常聰明;但就行為而言,老實說總有「還差一步」的地方。我認為已經相當聰明了。但考慮要處理非常專門的業務時,還是希望有一個「懂」みずほ的知見、金融的知見、知識、指引、各種法令的思考方式,以及貫穿其中的金融所需的思維與姿態的 LLM——安心感會不一樣。正因如此,把みずほ持有的各種資訊、資料,以及至今累積的 know-how 等等形式知化,讓這樣的模型去學習,做出能有更專門行為的 LLM——我們也在做這件事。

目標有三個。第一是確保資料的機密性;第二是擔保金融監理、法令的對應;第三是把這些用到專門業務上,連結到競爭力。現在還非常早期,學習的第一階段差不多要結束、正要進入實際 PoC 的階段;但目前在特定領域,已經出現非常好的分數。不過,光靠這個當然無法完成我們的 AI 轉型,所以會是與 Claude 等 LLM、大型 LLM 的組合來做——這是第一個。

再介紹一個。這是叫 RM Studio 的 app——幕後跑的是 agent,所以我刻意叫它 agent。

RM 在我們這裡指的是個人或法人的業務(營業人員)。RM Studio 定位為支撐法人營業活動的營業支援 AI agent。其他公司應該也一樣:營業人員其實很難 100% 面對客戶。要蒐集各種資訊、分析它,去客戶那裡提案之前的作業非常多;而且年資不同,手上的「抽屜」多寡也完全不同。過去年輕的 RM 多半是問前輩學著做;把那些 know-how、活動盡量平準化,或者用 AI 賦能年輕的 RM——以此為目的的 AI agent、應用程式。效果上,目標是讓營業活動的生產力提升兩倍以上。已在分行大規模實施 PoC,各處都收到相當正面的回饋。收到回饋、不斷改善的循環,正是用 coding agent 在轉的。

Big Rocks 與通往 Human on the Loop 的路線圖

最後,朝向 AI 原生的變革——把這些應用一個個做出來,重複地說,這本身不是目的;最終,如我在第一部分所說,必須讓全公司成為 AI 原生的組織、流程。把這個階段性路線圖講得更細一點:最初的這兩年,總之是看準必要的 AI agent、紮實地實作。這時,下面有個詞叫 Big Rocks。流程非常多,盲目地東摸西摸,終究不會順利;所以以客戶為起點思考流程時,確實看準價值高的流程,把它當作「通往想去的路上的障礙」移除。移除各種障壁、流線化(streamline)、提升對客戶的價值。挑出幾個這樣的東西、看準它、集中去做——我們是這樣的方法。透過這些,逐漸從 Human in the Loop 變成 Human on the Loop,最終走向 AI 原生的設計——是這樣的路徑。

今天談了我們正要推進的 AI 轉型旅程的樣貌與思路,以及實際為它賦能的 AI agent、coding agent,還有像 Claude 這樣的 LLM 是如何派上用場的。我們的取組還非常早期;今天也有各式各樣的場次,我們也在學習。希望透過這樣的機會向各位發信,我們自己也持續進化。我們的演講就到這裡。感謝各位的聆聽。