発注データを在庫システムに連携
エンジニア不要で実現

抽出したPOデータと在庫システムの本当のギャップはテクノロジーではなく、フォーマット変換です

購買マネージャーに、AIツールがPOフィールドをスプレッドシートに抽出した後、何が起こるか尋ねると、業界を問わず同じ答えが返ってきます。「ファイルを開き、在庫システムが期待する列名に合わせて半分の列名を変更し、日付形式を修正し、ベンダーの内部IDを調べ、システムが必要とする場合はデータをヘッダーと明細項目に分割し、CSVとして保存し直す」。それは統合ではありません。再フォーマットです。そして、インポートのたびに15〜30分を消費します。

このステップが存在するのは、POデータがサプライヤーの言語（「Order Date」「Vendor」「Part #」）で届き、在庫システムは独自の言語（「TranDate」「VendorName」「PartNumber」）を話すからです。この間の翻訳作業は、アップロードを行う担当者にのしかかります。ほとんどのチームはこれを避けられないものと考えています。しかし、そうではありません。

問題はフォーマットの多様性によってさらに複雑化します。30のサプライヤーから調達するメーカーは、30種類のレイアウトのPOを受け取ります。AIを活用したPOフィールド抽出のようなツールを使ってデータをきれいなスプレッドシートに抽出した後でも、人間が読むのに適した構造（サプライヤーごとにグループ化され、説明的な列ヘッダーがある）は、在庫システムのインポートエンジンが受け付ける構造とほとんど一致しません。修正には、見た目が正しいだけでなく、ターゲットシステムが実際に何を期待しているかを理解する必要があります。

ダウンストリームのワークフローは変わりません。それがポイントです

チームが新しいデータ入力方法の採用に抵抗するとき、それはめったにデータ入力が好きだからではありません。壊れやすいが機能するパイプラインをその周りに構築しており、変更があるたびに「これで受入は機能するのか？ パトアウェイはまだ動くのか？ サイクルカウントはどうなるのか？」と尋ねるからです。適切に設定された抽出から在庫へのフローにおける答えは、それらのどれも変わらないということです。

ワークフローで変わらない部分は次のとおりです。

• 入荷処理 — 倉庫スタッフは従来どおり、入荷商品を在庫システム上の発注書と照合します。出荷到着時には発注書はすでにシステムに登録されています。
• 棚入れ — 保管場所、通路割り当て、スキャンワークフローは影響を受けません。在庫記録は手動入力の場合と同様、インポートによって作成されます。
• サイクルカウントと実地棚卸 — 実在庫とシステム記録を照合します。記録の発生源（手動入力かインポートか）はカウントプロセスにまったく影響しません。
• 仕入先との照合 — 買掛金チームはシステム上の請求書と発注書を照合します。発注書データは存在しており、照合ロジックはデータの入力方法を考慮しません。
• 再発注トリガー — 最小在庫レベル、リードタイム、再発注点はすべて、発生源に関係なくシステムデータに基づいて動作します。

変更されるのは、発注書データがシステムに入力される方法だけです。誰かがPDFを読み、在庫UIにフィールドを手入力する（またはスプレッドシートにコピーしてからインポートする）代わりに、データは抽出→構造化出力→インポートの流れで処理されます。手動入力が1つのステップに置き換わるだけです。以降のすべてのプロセスはそのまま維持されます。

新ステップ（AI抽出→構造化出力）が手動入力を置き換えます。取込以降の処理は従来と同一です。

抽出列名は元文書ではなく、対象システムに合わせる

この統合手法により、再フォーマット作業が完全に不要になります。仕入先の文書に合わせた列見出し（「注文番号」「仕入先」「品目コード」）でPOデータを抽出し、後で手動で名前を変更するのではなく、抽出列名を在庫システムが取込時に期待する名前に正確に合わせます。

これを可能にする仕組みはカラム名抽出です。「PONum」「VendorName」「PartNumber」など、取得したいデータフィールドを指定すると、AIが各フィールドの意味を理解し、ドキュメント上の該当する値を自動で特定します。サプライヤーがどのような名称を使っていても問題ありません。「Order Reference」「PO #」「Document No.」など、すべて「PONum」にマッピングされます。AIはラベルではなく意味を読み取るからです。

これにより従来のワークフローが逆転します。通常は、まずデータを抽出し（その時点では自然なカラム名を使用）、スプレッドシートにエクスポートし、在庫システムのインポートテンプレートと比較してカラム名を変更し、日付を再フォーマットしてからインポートします。カラム名アライメント方式では、抽出とフォーマットを一度に完了できます。出力ファイルは既にターゲットシステム向けに構造化されています。

発注書にフィールドが不足している場合（サプライヤーが明細ごとの納期を記載していないが、在庫システムでは必須の場合など）は、抽出時に計算カラムを使用して不足を補えます。納期が発注書ヘッダーにのみ存在する場合、計算カラムですべての明細行にその値を導出できます。単価がなくても明細合計と数量があれば、単純な合計 ÷ 数量の計算で補完できます。抽出エンジンは、存在するデータの検出と、暗黙的に存在するデータの導出の両方を処理します。

複数のPOを一度に処理する場合（異なる仕入先からのPDFが50枚重なっている場合など）、バッチ抽出では、すべてのファイルに対して同じ列名マッピングを一度に適用します。バッチ内にいくつの異なる仕入先フォーマットがあっても、出力はインポート可能な単一の構造化ファイルになります。

5つの在庫システムが実際にPOデータを受け取る方法 — 抽出出力が一致すべき内容

各在庫システムには固有のインポート形式があります。違いは小さいですが重要です — 1つの詳細を間違えるとインポート全体が失敗します。以下は、各システムの公式ドキュメントに基づく期待される形式と、それに合わせた抽出出力の構成方法です。

Fishbowl Inventory

Fishbowlは北米の製造業や卸売業で広く使用されています。その発注書のCSVインポートでは、2行タイプのフラグシステムを使用します：

• 行タイプ1 — POヘッダー：最初の列にテキスト「PO」を含みます。フィールドにはPONum、Status（数値：10=見積依頼、15=承認待ち、20=発行済み、95=履歴）、VendorName（大文字小文字を区別せず、見つからない場合は自動作成）、RemitToName、ShipToName、CarrierName、日付フィールドがあります。
• 行タイプ2 — 明細行：最初の列にテキスト「Item」を含みます。フィールドにはPOItemTypeID（数値：10=購入、20=クレジット返品、30=外注、40=出荷）、PartNumber（既存のFishbowl部品と一致する必要あり）、VendorPartNumber、PartQuantity、UnitCostがあります。

Flag,PONum,Status,VendorName,RemitToName,...
PO,PO-2026-0423,20,Acme Industrial,Acme Industrial,...
Item,10,PART-8842,VP8842-A,250,14.75,...
Item,10,PART-7721,VP7721-B,100,22.30,...

Zoho Inventory

Zoho Inventoryでは、フィールドマッピング機能付きの標準CSVインポートを提供しています。Fishbowlのフラグシステムとは異なり、Zohoは各行が明細項目を表すフラット構造を採用しており、ヘッダーレベルのフィールドは複数の行にわたって繰り返されます。

• Zohoのインポートページからサンプルインポートテンプレートをダウンロードしてください。期待される正確な列ヘッダーと順序が含まれています。
• インポート時に、CSVの列をZohoのフィールドに対話的にマッピングできます。つまり、列名がZohoのフィールド名と完全に一致する必要はなく、アップロード時に調整できます。
• 必須フィールドは、仕入先名、品目名、数量、単価です。インポート前に、仕入先と品目名がZohoに存在している必要があります。

仕入先名,品目名,数量,単価,発注番号,納期
Acme Industrial,PART-8842,250,14.75,PO-2026-0423,2026-05-15
Acme Industrial,PART-7721,100,22.30,PO-2026-0423,2026-05-15

Cin7 Core

Cin7 Core（旧DEAR Inventory）は、RecordTypeベースのCSV構造を使用しており、一般的なものより複雑です。各行の最初の列がその行のデータタイプを決定します（公式インポートドキュメント参照）：

• RecordTypeの値：header、invoice_lines、stock_received、additional_costs、payments、credit_notes、refunds、unstock。
• ヘッダー行（列名）は必須 — Cin7はヘッダー行をチェックしてCSVタイプを検証します。
• 1つのファイルに複数の購買タスクを含めることができます（インポートあたり最大100タスク）。
• 重要な制限：CSVを使用して既存の購買明細を編集することはできません — インポートは新規タスク作成専用です。既存明細はAPIで管理する必要があります。

RecordType,Supplier,OrderNumber,OrderDate,...
header,Acme Industrial,PO-2026-0423,2026-05-10,...
invoice_lines,ITEM-8842,250,14.75,...
invoice_lines,ITEM-7721,100,22.30,...

Katana MRP

Katana は上記の CSV 中心のシステムとは異なるアプローチを採用しています。主な統合方法は REST API であり、CSV インポートではありません。これはより強力ですが、非技術者にとっては最初は難しく感じられます。

• QuickBooks Online、Xero、Shopify、HubSpot、BigCommerce、WooCommerce とのネイティブ統合が可能です。
• API は、製品/バリアント、顧客/仕入先、販売注文、購買注文、在庫調整、在庫移動の作成をサポートしています。
• Webhook は、注文ライフサイクルの変更（作成、更新、削除）を外部システムに通知します。
• Katana の パートナーディレクトリ には、カスタムワークフローを構築できる統合パートナーが掲載されています。

API開発リソースがないチームにとって現実的な方法は、POデータをスプレッドシートに抽出し、Katanaの製品インポート（CSV対応）で新しい材料を作成した後、手動でPOを作成するか、QuickBooks/Xeroの連携機能を利用することです。KatanaがQuickBooks Onlineと連携していれば、QuickBooksで作成したPOは自動的にKatanaに反映されます。

NetSuite

NetSuiteの発注書のCSVインポートは、ここで取り上げた5つのシステムの中で最も構造的に要求が厳しいものです。主な要件は次のとおりです。

• 2つの別々のファイル — 1つはPOヘッダー用、もう1つは明細行用です。両方のファイルに存在し、完全に一致する外部IDフィールドでリンクされます。
• 仕入先参照は内部IDまたは外部IDを使用する必要があります。仕入先名の文字列は検証に失敗します。インポートファイルを作成する前に、NetSuiteの仕入先マスターから数値の仕入先IDを調べる必要があります。
• 日付形式: 先頭ゼロなしのM/D/YYYY（例：3/5/2026、03/05/2026は不可）。
• 単一ファイル形式では、同じPO番号がヘッダーとすべての明細行で繰り返されます。2ファイル形式では、外部IDがそれらをリンクします。
• 直送POには、別のカスタムフォームを使用した個別のインポートジョブが必要です。

外部ID,注文番号,仕入先,仕入先内部ID,取引日
EXT-0423-001,PO-2026-0423,Acme Industrial,8842,2026/3/5

外部ID,品目,品目内部ID,数量,単価,金額
EXT-0423-001,PART-8842,4421,250,14.75,3687.50
EXT-0423-001,PART-7721,3398,100,22.30,2230.00

Google Sheetsを橋渡しに — CSVファイルを完全に避けたいチーム向け

CSVファイルの管理をチーム全員が担いたいとは限りません。特に、処理済みと未処理の状況を複数人で確認する必要がある場合です。週に20～50件のPOを処理する小規模な購買チームであれば、Googleスプレッドシートとノーコード連携プラットフォームを組み合わせることで、CSVインポートの手順を自動化されたパイプラインに置き換えられます。

設定は3つの層で構成されます：

1. Googleスプレッドシートへの抽出。抽出データをCSVとしてダウンロードする代わりに、直接Googleスプレッドシートに送信します。ImageToTable.aiはGoogleスプレッドシートアドオンを提供しています。スプレッドシート内のサイドバーでPDFや画像をアップロードし、抽出したい列名を指定すると、構造化データが直接スプレッドシートに追加されます。ファイルのダウンロードや手順間の形式変換は不要です。
2. フォーマット層。同じシート内の専用タブに、参照用のルックアップテーブル（ベンダー内部ID、品目番号マッピング、ステータスコード変換）を保持します。シンプルなVLOOKUPやINDEX/MATCH数式で、システム固有の値を抽出結果に反映します。抽出でベンダー列に「Acme Industrial」と出力された場合、隣の列の数式がNetSuiteベンダーID「8842」を返します。このルックアップタブは一度メンテナンスすれば、インポートごとに更新する必要はありません。
3. 在庫システムへのプッシュ。ZapierやMakeなどのプラットフォームが、Googleスプレッドシートと在庫システムを連携します。Zapが新しい行を監視し、必要に応じてデータを変換し、在庫システムに対応するPOレコードを作成します。直接コネクタがないシステムの場合は、SkyviaがGoogleスプレッドシートから在庫システムへのCSVインポートをスケジュールジョブとして処理します。

この方法は初期設定（数式とZapの設定）に時間がかかりますが、ダウンロード、開く、確認、アップロードといった定型的な手作業が不要になります。週30件のPOを処理するチームの場合、月あたり約5～7時間のファイル処理時間を節約でき、初期設定は2時間で済みます。

トレードオフは確かに存在します。Google Sheets方式は依存関係（Zapが稼働し続けること、数式が正しいこと）が生じる代わりに、可視性（チームメンバーは誰でもシートを確認して処理状況を把握できる）を得られます。購買を一人で担当するチームには、直接CSVインポートの方がシンプルです。複数のメンバーがPOデータを扱うチームでは、Google Sheetsを介した共有可視性が、追加の仕組みに見合う価値をもたらします。

60秒でできるインポート前チェックリスト

直接CSVインポートでもGoogle Sheets方式でも、以下の4つが間違っているとインポートは静かに失敗します。アップロード前に毎回確認してください。

もう一つ知っておくべき静かな失敗はエンコーディングの破損です。特殊文字（部品説明の™記号、欧州ベンダー名のアクセント付き母音）を含むサプライヤー名は、抽出時はそのままでも、CSV保存時にUTF-8からASCIIにエンコーディングが変わると破損する可能性があります。スプレッドシートのプレビューでは正しく見えても、インポートエンジンの文字列比較で失敗するため、発見が難しい問題です。対策は簡単で、常にUTF-8 CSVで保存し、エンコーディングオプションがある場合はそれ以外を選択しないことです。

よくある質問

これを機能させるには、仕入先のPO送信方法を変更する必要がありますか？

いいえ。列名抽出はフォーマットに関係なくフィールドの意味を読み取ります — これが仕入先側の変更を不要にする仕組みです。仕入先がPDF、メール添付、ポータルのスクリーンショット、スキャン画像のいずれで送信しても、AIは指定されたデータを特定します。仕入先に標準テンプレートやポータルの採用、新しい動作を求める必要はありません。これが、テンプレートベースの抽出（フォーマットのバリエーションで機能しなくなる）とセマンティック抽出（機能し続ける）の根本的なアーキテクチャ上の違いです。

私の在庫管理システムがここに挙げられている5つ以外の場合はどうすればよいですか？

列名アライメントの原則は、CSVインポートを受け付けるあらゆるシステムで機能します。お使いのシステムのインポートドキュメント（「[システム名] CSVインポート」または「[システム名] 発注書インポート」で検索）で期待される正確な列ヘッダーを確認し、それらを抽出列名として使用してください。マッピングの手順は同じで、特定のフィールド名が異なるだけです。システムが（Katanaのような）APIベースのインポートを使用しており、開発者アクセス権がある場合、APIドキュメントにJSONフィールド名が記載されています — CSVヘッダーの代わりにそれらを抽出列名として使用してください。

在庫管理システムが必要とするすべてのフィールドがPOにない場合はどうすればよいですか？

3つのアプローチを、労力が少ない順に紹介します。1つ目は、抽出時に計算列を使用する方法です。システムが明細ごとに納期を必要とするが、POではヘッダーにしか記載されていない場合、計算列でヘッダーの値を各行に割り当てられます。単価が欠落しているが、明細合計と数量が存在する場合、合計 ÷ 数量で補完できます。2つ目は、POごとに変わらない値（支払条件、配送方法、デフォルト倉庫の場所など）の小さなルックアップテーブルを維持し、抽出後に出力にマージする方法です。3つ目は、在庫システムのインポートで特定のフィールドにデフォルト値を受け入れるように設定する方法です（NetSuiteのImport Assistantでは、フィールドマッピングページでこれをサポートしています）。

30の異なるサプライヤーから30の異なる形式のPOを処理する場合でも機能しますか？

はい — そして、ここで列名の整合性アプローチがテンプレートベースの方法よりも大幅な時間節約を実現します。テンプレートベースのインポートでは、30のサプライヤー形式に30のインポートテンプレートが必要で、いずれかのサプライヤーの形式変更があればテンプレートの更新が必要です。セマンティック抽出では、列名を一度定義するだけで（在庫システムが期待するフィールドに合わせる）、AIがサプライヤー側の形式のバリエーションを処理します。バッチ処理により、30のPOすべてを1回のパスで処理できます。抽出は各ファイルに対して独立して実行され、同じ列名マッピングが適用され、結果は在庫システムのインポート用に構造化された単一の出力ファイルにマージされます。

抽出でフィールドが間違っていた場合はどうなりますか？

インポートは失敗します。しかし、間違ったデータを静かに取り込むよりは、その方がはるかに良いのです。ほとんどの在庫管理システムは、ファイルを受け入れる前に参照キーを検証します。ベンダー名や品番が既存のレコードと一致しない場合、インポートはその行を拒否し、エラーを生成します。これにより、データがシステムに入る前に抽出を修正する機会が得られます。参照データに対して「最善の推測」で一致させる在庫管理システムはありません。キーが完全に一致するか、行が拒否されるかのどちらかです。よくある抽出エラーのパターンと、インポート前にそれらを発見する方法については、ERPインポート失敗の6つのカテゴリと、その原因を解決する方法をご覧ください。

抽出と在庫システムの間の1ステップ

「POデータが抽出された」状態と「在庫システムに入った」状態の間にあるギャップは、ITプロジェクトを必要とする技術的な問題ではありません。これは、列名マップを必要とするフォーマット一致の問題です。在庫システムが期待するもの（正確なフィールド名、参照キーの種類、日付形式）がわかれば、抽出をその構造に直接出力するように設定できます。手動での再フォーマット手順は不要になります。

POをExcelで処理してから在庫システムに再入力している場合、列名の調整アプローチにより、両方のステップを1回のパスに置き換えることができます。システムのインポート形式に直接抽出し、アップロードするだけです。