新聞正文

在AI大量生成程式碼與測試案例的開發現場，目前最耗費人力的環節，正是「判斷AI寫出的內容是否可以發布」這項工作。 儘管測試通過，仍可能遺漏缺陷、忽略需求，甚至在發布後才發現相容性問題。 量產可由AI完成，但正確性的判斷仍需仰賴人工。 專精於軟體測試與品質保證的株式會社bubo（總部：大阪府大阪市中央區，代表取締役：渡邊博之）於2026年7月宣布，將其內部用於「判斷正確性」的品質保證方法論，整合為可透過MCP（Model Context Protocol）相容AI客戶端（如Claude、Cursor等）呼叫的工具「Nioh（仁王／讀音：におう）」，並正式推出。

以「為開發把關，注入品質智慧」為理念，Nioh涵蓋需求審查、測試設計、AI生成程式碼驗證，乃至營運階段的問題根源分析。 這些工具皆源自bubo自身日常開發所使用的實務方法。 正式版將以付費訂閱制提供。 在此之前，bubo現正以面談制方式，限量招募可優先體驗功能的先行測試企業。 ■ 背景：AI能產出數量，但判斷正確性仍是人類的工作常聽人說「AI將取代人類工作」，但在2026年的開發現場，實際發生的卻是相反情況：人類需逐一檢視AI高速產出的程式碼與測試，所花費的時間反而增加。 bubo認為，「判斷正確性的工作」將成為未來品質保證的核心。 因此，公司將自身在QA現場實踐的流程，整合為可從本地AI呼叫的工具。

在先行測試階段，bubo將與貴公司共同評估這些工具在實際流程中的有效性。 ■ 功能範圍：涵蓋從上游到營運的完整開發流程Nioh針對軟體開發各階段提供對應工具，整體架構對應典型的V型開發流程。

需求定義：在實作前，檢視需求是否遺漏、模糊或未定義對象（如需求審查、需求格式重整等）設計階段：找出影響範圍或異常流程的疏漏，於設計階段確立必要的測試觀點與優先順序（如設計審查、測試設計、測試優先排序、可追溯性檢查等）實作與程式碼審查：比對AI撰寫的變更是否符合需求、是否破壞既有功能，並在實作時即掌握因意外輸入導致崩潰的弱點或公開API的非相容變更（如AI變更驗證、穩健性檢查、API相容性檢查、完成條件檢查等）測試階段：辨識「雖通過卻遺漏缺陷」的測試，或容易失敗、不穩定的測試（如測試有效性評分、測試程式碼品質檢查、不穩定測試偵測等）發布與營運：針對發生的缺陷深入挖掘根本原因，並將結果反饋至預防措施與新增測試案例（如缺陷分析等）例如，向AI變更驗證工具提問「此PR是否符合需求？

」，系統將比對變更內容、需求文件與測試案例，指出需求未滿足之處，以及是否修改了無關區域。 ■ 兩種使用方式：對話中呼叫，或於CI自動攔截對話式呼叫：於開發過程中，從您使用的AI客戶端（如Claude、Cursor）直接呼叫，即時取得審查意見與回饋。 CI自動執行作為品質關卡：具備通過／不通過判定功能的工具，可整合至GitHub Actions等CI系統，自動攔截未達標準的變更，形成「品質關卡」。 ■ 與一般詢問AI有何不同？ 或許有人會想：「審查工作，直接問AI不就好了？ 」Nioh與通用大型語言模型（LLM）的差異在於以下三點：具備明確的審查觀點：工具本身內建QA應檢查的「觀點」。

需求審查依USDM方法，測試設計則基於邊界值分析、決策表等技術，確保檢查視角一致且無遺漏，結果不受提示詞撰寫技巧影響。 結果明確且可重現：多數工具透過靜態分析得出結果，相同輸入必得相同輸出，避免LLM常見的「每次回答不同」或「看似合理卻錯誤（幻覺）」問題，僅在必要時才呼叫AI。 可傳回通過／不通過結果，實現自動關卡：結果以結構化形式（如指摘事項、評分、通過／不通過）回傳，可整合至CI系統自動攔截。 一般對話式AI的文字回應則無法機械化處理。 簡言之，通用AI是「問了會回答」的工具，Nioh則是「知道該查什麼、怎麼查」的專業工具。 它將bubo在開發與QA現場累積的方法論，完整封裝其中。

■ 提供方式與先行測試計畫Nioh正式版將以付費訂閱制提供。 本次招募的先行測試，是為讓企業在正式版推出前優先體驗功能的限量方案。 正式版：預計以付費訂閱制提供（價格與方案細節尚未公布）。 先行測試：採面談制的限量名額。 因需面談，錄取企業數量有限。 面談中將共同評估適合貴公司流程的工具與導入順序，並提供設定與串接方式。 測試期間免費使用。 正式版發布時測試計畫即結束，參與企業將優先獲得正式版導入資訊。 ■ 為何免費提供先行測試？ 在為正式版定價前，bubo希望實際了解各工具在開發現場的成效，並根據使用者意見持續優化。 對bubo而言，這段期間是「驗證是否真正有用」的關鍵階段，優於定價考量。

正因如此，才以免費限量方式，邀請願意提供坦率意見的企業參與。 ■ 如何保護外部機密程式碼？ （BYOK）傳遞至工具的程式碼、規格與資料，bubo伺服器不會儲存，也不會用於自身模型訓練。 LLM由使用者自行提供金鑰（BYOK＝Bring Your Own Key），呼叫所選的服務供應商。 資料處理規範依使用者與供應商的合約而定。 目前使用LLM金鑰的工具支援Claude與Gemini，其他供應商將陸續支援。 因採用BYOK機制，使用LLM的工具所產生的API費用，將由使用者依自身與供應商的合約另行支付（與bubo服務費用分開）。 此規則適用於測試版與正式版。 純靜態分析即可完成的工具，則不產生此類API費用。

工具分為三大類：（1）僅透過靜態分析或統計完成、完全不呼叫外部LLM的工具（如測試有效性、穩健性、資源洩漏、API相容性、可追溯性等）；（2）以靜態分析為主，必要時可併用LLM的工具；（3）需使用LLM進行判斷或生成的工具（如需求審查、測試設計、AI變更驗證等）。 使用者可自行控制傳送至AI的資料範圍。 哪些工具會傳送資料至外部LLM，哪些不會，通訊