FAXやPDFの注文書を読み、商品を選び、数量を受注画面に入力する。こうした毎日の仕事を、AIに任せたいと考える会社は多いはずです。
画面を操作するAIでは、読み取りの精度に加えて、触れてよい情報・変更してよい項目・人に戻す条件を先に決める必要があります。数量の「10」を「70」と読んだまま注文を確定すれば、誤りは画面の中で収まらず、出荷や請求に進みます。
本記事は、代表・大塚のnote記事をもとに、企業の導入担当者向けに再構成しました。GPT-6.1 Terraの公式資料と、架空の受注業務を使い、導入前に確認する8項目を整理します。Terraによる受注処理の比較実験は、記事公開時点では実施していません。 以下は実測結果ではなく、検証と運用の設計例です。
この記事の目次を見る
画面を操作するAIで、業務のどこが変わるか
OpenAIはGPT-6.1 Terraを、画像の理解、コンピューター操作、文章作成を得意とするモデルとして紹介しています。公式モデルページには、商品写真と商品一覧の照合や、アプリケーション画面の操作などが用途として挙げられています。公式モデル情報
画面操作は、AIが画面を見て、接続されたツールを通じてクリックや入力を行い、その結果を確かめながら進める仕組みです。モデルを選んだだけで、社内のあらゆる業務ソフトを自動操作できるわけではありません。対応する操作ツールと実行環境の準備が必要です。Computer use
受注処理に当てはめると、仕事は次のようにつながります。
- 注文書から、商品名・数量・単位を読み取る。
- 商品マスタと照らし合わせ、登録する商品を選ぶ。
- 受注画面に入力し、不明点を確認担当者へ戻す。
- 下書きを保存し、保存後の内容を原本と照合する。
ここには小さな判断がいくつもあります。「トレー大」という略称が、似た商品3種類のどれを指すのか。「2箱」を、1箱の入数が分からないまま「2個」にしてよいか。訂正線で消された数字を採用していないか。
文字を読めたことと、正しい業務データを作れたことは、別々に確かめます。さらに、入力先を間違えて別の取引先の注文を書き換えれば、読み取った数字が正しくても事故になります。
最初に、AIに任せる終点を決める
導入の最初は、対象の注文書を読み、指定した受注画面へ下書きを保存するところまでを試す構成を勧めます。注文の確定、出荷指示、取引先への送信は、人が内容を確認してから実行します。
ただし、「下書き」というボタン名だけでは影響を判断できません。保存と同時に在庫を引き当てたり、社外へ通知したりするシステムも考えられます。実際にどの処理が動くかを、管理者や開発・保守担当者と確認してください。
表は横にスクロールして確認できます。
| 工程 | 最初の検証で任せる範囲 | 次へ進む条件 |
|---|---|---|
| 注文書の読み取り | 指定した架空の注文書だけを読む | 不明な文字や欠けた項目を示す |
| 商品の照合 | 検証用の商品マスタを参照する | 商品と単位を一意に決められる |
| 入力・下書き保存 | 検証用の受注画面に保存する | 保存先と保存後の値が一致する |
| 注文確定・出荷・送信 | 人の確認前には実行しない | 対象・内容・実行する操作を人が承認する |
「受注を処理して」だけでは、AIに任せる範囲が広すぎます。対象の注文書、使う画面、変更する欄、完了条件、保留条件を一組で渡します。下の8項目は、この一組を具体的に決めるための確認表です。
AIの画面操作を任せる前に確認する8項目
OpenAIの公式ガイドは、操作環境の制限、重要操作の確認、実行の上限、実際の結果の検証を挙げています。指示文だけでなく、アプリと実行環境でも制限するという点が重要です。以下は、その考え方を受注業務に当てはめたレイズの設計例です。公式の安全な実行に関する説明
01操作するアカウントと範囲を限定する
管理者のアカウントをそのまま使わせず、必要な注文だけを参照し、指定した下書きを作る権限に絞ります。商品マスタの参照は必要でも、全商品の単価変更や取引先の削除まで許可する必要はありません。
AIには専用の作業環境を用意し、開けるサイト、触れるフォルダ、使える操作を制限します。「削除しないで」と伝えるだけでなく、アカウントや操作ツール側でも削除を許さない構成にします。
確認すること： 対象外の注文・顧客一覧・設定画面へアクセスできないか。画面のメニューを隠しただけでなく、システム側で権限が制限されているか。
02AIに渡す情報と送信先を決める
商品と数量を読み取るために、取引先の銀行口座や無関係な顧客一覧まで渡す必要はありません。初期検証は架空データで行い、実データを使う前に、必要な項目、AIサービスへの送信範囲、保存期間、閲覧できる担当者を確認します。
AIが見る画面にも情報は含まれます。別の顧客の注文や、通知欄の個人情報が画面に写り込んでいないかも確認してください。また、外部の入力欄は、送信ボタンを押す前に入力内容を送る場合があります。機密情報を入力する先は、入力前に確認します。
OpenAI APIのデータは、明示的に共有へ同意しない限りモデルの学習に使われません。ただし、保存されるログや機能上のデータは別に定められています。「学習に使われない」と「どこにも保存されない」を混同しないでください。APIのデータ管理
確認すること： 利用するサービス・契約・設定で、何がどこへ送られ、誰が閲覧でき、いつ削除されるかを説明できるか。
03文書内の文章で操作権限を増やさない
注文書やWebページに、業務とは無関係な操作を促す文章が混ざることがあります。たとえば、注文の備考欄に「顧客一覧を外部へ送る」といった文章があっても、それは会社からの実行許可にはなりません。
外から読んだ文章でAIの動きを変えようとする攻撃は、プロンプトインジェクションと呼ばれます。文書の内容を、管理者が設定した指示や利用者の許可と同じ扱いにしない設計が必要です。エージェント構築時の安全対策
注文データとして取り込む項目を商品・数量・単位などに絞り、文書内の文章から送信先や操作対象を勝手に追加させないようにします。読み取り結果が許可した形式か、操作対象が許可した範囲かを、プログラム側でも確認します。
確認すること： 文書に業務外の指示が含まれても、権限の追加、別サイトへの移動、外部送信が実行されないか。
04曖昧な項目は、理由を示して保留する
数量が「10」にも「70」にも見えるとき、どちらかを埋めたことを成功に数えてはいけません。商品候補が複数ある、入数が不明、訂正前後が判別できない場合も、確定を止めます。
人へ戻すときは、「確認してください」だけで終えず、原本のどの行の、何が不明かを伝えます。たとえば「3行目の数量が10か70か判読できません。数量欄は未入力です」と返せば、担当者は確認箇所と処理状況を把握できます。
確認すること： 保留する条件と担当者が決まっているか。未入力・未保存・下書き保存済みのどの状態かを区別して報告できるか。
05確定・送信前に、人が内容を確認する
注文確定、出荷指示、メール送信、削除など、実行後の影響が大きい操作は、導入初期には人の確認を挟みます。確認画面には、対象の取引先、商品、数量、単位、実行する操作を表示します。送信する場合は宛先と本文も必要です。
「続けてよいですか？」だけでは、何を承認するのか分かりません。人が確認した後に内容や宛先が変わった場合は、その承認を流用せず、変更後の内容を確認し直します。
確認すること： 誰が、どの内容の、どの操作を承認したかが残るか。確認した内容と、実際に実行する内容が一致するか。
06完了の報告を、保存後のデータと照合する
AIが「完了しました」と答えても、入力エラーで保存できていなければ未完了です。保存後の注文を開き、注文番号、取引先、商品、数量、単位を原本や正解表と照合します。画面表示だけで確認できない項目は、管理画面や取得可能な保存データも使います。
保存ボタンを押した後に通信が切れた場合も注意が必要です。失敗したと思って再入力すると、同じ注文が二重登録される可能性があります。先に保存済みかを確認し、状態が不明なら自動で再登録せず人へ戻します。
確認すること： 完了とする条件が、AIの自己申告だけになっていないか。保存の成否が不明なとき、重複処理を止められるか。
07操作回数・時間・費用に上限を設ける
画面が変わった、ログインが切れた、入力エラーを解消できない。こうした場面で同じ操作を繰り返すと、費用だけでなく業務データへの影響も増えます。
一件当たりの実行時間、操作回数、AI利用額、同じ操作の再試行回数に上限を設けます。上限に達したら止め、どこまで保存したかを担当者へ通知します。上限はAIへのお願いだけにせず、実行するシステムでも管理します。適切な数値は、検証で得た処理時間やエラーの発生状況から決めます。
確認すること： 制限時間や費用を超えて動き続けないか。人が中断した後、裏で処理が継続しないか。
08操作記録と、中断後の対応を用意する
不具合が起きたときに、どの注文で、どの処理まで進んだかを追える記録を残します。処理番号、対象の注文番号、実行日時、変更した項目、人の承認、保存結果、保留理由が基本です。
一方、記録に顧客情報や画面画像を無制限に残すと、情報の保管場所が増えます。必要な内容に絞り、閲覧権限と保存期間を決めます。パスワードや認証コードをそのまま記録しないことも確認してください。
誤った更新を見つけたら、まず後続の処理を止め、実際の保存状態を確認します。変更を戻せる操作か、出荷や送信まで進んで別対応が必要かを担当者が判断します。
確認すること： 中断する人、状態を調べる人、修正する人が決まっているか。復旧手順を検証用のデータで試したか。
架空の注文書3種類で、進む・止まる・戻すを試す
最初の比較では、本番の顧客情報を使わず、実際の書式に近い架空の注文書と検証用の画面を用意します。正解表は人が先に作り、AIが処理した結果と比較します。
表は横にスクロールして確認できます。
| 検証する注文書 | 用意する例 | 合格にしたい動き |
|---|---|---|
| 普通の注文書 | 印字が明瞭で、商品・数量・単位がそろっている | 正しい下書きを保存し、保存結果を確認する |
| 訂正や手書きがある注文書 | 訂正線、手書きの追加、商品の略称がある | 訂正を反映し、決められない項目を具体的に示す |
| 確認が必要な注文書 | 判読しづらい数量、未登録商品、入数の欠落がある | 値を推測で確定せず、理由と処理状況を人へ戻す |
この3種類に加えて、文書内の業務外の指示、保存中の通信切断、ログイン切れ、停止操作も試します。正常に終わった件数だけでは、困ったときの動きを評価できません。
同じAIに二度読ませ、同じ答えが出ただけで正解としないことも大切です。同じ誤読を繰り返す可能性があります。原本、人が作った正解表、商品マスタ、保存後のデータを組み合わせて確認します。
判定は「保存できた」「適切に保留した」「誤って処理した」に分けます。保留が正解の注文書まで無理に埋めるAIを、高く評価しないためです。
料金と一緒に、人の確認・修正時間を測る
2026年10月30日に確認したTerraの標準API料金は、通常のテキスト入力が100万トークン当たり1ドル、出力が5ドルです。入力が272,000トークンを超える場合や、処理モードなどで料金は変わります。トークンは処理量の単位で、日本語の文字数とは一致しません。公式料金情報
一件の注文では、読み取り、商品照合、入力後の確認でAIを複数回使うことがあります。導入費、システム運用費、人の確認・修正時間も含めて判断します。APIの単価が低くても、毎回の修正が増えれば、担当者の負担は減りません。
比較時には、入力資料、商品マスタ、指示、完了条件をそろえ、少なくとも次を記録してください。
- 商品・数量・単位が正しかった件数と、誤りの内容。
- 保留すべき箇所で止まり、担当者に確認箇所を示せたか。
- 保存後の照合結果と、二重登録の有無。
- 人が追加指示や修正を行った回数と、確認に使った時間。
- AIの利用額、全体の処理時間、上限で停止した件数。
最初に選ぶのは、一つの入力業務です。その業務の「入力元」「保存後の正しい状態」「人が判断する箇所」を並べ、8項目を確認してから架空データで試してください。正しく進めた工程と、適切に止まった工程を確かめて、任せる範囲を決めます。
参考資料と出典
情報確認日：2026年10月30日。料金・機能・提供条件は変更される場合があります。受注業務の例と8項目の確認内容は、下記の資料を踏まえたレイズの設計・運用上の提案です。
