South Lodge on Hatley Road, Cockayne Hatley

© Copyright David Howard and licensed for reuse under this Creative Commons Licence.

 

昨年(2024年)10月1日より、NationalGridESO(営利企業集団であるNationalGridグループに属する英国の系統運用者)は英国政府に買収され、公共機関であるNational Energy System Operator(NESO)として新たに発足しましたが、NatrionalGridESOのメーリングリスト登録者には、改めてNESOのメーリングリスト登録案内があったので登録していました。

そうすると、不定期ですが、差出人:Code Administratorから「Code Administrator Update」というタイトルのメールが届くようになりました。内容はGrid Code Development Forum (GCDF)の開催案内とか、Grid Code Review Panel 構成員の選出結果報告やNew Grid Code Proposalなどです。

1月11日に届いた最新のメール内容は、そのような新たなグリッドコードの提案で、「Workgroup Nominations Extended: GC0176 Introduction of Demand Control Rotation Protocol within Operating Code 6 of the Grid Code」となっていました。

GC0176というのは、おそらく176番目のグリッドコード改定の提案書ということだと思われますが、このメールタイトル中のDCRP(Demand Control Rotation Protocol)と、グリッドコードの運用コード6(Operation Code 6)とは何か気になったので、ChatGPTで調べてみました。

※以下、私の部分の文字色=青、ChatGPTの出力部分の文字色=黒にしています。


 

届いたメール本文を要約すると以下の通りです:

GC0176 グリッドコード修正提案

概要:

GC0176提案では、電力供給不足の状況(3〜24時間に及ぶ可能性あり)に対応するために、需要制御ローテーションプロトコル(DCRP) を正式に認識し、グリッドコードの運用コード6(OC6)に変更を加えることを目的としています。このプロトコルの導入により、需要を効率的に管理し、特に冬季におけるリスクを最小限に抑えることが期待されます。

全体概要:

  • 背景: 需要供給の逼迫が懸念される状況、特に冬季に備えるため、DCRPは2022年に導入され、2024年に業界の支持を得て正式化されました。現行のOC6ではDCRPの柔軟な運用が制限されており、配電ネットワーク事業者(DNO)が不利になる可能性があるとされています。
  • 変更の目的: NESO(英国国家エネルギーシステム運用者)が供給不足時に効率的にDCRPを運用指示できるようにし、DNOのインセンティブ義務を免除する。
  • 提案内容:
    • OC6に新たなセクション(OC6.9)を設け、DCRPを独立したツールとして認識。
    • 必要に応じてOC6.5.6の修正または削除。
    • プロトコルの概要をグリッドコード関連文書として新設。
    • 一般条件にこれらの文書を参照する条項を追加。
  • 影響評価:
    • システムの安全性や信頼性向上が期待される。
    • 一部の利用者には短期的な影響があるものの、全体としてリスクが軽減される。

ハイライト:

  • 背景: 需要制御プロトコル(DCRP)は、特定の需要ピーク時に電力供給不足を管理するために作成されました。
  • 主要な変更点: DCRPをOC6の新たなセクション(OC6.9)で明文化し、柔軟性と迅速性を向上。
  • 保護措置: 配電事業者がインセンティブ義務から保護される仕組みを構築。
  • スケジュール:
    • ワークグループ協議: 2025年4月28日~5月19日
    • 実施予定日: 2025年11月1日
  • 期待される効果:
    • 供給不足時の安定性向上。
    • 個々の消費者への影響を最小限に。
    • システム全体の効率的な運用。
  • 法的文書: 法文は業界との協議で作成される予定。
  • ガバナンス: 標準的な手続きに基づき、ワークグループで評価。

提案の主なメリット:

  1. 供給不足時のリスク軽減: システム全体の安定性と効率性を向上。
  2. 柔軟な運用: NESOが迅速に指示可能、個別消費者への影響を軽減。
  3. 適合性の確保: グリッドコード義務への準拠。
  4. 社会的利点: 特に冬季に消費者リスクを削減。

要約文中の 「現行のOC6ではDCRPの柔軟な運用が制限されており、配電ネットワーク事業者(DNO)が不利になる可能性があるとされています。 変更の目的: NESO(英国国家エネルギーシステム運用者)が供給不足時に効率的にDCRPを運用指示できるようにし、DNOのインセンティブ義務を免除する。」 という部分が気になり、更にChatGPTに詳しく説明してもらいました。

現行OC6の条文とその問題点

現行OC6の概要

OC6は、需要を調整するための以下のような手段を提供しています:

  • 短期間の通知または無通知で、需要の削減や調整を指示できる。
  • **需要制御(Demand Control)**を使用して、国家電力系統(National Electricity Transmission System)の安定性を確保する。

現行の制約

DCRP(Demand Control Rotation Protocol)は、需要ピーク時に一時的に需要をローテーションし、全消費者への影響を分散する新たな手法ですが、以下の制約があります:

  1. 柔軟な運用の制限:
    • 現行OC6では、DCRPを特定の条件でしか使用できず、その利用方法が厳しく制限されています。
    • 例: 長時間の供給不足や広範な非常事態を対象とするESEC(Electricity Supply Emergency Code)の下での使用が主に規定されている。
  2. インセンティブ義務:
    • DNO(配電ネットワーク事業者)は、現行OC6の規定に基づき、他の義務(例: エネルギー供給や効率性向上のためのインセンティブ)を優先する必要があり、DCRPの指示に従うことで不利な立場になる可能性があります。
  3. 迅速性の欠如:
    • 現行の仕組みでは、DCRPを短期間で起動する手続きが明確に規定されておらず、NESOが迅速な対応を求める際に運用上の遅れが生じる可能性があります。

指摘される具体的な問題点

  1. 法的保護の欠如:
    • 現行のOC6では、DCRPが発動された際にDNOが他の義務を免除される条文がありません。
    • 例えば、DCRPの指示に従って供給を削減した場合でも、DNOは依然としてインセンティブスキーム(例: 供給義務や効率性向上義務)を守る必要があり、不利になる可能性があります。
  2. 現行OC6の範囲外の運用:
    • OC6は、需要制御を「短期間」かつ「特定の状況」での運用を想定していますが、DCRPはこれよりも柔軟かつ迅速な運用が必要とされる場合に対応できません。
    • 特に、3〜24時間の需要不足のようなケースでは、ESECのような既存の仕組みよりも迅速で限定的な措置が求められますが、OC6では明確に規定されていません。
  3. 文書化の不足:
    • DCRPは現在、明確な独立ツールとして認識されていないため、具体的な運用方法やガイドラインが不十分です。
    • その結果、NESOとDNOの間でのコミュニケーションや運用手順が不明確になるリスクがあります。

提案されている解決策

  • 新たなセクション(OC6.9)の追加:
    • DCRPを正式なツールとして認識し、柔軟性を持たせる。
  • DNOの法的保護を明記:
    • DCRPを起動する際、DNOが他の義務を免除される条項を追加。
  • 手続きの迅速化:
    • DCRPの起動方法やNESOからDNOへの指示手順を明文化。
  • 関連文書の整備:
    • DCRPに関する要約文書を新たに作成し、OC6に関連付ける。

これにより、現行OC6の制約が解消され、供給不足時の運用効率とDNOの負担軽減が図られることが期待されています。

DCRPは、Demand(=負荷)をRotetionalにControl(=順繰りに制御 ➡ 順番に停電)させるProtocol(=手続き)ということで、日本で、かつて3.11の後実施された「輪番停電」と似ているので、尋ねてみましょう。

私:

DCRPとは、輪番停電の手続きと理解してよいですか?

 

ChatGPT-4o:

はい、**Demand Control Rotation Protocol(DCRP)**は、日本で実施される輪番停電(計画停電)と非常に似た仕組みです。ただし、英国特有の電力系統運用やDCRPの設計にはいくつか特徴があるため、以下に比較しながら解説します。

DCRPと日本の輪番停電の比較

1. 共通点

  • 目的:
    • どちらも、電力供給不足が予測される状況で、系統全体の安定性を維持することを目的としています。
    • 電力不足の影響を公平に分散するため、地域ごとに計画的な電力供給の削減を行います。
  • 運用方法:
    • 両者とも、事前にスケジュールや地域ごとの停電計画が作成され、供給不足が見込まれる状況で実行されます。
    • 例えば、数時間ごとに地域ごとに供給を制限し、他の地域には電力を供給する「ローテーション方式」を採用します。
  • 想定される状況:
    • 主に、供給能力(発電所の故障や燃料不足)や送電能力(系統の障害)の不足時に適用されます。
    • 特に、冬季や夏季など、需要が大幅に増加する時期に実施される可能性が高いです。

2. DCRPの特徴(日本の輪番停電との違い)

  • 適用の柔軟性:
    • 日本の輪番停電は、大規模な震災や大災害時など、非常時に適用されることが一般的です。
    • 一方、DCRPは、短期的な供給不足(例: 数時間~1日程度)にも柔軟に対応可能で、英国では通常の電力運用の一環として設計されています。
  • 法的保護と運用体制:
    • DCRPは、配電ネットワーク事業者(DNO)やNESOが主体となって運用されます。
    • また、DNOはこのプロトコルを実行する際、他の法的義務(例: インセンティブスキーム)から免除される仕組みが設けられます。
  • 部分的な公開:
    • DCRPの具体的な内容は、英国の国家安全保障上の理由で詳細が非公開とされていますが、概要文書がグリッドコードに組み込まれる予定です。
    • 一方で、日本の輪番停電は、電力会社が計画の詳細を公開し、住民や企業が事前に準備できるよう配慮されることが一般的です。
  • 期間と影響:
    • 日本の輪番停電は、2011年の東日本大震災のように、長期間かつ広範囲で実施される場合が多いです。
    • DCRPは、3~24時間程度の比較的短期間に限定され、消費者への影響を最小限に抑える設計です。

結論: DCRPは輪番停電に似た仕組み

DCRPは、日本の輪番停電と同様に供給不足時の負荷分散を目的とした仕組みですが、以下の点で異なります:

  1. 短期間かつ柔軟な運用を重視。
  2. 配電ネットワーク事業者への法的保護を伴う運用体制。
  3. 一部非公開のプロトコル設計。

そのため、DCRPを日本の輪番停電の英国版と理解して問題ありませんが、より柔軟で効率的な運用を目指した設計であることが特徴です。

大体理解できましたが、もう一度、ChatGPTにGC0176の提案内容を簡潔に要約し、整理してもらいましょう。

GC0176の提案内容の要約

  1. 背景:
    • 現行のグリッドコード(運用規定OC6)では、電力供給不足時に需要を調整する仕組みが規定されていますが、**Demand Control Rotation Protocol(DCRP)**を柔軟かつ長時間運用するには制約があります。
    • また、DCRP実施時に配電ネットワーク事業者(DNO)が負うインセンティブ義務(効率性向上や供給信頼性確保に関連する義務)が、現行のOC6では免除されていないため、DNOに不利益をもたらす可能性があります。
  2. 提案内容:
    • DCRPの実施におけるインセンティブ義務の免除:
      • 配電ネットワーク事業者(DNO)がDCRPを実施する際、現行のOC6で規定される他の義務(例: エネルギー損失削減や供給信頼性確保)を免除する条項を追加。
    • DCRP実施条件の緩和:
      • DCRPをOC6の新しいセクション(OC6.9)で明文化し、短時間かつ柔軟な運用だけでなく、長時間(3〜24時間)のローテーション停電も可能にする。
    • プロトコルの正式な位置づけ:
      • DCRPを正式な運用ツールとして認識し、プロトコルの概要をグリッドコードの関連文書として新たに作成する。
  3. 目的:
    • 需要不足時の対応能力向上:
      • 特に冬季などの需要ピーク時に、電力供給不足に迅速かつ効果的に対応する。
    • DNOの運用リスク軽減:
      • DCRP実施時の法的保護を明確化し、DNOがインセンティブ義務を理由に不利益を被ることを防ぐ。
  4. 期待される成果:
    • 電力供給不足時のシステム安定性を確保。
    • 消費者への影響を最小限に抑えつつ、需要不足の公平な管理を実現。
    • 長時間の供給不足に対する準備を強化。

結論

GC0176は、現行のOC6で定められているインセンティブ義務の免除DCRP実施条件の緩和を主な内容とする修正提案です。この提案により、DCRPがより柔軟で長時間にわたる運用を可能にし、供給不足時のリスクを軽減することを目指しています。

 

ところで、このGC0176という提案書は、だれがだれに対して提出したものなのでしょうか?ChatGPTに尋ねると:

GC0176提案は、以下の関係者によって提出および審議されています。

提出者

  • 提案者: Frank Kasibante
    • 所属: National Energy System Operator (NESO)(英国国家エネルギーシステム運用者)
    • 連絡先: Frank.Kasibante1@nationalenergyso.com
    • 役割: グリッドコードの変更を提案し、電力供給不足に対応するための効率的な運用手法(DCRP)を正式に導入するために、関係者と連携してプロセスを推進しています。

提出先

  • グリッドコードパネル:
    • 提案は、英国の電力系統の規制および運用の枠組みを管理するグリッドコードパネルに提出されています。
    • パネルは、提案のガバナンス(審議と承認プロセス)のルートを決定し、修正案の適否を評価します。

目的

提案者の意図は、以下を実現するためにガバナンスプロセスを開始することです:

  1. DCRPの正式な導入:
    • ガイドラインを整備し、NESOとDNOの間で効率的な運用を可能にする。
  2. 標準ガバナンス手続き:
    • ワークグループを通じて法的文書や技術仕様の協議を行い、修正案の内容を確定する。

その他の関係者

  • コード管理者: Sarah Williams
    • 所属: NESO
    • 連絡先: sarah.williams@nationalenergyso.com
    • 役割: グリッドコードの修正プロセスを調整し、パネルおよび関係者間の連絡をサポート。
  • 利害関係者:
    • 配電ネットワーク事業者(DNOs)
    • 電力消費者
    • その他の業界関係者(例: 電力供給事業者)

提案は、特に冬季における供給不足への対応を効率化し、英国の電力消費者と業界全体に利益をもたらすことを目的としています。この提案を正式に採用するかどうかを決定するのはグリッドコードパネルであり、その後、必要な修正を行って実施されます。

このグリッドコードパネルというのは何者なのでしょうか?

私:

グリッドコードパネルというのは、Ofgem内の会議体ですか?

 

ChatGPT:

いいえ、グリッドコードパネルは**Ofgem(英国ガス・電力市場庁)**の内部組織ではありませんが、Ofgemの規制枠組みの一部として機能する独立したガバナンス機関です。このパネルは、**英国電力系統の運用に関連する規制や運用コード(グリッドコード)**を管理し、変更提案を審議・承認する役割を担っています。

グリッドコードパネルの概要

  • 設立目的:
    • グリッドコード(電力系統の運用と規制を定める規則)の管理、更新、修正を行う。
    • 電力業界の関係者(配電事業者、送電事業者、発電事業者、消費者代表など)が協力し、業界全体の利益を考慮した意思決定を行う。
  • 役割:
    • 提案された変更(例: GC0176)の評価。
    • 技術的・運用的・経済的な影響を議論し、提案の承認または却下を決定。
    • 関係者間で意見を調整し、合意形成を図る。
  • 構成メンバー:
    • NESO(National Energy System Operator): 提案者や運用の中心的役割を持つ。
    • 配電ネットワーク事業者(DNOs): 提案の影響を受ける主要な利害関係者。
    • 発電事業者: 電力供給に関する技術的視点を提供。
    • 電力消費者の代表: 消費者にとっての影響を考慮。
    • 独立した議長: 中立的な立場から議論を調整。

Ofgemとの関係

  • Ofgemの役割:
    • グリッドコードパネルそのものを運営するわけではありませんが、グリッドコードの全体的なガバナンスを監督します。
    • パネルが推奨した変更(例えばGC0176)を最終的に承認または却下する規制機関としての権限を持ちます。
    • 提案が消費者利益や規制の枠組みに適合しているかを確認します。
  • 独立性:
    • グリッドコードパネルは、業界内の関係者の意見を反映するために独立して運営されています。
    • ただし、最終的な変更内容が規制要件に反しないよう、Ofgemが一定の監視・承認プロセスを担います。

結論

グリッドコードパネルは、業界関係者の協力で運営される独立機関であり、Ofgemの直接的な会議体ではありません。ただし、Ofgemが最終的な承認者として関与し、規制の枠組み内で機能しています。

 

私:

では、グリッドコードパネルは、英国政府のどこに所属するのでしょうか?

 

ChatGPT:

グリッドコードパネルは、英国政府の直接的な所属機関ではなく業界主導で運営される独立したガバナンス機関です。そのため、英国政府のどこか特定の部門に所属しているわけではありません。ただし、英国のエネルギー市場の規制や監督の枠組みにおいて重要な役割を果たし、以下のような機関と密接に関連しています。

グリッドコードパネルの立ち位置

1. 業界主導の独立機関

  • グリッドコードパネルは、英国の電力業界における規制の一環として設置されており、業界関係者(配電事業者、送電事業者、発電事業者、電力システム運用者など)の協力で運営されています。
  • パネル自体は、英国エネルギー市場の参加者間で合意された運用規則を管理・更新するためのフォーラムです。

2. NESO(National Energy System Operator)との関係

  • **NESO(英国国家エネルギーシステム運用者)**が、グリッドコードの主要な管理者および実務的な運営を支えています。
  • NESOは、送電系統の運用を担うNational Grid ESO(Electricity System Operator)の一部であり、英国の電力送電網を効率的かつ安定的に管理する責任を持っています。

政府機関および規制機関との関連

1. Ofgem(英国ガス・電力市場庁)

  • グリッドコードパネルは、直接的にはOfgemに所属していませんが、Ofgemの規制枠組みの中で機能しています。
  • Ofgemは、パネルが提案した変更(例: GC0176)を最終的に承認または却下する権限を持つ規制機関であり、エネルギー市場全体の透明性、公平性、効率性を確保する役割を担います。

2. BEIS(ビジネス・エネルギー・産業戦略省)

  • BEISは、英国政府のエネルギー政策を策定し、エネルギー市場の規制全体を監督する部門です。
  • グリッドコードや関連規則は、BEISが策定したエネルギー政策や国家の電力供給の安全性基準に従っています。
  • BEISは、Ofgemにエネルギー市場の規制を委任し、必要に応じて法的枠組みを改定します。

結論: 関係性の整理

  • グリッドコードパネルは、業界主導で運営される独立機関であり、**National Grid ESO(NESO)**が管理を支援。
  • 直接的な政府の所属はなく、OfgemおよびBEISが規制・監督を行う枠組み内で機能しています。
  • その結果、英国のエネルギー市場の透明性と効率性を高めるための重要なガバナンス機能を果たしています。

このように、グリッドコードパネルは業界内の独立的な意思決定機関でありながら、政府機関との協力関係の中で運営されています。

 

ということで、グリッドコードパネルというのは、日本で言うと、電力・ガス基本政策小委員会や電力システム改革専門委員会などの下で特定の議題について法制化にあたって専門的な見地から検討するワーキンググループのような組織のようです。

 

ついでに、NESOのCode Administratorから届く「Code Administrator Update」というタイトルのメールにあった「Grid Code Development Forum (GCDF)」に関しても、ChatGPTに調べてもらいました。

 

私:

Grid Code Development Forum (GCDF) というのもあるようですが、これとパネルの関係は?

 

ChatGPT:

**Grid Code Development Forum(GCDF)Grid Code Panel(グリッドコードパネル)**は、英国の電力業界におけるグリッドコードの運用や改訂に関連する重要な役割を果たす2つの異なる機関ですが、密接な関係があります。それぞれの役割と両者の関係を以下に整理します。

1. Grid Code Development Forum(GCDF)の役割

目的

  • GCDFは、グリッドコードの変更提案に関する初期段階の議論と検討を行う場として機能します。
  • 主に、業界関係者間での意見交換を促進し、技術的な課題や改善点を洗い出します。

主な活動

  • 提案の初期評価:
    • 新しいグリッドコードの修正案(例: GC0176)について議論し、提案内容を精査。
    • 修正が必要な分野の特定や、提案がどのように業界全体に影響を与えるかを検討します。
  • 協議プロセスの提供:
    • 業界全体の意見を集約し、コード修正提案が効果的で公平なものになるよう支援。
  • 提案の改善:
    • 提案内容が技術的に実現可能かつ業界標準に適合しているかを確認するため、関係者がフィードバックを提供。

構成メンバー

  • 配電ネットワーク事業者(DNO)
  • 発電事業者
  • 送電運用者(National Grid ESO)
  • 電力供給事業者
  • 消費者代表など、幅広い関係者。

2. Grid Code Panel(グリッドコードパネル)の役割

目的

  • グリッドコードの最終的なガバナンスと意思決定を行う機関。
  • GCDFで議論された変更提案を評価し、採用するか否かを決定します。

主な活動

  • 提案の公式審議:
    • GCDFから送られた修正提案を正式に審議し、適切なガバナンスルート(標準的な手続きや迅速な手続きなど)を決定。
  • 決定の実行:
    • 修正案を承認または却下し、必要に応じて修正内容をグリッドコードに統合します。
  • Ofgemへの推奨:
    • 承認された変更案を英国規制機関(Ofgem)に提出し、最終的な承認を得る。

構成メンバー

  • 中立的な議長
  • 業界関係者の代表(DNO、発電事業者、供給事業者など)
  • National Grid ESO
  • 消費者代表など。

3. 両者の関係

GCDFとパネルの関係性

  1. プロセスの流れ:
    • GCDFは、グリッドコード変更提案の初期議論と詳細設計を担当します。
    • GCDFで議論・改善された提案がGrid Code Panelに提出され、パネルで公式に審議されます。
  2. 役割の違い:
    • GCDF:
      • 提案のアイデアを形成し、技術的・業務的な詳細を詰める「コンサルテーションフォーラム」として機能。
      • 提案内容の妥当性や実現可能性について議論を重ねる。
    • Grid Code Panel:
      • 提案の正式な意思決定機関として、最終的に承認または却下を決定。
      • 必要に応じて修正提案をOfgemに提出し、変更の実行を確定させる。
  3. 補完的な役割:
    • GCDFは技術的・業界的な知見を集め、提案内容を整備する。
    • Grid Code Panelは、GCDFの成果を基に意思決定を行うことで、制度の透明性と公平性を確保します。

4. GC0176における関係の例

  • GCDFでは、GC0176(DCRPをOC6に正式に組み込む提案)の初期案が議論され、業界関係者からのフィードバックを反映して提案が改善されました。
  • その後、改訂された提案がGrid Code Panelに送られ、正式な審議と承認プロセスが進められます。

5. 結論

Grid Code Development Forum(GCDF)は、グリッドコードの変更提案を技術的・業界的に検討する非公式な協議フォーラムとして機能し、Grid Code Panel(グリッドコードパネル)はその提案を正式に審議・意思決定する公式なガバナンス機関です。

両者は連携して動作し、提案内容の透明性と実現可能性を確保しながら、英国電力系統の効率的な運用と改善を目指しています。

 


 

以上、本日は英国の輪番停電制度に関するグリッドコード改定案GC0176のご紹介と、それに関連して、DCRPとグリッドコードのOC6について、そして、英国で、このようなグリッドコード改定に関与するNESOやOfgem以外の組織体について、ChatGPTに整理してもらいました。

※なお、今回のChatGPTとの対話内容を、AnthropicのClaude3.5に見せて、ChatGPTの説明内容に間違いがないかどうか確認したところ、以下の指摘がありました。

  • Grid Code Panelは確かに独立した機関ですが、その運営はNESOが担っており、この点についてはより強調されるべきでした。
  • Ofgemの役割については適切に説明されていますが、その最終的な承認権限についてはより強調されるべきでした。
  •  

ただ、Claude3.5はトレーニングデータとして2024年10月時点の情報は持っていないようで、NESO発足の部分に関して、「将来の予定された出来事について述べているようです。この部分は慎重に扱う必要があります。」とのコメントもありました。

また、DCRPに関しても、2024年10月より以前の定義に基づき、「DCRPは既存の緊急時対応計画(Emergency Plans)の一部として位置づけられており、この文脈での説明があれば更に正確でした。」とコメントしています。

※Google Gemini2.0およびCohere Command R+は、修正・補足コメントはありませんでした。

 

 

終わり