本篇文章是根據 LY Corp. 技術會議「Tech-Verse 2026」的場次「10x Speed With QA Agent Platform — How we scaled adoption from individual effort to organizational capability」的內容整理而成。
大家好。我們是 LY Corp. 產品 QA 組的上田洋平與福永誠。
在 Tech-Verse 2026 我們分享了 QA 組織如何運用 AI agent 的經驗。標題寫著「10x Speed」，但這次發表我們最想傳達的其實不是速度的部分。正如場次副標題所示「How we scaled adoption from individual effort to organizational capability」——我們想說的是，如何把 AI 的運用從個人的努力，擴展為整個組織的能力。
擅長 AI 的人會自行快速上手並不斷精進，真正困難的是，如何再往下一個階段推進。若 AI 的應用只侷限在少數擅長者身上，沒有擴散到整個組織，就無法真正提升整體能力。我們的組織也曾遇到相同問題。本文會說明我們如何讓 AI 成為「所有人都能自然而然使用」的工作方式，並分享過程中遇到的阻礙與因應方式。
我們的組織，以及 QA 這項工作
產品 QA 組是隸屬於 CTO Domain 的跨領域 QA 專業組織。我們在福岡與東京有據點，成員人數約 20 人。支援多個長期與短期專案，同時支撐 LY Corp 的服務品質。
談到 QA，很多人會聯想到「在發布前檢查缺陷的人」，但實際上的範圍更廣，從使用者感受到的服務品質到開發流程的品質，QA 涉及的是端到端的品質管理。
在 QA 的工作中，隨著專案推進，每天都會產生新的決策、工作產出，以及尚未文件化的默會知識。這些散落在各處的資訊，都需要持續追蹤並整合到測試相關產出中。要讓龐大的資訊 始終保持正確且最新，是一項相當繁重的工作。另一方面，正是這種「蒐集大量資訊並加以分析」的工作，與 AI 非常契合。
為了提升這類廣泛品質保證工作的效率，我們開發了 QA Agent Platform。以下簡稱 QAAP。
什麼是 QA Agent Platform
QAAP 是一個全組織共用的範本（template）儲存庫，搭配 OpenAI 的程式碼型 AI agent Codex（CLI / App）一起使用。它是已事先內建 QA 專業技能與安全 guardrail 的 Git 儲存庫，各成員可以把它 Fork 到自己的環境中，讓大家都能在相同的基礎環境上使用 AI agent。因為是在 GitHub Enterprise 上管理，內部任何人都能使用；在容易卡關的設定步驟，我們也以 shell script 自動完成設定。
使用流程很簡單：使用者向 Codex 提出任務請求後，系統會依據請求內容連接公司內多個 MCP（Model Context Protocol）伺服器收集資訊，再由內建 QA 專業知識的任務專用技能產出測試相關成果。在這個工作流程的每一個階段，都有多層防禦監控並封鎖可能造成安全風險的輸入。這個多層防禦會在後文進一步說明。
QAAP 在組織導入後，帶來了以下效果：
| 指標 | 結果 |
|---|---|
| QA 作業時間減少（不含測試執行） | 49.4％ |
| QA 產出數 | 1.54 倍 |
| 由 AI 代為產出的比例 | 68.1％ |
※ 以上皆為產品 QA 組針對 QA 工作（不含測試執行）所進行的內部測量值。
整體 QA 作業時間減少近一半，QA 產出數約為原本的 1.5 倍，且近七成的產出由 AI 代為完成。生產力提升後，人員得以專注於更需人力的工作，同時也有更多時間思考下一步的 AI 應用。
不過如同開頭所述，這些數字本身並不是本文的主題。接下來我要談的是我們在達成這些成果的過程中，所跨越的「兩道牆」。
阻礙組織採用 AI 的兩道牆
在推動 QA 組織整體採用 AI 的過程中，我們碰到過很多障礙。這次從中挑出兩個，這兩個應該也是許多組織都會遇到的共同議題。
牆 1：同時踩油門與剎車
組織一方面希望大家更多使用 AI 來加速工作流程，這是我們想強踩的「油門」。但在安全面上，又有必須嚴格控管的風險，這部分就像踩下「剎車」。兩者看似矛盾，卻必須在整個組織中同時兼顧。
牆 2：從少數人推廣到整個組織
具有早期採用者特質的人通常會主動積極地使用 AI，這本身很好。但那類人的做法與經驗常常會變成默會知識。為了避免誤解，補充一點：擅長的人通常並不是故意藏私，很多人其實相當樂於分享。但即使如此，其他人要複製相同做法，仍可能因各種因素而遇到困難。我相信很多組織也有相同的困擾。
面對這兩道牆，我們採取了「系統機制（Systems）」與「推動措施（Initiatives）」雙軌並進的策略。
用「系統機制（Systems）」破解牆 1
先來談牆 1，也就是油門與剎車的問題。
先說明一下：關於油門面—也就是我們為涵蓋各類 QA 工作所準備的預設技能（preset skills）—這一塊內容本身就足以寫成一整篇文章，這次先略過，期待日後再分享。與組織化 AI 應用直接相關且更具挑戰性的，其實是剎車這一側，也就是如何安全地控管風險。
風險控管不能只靠個人的注意力
在 AI 的生態中，每天都有不可忽視的新風險出現，例如機密資訊的處理、prompt injection、供應鏈攻擊等。理想上我們想持續踩油門以提升效率，但每當這類問題出現，就會被迫急踩剎車處理，投入大量時間與成本。
更棘手的是，從組織的角度要確實掌握每一位成員是否能正確應對這些風險、是否理解風險並正確使用工具，是非常不現實的。換句話說，若把所有防範措施都交給個人的注意力與判斷，組織就無法保證整體的安全性。
因此，我們把安全 guardrail 直接內建到 QAAP 的基礎設施中。運作方式是：各團隊或使用者 Fork QAAP，作為使用 AI agent 的基礎環境；由 upstream 原始儲存庫統一維護與更新 guardrail，使用者只要定期 sync，就能在組織層級獲得一致的防護機制。
多層防禦—一層若被突破，下一層來阻擋
接下來介紹 guardrail 的內容。基本概念是採用多層防禦（defense-in-depth）。我們在多個環節放置檢查點，即便有一層失效，下一層仍能攔截風險。
以 API key 或 token 等 secrets 的保護為例：若使用者將個人存取 token 以明文放在 .env 檔，設備或儲存庫若遭入侵就有外洩風險。因此 QAAP 規定 secrets 必須儲存在 1Password、Keychain 等加密管理工具，只有在必要時再安全地取出。
重要的是，這個方針不是仰賴使用者的自覺，而是以機制自動強制執行。對於 secrets，我們設計了三層的防護：
- 首先是「入口」。當使用者傳送 prompt 給 AI 時，系統會偵測 API key 或 token 常見的字串樣式，若偵測到，就會在資料送出到 AI 前直接阻擋。
- 接著是「執行時」。我們在 Codex 的執行政策中封鎖直接從 .env 或環境變數讀取 secrets 的行為。
- 最後是「出口」。假如入口檢查未能攔截，則會在建立 Pull Request 前進行靜態檢查（pre-PR），檢視生成的程式碼或技能是否依賴或參照以明文 儲存的機密資訊或檔案，從不同角度再次驗證。
不只封鎖，也要當場「教會」使用者
另一項巧思是，讓 guardrail 同時具備教育作用。
當 guardrail 被觸發時，系統會即時發出警示，並說明為何被阻擋、應該如何處理，並附上引導性文件或操作說明。實際上我們收到使用者回饋：「因為這個通知，我才理解風險的重要性以及應對方法。」這樣一方面自動阻擋風險，另一方面也同步提升使用者的理解度。
此外，我們只允許使用公司內部的安全 npm registry，並預設關閉會在安裝時自動執行腳本的行為。針對 AI agent 特有的操作風險，我們也禁止執行像 rm 這類不可復原的刪除指令，僅允許移到回收桶等可還原的操作。設計階段就防範「AI 誤刪所有資料，無法還原」這類最壞情況。
為什麼要做到這種程度？
前述的許多細節，對熟悉資安的人來說或許看似理所當然。但為何我們要把每個環節做得如此細緻？這是我在這一節最想強調的重點。
這些 guardrail 的共同目的，是為了因應下列「人們容易出錯的地方」：
- 依照指示精確執行任務
- 記住重要規範
- 閱讀並正確理解文件
- 不知道時坦白說「我不知道」
- 主動搜尋缺少的資訊
這些看似理所當然，但實際上很容易出錯。
更重要的是，這不是在講 AI，而是在講 人類。
就我（福永）個人而言，深有同感。常有「不說應該會懂吧」、「有寫了他會去讀吧」、「不懂應該會自己查或問吧」等期待，但事實往往並非如此，而這些本來以為理所當然的地方，一旦出錯就可能造成嚴重後果。
也有人會懷疑：「AI 在快速變化，現在做很多設計不是很快就過時嗎？」確實，AI 技術演進得很快，因此 QAAP 著眼的是「不會變的東西」：也就是人類在使用工具時普遍容易出錯的地方。
不要仰賴人的注意力，而是用機制去阻止錯誤。 這是 QAAP 一貫的設計理念。
總結牆 1：我們把自動剎車內建到標準配置，讓使用者可以專注踩油門。透過這樣的角色分工，解決了油門與剎車之間的矛盾。
不過僅有機制並不足以讓每個人都使用，剩下的挑戰是牆 2。
用「推動措施（Initiatives）」破解牆 2
接下來談的是如何把 AI 應用從少數人擴展到整個組織。
先說結論：我們做的，其實就是持續進行「了解現況 → 思考對策並改善 → 量化衡量」的循環。沒有什麼特別的框架，就是一個簡單的改善（Kaizen）循環。但看似簡單，要讓這個循環持續運作並不容易。以下依序說明我們的 做法。
我們以為「該做的都做了」
事實上，在開發 QAAP 的一年前，我們作為組織已經開始推動生成式 AI 的應用了：
- 設立專門的 AI Slack 諮詢頻道，讓人可以輕鬆詢問
- 依不同主題成立學習小組，每 3 個月為一個週期，提供主動學習的機會
- 舉辦 Lightning Talk，創造分享成果的機會
- 在每月全員會議分享方針與最新趨勢，建立組織內的共同認知
- 早期就將 AI 相關項目納入目標設定，推動成員行動
- 在 1on1 中也進行個別追蹤與輔導
我們已建立交流管道、積極分享資訊，也提供個別協助。作為推動者，我們自認已把能做的事情做得差不多了。
但這些後續行動多半還是交由個人來執行，結果往往變成「大家各自努力」。
但從組織整體的角度來看，我們並沒有明顯感受到整體能力真的被拉高了。雖然知道有人正在積極應用，但每個人實際怎麼使用，我們並不清楚。於是我們決定先以資料確切掌握當下位置，先把整個組織的 AI 應用程度視覺化。
以資料掌握當前位置
我們設計了 AI 能力成熟度模型（AI skill maturity model）。參考 DeNA 的 AI 能力評估指標「DeNA AI Readiness Score（DARS）」，並針對我們部門做客製化調整。
- 參考：DeNA「全社のAIスキルを評価する指標『DeNA AI Readiness Score(DARS)』を導入開始」 https://dena.com/jp/news/5279/
| Lv | 狀態 | 能做的事 |
|---|---|---|
| 1 | 臨時性嘗試（Ad-hoc trial） | 使用聊天型 AI 做摘要與頭腦風暴 |
| 2 | 部分 QA 支援（Partial QA support） | 結合業務情境與結構化 prompt 支援子任務 |
| 3 | 多來源情境整合（Multi-context integration） | 整合多個資訊來源，AI 主導產出穩定的工作成果 |
| 4 | 自主工作流程（Autonomous workflow） | 由 AI agent 實現工作流程的端到端自動化 |
| 5 | 新標準（New standard） | 重新設計並橫向擴展 QA 的標準流程 |
Lv1〜2 屬於尚未整合進正式業務流程的輔助型使用；當達到 Lv3〜4，便能透過 context engineering 等方式，讓 AI 主導工作產出與流程推進。
我們以這個模型做問卷後，結果顯示超過一半的成員位於 Lv1〜2，也有部分成員已達到 Lv3〜4，已能以 AI 驅動工作。這讓「應用程度不均」的感覺變成可被量化的事實。
我們當然歡迎擅長的同事繼續往前走，但從組織的角度，希望這些能力能沉澱並擴散到整個組織，進一步提升整體水準。如果不解決「各自努力」的問題，組織無法向前推進。透過資料掌握現況後，我們判斷需要建立一套機制，讓先行者的知識與做法能被所有人複製與使用，從而達成整體提升。
花一整天，把大家聚到福岡
資料準備好後，接著要執行對策。
我們首先做的是一場為期一整天的實體 Hands-on，目的在讓整個 組織都實際使用 QAAP。包括東京據點以及在名古屋遠端工作的成員，我們都請大家集中到福岡，親自參與。這次活動在 2026 年 2 月舉行。當時公司內多數活動仍以線上形式進行，我們特意選擇以實體方式舉辦。
為什麼堅持實體舉辦？因為「各自努力」的本質，是把問題交給個人承擔。
沒有人提問，不代表大家都已經會用。很多時候其實是「因為不懂，所以連問題都不知道怎麼問」；即便有人分享，因為理解還不夠，也不一定會追問，隔天更難把學到的內容落實到工作流程中。結果又回到「只有會的人在做」，這對組織來說並不健康。
所以我們要讓大家在同一時間、同一地點、面對面一起操作。不懂就能當場問：「這個怎麼做？」Hands-on 的內容設計也要求把學習直接對應到各自的業務，讓大家隔天就能在工作中使用。現場已經很熟練的成員，則在一旁協助還不熟悉的人操作。這種現場氛圍是線上難以複製的。雖然成本與行程協調都不容易，但我們判斷，這個階段最重要的是讓每個人至少有一次共同的實作體驗，因此仍決定採用這種方式。
Hands-on 只是起點
那麼，舉辦了 Hands-on 後一切就會順利運作了嗎？並非如此。
Hands-on 只是讓大家站上同一條起跑線的開始。如果到這裡就停下來，情況又會回到「各自努力」。要讓使用習慣持續下去，必須持續讓改善循環運轉。
因此，我們再次回到「把現況視覺化」這件事。當所有人都站上相同基礎後，除了等級分類外，更需要掌握具體的使用情況。於是我們把調查從成熟度等級改為 QAAP 使用情形問卷，並把問卷結果帶進三套運作機制中。
第一是每兩週一次、全員參與的 QAAP 例會。除了方針與更新外，我們會以問卷結果為基礎安排成員間的討論時間，目的在避免把問題留給個人自行承擔。第二是 QAAP 推動團隊例會，將「這個技能的輸出準確度不足」或「需要新增某種技能」等意見回饋到基礎設施的改進中。第三是領導層例會，透過觀察問卷趨勢，找出使用程度較低的成員遇到哪些障礙，並規劃個別輔導策略。
一份問卷，同時驅動橫向推廣、基礎建設改進與個別追蹤，這就是我們建立的結構。
為何系統突然開始運轉？
這裡可能會有個疑問：我們之前也做過資訊分享、例會與各種推動，為何在 QAAP 全體使用後，整個改善循環才真正開始運轉？
答案是：有了 QAAP 這套共用機制後，「共同理解的解析度（shared resolution）」改變了。
當所有人都在相同的機制上操作時，就能以具體且共同的操作基礎進行討論。其他人的做法，也更容易在自己的環境中重現。先前已在進行的那些循環，因為多了「具體性」與「可重現性」，才真正開始發揮作用。這點是關鍵差異。
實際成果
最近公司內部已能以組織為 單位視覺化生成式 AI 的使用情形。在以 AI 使用率為橫軸、使用次數中位數為縱軸的分布圖中，我們的產品 QA 組位於最右上角—也就是使用率 100％，而使用頻率的中位數在所有單位中也是最高。整個團隊都已能熟練使用 AI agent。
當然，我們並非一開始就達成這樣的狀態，而是持續運作改善循環的結果。除了讓每個人都能理所當然使用之外，先前提到的數字成果—QA 作業時間減少 49.4％（不含測試執行）、QA 產出數 1.54 倍、由 AI 代為產出的比例 68.1％—也明顯反映了這些努力。
與 DORA 報告的對照
在此引用一份報告，是由以 Four Keys 著名的 Google Cloud 研究團隊 DORA 發布的。他們在 2025 年的報告中得出以下結論：
Successful AI adoption is a systems problem, not a tools problem.（AI 導入的成功是系統的問題，而非工具的問題）
AI's primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.（在軟體開發中，AI 的主要角色是放大器。它會放大高績效組織的優勢，也會放大掙扎組織的功能失調）
出處：DORA | State of AI-assisted Software Development 2025
此處所言的「組織系統」，指的是支撐開發組織的基礎能力。若組織系統良好，AI 會放大其優勢；若系統不健全，AI 則會放大其問題。讀到這份報告時，我們有種「原來我們走的方向是對的」的感覺。
最後補充—危機感與率先垂範
最後回顧整個推動過程，我認為有兩件事最關鍵：危機感與率先垂範。
這部分是我（上田）個人的經驗分享。身為單位負責人，我得坦白到 2025 年 12 月左右為止，其實我並沒有在使用 AI agent。以我們的成熟度模型來說，我大概處在 Lv2〜3 之間。相對地，福永因為在內部被稱為「生成式 AI 大臣」，已經相當熟練地使用 AI agent。
到了 2025 年年末，福永在 Slack 的雜談頻道分享了一支 AI agent 入門的 YouTube 影片，片長約 1 小時 30 分。當時我其實有點不想看，但因為年末有空便觀看並自己嘗試操作後，深受震撼：眼前正發生一場典範轉移。AI 以驚人的速度改寫一切。如果我們不能成為真正大規模運用 AI 的一方，未來無論是組織還是個人，都可能難以生存。那一刻我感到強烈的危機感。
但只有危機感，組織不會自動跟著動起來。這就是第二點：率先垂範。推動機制與活動的人必須站在前面，以行動作為榜樣。如果一個人喊著「AI 讓我們速度 10 倍」，但他自己卻不用 AI，那就毫無說服力，也沒有人會跟進。提出倡議的人要徹底親自去嘗試、去使用、去熟悉。這樣策略才會變得具體，也才會有說服力。這是最重要的推動力。
結語
以上是我們如何以「系統機制（Systems）」與「推動措施（Initiatives）」雙軌並進來面對阻礙組織化 AI 應用的兩道牆。技術面的風險與障礙，由 QAAP 在基礎設施層處理；人性與心理層面的障礙，則透過持續的改善循環來面對。
本文後半段讀起來，或許較偏向管理議題，而非純粹的技術討論。不過，LINE 前 CTO 池邉智洋先生曾在就任 CTO 的訪談中提到：
「Management is actually engineering.（管理，其實也是一種工程。）」
（參考：エンジニアtype〈【LINE新CTO池邉智洋】生粋の技術屋が組織マネジメントに苦しんだ過去から学んだ“開発チーム戦”時代の生き抜き方〉）
從這個角度來看，制定組織策略、設計協作方式，以及與團隊成員持續溝通，本質上都可以視為一種工程問題：需要理解現況、辨識問題、設計機制，並透過實際運作持續驗證與改善。
因此，本文後半段所談到的各種「組織機制設計」，其實也可以視為一種工程實作。
我想應該有很多組織現在仍停留在「各自努力」的階段。希望本篇文章能成為大家思考下一步行動的參考。
