カスタム列を定義して
あらゆるアプリのスクリーンショットからデータを抽出する方法
Salesforceの商談カードのスクリーンショットを撮ります。そこには3月15日締めの47,200ドルの機会が表示されています。同じ商談が記載されたQuickBooksの請求書タブのスクリーンショットも撮ります。さらに、2011年に構築された社内の注文追跡ダッシュボードからも3枚目を撮ります。3枚のスクリーンショット、3つのまったく異なる視覚レイアウト、しかし共通する真実は1つ——同じ顧客、同じ金額、同じ締切日です。抽出列を一度定義するだけで——「顧客」「商談金額」「締切日」——この3つの言葉は、各ページのどこに配置されているかを事前に知らなくても、3枚すべてのスクリーンショットでその値を見つけ出します。
同じデータ、まったく異なる3つのスクリーンショット
上記のシナリオは仮定の話ではありません。複数のソフトウェアプラットフォームをまたいで仕事をしている人なら誰でも、この流れを知っています。Salesforceには商談データが、QuickBooksには請求書データが、業務ダッシュボードにはフルフィルメント状況が保存されています。各システムはカード、テーブル、フォーム、ステータスパネルといった独自のビジュアル言語で重複する情報を表示しており、そのデータを1つのスプレッドシートにまとめるには、ウィンドウを切り替えながら3つの異なるインターフェースから同じフィールドを打ち直す必要があります。
この問題への標準的な答えである「APIを使う」や「CSVにエクスポートする」は、すべてのシステムにその機能があることを前提としています。2011年に作られた内部ダッシュボードには、もちろんそんな機能はありません。照合用に必要な取引詳細を表示するモバイルバンキングアプリには、エクスポートボタンがありません。チームが使っているSaaS分析ツールは、毎週追跡している3つの特定のKPI値ではなく、完全なレポートしかエクスポートできません。
スクリーンショットは、すべてのソフトウェアに共通する最小公分母です。あらゆるアプリ、あらゆるデバイス、あらゆる時代のソフトウェアが生成できます。問題は、データをキャプチャできるかどうかではありません(スクリーンショットを撮った時点で、すでにキャプチャしています)。問題は、新しいアプリのインターフェースを個別の技術的問題として扱うことなく、そのキャプチャから特定のフィールドを抽出できるかどうかです。
テンプレートベースの抽出ツール、つまりサンプル文書の請求書日付フィールドの周りに長方形を描き、そのピクセル座標を以降のすべての文書に適用するタイプのツールは、スクリーンショットでは決して機能しません。Salesforceの商談カードは金額を左上の大きなヒーロー数字で表示し、QuickBooksの請求書はテーブルの右下にある「残高」セルに金額を表示し、内部ダッシュボードはメトリクスのグリッド中程にある色付きカードに金額を表示します。3つのUI、3つの座標系。最初のスクリーンショットで機能したテンプレートは、2番目では設計上機能しません。座標は、測定されたアプリの外では何の意味も持たないからです。
異なるアプリケーションのスクリーンショットには、共通の座標系がありません。ピクセル位置に基づくフィールド抽出方法は、砂の上に家を建てるようなものです。その方法は、データがたまたまどこにあるかではなく、データが何を意味するかを理解する必要があります。
これこそが、スクリーンショットを扱うすべての人にとってカスタム列抽出を理解する価値がある理由となる転換点です。これは長方形を描くアプローチの高速版ではなく、根本的に異なる原則なのです。
カスタム列抽出が値の位置を知らなくても値を見つける仕組み
カスタム列抽出は単一の原則に基づいて動作します。見つけたいものを記述すると、AIがページ全体を検索してその説明に一致する値を見つけます。ラベルのテキストをスキャンするのではなく、ラベルの意味を理解し、その意味的役割に適合する値を特定します。
列名として「Deal Amount」と入力するとき、AIにページ上の正確なテキスト「Deal Amount」を探すよう指示しているわけではありません。「ビジネス取引や機会の総額を表す金額値を探す」と指示しているのです。AIはスクリーンショット全体(すべてのラベル、すべての数字、すべてのコンテキストテキスト)を読み取り、その意味的役割を満たす値を見つけます。Salesforceのスクリーンショットでは、それは機会カードの上部に目立つように表示された「$47,200」かもしれません。QuickBooksのスクリーンショットでは、請求書テーブルの「Balance Due」行にある「$47,200」かもしれません。内部ダッシュボードでは、通貨記号なしで色付きメトリックカード内に表示された「47,200」かもしれません。
同じ列名が3つすべてで機能するのは、AIが空間的な問題ではなく意味的な問題を解決しているからです。「このページのどの数字が取引金額として機能するか?」と問いかけているのであって、「座標(340, 128)にあるテキストは何か?」と問いかけているのではありません。この違いは、文書を理解することと写真に撮ることの違いです。
このため、このアプローチは列名抽出と呼ばれることがあります。出力テーブルの列ヘッダーに入力する名前が、そのまま抽出命令として機能します。ルールを設定する別のステップも、サンプル文書に注釈を付けるトレーニングフェーズも、維持するテンプレートライブラリもありません。最終的なExcelファイルに表示される列名が、AIがデータを見つけるために使用した列名と同じです。
テンプレートOCRは「位置(x, y)にあるテキストは何か?」に答えます。カスタム列抽出は「このページのどこに『Deal Amount』を意味する値があるか?」に答えます。最初の質問はアプリを切り替えた瞬間に機能しなくなります。2番目の質問はアプリにまったく依存しません。
スクリーンショット抽出が従来のOCRとどう異なるかについての詳細は、スクリーンショットからデータを抽出する完全ガイドをご覧ください。
ステップバイステップ:列を一度定義すれば、あらゆるスクリーンショットから抽出できます
ワークフローは3つのステップで構成され、ステップ1だけは複数回行う必要はありません。この非対称性がポイントです。最初に思考を投資し、その後のスクリーンショットはすべて同じ定義で再設定なしに処理されます。
ステップ1:必要なフィールドに名前を付けます。これが唯一の判断です。抽出ツールを開き、出力スプレッドシートに表示したいデータポイントに対応する列名を入力します。クロスアプリの取引追跡ワークフローの場合、次のように入力します:
Customer | Deal Amount | Close Date | Stage | Owner
銀行アプリのスクリーンショット、支払い確認、会計システムのダッシュボードからデータを取得する財務照合ワークフローの場合、次のように入力します:
Transaction Date | Amount | Counterparty | Reference | Source App
これらの列名が抽出仕様になります。AIはこれらを「この説明に一致する値を見つける」という指示として読み取り、文字通りの検索文字列としては扱いません。「Customer」というラベルは、異なるアプリのUI全体で「Client」「Account Name」「Bill To」、またはその他の意味的に同等なフィールドに一致します。列名をできるだけ正確にする方法の詳細については、以下の命名戦略セクションに進んでください。
ステップ2:スクリーンショットをアップロードします。Salesforceの取引カード、QuickBooksの請求書タブ、内部ダッシュボードのキャプチャをドラッグ&ドロップするか、10種類のアプリから50枚のスクリーンショットをドラッグ&ドロップします。AIは各スクリーンショットを個別に処理し、同じ列定義をそれぞれに適用します。どのスクリーンショットがどのアプリケーションからのものかを知る必要はありません。
ステップ3:結合されたテーブルをダウンロードします。AIが各列名に対して見つけたすべての値は、スクリーンショットごとに1行として整理されます。出力ファイルの列ヘッダーは、ステップ1で入力した正確な名前です。特定のスクリーンショットに特定の列の値が含まれていない場合(たとえば、内部ダッシュボードに「Owner」フィールドがない場合)、そのセルは空白のままになります。抽出は残りの列に対してエラーなく続行されます。
ファイルは安全に処理され、保存されません。
スクリーンショット抽出の精度を最大化する列名の付け方
列名は、従来の文書処理よりもスクリーンショット抽出において重要な役割を果たします。PDFの請求書では、ほぼ常に「請求番号」「期日」「小計」といった予測可能なラベルテキストが使用されます。一方、スクリーンショットのUIでは、アプリの設計者が選んだラベルが使用され、アプリが異なればラベルも大きく異なります。
以下の命名原則は、異なるチームが異なる規則で設計したUI間で同じ列名が機能する必要がある、スクリーンショットからスプレッドシートへのワークフローに特化して調整されています。
| 原則 | スクリーンショットで重要な理由 | 例 |
|---|---|---|
| UIラベルではなくビジネス概念を使用する | あるアプリでは「Client」、別のアプリでは「Account Name」、3つ目のアプリでは「Customer Name」とラベル付けされています。列名「Customer」は、AIが文字列ではなく意味的な役割を照合するため、3つすべてをカバーします。 | 列: Customer — 異なるUIの「Client」「Account Name」「Bill To」「Customer Name」に一致 |
| 修飾語で類似フィールドを明確に区別する | CRMやERPシステムのスクリーンショットには、複数の類似した数値が表示されることがよくあります。取引カードには「Amount」「Expected Revenue」「ARR」が同じ画面に表示される場合があります。「Deal Amount」は「Amount」よりもはるかに具体的です。 | 「Amount」ではなく「Deal Amount」— 主要な取引額を年換算値や予測値と区別します |
| 出力形式が重要な場合は形式のヒントを含める | アプリによって日付の表示方法は異なります。「03/15/26」「March 15, 2026」「2026-03-15」などです。列名に形式のヒントを含めることで、ソースアプリの表示方法に関係なく、AIに標準化するよう指示できます。 | 「Close Date (YYYY-MM-DD)」— すべての日付形式を単一の標準に正規化します |
| 孤立した数値として表示される値にコンテキストを追加する | ダッシュボードのKPIカードには、近くにラベルがない数値が表示されることがよくあります。大きなフォントで「47,200」と表示され、小さな「% change」の字幕が付くだけです。AIが数値を正しい列に照合するには、十分な意味的枠組みが必要です。 | 「MRR (Monthly Recurring Revenue, USD)」— UIのラベルが最小限の場合に、AIが必要とするコンテキストを提供します |
フィールドデータ収集アプリで600枚以上のスクリーンショットを扱ったRedditユーザーは、命名の問題を簡潔に表現しています。各画像から「Tag Number, Length (cm), Weight (kg), Event Type, Tagger, Date, Time, GPS/Location, Water Temperature」が必要だったのです。括弧内の単位 — 「(cm)」「(kg)」「(°C)」— は任意の詳細ではありません。UIに複数の測定値が同じ画面に表示される場合、どの数値がどれかをAIに伝える指示なのです。
バッチ処理:1つの列定義で、あらゆるアプリのスクリーンショットを何枚でも処理
列名を定義すれば、追加設定なしでワークフローが拡張されます。ここでステップ1への投資が報われます。5枚でも500枚でも、2つのアプリでも20のアプリでも、抽出仕様は変わりません。
モバイルデータロギングアプリから600枚のスクリーンショットを持つフィールドリサーチャーを考えてみてください。各スクリーンショットには同じ種類のデータ(タグ番号、長さ、重量、GPS座標)が含まれ、同じアプリの同じUIレイアウトで整理されています。これは簡単なケースです。同じアプリ、同じレイアウト、ただ量が多いだけです。カスタム列抽出で処理できますが、適切に設定されたOCRテンプレートでも同様に処理できます。
より難しいケース(そしてカスタム列抽出を正しいアーキテクチャにする理由)は、スクリーンショットが異なるアプリケーションから来る場合です。毎週のメトリクスを収集するオペレーションマネージャーは、次のようなものをキャプチャするかもしれません:
- Shopify管理パネルからの売上と注文数(eコマースダッシュボードレイアウト)
- ShipStation画面からの保留中の出荷(物流テーブルレイアウト)
- Zendeskダッシュボードからのカスタマーサポートチケット数(アナリティクスカードレイアウト)
- Chaseモバイルアプリのスクリーンショットからの銀行残高(バンキングアプリカードレイアウト)
各スクリーンショットはまったく異なって見えます。しかし、「売上」「注文数」「保留中の出荷」「未処理チケット」「銀行残高」という列は、すべてのスクリーンショットでその値を見つけます。AIは各スクリーンショットを個別に読み取り、含まれるデータを理解し、一致する値を正しい列にマッピングします。出力は、スクリーンショットごとに1行、定義した列だけを持つ単一のテーブルです。
バッチワークフローの詳細なウォークスルー(命名規則、結果のマージ、複数ソースからのスクリーンショットの処理を含む)については、アプリのスクリーンショットを構造化スプレッドシートにバッチ処理するガイドをご覧ください。スクリーンショット抽出が初めてで、より広い基礎を築きたい場合は、タイピングなしでスクリーンショットからExcelにデータを取得する方法から始めてください。
ここで説明した列名アプローチを使用して、あらゆるスクリーンショットを構造化Excelデータに変換する専用ツールについては、スクリーンショットからExcelへの抽出ツールをご覧ください。
よくある質問
テーブルを含まないスクリーンショット(カードやラベルと値のペアのみ)でも機能しますか?
はい。そのシナリオこそ、テーブル検出ツールよりもカスタム列抽出が最も価値を発揮する場面です。支払い確認画面は、ラベルと値のペアが縦に3つ並んだものです。CRMの取引カードは、非テーブル形式で8〜10個のフィールドが配置されたビジュアルカードです。銀行アプリの取引詳細は、キーと値の行がスクロールするリストです。AIは、レイアウトがテーブル、カード、フォーム、または混在形式のいずれであっても、指定した値を探し出します。グリッド構造ではなく、意味を読み取るからです。
同じスクリーンショット上の2つの異なる数字が、同じ列名に一致する可能性がある場合はどうなりますか?
これこそ、列名の具体性が重要となる理由です。「金額」は曖昧です。Salesforceの商談カードには、取引金額、予想収益、年間経常収益が同じ画面に表示されることがあります。「取引金額」は、曖昧さを排除するのに十分具体的です。それでも曖昧さが残る場合は、形式や位置のヒントを追加できます。「取引金額(カード上の最大のドル金額)」と指定すれば、AIは正しいものを選ぶための十分な枠組みを得られます。列名が正確であればあるほど、曖昧さの余地は少なくなります。
非構造化レイアウトでテキストと数字の両方を含むスクリーンショットからデータを抽出できますか?
はい、合理的な範囲内で可能です。スクリーンショットに自由文の段落があり、その中に必要なデータが含まれている場合(たとえば、「SKU-4421を50個、123 Main Stに発送してください」というチャットメッセージなど)、AIは数量、SKU、住所をそれぞれ別の列として抽出できます。ただし、列名が何を探しているかを明確に示している場合に限ります(「発送数量」「SKU」「配送先住所」など)。抽出精度は構造化されたUIほど高くありませんが、機能します。チャットベースの注文抽出に特化した場合も、同じ列名アプローチが適用されます。
アプリ間のスクリーンショット抽出で、どの程度の精度を期待すべきですか?
精度は3つの要因に依存します。入力品質(鮮明で読みやすいスクリーンショットは、ぼやけたり切り取られたりしたものより良好)、列名の具体性(曖昧な名前は曖昧な一致を生む)、そしてUIの意味的明確さ(フィールドを明確にラベル付けするアプリは、密集したテキストに値を埋め込むものより良い結果を生みます)。実際には、明確なスクリーンショット上の適切に命名された列は高い精度を達成します。金額、日付、名前などの単純なフィールドでは、多くの場合95%以上です。複雑または高度に省略されたUIでは、時折手動でのスポットチェックが必要になる場合があります。そのため、出力テーブルは直接編集できる標準のスプレッドシートになっています。
英語以外の言語のスクリーンショットでもこの方法は機能しますか?
列名はスクリーンショットの言語ではなく、出力先の言語に合わせる必要があります。列が「Customer Name」で、スクリーンショットがドイツ語で「Kundenname」と表示されている場合、AIはこれらが同じ概念を指していることを理解します。意味的マッチングは文字列の一致ではなく意味に基づいて動作するため、言語をまたいで機能します。
Excelの組み込み機能「データから画像」とはどう違うのですか?
Excelの「データから画像」はテーブル検出器であり、行と列のグリッド構造を探してスプレッドシートのセルに変換します。きれいな罫線付きテーブルではうまく機能します。しかし、カードレイアウト、ラベルと値のペア、ダッシュボードのKPI、その他の表形式ではないUIには対応していません。カスタム列抽出ではデータがテーブル形式である必要はなく、ページ上のどこでも意味的な役割に基づいて値を検出します。この2つのアプローチは異なる問題を解決するものです。
定義した列名だけが唯一の設定です——1枚でも1,000枚でも、1つのアプリでも20のアプリでも対応します。
ご自身のスクリーンショットでお試しください。必要なフィールドを入力し、任意のアプリからアップロードして、30秒でコピー&ペーストの繰り返しが不要になるかをお確かめください。