Classifyを使用したAIドキュメントパーサー
このガイドの内容
AIドキュメントパーサー。分類 1 つのアナライザーで、1 つの呼び出しで複数のドキュメント バリアントを処理できます。 アナライザーID1つ追加します バリエーションごとの図 （クライアントABC、クライアントXYZ、汎用請求書、汎用発注書）。各スキーマには 分類名、 分類プロンプト 自然言語で、そして ドキュメントスキーマ 抽出するフィールドを記述します。実行時に、AIは入力されたフィールドと照合します。 PDF 各スキーマの分類プロンプトに対して、最適なものを選択し、一致した分類名と抽出されたフィールドの両方を返します。同じアナライザーIDは、 REST API そして、サポートされているすべての自動化プラットフォーム。
セットアップの認証
分類アナライザーは PDF4me 開発者ダッシュボード。アカウントでサインインしてから、 API AIパーサーのキー API ここで構築したアナライザーを参照する呼び出し。
- アナライザーリスト（ステップ 1, 2）：
https://dev.pdf4me.com/dashboard/#/ai-document-parser/ - 分析装置の詳細（ステップ 3, 4, 5）：
https://dev.pdf4me.com/ai-document-parser/?id=<analyzer-guid>
見逃してはならない重要な事実
ステップ1：ダッシュボードでAIドキュメントパーサーを開きます
- サインインはこちら pdf4me.com。
- ダッシュボードのサイドバーから、クリックします AIドキュメントパーサー。
- リストページには、既存のアナライザーがすべて3つの列で表示されます。 アナライザーID、 分析装置の種類 （解析または分類） 行動。
- 青色をクリック +追加 新しいアナライザーを開始するには、このボタンをクリックしてください。
AIドキュメントパーサーのリストビューです。「+追加」をクリックすると、新しいアナライザーが起動します。
ステップ2：分類アナライザーを作成する
新しい行が表示され、3つのコントロールが表示されます。
- アナライザーID入力覚えておけるような明確な識別子を入力してください。例:
client_invoices、Vendor Documents、 またはincoming-orders命名形式に制限はありません。スネークケース、キャメルケース、ケバブケース、スペースを含む通常の単語など、すべて同じように機能します。以下の例では、client_invoices。 - アナライザータイプのドロップダウン。 選ぶ 分類する （このガイド）または 解析 （参照） 解析ガイド)
- 保存／キャンセル ボタン。保存するとアナライザーが作成され、キャンセルすると行が破棄されます。
行を追加: アナライザー ID を入力します (ここに 顧客請求書）、 選ぶ 分類するそして保存します。
ステップ3：アナライザーを開き、最初のスキーマを追加します。
新しい行をクリックすると詳細ページが開きます。URLパターンは次のとおりです。
https://dev.pdf4me.com/ai-document-parser/?id=<your-analyzer-guid>
ダッシュボードは、初めて開いたときにアナライザーごとにGUIDを発行します。次回から同じ分類アナライザーに直接アクセスできるよう、このURLをブックマークしておいてください。
詳細ページには以下が表示されます。
- 機密情報 （左）ステップ2で入力したアナライザーIDが表示されます（ここ）
client_invoicesこのパネルは読み取り専用です。 - スキーマ （右）。デフォルトでは空です。各スキーマは1つのドキュメントバリアントです。 + 右上のボタンをクリックして、最初のスキーマを追加します。
- 変更を保存 （左上）。このページで行ったすべての編集内容が保持されます。
- 戻る. に戻る アナライザー一覧。
詳細ページ。 機密情報 左側にはアナライザーIDが表示されます。青色の「+」ボタンをクリックしてスキーマを追加します。
ステップ4：分類名、プロンプト、および文書スキーマを入力します
各スキーマは、アナライザーが処理する必要のあるドキュメントバリアントの1つです。すべてのスキーマには、必須の入力項目が3つと、下部に使い慣れたクイックフィル行があります。
スキーマフィールド（必須）
| 分野 | 目的 | 例 |
|---|---|---|
| Classification Name | The label returned by the API when this Schema matches. Use a short, business-friendly name. | Client ABC |
| Classification Prompt | Natural-language description of how to recognise this variant. Mention company name, email, layout cues, distinguishing phrases. This is what the AI uses to route. | The invoice has the company name ABC at the top, followed by the contact email [email protected]. |
| Document Schema | JSON object with a description and a fields array. Each field has fieldName, fieldType, and fieldDescription, plus an optional fieldMethod such as generate for derived values. | { "description": "Extract invoice detail for ABC invoices", "fields": [ ... ] } |
スキーマ例：クライアントABC
最初のスキーマ。分類名、分類プロンプト、およびドキュメントスキーマは、1つのドキュメントバリアントをまとめて記述します。
{
"description": "Extract invoice detail for ABC invoices",
"fields": [
{
"fieldName": "invoiceNumber",
"fieldType": "string",
"fieldDescription": "Invoice number / bill number / receipt number"
},
{
"fieldName": "invoiceDate",
"fieldType": "date",
"fieldMethod": "generate",
"fieldDescription": "Look for labels: 'Invoice Date', 'Bill Date', 'Date', 'Dated', 'Issue Date', 'Doc Date'. If 4-digit year not found then consider 2-digit year at the end of extracted date."
}
]
}
クライアントABCに対する分類プロンプトは、AIがこのスキーマにたどり着くための自然言語ヒントです。
請求書の上部には会社名ABCが記載されており、その後に連絡先メールアドレスが続きます。
[email protected]。
ステップ5：スキーマを追加して変更を保存する
青色をクリック + もう一度ボタンをクリックすると、次のバリアントのスキーマが追加されます。新しいスキーマごとに、独自の分類名、分類プロンプト、およびドキュメントスキーマが作成されます。スキーマごとにフィールドの内容は完全に異なる場合があります。例えば、クライアントABCには顧客参照列がないのに、クライアントXYZにはあるといった具合です。
例2のスキーマ：クライアントXYZ
同じアナライザーの 2 番目のスキーマ。両方のスキーマは現在、以下の場所にあります。 顧客請求書。
{
"description": "Extract Invoice data from company XYZ's Invoice",
"fields": [
{
"fieldName": "invoiceNumber",
"fieldType": "string",
"fieldDescription": "Invoice number / bill number / receipt number"
},
{
"fieldName": "invoiceDate",
"fieldType": "date",
"fieldMethod": "generate",
"fieldDescription": "Look for labels: 'Invoice Date', 'Bill Date', 'Date', 'Dated', 'Issue Date', 'Doc Date'. If 4-digit year not found then consider 2-digit year at the end of extracted date."
}
]
}
保存するとスキーマリストが折りたたまれます
両方のスキーマが追加されると、リストにはそれぞれ折りたたみ可能なカードとして表示され、左側に分類名、右側に展開ボタン（シェブロン）が表示されます。カードをクリックすると、後で再度編集できます。
両方のスキーマが保存されました。カードをクリックすると展開して編集できます。+ をクリックするとバリエーションを追加できます。
クリック 変更を保存 左上にある設定で、追加したすべてのスキーマを永続化します。アナライザーが稼働し、受信準備が整いました。 PDFs。
ドキュメントスキーマ内のフィールドレベルのオプション
| 属性 | 必須？ | その機能 |
|---|---|---|
fieldName | Required | The name of the field and how it will appear in the response JSON. |
fieldType | Required | The type of data to extract. One of string, number, date, or table. |
fieldDescription | Required | Natural-language description of what needs to be extracted and where to find it. Include alternate labels and example formats so the AI matches correctly. |
fieldMethod | Optional (default extract) | How the AI fills the value. extract takes the value verbatim from the document. generate tells the AI to derive or normalise it (useful for dates, computed totals, or cleaned-up IDs). Omit for default extract behaviour. |
fields | Required when fieldType is table | Nested array describing the columns of the table. Each entry takes the same attributes as a top-level field (fieldName, fieldType, fieldDescription, fieldMethod). Cannot itself be table. |
テーブルフィールド（ネストされた行）を含むスキーマ
使用 フィールドタイプ: "テーブル" スキーマが請求書明細などの繰り返し行を抽出する必要がある場合。各テーブルフィールドには独自のネストされた フィールド 列を記述する配列。
{
"description": "Invoice data extractor",
"fields": [
{
"fieldName": "invoiceNumber",
"fieldType": "string",
"fieldDescription": "Invoice number / bill number / receipt number"
},
{
"fieldName": "invoiceDate",
"fieldType": "date",
"fieldDescription": "Look for labels: 'Invoice Date', 'Bill Date', 'Date', 'Dated', 'Issue Date', 'Doc Date'. If 4 digit year not found then consider 2 digit year at the end of extracted date.",
"fieldMethod": "generate"
},
{
"fieldName": "lineItems",
"fieldType": "table",
"fieldDescription": "All product / service rows from the invoice table. Be careful, sometimes a row can be part of the next item like when description goes over one line, but it's of a single item.",
"fields": [
{
"fieldName": "itemNumber",
"fieldType": "string",
"fieldDescription": "Product number, product id number or product code"
},
{
"fieldName": "hsnCode",
"fieldType": "string",
"fieldDescription": "HSN / SAC code (4 to 8 digit)"
}
]
}
]
}
クイックフィルボタン（出発点として使用）
スキーマエディタは 請求書 そして 注文書 ドキュメントスキーマカードの下部にあるプリセットボタン。 これらを出発点として活用してください 特定のドキュメントファミリーの典型的なスキーマを作成するには、いずれかをクリックします。その後、フィールド名、型、メソッド、説明を、設定する特定のバリアントに合わせて調整します。プリセットはあくまでも骨組みであり、最終的な形状ではありません。
Classify Analyzer を使用する API または自動化呼び出し
一度保存すれば、同じアナライザーIDは参照によってどこでも実行できます。プラットフォームごとにスキーマを再作成する必要はありません。
| 分野 | ソース | 目的 |
|---|---|---|
AnalyzerId | ステップ2で入力した文字列（client_invoices） | Classify Analyzer用の安定した識別子。 |
docName | ソース PDF ファイル名 | 追跡情報やエラーメッセージの表示に使用されます。 |
docContent | ソース PDF エンコードされた Base64 | 分類および抽出対象となる文書。 |
async | false 同期の場合、 true 世論調査のために | 応答配信を制御します。 |
例 REST リクエストボディ:
{
"docName": "incoming_invoice.pdf",
"docContent": "BASE64_ENCODED_PDF_CONTENT",
"AnalyzerId": "client_invoices",
"async": false
}
レスポンスには、一致した分類名と、そのスキーマのドキュメントスキーマで定義されているフィールドが含まれます。クライアントABCとして認識されたドキュメントからはクライアントABCのフィールドが返され、クライアントXYZとして認識されたドキュメントからはクライアントXYZのフィールドが返されます。1回の呼び出しで両方の判断が行われます。
一般的なワークフロー
典型的な分類アナライザーのパターンHow a Classify Analyzer with multiple Schemas runs in production.
- ABC社、XYZ社、その他数社からの仕入先請求書が、一つの郵便受けに届く。
- Make、 Zapier、 Power Automate、 または n8n AIパーサーを呼び出す
アナライザーID: client_invoices。 - レスポンスには、分類名（クライアントABC、クライアントXYZなど）と抽出されたフィールドが含まれます。
- スイッチステップは、各結果を対応する ERP 分類名を使用して顧客レコードを取得します。抽出されたフィールドは、請求書レコードに直接入力されます。
- 新規取引先が初めて、レイアウトの異なる請求書を送付してきた。
- 既存の
顧客請求書ダッシュボードのアナライザーをクリックして +。 - 新しいスキーマが追加され、分類名（ベンダー名）、レイアウトを説明する分類プロンプト、および重要なフィールドのドキュメントスキーマが含まれます。
- 次の到着便 PDF 新しいスキーマに自動的にルーティングされます。自動化の再配線は不要です。
- One Analyzerは、請求書、発注書、およびクレジットノートに対応しています。
- 各スキーマの分類プロンプトは、識別マーカー（「含む」）を説明します。 請求先 「支払合計金額」と「発注番号と配送先住所が含まれている」のどちらが正しいか。
- ドキュメントスキーマは、スキーマごとに、そのドキュメントタイプに関連するフィールドを抽出します。
- 下流ルーティングは分類名に基づいて分岐し、各分岐は一致するシステムに書き込みます。
Classifyのスキーマに関するベストプラクティス
- 安定した文書バリアントごとに1つのスキーマが必要です。レイアウトが大きく異なる2つのベンダーは、重複するルールを持つ1つのスキーマではなく、2つのスキーマとして扱うべきです。
- 分類プロンプトは、ルーティングルールです。平易な英語で記述し、具体的な目印（会社名、メールアドレス、特徴的なフレーズ、レイアウトのヒントなど）を含めてください。
- 分類名は短く、ビジネスに分かりやすく、かつ安定したものにしてください。これは、下流のルーティングが分岐する際の基点となります。
- 請求書と発注書のクイック入力ボタンを起点として、各バリエーションのフィールド説明を詳細に記述してください。
- 追加
fieldMethod: "generate"日付、計算された合計値、またはAIが値をそのままコピーするのではなく正規化する必要があるフィールドに対して。 - 本番稼働前に、各スキーマを実際のサンプルに対してテストしてください。例えば、明らかな顧客ABCの請求書は、常に顧客ABCのスキーマにルーティングされるべきであり、顧客XYZにルーティングされるべきではありません。
- クリック 変更を保存 編集作業のたびに、保存されていないスキーマはナビゲーション時に失われます。