← 2026-11-03 の一覧へ戻るホーム
Tantivy の創作者ポール・マセール氏との対談

2026/11/01 3:26

Tantivy の創作者ポール・マセール氏との対談

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Tantivy の物語は、Java ではなく Rust でハイパフォーマンスな検索エンジンを構築するという決定的な技術選択から始まります。2017 年、東京からパリへの飛行中に『The Rust Programming Language』を読んでいたポール・マシュレルによって作成されたこの軽量ライブラリは、SIMD による圧縮加速、メモリアップマップ I/O、有限状態トランシューダといった高度な技術を駆使し、利用可能な RAM よりも大きなインデックスを処理します。Tantivy は Lucene のライブラリアーキテクチャ（インデクシング、圧縮、検索）を踏襲していますが、配信とオーケストレーションについては Quickwit などの下流システムに委譲しています。

ベンチマーク結果において Tantivy がしばしば Lucene よりも高速であること（場合によっては 2 倍）が示されたことで始まった顕著なコラボレーションにより、両プロジェクトは互いの改良パッチを交換し合うようになりました。プロトタイプは急速に大規模ユースケースへ拡張され、その好例として Binance が採用した 100PB のログ検索サービス（毎日 1.6PB をインデックス化する）が、Tantivy の初期のスケーリングロードマップに影響を与えました。

現在、Tantivy はスケーリングアウト可能なログ検索、誤字許容型クエリ、Postgres などのデータベース拡張のための基盤インフラを駆使しており、Quickwit、LNX、ParadeDB、Turso を含む複数のプロジェクトの土台となっています。2024 年の Datadog への買収（買収前には Quickwit を Tantivy の上で共同設立したポール・マシュレル）以降も、このプロジェクトは Apache ライセンスの下で進化を続け、広範なオープンソースアクセシビリティを保証しつつ、企業が内部でプロプライエタリフォークを利用できるようにします。これらのシステム抽象化が拡大するにつれ、パスカール、トリニティ、スー、ハリーソンといったコントリビューターが開発に大きく影響を与えており、開発者たちは将来の検索技術を形成する業界動向と学術的進展の両方について最新情報を追うことが推奨されます。

本文

フルテキスト検索の再定義：Tantivy の創設者ポール・マシュレへのインタビュー

2026 年 4 月 2 日、ジェームズ・ブラックウッド＝セウェル氏による寄稿。長年にわたり「解決済み」とされていた検索インフラの常識を打破し、Lucene との協力関係を築いた Tantivy の生みの親、ポール・マシュレ氏に話を伺った。

1. 挫折と Rust：Tantivy 誕生のきっかけ

背景：Exalead での挫折経験

  • フランスの検索会社「Exalead」でフロントエンドエンジニアとして働いていた時期、コアチームの一員になれず強い挫折感（フラストレーション）を抱えた。
  • 長期間蓄積されたこの挫折感は、彼にとって強力な原動力となり、検索エンジン開発への情熱に繋がった。

Tantivy の開発：東京からのフライトで始まった冒険

  • 2016 年、東京からパリへ向かう長距離フライト中、ポール氏は「The Rust Programming Language」の書籍を読みながら C++ との違いに魅了された。
  • 直ちに exercism.io で Rust を習得し、Indeed の検索品質チームで働く中で、既存の Lucene 2.4 ベースエンジンへの代わりとして新たな試作を開始する。
  • 当初は「少々馬鹿げた」アイデアだったが、わずか数ヶ月で作成され、その実現可能性が証明された。

設計思想とアーキテクチャ

  • 目標: 「小さなライブラリ」を作ることで、開発者が**ownership（所有感）**を持てる環境を創出すること。
    • Rust を導入して 2 週間後には生産性が向上し、「コードにバグがない」という確信を得た。
  • アーキテクチャ: Lucene のモデル（ライブラリ + サーバーの分離）を採用。
    • インデックス作成、圧縮、検索処理は Tantivy が担当。
    • 分散処理やオーケストレーションは外部システムに委ねる設計となっている。
  • 優先事項: **「Batteries included」だが「最小限」**を維持する方針。
    • Elasticsearch などの大手ソリューションではなく、自前エンジン構築が必要な企業向けに作られた。
    • Java を使うことを避けたいユーザーにとって、カスタマイズ可能なトークナイザーやクエリパーサを提供する代替手段となるよう設計された。

2. パフォーマンスの壁と Lucene との共生

ベンチマークゲーム：猫とマウスの競争

  • 性能差: Tantivy は多くの場合、Lucene よりも2 倍高速。
    • 技術的要因: ターム辞書に有限状態トランジューサ (FST)、逆インデックスに SIMD 加速、メモリマップド I/O レイヤの活用。
    • これにより、利用可能な RAM を超えるサイズのインデックスも問題なく処理可能となった。
  • 検証: 「Search Benchmark, the Game」という再現性の高いベンチマークスイートが作成され、両プロジェクト間で真摯な議論が続いた。

協力関係とトレードオフ

  • パッチの共有: Tantivy からの着想を受けたパッチが Lucene に採用される一方で、Lucene の開発者（Adrien Grand, Mike McCandless）も最適化策を探求し、逆説的に Tantivy との対話を深めた。
  • 現状の認識: 全体的には Lucene が技術的優位性を保つ状況にあるが、この健全な競争は両者に利益をもたらしている。
  • 哲学的立場: 「成功したら見栄を張る（Fake it till you make it）」という姿勢ではなく、オープンソースにおける協力の重要性を強調。

3. Open Source の成長と Quickwit への展開

オープンソース維持の課題

  • コントリビューションの審査:
    • プロジェクトの品質維持と、人々を喜ばせたい願望の間で葛藤する。
    • 機能追加による複雑化を避けるため、ニッチな機能を拒否したり外部実装を推奨したりする傾向があった（現在は緩和）。
  • 買収後の状況: Quickwit が Datadog に買収された後、レビュー時間やエネルギーの確保が困難になっている。

アーキテクチャによるエコシステムの拡大

  • Tantivy はインデックス作成と検索のみを担当し、シャarding やオーケストレーションは下流プロジェクトに委ねる設計だった。
  • このモジュラー性が資産となり、全く異なる目標を持つ製品群の基盤へ成長した：
    • Quickwit: スケーラブルなログ検索エンジン。
    • LNX / ParadeDB: 他社製データベースとの連携。
    • Turso: Postgres 内のトランザクション型検索など。

コントリビューションの質的進化

  • 当初は「不知名兵士の墓」に例えられたような匿名コントリビューターから始まり、現在は Geo 検索などの高度な機能を提供する本格的な PR が提交されるようになっている。

4. Quickwit と Datadog：大規模インフラへの道筋

Quickwit のビジョン転換

  • 初期: Indeed で使っていたリアルタイムアナリティクスツールの再現を目指していた。
  • 変化: S3 上で動作する検索エンジンの適性を発見し、ログ検索エンジンへ方向転換した（アーキテクチャの指引に従った）。
  • スケール: Binance などの大手企業から採用され、100 ピタバイトのログ検索サービスを提供。

Datadog 買収とライセンス戦略 (2024 年)

  • 決定背景: 技術が世界最大級のオブザーバビリティワークロードへ展開されることを可能にした点。
    • 資金調達ラウンドでは得られなかった「大規模環境への即時アクセス」を提供できる点が決定的だった。
  • ライセンス契約:
    • Quickwit は Apache ライセンス下で再ライセンスされた（4 社以上の独立製品開発が可能に）。
    • Datadog 自体のプロプライエタリコードとは分離し、オープンソースへの改善をプッシュする形をとった。

5. 開発者へのメッセージ：「解決済み」の壁を打ち破る

ポール氏の軌跡は、「解決済み」とされる問題を見極め、未解決と再定義するプロセスそのものである。開発者へ向けた助言は以下の通り。

  • 学術界への注視: 新しいアイデアはそこから生まれる。業界に浸透させるためには協力が必要である。
  • メンタルモデルの精査: ソフトウェアは抽象化のマトリョーシカであり、その層構造を研究することで漏れ（価値）を見つけられるようになる。
  • 批判的思考: 業界がなぜ特定解決策に収束したのか、過去ハードウェアの変化など文脈を考慮し、標準ソリューションへの盲信を避けること。

「Tantivy の物語はあなたにフライト上で始まったものですが、年々多くの人が関与してきました。あなたのビジョンの形成にもたらした影響を与えた他の人物は誰ですか？」 Quickwit メンバー（Pascal, Trinity）、Stuhood、ChillFish8 といった多くの仲間たちの尽力が、プロジェクトを生き延びさせた原動力だったと語る。

同じ日のほかのニュース

一覧に戻る →

2026/11/03 3:21

Astra は、Qwen の改善のために重みを読み書きできます。

## Japanese Translation: このテキストにおける最も重大な突破は、「Weight-Space Programming（ウェイトスペースプログラミング）」という技術の導入であり、GPT-6 Astra によって具現化されたものであり、自然言語プロンプトを通じてニューラルネットワークのウェイトを直接読み書きすることを可能にする。この機能は従来の手法とは異なり、重み行列をコードとして扱い、従来のトレーニングデータや勾配を用いないで編集できるようにする。 8 つの実験からのエビデンスがこの技術の力を裏付けている： 1. **解釈可能性:** Astra は、Atari ネットワーク（例：Breakout、Pong）におけるゲームの目標を、生ウェイトのみを解析することで特定したほか、拡散モデルの出力形状を予測し、小型トランスフォーマーモデルにおいてフォワードパスを実行せずに言語や「コピーヘッド」を検出することに成功した。 2. **修復と生成:** カート制御ネットワークにおけるローカル最小値の失敗を、ウェイトの一部を編集することで是正し、Atari ゲームおよび将棋（Go）に対して、ゼロから高パフォーマンスのアルゴリズムを生成した（百万ステップ以上トレーニングされた PPO モデルを凌駕）。 3. **診断と改善:** Astra は、既存モデル（Qwen3.5）に潜むシコフィアンシー（sycophancy）や数学的推論の弱点といった隠れた問題を成功裏に診断し、失敗を引き起こす特定の内部方向性を特定して除去することで、パフォーマンススコアを大幅に向上させた。 この技術は「ゼロデータ能力ステアリング」、recursive self-improvement（自己改善）、およびバックドアなどのリスクに対する徹底的な監査を可能にする一方で、明確な限界が存在する：それは、基礎的な能力を欠くシステムに対して新たにそのような能力を自動的に付与することはできない（例：Gemma 3 の数学的性能の向上には失敗）。結局のところ、ウェイトスペースプログラミングは、特定の修復のために大規模なデータセットへの依存を迂回させつつ、厳格な内部監査を可能にすることで、AI の開発を根本的に変革する。

2026/11/02 22:25

愛するウェブサイトならバックアップを取っておくべきです。

## Japanese Translation: 最も重要な教訓は、ウェブサイトが消滅する前に個人がアーカイブ化の責任を引き受ける必要があるという点です。元のホストに依存することは、デジタル上の記憶をハイジャックや削除に対して脆弱にさせるためです。この緊急な必要性は、2004 年から活動していたアニメおよび Ochaken トイラインのファンサイトである teapuppies.com の突然の消滅によって強調されました。著者はアーカイブ化を行わなかったため、同サイトがオフラインになり、後にギャンブル広告に置き換えられました。投稿では、ウェブサイトが消える前に保存について個人の制御を維持するために、標準形式（WARC/WACZ）を用いた個人ウェブアーカイブ化を推奨しています。具体的な 3 つの主なワークフローは以下の通りです。(1) ArchiveWeb.page Chrome 拡張機能：この拡張機能をインストールし、ページにアクセスし、「Start Archiving」をクリックしてコンテンツと対話し、ツールバーから停止することで、単一ページ、サイト全体、または SNS プロフィールを保存できます。アーカイブはダッシュボードでプレビューでき、WARC ファイルとしてローカルでの表示や共有のためにダウンロード可能です。(2) 独立した ArchiveWeb.page アプリ：ブラウザ拡張機能と同様に機能しますが、独自のウェブブラウザを含み、直接アーカイブメニューに開きます。(3) Browsertrix：開始 URL（例：teapuppies.mistys-internet.website）からリンクをたどりながら大きなウェブサイトや SNS プロフィールを自動的にクロールするために推奨されます。設定を通じて /episodes/ セクションや単一ページ（関連する全コンテンツを含む）など特定のセクションを対象としてカスタマイズできます。アーカイブされたコンテンツは、内蔵インターフェースを使用してブラウザで再生するか、WARC/WACZ ファイルを ArchiveWeb.page アプリまたは ReplayWeb.page ウェブサイトに読み込んでプライベートに共有できます。公開共有については、オープンソースの ReplayWeb.page インプット機能を使用することで、アップロードしたアーカイブファイルと JavaScript のみを必要としてウェブページに再生ビューアを追加できます。バックアップデータは単一の WACZ ファイルにまとめられており、複数のコピーで安全に保存したり、友人間で配布したりすることが容易になります。著者はこれらのツールが雇用主によって開発されたことを開示し、ほとんどが無料（Browsertrix は有料サービスを提供しており、7 日間の試用期間があり、その後は使用回数による課金制）であることを注記し、それらを個人ウェブアーカイブ化のための最良の選択肢として推奨しています。

2026/11/03 2:05

Launch HN: Momentic（YC W24）– ユーザーのアプリを利用してバグを検知するエージェント

## Japanese Translation: Mo は、エンドツーエンドのテストを自動化し、リリース前にバグを捕捉する、一般利用可能な AI エージェントとして、ソフトウェア品質保証における大きな飛躍を表します。従来のツールとは異なり、Mo は動的な知識基盤とアプリグラフマッピングを活用して複雑な画面フローを理解することで、検証を開発ループに直接統合します。これは、「代理型品質プラットフォーム」として機能し、検証がエージェントループに内在しています。 该系统は大幅な効率向上を実現します：ユーザーはテストの作成/維持において **3 倍の高速化** を報告しており（日常サイクルを数時間から数分に短縮）、また **6.3 倍のパラレルテスト実行** を達成しています。Mo は UI 変化を自動的に修復し、800 万回以上の自動修復が確認されており、Notion や Webflow などの大手企業向けに約 7,070 万回のテスト実行を完了させています。数百の手動ケースを取り替え、CI パイプライン内でステップ単位の失敗エビデンスを提供することでデバッグを簡素化します。 ベンチマークにおいて、Mo は他のエージェントよりも顕著に優れており、例えば多様なプロジェクトを対象とした QA ベンチテストでは、次点のエージェントが約 86 件のバグを検出したのに対し、Mo は 60 分間に約 269 件のバグを特定しました。具体的な成果には、2 段階認証のプロンプトスキップや破損したモバイルフローなどの重要なロジックエラーの捕捉が含まれます。该平台は簡素化されたワークフローを提供し、ユーザーが自然言語（YAML）でテストを記述でき、AI 駆動のトリアージと修復を開発パイプラインにシームレスに統合することを可能にします。