外觀
政府開放資料與 API 治理
本頁整理政府資料開放的制度面與 API 技術面。這題算是我本科最近的一篇，所以自己的判斷寫得比較多。個別機關的實際資料集、系統與內部作業流程不公開。
🔗 接在實習的哪一段：這頁不對應某一天的日誌。實習談資料治理時（07-16、07-17）問的是資料怎麼取得、怎麼用；這頁換一個方向，問資料要對外開放時得先過哪幾關。
先記幾件事
政府開放資料不是「把檔案丟上網」，制度上有一整套要求：開放格式、機器可讀、無償且不可撤回的授權、五項品質要求。API 那邊也有明文規範，走 RESTful、文件要用 OAS 3.0 以上（截至 2026-07，OAS 已更新到 3.2.0），不是 Swagger。授權條款有一條殺傷力很大：顯名聲明沒照格式標，視為自始未取得授權。最後是我查證時最大的收穫，課程講的兩份文件名稱其實都不準，其中一份根本查無此物。
一、開放的底線與五項品質要求
佐證：以《政府資訊公開法》為基礎極大化開放、開放格式與機器可讀、授權方式與品質要求，見 《行政院及所屬各級機關政府資料開放作業原則》。
先講名稱。課程講的是「政府資料開放作業原則」，正確全名是《行政院及所屬各級機關政府資料開放作業原則》，發布機關是行政院。主政機關原本是國發會，111 年組改後移交數位發展部，現行版本是 112.01.19 修正。查證時繞了一圈才確認主政機關已經換人，這種事查不到會寫錯。
核心要求有三層。第一層是開放範圍，以《政府資訊公開法》為基礎極大化開放。第二層是格式，資料必須是開放格式而且機器可讀。第三層是授權，須無償、不限使用目的、不限地區、不限期間，而且不可撤回。
品質那邊列了五項：可直接取得、易於處理、易於理解、確保品質、利於串聯。整套依個資法、資安法辦理。我覺得這五項裡最難的是「利於串聯」。前四項一個機關自己努力就做得到，串聯要求別的機關用同一套識別碼和欄位語意，跨機關的事沒人有權限一次拍板。
二、顯名聲明：沒標等於沒授權
佐證：顯名聲明格式與未依規定標示的效果，見 《政府資料開放授權條款－第 1 版》第 3 條第 2 項。
這條是全篇我覺得最該讓工程師知道的。授權條款 104.07.27 訂定，到現在仍然是第 1 版。第 3 條第 2 項要求依附件的顯名聲明格式標示原資料提供機關，格式是「[提供機關] [年份] [開放資料名稱與版本號]」，再加上條款聲明文字和條款連結。
沒依規定標示的後果不是被要求補標，是視為自始未取得開放資料之授權。等於整段使用從頭到尾都沒有授權基礎。條款也可以轉換為 CC BY 4.0。
從實作角度看，這件事很容易被漏掉。顯名聲明要標的是「原始提供機關」，可是資料進到自己的 pipeline 之後，通常只剩欄位和值，來源機關那一欄早在第一次清洗就被丟掉了。真要做對，我會在 ingest 那一層就把來源機關和資料集版本號當成必要 metadata 存下來，不等到前端要顯示才回頭找。
三、API 的明文要求：RESTful 與 OAS 3.0
佐證：RESTful 語法規則專章與 OAS 3.0 以上的文件格式要求，見 《共通性應用程式介面指引》。
課程講的「政府資料開放平臺共通性 API 指引」這個名稱不存在。實際的文件是數位發展部 111 年 12 月的《共通性應用程式介面指引》，適用範圍比「政府資料開放平臺」廣。
技術要求兩件事。API 以 RESTful 風格為主要基礎，指引裡有「RESTful API 語法規則」專章。說明文件的格式必須是 OAS 3.0 以上，也就是 OpenAPI Specification，而且要提供 JSON 或 YAML 的機器可讀版本。
指引明確寫 OAS 3.0 以上、不是 Swagger，這點在我看來是有意義的區分，不是名詞潔癖。Swagger 2.0 和 OAS 3.0 在 request body、components 複用、多種 content type 的描述上結構差很多，工具鏈也不同。很多機關的舊 API 文件其實停在 Swagger 2.0，升到 3.0 不是改個版本號就好。
四、身分驗證那三種，適用範圍要看清楚
佐證：IP 白名單、API Key 與 HTTP Basic Authentication 的介接身分確認方式，見 《政府資料開放跨平臺介接指引》。
這段我一開始理解錯，寫出來當提醒。三種身分確認方式出自《政府資料開放跨平臺介接指引》（數位發展部，113 年 5 月），適用的是各機關平臺與 data.gov.tw 之間 M2M 詮釋資料介接，不是對民眾提供開放資料 API 的通則。
反過來看更清楚：《共通性應用程式介面指引》明訂，需要身分驗證、會員註冊、API Key 限制而未在 OAS 註明驗證方式的，不屬於 Open API 範圍。所以拿介接指引的那三種方式去套公開資料 API，方向是反的。
| 方式 | 綁定對象 | 實務上的限制 |
|---|---|---|
| IP 白名單 | 來源網路位址 | 對方換網段或走雲端動態 IP 就得改設定 |
| API Key（UUID 形式） | 呼叫方身分 | 金鑰外流等於身分外流，換發流程要先想好 |
| HTTP Basic Authentication | 呼叫方身分，Authorization header 帶 API Key | 須走 HTTPS，否則憑證等同明文 |
三者常疊著用。我的看法是 IP 白名單只適合當外層粗篩，真正認得出「是誰在呼叫」的是 API Key。
五、詮釋資料：有一類欄位機關不能自己改
佐證：欄位分類與各類必填項目，見 《資料集詮釋資料標準指引》。
這份是數位發展部 113 年 5 月的《資料集詮釋資料標準指引》，舊名叫「標準規範」。欄位分四類：必須填寫、建議填寫、選擇性填寫，還有一類是系統產生、機關不可自行修改。第四類的存在，我讀起來是設計得對，資料集識別、上下架狀態這種東西讓各機關自己填，全站就沒有一致性可言。
必填清單相當長：服務分類、主題分類、資料集名稱、描述、授權方式、計費方式、資料提供者、提供機關 OID、聯絡人資訊、更新頻率、上架日期、語系、資料資源欄位、編碼格式、下載網址。檔案型資料另外要填「檔案格式」，API 服務另外要填 API 請求方式、使用手冊網址、OAS 說明文件。
必填欄位裡有一個是「更新頻率」，這欄我認為最容易變成謊言。填「每日」很容易，真的每天更新要有排程、有失敗告警、有人看告警。沒有這三件事，更新頻率就只是一個上架時填過的字串，而外部使用者會拿它來設自己的快取週期。
六、去識別化：查證時踩的坑
佐證：驗證要求及控制措施的訂定機關與相關標準，見 《個人資料去識別化過程驗證要求及控制措施》。
課程提到的去識別化文件名稱查無此物，所以我不引用。實際存在的是經濟部標準檢驗局（BSMI）104 年訂定的《個人資料去識別化過程驗證要求及控制措施》，相關標準是 CNS 29100:2014 隱私權框架，以及 108.09.24 公告的 CNS 29100-2:2019「個人資訊去識別化過程管理系統－要求事項」。
這裡有個誤區值得記下來：CNS 29191:2015 談的是「部分匿名及部分去連結鑑別」，常被誤引為去識別化標準。編號相近、名稱裡也有「去連結」，很容易抓錯。我自己就是先看到 29191 才發現對不上。
制度上還有一句要記住：國發會的立場是，通過驗證機制不等於不適用個資法。從工程角度想也合理，驗證看的是過程和控制措施，管不到之後有人把兩份都去識別化過的資料拿去交叉比對。這種再識別風險由誰持續監控、監控到什麼程度，我目前沒有找到明確答案。
這篇的分層結構
這篇按資料離開機關前要先過的幾道關排列，關卡順序不能對調，愈前面的判斷愈難補救：
text
第 1 層 能不能開
問什麼：這筆資料開得出去嗎、去識別化做到哪裡算夠、依據留不留得下
產出：極大化開放的範圍判斷、去識別化的控制措施與可引用的標準編號
↓ 決定開了，才問用什麼條件開
第 2 層 授權與顯名
問什麼：授權有沒有無償、不限目的、不可撤回、顯名要標成什麼樣
產出：提供機關、年份、資料集名稱與版本號組成的顯名字串與條款連結
↓ 授權條件要一路帶著走，靠的是欄位
第 3 層 詮釋資料
問什麼：哪些欄位必填、哪些機關不能自己改、更新頻率填得出來嗎
產出：必填欄位清單、系統產生欄位的邊界、對外承諾的更新頻率
↓ 欄位定好，才有東西可以做成介面
第 4 層 介面與說明文件
問什麼：走什麼風格、文件用什麼格式、要不要驗身分
產出：RESTful 語法規則下的端點、OAS 3.0 以上的 JSON／YAML 文件
↓ 開出去之後，語意會自己漂移
第 5 層 版本漂移與再識別
問什麼：欄位語意改了誰通知、散出去的副本怎麼處置、再識別風險誰盯
產出：新舊 OAS 的 diff 結果、下架新版的處置紀錄、還沒人認領的監控責任第 1 層：先答能不能開。 制度端要求以《政府資訊公開法》為基礎極大化開放；去識別化這邊實際可引的是經濟部標準檢驗局 104 年訂定的《個人資料去識別化過程驗證要求及控制措施》，相關標準是 CNS 29100:2014 與 108.09.24 公告的 CNS 29100-2:2019。CNS 29191:2015 談的是部分匿名及部分去連結鑑別，編號相近很容易抓錯，我自己就先看到它才發現對不上。還要記著國發會的立場：通過驗證機制不等於不適用個資法，判斷依據還是得留得下來。
第 2 層：用什麼條件開。 授權須無償、不限使用目的、不限地區、不限期間，而且不可撤回。殺傷力最大的是授權條款第 3 條第 2 項的顯名聲明，格式是提供機關、年份、開放資料名稱與版本號，沒依規定標示的後果是視為自始未取得授權。這條很容易被漏掉，資料進到 pipeline 之後只剩欄位和值，來源機關那一欄在第一次清洗就丟了。要做對，我的辦法是在 ingest 那層就把提供機關與版本號當成必要 metadata 存下來。
第 3 層：欄位先講清楚。 詮釋資料標準指引把欄位分成必填、建議填寫、選擇性填寫，以及系統產生、機關不可自行修改四類。第四類設計得對，資料集識別與上下架狀態讓各機關自己填，全站就沒有一致性。必填清單很長，服務分類、授權方式、提供機關 OID、更新頻率、下載網址都在裡面。我最不放心的是更新頻率這欄，填「每日」很容易，真的每天更新要有排程、有失敗告警、有人看告警，而外部使用者會拿這欄設快取週期。
第 4 層：開一個出口。 《共通性應用程式介面指引》要求 API 以 RESTful 風格為主要基礎，說明文件必須是 OAS 3.0 以上，並提供 JSON 或 YAML 的機器可讀版本。指引寫明 OAS 3.0 以上而非 Swagger，這個區分有實質差別：兩者在 request body、components 複用、多種 content type 的描述上結構差很多，工具鏈也不同，很多機關的舊文件還停在 Swagger 2.0。身分驗證那三種方式出自跨平臺介接指引，適用的是機關平臺與 data.gov.tw 之間的 M2M 詮釋資料介接，拿去套對民眾的公開資料 API 方向是反的。
第 5 層：出口之後的漂移。 這層問的是欄位語意改了誰通知、散出去的副本怎麼算、再識別風險誰盯。制度沒有機制強迫欄位語意改變時同步改版本，一個名稱不變、意義悄悄改掉的 API，兩邊都回 200，錯誤會沉默地傳下去。OAS 說明文件在這裡幫得上忙，它是機器可讀的，新舊兩版做 diff 進 CI 是我覺得最值得試的做法。再識別那邊沒有這種工具，驗證管得到過程，管不到有人把兩份都處理過的資料拿去交叉比對。
層與層之間的拉扯在第 2 層與第 5 層之間互相抵銷。授權不可撤回等於承諾使用者可以長期依賴；第 5 層能做的卻只有下架新版，散出去的副本收不回來。兩邊擺在一起，真正的閘門就只剩第 1 層那一次判斷，而那次判斷做在最沒有回饋訊號的時間點。我會把順序調成上架前先把再識別檢查寫成可重跑的腳本，連同判斷依據一起存檔，之後每次改欄位都重跑，讓第 1 層不只發生一次。
整條線換到的是資料能被信任地長期使用，代價是成本全落在開放之前，收益很久以後才看得到。真正的門檻在能不能開、去識別化夠不夠、欄位語意誰定義這三題，而它們都不是一個人查文件能定案的。
往下可以展開的追問：欄位語意悄悄改掉這件事，要到什麼程度才會被下游發現？顯名聲明的來源資訊在 pipeline 的哪一刻最容易被丟掉，補在哪一層成本最低？再識別風險由誰持續監控，制度上為什麼沒有指定負責的角色？
我的反思
整套讀下來，難的一直不是寫 API。RESTful 路由、分頁參數、JSON 回傳結構，這些對資訊背景的人幾乎沒有門檻。門檻在前面那段：這筆資料能不能開、去識別化做到哪裡算夠、欄位語意由誰定義。這幾題都不是我一個人查文件能定案的。
欄位語意的版本管理是我最擔心的一塊。制度要求填「資料資源欄位」，但沒有一個機制強迫欄位語意改變時同步改版本。一個欄位名稱不變、意義悄悄改掉的 API，兩邊都回 200，錯誤會沉默地傳下去。OAS 說明文件在這裡幫得上一點忙，因為它是機器可讀的，理論上可以拿新舊兩版做 diff 進 CI，這是我覺得最值得試的做法。
還有一個矛盾我沒想清楚。授權要求不可撤回，可是資料若事後被發現有再識別風險，機關能做的只有下架新版，已經散出去的副本收不回來。所以真正的閘門只剩上架前那一次判斷，而那次判斷做在最沒有回饋訊號的時間點。
核心結論
政府開放資料的重點在於授權標示做對、格式機器可讀、詮釋資料誠實、去識別化判斷留得下依據。API 只是最後那層出口，出口做得再漂亮，前面四件事沒做，開出去的資料就沒辦法被信任地長期使用。