AI社員の受注下書きに数量欄がない？営業事務が拒否・未完了を見分ける確認票

営業事務が見る一覧に「処理完了」と出ているのに、品番や数量が表示されない。この記事の架空原注文M40-L1は「商品P40を2箱希望。納期はまだ相談中。」です。2箱と書かれた原文を残したまま、AIから受け取った応答のどこを確認すればよいかを考えます。数量欄がないという理由だけで、注文が0箱になったとは判断できません。

OpenAIのResponsesは、API（システム間で情報をやり取りする窓口）から応答を受けるための形式です。statusは応答全体の状態を示す欄です。completedは応答処理の完了、refusalはAIが依頼に対応しないと返した本文の種類、incompleteは応答が完了していない状態を表します。公式の拒否例には、全体はcompletedで、本文はrefusalという組合せがあります。受注の受付完了や承認完了を表す値ではありません。

教材R40-01にはcompletedとrefusalを同時に入れました。拒否文は著者が作ったもので、実モデルがこの原注文を拒否した記録ではありません。営業事務は原注文の版と応答IDを開発担当へ渡し、「全体の状態」「本文の種類」「受注欄があるか」を別々に記録します。画面に完了の文字しか出ていない場合は、応答全体の記録を確認してもらいます。

営業事務が知りたいのは、処理の終了ではなく、今回の原注文を受注の下書きとして扱えるかです。completedは応答処理の状態で、原注文の2箱を受け付けたという証拠ではありません。refusalは依頼に対応しない本文の種類です。原注文の希望数量と応答に存在する欄を分けて読むことで、数量がない拒否を0箱の受注へ変えてしまう処理を止められます。

比較表は横に動かして全ての列を確認できます。

この章の根拠：出典1出典2

R40-01の本文は「この依頼には対応できません（架空教材）。」だけで、quantity（数量）という受注欄を持ちません。元の2箱は原注文に残っています。ここで数量欄へ0を入れると、原文にも拒否文にもない値を追加します。拒否を「注文なし」「取消」「在庫なし」と扱うことも、この応答からは決められません。

確認票の数量は「応答に受注欄なし」と書き、原注文の希望数量2箱を別欄に残します。業務責任者は、原依頼と拒否の記録を読んで、AIを通さない通常の受付手順で人が原文を確認できるかを決めます。拒否理由の詳細が分からなければ未確認と残し、資料が不足しただけだと推測して埋めません。

教材ではrefusalを読んだ時点で注文本文の解析を止めます。拒否文へ受注の欄を付け足す処理や、拒否を避けるための自動反復依頼は含めません。原文自体を正式に扱えるかは会社の責任者が別に判断します。原注文から人が下書きを作る場合も、R40-01のAI出力から採用した値だと記録しないことが必要です。

この章の根拠：出典1出典3

R40-02の全体はincomplete、理由はmax_output_tokensです。これは出力の上限に達したことを示す、公式にある未完了理由の例です。教材の本文は {"product_code":"P40","quantity": までで終わります。JSONは項目名と値で情報を表す形式です。この断片には数量の値も閉じる記号もなく、完成した受注本文としては読めません。

原注文に2箱と書かれていても、AIの途中の断片へ2を補って「応答が完成した」と記録しません。開発担当へ応答ID、状態、理由、最後までの断片を渡します。営業事務が急ぐ場合は、責任者の決めた別手順で原注文から人の下書きを作り、AIの未完了記録と区別して残します。

理由がmax_output_tokens以外だったり、理由欄が読めなかったりする場合も、未完了は未完了として扱います。この記事は上限設定の変更や自動再試行を実装する手順ではありません。原因の確認、再依頼してよい範囲、正式な受付の扱いを担当へ渡すために、元の応答を保持します。ローカル教材のプログラムは、incompleteなら注文のJSONを解析する前に止まります。

この章の根拠：出典1出典2

公式の説明ではoutput配列に、本文以外の要素が入る場合があります。配列は複数の項目を並べる入れ物です。messageはAIが返すメッセージ、contentはその中の本文の並びです。先頭の項目を必ず本文とみなさず、typeがmessageである対象と、その中のrefusalまたはoutput_textという種類を読みます。R40-05は先頭にreasoning、次にmessageを置き、種類で本文を選ぶ教材です。reasoningの内容を受注欄に転記しません。

この教材はassistantのmessage1件、content1件だけを扱います。複数候補、道具の呼出し、未知の種類はR40-06と同じ契約外の保留へ渡します。これは全てのResponsesが1件しか返らないという仕様ではありません。開発担当が自社で使う応答の範囲を決め、その範囲を超えた元の記録を確認できることが要点です。SDK（開発用の便利な道具）のoutput_textだけを読んでも、状態や拒否、受注の正しさを確認したことにはなりません。

本文がoutput_textとして選べた後に、欄と値を確かめます。故意破損例R40-03はquantityが文字列の"2"で、教材が受ける数値2と違うため項目・型を保留します。Structured Outputsは決めた欄と型に合う出力を得る仕組みです。正常なstrict設定のStructured Outputsがこの型違いを返すという主張ではありません。R40-04は必要な4欄と型が合いますが、品番P41が原注文のP40と違うため営業事務へ戻します。形式をそろえる仕組みと、原文に合う事実かの照合は別の確認です。

比較表は横に動かして全ての列を確認できます。

この章の根拠：出典1出典2

配布ZIPには原注文1行、6つの合成応答、期待表、Python（計算や処理を書くプログラム言語）とJavaScript（ブラウザでも動く処理を書く言語）の分岐コードを入れています。lesson.htmlはページの構造を記すHTMLで作った、ネットへ送信しない教材画面です。R40-01から06のボタンで、元応答、保留理由、引受担当と解析した注文の有無を見比べられます。現在の配布先では、ローカルChromiumで320・390・768・1280pxの各幅から6つのボタンを選ぶ24操作を作者が確認しました。表と元応答は横へ動かせ、数量の2箱と項目名を途中で分断せず読めます。実機・他のブラウザ・読者理解・本番連携は未確認です。

著者はPython3.9・3.12で各75項目を実行し、6例の期待結果との差はありませんでした。拒否と未完了で注文を解析せず、全例で数量を推測しません。R40-05だけが人の下書き確認候補へ進みます。Node.js（JavaScriptをブラウザ外で実行する環境）でも同じ6例の結果が一致しました。元の4値と一致しても、会社へ登録・送信・承認する処理はありません。AIの精度や拒否率の測定ではなく、著者が決めた6入力へのローカル処理の確認です。元のPython/Nodeの実行記録は、その記録の版と固定6例に対する過去の作者確認として保持します。現在のlesson.htmlの表示・選択24操作は、上に記した今回の作者確認です。本文との同版結合、独立確認、本番表示・公開後確認は別に記録します。元の75項目やZIPモデルを再実行したという新しい合格へ換算しません。

自社へ使う前は、開発担当が実際の応答種類、複数messageや途中受信、エラーを含む範囲を別に確かめます。Python教材には重複したJSONキーを拒否する追加確認がありますが、ブラウザ版は固定6例を読む比較用です。任意のAPI応答をそのまま本番へ投入する処理ではありません。入力が壊れた追加例を確認しても、実LLMがその入力を返したとは記録しないでください。

比較表は横に動かして全ての列を確認できます。

この章の根拠：出典1出典2出典3

数量欄がないときは、completedという文字だけから受注を作りません。refusalなら原依頼と拒否を業務責任者へ、incompleteなら状態・理由・断片を開発担当へ渡します。本文が選べた場合も、欄の形式と原注文の値を別々に確認し、どこまで進めたかを残します。

R40-01の7欄票には、M40-L1のP40・2箱、completed/refusal、応答に数量欄がないことを記入できます。原文の希望を保持し、拒否から0箱を作らないという作業が見えます。R40-05を確認する票なら、4値一致と営業事務の下書き確認候補を記入し、正式受注・納期確約・会社受領は未確認と残してください。nullは形式上「値なし」を示しますが、納期未定という業務の意味は原文の「まだ相談中」と照合します。

この確認票は、AIの方式を選び直す比較表や、全てのAPIエラーを直す手順ではありません。自社の1件について元応答を残し、数量欄の処理を始めてよいか分からない段階と、原注文を確認する担当を明示する持ち帰り物です。会社の受付手順へ組み込む前に、扱える応答の範囲と保留の引受先を決めます。

この章の根拠：出典1出典2出典3