RPKIが守るインターネットの経路――BGPハイジャックとは何か、全世界の70%が署名で保護されるまで

イントロ：BGPハイジャックは「自分ごと」――2026年8月のHetzner事件から

2026年8月28日、HetznerのIPアドレス空間が「本物のTLS証明書」を持った攻撃者に握られた――突破されたのは暗号ではなく、インターネットの経路だった。

クラウドや自宅サーバーを運用していると、「通信はHTTPSで暗号化しているから大丈夫」と考えがちです。しかし2026年8月28日、ドイツのホスティング大手Hetznerに降りかかった事件は、その前提を音もなく崩しました。まさに「BGPハイジャック」と呼ばれる、インターネットの経路を騙す攻撃の実例です。この日、Hetznerが保有する162.55.80.0/24のアドレスブロックが、Hetznerとは無関係の攻撃者から広告され始めたのです。攻撃者は経路の「出どころ」を示すorigin ASとしてHetznerのAS番号を偽装し、他人のアドレス空間を自分のものとして世界に宣言したと、ネットワーク分析企業Kentikが報告しています（Kentik［11］）。

しかもこの攻撃、RPKIによる防御がすでに敷かれていたにもかかわらず成功しています。HetznerはROA（経路起源の署名）を発行していましたが、maxLength /24 を許す緩い設定だったため、攻撃者による/24の偽装広告は「RPKI的にも正しい（valid）」と判定されてしまいました。より具体的な経路が優先されやすいBGPの仕様と相まって、偽装経路が広く伝播したと報告されています（Kentik［11］）。

さらに攻撃者は、VM管理ソフトVirtualizorのドメインについて正規のTLS証明書を取得し、悪意ある更新パッケージを一部のハイパーバイザへ配布したと、Virtualizor自身が公式に告知しています（Virtualizor公式告知［12］）。ブラウザの鍵マークは最後まで本物に見える――誰も暗号を解いていないのに、被害は成立します。TLSが守るのは「データの中身」であって、「そのトラフィックが誰のところへ届くか」ではありません。後者を決めているのがBGPであり、経路が騙されれば暗号化も認証も土台から崩れるのです。

だからこそ「経路を署名で守る」動きは、いま節目を迎えています。2026年9月28日時点で、インターネットで広告される経路の70.3%がRPKIの署名で保護されたと、IPinfoが測定しています。1年前の54.0%から16.4ポイントの急伸です。しかも、invalidと判定された経路は観測上ほとんど伝播しなくなっており、署名はもはや飾りではなく実効性を持ち始めています（IPinfo［1］）。

では、この「70%」は正確に何を測った数字なのか。そして残り30%には、どのようなネットワークが残されているのか。本稿ではBGPハイジャックの仕組みと歴史的事件をたどりながら、RPKIの考え方と、自分のプレフィックスを今日から守る手順までを解説します。

BGPの仕組みと「信頼」という構造的欠陥

インターネットのどの経路を通るかは、ルータ同士が交換する経路情報で決まります。その根幹を担うのがBGP（Border Gateway Protocol）です。この章では、BGPがなぜ「騙される」のかを、その設計思想から紐解きます。

ASとプレフィックス――経路は「広告」で描かれる

インターネットは、AS（Autonomous System／自律システム）と呼ばれる管理単位の集まりです。ASは、ISPや企業、データセンターなど、ひとつの組織が運用するネットワークのまとまりで、世界中で一意なAS番号（ASN）で識別されます。

各ASは「このIPプレフィックス（アドレス範囲）の宛先は自分だ」という経路広告を近隣ASに対して行い、それがASからASへ伝播してインターネット全体の地図が出来上がります。同じ宛先への経路が複数届いたとき、ルータはASパスの長さなどの基準で「ベストパス」を1本選びます。そして決定打になるのがlongest-prefix-match（最長一致）のルールです。同じ宛先空間について /22 と /24 が広告されていれば、転送表に載った有効な経路同士の転送時の選択では、より具体的な /24 が優先されます（経路の受理・伝播そのものは、各ASのローカルポリシーやフィルタにも依存します）。

「何でも信じる」設計と、破綻の理屈

ここにBGP最大の構造的欠陥があります。BGPは1980〜90年代に設計され、「他者が広告した経路を基本的に信頼する」思想で作られています。受信側は、広告主が本当にそのプレフィックスの持ち主かを確認する手段を持ちません。他人のアドレスを自分のものとして広告しても、BGPの世界では何のお咎めもないのです。

この問題への従来型の対抗策がIRR（Internet Routing Registry）です。「どのASがどのプレフィックスを広告してよいか」を登録してフィルタする仕組みですが、IRRは署名のないテキストデータベースで、古い・無効なエントリが多く、フィルタ精度には限界がありました［9］。実際、1997年のAS7007事件では、誤設定が7万を超える経路としてインターネット全体に伝播し、経路フィルタの重要性を示す教訓となりました［9］。

この「無防備な信頼」と「最長一致優先」が組み合わさると、攻撃の理屈は驚くほど単純になります。攻撃者が被害者のプレフィックス（例: /22）より具体的な more-specific（/24）を、被害者のAS番号を騙って広告する（origin偽装）。すると（フィルタされていない範囲の）ルータは「より具体的な経路」に従い、トラフィックを攻撃者へ引き寄せてしまうのです。

flowchart TB
    LEGIT["正規AS<br/>（本来は /22 を広告）"]
    UP["上流ISP"]
    TRANS["トランジット事業者 / IX"]
    ATTK["攻撃AS<br/>（他人の /24 を偽装広告）"]
    ROUTERS["世界中の各ASのルータ"]
    USERS["利用者のトラフィック"]

    LEGIT -- "① /22 を正規広告" --> UP
    UP -- "② 経路を中継" --> TRANS
    ATTK -- "③ /24（more-specific）を偽装広告" --> TRANS
    TRANS -- "④ longest-prefix-match:<br/>/24（more-specific）が優先される" --> ROUTERS
    ROUTERS --> USERS
    LEGIT -.->|"/22 は more-specific に敗れる"| ROUTERS

図の流れを文章で追うとこうなります。まず正規ASが上流ISPへ /22 を広告し、経路はトランジット事業者やIXを経由して世界中に伝わります（①②）。そこへ攻撃ASが /24 のmore-specificを偽装広告します（③）。経路を受け取った各ルータは最長一致のルールに従い、正規の /22 ではなく攻撃者の /24（more-specific）が優先される経路を選んでしまいます（④）。利用者のトラフィックは正規の宛先ではなく攻撃者のネットワークへ流れ込み、偽装広告が取り下げられるまで、騙された経路は世界に広がり続けます。実際、2018年のMyEtherWallet事件では、まさにこのmore-specific＋偽装広告の手口でDNS応答を乗っ取られ、暗号資産が窃取されました［10］。次の章で見る歴史的事件の多くが、この単純な理屈の上に成り立っています。

歴史は繰り返す: 重大BGPハイジャック事件簿

BGPが「他者の広告を基本的に信頼する」設計である以上、事件は特殊な事故ではなく、構造が生む再発です。主要な事件を表1に整理します。

表1: 重大BGPハイジャック事件一覧

※2013年Spamhaus事件など一次出典を確認できなかった報道事例は、本表から除外しています。各事件の時刻・経路・影響の細部は、各行に記した出典の報告に基づきます。「RPKI ROVで防げたか」は代表的な条件を想定した目安です。

YouTube事件（2008年）――誤広告1本が世界を止めた 2008年2月24日、Pakistan Telecom（AS17557）は国内遮断を目的にYouTubeの208.65.153.0/24を自AS由来で広告しました。本来/22の空間を/24で上書きするmore-specificが、上流PCCW Global（AS3491）経由で世界へ伝播し、約2時間、YouTube宛てトラフィックがパキスタンへ流入します。YouTube側は/25広告とASパスprependで対抗し、21:01（UTC）にPCCWがwithdrawして収束しました［3］。

MyEtherWallet事件（2018年）――DNS毒盛と資産窃取 2018年4月24日、eNet（AS10297）がAmazon Route 53のDNSサーバ空間の/24群をmore-specificで偽広告し、Hurricane Electric（AS6939）が転搬。11:05〜12:55（UTC）の約2時間、myetherwallet.comへのDNS応答が毒され、偽ページに誘導されたユーザーから暗号資産が窃取されました［10］。

Hetzner事件（2026年）――「RPKI-valid」のハイジャック 2026年8月28日、Hetznerの162.55.80.0/24が偽装originで出現しました。しかしHetznerのROAが/16にmaxLength /24を許容していたため、この経路はinvalidではなくvalidと判定されます。ROAが許諾した範囲内のmore-specificはROVで防げない――これがmaxLengthの穴です。攻撃者はこの経路で正規TLS証明書を取得し、VM管理ソフトVirtualizorの悪意ある更新を一部のハイパーバイザへ配布したと報告されています［1］［11］。

対比として、2021年10月4日のMeta（Facebook）大規模障害は、保守コマンド誤発行によるBGP広告の自滅的なwithdrawが原因です。経路が「騙された」のではなく「消えた」障害であり、ハイジャックでもRPKIの論点でもない別系統の問題です［16］。

構造的欠陥が歴史を繰り返してきたからこそ、経路に署名と検証を導く次章のRPKIが要請されます。

RPKIとは何か: ROA署名からROV検証まで

前節までに見たとおり、BGPは他者の広告を基本的に信頼する設計のため、経路偽装が成立してきました。これに対する現在の主力ソリューションがRPKI（Resource Public Key Infrastructure、リソース公開鍵基盤）です。IPアドレスやAS番号といったアドレス資源の割り振り・割り当てを証明書で保証するPKIで、RFC 6480により定義されました［4］。JPNICも「アドレス資源の割り振り・割り当てを証明するPKI」と定義し、誤った経路情報（Mis-Origination）の検出に使えると説明しています［18］。

ROA: 「広告してよい」ことへの署名

RPKIの中核となるオブジェクトがROA（Route Origin Authorization）です。「このプレフィックスはこのASが広告（originate）してよい」という許諾に保有者が署名したもので、書式はRFC 6482で定義されています［5］。例:「162.55.0.0/16はAS24940が広告してよい」です。

信頼の起点（Trust Anchor）はIANAの下で5つのRIR（ARIN、RIPE NCC、APNIC、LACNIC、AFRINIC）が運用します。日本ではJPNICがAPNICの下のNIR（National Internet Registry）として、会員向けにJPNIC経由のROA発行手順を提供しています［18］。

ROV: 受信側の検証と拒否

署名されたROAが実際に経路を守るのは受信側です。この検証をROV（Route Origin Validation）と呼びます。受信経路のorigin ASとプレフィックス長を検証済みROAの集合と照合し、3分類します。

• valid: ROAが存在し、origin ASとプレフィックス長が許諾範囲内
• invalid: ROAは存在するが、どのROAの許諾にも合致しない（偽装origin・許可外の長さなど）
• not-found: ROAが存在しない（未署名）

運用上はinvalidを受信ポリシーで拒否（reject）します。not-foundには未署名の正当経路も含まれるため拒否しません。この「存在しないものは拒否しない」設計が、次節の「70%」を考える鍵になります。

なお、暗号検証はルータではなく検証器（validator、rpki-client等）が担い、検証済みROA集合はRTR（RFC 8210）でルータへ配布されるのが標準構成です［6］。

flowchart LR
    A["① RIR/NIRポータルでROA発行<br/>（RFC 6482）"] --> B["② RPKIリポジトリへ公開<br/>（RFC 6480）"]
    B --> C["③ validatorがTrust Anchorから検証<br/>（rpki-client等）"]
    C --> D["④ RTRでルータへ配布<br/>（RFC 8210）"]
    D --> E["⑤ BGP受信時にROA集合と照合<br/>invalidを拒否（ROV）"]

全体の流れを図2に示します。①保有者がRIR/NIRポータル（ARIN Online、MyAPNIC、JPNIC経由など）で「プレフィックス×origin AS×maxLength」を指定しROAを作成します［5］。②ROAはRPKIリポジトリに公開され、世界中のvalidatorから参照できます［4］。③validator（rpki-client等）が5RIRのTrust Anchorから証明書チェーンを辿り、ROAの署名・有効期限・資源範囲を検証します［22］。④検証済みROA集合はRTR（RFC 8210）でルータへ配布されます［6］。⑤ルータはBGP受信時に照合し、invalidを拒否します。①〜③が署名と公開、④〜⑤が検証と拒否の分担です。

最後に重要な限界を先出しします。RPKIが検証するのはあくまで経路の起点（origin）だけで、ASパス全体は無検証です［9］。経路リークや中間ASの偽装は防げません。さらに2026年8月のHetzner事件のように、正規保有者が「許諾した範囲の内側」での偽装広告はROA上validと判定されます［1］［11］。この限界と、経路全体を守るASPA・BGPsecへの道筋は後の節で扱います。

70%の里程碑: 数字の意味と日本の立ち位置

「70%」の定義を正確に。 「世界の経路の70.3%がRPKIで保護された」という数字は、IPinfoが毎年9月28日のスナップショットで測定したものです［1］。公開観測網（RIPE RIS・RouteViews）が観測した広告済みプレフィックス1,614,288個のうち、検証済み認可集合に対して「valid」と判定されたシェアを指します。2025年9月28日の54.0%から1年で+16.4ポイント、観測ポイント2か所以上を要求する厳しめの条件でも71.4%です［1］。重要なのは、この数字が「ROA発行率」でも「ROV実施率」でもない点です。署名された経路のうちvalidな割合であり、署名する側（ROA発行）と検証する側（ROVフィルタ）は別の指標で見る必要があります［1］［27］。

16.4ポイントの伸びの中身。 この急伸の約6割は中国が占めました。中国のIPv4アドレスでvalidになる割合は、2025年9月の3.7%から2026年9月には83.0%へ急騰しています。エジプト・カザフスタンなども急増しました（いずれもIPv4アドレスベース）［1］。プロトコル別では、IPv6（79%）がIPv4（68%）を逆転しました（2025/9/28→2026/9/28、routed prefixesベース）［1］。一方で、署名されていない残り約3割には偏りがあり、未保護アドレスの約60%は米国に集中し、そのうち約4分の1は米国防総省（DoD）保有分です［1］。

70%に「実効性」がある理由。 典型的なvalidプレフィックスは596の観測ポイントで観測されるのに対し、invalidプレフィックスが届くのは平均わずか2か所です［1］。つまり観測データの上では、invalidを拒否するネットワークの拡大と、署名率の上昇が並行して進んでおり、70%という署名率が実際の防御力と結びつき始めていると読むことができます（観測網・時間窓による限界は原資料［1］を参照）。また、RPKI関連のBGPアップデートは全体の1%未満（平時は0.2%未満）で、導入が経路の安定性を損なう兆しは見つかっていません（Internet Society Pulse、2026年8月、11年分のアーカイブ分析）［28］。

日本の立ち位置。 APNIC LabsのI-RoV（観測地点から見てinvalidをフィルタしている度合い＝ROV実施の代理指標）では、日本は2020年5月の約19%から、2026年10月15日時点で約40%へ上昇しています［27］。世界の70.3%（ROA覆盖率）とは測っているものが違うため単純比較はできませんが、検証側の整備がまだ伸びしろを残すことを示しています（APNIC Labsの公開測定値に基づく値です）。事業者の動きとしては、IIJが自社バックボーンでのRPKI取り組みを公開しています［19］。個別ISP（NTT Com/KDDI/SoftBank）やIXの適用状況は、本稿執筆時点で一次確認が取れていないためここでは断定しません。エコシステム全体の監視にはNIST RPKI Monitorなどの公開資源があります［23］。

表2: 70%をめぐる主要指標（数値はすべてIPinfo［1］・APNIC Labs［27］・Internet Society Pulse［28］の各測定・公表値で、計測日付は各欄に併記）

実践編: 自分のプレフィックスでRPKIを有効化する

「暗号署名なんて難しそう」と身構える必要はありません。ROAの発行そのものはRIRポータルでのフォーム入力数項目で、ポータル操作に慣れた運用者なら10分前後の作業が目安です（所要時間は環境により変わります）。ここからは、自AS・自プレフィックスを持つ運用者に向けて、6つのステップで手順を整理します。

1. 資源の確認 —— まず自分のAS番号と、実際に広告しているプレフィックスを棚卸しします。JPNIC・APNIC・ARINなどの会員ポータルで「どの資源を、どのASが広告しているか」を一覧にしておきましょう［18］［20］［21］。上流ISPへの経路広告を委託している場合でも、資源の保有者であればROAの発行は可能です（発行可否・手順は各RIR/NIRの資源登録と委任状況に従います）。
2. ROAの発行 —— RIRポータル（ARINの管理画面［20］やAPNICのMyAPNIC［21］、JPNIC会員はJPNIC経由）で、prefixとorigin ASを指定してROAを作成します。重要なのは、maxLength（最大プレフィックス長）は原則「未設定」にすること。これぞRFC 9319が示す最良現行慣行（BCP）です［7］。2026年8月のHetzner事件では、/16に対してmaxLength /24を許したROAが、ハイジャック経路をRPKI-validのまま通してしまいました。緩いmaxLengthは最大の反面教師です［1］［11］。また、/24単位などに分割して広告している経路は、その分割単位ごとにROAを作成してください。
3. ルータ側のROV設定 —— 自前でBGPを動かすなら、「検証器（rpki-client［22］など）がTrust AnchorからROA集合を検証 → RTRプロトコル（RFC 8210）［6］でルータへ配布 → BGP受信ポリシーでinvalidをreject」という構成が基本型です。Cisco・Juniper・Aristaはネイティブ対応、OSSではFRR・BIRD・OpenBGPDが利用できます。設定コマンドは製品やバージョンで変わるため、具体的なコマンドは各社の最新ドキュメントを必ず参照し、ここでは構成の型だけ押さえておけば十分です。
4. 上流に聞く —— 小規模な運用で自分のルータにROVを入れられない場合も、あきらめる必要はありません。上流ISPがinvalid経路をrejectしているかを確認しましょう。日本全体の適用度は、APNIC LabsのI-RoV測定（2026年10月時点で約40%）が国レベルの代理指標になります［27］。
5. 監視 —— 発行して終わり、ではありません。RIPE RPKI Validator UI［24］・bgp.he.net［26］・IPinfo［2］などで、自プレフィックスがvalidと判定されているかを確認し、「ROAが消えていないか」の定期チェックを仕組み化してください。SEACOMやOrange Marocでは、障害も警告もないままROAが失効し、保護が「静かに」失われる事例が実際に起きています［1］。
6. （発展）ASPAの公開 —— ROAはorigin（広告者）しか保証しません。ASPAは「自分の正規のアップストリームAS」を列挙した署名で、経路のパス自体の検証を可能にする発展的な防御です。MyAPNICは発行に対応済みで［17］、Hetznerも事件後にASPAを公開しました［11］。ROAに慣れたら次の一手として位置づけましょう。

ROA発行は数分、ROV設定と監視の仕組み化を含めても半日程度の作業です。世界の経路の70.3%が署名で守られた今［1］、残りの30%に自分のプレフィックスを置いたままにしないこと。それが今日からできる、もっとも費用対効果の高い防御です。

残る30%と次の一手: ASPA、BGPsec、そして限界

70.3%という数字の裏側には、いまだ署名されていない約3割の経路が残っています［1］。その内実はかなり偏っています。未保護のrouted IPv4空間の約60%が米国に集中し、そのうち約4分の1は米国防総省（DoD）が保有する空間です。監視目的で広告されているとはいえ、それ以外は長尾の中小ISPやホスティング事業者が名を連ねており、「そのうち対応する」では済まされない状況が続いています［1］。

さらに厄介なのは、「署名していても危ない」ケースが存在することです。ROAのmaxLengthを実際の広告より緩く設定している経路は、IPv4で16.2%、IPv6で20.9%に上ります［1］。冒頭で紹介したHetzner事件は、まさにこの穴を突いた手本のような攻撃でした。攻撃者がRPKI-validのまま、無競合で広げられるmore-specific経路のアドレス数を合計すると、約1,800万個分に達します［1］。RFC 9319が「maxLengthは原則未設定」というBCPである理由を、数字がはっきり示しています。

そして、設定を完璧にしても消せない構造的な限界があります。第一に、RPKIが検証するのはorigin（誰が広告したか）だけで、ASパス――経路がどのASをたどるか――は一切検証されません。経路リークや中間ASに起因する問題は防げないのです。第二に、5つのRIRのTrust Anchorへ信頼が集中しており、運用ミスや失効管理の不備がエコシステム全体の品質を左右します。実際、モーリシャスのSEACOMやOrange MarocではROAが静かに消失し、障害も警告もないまま保護だけが失われていました。第三に、測定上の罠もあります。リポジトリ移行などでROA内のリンクが切れても、Trust Anchorからの実検証では有効なまま残るケースがあり、「失敗レコードの数」がそのまま「失われた保護」の量を意味するわけではありません［1］。

この「パスは無検証」という穴を埋めるのが、次世代の経路検証技術です。まず有力視されるのがASPA（Autonomous System Provider Authorization）です。自ASの正規アップストリーム事業者を署名付きで公開し、観測されたASパスと照合することで、リークや偽装経路を検出します。公開AS数は1年で131から3,272へと25倍に拡大しましたが、観測経路のうち公開レコードで実際に検証できているのは約3.5%と、まだ初期段階です。それでもRIPE NCC・ARIN・APNICが2025年秋以降順次対応を始めており、全RIRが2026年末までに対応する予定とされています（APNICの公表情報による。予定は変更され得ます）［1］［17］。設定の考え方や図解はAPNICブログの解説（参考文献［17］）が分かりやすいので、そちらを参照してください。

より本格的なパス署名がBGPsec（RFC 8205）です。ASパスの各ホップがデジタル署名を積み重ねていく方式で、経路全体を暗号的に保証できます。ただし鍵管理や運用負荷が大きく、実装は限定的なままです［8］。

ここまで見てきたように、RPKIは経路セキュリティの土台にはなりましたが、それ単体でBGPの信頼問題を解き切ったわけではありません。「RPKIは必要条件であって、十分条件ではない」――世界の7割が署名で守られた今日だからこそ、この言葉の重みはむしろ増しています。

よくある質問（FAQ）

BGPハイジャックされると、具体的に何が起こる?

宛先に向かうはずのトラフィックが攻撃者のASへ誘導され、盗聴・改ざん・遮断の被害につながります。実例として、2008年のYouTube事件では全世界のトラフィックが約2時間パキスタンへ流れ込み［3］、2018年のMyEtherWallet事件ではDNS応答の毒盛により暗号資産が窃取されました［10］。2026年のVirtualizor事件では、ハイジャック先で正規のTLS証明書を不正取得され、悪意ある更新プログラムが配布されました［11］。

RPKIの設定をしないままだと何がリスク?

偽のorigin広告がそのまま通ってしまい、第三者があなたのIP空間を騙る経路を作れてしまいます。ただし現在はinvalid経路を拒否するネットワークが広がっており、偽広告が伝播できる範囲は大きく狭まっています（invalid経路が観測できるのは代表的な観測網596か所のうち平均2か所程度）［1］。さらに、ROAを整備していない自プレフィックスが、他者による攻撃の「素材」として悪用されるリスクもあります［1］。

ROAのmaxLengthは設定すべき?

原則として設定しません（RFC 9319が定める最良現行慣行です）［7］。2026年のHetzner事件では、/16にmaxLength /24を許したROAが原因で、偽装originの経路がRPKI-validのまま広く伝播してしまいました［11］。分割広告を行う場合は、その分割単位で個別のROAを発行するのが安全です［7］。

個人や小規模事業者でもできることは?

まず上流ISPがinvalid経路を拒否しているか確認しましょう（国レベルの目安にはAPNIC Labs I-RoVが使えます）［27］。自プレフィックスの状態はRIPE Validator UIやIPinfoで監視でき、ROAが静かに消えていないかの定期チェックも重要です［2］［24］。必要であれば、RIRポータル（ARINやMyAPNICなど）から自分でROAを発行できます［20］。

RPKIがあればBGPは安全になる?

origin偽装によるハイジャックの大半は防げますが、経路全体（ASパス）の検証はASPAやBGPsecが発展途上であり、完璧ではありません［1］［8］［17］。また2021年のFacebook大規模障害のように、BGP広告を「引っ込めて」しまったことが原因の障害は別種の問題で、RPKIでは防げません［16］。RPKIは必要条件であって十分条件ではない、と覚えておきましょう。

まとめ：今日からできる3つの行動

ここまで見てきたとおり、BGPハイジャックへの最も基本的な防御は「自分のプレフィックスに正しい署名を置くこと」と「周囲がinvalidを拒否すること」で成り立ちます。特別な機材がなくても、今日から始められることが3つあります。

1. 自分のプレフィックスのRPKI状態を今すぐ確認する — RIPE RPKI Validator UI、IPinfo、bgp.he.netなどで、自分の経路が「valid」と判定されているかを数分で確認できます［2］［24］［26］。
2. ROA未発行ならRIRポータルで発行する — ARINやMyAPNICなどの管理画面から、広告するprefixとorigin ASを指定するだけです。その際、maxLengthは原則「未設定」が現行の最良慣行（RFC 9319）です［20］。すでに発行済みなら「ROAが消えていないか」も確認を。ROA消失は障害を伴わず起きるため、気づけないのが厄介な点です［1］。
3. ROVフィルタの導入または上流ISPへの確認を仕組み化する — 自分でreject invalidを入れられない小規模運用なら、上流ISPがinvalidを拒否しているかを確認し、ROA消失の定期監視を運用タスクとして組み込みます［27］。発展形として、正規のアップストリームを列挙したASPAの公開も始められています［17］。

18年前、YouTubeへの経路は2時間で世界を騙せた。今、世界の7割の経路は署名で自分を証明している。残る3割に、あなたのネットワークが入っていないか――それだけが今日の宿題。

世界の経路の70.3%がRPKI署名で保護され、invalid経路はほぼ伝播しなくなった（2026年9月28日時点）［1］今日やること: ①自プレフィックスのRPKI状態確認 → ②ROA発行（maxLengthは原則なし）→ ③ROVフィルタ・上流ISP確認とROA消失の定期監視RPKIはorigin検証が中心。パス検証のASPA/BGPsecへのキャッチアップも続けよう［17］

関連記事

• ポスト量子暗号とは何か――量子コンピュータ時代に『今』移行する理由 ―― 暗号インフラの「今から始める移行」という共通課題
• AI基盤・デジタル主権・サイバーリスクの事実検証：一次情報から読み解く5つのシグナル

参考文献

一次情報（公式・RFC・事業者・調査者本人）:

1. IPinfo — RPKI Now Protects 70% of Internet Routes: https://ipinfo.io/blog/rpki-protects-70-internet-routes
2. IPinfo RPKIデータ: https://ipinfo.io/data/rpki
3. RIPE NCC — YouTube Hijacking: A RIPE NCC RIS Case Study: https://www.ripe.net/about-us/news/youtube-hijacking-a-ripe-ncc-ris-case-study/
4. RFC 6480（RPKI基盤）: https://www.rfc-editor.org/info/rfc6480
5. RFC 6482（ROA）: https://www.rfc-editor.org/info/rfc6482
6. RFC 8210（RTR）: https://www.rfc-editor.org/info/rfc8210
7. RFC 9319（maxLength BCP）: https://www.rfc-editor.org/rfc/rfc9319.html
8. RFC 8205（BGPsec）: https://www.rfc-editor.org/info/rfc8205
9. Cloudflare — RPKI: The required cryptographic upgrade to BGP routing: https://blog.cloudflare.com/rpki/
10. Cloudflare — BGP leaks and cryptocurrencies: https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/
11. Kentik — Latest BGP Hijack Targets Hosting Software Vendor（Hetzner/Virtualizor事件）: https://www.kentik.com/blog/latest-bgp-hijack-targets-hosting-software-vendor/
12. Virtualizor — Security Incident (BGP Hijacking) 公式告知: https://www.virtualizor.com/blog/security-incident-bgp-hijacking/
13. Princeton CITP — KLAYswap攻撃分析: https://blog.citp.princeton.edu/2022/03/09/attackers-exploit-fundamental-flaw-in-the-webs-security-to-steal-2-million-in-cryptocurrency/
14. Kentik — BGP Hijacks Targeting Cryptocurrency Services: https://www.kentik.com/blog/bgp-hijacks-targeting-cryptocurrency-services/
15. Kentik — When Local Blocks Go Global: The India Telegram BGP Incident: https://www.kentik.com/blog/when-local-blocks-go-global-the-india-telegram-bgp-incident/
16. Meta Engineering — More details about the October 4 outage: https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/
17. APNIC Blog — ASPA at APNIC: Strengthening BGP path validation: https://blog.apnic.net/2026/07/09/aspa-at-apnic-strengthening-bgp-path-validation/
18. JPNIC — リソースPKI (RPKI): https://www.nic.ad.jp/ja/rpki/index.html
19. IIJ Engineers Blog — インターネットをよりロバストに。RPKIはじめます: https://eng-blog.iij.ad.jp/archives/6861/ ほか
20. ARIN — RPKI（ROA管理）: https://www.arin.net/resources/manage/rpki/
21. APNIC — MyAPNIC: https://www.apnic.net/manage-ip/myapnic/
22. rpki-client: https://www.rpki-client.org/
23. NIST RPKI Monitor: https://rpki-monitor.antd.nist.gov/
24. RIPE RPKI Validator UI: https://rpki-validator.ripe.net/ui/

二次情報（測定・集計）:

25. RIPE Labs — RPKI's 2024 year in review: https://labs.ripe.net/author/job_snijders/rpkis-2024-year-in-review/
26. Hurricane Electric RPKI/ASPA report: https://bgp.he.net/report/rpki_and_aspa
27. APNIC Labs I-RoV（日本）: https://stats.labs.apnic.net/rpki/JP
28. Internet Society Pulse — Do RPKI Updates Affect the Internet's Stability?: https://pulse.internetsociety.org/en/blog/2026/08/do-rpki-updates-affect-the-internets-stability/
29. ACM — 同研究論文: https://dl.acm.org/doi/10.1145/3808667
30. Wikipedia — BGP hijacking（事件一覧の集計・個別出典への導線）: https://en.wikipedia.org/wiki/BGP_hijacking