大家好，我是TIMEWELL的濱本。
「AI是不是自己做比較好？」
這個問題常被問到，而且不好回答。因為自主開發是手段不是目的，要看是為了什麼而做，答案才會不一樣。
不必全部自己做。但全部丟出去也會出事。問題在於界線畫在哪裡。 這篇文章寫界線的畫法，站在發包方的角度。
先講重點。
- 自主化不是目的。判斷的軸是「變更頻率」與「業務知識有多關鍵」
- 要自己做模型的公司，其實幾乎沒有
- 人不夠是前提。數位轉型人力不足的企業有85.5%
- 要外包的話，拿的是判斷的紀錄，不是只有交付物
- 自主化的本體不是技術力，是把「決定得了」這件事留在公司內部
「自主化」這個詞涵蓋得太廣
先把詞拆開。講「AI的自主化」的時候，其實混了五個不同的層。
1. 自己做模型。 自行訓練基礎模型的層。幾乎沒有企業需要。 費用與人才都差一個位數。
2. 用自家資料調整模型。 追加訓練與微調。這一層也建議先確認用檢索夠不夠。
3. 做應用程式。 配合業務的畫面與處理。現成品不夠用的時候做這一層。
4. 嵌進業務與維運設計。 用在哪個業務的哪個環節、人在哪裡確認、精度掉下來怎麼辦。
5. 決定用法與判斷基準。 什麼交給它、什麼不交，輸出怎麼驗證。
自主化的討論會兜不起來，是因為大家在講的層不一樣。對多數公司來說重要的是第四與第五層，第一、二層根本沒有關係。
而第四與第五層，是本質上外包不太會順的層，因為不懂自家業務就決定不了。
兩條軸就夠
畫界線的基準，我覺得不要弄複雜。我用的是兩條。
軸一：變更頻率高不高。
每週都想調整的東西，放在內側比較好。一次變更要走報價、發包、兩週的體制，改善就會停住。
AI的活用不會一次到位。改指令、換掉參照的資料、調整確認的步驟。這個小往返的次數決定成果。每一次往返都需要外部投入工時，次數就湊不出來。
反過來，一年才碰一次的東西，就算自主化，這個好處也用不到。
軸二：沒有自家業務知識就決定不了嗎。
「這個報價合不合理」「對這位客戶用這種說法可以嗎」「這道工序可不可以跳過」。這些外部的人沒辦法判斷。 而且要把判斷基準教會，本身就很難。
另一方面，「用哪個模型」「伺服器怎麼配置」「認證怎麼做」，不懂業務也決定得了。這些交出去沒有問題。
用這兩條軸分下去，通常會長成這樣。
| 變更多 | 變更少 | |
|---|---|---|
| 需要業務知識 | 自主化（最優先） | 偏自主化，判斷基準留在內部 |
| 不需要業務知識 | 自主化，或找機動性高的外包 | 外包即可 |
左上就是該放在內側的地方。而且這裡講的是業務知識而不是技術力，所以承擔的人多半不在資訊部門，而是離現場比較近的人。
人不夠是前提
自主化的討論一定會冒出「沒有人」。
確實如此。日本IPA在2026年7月公布的調查中，關於推動數位轉型的人力，回答「稍嫌不足」「大幅不足」的企業合計85.5%。對象是國內企業1,799家1。
AI相關人才也是，多數人才類別裡「不足」都佔過半。其中**「兼具現場知識與基礎AI知識、能推動公司內部AI導入的員工」**的短缺仍然偏高1。
這個人才輪廓，正是前面表格左上格要承擔的人。最缺的地方，剛好就是最該放在內側的地方。
所以結論會反過來。正因為人不夠，才不能想著全部自主化。 把有限的人集中在左上，右下交出去。想全部放在內側，最重要的地方就沒有人了。
要外包的話，拿判斷的紀錄
關於交出去的部分，簽約的時候有件事要先定。
要拿的不是交付物，是判斷的紀錄。
交付一個會動的東西是理所當然。問題在後面，為什麼採用這個設計、試過什麼但不採用，這些沒有留下來，下次要變更的時候每一次都要從頭說明。
具體來說，契約裡要放進這些。
- 含設計判斷理由的文件
- 評估過但不採用的選項與理由
- 維運時要看的指標，以及劣化時的處置
- 足以讓另一家公司接手的資訊
第四點很重要。不要做出「只有這家公司才懂」的狀態。 這不是在懷疑對方，而是承辦人會換，公司的方針也會變。
還有一點。公司內部一定要有一個人跟著做。 全部交出去、只收交付物，下一次變更又是一次發包。有一個一起做過的人在，那個人就會變成內部窗口，之後的發包會變小。
自主化的本體不是技術力
這是我最想講的一段。
講到自主化，很多人以為是招工程師、讓公司能自己開發。那也是一部分，但本體在別的地方。
把「決定得了」這件事留在公司內部。 我認為這才是自主化的本體。
- 用在哪個業務，自己決定得了
- 不順利的時候，抓得出原因的方向
- 廠商的提案合不合理，判斷得出來
- 該不該停，判斷得出來
這四件做得到，就算實作放在外面，實質上也是自主化。反過來，就算開發全部自己做，但要用在哪裡是廠商決定的，那就不是自主化。
要做得到判斷，某種程度上只能自己動手。全部外包，就不會有動手的機會。 這才是全部丟出去真正的問題。比起學不到技術，判斷的手感長不出來更痛。
怎麼開始
寫一個實際可行的順序。
1. 把現在交出去的東西盤點一次。 什麼、多少錢、多久變更一次。每次變更都很花時間的，就是自主化的候選。
2. 選一個左上的。 變更多而且需要業務知識的，只選一個。想同時把好幾個拉進內側，通常會失敗。
3. 指定一個負責人，把時間確保下來。 兼職片段時間是推不動的。要明示一週可以用幾小時。
4. 請外包方陪跑。 不是「全部拜託你們」，而是「一起做，讓我們變成做得到」。這會改變契約的寫法，所以要一開始就講。
5. 變成做得到之後，再選下一個。 一個拉進內側並且轉得起來之後，才換下一個。
從概念驗證到上線的判斷，寫在從概念驗證卡關中脫身；讓它在組織裡扎根的部分，寫在生成式AI在公司內扎不了根的原因。
我們在WARP做的就是這種「一起做、讓你們變成做得到」形式的支援。比起做好交付會花更多時間，但下一次的發包會變小，我們認為那才是正確的樣子。
總結
- 自主化不是目的。軸是「變更頻率」與「需不需要業務知識」兩條
- 要自己做模型的公司，其實幾乎沒有
- 人不夠是前提。數位轉型人力不足的企業有85.5%
- 正因為不夠，才不要全部自主化。 把有限的人集中在左上
- 外包要拿的是判斷的紀錄，做到另一家公司接得下來的狀態
- 自主化的本體不是技術力，是把「決定得了」留在公司內部
- 開始的時候只選一個，指定負責人並確保時間
想具體討論內部與外包的界線，歡迎從聯絡我們與我們談。
參考資料
Footnotes
-
國內企業的DX動向與AI活用動向重點（日本IPA 資訊處理推進機構，2026年7月16日，日文）。關於推動數位轉型的人力，回答「稍嫌不足」「大幅不足」合計85.5%，以及AI相關人才中「兼具現場知識與基礎AI知識、能推動公司內部AI導入的員工」短缺比例仍偏高，均出自該資料。回收數1,799家，調查期間2026年4月17日至6月12日 ↩ ↩2
