OpenClaw によるドキュメント処理の自動化

すべてのビジネスは文書に基づいて行われます。請求書、契約書、発注書、納品受領書、コンプライアンスレポート、経費請求など、その量は決して減らず、これらを手動で処理するコストは膨大です。控えめに見積もっても、手作業による請求書処理の平均コストは 1 文書あたり 12 ～ 16 ドルで、エラー率は 3% ～ 5% です。これを毎月何千ものドキュメントに掛け合わせると、自動化の必要性が自ずと高まります。

OpenClaw の文書処理エージェントは、OCR、構造化データ抽出、検証ルール、ERP 統合を単一の自律パイプラインに結合します。その結果、大部分のドキュメントに対して人間の介入を必要とせずに、ドキュメントを受信し、その種類と内容を理解し、ビジネス ルールに照らしてデータを検証し、抽出された情報を適切な宛先にルーティングするシステムが実現します。

重要なポイント

• OpenClaw ドキュメント エージェントは、統一されたパイプラインを通じて PDF、スキャンされた画像、添付ファイル付きの電子メール、および構造化ファイル形式 (CSV、XML、EDI) を処理します。
• OCR 品質スコアリングにより AI 抽出がゲートされます。低品質のスキャンは、処理を続行する前に再スキャン リクエストをトリガーします。
• 抽出レイヤーは、レイアウト分析、固有表現認識、LLM ベースの解析を組み合わせて使用​​し、ドキュメント形式全体で最大限の精度を実現します。
• 検証スキルは、データが ERP に届く前に、抽出されたデータをサプライヤーのマスター レコード、PO 番号、税コード、ビジネス ルールと照合してチェックします。
• 例外処理は、本当にあいまいな文書のみを人間にルーティングします。エージェントは、最良の推測を事前に入力したフォームを提供するため、人間は再入力せずに確認するだけです。
• パイプラインは、すぐに使える 300 以上のドキュメント タイプを処理します。カスタム テンプレートは、ローコード スキーマ エディターを通じて追加できます。
• ドキュメントの受信から ERP 入力までのエンドツーエンドの待ち時間は、クリーンなドキュメントの場合、平均 90 秒未満です。
• ECOSIRE は、Odoo、SAP、QuickBooks、およびカスタム ERP と統合された OpenClaw ドキュメント処理パイプラインを構築および管理します。

---

文書処理アーキテクチャの概要

本番環境の OpenClaw ドキュメント処理パイプラインは 6 つのステージで構成され、各ステージは 1 つ以上のスキルとして実装されます。

Document Ingestion
        ↓
[ Classifier Agent ]     — document type detection, routing
        ↓
[ Extraction Agent ]     — OCR + structured data extraction
        ↓
[ Validation Agent ]     — business rule validation, master data lookup
        ↓
[ Enrichment Agent ]     — GL coding, cost center assignment, approver lookup
        ↓
[ Integration Agent ]    — ERP/downstream system write
        ↓
[ Exception Agent ]      — handles ambiguous documents, requests human review

各エージェントは独立して実行され、タスク バスを通じて通信します。どの段階でも失敗したドキュメントは、上流の段階ですでに完了した作業を失うことなく、例外エージェントにルーティングされます。

---

ドキュメントの取り込み: あらゆる形式を受け入れる

ドキュメントは、電子メールの添付ファイル、ファイル システムのドロップ、API アップロード、FAX から電子メールへのゲートウェイ、ベンダー ポータルなどの複数のチャネルを通じて到着します。インジェスト レイヤーは、これらすべてを標準ドキュメント タスクに正規化します。

export const DocumentIngester = defineSkill({
  name: "document-ingester",
  tools: ["email", "storage", "queue"],
  async run({ input, tools }) {
    let rawFile: Buffer;
    let mimeType: string;

    if (input.source === "email") {
      const attachment = await tools.email.getAttachment(input.emailId, input.attachmentIndex);
      rawFile = attachment.buffer;
      mimeType = attachment.mimeType;
    } else if (input.source === "storage") {
      rawFile = await tools.storage.get(input.storageKey);
      mimeType = detectMimeType(rawFile);
    }

    // Normalize to PDF for consistent downstream processing
    const normalizedPdf = mimeType === "application/pdf"
      ? rawFile
      : await convertToPdf(rawFile, mimeType);

    const storageKey = `incoming/${Date.now()}-${generateId()}.pdf`;
    await tools.storage.put(storageKey, normalizedPdf);

    return {
      storageKey,
      originalSource: input.source,
      originalMimeType: mimeType,
      pagCount: await getPdfPageCount(normalizedPdf),
    };
  },
});

正規化ステップでは、Word 文書、Excel ファイル、画像ファイル (JPEG、PNG、TIFF)、および電子メールの HTML 本文を PDF に変換してから、ダウンストリームに渡します。下流エージェントは PDF のみを受信します。これにより、OCR とレイアウト分析が大幅に簡素化されます。

---

文書の分類: 何を持っているかを知る

抽出が開始される前に、分類子エージェントはドキュメント タイプを識別します。ドキュメントの種類によって必要な抽出テンプレートが異なるため、分類が重要になります。請求書は配達受領書とはまったく異なります。

分類子は 2 段階のアプローチを使用します。

ステージ 1 — レイアウト分析: ドキュメントの視覚構造 (表の位置、ヘッダー ブロック、フッター パターン、ロゴの配置) を分析して、ドキュメント カテゴリを少数の候補に絞り込みます。

ステージ 2 — コンテンツ分類: テキスト内のキー フレーズと構造パターンにより、特定の文書タイプが確認されます。分類器は、タイプ ラベルと信頼スコアを生成します。

export const ClassifyDocument = defineSkill({
  name: "classify-document",
  tools: ["storage", "classification-model"],
  async run({ input, tools }) {
    const pdfBuffer = await tools.storage.get(input.storageKey);
    const layoutFeatures = await extractLayoutFeatures(pdfBuffer);
    const textContent = await performOcr(pdfBuffer, { mode: "fast" });

    const classification = await tools.classificationModel.classify({
      layoutFeatures,
      textContent: textContent.slice(0, 2000), // First 2000 chars for speed
    });

    if (classification.confidence < 0.70) {
      return {
        type: "unknown",
        confidence: classification.confidence,
        requiresManualClassification: true,
      };
    }

    return {
      type: classification.label,
      confidence: classification.confidence,
      requiresManualClassification: false,
      extractionTemplate: TEMPLATE_MAP[classification.label],
    };
  },
});

一般的なドキュメント タイプとその抽出テンプレートは、仕入先請求書、クレジット メモ、注文書、納品書、銀行取引明細書、契約書、経費報告書、税関申告書など、事前に構築されています。コードを変更せずに、テンプレート エディターを使用して新しいドキュメント タイプを追加できます。

---

OCR と抽出: データを正確に取得する

抽出エージェントには、技術的な複雑さのほとんどが存在します。 OCR 出力とレイアウト分析および LLM ベースの解析を組み合わせて、非構造化ドキュメントから構造化データを生成します。

OCR の品質は、AI 抽出を開始する前に評価されます。 OCR からの平均文字信頼度が 0.80 未満の場合 (不鮮明なスキャン、低解像度、または傾いたページを示します)、エージェントは信頼性の低いテキストを続行するのではなく、文書に再スキャンのフラグを立てます。

OCR 品質チェックに合格したドキュメントの場合、抽出は次の 3 つのパスで行われます。

パス 1 — テンプレート マッチング: 既知のベンダーおよびドキュメント形式の場合、抽出テンプレートはフィールドの位置 (座標または正規表現アンカー) を提供します。テンプレート マッチングは、既知のソースからの構造化ドキュメントに対して高速かつ正確です。

パス 2 — 指定エンティティの認識: NER は、テンプレート マッチングで見逃した金額、日付、住所、識別子 (請求書番号、PO 番号、VAT 番号)、および品目の境界を特定します。

パス 3 — LLM 推論: あいまいなフィールドの場合、または最初の 2 つのパスで信頼性の低い値が生成された場合、LLM は周囲のテキスト コンテキストを解析して正しい値を推論します。

export const ExtractInvoiceData = defineSkill({
  name: "extract-invoice-data",
  tools: ["storage", "ocr-service", "llm"],
  async run({ input, tools, memory }) {
    const buffer = await tools.storage.get(input.storageKey);
    const ocrResult = await tools.ocrService.extract(buffer, { enhanceScannedPages: true });

    if (ocrResult.averageConfidence < 0.80) {
      return { success: false, reason: "LOW_OCR_QUALITY", ocrConfidence: ocrResult.averageConfidence };
    }

    // Pass 1: Template matching
    const templateFields = applyTemplate(ocrResult, input.extractionTemplate);

    // Pass 2: NER for missing fields
    const nerFields = await extractWithNer(ocrResult.text, { fieldTypes: ["amount", "date", "id"] });

    // Pass 3: LLM for remaining low-confidence fields
    const lowConfidenceFields = mergeAndFindGaps(templateFields, nerFields, { minConfidence: 0.85 });
    const llmFields = lowConfidenceFields.length > 0
      ? await tools.llm.extractFields(ocrResult.text, lowConfidenceFields)
      : {};

    const extracted = mergeExtractions(templateFields, nerFields, llmFields);
    await memory.working.set("extractedData", extracted);

    return { success: true, data: extracted, fieldConfidences: getFieldConfidences(extracted) };
  },
});

---

検証: ERP に到達する前にエラーを検出する

抽出された生データが ERP に直接書き込まれることはありません。検証エージェントは、何かが投稿される前に、すべてのフィールドをビジネス ルールおよびマスター データと照合してチェックします。

仕入先請求書の検証チェックには次のものが含まれます。

• ベンダーが存在します: サプライヤー名と VAT 番号がベンダー マスターのレコードと一致します。
• PO の一致: 請求書の PO 番号はオープン PO と一致し、金額は許容範囲内です (請求書発行の柔軟性のため、通常は ±5%)。
• 重複検出: このベンダーからの請求書番号は、過去 180 日間処理されていません。
• 税金の計算: 品目の合計と税金は、四捨五入許容範囲内で請求書の合計と等しくなります。
• 通貨と為替レート: 外貨建ての請求書は、請求日の為替レートに対して検証されます。
• GL期間: 請求日はオープン会計期間内にあります。

export const ValidateInvoice = defineSkill({
  name: "validate-invoice",
  tools: ["erp", "vendor-master"],
  async run({ input, tools }) {
    const errors: ValidationError[] = [];

    // Vendor validation
    const vendor = await tools.vendorMaster.findByVatNumber(input.data.vendorVat);
    if (!vendor) errors.push({ field: "vendorVat", code: "VENDOR_NOT_FOUND" });

    // PO match
    if (input.data.poNumber) {
      const po = await tools.erp.getPurchaseOrder(input.data.poNumber);
      if (!po) errors.push({ field: "poNumber", code: "PO_NOT_FOUND" });
      else if (Math.abs(po.totalAmount - input.data.totalAmount) / po.totalAmount > 0.05) {
        errors.push({ field: "totalAmount", code: "PO_AMOUNT_MISMATCH" });
      }
    }

    // Duplicate check
    const isDuplicate = await tools.erp.invoiceExists({
      vendorId: vendor?.id,
      invoiceNumber: input.data.invoiceNumber,
    });
    if (isDuplicate) errors.push({ field: "invoiceNumber", code: "DUPLICATE_INVOICE" });

    return {
      valid: errors.length === 0,
      errors,
      validatedData: errors.length === 0 ? input.data : null,
    };
  },
});

検証の失敗は、ドキュメントをサイレントに削除するのではなく、例外エージェントにルーティングされます。例外エージェントは、抽出されたデータと特定の検証エラーが事前に設定されたレビュー タスクを作成するため、人間はフラグが設定されたフィールドのみを修正できます。

---

エンリッチメント: ビジネス コンテキストの追加

クリーンで検証されたデータを ERP に送信するには、まだビジネス コンテキストが必要です。エンリッチメント エージェントは、GL アカウント コード、コスト センターの割り当て、税金処理コード、承認ワークフローの割り当て、支払条件など、ドキュメントに含まれていない情報を追加します。

強化ルールはポリシー ストアで定義され、ベンダー属性、品目説明、部門、プロジェクト コード、金額しきい値を参照できます。ほとんどのエンリッチメント ルールは決定論的な検索です。あいまいなケース（複数の GL アカウントにマッピングされる可能性のある説明を含む項目）の場合、LLM は説明付きのランク付けされた提案リストを提供します。

---

ERP 統合: 初回からデータを正確に書き込む

統合エージェントは、検証され強化されたデータを ERP にポストします。元のドキュメントのハッシュから派生した相関 ID を使用して冪等 API 呼び出しを使用します。ERP 書き込みが (ネットワーク タイムアウトにより) 再試行された場合、重複レコードが防止されます。

export const PostToErp = defineSkill({
  name: "post-to-erp",
  tools: ["erp"],
  async run({ input, tools }) {
    const correlationId = hashDocument(input.storageKey);

    const result = await tools.erp.createVendorBill({
      correlationId, // ERP uses this for idempotency
      vendorId: input.enrichedData.vendorId,
      invoiceNumber: input.enrichedData.invoiceNumber,
      invoiceDate: input.enrichedData.invoiceDate,
      lineItems: input.enrichedData.lineItems,
      taxLines: input.enrichedData.taxLines,
      paymentTerms: input.enrichedData.paymentTerms,
      glCodes: input.enrichedData.glCodes,
    });

    return {
      erpRecordId: result.id,
      erpRecordUrl: result.url,
      posted: true,
    };
  },
});

投稿後、元のドキュメントは ERP レコードにリンクされ、完全なメタデータとともにドキュメント管理システムにアーカイブされます。監査証跡は、電子メールの添付ファイルまたはファイルのドロップからすべての処理段階を経て、最終的な ERP エントリに至るまで完全です。

---

例外処理: 重要な場合は人間参加型

すべてのドキュメントがきれいに処理されるわけではありません。例外エージェントは、次の 4 つのカテゴリの例外を処理します。

1. 分類失敗: 文書タイプを十分な信頼性をもって決定できませんでした。
2. 抽出失敗: 重要なフィールド (合計金額、ベンダー ID、請求書番号) を抽出できませんでした。
3. 検証失敗: 抽出されたデータはビジネス ルール チェックに合格しません。
4. 統合の失敗: ERP が転記を拒否しました (例: 終了した会計期間、アカウントがロックされている)。

例外ごとに、エージェントは、エージェントの最善の試みと特定のエラーを示す事前入力フォームを使用して、ヘルプデスクまたはワークフロー システムにレビュー タスクを作成します。人間は失敗したフィールドのみを修正して承認し、エージェントが再送信を処理します。

---

よくある質問

正確な OCR にはどのようなドキュメント解像度が必要ですか?

印刷ドキュメントの場合、許容可能な OCR 結果の最小値は 150 DPI です。確実に抽出するには 300 DPI をお勧めします。手書きの文書やフォント サイズが非常に小さい文書の場合は、400 DPI 以上が推奨されます。 OCR 品質評価スキルは、抽出が開始される前にドキュメントがしきい値を下回るとフラグを立て、再スキャン要求を自動的にトリガーします。

システムは複数ページのドキュメントをどのように処理しますか?

複数ページのドキュメントはページ境界検出を使用して処理されます。請求書の場合、エージェントはヘッダー ページ、品目ページ、および継続ページを識別します。改ページにまたがる行項目は、レイアウト分析レイヤーによって正しく再構築されます。他の文書タイプ (契約書、レポート) の場合、エージェントはすべてのページを処理し、各ページから抽出されたフィールドを集計します。

システムは人間による修正から学習できますか?

はい。人間が例外ドキュメントを修正すると、その修正はナレッジ エージェントにフィードバックされます。同じ修正パターンが 3 回以上出現する場合 (たとえば、新しい仕入先が常に非標準的な方法で請求書の書式を設定する場合)、システムはその仕入先に対して新しい抽出テンプレートを自動的に提案します。管理者が提案されたテンプレートをレビューして承認すると、その時点からシステムはそのベンダーに対して人によるレビューを行わずにテンプレートを適用します。

手書きの文書はどのように扱われますか?

手書きの文書は最も困難なカテゴリです。 OCR レイヤーはこれらの文書に特化した手書き認識モデルを使用し、AI 抽出に渡すための信頼しきい値はより高くなります (印刷文書の場合は 0.90 に対して 0.80)。実際には、ほとんどの企業ドキュメント ワークフローでは、プロセスの変更 (電子提出ポータル、デジタル署名ワークフロー) によって手書きドキュメントを排除できます。手書きの文書を処理する必要がある組織に対して、ECOSIRE は手書きの多い文書に対して人間によるレビューを行うハイブリッド アプローチを推奨しています。

抽出ではどの言語がサポートされていますか?

OpenClaw の文書処理は、英語、ドイツ語、フランス語、スペイン語、アラビア語、中国語 (簡体字および繁体字)、日本語、ポルトガル語の主要なビジネス文書形式に対して検証された抽出テンプレートを使用して、OCR 用に 40 以上の言語をサポートしています。他の言語の場合、OCR は機能しますが、抽出テンプレートの品質はドキュメント サンプル セットによって異なります。 LLM 推論層は、多くの言語をネイティブに処理します。

文書の機密性はどのように維持されますか?

ドキュメントは転送中 (TLS 1.3) および保存中 (AES-256) で暗号化されます。各ドキュメントは分離されたコンテキストで処理され、組織間でドキュメントの内容が共有されることはありません。機密性の高い文書 (法的契約書、財務諸表) の場合、推論層にオンプレミス LLM を使用するようにパイプラインを構成し、文書の内容を完全にネットワーク境界内に保持できます。

請求書処理の一般的な精度率はどれくらいですか?

テンプレート マッチングを使用する既知のベンダーからの構造化請求書の場合、テンプレート キャリブレーション後のフィールド レベルの精度は通常 99.5% を超えます。新しいベンダーからの非構造化請求書の場合、精度は通常、最初の試行で 95 ～ 98% ですが、システムがベンダーの形式を学習するにつれて精度は向上します。追跡する重要な指標は例外率です。適切に構成されたパイプラインでは、例外率がドキュメント総量の 5% 未満になります。

---

次のステップ

手作業による文書処理はコストセンターであり、競争価値をもたらしません。 OpenClaw ドキュメント処理の自動化は、スタッフ集中型の操作を、人間の介入なしでドキュメント量の 95% 以上を処理する自動パイプラインに変換します。

ECOSIRE の OpenClaw 実装チーム は、Odoo、SAP、QuickBooks、カスタム ERP と統合されたドキュメント処理パイプラインの構築を専門としています。当社は、ドキュメント分類テンプレートの設計、OCR キャリブレーション、検証ルールの構成、ERP 統合、および例外ワークフローのセットアップを処理し、本番稼働可能なシステムを 6 ～ 8 週間で提供します。

ECOSIRE に連絡 して、現在の業務の文書処理監査を開始してください。