ばらばらな受注を整った注文記録へ：AI 入力ツールの設計

業務で注文を扱うと、入力形式がまったく揃っていない場面に必ず出会う。ある人は「A 製品を 200 個、単価 8、金曜日まで」と短いメッセージを送り、別の人は表計算ファイルを渡す。見積書を撮影した画像や、スキャンした PDF が届くこともある。社内では、それらを誰かが一件ずつ業務システムへ転記しなければならず、時間もかかれば誤入力も起こる。

この記録では、そうした任意形式の注文を AI に読ませ、整った注文記録へ変換し、チームの共有オンライン表へ書き込む自動入力ツールを扱う。実装そのものより難しかったのは、日常業務で使えるだけの信頼性をどう作るかだった。その過程で決めた規則と、失敗から残った判断をまとめる。

具体的な会社名、顧客名、製品名などはすべて除いている。「ある企業」「ある製品」という一般的な表現だけを用い、雑然とした入力を整理されたデータへ変える方法として記述する。技術用語は、初めて登場する箇所で平易に説明する。

全体像：データはどう流れるか

まず、構造化データとは、顧客、製品、数量などが決まった項目に分かれ、一件ずつ整った記録になっているデータを指す。検索や集計がしやすい。一方、自由に書かれたメッセージは非構造化データである。このツールの役割は、非構造化の注文を構造化された記録へ変えることにある。

もう一つの用語がマルチモーダル大規模モデルである。「マルチモーダル」とは、文章だけでなく画像も読めるという意味だ。撮影された見積書やスキャン文書も、単なる添付ではなく解析対象になる。

処理全体は次のように流れる。

1. 任意形式の注文を受け取る（文章、表計算、文書、画像、スキャン PDF）。
2. マルチモーダル解析で注文項目を抽出し、各項目を確実／不確実に分ける。
3. 換算・正規化で、kg とキログラムのような単位表現を統一する。
4. 表へ記録し、確実な値とともに原文・原ファイルを保存する。
5. 保存・通知を行い、不確実な項目は要確認として人へ知らせる。

最終的な注文はオンライン多次元表に置く。これは小さなデータベース、かんばん、集計画面を兼ねられるクラウド表で、複数人が同時に閲覧・分類・集計できる。AI が担当するのは入力だけであり、閲覧と共同作業は表そのものに任せる。

基本原則：推測より空欄を選ぶ

機能を作る前に、最優先の規則を一つ定めた。推測した値を埋めるより、空欄を残す方が安全である。 モデルが確信を持てない項目は空欄にし、人が補う対象として印を付ける。数量や単価の空欄は目に入り、後から直せるが、誤った値は気付かれないまま流れる可能性がある。

この原則から、五つの設計規則を導いた。

モデルには確信度付きの JSON だけを返させる

ここがツールの中核である。モデルに説明文を書かせず、厳密な JSON だけを返すよう求める。JSON は、名前の付いたキーと値で構成され、プログラムが読みやすいテキスト形式である。さらに、各項目に値だけでなく確信度フラグ（confident: true / false）を持たせ、モデル自身に「この抽出は確実か」を判断させる。

指示はおおむね次のようになる。

あなたは注文情報の抽出担当です。余分な文章を付けず、JSON だけを返してください。
各項目は value（値）と confident（確実か）を持ちます。
{
  "顧客名":   {"value": "", "confident": true/false},
  "製品":     {"value": "", "confident": true/false},
  "数量":     {"value": null, "confident": true/false},
  "単位":     {"value": "", "confident": true/false},
  "単価":     {"value": null, "confident": true/false},
  "原文抜粋": "確認用に保存する原文"
}
規則：
- 見つからない項目は value を空にし、confident を false にする。
- 曖昧または複数の解釈がある場合、confident は必ず false にする。
- 同じ意味の単位は、決められた表記へ正規化する。

出力を安定させるため、次の小さな工夫を重ねた。

• 一つか二つの例を示す。 これは few-shot、つまり「少数の見本を与える」方法である。入力と期待する出力を一組示すと、形式が安定する。
• temperature を 0 にする。 temperature は出力のランダム性を調整する値である。データ入力に必要なのは創造性ではなく再現性だ。
• 保存前に正規化する。 単位や名称の表記を指示内で決め、登録後の清掃にすべてを先送りしない。
• 許容的に解析する。 モデルが JSON を Markdown のコード枠で囲んだり、前後に一文付けたりする場合がある。最初の { から最後の } までを取り出す予備処理を置き、外側の装飾だけで注文全体を失敗にしない。

自動登録と人の確認を分けるゲート

各項目に確信度があれば、確信度ゲートで処理を分けられる。

• すべての重要項目が確実なら、自動的に記録し、主要な値をまとめた控えめな完了表示だけを出す。担当者は一目確認し、作業を中断されない。
• 重要項目が一つでも不確実なら、確認カードを表示する。不確実な項目を強調して入力欄を置き、確実な値も編集可能な文脈として見せる。人が確認するまで表には書き込まない。

重要項目は、顧客、製品、数量、単位、単価に限定した。連絡先や備考などの補助項目が不確実でも、必ずしも処理を止める必要はない。後から補える。小さな欠落のすべてが割り込みを起こせば、自動化は注意を節約できない。

非技術者のために、あえて単純な画面にする

基盤のエンジンは無人でバッチ処理できるが、毎日使うのはコードを知らない入力担当者である。そこでエンジンの上に、チャットに似たウェブ画面を置いた。文章を入力するかファイルをドラッグすると、その場で解析する。確実なら記録し、不確実なときだけ補足を求める。

機能数より、境界の決め方が重要だった。

• 担当者にコマンドラインを触らせない。 デスクトップのショートカットをダブルクリックすると、サービスが起動し、入力ページがブラウザで開く。利用者の操作は、起動、入力、ファイル追加だけになる。
• 再利用し、書き直さない。 画面は、すでに動作確認した解析・換算・保存関数を直接呼ぶ。画面用に同じ処理を書き直せば、二つの実装はいずれ食い違う。
• 危険な能力を意図的に持たせない。 一人が一台で使う環境に複雑なログインや自由会話は不要であり、コード変更、ファイル削除、コマンド実行の権限も与えない。狭い道具ほど、誤操作で壊れにくい。

形式ごとに分岐し、最後に一件へまとめる

「どんな形式でも読む」という課題は、二つの経路に分ければ扱いやすい。

• 文字を抽出できる形式（テキスト、表計算、文書、文字レイヤーを持つ PDF）は、先に文字へ変換し、より速く低コストなテキストモデルへ渡す。
• 文字を抽出できない形式（画像、スキャン PDF）は画像へ変換し、マルチモーダルモデルに見せる。PDF から文字が一つも取れなければ、多くの場合はスキャン文書なので視覚経路へ回す。

一件の注文が、説明メッセージと複数の添付に分かれて届くことも多い。その場合は、資料全体を一件の注文として統合し、二つの規則を置く。

1. メッセージと添付が矛盾する場合、文章の指示を優先し、ファイルは補助資料として扱う。
2. 一回に処理する画像数へ上限を設ける。上限を超えた場合は、対応範囲だけを処理して人の確認を必須にし、巨大な要求が失敗したり内容を黙って落としたりしないようにする。

モデルと人の仕事を分ける

ツール全体は、一つの分業として整理できる。

• モデルは反復作業を担う。 異なる形式を読み、雑然とした文章や画像から項目を抜き、単位を揃え、まとまった件数を処理する。
• 人は判断を担う。 不確実な項目を補い、最終記録を確認し、規則と確信度の閾値を決める。

これは完全自動化でも、手作業に AI を添えただけの仕組みでもない。反復を機械へ渡し、判断を人に残すという分担である。モデルが読み、人が決める。

変更、追跡、重複防止

実際の注文は変更されるため、履歴を守りながら重複も防がなければならない。

• 既存注文を変更する： 顧客と製品などの一般的な組で候補を出し、人が一件を選ぶ。確認カードに「旧値 → 新値」を示し、言及された項目だけを変更し、その変更を履歴へ追記する。
• 原資料を永続的に残す： 自動登録された注文にも、元の文章と添付を保存する。どの値も抽出元まで戻って確認できる。
• 冪等にする： 冪等とは、同じ操作を何度行っても最終結果が変わらない性質を指す。ファイル名と内容の指紋を組み合わせ、同じ資料から二件の記録が作られないようにする。

配備時に残った失敗記録

開発機で動く道具を、実際に使う端末へ移す段階が最も難しいことは多い。次の失敗は、同種の道具にもそのまま当てはまる。

問題	症状	対応
モデルの接続先を切り替えていない	配備後に解析エラーが出る、または画像の読解が変わる	開発環境と配備環境ではモデルサービスのアドレス（base_url）が異なる場合がある。対象の接続先へ切り替え、実際のマルチモーダルモデルで画像を再検証する。
オンライン表の「AI 自動抽出」列	スクリプトが書いた数量や単価が、数秒後に消えるか変わる	自動抽出列が原文を再読して値を上書きする場合がある。重要項目には通常のテキスト列を使い、計算額には読み取り専用の数式列を使う。
記録と添付を分けて書く	先に記録を作り、後から添付すると上の上書きが発生する	項目と添付を一回の書き込みで送信し、「作成してから補う」手順を避ける。
起動スクリプトの文字化け	ダブルクリックで起動すると、命令が分断されて失敗する	地域設定が Unicode に安全でない端末では、.bat や .vbs の内容を英数字に限定する。日本語画面は UTF-8 のウェブページ側へ置く。
クラウド同期中のファイルを読む	途中までしかないファイルを解析し、不完全な結果を作る	同期中はファイル名だけ先に見える場合がある。同期完了を確認するか、重要資料は信頼できるローカル場所から読む。

最後の問題は特に見落としやすい。クラウド上で同期途中のファイルは、フォルダには存在していても内容が揃っていないことがある。 クラウドとローカル、または複数端末の間でプロジェクトを移すときに、静かに現れる失敗である。

結論

最も大きな学びは、AI に雑然とした入力を読ませること自体より、実務で使えるほど信頼できる結果にすることの方が難しいという点だった。その信頼性は、より大きなモデルではなく、保守的な規則から生まれた。

不確実なら空欄にする。原資料を残す。確信度で確認へ回す。最終判断を人に残す。

モデルは今後も変わるが、この契約は安定した層として残せる。道具の価値は「完全自動」という言葉ではない。反復を機械へ、判断を人へ渡し、それぞれが得意な仕事を担当することにある。