Logfireのクエリが一部で「30秒でタイムアウト」していたものが「1秒未満」で終わるようになりました。1,000倍という数字自体よりも、JSONという柔軟なデータ形式をどう保存し直すかという地味な設計変更がここまでの差を生んだ点が今回の見どころです。今日はPydanticチームが公開した、観測データ基盤の設計変更を掘り下げます。
Logfireの1,000倍速、JSON属性を列に分解する発想転換
Pydantic社のLogfireは、アプリケーションの動作記録(OpenTelemetryデータ)を保存・検索するサービスです。同社が公開した技術ブログによると、同社はdynamic shredding(動的シュレディング)と呼ぶ最適化によって、クエリ速度を「場合によっては1,000倍以上」高速化したとしています。早期アクセスの顧客からは「クエリが基本的に瞬時に感じる」という声が上がったと紹介されています。この機能は2026年2月から全顧客への展開が始まる予定です。
比較の軸を置くと分かりやすくなります。従来は30秒でタイムアウトしていたクエリが、今回の変更後は1秒未満で完了するようになったとブログは述べています。つまり「速くなった」というより「終わらなかった処理が終わるようになった」という変化です。これは単なる微調整ではなく、クエリの実行時間という体感を根本的に変える規模の改善だと読めます。
かみ砕いて言えば、Logfireが扱うデータには、タイムスタンプやスパン名のように形が決まっている部分と、アプリケーションごとに中身が変わる「attributes（属性）」と呼ばれる自由形式の部分があります。この属性は、HTTPステータスコードやユーザーIDなど、サービスによって何が入っているか異なるキーと値の組み合わせです。出典記事によると、Logfireはこれまでこの属性データをJSON形式のまま1つの列にまとめて保存し、クエリの際にJiterという高速パーサーで読み解いていました。
Jiterは実はPydanticチーム自身が開発したJSON解析ライブラリです。GitHubで公開されているこのライブラリについて、出典記事は「数ある言語の中でも最速クラス」のJSONパーサーだと紹介しています。つまりLogfireは、パースという「作業そのもの」を速くする方向で最適化を重ねてきたわけです。しかし出典記事は、ここに根本的な見誤りがあったと振り返っています。パースを速くしても、パースという作業自体を避けることはできません。たとえるなら、毎回分厚いマニュアルを高速に読む技術を磨くのではなく、よく使うページだけを別の付箋付きファイルに分けておく方が速い、という発想の転換です。
出典記事が挙げる問題点は3つです。1つは圧縮効率の低下。中身が毎回変わるJSONの列は、Parquet形式の辞書圧縮が効きにくく、zstdのような汎用圧縮でも苦戦するとされています。2つ目はJSON記法自体のオーバーヘッド。3つ目が最大の要因で、Logfireのデータはオブジェクトストレージに保存されているため、大きなJSONの塊をダウンロードする通信そのもの、特にその開始にかかる遅延がクエリ時間の大半を占めていたと説明されています。CPUの処理速度よりも、データを取りに行く往復がボトルネックだったという指摘です。
PydanticのJSON列分解と型推定、Parquet Variant型は採用予定
ここからが本題の「shredding（シュレディング)」です。出典記事の説明によれば、頻繁に使われる属性をJSONの塊から取り出し、個別の型付き列として保存し直すことで、無駄な作業そのものを避ける設計にしたとされています。属性ごとに専用の列があれば、クエリ側はその列だけを読み込めばよく、JSONを都度解析する必要がなくなります。
Parquetには標準仕様としてVariant型が存在します。Apache Parquetの公式ドキュメントによると、Variant型は半構造化データ(JSONのようなデータ)を効率的にパスごとにクエリできるようにする2進エンコード方式で、Variantフィールドの一部要素を個別の列として取り出すことを「shredding」と呼ぶと定義されています。別の言い方をすれば、JSONの中の特定のキーだけを独立した列に"抜き出す"ための業界標準の仕組みが、もともと存在していたということです。LavX Newsの報道によると、今回シュレディングの対象にならなかった残りのJSON部分について、Logfireは今後このParquet Variant型を採用する計画だとされています。Parquet公式ドキュメントでは、Variant型の設計がParquetファイル内でネストの深い構造でも効率的なアクセスを可能にすると説明されています。
別媒体のLavX Newsが報じた詳細によると、実装の中身はもう少し具体的です。Logfireは各Parquetファイルの書き込み時に、データサイズ合計で上位128個の属性を自動的に特定し、個別列へ分解するとされています。残りはJSON列にそのまま残ります。この上限は、アプリケーションが誤って1,000個もの動的キーをログに出力してしまうような極端なケースで、スキーマが際限なく膨張するのを防ぐためだと報じられています。
型の扱いにも工夫があります。同じ属性が行によって整数だったり文字列だったりする場合は、widening（型の拡大）というルールに従って、最終的にJSON文字列として格納されます。一方、常に同じ型であれば、Arrowのネイティブ型としてそのまま保存され、パース処理自体が不要になります。LavX Newsの報道では、この仕組みによってクエリエンジンは不要なファイルやデータ塊を丸ごと読み飛ばせるようになり、列ごとの読み込みで必要な属性列だけをダウンロードでき、均質なデータゆえに辞書圧縮とzstdの効率が上がり、型付き列であればパース処理自体がゼロになるという4つの効果が重なって速度が出ると説明されています。
同じ報道によれば、この実装にはApache ArrowのクエリエンジンであるDataFusionへの貢献がおよそ半年にわたって必要だったとされ、JSONアクセサ向けの述語プッシュダウンなどの変更は2026年1月リリースのDataFusion 52.1.0に反映されています。GROUP BYやSELECT句からの処理を読み込み段階に押し込む残りの作業は、2026年2月までに完了する見込みだと報じられています。
用語補足：シュレディング（shredding）とParquet Variant型
シュレディングとは、JSON のような柔軟な形式のデータから、よく使われる項目だけを取り出して専用の列として保存し直す処理を指します。Parquet公式ドキュメントが定義する業界標準の手法で、Logfireに限った独自技術ではありません。この補足のポイントは、シュレディングが「JSONを使わなくする」技術ではない点です。あくまで一部の項目を列として抜き出し、残りはJSONのまま保持する仕組みです。今回の1,000倍という数字は、出典記事によれば「場合によっては」観測された改善であり、すべてのクエリが同じ倍率で速くなるとは出典記事からは読み取れません。
このデータ構造変更について、顧客側での設定作業は不要だと出典記事は述べています。2026年2月からの展開開始後、既存の使い方を続けるだけで効果が及ぶとされています。
観測データの保存形式を変えるだけでここまでの差が出るという事実は、クラウドで大量のログやメトリクスを扱っている企業にとって、自社のデータ基盤がどこにボトルネックを抱えているかを点検する材料になるかもしれません。ただし、今回の改善幅は早期アクセス顧客の体感談と、技術ブログの説明に基づくものです。自社のデータ量やクエリパターンでどの程度の差になるかは、出典記事だけでは判断できません。
注目ニュース
MicrosoftのMaia 300、2027年からGPU依存を減らす
Microsoftは自社開発のAI推論チップ「Maia 300」を発表しました。The Vergeの報道によると、2027年から本番環境への展開を開始し、同社のクラウド部門を率いるScott Guthrie氏は「主要GPUベースシステムと比べてメガワットあたりのトークン処理数が40%多い」と述べています。さらに96アクセラレータ構成では、前世代のMaia 200と比べてラックあたりのトークンスループットが最大7倍になるとされています。Guthrie氏は2027年以降、MaiaをMicrosoft製品・サービスの「主要なAI推論システム」として多ギガワット規模で展開し、NvidiaやAMDのチップへの依存を減らす方針を示しています。現行のMaia 200は既にMicrosoft CopilotやGitHub Copilotなど実際のサービスで稼働しているとGuthrie氏は説明しています。新アーキテクチャはTSMCのN2Pプロセスを採用し、演算・メモリ制御・入出力の機能を分離するchiplet構造を取り入れているとされています。The Verge
編集後記：JSONを「速く読む」から「読まなくて済む形で置く」へ
今回のLogfireの話で印象に残るのは、Pydanticチームが自ら作った高性能パーサーJiterを否定したわけではなく、「パースという作業の前提」そのものを見直した点です。処理速度の改善と、処理そのものを避ける設計は、似ているようで別の問題です。同社は従来は前者を追求し、今回は後者に手をつけました。オブジェクトストレージからのダウンロード遅延がボトルネックだったという指摘も具体的で、計算資源よりも通信の往復がボトルネックになりやすいという、クラウド時代のデータ基盤特有の事情を映しています。2月の全顧客展開後、実際にどの程度の体感差が出るかは、出典記事の範囲では分かりません。