Skip to content
Office Oxide

Apache Tika からの移行

Apache Tika は膨大な種類のファイル形式 — DOCX、XLSX、PPTX、レガシー DOC、XLS、PPT を含む — からテキストを抽出する事実上の標準 JVM ライブラリです。パイプラインが Office ドキュメント限定 なら、Office Oxide は最適な置き換えです: 同じ 6 形式、JVM なし、ネイティブ速度、シンプルなデプロイ。

いつ移行するか

以下のいずれかが当てはまるなら切り替えを:

  • 取り込みパイプラインが Office ドキュメントだけを扱う（Tika が扱う PDF、EPUB、RTF、ODT などは不要）
  • コンテナ / Lambda / デスクトップアプリで JVM を同梱・チューニングしたくない
  • Java の JAR だけでなく Python、Node.js、Go、C#、Rust のネイティブバインディングが欲しい
  • ファイル単位のレイテンシが重要; Tika の起動コストと JVM ウォームアップは短命ワーカーにつらい
  • LLM と RAG パイプライン向けに構造化された Markdown / IR 出力が欲しい

Tika に留まる方がよい場合:

  • Office Oxide がカバーしないロングテールの形式を取り込んでいる（Tika は約 1,400 種類を扱う）
  • すでに JVM 取り込みサービスがあり、ネイティブバインディングを追加するアーキテクチャ変更が割に合わない
  • ロングテール全体にわたる Tika の MIME 検出に依存

よくある中間案: ロングテールには Tika を残し、.docx / .xlsx / .pptx / .doc / .xls / .ppt（ほとんどのエンタープライズコーパスでボリュームを占める）には Office Oxide を使う。

インストール

Python

pip install office-oxide

（tika または apache-tika の Python ラッパーと、それらを動かしていた JVM を置き換えます。）

Rust

[dependencies]
office_oxide = "0.1.0"

Java

JVM にコミットしているなら、C FFI と JNA / JNR-FFI 経由で Office Oxide を使います。または office_oxide_cli を stdio 越しに呼ぶサイドカープロセスとして実行 — 同じエンジン、JVM ブリッジコード不要。

並べて比較するチートシート — Python

プレーンテキスト

Tika（REST モード）

import tika
from tika import parser

tika.initVM()    # JVM 起動; 初回は ~1-2s
parsed = parser.from_file("report.docx")
text = parsed["content"]
metadata = parsed["metadata"]

office_oxide

from office_oxide import Document

with Document.open("report.docx") as doc:
    text = doc.plain_text()
    props = doc.as_docx().core_properties()    # author、modified など

JVM 起動なし、REST ラウンドトリップなし、ミリ秒未満の抽出。

バイト入力（tempfile なし）

Tika

import io, requests
from tika import parser

data = requests.get(url).content
parsed = parser.from_buffer(io.BytesIO(data))

office_oxide

import requests
from office_oxide import Document

data = requests.get(url).content
with Document.from_bytes(data, "docx") as doc:
    print(doc.plain_text())

サーバー / バッチ処理

Tika — 通常は HTTP の背後で tika-server モードとして実行。

java -jar tika-server.jar -h 0.0.0.0 -p 9998

import requests
text = requests.put("http://localhost:9998/tika",
                     data=open("report.docx", "rb"),
                     headers={"Accept": "text/plain"}).text

office_oxide — JVM もサーバーも捨てて、ライブラリを直接呼ぶだけ。サイドカーアーキテクチャ（言語非依存のクライアント）が必要なら MCP サーバー または stdio 越しの CLI を使ってください。

並べて比較 — JVM ユーザー

パイプラインが Java/Kotlin/Scala で JVM を捨てたくない場合:

  • Office 以外のすべてには Tika を残す。
  • Office 形式には office-oxide を呼ぶ。2 つのオプション:
    • JNA / JNR-FFI で liboffice_oxide と C ヘッダ include/office_oxide_c/office_oxide.h を呼ぶ。Go と C# バインディングが使うのと同じ C API。
    • office_oxide_cli サイドカーを ProcessBuilder 経由で。stdin で入力をストリーム、stdout で出力を読む。再起動が容易で、クラッシュを隔離できる。

どちらも Office 形式で Tika を動かすより速く — JVM オン JVM の奇妙さを避けられます。

Tika 比で得られるもの

Tika Office Oxide
DOCX、XLSX、PPTX ✓ ✓
レガシー DOC、XLS、PPT ✓ ✓
PDF、EPUB、RTF、ODT など ✓ ✗（PDF には pdf_oxide を使用）
プレーンテキスト抽出 ✓ ✓
Markdown 出力 部分的 ✓（組み込み to_markdown）
構造化 IR / JSON XHTML SAX イベント ✓（型付き DocumentIR）
検索置換テンプレート化 ✗ ✓（EditableDocument）
セル書き込み（XLSX） ✗ ✓（set_cell）
レガシー → モダン変換 ✗ ✓（save_as）
JVM 必須 ✓ ✗
ネイティブ速度 JVM オーバーヘッド ファイルあたり <1 ms

パフォーマンス（Office 形式のみ）

100 万ドキュメントの Office 取り込み（DOCX、XLSX、PPTX、DOC、XLS、PPT の混合）を tika-server と比較:

パイプライン ウォール時間 備考
tika-server（REST）、8 ワーカー ~3 h 40 m HTTP オーバーヘッド含む
tika-app（プロセス内 JVM）、8 ワーカー ~1 h 50 m Tika のベストケース
office_oxide、8 ワーカー ~3 m ネイティブ解析

数字は形式の混合によって変わります; 取り込み中心の Office ワークロードでは通常 30–60 倍の差になります。

関連項目