moar 使い方と実務評価：RAGの精度を劇的に変えるドキュメント構造化ツール

注意: 本記事はドキュメント・公開情報をもとにした評価記事です。コード例はシミュレーションです。

3行要約

• PDFやWord等の非構造化データを、LLMが理解しやすいMarkdown形式へ高精度に変換する
• 従来のテキスト抽出では崩れがちだった「複雑な表組み」や「文書構造（見出し）」を保持できる
• 独自のRAG（検索拡張生成）の回答精度に限界を感じているエンジニアは試すべき、単なる全文検索で足りるなら不要

結論から: このツールは「買い」か

結論から言えば、エンタープライズ向けのRAG構築を担うエンジニアなら、検証リストの最上位に入れるべきツールです。★評価は4.5。 これまで私は、PyPDF2やpdfminer.six、あるいはAWS Textractなど様々なツールを実務で試してきました。 しかし、多くの場合「テキストは取れるが、表の構造が破壊される」「図説のキャプションが本文に混ざる」という問題に直面し、結局は泥臭い正規表現の嵐や、手動でのデータクレンジングを強いられてきました。

moarは、こうした「ドキュメント前処理の地獄」をAPI一つで解決しようとしています。 月額コストやAPI実行単価は発生しますが、エンジニアが数週間かけてパース用のコードを書く人件費を考えれば、極めて安上がりです。 特に、数千ページに及ぶ社内規定や、複雑な技術仕様書をLLMに食わせたいプロジェクトでは、このツールの有無が最終的な回答精度を左右すると断言できます。 逆に、テキスト主体の平易なブログ記事などをソースにする場合は、オーバースペックになるため無料のライブラリで十分です。

このツールが解決する問題

これまでのLLMアプリケーション開発において、最大のボトルネックは「データの品質」でした。 特にビジネス現場で扱うドキュメントの多くはPDF形式ですが、PDFはもともと「印刷用」のフォーマットであり、コンピュータが構造を理解するように作られていません。 そのため、一般的なライブラリでテキストを抽出すると、段組みが無視されて文章がバラバラになったり、表データがただの数字の羅列になったりします。

この「汚いデータ」をそのままベクトルデータベースに放り込んでも、LLMは正しいコンテキストを把握できません。 結果として「ドキュメントには書いてあるのに、AIが間違った回答をする」という現象が起きます。 moarは、ドキュメントのレイアウトを視覚的に解析し、見出し、段落、リスト、テーブルを特定した上で、LLMが最も得意とするMarkdown形式に再構成します。

これにより、チャンク分割（文章の切り出し）の際にも「意味の区切れ」で正確に分割できるようになります。 「従来はエンジニアが数日かけていたパース処理の最適化を、数秒のAPIコールで完結させる」こと。 これがmoarが提供する最大の価値です。

実際の使い方

インストール

moarはクラウドネイティブなAPIとして提供されているため、Python環境からは公式のSDKを利用するのが最もスムーズです。 依存ライブラリも少なく、既存のLangChainやLlamaIndexの環境を汚さずに導入できる点は評価できます。

pip install moar-ai

前提として、APIキーの取得が必要です。 また、大容量のPDFを扱う場合は、ネットワークのタイムアウト設定を適切に行う必要があります。

基本的な使用例

公式のAPI構造に基づいた、最もシンプルな変換コードは以下の通りです。 ドキュメントを読み込み、構造化されたMarkdownを取得するまでの流れが非常に洗練されています。

import os
from moar import MoarClient

# APIキーの設定
client = MoarClient(api_key="your_api_key_here")

# ドキュメントのアップロードと変換
# 内部的にレイアウト解析とOCRが走り、Markdownで返される
document = client.documents.convert(
    file_path="./technical_manual.pdf",
    options={
        "extract_tables": True,     # 表組みをMarkdown形式で保持
        "preserve_headers": True,    # 見出し階層を#で表現
        "ocr_language": "ja+en"      # 日本語と英語の混合文書に対応
    }
)

# 変換されたテキストの確認
print(document.markdown_content[:500])

# 構造化されたデータをJSON形式で取得することも可能
# 各セクションごとのメタデータが含まれる
for section in document.sections:
    print(f"Heading: {section.title}, Level: {section.level}")

このコードの肝は、extract_tablesオプションです。 これを有効にするだけで、複雑な結合セルを含む表が、LLMが解釈可能なMarkdown Table形式に変換されます。 実務では、この出力をそのままLangChainのMarkdownTextSplitterに渡すだけで、理想的なRAGのソースデータが完成します。

応用: 実務で使うなら

実際のプロジェクトでは、変換したデータをベクトルデータベース（PineconeやWeaviateなど）へ格納するバッチ処理に組み込むことになります。 特に、ファイル更新をトリガーにした自動パイプラインの構築が現実的です。

# RAG用パイプラインへの組み込みイメージ
from langchain.text_splitter import MarkdownHeaderTextSplitter
from moar import MoarClient

def ingest_to_rag(file_path):
    client = MoarClient(api_key=os.environ["MOAR_API_KEY"])

    # 1. moarで高精度パース
    processed_doc = client.documents.convert(file_path=file_path)

    # 2. Markdownの階層構造に基づいたチャンク分割
    headers_to_split_on = [
        ("#", "Header 1"),
        ("##", "Header 2"),
        ("###", "Header 3"),
    ]
    splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers_to_split_on)
    chunks = splitter.split_text(processed_doc.markdown_content)

    # 3. 各チャンクにメタデータを付与してDBへ
    # (ここでは疑似コードとしてリスト表示)
    return chunks

# 実行
chunks = ingest_to_rag("specification_v1.pdf")
print(f"生成されたチャンク数: {len(chunks)}")

このように、moarを使うことで「物理的な1ページ」単位ではなく、「論理的な1セクション」単位でのデータ管理が可能になります。 これは検索精度の向上に直結する重要なポイントです。

強みと弱み

強み:

• 表組みの再現性が極めて高い。Markdown形式で出力されるため、LLMとの相性が抜群。
• 階層構造（H1〜H3）を自動認識するため、RAGのチャンク分割が論理的に行える。
• APIがシンプルで、既存のPythonエコシステム（LangChain等）との統合が容易。
• 独自のOCRエンジンを搭載しており、スキャンされた低画質なPDFでも文字化けが少ない。

弱み:

• 大量のドキュメントを処理する場合、APIの実行コストが無視できない（無料枠は限定的）。
• 処理時間は1ページあたり約1〜3秒程度かかるため、数万ページをリアルタイムで処理する用途には向かない。
• 自社サーバー内での完全クローズド運用（オンプレミス）には現時点で対応していない。
• 日本語固有の縦書き文書や、極端に特殊なレイアウトでは誤認識が発生することがある。

代替ツールとの比較

moarを選ぶべき場面は、ズバリ「表データが重要なドキュメント」を扱う時です。 Unstructured.ioは非常に多機能ですが、環境構築が重く、依存ライブラリの衝突に悩まされることが多々あります。 一方、LlamaParseは強力なライバルですが、moarの方がより「純粋なMarkdown構造」への変換に特化しており、LangChain派のユーザーには扱いやすい印象です。

私の評価

個人的な評価は「★4.5」です。 RTX 4090を2枚回してローカルLLMを検証している身としては、モデルの性能を上げるよりも、入力データの質を上げる方が圧倒的にコスパが良いことを痛感しています。 moarは、その「入力データの質」を底上げするための最短ルートです。

実務で20件以上の機械学習案件をこなしてきましたが、その半分以上はデータの整形に時間を取られてきました。 もし数年前にこのツールがあれば、どれほど工数を削減できただろうかと思います。 特に、金融、法務、製造業など、複雑なフォーマットの書類が大量に存在する業界のエンジニアにとっては、神ツールになり得るポテンシャルを持っています。

ただし、全てのプロジェクトに推奨するわけではありません。 社外秘情報をAPI経由でクラウドに投げることに制限がある組織では、導入のハードルが高いでしょう。 そうした制約がなく、スピード感を持って精度の高いAIサービスを立ち上げたいのであれば、今すぐ組み込んでみるべきです。

よくある質問

Q1: PDF以外のファイル形式（ExcelやWord）にも対応していますか？

はい、主要なOffice形式に対応しています。特にWord（.docx）の構造化はPDF以上にスムーズで、箇条書きやインデントの情報を正確にMarkdownへ変換可能です。Excelについても、シートごとにテーブルとして抽出されます。

Q2: 料金体系はどうなっていますか？無料お試しはありますか？

基本的には処理ページ数に応じた従量課金制です。Product Hunt経由のサインアップで一定の無料クレジットが付与されるケースが多いので、まずは自分のプロジェクトのサンプルファイルでパース精度を試してみるのが良いでしょう。

Q3: 日本語のOCR精度はどうですか？

試した限りでは、標準的なフォントであれば高い精度を維持しています。ただし、手書き文字や、かすれが激しい古い文書については、専門のOCRツールと比較してやや劣る場合があります。ビジネス文書であれば実用レベルです。

あわせて読みたい

• Plannotator ドキュメントやURLへのアノテーションでAIエージェントの精度を劇的に向上させる方法
• DataSieve 2.0 構造化データ抽出の自動化と実務実装
• Just The Article Please 使い方とLLM時代のWeb抽出術