NEAR AI不正アクセス事件に学ぶ機密コンピューティングとAIセキュリティ設計

NEAR AIで起きた不正アクセス：何が、どう封じ込められたか

2026年11月9日、AIインフラサービスを提供するNEAR AIが内部システムへの不正アクセスを検知した（cryptoadventure.com、cryptometer.io）。発覚直後、NEAR AIは調査のためNEAR AI Cloudの推論サービスを予防的に停止。翌11月10日、全サーバーの脆弱性修正と影響を受けた認証情報の交換を完了し、サービスを再開した。最初の公開開示からサービス再開まで約4時間という対応速度だった（cryptoadventure.com）。NEAR ProtocolブロックチェーンおよびNEARの他サービスへの影響はなかったことが複数のソースで確認されている。侵入経路・侵害システムの詳細・攻撃者の身元は現時点で未公開であり、詳細なインシデントレポートは近日公開予定とされている（cryptobriefing.com）。

今回のインシデントで注目すべきは、顧客のプロンプトデータが漏洩しなかったとNEAR AIが主張していることだ。その根拠となっているのが、NEAR AI CloudがすでにIntel TDXおよびNVIDIA Confidential Computingによるハードウェア分離型TEE（Trusted Execution Environment：信頼実行環境）を採用していた点である（cryptobriefing.com）。この仕組みが今回の封じ込めにどう機能したのかは、AIサービスを提供・導入する組織が自らのセキュリティ設計を見直す上で、直接的な参照材料となる。ただしTEEによるデータ保護の有効性については、第三者による独立した検証は現時点で実施されていない点は留意が必要だ。

ほかのAIハッキングで実際に起きた被害は、日本・世界の主な被害一覧で解説しています。

関連記事AIによる情報漏洩の原因・事例は？

機密コンピューティングとTEEがデータを守る仕組み

従来のクラウドインフラでは、データは「保存時（at rest）」と「転送中（in transit）」に暗号化されるのが標準だった。しかし処理中（in use）のデータは、CPU上のメモリに平文で展開される。これはクラウド事業者のインフラ管理者が技術的にアクセス可能な状態であることを意味する。AIサービスにおいては、ユーザーが入力するプロンプトがまさにこの「処理中」の状態に該当する。

機密コンピューティングはこの「処理中」の脆弱性に対処するアーキテクチャである。Intel TDX（Trust Domain Extensions）やNVIDIA Confidential Computingは、CPUおよびGPUレベルでハードウェア的に隔離された保護領域（TEE）を提供する。NEAR AI CloudではこのTEE内部でプロンプトを暗号化処理し、インフラ事業者やNEAR AI自身もアクセスできない設計としていた（cryptoadventure.com）。さらに暗号学的アテステーション機能により、推論処理が意図した保護環境内で実行されたことをユーザー自身が検証できる仕組みを備えていた（cryptoadventure.com）。

この設計思想は「ゼロトラスト」の考え方とも親和性が高い。サービス提供者自身を信頼の前提に置かず、技術的な検証手段を利用者に開放するという方向性は、AIサービスにおけるデータ保護の透明性を高める上で注目すべきアーキテクチャの一つとなっている。

不正アクセスの迅速な封じ込めにAIをどう活用するか

今回のNEAR AIの対応が示した「早期検知→予防的停止→迅速復旧」という流れは、AIを活用したセキュリティ運用が目指すパターンを体現している。ただし各段階でAIが有効に機能する範囲と、人が判断を担うべき範囲は切り分けて考える必要がある。

未然に防ぐ：異常の予兆を事前に検出する

不正アクセスの防止において、AIを活用した機械学習ベースの異常検知は現在最も実績のある領域の一つだ。ネットワークトラフィック・認証ログ・APIアクセスパターンを機械学習モデルで常時モニタリングする構成は、ルールベースのSIEMでは検出しにくい「正常に見える逸脱」を捉えやすい。特にAIサービス基盤では、推論リクエストのパターン変化（急激な量の増減・送信元IPの分散・レスポンスタイムの異常）を時系列でモデル化し、ベースラインからの逸脱を自動検出する構成が有効とされる。

クレデンシャル（認証情報）管理についても、自動ローテーション・利用頻度分析・特権アクセスの異常検知が、今回のような「影響認証情報の交換」を迅速に完了させる土台となる。クレデンシャルの棚卸しが手動管理に依存している組織では、まずシークレット管理ツールへの移行が優先度の高い一手となる。

早く見つける：インシデント検知の自動化

内部システムへの不正アクセスを「検知した直後に予防的停止を判断できた」という今回の対応速度は、自動化されたアラートと明確なエスカレーションルールの存在なしには実現しにくい。AIを活用したSOC補助ツールは、大量のアラートの優先度付け・誤検知の除外・関連ログの自動集約といった作業を圧縮し、担当者が判断に集中できる状態を作る。

自然言語処理を活用したインシデント要約機能は、深夜や休日のオンコール対応において、担当者が状況を把握する時間を短縮できる可能性がある。ただし最終的な対応判断（サービス停止・外部通知・当局報告など）は必ず人が行う体制を維持することが前提となる。

被害を小さくする：影響範囲の自動特定と復旧支援

インシデント発生後の「影響範囲の特定」は、手動では時間と見落としの両面でリスクが高い。グラフ型のアセット管理データベースとAIを組み合わせることで、侵害が疑われるコンポーネントから伝播しうる依存関係を自動的にマッピングし、交換・パッチ適用が必要な認証情報・サーバー・サービスを洗い出す作業を支援できる。今回NEAR AIが全サーバーの脆弱性修正と影響認証情報の交換を約4時間で完了できた背景には、こうした構造的把握が可能なインフラ設計があったとみられる（cryptoadventure.com）。

AIサービス提供者・導入企業が今確認すべき設計の要点

今回のNEAR AIのインシデントは、AIサービスを提供・導入する組織が自社の設計を点検する上で、具体的な問いを提示している。

AIサービスのセキュリティ設計チェックポイント

設計レイヤー	確認すべき問い	対応策の例
データ保護（処理中）	推論処理中のプロンプトは誰がアクセスできるか	TEE（Intel TDX / NVIDIA Confidential Computing等）の採用有無をベンダーに確認
認証情報管理	クレデンシャルの棚卸し・ローテーションは自動化されているか	シークレット管理ツールへの移行、定期自動ローテーションの設定
異常検知	ベースラインからの逸脱をリアルタイムで検出できるか	機械学習ベースの異常検知をSIEM/SOCに組み込む、ログの一元化
インシデント対応	検知から予防的停止・外部通知までの判断フローは文書化されているか	インシデントレスポンスプレイブックの整備、定期的な机上訓練
影響範囲の把握	侵害が起きたとき、影響コンポーネントを速やかに特定できるか	アセット管理データベースの整備、依存関係の可視化
透明性・検証可能性	利用者がデータ保護の実施を検証できる手段があるか	暗号学的アテステーション・第三者監査・監査ログ提供の有無を確認

特に「処理中のデータ保護」は、多くのAIサービスがまだ対応を進めている途上の領域だ。TEEを採用しているというベンダーの主張を利用者側が独立して検証する手段は現時点では限られており、第三者監査の普及が今後の課題となる。契約段階で検証手段の有無を確認することが、現実的な対応の起点となる。

AIセキュリティの限界と、人が担うべき判断

今回のNEAR AIの対応は速やかだったが、侵入経路・侵害システムの詳細が未公開であることは、透明性の観点から留意が必要だ（cryptobriefing.com、cryptometer.io）。AIを活用したセキュリティ設計の有効性を評価する上で、インシデントレポートの開示は重要な判断材料となる。

AIを活用したセキュリティ対策には、いくつかの根本的な限界がある。

第一に、異常検知モデルは誤検知と見逃しを完全にゼロにできない。ベースラインの設定が不適切であれば、正常な運用を攻撃と判定して業務を止めるか、実際の攻撃をノイズとして流してしまうリスクが常に存在する。検知モデルの定期的な再学習と担当者によるチューニングは継続的な作業として必要になる。

第二に、機密コンピューティングはTEE内部のデータへのアクセスを制限するが、TEEの実装自体に脆弱性が発見される可能性を排除するものではない。ハードウェアおよびソフトウェアの脆弱性情報を継続的に追跡し、パッチを適用する運用体制は不可欠だ。

第三に、監視の強化は監視対象となる従業員や利用者のプライバシーとのバランスを常に要求する。内部脅威対策として操作ログを詳細に収集・分析することは技術的には可能だが、適用範囲・保存期間・利用目的については個人情報保護法や労働関係法令に基づいた設計が必要であり、AIが自動的に適切な判断を下せる領域ではない。

最終的な対応判断—サービスの停止、外部への通知、監督機関への報告—は必ず人が行う。今回NEAR AIが予防的に推論サービスを停止するという判断を速やかに行えたことは、自動化ツールの支援があったとしても、その判断を下す権限と責任が明確に定められた人間の存在なしには成立しない。

明日から着手できる実務的な一歩

まず自組織が利用するAIインフラの「処理中データ保護」の仕様をベンダーに確認する。TEEの採用有無、採用している場合の検証手段（アテステーション機能の有無）、第三者監査の実施状況を問い合わせ、不明な点はサービス契約の条件として明文化を求めることが出発点となる。

次に、インシデントレスポンスプレイブックの中に「AIサービス基盤の停止・切り離し」のシナリオが含まれているかを確認する。AIインフラを止める判断権限が誰にあるか、どのアラート水準で停止を判断するかが文書化されていない組織では、今回のような迅速な対応は難しくなる。

NEAR AIは2026年10月29日にサイバーセキュリティ研究向けモデルとNEAR AI Redイニシアチブを開始したばかりのタイミングでこのインシデントに直面した（cryptobriefing.com、cryptoadventure.com）。新機能・新サービスのリリース直後は攻撃対象領域が一時的に拡大する時期であり、同時期のモニタリング強化を標準的なプラクティスとして位置づけておく価値がある。AIを活用したセキュリティ設計は特定のツールを導入すれば完結するものではなく、検知・判断・対応・検証の各段階で人とシステムの役割を継続的に見直す営みだ。

参考文献

• cryptoadventure.com https://cryptoadventure.com/near-ai-restores-cloud-hours-after-internal-security-breach/
• www.cryptometer.io https://www.cryptometer.io/news/near-ai-confirms-security-breach-says-near-protocol-remains-unaffected/
• www.chaincatcher.com https://www.chaincatcher.com/en/article/2303199