LASSIC Media らしくメディア
緊急警報の署名必須化｜鍵管理と8.6秒の遅延
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 署名なしを拒否させる案：いまは無効な署名の拒否だけが義務で、署名なしは通ります*1。
- 旧方式では8.6秒の上乗せ：鍵長2048ビットの署名を2回送る場合の試算です*1。
- 地理精度は0.1マイル：はみ出しを許す例外を廃止する案が出ています*1。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関・ベンダー公式ドキュメント）に基づきます。
署名検証を必須にすると、鍵と証明書をどう配るかとどれだけ遅くなるかが毎回問題になります。この2つを実測の数字つきで議論している文書があります。
米国の連邦通信委員会（FCC）が2026年7月31日、緊急警報システム（EAS）と携帯向け緊急警報（WEA）をより回復力があり、柔軟で、役に立つものにするための規則案について意見を求める追加規則案を連邦官報に掲載しました*1。FCC-26-38、PS Docket Nos. 15-91・15-94・25-224で、意見の期限は2026年8月31日でした*1。
署名検証や通知配信を設計する立場に向けて、何を必須化しようとしているのかとその代償として何が挙げられているのかを一次情報から整理します。
目次
いまは「署名がない」メッセージも通る
まず現行の建て付けです*1。
委員会はEASをサイバー攻撃からよりよく守るため、有効な電子署名を含まないCAP（Common Alerting Protocol）のEASメッセージを、EAS参加事業者が拒否することを求めることを提案するとしています*1。
現行との差が明確に書かれています*1。電子署名は現在IPAWSによって求められているが、EAS参加事業者は、無効な電子署名を含むEASメッセージを拒否することだけを求められているとされ、委員会の規則は、電子署名がまったくないEASメッセージをEAS参加事業者が送信することを、いまなお認めていると述べられています*1。
提案の理由も置かれています*1。付随する規則・命令でEAS参加事業者に実装を求めるセキュリティの措置は、悪意ある者がEAS参加事業者の不十分なセキュリティ衛生を悪用することを防ぐには必要だが、我が国の敵対者が偽の警報を発信することを防ぐには十分ではないとされています*1。
実装の負担についての見立ても示されています*1。EAS参加事業者のEAS機器は、署名されたCAP EASメッセージをすでに認証しなければならないため、この要件の遵守は技術的に容易であると考えるとされ、そのうえでこの見方について意見を求めるとされています*1。
発信側の状況も数字で置かれています*1。2018年に委員会が、無効な電子署名を含む警報の拒否をEAS参加事業者に求めたとき、多くの州および地方の警報発信機関がIPAWSやCAPに基づく電子署名をまだ使っていなかったため、送信されるすべてのCAP EAS警報に電子署名を義務づけることは控えたとされています*1。
その状況が変わったとされています*1。しかし現在、IPAWSを使う連邦・州・地方・部族・領域の警報発信機関は2,000を超えると理解しており、IPAWSはそのシステムを通じて配信される警報に電子署名を要求していると述べられています*1。
鍵と証明書をどう配るか
署名検証の実装の中心はここです*1。
仕組みの説明も条文の解説として書かれています*1。電子署名は、署名者のみが知る「秘密鍵」でデータのハッシュ、すなわち「指紋」を暗号化することで機能するとされ、対応する「公開鍵」——通常は公開または半公開で利用可能にされる——は、その「秘密鍵」を用いて暗号化されたメッセージを復号できると説明されています*1。
鍵管理の位置づけも明示されています*1。実効的な鍵管理は、公開鍵と秘密鍵の双方の発行、配布、失効を統制し、発信元と受信者の双方が正しい有効な鍵を持つようにすることで、この処理が適切に機能することを確保するとされています*1。
| 項目 | 規則案の記述 |
|---|---|
| 公開鍵の形 | 公開鍵は「電子証明書」として発行され、通常は公的機関、民間、政府の各主体のために証明書を発行し管理する認証局によって発行されるとされています |
| IPAWSの役割 | IPAWSを通じて送られるCAP警報については、IPAWSが自身を含むすべての警報発信元の公開鍵を保持するとされています。IPAWSは自らが発する警報すべてに電子署名をするため、EAS機器はIPAWSの電子証明書（IPAWSの公開鍵を含む）を取得して、IPAWSが発した警報を認証するとされています |
| 必要な証明書の範囲 | 電子証明書とハッシュによる検証の仕組みが適切に機能するには、EAS機器は、警報を受け取りうるすべてのEAS参加事業者と警報発信元の電子証明書を必要とするとされています |
| 更新の頻度 | 電子証明書は通常1年間有効であるため、絶えず更新されているとされています。そうした証明書の取得にはインターネットへの接続が必要になるとされています |
認定の話も出てきます*1。CSRIC VIの指摘として電子証明書とハッシュによる検証の枠組みを完全に実装するには、EASメッセージを発するあらゆる者が、警報発信のための電子証明書を取得し（かつそのために認定される）必要があり、それには多くのEAS参加事業者自身が含まれうるとされています*1。
そのうえでFEMA IPAWSの電子証明書がこの目的に用いられると仮定すると、FEMAと放送業界の双方が、これらの追加の電子的な資格情報を取得し維持する要件に直面することになるとされています*1。証明書を配る側と受け取る側の両方に運用が生えるという指摘です。
依存関係の懸念も挙げられています*1。CSRIC VIは必要な公開鍵と秘密鍵の証明書を確認するためにインターネットに依存すること、すべての参加者の署名鍵の管理に関わる鍵管理、既存の消費者向け機器との相互運用性についての問題も提起したとされています*1。
遅延の見積りが数字で出ている
ここが設計の判断材料になります*1。
委員会はEASプロトコルを通じて送られる旧来のEAS警報について、EAS参加事業者に認証（すなわち電子署名）を求めることの実行可能性、実効性、費用についても意見を求めるとしています*1。
仕組み上の制約が説明されています*1。CAP警報と違い、旧来のEASは、警報を構成するデータが放送での伝送のために音声に変換されるため、伝えられるデータ量が厳しく制限されているとされ、電子署名に必要なデータを加えると、警報メッセージの伝送が遅れ、ひいては公衆が緊急警報を受け取るのが遅れると述べられています*1。
そして具体的な数字です*1。CSRIC VIによると、鍵長2,048ビットの電子署名を、ヘッダのコード列とともに2回送るとすれば、警報のヘッダのコード列を検証し処理するのに要する時間に8.6秒が加わるとされています*1。
この遅延が響く理由も書かれています*1。IPAWSから受け取るCAP警報と違い、旧来の警報はあるEAS参加事業者から別のEAS参加事業者へ中継されうるため、警報を送るすべての主体が、再放送のために組み直す前に、自らの電子署名を使って警報のハッシュを作る必要があるとされています*1。
結果としてEAS参加事業者が互いを警報の入手元として監視する旧来のEASの「デイジーチェーン」では、警報を認証するのに要する時間が、連鎖の中の各EAS参加事業者ごとに掛け算になっていく可能性が高いとされています*1。
逆に、CAP側の実績も数字で置かれています*1。2023年の全国EAS試験では、CAP EAS警報の電子署名に関連する問題を報告したEAS参加事業者は23社のみで、試験に参加した20,682のEAS参加事業者のうち非常に低い割合であるとされています*1。
リスクの整理もあります*1。CSRIC VIによれば警報の認証には多くの利点がある一方でリスクもあり、それには警報メッセージの配信が遅れること、および有効な警報が無効と判定されて拒否される可能性が高まることが含まれるとされています*1。委員会は2018年に無効な署名のCAP EAS警報の拒否を求めて以来、これらのリスクが現実化したか、有効な警報が誤って遅延または拒否された注目すべき事例があったかを問うています*1。
もうひとつの論点——地理ターゲティングの精度
この追加規則案は、署名以外にも配信範囲を扱っています*1。
問題の所在はこう書かれています*1。意見提出者は、正確な地理ターゲティングが警報システムの目的を達成するうえで「不可欠」であると広く認識しており、その能力の改善を圧倒的に支持しているとされています*1。
実害も引用されています*1。公衆が「自分に関係のないメッセージで溢れさせられている」という指摘があり、人々が自分に関係すると受け取れない警報で溢れさせられると、「緊急性が薄まり」、「信頼が損なわれ」、「警報疲れ」が起きうるとされています*1。その結果人々は自分に向けられたEASやWEAのメッセージを無視し、あるいはWEAの警報を完全に無効にしてしまうかもしれないと述べられています*1。
発信側にも跳ね返るとされています*1。地理ターゲティングが不十分であることの悪影響のために、警報の発信機関が警報システムを使いたがらなくなるという指摘と、その裏返しとして緊急警報がより正確になればなるほど、警報の発信機関がそれを使うようになるという前提が挙げられています*1。
| 項目 | 内容 |
|---|---|
| 現行の水準 | 参加する携帯サービス事業者は、WEAのメッセージを「対象地域の100パーセントに、0.1マイルを超えるはみ出しなく」配信することが求められているとされています |
| 現行の例外 | 「網の設備が指定された対象地域に技術的に合わせられない」場合の例外が認められており、委員会は、旧来の網、旧来の携帯端末、位置情報サービスを無効にしている携帯端末を含む、限定列挙ではない例示を示しているとされています |
| 提案 | 一定の状況で0.1マイルを超えるはみ出しを認めている既存の例外を廃止することが提案されています |
| 許容の考え方 | 警報は危険にある人だけに届くようできるだけ精確であるべき一方、危険な区域に入ってくる移動中の人を捉えるために、控えめなはみ出しは認めるという意見が引かれています |
都市と地方の両方で起きるとされています*1。この問題は、人口が密集した地域でメッセージのはみ出しが起こりうる都市で特に顕著であるという指摘と、地理ターゲティングのはみ出しは地方でも同じくらい厄介になりうるという指摘が並べられています*1。
署名検証を入れる側の読みどころ
自社のシステムに置き換えて読める部分を挙げます。
第一に、「無効を弾く」と「無いものを弾く」は別だという点です。現行規則は無効な署名の拒否だけを求め、署名がまったくないものは通るという状態です*1。自社の検証も、署名がある場合だけ検証する実装になっていないかを確認する観点になります。
第二に、証明書の在庫が必要になることです。検証側は受け取りうるすべての発信元の証明書を持つ必要があり、証明書は通常1年で失効します*1。取得にインターネット接続が必要という指摘もあります*1。オフラインでも動く前提の機器では、ここが設計の分かれ目になります。
第三に、遅延を数字で見積もることです。鍵長2,048ビットの署名を2回送ると8.6秒という試算は*1、帯域が限られた経路では署名がそのまま応答時間に乗ることを示します。低速な回線や音声帯域を使う経路では、鍵長と送信回数が直接コストです。
第四に、中継の段数が掛け算になることです。デイジーチェーンでは各事業者ごとに認証の時間が掛け算になっていくとされています*1。多段のキューやゲートウェイを挟む構成では、1段あたりの検証時間×段数で見る必要があります。
第五に、必須化の代償を先に測ることです。挙げられているリスクは配信の遅れと有効なものが無効と判定される可能性の高まりです*1。委員会自身が2023年の試験では20,682社のうち23社のみが署名関連の問題を報告したという実測を持ち出しています*1。本番相当の試験で失敗率を測ってから必須化するという順番は、そのまま使える型です。
誤解されやすいのは、署名を付ければ守れるという受け取り方です。文書が扱っているのは鍵の発行・配布・失効を統制する鍵管理があってはじめて機能するという点で*1、署名の実装より鍵の運用のほうが重いという整理になります。あわせてこれは追加規則案で、意見の期限は2026年8月31日でした*1。
全文は連邦官報で公開されています*1。適用の可否は事情により変わりますので、確認を挟みながら進めてください。
まとめ：署名必須化で押さえる3つの視点
米国FCCは2026年7月31日、緊急警報システム（EAS）と携帯向け緊急警報（WEA）をより回復力があり、柔軟で、役に立つものにするための追加規則案を連邦官報に掲載しました。FCC-26-38、PS Docket Nos. 15-91・15-94・25-224で、意見の期限は2026年8月31日でした。押さえたい視点は三つです。第一に、必須化の内容。現行規則ではEAS参加事業者は無効な電子署名を含むメッセージを拒否することだけを求められ、電子署名がまったくないメッセージの送信はいまなお認められています。委員会は、有効な電子署名を含まないCAPのEASメッセージを拒否することを求めることを提案し、EAS機器はすでに署名されたCAPメッセージを認証しなければならないため遵守は技術的に容易だと考えるとしています。IPAWSを使う警報発信機関は2,000を超えるとされています。第二に、鍵と証明書の運用。公開鍵は電子証明書として認証局から発行され、IPAWSは自身を含むすべての警報発信元の公開鍵を保持します。検証側のEAS機器は、警報を受け取りうるすべてのEAS参加事業者と警報発信元の電子証明書を必要とし、証明書は通常1年間有効であるため絶えず更新されます。取得にはインターネット接続が必要とされ、鍵管理と既存の消費者向け機器との相互運用性も論点に挙げられています。第三に、代償。旧来のEASは警報のデータが音声に変換されるためデータ量が厳しく制限され、CSRIC VIによると鍵長2,048ビットの電子署名をヘッダのコード列とともに2回送る場合、検証と処理に8.6秒が加わるとされています。中継のデイジーチェーンでは各参加事業者ごとに時間が掛け算になる可能性が高いとされます。一方で2023年の全国EAS試験では、参加した20,682のEAS参加事業者のうち署名に関連する問題を報告したのは23社のみでした。あわせてWEAの地理ターゲティングについて、対象地域の100パーセントへ0.1マイルを超えるはみ出しなく配信するという水準に対し、技術的に合わせられない場合の例外を廃止する案が示されています。
よくある質問
どんな文書ですか。
米国FCCが採択した追加規則案（Further Notice of Proposed Rulemaking）です。緊急警報システム（EAS）と携帯向け緊急警報（WEA）をより回復力があり、柔軟で、役に立つものにするための規則案について意見を求めるもので、2026年7月31日に連邦官報へ掲載されました。FCC-26-38、PS Docket Nos. 15-91・15-94・25-224で、意見の期限は2026年8月31日でした。
いまの規則と何が違うのですか。
現行規則では、EAS参加事業者は無効な電子署名を含むEASメッセージを拒否することだけを求められており、電子署名がまったくないEASメッセージの送信はいまなお認められています。提案は、有効な電子署名を含まないCAPのEASメッセージを拒否することを求めるものです。
検証にはどんな準備が必要ですか。
公開鍵は電子証明書として発行され、IPAWSを通じて送られるCAP警報についてはIPAWSが自身を含むすべての警報発信元の公開鍵を保持します。電子証明書とハッシュによる検証の仕組みが機能するには、EAS機器は警報を受け取りうるすべてのEAS参加事業者と警報発信元の電子証明書を必要とし、証明書は通常1年間有効であるため絶えず更新されます。取得にはインターネットへの接続が必要になるとされています。
どれくらい遅くなるのですか。
旧来のEASについて、CSRIC VIによると、鍵長2,048ビットの電子署名をヘッダのコード列とともに2回送るとすれば、警報のヘッダのコード列を検証し処理するのに要する時間に8.6秒が加わるとされています。旧来の警報は事業者間で中継されうるため、デイジーチェーンでは認証に要する時間が各参加事業者ごとに掛け算になる可能性が高いとされています。
地理ターゲティングについては何が提案されていますか。
参加する携帯サービス事業者はWEAのメッセージを対象地域の100パーセントに0.1マイルを超えるはみ出しなく配信することが求められていますが、網の設備が対象地域に技術的に合わせられない場合の例外が認められています。委員会は、一定の状況で0.1マイルを超えるはみ出しを認めている既存の例外を廃止することを提案しています。
署名検証と鍵運用の設計はLASSICへ
元請（プライムベンダー）として、鍵のローテーション設計から失効の引き方、検証時間の実測、観測モードからの段階移行までご提案します。まずはお気軽にご相談ください。
出典
- *1 参考：Federal Communications Commission「Wireless Emergency Alerts; The Emergency Alert System; Modernization of the Nation’s Alerting Systems」（連邦官報 2026年7月31日）（https://www.federalregister.gov/documents/2026/07/31/2026-15600/wireless-emergency-alerts-the-emergency-alert-system-modernization-of-the-nations-alerting-systems）。FCCがEASとWEAをより回復力があり柔軟で役に立つものにするための規則案について意見を求める追加規則案を採択したこと、2026年7月31日の連邦官報掲載と2026年8月31日の意見期限およびFCC-26-38とPS Docket Nos. 15-91・15-94・25-224、付随する規則命令のセキュリティ措置が敵対者による偽警報の発信を防ぐには十分でないという評価、有効な電子署名を含まないCAP EASメッセージの拒否を求める提案、電子署名の仕組みと実効的な鍵管理が発行と配布と失効を統制する旨、公開鍵が電子証明書として認証局から発行されることとIPAWSが自身を含む全警報発信元の公開鍵を保持しEAS機器がIPAWSの電子証明書を取得して認証すること、現行規則が無効な署名の拒否のみを求め署名のないメッセージの送信をなお認めていること、EAS機器がすでに署名済みCAPメッセージを認証しなければならないため遵守が技術的に容易と考える旨、2018年に無効署名の拒否を求めた際に全CAP EAS警報への署名義務づけを控えた理由と現在IPAWSを使う警報発信機関が2,000を超えること、認証のリスクとして配信の遅れと有効な警報が無効と判定される可能性の高まりが挙げられることと2023年の全国EAS試験で20,682のEAS参加事業者のうち23社のみが署名関連の問題を報告したこと、旧来のEASが音声変換のためデータ量が厳しく制限され鍵長2,048ビットの署名をヘッダのコード列とともに2回送ると検証と処理に8.6秒が加わるというCSRIC VIの試算、旧来の警報が事業者間で中継されるためデイジーチェーンで認証時間が各事業者ごとに掛け算になりうること、電子証明書とハッシュ検証の完全実装には全発信者が警報発信用の電子証明書を取得し認定される必要がありFEMAと放送業界の双方が追加の電子的資格情報の取得と維持に直面すること、証明書確認のためのインターネット依存と鍵管理と既存消費者機器との相互運用性の問題、EAS機器が受け取りうる全EAS参加事業者と警報発信元の電子証明書を必要とし証明書が通常1年有効で絶えず更新されインターネット接続を要すること、正確な地理ターゲティングが不可欠とされ関係のないメッセージの氾濫が緊急性の希薄化と信頼の低下と警報疲れを招きWEAの無効化にもつながりうること、地理ターゲティングの不十分さが発信機関の利用意欲を下げるという指摘、参加CMS事業者が対象地域の100パーセントへ0.1マイルを超えるはみ出しなく配信する義務と技術的に合わせられない場合の例外（旧来の網・旧来の携帯端末・位置情報サービス無効の端末を含む非限定列挙）ならびに当該例外を廃止する提案の一次情報として。確認日は2026年9月7日。（2026年9月確認）
- *2 参考：Federal Communications Commission「Wireless Emergency Alerts; The Emergency Alert System（全文テキスト）」（https://www.federalregister.gov/documents/full_text/text/2026/07/31/2026-15600.txt）。上記追加規則案の連邦官報掲載全文。SUMMARYとDATES、Synopsisの「Securing EAS Through Message Authentication」および「Improving the Accuracy of Alert Geotargeting」の原文の確認に使用。確認日は2026年9月7日。（2026年9月確認）
