ClickHouse 2026年5月1日公式ブログ解説: Qonto の observability 事例

ClickHouse は 2026年5月1日の公式ブログで、Qonto が ClickHouse Cloud を使って observability 基盤を見直した事例を公開しました。サンプリングや短い保持期間に制限された運用から、より長い query window と高圧縮の分析基盤へ移る話として読めます。

要点

• Qonto は observability の query window や sampling 制約を見直すため ClickHouse Cloud を活用している
• 記事では、2週間の query window、高 cardinality data の圧縮、AI incident companion などが示されている
• ログやトレースの保持・検索・調査体験を、コストと性能の両面で再設計する話
• ClickHouse の強みを、一般的な analytics だけでなく observability 運用へ広げる事例

今回のブログ記事で語られていること

このブログ記事は、Qonto の observability チームが直面していた制約を起点にしています。大規模なログ、トレース、イベントを扱う環境では、データ量が増えるほど保持期間、sampling、query latency、コストの間で妥協が生まれます。短い window しか見られない、細かいデータを捨てざるを得ない、障害調査で必要な過去データに届かない、といった問題は、observability 基盤ではよく起きます。Qonto の事例は、その制約を ClickHouse Cloud によってどう緩めたかを紹介しています。

記事で示されている重要なポイントは、単に ClickHouse は速い という話ではありません。高 cardinality な observability data を効率よく圧縮し、長めの query window を確保し、調査時に必要なデータをより直接検索できることが、運用の意思決定を変えるという話です。特に incident response では、直近数時間だけでなく、過去数日から数週間の傾向、類似インシデント、deployment との関係、ユーザー影響の広がりを見たい場面があります。そのとき、データをあらかじめ捨ててしまう設計だと、原因分析も再発防止も浅くなります。

また、記事は AI incident companion にも触れています。これは observability data を AI で要約・調査支援する方向性を示すものです。ただし、AI が有効に働くには、元になるログやメトリクスが十分に保持され、検索可能で、意味のある粒度で保存されている必要があります。つまり AI observability は、モデルだけでなく、基盤側の queryability と data retention に依存します。ClickHouse の事例として読むと、AI 活用の前に分析可能な observability store を作ることの重要性が見えてきます。

対象になりそうなユーザー・チーム

• 高 cardinality なログ・イベント・トレースを扱う SRE / platform team
• observability cost と保持期間のバランスに悩むデータ基盤チーム
• incident investigation に AI 支援を入れたい運用チーム
• ClickHouse Cloud を analytics 以外の operational workload に使えるか検討している人

実務で確認したいポイント

まず、自社の observability data で本当に捨ててよいデータと、障害調査で後から必要になるデータを分けたいところです。sampling や短期保持でコストを抑えている場合、その判断が調査品質を落としていないかを確認します。

次に、AI で incident support をしたいなら、検索可能な履歴、構造化された event、deployment metadata、service ownership などを一緒に整える必要があります。AI companion は、十分な context がなければ便利な要約以上にはなりません。

結局、このブログをどう読むべきか

Qonto の事例は、ClickHouse Cloud を observability の長期・高粒度分析基盤として使う方向を示しています。ログを安く保存する話ではなく、障害調査と AI 支援に耐えるだけのデータ保持と query 性能をどう作るか、という実務的な読み方が有益です。