Artemis SecurityがClickHouse Cloudで検出クエリを69倍高速に実行する方法

今日のサイバー脅威の状況は根本的に変化しました。攻撃者はAIを活用してより速く動き、より深く探り、従来のSIEMが前提としていたシグネチャベースの検知ルールを回避しています。これにより、レガシーツールが追いつくことがますます難しくなっています。

Artemisは、この新しい現実のために構築されたAIネイティブな脅威検知プラットフォームです。共同創業者兼CTOのDan Shieblerは次のように説明します。「私たちは、クラウド、アイデンティティ、ネットワーク、エンドポイントといったさまざまなソースからのすべてのログとテレメトリを取り込み、リアルタイム分析を行って潜在的なサイバー攻撃やその他の異常な挙動を特定するために、企業と協力しています。」静的なルールに頼るのではなく、検知はAIエージェントが継続的に受信データにクエリを実行し、潜在的な脅威を調査し、セキュリティチームにケースを浮上させることで処理されます。

ニューヨークを拠点とするこのスタートアップは、2026年4月にステルスから出て7,000万ドルの資金調達を発表し、すでにWix、Mercury、Lemonade、Upworkなどの企業のセキュリティチームから信頼を得ています。「その結果、私たちは膨大な量のデータを取り込み、処理しています」とDanは言います。「私たちが直面する最も難しい問題は、データプレーンでの問題です。」

Artemisは毎日、数テラバイトの圧縮されたログデータ(数百億行)を取り込み、数兆行に対して数百万件のクエリを実行しています。検知ルールは、最新の受信データに対して継続的に実行され、すべての顧客環境における個々の挙動パターンをスキャンします。「悪意のあるものを見つけて、『自分の管理下のどこか他に類似のものの兆候はないか?』と問うことがあるかもしれません」とDanは言います。「そういった干し草の中の針のようなものを、非常に迅速に浮かび上がらせる必要があります。」

ある挙動が異常であるかどうかを理解するには、以前に発生したことがあるかどうかを知る必要があるため、システムはリアルタイムで数か月分の履歴データを集約する必要もあります。ユーザーはこのIPアドレスから以前にログインしたことがあるか?この一連のイベントはこの組織にとって正常か?さらに厄介なことに、ログは何十もの異なるシステムやテレメトリソースから届きます。Danが指摘するように、これは「進化するセミ構造化スキーマ上で集約を実行できるシステムを構築しようとする際の、一貫した困難な点」でした。

DanとArtemisのソフトウェアエンジニアであるSergeyは、2026年4月のNYCでのClickHouseミートアップで講演し、Artemisが組織を安全に保つためにAWS上のClickHouse Cloudをどのように活用しているか、そしてプラットフォームをさらに高速かつ効率的にした3つのエンジニアリング上の解決策を共有しました。

解決策 #1: クエリのコアレシングによる69倍高速な検知 #

Artemisは顧客ごとに数百の検知ルールを実行しており、それぞれが最新のログデータのローリングウィンドウをスキャンして特定のパターン(例:削除されたIAMポリシー、新しく作成されたアクセスキー、疑わしいログインシーケンス)を探すSQLクエリです。素朴な実装では、顧客あたり150ルールがサイクルごとに数千のクエリになり、それぞれが同じデータ範囲を独立してスキャンすることになります。DanとSergeyが述べるように、そのオーバーヘッドは乗算的に増えていきます。

修正のきっかけは、Danがチームに次のように尋ねたことです。「これらすべてのルールが同じデータの同じ時間ウィンドウをクエリしているなら、なぜ1つのクエリとして実行しないのか?」彼らが構築したこの技術は「クエリコアレシング」と呼ばれ、ClickHouseのネイティブ関数を使用して、個々のルールの述語をすべて1つのクエリに結合し、データを一度スキャンして、一致する各行にトリガーしたルールIDをタグ付けします。「500個のクエリの代わりに1つのクエリだけを実行します」とSergeyは言います。

ClickHouseの内部キャッシュを考慮すると、Sergeyはどんな性能向上もささやかなものになると想定していました。しかし、簡単なPOCを実行したとき、彼は「クレイジーな結果になった」と言います。1つのコアレスされたクエリは、173秒に対して2.5秒で完了しました——69倍高速で、CPUは46分の1、メモリI/Oは100分の1です。本番環境では、100を超える検知ルールのバッチが1秒未満で実行されるようになりました。150個のCloudTrailルールを持つ顧客は、150個の独立したクエリの代わりに、わずか2つのコアレスされたバッチを実行するだけです。

とはいえ、Sergeyは「簡単な実験を実行したときに見えるほど、物事は必ずしも簡単ではない」と指摘します。まず、すべてのクエリをコアレスできるわけではありません。CTE、JOIN、GROUP BY、LIMIT、サブクエリ、およびラムダは、ARRAY JOINの内部ですべて破綻します。そこでチームは、手動オプトインを必要とせずに約15%のルールを自動的に除外する軽量なランタイム分類器を構築しました。

また、ClickHouseの256 KBのmax_query_size制限にも遭遇しました。修正としては、制限を1 MBに引き上げ、バイナリスプリットのフォールバックを備えたサイズを認識するバッチ処理を追加しました。バッチが失敗した場合、システムはそれを半分に分割して問題のあるルールを分離するため、1つの不正なクエリがバッチ全体を汚染することはありません。

Sergeyは、このシステムが継続的なメンテナンスを必要とすることを認めています。セキュリティリサーチチームは分類器のヒューリスティックを押し広げるようなクエリを定期的に書いており、コアレシング率を高く保つには、新しいエッジケースに合わせて定期的にチューニングする必要があります。「これはプラットフォームの安定性への投資であり、設定して忘れるようなものではありません」と彼は言います。「全体として、非常に価値があると考えています。多くの場合、最大の成果をもたらすのは、素晴らしいClickHouseソリューションアーキテクトと協力したり、ドキュメントを読んだり、スキーマの最適化を行ったりすることではありません。ときには一歩引いて、自分のアプリケーションの使い方を見つめ直すことも報われるのです。」

解決策 #2: ClaudeによるAI駆動のClickHouseデバッグ #

高スループットのClickHouseデプロイメントでのパフォーマンス問題の診断は、決して単純ではありません。Artemisにとって、何が問題だったかを理解することは、ClickHouseのシステムテーブル、CloudWatchメトリクス、Datadogダッシュボード、アプリケーションデータベース、およびソースコード全体でシグナルを相関させることを意味します。それを手動で行うには時間がかかり、インフラストラクチャの深い知識が必要で、経験豊富なエンジニアでもエラーが発生しやすい作業です。

Artemisの解決策は、「/poke」と呼ぶClaude Codeのスキル(オフィスでお気に入りの食べ物の1つにちなんで一部命名されました)で、これらすべてのシステムを1つのインターフェースにまとめる単一のデバッグコマンドです。自然言語のプロンプトだけで、自律的な調査を開始するのに十分です。Sergeyは1日に約20回これを実行していると言い、チームのインフラストラクチャデバッグ用の「スイスアーミーナイフコマンド」と呼んでいます。

/pokeスキルは、ClickHouseシステムテーブルのクエリ例、内部アーキテクチャドキュメントへの参照、および関連するソースコードへのポインタを含む比較的シンプルなmarkdownファイル上に構築されています。そのコンテキストがあれば、Claudeは自律的にクエリを生成し、複数のシステムからデータを取得し、結果を加工するためのPythonおよびbashスクリプトをその場で書き、実行可能な推奨事項を浮上させるのに十分です。「驚くほどうまく機能します」とSergeyは言います。

Artemisの専用の「バースト」ClickHouseインスタンス(高価なエージェント調査クエリをメインの取り込みパイプラインから分離するために使用)が劣化し始めたとき、Sergeyは「昔ながらの方法」でデバッグするか、/pokeを使うかの選択がありました。後者を選び、90秒で5語のプロンプト(/poke "burst instance performance degraded")が、Claudeにsystem.processesをクエリして長時間実行中のクエリを見つけさせ、8 GiB以上のメモリを消費し時間制限なしで42 TiBを読み取っている調査クエリを発見させ、アプリデータベースを相互参照してどのケース調査がそれを引き起こしたかを特定させ、修復のための手順(クエリを終了し、時間制限のガードレールを追加し、ユーザーごとのメモリ制限を設定する)を提案させるのをトリガーしました。

「/pokeコマンドを使えば、エンジニアリング経験のないチームメンバーでも、私が手動でやっていたよりも良い仕事を、はるかに速く行うことができます」とSergeyは言います。「LLM、特に最新のイテレーションは、ClickHouseとの連携において驚くほど得意です。」

解決策 #3: マテリアライズド抽出による30〜60倍高速な調査クエリ #

3つ目の最適化は、Sergeyが述べるように、AIそのものというよりは、データベース関連のトークでよく聞く話です。「私たちはデータベースで何かをやり、今ではすべてのクエリがはるかに高速になりました——そういう話です」と彼は冗談を言います。

問題は調査クエリのパフォーマンスでした。これらは、Artemisの調査エージェントとセキュリティアナリストが依存する干し草の中の針のような検索です(例:特定のIPアドレスに関わるすべてのイベントの発見、過去30日間のユーザーのアクティビティの追跡、狭い時間ウィンドウ内の異常の浮上)。これらのクエリの速度は、進行中の攻撃を捉えるか、事後に再構築するかの違いにつながる可能性があります。

根本原因は、Artemisが受信ログ形式の多様性を処理するためにClickHouseのJSONカラムを使用していたことでした。数十のソースタイプがすべて単一のマルチテナントSharedMergeTreeテーブルに着地する状況で、JSONカラムは「表面的にはユースケースに理想的にマッチする」とSergeyは言います。事前の正規化を必要とせずに絶えず進化するスキーマに対応できる柔軟性があります。しかし、JSONカラムに対するすべてのクエリは読み取り時にパースされ、深くネストされたフィールドをインデックス化する効率的な方法はなく、パフォーマンスの問題につながります。

ClickHouseのソリューションアーキテクトと反復的に作業して、Sergeyとチームは解決策としてマテリアライズドビューにたどり着きました。メインテーブルを変更するのではなく(Sergeyが指摘するように、稼働中の本番テーブルでのDDL操作は「時に理想的ではなく、時にリスクがある」)、最も頻繁にクエリされるサブカラムをネイティブClickHouse型を持つ並列テーブルに抽出し、INSERTごとに自動的に投入されるようにしました。

また、「ハイブリッド2ステップ」クエリパターンも開発しました。まず抽出テーブルでフィルタリングして狭い時間範囲を見つけ、次にそのスライスに対してのみフルJSONテーブルをクエリします。これにより、完全なスキーマへのアクセスを犠牲にすることなく、高速な検索が可能になります。

このアプローチにより、ステータスとイベントコードでのフィルタリングは、メインテーブルでの約12秒から、抽出テーブルでの0.2秒に短縮されました。これは60倍の高速化です。ソースIPによるグループ化は45秒から1.5秒に短縮され、クエリあたりのCPU消費量はワークロードに応じて60倍から400倍削減され、Sergeyが「大幅な削減」と呼ぶものになりました。

AI駆動サイバーセキュリティの未来を構築する #

Artemisのユーザーベースは急速に拡大しており、データ量は毎週増加しており、対抗する脅威の状況もそれと同じくらい急速に高度化しています。

DanとSergeyが共有した3つの最適化は、コストや複雑さを比例的に増やすことなくスケールするように構築されたインフラストラクチャレイヤーの一部です。検知クエリは69倍高速に実行され、かつて45秒かかった調査ルックアップは2秒未満で完了し、チームのどのエンジニアも、ClickHouseの経験に関係なく、数分でインフラストラクチャの問題を診断して解決できます。

「私たちは非常に急速に成長しています」とDanは言います。ClickHouse Cloudを使用することで、データが増加するにつれて高速かつ効率的になるデータ基盤を持ち、Artemisは阻止するために構築されたAI駆動の攻撃者の一歩先を行くことができます。