AI成果物の受入を三段階に分ける——JSON形式の検査・SHA-256照合・別担当レビュー

八個という答えを、何と比べるか

総務担当がAIへ備品の月次集計を頼み、「在庫は八個です」という報告を受け取ったとします。文章は自然で、指定した欄も埋まっています。それでも担当者は、翌週の発注をこの数字で決めてよいか迷います。八個という値が出たことは確認できても、入出庫記録をどう読んで得た数字かは分からないからです。AIが完成を宣言しただけで、発注に使える報告になったとは言えません。

備品集計を受け入れる手順として、提出された成果を機械的に調べ、その後に作業者と別の担当が条件ごとに確認する構成を考えます。対象の種類に応じて、必要な文字があるか、値の種類が一致するか、提出内容が変わっていないかを検査します。この基盤で確認できるのは受入の仕組みであり、在庫の集計や発注判断が正しく働くかは、業務資料を使った検査で確かめます。

受入を考えるときには、報告を作る能力と、報告を使えると決める根拠を分けます。機械は形式上の不備を速く見つけられますが、数字が業務に合うかには資料の読み方が関わります。今回の例では、最初に完成の条件を決め、八個が誤りと分かる場面まで進めます。そのうえで、訂正された報告を誰がどこまで確認すれば納品できるかを追います。

発注に使うなら、完成条件を先に狭める

依頼を「備品の状況をまとめて」だけにすると、総在庫、使用可能数、発注が必要な数のどれを答えるかが担当によって変わります。例では会議のための概要ではなく、翌週の発注判断に使う報告にします。対象は一種類の備品、締め時点は月末、入力は承認済みの入出庫記録、成果には月末数と未処理の返却分を分けて記載する、と先に定めます。目的から条件を選ぶと、検査すべき範囲も決まります。

さらに、納品する報告と集計結果の両方が必要なら、その二つを提出物として指定します。報告だけを受け取って集計結果がないと、あとから数字の確認に戻れません。逆に、依頼と無関係な資料が多数添付されていても完成には近づきません。実装では提出された成果の組が予定した組と一致するかを調べます。不足と余分な提出のどちらも、対象が曖昧なまま確認へ流れるのを防ぐための検査になります。

既存の報告を使い回してよいかも決める必要があります。新しい月の集計を求めたのに前月の文章をそのまま提出されたら、形式が整っていても依頼を満たしません。実装には内容が変わっていない成果の受入を原則拒否し、再利用を意図的に許した場合だけ別扱いにする設計があります。毎回変更させればよいのではなく、更新する仕事か、既存物を確認する仕事かを依頼時に区別することが要点です。

形式の検査を通っても、数字はまだ決まらない

最初の検査では、成果を読み取れること、求めた項目があること、計算結果が期待した種類の値になっていることを調べます。備品数を数値として使う契約なら、見た目が同じでも文字列の「八」と数量の八は同じ扱いにできません。後の処理が数を足したり発注基準と比較したりするからです。表示には支障がなくても、入力としては不適切な値があります。

文章の場合も、報告に必須の説明があるかは機械で調べられます。しかし「未処理の返却分」という語を含めるだけで、実際にその分を分けて計算したことにはなりません。用語の存在と計算の意味を分けて、前者を自動で確認し、後者を原資料に戻って判断します。全てを人が最初から読む方法に比べると、読み取れない成果や明らかな欠落を先に返せる利点があります。

この分業は、人の確認を不要にするためではありません。確認担当が業務上の判断に集中できるよう、形の問題を先に取り除くためです。例なら必要な二つの成果が揃い、数量欄が計算に使える形であることを確かめてから、八個という値の根拠を追います。どの検査を通ったかが表示されれば、担当者は未確認の内容を想像で合格扱いする必要がなくなります。

このジョブ基盤では、JSONの値を比較する際に型の一致も求めます。数量の1と文字列の「1」は別の値として扱います。成果物のSHA-256は内容から計算する照合値で、提出時と検査時の版を結び付けます。JSONの型検査は後続処理が使える形式かを、SHA-256は同じ現物かを確かめ、在庫として正しい数かは別担当の読解へ残します。

原資料を読むと、八個が六個へ変わる

入出庫記録の条件を、月初が十個、当月の受入が三個、払出が七個で、月末の使用可能数は六個とします。別の欄には二個の返却予定があり、受入確認はまだ済んでいないとします。AIがこの予定分まで加えれば、報告は八個になります。計算式としては整っていても、「承認済みの記録だけを月末数へ入れる」という依頼には合いません。誤りを確かめる材料は、流暢な説明ではなく返却欄の状態です。

確認担当は、報告の月末数と入出庫の数を照合し、返却予定が確定扱いになっている箇所を指摘します。差し戻す理由を「数字が違う」だけにせず、「二個は受入確認前なので使用可能数に加えず、予定として別記する」と残せば、作業担当は直す対象を特定できます。訂正後の期待値は月末六個、返却予定二個という組です。六個だけへ書き換えて予定を消すと、別の必要情報が失われます。

比較用に、返却が月末までに承認済みだった条件も考えます。その場合は八個が妥当になる可能性があります。同じ数だから誤り、前の確認で六個だったから正解、とは判断できません。締め時点と記録の状態が変われば、正しい答えも変わります。検査に固定の答えを用いるなら、どの入力条件に対応する値なのかを明示しておく必要があります。業務の意味を伴わない正解表は、正常な訂正まで拒否しかねません。

別担当には、全条件への判断を求める

訂正した報告は作業担当の自己確認だけで受け入れず、別担当へ渡します。実装では全ての受入条件への回答と、空でない説明が必要です。例の条件が月末数の照合、返却予定の区別、発注に使う締め時点の明示なら、それぞれについて確認した結果を残します。「全体として問題なし」だけでは、返却予定を見たのかどうかが後から分かりません。

作業者と確認者を分ける意味は、作る際の思い込みを違う視点で検出することです。今回なら作業者が返却予定を在庫と考えていたとき、確認者は原資料の承認欄に注目します。ただし実装上の担当名が異なるだけで、本人や組織としての独立性が自動的に証明されるわけではありません。別の人が資料を読んだのか、同じ人が別の名前を使ったのかは、運用側で確かめる必要があります。

条件を増やせば必ず良くなるとも限りません。発注判断に関係のない装飾の好みを大量に加えると、数字と原資料の照合が埋もれます。合格条件を作る際には、使う人が困る失敗から逆算します。備品不足を避けたいなら使用可能数の意味、月末締めを守りたいなら日付、引継ぎをしたいなら未処理分の説明が重要です。読みやすさの確認も必要ですが、数字の根拠の代わりにはなりません。

例えば発注基準が使用可能数七個未満なら、六個と八個の差は発注の有無を変えます。誤差が小さいから許容する、という判断では済みません。一方、一覧を作るだけで発注を決めない資料なら、用途に応じて確認の優先順位は変わります。数字の検査をどこまで厳密にするかは、値の桁数だけでなく、その値が次の操作をどう変えるかから決めるべきです。七個という基準はこの場面の仮定です。実際の基準は、納入までの時間や必要量を確認して業務側で定めます。

確認した版を、最後まで対象にする

確認担当が六個の報告を読んで合格にした後、作業担当が別の修正を加える場合があります。たとえ見出しだけの変更のつもりでも、本文が変われば確認対象は変化します。実装では提出した現物から照合値を計算し、検査側でも読み直して一致を確かめます。その値は内容が同じことの印であり、数値が正しいことの証明ではありません。品質の判断と版の固定を、この一度の説明で結び付けます。

最終段階の再検査で変化が見つかったら、古い合格を新しい報告へ使いません。内容を修正した場合は、その現物を改めて確認へ戻します。例では月末数を六個へ訂正した報告が対象です。確認中に入力資料も更新されたなら、どの締め時点を採用するかを再び決め、更新前の資料への確認が更新後へ適用できるかを検討します。急いで納品する事情は、版の対応を曖昧にする理由にはなりません。

提出場所についても、予定した範囲から外れる成果を受け取らない設計があります。関係のない場所を指定したり、許された置き場の外へ移動する指定を含めたりした成果は拒否します。これは内容を採点する検査ではなく、確認する対象と扱う範囲を限定する検査です。報告の中身が正しくても、管理対象外の資料を勝手に納品へ混ぜることは別の問題になります。

検査の実績は、保証の範囲と一緒に読む

関連する試験は成功しています。本文の存在、提出物の組、値の種類、使い回し、確認待ちでの内容変更などを扱う試験です。この件数は過去の検証結果で、現行環境での再実行結果ではありません。この記事の内容は、業務報告の正しさや発注ミスの減少を示すものではありません。

試験の数を見る際は、何を変えたときに何を拒否するかを読む方が役立ちます。前月と同じ文章を提出する条件では、再利用を許していない新規作業として拒否するかを見ます。必要な集計結果を抜く条件では、報告だけで確認へ進まないかを見ます。数量を文字として返す条件では、計算用の数値と取り違えないかを見ます。それぞれ失敗の種類が違うので、一つの異常な成果で代用しません。

業務上の意味を試すには、先ほどの未承認の返却予定を含む入力が有効です。形式の検査は通っても、確認担当が予定分の加算を指摘できるかを見ます。また、返却が承認済みの正常例を並べ、正しい八個を誤って差し戻さないかも確かめます。拒否する力だけを評価すると、全てを止める仕組みでも良く見えてしまいます。必要な仕事を受け入れる条件も対で試すべきです。

一つの納品から、受入条件を育てる

導入時には、全ての成果物へ共通の大きな確認表を押し付けるより、一つの報告の使い道を決めるところから始めます。備品例なら、発注担当が必要とする数量と、予定分をどう扱うかを書き出します。そこで機械が確認できる条件と、原資料を読まなければ分からない条件に分けます。まずこの分け方が、実際の確認担当の手順と一致しているかを確かめると、形だけの検査を増やさずに済みます。

試作では正常な報告と、予定分を混ぜた報告を同じ確認者へ渡し、どの資料を見て判断したかを聞きます。判断が割れたなら、確認者の能力だけでなく依頼の定義を見直します。「在庫」が使用可能数なのか、倉庫にある総数なのかが曖昧なら、双方に合理的な読み方があります。受入条件の不足を発見した時点で定義を補い、修正後の条件で双方の例をもう一度確認します。

最後に、合格した現物、読んだ資料、残った未確認事項を納品先へ伝えます。報告が発注量まで提案していても、発注基準を依頼に含めていなければ、その提案まで受入済みとは言えません。使い始める範囲を条件に合わせて決めることが、完成宣言を業務上の納品へ変える最後の判断です。あなたの業務でも、「できました」に続けて何を確かめれば使えるのかを、一つの成果について具体的に書いてみてください。