officeParserはNode.jsとブラウザの両方で動作するドキュメント解析ライブラリだ。docx・xlsx・pptx・PDF・RTFなど8形式に対応し、npmで週約23万ダウンロードを記録している。2026年4月14日にリリースされたv6.1.0では、OCRスケジューラーの強化・fflateによるzip展開の高速化・ESMネイティブサポートが実装され、プロダクション用途での安定性が大きく向上した。単純なテキスト抽出ツールではなく、書式・見出し階層・表・画像などの構造を保持したAST（Abstract Syntax Tree）形式でドキュメントを出力する点が最大の特徴だ。
この記事ではofficeParserに特化して解説します。RAG全般の仕組みは RAGとは？仕組み・構築・ベクトルDB選定まで【2026年完全ガイド】 をご覧ください。
officeParserが必要とされる背景：「テキスト抽出」だけでは足りない理由
RAGシステムの精度は、ドキュメントの前処理品質に直結する。Wordファイルを単純にテキストとして取り出すと、「第3章 セキュリティ設計」という見出しも「手順1. 環境変数を設定する」という箇条書きの一項目も、等価な文字列として扱われてしまう。これではベクトル検索で構造的な文脈が失われる。
たとえばExcelの販売データを想定すると、「商品名：ノートPC、価格：98,000円、在庫：12台」という表の1行は、テキストとして展開すると意味のない文字列の羅列になる。一方ASTで取得すれば行・セルの構造が保持され、「98,000円」がどのカラムのデータかを正確にRAGへ渡せる。
officeParserが週23万ダウンロードを獲得しているのは、この「構造付きドキュメント解析」という実需に応えているからだ。テキスト抽出ツールの選定で迷うケースの多くは、実は「テキスト」が欲しいのではなく「構造付きコンテンツ」が欲しいという問題を指している。
| 項目 | 内容 |
|---|---|
| GitHub Stars | 397 |
| npm 週次ダウンロード | 約 239,200 |
| ライセンス | MIT |
| Node.js 対応 | ESM ネイティブ（Node16 resolution） |
| ブラウザ対応 | ESM + IIFE バンドル（Vite・Angular 互換） |
| 最新バージョン | v6.1.0（2026-04-14） |
| 対応フォーマット | docx / pptx / xlsx / odt / odp / ods / pdf / rtf |
対応フォーマットと取得できるデータ型
officeParserが対応する8形式をまとめると次のようになる。ファイル形式ごとに取得できるデータの種類が異なる点に注意したい。
| フォーマット | 種別 | テキスト | 書式 | 表 | 画像 | メタデータ |
|---|---|---|---|---|---|---|
| docx | Microsoft Word | ✓ | ✓ | ✓ | ✓ | ✓ |
| pptx | Microsoft PowerPoint | ✓ | ✓ | ✓ | ✓ | ✓ |
| xlsx | Microsoft Excel | ✓ | ✓ | ✓ | ✓ | ✓ |
| odt | OpenDocument Text | ✓ | ✓ | ✓ | ✓ | ✓ |
| odp | OpenDocument Presentation | ✓ | ✓ | ✓ | ✓ | ✓ |
| ods | OpenDocument Spreadsheet | ✓ | ✓ | ✓ | ✓ | ✓ |
| ✓ | 部分的 | ✓ | ✓（OCR） | ✓ | ||
| rtf | Rich Text Format | ✓ | ✓ | - | - | 部分的 |
メタデータとして取得できる情報には、作成者・作成日時・更新日時・カスタムプロパティが含まれる。docxのカスタムプロパティ（Word文書のプロパティダイアログで追加できる任意のキー・バリューペア）まで取得できる点は、企業内文書管理システムとの連携で特に有用だ。
インストールとはじめての使い方
npmパッケージ名は officeparser（全小文字）だ。
npm install officeparser
基本的な使い方は parseOffice() を呼ぶだけだ。戻り値は OfficeParserAST オブジェクトで、.toText() でプレーンテキストに変換できる。
import officeParser from 'officeparser';
// ファイルパスを渡すだけで解析
const ast = await officeParser.parseOffice('document.docx');
// プレーンテキストとして取得
console.log(ast.toText());
// AST構造をJSONで出力（デバッグ用）
console.log(JSON.stringify(ast.content, null, 2));
CLIからも使用できる。npx 経由でインストール不要で試せる。
# プレーンテキスト出力
npx officeparser /path/to/file.docx --toText=true
# OCR有効でPDFを処理
npx officeparser /path/to/file.pdf --ocr=true --extractAttachments=true
ファイルパスの代わりに Buffer や ArrayBuffer も渡せるため、HTTPリクエストで受け取ったファイルをディスクに書き込まずに処理できる。Node.jsのストリーム処理との相性がよく、S3やGCSから取得したバイナリをそのまま渡す実装パターンが多い。
ASTの構造：ドキュメント構造を保持した出力形式
parseOfficeが返すASTオブジェクトのトップレベル構造を確認しておこう。
interface OfficeParserAST {
type: 'docx' | 'pptx' | 'xlsx' | 'odt' | 'odp' | 'ods' | 'pdf' | 'rtf';
metadata: {
author: string;
title: string;
createdAt: Date;
modifiedAt: Date;
customProperties: Record<string, string>;
styleMap: Record<string, StyleInfo>;
};
content: OfficeContentNode[];
attachments: Attachment[];
toText(): string;
}
content 配列には OfficeContentNode の階層が格納される。ノードタイプは heading・paragraph・list・table・row・cell・text・image・chart・note・break の11種類が定義されている。
この階層構造によって、単純なテキストよりも豊富な情報をRAGのチャンク生成に活用できる。たとえば heading ノードのレベル情報を使えば、ドキュメントの章・節単位でチャンクを分割できる。table ノードをそのまま保持すれば、表の行・列の意味関係を壊さずにベクトル化できる。
formatting オブジェクトにはbold・italic・underline・strikethrough・color・backgroundColor・size・font・subscript・superscript・alignmentが含まれる。この書式情報を活用することで、「太字になっている重要キーワード」だけを抽出するといった高度な前処理が可能になる。
設定オプション：実務で使う主要パラメータ
parseOffice() の第2引数に設定オブジェクトを渡せる。実務でよく使う設定を把握しておこう。
| オプション | 型 | デフォルト | 用途 |
|---|---|---|---|
outputErrorToConsole |
boolean | false | エラーをコンソールに出力（デバッグ用） |
newlineDelimiter |
string | \n |
toText()での改行文字 |
ignoreNotes |
boolean | false | PPTXのノートページをスキップ |
putNotesAtLast |
boolean | false | PPTXのノートを末尾にまとめる |
extractAttachments |
boolean | false | 画像・チャートをBase64で取得 |
includeRawContent |
boolean | false | XML/RTFの生マークアップを含める |
preserveXmlWhitespace |
boolean | false | XMLの空白を保持 |
ocr |
boolean | false | Tesseract.jsでOCRを実行 |
ocrLanguage |
string | eng |
OCRの言語コード（日本語: jpn） |
includeBreakNodes |
boolean | false | DOCXの改ページ・改行ノードを含める |
pdfWorkerSrc |
string | CDN | PDF.jsワーカーのパス（ブラウザ用） |
日本語ドキュメントのOCRには ocrLanguage: 'jpn' を指定する。Tesseract.jsは言語データを初回起動時にダウンロードするため、プロダクション環境では事前にダウンロードしてキャッシュしておくと処理時間を短縮できる。
ocr: true と extractAttachments: true の組み合わせで対処できる。extractAttachmentsがtrueの場合にのみ、画像ノードにocrTextプロパティが付与される仕様に注意。
OCR機能：Tesseract.jsを使った画像内テキスト抽出
v6.1.0で刷新されたOCRスケジューラーは、複数リクエストの並列処理時にTesseractワーカープールをインテリジェントに管理する。ワーカーの起動・停止オーバーヘッドを削減し、バッチ処理時のパフォーマンスを向上させている。
import officeParser from 'officeparser';
const ast = await officeParser.parseOffice('scanned-document.pdf', {
ocr: true,
ocrLanguage: 'jpn', // 日本語OCR
extractAttachments: true,
});
// OCRで抽出されたテキストを確認
ast.attachments.forEach(attachment => {
if (attachment.ocrText) {
console.log(`${attachment.name}: ${attachment.ocrText}`);
}
});
// スクリプト終了時はワーカープールを解放
officeParser.terminateOcr();
terminateOcr() の呼び出しを忘れるとNode.jsプロセスが終了しない場合がある。バッチ処理スクリプトではtry-finally構文で確実に呼ぶ実装が推奨される。
RAGパイプラインへの組み込み：実践的なパターン
officeParserは「ドキュメント→チャンク→ベクトル化」というRAGパイプラインの最初のステップを担当する。ASTの構造を活用して、見出し単位でチャンクを生成する実装例を示す。
import officeParser from 'officeparser';
async function extractChunksFromDocument(filePath) {
const ast = await officeParser.parseOffice(filePath);
const chunks = [];
let currentSection = { heading: '', content: [] };
for (const node of ast.content) {
if (node.type === 'heading') {
// 前のセクションを保存
if (currentSection.content.length > 0) {
chunks.push({
text: currentSection.content.join('\n'),
metadata: {
heading: currentSection.heading,
author: ast.metadata.author,
createdAt: ast.metadata.createdAt,
source: filePath,
}
});
}
currentSection = { heading: node.toText(), content: [] };
} else {
currentSection.content.push(node.toText());
}
}
// 最後のセクションを保存
if (currentSection.content.length > 0) {
chunks.push({
text: currentSection.content.join('\n'),
metadata: { heading: currentSection.heading, source: filePath }
});
}
return chunks;
}
この実装では heading ノードを境界としてチャンクを生成し、各チャンクにメタデータ（見出し・著者・作成日時・ソースファイル）を付与している。RAGシステムでの検索結果にメタデータを含めることで、「どの文書のどの章から取得した情報か」を回答と一緒に提示できる。
表データの扱いはさらに工夫が必要だ。table ノードはそのまま toText() するとタブ区切りのフラットテキストになるが、行・セルの構造を保持したまま処理するほうがRAGの精度に有利な場合がある。
RAGFlowのようなエンタープライズRAGエンジンとの連携を検討している場合、officeParserでASTを生成してからRAGFlowのカスタムドキュメントローダーへ渡すアーキテクチャが有効だ。RAGFlowの詳細は RAGFlow｜エンタープライズRAGエンジンの導入と使い方 で解説している。
また、PDFの高精度変換には MinerU｜PDFをマークダウンに変換するOSSツール との使い分けも検討する価値がある。MinerUはLaTeX数式・複雑なレイアウトのPDFに特化しており、学術論文や技術仕様書ではMinerUが優位な場合もある。
ブラウザ対応とESMバンドル
v6.1.0でのもっとも重要な変更の1つが、ブラウザ環境での安定動作だ。従来のzipライブラリをfflateに置き換えたことで、Webワーカー・Service Workerでも動作するようになった。
// ブラウザ（ESM）での使用例
import { OfficeParser } from 'officeparser';
// ファイル入力からArrayBufferを取得
async function handleFileUpload(file) {
const buffer = await file.arrayBuffer();
const ast = await OfficeParser.parseOffice(new Uint8Array(buffer));
return ast.toText();
}
IIFEバンドルも提供されているため、<script> タグで直接読み込むこともできる。PDF処理には pdf.js ワーカーが必要で、ブラウザ環境では pdfWorkerSrc オプションで正しいCDN URLかローカルパスを指定する必要がある。Vite・Angularプロジェクトでの動作はv6.1.0で検証済みとされている。
Next.jsやNuxt.jsのサーバーサイドでもそのまま動作するため、フルスタックアプリケーションでの採用障壁が低い。
代替ライブラリとの比較
Node.jsでドキュメントを解析するライブラリは複数あるが、2026年時点での状況を整理する。
| ライブラリ | docx | xlsx | pptx | AST | OCR | ブラウザ | 週次DL | 開発状況 | |
|---|---|---|---|---|---|---|---|---|---|
| officeParser | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | 239,200 | アクティブ |
| textract | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | 24,000 | 停滞気味 |
| mammoth | ✓ | ✗ | ✗ | ✗ | 部分的 | ✗ | ✓ | 210,000 | アクティブ |
| xlsx (SheetJS) | ✗ | ✓ | ✗ | ✗ | ✓ | ✗ | ✓ | 4,200,000 | アクティブ |
| pdf-parse | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | ✗ | 1,700,000 | 停滞気味 |
| docx2txt | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | 12,000 | 低メンテ |
mammothはdocxからHTML変換に特化した高品質ツールで、Wordドキュメントのスタイルを忠実にHTMLに変換する用途では今も最良の選択肢だ。SheetJSはExcel処理に特化した老舗ライブラリで、数式・ピボットテーブル・VBAまで扱える。
officeParserの強みは「8形式を1ライブラリで統一的に扱える」点にある。ドキュメントの種類が混在するRAGシステムでは、ファイル形式ごとに別ライブラリを管理するコストが問題になる。officeParserに一本化することで、「docxはmammoth、xlsxはSheetJS、pdfはpdf-parse」というパッチワーク的な実装を避けられる。
メタデータ抽出：ドキュメント属性をRAGの検索フィルタに活用する
officeParserはコンテンツの抽出だけでなく、ドキュメントのメタデータも豊富に取得できる。
const ast = await officeParser.parseOffice('contract.docx');
// 標準メタデータ
console.log(ast.metadata.author); // 作成者名
console.log(ast.metadata.createdAt); // 作成日時
console.log(ast.metadata.modifiedAt); // 最終更新日時
// カスタムプロパティ（Wordの「詳細プロパティ」で設定したもの）
console.log(ast.metadata.customProperties);
// 例: { department: '法務部', version: '2.1', status: '承認済み' }
企業内文書管理では、部門・バージョン・承認状態などのメタデータをドキュメントのカスタムプロパティに埋め込んでいるケースが多い。このメタデータをRAGシステムのフィルタ条件として活用することで、「法務部の承認済み文書のみを参照する」といった権限制御が実装しやすくなる。
v6.1.0でOOXML（docx/pptx/xlsx）、ODF（odt/odp/ods）、PDFの3つのフォーマット群でカスタムプロパティの取得が統一されたことで、形式を問わず同一のコードでメタデータを扱える。
実運用上の注意点とパフォーマンス最適化
大量のドキュメントをバッチ処理する場合、いくつかの点に注意が必要だ。
メモリ管理: 大きなドキュメント（数十MB以上）のASTはメモリを多く消費する。extractAttachments: false（デフォルト）に設定することで、画像データのBase64エンコードによるメモリ増大を防げる。添付ファイルが必要な場合のみ true にする運用が推奨される。
OCRのワーカープール管理: OCRを有効にした場合、terminateOcr() を適切なタイミングで呼ぶことが重要だ。Webサーバーとして使用する場合はシャットダウンフックで呼ぶ実装が一般的だ。
PDFの処理速度: PDFの解析にはpdf.jsのワーカーが使用されるため、Node.js環境では初回呼び出し時にワーカー起動のオーバーヘッドがある。プロセスの生存期間中は同一ワーカーが再利用されるため、サーバープロセスとして長期稼働させる設計の方が効率的だ。
ユースケース別の活用シナリオ
officeParserが実際にどのような場面で使われているか、公式ドキュメントとnpmユーザーの使用例を整理する。
企業内ナレッジベース構築: 社内のWord文書・Excelレポート・PowerPoint資料を定期的にRAGシステムへインジェストするパイプラインの構築。見出し単位のチャンク分割と作成者・日時メタデータの保持が重要で、officeParserのAST出力がそのまま活用できる。
契約書・法務文書の解析: docxで作成された契約書から条項番号・当事者名・期日などの構造化情報を抽出するケース。見出しレベルによるセクション識別と太字テキストの優先抽出が有効で、formatting.boldプロパティでフィルタリングできる。
スライド資料のテキスト検索システム: PPTXから各スライドのタイトル・本文・ノートを抽出してインデックスを構築するケース。ignoreNotes: false（デフォルト）でノートページも含めて取得できるため、プレゼンターノートの内容も検索対象にできる。
スキャン帳票のOCR後処理: OCRで読み取ったテキストをPDFに格納したドキュメントから情報を抽出するケース。ocrLanguage: 'jpn'で日本語スキャン文書に対応できる。ただし複雑なレイアウトのPDFはMinerUのようなレイアウト解析特化ツールの方が精度が高い場合もある。
ブラウザ内ドキュメントプレビュー: フロントエンドアプリケーションでユーザーがアップロードしたOfficeファイルの内容を表示するケース。ブラウザESMバンドルを使ってサーバーレスでテキスト抽出でき、プライバシー上の理由でドキュメントをサーバーに送りたくない場合に有効だ。
officeParserが向かない用途
あらゆる用途に適しているわけではない。次の場合は他のツールを検討すべきだ。
- Excelの数式評価・計算が必要な場合: SheetJS（xlsxパッケージ）が適している
- Wordのスタイルを忠実にHTMLに変換したい場合: mammothが優れている
- 複雑なレイアウトのPDF（学術論文・技術仕様書）: MinerUが精度で上回るケースがある
- Python環境での処理: python-docxやpdfminerなどPython向けライブラリを使う方が生態系的に自然
- 古い.doc形式（Word 2003以前）: .docxではなく.doc形式は非対応
まとめ
officeParserはNode.js・ブラウザ対応の8形式ドキュメントパーサーとして、2026年時点で最もアクティブに開発されているOSSの1つだ。週23万ダウンロードという数字は、「ドキュメント→テキスト」というシンプルな要求の背景に大きな実需があることを示している。
v6.1.0での主要改善（OCRスケジューラー刷新・fflateへの移行・ESMネイティブ化）は単なる機能追加ではなく、プロダクション環境での安定稼働を意識したインフラ投資だ。
RAGシステムを構築する上でドキュメントの前処理は「地味だが精度に直結する」工程だ。プレーンテキスト抽出で済ませるか、ASTで構造を保持するかの選択が、最終的な検索精度に影響する。LightRAGのような知識グラフ型RAGを採用する場合は特に、入力ドキュメントの構造情報が重要になる。LightRAGについては LightRAG完全ガイド：知識グラフ×デュアルレベル検索でRAGの精度と網羅性を根本的に変える方法 で詳述している。
