Akamai と、エッジセキュリティを可用性リスクに変えた誤検知

概要

• 最も明確な誤検知の記録は、2026 年 4 月 30 日の Akamai Bot Manager インシデントであり、公開ステータスミラーに保存されています。このインシデントでは、誤検知の増加により正規のエンドユーザートラフィックが拒否されました。この記録は可用性の問題を裏付けますが、完全な根本原因の主張には至りません。カスタマーログインなしで入手可能な Akamai の公開詳細では、インシデントの背後にある正確なモデル、ルール、テレメトリ信号、展開プロセス、または顧客数が特定されていません。
• より広範な Akamai の障害記録は、誤検知がプラットフォームリスク分析に含まれるべき理由を示しています。2021 年 6 月 17 日、Akamai は、Prolexic Routed 3.0 で使用されるルーティングテーブル値が意図せず超過し、この DDoS 緩和サービスの顧客に影響を与えたと発表しました。2021 年 7 月 22 日、Akamai は、Secure Edge Content Delivery Network の DNS システムでソフトウェア構成更新がバグを引き起こし、一部の顧客 Web サイトが最大 1 時間利用不能になったと発表しました。
• 説明責任は、拒否アクションを選択した顧客や検出アップデートを提供したベンダーだけに帰するわけではありません。Akamai はエッジ分類エンジン、グローバルディレクトリ、プラットフォーム展開、ステータス公開、製品テレメトリ、緊急修正を管理しています。顧客は、エンドポイントポリシー、ボットスコア閾値、監視から拒否への移行プロセス、オリジンバイパス設計、独立した可観測性、チェックアウト、ログイン、申告、メディア、公共サービスフローなどの事業継続を管理しています。
• この記録は、Akamai のグローバルネットワーク全体が停止した、全顧客が影響を受けた、2026 年の誤検知問題が全顧客にとって短い運用時間枠を超えて継続した、または法的責任が裁定されたという主張を裏付けるものではありません。しかし、ガバナンス上の知見を支持します。インラインセキュリティサービスには、通常、コア可用性システムに要求される変更管理、ロールバック、顧客可視の証拠、フェイルオープンまたはフェイルソフト計画が同じように必要です。

エッジは単なるセキュリティ境界ではありません

Akamai は有用な約束を提供しています。セキュリティと配信をユーザーの近くに配置し、悪質なトラフィックがオリジンに到達する前に吸収し、アプリケーションをより高速かつ安全にします。このアーキテクチャは、大量の Web サービスにまさに適しています。クレデンシャルスタッフィング、スクレイピング、DoS トラフィック、API 悪用、偽アカウント作成に直面する顧客は、小規模なオリジンネットワークから問題を解決できない場合があります。エッジには、顧客が持たないグローバルなテレメトリ、スケール、適用ポイントがあります。

同じ配置が、より困難な説明責任の問題を生み出します。エッジが誤った判断を下すと、その誤りは顧客自身のアプリケーションがリクエストを認識する前に発生します。正規のユーザーがログインページに到達できない可能性があります。支払いコールが、加盟店の不正検知エンジンが評価する前に拒否されるかもしれません。モバイルアプリは、顧客側のバグのように見える一般的なエラーを受け取るかもしれません。銀行、航空会社、小売業者、出版社、学校、公共機関は、エッジの背後で技術的に正常であっても、保護層が疑いを拒否に変換したために利用不能になる可能性があります。

これが、2026 年 4 月の Bot Manager の記録が重要な理由です。IsDown インシデントミラーは、エンドユーザーに対する正規トラフィックの拒否につながる誤検知の増加に関連する、Akamai の Bot Manager の問題を説明するステータステキストを保存しています。同じ記録では、2026 年 4 月 30 日 19:00 UTC の時点で修正が実装され、サービスが通常運用を再開し、監視が継続されていると述べています。StatusGator の Akamai Bot Management ページには、2026 年 4 月 30 日の Bot Manager の誤検知問題や、2026 年 5 月と 6 月の Bot Manager の問題を含む、最近の Bot Management インシデントが個別にリストされています。

これらのソースは、主題を確立するのに十分です。Akamai のボット保護制御が有効なトラフィックを誤分類し、拒否したことです。しかし、完全な技術メカニズムを確立するのには不十分です。ここで確認された公開記録には、影響を受けたホスト名、エンドユーザー数、関係国、各顧客が選択したポリシーアクション、関連するボットスコア範囲、変更された信号またはモデル、展開対象、インシデント後の修正措置記録は示されていません。Akamai ステータスページに示されているように、Akamai のステータスページには、ログイン資格情報を持つ顧客およびパートナー向けに、Akamai コミュニティのサービスインシデント通知でより詳細なマルチカスタマーインシデントの詳細が投稿されているとも記載されています。つまり、公開説明責任にはギャップがあります。運用上最も役立つ証拠は、顧客専用の壁の向こう側にある可能性があります。

このギャップは、イベントを重要でないとはしません。むしろ、エッジセキュリティのパラドックスの明確な例となります。悪質な自動化をブロックすることがビジネス価値である保護層が、誤った人間をブロックすることで停止を引き起こす可能性があります。サイバー攻撃やオリジンの障害、顧客のコード展開、従来のネットワーク断絶なしにそれが起こり得ます。ユーザーの視点からは、サービスは依然として失敗します。

誤検知は、拒否がインラインである場合の製品障害です

監視ダッシュボードでの誤検知は、アナリストの時間を浪費します。インライン拒否経路での誤検知は、収益、旅行、政府サービス、カスタマーサポート、予約スケジューリング、本人確認、メディア消費を中断させる可能性があります。その深刻さは、分類に結びついたアクションに由来します。

Akamai 自身の製品言語がこの区別を裏付けています。Akamai Bot Manager 製品ページでは、エッジでのボット検出、リクエストごとのボットスコア、エンドポイントごとのポリシー、許可、監視、チャレンジ、スロットリング、代替コンテンツの提供、ブロック、拒否、リダイレクトなどの可能なアクションについて説明しています。また、顧客は良好なボットと悪質なボットの処理を設定し、既知のボットカテゴリと許可リストを使用し、クライアント側の行動テレメトリを注入し、リアルタイムの可視性とレポートを使用できると述べています。言い換えれば、Bot Manager は単なる受動的な分析製品ではありません。これは、ライブの Web、モバイル、API トラフィックの前面に配置された意思決定システムです。

Akamai の検出精度ドキュメントは、運用上の問題を明確に定義しています。ボットおよび不正使用のセキュリティ制御を適用した後、顧客は潜在的な誤検知（正規トラフィックが悪質と誤分類される）と、誤不検知（悪質トラフィックが正規と誤分類される）を目にする可能性があります。そのドキュメントは、特定のインシデントを認めるものではありません。Akamai が誤検知を運用調整の予想されるカテゴリとして扱っていることを示すことで、一般的な製品証拠としてより強力です。

製品ドキュメントは、説明責任が「Akamai が行った」または「顧客が設定した」に還元できない理由も説明しています。Akamai の敵対的ボットガイダンスでは、慎重、厳格、積極的な応答セグメントを説明し、最高のボットスコアセグメントは拒否などの強力なアクションで緩和される可能性があると述べています。Akamai の検出手法ドキュメントは、最終的に拒否アクションを設定する前に、望ましくないボットカテゴリを監視するよう助言し、Akamai が検証したボットは異なる方法で処理できると記しています。これらは共有制御です。Akamai は検出、スコアリング、ディレクトリ、チャレンジメカニズム、プラットフォームの実行を提供し、顧客は保護するビジネスエンドポイントのポリシーと閾値を決定します。

この表が重要なのは、「誤検知」というラベルがいくつかの異なる障害を隠す可能性があるからです。分類が間違っているかもしれません。アクションが信頼度に対して厳しすぎるかもしれません。顧客が監視期間をスキップしたかもしれません。ベンダーがディレクトリまたはモデルの更新をあまりにも広範囲に展開したかもしれません。顧客が緊急時の上書き手段を持っていないかもしれません。サポートが、顧客が制御を緩和するかどうかを判断するのに十分な証拠を提供できないかもしれません。真剣なインシデント後レビューでは、これらの可能性を分離する必要があります。

Akamai はすでに保護が障害に変わるのを経験していた

2026 年の誤検知インシデントは、保護またはエッジ制御機能が可用性問題となった唯一の Akamai の記録ではありません。2021 年 6 月 17 日の Prolexic イベントは、影響を受けたサービスが明示的に DDoS 緩和サービスであったため、最も明確な先例です。

Akamai の公開Prolexic DDoS サービス影響アップデートでは、Prolexic Routed 3.0 が UTC 4:20 に停止を開始したと発表されました。Akamai によると、影響は同バージョンの Routed サービスを使用する顧客に限定され、約 500 の顧客の多くは自動的に再ルーティングされ、残りの大多数の顧客はその直後に手動で再ルーティングされ、UTC 8:47 までにサービスが復旧しました。Akamai は、この問題はシステムアップデートやサイバー攻撃によるものではなく、当該サービスで使用されるルーティングテーブル値が意図せず超過したことによるものだと述べています。

教訓は、DDoS 保護が悪いということではありません。Akamai の現在のProlexic 製品ページでは、ルーテッドまたはオンデマンド保護、スクラビング能力、セキュリティオペレーションサポートを通じた DDoS 防御について説明されており、これらは多くの顧客が必要とするまさにその機能です。教訓は、DDoS 保護がデータパス内に存在するということです。ルーテッド緩和サービスを使用する顧客は、インターネットと保護対象アプリケーションの間に意図的にプロバイダーのスクラビングおよびルーティングレイヤーを配置しています。そのレイヤーがピアリングパス、配信パス、またはルーティング状態を失うと、オリジンは準備完了でもユーザートラフィックが到達できなくなります。保護サービスが依存関係になっています。

Cisco ThousandEyes のProlexic Routed 障害分析は、そのイベントに関する独立したテレメトリを提供しています。この障害により、一部の顧客ウェブサイトがさまざまな時間到達不能になり、数分しか影響を受けなかったものもあれば、より長く影響を受けたものもあったと観察されています。また、Prolexic とピアリングしているサービスプロバイダーがサービスへの接続を失い、これらのパスで完全なトラフィック損失が発生したため、ネットワーク障害が顕著に急増したと説明しています。外部テレメトリは Akamai の内部原因を証明できませんが、インターネット向けの症状を裏付けています。到達性がルーテッド保護レイヤーで失敗しました。

オーストラリアとニュージーランドの文脈では、銀行、航空会社、その他のサービスが影響を受けたと報道されたため、このイベントが可視化されましたが、中核の問題はアーキテクチャ上のものです。常にパス内にある防御レイヤーは、重要な可用性レイヤーのように設計および調達されなければなりません。自動再ルーティング、手動再ルーティング、顧客連絡、ルート多様性、ロールバック、ステータス速度、修復証明は二次的な機能ではありません。それらは保護の一部です。

Prolexic のイベントは、誤検知との有用な比較も提供します。両方のケースで、セキュリティサービスが正規のサービス結果を拒否しています。Prolexic では、ルーティング障害のために正規のトラフィックがルーテッド緩和レイヤーを通過できませんでした。Bot Manager では、分類制御が正規のトラフィックを悪質なトラフィックと見なしたために、正規のユーザーが拒否されました。一方はネットワーク制御の障害であり、他方は意思決定制御の障害です。エンドユーザーの視点からは、どちらも区別がつかない場合があります。保護されたサイトが機能しません。

DNS は同じ説明責任問題を Web 規模で可視化した

2021 年 7 月 22 日、Akamai は再び公的な停止を経験しました。今回は Secure Edge Content Delivery Network の DNS に関連するものでした。サービス中断概要で、Akamai は、UTC 15:45 にソフトウェア構成更新がそのネットワークの DNS システムのバグを引き起こし、一部の顧客ウェブサイトに可用性の影響を与えたと発表しました。中断は最大 1 時間続きましたが、Akamai がソフトウェア構成更新をロールバックした後、サービスが再開されました。また Akamai は、このインシデントは Akamai プラットフォームへのサイバー攻撃の結果ではないと述べました。

この表現は重要です。DNS はしばしば配管のようなものとして扱われますが、権威 DNS は到達性の制御ポイントです。Akamai のEdge DNS ドキュメントでは、Edge DNS は、複数のネットワークにわたるネームサーバーのグローバル展開、IP エニーキャスト、および Akamai Intelligent Platform の共通コンポーネントとして、DNS プロトコルの独自実装を使用する権威 DNS サービスとして説明されています。Edge DNS 製品ページでは、構成、DNSSEC、Control Center を介した展開、監視、ゾーン管理がサービスの一部として紹介されています。DNS パスにバグがあり、顧客の名前解決が失敗すると、ユーザーのブラウザはその名前の背後にある動作中のサービスを確実に見つけることができません。

Cisco Umbrella のAkamai DNS 停止に関するカスタマーサポートノートは、同様の表現でインシデントを要約しています。Akamai エンジニアがソフトウェア構成更新をプッシュしたことで DNS バグが発生し、ユーザーは何千ものウェブサイトにアクセスしようとして広範囲にわたる DNS 障害を経験し、1 時間強後にロールバックによってサービスが復旧しました。ThousandEyes の2021 年停止レビューでも、2021 年 7 月下旬の Akamai DNS イベントは 1 時間以上続き、銀行、航空旅行、ゲームなど多くの分野のウェブサイトとアプリケーションに影響が及んだと説明されています。

7 月の DNS イベントはボットの誤検知ではありませんが、運用上の問題は同じであるため、同じ説明責任記録に含まれます。プロバイダーが管理するエッジの変更が顧客の可用性に波及したのです。ステータスや根本原因の表現を曖昧にすべきではありません。Prolexic はルーテッド DDoS 緩和の問題でした。Secure Edge DNS はソフトウェア構成更新が DNS バグを引き起こした問題でした。Bot Manager は誤検知が正常なトラフィックを拒否した問題です。それらは異なるメカニズムです。共通する教訓は、エッジへの集中がプロバイダーの変更、閾値、ルーティング状態を多くの顧客の本番環境の命運に変えるということです。

「サイバー攻撃ではない」は説明責任の終わりではない

Akamai は、2021 年 6 月の Prolexic の問題はシステムアップデートやサイバー攻撃ではなく、2021 年 7 月の DNS の問題はプラットフォームへのサイバー攻撃ではないと述べました。これらの制限は重要です。誇張を防ぎ、顧客が悪意のある侵害、構成のバグ、ルーテッドサービスの障害、分類の問題のいずれに対処しているのかを理解する助けとなります。

これらは説明責任の分析を終わらせません。最も重要なクラウドとエッジの障害の多くは、通常の制御障害です。値の超過、構成更新が潜んでいたバグを引き起こした、ヘルスチェックが容量を引き揚げた、検出モデルがドリフトした、サポートチャネルに適切な証拠がなかった、または顧客ポリシーに対する緊急ロールバックが存在しなかった。攻撃者がいないことで、運用責任がより明確になる場合があります。なぜなら、システムは設計通りに、あるいはそれを制御する人々によって十分にテストされていない状態で動作したからです。

2026 年の Bot Manager インシデントは特に示唆に富みます。なぜなら、誤検知は製品の既知のリスクの範囲外ではないからです。Akamai 自身のボット管理戦略ブログでは、ボット管理を、ボットが人間と間違われる誤不検知と、人間がボットと間違われる誤検知のバランスとして位置付けています。Akamai のWeb 信頼ブログは、正規のユーザーや善玉ボットをブロックすると生産性に影響を与える可能性があり、強力なボット管理ソリューションは誤検知を最小限に抑える自動調整機能を備えるべきだと述べています。これらの記述はマーケティングとガイダンスであり、インシデントの証拠ではありません。それでも、ビジネスリスクが認識されていることを示しています。精度は可用性の一部なのです。

この既知のリスクは、顧客がプロバイダーのインシデント後報告に期待すべき内容を変えます。有用な報告は、単に修正が適用されたと言うだけではありません。次の疑問に答えるでしょう：

• どの検出、スコア、ディレクトリ、ルール、またはアクションパスが誤検知を生成しましたか？
• 誤った判断は、グローバル、リージョナル、アカウント固有、エンドポイント固有、クライアント固有、またはトラフィックパターンに結びついたものでしたか？
• 影響を受けたリクエストのうち、拒否、チャレンジ、スロットリング、リダイレクトされた割合はどのくらいでしたか？
• 顧客が選択したポリシーアクションが Akamai 側の分類エラーを増幅しましたか？
• 監視のみまたはチャレンジのみの顧客は、トラフィックを拒否せずに問題を確認しましたか？
• Akamai がプラットフォームテレメトリから誤検知を検出するのにどれくらいの時間を要し、最初の顧客報告からどれくらいかかりましたか？
• 修正はロールバック、モデル変更、ディレクトリ訂正、閾値調整、または緊急例外措置でしたか？
• チームが影響を受けたユーザーとトランザクションを特定できるように、どの顧客向け証拠フィールドが提供されましたか？
• 同じクラスの障害の再発を防ぐために何が行われ、その防止策はどのようにテストされますか？

これらの答えがなければ、一般の人々は誤検知インシデントが発生したことを知ることができますが、顧客は非公開のサポートチャネルと自分たちのログを通してでなければ、制御変更の妥当性を評価できません。

ロールバックは拒否の前に設計されなければならない

ロールバックは、Akamai の記録に繰り返し現れる明確な境界線です。2021 年 7 月には、ソフトウェア構成更新のロールバックが Secure Edge DNS を復旧させました。2021 年 6 月には、自動および手動の再ルーティングが Prolexic の顧客をさまざまな速度で復旧させました。2026 年 4 月には、公開ミラーに保存された Akamai のステータステキストは、Bot Manager の修正が実装され、サービスが通常運用を再開したと述べています。これらは交換可能ではありません。プロバイダー構成のロールバック、保護サービスの迂回、ボット制御の修正は、権限、顧客依存関係、証拠要件が異なります。

Akamai 自身の構成ツールが、この区別が重要である理由を示しています。Property Manager のアクティベーションドキュメントでは、高速フォールバック機能について説明しています。アクティベーションが完了した後、顧客は 60 分間、直近のアクティブなプロパティバージョンに戻すことができます。本番アクティベーションドキュメントでは、アクティベーションが構成を Akamai 本番ネットワークに展開して稼働させることを説明しています。これらのツールは価値がありますが、顧客のプロパティ構成に対応しています。プロバイダー側の検出アップデート、ボットディレクトリの更新、またはプラットフォームサービス変更を顧客がロールバックできることの証拠にはなりません。

インラインセキュリティにとって、ロールバックには少なくとも 4 つのレイヤーがあります：

説明責任のある設計は、これらの選択肢をインシデント前に決定します。小売業者は、クレデンシャルスタッフィングリスクの一時的な増加を、病院の予約システム、航空会社のチェックインフロー、政府給付ポータル、支払い承認パスとは異なる許容度で受け入れることができます。ビジネスエンドポイントは、ユーザーを拒否する代わりに、より多くのユーザーにチャレンジするフェイルソフトパスを必要とするかもしれません。コンテンツエンドポイントは、古いキャッシュページを受け入れるかもしれません。ログインエンドポイントは、既知のデバイスを許可し、新しい高リスクセッションをブロックするかもしれません。チェックアウトエンドポイントは、トランザクション監視を強化しながら、ボット防御を一時的に緩和するかもしれません。これらの選択は、有効なユーザーが拒否されている間に初めてその場しのぎで行われるべきではありません。

証拠はプロバイダーと顧客の境界を越えなければならない

誤検知インシデントの診断は困難です。なぜなら、双方がパスの一部しか見えないからです。顧客はコンバージョンの低下、ログイン失敗、サポート苦情、合成テスト、リクエスト欠落を示すオリジンログ、そしておそらく Akamai のイベントストリームを見ます。Akamai はエッジ分類、ボットスコア、ポリシーアクション、プラットフォーム更新、顧客横断的なステータス、サポートレポートを見ます。影響を受けたユーザーは拒否しか見えません。

Akamai は、このギャップを埋めるのに役立つセキュリティイベント統合を提供しています。SIEM 統合ドキュメントでは、コネクタが Akamai Security Events Collector からほぼリアルタイムで JSON イベントデータを収集し、顧客の SIEM に送信できると説明されています。Akamai のサンプリングレポートドキュメントでは、完全な数値を必要とする顧客は、SIEM 統合を使用して Akamai プラットフォームから生成されたすべてのセキュリティイベントを分析し、サンプリングレポートが制限されている場合でも記録を保持できると述べられています。Akamai のDataStream セキュリティログページでは、セキュリティ設定によって生成されるセキュリティ情報およびイベント管理イベントのストリームについて説明しています。

これらの機能は、証拠問題を自動的に解決するわけではありません。顧客はそれらを有効にし、影響を受けるワークフローの外でデータを保持し、拒否されたエッジリクエストとビジネス指標を比較できるスタッフを配置する必要があります。プロバイダーは依然として、顧客が自分の証拠がより広範なプラットフォーム問題の一部なのか、ローカルな誤設定なのかを判断できるように、十分なインシデントレベルの詳細を公開しなければなりません。ステータスページ、非公開のコミュニティ投稿、サポートケース、SIEM ログは整合している必要があります。

Akamai のステータス設計は、透明性のトレードオフも生み出します。公開Akamai ステータスページにはコンポーネントのステータスが表示され、複数の顧客に影響を与えるインシデントの詳細は、有効な Control Center 認証情報を持つ顧客とパートナーがアクセスできる Akamai コミュニティのサービスインシデント通知グループに投稿されると記載されています。公開ステータス FAQ ページでは、ステータスページの仕組みとサービスインシデント通知のルーティングについて説明されています。これは有料顧客にとっては有用ですが、公共部門のユーザー、影響を受けたエンドユーザー、ジャーナリスト、投資家、および拒否されたリクエストがプロバイダーインシデントの一部かどうかを理解しようとしている下流ビジネスにとっては、あまり有用ではありません。

誤検知イベントに適切な証拠パッケージは、機械可読で顧客が行動に移せるものであるべきです。それには、影響を受ける製品、UTC での時間枠、アクションタイプ、関連する地域、ポリシーパス、プロバイダー修正の状況、既知の顧客緩和策、イベントフィールドガイダンス、および Akamai が判断できる範囲の制限が含まれるべきです。また、「監視中です」「顧客は依然としてポリシーを変更する必要があります」「プラットフォーム側の緩和はすべて完了しました」を区別する必要があります。これらの区別は単なる文章の美しさではありません。顧客が制御の緩和を続けるか、より厳格なルールを復元するか、ユーザーに補償するか、トランザクションを再実行するか、プライバシーと法的レビューを開始するかを決定するものです。

補償は復旧と同じではない

サービス利用料のクレジットは、履行されなかったコミットメントを認めることはできますが、セキュリティ制御が有効なユーザーをブロックした実際の結果を支払うことはめったにありません。1 時間の誤検知は、購入、旅行チェックイン、アカウントアクセス、フォーム送信、ストリーミング開始、ニュース消費、公共サービスのやり取りを妨げる可能性があります。これらのトランザクションの多くは、月額料金に対する部分的なクレジットで回復することはできません。

ここで確認された公開情報源は、2026 年 4 月の Bot Manager インシデント、2021 年 6 月の Prolexic 停止、または 2021 年 7 月の DNS イベントに、どの顧客契約、サービススケジュール、またはクレジットが適用されたかを確定していません。法的請求は、契約文言、影響を受けたサービス、顧客構成、通知、免責、因果関係、および管轄区域に依存します。この不確実性は明示されたままでなければなりません。

それでもなお、Akamai の企業提出書類は、この問題が重要である理由を示しています。Akamai の 2025 年Form 10-Kでは、同社をセキュリティ、配信、クラウドコンピューティングサービスを提供する企業として説明し、障害、中断、サイバー攻撃、技術変化、顧客の信頼に関するリスク要因の文言が含まれています。Akamai の 2025 年の業績もその規模を示しています。2025 年第 4 四半期および通期の決算発表では、2025 年の総収益が 42 億 800 万ドルであったこと、および収益がセキュリティ、配信、クラウドコンピューティングのカテゴリに分かれていることを報告しています。プロバイダーの規模は、特定のインシデントにおける過失を証明するものではありません。しかし、ビジネスコンテキストを示しています。Akamai はインターネットのエッジにある小さなアプライアンスベンダーではありません。セキュリティ上の決定が多くの下流サービスに影響を与える可能性がある主要なプラットフォームです。

この規模は、顧客の調達要件も変えます。インラインセキュリティを購入する顧客は、稼働率以上のものを求めるべきです。誤検知の検出閾値、イベントログの保持、緊急サポートパス、ポリシーロールバック権限、独立したステータスフィード、顧客固有の影響範囲レポート、インシデント後の詳細、運用上の損害を見えなくしないクレジット条件を求めるべきです。重要な公共サービスについては、プロバイダーのセキュリティレイヤーが有効なトラフィックを拒否した場合に公共機能を維持できる継続性モードも調達要件に含めるべきです。

NIST のCybersecurity Framework 2.0は、サプライヤーリスク管理をガバナンス機能として扱い、サプライヤー、顧客、パートナーの役割と責任を確立し、サプライチェーンリスクをエンタープライズリスク管理に統合することを含んでいるため、有用です。CISA のSecure by Design ガイダンスは、セキュリティの負担が顧客だけに課されるべきではなく、テクノロジーメーカーは結果に対して透明性と説明責任を負うべきだと主張しています。NIST のサイバーレジリエンスエンジニアリングガイダンスは、レジリエンスを、サイバーリソースによって実現される、予測、耐性、復旧、適応する能力として位置付けています。これらは一般的な基準であり、Akamai に関する所見ではありません。それらは適切な説明責任の語彙を提供します。サプライヤーの役割は明示的でなければならず、セキュリティは隠れた脆弱性なしに使用可能でなければならず、復旧は設計されていなければなりません。

顧客の責任は依然として現実のもの

プロバイダーの義務は、顧客の義務をなくすわけではありません。収益に直結するエンドポイントで、疑わしいボットスコアすべてを拒否にマッピングする顧客は、ビジネス上の決定を下したことになります。新しいルールを監視せず、セキュリティイベントデータを読まず、バイパス経路を定義せず、緊急時の緩和を訓練しない顧客は、すべての結果を上流に転嫁することはできません。エッジセキュリティが強力であるのは、まさに顧客がプロバイダーに代わりにポリシーを執行する権限を与えているからです。

顧客側のベースラインには、以下が含まれるべきです：

• 新たな高インパクトのボットカテゴリ、検出変更、保護エンドポイントに対して、拒否モードの前に監視モードを適用する。
• ブラウジング、ログイン、チェックアウト、アカウント復旧、API、モバイルアプリ、管理パス、公開情報ページに対して、個別のポリシーを設定する。
• 分類の信頼度に対して拒否が過剰である場合には、チャレンジまたはスロットリングのオプションを利用する。
• 適切な場合には、既知のパートナー、検索クローラー、アクセシビリティツール、稼働監視、緊急サービス統合のための明示的な許可リストを用意する。
• 複数のネットワークおよびデバイス（モバイルおよび支援技術プロファイルを含む）から Akamai エッジを通過する独立した合成テストを実施する。
• セキュリティイベントを独立したストアにエクスポートし、拒否された期間を再構築するのに十分な保存期間を確保する。
• ビジネス承認が事前に定義された、ポリシーを迅速に緩和する権限を与えられた指名チームを置く。
• 重要なワークフローに対するオリジンまたは代替経路の手順を準備し、バイパスがセキュリティ露出を増大させる可能性があり、時間制限すべきことを認識する。
• 「疑わしいトラフィックをブロックしています」と「プロバイダーが有効なリクエストを誤分類しています」を区別する、顧客向けメッセージングを用意する。

これはボット保護なしで運用することを推奨するものではありません。拒否アクションが本番変更であることを認識することです。メンテナンスのためにチェックアウトを停止する前にレビューを要求する組織は、サードパーティのスコアがチェックアウトユーザーを拒否することを許可する前にもレビューを要求すべきです。

顧客の監視は、不在にも気づかなければなりません。エッジでの誤検知イベントでは、エッジがリクエストを到着前に停止するため、オリジンログはよりクリーンに見えるかもしれません。コンバージョンが低下し、ログイン試行が減少し、サポートへの問い合わせが増加し、合成プローブがエッジ生成の応答で失敗するかもしれません。オリジンのエラー率だけを監視しているチームは、オリジンが拒否されたユーザーを受け取らなくなったために、問題を見逃す可能性があります。トラフィックの不在が証拠です。

Akamai の責任は稼働時間だけではない

Akamai のプロバイダー側の義務は、単にパケットを流し続けることだけではありません。一度に多くのビジネスに代わって運用できるほど、インラインセキュリティを安全にすることです。つまり、精度を測定し、展開を制御し、ロールバックを保持し、証拠を提供し、製品自体が拒否の原因である場合にステータスを有用なものにすることです。

公開記録は、いくつかの具体的な義務を支持しています。

第一に、プラットフォームの変更には影響範囲の制御が必要です。2021 年 7 月の DNS インシデントは、バグを引き起こしたソフトウェア構成更新から始まりました。Prolexic インシデントは、ルーテッド DDoS サービスで値が超過したことが関係していました。Bot Manager インシデントは、誤検知の増加を伴いました。いずれの事例も、変更や状態がカナリアで検出できたか、顧客コホートで制限できたか、自動ガードレールで停止できたか、または広範な影響の前に元に戻せたかを問うています。

第二に、エッジセキュリティには、ビジネス成果に結びついた精度テレメトリが必要です。Bot Manager はボットスコアとセキュリティイベントを報告できますが、誤検知は多くの場合、顧客のビジネスシグナルを通じて明らかになります。ログイン失敗率の上昇、放棄、支払い拒否パターン、コールセンターの苦情、または有効なパートナートラフィックの突然の減少などです。Akamai はすべてのビジネス成果を見ることはできませんが、顧客横断的な異常と拒否の急増を見ることができます。顧客はグローバルなパターンを見ることはできませんが、ローカルな結果を見ることができます。プロバイダーは、これらのシグナルを容易に結合できるようにすべきです。

第三に、プロバイダーは、顧客専用の証拠を唯一の公開説明責任経路にすることを避けるべきです。顧客固有の詳細にはアクセス制御が必要な場合があり、機密性の高いルールロジックを公開すべきではありません。しかし、インシデントの広範な事実は、顧客の秘密を明かすことなく公開できます。製品、時間枠、障害クラス、アクションタイプ、緩和策、残りの顧客手順、改善テーマなどです。

第四に、インシデント後の改善措置は検証可能であるべきです。「修正を実装しました」は復旧のマイルストーンであり、再発防止の記録ではありません。より強固な記録は、どのガードレールが追加されたか、どのようにテストされたか、ロールバック時間が改善したか、検出遅延が減少したか、顧客がイベント証拠を受け取ったかを示すでしょう。顧客ログインなしで見える公開記録は、2026 年の Bot Manager 誤検知インシデントについて、そのレベルの保証を提供していません。

責任マップ

答えは顧客によって異なります。メディアサイトは銀行のログインよりも多くのチャレンジ摩擦を受け入れるかもしれません。チケッティングプラットフォームは、リリース中は在庫を積極的に保護するが、アカウント復旧はよりソフトに保つかもしれません。公共給付ポータルは、短期の緊急ウィンドウにおいて、有効なユーザーの拒否が悪用トラフィックの多少の増加よりも有害であると判断するかもしれません。セキュリティベンダーは、すべての顧客に対してこれらのビジネス上の価値を選択することはできませんが、そのような選択を実現する制御を提供しなければなりません。

記録が証明しないもの

ここで検討した公開記録には重要な限界があります。

この記録は、2026 年 4 月の Bot Manager 誤検知イベントがすべての Akamai 顧客、すべての Bot Manager 顧客、または特定の顧客に影響を与えたことを証明するものではありません。すべてのユーザーが拒否されたこと、顧客のオリジンがダウンしていたこと、または特定のモデルやルールが問題を引き起こしたことも証明していません。公開ミラーの継続時間リストにおける明らかな不整合、特に StatusGator ページの長いインシデント行を解決するものでもありません。なぜなら、元の Akamai の顧客専用詳細は公開記録で利用できなかったからです。より安全な見方は、Akamai が誤検知の増加を認識し、4 月 30 日に修正を実装したが、公開ミラーは完全な継続時間や影響範囲の計算には不十分であるということです。

この記録は、2026 年の Bot Manager イベントを 2021 年の Prolexic および Secure Edge DNS の停止と統合するものではありません。それらは別個のメカニズムによる別個のイベントでした。それらを比較するのは、いずれもエッジまたは保護レイヤーの制御が可用性の依存関係になることを示しているからです。

この記録は、Akamai が後に改善に失敗したことを示すものではありません。Akamai は、ここでは利用できない顧客専用のインシデント後詳細、内部クローズ証拠、契約固有の救済策を持っている可能性があります。したがって、本記事では改善の有効性は公開情報として未検証であり、不在とは見なしていません。

これは法的判断を下すものではありません。事実は、過失、契約違反、保証、規制違反、損害賠償を決定することなく、運用上の説明責任を支持することができます。法的責任は、顧客契約、製品条件、管轄区域、因果関係、損失の証明に依存します。

実践的な教訓

Web セキュリティについての古い考え方は、境界を最優先することでした。アプリケーションがその仕事を行えるように、エッジで悪質なトラフィックをブロックするというものです。現代の説明責任の見方はより厳格です。エッジはアプリケーションの一部です。ボットスコア、DDoS ルート、DNS 応答、チャレンジ、拒否ルール、ロールバックボタンは可用性制御です。それらは、データベースのフェイルオーバーや支払い処理と同様の証拠規律に値します。

したがって、Akamai の記録は Akamai を超えて有用です。保護レイヤーが停止の原因となり得る 3 つの方法を示しています。正規のユーザーが誤検知のボット分類によって拒否されること、保護対象トラフィックが DDoS 緩和ルーティング障害によって取り残されること、構成更新によって引き起こされた DNS バグによって顧客サイトが利用不能になることです。各インシデントは解決されました。各々はまた、顧客がエッジセキュリティを継続性とは別物として購入できない理由を示しています。

説明責任の基準は、「正規のリクエストを決してブロックしない」ことではありません。インターネット規模では、それは現実的ではありません。基準は、プロバイダーと顧客が誤検知を制限し、可視化し、可逆的にし、説明可能に保つことができるかどうかです。優れたエッジセキュリティシステムは、顧客が監視モードで開始し、制御を慎重に段階的に上げ、完全なセキュリティイベントを確認し、ビジネスクリティカルなパスをテストし、緊急時にポリシーを緩和し、プラットフォーム側の変更が誤った場合にプロバイダーの証拠を受け取れるようにすべきです。優れたプロバイダーは、障害クラスと是正措置を理解可能にするのに十分な公開インシデント情報を公開しながら、顧客に自社トラフィックの詳細な証拠を提供すべきです。

セキュリティ制御は、攻撃を阻止することで信頼を獲得します。エラー時に、保護が説明不能なサービス妨害レイヤーになっていないことを証明できる場合に、信頼を維持します。