Google SecOpsとは？料金の決まり方と3パッケージの違い、SIEM・SOARの構成と廃止期限【2026年11月】

Google SecOps（正式名称はGoogle Security Operations）は、Google Cloudが提供するセキュリティ運用基盤です。ログを集めて脅威を検知するSIEMと、検知後の対応を自動化するSOARを1つの製品にまとめ、Google Threat Intelligence（Mandiant・VirusTotalの知見を統合した脅威情報）とGeminiによるAI支援を組み込んでいます。前身はChronicleという名前の製品で、ドキュメントのURLやAPI名には今も「chronicle」が残っています。

この記事では、料金がどう決まり3パッケージで何が変わるのか、SIEMとSOARがどうつながっているのか、ログをどの経路で取り込み、検知ルール言語YARA-Lで誤検知をどう抑えるのかを、2026年11月時点の公式ドキュメントにもとづいて説明します。既存の利用者向けに、Forwarderや旧APIなど2027年にかけて期限を迎える変更も1つの表にまとめました。SIEMやSOARそのものの仕組みはSOCとSIEM・SOARの違いの解説記事とSOARの解説記事で扱っているので、ここではGoogle SecOps固有の仕様に絞ります。

まとめ：Google SecOpsの料金・構成・期限の要点

料金は3パッケージとも取り込み量で決まり、公開価格はなく見積もり制です。パッケージで変わるのは、検知ルールの本数、UEBA（ユーザーとエンティティの行動分析）とGeminiの有無、脅威インテリジェンスの深さで、Enterprise PlusではCMEKやBigQueryへの管理エクスポートも加わります。

仕組みは、取り込んだログを独自スキーマUDM（Unified Data Model）に正規化し、YARA-Lのルールで検知し、検知結果をSOARのケースとして処理する、という一本の流れです。Google SecOpsの特徴の一つは、取り込んだデータを12か月、検索可能なホット状態で保持する点です。既存ユーザーは、2027年1月1日にEOLを迎えるForwarderと、2027年7月20日に止まる旧SIEM APIの置き換えを先に片付けてください。

Google SecOpsの構成：Chronicleからの系譜とSIEM・SOARのつながり

ChronicleからGoogle Security Operationsへの改称の経緯

SIEMの部分は、Alphabetの研究開発部門Xから2018年1月に独立したChronicleが起源です。SOARの部分は2022年1月4日に買収したSiemplify、脅威インテリジェンスは2022年9月12日に買収を完了したMandiantがもとになっています。Googleはこれらを統合した製品を2022年10月11日に「Chronicle Security Operations」として発表し、2024年4月25日のリリースノートでGoogle Security Operationsへの改称を告知しました。

「chronicle siem」「chronicle soar」で検索して見つかる情報は、いまのGoogle SecOpsと同じ製品の話です。ドキュメントのパス（/chronicle/docs/）、API名（Chronicle API）、課金明細のSKU名（Chronicle SecOps）にも旧名が残っているので、検索や請求書の照合では両方の名前で当たる必要があります。

取り込みからUDM正規化・YARA-L検知・SOAR対応までのデータの流れ

公式のアーキテクチャ文書は、Google SecOpsを入力・処理・出力の3段階で説明しています。入力はBindplaneなどのオンプレミス収集エージェント、クラウドのAPI、SaaSとの直接コネクタです。処理の中核では、生ログをパーサーがUDMに変換し、YARA-Lの検知エンジンが評価し、SOARのケース管理エンジンが対応フローを動かします。出力は、アナリストへのアラートとAIトリアージの結果、そしてAPIやリモートエージェント経由で対象環境へ送り返す封じ込め操作です。

UDMは、ベンダーごとに形式がばらばらのログを、IPアドレスやユーザー名、ファイルハッシュが同じフィールドパスに入るよう揃えるスキーマです。行為の主体をprincipal、影響を受けた対象をtarget、イベント自体の情報をmetadataに置きます。ファイアウォールのログでもEDRのログでも送信元IPはprincipal.ipで引けるので、1本のYARA-Lルールで複数製品のログを横断して検知できます。

従来型SIEMとの違い：12か月ホット保持と取り込み量課金

オンプレミス型のSIEMでは、ストレージ費用を抑えるために古いログをコールドストレージへ移し、調査のたびに戻す（リハイドレートする）運用が一般的です。Google SecOpsは取り込んだデータを最長12か月、インデックス付きのホット状態で保持し、公式のアーキテクチャ文書は1年前のデータも直近1時間と同じ性能で検索できるとしています。侵入から発覚まで数か月かかる事案を遡って調べるとき、この差が効きます。

保持期間は購入時の注文で最長5年まで延長でき、延長分は別のSKUで取り込んだデータ総量にもとづき翌月に後払いで請求されます。保持期間はインスタンス内の全データに一律で適用され、ログの種類ごとに変えることはできません。ログを手動で削除する手段もありません。

Google SecOpsの料金：3パッケージの違いと課金の決まり方

3パッケージの機能差：検知ルール数・UEBA・Gemini・脅威インテリジェンス

公式のパッケージ比較表とサービス上限のページから、選定で差が出る項目を抜き出しました。複数イベントルールの上限は、2026年6月30日にEnterpriseが200、Enterprise Plusが400へ引き上げられています。

Standardにも、12か月のホット保持、300以上のSOAR連携（統合）、Bindplaneでの収集と限定的なフィルタ・変換は含まれます。Geminiによる自然言語検索やケース要約、UEBAによる不審な認証の検出が要るならEnterprise以上です。Google SecOps側での高度なフィルタ・秘匿化・変換もEnterpriseから使えます。Bindplaneでのオンプレミス側の加工と複数宛先へのルーティング、BigQueryへの管理エクスポート、自前の暗号鍵（CMEK）が要件にある場合はEnterprise Plusになります。さらに上位のGoogle Unified Securityは、Enterprise PlusにSecurity Command Center Enterprise、Chrome Enterprise Premium、Mandiantのリテーナー契約などを加えた大企業向けのセットです。クラウドの設定ミスやワークロードの保護まで1つの契約で見たい場合の位置づけで、その領域の考え方はCNAPPの解説記事で扱っています。

BigQueryの扱いは2026年10月に変わりました。Google側が管理していた旧来のBigQueryデータセット（chronicle-tlaプロジェクト）へのエクスポートは、Enterprise Plus以外の顧客について2026年10月28日から廃止作業が始まっています。StandardやEnterpriseでBigQueryからSecOpsのデータを分析し続けるには、自社のGoogle Cloudプロジェクトへ書き出す方式（BYOBQ）に切り替えるか、Enterprise Plusへ上げる必要があります。

取り込み量のクレジットと超過・延長保持の課金

課金の説明ページによると、購入したGB数をクレジットとして請求先アカウントに積み、実際の取り込み量で減らしていく方式です。Cloud Billingの明細には、定額の「SecOps（commitment）SKU」と、取り込み量を示す「Bytes of data ingested」SKUの2行が常に出ます。クレジットを使い切った後の取り込みは、契約時に交渉した単価で超過料金になります。

導入時に詰まりやすいのが請求先アカウントの一致です。Google SecOpsのインスタンスを置くGoogle CloudプロジェクトとSecOpsのサブスクリプションが同じ請求先アカウントIDに紐づいていないと、クレジットが使用量に充当されず誤請求になります。SKUはデータ所在地の要件に合わせてリージョンごとに分かれ、単価もリージョンで異なりえるので、プロビジョニングするリージョンは契約書に明記してください。

請求の扱いが変わる例外は2つです。契約が更新前に切れると猶予期間に入り、その間の取り込みは割引なしの標準価格で月次後払いになります。また、SIEMやSOARを単体製品として購入している場合はCloud Billingを通らず、注文書のメールアドレス宛ての請求書になります。コンソールで明細を追えないため、予算アラートもCloud Billingとは別に用意します。

ログ取り込み経路の選び方とForwarder廃止への対応

Google Cloud直接取り込み・Bindplane・データフィード・Chronicle APIの使い分け

公式の取り込み概要は、経路を次のように使い分けるよう案内しています。

Google CloudのログをCloud Loggingのシンク経由で回す構成をとる例もありますが、公式は組織単位の直接取り込みを第一の方法としています。2026年9月21日からは、直接取り込みのログに送信元のGoogle Cloud組織IDが自動で付くようになり（UDMのmetadata.base_labels.ingestion_kv_labelsにキーgcp_organization_idで入る）、複数の組織を持つ企業が組織ごとにシンクとフィードを分けなくても出どころを区別できるようになりました。Cloud Logging側のログルーターの仕組みはCloud Loggingの解説記事で説明しています。

Forwarderの廃止スケジュールとBindplaneへの移行

Forwarderは、オンプレミスのログをDocker上で集めて送るGoogle SecOps独自のコンポーネントでした。インストール手順のページには、段階的な廃止の日付が次のように掲げられています。

• 2026年4月1日：新規顧客はForwarderを利用できない
• 2027年1月1日：EOL。セキュリティパッチを含め、修正は一切出ない
• 2027年4月1日：Forwarder経由のデータ取り込みが受け付けられなくなる

2027年1月から3月の3か月は、パッチの出ないエージェントでログを送り続ける状態になります。収集経路で新たな脆弱性が見つかっても修正を受けられない期間を避けるため、2026年中にBindplaneへ切り替えるのが現実的です。Bindplaneはログを収集・加工してGoogle SecOpsへ送るテレメトリパイプラインで、管理コンソールから複数のエージェントの設定をまとめて配れます。2026年3月18日には、既存のForwarder設定をBindplaneのパイプラインへ移すForwarder移行ツールがGAになっています。

取り込みが止まったことに気づく監視：Silent host monitoring

SIEMで見落とされやすいのは、検知ルールではなく「ログが届かなくなったこと」です。エージェントが止まったホストからは何も来ないので、アラートも出ません。Google SecOpsは、これをSilent host monitoringとして2つの方式で提供しています。

実運用ではCloud Monitoring方式を選んでください。ダッシュボード方式はアラートを出せず、結果も最大6時間遅れます。Cloud Monitoring方式は、Bindplane側でコレクタのホスト名を取り込みラベルとして各ログに付け、「Chronicle Collector > Ingestion > Total Ingestion Log Count」の指標にしきい値を置く構成です。公式は、しきい値を低めにすればコレクタの停止を、高めにすれば上流のログ欠落を拾えると説明しています。データフィード側の不調（届かない・遅れる・失敗する）は、2026年8月12日からプレビューで、フィードの動作ログをCloud LoggingのLogs Explorerで追えるようになりました。ただし自社のGoogle Cloudプロジェクトを紐づけた構成（BYOP）が前提です。

YARA-L 2.0の書き方：検知ルールと誤検知の抑え方

YARA-Lルールのセクション構成と必須・任意の区分

Google SecOpsの検知ルールは、YARA-L 2.0という独自言語で書きます。マルウェアのファイルを照合するYARAと名前は似ていますが、対象はファイルではなくUDMイベントで、別の言語です。ルールは次のセクションで構成されます。

matchを省いたルールは、条件に合うイベント1件ごとに検知する単一イベントルールになります。次は公式ドキュメントの例で、System32以外の場所から起動されたsvchost.exeを検知します。events内の行は暗黙にANDで結ばれ、notで除外条件を書きます。

rule suspicious_unusual_location_svchost_execution
{
meta:
  author = "Google Cloud Security"
  description = "Windows 'svchost' executed from an unusual location"
  yara_version = "YL2.0"
  rule_version = "1.0"
events:
  $e1.metadata.event_type = "PROCESS_LAUNCH"
  re.regex($e1.principal.process.command_line, `\bsvchost(\.exe)?\b`) nocase
  not re.regex($e1.principal.process.command_line, `\\Windows\\System32\\`) nocase
condition:
  $e1
}

matchによる相関ウィンドウと上限

複数のイベントを時間で束ねるときはmatchセクションを使います。次の公式例は、同じユーザーのログインが10分以内に10回以上あれば検知します。$userがグループ化のキー、over 10mがウィンドウ、#eがイベントの件数です。

rule MultiEventRule {
meta:
  author = "[email protected]"
events:
  $e.metadata.event_type = "USER_LOGIN"
  $e.principal.user.userid = $user
match:
  $user over 10m
condition:
  #e >= 10
}

ウィンドウは最小1分です。上限はmatch構文のページに今も「最大48時間」と書かれていますが、2025年9月3日のリリースノートで、複数イベントルールは最大14日まで指定できるようになりました。ただし実行頻度のページによると、48時間を超えるルールは実行間隔が「ウィンドウ÷10」（10日なら1日ごと）になり、48時間以下のルールにある自動のtrue-up実行（遅れて届いたログを拾い直す再実行）も付きません。検知は日単位で遅れると見込んでください。異なるルールの検知結果を段階的につなぐ多段の攻撃は、コンポジット検出（2025年8月にGA）で組みます。afterを使うと、あるイベントを起点にした「後続のイベントが来ない」ことも検知できます。次の例は、1台目のファイアウォールに記録があるのに、10分以内に2台目のファイアウォールに同じホストの記録がない状態を拾います。

rule MissingSequentialEvent {
meta:
  author = "[email protected]"
events:
  $e1.metadata.product_name = "firewall_1"
  $e1.principal.hostname = $host
  $e2.metadata.product_name = "firewall_2"
  $e2.principal.hostname = $host
match:
  $host over 10m after $e1
condition:
  $e1 and !$e2
}

ルール数の上限は、合計本数と、その内数としての複数イベントルール数の2段で決まります。Standardは合計1,000本のうち複数イベントルールが75本までなので、相関ルールを中心に組む運用では合計より先にこちらの上限に当たります。パッケージを選ぶ前に、手持ちの相関ルールの本数を数えておいてください。

誤検知を抑える設定：suppression_window・ルール除外・データテーブル

ルールを書いた後に手間がかかるのは、同じ事象から出る重複アラートと、既知の正常な動作への誤検知です。アラート抑制の公式ページは、7日分のデータでルールをテストして1日100件を超えるなら範囲が広すぎる、という目安を示しています。抑える手段は、カスタムルールかキュレーテッド検出ルールかで使い分けます。

スロットリングは、ルールのoptionsにsuppression_windowを書きます。次の公式例は、Windowsの管理共有への接続を「ユーザー×ホスト」ごとに1時間単位で1件だけ検知し、その組み合わせの検知を24時間抑えます。複数イベントルールとウィンドウ付き単一イベントルールではmatchの変数が抑制のキーになり、matchを持たない単一イベントルールではoutcomeに$suppression_keyを定義します。抑制ウィンドウをmatchのウィンドウと同じ長さにすると、抑制しない場合と同じ挙動になる点に注意してください。

rule rule_noisy_winshares {
meta:
  author = "Google Cloud Security"
events:
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.target.resource.name = /(C|ADMIN|IPC)\$/ nocase
  $user = $e.principal.user.userid
  $hostname = $e.target.hostname
match:
  $hostname, $user over 1h
outcome:
  $sharename = array_distinct($e.target.resource.name)
condition:
  $e
options:
  suppression_window = 24h
}

ルール除外はキュレーテッド検出ルール専用で、カスタムルールには付けられません。社内の脆弱性スキャナや資産管理ツールの動作を外す用途で使い、適用前に「Test Exclusion」で検知件数への影響を確かめられます。キュレーテッドのコンポジットルールには直接付けず、その材料になっている基礎のルールに付けるよう公式は注意しています。

カスタムルールで許可リストを使い回すなら、データテーブルに置きます。not $e.principal.ip in %data_table.benign_ipのようにinで列と比べる書き方なら、複数のルールから同じ表を参照できます。行の有効期限（TTL）は1時間〜365日で設定できます。旧来の参照リスト（Reference lists）はデータテーブルへ自動移行中で、参照リストのページでは2027年7月に完全廃止とされています。新しく作るならデータテーブル一択です。

注意点として、=や!=で表の行とイベントを結合するルールは、単一イベントのつもりで書いても複数イベントルールとして扱われ、matchセクションが必要になります。Standardでは75本しかない複数イベントルールの枠を、除外のための結合で消費しかねません。許可リストの照合は、行単位の結合ではなくinによる列の比較で書くのが安全です。

SigmaルールをYARA-Lへ変換するときの3つの落とし穴

他のSIEMから移行するとき、ベンダー非依存の検知ルール形式Sigmaで書かれたルールを変換したくなります。変換にはpySigma-backend-secops（AttackIQが公開・Python 3.10以上）を使えます。2026年11月6日に最新の1.0.0（2025年11月28日リリース）をPython 3.15.0とpySigma 1.5.1で動かし、Windowsのプロセス生成ルールをyara_l形式で変換すると、次の出力になりました（metaの後半5行は省略）。

rule svchost_launched_from_unusual_path {
  meta:
    id = "6b4bd3cc-6e1b-4b5e-9c1a-3f0e2b1c7a11"
    title = "Svchost Launched From Unusual Path"
    description = "None"
    author = "None"
    ...
  events:
    $event1.metadata.event_type = "PROCESS_LAUNCH"
    $event1.target.process.file.full_path = /\\svchost\.exe$/ nocase AND $event1.target.process.file.full_path != /^C:\\Windows\\System32\\/ nocase

  conditions:
    $event1
}

1つ目の問題は、末尾のセクション名がconditions:になっていることです。YARA-L 2.0の正しいセクション名はcondition:で、このままではパースエラーになります。GitHubではissue #3（2025年12月）として報告され、修正のプルリクエスト#5も出ていますが、2026年11月6日時点でマージされていません。変換後に置換するしかありません。

2つ目は、Sigmaで値を設定していない項目が文字列"None"として出力されることです。修正のプルリクエスト#6も未マージのままです。動作は止まりませんが、ルール一覧の説明欄が「None」で埋まります。

3つ目は、Sigmaの相関ルール（10分間に10回の失敗ログオンのようなevent_count）が変換できないことです。実行するとNotImplementedError（「Backend does not support correlation rules.」）で止まります。対応の要望はissue #4で議論中です。相関ルールは、上のMultiEventRuleのようにmatchとconditionを手で書き起こす必要があります。単一イベントの検知は機械変換し、相関はYARA-Lで書き直す、と分担を決めておくと移行の見積もりが立てやすくなります。

SOARのケース管理とプレイブックの上限

SIEMが出したアラートは、SOAR側でケースにまとめられます。グルーピングの設定（SOAR Settings → Advanced → Alerts Grouping）では、1ケースにまとめるアラートの最大数と、同じケースに束ねる時間幅（0.5〜24時間・30分刻み、既定は2時間）を決めます。サービス上限のページでは、1ケースあたりのアラート数は既定20件・最大90件です。グルーピングは原則として未解決のアラートとケースにだけ適用されますが、2026年10月18日のSOARリリースノートで、Source Grouping Identifierでまとめる場合に限り、クローズ済みのケースを再オープンするかどうかを選べるようになりました。

対応の自動化はプレイブックで組みます。1つのアラートに付けられるプレイブックは合計10本で、取り込み時に自動で付くのは1本だけ、残り9本は手動です。同じプレイブックの再実行は1つのケースまたはアラートにつき10回までです（ケース単位のプレイブック機能などが有効な環境では30本・30回）。自動で付くのは1アラートに1本なので、後続の処理はそのプレイブックの中からブロックとして呼ぶ設計にしておきます。2026年9月6日からは、ケース全体に対してプレイブックを走らせるケースプレイブックと、担当者やタグの変更などをきっかけにプレイブックを起動するリアクショントリガーがプレビューで使えます。

他製品との統合（インテグレーション）はStandardでも300以上あり、EDRでの端末隔離やIDプロバイダでのアカウント停止は、統合のアクションをプレイブックに並べて組みます。プレイブック設計の考え方そのものはSOARの解説記事で扱っています。

GeminiとAIエージェント・MCPサーバーの使いどころ

Gemini・Triage AgentとSecurity Tokensの課金

Enterprise以上で使えるGemini in Security Operationsは、英語の質問をUDM検索クエリに変換する自然言語検索、ケースの要約、プレイブックや検知ルールの作成支援を提供します。ただしGeminiが生成できる検知ルールは単一イベントルールに限られます。matchで時間ごとにまとめる形は作れますが、#e >= 10のように複数イベントの件数や組み合わせを条件にする相関ルールは人が書く必要があります。

自律的に調査するAIエージェントの代表がTriage Agent（正式にはTriage and Investigation Agent、TIN）で、2025年11月12日のリリースノートで提供が告知されました。アラートが真陽性か誤検知かを判定し、根拠の要約と次の調査手順を返します。調査では検索クエリの実行と絞り込み、Google Threat IntelligenceによるIoCの補強、コマンドラインの自然言語での説明、プロセスツリーの再構成を自動で行います。1件の調査は平均60秒、最長20分で、既定ではアラート発生の5分後に開始します。TINが調査するのはGoogle SecOps SIEMに取り込んだデータのアラートだけで、SOARのコネクタ経由で入ったアラートは対象外です。このほか、Threat Hunt Agent（2026年8月3日からEnterprise Plus向けパブリックプレビュー）と、脅威情報からYARA-Lルールの下書きを作るDetection Engineering Agent（2026年8月18日からパブリックプレビュー）も公開されています。

課金面では、2026年7月1日からSecurity Tokensという従量の単位が導入されました。Security TokensはEnterprise・Enterprise Plus・Google Unified Securityのアドオンとしてのみ販売されるため、Standardはエージェントの対象外です。トークンを消費するのは一般提供（GA）のエージェントだけで、チャットパネルや自動要約などの補助機能、プレビュー段階のエージェントは消費しません。Enterprise PlusとGoogle Unified Securityには年間契約額に応じて1日1,000万〜6,000万トークンの無償枠があり、太平洋時間の0時にリセットされ、翌日へは繰り越せません。Enterpriseの場合、無償枠は付かず全量が有償です。有償トークンの消費はテナントごとに明示的に有効化する必要があるので、検証用テナントで意図せず課金される事故は起きにくい設計です。

MCPサーバーでClaudeやChatGPTからSecOpsを操作する設定

Google SecOpsには、Antigravity・ChatGPT・Claudeなどの外部のAIアプリから検索やケース操作を呼び出せるリモートMCP（Model Context Protocol）サーバーがあります。公式の設定手順によると、Google Security Operations APIを有効にすると同時に有効になり、別のサーバーを立てる必要はありません。接続先はリージョンのエンドポイントの末尾に/mcpを付けたURLで、米国リージョンならhttps://us-chronicle.googleapis.com/mcpです。

呼び出す側には、MCP Tool User（roles/mcp.toolUser）に加えて、MCPのツールが内部で呼ぶChronicle APIの権限が要ります。公式手順はChronicle API Admin（roles/chronicle.admin）とChronicle SOAR Admin（roles/chronicle.soarAdmin）を例に挙げていますが、管理者ロールをAIアプリに渡すとケースのクローズやルールの変更まで任せることになります。調査だけに使うなら、必要なメソッドに絞ったカスタムロールを作ってください。なお、GAのエージェントはMCP経由で呼び出してもSecurity Tokensを消費します。

2027年までに対応が要るGoogle SecOpsの廃止・移行期限

Google SecOpsは統合と旧機能の整理が続いており、既存の連携スクリプトや取り込み経路には期限付きの作業がいくつもあります。2026年11月6日時点のリリースノートと各ドキュメントから、利用者側の作業が要るものを日付順に並べました。

影響が最も広いのは旧SIEM APIの停止です。2026年7月20日のリリースノートによると、対象はBackstory API（Customer Management APIを含む）とIngestion APIを呼ぶ自作スクリプト・統合・SOARコネクタ・取り込みフィードで、画面側の対応はGoogleが済ませています。まず自社の連携がどちらのエンドポイントを呼んでいるかを棚卸しし、旧API側のものから置き換えてください。SOARのGoogle Cloudへの移行のStage 2は、SOARの権限グループをCloud IAMのロールへ移す作業、SOAR APIをChronicle APIへ移す作業、リモートエージェントの認証基盤をサービスアカウントへ移す作業の3つからなります。2026年10月12日に延びたのはSOAR APIの移行（2027年3月31日まで）だけで、移行ガイドによると、IAMへの移行の期限は11月30日のままです。既存のリモートエージェントも同日を過ぎると動かなくなるので、APIキーをサービスアカウントに替え、エージェントをメジャーバージョンアップする作業も月内に済ませてください。Stage 2が済むと、SOAR Settings → License Managementのバージョン番号の後ろに「CloudIAM Enabled」と表示されます。

見落としやすいのは2027年1月25日のスコープ変更です。chronicle.readonlyのOAuthスコープで書き込みまでできていた連携は、この日から読み取りしかできなくなります。読み取りは通り続けるため、連携全体が止まるのではなく書き込みの処理だけが失敗します。脅威情報のフィードは、2026年10月12日からApplied Threat Intelligenceのキュレーテッドルールが新しいGTI_IOCフィードで照合するよう切り替わっており、旧フィードを自作ルールで参照している場合だけ書き換えが要ります。

Google SecOpsが向く組織と、ほかのSIEMを選ぶべき場面

Google SecOpsが強いのは、ログ量が多く、1年分を遡って調べる必要がある組織です。取り込み量で課金が決まり、保持期間内は検索速度が落ちないので、ログを捨てたりコールドへ逃がしたりする判断が減ります。Google Cloudを主に使っている組織では、監査ログやVPCフローログを直接取り込みで安く入れられる点も効きます。取り込みの前段となるGoogle Cloud側のログ基盤やIAMの設計から見直す場合は、インフラ構築（AWS・Google Cloud・Azure）の支援でも相談を受けています。社内SOCを持たずにMSSPへ運用を任せる場合も、Enterprise以上のマルチ環境SOARがMSSP側の運用形態に合います。SOCの体制づくりについてはSOCの解説記事を参照してください。

逆に、採用を見送るべき場面もはっきりしています。Microsoft 365とDefenderを中心に運用している組織なら、同じポータルで完結するMicrosoft Sentinelのほうが統合の手間が少なくなります。SPLで書いた検知ルールと運用資産が大量にあるなら、YARA-Lへの書き換えと検証のコストを先に見積もってください。上で見た相関ルールの変換不可はSigma用バックエンドの制限で、SPLについてはGoogleがSPLからYARA-Lへの移行ガイドとLabsの変換ツールを用意しています。ただし変換結果は出発点であり、検知の結果が移行前と一致するかは自分で確かめる必要があります。また、公開価格がなく見積もりが前提なので、まず小さく試して月額を把握したいという進め方には向きません。費用感を先に掴みたい場合は、料金の実額を確認できるSplunkやDatadog Cloud SIEMと比べてから判断してください。検体の判定だけを自動化したいなら、SIEMを入れる前にVirusTotal APIでの自動判定から始める手もあります。

よくある質問

Google SecOpsとChronicleは別の製品ですか？

同じ製品です。ChronicleのSIEMにSiemplify由来のSOARとMandiantの脅威インテリジェンスを統合し、2024年4月25日にGoogle Security Operationsへ改称しました。API名（Chronicle API）やドキュメントのURL、課金のSKU名には今もChronicleの名前が残っています。

Google SecOpsの料金はいくらですか？

公開価格はありません。Standard・Enterprise・Enterprise Plusのいずれも取り込み量（GB）にもとづく料金で、Google Cloudの営業かパートナーから見積もりを取ります。12か月を超える保持やAIエージェントのSecurity Tokensは別料金です。

Google SecOpsのSIEMとSOARは別々に契約できますか？

現行の販売単位はSIEMとSOARを一体にした3パッケージです（単体購入の可否は営業に確認してください）。SIEMやSOARを単体製品として購入している既存契約もありますが、その場合はCloud Billingを通らない別の請求系統になり、コンソールで明細を確認できません。

Google SecOpsのForwarderはいつまで使えますか？

2027年1月1日にサポートが終了し、2027年4月1日にはForwarder経由の取り込みが止まります。2026年4月1日以降の新規顧客はそもそも使えません。移行先として公式が推奨しているのはBindplaneエージェントです。

Google SecOpsのAPIはどれを使えばよいですか？

Chronicle APIを使います。取り込み用には、UDMイベントを送るevents.import、非構造化ログを送るlogs.import、エンティティ情報を送るentities.importがあります。旧来のBackstory APIとIngestion APIは、2026年10月26日以降に作られたインスタンスでは使えず、既存のインスタンスでも2027年7月20日に全面停止します。

関連記事

• SOCとは？SIEM・SOARとの違いと監視運用の仕組み・内製とアウトソースの判断を実装者向けに解説【2026年時点】
• SOARとは？SIEMとの違い・プレイブックの仕組みと導入判断を実装者向けに解説【2026年時点】
• Microsoft Sentinelとは？クラウドネイティブSIEM/SOARの仕組み・料金モデル・Defenderポータル統合を実装者目線で解説
• Splunkとは？SPLの書き方・Docker検証環境と料金の実額を実装者向けに解説
• Cloud Loggingとは？Google Cloudのログ管理の仕組み・ログルーター/シンクとCloudWatch Logsとの違いを実装者目線で解説