データ入力は、とっくに解決されているはずだった
何度も

解決されない問題

請求書、領収書、契約書、明細書、検査報告書、出荷伝票など、外部文書を扱うあらゆる組織は同じ問題に直面している。データは紙や画像の形で存在し、システム内に存在する必要がある。文書は、受け取る側ではなく送る側が管理する形式で届く。その情報を、信頼性と正確性を保ちながら大規模に受信システムに取り込むこと、それが現実のデータ入力である。

データ入力の歴史で注目すべきは、各時代が確かにそれ以前を凌ぐ技術を生み出したものの、既存のボトルネックを解消するどころか、新たなボトルネックを生み出したことだ。仕事の性質は変わった。しかし、仕事の量は変わらなかった。

各時代

1950年代～1970年代：パンチカード時代

コンピュータが対話型になる前、データ入力は物理的な製造プロセスだった。発注書、元帳記録、給与計算シートなどの原票は、1文字1穴の割合でIBMパンチカードに変換された。キーパンチオペレーターはタイプライターに似た機械を操作し、80桁のカードに穴を開けた。カードこそがデータだった。

速度よりも正確さが重視されたのは、エラーがすぐには見えなかったからだ。別の機械でカードを打ち直し、不一致を検出する検証工程が標準だった。その後、カードの束は計算センターに提出され、一晩かけて処理され、翌朝に出力が印刷された。もしカードの打ち間違いがあれば、修正して再提出するまでに丸一日かかった。

ボトルネックは人間の手とバッチ処理の待ち時間だった。この作業は熟練を要し、キーパンチオペレーターは認定・試験を受け、大規模な専任プールで雇用されていた。主要組織は、回避策としてではなく、認知された生産機能として、キーパンチオペレーター専用のフロア全体をインフラとして維持していた。

1980年代～1990年代：スプレッドシートが変えたのは入力先ではなく、その先

1979年にVisiCalcが登場。1983年にはLotus 1-2-3が続き、1980年代半ばまでにExcelがMacintoshで動作するようになった。これらのツールは、データが入力された後の処理を変えた。以前はバッチ実行が必要だった計算が、デスクトップ上で瞬時に行えるようになった。初めて、一人の人間がプログラミングスタッフなしでデータセットを構築、維持、分析できるようになったのだ。

しかし、スプレッドシートが変えなかったのは、データがシステムに入る方法だった。すべてのセルは、依然として人間が原稿を読みながら入力していた。ボトルネックはバッチ処理のターンアラウンドタイムから、人間のタイピング速度と正確性へと移行した。データ入力は民主化され、キーボードを持つ誰もがデータ入力オペレーターになったが、人間が文書を読んでセルに値を入力するという基本的な操作は、異なるハードウェアでキーパンチオペレーターが行っていたことと全く同じだった。

表計算ソフトの時代は、新たな障害ももたらした。一見正しいセルの中に潜む数式エラーだ。データ自体は正確に転記されていても、後続の処理で誤って使われる可能性があった。正確性の問題は、転記の正確性と数式の正確性の二つに分裂した。どちらも人間による確認が必要だったが、その確認作業は、多くの場合、データを入力した本人が行っていた。これは、キーパンチ時代の独立した検証工程に比べて、はるかに弱いチェックだった。

1990年代後半～2000年代：OCRの第一波

この時期、光学的文字認識（OCR）は成熟した。フラットベッドスキャナはオフィス機器となった。ABBYY FineReaderのような製品は、清刷りの印刷原稿であれば、スキャンした文書を高い精度で機械可読なテキストに変換できた。その可能性は本物だった。文書をスキャンできれば、再入力の工程を完全に省けるのだ。

OCRは定型化された帳票には有効だった。政府の統一テンプレートに印刷された税務書類、毎月同じ金融機関から届く銀行取引明細書、何年も様式が変わらない保険金請求書などだ。文字認識の精度は十分だったが、問題はレイアウト認識だった。固定された予測可能な構造を持たない文書の場合、OCRはテキストの羅列を出力するだけで、人間がそれを読み、該当する値を探し出し、対象システムに入力する作業が依然として必要だった。文字認識は入力を省いたが、理解を省いたわけではなかった。

ボトルネックは、キー入力速度から修正の手間に移った。非定型文書に対するOCRの出力は、空のセルよりも扱いにくいことが多かった。単に正確に入力する代わりに、既存のテキストの中から誤りを見つけて修正しなければならなくなったからだ。十分な量とレイアウトの一貫性がある文書タイプには、検証ルール付きのテンプレートベースOCRが有効だった。しかし、複数のソースが混在する場合には、修正するよりも再入力した方が速いケースが多かった。

2000年代～2010年代：デジタル文書と統合問題

ERPシステムが標準的な企業インフラとなり、サプライヤーが紙からの印刷ではなくソフトウェアからPDFを生成するようになると、デジタルからデジタルへの移行はシームレスであるべきという当然の期待が生まれました。元の文書はすでにファイルであり、対象システムもすでにデジタルでした。転記問題は解決されたはずでした。

転記問題に代わって統合問題が発生しました。ERPごとに独自のインポート形式があり、サプライヤーごとに独自のPDFテンプレートがありました。EDI（電子データ交換）は主要な取引先間の取引を標準化しましたが、それは専用の統合契約とそれを維持するITリソースを持つ組織間のペアに限られました。中小のサプライヤー、単発のベンダー、EDI標準外の文書タイプは、引き続き人手による処理が必要でした。

一方、PDFはデータ抽出ではなく印刷に最適化された形式であるため、デジタル文書でも解析作業が必要になることがよくありました。作業はタイピストから、統合を構築・維持するITチームへと移行し、統合コストに見合わないサプライヤーからの請求書、中小銀行からの明細書、非標準形式の文書といった構造化されていない残りの部分は、依然として手作業で処理されていました。

2010年代：ルールベースの自動化

RPAツールは、人間が行っていたこと（画面を見る、フィールドをクリックする、値を入力する）を自動化することでデータ入力問題に取り組みました。ボットは請求書を数分ではなく数秒で処理できます。高頻度で反復的、かつソース形式が安定しているワークフローでは、RPAは真の生産性向上をもたらしました。それは漸進的なものではなく、文書あたりの処理時間を桁違いに短縮するものでした。

脆弱性はコストだった。RPAボットはルールに従って動作する。文書の領域Xにある「請求書番号」というラベルのフィールドを見つけ、値を抽出し、システムのフィールドYに貼り付ける。送信元の文書レイアウトが変わると——新しい取引先、再設計されたPDFテンプレート、送信側の異なる会計システム——ルールは破綻し、ボットは停止する。障害監視とレイアウト変更時のルール更新は、継続的な運用負荷となった。

安定した高ボリュームのワークフローを少数持つ組織は、この保守コストを吸収できた——文書あたりの削減効果が、専任のボット保守機能を正当化した。多様で変動的な文書ソースを持つ組織は、それができなかった。ボトルネックは人間によるデータ入力から、ルール設計とボット保守に移った。データ入力オペレーターは、事実上ボット開発者になったのだ。

2020年代に実際に変わったこと

これまでの技術はすべて、既知のテンプレートや事前定義されたルールに対するパターンマッチングで動作していた。OCRは文字を見つけ、RPAはフィールド位置を照合し、EDIは既知のトランザクションコードをマッピングした。それらすべてに、ソースレイアウトを事前に予測することが必要だった——だからこそ、レイアウトが変わるとすべてが機能しなくなったのだ。

AI抽出は異なる動作をする。人間のように文書を意味的に読み取り、ラベルや位置に関係なくフィールドの意味を理解する。4つの取引先からの4つの文書にある「INVOICE NO.」「INV#」「Bill Reference」「Ref:」はすべて同じ意味であり——言語モデルは教えられなくてもこれを理解する。定義するカラム名（Invoice Number）は、特定の文字列や領域に一致させるキーワードではなく、概念を見つけるための指示である。

これにより、従来のアプローチを脆弱にしていたレイアウト依存性が解消されます。新しい仕入先の請求書に対して新たなルールを書く必要はなく、同じ列セットで処理するもう一つの文書にすぎません。最初の仕入先用に書いた列定義は、文書のフォーマットがどれほど異なっていても、50番目の仕入先でも機能します。

時代ごとのボトルネック

現在の作業内容

AI抽出はデータ入力作業をなくすのではなく、その内容を変えます。中心的な問いが「この文書からこの値をどう取得するか」から「すべての文書にわたって、一貫してどの値が必要か」に変わります。これは高速で正確なタイピングとは異なるスキルであり、スキーマ設計に近いものです。

• 列定義が文書読み取りを代替します。 必要な情報を一度指定するだけで — 請求書番号、取引先名、請求金額（数字のみ）、発行日（YYYY-MM-DD） — その定義が以降の全バッチの全文書に適用されます。読み取りとフィールド検出はモデルに委任されます。
• フォーマット要件は列名に含めます。 「金額（数字のみ、通貨記号なし）」は列名であり、同時にフォーマット指示でもあります。従来は後処理でのクレンジング工程が必要だった処理が、抽出時点で完了します。
• 検証が文字単位から行単位へ移行します。 各キー入力がソースと一致するかを確認する代わりに、抽出された各行が妥当かどうか — 金額に整合性があるか、日付が適切な範囲内か、取引先名が既知の仕入先と一致するか — を確認します。校正ではなく、異常検知です。
• ボリュームが制約ではなくなります。 50件の請求書でも、1件と同じ列設定で対応できます。従来は文書数に比例して増大していた作業が、異なる文書スキーマの数に応じてスケールするようになります — これは通常、文書数よりもはるかに少ない数です。

障害モードも異なります。AI抽出は、列名が曖昧な場合、文書が認識不能なほど劣化している場合、またはソース文書にフィールドが実際に存在しない場合に失敗します。これらは仕様の失敗 — 列定義の改良で解決可能 — であり、タイピング速度の失敗（より速いオペレーターか、より多くのオペレーターが必要）ではありません。

よくある質問