文書本文の抽出はデータセキュリティ分析の基盤であり、その処理効率とリソース使用量は関連タスクの実行コストに直接影響する。増大する文書処理需要に対応するには、内容の完全性、処理遅延、計算資源の消費を同時に考慮し、統一した条件で実測効果を検証する必要がある。
今回の文書処理エンジンの再設計は、処理効率の向上、CPU の計算コスト削減、単一タスクのメモリピーク低減を目的としている。性能評価では同じ文書セットを用い、再設計後の実装、従来の実装、Apache Tika を比較し、DOCX、XLSX、PPTX、PDF の 4 形式を対象とした。
文書ごとに独立したプロセスを起動し、起動と初期化のコストを含める条件では、従来の実装に比べ、累積経過時間は約 93.0%、累積 CPU 時間は約 94.3%、各ラウンドで最大となった単一タスクのピークワーキングセットは約 67.7% 減少した。これらの削減率は今回のワークロードと測定方式に限られ、コンピューター全体やすべての配置形態で同等の変化を示すものではない。
性能改善の概要
テストには 12 の生成文書を使用し、各形式に 3 段階の規模を設定した。各実装で 6 ラウンドの本測定を行い、表にはその中央値を示す。
経過時間と CPU 時間は各ラウンドの 12 タスクについて、それぞれ合計する。メモリ指標は、各ラウンドの単一タスク最大ピークを求めた後、6 ラウンドの中央値を算出する。異なるタスクのメモリ使用量は加算しない。累積経過時間は実行順を入れ替えた独立タスクの合計であり、常駐サービスによる連続処理のスループット測定とは異なる。
今回の構成の Apache Tika と比較した場合、再設計後の実装の 3 指標はそれぞれ約 95.0%、98.8%、88.7% 減少した。Apache Tika は外部の比較対象であり、ほかのバージョンや配置構成を評価したものではない。
文書処理時間

全 12 入力で、再設計後の実装のタスク別経過時間の中央値は、いずれの比較対象よりも小さかった。今回の短寿命タスクモデルにおいて、文書処理の実際の待ち時間が短縮されたことを示している。
改善幅は形式によって異なる。従来の実装ではプレゼンテーション文書の処理時間が比較的短い一方、今回の PDF ではページ数増加に伴う処理時間の伸びがより顕著であった。単一形式の最良結果だけでは、すべての文書を代表できない。
測定には初期化、本文抽出、結果出力を含む。各工程の寄与は個別に測定していないため、改善のすべてを特定の工程や技術選択に帰することはできない。
CPU の計算コスト

処理遅延と計算コストは異なる指標である。並列実行は経過時間を短縮する一方、累積 CPU 時間を増加させる場合があるため、性能評価では両方を記録した。
同じ 12 タスクを完了する際の累積 CPU 時間の中央値は、従来の実装の 9.930 秒から、再設計後の実装では 0.570 秒に減少した。これは測定対象のワークロードにおける累積計算コストの低減を裏付けている。
CPU 時間はコンピューター全体の CPU 使用率ではない。消費電力量やバッテリー駆動時間の変化に直接換算することもできない。今回はコンピューター全体の使用率、消費電力量、バッテリー駆動時間を測定しておらず、それらに関する推論は行わない。
単一タスクのメモリピーク

各ラウンドで最大となった単一タスクのピークワーキングセットの中央値は、従来の実装の 111.90 MiBから、再設計後の実装では 36.18 MiBに減少した。この指標は OS が記録したプロセスの最大常駐ワーキングセットであり、実行環境や共有常駐ページを含むため、プライベートメモリやコンピューター全体のメモリ使用量とは異なる。
メモリの増加傾向は形式ごとに異なる。このセットでは表計算文書の増加がプレゼンテーション文書より顕著であり、形式と内容規模に応じたリソース予算が必要であることを示している。小さなファイルの結果から、大きなファイルの動作を直接外挿することはできない。
単一タスクのピーク低減は、文書処理のリソース需要を抑える根拠となるが、同じ割合で同時実行数を増やせることを意味しない。同時実行時にはピークの重なり、共有ページ、キャッシュなどが影響するため、独立した測定が必要である。
テスト条件と結果の検証
2026 年 10 月 20 日、同じ Windows ワークステーション上で測定し、3 つのテストプロセスがすべて x64 であることを確認した。
文書規模は、DOCX が 100、1,000、5,000 段落、XLSX が 100、1,000、5,000 行で各行 6 列、PPTX が 5、50、200 スライドで各スライド 10 段落、PDF が 5、50、200 ページで各ページ 35 行である。各実装は同じ入力を読み取り、テスト前後でファイルのハッシュが変わらないことも確認した。
文書と実装の各組み合わせについて、1 回のウォームアップ後に 6 回の本測定を行い、すべて新しいプロセスを使用した。入力は事前に読み込むが、OS のファイルキャッシュは消去していない。6 ラウンドで 3 実装の全 6 通りの実行順を使用し、文書順は固定シードで並べ替えた。本測定は合計 216 回で、別に行った 36 回のウォームアップは統計に含めていない。本測定で遅かった実行も除外していない。
各実行で成功状態を確認し、本文中のすべての英数字トークンを順番どおりに照合した。ワークシート名を含めるかどうかの違いはテスト前に記録し、本文の差としては扱っていない。216 回の本測定すべてがこの検証に合格し、失敗、空の本文、本文欠落を速い結果として数えていない。この検証は空白レイアウトを比較するものではなく、複雑な文書における動作の同等性を証明するものでもない。
CPU 時間にはユーザーモードとカーネルモードの累積時間の和を用い、マルチスレッドでは実際の経過時間より大きくなる場合がある。このマシンの計時値は約 15.6 ミリ秒刻みで、短いタスクの値がゼロでも計算がなかったことにはならない。メモリには OS が管理するピークワーキングセットの値を使用し、定期サンプリングだけからピークを推定していない。
グラフには 6 回の中央値と最小値・最大値を示す。エラーバーは信頼区間ではなく、点を結ぶ線は未測定の規模への外挿を示さない。削減率は丸める前の中央値を用い、「1 − 再設計後の値 ÷ 比較対象の値」で計算した。異なる指標の削減率を加算したり、総合性能向上率にまとめたりすることはできない。
結果の適用範囲
今回の結果は、測定対象のワークロードにおける、再設計による経過時間、CPU 時間、単一タスクのメモリ面の効果を裏付けている。独立プロセスのテストは初期化コストを含むが、常駐サービスはこのコストを分散できる。そのため、上記の削減率から常駐サービスのリクエスト遅延、ウォームアップ後の純粋な解析速度、継続的なスループットを直接推定することはできない。
サンプルは ASCII テキストのみの生成文書で、画像、数式、マクロ、外部リソース、埋め込み添付ファイルを含まず、企業の実際の文書分布を代表しない。旧形式、中国語と複雑な文字エンコーディング、特殊なフォント、複雑な変更履歴、暗号化または破損した文書、PDF 透かしの結果は別途検証する必要がある。今回の結果は、動作が全面的に一致したという声明ではない。
テスト対象は 1 台のワークステーション、各組み合わせ 6 回の本測定に限られ、異なるハードウェアやプラットフォームでの性能を保証するものではない。以上は NSecsoft 内部のベンチマークに基づく数値であり、独立した第三者認証ではない。