---
title: F3 File Format
created: 2026-06-29
updated: 2026-06-29
type: entity
tags: [tool, dev-tool, data-format, reliability, hack]
sources: [raw/articles/f3-file-format-2026.md]
confidence: medium
---

# F3 File Format

F3 は、分析用データを保存するための新しい列指向ファイル形式を試す研究実装。Parquet や ORC のような既存形式が長く使われるなかで、古い配置や拡張しにくさを抱え続ける問題に対し、ファイルの中にデータ、メタデータ、必要なら WebAssembly の復号器まで入れる設計を提案している。

中心にある発想は [[extensible-data-file-formats]]。読み手が符号化方式をすでに知っていればそのまま読める。知らない場合でも、ファイル内の Wasm 復号器を使って読めるようにする。つまり「形式を読むための知識」を、実装や外部仕様だけに置かず、ファイル自身にも持たせる。

## 何が面白いか

- **将来対応の逃げ道**: 新しい圧縮・符号化・配置を試すたびにファイル形式全体を作り直すのではなく、符号化単位ごとに復号器を付ける道を作る。
- **細かい読み出しの設計**: row group、IOUnit/Chunk、EncUnit という階層で、入出力単位と符号化単位を分けて扱う。
- **自己説明性**: Arrow schema、列メタデータ、共有辞書、checksum、Wasm binary、任意メタデータを同じファイルにまとめる。
- **研究としての検証**: `fff-bench` と再現手順があり、Parquet、Vortex、Lance、Nimble、ORC などとの比較を論文側で扱っている。

## 注意点

README は明確に「研究プロトタイプであり本番利用しない」と書いている。実装にも、研究用 API、未整備の再現手順、Debian 12/Intel でのみ試験済みという制約が残っている。現時点では採用候補というより、データ形式の設計案と実験台として読むのがよい。

## Wiki 上の位置づけ

F3 は、[[ghidra-mcp]] が専門道具の操作を MCP の道具層へ寄せたのと少し似ている。どちらも、知識や手順を人間の記憶や prompt だけに置かず、扱う対象の近くに実行可能な形で置こうとする。ただし F3 の対象は逆解析ではなく、長く残るデータファイルそのもの。

また [[llm-wiki-pattern]] が raw source をあとから読める形で残し、合成された知識と出典を分けるのに対し、F3 はデータと読むための手掛かりを同じ保存物に近づける。どちらも「将来の読み手が困らないように、文脈を一緒に残す」設計として見られる。