Xikipedia: DuckDB×WASMでWikipediaをフィード化

この記事の注目ポイント： WikipediaをSNS風の無限スクロールフィードに再構築した実験サイト「Xikipedia」が公開されたよ。ブラウザ内でDuckDBをWebAssemblyで実行し、S3上のParquet（約40MB）を初期ロードしてクライアント側でフィードを生成するアプローチだ。アルゴリズムではなくユーザーの操作でローカルにフィード調整することで、プライバシー重視の「doomscrolling代替」を狙っているんだ。

3分で読めるように、デザインと実装の観点からポイントをわかりやすく解説するよ。デザイナー、フロントエンド、PMそれぞれに刺さる実務的な示唆をまとめたよ。

深掘り解説
まとめ
1. 参考リンク

深掘り解説

何が新しいかを端的に言うと、Wikipediaコンテンツを無限スクロールのフィード形式に変えた点だよ。UIはTwitter/TikTok風で、アルゴリズムフィードは使わず、ランダムやユーザーのインタラクションに基づいて表示順を調整する設計になっている。

技術の肝は、ブラウザで動くDuckDB（WASMビルド）と、S3に置かれたParquetファイルを初期ロードする仕組みだ。約40MBの圧縮データをクライアントに読み込み、リンク関係のマッピングやクエリをブラウザ内で実行してフィードを生成している。

この設計のメリットは、サーバー側での大規模なユーザーデータ収集を不要にする点。MLモデルや外部レコメンドに頼らず、プライバシーを保ちながら「各ユーザーごとの調整」をローカルで実現できるんだ。

もちろんトレードオフもある。初期ロードで数十MBのデータを取得するため、トラフィック急増時に遅延や帯域問題が発生しやすい。サーバー負荷を避けるためにデータをS3でホストしてるけど、スケール時の配慮（CDNや段階的ロード）が必要になる場面があるね。

デザイン面で注目すべきは、無限スクロールという強力な消費行動を「知識摂取」に向ける試みだということ。倫理的なパーソナライズ（アルゴリズム非依存）や、短いスニペット中心のUIは、プロトタイプとして非常に参考になるよ。

まとめ

Xikipediaは、DuckDB＋WASMでブラウザ内に大規模データ処理基盤を置くというアイデアを実践した良いケーススタディだ。デザイナーは無限スクロールのUX設計と注意経済の倫理を議論できるし、エンジニアはクライアントサイドでのSQL処理・Parquet運用の実装課題を学べる。

実務で試すなら、小さめのParquetサンプルでプロトタイプを作って、ロード時間・メモリ挙動・オフライン感のUXを確かめるのがおすすめ。プライバシー重視のフィードや、アルゴリズム依存を下げたいプロダクトにはヒントが多いはずだよ。

参考リンク

※内容の正確性には万全を期していますが、最新の仕様や公式情報については、必ず上記の参考リンク先をご確認ください。