＜Google Next '26＞ 9 万台の Windows を 1 本の配管で束ねる
Bindplane が示す SecOps スケール運用

Google Cloud Next は、Google Cloud が主催する 1 年に 1 度の製品アップデートや最新情報が発表される大規模イベントです。今年は 2026 年 4 月 22 日〜24 日（米国時間）、ラスベガスで開催されています。

公式サイト：https://www.googlecloudevents.com/next-vegas

「Google SecOps を大規模 Windows 環境に展開したいが、ログのボリュームとコストをどう捌けばよいのか」という悩みをお持ちの方は多いのではないでしょうか。ログは守備範囲を広げる一方で、インジェストコストと処理負荷が AI 投資の原資を静かに圧迫する構図が、現場のあちこちで見られます。

そこで本記事では、4 月 23 日に行われたセッション「Operating Google SecOps at Extreme Scale: 90,000+ Windows Endpoints」の主要発表を、一聴講者の視点で整理してお届けします。

9 万台超、実際には約 20 万台規模のエンドポイントを OpenTelemetry ベースのパイプラインで束ねる実装アーキテクチャが語られた内容ですので、スケール運用に関心のある方はぜひ最後までお読みください。

※当記事は、Next26 in Lasvegas 開催期間中、その後に新たな情報が判明した場合等に、情報が追記・修正される場合があります。

9 万台超を捌く鍵は「中央集約ゲートウェイ」にある

大規模 SecOps 運用の要は、多様なエンドポイントから流れ込むログを中央のゲートウェイ層で受け止め、そこで整形・減容・振り分けを巻き取る集中管理の設計にある、というのがセッション冒頭のメッセージでした。登壇された Craig Lee 氏（Chief Architect, Bindplane）は、9 万台超（実運用では約 20 万台規模）の Windows エンドポイントを扱う現場で直面する課題を、3 点に整理して提示されました。

1 つ目はエンドポイントの多様性です。
社内ネットワーク、在宅勤務者の家庭回線、VPN 経由の接続と、ログの発信元はバラバラで、宛先に安定してデータを届けるだけでも容易ではありません。Craig 氏はこれを「信頼できる集約点を中央に据え、その後のルーティングと整形を集中管理する」アプローチで解いたとのこと。

2 つ目はコスト管理です。
Windows イベントや Kubernetes のログはサイズが大きく、「シグナル対ノイズ」の選別を常に求められます。使える情報は残し、そうでないものは削ぎ落とす。この取捨選択をパイプライン側で実装できるかどうかが分水嶺になる、と Craig 氏は語られていました。

3 つ目がコンプライアンス対応です。
EU 圏の顧客を中心に最大 7 年間のログ保管要件が存在し、「冷蔵保存」相当の安価なストレージへルーティングする仕組みは必須。SecOps には直近の分析対象ログ、Cloud Storage には長期保管対象、という役割分担を同一パイプラインの設定で管理できる点が、現場運用者として素直に刺さる設計でした。

Fleet で 1 万台単位の論理グルーピングを実現

1 フリート（同種の端末が多数集まったグループを指す言葉）あたり最大 1 万台を束ね、OS・地域・用途などの軸で切り分けるため、20 万台規模でも約 20 フリートで整理できる計算になります。

フリート単位で構成を配信する運用は、ゾーン単位で段階的にロールアウトする際にも利き、大規模配布のリスク抑制という観点でも妥当な粒度設計だと感じました。ラベルには割り当てアプリ、所属フリート、データセンター名が含まれ、後段で SecOps の UDM へ変換されるため、メタデータ設計の質が検索・相関分析の精度へ直結する構造になっています。

ゲートウェイ層が PII 処理とルーティングを集中管理

テレメトリを受け止めるゲートウェイ層は、当初 20 台規模の大型 GCP VM で構成されたものが、現在は GKE への移行が進行中とのことです。

前段に Google のグローバルネットワークロードバランサを置き、OTLP 経由で集約したログを、PII 検出・リダクション、ログタイプ判定、SecOps 向け整形、長期保管用ルーティングと段階的に処理します。エッジ側は薄く広く、重い処理は中央に寄せるという責務分離が綺麗に機能していました。

大注目：Pipeline Intelligence による「AI 下書き」

今回のセッションで一聴講者として最も注目したいのは、デモ終盤に紹介された Pipeline Intelligence の挙動です。ゲートウェイを流れるログを AI が自動的に意味解釈し、SecOps 向け初期設定を「下書き」してくれる機能群で、導入時の最大のボトルネックだった泥臭い初期設計作業を、大きく短縮できる可能性を感じさせました。

デモでは、処理ノードでサンプリングした Windows イベントログに対して、Pipeline Intelligence がログ種別（WinEVT log）と対応する SecOps パーサーを裏側で自動判定。「Standardize Log Type for SecOps」のボタンひとつで、SecOps 投入に適したログタイプ標準化の設定が自動生成されていました。別のプロセッサでは、クレジットカード番号や生年月日といった一般的な PII パターンが標準ルールとして用意されており、正規表現で自社固有パターンも追加できる構成。

ルーティングコネクタを使えば、Windows セキュリティイベントは SecOps へ、それ以外は Google Cloud Logging や GCS（retention_interval: 7 years を付与して長期保管）へ、1 つの設定画面から振り分けられる点も実運用目線で秀逸でした。設定変更は OpAmp 経由でゲートウェイへ即時反映され、構成バージョンが進む様子もデモ中に確認できます。

従来、SecOps 導入における最大の工数はパーサー選定・マッピング・フィルタルール整備といった地味な作業に集中していましたが、AI が初期設計を下書きしてくれるなら、エンジニアはチューニングと例外対応に注力できます。90,000 台規模のロールアウト期間がどれほど短縮できるかを想像すると、スケール運用を志向する組織には十分な訴求力がある機能だと感じました。

Pipeline Intelligence の AI 機能は Bindplane Enterprise の一部として提供され、SecOps Enterprise Plus 契約者にも利用権が付帯する、との案内もありました。一方、セッション直後に司会者から言及があったとおり、Bindplane は Dynatrace による買収が完了したばかり。
Dynatrace の可観測性ポートフォリオと統合されていく中で、SecOps 文脈における位置づけがどう整理されるかは注視したいところです。

個人的には、オブザーバビリティとセキュリティのログパイプラインが OpenTelemetry という共通基盤の上で収斂していく業界トレンドを象徴する動きだと感じており、SOAR や UEBA との統合深化もあわせて追いかけたい論点です。

まとめ

今回のセッションは、エンタープライズの SecOps 運用において、「収集・整形・ルーティング・長期保管」という一連のデータパイプラインを OpenTelemetry ネイティブで組み直す動きが、実運用レベルへ到達しつつあることを示す場となりました。

Fleet による論理分割、ゲートウェイでの PII マスキングと減容、AI による自動ログ解釈という三層アプローチが揃えば、9 万台規模でも単一の運用モデルで管理可能、という実装例が公に示された意味は大きいと思います。日本国内でも、大規模な Windows 端末群を抱える製造業や金融機関、そしてベンダーロックインを避けつつ SecOps 導入を進めたい国内 SIer にとって、参考になる設計論ではないでしょうか。

スケール SecOps のログパイプライン設計や Google Cloud 関連の導入・活用についてより深く議論されたい方は、、Google Cloud Next 26 Tokyo（2026/7/30,31開催予定）での弊社ブース・セッションへぜひお立ち寄りください。現地でみなさまと議論できることをお待ちしております。