2026.06.06 09:45 (更新: 2026.06.06 09:51)

CrowdStrikeのSGNL買収（$740M）— AIエージェント時代の『Continuous Identity』が変えるゼロトラスト認可

執行役員 / 情報セキュリティ管理者

どうもおかしんです。

CrowdStrikeがContinuous Identity企業のSGNLを買収しました。発表は2026年1月8日、CrowdStrikeのFY2026 Form 10-Kでは買収完了日が2026年2月20日と記載されています。Reutersなどの報道では約7億4,000万米ドル、つまり$740Mの買収として扱われています。一方で、CrowdStrikeの10-K上は、会計上の対価として現金$627.9M（取得現金$9.4M控除後）と、買収前役務に帰属する置換株式報酬$8.9Mが記載されています。

この記事では、このニュースを単なる買収速報としてではなく、AIエージェント時代のゼロトラスト認可の変化として読みます。結論から言うと、SGNL買収の意味は、CrowdStrikeが「ログインできたか」だけでなく、ログイン後のその瞬間に、何をしてよいかを継続的に評価する認可レイヤーへ踏み込んだことにあります。

この記事の結論

CrowdStrikeのSGNL買収は、Identity Securityが「認証強化」から「継続的な認可強制」へ広がっていることを示す動きです。

従来のSSOやMFAは、主にログイン時点で「この主体は誰か」を確認していました。もちろんこれは今でも重要です。ただ、AIエージェント、サービスアカウント、APIキー、OAuthアプリ、SaaS連携、クラウドIAMロールが増えると、問題はログイン時点だけでは終わりません。

重要になるのは、次の問いです。

この主体は、人間なのか、NHIなのか、AIエージェントなのか。
この主体は、いまこの操作をする必要があるのか。
端末、セッション、SaaS設定、脅威シグナル、業務文脈が変わったとき、アクセスを剥奪できるのか。
IdPの外側にあるSaaSやクラウドリソースまで、失効や権限縮小を伝えられるのか。

つまり、ゼロトラストの話は「ログインを強くする」だけではなく、認証後の認可をどう継続評価するかに移っています。これはゼロトラストの基本思想にもつながる話で、社内か社外かではなく、主体、端末、データ、操作、リスク、ログを組み合わせてアクセスを判断し続ける設計です。

何が起きたのか

まず、発表内容を整理します。

項目	内容	出典
買収発表	CrowdStrikeがSGNLを買収する正式契約を締結したと発表	CrowdStrike公式プレスリリース
発表日	2026年1月8日	CrowdStrike公式プレスリリース
買収完了日	2026年2月20日	CrowdStrike FY2026 Form 10-K
報道額	約$740M	Reuters転載記事
10-K上の対価	現金$627.9M（取得現金$9.4M控除後）と置換株式報酬$8.9Mなど	CrowdStrike FY2026 Form 10-K
SGNLの位置づけ	Continuous Identityのリーダー企業	CrowdStrike公式プレスリリース
統合先	Falcon Next-Gen Identity Security	CrowdStrike公式プレスリリース / CrowdStrikeブログ

ここで注意したいのは、$740Mという金額の扱いです。CrowdStrikeのプレスリリース本文には買収金額の明示はありません。報道では$740Mとされていますが、10-Kでは実際の会計上の対価が別の粒度で記載されています。公開記事としては、タイトルでは市場で通用している報道額を使いながら、本文では「報道額」と「10-K上の記載」を分けて扱うのが安全だと判断しました。

CrowdStrikeはSGNLの何を買ったのか

CrowdStrikeはSGNLを、IdPとSaaS/ハイパースケーラークラウドのリソースの間にある「ランタイムアクセス強制レイヤー」として説明しています。ここが今回の肝です。

SGNLは、OktaやMicrosoft Entra IDのようなIdPを単純に置き換える製品として語られているわけではありません。むしろ、既存のIdP、SaaS、クラウド、企業文脈、CrowdStrike Falconのリスクシグナルを使って、アクセス要求をその場で評価し、許可、拒否、剥奪を判断するレイヤーとして説明されています。

CrowdStrikeのMichael Sentonas氏のブログでは、SGNL統合後の方向性として、次のようなことが述べられています。

人間、NHI、AIエージェントの認可を継続的かつ文脈に応じて評価する。
リスク条件が変われば、アプリケーション、データ、AIエージェントへのアクセスも変わるべきである。
静的なポリシーと常時付与された特権を、動的な権限管理へ置き換える。
Active Directory / Entra IDで提供されているJITアクセスを、AWS IAM、Okta、その他のクラウドID/SaaSシステムへ広げる。

この読み替えはかなり重要です。Identity Securityを「IdP」「MFA」「PAM」「ITDR」の機能一覧で見ると、SGNL買収は一機能追加に見えます。しかし、アクセスの経路に入り、リスクシグナルを認可判断へ反映する制御面として見ると、CrowdStrikeが狙っている領域が見えやすくなります。

Continuous Identityとは何か

この記事でいうContinuous Identityとは、ログイン時点で一度だけ信頼するのではなく、ユーザー、端末、セッション、リスク、業務文脈、脅威シグナルを継続的に見ながら、アクセスを付与または剥奪し続ける考え方です。

従来のモデルは、多くの場合こうでした。

IdPで認証する。
MFAを通す。
ロールやグループに基づいてSaaSやクラウドへアクセスする。
権限レビューや棚卸しは定期的に実施する。

これ自体が間違っているわけではありません。ただ、このモデルは「ログイン後にリスクが変わったらどうするか」に弱いことがあります。端末が侵害された、セッションが盗まれた、SaaS側の権限が過剰だった、APIトークンが漏れた、AIエージェントが想定外のツールを呼んだ。こうした状況では、ログイン時点の認証が正しかったとしても、アクセスを続けてよいとは限りません。

Continuous Identityの制御面を、人間、NHI、AIエージェント、IdP、SaaS、クラウド、リスクシグナルの関係で示すインフォグラフィック

Continuous Identityの発想では、認証済みかどうかだけでなく、アクセス中の状態を見ます。もっと言うと、「認証済みユーザー」ではなく、「いまこの文脈でこの操作をしてよい主体か」を見ます。

この話は、認証と認可を分けて考えると理解しやすいです。認証は「誰か」を確認することです。認可は「何をしてよいか」を判断することです。Continuous Identityは、その認可判断をログイン後も継続させる考え方だと捉えると、製品名に引っ張られずに読めます。

CAEPとSSFは何を担うのか

CrowdStrikeの発表では、SGNLによってCAEP-driven enforcementをFalcon Fusion SOARへ統合し、IdPの外側にある下流アプリケーションやサービスまでアクセス剥奪を広げる方向が示されています。

CAEPは、OpenID Foundationの仕様ではOpenID Continuous Access Evaluation Profileです。CrowdStrike発表内ではContinuous Access Evaluation Protocolと表記されていますが、OpenID仕様名としてはProfileです。本文では、正式仕様名に合わせてProfileと書きます。

OpenID CAEP 1.0は、Shared Signals Framework（SSF）上で定義されるプロファイルで、送信側と受信側が継続的な更新イベントを共有し、セッション、デバイス、ユーザー、アプリケーションへのアクセスを弱めたり失効させたりするためのイベント種別を定義しています。

実務者目線では、CAEP/SSFは「リスクを検知した製品」と「アクセスを止めたい製品」の間で、どうやってシグナルを渡すかという話です。

たとえば、次のような流れを想像すると分かりやすいです。

EDRやITDRが、端末侵害、セッション異常、資格情報窃取の兆候を検知する。
IdPやSaaSが、そのリスクシグナルを受け取る。
対象セッションを失効する、追加認証を要求する、特定リソースへのアクセスを止める。
その判断と実行ログを、後で監査できる形に残す。

これを各ベンダー独自のAPI連携だけで積み上げると、運用がかなり重くなります。標準化されたシグナル共有が重要になる理由はここにあります。

なぜAIエージェント時代に認可が問題になるのか

今回のニュースがAIエージェントと結びつく理由は、AIエージェントが「権限を持つ主体」になるからです。

AIエージェントは、チャット画面の中だけで完結するとは限りません。SaaSを読み、チケットを作り、コードを書き、リポジトリを操作し、メールやSlackに投稿し、データベースや社内ナレッジにアクセスします。その裏側では、APIキー、OAuthトークン、サービスアカウント、MCPサーバー、クラウドIAMロールなどが使われます。

弊社ブログのNHI（Non-Human Identity）管理が一気に立ち上がってきた件でも整理されているように、NHIはサービスアカウント、APIキー、OAuthトークン、CI/CD、Bot、RPA、AIエージェントのクレデンシャルまで含む広い概念です。AIエージェントは、このNHI問題をさらに大きくします。

CyberArkの2025 Identity Security Landscapeでは、組織内に人間1人あたり82のマシンアイデンティティがあること、42%のマシンアイデンティティが特権または機微アクセスを持つこと、68%の組織がAI向けのIdentity Securityコントロールを欠いていることが示されています。数値の絶対値は調査条件に依存しますが、「人間よりも非人間の主体が大幅に多く、しかも権限を持つ」という構造は、かなり現実的な課題です。

さらにGartnerは2024年10月22日の発表で、2028年までに企業侵害の25%が外部および悪意ある内部者によるAIエージェントの悪用に起因すると予測しています。日本語のGartner Japan発表でも、セキュリティ対策が十分ではない正規のAIエージェントが攻撃者に悪用される可能性があると説明されています。

ここで大事なのは、AIエージェントの危険を「AIだから特殊」とだけ見ないことです。多くの問題は、既存のID、SaaS、クラウド、API、権限管理の延長です。ただし、実行速度、委譲範囲、ツール連鎖、権限の見えにくさが大きくなるので、従来の棚卸しや定期レビューだけでは追いつきにくくなります。

このあたりは、弊社ブログのAIエージェントにゼロトラストを適用するや、Anthropicが発表したゼロトラスト「Zero Trust for AI agents」解説でも扱っています。SGNL買収は、その文脈で「認可をどう継続評価するか」という市場側の答えのひとつとして読むと位置づけやすいです。

Falcon Next-Gen Identity Security統合で何が変わるのか

CrowdStrikeは2025年8月14日にFalcon Next-Gen Identity Securityを発表しています。公式発表では、初期アクセス防止、モダンPAM、ITDR、SaaS Identity Security、Agentic Identity Protectionを、単一センサー、単一コンソールで統合する方向が示されています。

SGNL買収によって、CrowdStrikeが追加しようとしているのは、主に次の領域です。

領域	何が変わるか	実務上の意味
Zero Standing Privileges	常時付与された特権を減らし、必要な瞬間だけ付与する	管理者権限、クラウド権限、SaaS権限を定期レビューだけに任せない
JITアクセス範囲	AD / Entra ID中心からAWS IAM、Okta、SaaSへ広げる	IdPやディレクトリの中だけでなく、下流サービスのアクセスも設計対象になる
CAEP-driven enforcement	Falcon Fusion SOARと連携してアクセス剥奪を実行する	検知と剥奪を別々の運用にせず、対応フローとしてつなげる
Unified Identity Fabric	Falcon、IdP、SaaS、クラウド、企業文脈のシグナルを集約する	人間、NHI、AIエージェントを同じ設計原則で見る
FalconIDとの接続	2026年2月26日にGAしたFalconIDと組み合わせ、認証から継続認可までを扱う	ログイン時のフィッシング耐性MFAと、アクセス中のリスク評価を分けずに見る

ただし、ここで「CrowdStrikeを入れれば全部解決する」と読むのは危険です。プレスリリースやブログの多くは、統合後の方向性を示すforward-lookingな記述です。日本国内でいつ、どのSKUで、どの範囲まで使えるのかは、公開情報だけでは断定できません。

実務では、製品ロードマップを確認する前に、自社側の準備状態を見る必要があります。台帳がない、オーナーがいない、権限が見えない、失効手順がない、ログが取れていない状態では、どの製品を入れても効果は限定的になります。

情シス・セキュリティ担当が確認すべきこと

ここからは、ニュースを実務に落とします。私は、まず次の5つを確認すべきだと思います。

1. NHIとAIエージェントを台帳に載せる

Continuous Identityの前提は、主体が分かっていることです。

人間ユーザーだけでなく、サービスアカウント、APIキー、OAuthアプリ、CI/CDトークン、RPA、Bot、MCPサーバー、AIエージェントを台帳に載せます。最低限、次の項目を持たせたいです。

項目	何を見るか
所有者	誰が責任を持つか
用途	何の業務、どのシステムで使うか
権限	どのリソースに何ができるか
寿命	いつ作られ、いつ失効するか
保管場所	シークレットやトークンをどこに置いているか
ローテーション	どの頻度で更新するか
失効手順	漏えい時や退職/異動時にどう止めるか
ログ	いつ誰が何をしたか追えるか

ここが曖昧なままContinuous Identityの製品を見ても、「何を継続評価するのか」が決まりません。

2. IdPだけでなく下流SaaSとクラウド権限を見る

OktaやEntra IDを整備していても、SaaS側のローカル管理者、共有リンク、APIトークン、外部連携アプリ、AWS IAMロール、GitHub App、Slack Appのような下流権限が残っていることがあります。

SGNLの説明で面白いのは、IdPの外側にあるSaaSやハイパースケーラーリソースのアクセス強制まで視野に入れている点です。これは、情シスやセキュリティ担当にとっても発想を変えるポイントです。

「IdPで認証できるか」だけでなく、「IdPでリスクを検知したとき、SaaS側のセッションや権限を本当に止められるか」を確認する必要があります。

3. JITとZero Standing Privilegesの対象を決める

Zero Standing Privilegesは、常時付与された特権をなくす考え方です。理想としては分かりやすいですが、全部を一気にやるのは現実的ではありません。

最初は、次のような高リスク領域から始めるのがよいと思います。

IdP管理者
MDM/EDR管理者
クラウド管理者
CI/CD管理者
本番データに触れるSaaS管理者
AIエージェントに渡すAPIトークン
外部委託先や一時的な管理者アクセス

大事なのは、JITを「セキュリティ機能」ではなく「業務の承認・実行・ログ設計」として扱うことです。誰が申請し、誰が承認し、どの条件なら自動承認し、どの操作は人間承認を残すのか。ここまで決めないと、現場は回りません。

4. CAEP/SSFをロードマップ確認項目に入れる

現時点で、すべてのSaaSやIdPがCAEP/SSFを期待どおりに扱えるとは限りません。だからこそ、今すぐ全社実装というより、製品選定や更新時の確認項目に入れるのが現実的です。

確認観点は次のようになります。

観点	確認すること
シグナル受信	IdPやSaaSがリスクイベントを受け取れるか
シグナル送信	EDR/ITDR/SaaSがリスクイベントを送れるか
実行内容	セッション失効、追加認証、権限剥奪、アプリ遮断のどれができるか
対象範囲	人間、NHI、AIエージェントのどこまで対象か
監査ログ	何を根拠にアクセスを止めたか説明できるか
例外管理	誤検知や業務影響が出たときに戻せるか

標準対応は、カタログのチェックボックスではなく運用の話です。実際にどのイベントを受け取り、どの操作を止め、誰に通知し、どのログを残すかまで見ます。

5. AIエージェントの権限委譲を「短く、狭く、剥奪可能」にする

AIエージェントに権限を渡すとき、ついやりがちなのは「ひとまず広めのAPIトークンを渡す」ことです。これは楽ですが、後でかなりつらくなります。

AIエージェントに渡す権限は、少なくとも次の原則で見るべきです。

必要な操作だけに絞る。
長期間有効なトークンを避ける。
エージェントごとに固有の主体として識別する。
高リスク操作には人間承認を残す。
操作ログを人間ユーザーと分けて追えるようにする。
異常時に即時失効できるようにする。

AIエージェントの統制を「AI利用ルール」だけで扱うと、実装に落ちません。ID、認証、認可、シークレット、ログ、承認、失効の話として扱う必要があります。

導入前の注意点

SGNL買収は重要な動きですが、実務では注意点もあります。

国内提供時期やライセンスは公開情報だけで断定しない

CrowdStrikeの公式発表やブログは、統合後の方向性を説明しています。しかし、日本国内での提供時期、既存顧客への提供条件、追加ライセンス要否、管理画面上の具体的な設定項目は、公開情報だけでは断定できません。

提案や社内稟議に使う場合は、CrowdStrike Japanまたは販売パートナーに確認したうえで書くべきです。

自動剥奪は強力だが、業務影響も大きい

リスクが変わったら即座にアクセスを剥奪する。これはセキュリティ上は魅力的です。ただし、すべての操作を機械的に止めると、業務影響が大きくなる可能性があります。

特に、管理プレーン、決済、顧客通知、データ削除、本番環境操作のような高影響操作では、検知、保留、人間承認、ロールバック、通知、監査ログをセットで設計します。自動化は「人間判断をなくす」ではなく、「人間が判断すべき場所を明確にする」と考えた方がよいです。

IdP、PAM、EDR、SaaS管理の責任分界を決める

Continuous Identityは複数の製品領域にまたがります。IdP、PAM、EDR/ITDR、SaaS Security、CASB/SSE、SIEM/SOAR、クラウドIAMが関係します。

そのため、製品選定より前に責任分界を決める必要があります。

IdPチームはどこまで責任を持つか。
SOCはどのリスクシグナルを出すか。
SaaS管理者はどの権限変更を受けるか。
クラウドチームはJIT権限をどう運用するか。
情シスは利用者体験と例外管理をどう守るか。

ここを曖昧にしたままツールだけ入れると、検知はできても止められない、止めたが戻せない、ログはあるが説明できない、という状態になりがちです。

FAQ

SGNL買収は完了していますか

はい。CrowdStrikeのFY2026 Form 10-Kには、SGNL.AI, Inc.の買収が2026年2月20日に完了したと記載されています。2026年1月8日の公式プレスリリース時点ではFY2027第1四半期中に完了見込みとされていましたが、記事執筆時点では10-Kで完了日を確認できます。

なぜタイトルでは$740Mなのに、本文では別の金額も出しているのですか

$740MはReutersなどの報道で使われている買収額です。一方、CrowdStrikeの10-Kでは、現金$627.9M（取得現金$9.4M控除後）と置換株式報酬$8.9Mなど、会計上の対価が別の粒度で記載されています。公式プレスリリース本文には金額が明示されていないため、本文では報道額と10-K上の記載を分けています。

Continuous IdentityはIdPの置き換えですか

少なくともCrowdStrikeの説明では、SGNLは既存IdPを置き換えるものというより、IdPとSaaS/クラウドリソースの間でアクセスを継続評価し、許可、拒否、剥奪を行うレイヤーとして説明されています。OktaやEntra IDを使っている企業でも、下流SaaSやクラウド権限、セッション失効、JIT権限の設計が論点になります。

CAEPとは何ですか

CAEPは、OpenID Foundationの仕様ではOpenID Continuous Access Evaluation Profileです。Shared Signals Framework上で定義され、リスク変化やセッション状態のイベントを共有し、アクセスの弱化や失効に使うためのプロファイルです。CrowdStrike発表ではProtocol表記が使われていますが、OpenID仕様名としてはProfileです。

今すぐ何を始めればよいですか

最初にやるべきことは、製品比較ではなく台帳です。人間ユーザーだけでなく、NHI、AIエージェント、APIキー、OAuthアプリ、サービスアカウント、クラウドIAMロールを棚卸しし、所有者、用途、権限、寿命、保管場所、失効手順、ログを確認してください。そのうえで、IdP、SaaS、クラウド、EDR/ITDRの間でリスクシグナルとアクセス剥奪をどうつなぐかを検討します。

まとめ

CrowdStrikeによるSGNL買収は、Identity Securityが「ログインを守る」だけではなく、「アクセス中の認可を継続評価する」方向へ進んでいることを示しています。

AIエージェントやNHIが増えると、正規の主体が、正規の権限を使って、意図しない操作をする可能性が増えます。このとき、ログイン時点の認証だけでは足りません。必要なのは、主体、端末、セッション、リスク、業務文脈を見ながら、アクセスを短く、狭く、剥奪可能にする設計です。

私は、ゼロトラストを「全部疑う」話ではなく、業務を安全に進めるために信頼の置き方を設計し直す話だと考えています。SGNL買収は、その設計対象にAIエージェント、NHI、下流SaaS、クラウドIAMまで含める必要があることを、かなり分かりやすく示したニュースでした。

まずは、台帳です。誰が、何に、どの権限で、いつまでアクセスしているのか。そこが説明できるようになると、Continuous IdentityやCAEP/SSFのような新しい技術も、単なる流行語ではなく、自社のロードマップに置ける判断材料になります。

主な参照元

タグ

okash1n