政府開放資料怎麼用？做成內部工具或 App 前，授權商用、API 斷線與自建費用一次看懂

政府開放資料是政府機關把手上的資料整理成機器讀得懂的格式，免費讓任何人下載或用 API 取用，農產品行情、公車到站、天氣預報、公司登記都在裡面。大部分資料集可以拿來做商業產品，條件是清楚標示來源。真正花時間的地方在後面：日期和品名的寫法各機關不一樣，API 會變慢、會改版、也可能停止提供，原始數字跟使用者想知道的事之間，還差一段翻譯。

這些地方我們自己踩過。我們做過一支 App「今日菜價」，把農業部每天公布的蔬果批發行情，做成逛市場前打開就能看的行情雷達，2026 年 7 月 20 日通過審核上架 App Store。資料是免費的，但從「下載得到」到「使用者打開就能用」，中間卡了好幾關。這篇把那些經驗整理給想做資料型產品或內部儀表板的老闆和 PM：資料去哪找、能不能商用、格式和更新頻率要看什麼、API 斷了怎麼辦，以及自建大概要花多少。

拿我們用的那份資料舉例，政府資料開放平臺上的「農產品交易行情」標示每 1 天更新、採用政府資料開放授權條款、免費，2016 年就上架了。資料很成熟，但同一頁寫了一句「部分市場於週一休市」。做產品時最容易出事的，就是這種寫在角落的小字。

政府開放資料去哪找：常用資料源與取得方式一覽

先查 政府資料開放平臺 data.gov.tw，再去各部會自己的開放平臺。前者是總目錄，一份資料集的授權、更新頻率、格式都寫在同一頁；後者常有更完整的 API 說明和會員機制。下表是做產品時最常碰到的幾個來源。

如果你要的資料只有網頁、沒有開放資料集，就得改用爬蟲或手動整理，難度和法律風險都高一截，爬蟲工具的差別可以看 Scrapling 跟其他 Python 爬蟲框架的比較。能用開放資料就先用開放資料，授權清楚，格式也穩定得多。

怎麼判斷一份資料集夠不夠穩，能拿來做產品

資料集頁面上的「標章」是很好用的第一道篩選。依 政府資料開放優質標章的規定（2023 年修正版），標章分四級：銅標章是連結有效、可以直接下載；銀標章再要求結構化的開放格式；金標章再要求詮釋資料跟實際欄位對得起來，而且照填報的更新頻率即時更新；白金標章則要求超過兩成欄位符合政府資料標準。

要拿來做每天打開的產品，我們建議至少金標章起跳，農產品交易行情就是金標章。另外兩個頁面值得收藏：data.gov.tw 的「預計下架資料集」和「跨平臺介接即時狀態表」，前者讓你提早知道哪份資料要停，後者可以查各平臺介接的即時狀態。

我們做 今日菜價：蔬果行情雷達 時，第一步也是這樣挑資料：每天更新、全國批發市場都有、不用申請金鑰的農產品交易行情。那套 App 最後涵蓋 24 個批發市場、1,018 個品項，選對資料源，後面的功能才有地基。如果你手上也有一份想拿來用的政府資料，可以跟我們聊聊它適不適合做成產品。

政府資料開放授權條款：可以商用，但有三件事要做到

可以商用。政府資料開放授權條款（第1版）寫明使用者可以「不限目的、時間及地域、非專屬、不可撤回、免授權金」利用開放資料，利用方式包括「開發各種產品或服務型態之衍生物」。做成 App 收費、做成內部系統、包進給客戶的報表，都在範圍內。

要做到的三件事是：標示來源、自己檢查資料對不對、準備好資料停掉的那一天。下表把條款裡跟做產品有關的條文，翻成你實際要做的事。

顯名聲明怎麼寫、放哪裡

條款附件給了範本，開頭是「提供機關／單位 [年份] [開放資料釋出名稱與版本號]」，後面接一句「此開放資料依政府資料開放授權條款 (Open Government Data License) 進行公眾釋出，使用者於遵守本條款各項規定之前提下，得利用之。」再附上條款網址。

放的位置要讓使用者找得到。App 通常放在設定頁或「關於」頁，網頁儀表板放頁尾，匯出的 Excel 或 PDF 報表放在最後一頁。資料源有好幾份，就每一份各寫一行。

三種情況要另外確認

• 資料集另有授權：平臺上多數資料集用政府資料開放授權條款，但授權方式是逐份標示的，抓資料前先看那一欄。
• 資料裡有個人資料：條款第五點把「有侵害第三人智慧財產權、隱私權或其他法律上利益之虞」列為機關可以停止提供的理由。就算資料本身已經去識別化，跟你自己的資料比對後能認出個人，也要先停下來評估。
• 要賣給大客戶或放進合約：這篇整理的是條款內容，算不上法律意見。對外收費或客戶要求你保證資料正確時，合約與標示方式建議請法務看過。

資料格式與更新頻率：「每天更新」背後的五個坑

先講結論：更新頻率欄位只告訴你多久更新一次，沒告訴你日期怎麼寫、東西叫什麼名字、哪幾天根本沒有資料。下表是接農產品交易行情時會碰到的五件事，換成交通、氣象或其他資料，類型也差不多。

名字對不起來，是最花時間的一個

在今日菜價裡卡最久的就是名稱。官方品項是「主名-品種」的寫法，同一種菜可以拆成十幾個品種；使用者打的卻是口語名。我們的做法是建一張口語名對照表，先把「高麗菜」轉成官方主名「甘藍」，再去找資料。

比對方式也有講究。如果用「名稱裡有沒有包含這兩個字」去撈，查甘藍會把「球莖甘藍」一起撈進來，這是完全不同的菜，均價就被污染了。改成前綴比對（名稱開頭是甘藍才算）才乾淨，這條規則後來寫成回歸測試釘住，避免之後有人改壞。下面這段 Python 可以直接跑，看兩種比對的差別：

from datetime import date

def roc_to_date(s):
    """民國年字串 '115.06.04' 轉成西元日期"""
    y, m, d = (int(x) for x in s.split("."))
    return date(y + 1911, m, d)

names = ["甘藍-初秋", "甘藍-改良種", "球莖甘藍"]
keyword = "甘藍"

print(roc_to_date("115.06.04"))                  # 2026-06-04
print([n for n in names if keyword in n])         # 包含比對：會撈到球莖甘藍
print([n for n in names if n.startswith(keyword)])  # 前綴比對：只留甘藍

下圖是今日菜價的搜尋畫面：使用者打「高麗菜」，結果對應到官方的「甘藍」，球莖甘藍是另一個獨立品項，不會混進甘藍的均價。

內部系統也一樣。採購部門習慣講的品名、ERP 裡的料號、政府資料的分類代碼，三邊各說各話，第一步通常是先把對照表做出來，而且要有人負責維護。

政府 API 變慢、斷線、改版怎麼辦：別讓 App 直接打官方 API

一句話：在官方 API 和你的產品中間，放一層自己的資料服務。排程去抓官方資料、檢查過再存進自家資料庫，App 和儀表板只讀自己的資料庫。官方那邊慢了、掛了，使用者看到的是「最後更新時間」，看不到空白頁。

這是我們真的吃過虧的地方。農產品行情的官方 API 一次回約 3MB、九千多筆，冷啟動實測要 18 秒；App 端原本設 12 秒逾時，結果在真機上必定失敗，永遠退回內建的範例資料，使用者看到的一直是範例資料。後來把逾時放寬到 30 秒，下載成功後寫進手機的本地快取、設 6 小時有效，之後打開就是秒開。

走勢圖是另一個例子。官方 API 只給四天的滾動視窗，要畫更長的走勢，就得自己每天抓、自己累積。我們另外寫了一支排程服務，每天固定時間抓資料、整理成每個品項每天的加權均價存起來，App 再跟這支服務拿歷史。一般建議的資料流大致如下，其中寫入前的檢查與失敗通知，是我們建議另外加上的保護：

這層服務不用很大。一支排程程式、一個資料庫、一支簡單的 API 就夠了，前端已經有自己後台的話，直接掛在既有後端上也行。想先搞懂 API 在系統之間扮演什麼角色，可以看 API 是什麼這篇白話說明。下表是常見的出狀況方式，以及使用者會看到什麼。

跨好幾個系統、好幾份資料一起串的時候，這層中間服務就會長成正式的整合層，要自己寫還是用 iPaaS，可以參考 API 整合中介層與 iPaaS 的比較。

要金鑰的政府 API：TDX、氣象署這類資料源怎麼接

先講結論：先註冊拿金鑰，金鑰只放在自家後端，不要寫進 App 或網頁前端；token 要快取重用，不要每次呼叫都重新換。

交通部的 TDX 是最典型的例子。它的 官方範例程式說明寫得很清楚：要先註冊會員，完成 Email 驗證、帳號經管理員審核後才能登入，每個帳號最多建 3 組金鑰；呼叫 API 前要先用金鑰換 Access Token，換 token 的端點每個 IP 每分鐘最多 20 次。從 2024 年 4 月 29 日起，每把金鑰的呼叫次數上限依會員訂閱的方案而不同，官方也建議程式端定時換一次 token、其餘時間重複使用。

中央氣象署的氣象資料開放平臺則是會員授權碼制，我們實測不帶授權碼直接呼叫預報 API，回的是 401。這類資料源還是可以商用，只是多了帳號管理和用量估算兩件事。

金鑰放錯位置是最常見的錯誤。寫進 App 安裝檔或網頁前端程式的金鑰，任何人都能拆出來拿去用，額度被別人吃光，你的產品就跟著停擺。金鑰放後端還有一個好處：同一份資料抓一次，所有使用者共用，呼叫次數跟使用者人數脫鉤。

把政府開放資料做成產品：使用者要的是判斷，表格只是原料

我們的判斷是：開放資料做成產品，最難的部分在想清楚「使用者看完要做什麼決定」，技術反而排在後面。把官方的表格原封不動搬上手機，跟打開政府網站沒有兩樣，沒有人會為了它多裝一支 App。

今日菜價一開始的構想也走過冤枉路。最早想做的是通用的「拍照自動記帳」，查下去發現台灣電子發票的生態已經很完整，照片記帳在國外也早就成熟。真正的空白在沒有發票的消費場景，例如傳統市場。但「拍商品比價、告訴你買貴了」這條路也被我們否決：比價資料沒有來源，事後告訴使用者虧了，是在製造後悔。最後定位成行情雷達，只講「今天什麼便宜、該不該買」，範圍縮到蔬果之後，辨識準度也跟著上來。

數字的意思也要講對。官方給的是批發拍賣價，我們做產品時抓的經驗範圍是攤販零售大約是批發價的 1.5 到 2.5 倍，所以絕不能拿批發價對使用者說「攤販賣你貴」。那套 App 的做法是所有價格都標示為批發參考價，建議一律用正面的說法，而且這條規則寫成自動化測試：建議文案只要出現「被坑」「買貴了」這類字眼，測試就會失敗。辨識信心不夠時也不硬猜，改列候選讓使用者自己點，錯的建議比沒有建議更傷信任。

下圖是拍照辨識後的結果頁：今日批發價、近幾天均價、走勢，以及「近期偏高，不急可以再等等」這種使用者看得懂的判斷。

辨識的成本也是產品決策的一部分。雲端影像辨識每張約 $0.0006，使用者每天掃幾次就是一筆持續支出；我們最後改成自己訓練的模型跑在手機上，單次掃描的雲端成本降到 0，還能離線使用。類似的「把運算搬到裝置端」思路，在 瀏覽器端 OCR 的比較裡也看得到。

公司內部可以怎麼用：幾個情境

同樣的方法套到企業內部，重點一樣是「把資料翻成某個部門每天要做的決定」。下表是幾個常見的情境舉例，資料源都是公開的：

做成內部儀表板的話，指標怎麼定、圖表給誰看，可以接著看 BI 數據儀表板怎麼做；資料量大到要另外建資料倉儲時，再參考 中小企業資料倉儲怎麼選。

用政府開放資料自建系統要多少錢：三種規模的費用與時程

先給答案：只抓一兩份資料、做成內部報表的小工具，通常幾週就做得完；要上架給一般人用的 App，光是審核、離線、推播、帳號這些事，就會把範圍和費用拉高好幾倍。下表是常見的三種規模，金額是市場行情參考區間，實際要看功能範圍。

拿我們自己的經驗對照：今日菜價從立項到上架 App Store 約 7 週，那是自有產品，範圍刻意砍得很小，需求也是自己定的。替客戶做的專案多了需求訪談、驗收和修改的往返，時程會比這個長。

App 費用怎麼拆、為什麼同一份需求會報出很大的價差，APP 開發費用比較有完整的拆解；要找外包，報價分級和驗收方式可以看 App 外包指南。框架選擇（Flutter、React Native、原生）可以參考 客製 App 框架怎麼選，今日菜價用的是 React Native 搭配 Expo。準備上架 iOS 的話，iOS App 開發要準備什麼整理了帳號與審核要注意的事。

買現成、找人做、自己寫，怎麼選

• 已經有人做好整理過的服務：先用現成的。很多開放資料已經有民間網站或 App 整理好，內部只是偶爾查一下，就不必自建。
• 資料要跟公司自己的系統、流程接在一起：例如採購價格要對到料號、要自動通知特定部門，現成工具多半做不到，這時候值得做。用 No-Code 內部工具平台先做雛形也是一條路。
• 要對外收費或當成產品賣：資料層、比對規則、測試都要做到穩，找有做過資料型產品的團隊比較省事，發包前可以先看 API 整合外包怎麼找。

動手前的檢查清單：政府開放資料產品化先回答這八題

一句話：這八題答不出來的，開工前先處理。每一題都對應前面講過的坑。

Excel 版多了四題：呼叫上限與方案費用、需要歷史資料時有沒有每天累積、畫面用詞跟資料口徑有沒有一致，以及誰負責每季回頭檢查資料集頁面。最後一題最容易被忘記，資料集改版通常不會另外通知你。

看到這裡，如果你也在想「我們手上這份政府資料，能不能變成內部天天在用的工具」，我們很樂意 聽你聊聊現在的想法。把你想用的資料集連結和想解決的問題丟過來，我們會直接告訴你哪些用現成服務就夠、哪些值得做成系統。