要約

  • 第1段階のAPIは、事業者の公開料金データを標準化して取得しやすくする。消費者個人の料金情報を認可済み第三者へ渡す後続サービスとは役割が異なる。
  • 事業者ごとのTariff IDは、支払方法や地域などで異なる価格データの組み合わせを識別する。APIが一覧を返しても、家庭の契約に合う行を選ぶ作業は残る。

料金表を公開することと、その行を「あなたの契約です」と言い切ることは別の仕事だ。

10月30日、英国のDepartment for Energy Security and Net ZeroはEnergy Act 2023第245条(1)(e)に基づく決定を出した。Tariff Interoperability API Technical Specification version 1.0をRetail Energy Codeに取り込み、Energy Market Data SpecificationとStandards Definition Documentを改める。変更は11月6日に発効する。第1段階の公開Tariff Pricing Data APIは2027年2月18日の開始予定だ。

政府の説明では、第1段階は事業者の公開料金データへの標準化されたアクセスを提供する。消費者が事業者と料金の情報を共有する場面が想定されている。価格のカタログを機械が読めることは、家庭の契約口座へ接続されることではない。2027年11月予定の第2段階では、Consumer Consent Solutionに沿った手続きで、認可された第三者に消費者別の料金情報を共有する。

仕様書では、事業者の一覧取得がGET /tariffs/{supplier_mpid}、選んだ料金の詳細取得がGET /tariff/{supplier_mpid}/{tariff_id}だ。Tariff IDは事業者固有で、価格データのまとまりを区別する。同じ料金名が複数IDに付くことも、料金名とIDが同じこともある。支払方法や地域が違えば別のIDになる例も示されている。画面で読みやすい名前だけでは照合キーにならない。

記録には最終更新日、適用日、販売可能日があり、支払方法、地理グループ、メーター種別、料金種別も条件になりうる。価格を取得できても条件を一つ落とせば、表示は正確そうに見えて別の契約を示す。これは設計上の検証課題である。今回確認した公式資料は仕様と予定を説明しているが、誤照合で損失を受けた家庭の事例は示していない。

必要な検収記録は明快だ。supplier MPID、選んだTariff ID、一致した条件、適用日、選択を支えた消費者情報を残す。候補が複数なら不足情報を尋ねる。理由の見える選択なら利用者が異議を唱えられる。隠れた対応表は、便利さだけで決定権を得てしまう。

APIの公開日は価格取得の試験日でもある。その日には、取得できたかだけでなく、家庭が「なぜこの行なのか」を確かめられるかを見たい。

出典