AI入力補完を根拠付きデータへ限定する——台帳の値・欠損・人の確認を分ける設計案

空欄を消したのに、確認が増える

営業担当が新商品の案内文を作る場面を考えます。商品名と価格は決まっていますが、販売開始日とおすすめ理由が空欄です。AIに「不足を補って」と頼むと、もっともらしい発売日や魅力的な理由まで整えて返すかもしれません。しかし日付が誤っていれば訂正が必要になり、担当者が言っていない感想を書けば説明の責任が残ります。文章が完成したように見えるため、空欄のままより問題を見つけにくいこともあります。入力補助の目標は、何でも埋まった文章を作ることではなく、確認できる情報を確定し、確認できない部分を見える形で返すことです。

未確定情報は、指定された根拠から取得できる値と、本人の経験や判断が必要な値に分けて扱う方法があります。商品案内の入力補助を例に、この二つで取得方法と確認先を変える設計を考えます。商品台帳にある名称を転記することと、担当者のおすすめ理由を代筆することは、同じ補完でも必要な根拠が違います。後者を自然な言葉で書ける能力は、本人がそう感じた証拠にはなりません。この差を入口で決めれば、担当者は全てを疑って読み直すのではなく、自分にしか確定できない項目から確認を始められます。

例の依頼が「来月から売る予定」だけなら、来月の初日を販売開始日にしてはいけません。日付が未確定なのか、入力者が省略したのかを確認します。質問の答えを待つ間に商品説明の構成を準備することはできますが、予定日を確定した案内の完成とは分けます。進められる部分を残しながら、未確定の値が外部へ出る経路を止める設計です。

項目ごとに取得先を決める

まず商品名、価格、販売期間、おすすめ理由を一覧にします。商品名と通常価格は商品台帳、販売期間は承認済みの販売計画、おすすめ理由は担当者の回答を根拠にする、と決めます。「社内資料を見る」だけでは曖昧です。同名の商品が二つあれば、商品番号、地域、販売形態などで対象を選べる必要があります。価格には税込か税別か、通貨、単位も付けます。千円単位の数字を円として転記すれば、値を正確に取得しても案内文は誤ります。取得先、対象を選ぶ条件、単位を一組にして設計します。

入力として「東日本向けの家庭用商品、商品番号は確認済み」を受け取ったなら、出力は名称と価格だけでなく、どの台帳のどの対象から読んだかを示します。確認者用の画面では、値の横に根拠を開く入口を置く案が有用です。ただし取得元に含まれる秘密情報まで公開文面へ出す必要はありません。社内の確認記録と、顧客に見せる案内を分けます。取得する権限があること、社内業務で使えること、外部に掲載できることは別の条件です。入力補助に公開権限まで含めておくと、最後に一括して隠す手戻りを避けやすくなります。

取得先を変更する際は、同じ商品の新旧の値を並べ、項目の意味が維持されるかを確認します。旧台帳の価格が一個当たり、新台帳の価格が一箱当たりなら、欄の名前が同じでも互換ではありません。変更の担当と確認方法を記録し、以前に作った案内を無条件で新しい値へ置き換えないようにします。

未登録とゼロを同じにしない

価格欄が空のとき、無料商品なのか、価格が未登録なのか、通信失敗で読めなかったのかを分けます。無料ならゼロという確定値を返せます。未登録なら価格設定の確認が必要です。通信失敗なら取得の再試行が候補になります。この三つを全て空白にすると、案内文を作る担当が事情を推測してしまいます。画面には「取得済み」「台帳に登録なし」「取得できず」「担当者の確認待ち」と、次に必要な行動が分かる日本語を表示します。値の有無だけで後続の処理を進めないことが大切です。

似た商品の価格が台帳にあっても、今回の商品へ代用するとは限りません。類似検索は根拠を探す助けになりますが、確定した値を取得する仕事とは分けます。候補を提示する場合は「参考候補」と明示し、正式な価格欄へ自動転記しない設計にします。欠損を機械的に埋めると処理件数は増えますが、誤った値も成功として数えることになります。取得件数に加え、対象を正しく選べた件数、確認待ちに返した理由、根拠を開けるかを見ます。空欄の数だけを評価すると、必要な停止まで失敗に見えてしまいます。

入力者が空白を削除しても、未登録という状態まで消さないようにします。特に数値欄では、空白をゼロに変える計算処理が後段にあることがあります。計算前の検査で未確定を除外し、集計に含めなかった項目を一覧に返すと、欠損が結果へ隠れて入り込むのを防ぎやすくなります。

技術的には、取得した値だけを返す接続より、値、取得元、対象、単位、取得状態を一組の構造化データとして返す契約を提案します。JSONなどで項目を固定すれば、後段は未登録や通信失敗を価格ゼロへ変換せずに分岐できます。台帳との連携を実装するなら、各項目を返せることに加え、値がないときにも取得状態が失われないかを検査します。

人に聞く項目を具体的な質問に変える

おすすめ理由の確認を「不足情報を入力してください」と返すだけでは、担当者は何を書けばよいか迷います。「実際に使って便利だった点はありますか。まだ使っていなければ未使用と答えてください」と聞けば、経験の有無も確定できます。回答が未使用なら、使用感を作らず、確認できる仕様に基づく説明へ切り替える選択があります。人に残すのは文章をゼロから書く負担とは限りません。確認が必要な論点を分け、答えられる問いに整えるところまでをAIに任せる設計です。

費用や実績を一律に人の記憶へ任せる必要もありません。請求記録や測定記録があるなら、機械で照合できる範囲があります。反対に台帳に値があっても、使う意味が案件ごとに違えば人の判断が必要です。「数字は機械、感想は人」という固定した分け方より、根拠があるか、対象が特定できるか、用途が許されるかで考える方が実務に合います。人が確定した場合は、回答、根拠、確認日時を残します。確認したのが表現なのか事実なのかも分ければ、その後の修正で何を再確認すべきかが分かります。

質問を増やしすぎると確認者の負担が戻ってしまいます。今回の案内で使わない項目は聞かず、公開前に必要な項目と、後で調べられる項目を分けます。回答者が「分からない」を選べるようにして、形式的な回答で空欄を埋める圧力を減らすことも、情報の確かさを保つための設計です。

確認済みの値が変わったら差分を見せる

販売計画が更新され、開始日が一週間延びたとします。既に担当者が承認した案内文を自動で書き換えると、承認した内容と掲載内容がずれます。更新を見つけたら、変更前と変更後、変更された根拠、影響する文面をまとめて確認へ返す方法を提案します。商品名だけの変更と、価格や期間の変更では必要な判断が違います。どの項目の変更が再確認を必要とするかを、あらかじめ決めます。取得処理を最新化することと、人の承認を最新化することは別の仕事です。

全てを最初から確認し直す方法は分かりやすい一方、変更が一項目でも負担が増えます。差分だけを確認する方法は効率的ですが、変更の影響が広がる場合を見落としやすくなります。開始日の変更がキャンペーン見出しや配送予定にも関係するなら、その関連箇所まで示す必要があります。値と使用箇所を結び付けておけば、どの文章を作り直すかを選べます。確認待ちの間は旧版を配信するのか、公開を止めるのかも決めます。業務の運用条件によって答えが変わるため、単純な上書きを既定にしないことが重要です。

変更通知には、誰が確認するかも付けます。価格の承認担当へ、おすすめ理由の回答までまとめて送ると担当範囲が曖昧になります。項目ごとの担当を決め、代行する場合の条件も残します。通知されたことと確認が終わったことを別に表示すれば、未対応の変更を探せます。

失敗例を使って補完の境界を試す

検査用には、正常な商品、同名の商品、税別と税込が混在した価格、期限切れの販売計画、台帳への接続失敗、担当者が未使用と答える例を用意します。期待する結果は先に定めます。同名なら選択条件が足りないと返す、単位が不明なら価格を掲載しない、未使用なら体験談を作らない、と具体化します。正しい情報を一件埋められただけでは、危険な補完を防げるかは分かりません。止める例と進める例の両方を比べると、慎重すぎて仕事が進まない設計も見つけられます。

検査の結果は、出力の文面だけでなく根拠と状態も確認します。名称が正しく見えても、別の商品から取った値なら不合格です。通信失敗を「台帳に登録なし」と表示したなら、利用者に誤った作業をさせるため修正が必要です。確認後の資料更新も試し、古い承認で新しい価格が掲載されないことを確かめます。こうした条件を試作の検査に加え、各状態が期待どおり返るかを調べます。補完の精度を評価する前に、どんな誤りをどの検査で見つけるかを用意しておくことが、実務で使う範囲を決める材料になります。

正常例だけで試すと、台帳から必ず値が返ることを前提にした画面になりがちです。取得できない例を先に見ると、必要な説明や再開ボタンが分かります。再試行しても改善しない入力不足を何度も取得し直さず、問題の種類に応じて次の行動を変えられるかを確認します。

事例から借りられるのは、根拠を残す姿勢

関連する金融データ基盤の開発例では、取得値ごとの出所や網羅率、原本を保持する機能が提供資料に記されています。医療系の業務代行例では、分類、修正、起票と、人が行う操作の分担が示されています。これらは商品案内の補完を導入した事例ではありません。異なる仕事でも、値だけを渡さず取得元を残すこと、機械が扱える範囲と人の判断を分けることは、設計を比較する観点になります。事例の機能から、同じ仕組みの導入効果まで推し量らないようにします。

別の業務で使った補完方法をそのまま移すと、業務ごとの権限や鮮度条件を見落とす可能性があります。社名を補う仕事と、請求先の情報を更新する仕事では、誤りの影響も取り消しやすさも違います。導入する際は、一つの案内文や一種類の帳票から始め、担当者が根拠を確認できるか、確認待ちを解消できるかを見ます。どこまで機械に任せられるかは、AIの文章能力だけでは決まりません。根拠を取得する連携、対象の照合、人が引き取れる画面まで含めて判断する必要があります。

事例の規模や工程数が大きいことは、全ての入力補助が同じ規模を必要とする根拠にはなりません。一種類の台帳、一種類の案内だけでも、出所を記録する価値があります。担当者が調べ直す時間や訂正理由を観察し、必要な連携だけを段階的に追加する方法を考えられます。

小さく始めるなら、一項目の確定から

最初の試作では、商品名だけを指定台帳から取得し、取得元と一緒に表示する範囲に絞る方法があります。価格や販売期間まで一度に扱うより、対象の選び方と根拠への戻り方を検証しやすくなります。次に単位がある価格、更新がある販売期間、人の経験が必要な理由へ広げます。項目を追加するたびに、失敗したときの返し方と確認の担当も追加します。補完できる項目数を増やすより、確定した値と未確定の値を見分けられる状態を先に作る方が、次の開発判断につながります。

運用後は、担当者がどの項目を訂正したかを集めます。台帳の誤りなら元情報の保守、対象選択の誤りなら連携条件、質問が分かりにくいなら確認画面の改善、と修正先を分けられます。AIへの注意書きを増やすだけで終える必要はありません。なお、台帳の情報自体が正しいことをこの仕組みだけで保証はできません。根拠を示すことで確認が可能になる範囲と、根拠そのものを点検する仕事を分けておきます。入力補助が成功したと言えるのは、空欄が消えたときより、担当者が根拠と残る判断を説明できる状態になったときです。

次の段階へ進む判断では、補完率より訂正の内容を重視します。毎回同じ対象の取り違えが起きるなら、文章の生成能力を上げる前に対象を選ぶ条件を修正します。確認者が判断できない根拠なら、表示を増やすより資料の整理が必要です。改善の対象を工程へ戻せる記録が、試作を続ける理由になります。