# FAQ：Cyber Blast Radius と分散電源の接続

**Q1. Cyber Blast Radius（CBR）とは何か。**
一件のサイバー侵害が成功したとき、攻撃者が約 30 秒以内に同時に操作できる発電・消費容量（MW）。機器一台、アグリゲータのドメイン、ベンダーのファームウェア系統、全国制御面、系統エリアの単位で測る。NERC CIP-002 が送電側の設備に対して 1,500／3,000 MW で保護等級を決めているのと同じ論理を、配電側の分散電源と機器側に降ろしたもの。

**Q2. 「認証済みの機器なら安全」ではないのか。**
認証は侵害確率を下げる。正規の命令かどうかは見分けるが、正規の命令が系統を壊せる大きさかどうかは見ない。認証済みの機器が 1,000 万台あって同じクラウドに従うなら、そのクラウドの正規の権限を得た攻撃者には 1,000 万台が従う。本稿は認証を否定せず、侵害確率の低減（既定 3 倍）を集中側にも分散側にも同じ倍率で入れている。

**Q3. 結論は「分散すれば安全」か。**
違う。同じ制御面の侵害では分散自律は 35 GW を 117 MW にするが、攻撃面が 100 倍になり、ベンダーのファームウェア系統という A・B 共通の侵害経路がある。ソフトウェアだけの分散自律は合計リスクで集中と変わらなかった。合計を下げたのは、主ファームウェアから独立した監視回路が守る出力の床と、一つのファームウェア系統が遠隔で届く容量の上限である。この上限は集中側にも（サーバー側の集計上限として）置ける。

**Q4. 「ハードウェア強制のエンベロープ」は実在するのか。**
草稿ではそう書いたが、PCS 設計者の指摘で分解した。系統連系保護リレーは遮断しかできない。変化率制限はファームウェアであり、ファームウェア侵害では失われる。ハードウェアで可能なのは、遠隔停止・遠隔 OTA というコマンドクラスの物理的な無効化と、独立した監視 MCU が独立計測で出力の床を守ることである。後者は第二のファームウェアであり、更新経路と署名鍵を分離して初めて意味を持つ。

**Q5. 草稿の「5 桁」はどこへ行ったのか。**
一件の侵害同士（A の全国制御面対 B の 1 ドメイン）の比較で出た数字であり、侵害単位が非対称だった。フリート全体・年次・全経路で数え直すと、制御面経路で 1〜2 桁、合計ではソフトのみの B は A と同程度になった。Red Team の指摘と応答は `review/` に全文を置く。

**Q6. 日本の出力制御は分散自律の先例ではないのか。**
PCS がスケジュールを自分で実行し通信断時は最後のスケジュールで運転する点は、集中でも分散でも共通の機能で差分にならない。指令サーバーはエリア単位の単一制御面で出力ゼロまでの権限を持つ。本稿の分類では H 型であり、最初に CBR を測るべき対象である。

**Q7. 床 30% は出力制御の妨げにならないか。**
なる。だからスケジュール経路と即時命令経路を分ける。出力制御のスケジュールは床の対象外とし、代わりにエリア別の集計上限と機器側の周波数・電圧チェックを課す。即時命令（需給調整・DR）に床と権限上限を課す。スケジュールを書き換える権限の到達容量は即時命令と同じ重さで数える。

**Q8. ベンダーのシェア上限は競争政策と衝突しないか。**
提案は「首位ベンダーのシェア上限」ではなく「一つのファームウェア系統（同一署名鍵・同一 OTA 経路）が遠隔で届く容量の上限」。ベンダーは何 GW 売ってもよく、鍵と配信経路を分割すればよい。国籍中立で数量割当ではない。執行にはファームウェア系統別の設置容量台帳が要り、現在は存在しない。

**Q9. 経済性はどちらが有利か。**
決着しない。床 30% による需給調整の逸失価値は年 ¥120〜740 億、集中の期待停電費用は年 ¥100〜500 億で同じ桁。最も安いのは独立監視回路（年 ¥数億）とサーバー側セーフティモニタ（年 ¥数億〜十数億）で、どちらも合計リスクを 3 分の 1〜5 分の 1 にする。

**Q10. 系統モデルはどれくらい信用できるか。**
単一エリアのスイング方程式で、電圧・潮流・保護協調の連鎖、周波数変換設備経由の融通、揚水遮断は含まない。重大度関数は文献点への当てはめで、x<0.5 では同定されていない。結論は k（重大度の指数）に依存し、k＝1〜4 の範囲で併記している。

**Q11. 一人の攻撃者が日本で何 GW を動かせるのか。**
誰も答えられない。「一つの認証情報の背後に何 MW あるか」「首位ベンダーのクラウドが何 MW に届くか」が集計されていない。本稿が提案するのは、それを申告・登録・公表し、エリアごとの調整力に対する比で上限を置くことである。

**Q12. モデルを自分の数字で試せるか。**
記事内のシミュレータで、台数・容量・到達率・ベンダー構成・ドメイン数・床・侵害確率・系統規模などを変えて A・A+・B を比べられる。Python のモデルと同じ式で、7 ケースで 1e-9 の一致を確認している。コード・データ・図版は CC BY 4.0。

**Q13. I-S3 の製品宣伝ではないのか。**
I-S3 は機器側で命令を検証する基盤（RightOS／RightFlow）を開発しているが、本稿は製品を前提にしない。むしろ本稿の結果は、ソフトウェアだけの制約エンジンは合計リスクを下げないことを示している。I-S3 の実装も本稿の KPI（独立監視回路の有無、OTA 経路の分離）で測られるべきである。