試算SaaS的五年總成本｜漲價與日圓貶值會讓損益兩平點怎麼移動

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

收到SaaS的續約報價，看到比去年更高的數字時，應該有不少人會想：「這樣的話，自己做不是比較便宜嗎？」再聽到生成式AI讓開發變快，這個念頭更容易冒出來。但如果順勢把年費和開發費並列，就這樣寫簽呈，多半會判斷錯誤。比較的期間太短，而且自建這一側的費用只算進了一半。

這篇是「停用高價SaaS、改為內製」五篇系列的第三篇。第一篇的判斷基準談的是值不值得考慮，第二篇談的是哪些業務可以自己做。這次針對這些候選，用數字確認「五年要花多少錢」。材料有三個：漲價與日圓貶值的實際走勢、以本公司假設建立的模型案例的五年總成本，以及會移動損益兩平點的變數表。自建這一側，我一定會算進維護、資安與人力的費用。少了這些的試算，只是為了讓簽呈過關的試算。

金額以日圓表示，因為這個模型案例是一家以日圓支付美元計價SaaS的日本企業。以新台幣或美元支付的讀者，匯率那一節的影響方式會不同，但比較的架構可以直接沿用。

SaaS的帳單從兩個方向上漲：美元定價調漲，以及日圓價格重新評估

以日圓支付的海外SaaS，會經由兩條路徑漲價。一是美元定價本身的調整，二是參考匯率重新評估日圓價格。日本的買方兩者都得承受。

日圓價格的調整有多大，從一家海外大型協作軟體廠商的例子就看得出來。2023年4月，這家公司把企業用線上服務的日圓價格調漲15%，地端產品調漲20%。據報導，基本方案的月費以美元計維持在6美元不變，只有日圓價格從650日圓漲到750日圓¹。以美元來看，這是一分錢都沒漲的漲價。2024年4月，它又把企業用軟體與雲端服務一律調漲20%，並表示今後會考量美元匯率的變動，大約一年兩次評估並可能調整當地貨幣的價格²。接著在2026年7月，連美元定價本身也調整了，依方案從不變到最多調漲33%，該公司說明這反映了對AI功能及其支撐基礎設施的持續投資³。

美元定價的調漲不只這一家。一家大型CRM廠商在2025年8月，把主要產品的高階版本平均調漲6%，並說明這反映了AI功能的強化⁴。日本一家大型無程式碼平台也在2024年11月，把輕量方案從每位使用者每月780日圓調為1,000日圓、標準方案從1,500日圓調為1,800日圓，並把最低簽約人數從5人提高到10人⁵。各家提出的理由，都是功能的增加或營運上的投資。我不是要說漲價本身不合理，只是負責編列五年預算的人，必須以會漲價為前提來設定數字。

再看匯率。本公司把日本銀行公布的東京市場美元兌日圓即期匯率月平均逐年做簡單平均，2020年是106.78日圓，2024年是151.50日圓，2026年1至8月是158.78日圓⁶。和2020年相比，日圓約貶值49%。每位使用者每月60美元的SaaS，即使美元定價一次都沒變，每人每月的日圓金額也從6,407日圓增加到9,527日圓。

企業的預算也清楚反映了這個影響。日本資訊系統使用者協會（JUAS）的「企業IT動向調查報告書2026」中，IT預算增加的理由排名第二的是「日圓貶值、人事費上漲、廠商調漲價格等影響」，在2025年度計畫中有46.6%的企業提出⁷。漲價與日圓貶值，已經不是少數公司的問題了。

把年費和開發費並列，會得出錯誤的結論

同一份JUAS調查中，企業期待系統開發內製帶來的效果，第一名是「降低開發成本」（41.3%）⁷。想降低費用的動機很自然，問題出在比較的方式。

「這套SaaS一年付3,456萬日圓，自己做只要3,000萬日圓，一年就回本。」這種算法很常見。好懂，卻會在三個地方讓結論出錯。

第一，開發期間仍要繼續付SaaS的費用。多數SaaS是年約，若未在續約日前一定期間通知，就會自動續約。如果開發要8個月、資料移轉與平行運作要4個月，第一年的SaaS費用就會整筆留著。解約通知期限與資料匯出，會在第四篇解約與移轉的實務詳細說明；在試算上，設定「第一年兩邊都要付」比較實際。

第二，做好之後費用仍會持續。同一份JUAS調查中，2025年度IT預算的分配是「現有業務的維持與營運」75.9%、「業務新措施的推展」24.1%⁷。企業IT預算的四分之三，是用來讓既有的東西持續運作。自建的系統，從下一年起也會進入這四分之三。

第三，SaaS這一側也有看不見的費用，例如管理員的設定作業、使用者的新增與刪除、與其他系統串接的維護。要公平比較，兩邊都得算進內部的工時。

日本政府的指引也持相同立場。日本數位廳的DS-310（政府資訊系統適當使用雲端服務之基本方針）強力建議使用SaaS，但也寫明並非無條件。它指出，當使用者分階段增加等原因，使營運階段的SaaS使用費變得高昂時，應從生命週期成本的觀點審慎評估是否真的能降低成本；若同樣的功能能以其他託管服務實現，就應比較兩種方式並充分評估。對於依帳號數計費的SaaS或高價的SaaS，也提醒要注意帳號數增加造成費用膨脹⁸。本文的試算，就是把這個「比較兩種方式」套進民間企業簽呈的形式。

動手之前，還有一件事要確認，就是沒人在用的授權。一家美國SaaS管理工具廠商在2026年1月公布的調查指出，在其管理的4,000多萬個授權中，以建議的使用水準衡量，平均有36%沒有被使用⁹。這是以美國為主、而且是販售SaaS管理工具的公司的客戶資料，不能直接套用到日本或台灣的企業。即使如此，在決定要不要自建之前，先看一次自家的登入紀錄，是值得的。

用模型案例算出五年總成本（300人、每月60美元、1美元兌160日圓）

以下是根據本公司設定的假設所做的試算，不是任何實際企業的費用。所有數字都是預留給讀者換成自家數字的暫定值。

對象是一家日本企業、300人使用的業務SaaS。美元定價為每位使用者每月60美元，匯率取2026年1至8月的平均158.78日圓，四捨五入為1美元兌160日圓。美元定價設為每年上漲3%。之所以設得比前面提到的調漲幅度（平均6%、最多33%）保守，是因為我不想讓試算偏向自建。自建這一側，假設只重做實際在用的功能，並在第一年底的續約日停用SaaS。

費用項目	繼續使用SaaS	自建系統
授權費	300人×每月60美元×160日圓，第一年3,456萬日圓。美元定價每年上漲3%	第一年付到續約日為止（3,456萬日圓）
內部管理工時	每年100萬日圓	僅第一年100萬日圓（仍在使用SaaS的期間）
初期開發	無	3,000萬日圓（20人月×150萬日圓）
資料移轉與測試	無	400萬日圓
平行運作的內部負擔	無	300萬日圓（主要使用者60人×20個工作天×每天30分鐘×時薪換算5,000日圓）
資安	無	上線前檢測150萬日圓；第二年起檢測、監控與漏洞處理每年200萬日圓
雲端費用	無	每年1.5萬美元（以160日圓計為240萬日圓）；第一年為半年份120萬日圓
維護與修改	無	第二年起為初期開發費的25%（每年750萬日圓）
內部負責人	無	0.5人份的人事成本，每年500萬日圓（第一年起）

依這個前提排出五年，結果如下。單位為萬日圓，四捨五入。

年	繼續使用SaaS	自建系統	累計差額（繼續－自建）
第1年	3,556	8,026	−4,470
第2年	3,660	1,690	−2,500
第3年	3,766	1,690	−424
第4年	3,876	1,690	＋1,762
第5年	3,990	1,690	＋4,062
五年合計	18,848	14,786	＋4,062

五年總成本，繼續使用SaaS約1億8,848萬日圓，自建約1億4,786萬日圓。差額4,062萬日圓，自建比較便宜。不過，自建在累計上追上來是第四年，第三年底時仍落後424萬日圓。第一年要同時付SaaS費用和開發費，自建多出4,470萬日圓。這正是簽呈上很想寫「三年回本」的地方，但在這個前提下，寫不出來。

有些費用我刻意沒放進去，主要是五年中途可能發生的大規模重建或基礎架構更換。若第六年以後條件不變，差距每年會再拉開約2,400萬日圓。不過到那時重建的可能性也會升高，所以我建議簽呈上的試算以五年為限。

自建的費用為什麼要算進維護、資安與人力

在前提表中，我把自建的維護與修改設為初期開發費的25%，偏高，是有理由的。有好幾份調查顯示，生成式AI雖然讓寫程式變快，修正與資安的工作反而可能增加。

美國研究機構METR在2025年7月公布的隨機對照試驗中，16位資深開源開發者處理246件實際的議題，允許使用AI的條件下反而多花了19%的時間。他們事前預期會快24%，結束後仍覺得AI讓他們快了20%¹⁰。METR在2026年2月的更新中報告，以2025年底的AI工具，完成時間的變化為−18%（信賴區間從−38%到＋9%）。作者認為變快的可能性很高，但也指出，不想在沒有AI的情況下工作的開發者拒絕參加等選擇偏誤，讓真正的效果難以看清¹¹。不能說AI沒有讓開發變快，但這個數字也沒有可靠到能把估算砍半。

研究軟體交付組織的DORA計畫在2025年的報告中，根據近5,000份回覆指出，AI的採用與交付速度呈正相關，但與交付穩定性仍呈負相關。90%的受訪者在工作中使用AI，超過80%認為生產力提高了，但也有30%幾乎或完全不信任AI寫的程式碼¹²。開發分析工具公司GitClear分析了2億1,100萬行變更，發現代表重構的「移動」行比例，從2021年的24.8%降到2024年的9.5%。反過來，「複製貼上」的行從8.4%增加到12.3%。寫完不久就被改寫的行，比例也從3.3%升到5.7%¹³。比較自然的解讀是，修正程式的成本並沒有像撰寫的成本那樣下降。

資安也一樣。資安產品公司Veracode讓100多個語言模型撰寫程式碼，結果有45%的樣本未通過資安測試，較新、較大的模型在安全性上也沒有改善¹⁴。這是賣方的調查，需要打點折扣來看。即使如此，也不能因此把上線前的檢測，以及上線後的監控與漏洞處理從預算中拿掉。

最後是人。日本資訊處理推進機構（IPA）的「DX動向2025」詢問334家正在推動內製的日本企業面臨的課題，「人才的確保與培育很困難」以82.3%遙遙領先，另有15.0%回答「和委外相比，成本意識會降低」¹⁵。自建的系統，需要公司內部有人接收需求、排定優先順序、決定要不要修改。這就是我從第一年起就放進0.5人份人事成本的原因。拿掉這一行，試算每年就會對自建寬鬆500萬日圓。

平行運作也是容易被遺忘的一行。IPA的「系統重建成功使用者指南」提醒，新舊系統以相同操作並行的平行運作，會增加使用部門的負擔，必須先確認他們能承受到什麼程度¹⁶。表中的300萬日圓，假設60位主要使用者在一個月內每天花30分鐘重複輸入。人數或期間加倍，這一行也會加倍。

移動損益兩平點的變數

模型案例的結論，只要一個前提改變就可能翻轉。下表一次只變動一個變數，其他維持基準。五年差額是「繼續使用SaaS」減去「自建」的值，正數代表自建比較便宜。

變動的變數	值	五年差額	累計逆轉的年份
基準案例	300人、每月60美元、1美元兌160日圓、每年漲3%	＋4,062萬日圓	第4年
匯率	1美元兌140日圓	＋2,336萬日圓	第4年
匯率	1美元兌180日圓	＋5,789萬日圓	第3年
美元定價漲幅	每年0%	＋2,994萬日圓	第4年
美元定價漲幅	每年10%	＋6,813萬日圓	第3年
使用者人數	150人	−3,384萬日圓	五年內不會逆轉
使用者人數	240人（授權減少兩成）	＋1,084萬日圓	第5年
使用者人數	450人	＋1億1,509萬日圓	第3年
SaaS單價	每月40美元	−902萬日圓	五年內不會逆轉
初期開發費	1,500萬日圓（只花了一半）	＋7,062萬日圓	第3年
初期開發費	4,500萬日圓（膨脹為1.5倍）	＋1,062萬日圓	第5年
維護與修改	每年為初期開發費的40%	＋2,262萬日圓	第4年
開發費與維護同時膨脹	4,500萬日圓、每年40%	−1,638萬日圓	五年內不會逆轉

影響最大的是使用者人數和SaaS單價，也就是SaaS年費本身。使用者只有150人，或單價每月40美元時，在這個條件下五年內自建都追不上。年費小的SaaS，重做也回不了本。聽起來理所當然，但在簽呈的場合，這項確認最常被跳過。

匯率與漲價也有影響。匯率每變動10日圓，五年差額約變動860萬日圓。自建這一側的雲端費用也以美元支付，所以雖然不如SaaS那一側明顯，也會受日圓貶值影響。不過，無論每年漲0%還是10%，在基準條件下，自建五年內勝出的結論都沒有改變。匯率與漲價，大約只會讓逆轉的年份前後移動一年。會翻轉結論的，是使用者人數、單價，以及自建估算的可靠程度。

這個估算的可靠程度，是影響第二大的變數。開發費膨脹為1.5倍、維護每年佔40%時，即使在基準條件下自建也會輸1,638萬日圓。這兩種偏差在系統開發中都不罕見。反過來，若開發費只花一半，差額會擴大到7,062萬日圓。我認為，簽呈上的數字不該只有一個，而應該像這張表一樣以區間呈現，並列基準、樂觀、悲觀三種情境，由經營層判斷悲觀情境是否可以接受。

表中另一行值得一看，是授權減少兩成後的240人。自建在五年的優勢縮小到1,084萬日圓，逆轉也延到第五年。光是在動手前盤點授權，判斷就可能改變。不過要注意，有些大型SaaS的主合約中，有「減少數量續約時，不論先前單價為何都會重新定價」的條款。本想減量續用，結果單價上漲、費用沒降多少的情況也可能發生，所以請先確認合約。這一點也會在第四篇討論。

簽呈上也寫進撤退條件會比較安全。例如「第四個月時開發費若超過預算的六成，就續約SaaS並停止自建」這樣一句話。SaaS的續約日，就成了判斷的期限。把自建或外購當成每次續約都能重新檢視的判斷，而不是一次定生死的賭注，簽呈的分量就會輕一些。

與委外開發的差異

若要和外部夥伴一起執行這份試算，找委外開發還是和FDE（Forward Deployed Engineer，進駐客戶現場、做出可運作軟體的工程師）合作，表中的內容會不一樣。

委外開發中，工時就是營收。初期開發那一行，以及第二年起的維護與修改那一行，都會以付給承包商的款項形式留在帳上五年。因為工作是照規格書做出來，做了才發現不需要的功能，大多也會做完。從發包方來看，表中最不確定的「開發費」與「維護比例」，就交給了對方的工時估算。

本公司的FDE把工時視為投資而不是營收。我們第一天就拿出可運作的原型，一邊確認哪些功能實際在用一邊開發，所以不會做出沒人用的功能。其他公司也能用的共通機制回到本公司的產品，只屬於貴公司的流程則作為貴公司的設定保留。結束的條件，是貴公司的負責人能自己修改系統。用表中的語言來說，目標是把開發費那一行變小，並把維護那一行變成公司內部扛得起的大小。合約怎麼組，寫在成果的衡量與合約的文章。

本公司的FDE能做什麼

本公司的FDE，會從用貴公司的實際數字建立這篇文章的試算開始。我們確認合約的續約日與通知期限、授權數量與實際的登入紀錄、有在用和沒在用的功能，把表中的暫定值一個個換成實際數字。

最不確定的開發費，不只靠紙上估算決定。我們用遮蔽個人資料等敏感資訊後的實際資料做出原型，確認到底需要重做到什麼程度，再把它變成數字。有了原型，「其實這個畫面幾乎沒人用」「只有這張報表不能少」之類的事實會很快浮現，開發費的區間也會跟著縮小。這是先把敏感度分析表中影響第二大的變數縮小的做法。

做好的系統，預設放在貴公司自己的雲端環境，並設計成包括區域在內都能依貴公司的需求選擇。放在自家租戶時的權限與資料所在位置該怎麼想，寫在第五篇設計的文章。資料移轉與平行運作的步驟，也會從SaaS的續約日往回推算，一起規劃。

本公司的實務與限制

有幾件事我想坦白寫出來。

首先，試算結果若是繼續使用SaaS，我們就照實告知。使用者人數少、單價低，或是像會計、薪資那樣受法令約束的複雜業務，在這些條件下，比起自建，繼續使用SaaS，把時間花在盤點授權和續約議價上更划算。哪些業務適合重做，寫在第二篇。

其次，本文的維護比例25%與資安費用，並不是來自本公司五年的實績。以FDE打造的業務應用程式運作五年的實際數據，本公司手上還沒有。所以表中的數字都註明為假設，並把所有前提攤開，讓讀者能用自己的數字重算。

再者，本公司是做自建的業者，我很清楚這個立場容易偏向「自建」的結論。正因如此，我把SaaS的漲價設得保守，並把維護、資安與人力的費用偏重地放在自建這一側。如果仍覺得有哪一行太寬鬆，請把那一行調嚴後重算。若結論因此改變，那就是貴公司的答案。

最後，本公司規模小，能同時進入的現場有限。SaaS續約日越近的案子，越早找我們討論，越能保留做原型與試算的時間。

總結

• SaaS的費用會從兩條路徑上漲，一是美元定價調漲，二是日圓價格的重新評估。美元兌日圓的年平均，從2020年的106.78日圓變為2026年1至8月的158.78日圓（本公司依日本銀行月平均計算）
• 不要把年費和開發費並列，而是比較五年總成本。自建這一側要算進解約前的SaaS費用、資料移轉、平行運作、維護與修改、資安、雲端與內部負責人
• 在本公司假設的模型案例（日本企業、300人、每月60美元、1美元兌160日圓）中，五年下來自建便宜4,062萬日圓，累計在第四年逆轉
• 會翻轉結論的，是使用者人數、單價，以及自建估算的可靠程度。匯率與漲價大約只讓逆轉年份移動一年
• 簽呈上寫出區間與撤退條件，並把SaaS的續約日當作判斷的期限

自建還是續用，不是哪一邊正確的問題，而是哪一個前提崩掉就會翻轉的問題。把表中每一行換成自家的數字，就能看清真正該爭論的地方在哪裡。

想用自家的SaaS試算五年總成本，或想先用原型縮小開發費的區間，歡迎參考FDE的服務頁面，或透過FDE個別諮詢和我們聊聊。系列第四篇會寫解約通知期限、資料匯出與平行運作的安排。

Footnotes

1. 報導企業授權日圓價格調整的文章（＠IT，2023年4月7日，日文）。美元價格維持不變也依該文 ↩

2. 報導企業軟體與雲端服務調漲20%的文章（日經xTECH，2023年12月8日，日文）。約一年兩次的價格評估亦依該文 ↩

3. 報導2026年7月起訂閱價格調整（最多33%）的文章（ITmedia Enterprise，2025年12月19日，日文） ↩

4. 報導主要版本平均調漲6%的文章（ITmedia NEWS，2025年6月18日，日文） ↩

5. 報導日本無程式碼平台價格調整與最低簽約人數變更的文章（週刊ASCII，2024年6月1日，日文） ↩

6. 日本銀行 時間序列統計資料檢索網站。系列「東京市場 美元兌日圓 即期 17時 月平均」（FXERM07）。年度數值為本公司將月平均做簡單平均的計算值，2026年為1至8月平均。2026年9月29日取得 ↩

7. 企業IT動向調查報告書2026（日本資訊系統使用者協會，2026年4月，日文）。IT預算增加理由見2.1節圖表2-1-3，IT預算分配見2.1節（4），內製的期待效果見7.2節圖表7-2-6 ↩ ↩² ↩³

8. DS-310 政府資訊系統適當使用雲端服務之基本方針（日本數位廳，2025年5月27日，日文） ↩

9. 一家美國SaaS管理工具廠商於2026年1月29日公布的年度調查，對象為其管理的4,000多萬個授權與750億美元支出。依本公司方針，不列出公司名稱與連結 ↩

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

11. We are Changing our Developer Productivity Experiment Design（METR，2026年2月24日） ↩

12. State of AI-assisted Software Development 2025（DORA，2025年9月） ↩

13. AI Copilot Code Quality 2025（GitClear，2025年2月）。開發分析工具公司的調查，數值取自該資料的表格「Trends in Code Changes: 2020-2024」 ↩

14. 2025 GenAI Code Security Report（Veracode，2025年7月30日）。資安產品公司的調查 ↩

15. DX動向2025（日本資訊處理推進機構，2025年6月，日文）。圖表2-16（正在推動內製的企業，n=334） ↩

16. 系統重建成功使用者指南 第2版（日本資訊處理推進機構，2018年2月，日文）。表3.9（風險對策範例） ↩