情報は誰のものか：画期的なCルートへの情報提供
─ところで先ほどMDMSの話が出ましたが、集めた家庭からの電力使用量の情報（データ）は誰のものかという指摘があります。例えば、東電がMDMSに集めたり（一般家庭との契約による）、あるいは東電が第三者（プロバイダ）にそれをインタフェース（IEC 61968）を設けて渡しますね。その際の個人情報の扱いはどうなるのでしょうか。
浅見：これは図4に示すAルート（Ⓐ）、Bルート（Ⓑ）、Cルート（Ⓒ）のうち、Cルートの問題ですが、これについては今後の課題となっています。ただ、Cルートについてはスマートメーター制度検討会で検討された注16ように、スマートメーターの情報は「東電だけではなく、直接サービス事業者が収集するケースも考えられる」という認識になっています。
図4 東京電力が目指す実現スマートメーター網の姿：実現される機能などのイメージ
〔出所 原子力損害賠償支援機構・東京電力プレスリリース 2012年7月12日、添付資料「RFCを踏まえたスマートメーター仕様に関する基本的な考え方」、http://www.tepco.co.jp/cc/press/2012/1206387_1834.html〕
そもそも、スマートメーターから収集した家庭のデータを外部に渡すことについて、東電の最初の仕様では考えられていませんでした。そのような背景から、「東電だけではなく、直接サービス事業者が収集するケースも考えられる」（図4下段の※印）という一文を入れたのは、東電としては画期的なことなのです。これによって、（もちろん需要家の許諾が必要ですが）電力使用量のデータがオープン化されることになり、第三者（プロバイダ）が直接、需要家からデータを取得してサービスを提供できるような仕様になったのです。
需要家のメリットと電気料金ベースのデマンドレスポンス
─スマートメーターの導入によって、需要家（一般家庭）にはメリットがあるのでしょうか。
浅見：あります。
スマートメーターを利用して、東電は需要家から収集した電力使用量のデータを電力料金の算出などに使いますが、今後は現在のような固定的な仕組みではなく、例えば「夜間にたくさん電気を使い昼間にあまり電気を使わない人は安くする」というようなインセンティブを与えることが可能になります。
─それは、需要家にとってはメリットがある柔軟な料金体系になりますね。
浅見：はい。東電はそのような考えを基本に、なるべく1日の電力使用量を平均化することを考えているのです。基本的に電力料金（課金）の計算をする必要がありますので需要家のデータは必要なのですが、その需要家のデータを第三者に渡すかどうかについては、まだ細かなことは決まっていないのです。現在は、東電とサービス業者（プロバイダ）の間でデータを授受するためのプロトコルとして、前述したIEC（国際電気標準会議）の標準規格である「IEC 61968」が決まっているだけです。
一方、東電では、需要家のデータを基にして、需要家側の電力制御（デマンドレスポンス）も行います。このデマンドレスポンスは、おおまかに次のようにに分けられています。
- 時間帯別料金等（TOU、CPP等）の電気料金ベースのもの
- 需給調整契約等のインセンティブ注17ベースのもの
図5と表4に、電気料金ベースのデマンドレスポンスの例を示します。
図5 電気料金ベースのデマンドレスポンスの例（①〜③は事前通知型）
〔出所 経済産業省「電力システム改革の基本方針」平成24（2012）年7月、http://www.meti.go.jp/committee/sougouenergy/sougou/denryoku_system_kaikaku/pdf/report_001_00.pdf〕
表4 電気料金ベースのデマンドレスポンスの略語
〔出所 経済産業省資料をもとに編集部が作成〕
現在、東電では、米国のOpenADRアライアンス注18によって検証が行われているOpenADR仕様注19の動向も参考にし、そのユースケースを作成しながら、仕様を策定していくことになっています。
スマートメーターのセキュリティ対策とクラウドの活用
─スマートメーターがIPネットワークと接続され外部と通信するようになると、セキュリティ（サイバーセキュリティ）の問題が重要になってくると思いますが。
浅見：その通りです。スマートメーターは、電力使用量など一般家庭（ユーザー）のプライバシーに関する情報を扱うため、インターネットと同じように不正アクセス（通信傍受）やなりすまし、情報の漏洩・改ざんなどの脅威に対して、確実なセキュリティ対策を施すことが重要になります。
東電の場合は、最初はオープンではなく、完全に東電独自のクローズド仕様だったため、基本的に安全であるということが前提だったのです。ところがオープン化することになったため、これに関して大きな問題となり、現在、スタディ事項になっています。
─セキュリティとも関係しますが、スマートメーターとクラウドの関係はどう見ていらっしゃいますか？
浅見：そうですね。スマートメーターも小型のコンピュータのようなものですから、ハードウェア（スマートメーター）の制御を行うために組み込まれたソフトウェア（ファームウェア）をリモートから書き換えられるようにする、という仕様が必要になっています。これは、スマートメーターの仕様が絶えず進化し発展するということを前提にしているからです。
─ファームウェアをリモート（遠隔）から書き換える（バージョンアップする）のは、結局、クラウド経由で行うのでしょうか？
浅見：はい。そうなると思います。さらに、サービス内容も進化して変わってきますので、それに応じて必要なセキュリティも含めたパラメータ（設定値）なども当然変わってくるのです。
─なるほど。クラウドでセキュリティを強化するというようなこと（セキュリティのパラメータ）も含まれるのですね。
浅見：そういうことです。このようにサービス内容が進化発展していきますので、最初からつくりつけの（固定的な）スマートメーターというわけにはいかないのです。さらに、スマートメーターの通信用の無線のカード（有線カードも同じ）についても、Aルート（屋外）とBルート（屋内）で別々の仕様となったり、同じ仕様になったりします。そうすると、このような場合にもファームウェアを容易に書き換えられる余地は残しておくことも重要なのです。
─今、発送電分離問題注20が注目されていますが、これらについてはどのように論議されているのでしょうか。
浅見：発送電の分離に関しては、大枠では発電と送配電の分離ということが実際に起こったときに、新規参入業者の障壁にならないようなスマートメーターの仕様にする必要があるという視点から検討されています。
─ありがとうございました。（終わり）
【インプレスSmartGridニューズレター 2012年12月号掲載記事】
▼ 注16
『スマートメーター制度検討会報告書』、平成23（2011）年2月。
▼ 注17
負荷削減（ピーク時に電力消費を少なくすることなど）に対する報酬。
▼ 注18
Open Automated Demand Response（OpenADR）タスクグループ。OpenADRアライアンス（2010年設立）は、本部はカリフォルニア州パロアルト。
▼ 注19
仕様の最新版は、2012年8月に発表されたOpenADR 2.0aプロファイル仕様。
▼ 注20
「発電事業」と「送電事業」を分離し、発電事業に参入しやすくすること。具体的には、現在の10電力会社の発送配一貫体制（発送配：発電・送電・配電）によって運営され、地域独占形態となっている電力会社の「発電事業と送電事業（配電も含む）」を分離し、新規参入企業が、発電事業に参入しやすくし完全自由化すること。現在は、一部自由化にとどまっている。
