AI依頼の入力検証を工程ごとに置く——必須・空白・未定を分けて再開する設計案

見積の下書きができても、対象が分からない

「申請作業を自動化したいので見積をください」という依頼を受けたとします。AIは一般的な工程を想定し、画面や機能の案を整えて返せます。しかし、対象の申請が何か、どこまでを自動化するか、成果物は何かが分からなければ、その下書きは見積の判断に使えません。文章ができたことと、見積に必要な情報がそろったことは別です。必須情報の欠落をAIの気付きだけに任せず、次の工程に入る前の検査として定めると、何が足りないかを説明できます。

見積準備では、次の判断に必要な情報が未設定なら、工程を止めて不足を返す検査を設計できます。値の存在を確かめる工程と、分類や内容を判断する工程を分けると、項目が埋まっただけの依頼を妥当な依頼と取り違えずに済みます。依頼者へ最初から全ての答えを求めるのではなく、初期調査、試作、見積の確定で必要な情報を分けます。必須項目を増やすだけでは、依頼者が形式的な値を埋めて通す原因になるため、どの時点で何の判断に使うかまで決めます。

例えば、対象業務と欲しい成果を初期調査の必須項目とし、納期は未定を許します。見積を確定する前には、対象範囲と受入条件を確認する、と段階を分けます。未定を許すことと、最後まで放置することを区別する設計です。

入口の必須項目を、業務の判断へ結び付ける

対象業務という項目は、調査するシステムや資料を選ぶために必要です。欲しい成果は、下書きを作ればよいのか、既存画面へ接続するのかを決めるために必要です。納期が未定でも技術調査は始められる場合がありますが、本番の公開日が決まっているなら設計判断に影響します。各項目について、欠けると何が決められないかを説明します。「必須だから入力する」という欄より、情報の用途が分かる欄の方が、依頼者も必要な内容を選びやすくなります。

入力が「社内の申請、できれば全部自動化」なら、対象の具体化が必要です。申請の種類、今の受付先、最終的に誰が判断するかを短く聞きます。依頼者がシステム名を知らなくても、今使っている画面や帳票、困っている作業を説明できれば調査の入口になります。専門用語を要求することは必須項目の検査ではありません。業務担当が答えられる表現へ変換し、取得できる情報は既存資料から補います。確認が必要なものだけを質問へ返すことで、入口の検査を実務に合わせます。

項目を定める際は、単なる好みを必須にしないようにします。画面の色が未定でも業務調査はできます。反対に対象のデータを使う権限が不明なら、実データでの試作は進められません。判断の重要さと入力欄の順序をそろえます。

依頼者が資料を持っていない場合は、誰が取得できるかを確認します。本人へ同じ質問を繰り返すより、既存の業務担当や承認済み資料から分かる範囲を調べる方が有用なことがあります。取得の権限がない情報は、推測で補わず、必要な提供元を明示して返します。

存在、形式、妥当性を別々に確かめる

項目があること、形式が正しいこと、業務に適していることは三段階です。対象業務の欄に文字があっても、「お任せ」では対象を特定できません。納期が日付の形で書かれていても、現在より前の日付なら確認が必要です。担当者が登録済みの人でも、今回の申請を承認する権限があるとは限りません。通常のプログラムは項目や形式を検査し、業務上の適切さは資料と担当者の判断へつなぐ方法があります。一つの合格表示で全てを確認済みにしないようにします。

空欄の扱いも具体化します。項目自体がない、空文字、空白だけ、未定と答えた、対象外と答えた状態を分けます。未定を許す欄では、その状態を明示して進められます。必須欄に空白だけを入れた場合は不足として返します。対象外なら、なぜ今回の業務で不要かが分かる条件を使います。この区別がないと、正常な未定まで拒否したり、必須情報の欠落を未定として通したりします。欠落の検査は厳しさを競う仕組みではなく、今回の工程へ進める条件を説明する仕組みです。

検査対象の選択肢が変わる場合は、いつの一覧に照らしたかを残します。古い案件で使った分類を全て無効にする必要があるかは業務次第です。形式の更新を、既存案件の意味が変わることと同じに扱わないようにします。

この設計案では入力スキーマを工程ごとに定め、通常のプログラムで必須項目、空白、値の形式を検証します。スキーマは受け取る項目と値の条件を定める契約です。「未定」を許す項目はその状態を明示し、項目欠落と分けます。一方、「お任せ」という値で対象を決められるかは意味の確認へ回し、スキーマ検査の成功を業務上の妥当性まで広げません。

止めるときは、次に答えることを返す

「情報不足のため停止」とだけ伝えると、依頼者は同じ説明を長く書き直すかもしれません。対象の申請が不明なら、「勤怠、経費、購買のどれに近いか。分からなければ現在の帳票を示してください」と返す方法があります。何が不足し、なぜ必要で、どう補えば再開できるかを示します。必要な資料を調べる担当が別なら、その担当へ渡す情報もまとめます。停止理由を利用者の行動へつなげることで、検査が単なる拒否ではなく進行の支援になります。

一度に大量の質問を返すと、入口の負担が増えます。まず対象と成果を確かめ、調査で分かる項目は後へ回す方法を提案します。見積を確定するために後で必要な納期や保守条件は、確認予定として残します。最初の調査を始める条件と、完成を受け入れる条件を分ければ、情報がまだない状態でも独立して進められる仕事を選べます。ただし未確認のまま本番更新や外部公開へ進めるわけではありません。工程の進行ごとに必要な条件を検査し直します。

利用者へ返す表には、足りない項目だけでなく、既に確認した項目も示します。全部を最初から入力し直さずに済み、確認が積み重なっていることが分かります。どの情報を追加すればどの工程へ進むかを短く示すと、再開の判断が容易になります。

追加した情報に合わせて、成果も作り直す

依頼者が対象を経費申請から購買申請へ変更したとします。必須欄が埋まったとしても、古い経費申請の見積案を残していれば整合は戻りません。入力の変更がどの成果に影響するかを結び付けます。対象業務なら工程案と接続調査、納期なら計画、公開範囲なら権限の確認など、作り直す対象を選びます。修正した欄だけを検査して終わる設計では、後段に古い前提が残ります。入力の版と確認した成果を一緒に管理する方法が有用です。

全ての成果を無条件に作り直すと、調査済みの内容まで失う場合があります。変わらない接続仕様や、共通する帳票の確認は再利用できることもあります。ただし再利用の条件を説明できる必要があります。対象が変わっても同じシステムを使う、同じ権限で参照できる、といった根拠を確認します。開発パートナー（ヤクモ）提供の計画エンジン例では、作業の依存関係や制約、版を扱う機能が示されています。依存関係と版の管理を見積準備へ応用するなら、入力検査との対応を追加して確かめる必要があります。

人が確認した項目も、関係する入力が変われば再確認の対象になります。以前の回答を勝手に新しい案件へ当てはめないよう、確認の対象を残します。追加の質問を減らす工夫と、古い判断の使い回しを避ける工夫を両立させます。

依存する成果の一覧には、変更に影響しないものも残します。接続先は変わらず、申請の種類だけが変わったなら、接続の基本調査を再利用できる場合があります。再利用した根拠を記すことで、無駄な再作業を避けながら、古い業務判断の混入を確認できます。

欠落した例だけでなく、正常例を通す

検査用には、対象業務がない依頼、空白だけの依頼、無効な日付、納期が未定の正常依頼、対象が具体的な依頼を用意します。期待結果を先に決め、欠落は止め、未定を許す項目は進め、無効な形式は修正へ返すことを確認します。全件止める検査は欠落を見逃さなくても、業務に使えません。正しい依頼が調査へ進むことも、受入条件です。欠落の発見件数だけで判断せず、誤停止した理由も記録すると、必須条件を適切に見直せます。

AIが妥当性を判断する部分では、入力の言い換えでも結果が保たれるかを確認します。「経費の申請を整理したい」と「立替払いの手続きを楽にしたい」は、同じ業務へ分類できる可能性があります。一方で、購買と経費の違いを消してはいけません。分類の期待結果は業務担当が資料に照らして定めます。検査で使った例の成功を本番の全依頼へ拡大せず、使った対象と未確認の範囲を残します。欠落を意図的に与えた試験で止まったことと、新しい本番入力を適切に扱えたことは別の結果として残します。

停止理由の文面も確認対象です。問題のない欄を直すように案内していれば、内部の判定が正しくても利用者は再開できません。追加した情報で適切な地点から再開できるかまで試すと、入口の検査を業務の進行へ結び付けられます。

運用で見つかる不足を、適切な工程へ戻す

入口を通過した後に情報不足が見つかっても、必ず入口の必須項目を増やす必要はありません。初期調査で初めて分かる接続制約なら、調査後の検査へ追加する方が適切です。毎回依頼者へ全ての技術条件を要求すると、相談が始められなくなります。どの工程で何が判明し、どの工程までに必要かを整理します。入口の見逃し、工程中の新情報、依頼の変更を分けると、必要な検査の場所を選べます。チェックリストの長さだけで品質を評価しないことが大切です。

運用では、止まった件数、停止理由が正しかったか、追加の回答で再開できたか、後段で再び不足したかを追います。手戻り時間を測る場合は、開始と終了の定義を決めてから記録します。検査を導入しただけで時間短縮を断定することはできません。関連する記事制作の実装例には、根拠確認、レビュー、人の承認を分ける契約がありますが、見積準備への適用効果は別の測定になります。機能の考え方と効果の実測を別に扱うことで、次に集めるべき記録が見えます。

停止が多い場合、利用者が不慣れなのか、欄の説明が悪いのか、必須条件が過剰なのかを切り分けます。利用者へ注意を増やすだけでは解消しない問題もあります。入力画面や取得可能な資料の整理を改善対象へ含めます。

入口の負担が高いと、相談者は分からない欄へ仮の値を入れることがあります。分からない状態を明示できる選択を設け、必要な時点までに確認する経路を作ります。仮の回答が確定値として後段へ流れないことを検査し、入力の完成度と業務の進行を分けます。

最初は、一つの工程の開始条件から

導入するなら、見積準備の初期調査を始める条件だけに絞る方法があります。対象業務と成果を確認し、納期未定は明示して進めます。次に調査後の見積確定条件、さらに実装後の受入条件へ広げます。工程ごとに条件を増やせば、最初から巨大な入力フォームを作らずに済みます。機械で検査できる項目、資料へ照らす項目、人が判断する項目を一つの表へまとめると、担当の役割も明確になります。判断をAIに任せる範囲を、情報の不足に合わせて限定できます。

残る制約は、値が存在しても内容が正しいとは限らないことです。必須欄に具体的な言葉があっても、業務の理解が間違っている場合があります。入口の合格を、依頼の全内容が適切という保証へ広げません。形式の検査と意味の確認を分け、合格した範囲を示します。停止できることだけでなく、必要な情報を受け取り再開できることまでを完了条件にします。必須項目の検査が役立つのは、利用者を厳しく管理するからではなく、次の判断に必要な情報と残る確認を説明できるからです。

設計の変更後は、以前の正常例が通るかも確認します。新しい項目を追加して既存の依頼を無条件に失敗へ変えると、進行中の仕事が止まります。対象となる案件を明示し、移行の扱いを決めることが、運用で検査を維持するための条件です。