カスタム列の定義方法
あらゆるアプリのスクリーンショットからデータを抽出

同じデータ、まったく異なる3つの画面

上記のシナリオは仮定の話ではありません。複数のソフトウェアプラットフォームをまたいで業務を行う人なら誰でもご存知でしょう。Salesforceには商談データ、QuickBooksには請求書データ、業務ダッシュボードにはフルフィルメント状況が保存されています。各システムは重複する情報をそれぞれ独自のビジュアル言語（カード、テーブル、フォーム、ステータスパネル）で表示しており、それらのデータを1つのスプレッドシートにまとめるには、ウィンドウを切り替えながら3つの異なるインターフェースから同じフィールドを打ち直す必要があります。

この問題に対する一般的な解決策——「APIを使う」や「CSVにエクスポートする」——は、すべてのシステムにそれらの機能があることを前提としています。2011年に作られた社内ダッシュボードにはもちろんありません。 reconciliation に必要な取引明細を表示するモバイルバンキングアプリにはエクスポートボタンがありません。チームが使用している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が空間的な問題ではなく意味的な問題を解決しているからです。AIは「このページのどの数字が取引金額として機能するか？」を問いかけており、「座標(340, 128)にあるテキストは何か？」とは問いかけていません。この違いは、文書を理解することと写真に撮ることの違いに他なりません。

このアプローチが列名抽出と呼ばれる所以です。出力テーブルの列ヘッダーに入力する名前が、そのまま抽出指示として機能します。ルールを設定する別途のステップも、サンプル文書に注釈を付けるトレーニングフェーズも、維持すべきテンプレートライブラリもありません。最終的なExcelファイルに表示される列名こそが、AIがデータを見つけるために使用したものなのです。

スクリーンショット抽出が従来のOCRとどう異なるかについては、スクリーンショットからのデータ抽出完全ガイドをご覧ください。

ステップバイステップ：列定義は一度だけ、あとはスクリーンショットから抽出

ワークフローは3ステップ。最初のステップだけが繰り返し行う作業です。この非対称性こそがポイントです。事前に設計を済ませれば、以降のスクリーンショットはすべて同じ定義で、再設定不要で抽出できます。

ステップ1：必要なフィールドに名前を付けます。これが唯一の判断です。抽出ツールを開き、取得したいデータ項目に対応する列名を、出力スプレッドシートに表示したい通りに入力します。例えば、クロスアプリの案件トラッキングでは、次のように入力します。

銀行アプリのスクリーンショット、支払確認書、会計システムのダッシュボードからデータを抽出する財務照合ワークフローでは、次のように入力します。

これらの列名が抽出仕様です。AIはこれらを「この説明に合致する値を探せ」という指示として解釈します。文字通りの検索文字列ではありません。「顧客」というラベルは、異なるアプリUI上の「クライアント」「アカウント名」「請求先」など、意味的に同等なフィールドにも一致します。列名をより正確にする方法については、以下の命名戦略セクションをご覧ください。

ステップ2：スクリーンショットをアップロード Salesforceの取引カード、QuickBooksの請求書タブ、社内ダッシュボードのキャプチャ、あるいは10種類のアプリから50枚のスクリーンショットをドラッグ＆ドロップしてください。AIは各スクリーンショットを個別に処理し、同じ列定義をそれぞれに適用します。どのスクリーンショットがどのアプリケーションからのものかを認識する必要はありません。

ステップ3：結合テーブルをダウンロード AIが各列名に対して見つけたすべての値が、スクリーンショットごとに1行として整理されます。出力ファイルの列ヘッダーは、ステップ1で入力した正確な名前です。特定のスクリーンショットに特定の列の値がない場合（例：社内ダッシュボードに「所有者」フィールドがない場合）、そのセルは空白のままとなり、残りの列の抽出はエラーなく続行されます。

スクリーンショット抽出の精度を最大化する列名の付け方

列名は、従来の文書処理よりもスクリーンショット抽出において重要です。PDFの請求書にはほぼ常に「請求書番号」「支払期日」「小計」といった予測可能なラベルテキストがあります。一方、スクリーンショットのUIではアプリの設計者が選んだラベルが使われ、アプリごとにそのラベルは大きく異なります。

以下の命名原則は、特にスクリーンショットからスプレッドシートへのワークフロー向けに調整されています。このワークフローでは、異なるチームが異なる慣習で設計したUI間で、同じ列名が機能する必要があります。

600枚以上のスクリーンショットを扱うRedditユーザーが、フィールドデータ収集アプリから「タグ番号、長さ(cm)、重量(kg)、イベントタイプ、タガー、日付、時間、GPS/位置情報、水温」を各画像から抽出する必要があると簡潔に述べています。括弧内の「(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や略語が多いUIでは、時折手動での確認が必要になる場合があります。そのため、出力テーブルは直接編集可能な標準的なスプレッドシートになっています。

このアプローチは、英語以外の言語のスクリーンショットでも機能しますか？

列名は、スクリーンショットの言語ではなく、出力先の言語に合わせる必要があります。列が「Customer Name」で、スクリーンショットがドイツ語で「Kundenname」と表示されていても、AIはこれらが同じ概念を指すと理解します。意味ベースで動作するため、言語を超えたセマンティックマッチングが可能です。

Excelの「画像からデータ」機能との違いは？

Excelの「画像からデータ」はテーブル検出器です。行と列のグリッド構造を探し、スプレッドシートのセルに変換します。整った罫線付きテーブルには有効ですが、カードレイアウト、ラベルと値のペア、ダッシュボードのKPI、その他表形式でないUIには対応しません。カスタム列抽出では、データがテーブル形式である必要はなく、ページ上のどこにあっても意味的な役割に基づいて値を検出します。この2つのアプローチは、異なる課題を解決します。