ベンダー見積をGoogle スプレッドシートに抽出
して横並び比較

ベンダー比較テンプレートに手作業でのデータ入力がまだ必要な理由

Smartsheet、Asana、Xappex、あるいは3年前に財務チームがExcelで作ったものなど、どのベンダー比較テンプレートをダウンロードしても、その構造は共通しています。重み付けされた評価基準の列、スコアリング関数、そして最適なサプライヤーを浮き彫りにするランキングサマリーです。Xappexの無料ベンダー比較テンプレートのようなテンプレートには、あらかじめ定義された評価基準フィールド、カスタマイズ可能な重み付け係数、最終ランキングを計算するための組み込み関数が用意されています。比較のステップには確かに役立ちます。しかし、その前のステップにはまったく役に立ちません。

比較テンプレートは、RFQから始まり、サプライヤーからの回答が届く受信トレイを経由する一連の流れの最後に位置します。各サプライヤーは異なる形式で送ってきます。SAP Aribaから整形されたPDFを出力するサプライヤーもいれば、手書きの署名が入った印刷見積書をスキャンしてメールするサプライヤーもいます。また、条件とは別のシートに価格を記載したExcelスプレッドシートを添付するサプライヤーもいます。テンプレートはこれらのファイルをどれも開くことができません。PDFの段落の中から単価を見つけたり、スキャン文書の2ページ目から納期リードタイムを特定したりすることもできません。テンプレートが受け取れるのは、人間がすでに転記したデータだけです。

だからこそ、調達のプロフェッショナルがRedditでこう質問したのです。「5つの異なるPDF見積書を、正気を保ったまま比較する方法はありますか？ 何かツールがあるのでしょうか、それともみんなExcelにコピペしているのでしょうか？」（r/procurement）。この質問は問題の構造を明らかにしています。比較のためのツールは存在するが、抽出は依然として手作業だということです。別のr/procurementスレッドでは、あるユーザーが現実をこう述べています。「見積を依頼するたびに、PDF、Excelシート、スキャン文書、メール本文など、まったく異なる形式で3〜5件の回答が届きます。」

この断絶は構造的なものです。比較テンプレートは評価フェーズのために作られました。データ抽出はそもそも対象外だったのです。そして、CoupaやJaggaerのような調達ソフトウェアが抽出と評価の両方を1つのエンタープライズプラットフォームにバンドルしているため、抽出にはERP移行が必要だという思い込みが広まりました。これは誤ったトレードオフであり、調達スタック全体を置き換える準備ができていない何千もの中小規模チームが、コピペに留まり続ける原因となっています。

アドオンによるワークフロー：PDF見積から比較シートまでを1つのタブで完結

ほとんどの文書抽出ツールは同じ構造を採用しています。スプレッドシートを離れ、別のWebダッシュボードを開き、ファイルをアップロードして処理し、結果をダウンロードしてから、比較シートに再アップロードまたはコピーペーストする必要があります。そのたびにコンテキストが失われます。Google スプレッドシートのアドオンはこれを逆転させます。抽出エンジンがスプレッドシート内のサイドバーパネルとして動作し、データの右側に表示される狭いペインを拡張機能メニューから開きます。サイドバーから見積PDFをアップロードすると、抽出されたデータは現在アクティブなシートの次の行に追加されます。宛先がすでに開いているため、エクスポートの手順は不要です。対応フィールドタイプ、形式、プラン詳細などの完全な機能一覧は、Google スプレッドシート アドオンの機能ページをご覧ください。

5社のサプライヤー見積を比較する場合の完全なワークフローは次のとおりです。

1. 比較シートを開きます。これはすでに使用しているスプレッドシートです。加重基準の列、単価比較用のMIN/MAX 関数、最低合計額を強調表示する条件付き書式が設定されているものです。何も変わりません。アドオンは行を追加するだけで、シートを置き換えるわけではありません。

2. サイドバーで抽出列を定義します。各見積から必要なデータに一致するフィールド名を入力します。単価、MOQ（最小注文数量）、リードタイム、支払条件、見積有効期限などです。これらが、アップロードされたすべての見積でAIが検索する列になります。サプライヤーが各値をどのようにラベル付けまたは配置しても関係ありません。（ImageToTable.ai ウェブサイトでカスタム列抽出を使用したことがある場合 — 列名を入力すると、AIが値の位置ではなく意味を理解して一致する値を特定する仕組み — アドオンは同じエンジンを使用しますが、結果はアクティブなシートに直接追加されます。）

3. サプライヤー見積をアップロードします。PDF、スキャン画像、Excelファイルをサイドバーにドラッグします。1つずつでも、すべて一度に選択しても構いません。サプライヤーAのラベル付きテーブル列を持つSAP生成PDF、サプライヤーBの本文に価格が記載されたメールのスクリーンショット、サプライヤーCの手書き数量が記入されたスキャン済みフォーム — すべて同じアップロードキューに入ります。アドオンはPDF、JPG、PNG、WebP、AVIFに対応しています。

4. 抽出します。AIが各見積を読み取り、列名に一致する値を特定し、アクティブなシートの下部に新しい行として追加します。サプライヤーAの「Unit Rate (Qty 500+)」、段落に埋め込まれたサプライヤーBの単価、フォーム欄に手書きされたサプライヤーCの数字は、すべて同じ「単価」列に格納されます。サプライヤーごとに1行です。手動入力は不要です。

5. 比較数式が自動的に実行されます。新しい行が、すでに構築した加重スコアリング計算に反映されます。テンプレートで=MIN(E2:E6)のような数式を使用して最低単価を求める場合、ゼロではなく5つの値が対象になります。条件付き書式が最適なサプライヤーを強調表示します。テンプレートが設計された目的である比較ステップに、ようやくデータが揃います。

2つのアプローチの時間差は、見積数量に応じて拡大します。5社のRFQで各20行の明細がある場合、5つのPDFにわたって単価、数量、リードタイム、条件など、約100件の手動セル入力を要します。手動入力には、集中したコピー＆ペーストで30〜45分かかります。サイドバーワークフローでは、アップロード時間2分未満＋AI処理で同じ抽出を完了します。バッチ抽出の比較で実証されたように、処理時間は値1件あたり数分ではなく、ドキュメント1件あたり数秒です。

計算は抽出で終わりません。総輸入コスト（単価×数量＋送料＋サプライヤー別手数料）を比較する必要がある場合は、計算列を使用できます。列名に数式を定義し（例：「Landed Cost (Unit Price × Qty + Freight)」）、AIが抽出中に計算を実行して結果を直接出力します。シートに出力されるのは、Excelの数式を待つ生データではなく、比較にすぐ使える数値です。

見積比較列の設定

このワークフローで最も重要な決定は、AIに何を抽出させるかです。サイドバーに入力する列名によって、返ってくるデータが決まります。「価格」と入力すると、AIは見つけた価格を返しますが、それは単価かもしれないし、合計額かもしれないし、割引後の価格かもしれません。文書によって異なります。具体性が重要です。

調達比較の場合、以下のフィールドが実用的な比較テーブルを生成します：

この6つの列で、価格、数量制約、納期、キャッシュフローへの影響、意思決定の期間という、調達判断が実際に依存する5つの側面をカバーする比較テーブルが作成されます。送料、保証期間、その他特定のRFQに関連するフィールドを追加することもできます。AIは各文書内で各値を独立して検索します。

サプライヤーの見積書に特定のフィールドが含まれていない場合 — たとえば、サプライヤーCの見積書が支払条件のない単純な価格表である場合 — 出力テーブルの該当セルは空になります。そのギャップを埋めるためにサプライヤーCにフォローアップします。抽出はデータを捏造しません。見つけたものを報告し、見つからない箇所は空白のままにします。

異なる形式を送ってくるサプライヤーへの対応

理想的な調達プロセスでは、すべてのサプライヤーが標準化されたRFQテンプレートに記入し、同一のExcelシートを返送します。しかし実際には、r/procurementのスレッドを見ると、これはほとんど起こりません。あるコメンターはこうアドバイスしています：「Excelテンプレートを送ってください。そのExcelテンプレートについて、見積もりが『比較可能』となるために必須の項目（上位約10項目）は何ですか？」 別のコメンターは現実をこう返します：サプライヤーはテンプレートを無視して、自分たちの形式で送ってくる、と。

このアドオンは、サプライヤーに形式を押し付けるのではなく、届いた形式から意味的にデータを抽出することで、形式のばらつきに対応します。これを可能にする仕組みは3つあります：

テンプレート照合ではなく、意味的抽出。 AIは、「per unit」「unit rate」「each」の横にある「$4.20」が単価であることを理解して特定します。それが表のセル、段落の文章、スキャンされたフォームの手書き注釈のどこに現れてもです。座標を見るのではなく、意味を読み取ります。これは、請求書アドオンのワークフローでベンダー請求書や領収書を処理するのと同じ列名抽出アプローチです。必要なものを定義すれば、AIはサプライヤーが置いた場所にどこでも見つけ出します。

複数ページ対応。サプライヤーの見積もりが1ページだけで済むことはまれです。価格は1ページ目、条件は2ページ目、納期スケジュールは添付の別紙にあるかもしれません。AIはすべてのページを順番に読み取ります。見積有効期限がPDFの3ページ目に埋もれていても、見つけ出します。

混合形式のバッチ処理。5社のサプライヤーから5件の見積もりをアップロードします。PDFが3件、スキャン画像が1件、Excelスプレッドシートが1件です。これを1つのバッチで処理します。AIはそれぞれを独立して処理し、形式を識別し、内容を読み取り、結果を統合出力にまとめます。比較テーブルの各サプライヤー行は、まったく異なるソース形式から来ているかもしれません。出力は区別しません。なぜなら、列構造はサプライヤーが提供したものではなく、あなたが定義したものだからです。

実務的な意味合い：サプライヤーとの形式準拠の交渉をやめることができます。サプライヤーがERP生成のPDF、手書き見積もりのスマホ写真、メール本文のスクリーンショットのどれを送ってきても、抽出結果は同じ構造化された出力になります。つまり、あなたの列、あなたの比較テーブルです。

単価を超えて — MOQ、リードタイム、支払条件の抽出

単価のみを比較するRFQ比較は、効率化を装った調達ミスです。英国調達・供給協会（CIPS）は、調達ベンチマークを「総所有コスト、コンプライアンスとリスク管理、サイクルタイムとリードタイム、不良率と品質基準」の評価と定義しています。単なる初期価格ではありません。最も安い単価でも、リードタイムが12週間、支払条件がNet 7の場合、生産の中断と運転資本の面で、わずかに高い単価でも2週間納品、Net 60の条件よりもコストがかかる可能性があります。

ここで、列名アプローチが特に価値を持ちます。価格の抽出に限定されません。調達判断に重要な要素を定義すれば、AIが各サプライヤーの文書からそれらを見つけ出します。比較を変える3つの列：

MOQ（最小注文数量）。あるサプライヤーが単価3.20ドル、MOQ 5,000と見積もったとします。あなたの注文は1,000個。3.20ドルの価格は、最小注文数量を満たせないため無意味です。多くの比較テンプレートは見積価格のみを記録し、数量制約を見落とします。MOQを別の列として抽出することで、不一致が即座に明らかになります。

リードタイム。サプライヤーAは14日、サプライヤーBは45日と回答。生産スケジュールが3週間以内の材料到着に依存している場合、価格に関係なくサプライヤーBは選択肢になりません。リードタイムの抽出は、物流の詳細を比較の次元に変えます。手動の見積抽出では、この項目が価格とは別のページにあることが多く、見落とされがちですが、AIはすべてのページを読み取ります。

支払条件。一方が「2/10 Net 30」、もう一方が「Net 15」の場合、運営資金の差は価格差を超えることがあります。5万ドルの注文で、15日払いと30日払いの差は2週間の浮き、現在の商業金利で約200ドルです。単価の小さな節約は、不利な支払条件で消し去られます。支払条件を構造化データとして抽出することで、キャッシュフローをスコアリングマトリックスに組み込めます。

これらのフィールドは個別の設定を必要としません。アドオンのサイドバーに列名を一度入力するだけで、AIがアップロードされたすべての見積書からそれらを検索します。結果は、意思決定者が実際に必要とする列を持つ比較テーブルで、比較用に設計されていなかった文書から自動的に生成されます。

FAQ

アドオンは英語以外のベンダー見積もりを処理できますか？

はい。基盤となるAIモデルは複数の言語で書かれたテキストを読み取り、お客様が英語で定義した列名に値を抽出します。日本のサプライヤーの見積もりに「単価」や「納期」と記載されていても、アメリカのサプライヤーのPDFと同じ「Unit Price」や「Lead Time」の列が生成されます。抽出は言語に依存せず、出力スキーマはお客様が指定したものになります。

2つのサプライヤーが異なる品目を見積もった場合、比較はどのように機能しますか？

同じバッチで異なる製品の見積もりをアップロードした場合、AIはそれぞれを個別の行として抽出します。比較が有効なのは、すべてのサプライヤーが同じ仕様を見積もっている場合のみです。アドオンはサプライヤー間の品目マッチングを行わず、各文書に含まれる内容を抽出するだけです。抽出したデータを意思決定に使用する前に、すべての見積もりが同じRFQを参照していることを確認してください。

アドオンはオフラインで動作しますか？データのセキュリティはどうですか？

アドオンはインターネット接続が必要です。抽出はクラウドベースのAIによって実行されます。ファイルは転送中に処理され、抽出完了後は保存されません。接続にはAPI キーを使用して認証し、使用量はアカウントプランの割り当てにカウントされます。基盤となるアーキテクチャはウェブサイトの処理パイプラインと同じで、ブラウザタブの代わりにSheetsサイドバーからアクセスするだけです。

明細項目を抽出できますか、それともヘッダーレベルのフィールドのみですか？

明細項目も抽出できます。見積もり比較に品目レベルの詳細（個別のSKU価格、品目ごとの数量、品目ごとのリードタイム）が必要な場合は、「Item Description」「Item Quantity」「Item Unit Price」などの列を追加してください。AIは明細テーブルを読み取り、明細ごとに1行を生成し、サプライヤー名を各行に繰り返します。これにより、サプライヤーと品目でフィルタリングできる詳細な比較が可能になります。バッチでの品目レベル抽出の詳細については、バッチベンダー見積抽出ガイドをご覧ください。

抽出がサイドバーに移ると、実際に何が変わるのか

この変化は単なるスピードの問題ではありません。抽出作業が比較作業と比べてどこで行われるかという問題です。

抽出が別のステップ（PDFを開く、値を読む、スプレッドシートに切り替える、入力する）である場合、比較シートは処理後にたどり着く目的地です。データ入力の作業を行ってから、比較関数を使うことができます。抽出は、実際の分析を始める前に支払うコストなのです。

抽出がサイドバー内で行われる場合、比較シートが出発点になります。シートを開き、サイドバーを開き、見積書をアップロードすると、行が表示されます。関数が実行され、条件付き書式が作動します。受動的なテンプレートだったものが、ライブパイプラインになります。データを待っていたスプレッドシートが、今やデータを収集しているのです。

これにより、どの文書が抽出されるかが変わります。抽出にRFQあたり30分の手作業が必要な場合、調達チームはそれを節約します。絶対に必要なものだけを抽出し、勝てそうにない見積書はスキップします。サイドバーを通じて抽出に数秒しかかからない場合、そのしきい値はゼロになります。すべての見積書が抽出され、すべてのサプライヤーに公平な比較行が与えられます。調達の意思決定の質が向上するのは、より良い関数が作られたからではなく、より多くのデータが明らかになったからです。

次のRFQでお試しください

次回RFQを送信し、5つの異なる形式のPDFで回答が返ってきたら、比較シートを開き、アドオンを読み込み、それらをアップロードしてください。列が入力されていくのを見てください。スコアリング関数が新しい行を見つけるのを見てください。すでに構築したテンプレートが、ついに比較するために設計されたデータを手に入れます。

このアドオンはGoogle Workspace Marketplaceから入手できます。API キーを接続して、アクティブなシートに直接抽出を開始してください。