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 startup; ~1-2s on first call
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, etc.

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

バイト入力（一時ファイル不要）

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 です。
    • ProcessBuilder 経由で office_oxide_cli サイドカーを起動する。stdin で入力を流し、stdout で出力を受け取る。再起動が簡単で、クラッシュを隔離できます。

どちらも Office 形式において Tika より高速で、JVM on JVM の奇妙な挙動も回避できます。

Tika との機能比較

Tika Office Oxide
DOCX, XLSX, PPTX ✓ ✓
Legacy DOC, XLS, PPT ✓ ✓
PDF, EPUB, RTF, ODT, etc. ✓ ✗（PDF は pdf_oxide を使用）
プレーンテキスト抽出 ✓ ✓
Markdown 出力 部分的 ✓（組み込み to_markdown）
構造化 IR / JSON XHTML SAX イベント ✓（型付き DocumentIR）
検索・置換テンプレート ✗ ✓（EditableDocument）
セル書き込み（XLSX） ✗ ✓（set_cell）
旧形式 → 新形式変換 ✗ ✓（save_as）
JVM 必要 ✓ ✗
ネイティブ速度 JVM オーバーヘッド ファイルあたり 1ms 未満

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

DOCX・XLSX・PPTX・DOC・XLS・PPT が混在する 100 万件の Office 取り込みを 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 倍の差が出ます。

関連ドキュメント