高額SaaS該不該解約改為自建｜生成式AI時代的7個判斷標準

大家好，我是株式會社TIMEWELL的濱本 隆太。

打開SaaS的續約報價，看到比去年更高的金額時，你是否也曾閃過一個念頭：「這樣的話，我們自己做會不會比較便宜？」在生成式AI讓寫程式的成本降低的現在，這個念頭比以前更有現實感。

先說我的立場。大多數的SaaS，我認為不要解約比較好。像會計、薪資這類受法令規範的業務，現在交給SaaS仍然最合理。不過，對於按使用人數計費、功能變化緩慢、結構單純的業務，重新自己做開始有了價值。難的是，這個「對於」的界線要畫在哪裡。

這篇文章整理了7個標準，用來判斷是否該解約已經在付費的高額SaaS、改為自行開發。這是5篇系列的第1篇，候選對象的挑法、5年總成本的試算、解約與移轉的實務、放在自家雲端的設計，會分別在其他文章深入討論。至於AI的運用要有多少放在公司內部，這個更廣的分界問題，我寫在AI要自己做到什麼程度。這一篇只聚焦在一件事：現在付費的SaaS，要不要停掉。

為什麼會開始覺得「自己做比較便宜」

SaaS費用看起來膨脹，主要有兩個原因：價格本身上漲，以及對以日圓付款的日本企業來說，日圓貶值。

舉一個價格的例子。一家海外大型軟體公司的日本分公司，自2024年4月1日起，將企業用軟體與雲端服務的日圓價格一律調漲20%，並表示今後也會考量美元匯率變動，作為每年兩次定期價格評估的一環，可能調整當地貨幣計價的價格¹。也就是說，以日圓支付的SaaS價格，會透過美元定價的調整與日圓價格的重新檢視兩條路徑變動。

再看匯率。把日本銀行公布的月平均值按年份平均，2020年1美元兌106.78日圓，2024年為151.50日圓，2026年1月到8月為158.78日圓（我依日本銀行的統計計算）²。和2020年相比，日圓貶值超過四成。以美元定價的服務，即使什麼都不做，日圓帳單也會逐年變高。

日本企業也有感。日本資訊系統使用者協會（JUAS）2026年版的調查中，IT預算增加的第二大理由是「日圓貶值、人事成本上升、廠商調漲價格等影響」，在2025年度計畫中有46.6%的企業列出這一項³。同一份調查裡，企業對系統開發內部化最期待的效果，第一名變成「降低開發成本」（41.3%），超越前一年的第一名「在公司內部累積知識、提升開發能力」。報告書推測，受到廠商大幅漲價的影響，「眼前降低成本的優先度急速上升」³。

接著生成式AI來了。一家海外開發工具公司針對自家817名使用者所做的調查（2026年2月發表）中，35%的人表示至少已把一個SaaS換成自己做的工具。不過，回答者本來就是使用「做東西的工具」的人，比起一般企業，應該更偏向自己做。

常被拿來當象徵的是瑞典的支付公司Klarna。它停用一套大型CRM的事引起話題，「AI取代了SaaS」的看法也隨之擴散。然而執行長Sebastian Siemiatkowski本人在2025年3月的X（前Twitter）貼文中寫道，依公司內部估計停用了約1,200個SaaS，但同時明確表示，並不是用LLM取代SaaS，把CRM資料存進LLM是有極限的⁴。實際上做的，是用Neo4j等工具，建立把資料整合成知識的內部技術基礎。他也寫道：「所有公司都會做跟Klarna一樣的事嗎？我很懷疑。」⁵

我認為這段說明最有參考價值。Klarna能停用那些SaaS，不是因為AI幫它做出了畫面，而是因為它先把散落在各個SaaS的資料整合在一起。畫面之後要做多少都可以。在資料還沒整合之前就先解約，很可能只是在公司裡多了一堆做同樣事情的工具。

即便如此，基本上繼續用SaaS才是對的

先把削弱我主張的材料擺出來。隱瞞不寫，會讓讀者誤判。

首先，日本的公部門指引明顯偏向SaaS。日本經濟產業省的《DX報告2》（2020年12月）寫道，企業在協調領域應「排除凡事自己來的思維」，推動業務流程標準化，運用SaaS與套裝軟體，壓低IT投資的預算與人力投入⁶。日本數位廳為政府資訊系統訂定的DS-310（2025年5月），也因為SaaS能減少開發量，要求廣泛且優先地考慮使用⁷。

日本企業的實際情況也是同一個方向。根據日本資訊處理推進機構（IPA）的《DX動向2025》，非核心、非競爭領域系統的取得方式，「導入套裝軟體」占33.8%、「導入SaaS」占24.4%，「內部自行開發」只有16.6%。表示「正在推動」系統開發內部化的企業，日本是22.3%，美國是46.4%。而在正推動內部化的日本企業中，有82.3%把「人才的確保與培育很難」列為課題⁸。

生成式AI讓開發變快的說法，也有保留。美國研究機構METR以16名資深開源開發者、246個實際任務進行的隨機對照試驗中，允許使用AI的條件下作業時間反而長了19%。開發者事前預期會快24%，結束後也仍然覺得快了20%⁹。METR在2026年2月的後續報告估計，2025年底的工具讓作業時間縮短了18%，但信賴區間是負38%到正9%，跨越了零¹⁰。以近5,000名技術人員為對象的DORA 2025年研究指出，AI的使用與交付吞吐量呈正相關，但與交付穩定性仍持續呈負相關¹¹。資安產品公司Veracode的調查則發現，由100多個LLM產生的程式碼中，有45%沒有通過資安測試¹²。

做得快，和能長期安全地運作，是兩回事。SaaS的使用費裡，包含了「長期運作」的成本。

那為什麼還要談解約？因為DS-310本身就寫了例外。這份文件表示，強烈建議使用SaaS，但並非無條件；像使用人數會逐步增加等、運作階段使用費可能變高的情況，應從生命週期成本的觀點審慎評估是否真的能降低成本。如果能以其他代管服務實現與SaaS相同的功能，就應該比較兩種方式。另外在其他段落，它特別提醒，按帳號數計費的SaaS與高額SaaS，要充分留意使用帳號數的變化⁷。

這篇文章的主張，只限於這個例外的範圍。不是要你停掉SaaS，而是要辨識出符合例外的對象，只針對這些對象考慮重做。

判斷是否可以考慮解約的7個標準

先用表格列出我使用的7個標準。不是靠其中一個來決定，而是把7個並排來看。

標準	看什麼	可以考慮解約的訊號	最好繼續使用的訊號
① 年費與漲價幅度	目前的年費、過去的調價、匯率影響	年費高、持續調漲	年費低、自己做明顯比較貴
② 使用人數與按帳號計費	計費單位、使用人數的增加方式	按人計費，使用人數持續增加	固定費用，或使用人數幾乎不增加
③ 資料與功能變化的快慢	欄位與畫面變更的頻率	好幾年都用幾乎相同的欄位與流程	幾乎每個月都在用新功能
④ 法令與會計規則的複雜度	追隨稅制、會計準則、產業法規的修正	不受法令修正影響的內部業務	會計、薪資、報稅等經常修正的業務
⑤ 與其他系統的串接	串接系統的數量與方向	串接少，資料的進出口有限	與許多外部服務雙向連動
⑥ 維護的人力與體制	負責修改的人、可用時間、合作夥伴	能指定負責人並確保時間，也有夥伴	沒有人能負責，或只能兼職順便做
⑦ 解約與移轉的條件	續約日、通知期限、資料匯出方式	能以可用格式匯出全部資料，期限充裕	通知期限將至，或有資料無法匯出

① 年費與今後的漲價幅度

第一個要看的，是現在付多少、今後可能變成多少。聽起來理所當然，但我的感覺是，看請款單上年費的公司很多，把過去5年的調價紀錄和匯率影響並排來看的公司卻沒那麼多。

要看的數字有三個：目前的年費、過去調價的頻率與幅度，以及美元計價服務的匯率敏感度。像前面的例子，已表明每年檢視兩次價格的服務，先算好1美元變動10日圓時年費會變多少，簽呈時的討論就會具體得多。

相反地，年費只有幾十萬日圓的SaaS，解約後自己重做，幾乎划不來。開發費用、維護人員的時間、伺服器費用加起來，很容易就超過解約省下的金額。這個標準與其用來說明「可以解約」，不如用來篩掉「不值得考慮」的對象，比較實用。5年總成本的具體試算方式，會在系列第3篇SaaS的5年總成本試算討論。

② 使用人數的成長與按帳號計費

這是DS-310特別點名提醒的標準⁷。以每人每月計費的SaaS，公司越成長、使用人數越多，即使功能一樣，帳單也會一路增加。

用假設的數字算算看。每人每月3,000日圓的SaaS，300人使用的話，年費是1,080萬日圓。假設使用人數每年增加20%、單價每年上漲5%，第5年的使用人數約620人，年費約2,720萬日圓，5年合計約9,040萬日圓。若人數與單價都不變，5年是5,400萬日圓，差距約3,600萬日圓（以上皆為本公司的假設計算，實際單價與增加方式因公司而異）。

自己做的成本，使用人數加倍也不會跟著加倍。伺服器費用會增加，但增加方式和按人計費完全不同。越是像企業內部入口網站、申請、清冊這種全體員工都會用的工具，這個差距越明顯。日本總務省的2025年調查中，至少部分使用雲端服務的企業占83.5%，使用內容的第二名是「公司內部資訊分享與入口網站」（61.4%）¹³。全員都會用的工具，正是最常放在雲端服務上的。

使用人數幾乎不增加的公司，或是固定費用的合約，這個標準就不適用。使用人數的預估，請和招募計畫放在一起確認。

③ 資料與功能的變化是否緩慢

第三個標準，是那套系統多久變一次。這個標準容易被誤解，所以回到原典確認。

Gartner在2012年提出的「步調分層（Pace-Layered）」概念，把企業的系統依變化速度分成三層。對於最慢的一層「記錄系統（Systems of Record）」，原典的說明是：支援核心交易處理、管理組織重要主資料的既有套裝軟體或系統，因為流程已經成熟、多數組織共通，而且常受法規要求約束，所以變化速度慢¹⁴。換句話說，依原典的立場，越是變化慢的系統，越適合用標準套裝軟體。如果單純說「因為變化慢，所以可以自己做」，就和原典講的相反了。

我仍然把變化快慢列為標準，是因為它和另一個軸搭配起來就能用。那個軸就是下一個標準④：法令與會計規則帶來的複雜度。我們要找的，是變化慢、而且結構單純的業務。像內部清冊、FAQ、企業內部入口網站、申請受理、報價紀錄這類業務，一旦做好，欄位與流程好幾年幾乎不變。這類業務的SaaS使用費，有很大一部分是在支撐自家根本用不到的新功能開發。

同一份原典也寫道，同一個應用程式在不同公司可能屬於不同的層¹⁴。對某家公司只是一份清冊，在另一家公司可能是競爭力的來源。候選業務的辨識方式，我在系列第2篇哪些業務系統可以自己做中，用「資料更新頻率」這個本公司的觀點深入討論。另外，以資料更新頻率為軸來區分自己做或購買的公部門框架，在我查到的範圍內沒有找到。請把它當作本公司的觀點來讀。

④ 法令與會計規則的複雜度

即使看起來變化慢，受法令規範的業務也要另外處理。像會計、薪資、報稅、出勤管理這類，必須跟上稅制修正與會計準則變更的業務。

舉個具體例子。日本2024年的定額減稅，對受薪者的減稅原則上是從2024年6月1日以後支付的薪資所預扣的所得稅中扣除，6月扣不完的部分，再從同一年之後的薪資依序扣除¹⁵。如果薪資計算是自己開發的系統，就得在稅制修正後的幾個月內把這套機制做好、驗證完，年底的年末調整（日本的年度稅額結算）還要再確認一次。SaaS的使用費裡，也包含了追隨這類修正的成本。

即使生成式AI讓寫程式變快，閱讀修正內容、正確解讀、找出例外的工作仍然存在。而且一旦出錯，影響會直接出現在員工的薪資與報稅上。我認為這類業務應該繼續使用SaaS或套裝軟體。

判斷的基準是：「決定這項業務規則的，是公司自己，還是法令？」內部申請的核准路徑由公司決定；薪資預扣稅額的計算由法令決定。前者可以列為候選，後者原則上請排除。

不過，要排除的只有原始紀錄與法定處理。就算是會計或人事勞務的SaaS，全體員工會用的申請畫面與彙總，也是公司自己決定的部分。把這部分自己開發，資料再透過API交給SaaS，就有機會把SaaS帳號減到只剩會計與人事的負責人。這正好對應基準②的按帳號計費。怎麼切分、合約中要先確認哪些條款，寫在本系列第2篇哪些業務系統可以自己開發。

⑤ 與其他系統的串接有多少

第五個是串接的數量。這不是公部門的指引，而是我的看法：開發後維護工作量最大的變數，就是和其他系統的連結。

多數SaaS都有和單一登入（SSO）、會計、人事主檔、聊天工具、電子郵件、BI等串接的元件，對方規格變更時的跟進也由廠商負責。自己做的話，這些跟進全都變成自己的工作。每多串接一個系統，就多一個可能壞掉的地方。

算法很簡單。把所有把資料送進這個SaaS的系統、以及從這個SaaS接收資料的系統全部列出來。如果數量多、而且很多是雙向同步，重做的費用大半會花在串接的開發與維護，而不是畫面。如果只是員工在畫面上輸入、每個月匯出一次CSV交出去這種程度的進出口，難度就會大幅下降。

回想一下Klarna的例子。它能停用SaaS，是因為先整合了資料⁴。想解約串接很多的SaaS，就需要先把資料的存放位置整合起來的設計。這部分設計會在系列第5篇把業務應用程式放在自家雲端的設計討論。

⑥ 做好之後由誰維護

7個標準之中，我最看重的就是這一個。比起做出來，決定做好之後由誰持續修改，要難得多。

日本的數字相當嚴峻。前面提到的IPA調查中，正推動內部化的企業有82.3%把人才的確保與培育列為課題，19.5%表示「把外部開發的系統轉為內部維護很難」⁸。IPA的2026年版中，回答推動DX的人才數量「有點不足」或「非常不足」的企業合計85.5%¹⁶。

在海外，維護也是最後留下來的課題。據報導，美國醫療保險公司Curative的執行長Fred Turner表示，他解約了年費60萬美元的CRM合約、兩個月內做出公司內部的CRM，同時也說維護「絕對是最困難的課題之一」¹⁷。開發變快之後，維護的負擔反而更顯眼了。

這個標準要確認三個問題。能不能指名一位負責修改系統的人？能不能明確保留這個人每週幾小時的時間？遇到負責人一個人處理不了的變更或故障時，有沒有可以求助的夥伴？三個都答不出來，就表示解約還太早。

這裡說的夥伴，不是代替你開發再交件的外包商，而是在公司內部負責人能自己修改之前，坐在旁邊一起做的人。《DX報告2》也寫道，對於使用者企業內部人才無法立即因應的技術，廠商協助轉向內部開發、並肩合作轉移技能的需求將會提高⁶。

⑦ 解約與移轉的條件

最後是合約條件。即使其他條件都具備，解約手續和移轉時機一旦出錯，雙重付費的期間就會拉長，甚至可能遺失資料。

換約之難，數字也看得出來。日本公平交易委員會（JFTC）2022年公布的雲端領域實態調查中，過去10年曾更換雲端業者的事業者只有15.7%（548家中的86家）。若目前使用的服務漲價5到10%，在明確作答者之中，表示會更換的只有約14.1%¹⁸。這個題目的對象主要是IaaS與PaaS的使用者，但「一旦開始用某個雲端，就很難離開」的傾向相當明確。

要確認的項目，可以從IPA《中小企業雲端服務安全使用指南》（2026年6月版）列出的使用結束時確認事項開始：全部資料的返還或下載、資料的相容性與可攜性、剩餘資料的完全刪除，以及保證其他使用者無法再利用¹⁹。DS-310也要求選擇資料可攜性有保障、價格體系公開且合理的服務，以避免廠商鎖定⁷。

合約中，請務必確認三件事：自動續約的條件與解約通知期限；減少授權數量只保留一部分時，單價怎麼算；以及合約終止後幾天內還能取出資料。本公司確認過的一份海外大型SaaS基本合約（2026年9月版）規定：除非訂購單另有約定，若未在期滿30天前通知，就會以1年為單位自動續約；減少數量或期間續約時，不論前期單價，價格會重新設定；終止後30天內未提出要求，廠商就沒有保存資料的義務。只保留一部分，不一定比較便宜。解約的步驟，我在系列第4篇SaaS解約與系統移轉實務中，寫成從續約日倒推的時程表。

7個標準怎麼用

把7個標準用相同權重加總，會導致誤判。我是按照以下順序使用。

首先，用④和⑥篩選。受法令與會計規則強烈約束的業務，不論其他標準多麼傾向解約，都排除在候選之外。無法指名維護負責人的業務，也先排除。這兩項一旦失敗損失很大，而且要到做好之後才會浮現。

通過篩選的，再用①和②看金額。5年大概要付多少？其中按帳號計費的成長占了多少？和自己做的成本相比差距不大，就沒有解約的理由。只有差距大的才進入下一步。

接著用③和⑤看難度。變化越慢、串接越少，重做越容易，之後的維護也越輕。最後用⑦決定時機。即使成為候選，如果離通知期限只剩3個月，那一期就先讓它續約，為下一次續約做準備比較安全。

候選請只挑一個。同時解約好幾個SaaS，移轉工作會重疊，雙軌並行期間的負擔會集中在現場人員身上。先在第一個身上熟悉流程，確認維護運作得起來，再進行第二個，這樣比較實際。

系列的其餘4篇，是照這個順序寫的。

閱讀順序	文章	內容
1	哪些業務系統可以自己做	依標準③④挑選候選業務
2	SaaS的5年總成本試算	依標準①②比較自己做與繼續使用的總成本
3	SaaS解約與系統移轉實務	依標準⑦安排通知期限、資料匯出與雙軌並行
4	把業務應用程式放在自家雲端的設計	依標準⑤⑥設計權限、資料位置與維護體制

以FDE推動SaaS解約與自行開發

接下來談我們自己。TIMEWELL以FDE（Forward Deployed Engineer）的方式，陪客戶從這個判斷開始，一路走到重做、移轉，以及公司內部能自行運作。FDE是進入客戶現場、坐在旁邊負責開發與導入的工程師，詳細內容寫在什麼是FDE。

我們的FDE能做什麼

首先，盤點目前使用的SaaS，用這篇文章的7個標準把候選縮小到一個。把年費、計費單位、使用人數的變化、串接對象、合約的續約日與通知期限列成一覽表，不符合篩選條件的，我們會坦白告訴您「應該保留」。

候選確定後，我們會在第一週內，用遮蔽個人資料等資訊後的實際資料，讓您看到可以運作的試作品。不等規格書定案，先請現場負責人實際操作，詢問「和現在的業務哪裡不一樣」，隔天就修改。來回幾次之後，就會看出SaaS的哪些功能真的有在用、哪些根本沒用到。

接著決定雙軌並行的期間、移轉資料，並從續約日倒推發出解約通知的時間。期間一開始就以45到90天為區隔，結束條件在開始前就定為「公司內部的負責人能自己修改」。

關於AI的使用，我們也有一項承諾：處理所用的雲端服務與AI模型，只從不會把客戶資料用於訓練的選項中挑選。在哪裡處理，則依需求與成本的平衡，按案件個別設計。資訊安全管理方面，本公司已取得ISO/IEC 27001認證（登錄範圍：運用AI技術之SaaS產品的企劃、開發與提供）。

進行方式與體制的詳細內容，整理在FDE服務頁面。

與委外開發的差異

解約SaaS之後，改用委外開發重做，會發生什麼事？只有承包商知道新系統的內容，每次變更都需要報價與下單。好不容易脫離SaaS的鎖定，卻走進承包商維護合約這個新的鎖定，這是應該避免的結果。

我們的FDE在這一點上，和委外開發的組成方式不同。第一是工時的意義。委外開發的工時就是營收，待得越久越有利；我們把FDE的工時定位為投資，以每位客戶的工時逐漸減少為目標。第二是所得知識的去向。其他公司也能用的共通機制，會回流到我們產品的功能，用來讓下一個案子更快、更便宜；只有那家公司才有的流程與業務用語，則保留為那家公司所有。第三是結束的方式。不是驗收就結束，而是在公司內部負責人能自己修改的時候，我們就離開。也就是說，在開發過程中培養出標準⑥的「維護負責人」，也包含在我們的工作裡。

我們的實務與限制

坦白說，這種做法並不適合所有公司與業務。

會計、薪資、報稅這類受法令規範業務的SaaS，即使您來諮詢解約，我們也不會建議重做。如同標準④，把追隨修正的成本算進去，SaaS更便宜也更安全。像ERP核心這種交易量大、與許多系統相連的，也一樣。

公司內部無法安排維護負責人的情況，我們不承接。我們的前提是公司內部能自行運作時就離開，沒有負責人就開發，只會留下一套沒人能修改的系統。這種情況我們會建議，等到能安排負責人再開始，或是決定繼續使用SaaS。

年費低的SaaS，開發費用加上維護人事成本，很容易超過解約省下的金額，實際上不太會成為對象。離通知期限已經不遠時，我們會建議先從為下一次續約做準備開始。

也寫一下我們自己的界線。我們自己開發並營運員工用的入口網站（日報、目標管理、內部研修等），但會計仍然持續使用外部的雲端會計服務。這條線的理由，就是標準④和⑥。

最後是我們的容量。本公司是小公司，由經營團隊直接進入現場。能同時進行的案子數量有限，這個上限我們不隱瞞。

總結

• SaaS費用看起來膨脹，背後是漲價與日圓貶值的雙重作用；JUAS的調查中，企業對內部化最期待的效果也變成了降低開發成本
• 即便如此，公部門指引的基本立場仍是SaaS優先，生成式AI開發的速度也伴隨穩定性與安全性的保留
• 例外由DS-310本身寫明：因按帳號計費而膨脹的高額SaaS，以及可用代管服務做出同等功能的對象，應以生命週期成本比較
• 用7個標準判斷。以④法令與會計規則、⑥維護體制篩選，再以①②看金額、③⑤看難度、⑦看時機
• 候選只挑一個，先整合資料，再做畫面

我從Klarna的例子得到的教訓是：能不能停用SaaS，不是由AI有多聰明決定的，而是由能不能把資料與維護握在自己手上決定的。解約，只是這個結果而已。

現在付費的SaaS之中，哪些符合這7個標準？想從盤點開始一起進行的話，歡迎參考FDE服務頁面，或透過FDE個別諮詢和我們聊聊。下一篇會從「資料更新頻率」這個軸，寫如何辨識適合列為候選的業務。

Footnotes

1. 海外大型軟體公司自2024年4月起調漲企業用軟體與雲端服務價格（＠IT，2023年12月11日，日文）。2024年4月1日起調漲20%與每年兩次定期價格評估的敘述依該文 ↩

2. 時間序列統計資料檢索網站（日本銀行）。資料庫FM08、系列FXERM07（東京市場美元兌日圓即期匯率，17時，月平均）的月資料，由筆者按年份單純平均。2026年為1月至8月的平均 ↩

3. 企業IT動向調查報告書2026（日本資訊系統使用者協會，日文）。IT預算增加理由見圖表2-1-3，內部化期待效果見圖表7-2-6（n=863）。2025年度調查，對象為東證上市企業及同等企業4,500家，回覆957家 ↩ ↩²

4. Sebastian Siemiatkowski的X貼文（2025年3月4日）。約1,200個SaaS停用的內部估計，以及並非以LLM取代SaaS的說明依該貼文（筆者譯） ↩ ↩²

5. 報導：Klarna執行長懷疑其他公司會以AI取代大型CRM（TechCrunch，2025年3月4日，英文）。使用Neo4j等的內部技術基礎，以及懷疑其他公司會跟進的發言，依該文引用（筆者譯） ↩

6. DX報告2 中間彙整（日本經濟產業省 加速數位轉型研究會，2020年12月28日，日文）。協調領域運用SaaS與套裝軟體見本文第22頁，協助轉向內部開發與並肩合作轉移技能見第24至25頁（筆者譯） ↩ ↩²

7. DS-310 政府資訊系統適當使用雲端服務基本方針（日本數位廳，2025年5月27日，日文）。優先使用SaaS及對按帳號計費與高額SaaS的提醒見PDF第16頁，避免廠商鎖定見3.3節，生命週期成本比較見本文第33至34頁（筆者譯） ↩ ↩² ↩³ ↩⁴

8. DX動向2025（日本資訊處理推進機構，2025年6月26日，日文）。取得方式見圖表2-13（非核心、非競爭領域，日本n=1,475），內部化狀況見圖表2-14（日本n=1,500，美國n=509），內部化課題見圖表2-16（正推動內部化的企業n=334）。2024年度調查 ↩ ↩²

9. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（METR，2025年7月10日） ↩

10. We are Changing our Developer Productivity Experiment Design（METR，2026年2月24日）。為參與先前研究之開發者的估計。作者本身註明，選擇效應可能使真正的效果難以看清 ↩

11. State of AI-assisted Software Development 2025（DORA）。2025年9月公布，依全球近5,000名技術人員的回覆 ↩

12. 2025 GenAI Code Security Report（Veracode，2025年7月30日）。由提供資安產品的公司所做的調查 ↩

13. 令和7年通信利用動向調查結果（日本總務省，2026年5月29日，日文）。企業篇圖表4-1、4-3。對象為常用員工100人以上的企業 ↩

14. Gartner Says Adopting a Pace-Layered Application Strategy Can Accelerate Innovation（Gartner，2012年2月14日，MarketScreener轉載）。定義由筆者翻譯 ↩ ↩²

15. 2024年分所得稅定額減稅（給受薪者）（日本國稅廳，日文） ↩

16. DX動向2026（日本資訊處理推進機構，2026年7月30日，日文）。推動DX人才的數量確保狀況見4.2節圖表4-1。2025年度調查 ↩

17. 報導：Curative在兩個月內做出自己的CRM，解約與大型CRM業者年費60萬美元的合約（Business Insider Japan，2026年8月15日，日文）。發言出處據稱為Podcast節目「20VC with Harry Stebbings」。筆者未能確認發言的原始音檔 ↩

18. 雲端服務領域交易實態報告書（日本公平交易委員會，2022年6月28日，日文）。報告書本體第49至50頁、圖3-6。更換相關題目的對象主要為548家IaaS與PaaS使用者 ↩

19. 中小企業雲端服務安全使用指南（日本資訊處理推進機構，2026年6月，日文）。項目13「確保使用結束時的資料」 ↩